Що таке деструктивне тестування програмного забезпечення?
Томас Гамільтон
⚡ Розумний підсумок
Деструктивне тестування навмисно підштовхує програмний додаток до збою, виявляючи точні точки, де його надійність порушується через неправильне використання, недійсні вхідні дані та непередбачувану поведінку, до яких звичайні функціональні перевірки ніколи не доходять.
Що таке руйнівне тестування?
Руйнівні випробування – це метод тестування програмного забезпечення, який використовується для пошуку точок відмови в програмі. За допомогою цієї методики застосунок навмисно створюється таким чином, щоб він давав збій, щоб можна було перевірити його надійність та визначити точки відмови. На відміну від методів тестування, які перевіряють, що саме має робити застосунок, деструктивне тестування досліджує непередбачувану поведінку користувача всередині застосунку.
Знання початкових вимог не є необхідним для руйнівного контролю. Однак деякі знання допомагають у розробціping гарна стратегія тестування.
Ілюстрація нижче ілюструє цю ідею — тестер працює проти продукту, а не разом з ним.
Навіщо проводити руйнівний контроль?
- Це допомагає зрозуміти передбачувану поведінку програмного забезпечення, коли воно використовується неналежним чином.
- Це допомагає перевірити надійність програмного продукту.
- Він виявляє рідкісні дефекти, які звичайні користувачі ніколи не викликають, але які з'являються пізніше у виробництві.
Руйнівний контроль проти неруйнівного контролю
Ці два підходи доповнюють один одного, а не конкурують. Неруйнівний контроль — також зване позитивним або щасливим шляхом тестуванням — коректно взаємодіє з програмним забезпеченням і залишає збірку недоторканою. Деструктивне тестування робить протилежне: воно надає недійсні дані та неправильні послідовності, доки щось не зламається.
| Аспект | Руйнівні випробування | Неруйнівний контроль |
| умисел | Примусово завершити роботу програми | Переконайтеся, що програма працює належним чином |
| Використані вхідні дані | Недійсний, неправильний, поза діапазоном, поза послідовністю | Дійсні дані в межах очікуваного діапазону |
| Відповідь на запитання | Де і як воно ламається? | Чи робить воно те, що має робити? |
| Знання вимог | опціональний | істотний |
| Типова вартість | Вища — дослідницька та відкрита | Нижня — за сценарієм та повторювана |
| Результат | Точки відмови, межі діапазону, поведінка відновлення | Відповідність або невідповідність специфікації |
Що перевіряють під час руйнівного контролю?
Руйнівний контроль розглядає обидві сторони межі поведінки:
- Правильна поведінка програмного забезпечення
- Неправильна поведінка програмного забезпечення
- Неправильне використання
- Некоректні вхідні дані
- Правильні вихідні дані
Протягом усієї вправи повинні дотримуватися дві умови:
- Програмне забезпечення ніколи не повинно обробляти або приймати недійсні вхідні дані.
- Незалежно від достовірності чи правильності вхідних даних, програмне забезпечення завжди повинно видавати правильні вихідні дані.
Як провести руйнівне тестування?
Деструктивне тестування включає багато дій, таких як розробка набору тестових скриптів, виконання цих скриптів, виявлення помилок, виправлення помилок та надання зацікавленим сторонам показників успішного або неуспішного проходження тесту в кінці ітерації.
Існує багато способів його запуску. Нижче наведено кілька прикладів.
- Метод аналізу точки відмови: огляд системи, який оцінює, що може піти не так на різних етапах. Допомога від бізнес-аналітик можна використовувати для цієї стратегії.
- Оцінка тестувальника: отримати свою тестові справи проаналізовано або переглянуто іншим тестувальником, який менш знайомий із системою чи функцією.
- Огляд тестових випадків для бізнесу: кінцеві користувачі або експерти часто думають про дійсні сценарії, які тестувальники пропускають, оскільки тестувальники зосереджуються на заявлених вимогах.
- Проведіть дослідницьке тестування, використовуючи робочі аркуші: дослідницьке тестування за допомогою протоколів виконання записує, що було протестовано, дозволяє повторювати тести та контролює охоплення тестами.
- Використайте інше джерело: попросіть когось іншого зламати програмний продукт та проаналізувати знайдені сценарії.
Приклад руйнівного контролю
Розглянемо екрани входу та профілю банківського застосунку. Деструктивний пароль спрацює в таких випадках:
- Вставте рядок довжиною 5,000 символів у поле, обмежене 50 символами, і переконайтеся, що поле відхиляє його, а не скорочує безшумно.
- Введіть літери, символи та від’ємні значення в числове поле суми.
- Поруште очікувану послідовність — відкрийте сторінку підтвердження платежу безпосередньо, не виконуючи попередній крок.
- Натискайте кнопку «Надіслати» кілька разів поспіль, щоб побачити, чи створено дублікати записів.
- Від’єднайте мережу під час транзакції та перевірте, чи відновлюється програма коректно, чи залишає частковий запис.
Кожен випадок має визначене очікування: чітке повідомлення про перевірку, відсутність пошкодження даних та необроблених винятків. Все інше є точкою невдачі, яку варто позначати як дефект.
Методи руйнівного контролю
Наступні методи використовуються в програмній інженерії для досягнення цілей руйнівного тестування:
- Альфа / Бета-тестування
- Регресійне тестування
- Тестування інтерфейсу
- Розбиття еквівалентності
- Тестування циклу
- Приймальні випробування тощо
Методи руйнівного контролю
Наведені нижче методи можна використовувати з модифікаціями:
- Тестування білої скриньки
- Тестування безпеки
- Тестування на дефекти
- Тестування диму, і так далі
Суміжні методи, які варто додати, коли метою є надійність, це негативне тестування, стрес-тестування, тестування відновлення та нечітке тестування.
Переваги та недоліки руйнівного контролю
Варто чітко окреслити компроміс, перш ніж планувати реліз цієї методики.
Переваги
- Revвиявляє точки відмови, яких тестування на основі специфікацій ніколи не досягає.
- Встановлює реальні межі діапазону, щоб виріб можна було впевнено експлуатувати в їх межах.
- Виявляє рідкісні дефекти, які проявляються у виробництві ще довго після випуску.
- Перевіряє довговічність, відновлюваність та обробку помилок за умови зловживання.
Недоліки
- Відкритого характеру, тому покриття не може бути легко гарантовано або виміряно.
- Займає багато часу та залежить від досвіду та креативності тестувальника.
- Результати може бути важко відтворити без ретельного ведення журналу використаних кроків.
- Погано контрольовані запуску можуть пошкодити спільні тестові дані, тому потрібне ізольоване середовище.
