Как писать тест-кейсы для автоматизации?

Содержание

1. Как писать тест-кейсы для упрощения автоматизации тестирования
2. Что нужно сделать перед написанием автоматизированных тест-кейсов
3. Как создать автоматизированный тест-кейс
4. Лучшие практики создания тес-кейсов для автоматизации тестирования
5. Итоги

Автоматизированные тест-кейсы необходимы для проверки функциональности и надежности ПО без ручного вмешательства. Ниже приведен список типичных примеров автоматизированных тест-кейсов:

1. Модульный тест проверяет правильность поведения отдельных блоков или компонентов программного обеспечения. Например, модульный тест может проверить, что функция правильно складывает два числа.
2. Интеграционный тест оценивает взаимодействие между различными частями программного обеспечения, чтобы убедиться в слаженности их совместной работы. Примером может служить тестирование процесса регистрации пользователя через фронтенд приложения.
3. Функциональный тест сосредоточен на бизнес-требованиях приложения. Это может быть тестирование полного процесса отправки формы в веб-приложении. Таким образом мы проверяем, что все шаги от ввода данных до получения подтверждения работают правильно.
4. Тест производительности оценивает скорость, отзывчивость и стабильность работы приложения при определенной нагрузке. Примером может служить имитация одновременного доступа нескольких пользователей к веб-сервису.
5. Тест на безопасность выявляет уязвимости в программном обеспечении, а также проверяет защиту от атак и несанкционированного доступа. Сюда можно отнести тестирование на уязвимость к SQL-инъекциям в веб-приложении.
6. Тест UI/UX проверяет, что пользовательский интерфейс на разных устройствах и в разных браузерах выглядит и функционирует так, как ожидается. Например, такое тестирование позволяет убедиться, что веб-страница отображается правильно и все кнопки работают как в десктопных, так и в мобильных браузерах.

БЕСПЛАТНО СКАЧАТЬ КНИГИ в телеграм канале "Библиотека тестировщика"

Как писать тест-кейсы для упрощения автоматизации тестирования?

“Разработчики программного обеспечения ленивы, и это хорошо!!!” Эта фраза обычно используется для того, чтобы шокировать или разбудить аудиторию на конференциях и прочих мероприятиях. Тем не менее, заявление о лености разработчиков совершенно правдиво. Если бы не эта лень, или, выражаясь более профессионально, стремление к оптимизации, прогресс в мире ИТ был бы гораздо медленнее.

Желание и способность автоматизировать повторяющиеся задачи – одна из основ программирования. Если вам нужно создать сотню одинаковых объектов или сущностей в вашем приложении, станете ли вы делать это вручную? Скорее всего вы предпочтете создать скрипт, который сделает это за вас. То же самое происходит и с созданием тестов. И именно здесь на помощь приходит автоматизация тестирования.

Автоматизация тестирования – это практика использования специальных инструментов и скриптов для автоматизации процесса тестирования конкретного приложения.

При этом создание правильных скриптов и кейсов имеет решающее значение для успеха автоматизации. Но прежде чем перейти к этой теме, давайте на мгновение остановимся на том, зачем вообще автоматизировать наши тесты.

Итак, автоматизация в тестировании:

• Экономит время и деньги. Вы можете запускать тестовый сценарий в любое время, практически одним нажатием кнопки, что сокращает количество человеко-часов, необходимых для тестирования.
• Делает членов вашей команды счастливыми, ведь им не приходится снова и снова выполнять одни и те же задачи.
• Обеспечивает безопасность. Автоматизированные тесты менее подвержены ошибкам, чем ручные.
• Увеличивает тестовое покрытие. Если вы сможете автоматизировать наиболее приоритетные тест-кейсы, то у вас освободится время на ручное тестирование менее распространенных сценариев.

Что нужно сделать перед написанием автоматизированных тест-кейсов

Тест-кейсы – это не обособленная сущность. Они основываются на тестовом сценарии. Чтобы понять, что именно нужно тестировать, сначала нужно создать план.

Тестовый сценарий – это описание модели поведения пользователя. Обычно такие действия затрагивают сразу несколько функциональных возможностей. С точки зрения управления тестированием это означает, что один тестовый сценарий предполагает тестирование нескольких частей вашего программного обеспечения.

После определения тестовых сценариев нужно решить, сколько тестов следует автоматизировать. Почему бы не автоматизировать их все? Несмотря на то, что автоматизация всех тестов звучит эффективно и разумно, это совсем не так. Писать тест-кейс для автоматизации того, что будет происходить только один раз за весь процесс тестирования, – пустая трата времени.

Автоматизация будет наиболее эффективной в следующих ситуациях:

