Повний посібник з функціонального тестування для початківців

complete non functional testing guide

Повне керівництво з нефункціонального тестування: його призначення, типи, інструмент, тестові кейси з прикладами

Що таке нефункціональне тестування?

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

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

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

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

Тестування в основному класифікується на два типи:

• Функціональне тестування
• Нефункціональне тестування

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

• Важливість
• Призначення
• Приклад
• Переваги
• Як визначити нефункціональні вимоги?
  • # 1) Користувач / Технічні історії
  • # 2) Критерії прийнятності
  • # 3) В артефактах
• Різниця у функціональних та нефункціональних вимогах
• Це тестування чорної скриньки чи білої скриньки?
• Контрольний список непрацездатних випадків тестування
  • Контрольний список для тестування продуктивності
  • Контрольний список для тестування безпеки
  • Контрольний список для тестування документації
• Документ підходу
  • Обсяг тесту
  • Тестові показники
  • Тестові інструменти
  • Ключові дати та результати
• Нефункціональні типи тестування
• Нефункціональні засоби тестування
  • # 1) Тестові кейси для тестування юзабіліті
  • # 2) Тестові кейси для тестування продуктивності
  • # 3) Тестові кейси для тестування безпеки
• Висновок
• Рекомендована література

Важливість

Цьому тестуванню бракувало належної уваги, оскільки воно не впливає на функціональність системи.

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

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

Як видно з самої назви, це тестування зосереджується на нефункціональному аспекті програми. Отже, які є нефункціональні аспекти? Або я повинен сказати, які функції не пов'язані з функціональністю програми?

Ну, ось відповіді на них:

• Як працює програма за звичайних обставин?
• Як поводиться програма, коли занадто багато користувачів входять одночасно?
• Чи може заявка впоратися зі стресом?
• Наскільки безпечна програма?
• Чи може програма відновитись після будь-якої катастрофи?
• Чи може програма поводитися однаково в іншому середовищі чи ОС?
• Наскільки легко перенести програму в іншу систему?
• Чи легко зрозуміти документи / посібник користувача, що додаються до програми?

Список продовжується. Але справа тут у тому, що - чи не сприяють ці функції якості програми? Відповідь - ТАК. Ці особливості однаково важливі.

Уявіть, що додаток ідеально відповідає усім вимогам користувача, але якийсь неавторизований користувач легко переходить і зламує дані, введені користувачем у програму, або програма помирає, коли завантажено більше 5 ББ будь-якого файлу. Тож чи могли б ви сказати, що додаток хорошої якості? Очевидно, не правильно !!

Призначення

Єдина мета цього типу тестування - забезпечити тестування нефункціональних аспектів програми та належну роботу програми в контексті того самого.

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

Приклад

Це важливий тип тестування.

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

Щоб зрозуміти його важливість, візьмемо простий приклад:

Додаток розроблено та повністю перевірено на функціональність, але нефункціональне тестування не проводиться на ньому.

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

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

Переваги

Нижче наведено деякі переваги нефункціонального тесту:

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

Як визначити нефункціональні вимоги?

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

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

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

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

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

Приклад:

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

Крім того, його можна перевірити, коли (скажімо, 100) користувачі входять одночасно, скільки часу потрібно для входу користувача у Facebook.

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

Поворотливо, нефункціональна вимога повинна бути врахована за допомогою входів.

Нефункціональну вимогу слід враховувати як:

• Користувач / Технічні історії
• У критеріях прийнятності
• В Артефакт

9

# 1) Користувач / Технічні історії

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

# 2) Критерії прийнятності

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

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

# 3) В артефактах

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

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

Існує кілька відмінностей між функціональними та нефункціональними вимогами, і мало з них зазначено нижче:

Подальше читання => Різниця між функціональним та нефункціональним тестуванням

Це тестування чорної скриньки чи білої скриньки?

Нефункціональний тест підпадає під тестування чорної скриньки техніка.

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

Контрольний список непрацездатних випадків тестування

