Зубович Вадим, Минск. Опыт в IT более 5 лет, работает в компании ISSoft, специализация: разработка (.NET C# ASP\MVC, WPF, WinForm, Java) и автоматизация функционального тестирования програмного обеспечения (Web, Desktop, Mobile) и тестирования производительности (Web).
«Сравнительный анализ инструментов для автоматизации тестирования мобильных приложений». Development секция. Отделение тестирования.
Мобильные платформы уже набрали огромную популярность, и продолжают наращивать обороты. Ни один разработчик уже не обходит стороной мобильные приложения и автоматизация тестирования в этой сфере актуальна как никогда.
В настоящем докладе мы рассмотрим наиболее популярные и перспективные инструменты для автоматизации тестирования приложений для мобильных операционных систем iOS, Android и WindowsPhone, проведем анализ их особенностей и возможностей, основываясь на опыте их использования в рамках реальных проектов, а также подведем общий итог с рекоммендациями по выбору того или иного инструмента.
«Централизованное управление тестами с помощью TestLink». Development секция. Отделение тестирования.
Эффективное управление тестами это не только грамотный тим-менеджмент, это еще и правильный учет, контроль результатов и своевременное и централизованное обновление информации о тестах для всех участников процесса и силами всех участников процесса.
Достичь этого невозможно без системы управления тестами, позволяющей эффективно распределить права и обязанности участников и обеспечить постоянное поддержание информации о тестах в актуальном состоянии.
TestLink – бесплатный инструмент, предназначенный именно для выполнения этой задачи.
В рамках доклада мы рассмотрим:
1. Как устроен TestLink
2. Как построить работу с TestLink
3. Как создавать информативные отчеты в TestLink
4. Как наладить связь между автоматизацией и TestLink
4. Наши требования
• Поддержка Continuous integration
• Простота освоения и внедрения
• Интеграция с готовым решением
• Поддержка автоматизированных тестов
• Минимальная стоимость лицензии
5. Возможности
• Легкая интеграция с проектами на разных языках
программирования посредством TestLink API (C#,
Java, Python)
• Возможна реализация Continuous integration с
помощью совместимых сторонних инструментов
(Jenkins, Nant)
• Поддержка Requirement-based testing с
последующим формированием отчетов
• Поддержка автоматизированных тестов (Regression
test-plans + Automated test-case attribute)
7. Пользовательские роли
• Guest (guest) – только просмотр тест-кейсов, отчетов и параметров.
Ничего не может редактировать.
• Test Executor (tester) – имеет возможность просматривать и выполнять
тесты, назначенные ему.
• Test Designer (test designer) – может просматривать и редактировать
спецификации и требования.
• Test Analyst (senior tester) – просматривает, создает, редактирует и
удаляет тест-кейсы, выполняет их. Не может управлять тест-планами и
проектами или распоряжаться правами.
• Test Leader (leader) – те же права, что и у аналитика, кроме того может
управлять тест-планами и назначать права.
• Administrator (admin) – полный набор прав (как у лидера, плюс
возможность управлять проектами и пользователями).
* Права пользователей можно редактировать и создавать свои
собственные роли, предоставляя им любой набор прав.
8. Сущности TestLink
• Test Case – описание тест-кейса в виде шагов и ожидаемых
результатов.
• Test Suite (Test Case Suite) – набор тест-кейсов, позволяющий
структурировать все тесты в логичной форме.
Например: “LoginTests”, “ValidationErrorTests”, “MainMenuTests” и т.п.
• Test Plan – создается при переходе к выполнению тестов. Тест-планы
состоят из какого-либо набора тест-кейсов и/или TestSuite текущего
проекта.
Например: “Regression”, “Manual”, “Automation”, “Daily” и т.п.
• Test Project – ключевая единица в TestLink. Проект существует на
протяжении всего цикла тестирования и соответствует тестируемому
приложению. Тестовый проект в течение жизненного цикла может
сменить несколько версий и развиваться вместе с приложением.
Например: “OurWebPortal”, “Calculator” и т.п. Как правило носит имя
приложения, или включает его имя в название.
9. Вспомогательные сущности TestLink
• Build – Соответствует билду, или серьезной модификации
тестируемого приложения.
• Platform – платформа, на которой производится тестирование. В
качестве платформы может выступать операционная система
(Windows, Linux etc.), браузер для веб-приложений (Chrome, Firefox
etc.), различные варианты серверов (Apache, Tomcat etc.) и баз данных
(MySql, MSSQL etc.)
• Keyword – ключевое слово, служащее для группировки тест-кейсов по
какому-либо признаку.
Например “UI-Tests”
• Requirements – требования к приложению, которые необходимо
покрыть тестами (для requirement-based testing). К ним
осуществляется привязка тест-кейсов, на основании которой
производится формирование отчета о покрытии требований.
11. Типовой сценарий
• Администратор создает тестовый проект
“Fast Food” и двух пользователей: Adam, с
правами “leader” и Bela, с правами “senior
tester”.
12. Типовой сценарий
• Лид Adam импортирует требования к
приложению и для части этих требований
генерирует пустые тест-кейсы. Разделяет их
на два Test Suite: “Fish” и “Chips”.
13. Типовой сценарий
• Тестировщик Bela описывает тестовый
сценарий (наполняет содержимым пустые
тест-кейсы), используя спецификацию,
которая разбита на два тест-сюита.
14. Типовой сценарий
• Adam создает ключевое слово “Regression
testing” и назначает это слово 10-ти из этих
тест-кейсов.
15. Типовой сценарий
• Адам создает тестовый план “Fish & Chips
1”, билд “Fish 0.1” и привязывает все тест-
кейсы из сюита “Fish” к этому тест-плану.
Также он относит себя и Bela к ресурсам
этого плана.
16. Типовой сценарий
• Разработчики выпустили первый билд.
Adam и Bela выполнили тесты со
следующим результатом: 5 passed, 1
failed, 4 blocked.
17. Типовой сценарий
• Разработчики выпустили новый билд “Fish
0.2” и Bela выполняет только зафейленные
и заблокированные тесты. На этот раз все
тест кейсы завершены успешно.
Дополнительно выполняется прогон всех
тест-кейсов с ключевым словом “Regression
testing”.
18. Типовой сценарий
• Менеджер проекта хочет посмотреть на
результаты. Админ объясняет ему, как
создать свой гостевой аккаунт прямо со
стартовой страницы. После создания
аккаунта у менеджера есть гостевой доступ,
позволяющий просматривать все тест-
кейсы и результаты. Он видит, что все тесты
пройдены успешно в общем отчете, и что
были проблемы в первом билде “Fish 0.1” в
отчете по нему.
19. Типовой сценарий
• Позднее, когда разработчики добавили
функционал “Chips”, Adam создает тест-
план “Fish & Chips 2”. В качестве шаблона он
может использовать первый тест-план. Все
тест-кейсы и роли при этом будут
автоматически добавлены. Он создает
новый билд “Fish 1.1” и привязывает все
тест-кейсы “Chips” к нему.