24 Jul 2017

Операционная система

Operačný systém (OS) je softvér, ktorý spravuje zdroje počítača a poskytuje programom rozhranie na prístup k týmto zdrojom. Operačný systém tiež spracúva systémové dáta a vstupy od používateľa a odpovedá alokovaním a spravovaním úloh a interných zdrojov počítača ako služby pre užívateľa. OS vykonáva základné úlohy ako kontrola a alokovanie pamäte, pridelenie priority systémovým požiadavkám, kontrola vstupných a výstupných zariadení, umožnenie pripojenia do siete a správa súborov. Operačné systémy môžeme nájsť takmer vo všetkom, čo obsahuje integrované obvody, od osobných počítačov, cez internetové servery, mobilné telefóny, hudobné prehrávače, routre, switche, herné konzoly, digitálne kamery, až po šijacie stroje či teleskopy.

Vo väčšine prípadov operačný systém nie je prvým kódom, ktorý sa spúšťa v počítači pri bootovaní. Inicializačný kód, vykonávaný v počítači, je zvyčajne nahratý z firmvéru, ktorý je uložený vo Flash ROM, niekedy označovaný aj ako BIOS alebo boot ROM. Firmvér nahrá a spustí jadro operačného systému (zvyčajne z disku, niekedy aj cez sieť) a zobrazí prvý grafický alebo textový výstup, ktorý užívateľ uvidí.

Read more
24 Jul 2017

Sistema operativo

운영 체제(運營體制, 문화어: 조작체계) 또는 오퍼레이팅 시스템(영어: Operating System, OS)은 시스템 하드웨어를 관리할뿐 아니라 응용 소프트웨어를 실행하기 위하여 하드웨어 추상화 플랫폼과 공통 시스템 서비스를 제공하는 시스템 소프트웨어이다. 최근에는 가상화 기술의 발전에 힘입어 실제 하드웨어가 아닌 하이퍼바이저 위에서 실행되기도 한다.

입출력과 메모리 할당과 같은 하드웨어 기능의 경우 운영 체제는 응용 프로그램과 컴퓨터 하드웨어 사이의 중재 역할을 한다.[1][2] 그러나 응용 프로그램 코드는 일반적으로 하드웨어에서 직접 실행된다. 운영 체제는 휴대 전화, 게임기에서부터 슈퍼컴퓨터, 웹 서버에 이르기까지 컴퓨터를 포함하는 거의 모든 장치에서 볼 수 있다. 운영 체제는 한 면으로는 소비자를, 다른 한 면으로는 프로그램 개발자를 함께 하나의 시장으로 데려다 놓을 수 있는 양면 플랫폼이다. 잘 알려진 현대의 PC 운영 체제에는 마이크로소프트 윈도우, 맥 OS X, 리눅스가 있다.[3] 이 밖에 BSD, 유닉스 등의 PC용 운영 체제도 존재한다.

운영 체제는 실행되는 응용 프로그램들이 메모리와 CP

Read more
19 Jul 2017

Exploratory Tours

Intellectual tour (тур интеллектуала)
Вы - “турист-всезнайка”. Перед экскурсией вы уже погуглили все о том месте, куда идете: история, обычаи, самые удобные места для фото - ничего не ускользнуло. A вот ваш гид похоже не хочет рассказывать и половины из того, что есть во всемирной паутине! Вам очень хочется поделиться со всей группой своими знаниями, вы все время задаете наводящие вопросы своему гиду, чтобы он рассказал группе все те безумно интересные вещи, которые вы нашли вчера в интернете.
В тестировании: пытаемся задавать приложению самые сложные вопросы: какие фичи могут довести приложение “до предела”?Какие данные будут долго обрабатываться? Какие невалидные данные могут все разрушить? Пробуем хитрые сценарии, с большим объемом данных, осознанном вызове ошибок.