Контрольний список використовується, щоб гарантувати, що жоден важливий аспект не залишиться без тестування.

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

Подивимосьприкладконтрольного списку тестування продуктивності, безпеки та документації.

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

• Час відгуку програми має бути перевірено, тобто скільки часу потрібно для завантаження програми, будь-який вхід, наданий додатку, забезпечує висновок за скільки часу, оновлення браузера тощо.
• Пропускна здатність слід перевірити кількість транзакцій, виконаних під час перевірки навантаження.
• Навколишнє середовище налаштування має бути таким самим, як і середовище для проживання, інакше результати не будуть однаковими.
• Час процесу - Процес діяльності, як імпорт та експорт Excel, будь-які розрахунки в додатку повинні бути перевірені.
• Сумісність має бути перевірено, тобто програмне забезпечення повинно мати можливість взаємодіяти з іншим програмним забезпеченням або системами.
• ETL слід перевіряти час, тобто час, необхідний для вилучення, перетворення та завантаження даних з однієї бази даних в іншу.
• Збільшення навантаження щодо заявки слід перевірити.

Контрольний список для тестування безпеки

• Аутентифікація: Тільки автентичний користувач повинен мати можливість ввійти.
• Уповноважений: Користувач повинен мати можливість входити в ті модулі, лише для яких він має дозвіл або до яких користувачеві надано доступ.
• Пароль: Потрібно перевірити вимогу до пароля, тобто пароль повинен відповідати тому, як вимога визначає, тобто довжину, спеціальні символи, цифри тощо.
• Час вийшов: Якщо додаток неактивний, тоді він повинен очікувати через визначений час.
• Резервне копіювання даних: Резервне копіювання даних слід робити у визначений час та копіювати у захищене місце.
• Внутрішні посилання до веб-програми не повинна бути доступною, якщо вона розміщується безпосередньо у браузері.
• Усі зв’язки повинні бути зашифровані.

Контрольний список для тестування документації

• Документація користувача та системи.
• Документи для навчальних цілей.

Документ підходу

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

найкращий редактор python mac os x

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

Обсяг тесту

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

Тестові показники

Тестовий підхід вдосконалює показники для вимірювання та звітування під час тестування, такі як:

• Час відповіді (онлайн)
• Пакетне вікно (пакетне)
• Пропускна здатність ( Наприклад , кількість транзакцій за одиницю часу)
• Використання ( Наприклад , відсоток використаних ресурсів)

Тестові інструменти

Переважно тестування продуктивності вимагає використання відповідних інструментів:

• Інструменти для генерації навантаження
• Інструменти контролю ефективності
• Інструменти аналізу ефективності
• Інструменти профілювання додатків
• Інструменти для облицювання основи.

Ключові дати та результати

Документ про підхід до тестування повинен описувати наступне:

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

Нефункціональні типи тестування

На наступному зображенні зображено типи нефункціонального тестування:

Тестування продуктивності:

Оцінює загальну продуктивність системи .

Основними елементами є такі:

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

Тестування навантаження:

Оцінює, чи відповідає робота системи нормальним і очікуваним умовам.

Ключові моменти:

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

Стрес-тестування:

Оцінює, чи є продуктивність системи такою, як очікувалося, коли у неї мало ресурсів.

Ключові моменти:

• Тест на недостатню пам’ять або мало місця на диску на клієнтах / серверах, які виявляють дефекти, які неможливо знайти в звичайних умовах.
• Кілька користувачів виконують однакові транзакції з однаковими даними.
• Кілька клієнтів підключені до серверів з різним навантаженням.
• Скоротіть час для продумування до “Нуля”, щоб напружити сервери на максимальному рівні.

Думай час: Так само, як інтервал часу між введенням користувача та пароля.

Об'ємне тестування:

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

Ключові моменти:

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

Тестування зручності використання:

Оцінює систему для людського використання або перевіряє, чи придатна вона для використання.

Ключові моменти:

