Тестирование метод черного ящика: Тестирование методом черного ящика / Хабр

Тестирование методом черного ящика / Хабр

Книга «A Practitioner’s Guide to Software Test Design» Lee Copeland была опубликована в 2003 году.

С тех пор она надежно закрепилась в списке книг, которые обязательно должен прочитать любой тестировщик. Её стоит прочитать в оригинале. Читается очень приятно: язык не сложный, стиль легкий. По ходу книги автор слегка иронизирует над собой, своими учениками, читателями и в целом над сферой нашей деятельности.

Далее приводится не перевод, а скорее подробный конспект раздела “Техники тестирования методом черного ящика”, в котором содержится описание применения техник тест-дизайна.

Ко мне в руки книга попала по совету бывшего коллеги, за что ему отдельное спасибо.

To be most effective and efficient test case must be designed, not just slapped together.

Equivalence Class Testing
Boundary Value Testing
Decision Table Testing
Pairwise Testing
State-Transition Testing
Use Case Testing

Классы эквивалентности (Equivalence Class Testing)

Техника

1. Определить классы эквивалентности.
2. Создать тест-кейсы для каждого класса эквивалентности.

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

Любые данные в рамках класса эквивалентны, это означает что если один тест-кейс в кассе эквивалентности обнаружил/не обнаружил дефект, то все остальные тест-кейсы внутри этого класса эквивалентности обнаружат/не обнаружат тот же самый дефект.

Альтернативный подход — использование классов эквивалентности не для входов, а для выходов. Разделить варианты выходов на классы эквивалентности, определить какие входные значения могут инициировать такие выходы. Преимущество в том, что проверяется каждый возможный вариант выхода. Недостаток в том, что внутри класса эквивалентности по выходу, может прятаться несколько классов эквивалентности по входу.

При наличии нескольких переменных:

1. валидные классы нескольких переменных объединяются в один тест-кейс;
2. невалидные классы тестируются отдельно.
   

   Let your designers and programmers know when they have helped you. They’ll appreciate the thought and may do in again.

Граничные значения (Boundary Value Testing)

Техника

1. Определить классы эквивалентности
2. Определить границы каждого класса эквивалентности
3. Создать тест-кейсы для каждого граничного значения, выбирая по одной точке непосредственно на границе, выше и ниже границы.

Следует помнить, что точка выше или ниже границы может быть экземпляром другого класса эквивалентности, в этом случае дублировать тест не нужно.

Значения определяются типом. Если граница 5, то для поля, где вводятся целые числа тестируются точки 4 и 6, а для поля, где вводятся суммы в рублях и копейках тестируются точки 4,99 и 5,01.

При наличии нескольких переменных:

1. минимальные значения валидных границ объединяются в один тест-кейс;
2. максимальные значения валидных границ объединяются в другой тест-кейс;
3. невалидные границы тестируются отдельно, как и в случае с невалидными классами.
   

   Boundary value testing focuses on the boundaries because that is where so many defects hide.

Таблица принятия решений (Decision Table Testing)

Техника

1. Определить все условия
2. Составить все возможные комбинации условий
3. Убрать лишние комбинации. Удаляются те, в которых изменение значений никак не влияет на получаемый результат (Don’t care — DC)
4. Определить действия
5. Создать тест-кейсы для каждой комбинации

Таблица принятия решений — представляет связь составных условий и результирующих действий.

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

Внимательно посмотрев на таблицу, можно заметить, что в правилах 1, 2, 3, 4, если код акции недопустимый, то проверка остальных условий не имеет смысла. Правила 5 и 6 могут быть объединены, т.к. условие проверки средств никак не влияет на результат. Условия, которые не оказывают влияние на результат помечаются как “DC”. Таблица преобразуется:

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

Famous Software Tester Mick Jagger gives excellent advice regarding this “You can’t always get what you want, but if you try sometimes, you just might find, you get what you need.”

Попарное тестирование

Техника

1. Определить параметры (variables)
2. Определить количество значений для каждого параметра (choices for variable)
3. Построить массив, содержащий колонки для каждого параметра и значения в колонках, которые содержать все сочетания значений этих параметров друг с другом.
4. Сопоставить полученный ортогональный массив с целью тестирования.
5. Построить тест-кейсы.

Опытным путем было определено, что большинство дефектов это или одиночные дефекты (single-mode defects), или парные дефекты (double-mode defects), т.е. проявляющиеся при сочетании одного параметра всего лишь с одним другим параметром, при том что значение остальных параметров не имеет значения.

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

Два подхода попарного тестирования (pairwise testing): метод ортогонального массива (orthogonal arrays) и метод всех пар (allpair algorithm).

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

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

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

Нужно учитывать, что могут возникнуть ограничения связанные с тем, что некоторые сочетания параметров никогда не будут иметь места.

There is no underlying “software defect physics” that guarantees pairwise testing will be of benefit. There is only one way to know — try it.

Диаграмма переходов состояний

Техника

Состояние (State) — Условие в котором система ожидает одно или несколько событий.Состояние помнит что было получено на вход и определяет ответную реакцию, которая должна произойти. Это событие может быть приводить в новое состояние и/или инициировать новое действие. Состояние обычно отражает значение некоторой переменной в системе. Изображается в форме круга.

Переход (Transition) — Представляет переход из текущего состояния в новое, в результате выполнения какого-то действия. Изображается в виде стрелки.

Событие (Event) — Событие, ставшее причиной изменения состояния. Обычно событие поступает в систему из внешнего мира посредством некоторого интерфейса. Иногда это событие инициируется внутри самой системы например такие как срабатывание таймера, снижение ниже какого-то уровня. Считается, что событие происходит моментально. Событие может быть как независимым, так и связанным. Когда событие случается, система может изменить состояние или остаться в прежнем состоянии и/или инициировать действие. События могут иметь, связанные с ними параметры (номер карты, сумма на счете). Изображается как подпись к стрелке перехода.

Действие (Action) — Операция, инициированная в результате смены состояния. Зачастую это некоторый ответ системы. Помните, что действие происходит при переходе между состояниями. Состояния сами по себе статичны. Указывается через слеш в подписи к стрелке перехода после события.

Диаграмма перехода состояний представляет собой одну специфическую сущность (например, процесс резервирования). Частая ошибка — попытка смешивать разные сущности в одной диаграмме (например Резервирование и Пассажира с событиями и действиями, связанными с каждым из них).

Может использоваться, когда системе нужно знать предысторию или правильный порядок выполнения операций.

На основании Диаграммы перехода состояний составляется Таблица перехода состояний. Таблица содержит 4 колонки: текущее состояние, событие, действие, следующее состояние.

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

Может быть выбран один из 4 вариантов создания тест-кейсов:

1. Создать наборы тест-кейсов так, чтобы все состояния были пройдены хотя бы по одному разу. В одном тест-кейсе может быть описан переход через несколько состояний. Это довольно слабый уровень тестового покрытия.
2. Создать наборы тест-кейсов так, чтобы все события были инициированы хотя бы по одному разу. Тест-кейсы, которые покрывают все события в то же время покрывают и все состояния. Снова слабый уровень тестового покрытия.
3. Создать наборы тест-кейсов так, чтобы все пути были пройдены хотя бы по одному разу. Такой способ хорош с точки зрения тестового покрытия, однако практически не осуществим. Если диаграмма имеет циклы, то количество возможных путей может оказаться бесконечным.
4. Создать наборы тест-кейсов так, чтобы все переходы были выполнены хотя бы по одному разу. Этот способ обеспечивает хороший уровень тестового покрытия, поэтому рекомендуется использовать именно его.

   
   Рекомендуемая стратегия создания тест-кейсов состоит в том, чтобы хотя бы по разу протестировать все переходы между состояниями. В высокорисковых системах, где требуется более надежное тестовое покрытие, возможно создавать тест-кейсы на каждый путь (цепочку переходов) между состояниями.

   And now for something completely different. Monty Python

Варианты использования (Use Case Testing)

Техника

Use case — это сценарии, описывающие то как actor (обычно человек, но может быть и другая система) пользуется системой для достижения определенной цели. Варианты использования описываются с точки зрения пользователя, а не системы. Внутренние работы по поддержанию работоспособности системы не являются частью варианта использования.

Хотя бы один тест-кейс должен проверять основной сценарий и хотя бы по одному кейсу должно приходится на альтернативные сценарии.

Рекомендации по созданию тест-кейсов на основе вариантов использования

1. Начать с валидных данных и наиболее частых сценариев.
2. Проверить граничные значения и невалидные значения (с использованием ранее рассмотренных техник).
3. Редко используемые сценарии, крайне важные для системы (так называемая “Остановка ядерного реактора” Shut Down The Nuclear Reactor)
4. Тесты на каждое ветку-альтернативу (Extension) каждого шага
5. Попробовать выполнить операцию в непривычном порядке
6. Извратить предусловие, если это действительно может произойти
7. Если транзакция имеет циклы, запустите ее в цикле, и не один-два раза — будьте жестче
8. Найти очень долгий и извилистый путь и пройдите по нему
9. Если ожидается, что транзакция будет выполняться в логичном порядке, попробовать выполнить ее в обратном порядке (например заполнить поля не сверху вниз, а снизу вверх)
10. Создать тесты на защиту от дурака

Шаблон описания вариантов использования

If you don’t try strange things. you know the users will.

Открытый вебинар «Метод Pairwise Testing в Black Box тестировании»

Всем доброго времени суток!

Предлагаем вашему вниманию подробное описание открытого урока, посвящённого попарному тестированию. Мероприятие прошло всего пару дней назад и было приурочено к запуску курса «QA-специалист».

Преподаватель — Нина Деваева — Senior Tester, Team Leader и ISTQB-сертифицированный тестировщик, эксперт по направлению Quality Assurance.

На открытом уроке поговорили о необходимости такого вида техники тест-дизайна, как попарное тестирование (pairwise testing). Изучили кейсы применения на практике и подробно рассмотрели инструментарий, доступный для работы.

Перед началом вебинара поставили следующие цели:

• узнать, что из себя представляет попарное тестирование;
• узнать, в каких случаях допустимо применение попарного тестирования;
• научиться работать с инструментами попарного тестирования.

Несколько слов о тест-дизайне

Тест дизайн – это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы) в соответствии с определёнными ранее критериями качества и целями тестирования. Некоторые испытывают затруднение, когда их спрашивают, зачем нужен тест-дизайн. Между тем, ответ кроется в одном из принципов тестирования, а именно: исчерпывающее тестирование недостижимо. И это действительно так за исключением каких-либо тривиальных случаев, когда входных данных очень мало. Да и по большему счёту мало какой бюджет «потянет» все возможные проверки, которыми можно покрыть наш продукт.

Тестирование методом черного ящика

Хорошо известный метод, не требующий длительных разъяснений. Если вкратце, то black box testing — это функциональное или нефункциональное тестирование, которое выполняется без знания внутренней структуры компонента или системы. Метод основан на работе исключительно с внешними интерфейсами тестируемой системы.

Техники тест-дизайна при использовании метода черного ящика, включают:

• классы эквивалентности;
• анализ граничных значений;
• таблицы решений;
• диаграммы изменения состояния;
• попарное тестирование.

Если говорить о попарном тестировании, то существуют исследования, которые показывают, что большинство багов возникает при комбинации 2 каких-либо параметров. Именно поэтому в условиях ограниченных ресурсов и при огромном количестве входных данных имеет смысл использовать попарное тестирование.

Так что же такое попарное тестирование?

Попарное тестирование (pairwise testing) — это разработка тестов методом черного ящика, в которой тестовые сценарии разрабатываются таким образом, чтобы выполнить все возможные отдельные комбинации каждой пары входных параметров. Собственно говоря, попарное тестирование позволяет нам сэкономить много времени.

Для pairwise testing используются алгоритмы, основанные на построении ортогональных массивов или на All-Pairs алгоритме, которые опираются на теоретические исследования в области комбинаторных алгоритмов, алгоритмов дискретной математики и, в частности, латинских квадратов. Давайте остановимся на этих алгоритмах подробнее.

Тестирование с использованием ортогонального массива

Orthogonal array testing — систематический подход к тестированию всех парных комбинаций переменных с использованием ортогональных массивов. Такой подход значительно уменьшает количество комбинаций переменных при проверке всех парных комбинаций.

Ортогональный массив по сути — это таблица, где m — число строк, n — число столбцов, которое соответствует числу входных параметров, k — количество вариантов значений элементов таблицы. Таблица обладает следующими свойствами:

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

Например: — это ортогональный массив с четырьмя строками и тремя столбцами (по количеству переменных). Цифра 2 означает, что все переменные принимают только два значения – 1 и 2.

Например, у нашего приложения есть 3 входных параметра, причем каждый бинарный (принимает значение «1» или «2»). Таким образом, все возможные комбинации входных данных можно представить так:

Для наглядности давайте предположим, что у нас есть приложение «Фонарик», которое:

• работает с iOS и Android;
• имеет ночной и дневной режим подсветки;
• позволяет светить постоянно или мигать в режиме стробоскопа.

В общем, у нас есть три параметра, которые принимают бинарные значения.

Теперь давайте посмотрим, как будет выглядеть наша выборка после перевода в ортогональный массив:

Как видим, мы сократили число кейсов с 8 до 4 при 3 разных параметрах, принимающих бинарное значение. Это реальный выигрыш, который положительно отразится и на бюджете, и на ресурсах, которые мы используем.

All-Pairs Algorithm

All-Pairs Algorithm (алгоритм всех пар) — это комбинаторная методика, которая была специально создана для парного тестирования. В её основе лежит выбор возможных комбинаций значений всех переменных, в которых содержатся все возможные значения для каждой пары переменных. Исходя из определения, число комбинаций будет меньшее, чем при использовании ортогональных массивов.

При тестировании с использованием All-Pairs алгоритма выполняют следующие шаги:

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

Также нельзя не отметить тот факт, что ортогональные массивы и All-Pairs Algorithm используются с поправкой на предварительную выборку входных данных.

Тулзы для попарного тестирования

Чтобы не тратить время на сведение всех данных, можно и нужно использовать инструменты для попарного тестирования. Вот некоторые из них:

1. pairwise.teremokgames.com — сайт с понятным интерфейсом, работа с которым не требует специфических знаний.
2. PICT — свободный инструмент, разработанный Microsoft, для Pairwise Testing’а. Скачивается по следующей ссылке.

