Тестування інформаційних систем

Курсова робота

Тестування інформаційних систем

ЗМІСТ

ВСТУП

РОЗДІЛ 1. ОСНОВИ ТЕСТУВАННЯ ІНФОРМАЦІЙНИХ СИСТЕМ

1.1. Поняття «тестування інформаційних систем»

1.2. Критерії тестування

1.3. Принципи тестування

РОЗДІЛ 2. МЕТОДИ ТЕСТУВАННЯ

2.1. Тестування «білого ящика"

2.2. Тестування «чорного ящика»

РОЗДІЛ 3. ТЕСТУВАННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ «НАВЧАЛЬНО-МЕТОДИЧНИЙ РЕСУРС»

ВИСНОВОК

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

ДОДАТОК. ЗАСТОСУВАННЯ СТАНДАРТУ IEEE STD 829 ПРИ ПЛАНУВАННІ І ВИКОНАННЯ ФУНКЦІОНАЛЬНОГО і навантажувальних ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

ВСТУП

Відомо, що основним завданням перших трьох десятиліть комп'ютерної ери було розвиток апаратних комп'ютерних засобів. Це було обумовлено високою вартістю обробки і зберігання даних. У 80-і роки успіхи мікроелектроніки привели до різкого збільшення продуктивності комп'ютера при значному зниженні вартості.

Основним завданням 90-х років XX і початку XXI століття стало вдосконалення якості комп'ютерних програм, можливості яких цілком визначаються програмним забезпеченням (ПЗ).

Сучасний персональний комп'ютер має продуктивність великої ЕОМ 80-х років. Зняті практично всі апаратні обмеження на вирішення завдань. Решту обмежень припадають на частку ПЗ.

Надзвичайно актуальними стали наступні проблеми:

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

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

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

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

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

Відповідно до мети були поставлені наступні завдання:

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

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

Перша глава присвячена вивченню такого поняття, як «тестування програмного забезпечення».

Друга глава присвячена вивченню методів тестування, таких як метод "білого ящика" і метод «чорного ящика».

У третьому розділі розглядається процес тестування фрагмента інформаційної системи «Навчально-методичний ресурс».

РОЗДІЛ 1. ОСНОВИ ТЕСТУВАННЯ ІНФОРМАЦІЙНИХ СИСТЕМ

1.1. Поняття «тестування інформаційних систем».

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

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

Програма - це аналог звичайної формули у математиці.

Формула для функції f, отриманої суперпозицією f 1, f2, ... fn - вираз, що описує цю суперпозицію.

f = f 1 * f 2 * f 3 * ... * fn

Якщо аналог f 1, f2, ... fn - оператори мови програмування, то їх формула - програма.

Існує два методи обгрунтування істинності формул:

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

Інтерпретаційний підхід використовується при експериментальній перевірці відповідності програми своєї специфікації.

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

Налагодження (debug, debugging) - процес пошуку, локалізації та виправлення помилок в програмі. [6, c. 215]

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

Тестування - це процес виконання ПО системи або компонента в умовах аналізу або запису одержуваних результатів з метою перевірки (оцінки) деяких властивостей тестованого об'єкта. [11, c. 5]

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

Тестування - це контрольоване виконання програми на кінцевій множині тестових даних та аналіз результатів цього виконання для пошуку помилок. [7, c. 27]

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

Кроки процесу задаються тестами.

Кожен тест визначає:

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

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

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

Метою проектування тестових варіантів є систематичне виявлення різних класів помилок при мінімальних витратах часу і вартості.

Тестування забезпечує:

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

Тестування не може показати відсутність дефектів (воно може показувати тільки присутність дефектів). Важливо пам'ятати це твердження при проведенні тестування.

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

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

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

Види тестування.

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

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

Фази тестування.

Реалізація тестування ділиться на три етапи:

Створення тестового набору (test suite) шляхом ручної розробки або автоматичної генерації для конкретного середовища тестування (testing environment).
Прогін програми на тестах, керований тестовим монітором (test monitor, test driver) з отриманням протоколу тестування (test log).
Оцінка результатів виконання програми на наборі тестів з метою прийняття рішення про продовження чи зупинення тестування.

1.2. Критерії тестування.

Можна виділити вимоги до ідеального критерію тестування:

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

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

Класи критеріїв:

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

Структурні критерії (клас I).

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

Структурні критерії базуються на основних елементах УДП, операторах, гілках і шляхах.

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

Структурні критерії не перевіряють відповідність специфікації, якщо

воно не відображено у структурі програми.

Функціональні критерії (клас II).

