Нарешті, динамічний контроль програми - це перевірка правильності програми при її виконанні на комп'ютері, тобто тестування.
ЦЕЛІ, ПРІНЦИПИ І ЕТАПИ ТЕСТУВАННЯ
Кожному програмісту відомо, скільки часу і сил йде на відладку і тестування програм. На цей етап доводиться біля 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 у DO..., застосування критерію покриття умов вимагає перевірки обох варіантів виходу з циклу: NOT х і NOT у ).
З іншого боку покриття умов може не забезпечувати покриття всіх переходів. Наприклад, конструкція IF А AND В THEN... вимагає по критерію покриття умов двох тестів (наприклад, А=true, В=false і А=false, В=true ), при яких може не виконуватися оператор, розташований в then - гілки оператора if.
Практично єдиним засобом, що надається сучасними системами програмування, є можливість визначення частоти виконання різних операторів програми (її профілізації). Але за допомогою цього інструмента підтримки тестування можна перевірити виконання тільки найслабішого з критеріїв повноти - покриття всіх операторів.
Правда, за допомогою цього ж інструмента можна перевірити і виконання критерію С1. Але для цього заздалегідь текст програми повинен бути перетворений таким чином, щоб всі конструкції умовного вибору (IF і CASE
10
або SWITCH ) містили гілки ELSE або DEFAULT, хоч би і пусті. У цьому випадку всі гілки алгоритму, ті, що не виконувалися на даному тесті будуть “видимі" з таблиці частоти виконання операторів перетвореної програми.
Актуальною залишається задача створення інструментальних засобів, що дозволяють:
1) нагромаджувати інформації про покриті і непокриті гілки для всіх використаних тестів;
2) виділяти розробнику ще не покриті при тестуванні дільниці програми, полегшуючи вибір наступних тестів;
3) підтримувати більш могутні критерії повноти структурного тестування.
СПІЛЬНЕ ТЕСТУВАННЯ МОДУЛІВ.
Відомі два підходи до спільного тестування модулів: покрокове і монолітне тестування.
При монолітному тестуванні спочатку по окремості тестуються всі модулі програмного комплексу, а потім всі вони об'єднуються в робочу програму для комплексного тестування.
При покроковому тестуванні кожний модуль для свого тестування підключається до набору вже перевірених модулів.
У першому випадку для автономного тестування кожного модуля потрібний модуль - драйвер ( тобто допоміжний модуль, що імітує виклик модуля, що тестується ) і один або декілька модулів - заглушок ( тобто допоміжних модулів, що імітують роботу модулів, що викликаються з того, що тестується). При покроковому тестуванні модулі перевіряються не ізольовано один від одного, тому потрібні або тільки драйвери, або тільки заглушки.