Как писать тестовые примеры с примерами
Томас Гамильтон
🚀 Умное резюме
Тестовый случай — это документированный набор условий, входных данных, действий и ожидаемых результатов для проверки правильности работы определенной функции в программных приложениях.
Что такое тестовый пример?
A прецедент представляет собой набор действия, входы и ожидаемые результаты который помогает тестировщикам проверить, работает ли определённая функция или функционал программного обеспечения так, как задумано. Он служит шаг за шагом руководство который определяет, что тестировать, как тестировать и какой результат ожидать.
Подумайте о тестовом случае как о рецепт для проверки — он сообщает вам точные ингредиенты (данные испытаний), процесс (шаги, которые необходимо выполнить) и то, как должно выглядеть идеальное блюдо (ожидаемый результат).
Хорошо написанный тестовый пример помогает гарантировать:
- Программное обеспечение соответствует бизнес-требования и требования пользователей.
- Ошибки или неожиданное поведение пойман рано.
- Тестирование может быть повторен и пересмотрен любым профессионалом в области обеспечения качества.
- Команды могут прослеживать какое требование проверяет каждый тест.
👉 Зарегистрируйтесь на бесплатный проект по живому тестированию программного обеспечения
Шаги по созданию тестовых примеров при ручном тестировании
Давайте создадим тестовый пример для сценария: проверка функциональности входа в систему.
Шаг 1) Простой тестовый пример для объяснения сценария будет следующим:
| Прецедент # | Тестовый кейс Descriptион |
|---|---|
| 1 | Проверьте ответ при вводе действительного адреса электронной почты и пароля. |
Шаг 2) Проверьте данные.
Чтобы выполнить тестовый пример, вам понадобится Тестовые данные. Добавляем его ниже
| Прецедент # | Тестовый кейс Descriptион | Тестовые данные |
|---|---|---|
| 1 | Проверьте ответ при вводе действительного адреса электронной почты и пароля. | Электронная почта: guru99@email.com Пароль: lNf9^Oti7^2h |
Идентификация тестовых данных может занять много времени, а иногда может потребоваться создание тестовых данных заново. Причина, по которой это необходимо задокументировать.
Шаг 3) Выполнять действия.
Чтобы выполнить тестовый пример, тестировщику необходимо выполнить определенный набор действий над AUT. Это документировано, как показано ниже:
| Прецедент # | Тестовый кейс Descriptион | Шаги тестирования | Тестовые данные |
|---|---|---|---|
| 1 | Проверьте ответ при вводе действительного адреса электронной почты и пароля. | 1) Введите адрес электронной почты
2) Введите пароль 3) Нажмите «Войти». |
Электронная почта: guru99@email.com
Пароль: lNf9^Oti7^2h |
Зачастую этапы тестирования не так просты, как описано выше, поэтому их необходимо документировать. Кроме того, автор тестового случая может покинуть организацию, уйти в отпуск, заболеть и не работать, или быть очень занятым другими важными задачами. Выполнение тестового случая может быть поручено недавно нанятому сотруднику. Задокументированные этапы помогут ему и облегчат проверку другими заинтересованными сторонами.
Шаг 4) Проверьте поведение AUT.
Целью тестовых случаев при тестировании программного обеспечения является проверка поведения тестируемого приложения на соответствие ожидаемому результату. Это должно быть задокументировано следующим образом.
| Прецедент # | Тестовый кейс Descriptион | Тестовые данные | ожидаемый результат |
|---|---|---|---|
| 1 | Проверьте ответ при вводе действительного адреса электронной почты и пароля. | Электронная почта: guru99@email.com Пароль: lNf9^Oti7^2h |
Вход должен пройти успешно |
Во время выполнения теста тестер сверяет ожидаемые результаты с фактическими и присваивает статус «пройден» или «не пройден».
| Прецедент # | Тестовый кейс Descriptион | Тестовые данные | ожидаемый результат | Фактический результат | Пройдено / Не сдано |
|---|---|---|---|---|---|
| 1 | Проверьте ответ при вводе действительного адреса электронной почты и пароля. | Электронная почта: guru99@email.com Пароль: lNf9^Oti7^2h | Вход должен пройти успешно | Вход прошел успешно | Проходить |
Шаг 5) Помимо вашего тестового примера, может быть поле типа:
Предварительное условие, определяющее условия, которые должны быть выполнены перед запуском теста. В нашем тестовом случае предварительным условием будет установленный браузер для доступа к тестируемому сайту. Тестовый случай также может включать постусловия, определяющие всё, что применяется после завершения теста. В нашем тестовом случае постусловием будет сохранение времени и даты входа в базу данных.
Ключевые элементы тестового случая
Стандартный тестовый случай обычно включает в себя:
- Идентификатор тестового случая – Уникальный идентификатор (например, TC001)
- Название или Descriptион – Что проверяет тест
- Предпосылками – Что должно быть до начала теста
- Шаги тестирования – Точные действия, которые необходимо выполнить
- Тестовые данные – Входные значения или параметры
- ожидаемый результат – Результат, который вы должны увидеть
- Фактический результат – Что на самом деле произошло?
- Статус – Сдал, не сдал или заблокировал
Тестовый случай против тестового сценария
A тестовый сценарий описывает, что необходимо протестировать — общую функциональность или путь пользователя.
A тестовый случай, с другой стороны, объясняет, как будет проверяться эта функциональность — точные шаги, данные и ожидаемые результаты.
Проще говоря:
- Тестовый сценарий = Идея что тестировать.
- Тестовый случай = Реализация как проверить эту идею.
Подумайте об этом так:
«Если тестовый сценарий — это заголовок главы, то каждый тестовый случай — это абзац, подробно объясняющий эту главу».
Пример иллюстрации:
Давайте рассмотрим пример, чтобы было понятнее:
Сценарий тестирования:
«Проверьте функцию входа на сайт».
Связанные тестовые случаи:
- Подтвердите вход, используя действительное имя пользователя и пароль.
- Проверьте сообщение об ошибке с неверным паролем.
- Подтвердите вход с пустыми полями.
- Поле подтверждения пароля скрывает вводимый текст.
Здесь сценарий такой: единая функциональная цель, в то время как тестовые случаи разбивают его на конкретные, проверяемые условия.
Прочитайте для получения более подробной информации о Разница между тестовым случаем и тестовым сценарием
Преимущества написания качественных тестовых случаев
- Высококачественные тестовые случаи гарантируют тщательность тестовое покрытие, последовательность и прослеживаемость на протяжении всего процесса обеспечения качества.
- Они помогают тестировщикам поймать ошибки рано, поддерживать регрессионная устойчивостьи гарантировать, что каждая функциональность соответствует бизнес-требованиям.
- Хорошо написанные тестовые случаи прозрачный, многоразовый и воспроизводимый, позволяя любому тестировщику или инструменту автоматизации выполнять их надежно.
- Они также действуют как коммуникационный мост между разработчиками, тестировщиками и заинтересованными сторонами — уменьшая неоднозначность и экономя время.
- Документируя цели, этапы и результаты тестирования, команды могут измерять прогресс, соблюдать стандарты, и эффективно управлять обновлениями.
- Самое главное — хорошие тестовые случаи сократить расходы на техническое обслуживание, ускорить автоматизацию и обеспечить уверенность в качестве программного обеспечения.
- Они служат живой документацией для адаптации новых тестировщиков и структурированными входными данными для ИИ и инструменты управления тестированием.
Распространенные ошибки, которых следует избегать при написании тестовых случаев
Даже опытные тестировщики допускают небольшие ошибки, которые снижают качество тестирования.
Избегая этих ошибок, можно значительно улучшить точность, ясность и удобство обслуживания вашего набора тестов.
- Написание неопределенных шагов: Неоднозначные инструкции, такие как «проверьте страницу входа», сбивают тестировщиков с толку. Используйте чёткие, основанные на действиях инструкции.
- Пропуск негативных сценариев: Всегда включайте недопустимые входные данные или граничные тесты, чтобы обеспечить полный охват.
- Повторное использование неясных тестовых данных: Немаркированные или противоречивые данные делают результаты тестов ненадёжными. Ведите общий лист данных теста.
- Чрезмерное усложнение тестовых случаев: Длинные, многоэтапные кейсы сложно поддерживать. Сохраняйте каждый кейс целостным и неделимым.
- Игнорирование обновлений после изменений продукта: Устаревшие тестовые случаи создают ложные результаты. Revрегулярно просматривать и пересматривать.
- Отсутствует прослеживаемость: Всегда связывайте тестовые случаи с требованиями, чтобы отслеживать охват и соответствие.
- Пропуск рецензий коллег: Свежий взгляд быстро замечает неясные или лишние шаги.
