Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде
•Als PPT, PDF herunterladen•
0 gefällt mir•853 views
Доклад Дениса Марковцева на конференции SQA Days-21 www.sqadays.com
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде
Ähnlich wie Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде (20)
Mehr von SQALab
Mehr von SQALab (20)
Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде
- 1. Software quality assurance days 21 Международная конференция по вопросам качества ПО sqadays.com Москва. 26–27 мая 2017 Денис Марковцев Inflectra Corporation. Москва, Россия Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде
- 2. 2Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде инструменты для разработчиков и тестировщиков
- 3. 3Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде инструмент для автоматизации тестирования UI Desktop. Web. Mobile.
- 4. 4Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде
- 5. 5Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде Реальная задача Опыт решения
- 6. 6Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде Задача реальная Пример демонстрационный Почему?
- 7. 7Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде Outlook плагин для Офис 365
- 8. 8Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде Работает в десктоп Outlook и
- 9. 9Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде Зачем тестировать UI? Есть ли необходимость?
- 10. 10Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде Внешняя среда меняется
- 11. 11Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде Плагин не загружается
- 12. 12Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде Плагин отображается некорректно
- 13. 13Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде Приложение Город Тип клиента Результат Браузер Нью Йорк платный работает Браузер Гонконг пробный не работает Outlook Москва пробный работает Outlook Лондон платный не работает Зависимость от типа клиента и его географического положения
- 14. 14Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде Матрица контролирует нас
- 15. 15Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде Внешняя среда постоянно улучшается и мы не можем это контролировать
- 16. 16Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде Важна скорость реакции
- 17. 17Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде Автоматические UI тесты нужны
- 18. 18Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде
- 19. 19Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде Outlook плагин - веб приложение, даже в десктоп версии
- 20. 20Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде //span[@class='badge ng-binding']
- 21. 21Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде Локаторы Десктоп: контейнер IE XPATH Браузер: xpath_to_frame XPATH
- 22. 22Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде Одни и те же тесты для Outlook и браузеров
- 23. 23Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде Загрузка писем Запуск почтового клиента Авторизация Открытие письма Активация плагина Тест Завершение процесса
- 24. 24Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде Microsoft Active Accessibility UI Automation Managed Java Access Bridge
- 25. 25Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде Немного деталей
- 26. 26Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде SeS('Mail_Folders') .DoClickNode(userName + ";Inbox"); JavaScript Объект Локаторы Свойства Методы
- 27. 27Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде «Без программирования»
- 28. 28Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде Результаты проекта тестирования
- 29. 29Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде Другие проекты
- 30. 30Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде Тестовый набор регрессионное тестирование
- 31. 31Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде Мониторинг
- 32. 32Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде Один инструмент Один язык Единый подход Отчеты
- 33. 33Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде Get Rapise https://www.inflectra.com/SQADAYS21.aspx GitHub https://github.com/Inflectra/office365-outlook- plugin-ui-testing Email denis@inflectra.com
Hinweis der Redaktion
- Добрый день. Спасибо что пришли. Меня зовут Денис. Так сложилось, что уже больше 15 лет я занимаюсь разработкой инструментов для программистов и тестировщиков. В разное время это были и компиляторы, и интегрированные среды разработки, инструменты для нагрузочного и функционального тестирования.
- Сейчас я работаю в компании Inflectra. Inflectra – один из ведущих производителей ПО для управления жизненным циклом приложений и функционального тестирования приложений с графическим интерфейсом.
- В настоящий момент я занимаюсь автоматизацией тестирования пользовательского интерфейса. В Inflectra мы делаем Рапизу - это среда разработки и выполнения автоматических тестов для веб, десктоп и мобильных приложений. Продукт востребован на зарубежных рынках, и до сегодняшнего дня не был представлен в России. Мы в компании подумали, что стоит восполнить этот пробел и посмотреть, что из этого выйдет.
- Просто рассказывать об инструменте и его возможностях было бы информативно, но несколько скучно. Для этого существуют вебинары, которые можно слушать сидя в тапочках в любимом кресле.
- Поэтому я расскажу о реальной задаче, которую мы помогли решить с помощью Рапизы. Опыт, которым я хочу сегодня поделиться, довольно универсален, и его можно применить и в других проектах, пользующихся другими инструментами, включая бесплатные.
- Мы часто помогаем клиентам решать сложные вопросы в организации процесса тестирования. Как правило наши клиенты - это не магазины электронной торговли и не производители ПО для массового пользователя Часто это крупные компании, использующие ПО для поддержки внутренних бизнес процессов. Это могут быть решения для финансового сектора, управления производством, здравоохранения, например, банки крови. Как правило такие клиенты весьма закрыты и не спешат давать доступ к своим внутренним системам. При этом у них достаточно высокие требования к качеству ПО. И они часто обращаются за помощью, так как ПО достаточно сложное, реализованное с применением множества технологий, различных фреймворков и языков программирования. Поэтому иногда наша деятельность напоминает удаленные хирургические операции. Задачи стоят сложные и мы не всегда имеем возможность работать с системой напрямую. Мы даже не всегда знаем какие показатели были достигнуты клиентом в процессе тестирования. Часто это просто бинарное значение - клиент доволен - клиент не доволен. Почти всегда подписывается соглашение о конфиденциальности, что не дает нам права использовать данные о клиенте и его приложении в целях демонстрации возможностей инструмента. Поэтому сегодня я буду рассказывать о реальной задаче, но на демонстрационном примере, который мы подготовили специально для конференции. Это позволит вам не только получить информацию, но и при желании запустить демонстрационные примеры самим. Наш пример состоит из свободно доступного приложения, инструмента и тестов. Все это можно потрогать руками.
- Итак, о задаче. Тестируем Outlook плагин для Офис 365. Outlook – почтовый клиент от компании Микрософт. А Офис 365 – это Микрософт офис в облаке. Плагин называется TextMiner, он находит в тексте письма подписи и автоматически извлекает такую информацию, как имя, адрес, должность, название компании и т.д.
- Outlook плагин - это по сути веб приложение, которое может работать как в браузере, так и в десктоп версиях почтового клиента Outlook под Windows и Mac
- Зачем делать автоматические тесты пользовательского интерфейса в данном случае? Все мы знакомы с пирамидой тестирования и знаем, что данный вид тестирования является наиболее сложным и дорогим. Можно ли сэкономить ресурсы? Есть ли альтернатива? Бэкенд можно проверить модульными тестами. Можно сделать интеграционные тесты и закидывать письма в бэкенд с помощью CURL (в народе Курл). Это понятно, и не вызывает трудностей. Вопрос, что делать с фронтендом, с пользовательской частью? Хотя пользовательский интерфейс и достаточно прост есть одно "Но".
- Плагин работает во внешней среде, которая может измениться в любую минуту. И то, что работало минуту назад, просто перестает работать. Последствия неожиданных обновлений на стороне Микрософт могут быть достаточно разнообразными. Вот некоторые из них.
- Ночной кошмар для разработчика – получить отчет о проблеме от пользователя в виде – «ничего не работает». Причиной может быть проблема во взаимодействии с облачным API. Что-то не загрузилось, что-то изменилось.
- Может поехать верстка. Такая ситуация может возникнуть в результате изменения размеров фрейма, в который грузится плагин или проблем с получением данных из почтового ящика.
- Причем появление указанных проблем может зависеть от типа клиента и его географического положения. Причины этих явлений кроются в облачной природе такого сервиса как Офис 365. Разные аккаунты сидят на разных версиях/сборках почтового сервера. Причем вероятно, что обновления сначала выкатываются для не платящих клиентов и в выбранных регионах. Например, пользователи из Европы могут испытывать проблемы с загрузкой плагина, в то время как для клиентов из северной Америки все может по прежнему прекрасно работать. Также аккаунты, полученные в разное время, могут оказаться привязаны к различным версиям серверной части.
- Таким образом возникает ситуация, когда мы не контролируем происходящее на сто процентов. Мы в облаке и оно принимает решения за нас. В случае десктоп приложений хотя бы есть возможность следить за анонсами выхода обновлений операционной системы и своевременно проверять работоспособность приложения на виртуальных машинах с заданной нами конфигурацией. В облаке же нет возможности контролировать версию программного обеспечения, с которым мы работаем. Так бывает конечно не всегда, например, в коммерческих облачных системах, сопровождающих производство и продажи, где сбой в работе ПО приводит к явным финансовым потерям, о предстоящих обновлениях и изменениях предупреждают заранее и дают возможность адаптироваться. К сожалению, в случае с Офис 365 – не так. Усугубляет ситуацию также современная тенденция выпускать частые релизы. Хотя всем разработчикам знакома ситуация, когда исправление проблемы в одном модуле приводит к появлению новых в других частях системы. Потому что другие модули рассчитывали на «неправильное» поведение.
- Возникает парадокс. Нам делают как лучше, а получается как всегда. И глядя на возникающие при эксплуатации плагина проблемы, иногда хочется сказать словами политического классика: «Никогда такого не было – и вот опять!»
- В подобной ситуации важна скорость реакции и возможность вовремя потушить пожар. И очень желательно обнаружить проблему раньше пользователей.
- Поэтому необходим минимальный набор автоматических UI тестов, который бы проверял работоспособность плагина в десктоп версиях Outlook и в различных браузерах. Причем этот набор необходимо запускать постоянно, в режиме мониторинга, и для разных типов аккаунтов. А если плагин рассчитан на глобальную аудиторию, то и в различных географических зонах, чтобы увидеть проблемы максимально быстро и каким-то образом отреагировать. У меня есть вопрос к экспертам из зала. Стали бы вы делать автотесты в подобной ситуации? Если нет, то какова альтернатива? Если да, то какими бы инструментами стали пользоваться?
- Наш клиент в этой ситуации использовал Рапизу. Я не буду показывать код тестов и сам инструмент в подробностях. На это просто не хватит времени. В конце доклада я расскажу как бесплатно получить Рапизу и скачать тесты. Чтобы запустить тестовый набор вам понадобится только аккаунт Офис 365 (вы можете легко подписаться на пробную версию) и установка плагина TextMiner.
- Итак, перейдем непосредственно к тестовому набору. Напомню, что плагин – это веб приложение. Даже в десктоп версии Outlook загружает плагин во встроенный браузер.
- Поэтому локатор элемента интерфейса плагина не зависит от контейнера. Во всех случаях это один и тот же XPATH для заданного элемента.
- Чтобы добраться до элемента на десктопе необходимо подключиться к встроенному в процесс Outlook браузеру (на Windows это Internet Explorer), а затем использовать XPATH локатор. В случае с обычным браузером используется XPATH фрейма, в который загружен плагин, а затем XPATH элемента. Это позволяет построить тестовую систему таким образом, что тест записанный для браузера, можно без изменений запускать на десктоп.
- Таким образом клиент смог сэкономить и время и ресурсы необходимые на разработку и поддержку тестов. А дополнительную экономию дала возможность записывать действия пользователя при работе с приложением, в этом случае локаторы для элементов вычисляются автоматически (хотя и в некоторых случаях требуют обработки напильником).
- Отдельно для десктопа и браузеров реализовали только несколько вспомогательных процедур. Например навигацию в почтовом клиенте с целью открыть определенное письмо. Загрузку писем в систему реализовали с помощью встроенного в Рапизу SOAP клиента.
- Одной из решенных задач была автоматизация Outlook для Windows. Той его части, которая использовалась для открытия нужного письма в почтовом ящике и запуска плагина. Windows предлагает несколько технологий, для автоматизации тестирования десктоп приложений. Это Microsoft Active Accessibility. Технология доступная на Windows с конца прошлого века. Она была придумана чтобы помочь людям с ограниченными возможностями использовать компьютер. - UI Automation – последователь MSAA, но уже разработанный с мыслью о поддержке инструментов для автоматического тестирования пользовательского интерфейса. Наибольшая свобода при тестировании на Windows достигается для .NET (managed) приложений. В этом случае возможно внедриться в процесс приложения и получить доступ к классам и объектам. Java Access Bridge – компонент от Oracle, делающий возможными тестирование интерфейса Java приложений на Windows. Рапизв поддерживает все перечисленные технологии. Поэтому было из чего выбирать. Почтовый клиент Outlook не является Java или .NET приложением, поэтому выбор был очевидным – использовать UI Automation.
- Теперь немного деталей для тех, кто захочет попробовать демонстрационный фреймворк своими руками или понять как инструмент устроен изнутри.
- Рапиза работает с объектами, соответствующими элементам интерфейса. У объектов есть локаторы, свойства и методы. Локаторы используются для автоматического поиска элементов в приложении. Свойства и методы позволяют тестировщику, не вникая в низкоуровневые детали, узнать необходимую информацию об элементе, например, получить координаты, текст, снимок экрана. и взаимодействовать с ним, например, раскрыть нужный узел дерева, выбрать элемент из списка, нажать кнопку, ввести текст. Этот подход реализован для всех типов приложений: десктоп, мобильных и веб-приложений. В заголовке слайда вы видите код, сгенерированный Рапизой в процессе записи теста. Единственное что изменили вручную – параметризировали почтовый адрес. Здесь ‘Mail_Folders’ – идентификатор объекта, к нему привязан локатор, который вы здесь не видите, он хранится отдельно. Тип объекта – дерево, поэтому у него есть метод DoClickNode, который позволяет, указав путь к узлу, кликнуть на него.
- Часто клиенты просят, чтобы к созданию и модификации тестов можно было бы привлечь людей, не занимающихся программированием. Это происходит по разным причинам. Это могут быть люди, пришедшие из ручного тестирования Или аналитики, менеджеры, которые хорошо разбираются в предметной области (например, в технологии запуска атмосферных зондов) и не занимаются написанием кода) В таких случаях команда может состоять из тестировщиков-программистов, которые занимаются локаторами и эмуляцией действий пользователя (для них ПО – просто набор форм и элементов) и людей, которые занимаются непосредственной реализацией тестовых сценариев и работают на более высоком уровне абстракции. Для тестировщиков второго типа Рапиза предоставляет возможность создавать тестовые сценарии используя электронные таблицы. Примеры таких таблиц вы видите на экране. В первом примере вызывается сценарий, реализованный программистом (MyLogin). Во втором заполняется и отправляется веб-форма (в библиотеке регистрируется новая книга).
- Перейдем теперь к результатам проекта тестирования. Удалось ли достичь поставленной цели и можно ли использовать полученный опыт где-нибудь еще? Итак, основные результаты из реального проекта. В произвольном порядке важности.
- Аналогичный описанному подход оказался применим и для других приложений. Клиент тестировал ERP систему Dynamics AX. Это десктоп приложение. Большой конструктор. Одним из кирпичиков в нем оказался встраиваемый браузер Chromium Embedded Framework. Нам удалось подключиться к нему как реальному браузеру и тестировщики работали с содержимым как веб приложением, используя XPATH локаторы.
- Дополнительный плюс. Тестовый набор, разработанный заказчиком, используется им также для регрессионного тестирования. Тем самым тестировщики заработали благодарность от разработчиков.
- Думаю, это главный результат. С помощью разработанного тестового покрытия стало возможным постоянное наблюдение за работоспособностью плагина. Это принесло свои плоды и позволило своевременно поймать ряд проблем связанных с изменением внешней среды - обновлениями от Микрософт. Также удалось поймать определенные шаблоны в поведении внешней среды. И это позволило службе поддержки заказчика лучше взаимодействовать с пользователями. Пример шаблона – временные перебои - иногда кнопка запуска плагина (вообще всех плагинов в Outlook 365) просто пропадает и его невозможно открыть.
- Тестовый набор полностью реализован в рамках одного инструмента. Весь код тестов написан на JavaScript. На одном языке, который очень распространен и хорошо известен. Используется единый объектный подход для работы с элементами интерфейса на десктопе и в вебе. Настроен постоянный запуск тестов, сбор и анализ телеметрии, построение отчетов. Такой тестовый набор легко поддерживать и дополнять. Даже если сменится команда тестировщиков. Вообще к конечной цели часто есть много путей. И в этом проекте тестирования заказчик мог применить и другие инструменты. Разница в том, насколько быстро и качественно можно добиться желаемого результата. Мы считаем, что Рапиза справилась неплохо. Дополнительно в пользу инструмента сыграло то, что Рапиза является частью продуктовой линейки, включающей инструменты для планирования и удаленного запуска тестов, отслеживания дефектов и требований – и это дало дополнительные преимущества в проекте. В любом случае, каким инструментом пользоваться - в конечном счете решать вам.
- Спасибо за внимание. Как и обещал - ссылка на страницу, где можно бесплатно получить Рапизу (там нужно оставить свой мейл, на него придет письмо с ключом и ссылкой для скачивания). Эта возможность будет активна две недели. Также ссылка на ГитХаб репозиторий с кодом тестов. Эта ссылка есть еще в аннотации к докладу. Если хотите связаться со мной лично – пишите на почту. У нас еще есть время на вопросы и ответы. Пожалуйста.