Предположение об ошибке черный ящик

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

Методы

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

Методы проверки (тестирования) программ можно разделить на статические и динамические.

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

Динамические техники следующие:

1. Тестирование методом белого ящика. Это подробное исследование внутренней логики и структуры программы. При этом необходимо знание исходного кода.
2. Тестирование методом черного ящика. Данная техника не требует каких-либо знаний о внутренней работе приложения. Рассматриваются только основные аспекты системы, не связанные или мало связанные с ее внутренней логической структурой.
3. Метод серого ящика. Сочетает в себе предыдущие два подхода. Отладка с ограниченным знанием о внутреннем функционировании приложения сочетается со знанием основных аспектов системы.

Прозрачное тестирование

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

Тестирование программ методом белого ящика обладает следующими преимуществами:

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

Недостатки:

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

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

Основные разновидности:

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

2) отладка ветвления имеет целью исследование каждой опции (истинной или ложной) каждого оператора управления, который также включает в себя объединенное решение;

3) тестирование основного пути, которое позволяет тестировщику установить меру логической сложности процедурного проекта для выделения базового набора путей выполнения;

4) проверка потока данных – стратегия исследования потока управления путем аннотации графа информацией об объявлении и использовании переменных программы;

5) тестирование циклов – полностью сосредоточено на правильном выполнении циклических процедур.

Поведенческая отладка

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

Преимущества такого подхода:

• эффективность для большого сегмента кода;
• простота восприятия тестировщиком;
• перспектива пользователя четко отделена от перспективы разработчика (программист и тестировщик независимы друг от друга);
• более быстрое создание теста.

Тестирование программ методами черного ящика имеет следующие недостатки:

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

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

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

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

2) краевой анализ фокусируется на проверке границ или экстремальных граничных значений – минимумах, максимумах, ошибочных и типичных значениях;

3) фаззинг – используется для поиска погрешностей реализации с помощью ввода искаженных или полуискаженных данных в автоматическом или полуавтоматическом режиме;

4) графы причинно-следственных связей – методика, основанная на создании графов и установлении связи между действием и его причинами: тождественность, отрицание, логическое ИЛИ и логическое И – четыре основных символа, выражающие взаимозависимость между причиной и следствием;

5) проверка ортогональных массивов, применяемая к проблемам с относительно небольшой областью ввода, превышающей возможности исчерпывающего исследования;

6) тестирование всех пар – техника, набор тестовых значений которой включает все возможные дискретные комбинации каждой пары входных параметров;

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

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

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

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

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

Какое количество тестов необходимо произвести, чтобы проверить все возможные значения для 4 окон флажка и одного двухпозиционного поля, задающего время в секундах? На первый взгляд расчет прост: 4 поля с двумя возможными состояниями – 24 = 16, которые необходимо умножить на число возможных позиций от 00 до 99, то есть 1600 возможных тестов.

Тем не менее этот расчет ошибочен: мы можем определить, что двухпозиционное поле может также содержать пробел, т. е. оно состоит из двух буквенно-цифровых позиций и может включать символы алфавита, специальные символы, пробелы и т. д. Таким образом, если система представляет собой 16-битный компьютер, то получится 216 = 65 536 вариантов для каждой позиции, результирующих в 4 294 967 296 тестовых случаев, которые необходимо умножить на 16 комбинаций для флажков, что в общей сложности дает 68 719 476 736. Если их выполнить со скоростью 1 тест в секунду, то общая продолжительность тестирования составит 2 177,5 лет. Для 32 или 64-битных систем, длительность еще больше.

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

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

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

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

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

Например, в (1/x)^1/2 используется три последовательности данных, три эквивалентных разбиения:

1. Все положительные числа будут обрабатываться таким же образом и должны давать правильные результаты.

2. Все отрицательные числа будут обрабатываться так же, с таким же результатом. Это неверно, так как корень из отрицательного числа является мнимым.

3. Ноль будет обрабатываться отдельно и даст ошибку «деление на ноль». Это раздел с одним значением.

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

Краевой анализ

Обработка данных на границах эквивалентного разбиения может выполняться иначе, чем ожидается. Исследование граничных значений – хорошо известный способ анализа поведения ПО в таких областях. Эта техника позволяет выявить такие ошибки:

