Методи тестування програмного забезпечення та їх порівняння. Тестування методом "чорної скриньки" і тестування методом "білого ящика"

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

методи

Головна мета тестування ПО - підтвердження якості програмного комплексу шляхом систематичної налагодження додатків в ретельно контрольованих умовах, визначення їх повноти і коректності, а також виявлення прихованих помилок.

Методи перевірки (тестування) програм можна розділити на статичні і динамічні.

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

Динамічні техніки наступні:

1. Тестування методом білого ящика. Це ґрунтовне дослідження внутрішньої логіки і структури програми. При цьому необхідно знання вихідного коду.
2. Тестування методом чорного ящика. Дана техніка не потребує будь-яких знань про внутрішню роботу додатка. Розглядаються тільки основні аспекти системи, які пов`язані або мало пов`язані з її внутрішньої логічної структурою.
3. Метод сірого ящика. Поєднує в собі попередні два підходи. Налагодження з обмеженим знанням про внутрішній функціонуванні додатки поєднується зі знанням основних аспектів системи.

прозоре тестування

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

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

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

недоліки:

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

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

Основні різновиди:

1) тестування управління потоком - структурна стратегія, яка використовує потік управління програмою в якості моделі і віддає перевагу більшій кількості простих шляхів перед меншим числом більш складних;

2) налагодження розгалуження має на меті дослідження кожної опції (істинною або помилковою) кожного оператора управління, який також включає в себе об`єднане рішення;

3) тестування основного шляху, яке дозволяє тестувальника встановити міру логічної складності процедурного проекту для виділення базового набору шляхів виконання;

4) перевірка потоку даних - стратегія дослідження потоку управління шляхом анотації графа інформацією про оголошення і використанні змінних програми;

5) тестування циклів - повністю зосереджена на правильному виконанні циклічних процедур.

поведінкова налагодження

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

Переваги такого підходу:

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

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

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

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

До даної категорії можна віднести наступні методи тестування програмного забезпечення:

1) еквівалентну розбиття, яке може зменшити набір тестових даних, так як вхідні дані програмного модуля розбиваються на окремі частини;

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

3) фаззінга - використовується для пошуку помилок реалізації за допомогою введення перекручених або полуіскаженних даних в автоматичному чи напівавтоматичному режимі;

4) графи причинно-наслідкових зв`язків - методика, заснована на створенні графів і встановленні зв`язку між дією і його причинами: тотожність, заперечення, логічне АБО і логічне І - чотири основних символу, що виражають взаємозалежність між причиною і наслідком;

5) перевірка ортогональних масивів, що застосовується до проблем з відносно невеликою областю введення, що перевищує можливості вичерпного дослідження;

6) тестування всіх пар - техніка, набір тестових значень якої включає всі можливі дискретні комбінації кожної пари вхідних параметрів;

7) налагодження переходів станів - техніка, корисна для перевірки машини станів, а також для навігації по графічного інтерфейсу користувача.

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

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

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

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

Яка кількість тестів необхідно провести, щоб перевірити всі можливі значення для 4 вікон прапорця і одного двохпозиційного поля, що задає час в секундах? На перший погляд розрахунок простий: 4 поля з двома можливими станами - 24 = 16, які необхідно помножити на число можливих позицій від 00 до 99, тобто 1600 можливих тестів.

Проте цей розрахунок помилковий: ми можемо визначити, що двопозиційне поле може також містити пробіл, т. Е. Воно складається з двох літер та позицій і може включати символи алфавіту, спеціальні символи, прогалини і т. Д. Таким чином, якщо система являє собою 16-розрядний комп`ютер, то вийде 216 = 65 536 варіантів для кожної позиції, результирующих в 4 294 967 296 тестових випадків, які необхідно помножити на 16 комбінацій для прапорців, що в цілому дає 68 719 476 736. Якщо їх виконати зі швидкістю 1 тест в секунду, то загальна тривалість тестування складе 2 177,5 років. Для 32 або 64-бітових систем, тривалість ще більше.

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

еквівалентну розбиття

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

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

Іншим наслідком такого розбиття є скорочення комбинаторного вибуху між різними змінними і пов`язане з ними скорочення тестових випадків.

Наприклад, в (1 / x)^1/2 використовується три послідовності даних, три еквівалентних розбиття:

1. Всі позитивні числа будуть оброблятися таким же чином і повинні давати правильні результати.

2. Всі негативні числа будуть оброблятися так само, з таким же результатом. Це невірно, тому що корінь з від`ємного числа є уявним.

3. Нуль буде оброблятися окремо і дасть помилку «поділ на нуль». Це розділ з одним значенням.

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

крайовий аналіз

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

• неправильне використання операторів відносини (lt;, gt ;, =, &ne-, &ge-, &le-);
• поодинокі помилки;
• проблеми в циклах і ітераціях,
• неправильні типи або розмір змінних, використовуваних для зберігання інформації;
• штучні обмеження, пов`язані з даними і типами змінних.

напівпрозоре тестування

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

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

• архітектурна модель;
• уніфікована мова моделювання (UML);
• модель станів (кінцевий автомат).

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

Такі методи тестування мають наступні переваги:

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

недоліки:

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

Інша назва техніки сірого ящика - напівпрозора налагодження.

До цієї категорії відносять такі методи тестування:

1) прямокутний масив - використання підмножини всіх можливих комбінацій;

2) матрична налагодження з використанням даних про стан програми;

3) регресивна перевірка, яка проводиться при внесенні нових змін в ПЗ;

4) шаблонний тест, який аналізує дизайн і архітектуру добротного додатки.

Порівняння методів тестування ПО

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

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

Нижче наведені основні відмінності трьох динамічних технік тестування - дана таблиця порівняння між трьома формами налагодження ПО.

Автоматизація

Автоматичні методи тестування програмних продуктів набагато спрощують процес перевірки незалежно від технічного середовища або контексту ПО. Їх використовують в двох випадках:

1) для автоматизації виконання утомливих, повторюваних або скрупульозних завдань, таких як порівняння файлів в декількох тисяч рядків з метою вивільнення часу тестувальника для концентрації на більш важливих моментах;

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

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

• управління тестуванням, яке включає підтримку управління проектом, версіями, конфігураціями, ризик-аналіз, відстеження тестів, помилок, дефектів і інструменти створення звітів;
• управління вимогами, яке включає зберігання вимог і специфікацій, їх перевірку на повноту і багатозначність, їх пріоритет і відстеження кожного тесту;
• критичний перегляд і статичний аналіз, включаючи моніторинг потоку і завдань, запис і зберігання коментарів, виявлення дефектів і планових корекцій, управління посиланнями на перевірочні списки і правила, відстеження зв`язку вихідних документів і коду, статичний аналіз з виявленням дефектів, забезпеченням відповідності стандартам написання коду, розбором структур і їх залежностей, обчисленням метричних параметрів коду і архітектури. Крім того, використовуються компілятори, аналізатори зв`язків і генератори крос-посилань;
• моделювання, яке включає інструменти моделювання бізнес-поведінки і перевірки створених моделей;
• розробка тестів забезпечує генерацію очікуваних даних виходячи з умов і інтерфейсу користувача, моделей і коду, управління ними для створення або зміни файлів і БД, повідомлень, перевірки даних виходячи з правил управління, аналізу статистики умов і ризиків;
• критичний перегляд шляхом введення даних за допомогою графічного інтерфейсу користувача, API, командні рядки з використанням компараторов, які допомагають визначити успішні і невдалі тести;
• підтримка середовищ налагодження, яка дозволяє замінити відсутнє обладнання або ПЗ, в т. ч. симулятори обладнання на основі підмножини детермінованого виходу, емулятори терміналів, мобільних телефонів або мережевого устаткування, середовища для перевірки мов, ОС і апаратного забезпечення шляхом заміни відсутніх компонентів драйверами, фіктивними модулями і ін., а також інструменти для перехоплення і модифікації запитів ОС, симуляції обмежень ЦПУ, ОЗУ, ПЗУ або мережі;
• порівняння даних файлів, БД, перевірка очікуваних результатів під час і після закінчення тестування, в т. ч. динамічне і пакетне порівняння, автоматичні «оракули»;
• вимір покриття для локалізації витоків пам`яті і некоректного управління нею, оцінки поведінки системи в умовах симульованої навантаження, генерації навантаження додатків, БД, мережі або серверів по реалістичним сценаріями її зростання, для вимірювання, аналізу, перевірки та звіту про системні ресурси;
• забезпечення безпеки;
• тестування продуктивності, навантаження і динамічний аналіз;
• інші інструменти, в т. ч. для перевірки правопису і синтаксису, мережевої безпеки, наявності всіх сторінок веб-сайту та ін.

перспектива

Зі зміною тенденцій в індустрії ПЗ процес його налагодження також зазнає змін. Існуючі нові методи тестування програмних продуктів, такі як сервіс-оріентірованнае архітектура (SOA), бездротові технології, мобільні послуги і т. Д., Відкрили нові способи перевірки ПО. Деякі зі змін, які очікуються в цій галузі протягом наступних кількох років, перераховані нижче:

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

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