19.08.2016, 15:37:31
Войти Зарегистрироваться
Авторизация на сайте

Ваш логин:

Ваш пароль:

Забыли пароль?

Навигация
Новости
Архив новостей
Реклама
Календарь событий
Right Left

Автоматизоване тестування ПО: переваги і недоліки

ТЕСТУВАННЯ

Сьогодні автоматизація тестування (далі АТ) набуває все більшої популярності у вітчизняних виробників ПЗ. Для навчального центру компанії VDI, в якому я працюю, ця тенденція проявляється в збільшенні числа замовлень на навчання. Починаючи новий курс по АТ, я зазвичай розповідаю про переваги і недоліки цієї методики і даю ряд зауважень і рекомендацій, які можуть стати в нагоді тестувальникам в їх роботі. У даній статті я постарався по можливості доступно їх викласти.

Якщо говорити про те, навіщо взагалі потрібно автоматизоване тестування, то слід пам'ятати, що АТ для компанії - це інвестиції в майбутнє. Якщо підприємство вирішило значно підвищити якість своєї продукції і перейти на новий рівень виробництва ПО, то воно з великою ймовірністю займеться АТ. Перехід з ручного тестування на автоматичне вимагає багато часу і грошей, а також серйозного коригування бізнес-процесів. Однак ці витрати з лишком окупаються, коли фірма починає випускати більш якісне ПЗ, ніж у конкурентів, та ще й набагато швидше. А для тестувальника АТ - це інвестиції в сьогодення. Середня зарплата фахівця з АТ в два рази перевищує зарплату тестувальника, котрий має такими навичками. Крім того, проведення АТ вимагає від фахівця загального бачення проекту, вміння планувати і розподіляти ресурси, що, безсумнівно, благотворно позначається на його кар'єрі.

Тепер трохи теорії. Автоматизованим називається тестування із застосуванням засобів автоматизації. Існують три типи тестування, які можна автоматизувати: функціональне (в тому числі модульне, або unit-тестування), регресійні (перевірка працездатності старого функціоналу і відсутність раніше виправлених дефектів в нових версіях) і навантажувальний (поведінку програми під робочою і стресовим навантаженням, вплив працюючого додатки на системне оточення). Але тут слід підкреслити, що якщо автоматизацію застосувати можна, то це далеко не завжди означає, що застосовувати її потрібно. Як і в будь-якій справі, приймаючи рішення про автоматизацію, необхідно керуватися принципом вигоди.

Якщо ви розраховуєте вигоду автоматизації для компанії, то можна використовувати таку формулу:

K = NT х P / (L + T 'х P'),

де K - коефіцієнт вигоди; N - кількість версій програмного продукту, яке планується випустити в ході реалізації проекту; T - час на ручне виконання тест-плану тестувальником; P - зарплата тестувальника; L - вартість ліцензії на засіб автоматизації; T '- час на розробку, підтримку і виконання Автотест фахівцем з АТ; P '- зарплата фахівця з АТ.

Автоматизація має сенс, якщо K> 1. Як видно, ця умова буде виконуватися тільки в тому випадку, якщо величини N або T досить великі. Тобто якщо в компанії добре поставлений процес виробництва ПО (випускається і передбачається, що і в подальшому буде випускатися, багато версій програмного продукту) або специфіка виробленого ПО така, що тестувати його вручну складно (наприклад, якісь банківські додатки з безліччю полів для введення критичних даних). Однак ці умови пом'якшуються, якщо раптом виявиться, що L = 0.

Мал. 1. Варіанти тестування

Для тестувальника, вільно володіє засобами автоматизації і не піклується про ліцензії, головний критерій прийняття рішення про автоматизацію - можливість заощадити час. При цьому не важливо, який процес розробки в компанії і який продукт вона виробляє: якщо у вас є під рукою знайоме засіб АТ і ви розумієте, що з його допомогою набагато швидше виконайте тест, то користуйтеся ним. Скажімо, в якомусь простому графічному додатку, зазвичай тестируемом вручну, з'явилося поле, для якого треба перевіряти введення сотні різних значень. В цьому випадку автоматизація - розумний вихід.

переваги автоматизації

Але чому ж так хороша автоматизація тестування?

По-перше, АТ економить час. Програма-робот набагато швидше "клацає по клавішах" або посилає запити по протоколу, ніж будь-яка людина. Значить, програмісти швидше дізнаються про помилки і виправлять їх. І компанія отримає перевагу перед конкурентами.

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