Supporting actor tour (тур актера второго плана)
Обычно туристы ходят только по самым известным местам, которые стыдно не посмотреть коли приехал. Вы - не из таких: замечаете, что за поворотом есть что-то интересное и убегаете посмотреть не самые популярные места, а наоборот, никому не известные, но совсем рядом с туристическими мекками.
В тестировании: смотрим не основную функциональность, а рядом с ней, тех, кто рядом, но обычно “в тени”.

Collector’s tour (тур коллекционера)
У вас дома большая коллекция тарелочек из разных городов мира, весь холодильник усыпан магнитиками и конечно же из каждого города вы посылали себе открытку и бережно храните их все.
В тестировании: собирайте все, что найдете, все, что пользователь может “сохранить” себе на память: файлы, ссылки, закладки, история браузера, куки, локальное хранилище данных.

Supermodel tour (тур супермодели)
Вы любите созерцать. Просто смотреть и получать удовольствие от разглядывания красот.
В тестировании: этот тур не про функциональность, а про первое впечатление. Смотрим только UI: хорошо ли выглядит? Хорошо ли отображается, быстро ли?после изменений в данных, изменяются ли они в интерфейсе? Нет ли лишних артефактов в интерфейсе? Если в приложении есть какие-то цвета - по делу ли они используются? Панельки расположены там, где вы их ожидали? понятны ли иконки?

TOGOF tour (Test-One-Get-One-Free, тур шопоголика)
Вы зашли в сувенирный магазин, а там на полках всюду вывески вроде “при покупке сувенира, еще один получаете в подарок!” (Buy One Get One Free)
В тестировании: работаем с одним и тем же объектом или данными одновременно, удаляем и в это время редактируем, отправляем конфликтующие данные, …

Rained-out tour (тур, отмененный из-за дождя)
Сегодня вам не повезло: вы хотели ехать на длинную загородную прогулку, но пошел дождь. теперь нужно позвонить гиду и отменить участие, потом отменить забронированный велосипед для прогулок по парку, да и столик в ресторане тоже..
В тестировании: отменяет все, что только можно, и любыми способами :) “Cancel”, “Undo”, диспетчер задач, закрыть вкладку, esc, “вперед-назад” в браузере.. (данные не должны теряться, пользователь должен осознавать , что именно изменится, действие можно повторить,..)

The Antisocial Tour (антисоциальный тур)
Сегодня вы - против всех. Все на море - вы в отель, все в отель - вы на море.
В тестировании: выполняем все, что пользователи вряд ли буду делать, вводим запрещенные данные, противоречим логике приложения, например в плейлист вставляем 10763 песни (позитивные, но маловероятные значения), вводим инъекции, текст в числовые поля, заполняем поля формы не по порядку,..

The Obsessive-Compulsive Tour (Обсессивно-компульсивный тур)
Сегодня вы не в себе: повторяете одни и тебе фразы, дергаетесь, ходите взад-вперед по одной и той же улице..
В тестировании: повторяем одно и тоже много раз одни и те же входные данные, одни и те же действия или их последовательность. Добавляем - отменяем - отменяем отмену - копируем - отменяем - вставляем - отменяем, кликаем на одну кнопку несколько тысяч раз..

Read more
19 Jul 2017

Парадокс пестицида

Более 20 лет назад, в 1990 году, Борис Бейзер в свое книге “Software Testing Techniques” ввел понятие, известное как “парадокс пестицида” (pesticide paradox), которое формулируется следующим образом:

Каждый метод, который вы используете, чтобы предотвратить или найти ошибки, оставляет часть ошибок, против которых эти методы уже неэффективны.

На простом языке это означает, что если вы будете часто запускать одни и те же тесты, то со временем они перестанут находить ошибки. В своей книге Бейзер привел следующую аналогию между повторным выполнением тестов и обработкой сельскохозяйственных полей химикатом (в частности, пестицидом), который уже был применен ранее. После первой обработки химикатом большая часть вредителей погибает, однако все же некоторая часть из них выживает, потому что их организм оказался устойчив к яду. Те, кто выжил, с большой вероятностью переживут и последующие обработки пестицидом.

