Меню

Підручник з деструктивного контролю та неруйнівного контролю

  • Головна
  • Інший
  • Підручник з деструктивного контролю та неруйнівного контролю

destructive testing

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

Різниця між руйнівним та неруйнівним контролю за його видами та методами:

У цій статті ми будемо обговорювати деталі щодо деструктивного контролю та тестування неруйнівного програмного забезпечення.

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

Деструктивне та неруйнівне тестування

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

Що таке деструктивне тестування та які його переваги?

Деструктивне тестування програмного забезпечення (DST) - це різновид тестування програмного забезпечення, яке намагається змусити неконтрольовано вийти з ладу частину програмного забезпечення, перевірити його стійкість і виявити точку відмови.

Руйнівний

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

Зверніть увагу, що деструктивне тестування програмного забезпечення (DST) є альтернативним підходом до тестування програмного забезпечення звичайного типу (CST), але не його заміною. Ефективно проводити DST на додаток до CST.

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

Цей тип тестування схожий на тестування мавп, спеціальне тестування та дослідне тестування.

Переваги деструктивного тестування програмного забезпечення

Запитання щодо інтерв’ю Unix для підтримки виробництва
  • Це допомагає оцінити надійність, здатність до відновлення та тривалість життя програми.
  • Виявляє моменти відмови у разі неналежного використання або неправильного використання програмного забезпечення.
  • Він встановлює правильний контекст для тестера, оскільки ігнорує упередження історій користувачів під час тестування.
  • Це дозволяє нам виявити дефекти програмного забезпечення, з якими зазвичай не стикаються пересічні користувачі.
  • Цей тип тестування унікальний у виявленні недоліків програми, які при зверненні сприятимуть підвищенню рівня програмного забезпечення до статусу перевіряючого.

Кроки для проведення цього тестування

  1. На початку циклу деструктивного тестування програмного забезпечення клієнт надсилає копію програми або облікові дані доступу та вимоги користувача.
  2. Потім клієнт представляє вимоги та демонструє заявку аналітику з контролю якості.
  3. Далі аналітик контролю якості встановлює функцію меж у програмі та створює межі юзабіліті програми в межах меж.
  4. Тепер тестер контролю якості буде випадковим чином перевіряти програму в цих межах, використовуючи стохастичні прийоми. Фіксуються робочі процеси та дефекти перевірки якості.
  5. Нарешті, каталог дефектів надається клієнту.
  6. Якщо є необхідність, цикл руйнівного контролю може бути повторений на основі вимог клієнта.

Для цього тестування добре мати певні знання щодо оригінальних вимог програмного забезпечення. Це допомагає розробити хорошу стратегію тестування.

Що ви перевіряєте в деструктивному тесті?

  1. Неправильна та правильна поведінка програмного забезпечення.
  2. Дійсні та недійсні вхідні дані.
  3. Неправильне використання програми.

Методи та стратегії деструктивного тестування програмного забезпечення

Існує кілька способів, за допомогою яких можна проводити деструктивні перевірки:

1) Метод аналізу точки відмови:

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

2) Експертна оцінка:

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

3) Отримайте тестові кейси, розглянуті бізнесом:

c програмування запитань та відповідей на інтерв’ю

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

4) Дослідницькі випробування:

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

5) Подайте систему неналежними даними:

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

6) Використовуйте інші джерела:

Ви також можете використовувати будь-які інші джерела або способи зламати систему та проаналізувати різні сценарії. Хороша річ полягає в тому, що історія користувача про деструктивне тестування програмного забезпечення не обов’язково вимагає „вимог” та „специфікацій”, тому ви можете спробувати будь-який відповідний спосіб проведення цього тестування.

Методи руйнівного контролю

Деструктивне тестування програмного забезпечення може проводитися за допомогою різних методів, таких як:

  • Приймальна перевірка
  • Петлеве тестування
  • Регресійне тестування
  • Розбиття на еквівалентність
  • Випробування граничного значення
  • Тестування інтерфейсу
  • Альфа / бета-тестування
  • Тестування системи
  • Тестування зверху вниз
  • Тестування чорної скриньки

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

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

Що таке неруйнівний контроль та які його переваги?

Неруйнівний контроль (NDT) описується як техніка оцінки програмного забезпечення, яка передбачає коректну взаємодію з програмним забезпеченням. На відміну від деструктивного тестування програмного забезпечення, де ми шукаємо шляхи винятків, при неруйнівному тестуванні ми шукаємо щасливі шляхи або золоті шляхи. НДТ також відомий як позитивний тест.

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

Приклад неруйнівного контролю

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

Переваги тестування неруйнівного програмного забезпечення

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

Коли проводити це тестування

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

Стратегія неруйнівного тестування програмного забезпечення

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

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

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

Висновок

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

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

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

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

^