• неправильное использование операторов отношения (<,>, =, ≠, ≥, ≤);
• единичные ошибки;
• проблемы в циклах и итерациях,
• неправильные типы или размер переменных, используемых для хранения информации;
• искусственные ограничения, связанные с данными и типами переменных.

Полупрозрачное тестирование

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

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

• архитектурная модель;
• унифицированный язык моделирования (UML);
• модель состояний (конечный автомат).

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

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

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

Недостатки:

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

Другое название техники серого ящика – полупрозрачная отладка.

К этой категории относят такие методы тестирования:

1) ортогональный массив – использование подмножества всех возможных комбинаций;

2) матричная отладка с использованием данных о состоянии программы;

3) регрессивная проверка, проводимая при внесении новых изменений в ПО;

4) шаблонный тест, который анализирует дизайн и архитектуру добротного приложения.

Сравнение методов тестирования ПО

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

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

Ниже приведены основные отличия трех динамических техник тестирования — дана таблица сравнения между тремя формами отладки ПО.

Автоматизация

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

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

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

Тестовые инструменты могут быть классифицированы по-разному. Следующее деление основано на поддерживаемых ими задачах:

• управление тестированием, которое включает поддержку управления проектом, версиями, конфигурациями, риск-анализ, отслеживание тестов, ошибок, дефектов и инструменты создания отчетов;
• управление требованиями, которое включает хранение требований и спецификаций, их проверку на полноту и многозначность, их приоритет и отслеживаемость каждого теста;
• критический просмотр и статический анализ, включая мониторинг потока и задач, запись и хранение комментариев, обнаружение дефектов и плановых коррекций, управление ссылками на проверочные списки и правила, отслеживание связи исходных документов и кода, статический анализ с обнаружением дефектов, обеспечением соответствия стандартам написания кода, разбором структур и их зависимостей, вычислением метрических параметров кода и архитектуры. Кроме того, используются компиляторы, анализаторы связей и генераторы кросс-ссылок;
• моделирование, которое включает инструменты моделирования бизнес-поведения и проверки созданных моделей;
• разработка тестов обеспечивает генерацию ожидаемых данных исходя из условий и интерфейса пользователя, моделей и кода, управление ими для создания или изменения файлов и БД, сообщений, проверки данных исходя из правил управления, анализа статистики условий и рисков;
• критический просмотр путем ввода данных через графический интерфейс пользователя, API, командные строки с использованием компараторов, помогающих определить успешные и неудавшиеся тесты;
• поддержка сред отладки, которая позволяет заменить отсутствующее оборудование или ПО, в т. ч. симуляторы оборудования на основе подмножества детерминированного выхода, эмуляторы терминалов, мобильных телефонов или сетевого оборудования, среды для проверки языков, ОС и аппаратного обеспечения путем замены недостающих компонентов драйверами, фиктивными модулями и др., а также инструменты для перехвата и модификации запросов ОС, симуляции ограничений ЦПУ, ОЗУ, ПЗУ или сети;
• сравнение данных файлов, БД, проверка ожидаемых результатов во время и по окончании тестирования, в т. ч. динамическое и пакетное сравнение, автоматические «оракулы»;
• измерение покрытия для локализации утечек памяти и некорректного управления ею, оценки поведения системы в условиях симулированной нагрузки, генерации нагрузки приложений, БД, сети или серверов по реалистичным сценариям ее роста, для измерения, анализа, проверки и отчета о системных ресурсах;
• обеспечение безопасности;
• тестирование производительности, нагрузки и динамический анализ;
• другие инструменты, в т. ч. для проверки правописания и синтаксиса, сетевой безопасности, наличия всех страниц веб-сайта и др.

Перспектива

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

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

На смену придут новые бизнес-ориентированные методы тестирования программ, изменятся способы взаимодействия с системами и предоставляемой ими информацией с одновременным снижением рисков и ростом преимуществ от бизнес-изменений.

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

Так называемое «black-box тестирование» является методом тестирования программного обеспечения, внутренняя структура, дизайн и реализация которого неизвестна тестировщику (при подготовке тест-кейсов он опирается на требования и спецификацию). Хочу обратить внимание на то, что требования и спецификация не всегда существуют в письменном виде; тем не менее, при тестировании методом черного ящика мы можем опираться на устно описанные требования.

