Біла скринька – це категорія тестування програмного забезпечення, яка відноситься до методів тестування внутрішньої структури та дизайну програмного забезпечення. Воно контрастує з тестуванням “чорної скриньки”, тобто тестуванням, яке не стосується внутрішніх операцій програмного забезпечення, а натомість тестує лише зовнішні результати роботи програмного забезпечення.
У цій статті ми розглянемо тему тестування білого ящика: що це таке, як воно працює, і які типи інструментів тестування програмного забезпечення можуть допомогти тестувальникам і розробникам проводити тестування білого ящика при тестуванні програмного забезпечення.
Що таке тестування білих скриньок?
Тестування білого ящика – це метод тестування програмного забезпечення, який передбачає тестування внутрішньої структури та дизайну програмного забезпечення, на відміну від зовнішніх результатів або досвіду кінцевого користувача, які тестуються при тестуванні чорного ящика.
Тестування “білого ящика” – це загальний термін, який включає в себе багато різних типів тестування програмного забезпечення, включаючи модульне тестування та інтеграційне тестування. Оскільки тестування білого ящика передбачає тестування коду та програмування, проведення тестування білого ящика зазвичай передбачає певне розуміння комп’ютерного програмування.
Тестування “білого ящика” в інженерії програмного забезпечення може включати тестування коду і внутрішнього дизайну програмного забезпечення для перевірки потоку введення-виведення, а також для перевірки дизайну, зручності використання і безпеки програмного забезпечення.
Тестування “білого ящика” дозволяє тестувальникам перевірити внутрішню роботу системи, одночасно перевіряючи, що вхідні дані призводять до конкретних, очікуваних результатів.
Тестування білого ящика є важливим етапом у тестуванні програмного забезпечення, оскільки це єдиний тип тестування, який враховує, як функціонує сам код.
1. Коли і навіщо потрібен білий ящик
тестування в тестуванні та інженерії програмного забезпечення?
Тестування “білого ящика” можна проводити на різних етапах циклу тестування для перевірки функціонування внутрішнього коду та структури.
Найчастіше тестування “білого ящика” відбувається, коли розробники та тестувальники проводять модульне тестування, а також іноді під час інтеграційного тестування.
За визначенням, модульне тестування вважається різновидом тестування білого ящика, в той час як інтеграційне тестування може мати риси як тестування білого, так і чорного я щика, але зазвичай вважається різновидом тестування чорного ящика.
В іншому випадку, тестування білого ящика також можна використовувати для перевірки внутрішньої роботи програмного забезпечення. Тестування в білому ящику – це найекономічніший спосіб збільшити покриття тестів, якщо в цьому є потреба, а також простий спосіб перевірити, як працюють певні ділянки коду або тестові області збірки програмного забезпечення, які, як підозрюють тестувальники, недостатньо протестовані.
Формальні огляди коду, які проводяться за допомогою тестування “білого ящика”, також можуть бути використані для виявлення недоліків безпеки та інших вразливостей. Аналогічно, якщо елементи коду зламані, тестування білого ящика може допомогти інженерам-програмістам визначити, де знаходиться помилка.
2. Коли не потрібно проводити тестування білого ящика
У більшості випадків, коли інженери-програмісти і тестувальники проводять нову збірку програмного забезпечення через цикл тестування, для перевірки внутрішньої роботи коду необхідна певна кількість тестування в “білому ящику”.
Юніт-тестування – це тип тестування “білого ящика”, який проводиться розробниками для перевірки того, що окремі модулі працюють так, як очікується. Цей ранній тип тестування дозволяє розробникам виявляти помилки та дефекти до того, як відбудеться формальне тестування в середовищі QA.
Після модульного тестування відбувається інтеграційне тестування, системне тестування та тестування прийняття користувачем. Зазвичай вони вважаються формами тестування “чорного ящика”, які зазвичай не включають в себе багато методів тестування “білого ящика”.
Однак у деяких випадках тестувальники та розробники можуть використовувати тестування білого ящика на цих етапах, щоб виявити конкретні дефекти в коді. На цьому етапі, якщо немає жодних ознак того, що з кодом щось не так, і всі тести чорного ящика проходять успішно, багато команд тестувальників можуть вирішити, що немає необхідності проводити подальше тестування білого ящика.
3. Хто бере участь у тестуванні білих скриньок?
Тестування “білого ящика” майже завжди проводять розробники програмного забезпечення та інженери-програмісти. Це пов’язано з тим, що тестування білого ящика вимагає детального знання комп’ютерного коду та методів кодування, а більшості QA-тестерів бракує технічних навичок, необхідних для проведення тестування білого ящика.
Модульне тестування, основний тип тестування білого ящика, завжди виконується в середовищі розробки розробниками. Розробники також можуть проводити тестування “білого ящика”, коли це необхідно, щоб перевірити, як працюють різні елементи коду, або перевірити правильність виправлення помилок.
Переваги тестування “білої скриньки
Тестування білого ящика дозволяє розробникам та інженерам-програмістам перевірити більше аспектів коду, ніж тестування чорного ящика.
У той час як тестування “чорного ящика” може розповісти нам, як функціонує програмна збірка для кінцевих користувачів, “білий ящик” може розповісти нам більше про те, як працює програмний код. Чистий, ефективний код має важливе значення при розробці програмного забезпечення, особливо якщо розробники хочуть повторно використовувати код пізніше або додавати виправлення та оновлення в майбутньому.
1. Максимізація тестового покриття
Тестування в білому ящику може допомогти тестувальникам максимізувати покриття тестів. Тестування якомога більшої кількості програмного коду зазвичай максимізує шанс виявлення будь-яких помилок або помилок, присутніх в коді, і метою тестування білого ящика зазвичай є тестування якомога більшої кількості коду.
З іншого боку, тестування “чорного ящика” – це просто виконання тестових кейсів, які можуть мати або не мати широкого покриття коду.
2. Знайти приховані помилки та баги
Однією з найбільших переваг тестування за допомогою білого ящика є те, що оскільки тестування за допомогою білого ящика перевіряє внутрішню функціональність, це полегшує розробникам пошук помилок і багів, які інакше могли б бути приховані глибоко в коді.
Крім виявлення наявності помилок, при виконанні тестування за допомогою білого ящика зазвичай легше визначити, де саме в коді міститься помилка, оскільки цей тип тестування є дуже специфічним.
3. Простота автоматизації
Автоматизувати тестування білого ящика дуже просто, особливо при проведенні модульного тестування. Юніт-тести зазвичай вимагають, щоб розробники тестували невеликі фрагменти коду окремо, щоб перевірити, чи працюють вони так, як очікувалося. Це дуже легко автоматизувати, що означає, що це швидка та ефективна форма тестування програмного забезпечення.
Це одна з причин, чому модульне тестування виконується перед іншими, більш трудомісткими видами тестування.
4. Ефективність у часі
Тестування в “білому ящику” є ефективним у часі з кількох причин.
Як згадувалося вище, більшість типів тестування білого ящика відносно легко автоматизувати, а це означає, що часто тестування білого ящика відбувається швидше, ніж тестування чорного ящика. Крім того, тестування білого ящика полегшує розробникам пошук помилок, які вони виявляють у коді, оскільки вони знаходять їх під час тестування самого коду.
5. Якість коду
Тестування в білому ящику дозволяє розробникам ще раз поглянути на написаний ними код та оцінити його якість і чистоту.
Проходження коду по частинах дає розробникам можливість видалити непотрібні ділянки коду і очистити код, що полегшує повторне використання і редагування ділянок коду в майбутньому.
Це також може змусити розробників замислитися над тим, як реалізовано код і чи буде він добре масштабуватися в майбутньому.
Виклики тестування “білої скриньки
Тестування за допомогою “білої скриньки” не позбавлене певних труднощів. Є кілька причин, чому деякі команди розробників можуть вважати, що тестування білого ящика складніше проводити, ніж тестування чорного ящика, а також інші причини, чому деякі люди можуть вважати його менш важливим, ніж тестування чорного ящика.
1. Технічні бар’єри
Тестування “білих скриньок” має технічні бар’єри, яких немає при тестуванні “чорних скриньок”. Для проведення тестування білого ящика тестувальникам потрібні знання внутрішньої роботи системи, що в тестуванні програмного забезпечення зазвичай означає знання програмування.
Ось чому тестування білого ящика майже завжди проводиться інженерами та розробниками програмного забезпечення і не проводиться QA-тестерами, які рідко володіють технічними навичками, необхідними для виконання цього типу тестування.
2. Вартість
Тестування “білої скриньки” може бути дорожчим у порівнянні з тестуванням “чорної скриньки” через те, наскільки ретельним є цей тип тестування.
Розробникам доводиться витрачати багато часу на написання інтенсивних модульних тестів, а тести білого ящика часто не можна повторно використовувати для інших додатків, що означає, що тестування білого ящика зазвичай коштує досить дорого.
3. Точність
Тестування білого ящика не завжди є найточнішим методом тестування програмного забезпечення, і якби команди розробників покладалися виключно на тестування білого ящика, це призвело б до великої кількості пропущених помилок і кейсів.
Тестування білого ящика перевіряє лише ті функції, які вже існують, тоді як тестування чорного ящика може використовуватися для тестування частково реалізованих функцій або виявлення функцій, які насправді відсутні в програмному забезпеченні і повинні бути включені в наступні ітерації.
4. Сфера застосування
Тестування “білого ящика” зазвичай не дає нам багато інформації про досвід користувача або кінцевий результат роботи функцій, вбудованих у програмне забезпечення.
Хоча розробники можуть використовувати тестування білого ящика, щоб перевірити, чи працює код належним чином, вони не можуть зробити висновок про те, що робочий код надає правильні результати кінцевим користувачам без поєднання тестування білого ящика з тестуванням чорного ящика.
Це означає, що існують обмеження щодо обсягу тестування білих скриньок і того, як багато воно може розповісти нам про програмне забезпечення.
Характеристики тестів “білого ящика
Тестування “білої скриньки” можна визначити за певними характеристиками, які відрізняють його від інших форм тестування, таких як тестування “чорної скриньки” та “сірої скриньки”.
Більшість з цих характеристик можна розглянути з точки зору того, чим вони відрізняються від характеристик тестування “чорної скриньки” і як це відрізняє тестування “білої скриньки” від тестування “чорної скриньки”.
1. Ремонтопридатність
Тестування в білому ящику призводить до підвищення рівня супроводжуваності вашого коду, спрощуючи роботу, яку ваша команда повинна виконувати в майбутньому.
Оскільки ви постійно стежите за кодом і тим, що він робить з даними, підтримувати його набагато простіше, оскільки ви розумієте, де виникають проблеми і чому вони виникають. Це також спрощує код для майбутніх оновлень, оскільки вам не потрібно розробляти великі і складні патчі для невідомих і простих проблем.
2. Гнучкість
Тестування білого ящика відбувається на коді, який є достатньо гнучким, щоб відносно швидко приймати зміни. Негнучкий код, наприклад, той, що є частиною стороннього модуля або інтеграції, не дозволяє тестувальнику білого ящика вносити швидкі зміни.
Зосередження на коді, який ви можете змінити, як тільки виявите проблему, робить тестування білого ящика дуже адаптивним і означає, що проблеми програми вирішуються набагато швидше.
3. Модульність
Тестування білого ящика процвітає в коді, який має певний ступінь модульності, що означає, що окремі елементи програмного забезпечення чітко відрізняються один від одного.
Якщо в програмі є проблема “спагетті-коду”, в якому кожен аспект прив’язаний до іншого, тестування білого ящика стає нескінченно складнішим, оскільки тестувальник повинен перевіряти всю програму, а не конкретний блок.
4. Інтеграція
Тестування білого ящика надзвичайно корисне для тестування інтеграції. Тестувальники можуть бачити, чи працює функція до того моменту, коли вона залишає програмне забезпечення, і чи повертається вона з інтегрованої системи такою ж функціональною, як очікувалося.
Це дуже інформативно і дозволяє організації дізнатися, чи є проблема локальною або частиною інтегрованої платформи.
Що ми перевіряємо в тестах білого ящика?
Тести білого ящика використовуються для перевірки особливостей коду, які не можуть бути перевірені методами тестування чорного ящика. Це може означати тестування того, як працює сам код, що дозволяє розробникам зрозуміти причини і наслідки різних аспектів коду.
Розробники використовують тестування білого ящика для перевірки дірок у безпеці, операторів і функцій, виходів і шляхів у коді.
1. Внутрішні дірки в безпеці
Тестування “білого ящика” можна використовувати для пошуку прогалин у безпеці та вразливостей у коді, якими хакери та кіберзлочинці можуть скористатися в майбутньому.
Тестування “білого ящика” можна використовувати для перевірки того, чи були дотримані найкращі практики безпеки на етапі розробки, а також для пошуку вразливостей безпеки, які можна усунути до того, як код перейде до подальшого тестування.
2. Шляхи в процесах кодування
Тестування в білому ящику дозволяє розробникам тестувати шляхи, які з’єднують різні елементи коду між собою. Розробники не просто перевіряють логіку коду, вони також можуть звертати увагу на структуру та гігієну коду.
Хороший, чистий код не має зайвих рядків або зламаних елементів, які не працюють так, як очікувалося, навіть якщо зовнішні результати тестування “чорного ящика” відповідають очікуванням.
3. Очікувані результати
Тестування білого ящика також може перевіряти очікувані результати коду так само, як і тестування чорного ящика, хоча тестувальники роблять це, розглядаючи код, а не використовуючи додаток, як тестувальники можуть робити при тестуванні чорного ящика.
Розробники тестують очікувані результати, перевіряючи вхідні дані по черзі і перевіряючи, чи відповідає отриманий результат очікуванням.
4. Оператори, об’єкти та функції
Використовуючи методи тестування білого ящика, розробники програмного забезпечення можуть переконатися, що оператори, об’єкти та функції в коді поводяться логічно і призводять до очікуваних результатів.
5. Функціональність умовних циклів
Тестування білого ящика також можна використовувати для перевірки функціональності умовних циклів, включаючи одиночні, з’єднані та вкладені цикли. Розробники перевірять, чи ефективні ці цикли, чи відповідають вони вимогам умовної логіки, чи правильно обробляють локальні та глобальні змінні.
Проясняю деяку плутанину:
Тестування “білої скриньки” проти “чорної скриньки” та “сірої скриньки
Тестування білого ящика, тестування чорного ящика і тестування сірого ящика – це терміни, які тестувальники програмного забезпечення використовують для позначення різних категорій тестування або різних методів тестування.
Сучасний погляд на ці відмінності тестування полягає в тому, що межі між різними типами тестування стають все більш розмитими, оскільки різні типи тестування часто поєднують елементи тестування білих і чорних скриньок і виводять тести з документів на різних рівнях абстракції.
Тим не менш, між цими формами тестування все ще існують важливі відмінності.
1. Що таке тестування чорних скриньок?
Тестування “чорного ящика” – це форма тестування програмного забезпечення, при якій функціональність програмного забезпечення перевіряється тестувальниками, які не мають знань про внутрішню структуру коду або про те, як реалізувати код на більш технічному рівні.
Тестування “чорного ящика” перевіряє лише зовнішні результати роботи програмного забезпечення, або, іншими словами, те, що відчує кінцевий користувач під час роботи з програмним забезпеченням.
Тестування “чорного ящика” також відоме як поведінкове тестування, оскільки воно перевіряє, як поводиться програмне забезпечення за певних умов.
Тестувальники можуть використовувати тестування “чорної скриньки”, щоб оцінити поведінку різних функцій програмного забезпечення і порівняти їх з очікуваннями, щоб переконатися, що програмне забезпечення відповідає вимогам користувачів. Тестування “чорного ящика” використовується в системному тестуванні та приймальному тестуванні для перевірки різних функцій і перевірки того, що система працює так, як очікується, коли вона працює в цілому.
Під час тестування “чорного ящика” користувачі пишуть тестові кейси для перевірки різних елементів окремо. Оскільки тестування чорного ящика не вимагає таких же технічних навичок, як тестування білого ящика, тестування чорного ящика зазвичай проводиться тестувальниками в середовищі контролю якості, а не розробниками.
Автоматизувати тестування “чорного ящика” зазвичай легше, ніж тестування “білого ящика”, використовуючи наскрізні інструменти автоматизації, такі як ZAPTEST.
У чому різниця між тестування “білої скриньки” та “чорної скриньки”?
Основна відмінність між тестуванням “чорної скриньки” та “білої скриньки” полягає в тому, що саме тестується.
Тестування “чорного ящика” – це тестування зовнішніх виходів програмної збірки, тоді як тестування “білого ящика” – це тестування того, що відбувається під капотом.
Деякі з основних відмінностей між тестуванням “чорної скриньки” та “білої скриньки” полягають у наступному:
Мета
Метою тестування чорного ящика є перевірка того, що система працює так, як очікується для кінцевого користувача, тоді як метою тестування білого ящика є перевірка якості та цілісності коду програмного забезпечення.
Наприклад, тестування чорного ящика для відеогри може побачити, як кінцевий користувач пробує гру і оцінює її, а тестування білого ящика в тому ж проекті гарантує, що введення певних даних призводить до того, що персонаж виконує правильну дію.
Процес
Процеси, що використовуються при тестуванні білих і чорних скриньок, дуже відрізняються. Тестування білого ящика набагато легше автоматизувати, ніж тестування чорного ящика, і, як правило, тестування чорного ящика має бути автоматизовано за допомогою засобів автоматизації програмного забезпечення.
Наприклад, при тестуванні бази даних тест “білого ящика” передбачає автоматизацію введення даних для перевірки правильності всіх результатів, а тест “чорного ящика” передбачає відтворення користувачами ручних процесів і складання звітів про них без використання системи автоматизації.
Тестувальники
Тестування чорного ящика майже завжди проводиться в середовищі контролю якості професійними тестувальниками програмного забезпечення, в той час як тестування білого ящика проводиться розробниками програмного забезпечення та інженерами, які володіють більш детальними технічними знаннями про джерело коду.
Техніки
Тестування “чорного ящика” використовує різні методи, такі як еквівалентне розбиття, аналіз граничних значень і тестування таблиць прийняття рішень. Тестування білого ящика використовує такі методи, як покриття рішень, покриття умов та покриття операторів.
Операції
Методології тестування “чорного ящика” підходять для вищих рівнів тестування, таких як системне тестування та приймальне тестування, тоді як тестування “білого ящика” більше підходить для нижчих рівнів, таких як модульне тестування та інтеграційне тестування.
З цієї причини тестування білого ящика зазвичай проводиться перед більшістю форм тестування чорного ящика.
2. Що таке тестування сірої скриньки?
Тестування сірої скриньки – це метод тестування програмного забезпечення, який використовується для тестування програмних продуктів і додатків тестувальниками, які можуть мати часткові знання про внутрішню структуру програми, але не знати її повністю.
Тестування сірого ящика може поєднувати в собі елементи як чорного, так і білого ящика, що дозволяє розробникам і тестувальникам виявляти дефекти в коді та локалізувати контекстно-залежні помилки.
Тестування “сірого ящика” поєднує в собі особливості тестування “чорного ящика” та тестування “білого ящика”. Тестувальники повинні мати певні знання про внутрішню роботу системи, як і при тестуванні білого ящика, але вони використовують ці знання для створення тестових кейсів і виконання цих тестових кейсів на рівні функціональності, як це відбувається при тестуванні чорного ящика.
Тестування “сірого ящика” пропонує багато переваг тестування “чорного ящика” і “білого ящика”, а також є відносно ефективним за часом і гнучким.
У чому різниця між тестування білої та сірої скриньок?
Оскільки тестування “сірого ящика” пропонує деякі з тих самих функцій, що й тестування “чорного ящика”, між тестуванням “сірого ящика” і тестуванням “білого ящика” існують значні відмінності, хоча, можливо, не такі великі, як у випадку з тестуванням “чорного ящика”.
Деякі з найбільших відмінностей між тестуванням сірої скриньки та тестуванням білої скриньки полягають у наступному:
Структурні знання
При тестуванні “білого ящика” внутрішній дизайн і структура коду повинні бути повністю відомі особі, яка проводить тестування. При тестуванні сірих скриньок внутрішня структура коду зазвичай відома лише частково.
Залучені особи
Тестування білого ящика майже виключно проводять розробники програмного забезпечення та інженери-програмісти, тоді як тестування сірого ящика можуть проводити кінцеві користувачі, тестувальники та розробники.
Ефективність
Тестування білого ящика вважається найбільш трудомістким типом тестування програмного забезпечення, в той час як тестування сірого ящика запозичує деякі переваги тестування чорного ящика, щоб скоротити час, необхідний для виконання тестів.
Операція
При тестуванні білого ящика розробники просто пишуть код для реалізації тестів білого ящика і запускають цей код. При тестуванні сірого ящика, як і при тестуванні чорного ящика, тестувальники виконують функціональні тести, щоб оцінити, як система працює ззовні.
Покриття
Тестування білого ящика є найбільш вичерпним типом тестування, в той час як охоплення сірого ящика може варіюватися в залежності від типу виконуваних тестових кейсів, заснованих на коді або графічному інтерфейсі.
Висновок:
Біла скринька проти чорної скриньки тестування “сірої скриньки” проти тестування “білої скриньки
Тестування білого ящика, тестування чорного ящика та тестування сірого ящика – це терміни, що використовуються для позначення різних методів тестування програмного забезпечення. Загалом, кожен тип тестування може бути визначений на основі того, наскільки тестувальники повинні володіти знаннями про кодову базу та реалізацію коду:
1. Тестування чорної скриньки:
Внутрішня структура коду невідома.
2. Тестування білого ящика:
Внутрішня структура коду відома.
3. Тестування сірого ящика:
Внутрішня структура коду відома частково.
Під час тестування програмного забезпечення всі три типи тестування є важливими для перевірки функціонування та цілісності програмного забезпечення. У той час як тестування білого ящика розповідає нам більше про базову структуру коду, тестування сірого та чорного ящиків дозволяє перевірити, як працює система і чи відповідає вона вимогам кінцевого користувача.
Мабуть, найбільші відмінності між цими трьома типами тестування стосуються того, хто виконує кожен з них, вимог до самого тестування і того, що саме передбачає тестування.
Тестування “білого ящика” має найвищий бар’єр для входу, оскільки його проводять розробники з детальним знанням самої кодової бази, а також тому, що це найбільш трудомісткий і часто дорогий тип тестування.
На відміну від цього, тестування “чорного ящика” є найпростішим у виконанні, і його можуть проводити тестувальники, які не знають базового коду.
Типи тестів білої скриньки
Існує багато різних типів тестів білого ящика, кожен з яких може бути використаний для перевірки дещо різних аспектів внутрішньої структури коду.
Нижче наведено кілька найпоширеніших типів тестування білого ящика, які використовуються сьогодні.
1. Тестування шляху
Тестування траєкторії – це тип тестування білого ящика, заснований на структурі управління програмою. Розробники використовують структуру управління для створення графа потоків управління і тестування різних шляхів на графі.
Шляхове тестування – це тип тестування, який залежить від структури управління програмою, а це означає, що тестувальники повинні добре розуміти цю структуру.
Наприклад, якщо система повинна зв’язуватися з клієнтами з заданими повідомленнями в певних точках воронки продажів, тестування шляхів передбачає забезпечення того, що вона виконує правильні кроки залежно від умов, які задаються наборами даних.
2. Тестування циклу
Тестування циклів – це один з найважливіших видів тестування білого ящика, який перевіряє цикли в коді програми. Цикли реалізуються в алгоритмах всередині коду, а тестування циклів перевіряє, чи є ці цикли коректними.
Тестування циклів дозволяє оцінити, чи існують вразливості в конкретних циклах, і виявити області, де розробникам може знадобитися виправити код, щоб переконатися, що цикл функціонує належним чином.
Прикладом циклічного тесту є проходження через цикл з певним набором даних, які спонукають цикл продовжуватись, наприклад, відмова прийняти деякі умови, до введення цифри, яка конкретно перериває цикл. Якщо цикл поводиться так, як очікується, то тест пройдено успішно.
3. Умовне тестування
Умовне тестування – це тип тестування білого ящика, який перевіряє, чи логічні умови для значень у коді є істинними або хибними.
Умовне тестування – це основна форма тестування “білого ящика”, яка показує розробникам, чи є код логічним і чи відповідає він вимогам логіки програмування.
Прикладом умовного тестування є бухгалтерська платформа. Введення ряду витрат і доходів повинно призвести до правильних підсумків, а програмне забезпечення забезпечить точні результати протягом усього успішного тестування.
4. Модульне тестування
Модульне тестування – це важливий етап тестування програмного забезпечення, на якому розробники тестують окремі компоненти та модулі і перевіряють, чи працюють вони так, як очікувалося, перш ніж інтегрувати різні модулі разом.
Інженери-програмісти використовують методи тестування білої скриньки в модульному тестуванні для тестування невеликих фрагментів коду за один раз. Це дозволяє легко виявляти баги та помилки, коли вони виникають під час тестування.
Прикладом модульного тестування є рання стадія розробки, коли компанія створює просту кнопку на веб-сайті, яка перенаправляє користувача на іншу сторінку. Якщо модуль працює так, як очікується, то це означає, що він має успіх, і розробники вносять зміни до тих пір, поки він не буде працювати належним чином.
5. Тестування мутацій
Мутаційне тестування – це тип тестування, який перевіряє зміни та мутації. Під час мутаційного тестування розробники вносять невеликі зміни до вихідного коду, щоб перевірити, чи може це виявити помилки в коді.
Якщо тест проходить, це означає, що в коді є якась проблема, оскільки він не повинен проходити після внесених змін. В ідеалі при мутаційному тестуванні всі тестові кейси зазнають невдачі.
Прикладом мутаційного тестування є машинне навчання. Програми машинного навчання автоматично “мутують” залежно від нової інформації, тому постійне тестування цих програм на відповідність стандарту “мутації” інформує розробників про те, чи працює програмне забезпечення так, як очікувалося.
6. Інтеграційне тестування
Інтеграційне тестування – це основний етап тестування програмного забезпечення, під час якого тестувальники з’ясовують, чи правильно працюють різні модулі при інтеграції з іншими модулями.
Під час інтеграційного тестування використовуються методи тестування “білого ящика”, щоб перевірити, чи працює код, навіть коли кілька модулів, які часто були написані різними розробниками, працюють разом.
Наприклад, коли база даних отримує інформацію з онлайн-джерела, тестування інтеграції гарантує, що дані, які вона витягує, є точними і оновлюються з достатньо послідовною швидкістю.
7. Тестування на проникнення
Тестування на проникнення – це тип тестування “білого ящика”, який можна використовувати для імітації конкретних кібератак на систему.
Під час тестування на проникнення тестувальникам надається доступ до повних мережевих і системних даних, таких як паролі та мережеві карти. Потім вони намагаються отримати доступ до даних у системі або знищити їх, використовуючи якомога більше різних шляхів атаки.
Тестування на проникнення є важливим аспектом тестування безпеки, яке слід проводити для всіх збірок програмного забезпечення.
Наприклад, HR-платформа пройде тестування на проникнення і шукатиме вразливості в коді, щоб переконатися, що платформа достатньо безпечна для зберігання даних співробітників.
Методи тестування “білої скриньки
Існує багато різних методів тестування “білої скриньки”, які можна використовувати для проведення перерахованих вище тестів “білої скриньки”. Як завжди, для тестування різних аспектів коду найкраще підходять різні методи, але всі методи білого ящика, перелічені нижче, є важливими.
1. Покриття виписки
Однією з визначальних особливостей тестування за допомогою білого ящика є те, що тестувальники повинні намагатися охопити якомога більшу частину вихідного коду при виконанні тестів за допомогою білого ящика.
Покриття коду є важливим показником цього, і покриття операторів є однією з таких технік, яку тестувальники білих скриньок можуть використовувати для збільшення покриття операторів у коді.
Покриття операторів – це метрика, яка вимірює кількість виконаних операторів, поділена на загальну кількість операторів і помножена на 100. Тестувальники білих скриньок повинні прагнути до високого покриття тверджень.
2. Галузеве покриття
Покриття гілок, як і покриття операторів, відображає, наскільки широким є покриття певних елементів коду при тестуванні білого ящика. Гілки еквівалентні логічним операторам “IF”, де код розгалужується на істинні та хибні варіанти, які впливають на результат операції.
Використовуючи методи покриття гілок, тестувальники білого ящика перевіряють, чи кожна гілка обробляється хоча б один раз, і перевіряють, що обидві гілки працюють правильно.
3. Покриття шляху
Методи покриття шляхів оцінюють шляхи в програмному додатку. Максимізація покриття тестових шляхів означає, що всі шляхи в програмі будуть досліджені хоча б один раз. Це схожий тип тестування, як і покриття гілок, але він вважається більш ретельним та ефективним.
Тестування покриття шляхів зазвичай вважається найбільш придатним для тестування повних додатків, а не часткових збірок.
4. Висвітлення рішень
Покриття рішень є одним з найважливіших методів білого ящика, оскільки він надає дані про істинні та хибні результати булевих виразів у вихідному коді.
Тестування покриття рішень перевіряє вихідний код, гарантуючи, що кожен бренд кожного потенційного рішення буде пройдений принаймні один раз під час тестування.
До точок прийняття рішень відносяться будь-які випадки, коли існує можливість двох або більше різних результатів.
5. Покриття умов
Покриття умов також відоме як покриття виразів. Цей метод білого ящика оцінює підзмінні в умовних операторах у коді, щоб перевірити результат виконання кожної логічної умови.
Цей тип тестування розглядає тільки вирази з логічними операндами, тоді як тестування покриття рішень і тестування покриття гілок використовуються для забезпечення інших логічних операцій.
6. Покриття декількох умов
У тестах на множинне покриття умов тестувальники перевіряють різні комбінації умов і оцінюють рішення, які код приймає для кожної комбінації.
Для тестів на множинне покриття умов може бути багато різних тестових кейсів через величезну кількість існуючих комбінацій умов, тому цей тип тестування часто є дуже трудомістким.
7. Покриття скінченного автомата
Покриття скінченних автоматів є важливим типом тестування, але також одним з найскладніших способів досягти високого покриття коду в тестуванні білих скриньок. Він впливає на функціональність проекту і вимагає від розробників підрахунку кількості відвідувань або переходів через стан в процесі тестування, а також кількості послідовностей, які містить кожна система скінченних станів.
8. Тестування потоку управління
Тестування потоку управління – це метод тестування “білого ящика”, який має на меті встановити порядок виконання програми за допомогою простої структури управління.
Розробники створюють тестові кейси для тестування потоку управління, обираючи певну ділянку програми та будуючи шлях тестування. Тестування потоку управління зазвичай використовується в модульному тестуванні.
Життєвий цикл тестування “білої скриньки
у розробці програмного забезпечення
Тестування білого ящика є важливим етапом життєвого циклу розробки програмного забезпечення, хоча воно не має чіткого “місця” в циклі.
Розробники можуть проводити тестування білого ящика, коли їм потрібно перевірити роботу коду, і деякі розробники можуть більш ретельно, ніж інші, перевіряти щойно написаний код, щоб переконатися, що він чистий і не містить зайвих рядків.
Однак тестування білого ящика найчастіше проводиться під час модульного та інтеграційного тестування. Як модульне, так і інтеграційне тестування виконується розробниками на етапі розробки.
Вони відбуваються до початку функціонального тестування, такого як системне тестування та приймальне тестування, і дають розробникам можливість виявити, локалізувати та виправити основні помилки на ранній стадії тестування, перш ніж передати продукт команді QA.
Ручні чи автоматизовані тести білого ящика?
Як і інші види тестування програмного забезпечення, тестування білого ящика можна автоматизувати. Воно може бути як ручним, так і автоматизованим, хоча в більшості випадків автоматизувати тестування білого ящика легше, ніж автоматизувати тестування чорного ящика.
Оскільки тестування білого ящика є дуже трудомістким видом тестування, автоматизація стає все більш популярною серед команд розробників.
Ручне тестування “білого ящика”: переваги, виклики та процеси
Ручне тестування “білого ящика” означає виконання тестів “білого ящика” вручну, і воно вимагає від розробників навичок і часу для написання окремих тестових кейсів, щоб перевірити кожен рядок коду в програмній збірці, наскільки це можливо. Це може зайняти багато часу, але це також дає змогу отримати найретельніші результати тестування та висновки.
Деякі з переваг виконання тестування білого ящика вручну включають в себе наступні:
1. Глибина
Ручне тестування дозволяє тестувальникам досліджувати програмний код глибше, ніж автоматизоване тестування, якщо вони цього бажають, наприклад, читаючи весь вихідний код програми, а не просто автоматизуючи завдання, які стосуються поверхневої функціональності.
2. Місцезнаходження помилки
Ручне тестування полегшує пошук помилок і дефектів, оскільки розробники повинні мати можливість точно визначити, в якому саме рядку коду присутня помилка.
Наприклад, якщо ви бачите, що зображення не завантажується, то перевірка коду на наявність рядків, які пов’язані із завантаженням зображень, значно звужує коло шуканих причин.
3. Швидкість
Ручне тестування зазвичай займає більше часу, ніж автоматизоване, але якщо розробники хочуть провести лише один або два швидких тести, швидше за все, буде швидше виконати їх вручну, ніж налаштувати автоматизацію.
Наприклад, юніт-тестування полягає в тому, щоб подивитися на функцію і перевірити, чи працює вона, а не збирати величезні обсяги даних за допомогою автоматизації процесу. Однак у ручного тестування білих скриньок є й недоліки.
Деякі з проблем ручного тестування білих скриньок включають в себе наступні:
1. Точність
Ручне тестування може дозволити розробникам охопити широкий спектр коду, але люди-тестери завжди більш схильні до помилок, ніж комп’ютерні програми, а це означає, що ручне тестування часто вважається менш точним, ніж автоматизоване.
2. Час
Ручне тестування займає більше часу, ніж автоматизоване, а ручне тестування білого ящика – одне з найбільш трудомістких тестувань. Це збільшує час виконання замовлення і може ускладнити дотримання стислих термінів розробки.
3. Вартість
Через велику кількість робочої сили та ресурсів, задіяних у ручному тестуванні білого ящика, це часто обходиться командам розробників дорожче, ніж автоматизоване тестування, яке зазвичай вимагає меншої кількості розробників і менше часу.
4. Масштабованість
Ручне тестування насправді підходить лише для тестування невеликих додатків або окремих компонентів великих додатків. Для великих додатків, таких як хмарна база даних з тисячами вхідних даних на хвилину, автоматизоване тестування є кращим методом імітації стандартних навантажень.
Автоматизоване тестування білих скриньок: переваги,
виклики та процеси
Технології автоматизації з кожним днем спрощують автоматизацію різних аспектів тестування програмного забезпечення. Рух галузі до гіперавтоматизації частково зумовлений ефективністю та економією коштів, які автоматизація пропонує командам розробників, що завжди відчувають себе обмеженими в часі.
Білий ящик – це один з найбільш підходящих типів тестування для автоматизації, оскільки його відносно легко автоматизувати, а економія часу і коштів за рахунок автоматизації тестування в білому ящику може бути значною.
Автоматизоване тестування за допомогою білого ящика може передбачати самостійне написання розробниками тестових скриптів, або ж процес можна прискорити за допомогою повнофункціональних інструментів, таких як ZAPTEST, які надають найсучаснішу технологію наскрізного тестування програмного забезпечення.
Деякі з переваг автоматизації тестування білих скриньок включають в себе наступні:
1. Точність
Комп’ютерне тестування виключає ризик помилок, оскільки комп’ютери не втомлюються і не роблять помилок.
2. Час
Автоматизоване тестування білого ящика значно швидше, ніж ручне, і звільняє час, який розробники можуть витратити на інші завдання, такі як виправлення помилок або написання патчів для оновлень.
3. Масштаб
Автоматизоване тестування масштабується набагато краще, ніж ручне, тому якщо ваш програмний додаток зростає або якщо ви хочете провести масштабне тестування за один раз, автоматизація є кращим варіантом.
Наприклад, масштабування введення даних передбачає запит більшої кількості вхідних даних при автоматизації, порівняно з наймом більшої кількості співробітників для ручного тестування.
4. Вартість
Вартість автоматизованого тестування зазвичай є нижчою, ніж вартість ручного тестування, через кількість робочих годин, заощаджених завдяки автоматизації. 10-кратна рентабельність інвестицій ZAPTEST демонструє, як автоматизація може заощадити гроші розробників і призвести до збільшення прибутку. Однак автоматизація не позбавлена недоліків.
Деякі з проблем автоматизації тестування “білого ящика” включають в себе наступні:
1. Відстеження помилок
Автоматизація не завжди полегшує пошук помилок у коді, залежно від того, як розробники автоматизують тести або які інструменти тестування використовують, особливо якщо порівнювати з ручним тестуванням у білому ящику, де тестувальники можуть бачити код, який виконується, коли виникає помилка.
2. Навички
Не всі розробники знають, як автоматизувати тести або як користуватися автоматизованими інструментами тестування, тому перехід на автоматизацію може вимагати певних інвестицій у навчання основним навичкам, таким як кодування мовою конкретної платформи тестування та використання навичок аналізу даних, щоб зрозуміти причину проблем у тесті “білого ящика”.
Висновок: Ручне тестування білого ящика
або автоматизація тестування білих скриньок?
Загалом, тестування білих скриньок в інженерії програмного забезпечення є одним з найбільш придатних типів тестування для адаптації до автоматизованого тестування, здебільшого через трудомісткий і складний характер ручного тестування білих скриньок.
Автоматизоване тестування білого ящика швидше, дешевше, ефективніше і точніше, ніж ручне тестування, особливо при роботі з великими додатками.
Де це можливо, розробники програмного забезпечення повинні автоматизувати тестування білого ящика при тестуванні програмного забезпечення, щоб підвищити надійність тестів і охопити тестуванням більшу область великих додатків, ніж це практично можливо при виконанні тестів вручну. Це пов’язано зі значними витратами та досвідом, необхідними при проведенні тестів “білого ящика” виключно ручними методами.
Що потрібно для початку
тестування “білих скриньок”?
Перш ніж розпочати тестування білого ящика, переконайтеся, що у вас є все необхідне для початку. Залежно від того, чи виконуєте ви ручне або автоматизоване тестування за допомогою білого ящика, вам не потрібно багато ресурсів, окрім часу та грошей.
Однак вам потрібно переконатися, що ваша команда має відповідні знання та інструменти для належного проведення тестування за допомогою білого ящика.
1. Розуміння вихідного коду
Тестування “білого ящика” – це тестування, яке проводять розробники та інженери програмного забезпечення з повним робочим знанням вихідного коду та внутрішньої структури програмного забезпечення.
Якщо ви QA тестувальник без цих знань, вам доведеться передати програмне забезпечення комусь іншому, перш ніж розпочати тестування білого ящика.
2. Тестові кейси
Перед виконанням тестування білого ящика необхідно написати тестові кейси. Тестові кейси – це окремі набори інструкцій, що описують дії, які тестувальники або розробники можуть виконувати для перевірки функцій і роботи системи.
У тестуванні білого ящика тестові кейси розробляються людьми з повним знанням внутрішньої структури системи і створюються для того, щоб перевірити, чи працює вона так, як повинна.
3. Інструменти тестування “білого ящика
Існує безліч інструментів для тестування в білому ящику, які підтримують доступ до вихідного коду та проектної документації, а також автоматизацію тестування. Вони також доступні за різними ціновими категоріями для користувачів, наприклад, версії ZAPTEST FREE та ZAPTEST ENTERPRISE, що забезпечують більшу гнучкість.
Виберіть інструменти, які ви хочете використовувати перед початком тестування, приділяючи особливу увагу тому, щоб вони мали належну функціональність, таку як кросплатформеність і технологія комп’ютерного зору, щоб ви бачили те, що бачать автоматизовані тести.
Переконайтеся, що всі розробники та інженери, які беруть участь у тестуванні, знають, як і коли їх використовувати.
Процес тестування білої скриньки
Тестування білого ящика передбачає набагато більше знань про роботу системи, ніж тестування чорного ящика, і деякі етапи тестування білого ящика дещо відрізняються.
Тестувальники білих скриньок повинні спочатку визначити функції або компоненти системи, які вони хочуть перевірити, перш ніж планувати можливі шляхи тестування і писати тестові кейси для виконання.
Процес тестування “білої скриньки” може також відрізнятися залежно від того, який метод тестування ви використовуєте. Виконайте наведені нижче кроки, щоб дізнатися, як проводити тестування білого ящика, максимізуючи при цьому покриття шляхів.
Крок 1: Визначте функції, які потрібно протестувати
Перш ніж проводити тестування “білого ящика”, продумайте, що саме ви хочете перевірити і як ви збираєтеся це робити. Зазвичай це передбачає зосередження на невеликому наборі функцій або можливостей і створення набору тестових кейсів лише для їх тестування.
Ви будете виконувати цей крок знову і знову для різних областей системи, щоб максимізувати покриття тестом, але важливо розбивати різні області на окремі тести.
Чим вужчим буде ваш фокус, тим надійнішими і точнішими будуть ваші тести.
Крок 2: Побудуйте всі можливі шляхи на блок-схемі
Значна частина вашої роботи з підготовки до тестування білого ящика – це побудова всіх можливих шляхів, які вам потрібно протестувати, на блок-схемі.
Цей крок допоможе вам максимізувати покриття шляхів і переконатися, що ви перевіряєте всі можливі шляхи в кожному тестовому випадку, який ви створюєте. Намалюйте блок-схему, яка охоплює всі можливі шляхи для кожної функції або компонента, які ви тестуєте, наприклад, окресливши різні шляхи, які виникають при введенні різних значень.
Крок 3: Визначте всі можливі шляхи
Подивіться на свою блок-схему і визначте всі можливі шляхи, якими можуть пройти користувачі, починаючи з першого кроку вашої блок-схеми і закінчуючи останнім кроком.
Чим більше гілок і рішень представлено на вашій блок-схемі, тим більше буде унікальних шляхів. Розуміння того, скільки існує унікальних можливих шляхів, допоможе вам переконатися, що ваші тестові кейси охоплюють кожну можливість.
Крок 4: Створіть тестові кейси
Наступним етапом тестування білого ящика є написання тестових кейсів, які перевіряють всі шляхи, які ви визначили вище.
Важливо переконатися, що ваші тестові кейси охоплюють всі можливі шляхи і чітко окреслюють дії, які тестувальники або розробники повинні виконати для виконання кожного тестового кейсу.
Для кожного тесту додайте ідентифікатор та назву тесту, а також короткий опис та очікувані результати кожного тесту.
Крок 5: Виконайте тестові кейси
Тепер настав час виконати тестові кейси, тобто те, що більшість людей вважає проведенням самого тестування білого ящика.
Тестувальники виконують тестові кейси, дотримуючись короткого набору інструкцій, викладених у кожному тестовому кейсі, і звітують про результати кожного тестового кейсу. Це можна порівняти з очікуваними результатами, викладеними в тестовому кейсі, щоб визначити, чи пройшов кожен тест білої скриньки успішно, чи ні.
Крок 6: Повторіть цикл за необхідності
Як і інші форми тестування програмного забезпечення, тестування білого ящика полягає в порівнянні того, як система фактично функціонує, з очікуваннями тестувальників щодо того, як система повинна працювати.
Якщо тестувальники виявляють, що система поводиться не так, як вони очікують, це може означати, що тестування білого ящика не вдалося, і розробники повинні виправити рядки коду, перш ніж проводити подальше тестування.
Повторіть описаний вище процес для подальшого тестування білого ящика, поки система не буде ретельно протестована і всі помилки не будуть виправлені.
Найкращі практики для тестування білих скриньок
Найкращі практики тестування за допомогою білого ящика залежать від того, який тип тестування ви проводите і на якому етапі процесу тестування ви перебуваєте.
Оскільки більша частина тестування білого ящика відбувається під час модульного та інтеграційного тестування, більшість найкращих практик тестування білого ящика застосовуються саме до цих етапів.
1. Максимізація тестового покриття
За визначенням, при проведенні тестування “білого ящика” важливо максимізувати покриття тестів, щоб гарантувати, що великий відсоток програмного забезпечення буде протестовано на цьому етапі.
Ви можете зробити це, максимізувавши покриття шляхів і гілок та написавши тестові кейси, які досліджують всі можливі шляхи і результати на етапі підготовки.
2. Перевірити поведінку та продуктивність
Коли ви пишете тестові кейси при тестуванні білого ящика, ви хочете створити тестові кейси, які перевіряють, що система функціонує так, як ви очікуєте, а також тестові кейси, які перевіряють продуктивність системи.
Наприклад, крім перевірки того, що певні дії призводять до певних результатів, ви також можете перевірити, як швидко система може виконувати певні завдання або як на продуктивність впливають різні змінні.
3. Пишіть тестові кейси незалежно один від одного
Якщо ви хочете перевірити дві різні функції, наприклад, якщо клас коду залежить від певної бази даних, створіть абстрактний інтерфейс, який відображає це з’єднання з базою даних, і реалізуйте інтерфейс з фіктивним об’єктом для перевірки цього з’єднання.
Це гарантує, що ваші тестові кейси перевіряють саме ті з’єднання, які ви хочете, щоб вони перевіряли, а не щось інше.
4. Покрийте всі шляхи та петлі
Максимізація тестового покриття означає покриття всіх можливих шляхів, враховуючи умовні цикли та інші типи циклів у коді.
Переконайтеся, що ви створюєте тестові кейси, які повністю досліджують можливі шляхи і перевіряють, що цикли поводяться так, як ви очікуєте, незалежно від вхідних даних.
7 Помилок і підводних каменів, коли
Впровадження тестів “білої скриньки
Коли ви починаєте тестування білого ящика, важливо знати про деякі найпоширеніші пастки, в які розробники часто потрапляють при проведенні тестування білого ящика. Поширені помилки тестування білого ящика можуть спричинити затримки та неточності, які можуть зашкодити якості та графіку випуску програмного забезпечення.
1. Думка про те, що тестування “білих скриньок” не є необхідним
Деякі тестувальники вважають, що тестування білого ящика не є необхідним, оскільки тестування чорного ящика перевіряє всі зовнішні виходи програмного забезпечення, і якщо вони працюють правильно, то можна припустити, що внутрішня робота системи також працює.
Однак тестування білого ящика може допомогти розробникам виявити проблеми та помилки, які не завжди виявляються при тестуванні чорного ящика, а це дуже важливо для перевірки безпеки програмних систем.
Наприклад, якщо програма має витік пам’яті, який спричиняє погіршення продуктивності протягом тривалого періоду часу, що не можна виявити за допомогою тестування чорного ящика, тестування білого ящика є єдиним варіантом для того, щоб розібратися в коді і знайти проблему перед широким публічним випуском.
2. Виконання всіх тестувань білого ящика вручну
Деякі розробники можуть подумати, що проводити тестування білого ящика так само легко, як і тестування чорного ящика.
Однак тестування за допомогою білого ящика займає значно більше часу, і розробники, які намагаються провести тестування за допомогою білого ящика повністю вручну, можуть зіткнутися з тим, що неможливо виконати ручні перевірки відповідно до бажаних стандартів або з максимальним тестовим покриттям.
3. Виділення тестувальників для виконання тестових кейсів
Тестування “білого ящика” повинно повністю проводитися розробниками, інженерами-програмістами та людьми, які повністю розуміють внутрішню роботу програмної системи.
Деякі розробники думають, що вони можуть передати тестування білих скриньок QA-тестувальникам, якщо вони самі написали тестові кейси, але це призведе лише до поганого виконання і зниження якості документації.
4. Поспішати з тестуванням
Тестування програмного забезпечення – це довгий і трудомісткий процес, і у деяких розробників може виникнути спокуса поспішити з тестуванням білого ящика, щоб перейти до наступного етапу розробки. Важливо виділити достатньо часу і ресурсів на тестування білого ящика, щоб розробники не відчували поспіху і мали достатньо часу для максимального тестового покриття.
5. Погана документація
Ведення належної документації до, під час і після тестування гарантує, що всі, хто бере участь у розробці та тестуванні програмного забезпечення, матимуть доступ до потрібної інформації в потрібний час.
Переконайтеся, що кожен член команди розробників знає, як писати чітку документацію і як звітувати про результати тестування білого ящика.
6. Неправильне використання інструментів автоматизації
Інструменти автоматизації можуть полегшити проведення тестування білого ящика, але важливо переконатися, що вся ваша команда розуміє, які інструменти автоматизації ви використовуєте і як ними користуватися.
Різні інструменти підходять для різних типів тестування, тому важливо вибрати інструменти автоматизації, які підходять для тестування за допомогою білого ящика, і навчитися правильно використовувати їхні функції.
Наприклад, деякі інструменти не інтегрують автоматизацію, а натомість зосереджуються на зборі інформації та організації тікетів, що далеко не ідеально для автоматизованого тестування. Навпаки, повностекові інструменти, такі як ZAPTEST, охоплюють весь процес тестування завдяки таким функціям, як автоматизація будь-яких завдань, що робить їх придатними для більш ефективної роботи з тестування в білому ящику.
7. Відсутність співпраці з командою QA
Те, що тестування білих скриньок планується і виконується розробниками, не означає, що команда QA не повинна брати в ньому участі.
Важливо передати результати тестування білого ящика команді QA, щоб вони розуміли, що було протестовано до цього часу і як результати тестування білого ящика можуть вплинути на те, як команда QA підходить до тестування чорного ящика.
Не залучаючи команду QA, ви створюєте потенційний розрив між різними відділами, що призводить до поганої комунікації та гіршого зворотного зв’язку на пізніших етапах тестування. Кінцевим результатом цього є значно нижчий рівень якості кінцевого продукту.
Типи результатів тестів “білого ящика
Коли ви проводите тестування програмного забезпечення білого ящика, ви отримаєте різні результати залежно від результатів проведених вами тестів. Розуміння цих результатів тестів “білого ящика” може допомогти вам зрозуміти, які кроки робити далі.
1. Результати тестування
Результати ваших тестів білого ящика покажуть вам, чи потрібно продовжувати подальше тестування, чи є дефекти, які потрібно виправити, і чи пройшов кожен окремий тестовий кейс успішно чи ні. Ретельна документація необхідна, оскільки вона допомагає розробникам і тестувальникам зрозуміти результати тестування білого ящика.
2. Дефекти
Дефекти можуть бути виявлені під час тестування білого ящика, і іноді результатом ваших тестів білого ящика будуть дефекти та помилки.
Якщо програмна система поводиться не так, як ви очікуєте під час тестування білого ящика, це може означати, що в програмі є серйозні дефекти, які необхідно виправити, перш ніж продовжувати розробку і тестування.
3. Звіти про випробування
Тестові звіти – це звіти, складені розробниками та тестувальниками під час та після тестування програмного забезпечення.
Вони містять детальну інформацію про результати тестування, включаючи те, які тестові кейси пройшли, а які ні, будь-які дефекти, виявлені під час тестування, а також рекомендації щодо наступних кроків.
Розробники використовують тестові звіти для спілкування з іншими розробниками, завданням яких може бути виправлення помилок, знайдених під час тестування.
Приклади тестів білої скриньки
Тестування “білого ящика” дозволяє розробникам перевірити, що внутрішня структура програмної системи працює належним чином, незалежно від зовнішніх результатів і виходів системи.
Наведені нижче приклади ілюструють, як тестування білого ящика може допомогти розробникам перевірити внутрішні функції програмного забезпечення.
1. Приклад сторінки реєстрації електронної комерції
Один з прикладів тестування білої скриньки показує, як розробники тестують функції веб-сайтів. Якщо ви намагаєтеся протестувати сторінку реєстрації на веб-сайті електронної комерції, тестування білого ящика може дозволити розробникам зрозуміти, чи працюють функції та класи, задіяні в реєстрації, так, як вони повинні працювати, коли виконується функція реєстрації.
Це, зокрема, включає всю інформацію, яку вводить користувач, і оцінює параметри, що стоять за формою, включаючи дати, які є дійсними і недійсними, а також те, що форма сприймає як легітимну адресу електронної пошти.
Потім команда вводить ряд рядків, які тестують форму, причому деякі з них розраховані на невдачу, а інші – на успіх, перш ніж оцінити результати в порівнянні з прогнозованими результатами.
З іншого боку, тестування “чорного ящика” перевіряє лише те, чи працює сама сторінка, без будь-якого подальшого аналізу того, чому і як.
2. Приклад калькулятора
Калькулятори додатків є ще одним прикладом тестування білої скриньки.
Якщо ви створюєте калькулятор, який буде використовуватися як частина програми, тестери чорних скриньок просто перевірять, чи правильно виводяться результати при використанні калькулятора за призначенням.
Тестувальники “білих скриньок” перевіряють внутрішні обчислення калькулятора, щоб перевірити, як було розраховано результат і чи він правильний. Це більш корисно для більш складних розрахунків з декількома етапами, наприклад, податків. Тестувальники вивчають код, щоб побачити кроки, які виконує калькулятор, і порядок цих кроків, перш ніж побачити результат після кожного етапу.
Якщо на вході калькулятора (7*4) – 6, а на виході 22, то це правильно, і тестування чорної скриньки пройде успішно. Але це тому, що 7*4 = 28, а 28 – 6 дорівнює 22. Тестування білого ящика може виявити, що програма знайшла цей результат, виконавши 7*4 = 32 і 32 – 6 = 22, що не є правильним.
Таке більш глибоке розуміння показує, що розрахунок є точним після кожного конкретного етапу, знаходить етап, на якому він може бути неточним, і вирішує цю проблему швидше, оскільки тестувальник може чітко бачити, де саме відбувається помилка.
Типи помилок і багів у тестуванні білого ящика
Під час тестування “білого ящика” можна виявити та локалізувати помилки, які можуть вплинути на роботу систем під капотом. Ці помилки можуть впливати на зовнішні функції, а також на продуктивність або надійність.
Деякі з найпоширеніших типів помилок і багів, які виникають під час тестування за допомогою білого ящика, перераховані нижче.
1. Логічні помилки
Логічні помилки виникають при тестуванні білого ящика, оскільки тести білого ящика показують області, де програма не функціонує логічно, або де функції та умови неправильно використовуються в програмному коді.
Логічні помилки можуть проявлятися у вигляді збоїв системи або просто призводити до неочікуваної поведінки та результатів.
2. Помилки проектування
Тестування білого ящика може допомогти розробникам виявити помилки в коді. Помилки проектування виникають, коли є різниця між логічним потоком програмного забезпечення та його фактичною реалізацією. Вони можуть призвести до неочікуваної поведінки та помилок у роботі.
3. Друкарські помилки
Друкарські та синтаксичні помилки – це помилки, які виникають через людський фактор, наприклад, через те, що розробник неправильно надрукував певну фразу або додав неправильну пунктуацію до рядка коду. Такі невеликі помилки можуть призвести до непрацюючих функцій та операторів, які програма не зможе прочитати, що може спричинити серйозні помилки в системі.
Загальні показники тестування білих скриньок
Коли ви проводите тестування білого ящика, загальні метрики тестування можуть допомогти вам оцінити, наскільки успішним і повним є ваше тестування білого ящика, а також зрозуміти якість роботи ваших розробників.
Показники тестування інформують про процес розробки, оскільки вони можуть виявити області для вдосконалення або спрямувати процес тестування вперед.
1. Покриття коду
Однією з основних характеристик тестування білого ящика є те, що воно повинно охоплювати якомога більшу частину коду, і ви можете виміряти, скільки коду ви охопили, за допомогою метрик покриття коду.
Метрики покриття коду показують, яку частину всього коду програми ви перевірили за допомогою тестування білого ящика. Як правило, розробники прагнуть охопити тестуванням білого ящика якомога ближче до 100% програмного коду, наскільки це можливо.
Покриття коду можна розділити на окремі метрики, включаючи покриття шляхів, сегментів, операторів та гілок.
Покриття складених умов – це ще один тип метрики покриття коду, який перевіряє, що кожна умова в наборі була перевірена разом з декількома шляхами та комбінаціями шляхів.
2. Метрики дефектів
Метрики дефектів відображають, скільки дефектів було знайдено, наскільки добре ваше тестування білого ящика виявляє дефекти, і який відсоток коду проходить або не проходить тестування білого ящика.
Метрика дефектів може бути представлена як кількість дефектів на тисячу рядків коду або як загальна кількість дефектів у програмі. Незважаючи на те, що низька кількість дефектів може здатися позитивним моментом, розробники повинні переконатися, що це не є наслідком того, що дефекти пропускаються при тестуванні.
3. Виконання тесту
Показники виконання тестів можуть допомогти розробникам швидко побачити, яку частку від загальної кількості тестів було виконано і скільки залишилося невиконаних тестів. Метрики виконання тексту допомагають командам розробників зрозуміти, на якому етапі знаходиться тестування білого ящика і чи працюють автоматизовані програмні тести так, як очікувалося.
Однак можливі як хибнопозитивні, так і хибнонегативні результати, що може вплинути на точність цієї метрики.
4. Тривалість тесту
Показники тривалості тесту показують, скільки часу потрібно для запуску автоматизованих тестів, що особливо важливо при тестуванні “білих скриньок”, оскільки автоматизація необхідна для максимізації ефективності тесту і тестового покриття.
Тривалість тестування часто є вузьким місцем в гнучкій розробці програмного забезпечення, тому розуміння того, скільки часу займає тестування програмного забезпечення, може допомогти командам розробників прискорити процес розробки.
Однак важливо пам’ятати, що показники тривалості тесту нічого не говорять про якість тестів, які ви запускаєте.
Інструменти тестування “білої скриньки
Інструменти та технології можуть зробити тестування “білих скриньок” значно точнішим, ефективнішим та комплекснішим. Інструменти тестування “білого ящика” можуть допомогти інженерам-програмістам автоматизувати тестування “білого ящика”, записувати і документувати процес тестування “білого ящика”, а також керувати тестуванням “білого ящика” від початку до кінця.
5 найкращих безкоштовних інструментів для тестування білих скриньок
Якщо ви поки що не хочете інвестувати в дорогі інструменти тестування білих скриньок, ви можете спробувати цілу низку безкоштовних інструментів тестування білих скриньок в Інтернеті, не сплачуючи нічого.
Безкоштовні інструменти тестування не завжди пропонують всю ту ж функціональність, що і корпоративні інструменти, але вони є хорошою відправною точкою для початківців у тестуванні білого ящика і можуть допомогти командам розробників краще зрозуміти, які інструменти і технології їм потрібні.
1. ZAPTEST безкоштовна версія
ZAPTEST – це інструмент для тестування програмного забезпечення та роботизоване програмне забезпечення для автоматизації процесів, яке дозволяє розробникам і QA-тестерам автоматизувати тестування як білого, так і чорного ящика.
Безкоштовна версія ZAPTEST дозволяє використовувати декілька віртуальних користувачів, кілька ітерацій та підтримку форуму користувачів. Додаток працює як з локальними, так і з зовнішніми джерелами даних та інтегрується з HP ALM, Rally та JIRA. Користувачі, яким подобається безкоштовна пропозиція ZAPTEST і які хочуть дізнатися більше про те, що пропонує компанія, можуть також запитати про оновлення до корпоративної версії, коли вона буде готова.
2. Багзілла.
Bugzilla – це дуже популярний інструмент тестування програмного забезпечення з відкритим вихідним кодом, який дозволяє розробникам відстежувати помилки і дефекти в програмному забезпеченні та керувати життєвим циклом помилок.
Bugzilla дозволяє легко призначати баги розробникам, визначати пріоритети та перевіряти їх, а також закривати їх після виправлення. Bugzilla – це чудовий інструмент для команд, які все ще намагаються стандартизувати свій підхід до звітування про помилки, і він абсолютно безкоштовний у використанні.
3. OpenGrok
OpenGrok – це браузер з відкритим вихідним кодом і пошукова система по кодовій базі. Він сумісний з кодом, написаним на Java C++, JavaScript, Python та інших мовах програмування.
Якщо ви хочете мати можливість швидко орієнтуватися у великій кодовій базі під час тестування білого ящика, OpenGrok є абсолютно безкоштовним і простим у використанні.
4. SQLmap
SQLmap – ще один інструмент з відкритим вихідним кодом, який вважається майже необхідним для тестування білого ящика. SQLmap регулює процес експлуатації та виявлення багів SQL-ін’єкцій.
Самоописаний “інструмент тестування на проникнення”, SQLmap може допомогти тестувальникам “білих скриньок” виявити і локалізувати помилки безпеки у вихідному коді і виправити їх, перш ніж рухатися далі.
5. Емма.
Emma – це інструментарій з відкритим вихідним кодом, який може виміряти покриття вашого коду, якщо ви працюєте на Java. Це надзвичайно швидкий спосіб швидко визначити покриття коду і відстежити, скільки коду покрив кожен член команди розробників індивідуально.
Emma підтримує покриття класів, методів, рядків та базових блоків і повністю базується на Java.
5 найкращих інструментів тестування білих скриньок для підприємств
Якщо ви шукаєте інструменти з більшою функціональністю або кращою підтримкою, корпоративні інструменти для тестування білих скриньок можуть краще підійти вашій команді розробників.
1. Видання ZAPTEST ENTERPRISE
Корпоративна версія ZAPTEST – це розширена версія безкоштовного ZAPTEST. У цій версії користувачі можуть використовувати необмежену кількість шаблонів OCR, необмежену кількість ітерацій і необмежену кількість сценаріїв VBScript і JavaScript.
Корпоративна версія ZAPTEST пропонує більш повний набір інструментів для команд розробників, які бажають перейти на автоматизацію, а також включає в себе експертну підтримку, щоб переконатися, що ваша команда отримує максимальну віддачу від автоматизації тестування програмного забезпечення та технології RPA від ZAPTEST.
2. Скрипаль
Fiddler – це набір інструментів від Telerik, створений для тестування веб-додатків у “білому ящику”. Fiddler може реєструвати весь HTTP-трафік між вашою системою та інтернетом і оцінювати встановлені точки зупинки, а також коригувати вихідні та вхідні дані. Він доступний у різних форматах, залежно від вашого бюджету та вимог, тож майже для будь-якої команди знайдеться видання Fiddler.
3. HP Fortify
HP Fortify, раніше відомий як Fortify, є ще одним інструментом тестування безпеки, який пропонує комплексні рішення для тестування білих скриньок. Набір інструментів Fortify включає в себе інструмент аналізу вихідного коду Fortify Source Code Analysis, який автоматично сканує ваш вихідний код на наявність вразливостей, які можуть зробити вашу програму вразливою до кібератак.
4. Блок ABAP
Корпоративна версія ABAP Unit дозволяє розробникам програмного забезпечення швидко і просто проводити як ручне, так і автоматизоване модульне тестування. Розробники пишуть модульні тести всередині ABAP-додатків і використовують їх для перевірки функцій коду та виявлення помилок в рамках модульного тестування.
Команди розробників, які хочуть спробувати цей інструмент, можуть почати з безкоштовної версії ABAP Unit, перш ніж перейти на корпоративну версію.
5. LDRA
LDRA – це власний набір інструментів, який можна використовувати для покриття операторів, покриття гілок і покриття рішень при проведенні тестування в білому ящику. Це чудовий інструмент, якщо ви хочете перевірити, чи відповідає ваш вихідний код стандартним вимогам щодо відповідності, трасування та гігієни коду.
Коли варто використовувати enterprise
проти безкоштовних інструментів тестування “білої скриньки”?
Інструменти тестування як корпоративного, так і безкоштовного програмного забезпечення мають своє місце в будь-якій сучасній команді розробників програмного забезпечення. У міру того, як ваша команда зростає, а автоматизоване тестування стає все більш важливим для вашого підходу до тестування білих скриньок, ви, ймовірно, захочете перейти від роботи з безкоштовними інструментами тестування до роботи з корпоративними інструментами, які пропонують більше функціональних можливостей і необмежену кількість застосувань.
Однак існують специфічні сценарії, в яких безкоштовні інструменти можуть бути більш придатними, ніж корпоративні.
Багато розробників вирішують почати з безкоштовних інструментів, коли вони експериментують з новими функціями і технологіями, в першу чергу, щоб оцінити, чи підходять ці технології для їхньої команди, перш ніж інвестувати в корпоративні технології.
Ви також можете спробувати безкоштовні версії корпоративних інструментів, таких як ZAPTEST, щоб спробувати їх перед покупкою і дізнатися більше про те, що пропонують корпоративні інструменти.
Нарешті, деякі безкоштовні інструменти, такі як Emma та Bugzilla, спеціалізуються на нішевих, але важливих функціях, які пропонують постійні переваги навіть командам розробників, які готові платити за корпоративні технології.
Тестування “білого ящика”: контрольний список, поради та підказки
Коли ви будете готові до тестування білого ящика, переконайтеся, що у вас є все необхідне, перш ніж почати. Нижче наведено список речей, про які слід пам’ятати перед початком тестування білого ящика, щоб максимізувати покриття тесту і підвищити точність результатів тестування білого ящика.
1. Використовуйте інструменти автоматизації
Інструменти автоматизації можуть значно прискорити процес проведення тестування “білого ящика”, а також знизити рівень помилок і підвищити загальну точність.
Майже всі команди розробників сьогодні використовують певний рівень автоматизації для проведення тестування білого ящика, тому експерименти з різними інструментами і технологіями автоматизації перед початком тестування білого ящика можуть допомогти вам вибрати інструменти, які ви хочете використовувати ще до початку тестування.
2. Прагніть до 100% тестового покриття
Ви, ймовірно, не досягнете своєї мети – 100% тестового покриття, але при виконанні тестування за допомогою білого ящика найкраще прагнути максимально наблизитися до цієї цифри.
Використовуйте інструменти тестового покриття для відстеження та вимірювання окремих метрик, таких як покриття шляхів та гілок, і переконайтеся, що всі найважливіші шляхи та гілки у вашому програмному забезпеченні були охоплені під час тестування в білому ящику.
3. Створюйте чіткі тестові звіти
Як і у випадку з іншими формами тестування програмного забезпечення, переконайтеся, що ваша команда знає, як складати точні та зрозумілі тестові звіти після кожного етапу тестування.
Звіт про тестування повинен бути написаний у зручному для сприйняття форматі і містити деталі підходу до тестування, а також підсумок результатів і результатів кожного виконаного тестового кейсу. Фінальний звіт має обґрунтувати вжиті заходи та надати рекомендації щодо наступних кроків.
4. Вимірюйте свій успіх за допомогою метрик тестування
Метрики тестування допомагають командам розробників відстежувати і фіксувати хід тестування “білого ящика” і надають цінну інформацію, яка може бути використана в майбутніх процесах розробки.
Важливо, щоб розробники використовували метрики, щоб зрозуміти, наскільки ефективним є тестування, яке вони проводять, і наскільки чистим був їхній початковий код, щоб вони могли покращити свою роботу в майбутньому.
Тестування білої скриньки:
Висновок
Тестування “білого ящика” в інженерії програмного забезпечення – це важливий вид тестування програмного забезпечення, який перевіряє внутрішню структуру і логіку вихідного коду програмного додатку.
У поєднанні з тестуванням чорної скриньки, тестування білої скриньки перевіряє не лише те, що програмне забезпечення працює як очікувалося, але й те, що внутрішній код є логічним, чистим і повним.
Тестування “білого ящика” найчастіше проводиться в модульному та інтеграційному тестуванні, і воно завжди проводиться розробниками та інженерами програмного забезпечення з повним знанням внутрішнього коду програмного забезпечення.
Хоча деякі види тестування “білих скриньок” можна проводити вручну, сьогодні багато тестів “білих скриньок” автоматизовано завдяки підвищенню швидкості, ефективності та охоплення, які пропонує автоматизація тестування “білих скриньок”.
Поширені запитання та ресурси
Якщо ви хочете дізнатися більше про тестування білих скриньок, є багато безкоштовних онлайн-ресурсів, з якими ви можете ознайомитися. Ви можете використовувати відео, книги та інші ресурси, щоб навчитися проводити тестування білого ящика і переконатися, що ваші стандарти тестування білого ящика відповідають найкращим практикам.
1. Найкращі курси з автоматизації тестування за допомогою білого ящика
Якщо ви хочете дізнатися більше про автоматизацію тестування білих скриньок, ви можете пройти курс з тестування програмного забезпечення та тестування білих скриньок. Деякі з цих курсів є акредитованими і пропонують формальну кваліфікацію, в той час як інші є неформальними онлайн-курсами, призначеними для допомоги розробникам і тестувальникам програмного забезпечення, які хочуть покращити свої знання з певної теми.
Деякі з найкращих курсів тестування білих скриньок, доступних сьогодні в Інтернеті, включають в себе наступні:
2. Які п’ять найкращих запитань на співбесіді з автоматизації тестування білих скриньок?
Якщо ви готуєтеся до співбесіди, де вам доведеться обговорювати тестування “білих ящиків”, методи “білих ящиків” та інструменти автоматизації, важливо, щоб ви знали про це.
- У чому різниця між тестуванням “білої скриньки” і тестуванням “чорної скриньки”?
- Чому тестування білих скриньок є важливим?
- Які існують різні підходи до тестування білих скриньок?
- Які процеси задіяні в тестуванні “білих скриньок” і як ми можемо їх покращити?
- Які інструменти та технології ви можете використовувати, щоб зробити тестування білих скриньок швидшим і точнішим?
3. Найкращі навчальні відео на YouTube про тестування білих скриньок
Якщо ви хочете дізнатися більше про тестування за допомогою білого ящика, перегляньте навчальні відео на YouTube, щоб зрозуміти, як працює тестування за допомогою білого ящика, і побачити наочні пояснення процесів і підходів, що використовуються в тестуванні за допомогою білого ящика.
Деякі з найбільш інформативних онлайн-уроків на YouTube зараз включають в себе:
- Udacity: Приклад тестування білої скриньки
- Guru99: Що таке тестування “білого ящика”?
- Тестування “білої скриньки” та “чорної скриньки
- Методи тестування “білої скриньки
- Ментор з тестування програмного забезпечення: Що таке тестування в білому ящику?
4. Як підтримувати тести білого ящика
Обслуговування тестування програмного забезпечення гарантує, що тести, які ви проводите, будуть ретельними і відповідатимуть поставленим цілям. Важливо підтримувати всі типи тестування програмного забезпечення як в чорному, так і в білому ящику, тому що код, над яким ви виконуєте тести, постійно змінюється з кожним виправленням помилок та ітерацією. Це означає, що ваші тестові скрипти повинні змінюватися разом з ним.
Підтримка тестів “білого ящика” передбачає постійне оновлення вашої системи автоматизації тестування та впровадження процесів, призначених для забезпечення регулярного оновлення тестів і тестових кейсів.
Ви можете зробити це за допомогою:
Вбудовуйте технічне обслуговування в дизайн вашого тесту:
Враховуючи майбутнє тестування білого ящика, коли ви вперше створюєте і розробляєте тести білого ящика, вам буде легше підтримувати тести в майбутньому.
Забезпечити чітку комунікацію між командами:
Переконайтеся, що всі члени вашої команди розробників мають кілька каналів зв’язку, щоб після внесення змін до коду їх можна було швидко відобразити в тестах.
Пристосовуйся:
Іноді ви можете вносити зміни в код, які не планували. Переконайтеся, що ваша команда знає, як швидко адаптуватися до цих змін, і має навички відстеження цих змін у тестуванні.
Постійно переоцінюйте протоколи тестування:
Протоколи тестування, які ви впровадили на початку тестування, можуть виявитися непридатними після того, як ваше програмне забезпечення зазнало різних змін і вдосконалень. Регулярно переглядайте свої протоколи тестування, щоб переконатися, що вони все ще підходять.
5. Найкращі книги про тестування білих скриньок
Тестування “білих скриньок” – це глибока тема, на опанування якої можуть піти роки. Якщо ви хочете стати експертом у сучасному тестуванні білих скриньок у тестуванні програмного забезпечення, ви можете прочитати книги про тестування білих скриньок, написані розробниками, науковцями та інженерами.
Деякі з найкращих книг про тестування білих скриньок та автоматизацію тестування на сьогоднішній день включають в себе:
- Мистецтво тестування програмного забезпечення, третє видання Гленфорд Дж. Майерс, Корі Сендлер, Том Баджетт, Тодд М. Томас
- Тестування програмного забезпечення: Ремісничий підхід, четверте видання, Пол К. Йоргенсен (Paul C. Jorgensen)
- Як зламати програмне забезпечення: Практичний посібник з тестування від Джеймса Віттейкера
- Автоматизація тестування програмного забезпечення “Just Enough” Дена Мослі та Брюса Поузі
Ви зможете знайти ці книги в деяких книгарнях і бібліотеках, а також в Інтернеті. Ви також можете знайти інші матеріали для читання та навчальні ресурси у списках літератури хороших курсів і програм з тестування програмного забезпечення.