По-третє, АТ дає можливість працювати без графічного інтерфейсу користувача. Часто буває так, що на ранніх етапах розвитку програмного продукту цей інтерфейс ще не узгоджений і ПО являє собою по суті набір якихось модулів і елементів, які тим не менше повинні правильно працювати. Або, наприклад, на одній з ітерацій додають функцію в майже готовий продукт, так що доступу через інтерфейс до неї немає. Що вже говорити про обмін даними по протоколах, який може відбуватися взагалі непомітно для користувача. Хороші засоби АТ можуть істотно допомогти в таких випадках.

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

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

проблеми автоматизації

Однак не потрібно спокушатися: незважаючи на безліч переваг, АТ має ряд обмежень і недоліків, які необхідно брати до уваги.

Так, автоматизація вимагає часу на створення, підтримку і тестування (!) Тестів. Як не дивно, автоматизоване тестування завжди починається з тестування вручну. Вам просто необхідно показати роботу, як, що і з чим він повинен робити. Не забувайте, що будь-який засіб АТ - це всього лише інструмент. Воно не буде писати за вас тест-план, а буде тільки виконувати те, що ви його попросите, і тільки так, як попросите. Визначили завдання недостатньо чітко - робот вас не зрозуміє. Запрограмували зробити дурість - зробить. Тому автотест, як і будь-яка звичайна програма, вимагає дбайливого ставлення - акуратного створення, постійної підтримки і тестування. На все це потрібен час, і часом не багатьом менше, ніж на розробку самого програмного продукту.

Крім того, АТ вимагає від тестувальника програмістів навичок. Зазвичай вважається, що тестувальник - це антипод програміста, і дійсно, тестери часто зовсім не вміють програмувати. І це навіть добре, якщо користуватися методологією "чорного ящика". Але коли мова йде про автоматизацію, тут ситуація змінюється. Можна, звичайно, спробувати створювати Автотест, не вдаючись до роботи з кодом тестових скриптів, але з цим швидше за все нічого не вийде. Більшість сучасних засобів АТ пропонують широкі можливості для простого і легкого створення Автотест виключно за допомогою GUI-інструментарію самого засобу - залишається тільки записувати свої дії. Але справжня професійна автоматизація тестування неможлива без роботи безпосередньо з кодом тестового скрипта і без відмінного знання об'єктно-орієнтованого програмування. Тому будь-який фахівець з АТ рано чи пізно стає справжнім програмістом. Якщо таким не є відразу.

Автоматизовані тести дуже чутливі до середовища - програмному і навіть апаратного оточення тестованого програми. Ви можете дуже здивуватися, побачивши, що один і той же тест однієї і тієї ж версії сьогодні проходить зовсім інакше, ніж вчора. Зайві відкриті екземпляри додатку, системні процеси, незначні зміни в описі об'єктів - всі ці непомітні людині фактори враховуються засобом АТ. Тому ваша задача - створити фіксовану тестову середу, максимально докладно описавши використовувані об'єкти і виділивши для тестування окремий комп'ютер. Загалом, подбати про чистоту експерименту. Запам'ятайте: зовсім неприпустимо застосовувати автоматизацію для безперервно змінюється продукту (над яким, наприклад, спонтанним чином працюють програмісти). Дане правило справедливо і для тестування взагалі (див. Рис. 1). Не можна цього робити і тоді, коли немає впевненості в тому, що тестується один і той же об'єкт в одних і тих же умовах (червона лінія на малюнку). Тому процес виробництва ПО повинен передбачати якісь періоди, коли зміни не вводяться і тестувальники можуть спокійно працювати (сходинки на чорному графіку).

Нарешті, АТ можна використовувати стосовно об'єктів, які може тестувати тільки людина. Засіб АТ можна розглядати як робота, що володіє якоюсь подобою штучного інтелекту. Як відомо, основна проблема штучного інтелекту - в розпізнаванні складних образів і моделей поведінки. Тобто за допомогою автомата можна протестувати, наприклад, ергономіку (суб'єктивне зручність) інтерфейсу додатку або коректність фотографії.

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

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

Чималу проблему при автотестування становить також робота з різними платформами і протоколами. Не всі інструменти АТ однаково добре працюють (якщо взагалі працюють) з усіма відомими технологіями створення додатків і обміну даними. Наприклад, WinRunner нізащо не захоче тестувати ПО, написане на .NET, а WebLoad не стане генерувати навантаження для протоколу ODBC. Хороший спеціаліст по автотестування повинен знати всю лінійку сучасних засобів в цій галузі, знати їх переваги та недоліки і вміти вибрати відповідний інструмент в потрібний момент, а також підібрати плагін, що розширює його можливості.

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

Мал. 2. Схема роботи з

інструментами функціонального АТ