Что такое «черный ящик» согласно терминологии ISTQB?

Black-box тестирование – это функциональное и нефункциональное тестирование без доступа к внутренней структуре компонентов системы. Метод тестирования «черного ящика» – процедура получения и выбора тестовых случаев на основе анализа спецификации (функциональной или нефункциональной), компонентов или системы без ссылки на их внутреннее устройство.

Где используется метод «черного ящика»?

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

2. Функциональное тестирование.
Используя этот метод, тестировщик проверяет, выполняет ли программное обеспечение все заявленные функции и требования клиента в полном объеме согласно документации.

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

4. Usability-тестирование.
Пусть в упомянутой букмекерской конторе есть функционал «Купон»: мы проверяем, сколько времени уходит у пользователя для добавления ставки в купон, ввода суммы и завершения ставки.

5. Тестирование производительности.
Таким видом тестирования мы можем проверить: есть ли утечки памяти, насколько быстро система работает и выдает обратную связь, не потребляет ли наше ПО слишком много трафика и не создает ли избыточное количество подключений.

6. Приемочное тестирование.
После проверки ПО тестировщиками его отдают заказчику, который запускает приемочные тесты «черного ящика» на основе ожиданий от функциональности. Как правило, набор тестов в этом случае определяет сам заказчик, за ним же остается право отказаться от приемки (если его не устроили результаты тестирования).

7. Регрессионное тестирование.
Проводится на протяжении всего цикла разработки. Цель такого тестирования – проверить работоспособность нового кода и выяснить, не привел ли он к ошибкам или поломкам в старом функционале.

При выборе набора регрессионных тестов следует использовать следующие рекомендации:

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

8. Beta-тестирование.
Это тестирование также проводится методом «черного ящика». Практически готовое ПО отдают для «обкатки» желающим для выявления максимального количества ошибок еще до того, как оно попадет к конечному пользователю.

Что это дает:

Техники тестирования «черным ящиком»

1. Эквивалентное разбиение.
Эта техника включает в себя разделение входных значений на допустимые и недопустимые разделы и выбор репрезентативных значений из каждого раздела в качестве тестовых данных. Она может быть использована для уменьшения количества тестовых случаев. Допустим, у нас есть целая переменная N в диапазоне от -99 до 99: позитивными классами эквивалентности будут [-99, -10], [-9, -1], 0, [1, 9], [10, 99], а недействительными (негативными) – <-99, >99, пустое значение, нечисловые строки.

2. Анализ граничных значений.
Техника, которая включает в себя определение границ входных значений и выбор в качестве тестовых данных значений, находящихся на границах, внутри и вне границ. Многие системы имеют тенденцию вести себя некорректно при граничных значениях, поэтому оценка значений границ приложения очень важна. При проверке мы берем следующие величины: минимум, (минимум-1), максимум, (максимум+1), стандартные значения. Например, в том же случае -99 <= N <= 99 будет использоваться набор: -100, -99, -98, -10, -9 -1, 0, 1, 9, 10, 98, 99, 100.

3. Тестирование таблицы переходов.
При данной технике сценарии тестирования выбираются на основе выполнения корректных и некорректных переходов состояний. Допустим, мы хотим записаться на прием к врачу и зарезервировать время своего приема: заходим в форму, выбираем удобное для нас время и нажимаем кнопку «Записаться». Сразу после этого выбранное нами время становится недоступно для другой записи, так как первая запись привела к изменению в базе.

4. Тестирование по сценариям использования.
Эта техника используется при написании тестов для индивидуального сценария пользователя с целью проверки его работы.

Достоинства метода

Недостатки метода

Подведем итоги

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

Проведение «black-box» тестирования увеличивает уверенность в том, что приложение надежно работает на широком диапазоне входных данных, так как набор тестовых данных зависит только от спецификации, а не от особенностей внутренней реализации продукта (как в случае применения методов «белого» и «серого» ящиков).

Метод «черного ящика» выгодно применять, если вы ищете:

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

Обзор тестирования черного ящика

