Меню

Какво е тестване за приемане (Пълно ръководство)

what is acceptance testing

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

Въведение в изпитването за приемане (част-I):

В този урок ще научите:

  1. Какво е тестване за приемане
  2. Изпитвания за приемане и план за изпитване
  3. Тестове за приемане Състояние и обобщени отчети
  4. Какво е тестване за приемане от потребителя (UAT)

Приключихте ли със системното тестване? Поправени ли са повечето от грешките ви? Проверени и затворени ли са грешките? И така, какво следва?

На следващо място в списъка идва Тестване за приемане, което е последната фаза от процеса на тестване на софтуера . Това е фазата, в която клиентът решава GO / No-GO за продукта и трябва да се спазва задължително преди пускането на продукта на пазара. Съвместните усилия на разработчика и екипа за тестване ще бъдат възложени от клиента чрез приемане или отхвърляне на разработения продукт.

Изпитване за приемане

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

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

Какво е тестване за приемане?

Веднъж Процес на тестване на системата е попълнен от екипа за тестване и е подписан, целият Продукт / приложение се предава на клиента / няколко потребители на клиенти / и двамата, за да се тества за неговата приемливост, т.е. Продуктът / приложението трябва да бъде безупречно, отговаряйки както на критичните, така и на основни бизнес изисквания. Също така, бизнес-потоците от край до край се проверяват по същия начин, както в сценария в реално време.

Производствената среда ще бъде средата за тестване за приемане на тестване (Обикновено се нарича стадийно, предварително изготвено, неуспешно, UAT среда).

Фази на изпитване за приемане

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

Защо тестове за приемане?

Въпреки че тестването на системата е приключило успешно, тестът за приемане се изисква от клиента. Тестовете, проведени тук, се повтарят, тъй като те биха били обхванати при тестване на системата.

Тогава, защо това тестване се провежда от клиенти?

Това е така, защото:

  • За да спечелите увереност в продукта, който се пуска на пазара.
  • За да се гарантира, че продуктът работи по начина, по който трябва.
  • За да се гарантира, че продуктът отговаря на настоящите пазарни стандарти и е достатъчно конкурентен с останалите подобни продукти на пазара.

Видове

Има няколко вида това тестване.

Малко от тях са изброени по-долу:

# 1) Тестване за приемане от потребителя (UAT)

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

Терминът „Потребител“ тук означава крайните потребители, за които е предназначен Продуктът / приложението и следователно тестването се извършва от гледна точка на крайните потребители и от тяхна гледна точка.

=> Също така Прочети: Какво е тестване за приемане от потребителя (UAT)?

# 2) Тестване за приемане на бизнес (НДНТ)

Това е, за да се оцени дали Продуктът отговаря на бизнес целите и целите или не.

НДНТ се фокусира основно върху бизнес ползите (финансите), които са доста предизвикателни поради променящите се пазарни условия / напредващите технологии, така че настоящото изпълнение може да се наложи да претърпи промени, които водят до допълнителни бюджети.

е ключ за мрежова защита, същият като паролата

Дори Продуктът, който отговаря на техническите изисквания, може да се провали при НДНТ поради тези причини.

# 3) Изпитване за приемане на договор (CAT)

Това е договор, който уточнява, че след като Продуктът започне да действа, в рамките на предварително определен период, трябва да се извърши тест за приемане и той да премине всички случаи на приемане.

Договорът, подписан тук, се нарича Споразумение за ниво на услугата (SLA), което включва условията, при които плащането ще се извършва само ако Продуктовите услуги са в съответствие с всички изисквания, което означава, че договорът е изпълнен.

Понякога този договор може да се случи, преди Продуктът да бъде пуснат в действие. И двата начина, договорът трябва да бъде добре дефиниран по отношение на периода на тестване, областите на тестване, условията по въпроси, срещани на по-късни етапи, плащанията и т.н.

# 4) Наредби /СъответствиеИзпитване за приемане (RAT)

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

Обикновено разработеният Продукт / приложение, който е предвиден да бъде пуснат по целия свят, трябва да бъде подложен на RAT, тъй като различните страни / региони имат различни правила и разпоредби, определени от нейните ръководни органи.

