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

РЕФЕРАТ

Курсова робота: 30 с.,6 рис., 5 джерел.

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

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

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

 

ВСТУП.. 4

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

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

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

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

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

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

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

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

ВИСНОВКИ.. 29

СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ.. 30

ВСТУП

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

 

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

 

 

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

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

 

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

 

 

V- модель

 

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

 

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

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

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

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

 

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

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

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

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

 

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

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

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

 

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

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

 

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

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

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

 

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

 

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

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

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

Рис. 1.5 Техніка аналізу граничних значень

 

Тестовий набір, побудований за даною технікою, для діапазонів зображених на рис. 1.5, повинен включати тести на перевірку значень 0,1,99,100.

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

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

· зменшення тестових випадків у наборі

· для вибору правильних тестів, що покривають усі можливі сценарії

 

Один тест значення взяв з кожного класу під час тестування.

 

 

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

 

Тестовий набір для вимог на рис. 1.6, побудований за цією технікою повинен містити тести на перевірку значень -1 (лівий діапазон некоректних даних); 25 (діапазон коректних даних); 105 (правий діапазон некоректних даних).

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

 

Діаграма станів і переходів

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

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

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

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

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

 

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

Остання під задача – формування тестового набору.

 

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

 

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

 

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

Побудова тестів на основі моделі. Вибір техніки для побудови тестів на основі формальної моделі.

 

Формування тестового набору. Розробка алгоритму формування тестового набору.

ВИСНОВКИ

 

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

 

 

СПИСОК ЛІТЕРАТУРИ

1. Cost Benefits Analysis of Test Automation, Douglas Hoffman, Software Quality Methods, LLC; Douglas Hoffman, 1999. – 14 с.

2. IEEE 830.1998 IEEE Recommended Practice for Software Requirements Specifications. Approved 25 June 1998. IEEE-SA Standards Board.

3. ISO/IEC 9126 Software engineering

4. FOUNDATIONS OF SOFTWARE TESTING ISTQB CERTIFICATION. Dorothy Graham, Erik van Veenendaal, Isabel Evans, Rex Black.

5. Certified Tester Foundation Level Syllabus. Version 2010. P.: International Software Testing Qualification Board

РЕФЕРАТ

Курсова робота: 30 с.,6 рис., 5 джерел.

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

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

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

 

ВСТУП.. 4

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

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

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

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

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

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

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

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

ВИСНОВКИ.. 29

СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ.. 30

ВСТУП

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

РОЗДІЛ 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.

 

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

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