Тестування методом білої скриньки (White Box Testing)
Тестування методом білої скриньки (white-box testing): Тестування, що ґрунтується на аналізі внутрішньої структури компонента або системи (ISTQB).
Тестування на основі структури (structure-based testing): Динамічний тест, для якого тести є результатом аналізу структури елемента тестування. Примітка. Тестування на основі структури не обмежене використанням на рівні компонентів, а може використовуватися на всіх рівнях, наприклад, при покритті пункту меню, як частини тестування системи. (ГОСТ 56920)
Тестування методом білої скриньки (також: прозорої, відкритої, скляної скриньки; засноване на коді або структурне тестування) - метод тестування ПЗ, який передбачає, що внутрішня структура/пристрій/реалізація системи відома тому, хто її тестує. Ми вибираємо вхідні значення, ґрунтуючись на знанні коду, який їх оброблятиме. Так само ми знаємо, яким має бути результат цієї обробки. Знання всіх особливостей тестованої програми та її реалізації – обов'язкові для цієї техніки. Тестування білої скриньки - поглиблення у внутрішній пристрій системи, поза її зовнішніх інтерфейсів.
Техніка білої скриньки застосовується на різних рівнях тестування - модульному, інтеграційному та системному, але найчастіше застосовується для юніт-тестування цієї ділянки коду самим розробником або SDET. Тестування білої скриньки - це більше, ніж тестування коду: це тестування шляхів . Зазвичай тестовані шляхи знаходяться всередині модуля (модульне тестування). Але ми можемо застосувати цю методику для тестування шляхів між модулями всередині підсистем, між підсистемами всередині систем, і навіть між цілими системами.
Тестування білої скриньки - це покриття вимог у коді :
Code coverage;
Segment coverage: кожен оператор коду виконується один раз;
Branch Coverage or Node Testing: покриття кожної гілки коду з усіх можливих виконано;
Compound Condition Coverage: Для кількох умов перевіряється кожна умова з кількома шляхами та комбінацією різних шляхів для досягнення цієї умови;
Basis Path Testing: кожен незалежний шлях у коді взято на тестування;
Data Flow Testing (DFT): у цьому підході ви відстежуєте конкретні змінні за допомогою кожного можливого обчислення, визначаючи тим самим набір проміжних шляхів через код. DFT має тенденцію відбивати залежності, але переважно це відбувається через послідовності маніпуляцій з даними. Коротше кажучи, кожна змінна даних відстежується та її використання перевіряється. Цей підхід має тенденцію виявляти помилки, такі як змінні, які використовуються, але не ініціалізуються або оголошені, але не використовуються, і т.д. (компілятори/лінтери/IDE вже цілком здатні на це самі);
Path Testing: тестування шляху - це визначення та покриття всіх можливих шляхів проходження через код;
Loop Testing: ці стратегії належать до тестування одиночних циклів, складових (concatenated) циклів та вкладених циклів;
Використовуючи покриття Statement та Branch, ви зазвичай досягаєте 80-90% покриття коду, що є достатнім.
Процес White box testing :
Аналізується реалізацію програми;
У програмі визначаються можливі маршрути;
Вибираються такі вхідні дані, щоб програма виконала вибрані шляхи. Це називається сенсибілізацією шляхів. Наперед визначаються очікувані результати для вхідних даних;
Тести виконуються;
Результати аналізуються;
Переваги White box testing :
тестування може проводитися на ранніх етапах: немає необхідності чекати створення інтерфейсу користувача;
можна провести ретельніше тестування, з покриттям великої кількості шляхів виконання програми;
Недоліки White box testing :
Кількість шляхів, що виконуються, може бути настільки великою, що не вдасться перевірити їх усі. Як правило, спроба протестувати всі шляхи виконання за допомогою тестування білої скриньки так само неможлива, як і тестування всіх комбінацій всіх вхідних даних під час тестування чорної скриньки;
Вибрані тест-кейси можуть не містити дані, які будуть чутливими до помилок. Наприклад: p=q/r; може виконуватися коректно, крім випадку, коли r=0. y=x^2; тест не виявить помилок у випадках, коли x=0, y=0 та x=2, y=4;
Тестування білої шухляди передбачає, що потік управління правильний (або близький до правильного). Оскільки ці тести ґрунтуються на існуючих шляхах, за допомогою не можна
виявити неіснуючі шляхи;
Тестувальник повинен мати навички програмування для того, щоб зрозуміти і
оцінити програмне забезпечення, що тестується;
White box testing потрібно :
Щоб переконатися, що:
Усі незалежні шляхи у модулі були перевірені хоча б один раз;
Усі логічні рішення перевірені з їхньої справжнє і хибне значення;
Усі цикли виконуються на своїх межах та в межах своїх робочих кордонів валідності внутрішніх структур даних;
Щоб виявити такі типи помилок:
Логічна помилка має тенденцію зафарбуватися в нашу роботу, коли ми розробляємо та реалізуємо функції, умови чи елементи управління, які не входять до програми;
Помилки проектування через різницю між логічним потоком програми та фактичною реалізацією;
Типографічні помилки та перевірка синтаксису;
Джерела:
Лі Копланд - "A Practitioner's Guide to Software Test Design", Секція II. Методи тестування білої скриньки
Last updated