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

ДИПЛОМНА РОБОТА.

за ОКР магістра.

Тема: Автоматизація процесів тестування програмного забезпечення.

РЕФЕРАТ.

Дипломна робота: 63 с., 19 рис., 1 табл., 16 джерел, 1 додаток.

Об'єктом дослідження є процес тестування програмного забезпечення.

Мета магістерської роботи: розробка алгоритму автоматичної генерації тестів і утворення тестового набору для ручного виконання.

Методи дослідження. При вирішенні поставлених завдань було використано теоретичні знання та практичні надбання в галузі моделей програмного забезпечення; для побудови формальної моделі використані теорія графів і теорія автоматів.

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

Результати досліджень можуть бути застосовані при відділом тестування при створенні тестових наборів або бути інтегровані як складова у систему підтримки тестування програмного забезпечення.

Перелік ключових слів: ТЕСТУВАННЯ, ГЕНЕРАЦІЯ ТЕСТОВОГО НАБОРУ, СКІНЧЕНИЙ АВТОМАТ, ДІАГРАМА СТАНІВ ТА ПЕРЕХОДІВ.

ABSTRACT.

The master project of Anna Skumina, the 5th course student (Oles Honchar Dnipropetrovsk National University, Faculty of Applied Mathematics, Computer technologies department) is devoted to the research of algorithm for automation of test cases generation for manual execution. The existing formal models for software requirements specification have been considered and the finite state machine has been finally chosen.

The developed approach provides the variety of advantages such as guaranteed achievement of transition coverage, reducing ability to make a mistake via fixation of maximum value of steps in the test, selection of tests, which provide additional coverage, to the set. The extra effect is the detection of software requirements faults and contradictions during their translation into the state transition graph.

At the end, the application has been built to demonstrate declared approach, which can be easily used in a separate way or be integrated into the larger system of software testing support.

Bibliography 16, pictures 19, supplement 1.

ЗМІСТ.

• ВСТУП 6
• ПОСТАНОВКА ЗАДАЧІ 11
• РОЗДІЛ 1. АНАЛІЗ ПРОБЛЕМ ПРОЦЕСУ ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 12
• 1.1 Зв’язок між тестування і забезпеченням якості 17
• 1.2 Аналіз процесу тестування програмного забезпечення 18
• 1.3 Автоматизація процесу тестування програмного забезпечення 20
• 1.4 Аналіз переваг автоматичного тестування 28
• 1.5 Аналіз недоліків автоматичного тестування 29
• 1.6 Обґрунтування генерації тестів як більш ефективного підходу 30
• 1.7 Аналіз процесу ручного створення функціональних тестів 32
• РОЗДІЛ 2. ОБГРУНТУВАННЯ ПІДХОДУ 38
• 2.1 Формальна модель представлення вимог 38
• 2.2 Скінчений автомат 43
• 2.3 Діаграма станів і переходів 47
• 2.4 Повнота тестового покриття 48
• 2.5 Побудова тестів 49
• 2.6 Побудова тестового набору 52
• РОЗДІЛ 3. ГЕНЕРАТОР ТЕСТОВОГО НАБОРУ 57
• 3.1 Логіка додатку 57
• 3.2 Вибір середовища 57
• 3.3 Бібліотеки Boost 58
• 3.4 Структура додатку: Класи 60
• 3.5 Структура додатку: Методи 62
• 3.6 Інтерфейс додатку та параметри запуску 63
• РОЗДІЛ 4. РЕЗУЛЬТАТИ РОБОТИ 65
• 4.1 Приклад № 1: Побудова тестів для системи «Банкомат» 65
• 4.2 Приклад № 2: Побудова тестового набору для баг-трекінгової системи, представленої графом із циклами 69
• 4.3 Приклад № 3: Побудова різних тестових наборів із встановленим рівнем покриття 70
• ВИСНОВКИ 71
• СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ 74
• Додаток А 76

ВСТУП.

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

