Меню

Тестування білої скриньки: повний посібник із методами, прикладами та інструментами

white box testing complete guide with techniques

Спробуйте Наш Інструмент Для Усунення Проблем

Що таке тестування White Box?

Якщо ми йдемо за визначенням, „тестування білого ящика” (також відоме як прозоре, скляне коробкове або структурне тестування) - це метод тестування, який оцінює код та внутрішню структуру програми.

Тестування білого ящика передбачає розгляд структури коду. Коли ви знаєте внутрішню структуру виробу, можна провести тести, щоб переконатися, що внутрішні операції виконуються відповідно до специфікації. І всі внутрішні компоненти були адекватно використані.

Тестування білого ящика на прикладі

Що ви дізнаєтесь:

Мій досвід

Минуло майже десятиліття з того часу, як я займаюся тестуванням програмного забезпечення, і до цього часу помітив, що тестери найбільше захоплені у всій індустрії програмного забезпечення.

Основна причина цього - тестер завжди має чомусь навчитися. Будь то домен, процес або технологія, тестер може отримати повний розвиток, якщо забажає.

Але як кажуть 'Завжди є більш темна сторона' .

Тестери також насправді уникають такого типу тестування, який, на їхню думку, є дуже складним, і шматочок розробника. Так, “Тестування білої скриньки”.

Покриття

Тестування White Box - це висвітлення специфікації в коді:

1. Покриття коду

2. Покриття сегментів: Переконайтеся, що кожен оператор коду виконується один раз.

3. Покриття філій або тестування вузлів: Покриття кожної гілки коду з усього можливого було.

4. Покриття складного стану: Для кількох умов перевірте кожну умову з кількома шляхами та комбінацією різних шляхів, щоб досягти цієї умови.

5. Базове тестування шляху: Кожен незалежний шлях у коді береться для тестування.

6. Тестування потоку даних (DFT): У цьому підході ви відстежуєте конкретні змінні за допомогою кожного можливого розрахунку, таким чином визначаючи набір проміжних шляхів через код. DFT, як правило, відображає залежності, але це в основному через послідовності маніпулювання даними. Коротше кажучи, кожна змінна даних відстежується і її використання перевіряється. Цей підхід має тенденцію виявляти такі помилки, як змінні, що використовуються, але не ініціалізуються, або оголошуються, але не використовуються тощо.

7. Тестування шляху: Тестування шляхів - це місце, де визначено та охоплено всі можливі шляхи через код. Це трудомістке завдання.

8. Петльове тестування: Ці стратегії стосуються тестування окремих циклів, об’єднаних циклів та вкладених циклів. Незалежні та залежні цикли та значення коду перевіряються цим підходом.

Чому ми виконуємо WBT?

Гарантувати:

  • Що всі незалежні шляхи в модулі були здійснені принаймні один раз.
  • Всі логічні рішення перевіряються на їх справжні та хибні значення.
  • Усі цикли виконуються на своїх кордонах і в межах їх операційних меж дійсності внутрішніх структур даних.

Щоб виявити такі типи помилок:

  • Логічні помилки, як правило, потрапляють у нашу роботу, коли ми розробляємо та реалізовуємо функції, умови або елементи керування, які поза програмою
  • Помилки проектування через різницю між логічним потоком програми та фактичною реалізацією
  • Друкарські помилки та перевірка синтаксису

Це тестування вимагає детальних навичок програмування?

Треба писати тестові кейси які забезпечують повне охоплення логіки програми.

Для цього нам потрібно добре знати програму, тобто ми повинні знати специфікацію та код, який перевіряємо. Для цього типу тестування необхідні знання мов програмування та логіки.

Обмеження

Неможливо протестувати кожен шлях циклів у програмі. Це означає, що вичерпне тестування неможливе для великих систем.

Це не означає, що WBT не ефективний. Вибір важливих логічних шляхів та структури даних для тестування практично можливий та ефективний.

Різниця між тестуванням White-Box та Black-Box

Простіше кажучи:

Під час тестування чорної скриньки ми тестуємо програмне забезпечення з точки зору користувача, але в білій скриньці ми бачимо та перевіряємо фактичний код.

