Техніки тестування білої скриньки (версія 3.1)
Тестування білої скриньки базується на внутрішній структурі об’єкта тестування. Методи тестування білої скриньки можна використовувати на всіх рівнях тестування, але дві методики, пов’язані з кодом, розглянуті в цьому сілабусі, найчастіше використовуються на рівні тестування компонентів. Існують більш просунуті методи, які використовуються в деяких критично важливих для безпеки, критично важливих середовищах або середовищах із високим рівнем цілісності для досягнення більш повного покриття, але вони не рзглядаються.
Техніки тестування білої скриньки (версія 4.0)
Через їхню популярність і простоту цей розділ зосереджується на двох методах тестування білої скриньки, пов’язаних із кодом:
- Перевірка операторів (тверджень, заяв)
- Тестування гілок
Існують більш суворі методи, які використовуються в деяких критично важливих для безпеки, критично важливих середовищах або середовищах з високою цілісністю для досягнення більш повного покриття коду. Існують також методи тестування білої скриньки, які використовуються на вищих рівнях тестування (наприклад, тестування API) або використовують покриття, не пов’язане з кодом (наприклад, покриття нейронів у тестуванні нейронної мережі). Ці техніки не обговорюються в цьому сілабусі.
Тестування операторів і покриття (версія 3.1)
Тестування операторів перевіряє потенційні виконувані оператори в коді. Покриття вимірюється як кількість операторів, виконаних тестами, поділена на загальну кількість виконуваних операторів у тестовому об’єкті, зазвичай виражається у відсотках.
Тестування операторів і покриття (версія 4.0)
У тестуванні операторів елементи покриття є виконуваними операторами. Мета полягає в тому, щоб розробити тестові кейси, які виконують оператори в коді, доки не буде досягнуто прийнятний рівень покриття. Покриття вимірюється як кількість операторів, які виконуються тестовими кейсами, поділена на загальну кількість виконуваних операторів у коді та виражається у відсотках.
Коли досягнуто 100% охоплення операторів, це гарантує, що всі виконувані оператори в коді були виконані принаймні один раз. Зокрема, це означає, що кожен оператор з дефектом буде виконано, що може спричинити збій, що демонструє наявність дефекту. Однак виконання оператора з тестовим випадком не виявить дефекти у всіх випадках. Наприклад, він може не виявити дефекти, які залежать від даних (наприклад, ділення на нуль, яке не виконується лише тоді, коли знаменник встановлений на нуль). Крім того, 100% охоплення операторів не гарантує, що вся логіка прийняття рішень була протестована, оскільки, наприклад, вона може не виконувати всі гілки в коді.
Тестування рішень і покриття (версія 3.1)
Тестування рішень перевіряє рішення в коді та перевіряє код, який виконується на основі результатів рішень. Для цього тестові кейси слідують за потоками керування, які починаються з точки прийняття рішення (наприклад, для оператора IF, один для істинного результату та один для хибного результату; для оператора CASE тестові випадки будуть потрібні для всіх можливі результатів, включаючи результат за замовчуванням).
Покриття вимірюється як кількість результатів рішень, виконаних тестами, поділена на загальну кількість результатів рішень в об’єкті тестування, зазвичай виражається у відсотках.
Тестування гілок і покриття (версія 4.0)
Розгалуження — це передача керування між двома вузлами в графі потоку керування, який показує можливі послідовності, у яких оператори вихідного коду виконуються в тестовому об’єкті. Кожна передача контролю може бути або безумовною (тобто прямолінійним кодом), або умовною (тобто результатом рішення).
У тестуванні розгалужень елементами покриття є розгалуження, а метою є розробка тестових випадків для виконання розгалужень у коді, доки не буде досягнуто прийнятний рівень покриття. Покриття вимірюється як кількість розгалужень, які здійснюються тестовими випадками, поділена на загальну кількість розгалужень і виражається у відсотках.
Коли досягається 100% покриття розгалужень, усі розгалуження в коді, безумовні та умовні, перевіряються тестовими випадками. Умовні розгалуження зазвичай відповідають істинному чи хибному результату рішення «якщо…тоді», результату оператора switch/case або рішення вийти чи продовжити цикл. Однак виконання гілки за допомогою тестового кейсу не виявить дефекти у всіх випадках. Наприклад, він може не виявити дефекти, які потребують виконання певного шляху в коді.
Покриття гілок включає покриття операторів. Це означає, що будь-який набір тестів, який досягає 100% покриття гілок, також досягає 100% покриття операторів (але не навпаки).
Засноване на структурі або білої скриньки (Structure-based or White-box)
Тестування на основі структури або білої скриньки базується на визначеній структурі програмного забезпечення або системи, як показано в наведених нижче прикладах:
- Тестування операторів (заяв) і покриття
- Тестування рішень і покриття
- Інші методи на основі структури: покриття умов
Рівні
Рівень компонента: структура програмного компонента, тобто оператори, рішення, гілки або навіть окремі шляхи.
Рівень інтеграції: структура може бути вільною від виклику (схема, на якій модулі викликають інші модулі).
Системний рівень: структура може бути структурою меню, бізнес-процесом або структурою веб-сторінки.
Покриття операторів вимірюється як кількість операторів, виконаних тестами, поділена на загальну кількість виконуваних операторів у тестовому об’єкті, зазвичай виражається у відсотках.
Тестування рішень створює тестові випадки для виконання конкретних результатів рішень, як правило, щоб збільшити охоплення рішень.
Покриття рішень вимірюється як кількість результатів рішень, виконаних тестами, поділена на загальну кількість результатів рішень в об’єкті тестування, зазвичай виражається у відсотках.
Для кращої візуалізації і знаходження правильних відповідей у тестах варто будувати схеми коду. Для цього можна використовувати наступні позначення.
Цикломатична складність
Цикломатична складність Маккейба — це максимальна кількість лінійних незалежних шляхів у програмі.
Формула цикломатичної складності:
M = L – N + 2*P
Де
- L – кількість ребер/ланок у графі
- N – кількість вузлів у графі
- P – кількість з’єднаних компонентів
Приклад:
Потік керування показує сім вузлів (фігур) і вісім ребер (лінії), таким чином, використовуючи формальну формулу, цикломатична складність становить 8-7 + 2*1=3. У цьому випадку немає виклику графа або підпрограми.
Приклади тестових питань
Яка мінімальна кількість тестів потрібна для 100% покриття операторів та 100% покриття рішень?
Disc = 0
Order –qty = 0
Read Order-qty
If Order-qty >= 20 then
Disc = 0.05
If Order-qty>=100 then
Disc = 0.1
End If
End If
З наведеної схеми видно, що для покриття стейтментів знадобиться один тест кейс, а для покриття рішень – 3 тест кейса.
Яка мінімальна кількість тестів потрібна для 100% покриття операторів та 100% покриття рішень?
If width>length
Then biggest_dimension=width
If height>width
Then biggest_dimension=height
End_if
Else biggest_dimension=length
If height>length
Then biggest_dimension=height
End_if
End_if
З наведеної схеми видно, що для покриття стейтментів знадобиться 2 тест кейса, а для покриття рішень – 4 тест кейса.
Яка мінімальна кількість тестів потрібна для 100% покриття операторів та 100% покриття рішень?
Ask: “What type of ticket do you require, single or return?”
If the customer wants ‘return’
Ask: “What rate, Standard or Cheap-day”?
If the customer replies ‘Cheap-day’
Say: “That will be $11.20”
Else
Say: “That will be $19.50”
Endif
Say: ”That will be $9.75”
Endif
З наведеної схеми видно, що для покриття стейтментів знадобиться 3 тест кейса, а для покриття рішень також – 3 тест кейса. Цей приклад демонструє, що в ряді ситуацій кількість тест кейсів для 100% покриття рішень може збігатися з кількістю тест кейсів для покриття операторів.
Значення тестування операторів і рішень (версія 3.1)
Коли досягнуто 100% покриття операторів, це гарантує, що всі виконувані оператори в коді були протестовані принаймні один раз, але це не гарантує, що перевірено всю логіку прийняття рішень. З двох методів білого ящика, які обговорюються в цьому навчальному плані, тестування тверджень може забезпечити менше охоплення, ніж тестування рішень.
Коли досягнуто 100% покриття рішення, воно виконує всі результати рішення, що включає перевірку істинного результату, а також хибного результату, навіть якщо немає явного хибного оператора (наприклад, у випадку оператора IF без else в коді)). Покриття операторів допомагає знайти дефекти в коді, які не перевірялися іншими тестами. Покриття рішень допомагає знаходити дефекти в коді, де інші тести не приймають ні правдивих, ні хибних результатів.
Досягнення 100% покриття рішень гарантує 100% покриття операторів (але не навпаки).
Значення тестування білої скриньки (версія 4.0)
Фундаментальна сильна сторона всіх методів «білої скриньки» полягає в тому, що під час тестування враховується вся реалізація програмного забезпечення, що полегшує виявлення дефектів, навіть якщо специфікація програмного забезпечення розпливчаста, застаріла або неповна. Відповідна слабкість полягає в тому, що якщо програмне забезпечення не реалізує одну або більше вимог, тестування білого ящика може не виявити отримані дефекти упущення (Watson 1996).
Методи білої скриньки можна використовувати в статичному тестуванні (наприклад, під час пробних прогонів коду). Вони добре підходять для перегляду коду, який ще не готовий до виконання (Hetzel 1988), а також псевдокоду та іншої логіки високого рівня або низхідної логіки, яку можна моделювати за допомогою графа потоку керування.
Виконання лише тестування чорної скриньки не забезпечує вимірювання фактичного покриття коду. Показники покриття білої скриньки забезпечують об’єктивне вимірювання покриття та надають необхідну інформацію, щоб дозволити створити додаткові тести для збільшення цього покриття та згодом підвищити довіру до коду.
В цьому відео починаємо працювати з секцією 4.3.
00:01:16 White-box Test Techniques
00:06:21 Statement Testing and Coverage
00:12:47 Decision Testing and Coverage
00:23:07 Structure-based or White-box
00:20:21 Cyclomatic complexity
00:37:56 Приклади тестів
00:59:14 The Value of Statement and Decision Testing