Разом із обчислювальними можливостями значного розвитку зазнала і галузь програмного забезпечення, яке є інтерфейсом взаємодії людини і комп’ютерної техніки. Комп’ютерні програми стали вірними помічниками у найрізноманітніших сферах нашого життя. Якщо такі додатки як текстові редактори, системи документообігу або Інтернет — браузери є чимось досить звичним, то такі, скажімо, як прикладка для смартфонів, що аналізує за допомогою вбудованого акселерометру рухи людини під час сну і будить її під час швидкої його фази, що сприяє простому підйому і відчуттю бадьорості, — щось справді дивовижне.

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

Слід звернути увагу, що один і той самий недолік, може мати зовсім різний негативний вплив. Яскравим прикладом може слугувати граматична помилка. Якщо автор припустився її на локальній веб сторінці, де він склав генеалогічне дерево своєї родини, то максимальний негативний вплив, коли вона буде виявлена, це короткочасова образа з боку членів родини. Граматична помилка на офіційній Інтернет сторінці певного бізнесу може мати вкрай суттєві наслідки, партнери та клієнти можуть розцінити її як прояв непрофесійності і звернутися до конкурентів. Чи слід говорити про вплив такої помилки в авіаційній, медичній та фармацевтичній чи атомній галузях? Ціною неправильно складеного речення може опинитися загроза здоров’ю чи навіть життю людини.

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

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

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

У тестування є і інший аспект. За результатами досліджень Market Enablers — міжнародної мережі компаній, що займається консалтингом та оглядом статистики, грошовий обіг прикладок для смартфонів за 2010 рік склав 2 млрд. доларів, за прогнозами через п’ять років, у 2015 році, грошовий обіг лише ринку мобільних іграшок буде становити 11 млрд. доларів. І якщо раніше ігри встановлювались з дистрибутивів, наперед придбаних, або годинами завантажувались із Інтернету, то сьогодні у епоху сенсорних екранів та швидкісного Інтернету користувач очікує встановлення програми за одним дотиком. Якщо ні - він за миті може завантажити прикладку конкурента. Зросли також користувацькі очікування й щодо зручності програмного інтерфейсу. Інтерфейс повинен бути зручним, ергономічним, привітним, простим та зрозумілим. Ці аспекти сьогодні підлягають тестуванню настільки ж ретельному як і правильність функціонування, адже якість додатку визначається задоволенням користувацьких очікувань.

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

Слід звернути увагу, що тестування не гарантує якості прикладки, а лише проводить її аудит, і впливає на неї побічно: коли виявлені протягом тестування недоліки будуть виправлені, якість продукту зросте.

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

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

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

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

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

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

У першому розділі даної роботи буде розглянуто тестування у процесі розробки програмного забезпечення, його зв’язок із якістю продукту, автоматизація тестування у широкому і вузькому сенсі.

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

У третьому розділі розглядається структура додатку, що демонструє заявлений підхід.

У четвертому розділі наведено результати експерименту.

ПОСТАНОВКА ЗАДАЧІ.

1. Розглянути існуючі формальні моделі для представлення програмного забезпечення.

2. Розробити підхід генерації тестів на основі обраної моделі.

3. Розробити програмне забезпечення, що демонструє заявлений підхід — генерує тести і формує з них тестовий набір.

4. Продемонструвати роботу розробленого програмного забезпечення на прикладах.

РОЗДІЛ 1. АНАЛІЗ ПРОБЛЕМ ПРОЦЕСУ ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ.

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

Тому зараз тестування є неодмінною умовою успішного функціонування як для гігантів індустрії таких як Google, Microsoft, IBM чи Oracle, так і для розробників програмного забезпечення «під замовлення» .

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

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

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

Каскадна модель або «водоспад».

Найраніша модель розробки ПЗ, запропонована 1970 році Уінстоном Ройсом. Вона передбачає послідовне виконання всіх етапів проекту в чітко фіксованому порядку рис. 1.1. Перехід на наступний етап означає повне завершення робіт на попередньому. Вимоги, визначені на стадії формування вимог, суворо документуються у вигляді технічного завдання і фіксуються на весь час розробки проекту. Кожна стадія завершується випуском повного комплекту документації, достатньої для того, щоб розробка могла бути продовжена іншою командою розробників.

Рис. 1.1 Каскадна модель або «водоспад».

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

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

