Automated test script что это
Перейти к содержимому

Automated test script что это

  • автор:

Автоматизация тестирования программ

Автоматизированное тестирование программного обеспечения — основные понятия

Автоматизированное тестирование программного обеспечения (Software Automation Testing) — это процесс верификации программного обеспечения, при котором основные функции и шаги теста, такие как запуск, инициализация, выполнение, анализ и выдача результата, выполняются автоматически при помощи инструментов для автоматизированного тестирования.

Специалист по автоматизированному тестированию программного обеспечения (Software Automation Tester) — это технический специалист (тестировщик или разработчик программного обеспечения), обеспечивающий создание, отладку и поддержку работоспособного состояния тест скриптов, тестовых наборов и инструментов для автоматизированного тестирования.

Инструмент для автоматизированного тестирования (Automation Test Tool) — это программное обеспечение, посредством которого специалист по автоматизированному тестированию осуществляет создание, отладку, выполнение и анализ результатов прогона тест скриптов.

Тест Скрипт (Test Script) — это набор инструкций, для автоматической проверки определенной части программного обеспечения.

Тестовый набор (Test Suite) — это комбинация тест скриптов, для проверки определенной части программного обеспечения, объединенной общей функциональностью или целями, преследуемыми запуском данного набора.

Тесты для запуска (Test Run) — это комбинация тест скриптов или тестовых наборов для последующего совместного запуска (последовательного или параллельного, в зависимости от преследуемых целей и возможностей инструмента для автоматизированного тестирования).

Автоматизация тестирования программных систем

На сегодняшний день мало кто сомневается в целесообразности проведения процесса тестирования разрабатываемых программных продуктов. Целью любого проекта по тестированию является обеспечение качества разрабатываемого продукта. Автоматизация повышает эффективность тестирования и, следовательно, улучшает качество создаваемого программного обеспечения (ПО). Основная задача статьи – создать у читателя достаточно чёткую картину того, что собой представляет автоматизация тестирования.

Основные понятия

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

Тестирование – процесс, содержащий в себе все активности жизненного цикла, как динамические, так и статические, касающиеся планирования, подготовки и оценки программного продукта и связанных с этими результатами работ с целью определения их соответствия описанным требованиям, и демонстрации их пригодности для заявленных целей и определения дефектов;
Автоматизация тестирования – использование программного обеспечения для осуществления или помощи в проведении определенных тестов процессов, например, управление тестированием, проектирование тестов, выполнение тестов и проверка результатов;
Автоматизированное тестирование ПО – процесс тестирования ПО, при котором основные функции и шаги теста, такие как запуск, инициализация, выполнение, анализ и выдача результата производятся автоматически с помощью некого стека технологий, в котором главное место занимает инструмент для автоматизированного тестирования;
Инструмент для автоматизированного тестирования – это ПО, посредством которого специалист по автоматизированному тестированию осуществляет создание, отладку, выполнение и анализ результатов прогона тест-скриптов;
Интерфейс программирования приложений (иногда интерфейс прикладного программирования) (англ. application programming interface, API [эй-пи-ай]) — набор готовых классов, процедур, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) для использования во внешних программных продуктах. Используется программистами для написания всевозможных приложений;
Нагрузочное тестирование – вид тестирования производительности, проводимый с целью оценить поведение компонента или системы под увеличивающейся нагрузкой (число одновременно работающих пользователей и/или число транзакций) для определения максимально допустимого уровня нагрузки для исследуемого компонента или системы;
Регрессионная спираль смерти – данный эффект наступает тогда, когда на тестирование проекта тратится все больше и больше времени, т.к. готовой функциональности в продукте становится все больше и надо постоянно контролировать, что она по-прежнему работает;
Регрессионное тестирование – тестирование уже протестированной программы, проводящееся после модификации для уверенности в том, что процесс модификации не внес или не активизировал ошибки в областях, не подвергавшихся изменениям. Проводится после изменений в коде программного продукта или его окружения;
Тест-скрипт – это набор инструкций, для автоматической проверки определенной части ПО;
Тестовый набор – это комбинация тест-скриптов, для проверки определенной части ПО, объединенной общей функциональностью или целями, преследуемыми запуском данного набора;
Тестовые данные – данные, которые существуют (например, в базе данных) на начало выполнения теста\тест-скрипта и влияют на работу, или же испытывают влияние со стороны тестируемой системы или компонента;
Фреймворк (англ. framework — каркас, структура) — структура программной системы; программное обеспечение, облегчающее разработку и объединение разных компонентов большого программного проекта. (Употребляется также слово «каркас», а некоторые авторы используют его в качестве основного, в том числе не базируясь вообще на англоязычном аналоге);
Функциональное тестирование – тестирование, основанное на анализе спецификации функциональности компонента или системы.

