Как писать тестовые примеры с примерами
Шаги по созданию тестовых примеров при ручном тестировании
Давайте создадим тестовый пример для сценария: проверка функциональности входа в систему.
Шаг 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.Цель тестовых примеров при тестировании программного обеспечения — проверить поведение AUT на предмет ожидаемого результата. Это необходимо задокументировать, как показано ниже.
Прецедент # | Тестовый кейс Descriptион | Тестовые данные | ожидаемый результат |
---|---|---|---|
1 | Проверьте ответ при вводе действительного адреса электронной почты и пароля. | Электронная почта: guru99@email.com Пароль: lNf9^Oti7^2h |
Вход должен пройти успешно |
Во время выполнения теста тестер сверяет ожидаемые результаты с фактическими и присваивает статус «пройден» или «не пройден».
Прецедент # | Тестовый кейс Descriptион | Тестовые данные | ожидаемый результат | Фактический результат | Пройдено / Не сдано |
---|---|---|---|---|---|
1 | Проверьте ответ при вводе действительного адреса электронной почты и пароля. | Электронная почта: guru99@email.com Пароль: lNf9^Oti7^2h | Вход должен пройти успешно | Вход прошел успешно | Проходить |
Шаг 5) Помимо вашего тестового примера, может быть поле типа:
Предварительное — условие, которое определяет, что должно быть выполнено перед запуском теста. В нашем тестовом примере предварительным условием будет установка браузера для доступа к тестируемому сайту. Тестовый пример также может включать в себя пост-условия, которые определяют все, что применяется после завершения тестового примера. Для нашего тестового примера постусловием будет время и дата входа в систему, хранящиеся в базе данных.
Как написать видео с тестовым примером
Нажмите здесь если видео недоступно
лучшая практика написания хорошего тестового случая.
1. Тестовые случаи должны быть простыми и прозрачными:
Создавайте максимально простые тестовые примеры. Они должны быть ясными и краткими, поскольку автор тестового примера не может их выполнить.
Используйте настойчивые выражения, например, зайдите на домашнюю страницу, введите данные, нажмите на это и так далее. Это облегчает понимание этапов тестирования и ускоряет выполнение тестов.
2. Создайте тестовый пример с учетом конечного пользователя
Конечная цель любого программного проекта — создание тестовых примеров, отвечающих требованиям заказчика и простых в использовании и эксплуатации. Тестировщик должен создавать тестовые примеры, учитывая точку зрения конечного пользователя.
3. Избегайте повторения тестовых примеров.
Не повторяйте тестовые случаи. Если тестовый набор необходим для выполнения какого-либо другого тестового примера, вызовите тестовый набор по его идентификатору тестового набора в столбце предварительного условия.
4. Не предполагайте
Не предполагайте функциональность и особенности вашего программного приложения при подготовке тестового примера. Придерживайтесь технических характеристик.
5. Обеспечьте 100% покрытие
Обязательно напишите тестовые примеры для проверки всех требований к программному обеспечению, упомянутых в спецификации. Использовать Матрица прослеживаемости чтобы гарантировать, что ни одна функция/условие не останется непроверенной.
6. Тестовые случаи должны быть идентифицируемыми.
Назовите идентификатор тестового набора так, чтобы его можно было легко идентифицировать при отслеживании дефектов или определении требований к программному обеспечению на более позднем этапе.
7. Внедрить методы тестирования
Невозможно проверить все возможные условия в вашем программном приложении. Методики тестирования программного обеспечения помогают выбрать несколько тестовых случаев с максимальной вероятностью обнаружения дефекта.
- Анализ граничных значений (BVA): Как следует из названия, это метод, определяющий проверку границ для заданного диапазона значений.
- Раздел эквивалентности (EP): Этот метод разделяет диапазон на равные части/группы, которые имеют одинаковое поведение.
- Техника перехода состояний: этот метод используется, когда поведение программного обеспечения изменяется из одного состояния в другое после определенного действия.
- Техника угадывания ошибок: Это угадывание/предвидение ошибки, которая может возникнуть при выполнении ручного тестирования. Это не формальный метод, в нем используется опыт тестировщика приложения.
8. Самоочищение
Создаваемый вами тестовый пример должен возвращать Тестовая среда в состояние перед тестированием и не должно приводить тестовую среду в непригодное для использования состояние. Это особенно актуально для тестирования конфигурации.
9. Повторяемый и самостоятельный
Тестовый пример должен каждый раз давать одни и те же результаты, независимо от того, кто его тестирует.
10. Пэр Revвид.
После создания тестовых примеров попросите их просмотреть своих коллег. Ваши коллеги могут обнаружить дефекты в вашем тестовом примере, которые вы можете легко пропустить.
При составлении тестового примера необходимо включить следующую информацию
- Описание того, какое требование тестируется
- Объяснение того, как будет тестироваться система.
- Настройка теста, такая как версия тестируемого приложения, программное обеспечение, файлы данных, операционная система, оборудование, безопасный доступ, физическая или логическая дата, время суток, предварительные условия, такие как другие тесты, и любая другая информация о настройке, относящаяся к тестируемым требованиям.
- Вклады и результаты или действия и ожидаемые результаты
- Любые доказательства или приложения
- Используйте активный регистр
- Тестовый пример не должен содержать более 15 шагов.
- Сценарий автоматического тестирования сопровождается комментариями с указанием входных данных, цели и ожидаемых результатов.
- Установка предлагает альтернативу предварительным тестам.
- При других тестах это должен быть неправильный порядок бизнес-сценария.
Инструменты управления тестовым набором
Инструменты управления тестированием — это инструменты автоматизации, которые помогают управлять тестовыми примерами и поддерживать их. Основные характеристики инструмента управления тестовыми примерами:
- Для документирования тестовых случаев: С помощью инструментов вы можете ускорить создание тестовых примеров с использованием шаблонов.
- Выполните тестовый пример и запишите результаты: Тестовый пример можно выполнить с помощью инструментов, а полученные результаты можно легко записать.
- Автоматизируйте отслеживание дефектов: Неудачные тесты автоматически связываются с системой отслеживания ошибок, которая, в свою очередь, может быть назначена разработчикам и отслеживаться с помощью уведомлений по электронной почте.
- прослеживаемости: Требования, тестовые примеры и выполнение тестовых примеров связаны между собой посредством инструментов, и каждый случай можно отследить друг от друга для проверки покрытия тестами.
- Защита тестовых случаев: Тестовые случаи должны быть многоразовыми и должны быть защищены от потери или повреждения из-за плохого контроля версий. Инструменты управления тестовыми примерами предлагают такие функции, как
- Соглашения об именах и нумерации
- Versioning
- Хранилище только для чтения
- Контролируемый доступ
- Внешнее резервное копирование
Популярные инструменты управления тестированием: Центр качества и JIRA
Формат стандартных тестовых примеров
Ниже приведен формат стандартного примера тестового случая входа в систему.
Идентификатор тестового случая | Тестовый кейс Descriptион | Шаги тестирования | Тестовые данные | Ожидаемые результаты | Фактические результаты | Пройдено / Не сдано |
---|---|---|---|---|---|---|
TU01 | Проверьте вход клиента с действительными данными |
|
Идентификатор пользователя = guru99 Пароль = pass99 | Пользователь должен войти в приложение | Как и ожидалось | Проходить |
TU02 | Проверьте вход клиента с неверными данными |
|
Идентификатор пользователя = guru99 Пароль = glass99 | Пользователь не должен входить в приложение | Как и ожидалось | Проходить |
Вся эта таблица может быть создана в Word, Excel или любом другом Инструмент управления тестированием. Это все, что касается разработки тест-кейсов.
Шаблон тестового примера
- Обратите внимание, что используемый шаблон будет варьироваться от проекта к проекту. Прочитай это учебник изучить шаблон тестового примера с объяснением важных полей
Загрузите приведенный выше шаблон тестового примера Excel (.xls).