Доповідь з SQA Days - Автоматизація тестування: відкидаємо зайве і перевіряємо суть

Наводимо доповідь Ігоря Хрола, компанія Wargaming, Мінськ, з конференції SQA Days 15.

Відео доповіді:
vimeo.com/93944414

Презентація:
www.slideshare.net/slideshow/embed_code/33725306#


Я 8 років працюю в цій галузі, і я вважаю, що у нас є проблеми )

Насамперед, тестування вважається нецікавою професією. Що з цього випливає? В галузь приходять недосвідчені люди, або недостатньо кваліфіковані. Складну роботу, тому що люди недосвідчені, кому робити. І виходить, що ми робимо нескладну роботу. А тому ми робимо нескладну роботу, то нам мало платять, тому що бізнесу ми приносимо не так багато, як хотіли б. І коло замикається.



В результаті, якщо тестування потрапляють талановиті люди, то випадково. І потім вони все одно йдуть в розробку. Тобто тестування вважається простий і нецікавою IT-професією, і якість тестування залишає бажати кращого.

В першу чергу, я закликаю вас пригадати: Хто ми? Software testing engineer. Інженери. Тобто ми не називаємося тестерами, тестерами та ін., ми — інженери. І я вважаю, що ситуацію можуть змінювати інженери своїми технічними навичками, своїми підходами.

Мені б хотілося відзначити, що наша робота складніше, ніж здається на перший погляд. Я зараз говорю про тестування, але для мене тестування та автоматизація злилися в єдине, тому що я вважаю, що основним інструментом тестувальника повинна бути автоматизація.

Назва грає роль.
• Автоматизація тестування (ми щось робимо руками, і ми це автоматизуємо)
• Автоматичне тестування (що він хоче нас бізнес? щоб тестування йшло якось само, автоматом, а ми там логи дивилися та ін. Мета — не автоматизувати тестування, а зробити тестування автоматичним)
• Ефективне автоматичне тестування

Розглянемо абстрактний проект у вакуумі.
Це — модель, вона описує життєву ситуацію в якійсь мірі наближення.
У нас є 5 модулів. У першому треба протестувати 5 варіантів, у другому — 8, а третьому — 2 варіанти і т.д. Все треба провести 800 тестів, щоб переконатися, що все працює.



Міняємо цифри на V: V1 * V2* V3*...*Vn В результаті Vn — середня складність модуля. Що таке Vn? Математична складність і експонента. Все будується на тому, що завдання, що має таку складність вирішується дуже погано.
Експоненційна складність. См графік.



Зелений графік, який довгий час тримається нижче інших, але в якийсь момент стрімко йде вгору. І коли ми тестуємо методом " чорного ящика", коли ми намагаємося перебрати всі варіанти, у нас виходить, що чорний ящик (складність такого тестування) — це експоненційна складність. У нас з'являється багато автотестів, які працюють годинами, що ми далі робимо? Запускаємо їх паралельно. Ми ділимо цю складність на константу. У нас та ж експонента, але трохи зменшена константа. Тобто це не вирішує проблему.



Розділяй і володарюй

Давайте подивимося на нашу задачу з іншого боку.
У нас було 26 тестів (якщо тестувати кожен модуль окремо). Але ви скажете, що треба переконатися, що все це разом працює. Добре, давайте протестуємо окремих тест-кейсом кожну зв'язок і проженемо якийсь наскрізний сценарій. Вийшов 31 тест. У підсумку, ми експоненційну складність міняємо на лінійну. І завдання стає ефективно вирішена. Тобто якщо ми погано тестували, і найняли ще 10 тестувальників, то ми просто распараллелили на 10, а якщо ми змінили саму складність завдання, то не треба так сильно збільшувати ресурси, необхідні для тестування.

Якщо у нас є якась абстрактна система, що має по одному варіанту, а в кінці — 10, якщо перемножимо, то у нас 10 тест-кейсів, а сумарно — 14. А плюс ще перевірити зв'язку — 19. Але тести стали простіше. Замість одного довгого тесту, ми пишемо 10 маленьких. Тобто за фактом складність тестів все одно спрощується.



«Піраміда» автоматизації.

Якщо ми не буде будувати наші тести на цій «піраміді», ми отримав експоненційну складність нашого завдання, нашого тестування. Самий дрібний модуль декомпозиції задач — це окремі класи, окремі методи. Головне — це декомпозиція задач. Якщо вона — односложна, то ми отримуємо множення, якщо ні, то ми отримуємо додавання, і в довгостроковій перспективі це буде краще.

Тестування — не таке просте. Бо щоб провести таку декомпозицію одного чорного ящика на багато дрібних, треба розібратися до кінця, аж до самих нижніх рівнів у технологічному стенді, в якому виробите. Тобто треба мати кваліфікацію порівнянну з кваліфікацією розробника. Без цього ми впираємося в експоненту, ми не робимо нашу роботу якісно краще. Відповідно, треба вчитися, і за рахунок цього, мені здається, що наша робота не така проста, як здається.