У тестуванні Black Box ми проводимо тестування, не бачачи внутрішнього системного коду, але в WBT ми бачимо і тестуємо внутрішній код.

Техніка тестування білої скриньки використовується як розробниками, так і тестувальниками. Це допомагає їм зрозуміти, який рядок коду насправді виконується, а який ні. Це може свідчити про відсутність логіки або друкарську помилку, що врешті-решт може призвести до деяких негативних наслідків.

Рекомендована література => Повне керівництво з тестування Black Box

Етапи виконання WBT

Крок 1 - Зрозумійте функціональність програми через її вихідний код. Це означає, що тестувальник повинен добре володіти мовою програмування та іншими інструментами, а також методами, що використовуються для розробки програмного забезпечення.

Крок No2 - Створіть тести та виконайте їх.

Коли ми обговорюємо концепцію тестування, “ охоплення ”Вважається найважливішим фактором. Тут я поясню, як забезпечити максимальне охоплення з контексту тестування Білої скриньки.

Також читайте=> Графік причин і наслідків - Динамічна техніка написання тестових кейсів для максимального охоплення

Види та методи тестування білої скриньки

Для кожного типу тестування білої скриньки існує кілька типів та різних методів.

Див. Зображення нижче для довідки.

Типи тестування білого ящика

Сьогодні ми зосередимося головним чином на типи тестування на виконання «техніка модульного тестування білих ящиків»

3 основні методи тестування білого ящика:

  1. Покриття заяви
  2. Покриття філії
  3. Покриття шляху

Зверніть увагу, що виписка, гілка чи покриття шляху не ідентифікує жодної помилки чи дефекту, які потрібно виправити. Він ідентифікує лише ті рядки коду, які ніколи не виконуються, або залишаються недоторканими. На основі цього можна зосередитись на подальшому тестуванні.

Давайте розберемося в цих техніках по одному на простому прикладі.

# 1) Покриття заяви:

У мові програмування висловлювання - це не що інше, як рядок коду або інструкція, щоб комп'ютер розумів і діяв відповідно. Оператор стає виконуваним оператором, коли він компілюється і перетворюється в об'єктний код і виконує дію, коли програма перебуває в режимі роботи.

Отже “Покриття заяви” , як випливає з самої назви, це метод перевірки того, що кожен рядок коду виконується хоча б раз.

# 2) Покриття філії:

“Branch” у мові програмування подібний до “тверджень IF”. Заява IF має дві гілки: T рута і Неправда .

Отже, у Покритті філій (також звані Покриття рішень) ми перевіряємо, чи виконується кожна філія хоча б раз.

У випадку “твердження IF”, будуть дві умови тесту:

  • Один, щоб перевірити справжню гілку і,
  • Інше для перевірки помилкової гілки.

Отже, теоретично, Branch Coverage - це метод тестування, який при виконанні забезпечує виконання кожної гілки з кожної точки прийняття рішення.

# 3) Покриття шляху

Покриття шляху перевіряє всі шляхи програми. Це комплексний прийом, який гарантує, що всі шляхи програми пройдені принаймні один раз. Покриття шляху навіть потужніше, ніж покриття філій. Цей прийом корисний для тестування складних програм.

Давайте візьмемо простий приклад, щоб зрозуміти всі ці методи тестування білих коробок.

які фази sdlc?

Також перевірте=> Різні типи тестування

Приклад тестування White Box

Розглянемо наведений нижче простий псевдокод:

INPUT A & B C = A + B IF C>100 PRINT “ITS DONE”

Для Покриття заяви - нам знадобиться лише один тестовий приклад, щоб перевірити всі рядки коду.

Це означає:

Якщо я розгляну TestCase_01 має бути (A = 40 і B = 70), тоді всі рядки коду будуть виконані.

Тепер виникає питання:

  1. Це достатньо?
  2. Що робити, якщо я розглядаю свій тест як A = 33 і B = 45?