• Чи правильний та значущий результат і чи такий самий, як очікувалося у бізнесі?
• Чи правильно діагностовано помилки?
• Чи правильний графічний інтерфейс та відповідає стандарту?
• Чи проста програма для використання?

Тестування інтерфейсу користувача:

Оцінює графічний інтерфейс.

Ключові моменти:

• Графічний інтерфейс повинен надати допомогу та підказки, щоб полегшити його використання.
• Послідовний своїм виглядом?
• Дані правильно передаються з однієї сторінки на іншу?
• Графічний інтерфейс не повинен дратувати користувача або ускладнювати його розуміння.

Тестування сумісності:

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

Ключові моменти:

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

Тестування на відновлення:

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

Тести не обмежуються наступними пунктами:

• Переривання живлення, для клієнта під час виконання CURD діяльності.
• Недійсні вказівники та ключі до бази даних.
• Процес баз даних перервано або достроково припинено.
• Покажчики, поля та ключі бази даних пошкоджені вручну та безпосередньо в базі даних.
• Фізично відключіть зв'язок, вимкніть живлення, відключіть маршрутизатори та мережеві сервери.

Тестування на нестабільність:

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

що є хорошим завантажувачем музики для android

Ключові моменти:

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

Тестування документації:

Оцінює документи та інші посібники користувача.

Ключові моменти включають:

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

Відмовостійке тестування:

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

Щоб запобігти такій ситуації, тестування резервної копії відіграє велику роль. Створення резервної системи - ось у чому полягає процес. Якщо резервна копія доступна, це допомагає повернути систему назад.

Тестування безпеки:

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

Він включає тестування автентифікації, авторизації, цілісності та доступності.

Тестування масштабованості:

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

Перевірка відповідності:

Тестування на відповідність проводиться, щоб перевірити, чи дотримуються визначені стандарти чи ні. Аудити проводяться для перевірки того самого.

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

Це декілька вказівок, які охоплюються під час аудиту.

Тестування на витривалість:

Тестування на витривалість робиться для перевірки поведінки системи, коли навантаження збільшується до певної міри протягом тривалого часу.

Це також називається Soak testing & Capacity testing. Це допомагає перевірити, чи немає в системі витоків пам'яті. Випробування на витривалість - це підгрупа випробувань на навантаження.

Тестування локалізації:

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

Тестування на інтернаціоналізацію:

Тестування на інтернаціоналізацію також відоме як тестування i18n.

I18n представляє I – вісімнадцять літер- N. Це робиться для перевірки того, чи працює програма належним чином у всіх мовних налаштуваннях. Він перевіряє, що будь-яка функціональність або сама програма не порушує роботу, тобто програма повинна мати достатню здатність обробляти всі міжнародні налаштування.

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

Тестування надійності:

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

Перевірка портативності:

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

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

Базове тестування:

Базове тестування також відоме як базове тестування оскільки це створює базу для будь-якого нового додатка, що перевіряється.

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

Тестування ефективності:

Тестування ефективності проводиться для перевірки ефективності роботи програми та кількості необхідних ресурсів, необхідних інструментів, складності, вимог замовника, необхідного середовища, часу, типу проекту тощо.

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

Тестування на аварійне відновлення:

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

Тестування на ремонтопридатність:

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

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

Нефункціональні засоби тестування

На ринку доступно кілька інструментів для тестування продуктивності (навантаження та напруги).

Нижче перелічено кілька з них:

• JMeter
• Навантажувач
• Loadrunner
• Навантажувальна буря
• Neoload
• Прогноз
• Завантаження завершено
• Інструмент стресу веб-сервера
• WebLoad Professional
• Індикатор навантаження
• vPerformer

Чи завжди функціональне тестування проводиться без документації та тестування? Чому?

«Нас завжди вчать писати функціональні тестові кейси. Чому так? Чи проводиться «нефункціональне тестування» без документації (іншими словами, спеціально) або це окремий процес, який набагато складніше зрозуміти? Як пишуться тестові кейси для різних видів тестування, які відбуваються в додатку? '

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