По этой причине тестовые наборы всегда требуют своего обновления, независимо от того, запускаются ли они в автоматическом или ручном режиме.

Существует ряд обстоятельств, по которым хороший тестовый набор со временем утрачивает свою эффективность:

  1. Невозможно проверить все возможные сценарии

Даже простые приложения требуют большого количества тестов для проверки всех возможных сценариев и комбинаций данных. Вот почему мы прибегаем к помощи различных принципов, таких как классы эквивалентности или тестирование на основе модели, но все же и этого не достаточно. Большинство команд используют тестирование на основе рисков, создавая подмножество сценариев и наборов данных, а затем используют выявленные ошибки, найденные уже после первого релиза, для улучшения (изменения) своих тестовых сценариев. Это означает, что мы тестируем не все.

  1. Функциональность приложения изменяется с течением времени

Каждый раз, когда в продукт вносятся изменения, тестовые сценарии также должны обновляться в соответствии с этими изменениями. Нужно всегда помнить, что любое, даже незначительное изменение, может повлиять на работоспособность всей системы, поэтому важно изменять тесты каждый раз, когда такие изменения происходят.

  1. Люди осторожничают только там, где чувствуют непосредственную опасность

Это означает, что разработчики всегда будут проявлять гиперосторожность лишь в тех местах, где ранее тестировщики обнаружили проблемы. Однако там, где раньше было “все ОК”, их внимательность снижается на порядок. Т.е. другими словами, разработчики учатся избегать ошибок, которые находятся тестами.

Для того, чтобы преодолеть парадокс пестицида, тестировщики должны постоянно писать новые и различные тесты для покрытия разных частей программы для нахождения как можно большего количества ошибок.

Вот несколько рекомендаций на этот счет:

  1. Следите за изменениями в продукте и предугадывайте их возможные последствия

Необходимо приложить определенные усилия для того, чтобы понять, какие места в программе могло затронуть даже совсем небольшое изменение. После этого можно приступить к написанию дополнительных тестов, покрывающих эти изменения.

  1. Откажитесь от неэффективных тестов

Бесполезно держать большое количество тестов, которые в итоге не помогают вам. К примеру, если у вас есть 10 тестов, которые покрывают одну и ту же область, и ни один из них за все время так и не нашел ошибок, то вполне целесообразно сократить число таких тестов.

  1. Постоянно меняйте тестовые данные

Хоть это и кажется очевидным, но мы порой склонны забывать об этом. Многие ошибки в наших продуктах имеют специфический характер (особенно в автотестах), поэтому мы должны постоянно увеличивать / изменять тестовые данные (к примеру, использовать как можно больше тестовых БД).

  1. Используйте неформальные средства тестирования

Используйте по крайней мере один вид неформального тестирования за цикл (или за релиз). Допустим, вы можете прибегнуть к исследовательскому виду тестирования.

Read more
18 Jul 2017

Test Plan

The test plan is the master document about the activities regarding the testing of a certain feature (or another possible subject of testing, e.g., how the system handles a load).

Test plans come in many shapes and forms, but the majority of them have their roots in the test plan document introduced by ANSI/IEEE Standard 829-1983. For my projects I use a simplified version of this. Let’s look at the main sections.

General info

Introduction

Schedule

Feature documentation

Test documentation

Things to be tested

Things not to be tested

Entry/Exit criteria

Suspension/Resumption criteria

Other things

THINGS TO BE TESTED

Here you describe what you are going to test and how.

Example:

Subject of testing Testing approach
Check out with Visa 1. Component testing:
a. Positive testing: card valid + enough balance
b. Negative testing: card is invalid/not enough balance.
2. Integration testing:
a. Integration with Shopping Cart
3. System testing: Search->View book->Shopping cart->Checkout
Read more