Функціональний критерій - найважливіший для програмної індустрії критерій тестування. Він забезпечує, перш за все, контроль ступеня виконання вимог замовника в програмному продукті. Оскільки вимоги формулюються до продукту в цілому, вони відображають взаємодію тестованого додатки з оточенням. При функціональному тестуванні переважно використовується модель «чорного ящика». Проблема функціонального тестування - це, перш за все, трудомісткість; справа в тому, що документи, які фіксують вимоги до програмного виробу (Software requirement specification, Functional specification і т.п.), як правило, досить об'ємні, тим не менш, відповідна перевірка повинна бути всеосяжною.

Нижче наведені приватні види функціональних критеріїв.

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

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

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

Стохастичні критерії (клас III).

Стохастичне тестування застосовується при тестуванні складних програмних комплексів - коли набір детермінованих тестів (X, Y) має величезну потужність. У випадках, коли подібний набір неможливо розробити і виконати на фазі тестування, можна застосувати таку методику.

Розробити програми-імітатори випадкових послідовних вхідних сигналів {x}.
Обчислити незалежним способом значення {y} для відповідних вхідних сигналів {y} і одержати тестовий набір {X, Y}.
Протестувати додаток на тестовому наборі {X, Y}, використовуючи два способи контролю результатів:

Детермінований контроль - перевірка відповідності обчисленого значення значенням y, отриманому в результаті прогону тесту на наборі {x} - випадкової послідовності вхідних сигналів, згенерованої імітатором.
Стохастичний контроль - перевірка відповідності багатьох { }, Отриманого в результаті прогону тестів на наборі значень {x}, заздалегідь відомому розподілі результатів F (Y). У цьому випадку безліч y невідомо (його обчислення неможливо), але відомий закон розподілу даної множини.

Критерії стохастичного тестування:

Статистичні методи закінчення тестування - стохастичні методи прийняття рішень про збіг гіпотез про розподіл випадкових величин. До них належать широко відомі: метод Ст'юдента (St), метод Хі-квадрат (x ²⁾ і т.п.
Метод оцінки швидкості виявлення помилок - заснований на моделі швидкості виявлення помилок, згідно з якою тестування припиняється, якщо оцінений інтервал часу між поточною помилкою і наступної занадто великий для фази тестування програми.

Мутаційний критерій (клас IV).

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

Підхід базується на наступних поняттях:

Мутації - дрібні помилки в програмі.

Мутанти - програми, що відрізняються один від одного мутаціями.

Метод мутаційного тестування - у розроблювану програму P вносять мутації, тобто штучно створюють програми-мутанти P 1, P 2 ... Потім програма P і її мутанти тестуються на одному і тому ж наборі тестів {X, Y}.

Якщо на наборі {X, Y} підтверджується правильність програми P і, крім того, виділяються всі внесені до програми-мутанти помилки, то набір тестів (X, Y) відповідає мутаційному критерієм, а тестуєма програма оголошується правильною.

Якщо деякі мутанти не виявили всіх мутацій, то треба розширювати набір тестів (X, Y) і продовжувати тестування.

1.3. Принципи тестування

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

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

Неефективність існуючих технологій тестування.

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

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

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

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

Традиційний підхід призводить до виділення половини (а іноді і більше) бюджетних коштів виключно на тестування [2]. Недолік ресурсів та плану існуючих технологій тестування може стикатися зі зменшенням бюджету і терміну розробки, змушуючи в гіршому випадку взагалі відмовлятися від тестування. Ця ситуація досить небезпечна, якщо врахувати зростаючу роль програмного забезпечення в сучасному бізнесі. Розробникам потрібен новий підхід до тестування, який відповідав би вимогам складних додатків і припускав виправлення помилок як можна раніше. Це дає імпульс до перетворення процесу тестування: від тестування по завершенні коду, до тестування протягом всього процесу розробки.

Новий підхід до процесу тестування.

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

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

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

Як практичний підхід V-модель була перевірена і використовувалася більше 15-ти років [3]. Ця методика співвідносить стадії розробки з окремими стадіями тестування. З її допомогою можна точно визначити межі застосування і призначення кожного тесту з його відповідної специфікації. Це допомагає уникнути неефективності багатьох прийомів тестування, включаючи перекриття тестових умов і проведення тих же тестів, але на різних рівнях. V-модель містить три тестуючих дії: верифікацію (verification), перевірку на коректність (validation) і власне тестування (testing).

Верифікація.

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

Перевірка на коректність.

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

Тестування, засноване на специфікаціях.

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

Застосовність V-моделі.

