Конфігураційне тестування

    Спеціальний вид  тестування, спрямований на  перевірку сумісності об'єкта тестування з  різним апаратним та  програмним забезпеченням.

    Конфігураційне тестування необхідно для гарантованої сумісності об'єкта тестування з  максимально можливим обладнанням, для  забезпечення надійної роботи. Також КУ  має враховувати тип  операційної системи.

    RUP  має розгалужений механізм по  плануванню і  одночасного запуску конфігураційних тестів на  різних платформах одночасно.

    Тест повинен враховувати такі критерії, як: встановлене програмне забезпечення  (і їх версії), наявність і  версії драйверів обладнання, наявність обладнання  (довільній комбінаціях).

Мета Тестування:
    Перевірити об'єкт тестування на  сумісність з  оголошеним в  специфікації обладнанням, операційними системами та  програмними продуктами третіх фірм.

Методика:
    Використовуються скрипти функціонального тестування;

    До  початку тестування відкрити максимальне число загальновідомих додатків;

    Тестування проводиться на  різних платформах.

Критерії завершення:
    Тестовані програми правильні в  будь-якій аппартно-програмному середовищі.

    Всі виявлені дефекти оброблені і  задокументовані.

Інсталяційне тестування

    Останній вид  тесту в  нашому списку, але  перша функція, з  якої користувач розпочне ознайомлення з  програмним продуктом.

    Даний вид  тестування перевіряє здатність об'єкта тестування коректно і без збоїв встановитися на  комп'ютер користувача  (доустановити, оновитися) з  обробкою всіх можливих виняткових ситуацій  (брак  місця, збій харчування).

Мета Тестування:
    Упевнитися в  тому, що  об'єкт тестування правильно інсталюється на  систему, що задовольняє всім програмно-апаратним вимогам з  інструкції по  інсталяції. Особлива увага приділяється наступним видам установки:

1. нова інсталяція, нова машина, що не інстальований на неї раніше;

2. оновлення існуючої версії (перевстановлення);

3. оновлення зі старої версії (апгрейд)

4. спроба установки старої версії поверх нової.

 

Методика:
    Розробити скрипти для  перевірки всіх перерахованих комбінацій.

Критерії завершення:
    Установка, оновлення та  деінсталяція відбуваються коректно;

    Виняткові ситуації обробляються коректно.

    Всі виявлені дефекти оброблені і  задокументовані.

Тестування навантаження за допомогою Selenium

Введення

    В цій статті я розповім про застосування інструменту спочатку призначеного для функціонального тестування при тестуванні нагрузочної web частини системи електронного документообігу (СЕД).

    Навіщо взагалі це знадобилося? Ми переслідували дві мети - введення автоматичних тестів для наших web-додатків і створення навантажувальних тестів на основі функціональних тестів.

    Чому для тесту використовувався саме Selenium, а не більш підходящий інструмент - LoadRunner, jMeter? За допомогою LoadRunner's навантажувальний тест був проведений, але результати були поставлені під сумніви - при емуляції двохсот користувачів сторінки завантажувалася за 2 секунди плюс-мінус 2%, хоча при відкритті цих же сторінок з браузера відображення відбувалося більш ніж за 3 секунди. Так що хотілося провести навантажувальні тести максимально наближені до реальності, а це можна зробити тільки за допомогою повної емуляції поведінки користувача. Для цього якраз підходили інструменти для функціонального тестування з їх роботою з браузерами - сайт відкривався б через звичайний браузер, тобто так як робив би це користувач.

 

