Pull to refresh

Автоматизация через интеграцию. Промо-версия. UPD

Reading time 11 min
Views 3.2K
Upd: добавлены скиншоты.

19-20 мая в Минске проходил Software Engineering Forum 2011. Мы выступили с докладом «Новый уровень автоматизации тестирования», или альтернативный длинный вариант – «Доавтоматизация» автоматизированного тестирования через интеграцию тестового инструментария». В нем мы раскрыли три основных вопроса:
  1. Уровни автоматизации тестирования в организации.
  2. Основные моменты, на которые стоит обратить внимание при автоматизации тестирования (на основе собственного опыта и опыта коллег, а также результатов опросов).
  3. Прототип решения для управления автоматизированным тестированием (на базе внутренней разработки Octopus).

Под катом – содержание доклада, ссылка на промо-версию Octopus. Длинный пост.

1. Уровни автоматизации тестирования


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


A. Этап зарождения (I)

Наряду с ручным тестированием в компании начинают использовать:
— скрипты, копирующие setup тестируемого продукта, устанавливающие его и частично тестирующие;
— тесты, написанные в какой-либо среде разработки автоматических тестов.

Характеристики этапа
  • Действия, сопряженные с автоматизированным тестированием, выполняются вручную (запуск скриптов и тестов, работа с виртуалками и т.д.).
  • Отсутствие четкой организации хранения тестов (как правило, тесты хранятся на машине тестировщика, используются только им, т.е. не являются реиспользуемыми и адаптируемыми к изменениям тестируемых интерфейсов).
  • Нет систематизации запуска тестов и контроля над их выполнением (могут запустить тесты, а могут и забыть).
  • Между тестерами и разработчиками не налажены информационные потоки о статусе проверки билда.
  • Как правило, нет полного доверия к тестам. Тем не менее, тесты и скрипты существенно высвобождают ресурс тестировщика.

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

B. Осознанный этап (I+II)

Наряду с автоматизацией самих тестов, автоматизирована и некоторая часть процесса.

Характеристики этапа
  • Появляется организация централизованного хранения и реиспользоания тестов (библиотеки функций).
  • Вступают в силу соглашения по именованию автоматических тестов.
  • Большинство действий заавтоматизировано: запуск тестов, запуск/остановка виртуальных машин (в случае использования виртуализации), копирование необходимых конфигурационных файлов на тестовую машину и т.п.
  • Улучшается качество самих тестов.
  • Запуск тестов систематизируется и автоматизируется с выходом каждой сборки продукта.
  • Четко определено поведение при обработке результатов тестов – создание/закрытие багов.

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

C. «Продвинутый» уровень (I+II+III)

Этап «автоматизации автоматизированного тестирования». Тавтология использована намеренно, чтобы выразить мысль о том, что все операции цикла автоматизированного тестирования осуществляются без участия тестировщика – от подготовки окружения и запуска тестов над выпущенным билдом до регистрации ошибок в баг-трэкинг системе (BTS – bug tracking system – система контроля дефектов) и создания отчетов. Как правило, этого добиваются с помощью скриптов и конфигурационных файлов, гораздо реже инвестируют в разработку комплексной системы управления автоматизированным тестированием.

Характеристики этапа
  • «Доавтоматизированы» все операции, связанные с прогоном автотестов: конфигурация окружения, запуск виртуальных машин, запуск тестов на выполнение, регистрация багов, создание отчетности).
  • Создание ошибок (если уместно, то и закрытие исправленных) в системе контроля происходит автоматически по всем правилам, принятым в компании, с назначением ответственного лица и заполнением заданных полей в BTS.
  • Различные «примочки» для увеличения эффективности тестирования: создание групп тестов для одновременного запуска, группировка виртуальных машин по определенным признакам (Ось, установленные программы, локализация и т.п.).
  • Единый интерфейс для параметризации выполнения тестов (встречается нечасто).

Достичь этой стадии стремятся, в первую очередь, компании, разрабатывающие сложные программные продукты с широким функционалом, со средне- и долгосрочными проектами, и остро ощущающие проблему нехватки качественного и своевременного регрессионного тестирования.
Около 12,5% респондентов нашего опроса, проведенного среди Хаброжителей, заявили, что их компания находится на этом этапе.
К сожалению, нет возможности уточнить, каким образом у них происходит параметризация автоматизированного тестирования – через единый UI, с помощью config файлов и т.д. Идея задать такой вопрос пришла уже после того, как было получено более 100 ответов, и не было смысла его добавлять. Но мы его включили в англоязычный опрос для участников QA-сообществ на LinkedIn (см. график ниже).

Вышеописанная классификация — результат нашего опыта, и не претендует на единтвенно верную. Интересно, насколько Ваше видение не совпадает с нашим?

Немного лирики, или трудности с регрессионным тестированием