Виды тестирования

Немного разобравшись с основными понятиями, предлагаю вам рассмотреть и основные виды тестирования:
• Первым пунктом в этом списке стоит нагрузочное тестирование. Без автоматизации его выполнение трудно себе представить (программными продуктами имитируется нагрузка следующим образом: подключаются виртуальные пользователи, выполняющие различные скрипты (действия), по различным сценариям.);
• Следом идёт регрессионное тестирование. Ошибки, которые возникли после внесения изменений в программу называют регрессионными ошибками (англ. regression bugs). Выполняется с регулярной частотой, задаваемой в зависимости от многих условий: может проводиться с каждой новой сборкой проекта или с каждой версией для заказчика;
Функциональное тестирование проводится в целях проверки реализуемости функциональных требований, то есть способности ПО в определённых условиях решать задачи, нужные пользователям. (Одна из основных задач автоматизации регрессионного\функционального тестирования заключается в том, чтобы уберечь проект от регрессионной спирали смерти.)

Преимущества и недостатки автоматизированного тестирования

Но всё ли так хорошо и красиво, как описано выше? Для ответа на эти вопросы, предлагаю «взвесить все за и против», чтобы сделать для себя соответствующие выводы.

Преимущества:
• Исключен «человеческий фактор» во время выполнения: тест-скрипт не допустит ошибки по неосторожности;
• Быстрое выполнение;
• Автоматически формируемые и сохраняемые отчёты о результатах тестирования;
• Выполнение в фоне – во время выполнения тестов можно заниматься другими задачами или выполнять тест-скрипты в нерабочее время.

Недостатки:
• Однотипность – все написанные тесты всегда будут выполняться строго по алгоритму, реализованном в них, в то время как тестировщик, выполняя тест вручную, может обратить внимание на некоторые детали и найти дефект. (Например, после очередного обновления проекта на форме операции было добавлено необязательное поле, но разработчик допустил ошибку и формат данных для ввода оказался не верным. Во время функционального\регрессионного тестирования приложения тест-скрипт отработает без ошибок, т.к. в его алгоритме взаимодействие с этим полем не реализовано.);
• Затраты на поддержку – чем чаще изменяется приложение, тем они выше. (В результате доработок конкретный функционал может изменяться, что приведёт к частичной или полной непригодности тест-скриптов. Перед специалистом по автоматизированному тестированию встанет задача привести тест-скрипт(ы) к актуальному состоянию.);
• Большие затраты на разработку тестового каркаса для конкретного проекта (фактически идёт разработка приложения, которое тестирует другое).

Внедрение автоматизированного тестирования

Прежде, чем задумываться о внедрении автоматизации тестирования, необходимо убедиться, что процесс контроля качества на ваших проектах выстроен, документирован и работает как часы. Помните, что внедрение автоматизации – это не дань моде. Это задача, призванная поднять контроль качества на вашем проекте на новый уровень, ввиду чего повышается эффективность тестирования проекта (без дополнительной головной боли).
Вторым шагом будет обращение к специалистам, которые помогут Вам поставить процесс автоматизации на профессиональном уровне и в сжатые сроки. Несомненно, можно пробовать развивать направление собственными силами, но без опытных специалистов этот процесс, вероятно, выльется в существенные сроки, будет проходить методом проб и ошибок, затронет больший бюджет, и, в конечном итоге, вполне может и вовсе отбить у вас всё желание применять автоматизированное тестирование.
При внедрении на проекты автоматизации тестирования «с нуля», в большинстве случаев рекомендуется разработка фрэймворка. Данный подход позволит вашим специалистам самостоятельно дорабатывать фреймворк и развивать покрытие тест-скриптами. На сегодняшний день это наиболее технологически продвинутое решение по соотношению цена / трудозатраты / эффективность.

К особенностям такого фрэймворка можно отнести:
• Максимальная повторная используемость кода: фактически создается API, который обеспечивает управление процессом выполнения;
• Применение методик Data Driven (тестирование по одному и тому же сценарию, проводимое при различных наборах и/или значений исходных данных);
• Все сценарии тестирования (test cases) и пакеты запуска (test suites) также описываются во внешних файлах что позволяет легко управлять параметрами запуска;
• Фреймворк обладает максимальной гибкостью: вы можете легко добавлять, удалять, редактировать существующие сценарии тестирования и пакеты запуска, при этом для данной задачи не требуется дополнительной квалификации, необходимо лишь умение работать с фреймворком;
• В систему легко могут быть добавлены новые операции, или изменены существующие; при этом не потребуется каких-либо сложных действий, необходимо будет только написать новую функцию. Это позволяет легко и безболезненно расширять сам фреймворк;
• Для многих отделов тестирования данное решение может оказаться панацеей, т.к. по результатам разработки фреймворка и проведения краткого обучения работе с ним, требования к квалификации специалистов, покрывающих систему авто тестами, существенно снижается, достаточно навыков работы XML.

Итоги

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

  • automation testing
  • testing

Automated test script что это

Автоматизация тестирования

latest update of the page: 24-04-2023, 13:46 UTC

Присмотреться к чужому опыту

Базовое

  • Написание автоматических тестов для тестирования пользовательского интерфейса десктопных приложений
  • Selenium для всех: как мы учим QA-инженеров работать с автотестами. Примечательно то, что они задумались и даже реализовали какое-никакое автоматическое вычисление какие тесты запускать под выбранную задачу, на основе того какие файлы изменил разраб в репозитории. Т.е. своеобразный impact-analysis в тестировании.
  • Как сократить издержки на автотестах
  • Пожалуй, лучшая архитектура для UI тестов (НТЦ ПРОТЕЙ, 2020). Java.
  • Антипаттерны тестирования ПО (unit-тесты, интеграционные тесты) (2018)

Комплексный подход

  • Что делать, если у вас слишком много автотестов? (Сергей Потанин, Wrike, 2020)
  • Автоматизация End-2-End тестирования комплексной информационной системы. Часть 1. Организационная
  • Автоматизация End-2-End тестирования комплексной информационной системы. Часть 2. Техническая

Интересное

Тестирование в условиях микросервисной архитектуры и Service mesh

  • Реализация Consumer-Driven Contract подхода для тестирования микросервисов (Фрол Крючков, Авито, 2018)
  • Consumer-Driven Contracts глазами разработчика (2019)

Cucumber

  • Руководство: Cucumber + Java (2017)
  • Cucumber 3 + Java (2018)
  • Cucumber Selenium Java Example

