Тестування методом чорної скриньки (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;

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

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

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

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

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

  • Сліпі зони:

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

Джерела:

• Black Box Testing: У In-Depth Tutorial With Examples And Techniques
• Cem Kaner, James Bach - "Paradigms of Black Box Software Testing"