Download to read offline
Uploaded bySQALab
Автоматизация 0.0: 0 - бюджет, 0 - опыт программирования
Документ описывает опыт автоматизации регрессионного тестирования внутреннего приложения для техников Deutsche Telekom, внедренного с использованием инструмента Sikuli. В проекте участвовали три тестировщика, и в результате было автоматизировано 261 из 295 тестов, что значительно сократило время на их выполнение. В документе также рассматриваются проблемы и уроки, извлеченные из процесса автоматизации.
More Related Content
Similar to Автоматизация 0.0: 0 - бюджет, 0 - опыт программирования
![[JAM 1.1] Testing not for Fun (Evgeny Kaziak)](https://cdn.slidesharecdn.com/ss_thumbnails/testingnew-110307033017-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
Автоматизация 0.0: 0 - бюджет, 0 - опыт программирования
- 1. Software quality assurancedays 22 Международная конференция по вопросам качества ПО sqadays.com анкт-Петербург. 17–18 ноября 2017 Дарья Шишкова T-Systems RUS. Санкт-Петербург, Россия Автоматизация 0.0: 0 – HR-бюджет, 0 - опыт программирования
- 2. Автоматизация 0.0: 0– HR-бюджет, 0 - опыт программирования История проекта и команды Проект: Системный тест одного из внутренних приложений для техников Deutsche Telekom Система: • База данных Oracle • Десктопное приложение • Вэб-приложение для администрирования • Коробочный продукт комании Click Software для назначения заданий (вэб-приложение, Silverlight) • Симуляторы партнерских систем
- 3. Автоматизация 0.0: 0– HR-бюджет, 0 - опыт программирования История проекта и команды В связи с запланированной технической миграцией приложения в 2014 году возникла необходимость автоматизировать регрессионные тесты.
- 4. Автоматизация 0.0: 0– HR-бюджет, 0 - опыт программирования Описание проекта и команды На момент начала автоматизации: • Команда состояла из трех тестировщиков (middleX1, juniorX2) • Команда приняла участие в двух релизах, включавших в себя только тестирование новых требований • Опыт автоматизации в команде – отсутствовал
- 5. Автоматизация 0.0: 0– HR-бюджет, 0 - опыт программирования Выбора инструмента Для автоматизации регрессионных тестов был выбран open source инструмент – Sikuli http://sikulix.com/
- 6. Автоматизация 0.0: 0– HR-бюджет, 0 - опыт программирования Выбора инструмента Технические причины: • Особенность десктопного приложения, не позволявшая «добраться» до ряда элементов средствами инструментов типа Winium • Особенности Silverlight приложения, не позволявшие получить x-path’ы элементов
- 7. Автоматизация 0.0: 0– HR-бюджет, 0 - опыт программирования Выбора инструмента
- 8. Автоматизация 0.0: 0– HR-бюджет, 0 - опыт программирования Выбора инструмента Финансовые причины: • Отсутствие времени и финансовой возможности на введение в проект опытного специалиста по автоматизации • Отсутствие времени на проведение подготовки имеющихся сотрудников к использованию платных инструментов (типа Ranorex)
- 9. Автоматизация 0.0: 0- HR- бюджет, 0 - опыт программирования Процесс работы Что использовалось: • Sikuli IDE • Jython Позже добавились: • Selenium IDE/WebDriver • Soap UI
- 10. Автоматизация 0.0: 0- HR- бюджет, 0 - опыт программирования Грабли №1 Переиспользование кода
- 11. Автоматизация 0.0: 0- HR- бюджет, 0 - опыт программирования Грабли №1
- 12. Автоматизация 0.0: 0- HR- бюджет, 0 - опыт программирования Грабли №1
- 13. Автоматизация 0.0: 0- HR- бюджет, 0 - опыт программирования Грабли №1 Пара идей о том как можно было этого избежать: - Взять время на изучение «хороших практик» - Взять время на анализ тестов
- 14. Автоматизация 0.0: 0- HR- бюджет, 0 - опыт программирования Грабли №2 Выбор подходящих инструментов:
- 15. Автоматизация 0.0: 0- HR- бюджет, 0 - опыт программирования Грабли №2 Как можно было этого избежать: – не зацикливаться на одном инструменте, даже если он себя хорошо зарекомендовал
- 16. Автоматизация 0.0: 0- HR- бюджет, 0 - опыт программирования Грабли №3 Подробное логирование
- 17. Автоматизация 0.0: 0- HR- бюджет, 0 - опыт программирования Грабли №3 VS
- 18. Автоматизация 0.0: 0- HR- бюджет, 0 - опыт программирования Грабли №3 Как можно было этого избежать: – Использовать логирование, собственно
- 19. Автоматизация 0.0: 0- HR- бюджет, 0 - опыт программирования Результаты Технические: •Автоматизировано 261 из 295 регрессионных тестов •Время, затрачиваемое на прогон – 40 часов •Время на поддержку – около 200 часов (зависит от количества изменений) •Прогон регрессионных тестов вручную занял бы приблизительно 600 часов на версию при команде 6 человек
- 20. Автоматизация 0.0: 0- HR- бюджет, 0 - опыт программирования Смотрите также Другие доклады SQA-Days, посвященные Sikuli: • Sikuli Script – идеальный инструмент для обучения автоматизации: http://sqadays.com/ru/talk/16553 • Практическое применение Sikuli Script в автоматизации тестирования: http://sqadays.com/ru/talk/27521
- 21. Автоматизация 0.0: 0- HR- бюджет, 0 - опыт программирования Спасибо за внимание Дарья Шишкова T-Systems Rus Skype: dasha.shishkova E-mail: daria.shishkova@t-systems.ru http://www.t-systems.ru
Editor's Notes
- #2 Добрый день, коллеги. Меня зовут Дарья, я старший эксперт по тестированию в компании Т-Системз. И сегодня я хочу поделиться с вами рядом выводов из истории внедрения автоматизации в одном из проектов, которые, могут пригодится людям, начинаюшим свой путь в автоматизации или просто интересующимся этой темой.
- #3 И так, коротко о проекте: (текст слайда)
- #4 (текст слайда)
- #5 (текст слайда)
- #6 Текст слайда + что делает Сикули – она распознает видимые изображения на экране и может имитировать действия пользователя.
- #7 Для выбора Сикули было несколько причин: (текст слайда)
- #8 Для выбора Сикули было несколько причин: (текст слайда)
- #10 Селениум для автоматизации одного из вэб приложений, Соап в качестве симулятора одной из партнерских систем
- #11 Изначально мы брали тест из регрессионного сета и просто последовательно «переводили» все шаги на Jython. Через некоторое время мы вынесли в отдельные модули логины в разные системы и переиспользовали их в тестовых скриптах. Однако в прошлой весной, с обновлением Windows «внезапно» изменилось начертание шрифта. То есть шрифт остался преждним, но буквы стали чуть жирнее и Сикули отказалась их узнавать. Это привело к достаточно большому, не запланированному рефакторингу
- #12 Изначально мы брали тест из регрессионного сета и просто последовательно «переводили» все шаги на Jython. Через некоторое время мы вынесли в отдельные модули логины в разные системы и переиспользовали их в тестовых скриптах. Однако в прошлой весной, с обновлением Windows «внезапно» изменилось начертание шрифта. То есть шрифт остался преждним, но буквы стали чуть жирнее и Сикули отказалась их узнавать. Это привело к достаточно большому, не запланированному рефакторингу
- #14 К первому пункту могу только добавить, что далеко не в каждой ситуации действительно есть необходимость изобретать велоспед. Что касается анализа тестов – он должен был выявить общие шаги для большого количества тестов, и дать базу для переиспользования.
- #15 Как говорилось выше, небольшое изменение, даже не связанное с изменениями в приложении обернулось незапланированным рефакторингом. Что дало нам возможность и пинок не только переосмыслить структуру тестов, но и взглянуть внимательнее на используемые тулы. Как говорилось выше, два наших приложения были вэб приложениями. Одно из них использовало Silverlight, что привело к использованию Сикули для автоматизации обоих вэб приложений, но это было Совершенно не обязательно для второго приложения и, в сложившейся ситуации, было решено переписать автоматизацию регрессии второго приложения с помощью Selenium.
- #16 Текст слайда + кроме того и тут пригодится краткое ревью best practice. Однако, важно не закопаться во всем многообразии существующих тулов.
- #17 Однажды у нас отвалился тест на 293 строки, в котором логи, например, написаны только для циклов. И вот вроде бы и не сложно разобраться в том, что пошло не так, если хорошо знаешь систему, но во первых – это лишние временные затраты, и абсолютно не дружелюбно по отношению к тем кому в будущем будет нужно запускать наши тесты и анализировать результаты.
- #20 Кроме уроков котороые мы извлекли из этого поекта, у нас получилось следующее: Текст слайда + время затрачиваемое на поддержку - .... Зависит от количества изменений, произошедших в функциональности. В нашем случае, новые требования по функциональности приходят три раза в год.
- #21 Для тех кого заинтересовала конкретно Сикули, на конференции уже было несколько интересных докладов, ссылками на которые я хочу поделиться.