Определите, что именно тестировать, определите тестовые случаи и расставьте приоритеты.
В предыдущем посте вы узнали о стратегиях тестирования, количестве тестов, необходимых для тестирования приложения, и о том, как найти наилучшее соответствие, чтобы получить наибольшую уверенность в результатах, учитывая ваши ресурсы. Однако это дает нам только представление о том, сколько тестировать. Вам все еще нужно точно определить, что тестировать. Следующие три критерия могут быть полезны для понимания того, чего ожидать от теста, и для того, чтобы увидеть, какой тип тестирования и уровень детализации могут подойти лучше всего:
- Позаботьтесь о своем счастливом пути . Это самая общая или основная пользовательская история вашего приложения, где ваш пользователь очень быстро заметит ошибку.
- Тщательно выбирайте уровень детализации . Подробно опишите, если ваш вариант использования уязвим или ошибка может нанести большой ущерб.
- По возможности отдавайте приоритет низкоуровневым тестам , таким как модульные и интеграционные тесты, а не сквозным тестам высокого уровня.
В оставшейся части статьи рассматриваются эти критерии и то, как они применяются при определении тестовых случаев.
Что такое тестовый пример?
В разработке программного обеспечения тестовый случай — это последовательность действий или обстоятельств, которые разработаны для подтверждения эффективности программного обеспечения или приложения. Тестовый случай направлен на то, чтобы убедиться, что программное обеспечение работает так, как запланировано, и что все его возможности и функции работают правильно. Тестировщики или разработчики программного обеспечения обычно создают эти тестовые случаи, чтобы гарантировать, что программное обеспечение соответствует указанным требованиям и спецификациям.
При запуске тестового случая программное обеспечение выполняет ряд проверок, чтобы убедиться, что оно выдает желаемые результаты. При этом тест выполняет следующие задачи:
- Проверка . Процесс тщательной проверки программного обеспечения для обеспечения его работы без ошибок. Определение того, соответствует ли созданный продукт всем необходимым нефункциональным требованиям и успешно ли он достигает своего предполагаемого назначения, имеет решающее значение. Вопрос, на который он отвечает: «Правильно ли мы создаем продукт?»
- Валидация . Процесс обеспечения соответствия программного продукта необходимым стандартам или требованиям высокого уровня. Он включает проверку соответствия фактического продукта ожидаемому продукту. По сути, мы отвечаем на вопрос: «Создаем ли мы правильный продукт для требований пользователя?»
Предположим, что программа не может обеспечить ожидаемый результат. В этом случае тестовый случай будет посланником — таким образом, сообщая о неудачном результате, и разработчику или тестировщику нужно будет исследовать проблему и найти решение. Думайте о проверках и действиях как о путях, по которым следует компьютер, независимо от типа тестирования. Группы входных данных или условий, используемых для проверки, называются «классами эквивалентности». Они должны получать похожее поведение или результаты от тестируемой системы. Конкретные пути, выполняемые внутри теста, могут различаться, но должны соответствовать действиям и утверждениям, выполненным в вашем тесте.
Тестовые пути: типичные виды тестовых случаев
В разработке программного обеспечения тестовый случай — это сценарий выполнения кода, от которого ожидается и тестируется определенное поведение. Обычно существует три сценария для формирования тестовых случаев.
Первый из них наиболее известен, и вы, вероятно, уже его используете. Это счастливый путь , также известный как «сценарий счастливого дня» или «золотой путь». Он определяет наиболее распространенный вариант использования вашей функции, приложения или изменения — то, как это должно работать для клиента.
Второй по важности тестовый путь, который нужно охватить в ваших тестовых случаях, часто опускается, поскольку он неудобен — как может подразумевать его название. Это «страшный путь» или, другими словами, отрицательный тест . Этот путь нацелен на сценарии, которые заставляют код вести себя неправильно или входить в состояние ошибки. Тестирование этих сценариев особенно важно, если у вас есть очень уязвимые варианты использования, представляющие высокий риск для заинтересованных лиц или пользователей.
Есть и другие пути, о которых вы, возможно, захотите узнать и рассмотреть их использование, но обычно они используются реже. В следующей таблице они суммированы:
| Тестовый путь | Объяснение |
|---|---|
| Злой путь | Это приводит к ошибке, но вполне ожидаемой; например, если вы хотите убедиться, что обработка ошибок работает правильно. |
| Путь просроченной задолженности | Этот путь учитывает все сценарии, связанные с безопасностью, которые необходимо реализовать вашему приложению. |
| Пустынный путь | Путь тестирования сценария в вашем приложении не получает достаточно данных для функционирования, например, при тестировании нулевых значений. |
| Забывчивый путь | Тестирование поведения вашего приложения при недостатке ресурсов, например, при возникновении потери данных. |
| Нерешительный путь | Тестирование с пользователем, который пытается выполнить действия или следовать историям пользователя в вашем приложении, но не завершил эти рабочие процессы. Это может быть в случае, например, когда пользователь прерывает свой рабочий процесс. |
| Жадный путь | Попытка провести тестирование с использованием огромных объемов входных данных. |
| Стрессовый путь | Попытка любыми способами нагрузить ваше приложение до тех пор, пока оно не перестанет функционировать (аналогично нагрузочному тесту). |
Существует несколько методов категоризации этих путей. Два распространенных подхода:
- Эквивалентное разбиение . Метод тестирования, который классифицирует тестовые случаи по группам или разделам и, как следствие, помогает создавать классы эквивалентности. Он основан на идее, что если один тестовый случай в разделе обнаруживает дефект, другие тестовые случаи в том же разделе, скорее всего, выявят похожие дефекты. Поскольку все входные данные в определенном классе эквивалентности должны демонстрировать одинаковое поведение, вы можете уменьшить количество тестовых случаев. Узнайте больше о эквивалентном разбиении .
- Анализ пределов . Метод тестирования, также известный как анализ граничных значений , который исследует пределы или экстремумы входных значений для выявления любых потенциальных проблем или ошибок, которые могут возникнуть на предельных возможностях или ограничениях системы.
Лучшая практика: написание тестовых случаев
Классический тестовый случай, написанный тестировщиком, будет содержать определенные данные, которые помогут вам понять содержание теста, который вы хотите провести, и, конечно, выполнить тест. Типичный тестировщик документирует свои усилия по тестированию в таблице. На этом этапе мы можем использовать два шаблона, которые помогут нам структурировать наши тестовые случаи, а позже и сами тесты:
- Шаблон « Организуй, действуй, утверждай ». Шаблон тестирования «Организуй, действуй, утверждай» (также известный как «ААА» или «Тройной А») — это способ организации тестов в три отдельных этапа: организация теста, затем выполнение теста и, наконец, но не в последнюю очередь, подведение итогов.
- Дано, когда, тогда шаблон. Этот шаблон похож на шаблон AAA, но имеет некоторые корни в развитии, обусловленном поведением .
В будущих статьях мы более подробно рассмотрим эти шаблоны, как только рассмотрим структуру самого теста. Если вы хотите углубиться в эти шаблоны на данном этапе, ознакомьтесь с этими двумя статьями: Arrange-Act-Assert: A pattern for writing good tests и Given-When-Then .
Согласно всем выводам, сделанным в этой статье, следующая таблица резюмирует классический пример:
| Информация | Объяснение |
|---|---|
| Предпосылки | Все, что необходимо сделать перед написанием теста. |
| Тестируемый объект | Что необходимо проверить? |
| Входные данные | Переменные и их значения. |
| Действия, которые необходимо выполнить | Все, что вам предстоит сделать, чтобы оживить свой тест: все действия или взаимодействия, которые вы совершаете в своих тестах. |
| Ожидаемый результат | Что должно произойти и какие ожидания должны быть выполнены. |
| Фактический результат | Что происходит на самом деле. |
В автоматизированном тестировании вам не нужно документировать все эти тестовые случаи так, как это нужно тестировщику, хотя это, несомненно, полезно. Вы можете найти всю эту информацию в своем тесте, если будете внимательны. Итак, давайте переведем этот классический тестовый случай в автоматизированный тест.
| Информация | Перевод на автоматизацию тестирования |
|---|---|
| Предпосылки | Все, что вам нужно, организовать тест и подумать о том, что дано для того, чтобы сценарий вашего теста воплотился в жизнь. |
| Тестируемый объект | Этим «объектом» могут быть различные вещи: приложение, поток, блок или тестируемый компонент. |
| Входные данные | Значения параметров. |
| Действия, которые необходимо выполнить | Все действия и команды, выполняемые в вашем тесте, вещи, с которыми вы работаете, и выяснение того, что происходит, когда вы делаете определенные вещи. |
| Ожидаемый результат | Утверждение, которое вы используете для подтверждения своей заявки, то, о чем вы утверждаете в своей заявке. |
| Фактический результат | Результат вашего автоматизированного теста. |