Фреймворк автотестирования веб-сервисов своими силами
•Download as PPTX, PDF•
2 likes•2,962 views
Андрей Воробьев - доклад на SQA Days, 2-3 декабря 2011, Москва
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Фреймворк автотестирования веб-сервисов своими силами
Similar to Фреймворк автотестирования веб-сервисов своими силами (20)
More from SQALab
More from SQALab (20)
Фреймворк автотестирования веб-сервисов своими силами
- 1. Фреймворк для авто-тестирования веб-сервисов своими силами Воробьев Андрей Test Automation Engineer EPAM, Минск
- 2. О себе Воробьев Андрей Test Automation Engineer EPAM Systems Автор и ведущий тренингов для начинающих по авто-тестированию веб-сервисов andrei_varabyeu@epam.com
- 3. Профессиональный жаргон
- 4. Авто-тестирование веб-сервиса Запрос Ответ Да Ответ Тест БАГ правильный? пройден
- 5. Авто-тестирование веб-сервиса Покупать продукт или разрабатывать самим?
- 6. Как решить? Для того, чтобы принять верное решение, достаточно ответить только на один вопрос: “Насколько тривиальные задачи требуется решить”
- 8. Сложно или просто? Просто: Сложно: • Сложные входные данные • Простые входные (части запросов, данные(числа, строки) которые нужно группировать друг с • Примитивные типы другом) валидаций (=, >, <, contains) • Сложная валидация (по • Простые выборки в базу. шаблону, по данным Малый объем выборок которые тоже нужно откуда-нибудь получить ) • Поддержка транзакций БД, кэширования
- 11. Сложно или просто? <person name=„Андрей Воробьев‟> <relative>Лина Воробьева</relative> <relative>Сергей Воробьев</relative> </person>
- 12. Сложно или просто? <person name=„Андрей Воробьев‟> <relative name=“Лина Воробьева“> <relative>Валентина Криводубская</relative> <relative>Дмитрий Криводубский</relative> </relative > <relative name=“Сергей Воробьев“> <relative>Ядвига Воробьева</relative> <relative>Николай Воробьев</relative> </relative > </person>
- 13. Сложно или просто? <person name=„Андрей Воробьев‟> <relative name=“Лина Воробьева“> <relative name=“Валентина Криводубская“> <relative>Анна Криводубская</relative> <relative>Петр Криводубский</relative> </relative> <relative name=“Владимир Криводубский“> N == ? <relative>…</relative> <relative>…</relative> </relative> </relative> <relative name=“Сергей Воробьев“> <relative name=“Ядвига Воробьева“> <relative>…</relative> <relative>…</relative> </relative> <relative name=“Николай Воробьева“> <relative>…</relative> <relative>…</relative> </relative> </relative > </person>
- 14. Просто • SOAP, Rest, HTTP, JMS, DB • XPath Assertions • XQuery Assertions • Logging • Scripting Support (Groovy, JavaScript) • WS Security • …. and more 14
- 15. Сложно • Java/C#/… • WS implementation • *Unit testing Frameworks 15
- 16. «Сделай сам» Фреймворк для тестирования Веб Сервиса – это всего лишь: • Клиент веб-сервиса (для отправки запросов и получения ответов от сервера) • Реализация работы с БД, другими источниками входных/выходных данных • Набор валидаций, которые нужны ВАМ (XPath, XQuery, DB, равно, содержит, большеменьше, соответствует заданному формату) 16
- 17. Task list подготовить входные данные (получить из файлов, БД, etc) сформировать и отправить запрос/получить ответ выполнить валидацию ответа … и так много раз в течение одного теста 17
- 18. Подготовка запроса <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Body> <familyTree> <name>Андрей Воробьев</name> </ familyTree > </soapenv:Body> </soapenv:Envelope> 18
- 19. Подготовка запроса soapUI Java-based framework • Java Property files • Java Property files • Data Source (excel) • DB (+ORM, cashing, transactions) • DB via „Property Transfer‟ • ЛЮБЫЕ другие источники • использование groovy данных (Windows Active Directory, http, ftp, etc) 19
- 20. Отправка запроса/Получение ответа soapUI Java-based framework • ВСЕ уже сделано за вас • JAX-WS • Spring-WS • … • ЛЮБЫЕ другие источники имплементации, которые удобно использовать ВАМ 20
- 21. Валидация ответа <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Body> <person name=„Андрей Воробьев‟> <relative>Лина Воробьева</relative> <relative>Сергей Воробьев</relative> </person> </soapenv:Body> </soapenv:Envelope> 21
- 22. soapUI – это тоже Java код htmlUnit xmlUnit jUnit easyMock Фреймворк Расширение Расширение Библиотека для создания Junit, JUnit, для Mock- предназначен предоставляю модульного объектов ное для щее большой тестирования эмуляции набор средств на языке Java. действий для Позволяет браузера валидации создавать тест XML файлов, в кейсы, группы т.ч. с тест кейсов, помощью предоставляет XPath. базовые средства для валидации. 22
- 23. Архитектура или то, над чем стоит поломать голову… 23
- 24. Архитектура. Основные принципы Модульность Каждый из компонентов не зависит от другого 24
- 25. Архитектура. Основные принципы Расширяемость Легко добавлять: новый функционал новые типы валидаций 25
- 26. Архитектура. Основные принципы Читаемость Достаточно посмотреть на исходный код теста, чтобы понять что он делает 26
- 27. Архитектура. Компоненты cmp Component Model Framew ork TemplateProccesor WebServ er TestLayer «use» Serv iceInv oker WebServ ice «use» «use» Test «use» Validator 27
- 28. Архитектура. Диаграмма последовательности sd Use Case1 Test TemplateProcessor ServiceInvoker Validator WS PlainData() processMessage() :Message invoke() sendRequest() :Response :Result validate(Result) 28
- 29. Компоненты. Тест TestNG • базовые типы валидации • группировка в сьюты • отчеты о прохождении тестов • возможность выполнять тесты в несколько потоков • зависимости между тестами 29
- 30. Компоненты cmp Component Model Framew ork TemplateProccesor WebServ er TestLayer «use» Serv iceInv oker WebServ ice «use» «use» Test «use» Validator 30
- 31. Компоненты. Процессор шаблонов Данные Готовый запрос Шаблон 31
- 32. Компоненты. Процессор шаблонов <request> <amount>${amountValue}</amount> <currency>${currencyValue}</currency> </request> Шаблон 32
- 33. Компоненты. Процессор шаблонов Данные amountValue = 100 currencyValue = USD 33
- 34. Компоненты. Процессор шаблонов <request> <amount>100</amount> Готовый <currency>USD</currency> запрос </request> 34
- 35. Компоненты cmp Component Model Framew ork TemplateProccesor WebServ er TestLayer «use» Serv iceInv oker WebServ ice «use» «use» Test «use» Validator 35
- 36. Компоненты. XML - модель Мы используем… • XML в чистом виде • любые (в т.ч. невалидные) данные DOM • парсинг, Xpath • слабая привязка к схеме • нет парсинга • нет необходимости писать xPath JAXB выражения • невозможно вставить невалидные данные • жесткая привязка к схеме 36
- 37. Компоненты. SOAP-клиент Клиент НЕ Привязанный Привязанный К К схеме схеме • исходный код может быть • исходный код нужно писать сгенерирован автоматически по самому WSDL-схеме 37
- 38. Компоненты cmp Component Model Framew ork TemplateProccesor WebServ er TestLayer «use» Serv iceInv oker WebServ ice «use» «use» Test «use» Validator 38
- 39. Компоненты. Валидация Ответ База данных Сторонние сервисы 39
- 40. Компоненты. Валидация. Ответ • JUnit /TestNG + XPath DOM • XmlUnit + XPath • XMLUnit + шаблон ответа JAXB • JUnit/TestNG • JXPath 40
- 41. Почему это так важно Новые тесты создаются быстро 41
- 42. Почему это так важно Старые тесты поддерживать просто 2x2 42
- 43. soapUI Pro умеет… • измерять степень покрытия тестами • тестирование безопасности (SQL- инъекции, XPath-инъекции) • производить нагрузочное тестирование • интегрироваться в сборку сервиса и CI- цикл • создавать Mock-сервисы 43
- 44. soapUI vs. разработка • не нужно никаких подготовительных работ • новые тесты создаются медленно • старые тесты поддерживаются медленно • квалификация авто-тестировщика ниже среднего • базовый набор функционала* * расширяется только groovy-скриптингом 44
- 45. soapUI vs. разработка • перед написанием тестов необходимо разработать механизмы отправки, получения и валидации • новые тесты создаются быстро • старые тесты поддерживать просто • квалификация авто-тестировщика выше среднего 45
- 46. soapUI vs. разработка 46
- 47. soapUI vs. разработка • Любые протоколы • Любые источники входных и выходных данных (Active Directory, POP3, SMTP) • Простота валидации сложных типов данных (даты, UUID) 47
- 48. Наш опыт На разработку Фреймворка и первого теста путем проб и ошибок ушло около 2 человеко- месяцев 48
- 49. Наш опыт Сейчас, имея опыт, Это можно сделать за 2 человеко- недели 49
- 50. Ваши вопросы! 50
- 51. Спасибо за внимание! Воробьев Андрей Test Automation Engineer EPAM, Минск
- 52. Валидация ответа soapUI Java-based framework • Fault/Success • JUnit • Contains • TestNG • XPath • XmlUnit • Xquery • HtmlUnit • Schema Compilance • DbUnit • Timeout • …*Unit • WS-Security Status • Groovy • … 52
- 53. Компоненты. Процессор шаблонов Feature FreeMarker Velocity Циклы Да Да Условия Да Да Макросы Да Да Импорт других шаблонов Да Да Процессинг импортированных Да Да шаблонов Выполнение Java-кода Нет Частично 53
- 54. Компоненты. XML – модель. JAXB 54
Editor's Notes
- Для ответа на этот вопрос нам нужно дать ответ на следующий вопрос.Однако понятие «тривиально» у каждого человека свое.
- Давайте попробуем поделить все задачи на простые и сложные
- Мы используем сложные древовидные реквесты?Пример: обменник и несколько валютНам необходима валидация всего респонса или только нескольких полей?Работа с базой данные предполагает транзакции?Насколько сложными будут прекондишны?Пример транзакции: Для того чтобы заплатить по счету вам нужен личный лицевой счет. Для этого нужно зарегистрировать карточку
- Мы используем сложные древовидные реквесты?Пример: обменник и несколько валютНам необходима валидация всего респонса или только нескольких полей?Работа с базой данные предполагает транзакции?Насколько сложными будут прекондишны?Пример транзакции: Для того чтобы заплатить по счету вам нужен личный лицевой счет. Для этого нужно зарегистрировать карточку
- Мы используем сложные древовидные реквесты?Пример: обменник и несколько валютНам необходима валидация всего респонса или только нескольких полей?Работа с базой данные предполагает транзакции?Насколько сложными будут прекондишны?Пример транзакции: Для того чтобы заплатить по счету вам нужен личный лицевой счет. Для этого нужно зарегистрировать карточку
- Мы используем сложные древовидные реквесты?Пример: обменник и несколько валютНам необходима валидация всего респонса или только нескольких полей?Работа с базой данные предполагает транзакции?Насколько сложными будут прекондишны?Пример транзакции: Для того чтобы заплатить по счету вам нужен личный лицевой счет. Для этого нужно зарегистрировать карточку
- Мы используем сложные древовидные реквесты?Пример: обменник и несколько валютНам необходима валидация всего респонса или только нескольких полей?Работа с базой данные предполагает транзакции?Насколько сложными будут прекондишны?Пример транзакции: Для того чтобы заплатить по счету вам нужен личный лицевой счет. Для этого нужно зарегистрировать карточку
- Мы используем сложные древовидные реквесты?Пример: обменник и несколько валютНам необходима валидация всего респонса или только нескольких полей?Работа с базой данные предполагает транзакции?Насколько сложными будут прекондишны?Пример транзакции: Для того чтобы заплатить по счету вам нужен личный лицевой счет. Для этого нужно зарегистрировать карточку
- Все простые задачи решаются с помощью инструмента который называется soapUIОднако бывают ситуации когда soapUIнедостаточно.
- Тестировщик должен бытьПрограммистомПонимать имплементацию веб-сервисовИметь представление о юнит-фреймоврках
- Для того чтобы пройти тест необходимо
- Часть 1. Подготовка реквеста - или откуда взять исходные данныеФункциональное тестирование как процесс заключается в проверке тех или иных свойств системы по принципу черного ящика. Используется какой-то готовый набор тестовых данных на которые система должна реагировать в соответствии со своим назначением. Эти массивы тестовых данных нужно каким-то образом хранить и обрабатывать, что в разрезе тестирования веб-сервисов, значит собирать в soap-реквест (XML формат) и отправлять серверу. soapUIПозволяет работать с java-property файлами (java формат property-файла: ключ=значение), а также с базой данных. Работа с базой организована следующим образом - необходимо подготовить так называемый JDBC-request, который содержит в себе настройки соединения с БД и, конечно, SQL запрос. JDBC-request выбирает данные в виде XML файла, который потом можно распарсить с помощью XPathили преобразовать с помощью Xquery.Для того, чтобы сохранить какие-то значения выбранные из базы в переменные для последующей работы с ними, необходимо использовать еще одну специфическую фичуsoapUI - PropertyTransfer, которая позволяет передавать переменные от одного тест-степа к другому в рамках одного проекта. Есть возможность написать Groovy-скрипт и вытащить данные, используя стандартные Java-библиотеки, что, конечно, уже потребует от тестировщика знания основ программирования. JavaС другой стороны, клиент для тестирования, написанный на Java, позволит вам сделать все, что вы захотите: работать с файлами любых форматов, базой данных (более того, с использованием, например, такой распространенной технологии как ORM), другими удаленными и локальными источниками информации.Если команды разработчиков и QA работают параллельно, то у QA-команды может вообще отпасть вопрос о работе с базой данных, т.к. достаточно часто разработчики просто предоставляют свой DAO API (расшифровка нужна?) Как только тестовые данные собраны/получены/загружены - подготовить реквест не составит труда ни в soapUI, ни в написанном вручную Java-клиенте. Схема, как правило, одинаковая и там, и там: создается xml-шаблон, который состоит из т.н. XML и плейсхолдеров - мест, где вместо значений находятся имена переменных. Позже в места этих переменных будут просто вставлены необходимые значения для каждого теста.….<RequestType><Amount>${Amount}</Amount></RequestType>….Предположим, что для каждого теста, значение 'Amount' может отличаться. Тогда очень удобно подготовить темплейтреквеста и просто наполнять его значениями от теста к тесту. Основной вывод отсюда: soapUIпредоставляет очень ограниченный набор возможностей по подготовке реквеста. Расширить их можно с использованием groovy-скриптинга, что уже потребует больших временных затрат, а также повышенной квалификации от мануального тестировщика (что скажется и на его заработной плате).
- Часть 1. Подготовка реквеста - или откуда взять исходные данныеФункциональное тестирование как процесс заключается в проверке тех или иных свойств системы по принципу черного ящика. Используется какой-то готовый набор тестовых данных на которые система должна реагировать в соответствии со своим назначением. Эти массивы тестовых данных нужно каким-то образом хранить и обрабатывать, что в разрезе тестирования веб-сервисов, значит собирать в soap-реквест (XML формат) и отправлять серверу. soapUIПозволяет работать с java-property файлами (java формат property-файла: ключ=значение), а также с базой данных. Работа с базой организована следующим образом - необходимо подготовить так называемый JDBC-request, который содержит в себе настройки соединения с БД и, конечно, SQL запрос. JDBC-request выбирает данные в виде XML файла, который потом можно распарсить с помощью XPathили преобразовать с помощью Xquery.Для того, чтобы сохранить какие-то значения выбранные из базы в переменные для последующей работы с ними, необходимо использовать еще одну специфическую фичуsoapUI - PropertyTransfer, которая позволяет передавать переменные от одного тест-степа к другому в рамках одного проекта. Есть возможность написать Groovy-скрипт и вытащить данные, используя стандартные Java-библиотеки, что, конечно, уже потребует от тестировщика знания основ программирования. JavaС другой стороны, клиент для тестирования, написанный на Java, позволит вам сделать все, что вы захотите: работать с файлами любых форматов, базой данных (более того, с использованием, например, такой распространенной технологии как ORM), другими удаленными и локальными источниками информации.Если команды разработчиков и QA работают параллельно, то у QA-команды может вообще отпасть вопрос о работе с базой данных, т.к. достаточно часто разработчики просто предоставляют свой DAO API (расшифровка нужна?) Как только тестовые данные собраны/получены/загружены - подготовить реквест не составит труда ни в soapUI, ни в написанном вручную Java-клиенте. Схема, как правило, одинаковая и там, и там: создается xml-шаблон, который состоит из т.н. XML и плейсхолдеров - мест, где вместо значений находятся имена переменных. Позже в места этих переменных будут просто вставлены необходимые значения для каждого теста.….<RequestType><Amount>${Amount}</Amount></RequestType>….Предположим, что для каждого теста, значение 'Amount' может отличаться. Тогда очень удобно подготовить темплейтреквеста и просто наполнять его значениями от теста к тесту. Основной вывод отсюда: soapUIпредоставляет очень ограниченный набор возможностей по подготовке реквеста. Расширить их можно с использованием groovy-скриптинга, что уже потребует больших временных затрат, а также повышенной квалификации от мануального тестировщика (что скажется и на его заработной плате).
- Часть 2. Отправка реквеста - получение респонсаПоскольку soapUIявляется soap-клиентом, процесс отправки и получения soap-сообщения в нем уже реализован. Java-клиент необходимо писать самому и в этом заключается основная сложность, поскольку это процесс требует от автоматизатора навыков разработчика. Написание soap-клиента потребует дополнительных временных затрат, однако в это есть и свои плюсы: если команда решила проводить тестирование с использованием объектов, которыми пользуются разработчики (для Java очень распространены JAXB-объекты), то написание собственного клиента - это единственный выход, т.к. soapUIпозволяет работать только на уровне XML и не использует никаких абстракций. Многие считают, что тестировать веб-сервис технологиями, на которых построен сам веб-сервис не самым лучшим подходом. Оппоненты такой позиции с юмором предлагают открыть окно telnet-терминала и работать прямо в нем, чтобы избежать лишних слоев абстракций. Так или иначе, каждое мнение имеет право на жизнь. Одно из утверждений в пользу custom-made framework состоит в следующем: Java программисты знают, что наиболее используемые типы java-кода -это так называемые POJO-объекты (расшифровка нужна?), которые представляют собой просто набор полей класса со значениями (словно это контейнер для свойств какого-либо объекта). Такими объектами можно описать и XML-документ (JavaArchitecture for XML Binding), что, несомненно, очень удобно - часть необходимого кода автоматизатор может взять у команды разработчиков (или наоборот). А все в сумме экономит время и, конечно, деньги.Основной вывод: На этом этапе soapUIвыигрывает, поскольку не требует глубоких знания программирования и временных затрат для реализации собственного soap-клиента. Тем не менее, soapUIне обладает мощью полноценного высокоуровнего языка программирования, поэтому для решения нетривиальных задач лучше выбрать custom-made framework.
- soapUIпредставляет выбор из достаточно большого набора типов валидацииреспонса, начиная от валидации непосредственно XML респонса по XPath, XQuery выражениям, так и валидациюsoap статуса респонса, секьюрити валидацию. Есть возможность валидировать выборки из базы данных, использовать Groovy-скрипты. Соль состоит в том, что soapUIсам написан на Java и, следовательно, просто реализует набор таких Java-based фреймворков как JUnit, TestNG,XMLUnit, DBUnit. Однако, soapUIограничивает функциональность этих фреймворков ради простоты и удобства конечного пользователя. Для полного понимания картины проведем небольшой экскурс:JUnit - библиотека для модульного тестирования на языке Java.Позволяет создавать тест кейсы, группы тест кейсов, предоставляет базовые средства для валидации.TestNG - библиотека для функционального тестирования на языке Java.Представляет собой аналог JUnit со множеством улучшений таких как зависимости между тестами, параметеризация через XML-файлы и т.п.XMLUnit - расширение JUnit, предоставляющее большой набор средств для валидацииXML файлов, в т.ч. с помощью XPath.DBUnit - расширение JUnit, предоставляющее большой набор средств для валидации баз данных.
- soapUIпредставляет выбор из достаточно большого набора типов валидацииреспонса, начиная от валидации непосредственно XML респонса по XPath, XQuery выражениям, так и валидациюsoap статуса респонса, секьюрити валидацию. Есть возможность валидировать выборки из базы данных, использовать Groovy-скрипты. Соль состоит в том, что soapUIсам написан на Java и, следовательно, просто реализует набор таких Java-based фреймворков как JUnit, TestNG,XMLUnit, DBUnit. Однако, soapUIограничивает функциональность этих фреймворков ради простоты и удобства конечного пользователя. Для полного понимания картины проведем небольшой экскурс:JUnit - библиотека для модульного тестирования на языке Java.Позволяет создавать тест кейсы, группы тест кейсов, предоставляет базовые средства для валидации.TestNG - библиотека для функционального тестирования на языке Java.Представляет собой аналог JUnit со множеством улучшений таких как зависимости между тестами, параметеризация через XML-файлы и т.п.XMLUnit - расширение JUnit, предоставляющее большой набор средств для валидацииXML файлов, в т.ч. с помощью XPath.DBUnit - расширение JUnit, предоставляющее большой набор средств для валидации баз данных.