Значимість V-моделі була продемонстрована в проектах, які використовували кілька різних стилів розробки. У разі швидкої розробки (rapid development) V-модель допомагає визначити процес перевірки коректності, який необхідно виконувати для кожної ітерації розробки. Надалі це збільшує необхідність визначення кожної ітерації в термінах «тестових» вимог. Для об'єктної розробки (object development) V-модель забезпечує основу для організації тестування на рівнях класу і компонента.

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

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

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

Визначення критеріїв входу і виходу.

Критерії ходу і виходу визначаються для тих моментів, коли стадія починається і закінчується. Керівники робіт повинні визначити їх під час планування проекту. Застосування критеріїв покращує просування проекту зі стадії на стадію. Виконання критеріїв входу і виходу означає, що проект дійсно просувається вперед, а розробники не просто «замітають» свої помилки «під килим» наступної стадії.

Необхідно визначити умови тесту як можна раніше.

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

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

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

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

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

Залучення замовника в процес розробки.

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

Організація команд в робочі бригади.

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

Визначення архітектури тестування.

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

Необхідно ефективно використовувати інструменти тестування.

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

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

РОЗДІЛ 2. МЕТОДИ ТЕСТУВАННЯ.

2.1. Тестування «білого ящика"

Відома: внутрішня структура програми.

Досліджуються: внутрішні елементи програми і зв'язку між ними.

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

Особливості тестування "білого ящика".

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

У цьому випадку формуються тестові варіанти, в яких:

Гарантується перевірка всіх незалежних маршрутів програми.
Знаходяться гілки True, False для всіх логічних рішень.
Виконуються всі цикли (в межах їх кордонів і діапазонів).
Аналізується правильність внутрішніх структур даних.

Недоліки тестування "білого ящика":

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

При n = 5 і k = 20 кількість маршрутів m = 10 ^14. Приймемо, що на розробку, виконання і оцінку тесту по одному маршруту витрачається 1 мс. Тоді при роботі 24 години на добу 365 днів у році на тестування піде 3170 років.

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

Переваги тестування "білого ящика» пов'язані з тим, що принцип «білого ящика» дозволяє врахувати особливості програмних помилок:

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

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

Спосіб тестування базового шляху.

Тестування базового шляху - це спосіб, який заснований на принципі "білого ящика". Автор цього способу - Том МакКейб (1976).

Спосіб тестування базового шляху дає можливість:

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

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

Потоковий граф.

Для представлення програми використовується потоковий граф. Перерахуємо його особливості.

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

Цикломатичне складність.

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

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

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

Всі незалежні шляхи графа утворюють базову безліч.

Властивості базового множини:

Тести, що забезпечують його перевірку гарантують:

одноразове виконання кожного оператора;
виконання кожної умови по True-гілки і по False-гілки.

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

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

Цикломатичне складність обчислюється одним з трьох способів:

Цикломатичне складність дорівнює кількості регіонів потокового графа.
Цикломатичне складність визначається за формулою
V (G) = E - N + 2, де E - кількість дуг, N - кількість вузлів потокового графа.
Цикломатичне складність формується за висловом V (G) = p +1, де p - кількість предикатних вузлів в потоковому графі G.

Кроки способу тестування базового шляху.

На основі тексту програми формується потоковий граф:

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

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

Кожен тестовий варіант формується в наступному вигляді:

Вихідні дані (ВД):

Очікувані результати (ОЖ.РЕЗ.):

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

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

Важливо відзначити, що деякі незалежні шляху не можуть перевірятися ізольовано. Такі шляхи повинні перевірятися при тестуванні іншого шляху (як частина іншого тестового варіанту).

Способи тестування умов.

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

Розглянемо використовувану тут термінологію.

Просте умова - булева змінна або вираз відносини.

Вираз відносини має вигляд

E 1 <оператор відносини> E 2,

Де E 1, E 2 - арифметичні вираження, а в якості оператора відносини використовується один з наступних операторів:

Складений умова складається з кількох простих умов, булевих операторів і круглих дужок. Будемо застосовувати булеві оператори OR, AND (&), NOT. Умови, не містять виразів відносини, називають булевими виразами.

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

Якщо умова некоректно, то некоректний щонайменше один з елементів умови. Отже, в умови можливі такі типи помилок:

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

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

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

Існує кілька методик тестування умов.

Найпростіша методика - тестування гілок. Тут для складеного умови З перевіряється:

кожне просте умова;
True-гілка;
False-гілка.

Інша методика - тестування області визначення в ній для вираження відношення потрібно генерація 3-4 тестів. Вираз виду

Е1 <оператор відносини> Е2

перевіряється трьома тестами, які формують значення Е1 більшим, ніж Е2, рівним Е2 і меншим, ніж Е2.

