Какво е Грей Box Тестване? Техники, пример

Какво е Грей Box Тестване?

Сив Box Тестване (също се пише Грей Box Тестване) е техника за тестване на софтуер, която тества софтуерен продукт или приложение с частично познаване на вътрешната структура на приложението. Целта на Грей Box Тестването е за търсене и идентифициране на дефекти, причинени от неправилна структура на кода или неправилно използване на приложението.

В този процес обикновено се идентифицират специфични за контекста грешки, свързани с уеб системи. Техниката увеличава покритие на теста като се концентрира върху всички слоеве на сложна система, а не върху един от тях.

Сив Box Тестването е метод за тестване на софтуер, който комбинира Бял Box Тестване намлява черно Box ТестванеРазликата между трите се свежда до това каква част от вътрешната структура може да види тестерът:

• В бяло Box Тестването на вътрешната структура (кода) е известно.
• В черно Box Тестването на вътрешната структура (код) е неизвестно.
• В сиво Box Тестването на вътрешната структура (код) е частично известно.

Диаграмата по-долу поставя трите метода в една и съща скала на видимост.

In софтуерно инженерство, Грей Box Тестването дава възможност за тестване на двете страни на приложението, както на презентационния слой, така и на кода зад него. То е полезно предимно в интеграционно тестване намлява изпитване на проникване.

Пример за сиво Box Тестване: Докато тества функция на уебсайт, като например връзки или „осиротели връзки“, ако тестерът срещне проблем с тези връзки, промяната може да бъде направена веднага в HTML кода и проверена в реално време.

Защо сиво Box Тестване

Сив Box Тестването се извършва по следните причини:

• Той предлага комбинираните предимства както на тестване с черна кутия, така и на тестване с бяла кутия.
• Той комбинира приноса на разработчиците, както и на тестерите, и подобрява цялостното качество на продукта.
• Това намалява разходите за дълъг процес на тестване на функционални и нефункционални типове.
• Това дава на разработчика достатъчно свободно време, за да отстрани дефектите.
• Тестването се извършва от гледна точка на потребителя, а не от гледна точка на дизайнера.
• Един неуспех може да бъде обяснен, а не просто докладван, защото тестерът може да види слоя, където е възникнал.

Сив Box Тестване срещу Черно Box срещу Уайт Box Тестване

Трите метода не са толкова конкуриращи се алтернативи, колкото три нива на достъп, и всеки от тях отговаря на различен вид въпрос. Поставянето им един до друг прави избора конкретен.

Повечето отбори използват и трите жизнен цикъл на софтуерно тестване, а слоят „сива кутия“ е мястото, където обикновено се улавят дефектите, които попадат между потребителския интерфейс и хранилището на данни.

Сив Box Стратегия за тестване

Да изпълни Грей Box При тестване не е необходимо тестерът да има достъп до изходния код. Тестът се проектира въз основа на познания за алгоритмите, архитектурите, вътрешните състояния или други описания на поведението на програмата на високо ниво.

Да изпълни Грей Box Тестване:

• Той прилага прости техники за тестване на черна кутия.
• Базира се на генериране на тестове, основани на изисквания, така че предварително задава всички условия, преди програмата да бъде тествана чрез метода на твърдението.

Техники, използвани за сиво Box Тестването е:

• Матрично тестване: Тази техника включва дефиниране на всички променливи, които съществуват в програмата, заедно с риска, който всяка от тях носи, така че неизползваните и високорисковите променливи да са видими.
• Тестване на регресия: проверява дали промяна в предишната версия е повлияла на други аспекти на програмата в новата версия. Това се прави със стратегии като повторно тестване на всички, повторно тестване на рискови случаи на употреба и повторно тестване в рамките на защитна стена.
• Тестване на ортогонален масив или Овесени овсени ядки: осигурява максимално покритие на кода с минимален брой тестови случаи.
• Тестване на шаблони: извършвани върху исторически данни от предишни системни дефекти. За разлика от тестването с черна кутия, Grey Box Тестването анализира кода и определя защо е възникнал неуспехът.

Сив Box методологията обикновено използва автоматизирани инструменти за тестване на софтуер за провеждане на тестването. Създават се „stub“-ове и драйвери за модули, така че тестерът да не се налага да генерира кода ръчно.

Стъпки за изпълнение на Грей 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 Тестване като един слой сред няколко, а не като заместител на останалите, което е и основната идея, изразена в по-широкия набор от... техники за тестване на софтуер намлява видове софтуерно тестванеТой се разполага естествено до функционално тестване и подходи, основани на спецификации, като например тестване, базирано на модел.

Въпроси и Отговори