Тест-дизайн

 В рамках изучения курса "Функциональное тестирование" подробно рассматривалась тема "Тест-дизайн". Довольно объемная тема оказалась.

 Хотя весь курс, как мне кажется, не дает понимания "ФТ", он скорее является обзорным по основам тестирования и какие-то моменты освещаются чуть подробнее. Плюс за основу взяты стандарты ISTQB.

Итак,

Тест дизайн - срез по курсу:

Тест-дизайн – этап тестирования, включающий в себя разработку тестирования (Test development): проектировка и создание тест-кейсов.

Методики обеспечения качества:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не валидные граничные значения: пустое значение; ноль; минимального отрицательного числа; значение, которое превышает максимально указанный показатель.

Таблица принятия решений (комбинаторная техника)

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

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

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

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

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

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

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

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

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

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

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

Переход – это преобразование одного состояние в другое, происходящее по событию.

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

События могут вызывать смену состояния и/или инициировать действия. 

Действие инициируется сменой состояния. 

Комбинаторные подходы («Полный перебор» и метод «Всех пар»)

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

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

Техники User-story и use-case – не являются техниками тест-дизайна, а являются техниками выявления формирования функциональных и нефункциональных техник. 

User-story:

• Описание человека, использующего систему
• Описание, что должно содержаться в данной системе
• Описание, для чего она нужна пользователю

На основе анализа User-story формируются use-case.

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