Coded UI

  • Time for Coded UI Tests
  • Тестируем UI с помощью Coded UI Test
  • Walkthrough: Creating, Editing and Maintaining a Coded UI Test
  • тестирование на уровне кода — модульное ( unit testing). Это тестирование одного модуля кода (обычно это одна функция или один класс в случае ООП-кода) в изолированном окружении. Это значит, что если код использует какие-то сторонние классы, то вместо них подсовываются классы-заглушки (моки и стабы). Код не должен работать с сетью (и внешними серверами), файлами, базой данных, иначе мы тестируем не саму функцию или класс, а еще и диск, базу, и т.д.
  • тестирование через API. API — это набор функций, которые можно вызывать, чтобы получить какие-то данные.
    Например, у Яндекс.Карт есть API геокодера. Отправив к нему запрос с географическим адресом, ты можешь получить координаты точки (и наоборот), а у Центробанка есть API, которое возвращает официальный курс валют в заданный день.
    Если у твоего приложения есть API, то можно тестировать его, посылая заранее подготовленные запросы и сравнивая пришедший ответ с ожидаемым.
  • тестирование через пользовательский интерфейс — GUI-тестирование. Имитация действий пользователя в браузере с помощью специальных тестовых фреймворков (типа Selenium).
  • серия программных продуктов Selenium
  • PhantomJS
  • JUnit
  • PhpUnit

Компания созрела для автотестов?