Ако някое от правилата и разпоредбите е нарушено за която и да е държава, тогава тази държава или конкретният регион в тази държава няма да имат право да използват Продукта и се счита за неизправност. Доставчиците на Продукта ще носят пряка отговорност, ако Продуктът бъде пуснат, въпреки че има нарушение.

# 5) Изпитване за оперативно приемане (OAT)

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

OAT главно осигурява стабилността на продукта, преди да го пусне в производството.

# 6) Алфа тестване

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

Тук тестването се извършва по контролиран начин.

=> Прочетете също: Какво е алфа тестване?

# 7) Бета тестване / полеви тестове

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

Тестването се извършва по неконтролиран начин, което означава, че потребителят няма ограничения за начина, по който се използва Продукта.

=> Прочетете също: Какво е бета тестване?

Видове тестове за приемане

Всички тези типове имат обща цел:

  • Уверете се, че придобивате / обогатявате доверието в продукта.
  • Уверете се, че Продуктът е готов за използване от реалните потребители.

Кой прави тестове за приемане?

За алфа тип тестване извършват само членовете на организацията (разработили продукта). Тези членове не са пряко част от проекта (мениджъри / ръководители на проекти, разработчици, тестери). Екипите за мениджмънт, продажби и поддръжка обикновено извършват тестването и съответно предоставят обратна връзка.

Освен типа Alpha, всички други видове приемане обикновено се извършват от различни заинтересовани страни. Подобно на клиентите, клиентите на клиентите, специализираните тестери от организацията (не винаги).

Също така е добре да включите бизнес анализатори и експертиза на предметните въпроси, докато извършвате това тестване въз основа на неговия тип.

Качества на приемните тестери

Тестери със следните качества са квалифицирани като приемни тестери:

  • Способност да мисли логично и аналитично.
  • Добри познания в областта.
  • В състояние да проучи конкурентните продукти на пазара и да ги анализира в разработения продукт.
  • Възприемане на крайния потребител по време на тестване.
  • Разберете бизнес нуждите за всяко изискване и тествайте съответно.

Въздействие на проблемите, открити по време на това тестване

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

Екипът за тестване играе основна роля в предоставянето на RCA за проблеми с приемането. Те също така помагат за определяне колко ефективно се извършва тестването.

Също така валидните проблеми в теста за приемане ще засегнат както тестването, така и усилията на екипа за разработки по отношение на впечатление, рейтинги, анкети на клиентите и др. Понякога, ако се установи някакво невежество от екипа за тестване относно валидирането, това води и до ескалация.

Използвайте

Това тестване е полезно от няколко аспекта.

Малко от които включват:

  • За да разберете проблемите, пропуснати по време на фазата на функционално тестване.
  • Колко добре е разработен Продукта.
  • Продуктът е това, което всъщност се нуждае от клиентите.
  • Проведените отзиви / проучвания помагат за подобряване на производителността на продукта и потребителското изживяване.
  • Подобрете процеса, последван от RCA като вход.
  • Минимизирайте или премахнете проблемите, произтичащи от производствения продукт.

Различия между тестване на системата, тестване за приемане и тестване за приемане от потребителя

По-долу са дадени основните разлики между тези 3 вида тестове за приемане.


