Автоматизация тестирования многопоточности

Автоматизация тестированиямногопоточности

Андрей Иваровский. Глойп.

Содержание

1. Зачем нужны многопоточные автотесты?

2. Как это делают “ручные” тестировщики

3. Как это делают разработчики

4. Как это делаю я

5. Описание сценария

6. Выполнение сценария

7. Шаблоны

8. Выводы

1. Зачем нужны многопоточные автотесты?

Назовём автотест многопоточным, если его компоненты запускаются параллельно, в несколько потоков, взаимодействуя между собой.

1. Зачем нужны многопоточные автотесты?

Лучший способ тестирования многопоточного кода - это убрать многопоточность.

© Энтони Уильямс

1. Зачем нужны многопоточные автотесты?

1. Когда тесты нельзя выполнить в одном потокеТребования бизнес-логики приложения обязывают выполнять

тесты параллельно – в несколько потоков одновременно.

2. Если тестов очень много + они зависят друг от другаПараллельный запуск тестов значительно уменьшает время

прохождения набора тестов.

3. При тестировании производительностиТребуется проверить, как ведет себя

приложение при большом количестве пользователей, работающих с ним одновременно.

1. Зачем нужны многопоточные автотесты?

Пример #1: интернет-мессенджер

1. Зачем нужны многопоточные автотесты?

Пример #2: пуск ракет

1. Зачем нужны многопоточные автотесты?

Пример #3: автоматизированные системы управления войсками

2. Как это делают “ручные” тестировщики

Способ #1: тестировщик выполняет тесты последовательно, один за другим

Способ #2: тестировщик использует средство виртуализации, например vmware, и выполняет несколько тестов одновременно

2. Как это делают “ручные” тестировщики

Способ #3: несколько “ручных” тестировщиков тестируют приложение одновременно и согласованно

2. Как это делают “ручные” тестировщики

3. Как это делают разработчики

Тестирующая логика в:

• В одном потоке• В нескольких потоках

- тестируемый поток

- тестирующий поток

3. Как это делают разработчики

Промышленный стандарт:

• Большой тираж• Надежность в эксплуатации• Низкие затраты

3. Как это делают разработчики

Промышленный стандарт:

Решение должно быть простым и надежным!

3. Как это делают разработчики

Промышленный стандарт:

Логика приложения описывается в xml-файлах, называемых обычно сценариями.

Теги сценария связываются с определенными классами.

В классах нет условной логики, - только набор операторов. Операторы if и switch – не используются.

Используется уже готовый “движок” для запуска сценариев.

3. Как это делают разработчики

“Custom-ная” разработка:

изобретается свой “велосипед” – используются методы и многопоточного программирования: в коде создаются потоки и/или процессы.

3. Как это делают разработчики

“Custom-ная” разработка:

изобретается свой “велосипед” – используются методы и многопоточного программирования: в коде создаются потоки и/или процессы.

Создание классов, реализующих интерфейс Runnable Класс Thread Блокировки контекста И так далее…

Все это слишком сложно!

4. Как это делаю я

1. Описание сценария

2. Разработка тестовых методов

3. Запуск сценариев на vmware

4. Анализ логов

5. Описание сценария

Граф (дерево)Test1:Test2, Test3;Test3:Test4, Test5;Test5:Test6, Test7, Test8.

5. Описание сценария

Граф (дерево)

Scenario.xml

<test name=“Test1” predecessor=“” />

<test name=“Test2” predecessor=“Test1” />

<test name=“Test3” predecessor=“Test1” />

<test name=“Test4” predecessor=“Test3” />

<test name=“Test5” predecessor=“Test3” />

<test name=“Test6” predecessor=“Test5” />

<test name=“Test7” predecessor=“Test5” />

<test name=“Test8” predecessor=“Test5” />

5. Описание сценария

BPMN - Business Process Model and Notation, нотация и модель бизнес-процессов

5. Описание сценария

TestNG

<suite name="Call." thread-count="2" parallel="tests" preserve-order="true" > <test name="User1.Call." >

<parameter name="loginname" value="user1"/> <classes> <class name="tests.TestCall" />

</classes></test>

<test name="User2.Call." > <parameter name="loginname" value="user2"/>

<classes> <class name="tests.TestCall" />

</classes></test>

</suite>

6. Выполнение сценария

BPMN-”движок”, использующий web-сервисы: например Intalio

Сценарий Intalio

Web-сервисы

Пул VM

6. Выполнение сценария

Используется самый простой “движок” - Sarasvati

Сценарий Sarasvati

Java-классы

Пул VM

6. Выполнение сценария

Используется фреймворк TestNG

Сценарий Ant + TestNG

Тесты

Пул VM

6. Выполнение сценария

Для запуска сценариев пишется свой “движок”

Сценарий“Самописный

движок”

Тесты

Пул VM

Шаблон №1: Ant + TestNG + Selenium WD

7. Шаблоны

Framework + testng tests

AntTestng

task

Testng scenario .x

ml

ReportNGVIX vmrun

Selenium WD+AutoIT

SeleniumServer

VM

Шаблон №1: Ant + TestNG + Selenium WD

7. Шаблоны

1. Ant запускает testng задачу

2. Выполняется testng сценарий

3. При помощи vix vmrun идет управление виртуальными машинами: включить, выключить, перезагрузить, снять скриншот и т.д.

4. На виртуальных машинах запускается Selenium Server

5. Тестовые методы, используя Selenium WD, через Selenium Server взаимодействуют с UI приложения на виртуальных машинах

6. Для взаимодействия с win-приложениями используются откомпилированные скипты AutoIT, которые запускаются на виртуальных машинах через vix vmrun

7. При помощи библиотеки ReportNG создаются отчеты

Шаблон №2: JSP + DB + VBS + QTP

7. Шаблоны

JSP web.app.

DB

VBS+ QTP

VM

Tomcat

VIX vmrun

Daemon

Browser

Шаблон №2: JSP + DB + VBS + QTP

7. Шаблоны

1. Для управления запусками тестов, а также отображения результатов используется веб-приложение, написанное на JSP. Веб-приложение деплоится на любой веб-сервер, поддерживающий JSP, например Tomcat.

2. При выборе теста и нажатии кнопки “Пуск” серверная часть JSP приложения находит соответствующий xml сценарий и запускает тесты в определенном порядке на указанных в сценарии виртуальных машинах.

3. Для взаимодействия с виртуальной машиной используется vix vmrun.

4. Для операции с UI тестируемого приложения используются QTP-скрипты, которые запускаются при помощи vbs на виртуальных машинах.

5. Информация о запланированных, текущих и уже прошедших запусках, о состоянии виртуальных машин хранится в базе данных.

6. Для управления очередью задач на запуск используется daemon-приложение, которое отслеживает запуски через базу данных.

7. Отчеты о запусках генерируются при помощи запросов к базе данных, выполняемых JSP приложением.

Для описания многопоточных сценариев лучше использовать XML

Запуск многопоточных автотестов следует осуществлять через уже написанный “движок”. Например TestNG

Не использовать в коде тестов условной логики – она должна быть помещена в XML-сценарий

Не использовать при написании кода методы многопоточного программирования (не создавать новые потоки)

Использовать средства виртуализации. Например vmware

8. Выводы

Контакты:

Email: andrew@runteo.com Skype: andrew.ivarouski Mobile: (+375 29) 705 00 28 Web: www.runteo.ru

Спасибо за внимание!