Если хочется , то для этого нужно и скиллы ролей
проектирования и разработки автотестов 1. Сначала нужно провести тест-анализ продукта/сервисов — выявить требования, определить процент покрытия их существующими тестами, определить технологический стек, используемый тестируемыми сервисами и их БД. тест-аналитика, лида
2. Определиться с уровнем тестирования: фронт, бэк, UI, API (web REST, web не REST, RPC. ), десктоп/мобильное приложение и т.п. тест-аналитика
3. Определиться каким образом будем тестировать: функциональное, интеграционное, нагрузочное. тест-аналитика
4. Исходя из п.1-3 подобрать ЯП и фреймворк (готовый или создавать самим) для автотестов.
Используем ли Selenium для UI, используем ли Cucumber с его Gherkin. И т.п.
опытного разработчика автотестов, тест-аналитика
5. Для подачи на вход автоматизаторам, требуется, чтобы кто-то составлял тест-кейсы по требованиям. Возможно, это будет тест-аналитик или сами тестировщики.
Требуется удобный инструмент для хранения тест-кейсов (какой-нибудь древний HP ALM, современная Jira-плагин TM4J, что-то ещё.
тест-аналитика, тестировщика
6. Непосредственно разработка автотестов.
Требуется обеспечить разработчиков удобной IDE (платной/бесплатной), исходя из выбранных языков/фреймворков в п.4.
разработчика автотестов
7. Исходя из п.1-3 можно уже сколько и каких сервисов требуется развернуть для тестирования.
Таким образом выходим на технические требования к тестовому стенду (CPU/RAM, OS, будет ли это Openshift и прочее и прочее) и БД на них. Нужны ли в наличии актуальные мобильные устройства для прогона на них автотестов.
Далее происходит обсуждение с ЛПР есть ли бюджет на покрытие этих технических требований, надо ли где-то ужиматься за счёт уменьшения тестового покрытия. Обычный процесс «торговли» за бюджет и поиски компромисса.
встраивания автотестов в CI/CD 8. Выбрать инструмент для CI/CD. Возможно, решено использовать Jenkins как один из самых распространённых, по установке/настройке/решению проблем с которым легко найти ресурсы в Сети.
Определить как будут запускаться job’ы с автотестами, на каких машинах, с какими параметрами, в каком виде мы хотим получать отчёт о тесте (Allure, кастомные виды представлений. ).
Определить на какой машине с какими ресурсами будет размещён выбранный инструмент, какая там будет ролевая модель (кто будет иметь права на запуск/редактирование job’ов).
Если делать это всё без инструмента, т.е. запуск будет производиться вручную или средствами cron в linux или job’ов Windows — то всё равно это требует обсуждения.
любого кто пользовался выбранным инструментом CI/CD
— разработчика автотестов, администратора, тестировщика.
* методик нагрузочного тестирования,
* разработки и актуализации средств нагрузочного тестирования
(сценарии и скрипты НТ
, эмуляторы, скрипты генерации данных
, скрипты анализа результатов),
9. После п.1 провести тест-анализ сервисов в разрезе именно нагрузочного тестирования, в т.ч. получение профия нагрузки с ПРОДа, опрос администраторов, поддерживающих ПРОД и т.п.
Отталкиваясь от требований, определить что следует нагружать и каким образом, какими способами будем измерять, какие метрики будем использовать.
тест-аналитика, тестировщика-нагрузочника
10. Определить какие технические ресурсы нам потребуются для реализации задуманного по НТ.
Провести обсуждение с ЛПР есть ли бюджет на такие ресурсы, надо ли где-то ужиматься за счёт уменьшения тестового покрытия. Обычный процесс «торговли» за бюджет и поиски компромисса.
тестировщика-нагрузочника, архитектора, тест-аналитика, лида
11. На основании тест-анализа в разрезе НТ из п.9 спроектировать сценарии НТ, определить необходимость скриптов анализа данных, учесть их в сценариях. тестировщика-нагрузочника, тест-аналитика
12. На основании сценариев НТ из п.9 определяем необходимость подготовки данных в БД. Какие они должны быть. Нужно ли их подготавливать отдельными скриптами или же можем себе позволить репликацию с БД прода полностью или частично. тестировщика-нагрузочника, тестировщика данных, тест-аналитика
13. На основании тест-анализа из п.1 и п.9 определяем нужны ли нам заглушки, моки, синтетические тестовые приложения (имитирующие поведение задействованных в сценарии сервисов) тестировщика-нагрузочника, разработчика автотестов, тест-аналитика
14. Непосредственно разработка скриптов НТ. тестировщика-нагрузочника, разработчика автотестов
15. На основании данных из п.10 и п.12 провести обсуждение с ЛПР есть ли бюджет на такие ресурсы, надо ли где-то ужиматься за счёт уменьшения тестового покрытия. Обычный процесс «торговли» за бюджет и поиски компромисса. тестировщика-нагрузочника, архитектора, тест-аналитика, лида.
поддержки разработанных автотестов разработчика автотестов и немного тест-аналитика.

Что автоматизировать

Какие тест-кейсы стоит автоматизировать в первую очередь

  • покрывающие самые критические для Бизнеса бизнес-процессы и юзкейсы
  • часто требующиеся к (пере)прохождению
  • которые слишком сложно и неудобно выполнять вручную
    , например, содержащие проверку данных, требующих точных математических и логических расчётов (банковское, бухгалтерское, аналитическое ПО)
    или проверку структуры многочисленных файлов/сообщений, созданных системой.
  • требующие много времени на ручное прохождение
    , например по проверке корректности отображаемых результатов поиска данных в ответ на запрос по данным
    или проверяющие длинные бизнес-процессы, требующие действий под различными пользовательскими ролями на многочисленных формах UI и в различных системах.

Какие тест-кейсы НЕ СТОИТ автоматизировать

  • разработанные недавно и еще не проверенные вручную
  • требования для которых постоянно меняются
  • разработанные для специфической задачи

Общие рекомендации

  1. Разметка автотестов по @Tag, @Category, @Feature, @Types, @Step и прочему. Не экономьте на этом.
    Такая группировка автотестов позволяет производить запуск не всех 100500 тестов при каждом чихе, а именно тех, которые связаны с изменённой/добавленной функциональностью.
    Также это позволяет производить трассировку между тестами и функциональностью.
  2. Кошерный автотест в случае PASS (успешного прохождения) «убирает за собой», возвращая данные и настройки тестового стенда в состояние, максимально близкое к исходному. Если, конечно, настройки тестируемых приложений менялись в ходе теста, если в ходе теста создавались/изменялись объекты данных.
    Если автотест упал, то чистить за собой ему не надо, потому что его данные потребуются для расследования причины падения.
    Также, хорошей идеей может быть создание cleanup-скрипта, который по расписанию, например, ранним утром каждый день, чистит данные, которые были созданы за предыдущий период время упавшими тестами; предполагается, что за 1-2 дня все упавшие автотесты были расследованы и их данные нам больше не нужны).
  3. Здесь про must have
  4. TBD
  1. Файлы проекта укладываются в контейнер с указанием запускающего файла start.sh и публикуются в хранилище YYY.
  2. При запуске тестов из Jenkins, контейнер устанавливается в Openshift/k8s и происходит автоматический запуска скрипта start.sh
  3. все файлы из контейнера копируются в папку /tmp/tests
  4. запускается сборка проекта Maven’ом с запуском тестов
  5. по завершению сборки и тестов формируется allure-отчёт