Рис. 1.2 Ціна виправлення дефекту на різних етапах розробки ПО.

Vмодель.

Рис. 1.3 Vмодель.

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

V-модель демонструє як перевірка (верифікація і валідація) може бути інтегрована у кожний етап життєвого циклу рис. 1.3.

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

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

Ітеративна модель.

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

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

Рис. 1.4 Ітеративна модель.

Тестування у ітеративній моделі.

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

Регресійне тестування є важливим для кожної ітерації після першої. З цього випливає, що об'єм тестування для кожної наступної фази буде збільшуватись.

Гнучка розробка.

Гнучка розробка бере за основу ітеративний підхід, але зумовлює більш «легкий» та більш орієнтований на людські ресурси механізм. Гнучкі процеси використовують зворотній зв’язок замість планування як основний механізм контролю. Зворотній зв’язок гарантується частими тестами і раннім релізом продукту, що є в розробці. Найпопулярнішими варіаціями гнучких моделей є Екстремальне програмування (XP) і Scrum..

Тестування у гнучкій розробці.

Гнучка розробка часто використовує підхід розробки через тести — це підхід, який зумовлює спочатку написання автоматичних модульних тестів, своєрідних прикладів, а потім написання коду безпосередньо.

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

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

1.1 Зв’язок між тестування і забезпеченням якості.

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

Тестування — інформаційний сервіс. Тестування вимірює якість, однак не гарантує її.

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

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

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

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

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

1.2 Аналіз процесу тестування програмного забезпечення.

Найпомітніша активність з тестування — це безпосереднє виконання тестів. Однак, щоб тестування було ефективним і результативним, час повинен бути виділений на його планування, дизайн тестів, підготовку до виконання і оцінку результатів.

Фундаментальний процес тестування складається із наступних головних активностей:

· Планування і контроль.

· Аналіз і дизайн.

· Розробка та виконання тестів.

· Оцінка вихідного критерію та звітність.

· Активності по завершенню тестування.

Ці активності знаходяться у логічній послідовності слідування, однак можуть виконуватись і паралельно.

Планування і контроль.

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

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

Вони також включають активності необхідні для досягнення запланованих цілей проекту. Планування бере до уваги зворотній зв’язок від моніторингу і контролю.

Аналіз і дизайн.

На етапі аналізу та дизайну загальні цілі транслюються у конкретні умови для тестування і тестові випадки.

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

Розробка та виконання тестів.

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

Серед задач даної фази виділяють наступні:

· Розробка і пріорітезація тестових випадків.

· Розробка тестової процедури для кожного тестового випадку, створення для нього тестових даних, і опціонально, написання для нього автоматичного скрипту.

· Створення тестових наборів для ефективного виконання тестів (після умова попереднього тесту є передумовою наступного).

· Перевірка, що тестове обладнання налаштовано правильно.

· Виконання тестових процедур вручну або з використанням спеціальних інструментів для виконання я заданій тестовим набором послідовності.

· Запис результатів виконання тестів і запис відповідної версії продукту під тестуванням, тестового інструменті і тестового обладнання.

· Порівняння актуального результату із запланованим.

· Звітування відхилень як інцидентів і їх аналіз з метою виявлення їх причин.

· Повтор активностей з тестування з метою перевірки, що виправлені дефекти справді виправлені і не стали причиною виникнення нових недоліків.

Оцінка вихідного критерію та звітність.

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

Для даного етапу характерні наступні задачі:

· Перевірка запису результатів тестування на задоволення ними встановленого на стадії вихідного критерію.

· Оцінка на предмет необхідності проведення додаткових перевірок о перегляд встановленого вихідного критерію.

· Написання результуючого звіту для зацікавлених осіб.

Активності по завершенню тестування.

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

Наступні задачі мають місце:

· Перевірка які з запланованих результатів отримані.

· Закриття репортів про інциденти.

· Документування результатів приймального тестування.

· Архівація тестового обладнання для наступного повторного використання.

· Використання отриманої інформації для удосконалення процесу.

1.3 Автоматизація процесу тестування програмного забезпечення.

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

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

