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