Якщо оператор відносини неправильний, а Е1 і Е2 коректні, то ці три тести гарантують виявлення помилки оператора відносини.

Для визначення помилок в Е1 і Е2 тест повинен сформувати значення Е1 більшим чи меншим, ніж Е2, причому забезпечити якомога меншу різницю між цими значеннями.

Спосіб тестування потоків даних.

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

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

Нехай є потоковий граф програми з керівниками й інформаційними зв'язками.

Під визначенням даних розуміють дії, що змінюють елемент даних.

Використання даних - це застосування елемента в вираженні, де відбувається звернення до елемента даних, але не зміна елемента.

Назвемо DU-ланцюжком (ланцюжком визначення-використання) конструкцію [x, i, j], де i, j - імена вершин; x визначена в i-й вершині і використовується в j-й вершині.

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

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

Кроки способу DU-тестування:

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

Переваги DU-тестування:

простота необхідного аналізу операційно-керуючої структури програми;
простота автоматизації.

Недолік DU-тестування: труднощі у виборі мінімальної кількості максимально ефективних тестів.

Область використання DU-тестування: програми з вкладеними умовними операторами і операторами циклу.

Тестування циклів.

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

Розрізняють 4 типи циклів: прості, вкладені, об'єднані, неструктуровані.

Прості цикли.

Для перевірки циклів з кількістю повторень n може використовуватися один з наступних наборів тестів:

прогін всього циклу;
тільки один прохід циклу;
два проходи циклу;
m проходів циклів, де m <n;
n -1, n, n +1 проходів циклу.

Вкладені цикли.

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

Кроки тестування:

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

Об'єднані цикли.

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

Неструктуровані цикли.

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

2.2. Тестування «чорного ящика»

Відомі: функції програми.

Досліджується: робота кожної функції на всій області визначення.

Основне місце програми тестів «чорного ящика» - інтерфейс ПЗ.

Ці тести демонструють:

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

При тестуванні «чорного ящика» розглядаються системні характеристики програм, ігнорується їх внутрішня логічна структура. Вичерпна тестування, як правило, неможливо. Наприклад, якщо в програмі 10 вхідних величин і кожна приймає по 10 значень, то буде потрібно 10 ¹⁰ тестових варіантів. Тестування «чорного ящика» не реагує на багато особливості програмних помилок.

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

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

Будь-який спосіб тестування «чорного ящика» повинен:

Виявити такі вхідні дані, які з високою ймовірністю належать набору IT;
Сформулювати такі очікувані результати, які з високою імовірністю є елементами набору OT.

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

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

Принцип «чорного ящика» не альтернативний принципом "білого ящика". Скоріше це доповнює підхід, який виявляє інший клас помилок.

Тестування «чорного ящика» забезпечує пошук наступних категорій помилок:

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

Подібні категорії помилок способами «білого ящика" не виявляються.

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

Техніка «чорного ящика» орієнтована на вирішення наступних завдань:

Скорочення необхідної кількості тестових варіантів (через перевірки не статистичних, а динамічних аспектів системи);
Виявлення класів помилок, а не окремих помилок.

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

Розбиття по еквівалентності - найпопулярніший спосіб тестування «чорного ящика».

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

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

Класи еквівалентності можуть бути визначені по специфікації на програму.

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

Умова введення може задавати;

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

Сформулюємо правила формування класів еквівалентності.

якщо умова введення задає діапазон n ... m, то визначається один допустимий і два неприпустимих класу еквівалентності.
якщо умова введення задає конкретне значення a, то визначається один допустимий і два неприпустимих класу еквівалентності.
якщо умова введення задає безліч значень {a, b, c}, то визначається один допустимий і один неприпустимий клас еквівалентності.
якщо умова введення задає логічне значення, наприклад true, то визначається один допустимий і один неприпустимий клас еквівалентності.

Після побудови класів еквівалентності розробляються тестові варіанти.

Тестовий варіант вибирається так, щоб перевірити відразу найбільшу кількість властивостей класу еквівалентності.

Спосіб аналізу граничних значень.

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

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

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

Сформулюємо правила аналізу граничних значень.

якщо умова введення задає діапазон n ... m, то тестові варіанти повинні бути побудовані:

для значень n і m.
для значень трохи лівіше n і трохи правіше m на числовій осі.

2. Якщо умова введення задає дискретну безліч значень, то створюються тестові варіанти:

1. для перевірки мінімального і максимального із значень.

2. для значень трохи менше мінімуму та трохи більше максимуму.

3. Правила 1 і 2 застосовуються до умов області виведення.

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

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

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

Спосіб діаграм причин-наслідків.

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