Сьогодні ринок програмного забезпечення, що асистує тестуванню досить різноманітний. Є безліч засобів тестування, які підтримують різні його аспекти. Існуючи інструменти можна класифікувати за декількома критеріями — цілі, вартість (комерційні, безкоштовні, з відкритим кодом), за технологією, що покладено в основу тощо.

Найпоширенішою є класифікація за активностями, які інструмент підтримує. Деякі засоби мають лише одне призначення; інші можуть підтримувати більше, ніж одне, але класифікуються за тією функцією, з якою вони найбільш тісно пов’язані.

· Інструменти, що асистують управлінню тестуванням і тестами.

· Інструменти, що асистують статичному тестуванню.

· Інструменти, що асистують створенню тестів.

· Інструменти, що асистують виконанню тестів та запису результатів.

· Інструменти, що асистують моніторинг продуктивності.

Інструменти, що асистують управлінню тестуванням і тестами.

Засоби управління застосовуються у всіх процесах тестування протягом всього життєвого циклу розробки ПЗ.

Інструменти управління тестуванням.

· Інструменти цієї групи забезпечують:

· Підтримку керування виконанням тестів і процесами тестування.

· Інтерфейс для засобів виконання тестів, засобів відстеження дефектів і засобів управління вимогами.

· Незалежний засіб керування версіями або інтерфейс для зовнішнього засобу управління конфігураціями.

· Засоби для трасуванню тестів, результатів тестування та звітів про інциденти із вхідною документацією, такою як специфікація вимог Запис результатів тестування та генерація звітів.

· Кількісний аналіз (метрики), пов’язані з тестами (наприклад, виконані тести і успішні тести) і тестовим об'єктах (наприклад, виявлені відмови системи), для того, щоб дати інформацію про тестові об'єкти і для того, щоб контролювати і поліпшувати процес.

Засоби керування вимогами.

Засоби керування вимогами зберігають вимоги, перевіряють їх на узгодженість і наявність невизначених (пропущених) вимог, дозволяють розставляти пріоритети за вимогами і дозволяють окремим тестами трасуватися згідно до вимогам, функцій або опцій. Результати трасування можуть бути включені у звіти про тестування. Покриття вимог, функцій або опцій набором тестів також може бути відображено у звітах.

Засоби управління інцидентами.

Засоби управління інцидентами зберігають і управляють звітами про відмови, тобто дефекти, збої або проблеми і відхилення, і забезпечують управління звітами про інциденти таким чином, що:

· Допомагають виставляти пріоритети.

· Розподіляють необхідні дії між людьми (наприклад, тестування виправлень).

· Визначення статусів (наприклад, скасований, готовий бути протестований або відкладений до наступного випуску).

· Ці засоби дозволяють постійно відстежувати звіти про інциденти, часто сприяють статистичному аналізу і надають звіти про інциденти. Вони також відомі як засобу відстеження дефектів.

Засоби управління конфігураціями.

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

· Зберігають інформацію про версії та збірки ПЗ і проведене тестуванням.

· Забезпечують зіставлення між проведеним тестуванням і результатом роботи ПЗ та варіантами продукту Особливо корисні, коли розробка ведеться більш ніж на одній конфігурації апаратного та програмного забезпечення (наприклад, для різних версій операційних систем, різних бібліотек або компіляторів, різних браузерів або різних комп’ютерів).

Інструменти, що асистують статичному тестуванню.

Засоби підтримки процесу експертизи.

Засоби підтримки процесу експертизи можуть зберігати інформацію про процеси експертизи, зберігати і обмінюватися експертними коментарями, надавати інформацію про дефекти і обсяги робіт, керувати зв’язками з експертними правилами та / або списками перевірки, і забезпечувати трасуванню між документацією і вихідним кодом. Також вони можуть надавати можливість експертизи в реальному часі, яка корисна для географічно розподіленої команди.

Засоби статичного аналізу.

Засоби статичного аналізу допомагають розробникам, спеціалістам з тестування і співробітникам забезпечення якості в пошуку дефектів до початку динамічного тестування. Основні цілі включають:

Дотримання стандартів програмування.

· Аналіз структури і залежностей (наприклад, посилання на веб-сторінках).

