Техники тест-дизайна. Методы тестирования "черного ящика"

По материалам ранее изученной информации и по переводу книги Ли Копланда “A Practitioner's Guide to Software Test Design”. Автор перевода:​ Уфимцева Галина

Анализ классов эквивалентности

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

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

Таблицы принятия решений
Состояний и переходов

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

Анализ классов эквивалентности

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

другими словами

Эквивалентная область (equivalence partition) – часть области входных или выходных данных, для которой поведение компонента или системы, основываясь на спецификации, считается одинаковым.

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

Не валидные классы эквивалентности – при вводе которых система не позволяет сделать то, что сделать нельзя. 

Порядок действий:

1. Ознакомиться с документацией

2. Выделить классы эквивалентности для данных и параметров системы, в рамках которых должна быть протестирована работа системы.

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

Признаки эквивалентности (несколько тестов эквивалентны, если):

• Они направлены на поиск одной и той же ошибки.
• Если один из тестов обнаруживает ошибку, другие её тоже обнаружат.
• Если один из тестов не обнаруживает ошибку, другие её тоже не обнаружат.
• Тесты используют схожие наборы входных данных.
• Для выполнения тестов мы совершаем одни и те же операции.
• Тесты генерируют одинаковые выходные данные или приводят приложение в одно и то же состояние.
• Все тесты приводят к срабатыванию одного и того же блока обработки ошибок («error handling block»).
• Ни один из тестов не приводит к срабатыванию блока обработки ошибок («error handling block»).

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

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

Порядок действий:

1. Ознакомиться с документацией

2. Выделить классы эквивалентности для данных и параметров системы, в рамках которых должна быть протестирована работа системы.

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

4. По каждой границе выбрать значения для тестирования: до границы, на границе, после границы.

АГЗ имеет два подхода:

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

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

Не валидные граничные значения: 

- пустое значение; 

- ноль; 

- минимального отрицательного числа; 

- значение, которое превышает максимально указанный показатель.

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

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

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

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

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

Шаги для достижения цели:

1. Для начала нужно разделить предполагаемые значения на отдельные группы, условия - это могут быть:

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

2. Выявить конкретный набор значений и выбрать из них наиболее показательные, представляющие каждую группу, включая обязательно границы. Здесь мы уже определяем значения, которые будем проверять и используем принципы АКЭ и АГЗ.

3. Скомбинировать эти значения (позитивные тесты) таким образом, чтобы отдельные параметры можно было протестировать одновременно.

Принципы:

• Производить сразу несколько позитивных тестов (например, ввод данных в несколько полей), вместо одного.
• Не стоит комбинировать много (больше семи?) позитивных значений одновременно, иначе тест будет громоздким. В случае обнаружения ошибки ее придется долго локализовывать.
• Негативные тесты комбинировать нельзя, так как будет не понятно, что тестируемая программа корректно отслеживает проблемы с каждым из полей.
• Не стоит в одном тесте комбинировать позитивные и негативные сценарии. Каждое негативное условие всегда проверяется отдельно.
• Начинайте проверку с граничных значений.
• Во избежание эффекта пестицида, при повторе тестов использовать разные эквивалентные значения.
• В случае, если использование спецсимволов ведёт к ошибке, то рекомендуется каждый спецсимвол проверять отдельно.

Таблица принятия решений

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

Используется для исследования взаимодействия между комбинациями условий.

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

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

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

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

Таблица принятия решений помогает:

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

Составляющие таблицы принятия решений:

• Условия – список возможных условий, оказывающих влияние на то, какие действия нужно будет предпринять, выполнить.
• Варианты выполнения условий – всевозможные комбинации выполнения или невыполнения условий из списка. 
• Действия – это список всевозможных действий, которые могут быть предприняты, выполнены исходя из условий, созданных той или иной комбинацией вариантов выполнения условий.
• Необходимость действий - в этом разделе таблицы отмечаются те действия из списка (обозначенного в разделе «Действия»), которые нужно будет выполнить из условий, созданных той или иной комбинацией вариантов выполнения условий.

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

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

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

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

