"Програма складної структури з використанням меню"
ВИКОНАВ: Пикулін Е. Г.
прийняв: Солодовников А. Д.
м. Москва 1996
ЗМІСТ.
1. ВИДИ КОНТРОЛЮ ПРОГРАМ
2. ЦІЛІ, ПРИНЦИПИ І ЕТАПИ ТЕСТУВАННЯ
3. СТРУКТУРНЕ ТЕСТУВАННЯ
4. СПІЛЬНЕ ТЕСТУВАННЯ МОДУЛІВ
5. Функціонального тестування
6. ТЕСТУВАННЯ ПРОГРАМНОГО КОМПЛЕКСУ В ЦІЛОМУ
7. НАЛАГОДЖЕННЯ ПРОГРАМ
ВИДИ КОНТРОЛЮ ПРОГРАМ
Програмний комплекс - це сукупність програмних модулів, призначених для вирішення однієї задачі і складових одне ціле.
Основними різновидами контролю програмного забезпечення є візуальний, статичний і динамічний.
Візуальний контроль - це перевірка програм "за столом", без використання комп'ютера. На першому етапі візуального контролю здійснюється читання програми, причому особлива увага приділяється наступним її елементам:
коментарям і їх відповідності тексту програми;
умовам в операторах умовного вибору (IF, CASE) і циклу;
складним логічним виразами;
можливості незавершення ітераційних циклів (WHILE, REPEAT, LOOP).
Другий етап візуального контролю - наскрізний контроль програми
(Її ручна прокрутка на декількох заздалегідь підібраних простих тестах). Поширена думка, що більш вигідним є перекладання більшої частини роботи по контролю програмних засобів на комп'ютері, помилкова. Основний аргумент на користь цього такий: при роботі на комп'ютері головним чином удосконалюються навички у використанні клавіатури, в той час як Програмістська кваліфікація набувається перш за все за столом.
Статичний контроль-це перевірка програми по її тексту (без виконання) за допомогою інструментальних засобів. Найбільш відомою формою статичного контролю є синтаксичний контроль програми за допомогою компілятора, при якому перевіряється відповідність тексту програми синтаксичним правилам мови програмування.
Повідомлення компілятора звичайно діляться на кілька груп залежно від рівня важкості порушення синтаксису мови програмування:
інформаційні повідомлення і попередження, при виявленні яких компілятор, як правило, будує коректний об'єктний код і подальша робота з програмою (компонування, виконання) можлива (проте повідомлення цієї групи також повинні ретельно аналізуватися, оскільки їх поява також може свідчити про помилку в програмі - наприклад, через невірне розуміння синтаксису мови);
повідомлення про помилки, при виявленні яких компілятор намагається їх виправити і будує об'єктний код, але його коректність малоймовірна і подальша робота з ним швидше за все не можлива;
повідомлення про серйозні помилки, за наявності яких побудований компілятором об'єктний код явно некоректний і його подальше використання неможливо;
повідомлення про помилки, виявлення яких привело до припинення синтаксичного контролю і побудови об'єктного коду.
Однак, практично будь-який компілятор пропускає деякі види синтаксичних помилок. Місце виявлення помилки може знаходитися далеко по тексту програми від місця істинної помилки, а текст повідомлення компілятора може не вказувати на істинну причину помилки. Одна синтаксична помилка може спричинити генерацію компілятором декількох повідомлень про помилки (наприклад, помилка в описі змінної приводить до появи повідомлення про помилку в кожному операторі програми, що використовує цю змінну).
Другою формою синтаксичного контролю може бути контроль структурованості програм, тобто перевірка виконання угод і обмежень структурного програмування. Прикладом подібної перевірки може бути виявлення в тексті програми ситуацій, коли цикл утвориться за допомогою оператора безумовного переходу (використання оператора GOTO для переходу вгору по тексту програми). Для проведення контролю структурованості можуть бути створені спеціальні інструментальні засоби, а при їх відсутності ця форма статичного контролю може поєднуватися з візуальним контролем.
Третя форма статичного контролю - контроль правдоподібності програми, тобто виявлення в її тексті конструкцій, які хоч і синтаксично коректні, але швидше за все містять помилку або свідчать про неї. Основні неправдоподібні ситуації:
використання в програмі неініціалізовані змінних (тобто змінних, які не отримали початкового значення);
наявність в програмі описів елементів, змінних, процедур, міток, файлів, надалі що не використовуються в її тексті;
наявність в тексті програми фрагментів, що ніколи не виконуються;
наявність в тексті програми змінних, ні разу що не використовуються для читання після привласнюючи їм значень;
наявність в тексті програми явно нескінченних циклів;
Навіть якщо присутність в тексті програми неправдоподібних конструкцій не приводить до її неправильної роботи, виправлення цього фрагмента підвищить ясність і ефективність програми, т. е. благотворно позначиться на її якості.
Для можливості проведення контролю правдоподібності в повному об'ємі також повинні бути створені спеціальні інструментальні засоби, хоч ряд можливостей по контролю правдоподібності є в існуючих налагоджувальних і звичайних компіляторах.
Слід зазначити, що створення інструментальних засобів контролю структурованості і правдоподібності програм може бути істотно
спрощено при застосуванні наступних принципів:
проведення цих додаткових форм статичного контролю після завершення компіляції і тільки для синтаксично коректних програм;
максимальне використання результатів компіляції програми і, зокрема, інформації, що включається в лістинг компілятора;
замість повного синтаксичного розбору тексту програми перевіряється побудова для неї списку ідентифікаторів і списку операторів з вказівкою всіх їх необхідних ознак.
При відсутності інструментальних засобів контролю правдоподібності ця фаза статичного контролю також може об'єднуватися з візуальним контролем.
Четвертою формою статичного контролю програм є їх верифікація, тобто аналітичний доказ їх коректності.
У інтуїтивному значенні під коректністю розуміють властивості програми, що свідчать про відсутність у ній помилок, допущених розробником на різних етапах проектування (специфікації, проектування алгоритму і структур даних, кодування). Коректність самої програми по відношенню до цілей, поставлених перед її розробкою (тобто ця відносна властивість). Відмінність поняття коректності і надійності програм в наступному:
надійність характеризує як програму, так і її "оточення" (якість апаратури, кваліфікацію користувача і т.п.);
кажучи про надійність програми, звичайно допускають певну, хоча й малу, частку помилок в ній і оцінюють імовірність їх появи.
Надійність можна представити сукупністю наступних характеристик:
цілісність програмного засобу (здатність його до захисту від відмов);
живучість (здібність до вхідного контролю даних і їх перевірки в ході роботи);
завершеність (бездефектність готового програмного засобу, характеристика якості його тестування);
працездатність (здатність програмного засобу до відновлення своїх можливостей поле збоїв).
Очевидно, що не всяка синтаксично правильна програма є коректною у вказаному вище значенні, т. е. коректність характеризує семантичні властивості програм.
З урахуванням специфіки появи помилок в програмах можна виділити дві сторони поняття коректності:
коректність як точна відповідність цілям розробки програми (які відображені в специфікації) при умові її завершення або часткова коректність;
завершення програми, тобто досягнення програмою в процесі її виконання своєї кінцевої точки.
В залежності від виконання або невиконання кожного з двох названих властивостей програми розрізняють шість задач аналізу коректності:
доказ часткової коректності;
доказ часткової некоректність;
доказ завершення програми;
доказ незавершення програми;
доказ тотальної (повної) коректності (тобто одночасне рішення першої і третьої задач);
доказ некоректність (рішення другої або четвертої задачі).
Методи доказу часткової коректності програм як правило спираються на аксіоматичний підхід до формалізації семантики мов програмування. В даний час відомі аксіоматичні семантики Паскаля, підмножини ПЛ/1 і деяких інших мов.
Аксіоматична семантика мови програмування являє собою сукупність аксіом і правил виводу. За допомогою аксіом задається семантика простих операторів мови (привласнення, введення - виведення, виклику процедур). За допомогою правил висновку описується семантика складових операторів або керуючих структур (послідовності, умовного вибору, циклів). Серед цих правил висновку треба відмітити правило висновку для операторів циклу оскільки воно вимагає знання інваріанта циклу (формули, істинності якій не змінюється при будь-якому проходженні циклу).
Побудова інваріанта для оператора циклу по його тексту є алгоритмічно нерозв'язних задачі, тому для опису семантики циклів потрібно свого роду "підказка" від розробника програми.
Найбільш відомим з методів доказу часткової коректності програм є метод індуктивних тверджень запропонований Флойдом і вдосконалений Хоар. Метод складається з трьох етапів.
Перший етап - отримання анотованої програми. На цьому етапі для синтаксично правильної програми повинні бути задані твердження на мові логіки предикатів першого порядку:
вхідний предикат;
вихідний предикат;
по одному твердженням для кожного циклу (ці твердження задаються для вхідної точки циклу і повинні характеризувати семантику обчислень в циклі).
Доказ неістинності умов коректності свідчить про неправильність програми, або її специфікації, або програми і специфікації.
Незважаючи на достатню складність процесу верифікації програми і на те, що навіть успішно завершена верифікація не дає гарантій якості програми (так як помилка може міститися і у верифікації), застосування методів аналітичного доказу правильності дуже корисно для уточнення сенсу розробляється програми, а знання цих методів благотворно позначається на кваліфікації програміста.
Нарешті, динамічний контроль програми - це перевірка правильності програми при її виконанні на комп'ютері, тобто тестування.
ЦІЛІ, ПРИНЦИПИ І ЕТАПИ ТЕСТУВАННЯ.
Кожному програмісту відомо, скільки часу і сил витрачається на налагодження і тестування програм. На цей етап припадає близько 50% загальної вартості розробки програмного забезпечення.
Але не кожен з розробників програмних засобів може вірно визначити мету тестування. Нерідко можна почути, що тестування - це процес виконання програми з метою виявлення в ній помилок. Але ця мета недосяжна: ні яке саме ретельне тестування не дає гарантії, що програма не містить помилок.
Інше визначення тестування (у Г. Майерса) тестування - це процес виконання програми з метою виявлення в ній помилок. Таке визначення мети стимулює пошук помилок в програмах. Звідси також ясно, що "вдалим" тестом є такою, на якому виконання програми завершилося з помилкою. Навпаки, "невдалим можна назвати тест, що не дозволив виявити помилку в програмі.
Визначення Г. Майерса вказує на об'єктивну трудність тестування: це деструктивний (тобто зворотний творчому) процес. Оскільки програмування - процес конструктивний, ясно, що більшості розробників програмних засобів складно "перемкнутися" при тестуванні створеної ними продукції.
У Майерса сформульовані також основні принципи організації тестування:
необхідною частиною кожного тесту повинно бути опис очікуваних результатів роботи програми, щоб можна було швидко з'ясувати наявність або відсутність помилки в ній;
слід по можливості уникати тестування програми її автором, тому що крім вже вказаної об'єктивної складності тестування для програмістів тут присутній і той чинник, що виявлення недоліків в своїй діяльності суперечить людській психології (однак налагодження програми ефективніше усього виконується саме автором програми);
по тих же міркуваннях організація - розробник програмного забезпечення не повинна "одноосібно" його тестувати (повинні існувати організації, що спеціалізуються на тестуванні програмних засобів);
повинні бути правилом досконале вивчення результатів кожного тесту, щоб не пропустити малопомітну на поверхневий погляд помилку в програмі;
необхідно ретельно підбирати тест не тільки для правильних (передбачених) вхідних даних, але і для неправильних (непередбачених);
при аналізі результатів кожного тесту необхідно перевіряти, чи не робить програма того, що вона не повинна робити;
слід зберігати використані тести (для підвищення ефективності повторного тестування програми після її модифікації або установки у замовника);
тестування не повинне плануватися виходячи з припущення, що в програмі не будуть виявлені помилки (зокрема, слід виділяти для тестування достатні тимчасові і матеріальні ресурси);
слід враховувати так званий "принцип скупчення помилок": імовірність наявності не виявлених помилок в деякій частині програми прямо пропорційна числу помилок, вже виявлених в цій частині;
слід завжди пам'ятати, що тестування - творчий процес, а не ставитися до нього як до рутинного заняття.
Існує два основних види тестування: функціональне і структурне. При функціональному тестуванні програма розглядається як "чорний ящик" (тобто її текст не використовується). Відбувається перевірка відповідності поведінки програми її зовнішньої специфікації. Чи можливо при цьому повне тестування програми? Очевидно, що критерієм повноти тестування в цьому випадку був би перебір всіх можливих значень вхідних даних, що нездійсненна.
Оскільки вичерпне функціональне тестування неможливе, мова може йти про розробки методів, що дозволяють підбирати тести не "наосліп", а з великою імовірністю виявлення помилок в програмі.
При структурному тестуванні програма розглядається як "білий ящик" (тобто її текст відкритий для користування). Відбувається перевірка логіки програми. Повним тестуванням в цьому випадку буде таке, яке приведе до перебору всіх можливих шляхів на графі передач управління програми (її керуючому графі). Навіть для середніх по складності програм числом таких шляхів може досягати десятків тисяч. Якщо обмежитися перебором тільки лінійних не залежних шляхів, то і в цьому випадку вичерпне структурне тестування практично неможливо, тому що неясно, як підбирати тести, щоб забезпечити "покриття" всіх таких шляхів. Тому при структурному тестуванні необхідно використати інші критерії його повноти, що дозволяють досить просто контролювати їх виконання, але не дають гарантії повної перевірки логіки програми.
Але навіть якщо припустити, що вдалося досягнути повного структурного тестування деякої програми, в ній проте можуть міститися помилки, тому що
програма може не відповідати своїй зовнішній специфікації, що зокрема, може призвести до того, що в її керуючому графі виявляться пропущеними деякі необхідні шляхи;
не будуть виявлені помилки, поява яких залежить від оброблюваних даних (тобто на одних початкових даних програма робота?? т правильно, а на інших - з помилкою).
Таким чином, ні структурне, ні функціональне тестування не може бути вичерпним. Розглянемо докладніше основні етапи тестування програмних комплексів.
У тестування багатомодульним програмних комплексів можна виділити чотири етапи:
тестування окремих модулів;
спільне тестування модулів;
тестування функцій програмного комплексу (тобто пошук відмінностей між розробленою програмою і її зовнішньою специфікацією);
тестування всього комплексу загалом (тобто пошук невідповідності створеного програмного продукту сформульованим раніше цілям проектування, відображеним звичайно в технічному завданні).
На перших двох етапах використовуються передусім методи структурного тестування, тому що
на подальших етапах тестування ці методи використати складніше через великі розміри перевіряється програмного забезпечення;
подальші етапи тестування орієнтовані на виявлення помилок різного типу, які не обов'язково пов'язані з логікою програми.
При тестуванні як окремих модулів, так і їх комплексів повинні бути вирішені дві задачі:
побудова ефективної безлічі тестів;
вибір способу комбінування (збирання) модулів при створенні трестіруемого варіанту програми.
СТРУКТУРНЕ ТЕСТУВАННЯ.
Оскільки вичерпне структурне тестування неможливе, необхідно вибрати такі критерії його повноти, які допускали б їх просту перевірку і полегшували б цілеспрямований підбір тестів.
Найбільш слабким з критеріїв повноти структурного тестування є вимога хоч би однократного виконання (покриття) кожного оператора програми.
Більш сильним критерієм є так званий критерій С1: кожна гілка алгоритму (кожний перехід) повинна бути пройдена (виконана) хоч би один раз. Для більшості мов програмування покриття переходів забезпечує і покриття операторів, але, наприклад, для програм на мові ПЛ/1 додатково до покриття всіх гілок потрібно всіх додаткових точок входу в процедуру (що задаються операторами ENTRY) і всіх ON - одиниць.
Використання критерію покриття умов може викликати підбір тестів, що забезпечують перехід в програмі, який пропускається при використанні критерію С1 (наприклад, у програмі на мові Паскаль, що використовує конструкцію циклу WHILE х AND y DO ..., застосування критерію покриття умов вимагає перевірки обох варіантів виходу з циклу: NOT x і NOT y).
З іншого боку покриття умов може не забезпечувати покриття всіх переходів. Наприклад, конструкція IF A AND B THEN ... вимагає по критерію покриття умов двох тестів (наприклад, A = true, B = false і A = false, B = true), при яких може не виконуватися оператор, розташований в then - гілки оператора if.
Практично єдиним засобом, що надається сучасними системами програмування, є можливість визначення частоти виконання різних операторів програми (її профілізації). Але за допомогою цього інструмента підтримки тестування можна перевірити виконання тільки слабшого з критеріїв повноти - покриття всіх операторів.
Правда, за допомогою цього ж інструмента можна перевірити і виконання критерію С1. Але для цього заздалегідь текст програми повинен бути перетворений таким чином, щоб всі конструкції умовного вибору (IF і CASE
або SWITCH) містили гілки ELSE або DEFAULT, хоч би й порожні. У цьому випадку всі гілки алгоритму, не виконувалися на даному тесті будуть "видимі" з таблиці частоти виконання операторів перетвореної програми.
Актуальною залишається задача створення інструментальних засобів, що дозволяють:
накопичувати інформації про покритих і непокритих гілках для всіх використаних тестів;
виділяти розробнику ще не покриті при тестуванні дільниці програми, полегшуючи вибір наступних тестів;
підтримувати більш могутні критерії повноти структурного тестування.
Спільне тестування модулів.
Відомі два підходи до спільного тестування модулів: покрокове і монолітне тестування.
При монолітному тестуванні спочатку по окремості тестуються всі модулі програмного комплексу, а потім всі вони об'єднуються в робочу програму для комплексного тестування.
При покроковому тестуванні кожний модуль для свого тестування підключається до набору вже перевірених модулів.
У першому випадку для автономного тестування кожного модуля потрібний модуль - драйвер (тобто допоміжний модуль, що імітує виклик тестового модуля) і один або декілька модулів - заглушок (тобто допоміжних модулів, що імітують роботу модулів, що викликаються з тестового). При покроковому тестуванні модулі перевіряються не ізольовано один від одного, тому потрібні або тільки драйвери, або тільки заглушки.
рис. 1
При порівнянні покрокового і монолітного тестування можна відмітити наступні переваги першого підходу:
менша трудомісткість (для прикладу на рис.1 при монолітному тестуванні потрібні 5 драйверів і 5 заглушок; при покроковому тестуванні потрібні або тільки 5 драйверів - якщо модулі підключаються "знизу вгору", - або тільки 5 заглушок - якщо модулі підключаються "зверху вниз") ;
більш раннє виявлення помилок в інтерфейсах між модулями (їх збирання починається раніше, ніж при монолітному тестуванні);
легше налагодження, тобто локалізація помилок (вони в основному пов'язані з останнім з підключених модулів);
більш досконалі результати тестування (більш ретельна перевірка спільного використання модулів).
Є переваги і в монолітного тестування:
менше витрата машинного часу (хоча через більшу складність відладки може знадобитися додаткова перевірка програми і ця перевага буде зведена на немає);
надається більше можливостей для організації паралельної роботи на початковому етапі тестування.
Загалом більш доцільним є вибір покрокового тестування. При його використанні можливі дві стратегії підключення модулів: спадна і висхідна.
Спадний тестування починається з головного (або верхнього) модуля програми, а вибір наступного модуля відбувається з числа модулів, що викликаються з вже протестованих. Одна з основних проблем, що виникають при низхідному тестуванні, - створення заглушок. Це тривіальна задача, т. к. як правило недостатньо, щоб в заглушці виконувався висновок відповідного інформаційного повідомлення і повернення завжди одних і тих же значень вихідних даних.
Інша проблема, яку необхідно вирішувати при низхідному тестуванні, - форма представлення тестів в програмі, тому що, як правило, головний модуль отримує вхідні дані не безпосередньо, а через спеціальні модулі введення, які при тестуванні на початку замінюються заглушками. Для передачі в головний модуль різних тестів треба або мати декілька різних заглушок, або записати ці тести в файл у зовнішній пам'яті і за допомогою заглушки прочитувати їх.
Оскільки після тестування головного модуля процес перевірки може продовжуватися по-різному, варто дотримуватися наступних правил:
модулі, які містять операції введення-висновку, повинні підключатися до тестування як можна раніше;
критичні (тобто найбільш важливі) для програми загалом модулі також повинні тестуватися в першу чергу.
12
Основні переваги спадного тестування:
вже на ранній стадії тестування є можливість отримати працюючий варіант розробляється програми;
швидко можуть бути виявлені помилки, пов'язані з організацією взаємодія з користувачем.
Недоліки низхідній стратегії продемонструють за допомогою рис.2.
Припустимо, що на наступному кроці тестування заглушка модуля H замінюється його реальним текстом. Тоді
може виявитися важким або навіть неможливим побудувати такий тест на вході модуля J, який відповідав би будь-якої заданої наперед послідовності значень даних на вході модуля Н;
не завжди виявиться можливим легко оцінити відповідність значень даних на вході модуля J необхідним тестам для перевірки модуля Н;
тому що результати виконання програми на побудованому для перевірки модуля Н тесті виводяться не їм, а модулем I, може виявитися важким відновлення дійсних результатів роботи модуля Н.
Інші проблеми, які можуть виникати при низхідному тестуванні:
з'являється спокуса суміщення спадного проектування з тестуванням, що, як правило, нерозумно, тому що проектування - процес ітеративний і в ньому неминучий повернення на верхні рівні і виправлення прийнятих раніше рішень, що знецінює результати вже проведеного тестування;
може виникнути бажання перейти до тестування модуля наступного рівня до завершення тестування попереднього з об'єктивних причин (необхідності створення декількох версій заглушок, використання модулями верхнього рівня ресурсів модулів нижніх рівнів).
При висхідному тестуванні перевірка програми починається з термінальних модулів (тобто тих, які не викликають не яких інших модулів програми). Ця стратегія багато в чому протилежна низхідному тестування (зокрема, переваги стають недоліками і навпаки).
Немає проблеми вибору наступного модуля - враховується лише те, щоб він викликав тільки вже протестовані модулі. На відміну від заглушок драйвери не повинні мати декілька версій, тому їх розробка в більшості випадків простіше (крім того, використання коштів автоматизації і відладки полегшує створення якраз драйверів, а не заглушок).
Інші достоїнства висхідного тестування:
оскільки немає проміжних модулів (тестовий модуль є для робочого варіанту програми модулем самого верхнього рівня), немає проблем, пов'язаних з можливістю або складністю завдання тестів;
немає можливості поєднання проектування з тестуванням;
немає труднощів, що викликають бажання перейти до тестування наступного модуля, не завершивши перевірки попереднього.
Основними недоліком висхідного тестування є те, що перевірка всієї структури програмного комплексу розробляється можлива тільки на завершальній стадії тестування.
Хоча однозначного висновку про переваги тієї чи іншої стратегії покрокового тестування зробити не можна (потрібно враховувати конкретні характеристики тестованої програми), в більшості випадків більш переважним є висхідне тестування.
На третьому етапі тестування програмних комплексів (тестуванні функцій) використовуються передусім методи функціонального тестування.
Функціональне тестування.
Огляд методів проектування тестів при функціональному тестуванні почнемо з методу еквівалентного роздроблення.
Оскільки нашою метою є побудови безлічі тестів, що характеризується найвищою імовірністю виявлення більшості помилок в тестованої програмі, то тест з цієї безлічі повинен:
зменшувати (більш ніж на одиницю) число інших тестів, які повинні бути розроблені для досягнення заздалегідь поставленої мети "задовільного" тестування;
покривати собою значну частину інших можливих тестів.
Іншими словами:
кожен тест повинен містити в собі перевірку найбільшого числа задаються зовнішньою специфікацією вхідних умови (обмежень на вхідні дані) для того, щоб мінімізувати загальне число необхідних тестів;
необхідно розбити область значень вхідних даних на кінцеве число підобластей (які будуть називатися класами еквівалентності), щоб можна було вважати кожний тест, що є представником деякого класу, еквівалентним будь-якого іншого тесту цього класу (тобто виявляє одні й ті ж помилки). < br>
У загальному випадку використання терміну "клас еквівалентності" є тут не цілком точним, так виділені підобласті можуть перетинатися.
Проектування тестів по методу еквівалентного роздроблення проводиться в два етапи:
виділення по зовнішній специфікації класів еквівалентності;
побудова безлічі тестів.
На першому етапі відбувається вибір з специфікації кожної вхідної умови і роздроблення його на дві або більше за групу, відповідні так званим "правильним" (ПКЕ) і "неправильним" класом еквівалентності (НКЕ), тобто областям допустимих для програми і неприпустимих значень вхідних даних. Цей процес залежить від вигляду вхідної умови. Якщо вхідна умова описує область (наприклад, х <= 0.5) або кількістю (наприклад, розмір масиву А рівний 50) допустимих значень вхідних даних, то визначаються один ПКЕ (х <= 0.5 або розмір А рівний 50) і дві НКЕ ( х <-0.5; г> 0.5 або розмір А менше 50; розмір А більше 50).
Якщо вхідна умова описує дискретне безліч допустимих значень вхідних даних (наприклад, В може дорівнює -1, 0 або 1), то визначаються ПКЕ для кожного значення з безлічі (в даному прикладі 3) і одна НКЕ (В <> -1 & В < > 0 & В <> 1).
Якщо вхідна умова описує ситуацію "помилково бути" (наприклад, N> 0), то визначаються один ПКЕ (N> 0) і один НКЕ (N <= 0).
На другому етапі методу еквівалентного роздроблення виділені класи еквівалентності використовуються для побудови тестів:
кожному класу привласнюється свій номер;
проектуються тести для ПКЕ таким чином, що кожний тест покриває як можна більше ще не покритих ПКЕ, до тих пір, поки все ПКЕ не будуть покриті;
проектуються тести для НКЕ таким чином, що кожний тест покриває один і тільки один НКЕ, до тих пір, поки всі НКЕ не будуть покриті.
Порушення третьої умови приводить до того, що деякі тести з недопустимими значеннями вхідних даних перевіряють тільки одну помилку і приховують реакцію програми на інші помилки.
Метод еквівалентного роздроблення значно краще випадкового підбору тестів, але має свої недоліки. Основний з них - пропуск певних типів високоефективних тестів (тобто тестів, що характеризуються великою імовірністю виявлення помилок). Від цього недоліку багато в чому вільний метод аналізу граничних умов.
Під граничними умовами розуміють ситуації, виникаючі безпосередньо на кордоні певної в специфікації вхідної або вихідної умови, вище або нижче її. Метод аналізу граничних умов відрізняється від методу еквівалентного роздроблення наступним:
вибір будь-якого представника класу еквівалентності здійснюється таким чином, щоб перевірити тестом кожний кордон цього класу;
при побудові тестів розглядаються не тільки вхідні умови, але й вихідні (тобто певні у зовнішній специфікації обмеження на значення вхідних даних).
Загальні правила методу аналізу граничних умов:
побудувати тести для кордонів області допустимих значень вхідних даних і тести з недопустимими значеннями, відповідними незначному виходу за межі цієї області (наприклад, для області [-1.0; 1.0] будуємо тести -1.0; 1.0; -1.001; 1.001);
побудувати тести для мінімального і максимального значень вхідних умов, що визначають дискретне безліч допустимих значень вхідних даних, і тести для значень, великих або менших цих величин (наприклад, якщо вхідний файл може містити від 1 до 225 записів, то вибираються тести для порожнього файла, що містить 1, 255 і 256 записів);
використати правило 1 для кожної вихідної умови (наприклад, програма обчислює щомісячну витрату приватної особи або невеликого підприємства, мінімум якого 0.00 $, а максимум 1165.50 $; тоді необхідно побудувати тести, що викликають негативну витрату, витрати, рівну 0.00 $ і 1165.50 $, і витрату , більшу 1165.50 $);
використати правило 2 для кожної вихідної умови (наприклад, програма шукає і відображає на екрані дисплея найбільш відповідні, в залежності від вхідної умови, реферати статей, але не більше чотирьох; тоді необхідно побудувати тести, що приводять до відображення 0, 1, 4 рефератів і спроб помилкового відображення 5 рефератів);
якщо вхідні і вихідні дані програми собою впорядковану безліч (послідовний файл, лінійний список, таблицю), то при тестуванні зосередити увагу на першому і останньому елементі безлічі;
спробувати знайти і перевірити тестами інші гран?? чние умови.
Важливість перевірки кордонів вихідних умов пояснюється тим, що не завжди граничним значенням вхідних даних відповідають граничні значення результатів роботи програм.
Для ілюстрації необхідності аналізу граничних умов приведемо тривіальний приклад. Нехай є програма, що здійснює введення трьох чисел інтерпретує їх як довжину сторін трикутника і що виводить повідомлення про тип трикутника ( "різносторонній", "рівнобедрений" або "рівносторонній"). Припустимо також, що в програмі міститься помилка: при перевірці умови побудови трикутника (сума довжин будь-яких двох сторін повинна бути більше третьою) використовується операція відношення> = замість>. При проектуванні тестів по методу еквівалентного роздроблення будуть побудовані тести для випадків можливості побудови трикутника (наприклад, 3, 4, 5) і неможливості його побудови (наприклад, 1, 2, 4), тобто помилка в програмі не буде виявлена (на вхідні дані 1, 2, 3 буде виведене повідомлення "різносторонній трикутник"). Але подібний тест буде отриманий при використанні методу аналізу граничних умов.
Аналіз граничних умов - один з найбільш корисних методів проектування тестів. Але він часто виявляється неефективним через те, що граничні умови іноді ледь вловимі, а їх виявлення вельми важко.
Загальним недоліком двох розглянутих вище методів функціонального тестування є те, що при їх застосування досліджуються можливі комбінації вхідних умов. Слід, щоправда, зауважити, що через вельми велике число таких комбінацій, їх аналіз викликає істотні ускладнення. Але існує метод (метод функціональних діаграм), що дозволяє в цьому випадку систематичним образом вибрати високо ефективні тести. Корисним побічним ефектом цього методу є виявлення неповноти і суперечності у зовнішніх специфікаціях.
Функціональна діаграма - це текст на деякій формальній мові, на яку транслюється специфікація, складена на природному або напівформальному мовами. Далі буде називатися причиною окрема вхідна умова і слідством - вихідна умова або перетворення системи (тобто залишкова дія програми, викликана певною вхідною умовою або їх комбінацією). Наприклад, для програми оновлення файла зміна в ньому є перетворенням системи, а підтверджує ця зміна повідомлення - вихідною умовою.
Метод функціональних діаграм складається з шести основних етапів. На першому з них (необов'язковому) зовнішня специфікація великого розміру розбивається на окремі ділянки (наприклад, специфікація компілятора мови програмування розбивається на дільниці, що визначають синтаксичний контроль окремих операторів мови).
На другому етапі в специфікації виділяються причини і слідства, а на третьому - аналізується семантичний зміст специфікації і вона перетворюється в булевський граф, що зв'язує причини і слідства і що називається функціональною діаграмою. На рис.3 приведені базові символи для запису функціо
