Развитие унаследованного фреймворка тестирования Илья Ляукин. Align Technology, Inc.
Обо мне Илья Ляукин, Align Technology ilyaukin@aligntech.com Занимаюсь тестированием ~10 лет Последние три года работаю в Align в «сервисной» команде автоматизации тестирования Задача нашей команды – построение процесса автоматизации тестирования в проектных командах
Background WinRunner QT Pro Selenium 2 Froglogic Squish
Legacy test automation Давным-давно, кто-то в вашей компании решил, что тесты должны быть автоматическими И стали тесты автоматическими И стало их много И все бы хорошо…
Проблемы Тесты не структурированы, их трудно поддерживать Тесты разрабатываются по «догоняющему» принципу На поддержку уходят все ресурсы Добавление нового сценария все дороже и дороже Эффективность команды автоматизации стремится к нулю
Legacy application? Legacy tests? Legacy приложение Устаревший пользовательский интерфейс (например, WinAPI) Нет API Не обновляется Legacy тесты Приложение написано на современных технологиях и развивается, но тесты по историческим причинам написаны на устаревшем инструменте
Рассмотрим хороший случай… Внутренняя разработка, разработчики сидят в 10 метрах от нас Приложение в фазе активной разработки Нормальный пользовательский интерфейс (web) Существует набор тестов, написанных с использованием устаревшего инструмента (qtp)
Расширять старые или писать новые? Расширение тестового покрытия Не надо писать базовые вещи Не надо тратить время на исследование o Мы наследуем все недостатки существующего подхода, такие как ограниченная концепция (data driven вместо behavior driven), устаревший инструмент или невыразительный язык программирования
Расширять старые или писать новые? Создание нового фреймворка Позволяет выбрать наиболее подходящие технологии Позволяет учесть недостатки старого подхода Нет скрытых особенностей o Требуется существенное время, для того чтобы сделать хотя бы что-то работающее («тест авторизации», который сам по себе не нужен)
Расширять старые или писать новые? Чем раньше начать разрабатывать новый фреймфорк, тем меньше издержки
Немного технической информации… Мы используем Selenium 2 (webdriver), python binding. Мы используем nose с плагином freshen, который позволяет писать тесты как сценарии Мы используем nose+multiprocess и grid для распраллеливания Мы используем систему непрерывной интеграции (bamboo) для запусков и хранения результатов
Немного технической информации… Пример сценария Scenario: Staff creation and login Given I am authorized as en_US doctor And I have Staff logins enabled When I am on Account tab in IDS When I am on Staff Accounts tab in IDS And I create new staff member Then I landed on Staff Accounts page And I see current staff member in Staffs table Given I am authorized as current staff member Then I landed on GATI page And I see correct salutation for current staff user
Немного технической информации… Параметризация Scenario Outline: Verify primary submissions for IDS and RDS Given I am authorized as <doctor> doctor And I have Intra oral scanning disabled And I have a patient with <order> Primary order submitted When I am on Patient File page in <app> Then I see Patient ID And I see transient status as Waiting for patient's records And I see last final status as Prescription submitted Examples: | doctor | order | app | | any RDS | Realine | RDS | | en_GB | Lite | IDS |
Обзор результатов Плюсы и минусы нового решения Сценарии отделены от реализации Изоляция внешних систем o Приложение и тесты в разных репозиториях o Используется пользовательский интерфейс там где нужно лишь создать, изменить или получить данные
Обзор результатов Сценарии отделены от реализации *.feature 26236 строк *.py 11039 строк
Обзор результатов Сценарии отделены от реализации Вариант 1. Разработчики решаются поддерживать тесты самостоятельно. Мы готовы к этому – нужно переписать лишь реализацию, сценарии остаются! Вариант 2. Разработчики решаются переписать приложение на ruby. Мы готовы к этому – нужно лишь реализовать шаги на Cucumber, сценарии остаются!
Обзор результатов Изоляция внешних систем Нам не нужно разворачивать весь стек приложений, чтобы протестировать нашу систему Дисфункция внешней системы не мешает нашему тестированию
Обзор результатов Приложение и тесты в разных репозиториях o Разработчики не владеют кодом тестов, также как и QA не владеют кодом приложения o Мешает непрерывной интеграции Если сделано изменение, не совместимое с UI тестами, починить его можно только в следующем билде Разработчики просто не хотят видеть красный билд из-за того что упали UI тесты
Обзор результатов Используется пользовательский интерфейс там где нужно лишь создать, изменить или получить данные o Львиная доля времени выполнения тестов уходит на подготовку тестовых данных