Разумеется, есть ещё Allpairs и VPTag, но разговор о них вышел за рамки прошедшего вебинара.

Практика и ещё раз практика

Теперь давайте попробуем, как эти инструменты работают на деле. Итак, постарайтесь выполнить два простых задания:

1. С помощью pairwiseTool произведите выборку комбинаций исходных параметров и скиньте ссылку на скриншот результата в комментарии. Берётся условный сайт, который должен открываться на Win 7, Win 8 и Win 10. Поддерживаемые браузеры — Google Chrome, Opera, Microsoft Edge, Mozilla Firefox, Яндекс.Браузер. Пользователи могут использовать или не использовать AdBlock.
2. С помощью программы PICT сделайте выборку комбинаций исходных параметров и скиньте ссылку на скриншот результата в комментариях. Необходимо провести конфигурационное тестирование со следующими комплектующими:

• видеокарты: GeForce GT 730, GeForce GT 1030, GeForce GTX 1080, GeForce RTX 2070;
• процессоры: Intel Core i5, Intel Core i7, AMD Ryzen 7, Intel Core i9;
• память: 8GB, 16GB.

На этом, пожалуй, всё. Более подробно ознакомиться с нюансами попарного тестирования можно, посмотрев вебинар полностью. И, да, не пропустите День открытых дверей курса «QA специалист»!

Тестирование методом черного ящика

Книга «A Practitioner’s Guide to Software Test Design» Lee Copeland была опубликована в 2003 году.

С тех пор она надежно закрепилась в списке книг, которые обязательно должен прочитать любой тестировщик. Её стоит прочитать в оригинале. Читается очень приятно: язык не сложный, стиль легкий. По ходу книги автор слегка иронизирует над собой, своими учениками, читателями и в целом над сферой нашей деятельности.

Далее приводится не перевод, а скорее подробный конспект раздела “Техники тестирования методом черного ящика”, в котором содержится описание применения техник тест-дизайна.

Ко мне в руки книга попала по совету бывшего коллеги, за что ему отдельное спасибо.

To be most effective and efficient test case must be designed, not just slapped together.

Equivalence Class Testing

Boundary Value Testing

Decision Table Testing

Pairwise Testing

State-Transition Testing

Use Case Testing

Классы эквивалентности (Equivalence Class Testing)

Техника

1. Определить классы эквивалентности.
2. Создать тест-кейсы для каждого класса эквивалентности.

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

Любые данные в рамках класса эквивалентны, это означает что если один тест-кейс в кассе эквивалентности обнаружил/не обнаружил дефект, то все остальные тест-кейсы внутри этого класса эквивалентности обнаружат/не обнаружат тот же самый дефект.

Альтернативный подход — использование классов эквивалентности не для входов, а для выходов. Разделить варианты выходов на классы эквивалентности, определить какие входные значения могут инициировать такие выходы. Преимущество в том, что проверяется каждый возможный вариант выхода. Недостаток в том, что внутри класса эквивалентности по выходу, может прятаться несколько классов эквивалентности по входу.

При наличии нескольких переменных:

1. валидные классы нескольких переменных объединяются в один тест-кейс;
2. невалидные классы тестируются отдельно.
   

   Let your designers and programmers know when they have helped you. They’ll appreciate the thought and may do in again.

Граничные значения (Boundary Value Testing)

Техника

1. Определить классы эквивалентности
2. Определить границы каждого класса эквивалентности
3. Создать тест-кейсы для каждого граничного значения, выбирая по одной точке непосредственно на границе, выше и ниже границы.

Следует помнить, что точка выше или ниже границы может быть экземпляром другого класса эквивалентности, в этом случае дублировать тест не нужно.

Значения определяются типом. Если граница 5, то для поля, где вводятся целые числа тестируются точки 4 и 6, а для поля, где вводятся суммы в рублях и копейках тестируются точки 4,99 и 5,01.

При наличии нескольких переменных:

1. минимальные значения валидных границ объединяются в один тест-кейс;
2. максимальные значения валидных границ объединяются в другой тест-кейс;
3. невалидные границы тестируются отдельно, как и в случае с невалидными классами.
   

   Boundary value testing focuses on the boundaries because that is where so many defects hide.

Таблица принятия решений (Decision Table Testing)

Техника

1. Определить все условия
2. Составить все возможные комбинации условий
3. Убрать лишние комбинации. Удаляются те, в которых изменение значений никак не влияет на получаемый результат (Don’t care — DC)
4. Определить действия
5. Создать тест-кейсы для каждой комбинации

Таблица принятия решений — представляет связь составных условий и результирующих действий.

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

Внимательно посмотрев на таблицу, можно заметить, что в правилах 1, 2, 3, 4, если код акции недопустимый, то проверка остальных условий не имеет смысла. Правила 5 и 6 могут быть объединены, т.к. условие проверки средств никак не влияет на результат. Условия, которые не оказывают влияние на результат помечаются как “DC”. Таблица преобразуется:

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

Famous Software Tester Mick Jagger gives excellent advice regarding this “You can’t always get what you want, but if you try sometimes, you just might find, you get what you need.”

Попарное тестирование

Техника

1. Определить параметры (variables)
2. Определить количество значений для каждого параметра (choices for variable)
3. Построить массив, содержащий колонки для каждого параметра и значения в колонках, которые содержать все сочетания значений этих параметров друг с другом.
4. Сопоставить полученный ортогональный массив с целью тестирования.
5. Построить тест-кейсы.

Опытным путем было определено, что большинство дефектов это или одиночные дефекты (single-mode defects), или парные дефекты (double-mode defects), т.е. проявляющиеся при сочетании одного параметра всего лишь с одним другим параметром, при том что значение остальных параметров не имеет значения.

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

Два подхода попарного тестирования (pairwise testing): метод ортогонального массива (orthogonal arrays) и метод всех пар (allpair algorithm).

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

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

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

Нужно учитывать, что могут возникнуть ограничения связанные с тем, что некоторые сочетания параметров никогда не будут иметь места.

There is no underlying “software defect physics” that guarantees pairwise testing will be of benefit. There is only one way to know — try it.

Диаграмма переходов состояний

Техника

Состояние (State) — Условие в котором система ожидает одно или несколько событий.Состояние помнит что было получено на вход и определяет ответную реакцию, которая должна произойти. Это событие может быть приводить в новое состояние и/или инициировать новое действие. Состояние обычно отражает значение некоторой переменной в системе. Изображается в форме круга.

Переход (Transition) — Представляет переход из текущего состояния в новое, в результате выполнения какого-то действия. Изображается в виде стрелки.

Событие (Event) — Событие, ставшее причиной изменения состояния. Обычно событие поступает в систему из внешнего мира посредством некоторого интерфейса. Иногда это событие инициируется внутри самой системы например такие как срабатывание таймера, снижение ниже какого-то уровня. Считается, что событие происходит моментально. Событие может быть как независимым, так и связанным. Когда событие случается, система может изменить состояние или остаться в прежнем состоянии и/или инициировать действие. События могут иметь, связанные с ними параметры (номер карты, сумма на счете). Изображается как подпись к стрелке перехода.

Действие (Action) — Операция, инициированная в результате смены состояния. Зачастую это некоторый ответ системы. Помните, что действие происходит при переходе между состояниями. Состояния сами по себе статичны. Указывается через слеш в подписи к стрелке перехода после события.