Оскільки висвітлення висловлень охоплює лише справжню сторону, для псевдокоду для перевірки НЕ буде достатньо одного тесту. Як випробувач, ми також повинні розглянути негативні випадки.

Отже, для максимального охоплення ми повинні враховувати ' Покриття філії ' , який оцінить умови “FALSE”.

У реальному світі ви можете додати відповідні твердження, коли умова не вдається.

Отже, псевдокод стає:

INPUT A & B C = A + B IF C>100 PRINT “ITS DONE” ELSE PRINT “ITS PENDING”

Оскільки покриття Statement недостатньо для тестування всього псевдокоду, нам буде потрібно покриття Branch для забезпечення максимального покриття .

Тож для охоплення філій нам знадобиться два тестові кейси для завершення тестування цього псевдокоду.

TestCase_01 : A = 33, B = 45

TestCase_02 : A = 25, B = 30

Завдяки цьому ми бачимо, що кожен рядок коду виконується принаймні один раз.

Ось висновки, які виведені до цього часу:

  • Покриття філій забезпечує більше охоплення, ніж висвітлення.
  • Висвітлення філій є більш потужним, ніж висвітлення.
  • 100% охоплення філій саме по собі означає 100% покриття виписки.
  • Але 100% покриття виписки не гарантує 100% покриття філій.

Тепер перейдемо до Покриття шляху:

Як було сказано раніше, Path покриття використовується для тестування складних фрагментів коду, які в основному включають оператори циклу або комбінацію циклів та оператори рішення.

Розглянемо цей псевдокод:

INPUT A & B C = A + B IF C>100 PRINT “ITS DONE” END IF IF A>50 PRINT “ITS PENDING” END IF

Тепер для забезпечення максимального охоплення нам знадобиться 4 тестові кейси.

Як? Просто - є 2 заяви про рішення, тож для кожної заяви про рішення нам потрібно буде дві гілки для тестування. Один за істинний, а другий за хибний стан. Отже, для 2 заяв про прийняття рішень нам знадобиться 2 тестові кейси для перевірки справжньої сторони та 2 тестові кейси для перевірки помилкової сторони, що в цілому складає 4 тестові кейси.

Щоб спростити їх, давайте розглянемо нижче блок-схему псевдокоду:

Покриття шляху 1

Для того, щоб мати повне охоплення, нам потрібні такі тестові приклади:

TestCase_01: A = 50, B = 60

TestCase_02 : A = 55, B = 40

TestCase_03: A = 40, B = 65

TestCase_04: A = 30, B = 30

Отже, пройдений шлях буде таким:

Покриття шляху 2

Червона лінія - TestCase_01 = (A = 50, B = 60)

Синя лінія = TestCase_02 = (A = 55, B = 40)

Помаранчева лінія = TestCase_03 = (A = 40, B = 65)

Зелена лінія = TestCase_04 = (A = 30, B = 30)

******************
= >> Зв'яжіться з нами запропонувати свій список тут
*****************

Інструменти для тестування White Box

Нижче наведено перелік найкращих інструментів для тестування білого ящика.

# 1) Веракода

Веракода

Засоби тестування «білих ящиків» Veracode допоможуть вам швидко та легко визначити та усунути недоліки програмного забезпечення за зниженою вартістю. Він підтримує кілька мов додатків, таких як .NET, C ++, JAVA тощо, а також дозволяє перевірити безпеку настільних, веб- та мобільних додатків. Проте є кілька інших переваг інструменту Veracode. Щоб отримати детальну інформацію про тестові інструменти Veracode White box, перегляньте посилання нижче.

Посилання на веб-сайт: Веракода

# 2) Екклема

Еклемма

Спочатку EclEmma був розроблений для тестових запусків та аналізу в робочому середовищі Eclipse. Вважається, що це безкоштовний інструмент покриття коду Java, який також має кілька функцій. Щоб встановити або дізнатись більше про EclEmma, ​​перегляньте посилання нижче.

Посилання на веб-сайт: Еклемма

# 3) РОЗДІЛ

RCUnit

