Интеллектуальная система автоматизации тестирования на базе Groovy
•Transferir como PPTX, PDF•
0 gostou•784 visualizações
Доклад Андрея Пахомова и Сергея Аксененко, SQA Days-13, 26-27 апреля 2013, www.sqadays.com
Recomendados
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (20)
Semelhante a Интеллектуальная система автоматизации тестирования на базе Groovy
Semelhante a Интеллектуальная система автоматизации тестирования на базе Groovy (20)
Mais de SQALab
Mais de SQALab (20)
Интеллектуальная система автоматизации тестирования на базе Groovy
- 1. 1© Copyright 2013 EMC Corporation. All rights reserved. Интеллектуальная система автоматизации тестирования на базе Groovy Аксененко Сергей Пахомов Андрей Санкт-Петербургский центр разработок ЕМС
- 2. 2© Copyright 2013 EMC Corporation. All rights reserved. О чем мы будем говорить: Зачем «изобретать велосипед» Как спроектировать систему тестирования И как ее реализовать И о чем не будем: Универсальные решения на все случаи жизни Процессы тестирования Как мы все здорово протестировали
- 3. 3© Copyright 2013 EMC Corporation. All rights reserved. Зачем «изобретать велосипед»
- 4. 4© Copyright 2013 EMC Corporation. All rights reserved. Тестируемые продукты VMAX
- 5. 5© Copyright 2013 EMC Corporation. All rights reserved. Тестовый стенд Application Data Center A Data Center B Data Center CTest engine
- 6. 6© Copyright 2013 EMC Corporation. All rights reserved. Элементы идеальной тестовой системы Структура • Иерархия • Параметризация Сценарии • Простота и гибкость • Универсальность Структура • Иерархия • Параметризация Сценарии • Простота и гибкость • Универсальность Модель • Уровень абстракции • Адаптеры Конфигурация
- 7. 7© Copyright 2013 EMC Corporation. All rights reserved. Структура сценариев Структура Сценарии Модель Конфигурация • Иерархия • Параметризация • Простота и гибкость • Универсальность • Уровень абстракции • Адаптеры
- 8. 8© Copyright 2013 EMC Corporation. All rights reserved. Структура блоков скриптового сценария Suite Scenario Test Case Test Step Verification Action
- 9. 9© Copyright 2013 EMC Corporation. All rights reserved. Проектирования языка сценариев Структура Сценарии Модель Конфигурация • Иерархия • Параметризация • Простота и гибкость • Универсальность • Уровень абстракции • Адаптеры
- 10. 10© Copyright 2013 EMC Corporation. All rights reserved. Предметно-ориентированный язык (DSL) + Разделение логики сценариев и среды для их запуска + Создание и изменение сценариев силами QA - Дополнительная затрата ресурсов на разработку скриптового языка
- 11. 11© Copyright 2013 EMC Corporation. All rights reserved. Groovy как основа для создания DSL Интерпретация вместо компиляции Полная интеграция с JAVA Возможность перегрузки стандартных конструкций языка Лаконичность Поддержка со стороны основных IDE
- 12. 12© Copyright 2013 EMC Corporation. All rights reserved. Предметно-ориентированный язык Компоненты предметно- ориентированного языка groovy.lang.Script BaseSript Script Engine Filters Blocks Verifications • Бесконтекстные операции • Операторы • Структура блоков
- 13. 13© Copyright 2013 EMC Corporation. All rights reserved. DSL как средство агрегации знаний Знания DSL Model Groovy Библиотека знаний
- 14. 14© Copyright 2013 EMC Corporation. All rights reserved. Концепция фильтров Декларативно описывает свойства объекта Во время прогона теста выделяет коллекцию объектов модели Возможность комбинировать вместе несколько фильтров
- 15. 15© Copyright 2013 EMC Corporation. All rights reserved. Операции над множествами + * - Доменная область Примеры кода: • Figure.RED * Figure.Star • ((Figure.CIRCLE + Figure.TRIANGLE) * Figure.GREEN)
- 16. 16© Copyright 2013 EMC Corporation. All rights reserved. expected events in 1.min { every Host.PRODUCTION => Event.10203 } Логика проверок Expected Темпоральный оператор Время Квантор Фильтр Событие/ состояние
- 17. 17© Copyright 2013 EMC Corporation. All rights reserved. Проверки (expected блок) Темпоральные операторы – States (n1, n2 => s1 , Δt) – Events (n1, n2=>e1 || e2 , Δt) – Stability (n1,n2 => s1, Δt) n1 s0 s1 n2 s2 s1 n1 n2 Satisfied Satisfied n1 e1 n2 e2 Satisfied
- 18. 18© Copyright 2013 EMC Corporation. All rights reserved. Модель тестового стенда Структура Сценарии Модель Конфигурация • Иерархия • Параметризация • Простота и гибкость • Универсальность • Уровень абстракции • Адаптеры
- 19. 19© Copyright 2013 EMC Corporation. All rights reserved. Пример h1 h2 h3 h4 h5 SW1 SW2 Test enginePRODUCTION REPLICA Запись Чтение Репликация
- 20. 20© Copyright 2013 EMC Corporation. All rights reserved. Пример скрипта scenario("WriteAndCheck") { Timeout writeTime = userVariable("writeTime", Timeout) Host.PRODUCTION.startWrites() //h1,h2,h3 start writing writeTime.sleep() testStep(“switchDisaster”) { Switch.byHost(Host.PRODUCTION).disableLink() //SW1 expected events in 15.seconds { Storage.PRODUCTION => Event.REPLICATION_FAILED } }
- 21. 21© Copyright 2013 EMC Corporation. All rights reserved. Пример скрипта (продолжение) testStep(“Disaster recovery”) { Switch.byHost(Host.PRODUCTION).enableLink() expected events in 1.min { Storage.PRODUCTION => Event.REPLICATION_RESTORED } expected states in 10.min { Storage.REPLICA => SyncState.SYNCHRONIZED } } Host.PRODUCTION.stopWrites() (Host.PRODUCTION + Host.REPLICA).checkConsistency() }
- 22. 22© Copyright 2013 EMC Corporation. All rights reserved. Конфигурация системы Структура Сценарии Модель Конфигурация • Иерархия • Параметризация • Простота и гибкость • Универсальность • Уровень абстракции • Адаптеры
- 23. 23© Copyright 2013 EMC Corporation. All rights reserved. Конфигурация Конфигурационный файл: Минимальный набор данных об оборудовании Подключение к API CХД и импорт данных об окружении Построение топологии FC сети
- 24. 24© Copyright 2013 EMC Corporation. All rights reserved. Что дальше... ITE (Integrated Testing Environment) Непрерывная интеграция Виртуальная/облачная тестовая среда
- 25. 25© Copyright 2013 EMC Corporation. All rights reserved. Итоги Составляющие эффективной тестовой системы Библиотека знаний Гибкое конфигурирование
Notas do Editor
- Авторы описывают подход к автоматизации тестирования сложных систем хранения и обработки данных на базе продуктов компании ЕМС. Предлагаемый подход позволяет формализовать тестовые сценарии которые могут выполняться на различных конфигурациях оборудования и приложений. Предложенный предметно-ориентированный язык позволяет оперировать сущностями системы не привязываясь к конкретной конфигурации. Язык позволяет декларативно описывать сценарий в терминах объектов, операций и ожидаемых состояний. Результат работы авторы представляют в виде набора методик которые могут применяться в автоматизации тестирования различных систем.
- .....You won’t find ready to use solution in that presentation, indeed, we found that every problem may need specific system and focused on fundamental principles of building such a systems but not on the systems themselvesWe won’t describe how we implemented test process, it may be good or bad, but it won’t be possible without automation techniques we present here
- Large, complicated systemsMany configurationsMany deployment scenario…
- Why do we care?Distributed heterogenuous data centersWe can easily define scenario stepsCannot reproduce at different configurationHard to maintain test stepsHard to manage multiple tests
- Перед нами стояла задача реализовать возожность создавать сценарии независимые от конфигурации системы и
- Здравствуйте коллеги, сегодня я расскажу вам о технических аспектах создания своего предметно-ориентированного языка. Есть мнение что создать свой язык чрезмерно сложно и трудоемко, это не совсем так. Существует два подхода:создание языка с нуля создания парсека, лексического анализатора и компиляторавзять за основу язык общего предназначения и дополнить его конструкциями которые и будут представлять собой новый синтаксис.
- Основные структурные элементы тестового процессаSuite – список параметризованных сценариевScenario – groovy скрипт, содержит вызовы test casesTest Case – groovy скрипт, лежит отдельноДобавляем языковые конструкции
- Структура – иерирархия, переиспользуемые модули
- Предметно-ориентированный язык (DSL) как средство спецификации сценарияПеред созданием своего языка нужно взвестись преимущества и недостатки. Вложение на начальном этапе, выгода в долгосрочной преспективе.Основные т.с. Показания к созданию ПОЯ:Разные команды занимаются платформой для тестирования и непосредственным написанием сценариев.Необходимость изменений скриптовОтсутствует один язык программирования который знают разработчики и тестировщики.Легкость понимания для пользователя автоматизации
- Почему Groovy?Было расмотрено много средст, но был выбран Groovy за сл св-ваУ Groovy есть встроенный интерпретатор: приложение для а.т. Компилируются, сами файлы скриптов находятся отдельно, их обработка производится непосредственно в момент выполнения. У пользователя есть возможность дописывать и измениять сценарии без компиляции и без перезапуска сис тестСистема тестирования написана на JAVA, скриптовый язык по сути своей является уровнем над сервисами и возможностями риализованными на Java.Groovy позволяет перегружать почти любые стандартные операторы языка, и добавлять методы к классам к исходному коду которых доступа нет.В Groovy сделан упор на краткость синаксиса, считается что один и тот же код на G в несколько раз меньше чем на Java. На G можно сделать описание теста очень выразительными конструкциями, концентрируя внимания на логике сценария, без деталей исполнения.Groovy де-факто стандарт для создания DSL. Легко найти документацию и примеры.Тестовый сценарий является groovy кодом, имея IDE c поддержкой Groovy мы получаем подсветку синтаксиса и автодополнение. Что облегчает создание сценариев.
- Первый шаг при разработке DSL – создание своего наследника groovy класса Script который будет содержать ключевые слова языка – методы по своей сути.В основе модели системы автоматизации лежит объекто-ориентированный подход. Любой синтаксический элемент языка – это объект.Основные элементы блоки, фильтры, проверки – о них будет позже.Этапы выполнения скрипта:Groovy компиляцияВыполнение groovy кода – ничего не происходит – создается дерево блоков и вызовов операций – т.е. мы получаем структурированный план выполнения сценария. Трансляция языковых конструкций в последовотельность действий, которые будут выполняться от тех или иных условий.Проверка внутренней логики скриптаПроход по дереву и вызов методов сервисов, осуществеление проверок
- В любом крупном проекте возникает проблема организации информации о том как система должна работать. Формальные спецификации не обновляются и быстро устаревают. В итоге вся масса знаний распределена (но неравномерно) по головам ведущих разработчиков и архитекторов.Используя декларативный синтаксис DSL мы можем описывать поведение системы, создавать спецификацию которая всегда будет в актуальном состоянии и будет иметь единый формат.
- Что такое фильтр:Мы не хотим привязываться к конкретным конфигурациям, вместо задания конкретных объектов мы задаем правила по которым они должны выбиратьсяю. Выборка подмножества объектов из полного множества.Например у нас есть тестовый сценарий где мы хотим отключить порты на свиче к которым подключен сервер имеющий определенную роль в процессе репликации.Нам не нужно создавать фильр для каждой задачи, для этого мы можем комбинировать фильры
- Используя возможность перегрузки операторов языка были реализованы основные операции над множествами+ объединение множеств* пересечение множеств- отрицание (унарный оператор)разность (бинарный оператор)Примеры:1) красная звезда2) Все фигуры кроме зелыных круга и треугольникаКаждый фильтр имеет специальные методы при выполнение которых создаются команды в дереве вызовов, т.е. планируется выполнение операций над множеством объектов, полученных в результате вычисления фильтра.
- Тест состоит из команд и проверок, т.к. проверяем мы сложную распределенную систему обладающую определенной инертностью, состояния не меняются мгновенно, для описания логики и нами создана такая конструкция. Блок Expected описывает что должно произойти с какой сущностью как именно и когда. Квантор описывает отношение проверки ко множеству объектов.Every – проверка для кажной сущности полученой в результате вычисления фильраAny – достаточно если хотя бы для одной сущности проверка пройдетСостояние может быть либо дискретное из определенного множесто возможных, может быть выражением например размер записанных данных должен быть больше какого-то числа.Обратите внимание что этот пример это реальный код.Обратите внимания как легко… конструкцию можно читать без знания языка программирования, понимая что проверяется. То что написано здесь в 5 словах на языке, ранее было описано десятками приложений тестовой спецификации для ручных тестов. Тестировщику которому нужно было ручные тесты, необходимо было разбираться в эзотерических талмудах писателей тестовой документации, чтобы понять как правильно нужно проверять.
- Для всего множество проверок нам понадобилось реализовать 3 темпоральных оператораStates – удовлетворится когда все сущности перейдут в заданное состояние. Нам важен финальный результат.Events – удовлетворится когда появится события или состояние на всех сущностях. Но нам не важно конечное состояние.Stability – удовлетворится если в течении заданного промежутка времени состояние не менялос
- Структура – иерирархия, переиспользуемые модули
- Вернемся к нашему примеру: один из вариантов тестового стенда: Есть 2 сайта – датацентра: основной и резервный.На основном установлены сервера осуществляющие запись на СХД, на резерном установлены сервера которые получат доступ к копии даных в случае неисправности основного датацентра или по требованию пользователя для проверки консистентности данных.Попробуем протестировать простейший пример. Слева все production сервера осуществляют запись на СХД в течении заданного промежутка времени. Тестируем случай неисправности связи между сайтами. Линк между SW1 и SW2 пропадет. Репликация приастоновится, востановим соединение, репликация должна поднятся, в это время сервера осуществляют запись на основную СХД, система репликация должна синхронизовать данные на основной и резервной СХД в заданый промежуток времени. После этого запись остонавливается, после это сервера на обоих сайтах читают данные с СХД и сравнивают контрольные суммы. Этим проверяется что в случае неисправности связи между сайтами, данные будут синхранизированы и будут одинаковые.
- Структура – иерирархия, переиспользуемые модули
- Знание конфигурации позволяют реализовать Constaints (ограничения)