Меню

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

what is longevity testing

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

Ця стаття пояснює значення “ Тестування на довговічність 'І як це допомагає оцінити стабільність Системи або Продукту та зменшити виявлені замовником дефекти, тобто ' Виловлюйте помилок удома до того, як клієнт знайде їх '.

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

  • Що таке тестування на довговічність?
  • Чому потрібно тестування на довговічність?
  • Планування та виконання тестів на довголіття
  • Які плюси та мінуси тестування на довголіття?

Тестування на довговічність

Як відкрити торрент-файл у Windows -

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

Що таке тестування на довговічність?

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

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

Блок-схема обробки питань, про які повідомляв замовник (рис. 1)

Що таке тестування на довговічність

Передумови тестування на довголіття

# 1) Зазвичай у перші кілька тижнів розгортання Продукту або після оновлення до останнього випуску Програмного забезпечення на сайті замовника все працює добре. Однак протягом декількох тижнів клієнт починає повідомляти про проблеми.

# два) Багато питань можуть бути простими функціями, оскільки про них повідомляє замовник, і їх неможливо легко відтворити власними силами. Їм потрібно багато часу та ретельного аналізу з боку експертної групи по всьому спектру. Підказка: Час = $$$ !!!

# 3) Одне або кілька з наступного трапляються, коли клієнт (и) знаходять дефект (рис. 1)

  • Тяжкість дефекту матиме прямий вплив на бізнес Клієнта, тобто $$$
  • Будь-який запит на обслуговування до Центру технічної підтримки коштує $$$ Організації технічного обслуговування продуктів
  • Рідко проблеми, порушені замовником, вирішуються командою технічної підтримки
  • Такі запити або квитки передаються команді підтримки ескалації
  • Ескалація квитків для клієнтів буде коштувати дорожче $$$ для Організації
  • Якщо команда ескалації не може вирішити проблему, тепер їй доведеться залучити інженерну команду (розробник та контроль якості)
  • До цього часу вартість $$$ для вирішення проблеми також суттєво зросла
  • Чим довше вирішення дефектів, тим більша ймовірність незадоволеного (их) клієнта (-ів), який не дасть повторних замовлень, і найгірший сценарій, коли клієнт вирішує перейти до рішення конкурента у зручний час. Однак в обох випадках це втрата доходу для будь-якої організації, що займається розробкою продуктів

4) Більший відсоток таких проблем, про які повідомляють клієнти, пов’язані із типовою стабільністю системи або продукту у поєднанні з топологією клієнта, інфраструктурою, трафіком та специфікою додатків.

Чому потрібно тестування на довговічність?

1) Будь-який 'дефект', який виникає внаслідок повідомлення про проблему замовника, зазвичай є тестовим втечею.

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

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

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

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

Як відкрити SWF-файли у Windows - -
  • Особливість
  • Регресія
  • Навантаження
  • Стрес
  • Продуктивність
  • Система
  • Рішення
  • Альфа
  • Бета

6) Ключові спостереження, які слід враховувати -

  • Під час будь-якого циклу випуску програмного забезпечення система, що тестується (SUT), або пристрій, що тестується (DUT), у всіх тестових стендах часто перезавантажуються м’яко або жорстко через відсутність таких речей, як завантаження нового коду, перевірка помилок тощо
  • Навіть набори автоматизованих тестів на регресію зазвичай перезавантажують або скидають після виконання SUT або DUT певний сценарій тестового сценарію або серію сценаріїв тестового випадку
  • Таким чином, SUT або DUT працює недостатньо довго без м’якої або жорсткої перезавантаження
  • Тоді як ситуація на місці замовника зовсім інша. Клієнт не може дозволити собі постійно перезавантажувати Систему, що призводить до порушення продуктивності
  • Клієнти дотримуються перевіреної практики, коли оголошують належне вікно технічного обслуговування бажаній аудиторії, а потім здійснюють оновлення програмного забезпечення або заміну обладнання тощо.
  • Такі вікна технічного обслуговування можуть бути на певну тривалість від щокварталу до року, залежно від внутрішніх рекомендацій та процедур організації замовника
  • Насправді фактична картина здоров'я Системи або Продукту на сайті замовника абсолютно відрізняється від карти випробувальних стендів під час даного циклу випуску програмного забезпечення в будь-якій організації, що займається розробкою продуктів.
  • Багато клієнтів також шукають авторизований документ про якість, який пройшов тестування на вертикальні моделі, особливо фінансові, медичні та федеральні вертикальні

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

  • Очевидно, що Система або Продукт повинні проходити триваліші випробування або Тести на довговічність із наскрізним сценарієм, що імітує Сайт або вертикалі Клієнта
  • Більша тривалість може становити 72-720 годин. (3-30 днів) або відповідною тривалістю на основі EFD або CFD дані та конкретні випадки клієнтів
  • Рекомендованою практикою для менеджерів з контролю якості, потенційних клієнтів та тестувальників є проведення тестування на довговічність як окремого заходу в певному циклі випуску програмного забезпечення.
  • Тестування Net-Net, Довговічність дуже важливо для стабільності Системи чи Продукту, оскільки воно має пряме відношення до нижчого рівня $$$ Організації