• Функциональность является критически важной с точки зрения бизнеса
• Функциональность часто используется
• Для теста требуется несколько наборов данных
• Тест подвержен влиянию человеческого фактора
• Выполнение теста вручную сложно или даже невозможно
• Тест часто повторяется и выполняется на нескольких сборках

Еще один аспект, который необходимо учитывать, – инструмент автоматизации тестирования. Важно понимать его плюсы, минусы и ограничения. Можно с уверенностью предположить, что вы будете использовать один и тот же инструмент на протяжении всего процесса тестирования. Таким образом, вы готовите кейсы для конкретного программного обеспечения.

Как создать автоматизированный тест-кейс?

Создание тест-кейсов для автоматизации немого отличается от тест-кейсов для ручного тестирования.

Тест-кейс для ручного тестирования создается человеком для человека. Каждый такой тест-кейс должен содержать некоторые элементы, используемые для отчетности или поддержания порядка при выполнении теста. Например, заголовок или описание.

Тест-кейсы для автоматизации тестирования также должны содержать несколько обязательных элементов:

• Предварительные условия. Необходимо описать, каковы требования к входу или в каком состоянии должно находиться приложение. Например, какой браузер вы используете, нужно ли вам регистрироваться или просто зайти на определенную страницу.
• Шаги тестирования. Инструкция о том, какие действия необходимы для достижения желаемого состояния приложения, а также необходимые тестовые данные.
• Синхронизация и ожидания. В “старые добрые времена” перед выполнением каждого этапа теста нужно было определить, когда и сколько времени необходимо приложению для выполнения его работы. Если тесты выполнялись быстрее, чем приложение, результаты получались очень неточными. В настоящее время современным инструментам автоматизации не нужна синхронизация и задержка. Они реагируют на то, что происходит в приложении. Вы определяете, какие элементы должны быть видны, и если они появляются, тест продолжается.
• Комментарии. Обеспечивают передачу знаний, описывая подход к текущему тестированию программного обеспечения.
• Отладочная информация. Нужна для выявления и устранения проблем и ошибок, возникающих во время выполнения автоматизированных тестов. Это могут быть логи или сообщения об ошибках в вашем инструменте автоматизации тестирования. Постарайтесь как можно подробнее описать ошибку. Это поможет разработчикам максимально быстро понять проблему.
• Выходные данные. Используются для сообщения о результатах каждого теста. Сюда можно поместить анекдотичное сообщение “test failed successfully” для негативного теста.

Обратите внимание на важную разницу между двумя последними пунктами. Отладочная информация записывается во время выполнения теста при возникновении ошибки. Выходные данные записываются в лог после каждого завершенного теста.

Лучшие практики создания тест-кейсов для автоматизации тестирования

Составляя тест-кейсы для автоматизации, стоит придерживаться best practices:

1. Принцип KISS (“будь проще”) действует и здесь. Создавайте свои тест-кейсы так, чтобы их понимали все участники процесса. Вы должны быть уверены, что то, что вы пишете, и то, как вы пишете, понятно команде тестировщиков. Если у вас есть время и ресурсы, создайте руководство или инструкцию по написанию тест-кейсов. Что туда включить? Глоссарий или список сокращений, которые вы будете использовать в своих кейсах.
2. Начните со сценария. Хорошие тестовые сценарии помогут вам создать хорошие тест-кейсы. Вы сможете выбрать нужный функционал, правильный порядок и т. д. Окупаемость инвестиций в автоматизацию тестирования (ROI) начинается со сценария. Если на этом этапе вы не приложите усилия, вам будет сложно составить правильные тест-кейсы.
3. Общее и подробное – канат и перо. Это приходит с опытом. Достижение идеального баланса между общим и подробным описанием – это как хождение по натянутому канату с перышком. Как создатель тест-кейса вы должны чувствовать и понимать, где написать общие тест-кейсы, а где подробные. Нет смысла ограничивать гибкость тестировщиков. Кроме того, написание общих кейсов – лучший способ повысить адаптивность к изменениям в программном обеспечении. Например, если вы напишете “навести мышь в правый верхний угол на кнопку входа”, а в будущем кнопка входа будет перемещена влево, тест-кейс нужно будет изменить. В то время как “навести мышь на кнопку входа” гораздо более универсален.
4. Поощряйте исследования. Начнем с шокирующего факта: никто не совершенен! Команды обычно создают тест-кейсы на скорую руку и часто работают по шаблонам или исходя из опыта. Таким образом, тестовое покрытие приложения никогда не достигает 100%. И никогда не достигнет. Предположите, что у вас неполное покрытие тестами, и начните исследование. Тест-кейсы служат для проверки ошибок, которые, как вы предполагали, могут возникнуть. А как насчет тех, которые вылетели у вас из головы во время разработки? Убедитесь, что ваш сценарий и план автоматизации достаточно гибкие для добавления/изменения тест-кейсов.
5. Независимость! Важно разрабатывать тест-кейсы независимыми друг от друга. Если для корректной работы теста A требуется тест B, возрастает риск получения ложных результатов. Кроме того, так возрастает время тестирования, поскольку связанные кейсы не смогут запускаться параллельно.

