Меню

Какво е тестване за дълголетие? Как да уловим грешките, преди клиентът да го намери

what is longevity testing

Опитайте Нашия Инструмент За Премахване На Проблемите

Тази статия обяснява значението на „ Тестване на дълголетието ”И как помага да се оцени стабилността на системата или продукта и да се намалят дефектите, открити от клиента, т.е. ' Хванете грешките вътре, преди клиентът да ги намери ”.

До края на тази статия QA мениджърите, потенциалните клиенти и тестери ще имат добри познания за:

  • Какво е тестване за дълголетие?
  • Защо се изисква тестване на дълголетието?
  • Планиране и изпълнение на тестове за дълголетие
  • Какви са плюсовете и минусите на тестването за дълголетие?

Тестване на дълголетието

какво е 7z файл?

Какво ще научите:

Какво е тестване за дълголетие?

Тестването на дълголетието е тестова дейност:

  • Да се ​​провери стабилността на системата или характеристиките на продукта и функционалността за по-дълъг период от време срещу подходящо натоварване и напрежение с трафик и приложения в реално време
  • За да се намали появата на дефекти, появяващи се на сайта на клиента

Схема на обработка на проблеми, докладвани от клиенти (фиг. 1)

Какво е тестване за дълголетие

Предистория на тестването за дълголетие

# 1) Обикновено през първите няколко седмици от внедряването на Продукта или след надстройка до най-новата версия на Софтуера на сайта на клиента, всички неща работят добре. За период от няколко седмици обаче клиентът започва да докладва за проблемите.

# две) Много от проблемите може да са прости функции, тъй като те са докладвани от клиента и не са лесно възпроизводими вътрешно. Те се нуждаят от много време и внимателен анализ от експертния екип в целия спектър. Подсказка: Време = $$$ !!!

# 3) Едно или повече от следните се случват, когато клиент (и) открият дефекта (Фиг. 1)

  • Тежест на дефекта ще има пряко въздействие върху бизнеса на клиента, т.е. $$$
  • Всяка заявка за услуга до Центъра за техническа поддръжка струва $$$ на Организацията за продуктово инженерство
  • Рядко проблемите, повдигнати от клиента, се решават от екипа за техническа поддръжка отпред
  • Такива заявки или билети се предават на екипа за поддръжка на ескалацията
  • Ескалацията на клиентските билети ще струва повече $$$ за Организацията
  • Ако екипът за ескалация не е в състояние да разреши проблема, сега ще трябва да привлече инженерния екип (Разработка и QA)
  • До този момент разходите $$$ за разрешаване на проблема също биха се увеличили значително
  • Колкото по-дълго е разрешаването на дефекти, толкова по-голяма е вероятността за недоволни клиенти, които не биха дали повторни поръчки и най-лошият сценарий е, когато клиентът реши да премине към решение на конкурент в подходящ момент. И в двата случая обаче това е загуба на приходи за която и да е организация за продуктов инженеринг

4) По-високият процент на такива проблеми, докладвани от клиент (и), са свързани с типичната стабилност на системата или продукта в комбинация с клиентска топология, инфраструктура, трафик и специфично приложение.

Защо се изисква тестване на дълголетието?

1) Всеки „дефект“, който възниква от съобщения от клиента за проблема, обикновено е Тестово бягство.

разлика между sql и sql сървър

2) Всички подобни дефекти струват $$$ на клиента, както и на инженерната организация, която предоставя решения и услуги на клиентите.

3) В нормален сценарий дефектът трябва да бъде забелязан вътрешно по време на различни цикли на тестване, включително тестване на регресия от един или повече тестери от тестващия екип в зависимост от сложността на проблема.

4) Най-важното е, че такива дефекти, произтичащи от проблеми, съобщени от клиентите, също посочват подходящ сценарий на теста или тестов случай от пропускане в момента на изпълнение на плана за тестване.

5) Много от тестерите трябва да са преживели, че дадена функция се проваля на място на клиента, но преминава вътре в различни тестови лаборатории като

  • Особеност
  • Регресия
  • Заредете
  • Стрес
  • производителност
  • Система
  • Решение
  • Алфа
  • Бета

6) Основни наблюдения, които трябва да бъдат взети предвид -

  • По време на всеки цикъл на издаване на софтуер, System Under Test (SUT) или Device Under Test (DUT) във всички Testbeds често се рестартират меко или твърдо поради липса на неща като зареждане на нов спад на код, проверка на грешки и т.н.
  • Дори автоматизираните тестове за регресия обикновено рестартират или нулират SUT или DUT след изпълнението на определен скрипт за тестов случай или поредица от скриптове за тестови случаи
  • Така че SUT или DUT не работи достатъчно дълго без меко или твърдо рестартиране
  • Докато ситуацията е съвсем различна на сайта на клиента. Клиентът не може да си позволи да продължава да рестартира системата често, което води до нарушения в производителността
  • Клиентите следват доказана практика, при която обявяват подходящ прозорец за поддръжка на предвидената аудитория и след това извършват надстройка на софтуер или подмяна на хардуер и т.н.
  • Такива прозорци за поддръжка могат да бъдат за определена продължителност от тримесечни до годишни в зависимост от вътрешните насоки и процедури на организацията на клиента
  • В действителност действителната здравна картина на Системата или Продукта на сайта на клиента е напълно различна от тази на Тестовите стендове по време на даден цикъл на пускане на софтуера във всяка организация за инженерни продукти
  • Много клиенти търсят и оторизиран документ за качество, преминал специално тестване на вертикални модели, особено финансови, здравни и федерални вертикални

