Sef Ikhelis

571 views
531 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
571
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Типы фреймворков:Для конкретного продукта/компании (domain-specific)Общей направленности (для широкого использования)
  • *Сложное web-приложение (http/https, Ajax)*Различные приложения (проекты), функционалы, локали, версии (релизы)*Тестирование на разных серверах*Более 40 локализаций, включая иероглифические, постоянное добавление новых локалей* (Гибкость) Каждая локаль имеет свои конфигурационные настройки, форматы дат, цен, и тд
  • *Частые выпуски новых версий (releases),необходимость тестирования различных версий и различных окружений одновременно*Необходимость в автоматизации различных функционалов, регрессионное тестирование на всех локалях+Распределенная команда -> нужен общий подход к автоматизации, централизованное управление
  • *парарллельное выполнение*масштабируемость -> различные клиентские конфигурации*поддержка разных проектов и версий (разные ветки в репозитории и гибкий UI для управления)*гибкость работы с данными (XLS, XML, MS SQL, MySQL)*поддержка разных environments, локалей, настроек
  • *Effective test designs (functional decomposition, separate data from code, PageObject pattern, DSL, given-when-then, etc)*Gain more skills: about web app design and implementations, work in pair with developers, etc*Increase testability (DOM structure, unique IDs, etc)*Speed up execution: testable app to identify elements faster, parallel execution, reduce manual interaction – integrate into source control system*Informative tests (results, logs)*I suggest you create unit tests for more involved support functions and for ‘driver’ code, rather than for the tests themselves.*Simple navigation test suite for your GUI layers, increase it continuously along with adding new UI elements to your tests
  • *design for maintenability and sustainability
  • Sef Ikhelis

    1. 1. Реализация тестового фреймворка на основе OPEN-SOURCE инструментов Александр Ихелис. EPAM Systems
    2. 2. Предыстория • Архитектура и требования к фреймворкам • Особенности работы в open-source • Watir – драйвер браузера • Практическая реализация фреймворка • Круглый стол: Использование open-source инструментов тестирования
    3. 3. Содержание  Тестовый фреймворк – как много в этом слове...  Постановка задачи  Архитектура и решение входных условий  Полезные решения и практики  Рекомендации
    4. 4. Тестовый фреймворк – как много в этом слове... Тестовый фреймворк – инфраструктура, обеспечивающая автоматизацию тестирования Основные цели: • Единая концепция создания и управления авто-тестами • Упрощенное написание тест кейсов • Целостная система драйверов, модулей, библиотек, источников данных, результатов • Максимальное повторное использование • Минимальные усилия на поддержку тестов
    5. 5. Выбор и разработка фреймворка Разработка фреймворка – это разработка программного комплекса: • Анализ требований к автоматизации и к средству тестирования • Анализ приложения – кандидата для автоматизации • Качественные характеристики фреймворка • Набор возможностей фреймворка • Выбор средств реализации • Дизайн архитектуры, разработка, отладка, документация • Поддержка и развитие
    6. 6. <Оболочка> <Приложение> Раннер Отчеты Язык <Тест кейсы> Черный TC_1 Ящик Библиотеки Драйвер TC_2 Тесты: TC_1 Passed Действия Отчеты TC_2 Failed Проверки Данные
    7. 7. «Боевой робот» в open-source
    8. 8. «Боевой робот» в open-source Гибкость и расширяемость
    9. 9. Риски open-source средств: бесплатный сыр бывает только в мышеловке…
    10. 10. Построение фреймворков в open-source Особенности • Необходимо понимать «анатомию» тестовых средств и фреймворков • «Заботимся о деталях сами»: самостоятельная разработка многих компонентов и интерфейсов фреймворка • Open-source средства дают свободу и гибкость, позволяют создавать легко расширяемые фреймворки
    11. 11. Содержание  Тестовый фреймворк – как много в этом слове...  Постановка задачи  Архитектура и решение входных условий  Полезные решения и практики  Рекомендации
    12. 12. Общие требования к автоматизации www.hotels.co.uk QA www.hotel.hu www.hotels.ru … Staging www.expedia.co.uk www.expedia.ru … • Сложное web-приложение Production • Различные приложения, функционалы, локали (40+) • Разные сервера
    13. 13. Общие требования к автоматизации R10 R11 R10.1 R10.2 Тестовый набор 1 Тестовый набор 2 Время 1 ~ Время 2 Тестовый набор 2 > Тестовый набор 1 Локали 2 > Локали 1
    14. 14. Общие требования к автоматизации • Распределенная команда  необходим общий подход и централизованное управление тестированием
    15. 15. Содержание  Тестовый фреймворк – как много в этом слове...  Постановка задачи  Архитектура и решение входных условий  Полезные решения и практики  Рекомендации
    16. 16. Распределенная архитектура – это реально
    17. 17. Архитектура фреймворка на основе Watir Консоль Сервер Код БД Клиент 1 Web- интерфейс … Репозиторий Browser Клиент: Режим отладки Код Клиент K Watir Ядро
    18. 18. Архитектура фреймворка на основе Watir Серверная часть: • Версии 1.*: Apache/PHP + MySQL • Версии 2.*: Mongrel/ruby-on-rails + MySQL • Конфигурация в Production окружении (требования безопасности): MS IIS/ruby-on-rails + MS SQL Server Клиентская часть (масштабируемость путем добавления клиентов): • Ruby, Watir, Sponte gem (ядро фреймворка), рабочее окружение Cистемы управления версиями: • CVS, MS Perforce
    19. 19. Основные возможности фреймворка • Собственный драйвер тестов, централизованный и удобный запуск, распределенное выполнение на многочисленных клиентах с различной конфигурацией, свободная масштабируемость • Параллельное выполнение • Масштабируемость • Работа в режиме отладки (debug) • Гибкая расширяемость для новых тестовых окружений (серверов), локалей • Поддержка нескольких проектов и версий • Возможность создания data-driven сценариев из нескольких тестовых компонентов Scenario = (Test1 + Dataset1)+…+(Test i + Dataset j) • Удобный интерфейс, мощный механизм отчетов
    20. 20. Поддержка разных проектов и версий Web- интерфейс Фреймворк БД Репозиторий: *проекты *версии
    21. 21. Sponte: Запуск тестового набора
    22. 22. Sponte: Редактирование управляющих параметров и входных данных сценария
    23. 23. Содержание  Тестовый фреймворк – как много в этом слове...  Постановка задачи  Архитектура и решение входных условий  Полезные решения и практики  Рекомендации
    24. 24. Полезные решения и практики • Объектно-ориентированная структура и подход в тестировании, включая модель UI приложения • Создание бизнес слоя  тесты на DSL (Domain Specific Language) • Реализация различных интерфейсов для работы с внешними источниками данных (XLS, XML, Excel XML, MySQL, MS SQL Server), поддержка Unicode и конфигурационных, локализационных, тестовых данных для разных локалей • Design Patterns + Coding Convention  гибкий UI серверной части без необходимости описывать статически каждую UI страницу для управления разными тестами и тп
    25. 25. Идея OOP GUI layer patters + Domain Specific Language (Business Layer)
    26. 26. Поддержка разных environments, локалей, конфигурационных настроек БД приложения Файлы с данными (AUT) • Локализационные данные (форматы и тп) • Настройки конфигурации • Информация о поддерживаемых environments • локалях Фреймворк БД • URLs • Servers’ hosts
    27. 27. Полезные решения и практики • Расширение функционала Watir и драйвера браузера • Гибкая синхронизация с приложением (сложные страницы, Ajax вызовы, тестирование с включенной и отключенной поддержкой JavaScript в браузере) • Тестирование через HTTP протокол: рекурсивные тесты на нахождение broken-links • Работа с настройками браузера и соединения (cookies, cache, включение и отключение поддержки JavaScript, установка HTTP headers)
    28. 28. Содержание  Тестовый фреймворк – как много в этом слове...  Постановка задачи  Архитектура и решение входных условий  Полезные решения и практики  Рекомендации
    29. 29. Построение фреймворков в open-source Рекомендации • Используй стандартизированные интерфейсы и протоколы • Реализуй только то, что тебе необходимо. Поддерживай только необходимые тебе интерфейсы приложения • Твоя цель – тестирование, приносящее пользу проекту ВОВРЕМЯ • “It does not have to be perfect to be useful” • Будь в теме! • Популярные средства быстро развиваются • Часто поддерживаются только последние версии • Работай с разработчиками над тестируемостью приложения и альтернативными интерфейсами (если необходимо)
    30. 30. Построение фреймворков в open-source Рекомендации Относись к фреймворку и тестовому коду как к программному продукту • Хорошая и простая архитектура • Сначала простой код  тестирование  модульность • Регулярные ревью кода, рефакторинг, DRY • Стандарты кодирования • Комментарии • Контроль версий • Возможно, поддержка разных версий (branching) для разных версий (releases) тестируемой системы
    31. 31. Построение фреймворков в open-source Прогнозы Появляется необходимость в новом наборе навыков для инженера по автоматизации (Software Design Engineer in Test) • Навыки разработки и кодирования • Навыки архитектора • Навыки тестирования Рекомендуемое разделение обязанностей: • Разработчик ядра фреймворка и библиотек • Разработчик автоматических тестов
    32. 32. Благодарность • Bernard Miles, QA Manager and Architect, Expedia Limited, UK • Stanislaw Wozniak, Test Automation Engineer, Expedia Limited, UK • Sponte framework Lead Developer • Tamas Zombori, Test Automation Engineer, Epam Systems Inc, Hungary • Hcom Team Test Automation Engineer • Bret Pettichord, Lead developer for Watir and CTO of WatirCraft • Author and co-author of many outstanding and wholesome published works and articles (www.pettichord.com)
    33. 33. Контактная информация <epam> Ихелис Александр EPAM Systems ул. В. Хоружей, 29 220123 Минск, Беларусь почта: alex.ikhelis@gmail.com блог: http://alexikhelis.blogspot.com </epam>

    ×