Диаграмма перехода состояний представляет собой одну специфическую сущность (например, процесс резервирования). Частая ошибка — попытка смешивать разные сущности в одной диаграмме (например Резервирование и Пассажира с событиями и действиями, связанными с каждым из них).

Может использоваться, когда системе нужно знать предысторию или правильный порядок выполнения операций.

На основании Диаграммы перехода состояний составляется Таблица перехода состояний. Таблица содержит 4 колонки: текущее состояние, событие, действие, следующее состояние.

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

Может быть выбран один из 4 вариантов создания тест-кейсов:

1. Создать наборы тест-кейсов так, чтобы все состояния были пройдены хотя бы по одному разу. В одном тест-кейсе может быть описан переход через несколько состояний. Это довольно слабый уровень тестового покрытия.
2. Создать наборы тест-кейсов так, чтобы все события были инициированы хотя бы по одному разу. Тест-кейсы, которые покрывают все события в то же время покрывают и все состояния. Снова слабый уровень тестового покрытия.
3. Создать наборы тест-кейсов так, чтобы все пути были пройдены хотя бы по одному разу. Такой способ хорош с точки зрения тестового покрытия, однако практически не осуществим. Если диаграмма имеет циклы, то количество возможных путей может оказаться бесконечным.
4. Создать наборы тест-кейсов так, чтобы все переходы были выполнены хотя бы по одному разу. Этот способ обеспечивает хороший уровень тестового покрытия, поэтому рекомендуется использовать именно его.

   
   Рекомендуемая стратегия создания тест-кейсов состоит в том, чтобы хотя бы по разу протестировать все переходы между состояниями. В высокорисковых системах, где требуется более надежное тестовое покрытие, возможно создавать тест-кейсы на каждый путь (цепочку переходов) между состояниями.

   And now for something completely different. Monty Python

Варианты использования (Use Case Testing)

Техника

Use case — это сценарии, описывающие то как actor (обычно человек, но может быть и другая система) пользуется системой для достижения определенной цели. Варианты использования описываются с точки зрения пользователя, а не системы. Внутренние работы по поддержанию работоспособности системы не являются частью варианта использования.

Хотя бы один тест-кейс должен проверять основной сценарий и хотя бы по одному кейсу должно приходится на альтернативные сценарии.

Рекомендации по созданию тест-кейсов на основе вариантов использования

1. Начать с валидных данных и наиболее частых сценариев.
2. Проверить граничные значения и невалидные значения (с использованием ранее рассмотренных техник).
3. Редко используемые сценарии, крайне важные для системы (так называемая “Остановка ядерного реактора” Shut Down The Nuclear Reactor)
4. Тесты на каждое ветку-альтернативу (Extension) каждого шага
5. Попробовать выполнить операцию в непривычном порядке
6. Извратить предусловие, если это действительно может произойти
7. Если транзакция имеет циклы, запустите ее в цикле, и не один-два раза — будьте жестче
8. Найти очень долгий и извилистый путь и пройдите по нему
9. Если ожидается, что транзакция будет выполняться в логичном порядке, попробовать выполнить ее в обратном порядке (например заполнить поля не сверху вниз, а снизу вверх)
10. Создать тесты на защиту от дурака

Шаблон описания вариантов использования

If you don’t try strange things. you know the users will.

Тестирование черного ящика — CoderLessons.com

Что такое тестирование черного ящика?

BLACK BOX TESTING определяется как методика тестирования, при которой функциональность тестируемого приложения (AUT) тестируется без учета внутренней структуры кода, деталей реализации и знания внутренних путей программного обеспечения. Этот тип тестирования полностью основан на требованиях и спецификациях программного обеспечения. В BlackBox Testing мы просто фокусируемся на входах и выходах программной системы, не заботясь о внутренних знаниях программ.

Вышеупомянутый Black-Box может быть любой программной системой, которую вы хотите протестировать. Например, операционная система, такая как Windows, веб-сайт, такой как Google, база данных, такая как Oracle, или даже ваше собственное приложение. В Black Box Testing вы можете протестировать эти приложения, просто сосредоточившись на входах и выходах, не зная их внутренней реализации кода. Рассмотрим следующий видео-учебник

Нажмите здесь, если видео не доступно

Как сделать BlackBox Testing

Вот общие шаги, которые необходимо выполнить для проведения любого типа тестирования черного ящика.

• Сначала рассматриваются требования и спецификации системы.
• Тестер выбирает допустимые входные данные (положительный сценарий тестирования), чтобы проверить, правильно ли их обрабатывает SUT. Кроме того, некоторые недействительные входные данные (сценарий отрицательного тестирования) выбираются для проверки того, что SUT может их обнаружить.
• Тестер определяет ожидаемые результаты для всех этих входов.
• Тестировщик программного обеспечения создает тестовые наборы с выбранными входами.
• Тестовые случаи выполнены.
• Тестер программного обеспечения сравнивает фактические результаты с ожидаемыми результатами.
• Дефекты, если таковые имеются, исправлены и перепроверены.

Типы тестирования черного ящика

Существует много видов тестирования черного ящика, но наиболее важными являются следующие:

• Функциональное тестирование — этот тип тестирования черного ящика связан с функциональными требованиями системы; это делают тестеры программного обеспечения.
• Нефункциональное тестирование. Этот тип тестирования черного ящика связан не с тестированием конкретной функциональности, а с нефункциональными требованиями, такими как производительность, масштабируемость, удобство использования.
• Регрессионное тестирование — Регрессионное тестирование проводится после того, как исправления кода, обновления или любое другое обслуживание системы для проверки того, что новый код не затронул существующий код.

Инструменты, используемые для тестирования черного ящика:

Инструменты, используемые для тестирования черного ящика, во многом зависят от типа тестирования черного ящика, которое вы делаете.

Методы испытаний черного ящика

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

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

Сравнение тестирования черного ящика и белого ящика:

Жизненный цикл тестирования и разработки программного обеспечения (SDLC)

Тестирование черного ящика имеет собственный жизненный цикл, называемый жизненным циклом тестирования программного обеспечения ( STLC ), и он относится к каждому этапу жизненного цикла разработки программного обеспечения.

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

Черный ящик против Белая коробка

НОУ ИНТУИТ | Лекция | Тестирование

Аннотация: Стандартизация качества. Методы обеспечения качества ПО. Понятие тестирования. Тестирование черного ящика. Тестирование белого ящика. Инструменты тестирования. Критерии тестирования. Виды тестирования. Работа с ошибками. Средства контроля ошибок (bug tracking systems).

Управление качеством

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

1. 1865 год – образован комитет, который ныне называется ITU (International Telecommunication Union). Сейчас штаб-квартира в Женеве (Швейцария), а ITU является частью ООН. Его основная задача – стандартизация телекоммуникационных протоколов и интерфейсов с целью поддержания и развития глобальной мировой телекоммуникационной сети. Самыми известными стандартами ITU являются:
   • ISDN (цифровая телефонная связь, объединяющая телефонные сервисы и передачу данных),
   • ADSL (широко известная модемная технология, позволяющая использовать телефонную линию для выхода в Интернет, не блокируя при этом обычного телефонного сервиса),
   • OSI (модель открытого 7-уровневого сетевого протокола, на которой базируются все современные стандартные сетевые интерфейсы и протоколы; также является стандартом ISO),
   • языки визуального проектирования телекоммуникационных систем, SDL и MSC, влившиеся позднее в UML.

   Многие стандарты ITU переводятся на русский язык и превращаются в российские стандарты в виде ГОСТов.

2. 1946 год – создана организация ISO (International Organization for Standardization). Цель – содействие развитию стандартизации, а также смежных видов деятельности в мире с целью обеспечения международного обмена товарами и услугами, способствование и развитие сотрудничества в интеллектуальной, научно-технической и экономической областях. К настоящему времени создано около 17 000 стандартов в самых разных областях промышленности – продовольственные и иные товары, различное оборудование, банковские сервисы и т.д. Вот некоторые стандарты.
   • Серия стандартов ISO 9000. Направлены на стандартизацию качества товаров и услуг. Определение качества, определение системы поддержки качества на всех жизненных фазах изделия, товара, услуги (проектирование, разработка, коммерциализация, установка и обслуживание), описание процедур по улучшению деятельности компании, промышленного производства.
   • ISO/IEC 90003:2004 – адаптация стандартов ISO 9000 к производству ПО в русле обеспечения качества в жизненном цикле ПО.
   • ISO 9126:2001 – определение качественного ПО и различных атрибутов, описывающих это качество.

   Многие стандарты ISO переводятся на русский язык и превращаются в российские стандарты в виде ГОСТов. Имеется много стандартов в области информационных технологий, а также несколько – в области программной инженерии. На соответствие стандартам ISO существует сертификация. В частности, компании сертифицируются на соответствие стандартам ISO 9000, то есть на качественный процесс разработки ПО.

3. 1988 год, образование организации ETSI (European Telecommunications Standards Institute), штаб-квартира в г. София Антиполис (Франция). Является независимой, некоммерческой, организацией по стандартизации в телекоммуникационной промышленности (изготовители оборудования и операторы сети) в Европе. Самые известные стандарты – GSM, система профессиональной мобильной радиосвязи TETRA.

Остановимся теперь на ряде комитетов, непосредственно связанных с разработкой ПО.

1. 1984 год – создание SEI (Software Engineering Institute) на базе университета Карнеги-Меллон в г.Питсбурге (США). Инициатор и главный спонсор – министерство обороны США. Основная задача – стандартизация в области программной инженерии, выработка критериев для сертификации надежных и зрелых компаний (что в первую очередь интересует Минобороны США для выполнения его заказов). Самые известные продукты – стандарт CMM, CMMI, разработки в области семейства программных продуктов (product lines). Эти продукты шагнули далеко за пределы военных разработок США, их использование и развитие стало международной деятельностью. Некоторые продукты SEI стандартизованы также ISO. На соответствие CMM/CMMI проводится сертификация.
2. 1963 год – создание IEEE (Institute of Electrical and Electronics Engineers). Ведет историю с конца XIX века, в контексте промышленной стандартизацией в США. Сейчас IEEE международная некоммерческая ассоциация специалистов в области техники, мировой лидер в области разработки стандартов по радиоэлектронике и электротехнике. Штаб-квартира в США, существуют многочисленные подразделения в разных странах, включая Россию. IEEE издаёт третью часть мировой технической литературы, касающейся применения радиоэлектроники, компьютеров, систем управления, электротехники, в том числе (январь 2008) 102 реферируемых научных журнала и 36 отраслевых журналов для специалистов, проводит в год более 300 крупных конференций, принимала участие в разработке около 900 действующих стандартов.
3. 1989 год – группа американских IT-компаний (в том числе Hewlett Packard, Sun Microsystems, Canon) организовали OMG (Object Management Group). Сейчас включает около 800 компаний членов. Основное направление — разработка и продвижение объектно-ориентированных технологий и стандартов, в том числе для создания платформо-независимых программных приложений уровня предприятий. Известные стандарты CORBA, UML, MDA.

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

Стандартизация качества. С точки зрения тестирования ПО нас интересует в этих стандартах стандартизация качества (как контекст тестирования) – сначала выпускаемой продукции, а потом и процессов по ее разработке. Здесь срабатывает идея о том, что качественного результата не создать без качественного процесса. Обеспечение качества является более общим контекстом для тестирования.

Качество продукта или сервиса, предназначенного потребителю, определяется в стандарте ISO 9000:2005 как степень соответствия его характеристик требованиям — обязательным или подразумеваемым.

Методы обеспечения качества ПО. Не претендуя на абсолютную полноту, перечислим различные способы контроля качества, используемые на практике при разработке ПО.

• Наладка качественного процесса, другими словами совершенствование процесса. Для комплексного улучшения процессов в компании (подход technology push) компаниями-разработчиками ПО используются стандарты CMM/CMMI, а также по стандартам серии ISO 9000 (с последующей официальной сертификацией). Применяются и локальные стратегии, менее дорогостоящие и более направленные на решение отдельных проблем (подход organization pull).
• Формальные методы¹ – использование математических формализмов для доказательства корректности, спецификации, проверки формального соответствия, автоматической генерации и т.д.:
  • доказательство правильности работы программ,
  • проверка на моделях определенных свойств (model checking),
  • статический анализ кода по дереву разбора программы (например, проверка корректности кода по определенным критериям – аккуратная работа с памятью, поиск мертвого кода и пр.),
  • модельно-ориентированное тестирование (model-based testing): автоматическая генерация тестов и тестового окружения по формальным спецификациям требований к системе) и т.д.

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

• Исследование и анализ динамических свойств ПО. Например, широко используется профилирование – исследование использования системой памяти, ее быстродействие и др. характеристик путем запуска и непосредственных наблюдений в виде графиков, отчетов и пр. В частности, этот подход используется при распараллеливании программ, при поиске «узких» мест. Еще пример – область, называемая «моделирование и анализ производительности» (performance modeling and analysis). Здесь моделируется нагрузочное окружение системы (число одновременных пользователей системы, сетевой трафик и пр.) и наблюдается поведение системы.
• Обеспечение качества кода. Сюда относится целый комплекс различных мероприятий и методов. Вот некоторые, самые известные из них.
  • Разработка стандартов оформления кода в проекте и контроль за соблюдением этих стандартов. Сюда входят правила на создание идентификаторов переменных, методов и имен классов, на оформление комментариев, правила использования стандартных для проекта библиотек и т.д.
  • Регулярный рефакторинг для предотвращения образования из кода «вермишели». Существует тенденция ухудшения структуры кода при внесении в него новой функциональности, исправления ошибок и пр. Появляется избыточность, образуются неиспользуемые или слабо используемые фрагменты, структура становится запутанной и трудной для понимания. Рефакторинг – это регулярная деятельность по переписыванию кода, но не с целью добавления новой функциональности, а для улучшения его структуры. Рефакторинг появился в контексте «гибких» методов, в данный момент активно поддерживается различными средами разработки ПО.
  • Различные варианты инспекции кода, например, техника peer code review. Последняя заключается в том, что код каждого участника проекта, выборочно, читается и обсуждается на специальных встречах (code review meetings), и делается это регулярно. Практика показывает, что в целом код улучшается.
  • Еcть еще такой подход, как «вычитка» кода, используемый, например, при разработке критических систем реального времени. Ею занимаются также разработчики, но их роль в данном проекте – вычитка, а не разработка.
• Тестирование. Самый распространенный способ контроля качества ПО, представленный, фактически, в каждом программном проекте.

Тестирование

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

Ожидаемое поведение программы. Исходной информацией для тестирования является знание о том, как система должна себя вести, то есть требования к ней или к ее отдельной части. Самым распространенным способом тестирования является тестирование методом черного ящика, то есть когда реализация системы недоступна тестировщикам, а тестируется только ее интерфейс. Часто это закрепляется и организацией коллектива – тестировщики оказываются отдельными сотрудниками и в некоторых компаниях они даже принципиально не общаются с разработчиками, чтобы минимально знать реализационных деталей и максимально полно выступить в роли проверяющей инстанции. Существует тестирование методом белого ящика, когда код программ доступен тестировщикам и используется в качестве источника информации о системе². Его схема представлена на
рис.
7.1.

Рис.
7.1.

На этом рисунке видно, что на основе требований к системе создается реализация и тестовая модель системы. Тестирование есть сопоставление двух этих представлений с целью выявить их несоответствия. Чем независимее друг от друга будут эти представления, тем больше прока от их сопоставления. Иначе, если тестировщики существенно используют информацию о реализации системы при составлении тестов, то они могут невольно внести в тесты ошибки реализации. Найденное при тестировании несоответствие – это еще не ошибка, поскольку сами тестировщики могли неправильно понять требования, в тестах и средствах тестирования могли быть ошибки.

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

Специально заданные, искусственные условия, – те условия, где осуществляется тестирование. При этом ключевым аспектом здесь является наличие тестов – воспроизводимых шагов манипуляции с системой, приводящих к ее некорректной работе. Концепция теста очень важна, так как необходимо не просто обнаружить некорректное поведение системы, а создать и зафиксировать алгоритм воспроизведения ошибки – чтобы повторить его для разработчика или чтобы разработчик сам смог воспроизвести ошибку. Если ошибка не воспроизводится, то нет возможности ее исправить.

Тесты могут быть «ручными» и автоматизированными. «Ручной» тест – это последовательность действий тестировщика, которую он (или разработчик) может воспроизвести и ошибка произойдет. Как правило, в средствах контроля ошибками такие последовательности действий содержатся в описании ошибки. Автоматический тест – это некоторая программа, которая воздействует на систему и проверяет то или иное ее свойство. Автоматический тест, по сравнению с «ручным», можно легко воспроизводить без участия человека. Можно создавать наборы тестов и прогонять их часто, например, в режиме регрессионного тестирования. Кроме того, автоматические тесты можно генерировать по более высокоуровневым спецификациям, например, по формально описанным требованиям к системе. А, например, тесты для компиляторов можно генерировать по формальному описанию языка программирования.

Таким образом, преимущества автоматических тестов перед «ручными» очевидны. Поговорим теперь о трудностях автоматического тестирования.

Во-первых, для того, чтобы тесты автоматически запускать, нужны соответствующие программные продукты, которые также являются неотъемлемой частью специально заданных, искусственных условий, которые мы сейчас обсуждаем. Их будем называть инструментами тестирования. В их задачу входит запуск теста на системе, «прогон» целого пакета тестов, а также анализ получившихся результатов и их обработка.

Кроме того, немаловажной задачей инструментов тестирования является обеспечение доступа теста к системе через некоторый ее интерфейс. Доступ к системе может оказаться затруднительным, например, в силу политических обстоятельств, когда сторонними разработчиками делается подсистема некоторой стратегической системы, и доступ к этой объемлющей системе у разработчиков сильно ограничен. Или в силу аппаратных ограничений – трудно «залезть» на «железку», где работает целевой код системы.

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

Во-вторых, часто возникает проблема ресурсов для автоматического тестирования. Особенно при автоматической генерации тестов: часто есть возможность автоматически сгенерировать очень большое количество тестов, так что если их еще выполнять регулярно, в режиме непрерывной интеграции, то не хватит имеющихся системных ресурсов. При этом качество тестирования может оказаться неудовлетворительным – ошибки находятся редко или вообще не находятся. Дело в том, что количество всех возможных состояний программной системы очень велико, и тестирование не может покрыть их все. На практике, в реальных проектах, определяют критерии тестирования, которые определяют ту «планку» качества, которую необходимо достичь в этом проекте. Ведь хорошее качество стоит дорого и очевидно, что разное ПО имеет разное качество, например, система управления ядерным реактором и текстовый редактор. На практике, часто, качество ПО определяется бюджетом проекта по его разработке.
Далее, в силу ограниченности ресурсов на тестирование часто целесообразно бывает определить те аспекты ПО, которые наиболее важны -как для общей работоспособности системы, так и для заказчика. Например, при тестировании Web-приложения, предоставляющего услугу по созданию объявлений о продаже недвижимости, такими критериями были:

• правильность переходов сложного мастера – в частности, в связи с возможностью переходов назад;
• целостность введенных пользователем данных о создаваемых объявлениях.

Наконец, кроме ограничения количества тестов их отбора важным является их прогон на некоторых (не на всех возможных!) входных данных. Часто здесь применяют принцип факторизации – множество всех возможных входных значений разбивают на значимые с точки зрения тестирования классы и «прогоняют» тесты не на всех возможных входных значениях, а берут по одному набору значений из каждого класса. Например, тестируют некоторую функцию системы на ее граничные значения – очень большие значения параметров, очень маленькие и пр. Часто факторизацию удобно делать, исходя из требований к данной функции, также бывает полезно посмотреть на ее реализацию и «пройтись» тестами по разным ее логическим веткам (порождаемым, например, условными операторами).

Виды тестирования. Не претендуя на полноту, выделим следующие виды тестирования.