Имайки предвид няколко пропуски в теста, както беше споменато по-горе =>

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

Планиране и изпълнение на тестове за дълголетие

Важно е QA мениджърите, потенциалните клиенти и тестерите да включват тестване за дълголетие като част от своите цялостна тестова стратегия .

Планиране

Планиране и изпълнение на тестове за дълголетие

  • Инженерните организации извършват вътрешен анализ на бягство от тестове ( ЧАЙ ) упражнявайте от време на време за много Продукти (Хардуер и Софтуер). Някои дори имат интегриран и автоматизиран механизъм за изкопаване на данни от Test Escape, обикновено базирани на „Външно открити дефекти ( EFD ) “Или„ Открити от клиента дефекти ( CFD ) “, Регистрирано от екипа за поддръжка на ескалацията
  • EFD или CFD трябва да бъдат внимателно анализирани в контекста на внедряването на клиентите на живо от перспектива от край до край, не само инфраструктурата, но и устройствата, приложенията, моделите на трафика на крайния потребител

Разбиране на вертикалите на клиентите:

Клиентите обикновено попадат в една от долупосочените по-широки вертикали:

  • Здравеопазване
  • На дребно
  • Финанси
  • Образование
  • Транспорт
  • производство
  • Инженерство
  • Федерална (правителство)

Дейности

# 1) Разработете отделен план за изпитване и тест за тестване за дълголетие. Това също ще помогне за проследяване на изпълнението на теста, регистриране на грешки и проверка

# две) Идентифицирайте тестови случаи въз основа на входовете за анализ на Escape Test - обикновено почистване на грешки на EFD или CFD

# 3) Много е важно екипът за QA да имитира тестови легла на една или повече вертикали в зависимост от дейността на организацията с броя на вертикалите

# 4) Специално (те) легло (а) за изпитване трябва да има

  • Мрежова топология, подобна на тази на предвидената вертикала или множество вертикали
  • Инфраструктура с подобни комутатори, рутери, задни сървъри, защитни стени и др
  • Най-често и популярно използваните сървъри за приложения от дадена вертикала (и)
  • Най-често и популярно използвани приспособления за краен потребител от дадена вертикала (и)

# 5) Подходящи инструменти за генериране на товар, стрес и трафик в реално време

# 6) Идентифицирайте ресурса за ръчно изпълнение

# 7) Идентифицирайте ресурс / стратегия за автоматизация за по-бързо и многократно изпълнение

# 8) Определете СТАРТ и КРАЙ на тестването за дълголетие за дадено издание

Два подхода за СТАРТ и КРАЙ на тестването за дълголетие:

как да отворите eps файл на windows -

I) Подход 1:

  • Софтуерният код или хардуерът трябва да са в стабилно състояние
  • СТАРТ в края на FEATURE Завършване на теста
  • END преди замразяване на кода

II) Подход 2:

  • Вземете лек удар, като позволите леко нестабилен код
  • СТАРТ при 70% завършване на тестовия цикъл FEATURE
  • END преди замразяване на кода

# 9) Проверка на грешки за отстранени дефекти

# 10) Преместете Тестването за дълголетие в Регресия за последващо Регресивно Тестване

Екзекуция

  • Настройте тестовия (ите) етаж (и), за да имитирате една или повече вертикали на клиента
  • Уверете се, че всички вътрешни инфраструктури, приложения и бази данни, включително аромати, са подобни на тези на клиента
  • Уверете се, че устройствата на крайния потребител са подобни на използваните от клиента, че са налични и се използват по време на изпълнението на тестовия план
  • Уверете се, че са налични подходящи инструменти за генериране на умерено напрежение и натоварване на системата или продукта
  • Изпълнете целия тестов пакет от плана за тестване на дълголетието, без меко или твърдо рестартиране на SUT или DUT, back-end сървъри други устройства, свързани с Infra
  • Многобройни тестове на тестове трябва да бъдат изпълнени по горния начин за определена непрекъсната продължителност от слота 72-720 часа.
  • Запишете резултатите
  • Запишете всички идентифицирани грешки
  • Проверете всички грешки

Какви са плюсовете и минусите на тестването за дълголетие?

Професионалисти

  • Помага идентифициране на критични грешки преди клиентът да го намери
  • Помага за стабилизиране на Системата или Продукта поради неговата функционална функция, която е от решаващо значение за производителността и бизнеса на клиента
  • Помага за увеличаване на удовлетвореността на клиентите
  • Спестява много разходи $$$ на Организацията - спестените пари са спечелени пари !!!
  • Докладът за тестване на дълголетието може също да бъде превърнат в сертификат за качество, обслужващ различни вертикали

Минуси

  • Първоначални разходи за включване на тестване за дълголетие и свързаните с него дейности като част от дадено освобождаване и регресия
  • Идеално подходящ за Модел на водопад
  • Моделите Agile / Scrum се нуждаят от промяна на продължителността и покритието

Заключение

Много от „Дефектите“, възникнали от съобщени от клиента проблеми, се дължат предимно на Test Escape. Това от своя страна поражда много въпроси като разработване, преглед, покритие и изпълнение на тестовия план.

Външно откритите дефекти (EFD) или Клиентските дефекти (CFD) оказват влияние върху бизнеса ($$$) както за клиента, така и за продуктовата организация.

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

За автора: Тази статия е написана от автора на STH Винаяк. Той има 12 години опит за QA / тестване във фирми от Fortune 500.

Уведомете ни, ако имате някакви въпроси или предложения относно тази статия.

Препоръчително четене

^