Проект з життя.
Siebel, Oracle — жорстке enterprise рішення, це був проект по кастомізації, по впровадженню мобільного оператору рішень на основі технологій Siebel. До того як я приєднався до проекту, тести писалися на QTP. Вони представляли з себе таку структуру: там був внутрішній API, тести і ходять, клацають на кнопочки, в середині — чорний ящик, і знизу база даних. Досить типова картина.



Як результат: тести довгі, тести нестабільні. Прийшла завдання: оптимізувати передумови, які робляться годинами.

Я написав на java скриптик, який відправляє GET запит, парсити XML, дивиться XML, відправляє ще один GET запит і т.д. Тести стали працювати 20 хвилин і стали добре параллелиться.

В результаті відмови від браузера тести стали працювати швидше, не стало проблем з синхронізацією, тести стали більш надійні і легко запускатися паралельно. З мінусів: не видно, як працюють тести; немає довіри, і вище поріг входження.

Питання «не видно» зважився як у старому анекдоті: «Вам шашечки чи їхати?» Вам на тести дивитися, чи треба проводити тестування? Тобто тут питання: ми хочемо автоматичне тестування або автоматизувати тестування?

Структура рішення: Java + TestNG + Maven + HttpClient. Покласти кілька рівнів абстракцій, щоб не працювати безпосередньо, запити не писати, а працювати з сутностями, які специфічні для Siebel'а.



Але виявилося, що від браузера не піти, і частина логіки виявилася реалізована в самому браузері. Тобто частина логіки була на сервері, а частина логіки — браузері. Тому з'явився Selenium. Але знаючи про те, що браузер — це довго, нестабільно і неміцно, ми це робили акуратно. Запускали тільки тоді, коли реально потрібен браузер, коли в тест-кейсі з'являється логіка, яка реалізована в браузері, і яку ми хочемо перевірити (близько 3% сценаріїв). Також реиспользуется headless-сесія з безбраузерного взаємодії.

Далі декомпозируем цю задачу на якісь шматочки. Виявилося, що верстка браузера генерується самим Siebel'ом. І нам не важливо, щоб натискання на кнопку було реальним, тому що це вже розроблено Siebel'е, це протестовано в Siebel'е, нам треба просто відкинути зайве і тестувати тільки те, що ми робили.
Виявилося, що для розробки браузерною логіки є API (оф. документація Oracle): хочеш щось зробити в UI — виклич ось той метод.



База даних.
Це — найшвидший спосіб працювати з системою, але краще туди безпосередньо не писати (але це була специфіка нашого проекту). Якісь зміни в базі ми робили через спеціальні вивірені stored procedures, і це добре підходить для перевірок.

Web-сервіси
JAX-WS — це протокол в Java для роботи з web-сервісом. Замість того, щоб тестувати наш Siebel в контексті всіх інших систем, ми заглушили всі зовнішні взаємодії, і коли нам треба було перевірити, що з Siebel'а що-то йде, ми дивилися це не на якихось зовнішніх системах, а на заглушках. Також ми відправляли java запити на web-сервіси для перевірки вихідної інформації.

Наш сервер складається з двох частин: Web-сервер і Application-сервер. Web-сервер відповідає за верстку та надсилання відповідей, а Application-сервер за логіку програми. І є доступ до логіки через Java Data Веап.И через неї ми отримали повний програмний інтерфейс для створення логіки додатків в Siebel'е з Java.

Тести продуктивності.
Тому наші тести пишуться на java, оскільки вони добре параллелятся, ми можемо просто «нацькувати» на JMeter наші тести, і по суті навантажити систему функціональними тестами. Також тести суппортились разом з підтримкою функціональних тестів. Тобто якщо для нового білду потрібні були нові версії скриптів, ми все одно для проведення функціональних тестів ці скрипти оновлюємо.



Ми розібралися, як працює наш стек технологій, зрозуміли варіанти взаємодій, і ми розуміли, що чим нижче ми опускаємося, тим більш швидко і надійно.
В результаті ми отримали:
• швидкі тести
• передбачувані результати які легко масштабуються
• можливість взаємодії з Siebel на будь-якому рівні

Мені б не хотілося, щоб моя доповідь сприймався як інструкція: “Як працювати з Siebel “. Мені б хотілося, щоб ви глянули на свій стек технологій і подивилися, що там «під капотом», тому що це робить нашу роботу якісніше та цікавіше.
Погляд на тестування з боку реалізації системи дозволяє:
• зменшити складність самої задачі тестування
• зменшити складність і довжину сценаріїв
• збільшити швидкість і стабільність роботи
• знайти нові області застосування автотестів

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.