• Модульное тестирование — тестируется отдельный модуль, в отрыве от остальной системы. Самый распространенный случай применения – тестирования модуля самим разработчиком, проверка того, что отдельные модули, классы, методы делают действительно то, что от них ожидается. Различные среды разработки широко поддерживают средства модульного тестирования – например, популярная свободно распространяемая библиотека для Visual Studio NUnit, JUnit для Java и т.д. Созданные разработчиком модульные тесты часто включаются в пакет регрессионных тестов и таким образом, могут запускаться многократно.
• Интеграционное тестирование – два и более компонентов тестируются на совместимость. Это очень важный вид тестирования, поскольку разные компоненты могут создаваться разными людьми, в разное время, на разных технологиях. Этот вид тестирования, безусловно, должен применяться самими программистами, чтобы, как минимум, удостовериться, что все живет вместе в первом приближении. Далее тонкости интеграции могут исследовать тестировщики. Необходимо отметить, что такого рода ошибки – «ошибки на стыках» — непросто обнаруживать и устранять. Во время разработки все компоненты все вместе не готовы, интеграция откладывается, а в конце обнаруживаются трудные ошибки (в том смысле, что их устранение требует существенной работы). Здесь выходом является ранняя интеграция системы и в дальнейшем использование практики постоянной интеграции.
• Системное тестирование – это тестирование всей системы в целом, как правило, через ее пользовательский интерфейс. При этом тестировщики, менеджеры и разработчики акцентируются на том, как ПО выглядит и работает в целом, удобно ли оно, удовлетворяет ли она ожиданиям заказчика. При этом могут открываться различные дефекты, такие как неудобство в использовании тех или иных функций, забытые или «скудно» понятые требования.
• Регрессионное тестирование – тестирование системы в процессе ее разработки и сопровождение на регресс. То есть проверяется, что изменения системы не ухудшили уже существующей функциональности. Для этого создаются пакеты регрессионных тестов, которые запускаются с определенной периодичностью – например, в пакетном режиме, связанные с процедурой постоянной интеграции.
• Нагрузочное тестирование – тестирование системы на корректную работу с большими объемами данных. Например, проверка баз данных на корректную обработку большого (предельного) объема записей, исследование поведение серверного ПО при большом количестве клиентских соединений, эксперименты с предельным трафиком для сетевых и телекоммуникационных систем, одновременное открытие большого числа файлов, проектов и т.д.
• Стрессовое тестирование – тестирование системы на устойчивость к непредвиденным ситуациям. Этот вид тестирования нужен далеко не для каждой системы, так как подразумевает высокую планку качества.
• Приемочное тестирование – тестирование, выполняемое при приемке системы заказчиков. Более того, различные стандарты часто включают в себя наборы приемочных тестов. Например, существует большой пакет тестов, поддерживаемых компанией Sun Microsystems, которые обязательны для прогона для всех новых реализаций Java-машины. Считается, что только после того, как все эти тесты успешно проходят, новая реализация вправе называться Java.

Работа с ошибками

Между программистами и тестировщиками необходим специальный интерфейс общения. Ведь ошибок находится много, их исправление требует времени, и их исправления разработчиками тестировщики должны удостовериться, что они действительно исправлены. Кроме того, менеджерам нужна статистика по найденным и исправленным ошибкам – это хороший инструмент контроля проекта. Все это изображено на
рис.
7.2. Чтобы справиться с этим потоком информации и обеспечить необходимые в работе, удобные сервисы, существует специальный класс программных средств – средства контроля ошибок (bug tracking systems).

Рис.
7.2.

Как правило, описание ошибки в системе контроля ошибок имеет следующие основные атрибуты:

• ответственного за ее проверку – тестировщика, который ее нашел и который проверяет, что исправления, сделанные разработчиком, действительно устраняют ошибку;
• ответственного за ее исправление – разработчика, которому ошибка отправляется на исправление;
• состояние, например, ошибка найдена, ошибка исправлена, ошибка закрыта, ошибка вновь проявилась и т.д.

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

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

• базу данных для хранения ошибок;
• интерфейс к этой базе данных для внесения новых ошибок и задания их многочисленных атрибутов, для просмотра ошибок на основе различных фильтров – например, все найденные ошибки за последний месяц, все ошибки, за которые отвечает данный разработчик и т.д.;
• сетевой доступ, так как проекты все чаще оказываются распределенными;
• программный интерфейс для возможностей программной интеграции таких систем с другим ПО, поддерживающим разработку ПО (например, со средствами непрерывной интеграции – они могут автоматически вносить в базу данных найденные при автоматическом прогоне тестов ошибки).

Очень важным при работе с ошибками оказываются различные отчеты, о чем будет подробно рассказано при обсуждении VSTS.

Тестирование по стратегии чёрного ящика — Википедия

Тестирование чёрного ящика или поведенческое тестирование — стратегия (метод) тестирования функционального поведения объекта (программы, системы) с точки зрения внешнего мира, при котором не используется знание о внутреннем устройстве тестируемого объекта. Под стратегией понимаются систематические методы отбора и создания тестов для тестового набора. Стратегия поведенческого теста исходит из технических требований и их спецификаций^[1].

Понятие «чёрного» ящика

Под «чёрным ящиком» понимается объект исследования, внутреннее устройство которого неизвестно. Понятие «чёрный ящик» предложено У. Р. Эшби. В кибернетике оно позволяет изучать поведение систем, то есть их реакций на разнообразные внешние воздействия и в то же время абстрагироваться от их внутреннего устройства.

Манипулируя только лишь со входами и выходами, можно проводить определённые исследования. На практике всегда возникает вопрос, насколько гомоморфизм «чёрного» ящика отражает адекватность его изучаемой модели, то есть как полно в модели отражаются основные свойства оригинала.

Описание любой системы управления во времени характеризуется картиной последовательности её состояний в процессе движения к стоящей перед нею цели. Преобразование в системе управления может быть либо взаимно-однозначным и тогда оно называется изоморфным, либо только однозначным, в одну сторону. В таком случае преобразование называют гомоморфным.

«Чёрный» ящик представляет собой сложную гомоморфную модель кибернетической системы, в которой соблюдается разнообразие. Он только тогда является удовлетворительной моделью системы, когда содержит такое количество информации, которое отражает разнообразие системы. Можно предположить, что чем большее число возмущений действует на входы модели системы, тем большее разнообразие должен иметь регулятор.

В настоящее время известны два вида «чёрных» ящиков. К первому виду относят любой «чёрный» ящик, который может рассматриваться как автомат, называемый конечным или бесконечным. Поведение таких «чёрных» ящиков известно. Ко второму виду относятся такие «чёрные» ящики, поведение которых может быть наблюдаемо только в эксперименте. В таком случае в явной или неявной форме высказывается гипотеза о предсказуемости поведения «чёрного» ящика в вероятностном смысле. Без предварительной гипотезы невозможно любое обобщение, или, как говорят, невозможно сделать индуктивное заключение на основе экспериментов с «чёрным» ящиком.
Для обозначения модели «чёрного» ящика Н. Винером предложено понятие «белого» ящика. «Белый» ящик состоит из известных компонентов, то есть известных X, Y, δ, λ. Его содержимое специально подбирается для реализации той же зависимости выхода от входа, что и у соответствующего «чёрного» ящика. В процессе проводимых исследований и при обобщениях, выдвижении гипотез и установления закономерностей возникает необходимость корректировки организации «белого» ящика и смены моделей. В связи с этим при моделировании исследователь должен обязательно многократно обращаться к схеме отношений «чёрный» — «белый» ящик.

Исследование поведения «чёрного» ящика

Рассмотрим, как изучается и исследуется поведение «чёрного» ящика второго вида. Предположим, что дана некоторая система управления, внутреннее строение которой неизвестно. Система управления имеет входы X(x1,x2,x3,…,xn){\displaystyle X(x_{1},x_{2},x_{3},…,x_{n})} и выходы Y(y1,y2,y3,…,ym){\displaystyle Y(y_{1},y_{2},y_{3},…,y_{m})}.

Способ исследования поведения данного «чёрного» ящика заключается в проведении эксперимента, результаты которого можно представить в виде табл. 1.

Такой способ исследования «чёрного» ящика называется протокольным. Значения входных величин в моменты времени (t1,t2,…,tk){\displaystyle (t_{1},t_{2},…,t_{k})} могут выбираться произвольно.

Таблица 1

Другой способ исследования заключается в подаче на входы некоторых стандартных последовательностей. Этот способ особенно привлекателен, потому что позволяет сравнивать поведение нескольких «чёрных» ящиков с условием выбора таких, которые будут соответствовать предъявляемым требованиям.

