Author: adminsimplerec

Нефункціональне тестування

Нефункціональне тестування оцінює атрибути, відмінні від функціональних характеристик компонента або системи. Нефункціональне тестування — це перевірка того, «наскільки добре поводиться система». Основною метою нефункціонального тестування є перевірка нефункціональних характеристик якості програмного забезпечення. Тестування продуктивності відноситься до нефункціонального тестування.

Нефункціональні характеристики

Ще раз згадаємо нефункціональні характеристики. Стандарт ISO/IEC 25010 надає таку класифікацію нефункціональних характеристик якості програмного забезпечення:

• Ефективність виконання/продуктивності (Performance efficiency)
• Сумісність (Compatibility)
• Зручність використання (Usability)
• Надійність (Reliability)
• Безпека (Security)
• Зручність супроводу (Maintainability)
• Портативність (Portability)

Тестування продуктивності

Тестування продуктивності (Performance testing) — це процес тестування програмного забезпечення, який використовується для перевірки швидкості, часу відгуку, стабільності, надійності, масштабованості та використання ресурсів програмного додатка під певним навантаженням. Основною метою тестування продуктивності є виявлення та усунення вузьких місць продуктивності програмного додатку.

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

• Швидкість (Speed) – визначає, чи швидко реагує програма
• Масштабованість (Scalability) – визначає максимальне навантаження на користувача, яке може витримати програма.
• Стабільність (Stability) – визначає, чи програма стабільна за різних навантажень

Значення тестування продуктивності

Метою тестування продуктивності є усунення вузьких місць продуктивності.

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

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

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

Типи тестування продуктивності

Тестування навантаження (Load testing) – перевіряє здатність програми працювати при очікуваному навантаженні користувача. Мета полягає в тому, щоб виявити вузькі місця продуктивності .

Стрес-тестування (Stress testing) – передбачає тестування програми за екстремальних робочих навантажень, щоб побачити, як вона справляється з великим трафіком або обробкою даних. Мета полягає в тому, щоб визначити точку зламу програми.

Тестування витривалості (Endurance testing) – проводиться, щоб переконатися, що програмне забезпечення може витримати очікуване навантаження протягом тривалого періоду часу.

Тестування стрибків (Spike testing) – перевіряє реакцію програмного забезпечення на раптові великі стрибки навантаження, створювані користувачами.

Тестування об’єму (Volume testing) – створюється велика кількість записів у базі і даних і моніториться поведінка системи. Мета – перевірити поведінку системи у разі зміни обсягів даних в базі даних.

Тестування масштабованості (Scalability testing) – визначити ефективність програмного додатку у разі збільшення кількості користувачів.

Проблеми продуктивності

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

• Тривалий час завантаження – зазвичай час завантаження – це початковий час, потрібний програмі для запуску. Як правило, це має бути зведено до мінімуму.
• Поганий час відгуку – час відгуку – це час, який проходить від моменту введення користувачем даних у програму до моменту, коли програма виводить відповідь на цей вхід. Загалом це має бути дуже швидко. Знову ж таки, якщо користувачеві доводиться чекати занадто довго, він втрачає інтерес.
• Погана масштабованість – програмний продукт страждає від поганої масштабованості, якщо він не може працювати з очікуваною кількістю користувачів або коли він не вміщує достатньо широке коло користувачів.
• Вузькі місця – вузькі місця – це перешкоди в системі, які погіршують загальну продуктивність системи. Вузьке місце — це коли помилки кодування або проблеми з апаратним забезпеченням спричиняють зниження пропускної здатності за певних навантажень. Вузьке місце часто спричинене одним несправним розділом коду. Ключ до вирішення проблеми з вузьким місцем полягає в тому, щоб знайти частину коду, яка спричиняє сповільнення, і спробувати її виправити. Вузькі місця, як правило, усуваються шляхом виправлення погано запущених процесів або додавання додаткового обладнання. Деякі поширені вузькі місця продуктивності: завантаження ЦП, використання пам’яті, використання мережі, обмеження операційної системи, використання диска.

