Тест-Дизайн
Last updated
Last updated
Тест-дизайн – это этап тестирования ПО (Программного обеспечения). На нем проектируются и создаются тест-кейсы, которые будут соответствовать определенным заранее критериями качества и целями тестирования. Цель тест-дизайна — создать наборы тестовых случаев, обеспечивающих оптимальное тестовое покрытие. Разработка тестов начинается после проведения исследования ПО, когда цели определены, а критерии тестирования заданы и выполняются.
Метод эквивалентного разбиения позволяет минимизировать число тестов, не создавая сценарий для каждого возможного значения, а выбрав только одно значение из целого класса и приняв за аксиому, что для всех значений в данной группе результат будет аналогичным.
Например, мы тестируем функциональность приложения, позволяющего покупать авиа- и железнодорожные билеты онлайн. Стоимость билета будет зависеть от возраста пассажира, так как дети, студенты и пенсионеры относятся ко льготным категориям.
У нас есть четыре возрастных группы: младше 15 лет, от 15 до 25 лет, старше 25 и младше 60 лет и люди старше 60. При этом, в поле для ввода возраста помещается всего два символа, поэтому указать возраст более 99 лет технически невозможно.
QA-специалисту не нужно писать 99 тестов для каждого возраста, хватит пяти: по одному для каждой возрастной группы (скажем, 10, 18, 35 и 75 лет) и один для случая, если возраст человека превышает 99 лет. Да, последний тест на практике невыполним (поскольку в поле возраста невозможно ввести более двух знаков), и все же не следует забывать об этой проверке.
Пример
У меня есть калькулятор инвестиций, который содержит поле процента прибыли, которое мне необходимо указать. Разрешенные значения находятся в диапазоне от 1 до 100 по требованию заказчика.
Шаг 1: Определите эквивалентные классы:
Положительные числа (1–100)
Отрицательные числа и ноль (<=0)
Больше допустимого (>100)
Буквы (a-z, a-Z, кириллица, арабский и т. д.)
Специальные символы (!@# и т. д.)
Шаг 2: Выберите одно значение для каждого класса. И у нас есть следующие тест-кейсы для проверки: 50, -10, 146, aBc, !
Где использовать?
Везде! При тестировании пользовательского интерфейса (UI) - это поля, даты, конкретные кнопки. При тестировании API нам нужно проверить все возможные параметры в теле запроса (body), заголовках (headers), пути (path) или параметрах запроса (query parameters).
Техника граничных значений основана на предположении, что большинство ошибок может возникнуть на границах эквивалентных классов. Она тесно связана с вышеописанной техникой эквивалентного разбиения, из-за чего часто используется с ней в паре. Тогда для примера из предыдущего пункта границами будут являться значения 0, 15, 25, 60 и 99. Граничными значениями будут 0, 1, 14, 15, 16, 24, 25, 26, 59, 60, 61, 98, 99, 100.
Часто сложности возникают, если возрастные категории указаны «внахлест», например, 0-12, 12-25 лет и т.д.
Пример:
Интернет-магазин предоставляет скидку 10%, если сумма покупки превышает $100.
Шаг 1: Определите эквивалентные классы и границы каждого из них:
Сумма покупки <= $100
Сумма покупки > $100
Шаг 2: Выберите значения, находящиеся на границе этих классов с минимальным отклонением, а также само граничное значение:
Сумма покупки = $99.99: скидка не применяется
Сумма покупки = $100: скидка не применяется
Сумма покупки = $100.01: скидка применяется
Где использовать?
Ответ тот же, что и для разбиения на классы эквивалентности - везде.
Другое название метода – матрица принятия решений. Эта техника подходит для более сложных систем, например – двухфакторной аутентификации. Предположим, чтобы войти в систему, пользователю нужно ввести сначала логин и пароль, а затем еще подтвердить свою личность присланным в смс кодом.
Какие возможны сценарии: 1. Правильный логин и правильный пароль. 2. Правильный логин, неправильный пароль. 3. Неправильный логин, правильный пароль. 4. Неправильный логин, неправильный пароль.
Первый из этих сценариев сопровождается либо правильным, либо неправильным вводом смс-кода, итого у нас получается 5 тестов. При этом только один из сценариев приведет к положительному результату (пользователь успешно авторизуется), а остальные закончатся неудачей.
Однако, может быть так, что система выдает разные сообщения в зависимости от того, на каком этапе была допущена ошибка, скажем: invalid login, invalid password. Соответственно, групп потребуется больше, а таблица станет обширнее.
Этот метод хорош тем, что он показывает сразу все возможные сценарии в форме, понятной даже неспециалисту.
Пример:
Пользователь имеет возможность написать комментарий к посту. Затем он может изменить или удалить этот комментарий. У комментариев есть несколько состояний: создан, изменен, удален. Каждое из этих состояний может быть характеризовано набором уникальных свойств.
Шаг 1: Определите объект, который мы хотим протестировать.
Шаг 2: Нарисуйте прямоугольник для каждого состояния, определенного для объекта.
Шаг 3: Создайте переходы между состояниями и отметьте каждый из них связанным действием.
Шаг 4: Вы готовы создавать положительные и отрицательные тест-кейсы.
Где использовать?
Прежде всего, при тестировании моделей объектов домена. Этот метод можно применять и к части пользовательского интерфейса, как уже упоминалось ранее. Мы можем охватить все переходы между экранами (страницами) пользовательского интерфейса и создать тестовые случаи, проверяющие переключение между ними.
Суть этого метода, также известного как pairwise testing, в том, что каждое значение каждого проверяемого параметра должно быть протестировано на взаимодействие с каждым значением всех остальных параметров. После составления такой матрицы мы убираем тесты, которые дублируют друг друга, оставляя максимальное покрытие при минимальном необходимом наборе сценариев.
Попарное тестирование позволяет обнаружить максимум ошибок без избыточных проверок.
Pairwise testing: пример
Для Parwise достаточно, чтобы каждое значение всех параметров хотя бы единожды сочеталось с другими значениями остальных параметров. Таким образом, матрицу можно значительно сократить. Например:
При составлении матрицы принятия решений для двух браузеров, двух ОС и двух языков было бы нужно 8 сценариев. При попарном тестировании достаточно четырех.
Все это можно просчитать и вручную, но не обязательно – гораздо удобнее автоматизировать процесс. Для этого существует программа попарного независимого комбинированного тестирования – Pairwise Independent Combinatorial Testing (PICT). Для проведения тестирования специалист создает текстовый файл с перечислением и их возможных значений, а затем запускает PICT через cmd – командную строку. Скомбинированные тесты отображаются в виде таблицы в самой консоли. Так же результаты по желанию можно выгрузить в файл Excel.
Пример содержимого файла для программы PICT: Браузер: Chrome, Opera ОС: Windows, Linux Язык: RU, ENG
Суть его заключается в том, чтобы рассмотреть все возможные комбинации каждой пары входных параметров.
Шаг 1: Определите возможные параметры и их значения для функциональности, которую необходимо протестировать.
Где использовать?
Когда у вас большое количество входных параметров и большое количество возможных значений параметров. Это может быть применено к приложениям с графическим интерфейсом и API-приложениям.
Ее стоит использовать в том случае, когда входные данные связаны друг с другом. Точнее результат выполнения теста напрямую зависит от того, какие комбинации данных будут подаваться на входе.
Простая проверка базовых действий и их результата. Например, если нажать крестик в правом верхнем углу окна (причина), оно закроется (следствие), и т.д. Этот метод позволяет проверить все возможности системы, а также обнаружить баги и улучшить техническую документацию продукта.
Примерный алгоритм использования техники: 1. Выделяем причины и следствия в спецификациях. 2. Связываем причины и следствия. 3. Учитываем «невозможные» сочетания причин и следствий. 4. Составляем «таблицу решений», где в каждом столбце указана комбинация входов и выходов, т.е. каждый столбец – это готовый тестовый сценарий. 5. Расставляем приоритеты.
Эта техника помогает:
Определить минимальное количество тестов для нахождения максимума ошибок.
Выяснить все причины и следствия – таким образом, мы убедимся, что на любые манипуляции с системой у системы будет ответ.
Найти возможные недочеты в логике описания приложения (что, в свою очередь, поможет улучшить документацию).
Например, QA-специалист тестирует приложение типа “записная книжка”. После ввода всех данных нового контакта и нажатия кнопки Создать (причина) приложение должно автоматически создать карточку с номером телефона, фотографией и ФИО человека (следствие). Тесты покажут, можно ли оставлять одно или несколько полей пустыми, распознает ли система кириллицу, латиницу или оба алфавита, а также другие параметры.
Как пользователь, я заполняю поля логина и пароля и нажимаю кнопку OK. Я ожидаю, что мои данные пользователя будут сохранены в базе данных. Это простой пример, чтобы помочь вам понять технику. Более сложные случаи могут быть рассмотрены в будущем.
Шаг 1: Определите карту причин и откликов.
Шаг 2: Создайте таблицу принятия решений на основе этой карты.
Где использовать?
Эта техника может быть использована в случаях, когда у нас есть неочевидные зависимости и сложные условия для принятия решения. Она также может быть применена, когда наши действия влияют на хранение данных или другие внешние сервисы. Стоит отметить, что эта техника хорошо сочетается с диаграммами состояний и последовательности.
Используя свои знания о системе, QA-специалист может «предугадать», при каких входных условиях есть риск ошибок. Для этого важно иметь опыт, хорошо знать продукт и уметь выстроить коммуникации с коллегами.
Например, в спецификации указано, что поле должно принимать код из четырех цифр. В числе возможных тестов:
Что произойдет, если не ввести код?
Что произойдет, если не ввести спецсимволы?
Что произойдет, если ввести не цифры, а другие символы?
Что произойдет, если ввести не четыре цифры, а другое количество?
Преимущества:
1. Эта проверка эффективна в качестве дополнения к другим техникам. 2. Выявляет тестовые случаи, которые “никогда не должны случиться”.
Недостатки: 1. Техника в значительной степени основана на интуиции. 2. Необходим опыт в тестировании подобных систем. 3. Малое покрытие тестами.
Пример
В предыдущем сценарии мы можем не предоставлять данные вообще, предоставлять специальные символы в качестве имени пользователя, только цифры и т. д.
Шаг 1: Определите отрицательные случаи для функциональности, которую нужно протестировать на основе каждой техники проектирования тестов.
Шаг 2: Определите, что ожидается для каждого отрицательного сценария из шага #1.
Где использовать?
Везде, где пользователь может предоставлять данные. Для UI это могут быть формы, флажки, кнопки и т. д. Для API-сервисов - параметры запроса, параметры пути, параметры тела.
Шаг 2: Создайте тест-кейсы, чтобы включить все возможные пары между каждыми 2 параметрами. Вы можете использовать инструменты, такие как , чтобы облегчить свою работу.