Кроки способи:

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

РОЗДІЛ 3. ТЕСТУВАННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ «НАВЧАЛЬНО-МЕТОДИЧНИЙ РЕСУРС»

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

Нами був обраний такий метод тестування, як метод «чорного ящика». Це обумовлено тим, що тестуванням коду програми займався безпосередньо розробник коду. Ним був написаний файл реєстрації reg. Php. У результаті роботи файлу на головній сторінці інформаційної системи з'являється наступна форма.

Нами були заповнені всі обов'язкові й необов'язкові поля форми, але в полі «Підтвердження» нами була вказана невірна пароль, в результаті чого з'явилося наступне повідомлення.

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

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

Після проведення реєстрації ми потрапляємо на головну сторінку сайту і дізнаємося його зміст і структуру.

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

На головній сторінці вказується кількість лекцій. У нашому випадку їх кількість - 3. Натисканням кнопки «Лекції» викликається форма, що містить порожні поля для введення назви лекції та шляхи, за яким знаходиться файл з безпосередньо змістом (текстом) лекції. Файл з лекцією повинен бути написаний у текстовому редакторі Microsoft Office Word і збережений як веб-сторінка з фільтром, інакше можуть виникнути помилки у формуванні кінцевої сторінки. У результаті пророблених дій повинна формуватися веб-сторінка, що містить всі лекції, зазначені користувачем. У нашому випадку формування сторінки відбувається успішно, і ми отримуємо веб-сторінку з трьома лекціями з заданими назвами і з вірним вмістом.

Крім тестування веб-сторінок інформаційної системи «УМР» вироблялося візуальне тестування вихідного коду сценарію reg. Php. Перевірка даного файлу здійснювалася за допомогою редактора PHP Expert Editor.

Файл сценарію reg.php

<? Php

session_start ();

/ / Ñîçäàåì íîâóþ ñåññèþ èëè

/ / Âîññòàíàâëèâàåì òåêóùóþ

$ Err _ msg = array ("lname" => "Ôàìèëèÿ:", "fname" => "Èìÿ", "oname" => "Îò ÷ åñòâî", "pass" => "Íå âåäåí ïàðîëü", "repass "=>" Íå ïîäòâåðæäåí ïàðîëü "," error "=>" Ïàðîëü íå ñîâïàäàåò ñ ïîäòâåðæäåíèåì ",

"Login" => "Ïîëüçîâàòåëü ñ òàêèì ïñåâäîíèìîì óæå ñóùåñòâóåò");

/ / Print _ r ($ err _ msg);

/*------- Âñïîìîãàòåëüíûå ôóíêöèè ------- * /

function Check ($ var, $ val =""){

if (! isset ($ var))

return $ val;

else

return $ var;

}

/ / Ôóíêöèÿ äëÿ ïðîâåðêè ÔÈÎ

/ / Function FIO _ OK ($ str) {

/ / Return ereg ("^ [À-ßà-ÿ \ '-] {l, 25} $", $ str);

/ /}

function LOGIN_OK ($ str) {

$ Conn = mysql_connect ("localhost", "root ");// óñòàíàâëèâàåì ñîåäèíåíèå

$ Database = "users";

$ Table_name = "pass";

mysql_select_db ($ database); / / âûáèðàåì áàçó äàííûõ

/ / Ïðîâåðêà óíèêàëüíîñòè ïñåâäîíèìà

$ Sql = "SELECT login FROM $ table_name WHERE` login `= "."'".$ str ."'";

$ Result = mysql_query ($ sql);

mysql_close ($ conn);

return mysql_num_rows ($ result);

}

/ / Ôóíêöèÿ äëÿ ïðîâåðêè email

function email_OK ($ str) {

return preg_match ("/ ^ \ w + ([\. \ w] +) * \ w @ \ w ((\. \ w) * \ w +) * \. \ w {2,3 }$/",$ str );

}

/ / Ôóíêöèÿ äëÿ ïðîâåðêè òåëåôîíà

function telefon _ OK ($ str) {

return preg_match ("/ \ d {3} - \ d {2} - \ d {2 }/",$ str);

}

/ / Ôóíêöèÿ äëÿ ïðîâåðêè ôîðìû

function Form _ OK () {

/ / Ìàññèâ îøèáîê è ñîîòâåòñòâóþùèõ ñîîáùåíèé

global $ errors, $ err _ msg;

/ * If (! FIO_OK ($ _POST ["fname "])){

$ Errors ["fname"] = 1;

$ _POST ["Fname"] = "";

}

if (! FIO_OK ($ _POST ["oname "])){

$ Errors ["oname"] = 1;

$ _POST ["Oname"] = "";

}

if (! FIO_OK ($ _POST ["lname "])){

$ Errors ["lname"] = 1;

$ _POST ["Lname"] = "";

}

* /

if (LOGIN_OK ($ _POST ["login "])){

$ Errors ["login"] = 1;

$ _ POST ["login"] = "";

}

/ / Ïðîâåðêà ñîâïàäåíèÿ ïàðîëÿ è ïîäòâåðæäåíèÿ

if (strcmp ($ _POST ["pass "],$_ POST [" repass "])!= 0) {

$ Errors ["error"] = 1;

$ _POST ["Repass "]="";

}

if (! $ _POST ["pass"]) {

$ Errors ["pass"] = 1;

$ _POST ["Repass "]="";

}

if (! $ _POST ["repass"]) $ errors ["repass"] = 1;

if (sizeof ($ errors)> 0) {

/ / Åñëè ñóùåñòâóþò îøèáêè, âûâîäÿòñÿ ñîîòâåòñòâóþùèå ñîîáùåíèÿ, è ôîðìà îòîáðàæàåòñÿ çàíîâî

echo "<html> <body> <div align='center' style='font-size: 18'> <b> ÎØÈÁÊÀ </ b> </ div>";

echo "<div align='center' style='font-size: 14, color:red'> Îáíàðóæåíû ñëåäóþùèå îøèáêè: <br>";

foreach ($ errors as $ key => $ value) {

echo "<b>". $ err_msg [$ key ]."</ b> <br> ";

}

echo "</ div>";

ShowForm ();

echo "</ body> </ html>";

}

else {

/ / Åñëè îøèáêè îòñóòñòâóþò, âûâîäèòñÿ ñîîòâåòñòâóþùåå ñîîáùåíèå

echo "<h2 align='center'> Óâàæàåìûé (àÿ)". $ _POST ["lname"]. "". $ _POST ['fname']."!</ h2> <br> <h3 align =' center '>

Ðåãèñòðàöèÿ ïðîøëà óñïåøíî </ h 3> ";

$ _ SESSION ['login']=$_ POST [' login '];

/ / Ðåãèñòðèðóåì ïåðåìåííóþ login

/ / $ _SESSION ['Pass']=$_ POST [' pass '];

/ / Ðåãèñòðèðóåì ïåðåìåííóþ pass

/ / Òåïåðü ëîãèí è ïàðîëü - ãëîáàëüíûå

/ / Ïåðåìåííûå äëÿ ýòîé ñåññèè

echo "<center> <a href =main_form.php> OK </ a> </ center>";

/ / Âíîñèì äàííûå â áàçó

$ Conn = mysql _ connect ("localhost", "root ");// óñòàíàâëèâàåì ñîåäèíåíèå

$ Database = "users";

$ Table_name = "pass";

mysql_select_db ($ database); / / âûáèðàåì áàçó äàííûõ

/ / Ïðîâåðêà óíèêàëüíîñòè ïñåâäîíèìà

$ List_f = mysql_list_fields ($ database, $ table_name); / / ïîëó ÷ àåì ñïèñîê ïîëåé â áàçå

$ N = mysql _ num _ fields ($ list _ f); / / ÷ èñëî ñòðîê â ðåçóëüòàòå ïðåäûäóùåãî çàïðîñà

/ / Ñîñòàâèì îäèí çàïðîñ ñðàçó äëÿ âñåõ ïîëåé òàáëèöû

$ Sql = "INSERT INTO $ table _ name SET"; / / íà ÷ èíàåì ñîçäàâàòü çàïðîñ, ïåðåáèðàåì âñå ïîëÿ òàáëèöû

for ($ i = 0; $ i <$ n; $ i + +) {

$ Name_f = mysql_field_name ($ list_f, $ i); / / âû ÷ èñëÿåì èìÿ ïîëÿ

$ Value = $ _POST [$ name_f]; / / âû ÷ èñëÿåì çíà ÷ åíèå ïîëÿ

$ J = $ i + 1;

$ Sql = $ sql. $ Name _ f. "= '$ Value'"; / / äîïèñûâàåì â ñòðîêó $ sql ïàðó èìÿ = çíà ÷ åíèå

if ($ j <> $ n) $ sql = $ sql. ","; / / åñëè ïîëå íå ïîñëåäíåå â ñïèñêå, òî ñòàâèì çàïÿòóþ

}

/ / Ïåðåä òåì êàê çàïèñûâàòü ÷ òî-òî â áàçó,

/ / Ìîæíî ïîñìîòðåòü, êàêîé çàïðîñ ïîëó ÷ èëñÿ

/ / Echo $ sql;

$ Result = mysql _ query ($ sql, $ conn); / / îòïðàâëÿåì çàïðîñ âûâîäèì ñîîáùåíèå óñïåøíî ëè âûïîëíåí çàïðîñ

if (! $ result) echo "Can't add". $ table_name;

else echo "Success! <br>";

mysql_close ($ conn);

}}

function ShowForm () {

echo $ _SERVER ['PHP_SELF'];

echo "

<h3 align=\"center\"> Ðåãèñòðàöèÿ </ h3>

<h4 align=\"center\"> <b> <font face=\"Courier New, Courier, mono\"> Ïîæàëóéñòà, çàïîëíèòå

ôîðìó, ïðèâåäåííóþ íèæå. Ñïàñèáî! </ Font> </ b> </ h 4>

<h4 align=\"center\"> <font face=\"Courier New, Courier, mono\"> <i> <font size=\"2\"> Íå

îáÿçàòåëüíûå ïîëÿ ïîìå ÷ åíû * </ font> </ i> </ font> </ h 4>

<tr>

<td>

<div align=\"right\"> Ôàìèëèÿ </ div>

</ Td> ";

if (! isset ($ _POST ['lname'])) $ value = "";

else $ value = Check ($ _POST ["lname"]);

echo "

<td>

</ Td>

</ Tr>

<tr>

<td>

</ Td> ";

if (! isset ($ _POST ['fname'])) $ value = "";

else $ value = Check ($ _POST ['fname']);

echo "

<td>

</ Td>

</ Tr>

<tr>

<td>

<div align=\"right\"> Îò ÷ åñòâî </ div>

</ Td> ";

if (! isset ($ _POST ['oname'])) $ value = "";

else $ value = Check ($ _POST ['oname']);

echo "

<td>

</ Td>

</ Tr>

<tr>

<td>

<div align=\"right\"> * Çâàíèå </ div>

</ Td> ";

if (! isset ($ _POST ['rank'])) $ value = "";

else $ value = Check ($ _POST ['rank']);

echo "

<td>

</ Td>

</ Tr>

<tr>

<td>

<div align=\"right\"> * Äîëæíîñòü </ div>

</ Td> ";

if (! isset ($ _POST ['post'])) $ value = "";

else $ value = Check ($ _POST ['post']);

echo "

<td>

</ Td>

</ Tr>

<tr>

<td>

<div align=\"right\"> * Òåëåôîí </ div>

</ Td> ";

if (! isset ($ _POST ['telefon'])) $ value = "";

else $ value = Check ($ _POST ['telefon']);

echo "

<td>

</ Td>

</ Tr>

<tr>

<td>

</ Td> ";

if (! isset ($ _POST ['email'])) $ value = "";

else $ value = Check ($ _POST ['email']);

echo "

<td>

</ Td>

</ Tr>

<tr>

<td>

<div align=\"right\"> Ïñåâäîíèì </ div>

</ Td> ";

if (! isset ($ _POST ['login'])) $ value = "";

else $ value = Check ($ _POST ['login']);

echo "

<td>

</ Td>

</ Tr>

<tr>

<td>

<div align=\"right\"> Ïàðîëü </ div>

</ Td> ";

if (! isset ($ _POST ['pass'])) $ value = "";

else $ value = Check ($ _POST ['pass']);

echo "

<td>

</ Td>

</ Tr>

<tr>

<td>

<div align=\"right\"> Ïîäòâåðæäåíèå </ div>

</ Td> ";

if (! isset ($ _POST ['repass'])) $ value = "";

else $ value = Check ($ _POST ['repass']);

echo "

<td>

</ Td>

</ Tr>

</ Table>

</ Div>

</ Form> ";

}

if (! isset ($ _POST ['ok'])){

echo "

<html>

<head>

<title> Registration </ title>

</ Head>

<body background=..\\ris\\1.jpg text=\"#000000\"> ";

ShowForm ();

echo "

</ Body>

</ Html>

";}

else Form_OK ();

ВИСНОВОК

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

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

Далі були розглянуті види тестування:

Блокове тестування;
Тестування компонента;
Інтеграційне тестування;
Регресивне тестування;
Тестування системи.

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

Метод «білого ящика".
Метод «чорного ящика».

Практичною частиною курсової роботи було тестування фрагмента інформаційної системи «Навчально-методичний ресурс».

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

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

Липаев В.В.

Налагодження складних програм: Методи, засоби, технологія. М.: Вища школа, 1993, 384 с.

Майерс Г.

Мистецтво тестування програм.

М.: Фінанси і статистика, 1982, 176 с.

Технології розробки програмного забезпечення: Підручник для вузів. 3-є з д. / С.А. Орлов. - СПб.: Пітер, 2004. - 527 с.: Іл.
Макгрегор Дж., Сайкс Д.

Тестування об'єктно-орієнтованого програмного забезпечення

К.: ДіаСофт, 2002. - 432 с.

Липаев В.В.

Тестування програм

М.: Радіо і зв'язок, 1986. - 296 с.

Канер С., Фолк ДЖ., Нгуен Енг.

Тестування програмного забезпечення

К.: ДіаСофт, 2000 - 544 с.

Шімаров В.А.

Тестування програм: цілі та особливості інструментальної підтримки

/ / Програмне забезпечення ЕОМ / АН УРСР. Інститут математики.

Мінськ, 1994. - Вип. 100 - с.19 - 43

Борзов Ю.В., Уртанг Г.Б., Шімаров В.А.

Вибір шляхів програми для побудови тестів

УСиМ. - 1989. - N.6 - с.29-36

Boehm, Barry W.

«A Spiral Model of Software Development and Enhancement»

IEEE Computer, Vol. 21, no. 5 (May 1988), pp 61-72.

Humphrey, Watts S.

Managing the Software Process.

Reading, MA: Addison-Wesley, 1989.

Marks, David M.

Testing Very Big Systems.

New-York: Bellcore (McGraw-Hill), 1992.

Карлбертсон Р., Браун К., Кобб Г.

Швидке тестування

Вид. Вільямс 2002, 216 с.

Дастін Е., Решкі Дж., Пол Дж.

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

Вид. Лорі 2003, 310 с.

Стандарт IEEE 829 Software Test Documentation - «Задає планку» для індустрії ІТ з організації процесу тестування. Цей стандарт розроблявся з 1977 року і був затверджений у 1983 році, а потім знову підтверджений у 1991 та 1998 роках. Незважаючи на свою зрілість, він актуальний і в 21-му столітті. Стандарт «лягає» як на каскадну, так і на спіральну, итерационную модель життєвого циклу (ЖЦ) розробки та супроводу програмного забезпечення, а також стандарт не суперечить ідеології об'єктно-орієнтованого підходу. IEEE STD 829 пропонує основу - достатній набір документів для того, щоб :

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

Місце і роль процесу тестування у життєвому циклі розробки та супроводу ПО описані в багатьох стандартах, в тому числі і в стандарті ДСТУ ISO / IEC 12207.

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

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

Склад документів, рекомендованих в стандарті IEEE STD 829:

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

Рекомендований склад плану тестування:

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

Специфікація сценарію тесту:

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

Специфікація тестової процедури:

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

Використання стандарту IEEE STD 829 в реальних проектах.

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

За практиці даних робіт видно, що стандарт можна доповнити, наприклад, якщо використовується об'єктно-орієнтоване проектування (ООП), то можна додати такі документи: опис тестових класів, тестових пакетів. Економія при використанні шаблонів не тільки в тому, що є зразок, але і в тому, що логіка і склад документа ретельно продумані і опрацьовані, як оп змістом, так і за оформленням, тобто не потрібно «винаходити велосипед». А для випадків, коли виконується замовна робота, ці шаблони готові для розгляду та узгодження з Замовником з перших днів і годин з початку робіт. Для великих і / або досить формалізованих проектів (RUP) потрібен повний або розширений список документів, а для малих проектів, які дуже поширені останнім часом у зв'язку з популярністю аутсортінга, методологій RAD, XP - список документів може бути скорочений або спрощений.

Плюси впровадження стандарту - уніфікація (прискорення робіт, єдина корпоративна структура), смислова повнота.

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

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

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

Розглянутий стандарт рекомендується використовувати не тільки для планування та виконання робіт з тестування, а й для розробки стандарту підприємства, програми і методики випробувань, а також для створення методик по окремих видах тестування (функціональному, навантаження, стресовому, приймальному і т.п.). У цьому випадку можна також використовувати ГОСТ 19.301-79 Програми і методики випробувань. Стандарти підприємств рекомендовано створювати для розробників ПЗ, для служб супроводу (тиражні системи). Програми і методики випробувань - для служб експлуатації систем (біллінг, ERP, CRM).

Ресурсні витрати на розробку однакового типу шаблону можуть відрізнятися для різних організацій: створення в перший раз - від 8 годин, при наявності відповідного зразка і досвіду, за кілька днів; адаптація відпрацьованого шаблону для нового проекту - від 1 години до 1дня. Деякі методології і пакети інструментальних засобів пропонують набори типових шаблонів за різних процесів, в тому числі і для тестування.

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