· Допомога в розумінні коду.

· Засоби статичного аналізу можуть витягувати метрики з вихідного коду (наприклад, складність), які можуть дати цінну інформацію, наприклад, для аналізу планування або ризиків.

Засоби моделювання.

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

Інструменти, що асистують створенню тестів.

Засоби проектування тестів.

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

Засоби підготовки тестових даних.

Засоби підготовки тестових даних оперують з базами даних, файлами, або передачею даних для визначення тестових даних, які будуть використовуватися під час виконання тестів. Перевага таких інструментів у тому, що реальні дані передаються в тестове середовище анонімно для захисту даних.

Засоби підтримки виконання і протоколювання тестів.

Засоби виконання тестів.

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

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

Засоби виконання тестів також можуть використовуватися механізм запису/відтворення тестів. Запис тестових вхідних даних під час дослідницького тестування може бути корисно для відтворення або документування тесту, наприклад, якщо відбулася відмова.

Тестовий вузол / засоби оболонки модульних тестів.

Тестові вузли можуть полегшувати тестування компонентів або частини системи, імітуючи оточення, на якому об'єкт тестування буде працювати. Це може бути зроблено через те, що інші компоненти цього оточення ще не готові і замінені заглушками і / або драйверами, або просто для того, щоб забезпечити передбачуване і контрольоване оточення, в якому будь-які відмови можуть бути локалізовані в об'єкті тестування. Оболонка може бути створена там, де частина коду, об'єкт, метод або функція, модуль чи компонент можуть бути виконані, викликаючи об'єкт тестування або забезпечуючи зворотний зв’язок з цим об'єктом.

Тестові порівняльники.

Тестові порівняльники встановлюють відмінності між файлами, базами даних або тестовими результатами. Засоби виконання тестів зазвичай включають динамічні порівняльники, але порівняння після виконання може бути виконано окремими засобами. Тестовий порівняльник може використовувати тестового оракула, особливо якщо він автоматизований.

Засоби вимірювання покриття.

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

Засоби безпеки.

Засоби безпеки перевіряють на комп’ютерні віруси та DoS-атаки. Інші інструменти безпеки навантажують систему, шукаючи певні уразливості в ній.

Інструменти, що асистують моніторинг продуктивності.

Засоби динамічного аналізу.

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

Засоби тестування продуктивності / навантажувального / стресового тестування.

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

Засоби моніторингу.

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

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

Під автоматизацією тестування у вузькому сенсі мають на увазі залучення інструментів до перевірки програми під час її виконання — тобто під час динамічного тестування. Подібні інструменти емулюють дії користувача за допомогою спеціальних тестових фремворків.

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

Автоматизація продуктів з графічним користувацьким інтерфейсом розвивалася протягом 4 поколінь інструментів та технік:

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

Сценарії (Scripting) — форма програмування на мовах, спеціально розроблених для автоматизації тестування ПЗ — пом’якшує багато проблем capture / playback інструментів. Але розробкою займаються програмісти високого рівня, які працюють окремо від тестувальників, безпосередньо запускають тести. До того ж скрипти найбільше підходять для тестування GUI і не можуть бути впровадженими, пакетними або взагалі яким-небудь чином об'єднані в систему. Нарешті, зміни в ПЗ вимагають складних змін у скриптах, і підтримка все зростаючою бібліотеки тестуючих скриптів стає врешті-решт непереборної завданням.

Data-driven testing — методологія, яка використовується в автоматизації тестування. Особливістю є те, що тестові скрипти виконуються та верифікуються на основі даних, які зберігаються в центральному сховищі даних або БД. Роль БД можуть виконувати ODBC-ресурси, csv або xls файли і т.д. Data-driven testing — це об'єднання декількох взаємодіючих тестових скриптів і їх джерел даних у фреймворк, який використовується в методології. У цьому фреймворку змінні використовуються як для вхідних значень, так і для вихідних перевірочних значень: у тестовому скрипті зазвичай закодовані навігація по додатком, читання джерел даних, ведення логів тестування. Таким чином, логіка, яка буде виконана в скрипті, також залежить від даних.