Для каждого правила создаётся как минимум один тест-кейс.

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

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

Как правило таблицы строятся при помощи специальный приложений (Decision Table Creator, Test case generator, logicGem и пр.).

Тестирование переходов и состояний

Диаграммы состояний и переходов документируют входящие события, которые

обрабатываются системой так же, как системные ответы. 

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

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

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

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

Инструменты:

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

Таблица переходов состояний (матричное представление)

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

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

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

События могут поступать извне – через интерфейс. Также могут генерироваться внутри системы изнутри. Когда происходит событие, приложение может поменять (или не поменять) состояние и выполнить (или не выполнить) действие. События могут быть независимыми или причинно-связанными (событие B не может произойти прежде события А). Событие могут иметь параметры. 

Действия (представлено в виде команды, следующей за "/") - это ответ системы на какое-либо событие, операция, которая вызвана изменением состояния. Действие инициируется сменой состояния. Часто эти действия служат причиной создания каких-либо выходных значений системы. Обратите внимание, что действия происходят при переходах между состояниями. Сами состояния пассивны.

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

Точка входа - это старт всей системы. А точно выхода - то финиш.

Роль пользователя. Роль влияет на то, какой переход может делать пользователь и какой контент он может видеть.

Диаграммы составляются на основе ТЗ. 

Диаграмму можно построить используя приложение StarUML.

Таблицы состояний и переходов

Как не пропустить все переходы?

Для этого нужно составить таблицу, в которой информация будет отображена. Таблица состоит из столбцов:

• текущее состояние
• событие
• действие
• следующее состояние
• условие

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

Ключевой момент

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

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

Создание тест-кейсов

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

Определим четыре разных уровня покрытия:

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

Ключевой момент

Как правило, рекомендуемым уровнем покрытия для диаграмм состояний и переходов является тестирование ​каждого перехода

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

Pairwise testing - это техника формирования наборов тестовых данных, в которых каждое тестируемое значение каждого из проверяемых параметров хотя бы единожды сочетается с каждым тестируемым значением всех остальных проверяемых параметров.

Суть техники pairwise testing - мы не проверяем все сочетания всех значений, но проверяем все пары значений.

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

Составление нужных комбинаций данных - задачка часто не самая простая, но для её решения существует много инструментов, разного уровня качества и (бес)платности: https://www.pairwise.org/tools.html

Pairwise testing - это та техника, применять которую стоит именно в случае взаимодействующих значений (для невзаимодействующих - чаще всего достаточно просто отдельной проверки каждого из параметров). 

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

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

Важные нюансы:

1. Есть инструменты, которые умеют генерить комбинации по произвольному базисы (пары, тройки и тд).
2. Тулы, которые не умеют генерить базируясь на условиях (а таких большинство) - можно выкинуть. Очень редко бывают задачи, в которых параметры или их значения надо попарно перемножать и все комбинации допустимы. Например если операционка != windows, тогда браузер != IE. Если так задать нельзя, то вы получите кучу мусора, а выкинуть уже сгенеренные неправильные комбинации нельзя, т.к. вы выкинете другие правильные сочетания параметров.
3. Ищите инструмент, который умеет использовать предписанные сочетания. Есть комбинации параметров и их значений, которые либо наиболее вероятны, либо наиболее важны для проверки (известные конфигурации у клиентов, например). Их хочется проверять, но навряд ли тул так удачно все сгенерит.
4. Перед применением этого метода, надо обязательно воспользоваться другими методами (доменное тестирование, таблица принятия решений).
5. Есть параметры на которые перемножать не надо. У нас например, это encoding. Если все умножать на encoding, то количество комбинаций резко возрастет, а толку от них нет. Поэтому такой параметр просто добавляется к уже сгенеренным комбинациям, не увеличивая их числа.