Не секрет, что регулярное регрессионное тестирование новых билдов обеспечивает стабильно высокое качество конечного продукта. Но в силу ограниченности ресурсов именно регрессионным тестированием зачастую пренебрегают, либо оно выполняется не в полном объеме.
Лет пять назад наша компания столкнулась с этой проблемой. Количество ошибок, найденных на стороне заказчика, превысило все нормы приличия. Продукт – сложная desktop-система для автопрома, состоящая из множества агентов, модулей и компонент. Ежемесячно приложение обрастало новыми фичами, и у тестировщиков успевали проверить новый функционал и лишь какую-то часть старого. Несмотря на тесное сотрудничество между разработчиками и тестерами, система «падала» в таких местах, где никто не ожидал.
Стало очевидно, что процессы тестирования необходимо выводить на новый уровень.
Начали облегчать труд автотестами, скриптами и batch-файлами. Это позволило проводить регрессионное тестирование быстрее и в большем объеме. Однако внедрение автоматизированного тестирования скрывало в себе множество заморочек, которые мы не предвидели изначально. По сути, мы бегло затронули некоторые из них в описании этапов автоматизации, но сейчас рассмотрим более обстоятельно.

2. Проблемы на пути автоматизации тестирования


A. Неполнота автоматизации

Выражение «автоматизированные тестирование» является до некоторой степени условным. Зачастую тестировщик много задач выполняет вручную: готовит окружение, закачивает новую версию продукта, перетаскивает конфигурационные файлы, запускает автотесты на разных Осях, регистрирует дефекты в BTS и т.д. Это несложно, но трудоемко, а также увеличивает вероятность ошибок из-за человеческого фактора.


Иногда потеря времени может быть значительной. Например, в случае Data Driven тестов, где важен каждый отдельный результат, поэтому количество багов, которые нужно внести в систему контроля дефектов, может быть огромным. В среднем, у опытного специалиста создание бага в BTS с заполнением всех необходимых полей занимает чуть больше 1 минуты, закрытие – около 15 секунд (*). Эти трудоемкие действия имеют низкую добавленную стоимость, а время, затраченное на их выполнение, можно более эффективно использовать, задействуя интеллектуальный потенциал тестировщика, например, на написание новых тестов.

(*) Измерения проводились в следующих условиях:
1. Системы контроля дефектов — MS TFS, Mantis, Bugzilla.
2. Экспериментаторы: 2 тестировщика с 4-летним стажем.
Во время эксперимента было создано 10 багов с заполнением следующих обязательных полей:
MS TFS: Title, AssignTo, Iteration, Area, Tester, FoundIn, Severity.
Mantis: Category, Summary, Description, Platform, OS, Severity.
Bugzilla: Component, Version, Summary, Description, Severity, Assignee.
Время, затраченное на открытие BTS, также учитывалось.


B. Отсутствие удобного и гибкого инструмента управления тестированием

Даже если компания находится на продвинутой стадии автоматизации тестирования, редко у них имеется общий интерфейс управления всеми задачами, связанными с автоматизированным тестированием. Чаще всего параметризация происходит через config файлы (50% респондентов), валидация которых зачастую не производится. В результате, растет число ошибок и снижается эффективность автоматизированного тестирования в целом.
Результаты опроса пользователей LinkedIn:


C. Расширяемость и масштабируемость архитектуры

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

D. Отсутствие кумулятивной отчетности едином формате

Как правило, каждый тип теста (например, написанный в Visual Studio, HP QTP и т.д.) предоставляет отчет о результатах в собственном (native) формате, и чтобы его просмотрел менеджер проекта или заказчик, у них должно быть установлено соответствующее ПО. Несмотря на то, что некоторые среды разработки автоматических тестов позволяют экспортировать эти результаты, например, в HTML отчеты, которые может посмотреть любой желающий, они все отличаются по форме и структуре, что осложняет восприятие информации. К тому же, прогнав нужные тесты на виртуальных или физических машинах, мы получаем несколько пачек отчетов, каждый из которых приходится просматривать в отдельности.
Под словом «кумулятивный» подразумевается накапливание результатов по мере прохождения тестов в едином документе. Таким образом, «кумулятивный отчет в едином формате» означает создание единственного общего отчета, который постоянно обновляется по мере поступления новых результатов тестов и обеспечивает актуальность информации.

Пример общего HTML отчета по всем тестам


E.Бесперебойность процесса

Система, управляющая автоматизированным тестированием, по сути, является конвейером. На вход подаются новые сборки для тестирования, а на выходе – результат в виде созданных багов и отчетов. Разрабатывая такую систему, мы столкнулись с проблемой отсутствия защиты от «дурака». Т.е., если один из тестов был написан с ошибкой, он мог выполняться системой до бесконечности и загружал ресурс в виде виртуальной или реальной машины, тем самым не давая дороги тестам в очереди выполнения. Решить эту проблему можно по-разному; мы реализовали фичу «timeout kill» (прерывание выполнения долго выполняющихся команд).

F.Недостаточное логирование системы

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

3. Решение для управления автоматизированным тестированием