Тестване на системата		Изпитване за приеманеТест за приемане от потребителя
Извършват се положителни и отрицателни тестовеОбикновено се извършват положителни тестовеИзвършват се само положителни тестове
Извършва се тестване от край до край, за да се провери дали Продуктът отговаря на всички посочени изискванияТестването се извършва, за да се провери дали Продуктът отговаря на изискванията на клиента за приемливостТестването се извършва, за да се провери дали изискванията на крайните потребители са изпълнени за приемливост
Продуктът е тестван като цяло, като се фокусира само върху функционални и нефункционални нуждиПродуктът е тестван за бизнес нужди - приемливост на потребителя, бизнес цели, правила и разпоредби, операции и др.Продуктът е тестван само за приемливост от потребителя
Екипът за тестване извършва системно тестванеКлиент, клиенти на клиенти, тестер (рядко), мениджмънт, продажби, екипи за поддръжка извършва тестове за приемане в зависимост от вида на провеждания тестКлиент, клиент на клиента, тестери (рядко) извършват тестване за приемане от потребителя
Тестовите случаи се пишат и изпълняватТестовете за приемане се пишат и изпълняватТестовете за приемане от потребителя се пишат и изпълняват
Може да бъде функционален и нефункционаленОбикновено функционални, но нефункционални в случай на RAT, OAT и т.н.Само функционални
За тестване се използват само тестови данниЗа тестване се използват данни в реално време / производствени данниДанни в реално време / производствени данни се използват за тестване
Откритите проблеми се считат за грешки и са фиксирани въз основа на тежестта и приоритетаОткритите проблеми маркират продукта като неизправност и се считат за незабавно отстранениОткритите проблеми маркират продукта като неизправност и се считат за незабавно отстранени
Контролиран начин на тестванеМоже да се контролира или неконтролира въз основа на типа тестванеНеконтролиран начин на тестване
Тестване на среда за развитиеТестване на среда за разработка или предпроизводствена среда или производствена среда, въз основа на типаТестването винаги е в предварителна производствена среда
Няма предположения, но ако има такива, могат да бъдат съобщениНяма предположенияНяма предположения

Тестове за приемане

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

Това не дава ясна представа за това как да се извършват тестове, както в тестовите случаи. Тестовете за приемане се пишат от тестери, които имат пълен контрол върху Продукта, обикновено експертиза по предмета. Всички написани тестове се преглеждат от клиент и / или бизнес анализатори.

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

Тест за приемане

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

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

двойно свързан списък c ++

Ако няма отделна среда, създадена за тестове за приемане, за тази цел може да се използва редовна среда за тестване. Но тук ще бъде объркано, тъй като тестовите данни от редовното тестване на системата и данните в реално време от приемащите тестове се поддържат в една среда.

Приемо-изпитателното легло обикновено се поставя от страната на клиента (т.е. в лабораторията) и ще има ограничен достъп до екипите за разработка и изпитване.

От екипите ще се изисква достъп до тази среда чрез виртуални машини / или специално проектирани URL адреси, използващи специални идентификационни данни за достъп, и целият достъп до това ще бъде проследен. Нищо в тази среда не трябва да се добавя / модифицира / изтрива без разрешението на клиента и те трябва да бъдат уведомени за направените промени.

Критерии за влизане и излизане за AT

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

Това е фазата, която започва веднага след тестването на системата и завършва преди стартирането на производството. И така, критериите за изход при тестване на системата стават част от критериите за влизане за AT. По същия начин критериите за изход на AT стават част от критериите за влизане в производството.

Критерии за влизане

По-долу са дадени условията, които трябва да бъдат изпълнени преди започване:

  • Бизнес изискванията трябва да са ясни и достъпни.
  • Системата и фазата на регресионно тестване трябва да бъдат завършени.
  • Всички критични, основни и нормални грешки трябва да бъдат поправени и затворени (Приемат се по-малки грешки, основно са козметични грешки, които не нарушават употребата на продукта).
  • Списъкът с известни проблеми трябва да бъде изготвен и споделен със заинтересованите страни.
  • Трябва да се създаде изпитвателно легло за приемане и да се извърши проверка на високо ниво за екологични проблеми.
  • Фазата на системно тестване трябва да бъде подписана, като се остави продуктът да премине към фаза AT (обикновено се извършва чрез комуникация по имейл).

Критерии за изход

AT трябва да изпълни определени условия, за да пусне продукта за стартиране на производството.

Те са както следва:

  • Тестовете за приемане трябва да бъдат изпълнени и всички тестове трябва да преминат.
  • Не са оставени отворени критични / основни дефекти. Всички дефекти трябва да бъдат отстранени и проверени незабавно.
  • AT трябва да бъде подписан от всички включени заинтересовани страни с Върви / Не-отивай Решение за продукта.

Процес на изпитване за приемане

В V-модел , AT фазата е успоредна на фазата на изискванията.

Действителният AT процес протича както е показано по-долу:

