Меню

Функціональне тестування проти тестування продуктивності: чи слід це робити одночасно?

functional testing vs performance testing

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

Функціональне тестування проти тестування продуктивності:

Відмінності між Тестування продуктивності, навантаження та стрес-тестування були пояснені на прикладах у нашому останньому уроці.

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

=> Клацніть тут, щоб отримати повну серію навчальних посібників з тестування продуктивності

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

тестування функціональної продуктивності 5

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

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

Sl НІФункціональне тестування
Тестування продуктивності
1Для перевірки точності програмного забезпечення з певними входами щодо очікуваного результатуДля перевірки поведінки системи при різних умовах навантаження
дваВін може бути ручним або автоматизованим
Це може бути ефективно виконано, якщо автоматизовано
3Один користувач виконує всі операції
Кілька користувачів виконують бажані операції
4Залучення вимагається від замовника, тестувальника та розробникаПотрібне залучення замовника, тестувальника, розробника, команди адміністраторів баз даних та управління з питань, що стосуються Н / З
5Виробниче випробувальне середовище не є обов’язковим, а вимоги до В / В мінімальніПотрібні близько до виробничого випробувального середовища та декількох об'єктів В / В для заповнення навантаження

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

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

Витоки дефектів можуть стати однією з найбільших проблем:

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

тестування функціональної продуктивності 1

Далі йде розмова міжМенеджер випробувань та тестер :

(Менеджера випробувань називають 'TM', а тестера - 'TR')

ТМ : Привіт, приятелю ... Як справи у тестуванні продукту «А»?

TR : Так ... Ми просуваємось у більшій мірі.

ТМ : Це фантастика ... А який наш обсяг з точки зору тестування продуктивності, поки функціональне тестування виконується?

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

Є кілька запитань із наведеної розмови, які слід розглянути:

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

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

Отже, вам потрібно розглянути 2 запитання:

  1. Продуктивність - чи впливає це на функціональне тестування?
  2. Чи ми вважаємо тестування продуктивності окремим результатом, навіть якщо це турбує клієнта?

Тестування продуктивності є важливо !

що таке ім'я користувача та пароль для маршрутизатора

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

  1. Потрібні моделі відповідей на відповіді
  2. Системи, засновані на операціях
  3. Навантажувальні системи
  4. Системи на основі реплікації даних

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

тестування функціональної продуктивності 2

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

Далі йде розмова міжклієнта та менеджера випробувань.

(Клієнта називають «CL», а менеджера випробувань - «TM»)

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

ТМ : Так, це можна зробити. Як ви вже сказали, буде більша ймовірність ітеративного тестування, ми хотіли б запропонувати автоматизацію для функціонального (регресійного) тестування.

CL : Добре, чудово, надішліть нам свій підхід, щоб ми могли схвалити це. Автоматизація матиме набагато більший вихід з мінімальними зусиллями.

ТМ : Точно так. Ми попрацюємо над підходом та зв’яжемося з вами з підтвердженням концепції.

З наведеної розмови стає ясно, що потреба клієнтів полягає в оптимізації ефективності.

Приклад

Компанія ABC працює над проектом з розробки програмного забезпечення А. Тестування програмного забезпечення А проводиться компанією XYZ.

У контракті компанії ABC та XYZ є деякі обмеження щодо їх співпраці. Будь-яка дискусія між двома компаніями повинна відбуватися раз на тиждень або три рази на місяць. Система працює за моделлю режиму запиту-відповіді. Етап розробки завершено компанією ABC.

Зараз настав час для компанії XYZ виконати офіційне функціональне тестування програмного забезпечення А. XYZ починає працювати над тестуванням програмного забезпечення А. Вони провели чисту перевірку програмного забезпечення і дали «Go» для реалізації в реальному часі після 2 циклів тестування.

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

Отже, що це такепроблема?

тестування функціональної продуктивності 3

  • Чи проблема в обмеженні співпраці між розробниками та тестувальниками?
  • Це те, що вимоги не були враховані на 100%?
  • Це те, що виріб не тестували у належних тестових умовах?
  • Або якісь інші причини?

Після ретельного дослідження та аналізу,наступні були зроблені висновки:

тестування функціональної продуктивності 4

  1. Було небагато залежних та взаємозалежних додатків, які мали проблеми з продуктивністю під час отримання відповідей.
  2. Використані тестові входи не були абсолютними.
  3. Про надійність програмного забезпечення не піклувались.
  4. Багато проблем із синхронізацією між кількома незалежними програмами.
  5. Тестування програмного забезпечення зробило кілька переробок, які не враховувались.

Отже післявиправні діїКоманда планування вступила, було запропоновано наступне:

  1. Потрібно посилити взаємодію між командою розробників та командою випробувачів.
  2. Всі залежні програми потрібно підключити та включити в тестування функціональності системи
  3. Значення часу очікування запиту та відповіді потрібно збільшити, щоб надати простору невиробничому середовищу
  4. Для функціонального тестування слід використовувати різні вхідні дані - від простих до складних
  5. Нефункціональне тестування, особливо тестування продуктивності та навантаження, повинно проводитися відповідно до рекомендацій бригади з усунення несправностей.
  6. Окрім тестування системи, має бути проведено тестування системної інтеграції.
  7. Слід передбачити мінімальний проміжок часу між будь-якими двома ітераціями тестування. Це для повторного тестування раніше виявлених помилок.
  8. Усі помилки, виявлені в попередніх ітераціях, повинні бути виправлені в поточній ітерації.

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

Спостереження:

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

Висновок

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

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

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

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

=> Завітайте сюди, щоб отримати повну серію навчальних посібників з тестування продуктивності

НАЗАД Підручник | НАСТУПНИЙ підручник

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

^