Техники тест-дизайна

Объединение теории по теме

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

Методы:

Статические – без запуска кода (анализ кода, требований).

Динамические – запуск ПО.

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

Статические:

Рецензирование – анализ спека и/или кода с привлечением сторонних специалистов.

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

По сути это анализ кода для определения порядка выполнения программы, последний выражается в виде грава потока управления. Граф потока управления - множество всех путей исполнения программы, представленное в виде графа. 

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

Стандарты кодирования – насколько код соответствует установленным стандартам.

Динамические:

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

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

Критерии покрытия кода:

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

Ориентированных на опыт:

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

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

• Эквивалентное разбиение (классы эквивалентности)
• Анализ граничных значений
• Таблицы принятия решений
• Переход состояний
• Use-case тестирование и user story
• Комбинаторные подходы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- ноль; 

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

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

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

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

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

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

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

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

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

Принципы:

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

Доменное тестирование. Техника заключается в комбинации эквивалентного разбиения и анализа граничных значений.

https://crashtest.by/domain-testing/ - описание с примерами 

https://sedtest-school.ru/test-design/chto-takoe-domennoe-testirovanie/  - описание с примером 

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

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

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

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

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

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

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

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

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

• Условия (conditions) — короткое описание входных условий (данных), сформулированное в виде вопроса. Ответ на него должен содержать либо «да/нет», либо ограниченный набор значений. Например: «Пользователь авторизован в системе?», «Вид документа, предоставленный клиентом, — паспорт, водительские права, загранпаспорт?»
• Действия (actions) — чёткое описание ожидаемого результата, действия системы. Формулировка действия — утвердительное предложение. Одно предложение обязательно описывает только одно действие. Например: «Данные заполнены автоматически», «Сообщение об ошибке отображается на экране».
• Значения (values) — значения, допустимые для входных данных, указанных в условии. Например: «да/нет», «Паспорт, водительские права, загранпаспорт».
• Правила (rules) — комбинации входных данных, которые отражены в таблице. При построении простой таблицы (без диапазонов вариантов условий) каждое правило (вертикальная колонка) становится тест-кейсом. Условия указывают на входные значения, а действия - на ожидаемые результаты.

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

При тестировании для каждого правила создаётся как минимум один тест-кейс. Если состояния этого правила бинарные, то должно быть достаточно одного теста для каждого сочетания. С другой стороны, если состояние является диапазоном значений, то применяются техники АКЭ, АГЗ, доменное тестирование.

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

Последовательность действий:

1. Разбить требования на условия
2. Посчитать количество возможных комбинаций
3. Составить таблицу принятия решений
4. Исключить лишние комбинации
5. Записать тесты

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

Пример: https://dzen.ru/media/id/63d52d2c1522912fd2f8761e/tehniki-test-dizaina-v-testirovanii-chast-4-6403028d976ffe173b3bd2c7

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

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

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

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

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

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

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

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

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

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

События могут вызывать смену состояния и/или инициировать действия.  События могут быть независимыми или причинно-связанными (событие B не может произойти прежде события А). Событие могут иметь параметры. 

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

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

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

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

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

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

Пример - https://dzen.ru/a/ZAL-NFTNXlv2ZSkj

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Данный метод позволяет сократить количество возможных комбинаций значений параметров тестируемого продукта. Он основан на том, что в большинстве случаев наличие дефекта зависит только от двух параметров. Поэтому для тестирования достаточно проверить все возможные комбинации пар параметров. Например, если в продукте есть 5 параметров, каждый из которых может принимать 10 значений, то без использования метода парных комбинаций количество комбинаций будет равно 10 в 5 степени (100000). А при использовании метода парных комбинаций количество комбинаций сократится до 1250. 

Пример https://qaevolution.ru/metody-kombinatornogo-testirovaniya 

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

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

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

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

https://pairwise.teremokgames.com 

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

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

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

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

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