Исследование систем управления связано с понятиями «вероятностный автомат», «вероятностная система», что требует изучения их вероятностных свойств. Для этих целей можно построить матрицу вероятностей (табл. 2), в которой для каждого входа xi{\displaystyle x_{i}} и каждого выхода yi{\displaystyle y_{i}} указывается условная вероятность pi{\displaystyle p_{i}}, что yi{\displaystyle y_{i}} возникает в ответ на xi{\displaystyle x_{i}} [7], приведённой в табл. 2.

Разработка методов построения математических моделей «чёрного» ящика является одной из важных кибернетических проблем. При условии наличия математической модели «чёрного» ящика появляется возможность отнести его к какому-либо одному классу, все системы которого изоморфны по поведению.

Создание математического описания «чёрного» ящика является своего рода искусством. В некоторых случаях удаётся сформировать алгоритм, в соответствии с которым «чёрный» ящик реагирует на произвольный входной сигнал. Для большинства же случаев делаются попытки установить дифференциальные уравнения, которые связывают реакцию «чёрного» ящика с его входами или, как говорят, с его входными стимулами.

Для науки метод «чёрный» ящик имеет весьма большое значение. С его помощью в науке были сделаны очень многие выдающиеся открытия. Например, учёный Гарвей ещё в XVII веке предугадал строение сердца. Он моделировал работу сердца насосом, позаимствовав идеи из совершенно другой области современных ему знаний — гидравлики. Практическая ценность метода «чёрный» ящик заключается во-первых, в возможности исследования очень сложных динамических систем, и, во-вторых, в возможности замены одного «ящика» другим. Окружающая действительность и биология дают массу примеров выявления строения систем методом «чёрного» ящика.

Принципы тестирования чёрного ящика

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

Свойства правильно выбранного теста

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

Приёмы тестирования чёрного ящика

1. Эквивалентное разбиение.
2. Анализ граничных значений.
3. Анализ причинно-следственных связей.
4. Предположение об ошибке.

Рассмотрим подробнее каждый из этих методов:

Эквивалентное разбиение

Основу метода составляют два положения:

1. Исходные данные необходимо разбить на конечное число классов эквивалентности. В одном классе эквивалентности содержатся такие тесты, что если один тест из класса эквивалентности обнаруживает некоторую ошибку, то и любой другой тест из этого класса эквивалентности должен обнаруживать эту же ошибку.
2. Каждый тест должен включать, по возможности, максимальное количество классов эквивалентности, чтобы минимизировать общее число тестов.

Разработка тестов этим методом осуществляется в два этапа: выделение классов эквивалентности и построение теста.

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

Выделение классов эквивалентности является эвристическим способом, однако существует ряд правил:

1. Если входное условие описывает область значений, например «Целое число принимает значение от 0 до 999», то существует один правильный класс эквивалентности и два неправильных.
2. Если входное условие описывает число значений, например «Число строк во входном файле лежит в интервале (1..6)», то также существует один правильный класс и два неправильных.
3. Если входное условие описывает множество входных значений, то определяется количество правильных классов, равное количеству элементов в множестве входных значений. Если входное условие описывает ситуацию «должно быть», например «Первый символ должен быть заглавным», тогда один класс правильный и один неправильный.
4. Если есть основание считать, что элементы внутри одного класса эквивалентности могут программой трактоваться по-разному, необходимо разбить данный класс на подклассы. На этом шаге тестирующий на основе таблицы должен составить тесты, покрывающие собой все правильные и неправильные классы эквивалентности. При этом составитель должен минимизировать общее число тестов.

Определение тестов:

1. Каждому классу эквивалентности присваивается уникальный номер.
2. Если ещё остались не включённые в тесты правильные классы, то пишутся тесты, которые покрывают максимально возможное количество классов.
3. Если остались не включённые в тесты неправильные классы, то пишут тесты, которые покрывают только один класс.

Анализ граничных значений

Граничные условия — это ситуации, возникающие на высших и нижних границах входных классов эквивалентности.

Анализ граничных значений отличается от эквивалентного разбиения следующим:

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

Метод требует определённой степени творчества и специализации в рассматриваемой задаче.

Существует несколько правил:

1. Построить тесты с неправильными входными данными для ситуации незначительного выхода за границы области значений. Если входные значения должны быть в интервале [-1.0 .. +1.0], проверяем −1.0, 1.0, −1.000001, 1.000001.
2. Обязательно писать тесты для минимальной и максимальной границы диапазона.
3. Использовать первые два правила для каждого из входных значений (использовать пункт 2 для всех выходных значений).
4. Если вход и выход программы представляет упорядоченное множество, сосредоточить внимание на первом и последнем элементах списка.

Анализ граничных значений, если он применён правильно, позволяет обнаружить большое число ошибок. Однако определение этих границ для каждой задачи может являться отдельной трудной задачей. Также этот метод не проверяет комбинации входных значений.

Анализ причинно-следственных связей

Этапы построения теста:

1. Спецификация разбивается на рабочие участки.
2. В спецификации определяются множество причин и следствий. Под причиной понимается отдельное входное условие или класс эквивалентности. Следствие представляет собой выходное условие или преобразование системы. Здесь каждой причине и следствию присваивается номер.
3. На основе анализа семантического (смыслового) содержания спецификации строится таблица истинности, в которой последовательно перебираются всевозможные комбинации причин и определяются следствия для каждой комбинации причин.

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

Предположение об ошибке

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

Примечания

Литература

• Росс Эшби У. Глава 6. Чёрный ящик // Введение в кибернетику = An Introduction to Cybernetics. — Издательство иностранной литературы, 1959. — С. 127-169. — 432 с.
• Бейзер Б. Тестирование чёрного ящика. Технологии функционального тестирования программного обеспечения и систем. — Питер, 2004. — 320 с. — ISBN 5-94723-698-2.

Что такое тестирование BLACK Box? Методы, примеры и типы

• На главную

• Тестирование

  • • Назад
    • Гибкое тестирование
    • BugZilla
    • Cucumber
    • Тестирование базы данных
    • 000 J2000
    • 000
    • 000 9274000

    000

    000 JUnit

    • LoadRunner
    • Ручное тестирование
    • Мобильное тестирование
    • Mantis
    • Почтальон
    • QTP
    • Назад
    • Центр качества (ALM)
    • RPA
    • SAP Testing

    Управление тестированием Soap

    • TestLink

• SAP

  • • Назад
    • ABAP
    • AP O
    • Начинающий
    • Basis
    • BODS
    • BI
    • BPC
    • CO
    • Назад
    • CRM
    • Crystal Reports
    • MMO
    • HANA
    • Назад
    • PI / PO
    • PP
    • SD
    • SAPUI5
    • Безопасность
    • Менеджер решений
    • Successfactors
    • SAP Tutorials

  000

• Web

• AngularJS
• ASP.Net
• C
• C #
• C ++
• CodeIgniter
• СУБД
• JavaScript

• Назад
• Java
• JSP
• Kotlin
• Linux
• Linux
• Kotlin
• Linux

js

• Perl

• Назад
• PHP
• PL / SQL
• PostgreSQL
• Python
• ReactJS
• Ruby & Rails
• Scala
• SQL

000

• SQL

000

0003 SQL

000

0003 SQL

000

• UML
• VB.Net
• VBScript
• Веб-службы
• WPF