Примеры автоматизированных тест-кейсов

Попробуйте прочитать следующий абзац так, будто вам что-то предлагают в “телемагазине”. Вперед!

У нас есть эксклюзивное предложение для наших самых преданных читателей! Мы предоставим вам примеры тест-кейсов не для одного, не для двух, а для трех – да, вы правильно прочитали – ТРЕХ! видов тестирования.

Весело, правда? 🙂

Мы и правда подготовили для вас три тест-кейса.

1. Функциональное тестирование

Как вы помните, функциональное тестирование проверяет, правильно ли работает определенный функционал.

Предусловия. Пользователь не вошел в систему. В приложении открыта домашняя страница.

Шаги тестирования. Нажмите кнопку входа в систему. Дождитесь появления формы. Введите “test_user” в качестве имени пользователя и “test_pa$$word” в качестве пароля. Нажмите кнопку “Войти”.

Комментарии. Это базовый тест для аутентификации пользователя.

Отладочная информация. Если пользователь не вошел в систему, запишите в логи “Не удалось выполнить аутентификацию пользователя”. Если в форме входа в систему были какие-либо подсказки, тоже отобразите эту информацию в логах.

Выходные данные. Для пройденного теста выведите сообщение: “Аутентификация пользователя успешна”.

2. Интеграционное тестирование

Если говорить коротко, то интеграционное тестирование направлено на проверку того, способны ли различные части программного обеспечения или любые соединения с внешними сервисами правильно взаимодействовать.

Предусловия. Пользователь не вошел в систему. В приложении открыта домашняя страница.

Шаги тестирования. Нажмите кнопку входа в систему. После появления формы нажмите кнопку “Войти через социальную сеть”. Проверьте URL для /profile и проверьте содержимое для “Hello test_user”.

Комментарии. Проверка, перешел ли пользователь на правильный URL-адрес после аутентификации через социальную сеть.

Отладочная информация. Записывайте в лог соответствующую информацию при возникновении любого из двух условий: “Неправильный URL”, если пользователь не находится в /profile, и “Неправильное приветствие”, если “Welcome test_user” не отображается.

Выходные данные. Для пройденного теста выведите сообщение: “Переход в профиль успешен”.

3. Регрессионное тестирование

Регрессионное тестирование проверяет, что имплементация нового функционала не ломает старый.

Предусловия. Пользователь не вошел в систему. В приложении открыта домашняя страница.

Шаги тестирования. Нажмите кнопку входа в систему. Дождитесь появления формы. Введите “test_user” в качестве имени пользователя и “test_pa$$word” в качестве пароля. Нажмите кнопку “Войти”. Запускается анимация, а пользователь переходит по URL /profile.

Комментарии. Проверка, видит ли пользователь анимацию перед переходом в профиль и происходит ли затем сам переход. В профиле больше не должно быть приветствия.

Отладочная информация. Записывайте в лог соответствующую информацию при возникновении любого сбоя: “Анимация не видна”, если анимация отсутствует, “Неверный URL”, если пользователь не вошел по URL /profile, “Приветствие видно”, если приветствие “welcome test_user” видно.

Выходные данные. Для пройденного теста выведите сообщение: “Переход в профиль успешен”.

Итоги

Для автоматизированных тестов требуются специальные инструменты. Благодаря им вы сможете быстро запускать тесты, например, после каждой сборки или спринта. Они сокращают время тестирования, а это то время, которое вы можете потратить на написание кода и “более эффективное завершение”полировку” продукта.

Ручные и автоматизированные тест-кейсы имеют некоторые общие элементы, но в автоматизированных обязательно должны быть:

• предусловия
• шаги тестирования
• синхронизация и ожидание
• комментарии
• отладочная информация
• выходные данные

Обязательно ознакомьтесь с лучшими практиками и примерами в нашей статье (это обращение к тем читателям, которые начинают чтение статьи с конца).

Запуск автоматизированных тестов вместо ручных в большинстве случаев является более эффективным. Есть тесты, которые требуют ручного подхода, но это тема для совсем другой статьи.

Перевод статьи «How to Write Automation Test Cases?».