2. Содержание
• Цель доклада
• О компании Align Technology
• Постановка проблемы
• Описание системы
• Среда выполнения – Web-портал
• Проблемы скриптов и их решения
• Дополнительные возможности
• Результаты использования
• Заключение
• Q&A
2
3. Цель доклада
• Цель доклада
• Поделиться опытом создания инфраструктуры
автоматизации тестирования, ориентированной на
использование внешними по отношению к
“автоматизаторам” пользователями
• Пользователи нашей GUI-автоматизации
Тестировщики, разработчики
Администраторы приложений
Представители производства
Финансисты
3
4. О компании Align Technology
• Align Technology, Inc – лидер в
области “невидимой ортодонтии”.
• альтернатива брекетам
• на рынке с 1999г.
• Мы помогаем людям улыбаться
больше и таким образом делаем
людей счастливее
• Размер R&D: ~200 человек
• Сайт компании - www.aligntech.com
4
6. Постановка проблемы – зачем
6
Мы хотим:
• Чтобы наши коллеги самостоятельно использовали
автоматизацию тестирования для своих нужд
Зачем??
• Уменьшение накладных расходов на коммуникации с
автоматизаторами
• Недоступность целевой системы (ОС, WAN, Security)
• Уменьшение требований к экспертизе сотрудников
• Ускорение часто выполняемых операций
• Другие преимущества автоматизации в целом
• Дополнительное использование уже существующих скриптов
7. Постановка проблемы – сложности?
7
«Пирамида проблем»:
?
Желание
Скорость
Надежность
Доверие
Информированность
Функциональность/гибкость
Доступность/простота использования
1: Среда
выполнения
2: Скрипты
3: Доп.
функционал
9. Среда выполнения (ROCS) – workflow
• Схема использования
• Пользователь с помощью web-интерфейса запускает
задачу на запуск автоматизации
• Задача поступает в очередь. Из очереди задачи поступают
на свободные машины в кластере и выполняются
• После выполнения скрипта пользователь получает e-mail с
результатами запуска автоматизации
9
10. Среда выполнения (ROCS) - компоненты
10
• Сервер
• Хост для web-интерфейса системы
• Файловое хранилище для отчетов
• Кластер виртуальных машин
• Каждый клиент способен выполнить любую задачу
• Сервер БД
• Сервер лицензий (HP QTP)
15. Среда выполнения (ROCS) – отчеты (1/2)
• Результат – на e-mail
• Пользователь получает детальное описание результатов
прохождение автоматизации и описание ошибок
(+скриншот), если что-то пошло не так
15
17. Среда выполнения (ROCS) – кластер
Кластерные клиенты:
• Виртуальные машины
• Самоорганизующиеся
• Идентичны
• Универсальны
• Обновление скриптов: Subversion
• Регулярные перезагрузки и другие
методы обхода известных проблем
QTP
17
VNC
SVN
Server
DB
18. Среда выполнения (ROCS) – БД
СУБД:
• Вспомогательная информации
веб-портала и кластера
• Обмен информацией между
QTP-скриптами
• Статистическая информация
• Регулярные автоматизированные
отчеты
18
19. Среда выполнения (ROCS) – Преимущества
• “Заточенность” под компанию
• Простота использования
• Дополнительная функциональность
• Бесконечная кастомизация
• Возможность совмещения нескольких тулов
• Кросс-платформенность
• Бесплатность -> масштабируемость
• Наличие экспертов по системе
19
21. Проблемы скриптов и методы решения (1/2)
•Функциональность
- Постоянный сбор запросов
- Выдвижение предложений
- Максимальная гибкость
- Up-front design
•Юзабилити
- Справка и документация
- Введение обработки параметров по умолчанию
- “Читабельные” и понятные отчеты
21
22. Проблемы скриптов и методы решения (2/2)
•Доверие
- Видео, показательные забеги
- Хорошие логи, побольше скриншотов
- Прозрачное отображение на тест-сценарии
•Надежность
- Обработка исключительных ситуаций
- Подробное описание ошибок
•Скорость
- Возможность выключения ненужных шагов
- Распараллеливание, если возможно
- Внимание к мелочам при разработке скриптов
22
24. Дополнительные возможности системы
• Проверка работоспособности тестовых сред
• Регулярные запуски на 6 тестовых средах (+ по запросу)
• Результаты на портале в реальном времени:
24
26. Результаты использования (1/2)
• Используется в 4 географических зонах:
• США (Калифорния),
• Коста-Рика,
• Мексика,
• Россия (Москва)
• Используется в различных департаментах:
Тестировщики, разработчики
Администраторы приложений (для Smoke Tests)
Представители производства (для UAT)
Финансисты (для UAT финансовой части)
26
27. Результаты использования (2/2)
• 30-40 внешних пользователей в неделю
• Несколько сот запусков скриптов в неделю
• С начала 2010 года автоматизацией создано более 54 000
пациентов (что эквивалентно трудоемкости порядка 15-20
человеко-лет):
27
0
1000
2000
3000
4000
5000
6000
7000
8000
Jan Feb Mar April May June July Aug Sep Oct
Bots Automation Msk INTL Total
28. Заключение
• Создана инфраструктура автоматизации, которая
используется “неавтоматизаторами”
• Общение с системой через Web-интерфейс
• Систему часто используют люди, далекие от R&D
(бизнес-пользователи, администраторы, менеджмент)
• Система имеет ряд полезных свойств, в частности:
• Удобство и простота использования
• Оптимизация использования лицензий
• Расширяемость (за счет виртуализации)
• Наличие дополнительного функционала
Надеемся, что этот опыт будет Вам полезен!
28
30. Контактная информация (backup slide)
• Бурмистров Валерий – Senior SQA Manager
• E-mail – vburmistrov@aligntech.com
• Profile - http://valeriyburmistrov.moikrug.ru/
• Фомин Илья – SQA Automation Team Lead
• E-mail – ifomin@aligntech.com
• Profile - http://i-fomin.moikrug.ru/
30
Editor's Notes
Вы расскажем вам о том, какую проблему мы решаем, опишем решение и сделаем выводы
(по этому слайду – очень коротко)
Цель доклада – поделить опытом (!), рассказать как у нас устроена жизнь.
У нас есть инфрастуктура автоматизации. Специфика ее состоит в том, что она используется внешними пользователями; более-менее самостоятельно.
Пользователи разные, кроме разработчиков и тестировщиков это администраторы, которым нужно делать smoke test и бизнес-пользователи (UAT)
Мы представляем компанию Align Technology.
Компания не очень известна у нас, но известна в США.
Компания предоставляет решение для исправления прикуса зубов, альтернативное “брэкетам”.
Специфика – прозрачность, поэтому пациенты могут носить Aligner’ы и улыбаться больше.
Высокотехнологичный Manufacturing
Мы делаем что-то, что делает людей счастливее
Мы хотим, чтобы автоматизацию использовали без нашего участия для удовлетворения каких-то своих нужд. Хотите ли этого вы? Есть ли у ваших коллег такие нужды? Решать вам. У наших таковые имеются, кроме того, удовлетворение одних потребностеей постоянно порождает новые.
Зачем нам это может быть нужно?
Если смотреть именно на использование тестировщиками – уменьшение накладных расходов на коммуникации с автоматизаторами. Если есть много маленьких задач – то даже написание имейла – уже немаленький оверхед. У нас компания размазана по миру, так что для некоторых коммуникаций необходим день, преимущества понятны.
Если добавить сюда еще и людей, далеких от SQA, получаем
Обход недоступности системы: у пользователей нет паролей, оборудования, ПО для доступа к системе, а у скриптов это все есть. Доступ к скрипту может тогда быть чуть ли не единственным возможным средством выполнения необходимых действий над системой
Уменьшение требований к экспертизе – пользователю не надо знать, как выполнять какие-то действия с системой, это знают скрипты
Скрипты часто работают с системой быстрее пользователей (особенно бизнес-пользователей =). Гуй-автоматизация хороша тем, что может автоматизировать практически любую активность, которую рядовой пользователь системы может представить.
Вообще говоря, все другие профиты от автоматизации, которые вы можете представить, тут тоже применимы.
Особенно эффективно это будет работать, если вашим пользователям нужна автоматизация действий, часть которых уже покрыта существующими тестовыми скриптами. Возможно, нам повезло, и у нас это именно так.
Это все причины, а следствием может быть зарождение в компании новых процессов, требующих вашего, как автоматизатора, участия.
В процессе реализации и внедрения мы, естественно, сталкивались с рядом проблем. Пытаясь их упорядочить, получили нечто похожее на пирамиду. Сейчас будем ее строить.
Первым пунктом идет юзабилити. Даем коллегам возможность получить доступ к системе, желательно, чтобы они могли в ней сходу разобраться.
Допустим, система доступна. Заходит в нее пользователь – конечно, хочет сходу удовлетворять свои потребности. Гибкость здесь – как метод расширения функциональности. Зачастую эффективный.
Отлично, пользователи могут зайти в систему и удовлетворить свои какие-то потребности. Надо им об этом сообщить. Чем больше информации – тем лучше. Плюс только зайдя в систему один раз, он должен уже иметь какое-то представление о том, чем система может ему помочь.
Это довольно специфично для внешних пользователей. Приходится их убеждать, что скрипты делают то, что нужно.
Получили доверие – нужно его оправдать. Работаем над надежностью
Ну и желательно не тормозить, да. Здесь важно выделять как минимальное, так и среднее время выполнения скрипта.
Вроде бы, теперь все должно работать, осталось заставить пользователя захотеть это использовать. Некоторые сразу хотят, некоторые – нет.
И даже если вы все эти проблемы поборете, наверняка всплывут еще какие-то, специфичные для вашей компании.
Вообще говоря, если вы пойдете этим путем у себя в компании, эта пирамида будет для вас выглядеть, как айсберг. Рекомендую предусмотреть появление таких проблем.
В презентации рассмотрим решение этих проблем с трех сторон: сама система для запуска тестов, тесты, и доп функциональность системы, не связанная напрямую с запуском тестов.
Вот так выглядит схема работы пользователя с системой:
Пользователь обращается в web-интерфейсу
Запускает задание на автоматизацию
Задание поступает на одну из клиентских машин, где есть QTP, выполняется и возвращает результаты пользователю
Достаточно нехитрая, но надежная архитектура:
Web-сервер
На нем же – централизированное хранение отчетов
Кластер виртуальных машин, на которых выполняются задания
Сервер БД для хранения всей информации о том, что было и для служебных задач
Сервер лицензий
Вот так выглядит интерфейс системы. На первый взгляд страшновато, правда? На самом деле все достаточно просто если один раз попробовать. (КОРОТКИЙ СЛАЙД)
В левой части – дерево скриптов, которые мы будем запускать
Далее – для каждого скрипта (мы их называем батчи) есть описание
Набор шагов, можно выделять галочками все или не все шаги
Важный шаг – выбираем параметры запуска (возможно по-умолчанию)
Выбираем тестовый стенд, на котором запускаться и вперед!
Задача поступает на кластер и выполняется на одном из клиентов. Можно посмотреть на каком именно.
Параметры передаются в XLS
выпадающиеся списки для наиболее использующихся
тулы для редактирования
выгрузка/загрузка XLS на свой компьютер
Решение предоставляет несколько способов отслеживания того, что происходит:
Состояние кластера через web-интерфейс
Специальная вкладка для просмотра результатов запусков (вся информация в БД)
Можно зайти на каждую машину кластера и посмотреть что там происходит. Речь о GUI-автоматизации, все достаточно забавно бегает
Когда задача отбегала, хочется видеть отчет. У нас отчет приходит на e-mail в виде HTML
Ключевые мысли:
Структурированный
Если Fail, то есть скриншот и детальное описание что случилось. По сути в некоторых случаях скрипт умеет подсказывать в чем проблема и даже подсказывает что делать.
На простом HTML построена функциональность, которая делает отчеты простыми в использовании:
Можно открывать и закрывать секции отчета
Посмотреть только fail’ы и warning’и.
Посмотреть параметры по которым можно найти все данные в системе и посмотреть руками (
Итак, после запуска задания пользователем, оно поступает на кластер и там обрабатывается.
Кластер у нас представляет набор виртуальных машин, на каждой установлен весь необходимый софт.
Клиенты самооргинизующиеся, т.е. Отсутствует кластер-менеджер. Проще говоря, клиенты сами между собой договариваются, кто какое задание запустит. Сервер за этим наблюдает, но в процесс не вмешивается. Это снимает зависимость от сервера, кроме того, позволяет нам закидывать задания в очередь кучей разных способов. Даже есть некоторые батчи, которые сами создают задания на запуски новых батчей.
Все клиенты идентичны, если один сломался – можно заменить клоном.
Каждый клиент может выполнить каждую задачу. Позволяет не держать простаивающих клиентов.
Удобно использовать систему версионноо контроля для хранения и распространения сриптов. У нас это SVN. Работая версия скриптов попадает на машины каждый день, либо по запросу – для срочных фиксов.
Реализация такого кластера самостоятельно позволила добавить различные методы борьбы с глюками QTP, кроме того, обрабатываем ситуацию с нехваткой лицензий. Тот же QC не может этого делать, ну и не хочет, естественно.
Также у нас есть БД, много для чего используемая.
Во-первых, всякая информация для работы веб-приложения хранится там.
Кластерные клиенты между собой договариваются через ту же базу.
Кроме того, некоторым скриптам нужно обмениваться информацией – как для последовательно, так и для параллельного запуска.
Еще собираем там всякого рода статистику и на ней автоматически строятся некоторые регулярные отчеты.
Как пример использования таких отчетов – вот такой хит-парад лучших пользователей автоматизации у нас выходит каждую неделю, в частности, привлекает внимание к автоматизации и зарождает у пользователей интерес.
Даже если у нас есть идеальная среда запусков тестов, никто ей не будет пользоваться, если нет хороших тестов.
Какие проблемы надо решать и как
В первую очередь – функциональность.
Up-front design – часто пользователи нас спрашивают, а есть ли у нас то-то – а у нас уже есть
Дополнительная функциональность, но использующаяся каждый день в Москве и головном офисе – проверка состояния тестовых стендов.
Каждый день бегают скрипты, которые проверяют состояние тестового стенда. Соответсвенно т.к. Вся информация сохраняется в БД, то был сделан функционал, позволяющий полностью автоматически понимать состояние каждого тестового стенда. И Web-страничка, на которой это можно посмотреть.
Мы компания, разные функции которой разбиты по разным географическим локациям
кратко о каждой.
упомянуть, что многие пользуются нашей системой
для чего?
Администраторы бизнес приложений, представители производства и бизнеса для UAT
Успешно.
Немного цифр.
Системой пользуются несколько десяткой человек в неделю. Запускаются сотни скриптов. Если посчитать количество полеченных с помощью нашей системы пациентов, то за 2010 эта цифра больше 54000, значит автоматизаторы не зря едят свой хлеб меньше чем в продуктиве, но достаточно много
Итак, заканчиваем тем, чем начинали. У нас создана инфрастуктура автоматизации, которой пользуются не только автоматизаторы. Это организационно-техническое решение обладает рядом интересных свойств. Это то, как оно сделано у нас. Может быть что-то из этого покажется вам полезным.