1.4 Аналіз переваг автоматичного тестування.

Повторюваність — Усі написані тести завжди будуть виконуватися одноманітно і точно, тобто виключений «людський фактор». Автоматичний тест на відміну від людини нічого не пропустить через необережність і нічого не наплутає у результатах.

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

Швидке виконання — автоматизованому скрипту не потрібно звірятися з інструкціями та документацією, це сильно скорочує затрати часу на виконання.

Затрати на підтримку менші ніж на ручне тестування — коли автоматичні скрипти вже написані, на їх підтримку і аналіз результатів потрібний, як правило, менший час ніж на проведення того ж обсягу ручного тестування.

Звіти — можна налаштувати автоматичну розсилку звітів по результатам тестування і їх централізоване зберігання.

Виконання без втручання — під час виконання тестів інженер відділу тестування може займатися іншими корисними справами, або тести можуть виконуватися в неробочий час.

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

1.5 Аналіз недоліків автоматичного тестування.

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

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

Великі витрати на розробку — розробка автоматизованих тестів це складний процес, тому що фактично йде розробка програми, що тестує іншу програму. У складних автоматизованих тестах також є фреймворки, утиліти, бібліотеки та інше. Природно, все це потрібно тестувати і налагоджувати, а це вимагає часу та високої кваліфікації персоналу.

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

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

Не зважаючи на те, що автоматизація слугує тестуванню, існують і суттєві недоліки. Автоматичні функціональні тести орієнтована на підтвердження, що нічого не зламалося (регресійне тестування), а не на знаходження нових дефектів.

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

У випадку невдачі, пошук причин неуспішності тесту потребує затрат часу як правило більших ніж під час ручного тестування.

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

До того ж, написання автоматичних тестів потребує часу приблизно рівному трьом циклам ручного тестування [l], що робить економічно невигідним створення тестів для нетривалих проектів.

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

1.6 Обґрунтування генерації тестів як більш ефективного підходу.

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

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

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

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

Підхід повинен відповідати наступним вимогам:

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

Простота і легкість. Реалізація повинна бути досить простою, щоб не виникло необхідності тривалої і коштовної перепідготовки персоналу.

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

1.7 Аналіз процесу ручного створення функціональних тестів.

Розглянемо процес створення тестів і об'єднання їх у тестовий набір в ручний спосіб, щоб отримати розуміння задачі для автоматизації.

В найзагальнішому наближені процес створення тестового набору відбувається за наступним алгоритмом:

1. Визначення області перевірки.

2. Аналіз функціональних вимог до цільової системи.

3. Визначення вимог до повноти тестового покриття.

4. Розробка тестів.

5. Формування тестових наборів.

Визначення області перевірки. На цьому етапі визначається функціональність системи, що повинна бути перевірена. Перед кожною задачею тестування ставиться певна ціль в залежності від якої визначається область тестування. До області, що може підлягати перевірці, може відноситись як уся цільова система, так і її окремі компоненти, функції та або якісні характеристики (надійність, практичність, ефективність та інші [3]).

Визначення масштабу тестування є необхідним, щоб визначити, що буде перевірятися, а що — ні.

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

У сучасній програмній інженерії функціональні вимоги до програмного забезпечення існують у різних формах в залежності від моделі розробки продукту, зрілості процесу в компанії і ризиків, що несе продукт. Їх форма може набувати як форми документу, строго відповідного стандартизованому шаблону — IEEE 830 [2], так і форми користувацьких історії, занотованих на картках формату 3 на 4, що практикується у гнучких моделях розробки, або просто не задокументованих знань учасників проектної команди — експертів, аналітиків та проектувальників.

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

З цього випливає перша підзадача: пошук такого представлення функціональних вимог до програмного продукту, які можуть бути оброблені автоматично — формальної специфікації.

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

Для функціонально тестування методом «чорного ящику» обраховується критерій повноти на основі вимог і безпосередньо залежить від їх представлення.

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

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

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

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

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

Тестові випадки для тестування методом «чорного ящику» можуть бути побудовані, взагалі кажучи, з використанням одного з двох підходів — дослідницького та основаного на специфікацій.

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