Як так, що ми ніколи не бачимо та не практикуємося у написанні нефункціональних тестових кейсів?

Почнемо з того, що ми знаємо, і як завжди з практичного сценарію.

Приклад: Нижче наведено кроки, які слід виконати у програмі Інтернет-банкінг для здійснення переказу. Давайте використаємо це як наш тест для довідки.

1. Увійдіть на сайт.
2. Виберіть банківський рахунок.
3. Виберіть одержувача (цей одержувач може належати до того самого банку або іншого - це залежить від вашого вибору даних для виконання цього кроку. У будь-якому випадку, виберіть один. Крім того, ми припустимо, що одержувач вже доданий.) .
4. Введіть суму для переказу (додатне значення, в межах ліміту, правильний формат тощо).
5. Натисніть Передати та перевірте, чи отримано підтвердження, чи оновлений баланс рахунку, і все таке.

Це функціональний тест, правильно?

Скажімо, в тому самому додатку, на тій же сторінці переказів, що ми виконуємо Тестування продуктивності, безпеки та зручності використання . Це нефункціональні типи, правильно?

Як би ми писали тестові кейси?

# 1) Тестові кейси для тестування юзабіліті

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

• Наскільки простою у використанні програма?
• Наскільки задовольняє досвід використання системи?
• Якщо не те, що знайоме відразу, як легко навчитися?

Детальніше про це тут: Посібник з тестування зручності використання

Як користувач визначав відповіді на вищезазначені запитання в контексті тестування юзабіліті?

Користувач виконує точно такі ж кроки, як у функціональному тесті. Маю рацію?

# 2) Тестові кейси для тестування продуктивності

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

Перевірте наш Підручники з тестування продуктивності щоб дізнатися більше про це.

Тепер, якби я мав перевірити ефективність транзакції переказів, я мав би 10, 20, 30, 100 ... 1000 ... і т. Д. Користувачі виконували операцію передачі одночасно або поступово, залежно від того, на що я хочу націлитись та зібрати дані.

Які дії виконував би кожен користувач, щоб використовувати передачу, поки триває перевірка продуктивності?

Ті ж самі кроки, що і функціональний тест, правильно?

# 3) Тестові кейси для тестування безпеки

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

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

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

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

Давайте розглянемо порівняльний:

Що цікаво відзначити, це те, що незалежно від того, яку форму тестування ми хочемо зробити, всі кроки однакові .

Справжня різниця полягає в тому, що:

1. Хто виконує ці кроки?
2. Який намір, або іншими словами, чого я намагаюся досягти за допомогою цього тесту?
3. Використані інструменти та прийоми.

Повертаючись до нашого запитання, чому ми ніколи не вчимося писати нефункціональні тестові кейси з усіма детальними кроками до цього?

Це тому, що ,за своєю суттю кроки тестування для варіації типів тестів для певної функції однакові, функціональні чи ні. Саме намір має значення і, можливо, метод.

Висновок

Перш ніж виконувати нефункціональне тестування, важливо правильно спланувати стратегію тестування, щоб забезпечити належне тестування. На ринку доступні різні інструменти для проведення такого типу тестів, як Load Runner, RPT тощо.

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

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

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

Як ви працюєте з нефункціональним тестуванням у своїх командах? І як завжди, повідомте нам, якщо ви погоджуєтесь чи не погоджуєтесь чи хочете щось додати до того, що ми тут робимо.

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

• Функціональне тестування проти нефункціонального тестування
• Альфа-тестування та бета-тестування (повний посібник)
• Посібник із тестування безпеки веб-додатків
• Повне керівництво з функціонального тестування з його типами та прикладами
• Повне керівництво з тестування перевірки складання (тестування BVT)
• Найкращі засоби тестування програмного забезпечення 2021 р. (Інструменти автоматизації тестування якості)
• Посібник для початківців для тестування на проникнення веб-додатків
• Повне керівництво для тестування навантаження для початківців