Процес на изпитване за приемане

Анализ на бизнес изискванията

Бизнес изискванията се анализират чрез препращане към всички налични документи в рамките на проекта.

Някои от които са:

  • Спецификации на системните изисквания
  • Документ за бизнес изисквания
  • Случаи на употреба
  • Диаграми на работния поток
  • Проектирана матрица за данни

План за изпитване за приемане на проекта

Има някои елементи, които трябва да бъдат документирани в плана за изпитване за приемане.

Нека да разгледаме някои от тях:

  • Стратегия и подход за изпитване за приемане.
  • Критериите за влизане и излизане трябва да бъдат добре дефинирани.
  • Обхватът на AT трябва да бъде добре споменат и трябва да покрива само бизнес изискванията.
  • Подходът за проектиране на приемни тестове трябва да бъде подробен, така че всеки, който пише тестове, лесно да разбере начина, по който трябва да бъде написан.
  • Създадено тестово легло, трябва да се споменат действителният график / график за тестване.
  • Тъй като тестването се провежда от различни заинтересовани страни, трябва да се споменат подробности относно грешката в регистрацията, тъй като заинтересованите страни може да не са наясно с процедурата, която се следва.

Тестове за приемане на проекти и преглед

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

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

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

Създаване на тест за приемане

Пробното легло трябва да бъде настроено подобно на производствена среда. Изискват се проверки на много високо ниво, за да се потвърди стабилността на околната среда и използването. Споделете идентификационните данни, за да използвате средата само със заинтересованата страна, която извършва това тестване.

Настройка на данните от теста за приемане

Данните за производството трябва да бъдат подготвени / попълнени като тестови данни в системите. Освен това трябва да има подробен документ по такъв начин, че данните да се използват за тестване.

Не разполагайте с тестови данни като TestName1, TestCity1 и т.н., вместо това имайте Albert, Мексико и др. Това дава богат опит в реално време и тестването ще бъде актуално.

Изпълнение на приемателен тест

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

Отново, отстранените грешки трябва да бъдат проверени и затворени като задача с висок приоритет. Отчетът за изпълнение на теста трябва да се споделя ежедневно.

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

Бизнес решение

Излиза a Върви / Не-отивай решение продуктът да бъде пуснат в производство. Отивам решението ще вземе продукта напред да бъде пуснат на пазара. Не ходи решение маркира продукта като Неизправност.

Няколко фактора за решение за забрана:

  • Лошо качество на продукта.
  • Твърде много отворени функционални грешки.
  • Отклонение от бизнес изискванията.
  • Не отговаря на пазарните стандарти и се нуждае от подобрения, за да съответства на настоящите пазарни стандарти.

Фактори за успех на това тестване

След като този тест е планиран, подгответе контролен списък, който увеличава степента на успех на него. Има някои елементи на действие, които трябва да бъдат изпълнени преди началото на теста за приемане.

Те са:

  • Имайте добре дефиниран обхват и се уверете, че има бизнес необходимост от обхвата, определен за това тестване.
  • Изпълнете тестове за приемане в самата фаза на тестване на системата поне веднъж.
  • Изпълнявайте екстензивно ad-hoc тестване за всеки от сценариите за приемане.

Заключение

Накратко, тестовете за приемане помагат да се разбере ефективността на екипите за разработка и тестване.

Има няколко инструмента за провеждане на тази дейност, но обикновено се предпочита да се извършва ръчно, тъй като има участие на реалните потребители и различни заинтересовани страни, които не са от технически опит, и може да не е осъществимо за тях.

Какво следва?

В следващия ни урок ще преминем към следните теми:

  • Примери за критерии за приемане.
  • Как да напиша план за приемане на изпит.
  • Подходящ шаблон за писане на тестове за приемане.
  • Как да напиша тестове за приемане с примери.
  • Идентифициране на сценарии за приемни тестове.
  • Доклади от тестове за приемане.
  • Тестове за приемане в Agile и разработено с тестове.

СЛЕДВАЩ Урок # 2: План за тестове за приемане

Извършвали ли сте тестове за приемане? Ще се радваме да чуем вашите преживявания !!

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

^