Процес тестування продуктивності

Крок 1) Визначте середовище тестування. Знайте середовище тестування та доступні інструменти тестування. Зрозумійте деталі обладнання, програмного забезпечення та мережевих конфігурацій, які використовувалися під час тестування, перш ніж розпочати процес тестування. Це допоможе тестувальникам створювати ефективніші тести. Це також допоможе визначити можливі проблеми, з якими можуть зіткнутися тестувальники під час процедур тестування продуктивності.

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

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

Крок 4) Налаштування тестового середовища. Підготуйте середовище тестування перед виконанням. Крім того, організуйте інструменти та інші ресурси.

Крок 5) Впровадження тестів. Створіть тести продуктивності відповідно до вашого тестового дизайну.

Крок 6) Виконайте тести. Виконувати та контролювати тести.

Крок 7) Проаналізуйте, налаштуйте та повторно перевірте. Проаналізуйте результати тестів. Потім виконайте налаштування та перевірте ще раз, щоб побачити, чи є покращення чи зниження продуктивності.

Деякі показники тестування продуктивності

Використання процесора (Processor Usage) – кількість часу, який процесор витрачає на виконання активних потоків.

Використання пам’яті (Memory use) – обсяг фізичної пам’яті, доступний процесам.

Дисковий час (Disk time) – час, протягом якого диск зайнятий виконанням запиту на читання або запис.

Пропускна здатність (Bandwidth) – оказує кількість бітів на секунду, які використовуються мережевим інтерфейсом.

Приватні байти (Private bytes) – кількість байтів, виділених процесом, які не можуть бути спільно використані іншими процесами. Вони використовуються для вимірювання витоків пам’яті та використання.

Деякі інструменти тестування продуктивності

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

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

• LoadNinja. Цей cloud інструмент навантажувального тестування дає змогу командам записувати та миттєво відтворювати комплексні навантажувальні тести. Команди можуть збільшити охоплення тестуванням і скоротити час тестування навантаження.
• BlazeMeter. Це потужний інструмент тестування продуктивності. Тестувальники можуть використовувати такі розширені функції, як імітаційні служби, дані синтетичних тестів, тестування та моніторинг API. Масштабується до 2 мільйонів користувачів.
• LoadRunner – це популярний інструмент тестування продуктивності. Цей інструмент здатний симулювати сотні тисяч користувачів, навантажуючи додатки, щоб визначити їх поведінку під очікуваними навантаженнями. У Loadrunner є генератор віртуальних користувачів, який імітує дії живих користувачів.
• Jmeter – один з провідних інструментів, який використовується для навантажувального тестування веб-серверів і серверів додатків.

В цьому відео поговоримо про тестування продуктивності (тип нефункціонального тестування чорної скриньки):
00:27 Нефункціональне тестування
00:51 Нефункціональні характеристики
01:22 Тестування продуктивності
02:20 Значення тестування продуктивності
03:42 Типи тестування продуктивності
07:03 Проблеми продуктивності
09:42 Процес тестування продуктивності
13:27 Деякі показники для тестування продуктивності
14:54 Деякі інструменти для тестування продуктивності

Тестування чорної скриньки

Тестування чорної скриньки базується на специфікаціях і одержує тести з зовнішньої документації щодо об’єкта тестування. Основна мета тестування чорної скриньки — перевірити поведінку системи на відповідність її специфікаціям. Тому в англомовній літературі можна зустріти термін specification-based (той що базується на специфікації), який є синонімом black-box.

Функціональне та нефункціональне

Функціональне тестування оцінює функції, які повинен виконувати компонент або система. Функції – це «те, що» повинен робити тестовий об’єкт. Основною метою функціонального тестування є перевірка функціональної повноти, функціональної правильності та функціональної відповідності.

Нефункціональне тестування оцінює атрибути, відмінні від функціональних характеристик компонента або системи. Нефункціональне тестування — це перевірка того, «наскільки добре поводиться система». Основною метою нефункціонального тестування є перевірка нефункціональних характеристик якості програмного забезпечення.

Стандарт ISO/IEC 25010 надає таку класифікацію нефункціональних характеристик якості програмного забезпечення:

• Ефективність виконання/продуктивності (Performance efficiency)
• Сумісність (Compatibility)
• Зручність використання (Usability)
• Надійність (Reliability)
• Безпека (Security)
• Зручність супроводу (Maintainability)
• Портативність (Portability)

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

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

Функціональне тестування

Функціональне тестування системи включає тести, які оцінюють функції, які система повинна виконувати. Функціональні вимоги можуть бути описані в робочих продуктах, таких як специфікації бізнес-вимог, епіки, історії користувачів, варіанти використання або функціональні специфікації, або вони можуть бути незадокументованими. Функції – це «те, що» повинна робити система.

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

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

Ретельність функціонального тестування можна виміряти за допомогою функціонального покриття. Функціональне покриття – це ступінь, до якого певна функціональність була покрита тестами, і виражається у відсотках від типу(ів) покритого елемента.

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

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

Usability і функціональне

Зручність використання (Usability) є нефункціональною характеристикою. І відповідно тестування зручності використання (Usability testing) є нефункціональним типом тестування.

Однак в ряді випадків можна побачити, що до функціонального тестування відносять тестування базової зручності використання (Basic usability testing) чи тестування базового чи мінімально необхідного інтерфейсу користувача (Basic user interface testing).

Більш коректним є другий варіант (про базовий інтерфейс). Тим не менше важко провести межу між базовим інтерфейсом та зручністю використання. Низка авторів відносить тестування інтерфейсу користувача (user interface testing) до функціонального тестування. Однак під час тестування зручності використання також оцінюється робота користувацького інтерфейсу. Якщо в ході тестування нас цікавить працездатність, функціональність елементів інтерфейсу, то можна вважати таке тестування функціональним. Якщо ж нас цікавить питання оптимальності розміщення елементів інтерфейсу, їхня доступність, читабельність шрифтів тощо, то це вже парафія Usability тестування.

Процес виконання функціонального тестування

• Зрозуміти функціональні вимоги
• Визначити тестові вхідні дані
• Визначити очікувані результати
• Виконати тестові кейси
• Порівняти фактичні та очікувані результати

Класи еквівалентності

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

Дійсні значення – це значення, які повинні бути прийняті компонентом або системою. Розділ еквівалентності, що містить дійсні значення, називається «дійсним розділом еквівалентності».

Недійсні значення – це значення, які повинні бути відхилені компонентом або системою. Розділ еквівалентності, що містить недійсні значення, називається «недійсним розділом еквівалентності».

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

Кожне значення має належати одному й лише одному розділу еквівалентності.

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

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

Аналіз граничних значень

Аналіз граничних значень (BVA) є розширенням розподілу еквівалентності, але його можна використовувати лише тоді, коли розділ впорядкований і складається з числових або послідовних даних. Мінімальне та максимальне значення (або перше та останнє значення) розділу є його граничними значеннями.

Наприклад, припустімо, що поле введення приймає одне ціле значення як вхід, використовуючи клавіатуру для обмеження введення таким чином, щоб інші варіанти були неможливі. Допустимий діапазон – від 1 до 5 включно. Отже, є три розділи еквівалентності: недійсний (занадто низький); дійсний; недійсний (занадто високий). Для дійсного розділу еквівалентності граничними значеннями є 1 і 5. Для недійсного (занадто високого) розділу граничне значення дорівнює 6. Для недійсного (занадто низького) розділу існує лише одне граничне значення, 0, оскільки це розділ лише з одним членом.

У наведеному прикладі ми визначаємо два граничні значення на межу. Межа між недійсним (занадто низьким) і дійсним дає тестові значення 0 і 1. Межа між дійсним і недійсним (занадто високим) дає тестові значення 5 і 6. Деякі варіанти цього методу визначають три граничні значення на межу: значення перед, на та безпосередньо за межею. У попередньому прикладі з використанням трьохточкових граничних значень нижні граничні тестові значення становлять 0, 1 і 2, а верхні граничні тестові значення – 4, 5 і 6.

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

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

Приклад 1

В цьому прикладі у нас 5 класів еквівалентності: до 10 грамів, від 11 до 50 грамів, від 51 до 75 грамів, від 76 до 100 грамів та більше 100 грамів. Себто відповіді А та С не підходять оскільки містять лише 4 класи. Відповідь D є неправильною оскільки не тестує 5 клас. А правильна відповідь В.

Приклад 2

Правильна відповідь в даному прикладі 33501 (4000+1500+28000).

Тестування таблиці рішень

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

Загальні позначення в таблицях рішень такі:

Для умов:

• Y означає, що умова виконується (також може відображатися як T або 1)
• N означає, що умова хибна (також може відображатися як F або 0)
• — означає, що значення умови не має значення (також може відображатися як N/A)

Для дій:

• lX означає, що дія має відбутися (також може відображатися як Y, T або 1)
• Порожнє означає, що дія не повинна відбуватися (також може відображатися як – або N, або F, або 0)

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

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

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

Приклад 3

Правила роботи:

• Кредит не надається безробітним
• Кредит надається особам, які мають постійну легальну роботу без обмежень

Вікові правила:

• Особам до 18 років кредит не надається
• Цільовою групою для отримання кредиту є люди 18-40 років
• Для осіб старше 40 років кредит не надається

Правила по доходу:

• Кредит не надається людям з доходом менше 1000 доларів США на місяць
• Кредит надається особам з доходом 1000-5000 USD/місяць, сума кредиту < 2000 USD
• Кредит надається людям з доходом понад 5000 доларів США на місяць, сума кредиту > 2000 доларів США

Спробуйте визначити очікуваний результат для наступних тест кейсів:

• Student, unemployed, 17 years old, income is 100 USD/month
• Post graduate, unemployed, 25 years old, no income
• Retired, unemployed, 60 years old, income is 200 USD/month
• Manager, legally employed, 50 years old, income 1500 USD/month
• Lawyer, legally employed, 45 years old, income 5000 USD/month
• Worker, legally employed, 35 years old, income 950 USD/month
• Accountant, legally employed, 28 years old, income 2500 USD/month
• Sales manager, legally employed, 37 years old, income 4500 USD/month

Тестування переходу стану

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

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

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

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

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

Відомий приклад-ілюстрація для демонстрації переходу станів. В даному випадку для покриття всіх станів знадобиться 2 тест кейси. А для покриття всіх дійсних переходів – 4 тест кейси.

Тестування варіантів використання

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

Кожен варіант використання визначає певну поведінку, яку суб’єкт може виконувати у співпраці з одним або кількома виконавцями (UML 2.5.1 2017). Випадок використання може бути описаний взаємодіями та діями, а також передумовами, постумовами та звичайною мовою, де це доречно. Взаємодія між виконавцями та суб’єктом може призвести до змін стану суб’єкта. Взаємодії можуть бути представлені графічно за допомогою робочих процесів, діаграм діяльності або моделей бізнес-процесів.

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

Приклад UML діаграми та сценарію використання логіну.

В цьому відео поговоримо про функціональне тестування:
00:00:03 Тестування чорної скриньки
00:03:20 Функціональне та нефункціональне тестування
00:05:58 Функціональне тестування
00:13:19 Usability і функціональне тестування
00:19:20 Процес виконання функціонального тестування
00:19:47 Техніка розподілу на класи еквівалентності
00:23:33 Техніка аналізу граничних значень
00:46:50 Техніка тестування таблиці рішень
01:08:35 Тестування переходу стану
01:15:33 Тестування варіантів використання

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

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

Structure-based or White-box

В англомовній літературі терміни structure-based та white-box є синонімами, тому якщо зустрічаєте їх, то мова йде про тестування білої скриньки.

Тестування на основі структури або білої скриньки базується на визначеній структурі програмного забезпечення або системи і включає наступні техніки:

• Тестування операторів, заяв і покриття (Statement testing)
• Тестування рішень і покриття (Decision Tetsing)
• Тестування умов (Condition Testing)
• Тестування множинних умов (Multiple Condition Testing)
• Тестування шляхів та покриття (Path Coverage)

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

Тестування операторів (Statement testing) перевіряє потенційні виконувані оператори в коді.

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

Тестування рішень

Тестування рішень перевіряє рішення в коді та перевіряє код, який виконується на основі результатів рішень. Для цього тестові випадки слідують за потоками керування, які відбуваються з точки прийняття рішення (наприклад, для оператора IF, один для істинного результату та один для помилкового результату; для оператора CASE тестові випадки будуть потрібні для всіх можливих результатів, включаючи результат за замовчуванням).

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

Приклад 1

Нижче наводиться приклад коду і потрібно визначити скільки тестів забезпечить 100% покриття операторів (statements), а скільки відповідно – рішень (decisions).

• Disc = 0 //statement буде зображуватися у вигляді прямокутника
• Order –qty = 0 //statement буде зображуватися у вигляді прямокутника
• Read Order-qty //statement буде зображуватися у вигляді прямокутника
• If Order-qty >= 20 then //condition буде зображуватися у вигляді ромба
• Disc = 0.05 //statement буде зображуватися у вигляді прямокутника
• If Order-qty>=100 then //condition буде зображуватися у вигляді ромба
• Disc = 0.1 //statement буде зображуватися у вигляді прямокутника
• End If //закінчення блоку буде зображуватися у вигляді малого прямокутника
• End If //закінчення блоку буде зображуватися у вигляді малого прямокутника

З прикладу видно, що для покриття операторів знадобиться лише один тест кейс, який слід спроєктувати таким чином, щоб він пройшов в обох випадках по гілках true і таким чином пройшов через усі оператори (statements) в даному прикладі коду. А от для покриття рішень знадобиться 3 тест кейси: 1 тест кейс у в першій умові обере true і в другій умові також true, 2 тест кейс у в першій умові обере true, а в другій умові обере false, 1 тест кейс у в першій умові обере false. Таким чином будуть виконані всі гілки, тобто рішення в даному прикладі.

Приклад 2

Нижче наводиться приклад коду і аналогічно до попереднього прикладу потрібно визначити скільки тестів забезпечить 100% покриття операторів (statements), а скільки відповідно – рішень (decisions).

• Ask: “What type of ticket do you require, single or return?” //statement буде зображуватися у вигляді прямокутника
• If the customer wants ‘return’ //condition буде зображуватися у вигляді ромба
• Ask: “What rate, Standard or Cheap-day”? //statement буде зображуватися у вигляді прямокутника
• If the customer replies ‘Cheap-day’ //condition буде зображуватися у вигляді ромба
• Say: “That will be $11.20” //statement буде зображуватися у вигляді прямокутника
• Else // блок else для найближчого if означає, що гілка false матиме вміст
• Say: “That will be $19.50” //statement буде зображуватися у вигляді прямокутника
• Endif //закінчення блоку буде зображуватися у вигляді малого прямокутника
• Say: ”That will be $9.75” //statement буде зображуватися у вигляді прямокутника
• Endif //закінчення блоку буде зображуватися у вигляді малого прямокутника

З прикладу видно що для покриття операторів і рішень знадобиться однакова кількість тест кейсів, а саме три. Це особливий випадок, оскільки частіше для покриття операторів потрібно менше тест кейсів ніж для покриття рішень. Для того, щою пройти через усі оператори доведеться спроєктувати три тест кейси: 1 тест кейс в першій умові пройде по гілці true і у вкладеній умові обере також true, 2 тест кейс в першій умові пройде по гілці true, а у вкладеній умові обере false, 3 тест кейс в першій умові піде по гілці false. Це забезпечить також і покриття рішень.

Приклад 3

Нижче наводиться приклад коду і знову потрібно визначити скільки тестів забезпечить 100% покриття операторів (statements), а скільки відповідно – рішень (decisions).

• If width>length //condition буде зображуватися у вигляді ромба
• Then biggest_dimension=width //statement буде зображуватися у вигляді прямокутника
• If height>width //condition буде зображуватися у вигляді ромба
• Then biggest_dimension=height //statement буде зображуватися у вигляді прямокутника
• End_if //закінчення блоку буде зображуватися у вигляді малого прямокутника
• Else biggest_dimension=length //statement буде зображуватися у вигляді прямокутника
• If height>length //condition буде зображуватися у вигляді ромба
• Then biggest_dimension=height //statement буде зображуватися у вигляді прямокутника
• End_if //закінчення блоку буде зображуватися у вигляді малого прямокутника
• End_if //закінчення блоку буде зображуватися у вигляді малого прямокутника

В цьому прикладі для покриття операторів знадобиться 2 тест кейси: 1 тест кейс пройде по гілці true у першій умові і далі у вкладеній умові обере також true, 2 тест кейс пройде по гілці false першої умови і далі у вкладеній умові обере true. Таким чином будуть виконані всі оператори statements. А от для покриття рішень знадобиться всього 4 тест кейси, оскільки потрібно покрити гілки false у вкладених умовах.

Цикломатична складність Маккейба

Цикломатична складність Маккейба — це максимальна кількість лінійних незалежних шляхів у програмі. Формула цикломатичної складності:

M = L – N + 2*P

Де L – кількість ребер/ланок у графі, N – кількість вузлів у графі, P – кількість з’єднаних компонентів.

Наведемо приколад розрахунку цього показника за допомогою зразка коду нижче.

• IF A=575 //condition буде зображуватися у вигляді ромба
• THEN IF B>C //condition буде зображуватися у вигляді ромба
• THEN A=B //statement буде зображуватися у вигляді прямокутника
• ELSE A=C //statement буде зображуватися у вигляді прямокутника
• ENDIF //закінчення блоку буде зображуватися у вигляді малого прямокутника
• ENDIF //закінчення блоку буде зображуватися у вигляді малого прямокутника
• Print A //statement буде зображуватися у вигляді прямокутника

Потік керування показує сім вузлів (фігур) і вісім ребер (лінії), таким чином, використовуючи формальну формулу, цикломатична складність становить 8-7 + 2*1=3.

Цінність White Box

Фундаментальна сильна сторона всіх методів білої скриньки полягає в тому, що під час тестування враховується вся реалізація програмного забезпечення, що полегшує виявлення дефектів, навіть якщо специфікація програмного забезпечення розпливчаста, застаріла або неповна. Відповідна слабкість полягає в тому, що якщо програмне забезпечення не реалізує одну або більше вимог, тестування білої скриньки може не виявити дефекти в результаті таких упущень (Watson 1996).

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

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

Коли досягнуто 100% охоплення операторів (statements), це гарантує, що всі виконувані оператори в коді були протестовані принаймні один раз, але це не гарантує, що перевірено всю логіку прийняття рішень. З двох методів білої скриньки, які розглядалися, тестування операторів може забезпечити менше покриття, ніж тестування рішень.

Коли досягнуто 100% покриття рішень, то виконуються всі результати рішення, що включає перевірку справжнього результату, а також хибного результату, навіть якщо немає явного хибного оператора (наприклад, у випадку оператора IF без else в коді).

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

Досягнення 100% покриття рішень гарантує 100% покриття заяв (але не навпаки).

В цьому відео поговоримо про тестування білої скриньки:
00:05 Тестування білої скриньки
10:22 Structure-based or White-box
16:42 Тестування операторів (Statement Testing)
17:28 Тестування рішень (Decision testing)
18:52 Приклад 1 Statement and Decision Testing
26:38 Приклад 2 Statement and Decision Testing
34:51 Приклад 3 Statement and Decision Testing
43:00 Цикломатична складність Маккейба
48:20 Цінність White Box