Тестування методом чорної скриньки (Black Box Testing)

Тестування методом чорної скриньки (black box testing): Тестування, функціональне чи нефункціональне, без знання внутрішньої структури компонента чи системи (ISTQB).

Тестування на основі специфікації (specification-based testing): Тестування, основним базисом якого є зовнішні введення та висновки елемента тестування, зазвичай на основі специфікації, а не її реалізація у вихідному коді або програмному забезпеченні. (ГОСТ 56920)

Інші назви: Behavioral Testing, Specification-Based Testing, Input-Output Testing, непрозора скринька (opaque-box), закрита скринька (closed-box), тестування на основі специфікації (specification-based testing) або тестування віч-на-віч (eye -to-eye testing).

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

Functional Testing : цей тип стосується функціональних вимог або специфікацій програми (functional requirements or specifications). Тут різні дії чи функції системи тестуються шляхом надання вхідних даних та порівняння фактичного виходу з очікуваним виходом. Наприклад, коли ми тестуємо список, що розкривається, ми натискаємо на нього і перевіряємо, що він розкривається і всі очікувані значення відображаються. Ось кілька основних типів функціонального тестування:

  • Smoke Testing;

  • Sanity Testing;

  • Integration Testing;

  • System Testing;

  • Regression Testing;

  • User Acceptance Testing;

Non-Functional Testing : Крім функціональності вимог, є кілька нефункціональних аспектів, які необхідно протестувати, щоб покращити якість та продуктивність програми. Декілька основних типів нефункціонального тестування включають:

  • Usability Testing;

  • Load Testing;

  • Performance Testing;

  • Compatibility Testing;

  • Stress Testing;

  • Scalability Testing;

Переваги Black box testing :

  • Тестувальнику не обов'язково мати технічний досвід. Важливо проводити тестування, опиняючись дома користувача і думаючи з його погляду;

  • Тестування можна розпочинати після завершення розробки проекту/додатку. І тестувальники, і розробники працюють незалежно, не заважаючи одне одному;

  • Це більш ефективно для великих та складних додатків;

  • Дефекти та невідповідності можна виявити на ранній стадії тестування;

Недоліки Black box testing :

  • Без будь-яких технічних чи програмних знань є можливість пропустити можливі умови тестованого сценарію;

  • В обумовлений час є можливість протестувати не всі вхідні та вихідні значення;

  • Повний Test Coverage неможливий для великих та складних проектів;

Парадигми тестування методом чорної скриньки (Paradigms of Black Box Software Testing)

Парадигма створює основний напрямок мислення - вона дає розуміння та напрямок для подальших досліджень або роботи. Парадигма тестування визначатиме типи тестів, які (для людини, яка працює в рамках цієї парадигми) є актуальними та цікавими. Список парадигм:

  • Domain driven

    • Ключові ідеї:

      • «Спробуйте діапазони та варіанти»;

      • "Поділіть світ на класи";

    • Основне питання чи мета:

      • Стратегія стратифікованої вибірки. Розділіть великий простір можливих тестів на підмножини. Виберіть найкращих представників з кожного набору;

    • Приклади кейсів:

      • Аналіз еквівалентності простого числового поля;

      • Тестування сумісності принтерів;

    • Сильні сторони:

      • Знаходження помилок із найбільшою ймовірністю за допомогою відносно невеликого набору тестів;

      • Інтуїтивно зрозумілий підхід добре узагальнює;

    • Сліпі зони:

      • Помилки, що виходять за межі, або у очевидних особливих випадках;

      • Крім того, фактичні домени часто залишаються невідомими;

  • Stress driven

    • Ключові ідеї:

      • «Сокруш продукт»;

      • «Проведи його через відмови;

    • Основне питання чи мета:

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

    • Приклади кейсів:

      • Великі обсяги даних, підключення пристроїв; довгі ланцюжки транзакцій;

      • Умови нестачі пам'яті, збої пристроїв, віруси та інші проблеми;

    • Сильні сторони:

      • Виявлення слабких місць, зокрема. дірок у безпеці;

    • Сліпі зони:

      • Слабкості, які стають помітнішими через стресу;

  • Спеціалізація driven

    • Ключові ідеї:

      • «Перевіряйте кожну вимогу»;

    • Основне питання чи мета:

      • Перевіряйте відповідність (conformance) продукту кожній заяві у кожній специфікації, документі з вимогами тощо;

    • Приклади кейсів:

      • Матриця простежуваності, що відстежує тестові випадки, пов'язані з кожним елементом специфікації;

    • Сильні сторони:

      • Критичний захист від гарантійних претензій, звинувачень у шахрайстві; втрати довіри з боку клієнтів;

    • Сліпі зони:

      • Будь-які проблеми, не зазначені у специфікаціях або погано вирішені у специфікаціях;

  • Risk driven

    • Ключові ідеї:

      • "Спочатку знайди найбільші помилки";

    • Основне питання чи мета:

      • Розставте пріоритети під час тестування з погляду відносного ризику різних областей чи проблем, які ми могли б перевірити;

    • Приклади кейсів:

      • Переформульований аналіз класів еквівалентності;

      • Тестуйте у порядку частоти використання;

      • Стрес-тести, тести на обробку помилок, тести безпеки, тести для пошуку прогнозованих чи передбачуваних помилок;

      • Зразок зі списку передбачених помилок;

    • Сильні сторони:

      • Оптимальна пріоритезація (за умови, що ми правильно ідентифікуємо та розставляємо за пріоритетами ризики);

      • Тести високої потужності;

    • Сліпі зони:

      • Ризики, які не були ідентифіковані або які напрочуд вірогідніші;

  • Random / статистичне тестування

    • Ключові ідеї:

      • "Об'ємне тестування з новими кейсами";

    • Основне питання чи мета:

      • Нехай комп'ютер створює, виконує та оцінює величезну кількість тестів;

    • Приклади кейсів:

      • Валідація функції або підсистеми (наприклад, тестування еквівалентності) на основі оракулів (Oracle-driven);

      • Стохастичне (перехід між станами) тестування виявлення конкретних збоїв (асерти, витоку тощо. буд.);

      • Оцінка статистичної надійності;

      • Частковий або евристичний оракул знайти деякі типи помилок без загальної перевірки;

    • Сильні сторони:

      • Регресія не залежить кожного разу від одного й того самого старого тесту;

      • Часткові оракули можуть швидко і дешево знаходити помилки у молодому коді;

      • Менше можливість пропустити невидимі ззовні внутрішні оптимізації;

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

    • Сліпі зони:

      • Потрібно вміти відрізняти pass від failure. Занадто багато людей думають: "Not crash = not fail";

      • Крім того, ці методи часто охоплюють багато типів ризиків, але затемнюють необхідність інших тестів, які не піддаються автоматизації;

  • Function Testing

    • Ключові ідеї:

      • «Модульне тестування чорної скриньки»;

    • Основне питання чи мета:

      • Ретельно перевіряйте кожну функцію по черзі;

    • Приклади кейсів:

      • Таблиця, тестуйте кожен елемент окремо;

      • База даних тестуйте кожен звіт окремо;

    • Сильні сторони:

      • Ретельний аналіз кожного протестованого елемента;

    • Сліпі зони:

      • Упускає взаємодії, пропускає дослідження переваг пропоновані програмою;

  • Regression Testing

    • Ключові ідеї:

      • "Повторити тестування після змін";

    • Основне питання чи мета:

      • Керуйте ризиками, пов'язаними з тим, що (а) виправлення помилки не усуває помилку або (б) виправлення (або інша зміна) мало побічний ефект (side effect);

    • Приклади кейсів:

      • Регресія помилок; регресія старих виправлень; загальна функціональна регресія;

      • Набори автоматизованої регресії графічного інтерфейсу;

    • Сильні сторони:

      • Обнадіює, зміцнює довіру, зручне для регуляторів;

    • Сліпі зони:

      • Все, що не увійшло до регресійної серії. Крім того, підтримка цього стандартного списку може бути дуже дорогою;

  • Scenario / use case / transaction flow

    • Ключові ідеї:

      • «Роби щось корисне і цікаве»;

      • "Робіть одне за одним";

    • Основне питання чи мета:

      • Складні випадки, що відбивають реальне використання;

    • Приклади кейсів:

      • Оцінюйте продукт на предмет відповідності бізнес-правилам, даним про клієнтів та продукцію конкурентів;

      • Тестування життєвого циклу / Life history testing ( Hans Buwalda's “soap opera testing” );

      • Варіанти використання (Use cases) - це простіша форма, часто заснована на можливостях продукту та користувальницької моделі, а не на природному спостереженні за системами такого типу;

    • Сильні сторони:

      • Складні, реалістичні події. Може допомагати справлятися у ситуаціях, які надто складні для моделювання;

      • Виявляє збої, що відбуваються (розвиваються) з часом;

    • Сліпі зони:

      • Відмова однієї функції може зробити цей тест неефективним;

      • Необхідно добре подумати, щоб досягти гарного покриття;

  • User testing

    • Ключові ідеї:

      • Прагніть реалізму;

      • Спробуємо це зі справжніми людьми (для різноманітності);

    • Основне питання чи мета:

      • Виявити збої, які можуть виникнути з вини людини, тобто збої у загальній системі людина/машина/програмне забезпечення;

    • Приклади кейсів:

      • Бета-тестування;

      • Власні експерименти із використанням стратифікованої вибірки цільового ринку;

    • Сильні сторони:

      • Проблеми дизайну більш вірогідні;

      • Може продемонструвати, що деякі аспекти продукту незрозумілі або призводять до високого відсотка помилок під час використання;

      • Внутрішні випробування можна контролювати за допомогою логів, відео, відладчиків та інших інструментів;

      • Внутрішні тести можуть бути зосереджені на галузях/завданнях, які, на вашу думку, є (або мають бути) спірними;

    • Сліпі зони:

      • Покриття не гарантоване (серйозні пропуски бета-тестування, інших тестів користувача);

      • Тестові приклади можуть бути погано спроектовані, тривіальні, навряд чи виявляють малопомітні помилки;

      • Бета-тестування коштує грошей;

  • Exploratory testing

    • Ключові ідеї:

      • «Інтерактивне, одночасне дослідження, розробка тестів та тестування»;

    • Основне питання чи мета:

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

    • Приклади кейсів:

      • Повне тестування test-it-today;

      • Сторонні компоненти;

      • Горила-тестинг;

    • Сильні сторони:

      • Продумана стратегія отримання результату у невідомості;

      • Стратегія виявлення невідповідності очікуванням клієнтів;

    • Сліпі зони:

      • Чим менше ми знаємо, тим більше ризикуємо упустити.

Джерела:

PreviousМетоди тестування (White/Black/Grey Box)NextТестування методом білої скриньки (White Box Testing)

Last updated