Окремо слід сказати про планування АТ. Для функціонального тестування все просто: тут основа - вимоги, явні і неявні. У тестуванні не повинно бути нічого, крім перевірки вимог. Поділяємо їх за ступенем критичності і починаємо планувати тести найкритичніших користувальницьких бізнес-прецедентів (UseCase). Зрозуміло, не забуваємо про баланс між користю АТ і витратами на неї. Якщо можна уникнути автоматизації, то краще так і зробити. Ну а далі - все як у звичайному тестуванні: дотримуємося максимальне тестове покриття вимог і ненадмірність тестів.

Для навантажувального тестування справа йде трохи складніше. Взагалі цей вид тестування має три основні цілі. Перша - переконатися, що при тій чи іншій навантаженні додаток не дає збої, т. Е. Відсутні помилки. Друга - перевірити, чи зберігається з ростом навантаження зручність (ергономіка) додатки. Наприклад, перевіряємо час відгуку сервера на вимогу "клієнт не повинен чекати відкриття сторінки більш восьми секунд". Третя - пошук небезпечних тенденцій для системних ресурсів клієнта і сервера. Скажімо, спроба визначити, що відбувається з пам'яттю при збільшенні кількості клієнтів або при їх тривалій роботі, чи немає витоків, здатних досягти критичної позначки. Рівнів навантаження теж три. Мінімальне навантаження (один користувач) дозволяє перевірити, що додаток в принципі працездатний. Робоча (деяка кількість клієнтів, що вважається штатним) - коли додаток має поводитися бездоганно. І нарешті, стресова, або пікова, навантаження, яку програма має витримувати в принципі. Конкретні цифри визначає ваш бізнес-аналітик, або менеджер проекту, або навіть ви самі, спираючись на статистику. Для різних UseCase ці цифри можуть сильно відрізнятися. Не слід забувати і про те, що існує системне тестування - коли треба перевіряти загальну працездатність додатки при різноманітної навантаженні.

засоби автоматизації

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

Для інструментів функціонального АТ має місце схема "з чим - що - як". Щоб робот міг робити те, що вам потрібно, йому треба "пояснити", з чим працювати, - побудувати репозиторій (бібліотеку) з докладним описом всіх використовуваних в тесті об'єктів; що конкретно робити - записати бібліотеку функцій, методів або елементарних дій з об'єктами (якщо вас не влаштовують стандартні методи) - і як робити, в якій послідовності - створити скрипт, що містить опис тестових кроків, логіки тесту і глобальних змінних. Цю схему можна зобразити у вигляді трикутника зі взаємопов'язаними вершинами (див. Рис. 2).

Для навантажувального тестування додаються варіанти багатокористувацької і многопротокольной роботи. Ви маєте можливість задавати послідовність доступу віртуальних користувачів, вказувати, що і коли їм потрібно робити, - прямо як режисер. Напевно, тому навантажувальні тести часто називаються сценаріями. До того ж ваші віртуальні актори (actor - стандартну назву користувача в універсальній мові моделювання UML) можуть говорити на різних мовах, т. Е. Обмінюватися даними одночасно по різних протоколах.

На закінчення зробимо короткий огляд найбільш відомих засобів АТ.

Функціональне та регресійні тестування

Mercury QuickTest. З переваг цього потужного засобу компанії Mercury (www.mercury.com) слід виділити зручний і зрозумілий призначений для користувача інтерфейс для створення тестів без ручної правки скрипта, з недоліків - необхідність ліцензій для розширень і незручність роботи з нестандартними об'єктами.

Mercury WinRunner. Уже початкуюче застарівати засіб тієї ж компанії. Від QuickTest воно відрізняється тим, що вам доводиться багато вручну працювати з кодом, написаним на спеціальній мові TSL.

Segue SilkTest. Цікаве і відносно зручний засіб, яку пропонує компанія Segue Software (www.segue.com), надає широкі можливості для ручної роботи зі стандартними і нестандартними об'єктами на об'єктно-орієнтованої мови 4Test.

Rational Robot. Уже майже застаріле засіб від компанії IBM (www.ibm.com/ru) з досить незручним мовою.

Тестування навантаження

Mercury LoadRunner. Дуже зручний інструмент - однозначний лідер, що володіє широким спектром можливостей.

Segue SilkPerformer. Хороший засіб зі своїми достоїнствами і недоліками.

RadView WebLoad. Непогана програма компанії RadView Software (www.radview.com) для тестування Web-додатків, але не більше того.

З автором статті, провідним тренером у напрямку QA навчального центру компанії VDI, можна зв'язатися за адресою: [email protected].

Версія для друку

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