Планування та виконання тестів на довголіття

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

Планування

Планування та виконання тестів на довголіття

  • Інженерні організації проводять власний аналіз випробувального втечі ( ЧАЙ ) час від часу робити вправи для багатьох Продуктів (апаратне та програмне забезпечення). Деякі навіть мають інтегрований та автоматизований механізм копання даних Test Escape, як правило, на основі 'Зовнішньо виявлених дефектів ( EFD ) »Або« Клієнт виявив дефекти ( CFD ) », Зареєстровану командою підтримки ескалації
  • EFD або CFD повинні бути ретельно проаналізовані в контексті розгортання клієнта в реальному часі з наскрізної точки зору, не тільки інфраструктури, а й пристроїв, додатків, шаблонів трафіку кінцевих користувачів

Розуміння вертикалей клієнта:

Клієнти, як правило, потрапляють в одну із нижчих ширших вертикалей:

  • Охорона здоров'я
  • Роздрібна торгівля
  • Фінанси
  • Освіта
  • Транспортування
  • Виробництво
  • Техніка
  • Федеральний (уряд)

Діяльність

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

# два) Визначте тестові випадки на основі вхідних даних аналізу виходу із системи - зазвичай це очищення від помилок EFD або CFD

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

# 4) Спеціальні випробувальні стенди повинні мати

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

# 5) Відповідні інструменти для формування навантаження, напруги та руху в режимі реального часу

# 6) Визначте ресурс виконання вручну

# 7) Визначте ресурс / стратегію автоматизації для більш швидкого та повторного виконання

# 8) Визначте ПОЧАТОК і КІНЕЦЬ тестування на довголіття для даного випуску

Два підходи для початку та кінця тестування на довголіття:

I) Підхід 1:

  • Код програмного забезпечення чи обладнання має бути в стабільному стані
  • ПОЧАТИ в кінці завершення тесту FEATURE
  • END перед заморожуванням коду

II) Підхід 2:

  • Зробіть незначний удар, дозволивши трохи нестабільний код
  • ЗАПУСК із 70% завершення тестового циклу FEATURE
  • END перед заморожуванням коду

# 9) Перевірка помилок на виявлені дефекти

# 10) Перемістіть тестування довговічності на регресію для подальшого тестування регресії

Виконання

  • Налаштуйте тестові стенди, щоб імітувати одну або кілька вертикалей клієнта
  • Переконайтеся, що всі внутрішні інфрачервоні програми, програми та бази даних, включаючи аромати, подібні до тих, що використовуються клієнтом
  • Переконайтеся, що пристрої кінцевого користувача подібні до тих, що використовуються клієнтом, доступні та використовуються під час виконання плану тестування
  • Переконайтеся, що доступні відповідні інструменти для створення помірного напруження та навантаження системи чи продукту
  • Виконайте весь набір тестів із плану тестування на довговічність без м'якої або жорсткої перезавантаження SUT або DUT, серверних серверів інших пристроїв, пов'язаних з Інфра
  • Кілька запусків тестів повинні бути проведені вищевказаним способом протягом визначеної нон-стоп тривалості від слоту 72-720 годин.
  • Запишіть результати
  • Записати всі виявлені помилки
  • Перевірте всі помилки

Які плюси та мінуси тестування на довголіття?

Плюси

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

Мінуси

  • Початкові витрати на включення тестування на довголіття та пов'язаних з ним заходів як частину даного випуску та регресії
  • Ідеально підходить для Модель водоспаду
  • Моделі Agile / Scrum потребують налаштування тривалості та охоплення

Висновок

Багато «дефектів», які виникають із-за проблем, про які повідомляв Клієнт, в основному пов’язані з тестовим втечею. Це, у свою чергу, викликає багато питань, таких як розробка плану випробувань, перегляд, охоплення та виконання.

Зовнішньо виявлені дефекти (EFD) або Клієнтські дефекти (CFD) впливають на бізнес ($$$) як для Клієнта, так і для Організації Продукту.

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

Про автора: Ця стаття написана автором STH Вінаяком. Він має 12 років досвіду якості та тестування у компаніях Fortune 500.

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

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

^