Автоматизация всегда следует за ручным тестированием. Это подразумевает, что тест-кейсы уже написаны, и приложение прошло один или несколько циклов ручного тестирования.
Подпишитесь на наш ТЕЛЕГРАМ КАНАЛ ПО АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ
В таблице приведен пример тест-кейса для ручного тестирования функции авторизации на сайте Gmail.com. Что необходимо сделать, чтобы перевести его в скрипт для автоматизации?
Ниже представлены схема и рекомендации, следуя которым можно выполнить поставленную задачу:
1. Предусловия: Это не что иное, как список действий, которые надо выполнить до начала проверки, и/или инструментов, которые надо использовать. Прописывать предусловия особенно важно в следующих случаях:
- Для запуска теста: В вышеописанном примере с тестированием функции авторизации на сайте нужно, чтобы браузер был доступен и запущен. (Вопрос о доступности имени пользователя и пароля будет рассмотрен чуть позже). Как написать то же самое для автоматизированного теста? Рассмотрим инструмент QTP (QuickTest Professional). В нем есть возможность запустить браузер с помощью оператора, либо через диалоговое окно “Параметры записи и запуска” (Record and Run Settings), где можно задать соответсвующие настройки. Ошибки в указанных параметрах могут являться причиной того, что определенная часть кода будет работать на одной машине и не будет работать на других.
- Для воспроизведения определенного шага: Для выполнения шага 2 необходимо, чтобы шаг 1 был выполнен и завершен. Чтобы сделать это вручную, можно просто подождать, пока выполнение шага завершится и страница загрузится полностью. В автоматизированных тестах для этого используются операторы sync или wait.
Примечание: В случае выполнения одного и того же теста с разными наборами данных, необходимо убедиться что тестируемое приложение возвращается в исходное состояние для начала следующей итерации.
2. Шаги воспроизвдения
Мы можем разделить шаги воспроизведения в ручном тестировании на 3 типа:
- Ввод данных: Здесь задаются некие входные данные для тестируемого приложения.
- Изменение состояния приложения: Это шаги, которые приводят к изменению состояния программы. Например, переход на новую страницу, отображение или редактирование определенного поля и т.д.
- Комбинированные шаги: Как следует из названия, это комбинация двух вышеперечисленных типов. Например, чекбокс, при нажатии на который определенное поле становится активным. В этом случае вводится значение “True” для поля чекбокса, что приводит к изменению состояния тестируемого приложения.
В приведенном выше тестовом примере существуют только шаги воспроизведения 1 и 2 типа.
- Тип 1: шаги 2 и 3
- Тип 2: шаги 1 и 4
Предпосылкой для создания сценария автоматизации с использованием любого инструмента является необходимость потратить некоторое время на анализ как инструмента, так и тестируемого приложения. Например, QTP имеет 3 режима записи, и каждый из них работает по-разному. Если знать, как инструмент идентифицирует объекты, легче решить, какой из режимов записи использовать. Например, при тестировании веб-приложения, в котором QTP легко идентифицирует объекты, можно использовать Normal режим. В противном случае, возможно, придется использовать Analog или Low-level режимы записи.
Шаги автоматизации:
- Этапы ввода данных не сильно отличаются при автоматизированном и ручном тестированиях. Все, что вы делаете, – это вводите данные. Однако поскольку эти шаги будет выполнять машина, необходимо убедиться, что даны верные ссылки на тестируемые поля в приложении. Это означает, что нужно использовать то имя поля, которое указано в коде.
- Изменения состояния приложения / комбинированные шаги: В ручном тестировании выполнение действия (клик или ввод) и верификация изменения происходят одномоментно. Но в сценариях автоматизации это невозможно, поэтому важно убедиться, что в них добавлены отдельные шаги как для самого действия, так и для верификации изменения.
- Отладка кода: Здесь речь идет о поиске ошибок в коде самого теста. Следует чаще использовать функцию MessageBox для вывода сообщений на разных этапах выполнения теста, это упрощает отслеживание и устранение дефектов.
- Операторы вывода необходимы для записи результатов проведенного теста.
3. Верификация и валидация
Без верификации и валидации смысл тестирования теряется. Как правило, необходимо использовать некие контрольные точки в коде (не обязательно встроенные), которые задаются условными и циклическими операторами.
Важный момент: атрибут, на основе которого строится валидация и верификация, не должен быть двусмысленным. Например, при успешной авторизации в систему нужно смотреть на отображение страницы входящих сообщений, а не на количество новых писем, так как это не постоянная величина.
Другими словами, важно выбирать такие контрольные точки (атрибуты), которые будут оставаться неизменными после выполнения определенного набора операций в коде.
4. Тестовые данные
Ниже перечислены некоторые вопросы, касающиеся требований к тестовым данным:
- Где их разместить?
- Следует ли внести их в скрипт?
- Обеспечена ли безопасность хранения данных?
- Можно ли их использовать повторно?
Если посмотреть на вышеописанный тест-кейс авторизации, можно заметить, что наличие таких тестовых данных, как имя пользователя и пароль, является одним из обязательных предварительных условий для запуска теста.
5. Результаты
При ручном тестировании можно поместить результат каждого шага в колонку “Фактический результат”.
Современные средства автоматизации предлагают мощные функции отчетности. Однако в некоторых случаях необходимость адаптировать результаты тестирования сохраняется. Для этого целесообразно включать шаги логирования результатов, чтобы упростить отслеживание хода выполнения теста.
Если используемый вами инструмент не поддерживает функцию логирования результатов, можно завести отдельный Excel файл для каждого теста, куда будут своевременно вноситься комментарии о состоянии выполнения теста.
6. Постусловия
При ручном тестировании в тест-кейсе не всегда прописывается, что нужно закрыть браузер или выйти из тестируемого приложения после завершения теста. Как правило, тестировщик выполняет эти действия без лишних напоминаний. В случае автоматизированного тестирования важно включать дополнительные шаги с обязательными постусловиями в сценарий, как, например, “Закрыть все приложения” или “Очистить память”.
Следуя вышеперечисленным рекомендациям, получилось перевести тест-кейс для ручного тестирования по авторизации на сайте Gmail.com в тестовый сценарий QTP, использующий VB Scripting:
Подробнее по каждому шагу:
Шаг 1: Предусловие: запуск IE с URL-адресом Gmail.com.
Шаг 2 и 7: Оператор sync: он нужен для того, чтобы убедиться, что тестируемое приложение пришло в соответствующее состояние перед выполнением следующего шага.
Шаг 3 и 4: Ввод данных: в этом примере входные данные записаны в скрипте.
Шаг 5: Изменение состояния приложения: данный шаг включает нажатие на кнопку Sign In/Войти.
Шаг 6 и 8: Комментарии
Шаг 9 и 11: Условный оператор: верификация и валидация/контрольная точка. Здесь происходит проверка, был ли вход в систему успешным. В качестве контрольной точки выбрана ссылка на входящие сообщения, которая должна появиться на странице после успешного входа на сайт. Машина будет искать ссылку с внутренним текстом “inbox.*“, и, если она обнаружена, это означает, что авторизация на сайте успешно пройдена.
Шаг 10: Функция MessageBox . Для наглядности.
Шаг 12 и 13: Постусловия: выход из учетной записи и закрытие браузера.
Заключение
Поскольку это статья не о фреймворках, здесь не затронуты вопросы функций, реюзабилити, параметризации и т.д. А что касается создания скриптов для автоматизации, то при наличии хорошо написанного тест-кейса и набора основных рекомендаций, сделать это становится не так сложно.
Перевод статьи «How to Translate Manual Test Cases into Automation Scripts? – A Step by Step Guide with Example».