Неруйнівне тестування програмного забезпечення (НДТ): що таке, стратегія тестування
Томас Гамільтон
⚡ Розумний підсумок
Неруйнівне тестування перевіряє, чи правильно поводиться програма, коли вона отримує дійсні вхідні дані, тому тестувальники також називають його тестуванням позитивного або щасливого шляху. Воно підтверджує очікувані результати відповідно до задокументованих вимог.
Що таке неруйнівне тестування програмного забезпечення?
Неруйнівний контроль це тип тестування програмного забезпечення, який передбачає тестування та правильну взаємодію з програмним додатком. Іншими словами, неруйнівне тестування програмного забезпечення (NDT) також можна назвати позитивним тестуванням або тестуванням щасливого шляху. Він дає очікувані результати та доводить, що програма працює належним чином.
Назва запозичена з інженерії, де неруйнівний контроль перевіряє фізичний компонент, не пошкоджуючи його. У програмному забезпеченні ідея та сама: додаток працює так, як він був розроблений, і він переживає випробування без змін.
приклад: Введення правильних даних у модуль входу та перевірка, чи приймає він облікові дані та переходить на наступну сторінку.
На скріншоті нижче показано форму входу з дійсним значенням, введеним у поле імені користувача перед виконанням тесту.
Щоб виконати неруйнівний контроль у наведеному вище прикладі, введіть дійсне ім'я користувача та пароль у форму входу. Оскільки введені дані відповідають дозволеним вимогам, бажаний результат є позитивним, і тестер просто підтверджує перехід програми на наступну сторінку.
Для чого необхідне неруйнівне тестування програмного забезпечення (NDT)?
Неруйнівне тестування відповідає на перше питання, яке ставить кожен зацікавлений сторін щодо збірки: чи дійсно функція виконує те, що їй було запропоновано? Це причини, чому команди її запускають.
- Головною перевагою методу неруйнівного контролю є те, що він призводить до покращення якості програмного забезпечення, оскільки дефекти, виявлені в основному потоці, виправляються на ранній стадії.
- Щоб продемонструвати, що функції програмного забезпечення працюють відповідно до специфікації.
- Щоб перевірити, чи виконано вимоги до продуктивності.
- Щоб перевірити, чи дотримано вимог кінцевих користувачів.
- Щоб перевірити, чи невелика частина коду або функціональності працює належним чином і не порушує пов'язану функціональність.
- Надати докази, які можна пред'явити на приймальне тестування користувачами підписання, де клієнт хоче бачити заплановану поведінку, а не режими відмови.
Коли проводиться неруйнівний контроль (NDT)?
Тут час має більше значення, ніж для більшості технік, тому що щасливий шлях контролює все нижче за течією.
- Це перша форма тестування, яку тестер виконує над застосунком, тобто на початковому етапі SDLC.
- Неруйнівний контроль зазвичай проводиться, коли недостатньо часу для повного циклу випробувань, оскільки він все одно доводить, що критерії прийнятності виконані.
- Він виконується перед негативними та деструктивними сценаріями. Якщо основний потік порушений, тести обробки помилок повідомляють про шум, а не про реальні дефекти.
- Це повторюється після кожного виправлення дефекту, де воно перетинається з регресійне тестування.
Стратегія тестування для неруйнівного контролю
Стратегія неруйнівного контролю навмисно проста, а дисципліна полягає в позитивному настрої, а не в інструментарії.
- Підхід до неруйнівного контролю повинен бути позитивним.
- Мета методу неруйнівного контролю (НК) полягає в тому, щоб довести, що застосунок працюватиме, коли йому надано коректні вхідні дані.
- Для проведення неруйнівного контролю немає спеціальних вимог або умов.
- Найкраща практика для неруйнівного контролю — перевірити, чи система виконує свої функції.
На діаграмі нижче підсумовано, як ця стратегія зазвичай організована протягом циклу тестування.
Як писати неруйнівні (позитивні) тестові випадки
Неруйнівний тестовий випадок корисний лише тоді, коли його вхідні дані є довідково валідними, а очікуваний результат випливає з вимоги, а не з припущення тестувальника. Наступні кроки створюють такий тип тестовий випадок.
Крок 1) Виберіть один критерій прийнятності. Прочитайте вимогу та переформулюйте її як одне перевірене твердження, наприклад, «поле імені користувача приймає від шести до двадцяти буквено-цифрових символів».
Крок 2) Виберіть коректні вхідні дані. Виберіть значення, які зручно знаходяться в межах дозволеного діапазону. Розбиття еквівалентності допомагає тут — зазвичай достатньо одного репрезентативного значення на дійсний розділ.
Крок 3) Запишіть очікуваний результат перед виконанням. Очікуваний результат має бути записаний зі специфікації. Його написання після запуску перетворює тест на опис того, що робилося під час збірки.
Крок 4) Дотримуйтесь порядку виконання кроків у призначеному для користувача порядку. Послідовність повинна відповідати тому, як би виконав завдання реальний користувач, оскільки метою методики є підтвердження запланованого шляху.
Крок 5) Запишіть ідентифікатор вимоги. TracПовернення справи до її критерію дозволяє команді довести покриття під час перевірки.
Приклад роботи модуля входу виглядає ось так.
| Поле | Неруйнівний тестовий випадок |
|---|---|
| Вимога | Ім'я користувача приймає 6–20 буквено-цифрових символів |
| Дані тесту | ім'я користувача guru99tester, дійсний пароль, що відповідає |
| заходи | Відкрийте сторінку входу, введіть облікові дані, виберіть «Увійти» |
| Очікуваний результат | Облікові дані прийнято, і відображається головна сторінка |
| тип | Позитивний / щасливий шлях |
Зверніть увагу, що ніщо у кейсі не намагається розірвати поле. Кейс, який вводить п'ять символів для відображення повідомлення про помилку, є негативний тест, а не неруйнівний.
Приклади неруйнівного контролю
Наведений нижче приклад показує, як неруйнівний контроль поводиться в багатомодульному застосунку після виправлення дефекту.
- Додаток має п'ять модулів: сторінку входу, головну сторінку, сторінку з деталями користувача, сторінку створення нового користувача та створення завдань.
- Припустимо, що на сторінці входу є помилка: поле імені користувача приймає менше шести буквено-цифрових символів. Це суперечить вимозі set, яка стверджує, що ім'я користувача не повинно приймати менше шести символів, тому така поведінка є дефектом.
- Повідомлення про помилку надходить до команди розробників через звичайний процес управління дефектами, це виправлено, а збірку відправлено назад команді тестування.
- Команда тестування не лише перевіряє сторінку входу, де було виправлено дефект, але й тестує інші модулі. Під час тестування всіх модулів з дійсними даними вона виконує неруйнівне тестування, просто щоб підтвердити, що вся програма все ще працює належним чином.
Неруйнівний контроль проти руйнівного контролю
Ці дві техніки часто викладаються разом, оскільки вони відповідають на протилежні питання щодо однієї й тієї ж конструкції. Руйнівні випробування шукає точку, в якій програмне забезпечення дає збій, тоді як неруйнівний контроль підтверджує, що запланована поведінка зберігається.
| Аспект | Неруйнівний контроль | Деструктивне тестування |
|---|---|---|
| Намір | Правильно взаємодійте з додатком та перевіряйте позитивні результати | Введіть незвичайні або недійсні дані, щоб знайти точку відмови |
| Вхідні дані | Дійсні дані, взяті з вимоги | Недійсні, пошкоджені або невідповідні послідовності дані |
| Необхідні вимоги | Так — справи пишуться відповідно до критеріїв прийнятності | Не обов'язково; тестувальники працюють без упередженості користувацьких історій |
| Що це розкриває | Слабкі сторони функціональності порівняно зі специфікацією | Недоліки в конструкції, надійності та відновлюваності |
| Супутні техніки | Тестування диму, функціональне тестування | Тестування на мавпах, дослідницьке тестування |
Ці два методи радше доповнюють один одного, ніж є альтернативами. Проведення лише неруйнівного контролю залишає обробку помилок неперевіреною, а проведення лише руйнівного контролю ніколи не доводить, що продукт виконує свою роботу.
Переваги та обмеження неруйнівного тестування програмного забезпечення
Знання того, де техніка перестає бути корисною, так само важливо, як і знання того, що вона охоплює.
Переваги
- Швидке проектування та виконання, оскільки тестові дані надходять безпосередньо зі специфікації.
- Не потребує спеціального середовища, впровадження помилок або пошкодженого набору даних.
- Надає докази, що однозначно відповідають вимогам, що підходить для аудитів та узгоджень.
- Працює однаково добре, як ручне тестування і за сценарієм тестування автоматизації, тому ті самі випадки можна повторно використовувати в наборі регресійних алгоритмів.
- Дає ранній, чесний сигнал про стан збірки на будь-якому рівні, від юніта до інтеграційне тестування до тестування системи.
Недоліки
- Повний пропуск нічого не говорить про те, як поводиться програма з недійсними вхідними даними, тому серйозні дефекти обробки помилок можуть його пережити.
- Покриття обмежене якістю вимог. Все, що не визначено, ніколи не перевіряється.
- Це може створити хибну впевненість, коли щасливий шлях є єдиним шляхом, яким можна йти до звільнення.
- Він не вимірює стійкість, відновлення або продуктивність під впливом стресу, для чого потрібні власні методики з ширшого набору... види тестування програмного забезпечення.
Розглядайте неруйнівний контроль як базову основу, на якій базується будь-який інший метод, і плануйте його в рамках ширшого плану. життєвий цикл тестування ПЗ а не як одноразова діяльність.
