В этой статье мы подробно рассмотрим виды автоматизированного тестирования (АТ), а также разберем некоторые фреймворки автоматизации.
Содержание
- Виды АТ в зависимости от вида тестирования
- Виды АТ в зависимости от фазы тестирования
- Виды АТ в зависимости от видов тестов
- Фреймворки автоматизации
- Инструменты автоматизации
- Заблуждения относительно автоматизации тестирования
- Заключение
Виды АТ в зависимости от вида тестирования
Функциональные тесты
Функциональные тесты пишутся для проверки бизнес-логики приложения. Автоматизация этих тестов означает написание скриптов для проверки функционала приложения.
Нефункциональные тесты
Нефункциональные тесты определяют некоммерческие требования к приложению. Это требования, связанные с производительностью, безопасностью, базами данных и т.д. Эти тесты могут оставаться неизменными или масштабироваться в зависимости от характеристик программного обеспечения.
Подпишитесь на наш ТЕЛЕГРАМ КАНАЛ ПО АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ
Виды АТ в зависимости от фазы тестирования
Модульные тесты
Эти тесты выполняются во время или же после завершения разработки и до передачи приложения на проверку тестировщикам.
Тесты API
API-тесты выполняются на этапе интеграции. Они могут выполняться и командой разработчиков, и тестировщиками. API-тесты проводятся до или после разработки пользовательского интерфейса приложения. Основная цель этих тестов – проверить работу приложения посредством запросов и ответов.
UI-тесты
Тесты, основанные на пользовательском интерфейсе (UI), проверяют функциональность и бизнес-логику приложения через его интерфейс.
Виды АТ в зависимости от видов тестов
Юнит-тесты
Юнит-тесты создаются для проверки кода приложения и обычно встроены в сам код. Они направлены на стандарты написания кода, например, на способ реализации методов и функций.
Эти тесты чаще всего пишут сами разработчики, однако в современном мире их написание может быть поручено и тестировщикам, в том числе автоматизаторам.
Выполнение этих тестов и отсутствие в них ошибок означает, что ваш код будет компилироваться и работать без каких-либо проблем. Эти тесты обычно направлены не на функциональные аспекты приложения, а на сам код. Их автоматизация позволяет разработчику запускать тесты по мере необходимости.
Smoke-тесты
Дымовое тестирование проводится, чтобы убедиться, что приложение продолжает функционировать после завершения сборки.
Это небольшой набор тестов, которые будут выполняться много раз, поэтому имеет смысл их автоматизировать. Эти тесты обычно носят функциональный характер, и в зависимости от типа приложения для них необходимо подобрать соответствующий инструмент.
API-тесты
При тестировании API тестировщики проверяют бизнес-логику приложения, задавая различные комбинации запросов и ответов для разных API. Тесты API также могут быть выполнены в рамках интеграционного тестирования.
Интеграционные тесты
Интеграционный тест, как следует из самого названия, это проверка функциональности приложения при интеграции всех модулей. Такое тестирование может быть выполнено через API или через пользовательский интерфейс приложения.
UI-тесты
UI-тесты проводятся на уровне пользовательского интерфейса или фронтенда приложения. Они могут быть направлены на проверку функциональности или просто на тестирование элементов пользовательского интерфейса.
Автоматизация UI-тестов для проверки функциональности – обычная практика. Однако автоматизация проверки элементов графического пользовательского интерфейса является сложной задачей.
Регрессионные тесты
Одними из наиболее часто автоматизируемых тестов являются регрессионные. Это тесты, которые выполняются в конце тестирования нового модуля, чтобы убедиться, что он не повлиял на существующие модули.
Регрессионные тесты повторяются после каждой новой итерации тестирования. Основные тес-кейсы остаются неизменными, обычно с несколькими новыми дополнениями после новой итерации. Все команды тестирования стремятся автоматизировать этот набор тестов, так как он часто запускается.
Тесты безопасности
Тестирование безопасности может быть как функциональным, так и нефункциональным. Оно включает в себя проверку приложения на уязвимости. Функциональные тесты будут состоять из тестов, связанных, например, с авторизацией, в то время как нефункциональные тесты могут проверять систему на устойчивость к SQL-инъекциям, межсайтовому скриптингу и т.д.
Тесты производительности
Тесты производительности – это нефункциональные тесты, которые направлены на проверку работы системы под высокими и стрессовыми нагрузками, а также проверку масштабируемости приложения.
Приемочные тесты
Приемочные тесты относятся к функциональным тестам. Обычно они позволяют убедиться, что критерии приемки, заданные клиентом, были выполнены.
Как только вы определили тесты, которые вы хотите автоматизировать, исходя из вышеприведенной классификации, вам необходимо разработать логику таким образом, чтобы эти тесты выполнялись без проблем и с минимальным ручным вмешательством. Именно здесь на помощь приходят фреймворки: они позволяют превратить набор ручных тестов в набор автоматизированных, предоставляя соответствующий дизайн и инструменты.
А теперь давайте рассмотрим три основных вида автоматизированного тестирования:
- Юнит-тестирование
- API-тестирование
- Тестирование графического интерфейса
1. Автоматизированные модульные тесты
Автоматизированные модульные тесты пишутся для тестирования на уровне кода. В них выявляются ошибки в функциях, методах и процедурах, написанных разработчиками.
Некоторые компании просят разработчиков проводить модульное тестирование самостоятельно, другие нанимают специалистов по автоматизации тестирования.
Благодаря автоматизации модульных тестов они запускаются при каждой компиляции кода и сообщают нам о том, правильно ли работает код приложения. Если какой-либо модульный тест проваливается, это означает, что в коде есть ошибка.
Одними из самых популярных инструментов для модульного тестирования являются NUnit и JUnit. Microsoft также предоставляет свой собственный фреймворк под названием MSTest.
2. Автоматизированные тесты API
API позволяет программному обеспечению общаться с другими приложениями. Как и любое другое ПО, API необходимо тестировать. В этом виде тестирования графический интерфейс обычно не задействован.
Обычно мы тестируем функциональность, соответствие приложения требованиям и вопросы безопасности. В веб-приложениях мы можем тестировать запросы и ответы нашего приложения, выясняя, являются ли они безопасными и зашифрованными.
Наиболее популярным инструментом для тестирования API является SOAPUI, который имеет как бесплатную, так и платную версии. Существуют и другие инструменты, которые вы можете использовать в соответствии с вашими потребностями.
3. Автоматизированные UI-тесты
Этот вид автоматизированного тестирования является самой сложной формой автоматизации, поскольку графические интерфейсы сильно подвержены изменениям.
Но этот вид тестирования наиболее близок к тому, что пользователи будут делать с нашим приложением. Поскольку пользователь будет использовать мышь и клавиатуру для взаимодействия с приложением, автоматизированные тесты GUI должны имитировать такое же поведение.
Этот вид тестирования может использоваться во многих сценариях, таких как регрессионное тестирование или заполнение форм, что занимает много времени.
Наиболее популярными инструментами для тестирования GUI являются Micro Focus Unified Functional Testing (UFT), Selenium, Test Complete и Microsoft Coded UI (который является частью Visual Studio Ultimate и Premium Editions).
Фреймворки автоматизации
Некоторые широко используемые фреймворки автоматизации:
- Linear
- Keyword Driven
- Data Driven
- Page Object Model
- Modular
Как вы видите, первый шаг в процессе автоматизации – определить вид автоматизации, затем вы можете выбрать фреймворк и инструменты, которые подходят для ваших целей.
Инструменты автоматизации
В зависимости от вида тестирования, можно использовать следующие инструменты автоматизации:
- Selenium. Очень мощный инструмент для тестирования веб-приложений. Обеспечивает поддержку нескольких браузеров.
- Junit и Nunit. Инструменты, которые в основном используются разработчиками для модульного тестирования.
- Sikuli. Инструмент с открытым исходным кодом для тестирования графического интерфейса.
- Soap UI. Инструмент для тестирования API.
- Rest Assured. Библиотека для создания фреймворка для тестирования API.
- Appium. Инструмент, поддерживающий тестирование нативных приложений, гибридное тестирование и тестирование мобильных приложений.
- Jmeter. Используется для тестирования производительности.
- TestNG. Вообще это не инструмент автоматизации, однако TestNG обеспечивает отличную поддержку фреймворков автоматизации, построенных на основе Selenium, Appium, Rest Assured и т.д.
Заблуждения относительно автоматизации
Не все правильно понимают суть и цель автоматизации тестирования.
Заблуждение №1. Автоматизация заменяет ручных тестировщиков
Автоматизация тестирования предназначена для того, чтобы помочь тестировщикам проводить тестирование быстрее и надежнее. Она никогда не сможет заменить человека.
Думайте об автоматизации тестирования как об автомобиле. Если вы идете пешком, вам потребуется около 20 минут, чтобы добраться до дома. Но если вы воспользуетесь автомобилем, то доберетесь за две минуты. Водителем автомобиля по-прежнему являетесь вы, человек, но автомобиль помогает вам быстрее достичь цели. Кроме того, большая часть вашей энергии сохраняется, поскольку вы не ходили пешком. Эту энергию вы можете использовать для выполнения более важных дел.
То же самое происходит и с автоматизацией тестирования. Она позволяет быстро запускать большинство повторяющихся, длинных и скучных тестов и экономит ваше время и силы.
Как сказал Джеймс Бах, “Инструменты не тестируют. Тестируют только люди. Инструменты лишь выполняют действия, которые помогают людям тестировать”.
Инструменты могут выполнять клики по объектам, но где именно кликать всегда будет определять ручной тестировщик.
Заблуждение №2. Все может быть автоматизировано
Если вы попытаетесь автоматизировать 100% ваших тест-кейсов, возможно, вам это удастся, но если все будет автоматизировано, то что тогда будет делать ручной тестировщик?
На самом деле вы не можете автоматизировать все ваши тест-кейсы. Мы, как тестировщики, считаем, что ни одно приложение не может быть протестировано на 100%. Всегда будут сценарии, которые мы пропустим. Всегда будут ошибки, которые появятся только тогда, когда ваше приложение будет использоваться клиентами.
Если приложение не может быть протестировано на 100%, то как вы можете обещать 100% автоматизацию?
Кроме того, очень мала вероятность того, что вы сможете автоматизировать все существующие тест-кейсы. Всегда есть сценарии, которые сложно автоматизировать и проще сделать вручную.
Например, один пользователь вводит данные, второй пользователь отправляет данные, третий пользователь просматривает данные, а четвертому пользователю запрещено просматривать данные. Эти сценарии можно автоматизировать, но это займет много времени и сил. Таким образом будет проще, если вы будете делать это вручную.
Вернемся к аналогии с автомобилем. Мы используем машины для поездок на длинные расстояния, но по пути нас подстерегает много неприятных вещей: расход топлива, проблемы с парковочными местами, плата за парковку и много другой головной боли. В некоторых случаях мы просто идем пешком и добираемся до места назначения.
Таким образом, не стоит пытаться автоматизировать все. Автоматизируйте только те сценарии, которые важны, и те, которые займут много времени для выполнения вручную.
Заблуждение №3. Автоматизация – это только запись и воспроизведение действий
Автоматизация не ограничивается только записью и воспроизведением действий. Создатели инструментов автоматизации могут заявлять, что для автоматизации тест-кейсов достаточно записать и воспроизвести шаги при помощи их инструмента. Но на самом деле автоматизация включает в себя гораздо больше.
Настоящие инженеры автоматизации обычно не полагаются исключительно на запись и воспроизведение. Запись и воспроизведение могут использоваться лишь для понимания того, как инструмент создает скрипт для наших действий.
Для создания автоматизированных тестов мы всегда используем программирование, поэтому тестировщики-автоматизаторы должны иметь навыки написания кода. Не отчаивайтесь, если у вас таких навыков нет. Как и все остальное, программирование можно освоить с помощью практики и усердия.
Есть люди, которые даже без технического образования научились программировать и теперь являются отличными инженерами по автоматизации. В Microsoft нанимают тестировщиков, которые умеют программировать. Их называют SDET (инженеры по разработке программного обеспечения для тестирования). Первая строка описания вакансии гласит: “SDET’ы пишут много кода…”.
Научитесь программировать, не убегайте от этого. Умение писать код сделает из вас замечательного тестировщика.
Заключение
Надеемся, эта статья помогла вам прояснить некоторые понятия, связанные с автоматизацией тестирования.
Мы рассмотрели различные виды автоматизации тестирования и их классификации. Мы также перечислили различные инструменты, которые могут быть использованы для разных видов автоматизированного тестирования.
Перевод статьи «Types Of Automation Testing And Some Misconceptions».