Учитывая моменты, о которые мы «набили шишки» и описали выше, мы постепенно шаг за шагом разрабатывали систему, которая бы в автономном режиме 24 часа в сутки управляла всем циклом автоматизированного тестирования – от подготовки окружения и запуска тестов до регистрации дефектов и создания отчетов.
Стоит отдельно подчеркнуть, что речь не идет о создании собственной баг-трекинг системы или среды скриптования. Решение является интегратором, объединяющим уже существующий тестовый инструментарий в единую систему с общим интерфейсом. Под тестовым инструментарием подразумевается различное ПО для тестирования и управления проектам: система сборки, система контроля версий, баг-трекинг система, система виртуализации и среды разработки тестов.
Вначале были изучены основные взаимодействия тестировщиков с каждым из этих инструментов, затем APIs последних. Наконец, они были интегрированы все вместе под общим UI, который позволяет удобно и быстро настраивать систему в соответствии с правилами и процессами, существующими в компании.
Основная разработка системы управления, которую позже назвали Осьминожкой в честь 8 основных фич, была завершена года 1,5-2 назад, с тех пор у нас не было головной боли по поводу нехватки ресурсов для регрессионного тестирования, а качество производимого ПО ощутимо возросло. По эффекту, такое ощущение, что мы дополнительно наняли 5 тестеров.
Процесс автоматизированного тестирования мы настраиваем с помощью 5 вкладок: Билды, Машины, Ручной запуск, Очередь, Лог. На каждой вкладке в полной мере посуществляется настройка соответствующих элементов, а Лог позволяет следить за происходящим в любом уголке системы.

Примеры скриншотов
Вкладка «Билды»


Вкладка «Машины»


Вкладка «Очередь»


Основные фичи системы управления Octopus

1. Запускает виртуальные машины (ВМ) в случае использования виртуализации при тестировании.
2. Подготавливает тестовое окружение: копирует конфигурационные файлы и автотесты на машину для тестирования, устанавливает продукт.
3. Ставит успешно собранные билды в очередь тестирования в соответствии с приоритетом билда.
4. Запускает автоматизированные тесты/группы тестов по расписанию или по событию успешного выхода сборки.
5. Тестирует на «чистых» ВМ, определенных снэпшотах и на физических машинах.
6. Регистрирует обнаруженные ошибки в BTS, заполняет назначенные тестером поля (например, Title, Assigned to, State, Description, Found in, Reviewer/Tester, Severity и т.д.).
7. Закрывает исправленные баги, если разрешено оператором.
8. Создает общий отчёт по всем пройденным тестам в HTML.
Тестировщик загружает автоматические тесты в базу объединенной системы, единожды задает ее настройки под конкретный проект, и она самостоятельно в режиме нон-стоп тестирует каждый новый билд продукта.
В этом видео (3 мин.) показано, как система автоматически начинает тестировать собранный билд.


Структура системы Octopus

Решение состоит из трех модулей:
Менеджер автоматических тестов — серверная компонента, которая управляет работой всей системы.
Технология реализации: Windows Service на языке C# под платформу .NET Framework v3.5.
Потребление ресурсов:
CPU: практически не нагружается
RAM: ~50 Мб
Сеть: при старте и завершении заданий занята полностью – производится загрузка окружения на виртуальную машину и получение результатов

Агент запуска автоматических тестов — модуль, который непосредственно запускает тесты над билдами на виртуальной или физической машине для тестирования, производит настройку окружения, передает файл с результатами тестов Менеджеру автоматических тестов.
Технология реализации: консольное приложение на C++.
Потребление ресурсов:
CPU: во время выполнения тестов не используется
RAM: ~7 Мб

Панель управления автоматическим тестированием — клиентская часть, обеспечивающая пользовательский интерфейс «Octopus». Через него можно провести всестороннюю настройку выполнения тестов, управлять ресурсами (виртуальными машинами), просматривать текущее состояние выполнения тестов и лог событий, а также при необходимости вручную запускать и останавливать тесты.
Технология реализации: настольное и веб-приложение на C# под платформу Microsoft Silverlight.
Потребление ресурсов:
Размер: ~0,5 Мб
RAM: ~30 Мб

Системные требования

OS: Windows XP/Vista/7, Windows Server 2003/2008
CPU: 1.0 GHz
RAM: 512 MB
Hard Drive: 4 MB

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

В настоящий момент список выглядит так:

Системы виртуализации: VMware Server 2.0*, Hyper-V.
Системы сборки: CruiseControl.NET*, Microsoft Team Foundation Server 2008/2010.
Системы контроля версий: SVN*, Microsoft Team Foundation Server 2008/2010.
Системы контроля ошибок: Mantis Bug Tracker*, Bugzilla*, Microsoft Team Foundation Server 2008/2010.
Среды разработки тестов: AutoIt*, Microsoft Visual Studio, HP QTP.
(*) – свободное ПО.

Система кастомизируется под коммерческие и свободные тулы с открытым API. В ближайших планах – «прикрутить» баг-трекинг систему Jira.

Бесплатная промо-версия

Мы сделали бесплатную промо-версию приложения Octopus, основанную на свободно-распространяемом ПО. Мы выбрали именно freeware, чтобы при желании каждый мог попробовать его в действии.
Больше информации на этой странице: www.appsys.net/Octopus/Download/Ru.
Жду Ваших вопросов и комментариев.
Tags:
Hubs:
+12
Comments 10
Comments Comments 10

Articles