Определение тестовых случаев и приоритетов

Определите, что тестировать, определите тестовые примеры и расставьте приоритеты.

Ramona Schwering

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

1. Берегите свой счастливый путь . Это наиболее общая или основная пользовательская история вашего приложения, в которой ваш пользователь очень быстро заметит ошибку.
2. Тщательно определитесь с уровнем детализации . Узнайте больше, если ваш вариант использования уязвим или ошибка может привести к серьезному ущербу.
3. По возможности отдавайте предпочтение тестам более низкого уровня , таким как модульные и интеграционные тесты, перед сквозными тестами более высокого уровня.

В оставшейся части статьи рассматриваются эти критерии и то, как они применяются при определении тестовых примеров.

Что такое тестовый пример?

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

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

• Проверка . Процесс тщательной проверки программного обеспечения для обеспечения его работы без ошибок. Решающее значение имеет определение того, отвечает ли созданный продукт всем необходимым нефункциональным требованиям и успешно ли достигает поставленной цели. Вопрос, на который он отвечает: «Правильно ли мы создаем продукт?»
• Проверка . Процесс обеспечения соответствия программного продукта необходимым стандартам или требованиям высокого уровня. Он включает в себя проверку того, соответствует ли фактический продукт ожидаемому продукту. По сути, мы отвечаем на вопрос: «Создаем ли мы продукт, соответствующий требованиям пользователя?»

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

Пути тестирования: типичные виды тестовых случаев

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

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

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

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

Существует несколько методов классификации этих путей. Два распространенных подхода:

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

Лучшая практика: написание тестовых примеров

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

• Организуйте, действуйте, утверждайте шаблон. Шаблон тестирования «организовывать, действовать, утверждать» (также известный как «ААА» или «Тройной А») — это способ разбить тесты на три отдельных этапа: организация теста, затем его выполнение и, наконец, что не менее важно, Делать выводы.
• Учитывая, когда, то закономерность. Этот паттерн похож на паттерн ААА, но имеет некоторые корни в разработке, основанной на поведении .

В следующих статьях эти шаблоны будут рассмотрены более подробно, как только мы рассмотрим структуру самого теста. Если вы хотите углубиться в эти шаблоны на этом этапе, ознакомьтесь с этими двумя статьями: Arrange-Act-Assert: шаблон для написания хороших тестов и «Дано-Когда-Тогда» .

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

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