Black Box Testing — это метод тестирования программного обеспечения, при котором внутренняя структура, дизайн или реализация предмета, который необходимо проверить, неизвестен тестировщику.

Что такое тестирование программного обеспечения?

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

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

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

Преимущества тестирования черного ящика включают в себя:

• Простота: облегчает тестирование проектов высокого уровня и сложных приложений
• Экономия ресурсов: тестеры сосредоточены на функциональности программного обеспечения.
• Тестовые случаи: Сосредоточение внимания на функциональности программного обеспечения для облегчения быстрой разработки тестовых случаев.
• Обеспечивает гибкость: специальные знания программирования не требуются.

Пример

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

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

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

• Функциональные / регрессионные тесты могут быть выполнены через QTP или Selenium
• Нефункциональные тесты могут быть выполнены через LoadRunner или Jmeter.

Уровни

В Black Box Testing следующие уровни предназначены для тестирования программного обеспечения:

• Интеграционное тестирование
• Тестирование системы
• Приемочное тестирование

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

Определение черного ящика

Тестирование черного ящика может быть определено как метод тестирования, в котором тестируется функциональность Application Under Test (AUT), но при этом не учитывается структура внутреннего кода, детали реализации и любые знания о внутренних путях программного обеспечения.

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

Тестирование черного ящика касается всех спецификаций и требований к программному обеспечению. Black Box Testing просто фокусируется на входах и выходах системы программного обеспечения и не беспокоится о внутренних знаниях программного обеспечения.

Как Black Box Testing облегчает работу?

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

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

Что вы можете сделать с Black Box Testing?

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

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

Тестирование класса эквивалентности

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

Это делается в следующие два этапа:

1. Идентификация и разбиение на классы эквивалентности. Сначала входные данные разбиваются как минимум на два набора: первый набор содержит список допустимых входных значений, а второй набор содержит список недопустимых входных значений. Например, если есть поле возраста, которое может содержать возраст в диапазоне от 20 до 40, то допустимые входные значения могут быть 21, 25, 30, 39 и т. Д., А недопустимые входные значения могут быть любым значением меньше 20 или больше, чем 40 вроде 10, 15, 45, 55 и т. Д.

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

Тестирование граничных значений

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

Тестирование таблицы решений

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

Причинно-следственная графика

Причинно-следственный График развивает связь между причинами (логические входы) с соответствующим эффектом (Действия). Они представлены с помощью булевых графов. Шаги должны быть следующими:

1. Идентификация входов и выходов.
2. Разработка причинно-следственного графика.
3. Преобразование графика в таблицу решений.
4. Преобразование правил таблицы решений в контрольные примеры.

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

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

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

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

1. Процессоры Pentium 3 или Pentium 4 и количество используемых процессоров
2. 32-битная или 64-битная архитектура
3. Серверы баз данных или любые другие внутренние компоненты
4. Тип операционной системы (Windows, Linux и т. Д.).

Работа с тестированием черного ящика

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

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

преимущества

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

Недостатки

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

Почему мы должны использовать Black Box Testing?

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

Сфера

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

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

Различия

Black Box Testing — это метод тестирования программного обеспечения, при котором внутренняя структура, дизайн или реализация тестируемого продукта неизвестны тестировщику.

White Box Testing — это метод тестирования программного обеспечения, при котором внутренняя структура, дизайн или реализация тестируемого продукта известны тестировщику.

Вывод:

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

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

Рекомендуемые статьи

Это было руководство к тестированию черного ящика. Здесь мы обсудили, как Black Box Testing выполняется с помощью примеров и различных методов Black Box Testing с инструментами. Вы также можете просмотреть наши другие предлагаемые статьи, чтобы узнать больше —

1. Тестирование белого ящика
2. Тестирование Интервью Вопросы
3. Что такое гипервизор
4. Вопросы по тестированию игр

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

Понятие «чёрного» ящика[править | править код]

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

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

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

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

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

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

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

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

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

Таблица 1

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

Исследование систем управления связано с понятиями «вероятностный автомат», «вероятностная система», что требует изучения их вероятностных свойств. Для этих целей можно построить матрицу вероятностей (табл. 2), в которой для каждого входа и каждого выхода указывается условная вероятность , что возникает в ответ на [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.

Книга «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.