Java + Maven + Cucumber + Selenium

Создадим примитивные helloworld GUI-тест и API-тест с использованием Java, Maven, Cucumber (+JUnit) и Selenium.
Нижеизложенное выполнялось под Windows 10 и Intellij IDEA Ultimate 2020.1.

Установка

  1. Установить JRE (Java Run-Time Environment) = https://www.java.com/ru/download/
    Посредством консоли убедиться что Java установлена, например: > java -version java version «1.8.0_261» Java(TM) SE Runtime Environment (build 1.8.0_261-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.261-b12, mixed mode)
  2. Установить JDK: SE или EE.
    Ссылки для Java Standard Edition:
    1. Java SE download = https://www.oracle.com/java/technologies/javase-downloads.html
    2. JDK installation guide = https://docs.oracle.com/en/java/javase/14/install/overview-jdk-installation.html
    1. JAVA_HOME = [путь установленного JDK, например C:\Program Files\Java\jdk-14.0.2 ]
    2. в переменную Path добавить путь %JAVA_HOME%\bin
    1. download = https://maven.apache.org/download.cgi
    2. installation guide = https://maven.apache.org/install.html
    3. installation guide = https://mkyong.com/maven/how-to-install-maven-in-windows/
    1. MAVEN_HOME = [путь установленного Maven, например C:\Program Files\apache-maven-3.6.3 ].
    2. в переменную Path добавить путь %MAVEN_HOME%\bin

    Настройка IDEA, создание Проекта, настройка dependencies

    1. Настроить Intellij IDEA на работу с Maven.
      1. Меню File/Config -> Settings -> Build, Execution, Deployment -> Build Tools -> Maven. Maven home directory = путь до каталога с Мавен
      2. .. Maven->Importing. JDK for importer = Use JAVA_HOME
      3. .. Maven->Runner. JRE = Use JAVA_HOME
      4. OK
      1. +Create New Proejct
      2. Maven
      3. Archetype = org.apache.maven.archetypes:maven-archetype-quickstart
      4. Project SDK = [путь до JDK]
      5. Next
      6. Заполняем Name, выбираем Location
      7. Заполняем GroupId и ArtifactId, например = org.tests и helloworld
      8. Finish

      mvn clean compile

      Hello world

      1. Структура проекта, создание cucumber-файлов для фич и кода
        TBD
      2. Hello World test
        TBD

      Что такое автоматизированное тестирование? Гайд по основам.

      Автоматизированное тестирование (Automation Testing, Test Automation) — техника тестирования, в которой для выполнения тест кейсов используются специальные программы. Это отличает ее от ручного тестирования, в котором тест кейсы выполняются вручную тестировщиком.

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

      Разработка продукта циклична и итерационна — и на каждой итерации, как правило, требуется выполнение одного и того же набора тестов. С помощью инструментов автоматизированного тестирования можно записывать наборы тестов (test suites) и выполнять, когда это необходимо. Как только набор тестов автоматизирован, участие человека в выполнении тестов практически не требуется. Это делает автоматизированное тестирование эффективной техникой. Цель автоматизации — уменьшить количество тестов, которые нужно выполнять вручную.

      Зачем нужно автоматизированное тестирование?

      Автоматизированное тестирование — лучший способ улучшить эффективность, покрытие продукта тестами, уменьшить время на тестирование. Автоматизированное тестирование очень важно, и вот почему:

      • Ручное тестирование всех возможных сценариев использования требует много времени (и, следовательно, денег)
      • Автоматизированное тестирование увеличивает скорость тестирования
      • Автоматизированное тестирование не требует участия человека для выполнения тестов. Автоматизированные тесты могут быть запущены в любое время (днем, ночью, в выходные и праздники)
      • Многократное ручное тестирование одной и той же функциональности скучно

      Что автоматизировать в первую очередь?

      Для максимальной эффективности, для определения сценариев, подходящих под автоматизацию, пользуйтесь следующими критериями:

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

      Следующие критерии не подходят для автоматизации:

      • Новые тест кейсы, которые еще не были выполнены вручную
      • Тест кейсы для функциональности, требования к которой часто меняются
      • Тест кейсы, которые выполняются редко

      Мы написали небольшой гайд по выбору приоритетных тест-кейсов для автоматизации.

      Процесс автоматизированного тестирования

      Процесс автоматизированного тестирования

      Шаг 1: Выбор инструмента для автоматизации

      Шаг 2: Определение функциональности, которую нужно автоматизировать

      Шаг 3: Планирование, тест дизайн и разработка тестов

      Шаг 4: Выполнение тестов

      Шаг 5: Поддержка написанных тестов

      Выбор инструмента

      Определение функциональности, которую нужно автоматизировать

      Область для автоматизации может быть определена по следующим критериям:

      • Функциональность, которая важна для бизнеса
      • Сценарии, для тестирования которых нужны большие объемы входных данных
      • Функциональность, использующаяся в нескольких частях приложения
      • Целесообразность с технической точки зрения
      • Сложность написания тест кейсов
      • Возможность использования одних и тех же тест кейсов для кроссбраузерного тестирования

      Планирование, тест дизайн и разработка

      На этом этапе создается тест стратегия и тест-план, которые содержат следующие детали:

      • Выбранный инструмент автоматизации
      • Фреймворк с описанием его особенностей
      • Описание функциональности, тестирование которой будет автоматизировано
      • Подготовка стендов для выполнения тестов
      • Расписание выполнение автотестов
      • Результаты автоматизированного тестирования

      Выполнение тестов

      Во время этой стадии происходит выполнение автотестов. После выполнения генерируется подробный тест репорт.

      Выполнение тестов может быть запущено как из инструмента автоматизации напрямую, так и с помощью системы управления тестированием (Test Management Tool), который запустит инструмент автоматизации.

      Пример: HP Quality Center — cистема управления тестированием, которая управляет QTP для выполнения автотестов.

      Поддержка написанных тестов

      На стадии поддержки происходит изменение существующих тестов (в случае планируемого изменения функциональности) или добавление новых тестов.

      Советы по использованию инструментов автоматизации

      • Функциональность, подходящая для автоматизации, должна быть определена до начала разработки проекта.
      • Инструмент для автоматизации должен быть выбран исходя из требований конкретного продукта, а не из популярности.
      • Придерживайтесь стандартов написания кода, когда разрабатываете автотесты. Вот некоторые из них:
        • Придерживайтесь гайдлайнов при написании кода
        • Оставлйте комментарии
        • Обрабатывайте ошибки — при разработке думайте о том, как отработает ваша система в случае некорректного поведения приложения.
        • Процент найденных багов
        • Время, затраченное на выполнение автотестов для каждого релиза

        Преимущества автоматизированного тестирования

        • На 70% быстрее, чем ручное тестирование
        • Надежность
        • Сохраняет время и деньги
        • Не требует участия человека для выполнения тестов
        • Возможность повторного использования написанных скриптов

        Типы автоматизированного тестирования

        • Smoke Testing
        • Unit Testing
        • Integration Testing
        • Functional Testing
        • Keyword Testing
        • Regression Testing
        • Data Driven Testing
        • Black Box Testing

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *