Що таке сірий Box Тестування? Техніки, приклад
Томас Гамільтон
⚡ Розумний підсумок
сірий Box Тестування досліджує застосунок з частковим знанням його внутрішньої структури, поєднуючи погляд користувача на тестування чорної скриньки з достатнім розумінням архітектури, щоб пояснити, чому стався збій, а не лише те, що він стався.
Що таке сірий Box Тестування?
сірий Box Тестування (також пишеться Сірий Box Тестування) — це метод тестування програмного забезпечення, який перевіряє програмний продукт або застосунок з частковим знанням внутрішньої структури застосунку. Мета Грея Box Тестування полягає в пошуку та виявленні дефектів, спричинених неправильною структурою коду або неправильним використанням програми.
У цьому процесі зазвичай виявляються контекстно-специфічні помилки, пов'язані з веб-системами. Методика збільшує покриття тесту зосереджуючись на всіх рівнях складної системи, а не на одному з них.
сірий Box Тестування – це метод тестування програмного забезпечення, який поєднує білий Box Тестування та Black Box ТестуванняРізниця між цими трьома зводиться до того, яку частину внутрішньої структури може побачити тестер:
- У білому Box Тестування внутрішньої структури (коду) є відомим.
- Чорним Box Тестування внутрішньої структури (коду) невідоме.
- У сірому Box Тестування внутрішньої структури (коду) частково відоме.
На діаграмі нижче ці три методи розміщені на одній шкалі видимості.
In розробка програмного забезпечення, Сірий Box Тестування дає можливість протестувати обидві сторони програми, як рівень представлення, так і код, що стоїть за ним. Воно корисне, перш за все, у інтеграційне тестування та проникнення тестування.
Приклад сірого Box Тестування: Під час тестування функцій веб-сайту, таких як посилання або посилання-сироти, якщо тестер зіткнеться з проблемою з цими посиланнями, зміни можна буде внести негайно в HTML-код і перевірити в режимі реального часу.
Чому сірий Box Тестування
сірий Box Тестування проводиться з таких причин:
- Він забезпечує комбіновані переваги як тестування чорної скриньки, так і тестування білої скриньки.
- Він поєднує внесок розробників та тестувальників і покращує загальну якість продукту.
- Це зменшує накладні витрати на тривалий процес тестування функціональних та нефункціональних типів.
- Це дає розробнику достатньо вільного часу для виправлення недоліків.
- Тестування проводиться з точки зору користувача, а не з точки зору дизайнера.
- Збій можна пояснити, а не просто повідомити про нього, оскільки тестер може бачити шар, де він стався.
сірий Box Тестування проти Блек Box проти Білого Box Тестування
Ці три методи є не стільки конкуруючими альтернативами, скільки трьома рівнями доступу, і кожен відповідає на питання різного типу. Розташування їх поруч робить вибір конкретним.
| Основа | Black Box Тестування | сірий Box Тестування | білий Box Тестування |
|---|---|---|---|
| Знання внутрішньої структури | ніхто | Частковий | Повний |
| Виконано | Тестери та кінцеві користувачі | Тестери та розробники, що працюють з тестувальниками | Розробники та інженери-тести |
| Основи дизайну тестів | Вимоги та специфікації | Archiтекстура, алгоритми, структури даних та інтерфейси | Вихідний код та потік керування |
| Типовий рівень | Системне та приймальне тестування | Інтеграційне, проникненне та веб-сервісне тестування | Тестування блоків та компонентів |
| Покриття вимірюється як | Покриття вимог | Інтерфейс, дані та покриття шляху | Покриття операторів, гілок та шляхів |
| Основне обмеження | Причина невдачі залишається прихованою | Глибина обмежена наданим доступом | Дорого, і може не відповідати відсутнім вимогам |
Більшість команд використовують усі три життєвий цикл тестування ПЗ, а шар сірого прямокутника – це місце, де зазвичай виявляються дефекти, що знаходяться між користувацьким інтерфейсом та сховищем даних.
сірий Box Стратегія тестування
Виконати Грея Box Під час тестування тестувальнику не обов'язково мати доступ до вихідного коду. Тест розробляється на основі знань алгоритмів, архітектур, внутрішніх станів або інших високорівневих описів поведінки програми.
Виконати Грея Box Тестування:
- Він застосовує прості методи тестування чорної скриньки.
- Він базується на генерації тестових випадків на основі вимог, тому всі умови попередньо встановлюються до того, як програма буде протестована методом тверджень.
Методи, що використовуються для сірого Box Тестування проводиться:
- Тестування матриці: Цей метод передбачає визначення всіх змінних, що існують у програмі, разом із ризиком, який несе кожна з них, щоб бути видимими невикористані та високоризикові змінні.
- Регресійне тестування: перевіряє, чи зміни в попередній версії призвели до регресу інших аспектів програми в новій версії. Це робиться за допомогою таких стратегій, як повторне тестування всіх, повторне тестування ризикованих випадків використання та повторне тестування всередині брандмауера.
- Тестування ортогонального масиву або вівсянка: забезпечує максимальне покриття коду з мінімальною кількістю тестових випадків.
- Тестування шаблону: виконано на історичних даних про попередні системні дефекти. На відміну від тестування чорної скриньки, Grey Box Тестування заглиблюється в код і визначає, чому стався збій.
сірий Box методологія зазвичай використовує автоматизовані засоби тестування програмного забезпечення для проведення тестування. Заглушки та драйвери модулів створюються таким чином, щоб тестувальнику не доводилося генерувати код вручну.
Кроки для виконання Грея Box Тестування проводиться:
- Крок 1: Визначте вхідні дані.
- Крок 2: Визначте результати.
- Крок 3: Визначте основні шляхи.
- Крок 4: Визначте підфункції.
- Крок 5: Розробіть вхідні дані для підфункцій.
- Крок 6: Розробка результатів для підфункцій.
- Крок 7: Виконайте тестовий сценарій для підфункцій.
- Крок 8: Перевірте правильність результату для підфункцій.
- Крок 9: Повторіть кроки з 4 по 8 для інших підфункцій.
- Крок 10: Повторіть кроки 7 та 8 для інших підфункцій.
Тестові випадки для Грея Box Тестування може охоплювати, серед іншого, питання графічного інтерфейсу, безпеки, бази даних, браузера та операційної системи. Кожен згенерований випадок все ще потребує звичайного тестовий випадок атрибути, оскільки випадок, який неможливо відтворити за його власним описом, мало корисний під час регресії.
Де Грей Box Використовується тестування
Цей метод знаходить своє місце скрізь, де дефект можна діагностувати лише шляхом одночасного розгляду двох шарів. Найчастіше його застосовують у таких сценаріях:
- Робочі процеси, що базуються на базах даних: Дія виконується через інтерфейс користувача, а отримані рядки потім запитуються безпосередньо для підтвердження того, що значення, типи та зв'язки були збережені належним чином.
- Веб-сервіси та API: запит надсилається, а статус відповіді, заголовки та корисне навантаження перевіряються на відповідність опублікованій конфіденційності.tract, що є повсякденною формою Тестування API.
- Точки інтеграції: Повідомлення, що перетинають межу між двома модулями, перевіряються, при цьому обидва модулі розглядаються як запущені системи, а не як вихідні файли.
- Оцінка безпеки: Тестер на проникнення, маючи звичайний обліковий запис користувача та огляд архітектури, відтворює позицію інсайдера, яка є стандартною моделлю взаємодії «сірого ящика».
- Веб-додатки та графічні інтерфейси: Непрацюючі посилання, сторінки-сиріти, обробка сеансів та перевірка на стороні клієнта перевіряються з частковою видимістю розмітки та потоку запитів.
У всіх цих випадках загальна вартість системних дефектів знижується, оскільки проблеми виявляються та пояснюються, перш ніж вони потрапляють далі по конвеєру в... тестування системи або виробництво.
сірий Box Тестування інструментів
Жоден інструмент не працює сірий Box Тестування саме по собі. Цій категорії потрібна комбінація драйвера інтерфейсу, інструменту перевірки нижнього шару та способу написання скриптів для цих двох елементів разом.
- Клієнти API та веб-сервісів такий як Postman та SoapUI, що використовується для видачі запитів та підтвердження кодів стану та тіл відповідей.
- Клієнти баз даних та інструменти для SQL-запитів, що використовується для перевірки збереженого стану після дії інтерфейсу.
- Інструменти розробника браузерів та HTTP-проксі такий як Burp Suite, що використовується для перевірки та зміни запитів під час сеансів, орієнтованих на безпеку.
- Фреймворки для автоматизації інтерфейсу користувача такий як Selenium, що використовується для керування шаром презентації всередині тестування автоматизації на.
- Інструменти для ведення журналу та моніторингу, що використовується для співвіднесення спостережуваної помилки з тим, що програма зафіксувала внутрішньо на той момент.
Вибір має менше значення, ніж підключення: якщо драйвер інтерфейсу та крок перевірки не виконуються в одному сценарійному потоці, результатом є дві окремі ручні перевірки, а не один тест «сірої коробки».
сірий Box Тестування
Часткова видимість створює проблеми, яких немає в жодному з чистих методів, і ось ті, з якими команди стикаються найчастіше:
- Коли тестований компонент стикається з певним збоєм, він може перервати поточну операцію та залишити решту послідовності невиконаною.
- Тест може виконатися повністю, навіть якщо вміст результату неправильний, тому крок перевірки має перевіряти значення, а не завершення.
- Повне покриття шляху коду неможливо, оскільки тестер ніколи не бачить кожну гілку, до якої досягне тестування білої скриньки.
- Проектна документація, на яку спираються тести, може бути застарілою, а застаріла схема або специфікація інтерфейсу непомітно робить дизайн тесту недійсним.
- Тестувальникам потрібні як розуміння предметної області, так і глибокі технічні знання, що є вужчим профілем навичок для найму.
- Розподілений і сильно напружений пресtracЗмінні архітектури ускладнюють віднесення спостережуваної відмови до певного внутрішнього компонента.
Ці обмеження свідчать на користь ставлення до Грея Box Тестування як один рівень серед кількох, а не як заміна інших, що є головною точкою зору щодо ширшого набору методи тестування програмного забезпечення та види тестування програмного забезпеченняВін природно розташовується поруч функціональне тестування та підходи, що базуються на специфікаціях, такі як тестування на основі моделі.