Про Selenium

    Для функціонального тестування був обраний саме Selenium з простої причини - він кращий з безкоштовних інструментів для функціонального тестування. Якщо точніше - у нього хороша підтримка віддаленого управління (Selenium Server, Selenium Grid), багато документації (в тому числі і російською мовою ( habrahabr.ru/post/151715/  habrahabr.ru/post/152653/ ) і підтримка всіх основних браузерів (хоча це вже більше заслуга WebDriver).

 

Загальна архітектура

 

 

    Додаток розділений на рівні (для наочності на схемі елементи кожного рівня мають осмислені назви, а не просто Тест 1, Методи 2).

    Перший рівень - рівень «запускальщика» тестів. Він просто запускає тести. У налаштуваннях конфігурується кількість потоків, кількість запусків тесту, класи тесту.

    Другий рівень - самі тести. Вони виконують бізнес операції - авторизацію, відкривають списки документів, відкривають документи, переходять по вкладках документів.
    Третій рівень - рівень роботи з web-елементами. У ньому міститися атомарні користувальницькі операції по роботі з системою - відкриття списку документів, перехід до певного документу, робота з вкладками документа.

    Для початку перерахованих дій буде достатньо для забезпечення мінімальної роботи з системою. Надалі вони будуть додаватися.

    Поділ на ці рівні дає таку ж вигоду - можна запускати тести як з «запускальщика», так і без - просто запуск одного тесту з середовища розробки. Винесення атомарних користувальницьких операцій на окремий рівень дозволить надалі відмовитися від написання тестів на Java, а розробити свій DSL для того, що б тести могли писати будь-які люди.

 

Запуск тестів

    Програма для запуску jUnit тестів досить проста і складається з трьох класів - клас, який виконує зазначені тести у своєму потоці; клас «слухача» jUnit тесту для підрахунку часу виконання тесту; клас для формування потоків і їх запуску.
Код Runner 'а

Final Int threadCount = readThreadCount ();

Final Int invocationCount = readInvocationCount ();

Final List < Class> testClasses = readTestClasses ();

ExecutorService taskExecutor = Executors.newFixedThreadPool (threadCount);

for ( Int I = 0; i < threadCount; i ++) {

taskExecutor.execute ( New TestRunner (invocationCount, testClasses));

}

taskExecutor.shutdown ();

taskExecutor.awaitTermination (Long.MAX_VALUE, TimeUnit.NANOSECONDS);

 

Код класу запускає тести

 

Public Class TestRunner Implements Runnable {

Public Void Run () {

JUnitCore jUnitRunner = New JUnitCore ();

jUnitRunner.addListener ( New TimeListener ());

for ( Int I = 0; i < invocationCount; i ++) {

for (Class clazz: testClasses) {

jUnitRunner.run (clazz);

}

Thread.sleep (invocationTimeOut);

}

}

}

 

Код listener 'а

 

Public Class TimeListener extends RunListener {

Private EtmPoint Point;

Public Void testStarted (Description description) throws Exception {

point = EtmManager.getEtmMonitor (). createPoint (description.getClassName () + "." + description.getMethodName (); );

}

Public Void testFinished (Description description) throws Exception {

point.collect ();

}

Public Void testFailure (Failure failure) throws Exception {

log.error ( " Error in test." , failure.getException ());

}

}

 

Тести

    Тести були написані прості, але, тим не менш, відображають роботу користувача - відкриття списку документів, відкриття картки документа, перехід по вкладках картки.

    Для написання тестів використовувався jUnit. Хоча також можна використовувати TestNG, який підтримує паралельний запуск тестів (а при навантажувальному тестуванні це обов'язкова вимога). Але обраний був саме jUnit з двох причин: 1) у компанії він широко поширений і давно використовується 2) потрібно було все одно писати свій «запускальщик» який би дозволив, не змінюючи тести, запускати їх в різних потоках (у TestNG паралельний запуск налаштовується в самих тестах) і збирати статистику щодо їх виконання.

    Крім тестів були написані додаткові модулі - pool webdriver'ов (тут слово webdriver використовується в термінології Selenium'а), pool користувачів, pool документів, rule (у термінології jUnit) по зняттю скріншотів при помилку, rule з видачі webdriver тесту, rule авторизації.

    Pool webdriver'ов - це клас, який управляє отриманням webdriver з сервера Selenium'а і розподіляє їх між тестами. Потрібен для того, що б абстрагувати роботу з Selenium'ом - тести будуть отримувати webdriver'и і віддавати їх цьому pool'у. Webdriver'и при цьому не закриваються (не викликається метод close). Це потрібно тому, що б не перезапускати браузер. Тобто таким чином виходить «реіспользованіе» webdriver'ов іншими тестами. Але повторне використання має свої мінуси - при поверненні webdriver'а в pool потрібно «підчистити» за собою - видалити всі cookie або, якщо це зробити не можна, виконати logout.
Так само, як надалі з'ясувалося, цей pool повинен перезапускати webdriveри, сесія яких завершилася. Таке можливо, коли сталася помилка на стороні сервера.

    Pool користувачів потрібний в основному при навантажувальному тестуванні, коли потрібно запускати однакові тести від різних користувачів. Він всього лише по колу віддає логін / пароль чергового користувача.
    Pool документів, так само як і користувачів, потрібний в основному при навантажувальному тестуванні - він по колу повертає id документів певного типу.

    Rule по зняттю скріншотів про помилку, потрібен, як випливає з назви, знімати скріншот про помилку виконання тесту. Він зберігає його в папку і записує в лог назва скриншота зі stacktrace'ом помилки. Дуже допомагає в подальшому «побачити» помилку, а не тільки прочитати її в логах. ( internetka.in.ua/selenium-rule-screenshot/ )
    Rule з видачі webdriver'а тесту потрібен для того, що б автоматизувати отримання перед початком тестового методу і повернення при його закінченні webdriver'а з pool'а webdriver'ів.

    Rule авторизації потрібен так само для автоматизації, тільки тепер авторизація - щоб в кожному тестовому методі не писати login \ logout.

 

Збір статистики

    Для збору статистики було вирішено не винаходити велосипед, а використовувати що-небудь з готових framework'ів. Пошук в інтернеті, на жаль, не дав широкого вибору - всього один інструмент - JETM (http: //jetm.void.fm/), та й він уже не змінювався з 2009 року. Хоча володіє хорошою документацією і невеликий плюси - віддалене підключення по HTTP для перегляду статистики в реальному часі.
    Код конфігурації монітора і запуску http-консолі:

 

BasicEtmConfigurator.configure ();               

EtmMonitor etmMonitor = EtmManager.getEtmMonitor ();

etmMonitor.start ();

HttpConsoleServer server = New HttpConsoleServer (etmMonitor);

server.start ();

 

    Збір статистики походив з двох місць - збирався загальний час виконання тестових методів (з рівня «запускальщика») і час виконання атомарних користувальницьких операцій (з третього рівня). Для вирішення першої проблеми використовувався спадкоємець RunListener'а, в якому перевизначаються методи початку і закінчення тесту і в них збиралася інформація про виконання.

    Рішення другої проблеми можна було виконати «в лоб» - на початку і наприкінці кожного методу, час виконання якого потрібно записувати, писати код для відліку цього часу. Але так як методів вже зараз більше п'яти, а надалі їх буде набагато більше, то хотілося б це автоматизувати. Для цього скористуємось AOP, а конкретно AspectJ. Був написаний простим аспектом, який додавав підрахунок часу виконання всіх public методів з класів з одними операціями. Час підраховувався тільки успішно виконаних методів, що б методи, що вилетіли з помилкою на середині виконання, не псували статистику. Так само виявився один недолік при зборі статистики за назвами методів - так як методи по роботі з одними операціями були універсальні і викликалися усіма тестами, але статистику потрібно було збирати за типами документів. Тому статистика збиралася не тільки за назвою методів, але ще й по їхніх аргументах, що ідентифікують тип документа.

Код методу аспекту

 

Around ( " execution (public static * < Пакет з класами користувальницьких операцій>. *. * (..))" )

Public Object profileMethod (ProceedingJoinPoint thisJoinPoint) throws Throwable {

EtmPoint point = EtmManager.getEtmMonitor (). CreatePoint (getPointName (thisJoinPoint));

Object result = thisJoinPoint.proceed ();

point.collect ();

Return Result;

}

 

Метод getPointName формує назву точки зрізу часу на основі назви методу і його параметрів.

 

⇐ Предыдущая12345678910Следующая ⇒

Поделиться: