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

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

· управління проектом у вигляді координації зусиль проектної команди, спрямованих на досягнення цілей проекту оптимальним шляхом;

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

· управління змінами в проекті: зміна може стосуватися як безпосередньо самих вимог до системи, так і торкатися організаційну схему процесу, і можуть породжуватися або самим замовником (бізнес-аналітиком), або бути наслідком виявлених в ІС дефектів;

· розробка ПЗ, як безпосереднє кодування програмної реалізації функціональних вимог і проектування схем збереження і руху інформації в ІС;

· тестування ПЗ - процес, вирішальний завдання верифікації відповідності вимог висунутих до ІС та їх програмної реалізації;

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

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

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

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

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

Тестування не є пошуком помилок у програмі! При пошуку помилок:

– мета – знайти найбільшу кількість багів;

– тестуються найбільш нестабільні частини програми;

– тести – максимально нестандартні випадки.

При тестуванні:

– мета – пропустити як найменше критично важливих для користувача багів;

– тестуються найбільш пріоритетні для користувача частини програми;

– тести стандартні.

Основні класифікаційні ознаки тестування:

– за об’єктом тестування: функціональне, завантажувальне, тестування безпеки, тестування локалізації та інше;

– тестування за знанням системи: чорний ящик, сірий ящик, білий ящик;

– за часом проведення: альфа-тестування, димове тестування, регресійне тестування, бета-тестування;

– за ступенем ізольованості: компонентне, інтеграційне, системне.

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

Тестування за стратегією білого ящика передбачає такі моменти:

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

– перевірка реалізованих виключних операцій методом ламання

– крайові тести: що буде, якщо функція не одержить аргумента? Що буде, якщо система зіткнеться з нехваткою ресурсів?

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

Коли говорять про тестування сірим ящиком, найчастіше мають на увазі тестування таких аспектів поведінки програми:

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

– перевірка інформації, що створюється самою системою;

– перевірка видалення тимчасових файлів, перевірка очистки пам’яті.

Тестове покриття – це метрика оцінки якості тестування, що являє собою показник покриття тестами…

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

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

Для вимірювання покриття вимог необхідним є аналіз специфікації і розбивка вимог на пункти. У відповідність кожному пункту слід ставити набір тестів. Такі зв’язки часто об’єднюють в єдину матрицю (таблицю), що називається матрицею трасування вимог. Покриття визначається як T=Lc/Lt, де T – покриття вимог, Lc – кількість перевірених тестами вимог, Lt – загальна кількість вимог. Інший підхід – T=Lеc/Lсоde, де Ltc – кількість покритих тестами рядків коду, Lcode – загальна кількість рядків коду. Обчислення цієї характеристики можна автоматизувати.

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

– Python – unittest, doctest

– Java – JUnit

– C++ – Google Test

– C – UnitTESK

– Web –форми – Selenium.

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

Програма для тестування розглядають часто аналог звичайної формули у математиці.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· Свій набір вихідних даних і умов для запуску програми.

· Набір очікуваних результатів роботи програми.

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

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

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

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

· Виявлення помилок.

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

· Демонстрацію реалізації вимог до характеристик програми.

· Відображення надійності як індикатора якості програми.

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

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

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

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

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

· Інтеграційне тестування - це спільне виконання двох або більше класів, пакетів, компонентів або підсистем, створених кількома програмістами або групами.

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

· Тестування системи - це виконання ПЗ в його остаточної конфігурації, інтегрованого з іншими програмними та апаратними системами.

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

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

1. Створення тестового набору (test suite) шляхом ручної розробки або автоматичної генерації для конкретного середовища тестування (testing environment).

2. Прогін програми на тестах, керований тестовим монітором (test monitor, test driver) з отриманням протоколу тестування (test log).

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

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

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

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

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

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

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

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

· Структурні критерії використовують інформацію про структуру програми (критерії так званого «білого ящика»).

· Функціональні критерії формулюються в описі вимог до програмного виробу (критерії так званого «чорного ящика»).

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

· Мутаційні критерії орієнтовані на перевірку властивостей програмного вироби на основі підходу Монте-Карло.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· Розробити програми-імітатори випадкових послідовних вхідних сигналів {x}.

· Обчислити незалежним способом значення {y} для відповідних вхідних сигналів {y} і одержати тестовий набір {X, Y}.

· Протестувати додаток на тестовому наборі {X, Y}, використовуючи два способи контролю результатів:

1. Детермінований контроль - перевірка відповідності обчисленого значення значенням y, отриманому в результаті прогону тесту на наборі {x} - випадкової послідовності вхідних сигналів, згенерованої імітатором.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· Гарантується перевірка всіх незалежних маршрутів програми.

· Знаходяться гілки True, False для всіх логічних рішень.

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

· Аналізується правильність внутрішніх структур даних.

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

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

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

· Повне тестування маршрутів не гарантує відповідності програми вихідним вимогам до неї.

· У програмі можуть бути пропущені деякі маршрути.

· Не можна виявити помилки, поява яких залежить від даних.

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

· Кількість помилок мінімально в «центрі» і максимально на «периферії» програми.

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

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

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

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

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

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

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

· Отримати оцінку комплексної складності програми.

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

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

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

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

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

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

· Дуги потокового графа відображають потік управління у програмі (передачі управління між операторами). Дуга - це орієнтоване ребро.

· Розрізняють операторні і предикатні вузли. З операторного вузла виходить одна дуга, а з предикатного - дві дуги.

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

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

· Навколишнє граф середовище розглядається як додатковий регіон.

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

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

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

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

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

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

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

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

1. одноразове виконання кожного оператора;

2. виконання кожної умови по True-гілки і по False-гілки.

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

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

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

· Цикломатичне складність дорівнює кількості регіонів потокового графа.

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

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

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

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

1.) нумеруються оператори тексту;

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

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

· Визначається базове безліч незалежних лінійних шляхів.

· Готуються тестові варіанти, які ініціюють виконання кожного шляху.

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

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

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

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

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

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

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

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

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

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

· кожне просте умова;

· True-гілка;

· False-гілка.

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

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

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

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

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

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

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

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

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

· прогін всього циклу;

· тільки один прохід циклу;

· два проходи циклу;

· m проходів циклів, де m < n;

· n -1, n, n +1 проходів циклу.

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

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

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

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

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

· Робота триває до того часу, поки не будуть протестовані всі цикли.

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

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

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

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

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

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

· Виявити такі вхідні дані, які з високою ймовірністю належать набору IT;

· Сформулювати такі очікувані результати, які з високою імовірністю є елементами набору OT.

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

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

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

· Некоректних чи відсутніх функцій;

· Помилок інтерфейсу;

· Помилок у зовнішніх структурах даних або в доступі до зовнішньої базі даних;

· Помилок характеристик (необхідна ємність пам'яті і т.д.);

· Помилок ініціалізації та завершення.

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

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

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

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

· Виявлення класів помилок, а не окремих помилок.

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

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

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

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

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

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

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

· Певне значення.

· Діапазон значень.

· Безліч конкретних величин.

· Булева умова.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

– для значень n і m;

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

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

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

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

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

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

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

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

ПЕРЕЛІК РЕКОМЕНДОВАНИХ ДЖЕРЕЛ

1. Статистика: Підручник / С. С. Герасименко, А. В. Головач, А. М. Єріна та ін.; за наук ред. д-ра екон. наук С. С. Герасименка. – 2-ге вид., перероб. і доп. – К.: КНЕУ, 2000 – 467с.

2. Майоров С. А. Основы теории вычислительных систем. М.: Высшая школа, 1978 – 613с.

3. Руденко В. М. Математична статистика. Навчальний посібник. – К.: Центр учбової літератури, 2012. – 304с.

4. Турчин В. М. Математична статистика: навчальний посібник. – К.: Видавничий центр “Академія”, 1999 – 240с

5. Математическая статистика. Ученик для техникумов. Под ред. А. М. Догиня / М.: Высшая школа, 1975 – 398с.

6. Опря А. Т. Статистика. Метематическая статистика. Загальна теорія статистики: Навчальний посібник. – К.: Видавничий центр “Академія”, 1999 – 240c.

7. Тамре Л. Введение в тестирование программного обеспечения: Пер. с англ. – М.: Изд. дом “Вильямс”, 2003 – 368с.: ил

8. Степанченко И. В. Методы тестирования программного обеспечения: Учебное пособие / ВолгГТУ, Волгоград, 2006. – 74с.