Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ
•Als PPTX, PDF herunterladen•
0 gefällt mir•1,624 views
Анастасия Кугач, Рексофт
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ
Ähnlich wie Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ (20)
Mehr von CEE-SEC(R)
Mehr von CEE-SEC(R) (20)
Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ
- 1. Становление процесса автоматизированного тестирования в интернет-магазине О’КЕЙ Кугач Анастасия Рексофт 2016
- 2. Кратко о проекте • Заказчик – О’КЕЙ • Интернет-магазин • Платформа IBM WebSphere Commerce
- 3. Цели и задачи Цели: • Уменьшение трудозатрат на регрессионное тестирование • Оптимизация использования имеющихся ресурсов • Уменьшение времени на релиз Задачи: • Разработка собственной утилиты сборки • Поиск ресурсов для автоматизации тестирования • Подготовка тестов
- 4. С чего начать? • Ресурсы • Люди • Бюджет
- 5. Бюджет – обоснование необходимости автоматизации тестирования • экономия времени на регрессионное тестирование • сравнительно небольшая стоимость поддержки автотестов по сравнению с ручным тестированием • окупаемость процесса автоматизации за предсказуемое время • более строгий контроль качества разработки
- 6. С чего начать? • Ресурсы • Люди • Бюджет • Тестовое окружение
- 7. Тестовое окружение – основные факторы • железо (если требуется) • инструменты автоматизации • стоимость лицензий специализированного ПО и операционных систем
- 8. С чего начать? • Ресурсы • Люди • Бюджет • Тестовое окружение • Тесты • База регрессионных тестов
- 9. А кому и зачем это нужно? • Команде тестирования • Команде разработки • Руководителю проекта • Заказчику ЗАЧЕМ? Предсказуемое время для получения точного результата
- 10. Технические особенности проекта, на которые нельзя закрыть глаза • Платформа IBM WebSphere Commerce • Не имеет своей системы сборки • Различие окружений dev, test, stage, prod
- 11. Технические особенности проекта, на которые нельзя закрыть глаза • Разные ветки разработки - разные окружения – разные конфигурационные файлы • Различие в идентификаторах публикуемых магазинов (особенность WSC) • Внутренние идентификаторы доступности товаров в SOLR – различается от окружений
- 12. Технические особенности проекта, на которые нельзя закрыть глаза DEV TEST STAGE Module Module, system Module, system, integration
- 13. Выгода • Исходные данные: • 6 чел/дней - ручное регрессионное тестирование версии (Tmanual) • 132 чел/дня – разработка утилиты сборки и автоматизация (Tauto) • 20 – 23 новые версии в год (С) • Бесплатный инструмент Selenium/Selenium Grid • Расчет: Tmanual * С > Tauto * C • Вывод: срок окупаемости автотестирования: 1-1,5 года
- 14. Масштабируемость • Увеличение числа nodes, hubs, scripts • Test script - программа, использующая библиотеку Selenium для выполнения тестов; • NODE - запускает браузеры и выполняет действия запрограммированные в Test script'е; • HUB - выполняет роль сервера, который получает запросы от Test script'а и направляет их на выполнение в NODE'ы. • Различные конфигурации тестовых систем (ОС + версия браузера)
- 15. Что мы имеем Универсальный процесс • Установка current PROD версии на тестовое окружение • Сборка и установка изменений на тестовое окружение • Загрузка тестовых данных (каталоги, цены, изображения, etc.) • Запуск тестовых скриптов из Selenium Grid • Сбор и публикация результатов Время проведения - ночь
- 16. Выводы • Высокая скорость проверки • Удобное масштабирование окружений и поддержка тестов • Сокращение трудозатрат на регресс • 100 % результат после исполнения тестов • Плюсик в карму
- 17. Спасибо за внимание Вопросы? Анастасия Кугач Старший инженер по тестированию Рексофт
Hinweis der Redaktion
- Всем добрый день. Меня зовут Анастасия и я хочу сегодня рассказать о том, как мы выстраивали процесс автоматизации тестирования на проекте интернет-магазин Окей. Думаю, что в связи с тенденциями текущего времени наш опыт может пригодиться.
- Для начала - пару слов о проекте. Интернет магазин окей реалзиуется на базе платформы IBM WebSphere Commerce. Опыт работы с этой платформой - не однозначный из за технических особенностей платформы, а также из за организации самого проекта. Относительно функционала важно отметить то, что по сути один сайт интернет магазина содержит в себе несколько так называемых подсайтов для гипермаркетов. Дело в том, что покупатель делает заказ на конкретный гипермаркет. Проект реализуется уже в течение двух лет, и за это время мы плавно подошли к тому, что настало время внедрить в проекте автотесты. И вот как это было:
- Собственно, необходимость объяснялась тем, что стало слишком много времени уходить на регрессионное тестирование и на локализацию ошибок. Уменьшение времени на эти активности без потери качества, а так же простота локализации ошибок стали нашими главными целями в вопросе внедрения автотестов. И для их достижения был определен следующий круг задач: - разработка собственной утилиты борки (мы помним, что платформа свой утилиты не предоставляет) - Подготовка тестов - выделение времени и людей для организации процессов автоматизации тестирования.
- Когда встает вопрос о необходимости автоматизировать что либо в контексте тестирования, закономерно встает вопрос "с чего начать, за какую из задач взяться?". Когда мы задали этот вопрос себе, то поняли, что первое, за что мы возьмемся - это РЕСУРСЫ. Ресурсы мы разделяли так: Люди. В организационной структуре проекта люди выделяются под потребности, и если на какой то момент для человека нет задач, то он высвобождается из проекта в так называемый пул. Для нашего проекта был выделен тестировщик-автоматизатор. Одному ему было бы справляться тяжело, поэтому технический руководитель нашего проекта и инженер по технической поддержке выделяли свое время соразмерно своему кругу задач для поднятия автоматизации. У проекта есть определенный бюджет. Единственный источник этого ресурса - заказчик, который дает согласие на такие работы. Поэтому ему необходимо их обосновать. И тут могут подойти следующие доводы:
- - экономия времени на регрессионное тестирование - сравнительно небольшая стоимость поддержки автотестов по сравнению с ручным тестированием - окупаемость процесса автоматизации за предсказуемое время - более строгий контроль качества разработки
- Когда мы начинаем говорить о бюджете, нельзя не сказать о стоимости технологических решений, которые будут использоваться. Третий вид ресурса, о котором стоит задуматься - тестовое окружение. Под это понятие определяем следующие пункты:
- - железо (если требуется, например, сервера) - инструменты автоматизации - стоимость лицензий специализированного ПО и операционных систем
- Второй пункт, который мы рассматриваем - это тесты. Руководством проекта должно быть принято решение, какого рода автоматизация должна быть внедрена: функциональное, нефункциональное тестирование или же все вместе. Мы приняли решение на данном этапе автоматизировать проверку интерфейса и функционала, нагрузочное тестирование в рамках данного рассказа мы рассматривать не будем. Проект уже, можно сказать, зрелый, за время его существования на нем проработали несколько тестировщиков, и общими усилиями была выделена определенная база регрессионных тестов. Именно их было решено автоматизировать, сделав их более "атомарными".
- Осознав круг задач, кто-то может махнуть рукой и спросить, а зачем все это нужно? А главное - кому? Не проще ли оставить все как есть, не вводя в проект новые риски? Так, в неформальной обстановке мы пришли к выводу, что в первую очередь это нужно нам самим - команде тестирования. Приложив усилия в начале процесса на его становление, мы получим ожидаемый результат в последствии, сможем предсказывать выходной уровень качества. По мере обсуждения и развития темы, нас поддержали коллеги-разработчики. Для них - это возможность непосредственного наблюдения и точного выявления ошибок, а так же возможность точного воспроизведения конкретных багов. Наконец, автоматизация нужна и руководителю проектов. Это помогает при планировании релизов давать более четкие оценки. Ну и в завершении, для заказчика будет аргументом то, что плюсы от автотестов окупятся за обозримый срок. Все это позволяет нам корректно определять время для получения точного результата.
- Говоря об автоматизации на проекте, стоит упомянуть о некоторых его технических особенностях. Как я уже говорила, платформа IBM WebSphere Commerce не имеет никакой своей системы сборки. На старте проекта она была написана командой разработки самостоятельно. Первые сборки же вообще проводились вручную,но на данный момент создана своя утилита. Еще одна важная особенность - это различие окружений разработчиков, тестировщиков, стэйджа и прода.
- Различия заключаются вот в чем. Первое - в один момент в реализации может быть несколько версий, что в принципе нормальная ситуация. Это уже требует различных окружений с различными конфигурационными файлами. Второе - WebSphere Commerce берет идентификаторы публикуемых магазинов из своего некоего пула, соответственно, поэтому, идентификаторы одного и того же магазина на различных окружениях различаются. Ну и третье - платформа поиска SOLR так же имеет свои внутренние уникальные идентификаторы в поисковом индексе для определния доступности товаров в магазинах, что являлось специальной ее кастомизацией. (заказчику необходимо было использовать один и тот же каталог продаж в нескольких магазинах.Но при этом ещё и нужно было определённые товары скрывать в определённых магазинах.)
- Поскольку автоматизация вводится уже сильно после старта проекта, мы имеем уже вполне устоявшийся план тестирования на наших окружениях, которые, как мы видим, сильно различаются, и, к сожалению, нам проходилось выполнять одни и те же тесты по несколько раз. Во-первых, на dev окружении выполняются ручные модульные тесты. После этого, на test окружении - модульные и часть системны тестов, которые касаются именно сайта. Финальной проверкой перед передачей на приемочное тестирование заказчику служит проверка на stage-окружении. На нем выполняются модульные, системные и интеграционные тесты.
- Когда принималось решение о внедрении автоматизации, были подсчитаны количественные показатели выгоды. Что мы имели: на каждую версию, поставляемую в PROD, мы тратили 6 человеко-дней на регрессионное тестирование на stage-окружении. С учетом 20-23 версий в год, мы получали 120-132 человеко-часов только на регресс. По подсчетам, на внедрение автоматизации была дана оценка в 132 человеко/дня, в которую так же входит написание своей утилиты сборки. Как видим, затраты сопоставимы. Так же, было решено использовать бесплатный инструмент Selenium Grid, который полностью покрывает наши потребности в использовании. На старте работ по внедрению автоматизации трудозатраты превосходили время, затраченное на ручное тестирование. Однако, с течением времени, процесс окупился. Срок окупаемости – примерно полтора года.
- Внедренное решение на основе Selenium Grid позволило нам быстро расширить архитектуру нашей автоматизации на все тестовые окружения за счет увеличения числа нод, хабов и скриптов. А уже внутри каждого кластера, образуемого ими, мы можем поднимать сколько угодно конфигураций тестовых машин (ОС и версия бразуера).
- В общем итоге мы получили универсальный процесс обновления, осуществляемый по ночам: - установка текущей ПРОД версии на тестовое окружение - сборка и установка изменений - загрузка тестовых данных - запуск тестовых скриптов - сборка и публикация результатов прогона тестов.
- 22. Выводы от всех наших действий могут быть следующими: увеличение скорости проверки и сокращение трудозатрат на регресс с 6 человеко-дней до 4-6 часов. удобное масштабирование окружений и поддержка тестов. При желании увеличить регрессионную базу тестов это будет сделать легко 100 процентный результат после исполнения автотестов