Что такое тестовый пример?
TEST СЛУЧАЙ представляет собой набор действий , выполняемых для проверки конкретной функции или функциональности вашего приложения. Тестовый пример содержит этапы тестирования, тестовые данные, предварительное условие и постусловие, разработанные для конкретного тестового сценария для проверки любого требования. Тестовый пример включает в себя определенные переменные или условия, с помощью которых инженер по тестированию может сравнить ожидаемые и фактические результаты, чтобы определить, работает ли программный продукт в соответствии с требованиями заказчика.
Тестовый сценарий против тестового случая
Сценарии тестирования довольно расплывчаты и охватывают широкий спектр возможностей. Главное в тестировании - быть очень конкретным.
Для тестового сценария: проверьте функциональность входа в систему, существует множество возможных тестовых случаев:
- Тестовый пример 1. Проверьте результаты при вводе действительного идентификатора пользователя и пароля.
- Тестовый пример 2: проверьте результаты при вводе неверного идентификатора пользователя и пароля
- Тестовый пример 3: проверка ответа, когда идентификатор пользователя пуст и нажата кнопка входа в систему, и многое другое.
Это не что иное, как тестовый пример.
В этом руководстве вы узнаете, как писать тестовые примеры при ручном тестировании с примером -
- Как писать тестовые примеры при ручном тестировании
- Формат стандартных тестовых случаев
- Лучшая практика для написания хорошего тестового примера.
- Инструменты управления тестовым набором
- Ресурсы
Нажмите здесь, если видео недоступно
Как писать тестовые примеры при ручном тестировании
Давайте создадим тестовый пример для сценария: Проверка функциональности входа в систему
Шаг 1) Простой тестовый пример для объяснения сценария:
| Прецедент # | Описание тестового случая |
|---|---|
| 1 | Проверить ответ, если введен действующий адрес электронной почты и пароль |
Шаг 2) Для выполнения тестового примера вам потребуются тестовые данные. Добавляем его ниже
| Прецедент # | Описание тестового случая | Данные испытаний |
|---|---|---|
| 1 | Проверить ответ, если введен действующий адрес электронной почты и пароль | Электронная почта: Этот адрес электронной почты защищен от спам-ботов. У вас должен быть включен JavaScript для просмотра. Пароль: lNf9 Oti7 2h |
Идентификация тестовых данных может занять много времени и иногда может потребоваться создание тестовых данных заново. Причина, по которой это необходимо задокументировать.
Шаг 3) Чтобы выполнить тестовый пример, тестировщик должен выполнить определенный набор действий с AUT. Это задокументировано ниже:
| Прецедент # | Описание тестового случая | Шаги тестирования | Данные испытаний |
|---|---|---|---|
| 1 | Проверить ответ, если введен действующий адрес электронной почты и пароль |
1) Введите адрес электронной почты 2) Введите пароль 3) Нажмите "Войти". |
Электронная почта: Этот адрес электронной почты защищен от спам-ботов. У вас должен быть включен JavaScript для просмотра. Пароль: lNf9 Oti7 2h |
Часто этапы тестирования не такие простые, как указано выше, поэтому для них требуется документация. Кроме того, автор тестового примера может уволиться из организации или уйти в отпуск, или заболеть и не работать, или будет очень занят другими важными задачами. Недавно нанятого сотрудника могут попросить выполнить тестовый пример. Задокументированные шаги помогут ему, а также облегчат рассмотрение другими заинтересованными сторонами.
Шаг 4) Цель тестовых примеров при тестировании программного обеспечения - проверить поведение AUT для получения ожидаемого результата. Это необходимо задокументировать, как показано ниже.
| Прецедент # | Описание тестового случая | Данные испытаний | ожидаемый результат |
|---|---|---|---|
| 1 | Проверить ответ, если введен действующий адрес электронной почты и пароль | Электронная почта: Этот адрес электронной почты защищен от спам-ботов. У вас должен быть включен JavaScript для просмотра. Пароль: lNf9 Oti7 2h | Вход должен быть успешным |
Во время выполнения теста тестировщик сравнивает ожидаемые результаты с фактическими результатами и присваивает статус пройден или не пройден.
| Прецедент # | Описание тестового случая | Данные испытаний | ожидаемый результат | Фактический результат | Пройдено / Не сдано |
|---|---|---|---|---|---|
| 1 | Проверить ответ, если введен действующий адрес электронной почты и пароль | Электронная почта: Этот адрес электронной почты защищен от спам-ботов. У вас должен быть включен JavaScript для просмотра. Пароль: lNf9 Oti7 2h | Вход должен быть успешным | Вход был успешным | Проходить |
Шаг 5) Кроме того, в вашем тестовом примере может быть поле типа Pre - Condition, в котором указываются вещи, которые должны быть выполнены перед запуском теста. Для нашего тестового примера предварительным условием будет наличие установленного браузера для доступа к тестируемому сайту. Тестовый пример может также включать постусловия, которые определяют все, что применяется после завершения тестового примера. Для нашего тестового примера постусловием будет время и дата входа в систему, хранящиеся в базе данных.
Формат стандартных тестовых случаев
Ниже приведен формат стандартного примера тестовых случаев входа в систему.
| ID тестового набора | Сценарий тестирования | Шаги тестирования | Данные испытаний | Ожидаемые результаты | Фактические результаты | Пройдено / Не сдано |
|---|---|---|---|---|---|---|
| TU01 | Проверьте логин клиента с действительными данными |
| Userid = guru99 Пароль = pass99 | Пользователь должен войти в приложение | Как и ожидалось | Проходить |
| TU02 | Проверьте логин клиента с неверными данными |
| Userid = guru99 Пароль = glass99 | Пользователь не должен входить в приложение | Как и ожидалось | Проходить |
Вся эта таблица может быть создана в Word, Excel или любом другом инструменте управления тестированием. Это все, что касается дизайна тестового кейса
При составлении тестового примера необходимо включить следующую информацию
- Описание того, какое требование тестируется
- Объяснение того, как система будет тестироваться
- Тестовая настройка, такая как версия тестируемого приложения, программное обеспечение, файлы данных, операционная система, оборудование, безопасный доступ, физическая или логическая дата, время дня, предварительные условия, такие как другие тесты, и любая другая информация о настройке, относящаяся к тестируемым требованиям.
- Входы и выходы или действия и ожидаемые результаты
- Любые доказательства или вложения
- Использовать активный регистр
- Тестовый набор не должен содержать более 15 шагов.
- Сценарий автоматического тестирования комментируется с вводными данными, целью и ожидаемыми результатами.
- Установка предлагает альтернативу предварительным тестам.
- С другими тестами это должен быть неправильный порядок бизнес-сценария
Лучшая практика для написания хорошего тестового примера.
1. Тестовые примеры должны быть простыми и прозрачными:
Создавайте как можно более простые тестовые примеры. Они должны быть четкими и краткими, поскольку автор тестового примера не может их выполнить.
Используйте напористый язык, например, перейдите на домашнюю страницу, введите данные, щелкните по нему и так далее. Это упрощает понимание этапов тестирования и ускоряет выполнение тестов.
2. Создайте тестовый пример с мыслями о конечном пользователе.
Конечная цель любого программного проекта - создать тестовые примеры, которые соответствуют требованиям клиентов и просты в использовании и эксплуатации. Тестировщик должен создавать тестовые примеры с учетом точки зрения конечного пользователя.
3. Избегайте повторения тестовых примеров.
Не повторяйте тестовые случаи. Если тестовый пример необходим для выполнения другого тестового примера, вызовите тестовый пример по его идентификатору тестового примера в столбце предварительного условия.
4. Не предполагайте
Не предполагайте функциональность и особенности вашего программного приложения при подготовке тестового примера. Придерживайтесь спецификационной документации.
5. Обеспечьте 100% покрытие
Убедитесь, что вы написали тестовые примеры, чтобы проверить все требования к программному обеспечению, упомянутые в документе со спецификациями. Используйте матрицу прослеживаемости, чтобы убедиться, что ни одна функция / условия не остались непроверенными.
6. Тестовые наборы должны быть идентифицируемыми.
Назовите идентификатор тестового примера так, чтобы их можно было легко идентифицировать при отслеживании дефектов или выявлении требований к программному обеспечению на более позднем этапе.
7. Внедрите методы тестирования.
Невозможно проверить все возможные условия в вашем программном приложении. Методы тестирования программного обеспечения помогают выбрать несколько тестовых примеров с максимальной вероятностью обнаружения дефекта.
- Анализ граничных значений (BVA): как следует из названия, это метод, который определяет тестирование границ для указанного диапазона значений.
- Разделение эквивалентности (EP): этот метод разбивает диапазон на равные части / группы, которые, как правило, имеют одинаковое поведение.
- Техника перехода между состояниями : этот метод используется, когда поведение программного обеспечения изменяется из одного состояния в другое после определенного действия.
- Техника угадывания ошибок: это угадывание / прогнозирование ошибки, которая может возникнуть при выполнении ручного тестирования. Это не формальный метод, в нем используется опыт работы с приложением тестировщика.
8. Самоочистка.
Создаваемый вами тестовый пример должен вернуть тестовую среду в состояние до тестирования и не должен выводить тестовую среду из строя. Это особенно актуально для тестирования конфигурации.
9. Повторяющиеся и самостоятельные
Тестовый пример должен генерировать одни и те же результаты каждый раз, независимо от того, кто его тестирует.
10. Экспертная оценка.
После создания тестовых случаев попросите их рассмотреть ваши коллеги. Ваши коллеги могут обнаружить дефекты в дизайне вашего тестового набора, которые вы легко можете пропустить.
Инструменты управления тестовым набором
Инструменты управления тестированием - это инструменты автоматизации, которые помогают управлять тестовыми наборами и поддерживать их. Основные возможности инструмента управления тестовыми случаями:
- Для документирования тестовых случаев: с помощью инструментов вы можете ускорить создание тестовых примеров с использованием шаблонов.
- Выполните тестовый пример и запишите результаты: тестовый пример можно выполнить с помощью инструментов, а полученные результаты можно легко записать.
- Автоматизация отслеживания дефектов: неудавшиеся тесты автоматически связываются с системой отслеживания ошибок, которая, в свою очередь, может быть назначена разработчикам и может отслеживаться с помощью уведомлений по электронной почте.
- Прослеживаемость: требования, тестовые примеры, выполнение тестовых примеров связаны между собой с помощью инструментов, и каждый случай может быть отслежен друг с другом для проверки покрытия тестами.
- Защита тестовых примеров : тестовые примеры должны быть многоразовыми и должны быть защищены от потери или повреждения из-за плохого контроля версий. Инструменты управления тестовыми случаями предлагают такие функции, как
- Соглашения об именах и нумерации
- Управление версиями
- Хранилище только для чтения
- Контролируемый доступ
- Внешнее резервное копирование
Популярные инструменты управления тестированием: Центр качества и JIRA.
Ресурсы
- Обратите внимание, что используемый шаблон будет отличаться от проекта к проекту. Прочтите это руководство, чтобы изучить шаблон тестового случая с объяснением важных полей.
Загрузите вышеуказанный шаблон тестового случая в формате Excel (.xls)
