Розділ 1 структурне тестування програмного забезпечення

Тема 1.1 Класифікація принципів тестування програмного забезпечення

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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