Фреймворк, який використовується для тестування програм C, відомий як RCUNIT. RCUNIT можна використовувати відповідно до умов ліцензії MIT. Його можна використовувати безкоштовно, а для того, щоб встановити або дізнатись більше про нього, перевірте посилання нижче.

Посилання на веб-сайт: РОЗДІЛ

# 4) cfix

cfix - це одна з платформ модульного тестування для C / C ++, яка спрямована виключно на максимально просту та легку розробку тестових наборів. Тим часом, cfix зазвичай спеціалізується на режимі ядра NT та Win32. Щоб встановити та дізнатись більше про cfix, перегляньте посилання нижче

Посилання на веб-сайт: cfix

# 5) Тест Google

Тест Google

Googletest - це тестова система Google від C ++. Виявлення тестів, тести смерті, параметризовані тести, фатальні та не фатальні збої, генерація звіту про тестування XML тощо - це кілька функцій GoogleTest, але є також кілька інших функцій. Linux, Windows, Symbian, Mac OS X - це кілька платформ, на яких використовувався GoogleTest. ЩобЗавантажте, будь ласка, перевірте посилання нижче.

Посилання для завантаження: Тест Google

# 6) EMMA

Емма

Емма - це простий у використанні безкоштовний інструмент покриття коду JAVA. Він включає кілька функцій та переваг. Щоб завантажити та дізнатись більше про Емму, перевірте посилання нижче.

Посилання для завантаження: EMMA

# 7) NUnit

NUnit

NUnit - це простий у використанні блок тестування з відкритим кодом, який не вимагає жодного втручання вручну для оцінки результатів тесту. Він підтримує всі мови .NET. Він також підтримує керовані даними тести та тести, що виконуються паралельно під NUnit. У попередніх версіях NUnit використовувалася ліцензія NUnit, але NUnit 3 випускався під ліцензією MIT. Але обидві ліцензії дозволяють вільне використання без будь-яких обмежень. Щоб завантажити та дізнатись більше про NUnit, перевірте посилання нижче.

Посилання для завантаження: NUnit

# 8) CppUnit

CppUnit

CppUnit - це модульна система тестування, написана на C ++ і вважається портом JUnit. Тестовий результат для CppUnit може бути у форматі XML або текстовому. Він створює модульні тести зі своїм власним класом і запускає тести в тестових наборах. Він ліцензований згідно LGPL. Щоб завантажити та дізнатись більше про CppUnit, перевірте посилання нижче.

Посилання для завантаження: CppUnit

# 9) JUnit

JUnit

JUnit - це тихий простий модульний модуль тестування, який підтримує автоматизацію тестування на мові програмування Java. Він в основному підтримує розробку, керовану випробуваннями, а також забезпечує звіт про випробування. Він ліцензований під публічною ліцензією Eclipse. Для безкоштовного завантаження та для того, щоб дізнатись більше про JUnit, перевірте посилання нижче.

Посилання для завантаження: JUnit

# 10) JsUnit

JsUnit

JsUnit вважається портом JUnit для javascript. І це фреймворк модульного тестування з відкритим кодом для підтримки сторонніх клієнтів Javascript. Він ліцензований за GNU Public License 2.0, GNU Lesser Public License 2.1 та Mozilla Public License 1.1. Для того, щоб завантажити та дізнатись більше про JsUnit, перевірте посилання нижче.

Посилання для завантаження: JsUnit

Також перевірте всі інструменти, які ми перерахували Аналіз статичного коду тут .

який найкращий додаток vr

Не соромтеся пропонувати більш прості або вдосконалені інструменти, які ви використовуєте для техніки білих коробок.

Висновок

Покладання лише на тестування чорної скриньки недостатньо для максимального охоплення тестом. Нам потрібно мати поєднання методів тестування як чорної, так і білої скриньки покрити максимальні дефекти .

Якщо все зробити правильно, тестування White Box, безумовно, сприятиме підвищенню якості програмного забезпечення. Тестерам також добре брати участь у цьому тестуванні, оскільки це може надати найбільш «неупереджену» думку щодо коду. :)

Повідомте нас, якщо у вас виникнуть запитання щодо методів, про які ми говорили в цій статті.

Рекомендована література

^