Написание автоматизированных скриптов, безусловно, важно. Но, помимо этого, нужно продумать, в каких условиях будет проходить выполнение автотестов, а также не забыть о емкой отчетности.
Планирование выполнения автотестов
Самое важное в плане выполнения скриптов – это то, что он должен быть создан до создания самих скриптов.
Подпишитесь на наш ТЕЛЕГРАМ КАНАЛ ПО АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ
Допустим, вы тестируете веб-приложение. Вам нужно создать несколько скриптов для проверки функции входа на сайт. На первый взгляд кажется, что создать 8-10 скриптов (то есть автоматизированных тест-кейсов) достаточно просто. Но как только вы попытаетесь выполнить эти скрипты, вы столкнетесь со многими трудностями. Поэтому перед началом создания скриптов лучше задаться следующими вопросами.
Вопрос 1. Какова среда выполнения?
На самом деле это самый важный вопрос. Выполнение автотестов всегда происходит в какой-то среде, и нам нужно знать, в какой именно.
Например, мы тестируем веб-приложение, которое размещено в локальной среде. Мы создаем тест-кейсы, исходя из этого. Но если в будущем планируется разместить этот сайт на сервере для показа в Интернете, мы должны знать об этом заранее. Благодаря этому мы сможем сохранить многие значения за пределами нашего скрипта, чтобы легко изменить их в дальнейшем.
Речь идет об URL сайта, именах пользователей, паролях, электронной почте и многих других значениях, которые могут меняться при смене сервера. Мы будем хранить эти переменные вне нашего скрипта (в файле excel, базе данных или файле настроек конфигурации), чтобы их можно было легко изменить без необходимости модифицировать наш скрипт.
Далее, нужно определиться, где будут выполняться наши тесты. На виртуальной машине (VM) или на физической? Если на виртуальной, то сколько машин вам понадобится, какой объем оперативной памяти должен быть у каждой, какие требования к процессору? Все это требует ответа.
Также нужно подумать, возможно ли выполнение автотестов без установки платного ПО на этих виртуалках. Потому что установка такого ПО означает покупку еще одной лицензии на эту программу, что будет очень дорого.
Для этой цели некоторые программы предоставляют урезанные и менее дорогие версии, которые используются только для выполнения автоматизированных тест-кейсов. Например, MS Coded UI предоставляет “MS Test Agent”, а Test Complete – “TestExecute”.
Преимущество использования виртуальной машины заключается в том, что вы можете начать выполнение автотестов, свернуть виртуальную машину и продолжить выполнять другую работу на физической машине. Таким образом, пока выполняются одни скрипты, вы можете создавать другие.
Третий момент, связанный с окружением, заключается в том, в скольких браузерах вы собираетесь запускать выполнение автотестов? Если нам нужно выполнять скрипты в Chrome, Firefox и IE, мы убедимся, что локаторы, которые мы используем для идентификации элементов, должны успешно определяться во всех трех браузерах. Если мы используем локаторы CSS, мы должны проследить, во всех ли браузерах поддерживаются эти атрибуты CSS, чтобы тесты не падали впоследствии.
Вопрос 2. Когда и кем будут выполняться эти тест-кейсы?
На вопрос “Когда”, кажется, легко ответить: “При каждой сборке”. Но цель этого вопроса была не в этом. В настоящее время компании используют непрерывную интеграцию.
Что такое непрерывная интеграция? Простыми словами можно сказать, что как только разработчик проверяет свой код, выполняется процедура, которая интегрирует все части приложения и автоматически выпускает билд. В некоторых случаях этот билд будет развернут автоматически и так же автоматически протестирован скриптами.
Вопрос в том, будут ли наши автоматизированные скрипты частью непрерывной интеграции. Если да, то мы должны убедиться, что наши скрипты могут правильно интегрироваться с CI-серверами, такими как Jenkins, MS Build, Hudson и т.д.
Некоторые компании используют ночные билды. В таких случаях мы должны убедиться, что наши скрипты могут быть как запущены, так и выполняться автоматически, без участия человека.
Некоторые компании не используют сервер непрерывной интеграции (или билд-сервер). Они вручную выпускают билд, после чего мы устанавливаем программное обеспечение в нашу систему и выполняем автоматизированный тест. В этом сценарии иногда автотесты выполняются командой автоматизации.
В некоторых компаниях выполнение автотестов доверяют ручным тестировщикам или специально нанятым специалистам. Все зависит от масштаба приложения и количества сред. Если количество сред высоко, я рекомендую привлечь дополнительных людей.
Вопрос 3. Следует ли останавливать выполнение автотестов при первом сбое или продолжать их выполнение?
Некоторые приложения таковы, что их выполнение сильно зависит от предыдущих действий.
Допустим, вы тестируете модуль расчета заработной платы из ERP-приложения. Тесты таковы, что в первом тест-кейсе вы должны создать сотрудника в базе данных. В следующем тест-кейсе вы должны распечатать чек на зарплату для этого сотрудника.
Теперь рассмотрим следующую ситуацию. Если сотрудник не создан (из-за ошибки в приложении), вы не можете выдать ему зарплату. В подобных сценариях, если первый тест-кейс провален, нет смысла запускать следующий.
Поэтому перед разработкой тест-кейсов мы должны увидеть зависимость между ними. Если тест-кейсы зависят друг от друга, их нужно упорядочить соответствующим образом. В таком случае при первом сбое выполнение останавливается и мы сообщаем об ошибке.
Некоторые приложения таковы, что у них есть базовое состояние.
Например, страница панели инструментов, с которой мы всегда начинаем, чтобы что-то открыть. Эта страница станет базовым состоянием в нашем тест-кейсе. Каждый тест-кейс будет начинаться с этого базового состояния и заканчиваться в этом базовом состоянии. Таким образом, при сбое одного тест-кейса новый тест-кейс может быть запущен без проблем.
В подобных сценариях мы не останавливаем выполнение при сбоях. Если какой-либо тест не прошел, мы помечаем его как неудачный, возвращаемся в базовое состояние и продолжаем выполнение следующего теста (это также называется сценарием восстановления). По окончании тестирования мы получаем отчет о том, сколько автотестов потерпели неудачу и сколько из них прошли. Мы отлаживаем неудачные тест-кейсы, выявляем ошибки и сообщаем о них.
Для успешной разработки скрипта и его непрерывного выполнения нужно задать все вышеперечисленные вопросы и получить на них четкие ответы. Простой автоматизированный скрипт входа в систему легко создать, но его выполнение будет намного сложнее, если мы не учтем вышеуказанные моментов.
Отчетность
Переходим к советам по эффективному составлению отчетов о выполнении тестов.
Если скрипты отличные, а отчетность хромает, то найти ошибки с помощью автоматизации будет сложно.
Четкие и полные отчеты помогают нам сделать вывод после завершения выполнения скриптов.
Форматы отчетов сильно отличаются в каждом инструменте, но я постараюсь перечислить наиболее важные аспекты, которые должны присутствовать в отчете.
1. Отчет для набора тест-кейсов
Если несколько тест-кейсов включены в набор, и этот набор выполняется, то в отчет необходимо включить следующие важные моменты:
- Общее количество автотестов
- Список всех автотестов в табличной форме
- Результат теста (пройден или не пройден, перед каждым тест-кейсом)
- Продолжительность (перед каждым тест-кейсом)
- Имя машины / среды (напротив каждого тест-кейса).
2. Подробный отчет для отдельного тест-кейса
Когда мы нажимаем на любой тест-кейс, чтобы увидеть подробный отчет, мы должны получить следующую информацию:
- Название тест-кейса
- Идентификатор этого тест-кейса, если он связан с хранилищем тест-кейсов
- Продолжительность тест-кейса (мин: сс)
- Статус (пройден или не пройден)
- Снимки экрана (только при неудаче или на каждом шаге)
- Где произошел сбой (точный номер строки в скрипте)
- Любые другие полезные логи, которые мы написали в скрипте для отображения в отчете
Примеры
Пример отчета из набора тест-кейсов (Selenium C# Web Driver и MSTest):
Пример подробного отчета для упавшего автотеста:
Некоторые другие моменты, о которых следует помнить
- Продолжительность – важный фактор. Если выполнение тестовых скриптов занимает много времени, их необходимо тщательно отладить и оптимизировать для ускорения работы. Чем быстрее завершается автотест, тем он лучше.
- Снимок экрана следует делать только в случае отказа, чтобы ускорить выполнение.
- Отчет должен сохраняться в удобном формате, например, PDF или Excel.
- Пользовательские сообщения на контрольных точках автотестов должны быть написаны так, чтобы в случае падения теста мы понимали, что пошло не так, просто посмотрев отчет.
- Хорошей практикой является запись в лог строки текста перед каждым действием. Этот лог будет отображаться в отчете, и неспециалист будет знать, на каком действии автотест потерпел неудачу.
Заключение
Непрерывное выполнение автоматизированных тест-кейсов и правильная отчетность являются одними из важных факторов в автоматизации тестирования.
Я постарался объяснить эти факторы простым языком на собственном опыте. Мы сталкивались со многими трудностями, когда у нас не было плана выполнения автотестов. Но в наших следующих проектах мы разработали такой план, и это уменьшило количество наших проблем.
Перевод статьи «How to Have Seamless Script Execution Planning and Reporting for Success of an Automation Project».