13 советов по написанию мощных тестовых примеров, которые вам нужно знать
25 апреля 2023 г.Написание тестовых сценариев — самый недооцененный, но самый эффективный инструмент анализа требований. Только вопрос «Как мы собираемся это проверить?» может выявить все скрытые риски и проблемы с требованиями. Тест-кейсы — это подстраховка при разработке программного обеспечения. Хотя нет, если они плохо написаны. В таком случае они могут только способствовать неправильному представлению о том, что написание тестовых случаев — это пустая трата времени и узкое место.
Вот мои 13 советов по написанию мощных тестов, которые укрепляют доверие к тестированию.
#1 Тестовые случаи должны быть простыми для понимания
Первое эмпирическое правило написания тестового примера состоит в том, что (почти) каждый может понять его цель, его важность, как к нему подготовиться, как выполнить тестовый набор и каков ожидаемый результат. При написании контрольного примера всегда представляйте себя в свой первый рабочий день. Не могли бы вы выполнить это?
Всегда добавляйте всю необходимую информацию о выполнении теста и проверке ожидаемых результатов.
Например, если необходимо проверить запись журнала, добавьте инструкции о том, как получить доступ к журналу. Если эти инструкции не написаны, напишите их и добавьте ссылку в статью.
Или, если ожидаемый результат нужно проверить в базе данных, прикрепите запрос к тестовому набору, чтобы следующему человеку не пришлось писать его заново.
#2 Тестовые случаи должны быть простыми в выполнении
Эффективность. Тестовый пример должен быть написан ясно и просто, чтобы его выполнение вручную не было медленным, подверженным ошибкам и утомительным.
Эффективность. Тестовый пример должен обеспечивать быстрое выполнение и отслеживаемость выполненных шагов и используемых тестовых данных, чтобы можно было легко вывести причину этого из теста при обнаружении ошибки.
Надежность. Тестовый набор всегда должен давать одни и те же результаты, если нет регрессии или измененного поведения, требующего модификации самого теста.
Автоматизированный. Кроме того, всегда помните, как можно автоматизировать этот тестовый пример. Изменится ли способ написания?
#3 Тестовые наборы должны быть независимы друг от друга
Независимые тестовые наборы — сложная практика, но это правило номер один, когда речь идет об автоматизированных тестах.
Однако для ручных тестов вот как избежать путаницы: используйте предварительные условия и общие шаги. Если результат тестового примера можно использовать в качестве входных данных для другого тестового примера, пометьте последний шаг (или весь тестовый набор) как «общий шаг». Таким образом, вместо упорядочивания тестовых наборов вы можете указать, что предварительным условием для тестового примера А является X, что может быть достигнуто, если вы выполните тестовый набор Б.
Упомянутое выше правило автоматизации гласит, что каждый тест должен создавать свои тестовые данные, а затем уничтожать их, оставляя систему в нейтральном состоянии, на которое не влияет выполнение теста.
Второе правило автоматизации заключается в том, что тесты должны выполняться параллельно
.Представьте тесты 2104, которые вам нужно запускать при каждой отправке в основную ветку, большинство из которых являются модульными тестами. Некоторым нужно 10-20 секунд, чтобы бежать. Это час. Хотя обычно это безумно хорошая производительность теста, представьте, что они зависят друг от друга, а 486-й не проходит…
Вы потратили 20 минут, не понимая, что не так, потому что все остальное тоже провалилось. А теперь представьте, что вы можете запускать их независимо параллельно, и вместо часа тестовый прогон занимает 20 минут.
Все проходят — трое не проходят. Это обеспечит очень суженные рассуждения и эффективное устранение неполадок, не говоря уже об эмоциях, которые вы испытаете, когда увидите, что 3 теста не пройдены именно этим изменением по сравнению с 1618 RED.
#4 Тестовый пример должен быть грамотным, тщательным, но компактным
Качество тест-кейсов — второй фактор, демонстрирующий навыки тестировщика после описания ошибки.
На каком бы языке вы ни писали, убедитесь, что текст хорошо написан. Подходит для тестового случая. Держите его сфокусированным, простым и компактным. Не используйте слова-заполнители.
Думайте о контрольном примере, как о диаграмме или блок-схеме, написанной текстом. Тем не менее, он должен быть тщательным и ясным, и читатель не должен ни о чем догадываться.
#6 Если шаг не имеет значения, не пишите его.
Просматривайте и оптимизируйте свои тестовые наборы так часто, как это необходимо, чтобы убедиться, что нет шагов, которые могут изменить способ выполнения тестового набора или отвлечь от первоначального замысла, не имея отношения к ожидаемому результату.
#7. Если шаг одинаков для всех случаев, извлеките его.
Не повторяйте. Каждый раз, когда вам нужно выполнить копирование/вставку, это красный сигнал тревоги о том, что вы накапливаете отходы. Если есть необходимость копировать и вставлять одну и ту же информацию более чем в одном месте, то, когда придет время их обновить, вам придется обновить ее в нескольких местах. Нет ничего более вероятного, что может вызвать ошибки.
Это правило применимо ко всему в жизни и работе.
Извлеките повторяющуюся информацию в одно место и свяжите или свяжите ее потребителей.
#8 Всегда помните об ожидаемом результате.
Тест — пустая трата времени, если вы не возлагаете на него никаких ожиданий. У вас также есть ожидания, когда вы проводите исследовательское тестирование. Вы хотите найти вопросы, проблемы, сбои, несоответствия, несоответствия и все остальное, что беспокоит вас как тестировщика и может беспокоить пользователя.
Ожидаемый результат — это ваша тестовая путеводная звезда. Зачем ты это тестируешь? Что вы ожидаете найти? Вы не ожидаете, что это сработает. Ничто не работает, пока не будет доказано тестированием.
Если вы начинаете тестирование с фразой «все вроде бы работает», вы вредите себе.
Поэтому, когда вы пишете тестовый пример, всегда спрашивайте себя, каков ожидаемый результат каждого шага и всего тестового примера. Каждый шаг и тестовые данные должны использовать различные способы, которые могут привести к тому, что система не оправдает ожиданий.
Отношение между положительными и отрицательными тестовыми примерами — один ко многим. Не довольствуйтесь только позитивом. Докажите, что система надежна.
#9 Ожидается более одного результата.
Только один ожидаемый результат — редкость. В типичном веб-приложении вам может потребоваться проверить результат в пользовательском интерфейсе, проверить, правильно ли значение отправляется через API и правильно ли оно хранится в базе данных. Вам нужно проверить ожидаемый результат в 3 разных местах.
Напишите в контрольном примере и дополнительную информацию о том, как получить доступ к этим местам и как проверить ожидаемый результат.
#10 Всегда пишите в таблицах, а не в списках
То, что мы называем тестовым набором, может быть отдельным значением или комбинацией значений. Это может быть одно действие или комбинация действий. Но самое главное, это концепция письма, изображающая комбинацию входных значений, действий и ожидаемых результатов.
Таблица — лучший формат для тестового примера.
Даже если вам нужно выполнить последовательность действий, не записывайте ее в виде списка действий. Когда вы начинаете писать тест-кейс, независимо от того, используете ли вы систему управления тест-кейсами или нет, всегда начинайте с таблицы.
#, Step, Input, Expected Result — это таблица тестов, все, что вам нужно. Добавьте простой раздел о назначении, предварительных условиях, конфигурациях и т. д.
#11. Используйте домен и язык пользовательского интерфейса.
Формулировки в контрольном примере должны соответствовать вашим соглашениям. Если их нет, то тестовые примеры — это хорошая отправная точка для создания словаря вашего продукта.
Очень часто инженеры называют функции и компоненты иначе, чем названия продуктов, отделов продаж и маркетинга или клиентов.
Тестировщики — это те, кто должен говорить на всех языках, а тестовые примеры — источник правды для имен и поведения.
#12 Следуйте соглашению об именах тестовых наборов:
Какой бы контент вы ни создавали, с первого взгляда должно быть понятно, какую информацию он предоставляет и как по нему перемещаться. Лучшее соглашение об именах для тестового примера: «Модуль — Функциональность — Какой случай вы проверяете с его помощью».
Не пишите заголовки контрольных примеров вроде «Убедитесь, что отчеты работают должным образом».
Есть два основных преимущества написания схем заголовков:
- Во-первых, однозначно ясно, какова цель теста и какая функция тестируется.
- Во-вторых, это делает тестовые наборы доступными для поиска, фильтрации и сортировки, их легко группировать, упорядочивать и расставлять по приоритетам.
#13 Соблюдайте правила оформления тестовых данных:
Если вы читали мои предыдущие темы о написании тестовых случаев, вы заметили главную тему — ясность. И дело не только в тест-кейсах. То, что известно, должно быть ясно донесено до целевой аудитории. Неудивительно, что стиль имеет значение.
Не впадайте в другую крайность, тратя слишком много времени и усилий на дизайн текста, который еще более неясен.
Используйте умный стиль шрифта, чтобы различать текст тестового примера, инструкции, шаги, ожидаемые результаты тестовых данных, конфигурации, имена функций и компонентов и т. д.
Проще всего использовать ВСЕ ЗАГЛАВНЫЕ буквы для всего, что не является простым текстом — для любых компонентов пользовательского интерфейса или имен функций. Это также самый быстрый способ написать. Другие примеры соглашений о стилях тестовых данных
- Кнопка
- Сохранить, СОХРАНИТЬ, Сохранить, СОХРАНИТЬ.
- Файл, РЕДАКТИРОВАНИЕ, Просмотр, меню ИСТОРИЯ
- кнопка «Сохранить»; Меню «Файл».
Соглашения о стилях также применяются к входным тестовым данным, но лучше всего использовать параметры теста и извлекать тестовые данные вне теста.
- @firstName, @firstName, @first_name, @FIRST_NAME
, [first_name] - [имя], «имя_имя»
Начните писать и сами убедитесь, что написать проще и быстрее всего. Для меня лучший формат тестовых параметров — @firstName
И последнее, но не менее важное: параметризованные тестовые случаи намного быстрее автоматизируются.
Продолжайте писать
Это мои 13 правил написания тестовых сценариев, которые на протяжении многих лет доказали свою эффективность в налаживании хороших отношений между группами разработчиков, разработчиков, тестировщиков, разработчиков и специалистов службы поддержки, поскольку они объединяют язык продукта и упрощают взаимодействие между командами.
Тестовые наборы — это база знаний. Они являются живой историей программного обеспечения и должны отвечать на восклицания типа «Это всегда так работало!», «Так задумано!», «Как это должно работать?», «Почему эта ошибка ускользнула?
Тестовые случаи также являются отличным инструментом анализа и управления рисками. При их написании команда могла сразу же обнаружить упущения, противоречия, неясности, расползание и сокращение объема в требованиях и, таким образом, гарантировать, что команда приступает к разработке с гораздо большей ясностью в отношении ожиданий клиентов.
Если один из регулярных вопросов в разделе «Улучшение» ваших ретроспектив — «Нам следовало улучшить историю», не пропустите мой семинар «Освоение анализа пользовательских историй», где я расскажу о состоянии дел. art Доска Miro для анализа пользовательских историй!
:::информация Также опубликовано здесь.
:::
Оригинал