what are test deliverables software testing
Научете всичко за тестовите резултати при тестване на софтуер с примери:
Въздишка с облекчение идва за всеки тестер, когато възложената задача е изпълнена успешно. В края на всяко тестване тестващият трябва да изпрати на клиента съответните резултати от теста.
В тази статия ще разгледаме подробно някои от важните резултати от теста.
Като цяло тестовите резултати се използват в целия проект. Те се използват във всички фази на тестване и те винаги трябва да бъдат изпратени навреме, за да продължат за по-нататъшна обработка.
Какво ще научите:
Тестови резултати при тестване на софтуер
Тестовите резултати играят важна роля в тестването на софтуер. Тази статия разглежда подробно всичко за тестовите резултати.
Някои от важните резултати от теста са посочени по-долу за справка:
- Тестова стратегия
- План за тестване и оценка
- Тестов сценарий
- Тестови случаи и данни от тестове
- RTM
- Резюме на теста
- Доклад за приключване на теста
- Доклад за инцидент
Тестова стратегия
Тестовата стратегия ще бъде взета въз основа на спецификацията на бизнес изискванията. Това е жизненоважен документ, който съдържа всички подробности за тестовата работа, която трябва да се извърши. Това е пълен документ за управление.
В сравнение с плана за тестване, това е документ на високо ниво и обикновено се изготвя от ръководителя на теста или ръководителя. Тук трябва да бъдат посочени цел на теста, подход на теста, обхват на теста, критерии за влизане и излизане, видове и нива на тестване, етапи, персонал и т.н.
План за тестване и оценка
Тук трябва да бъдат посочени подробните подробности за нивото на всяка стъпка от тестването. Като цяло правилният план води до правилна работна структура. По същия начин добрият план води до добро тестване.
Целта на теста, подходът на теста, обхватът на теста, критериите за влизане и излизане, видовете и нивата на тестване, етапи, персонал и т.н. трябва да бъдат споменати тук подробно.
Генералният план, който включва начина на провеждане на тестването, се използва за прости проекти.
как да отворите .bin файл в Windows
Оценка: Оценката определя колко дълго ще се извършва всяка стъпка при тестване заедно с общите разходи.
Прочетете също => Урок за перфектен план за тестване - Ръководство в дълбочина
Тест сценарий
Ще разберем това с пример сега. Нека вземем за пример тук резервацията на влака. Всички функционалности, които трябва да тестваме, са споменати във формуляри на високо ниво в документа за сценария на теста. С прости думи това означава група от подобни дейности, които трябва да бъдат извършени.
Две техники за сценария:
# 1) Случай за употреба
Методът, ориентиран към целта, е съвкупност от взаимодействия между външните фактори и системата. Неговите компоненти включват първичен поток, алтернативен поток, задействания или дейности, потоци на изключения, предварителни условия, последващи условия и др.
Пример:
[изображение източник ]
# 2) ACE (елемент на компонента на активността)
Процесът на елемента на компонента на дейността разбива бизнес изискванията на дейности.
Пример:
Като цяло резервираме билет, като попълваме данните за пътника, пола и т.н. Следователно трябва да потвърдим следните полета, които по този начин се превръщат в сценарии.
- Резервация: Проверете функционалността на резервацията.
- Подробности за пътника: Проверете функционалността на пола, възрастта и пола.
- Промяна: Проверете дали модифициращата функционалност работи правилно.
- Концесия: Проверете дали функционалността на концесията работи правилно.
- Изглед: Проверете дали функционалността на изгледа работи правилно.
- Отказ: Проверете дали функцията за анулиране работи правилно.
Тук концесията може да се нарече „алтернативен сценарий“, тъй като потребителят може да резервира с или без него въз основа на възрастта. Целта обаче е същата, т.е.да резервирате билет.
Тестов случай
Като вземем същия пример по-горе на страницата за резервация, тестовите случаи се пишат по следния начин:
Резервация:
- Проверете дали потребителят може да резервира билет, като попълни валидни данни във всички полета.
- Проверете дали потребителят може да резервира билет, като попълни невалидни данни във всички полета.
- Проверете дали потребителят може да резервира билет, като оставите празно поле.
Подробности за пътника:
- Проверете дали потребителят може да резервира билет, като въведе валидно име.
- Проверете дали потребителят може да резервира билет, като въведе невалидно име.
- Проверете дали потребителят може да резервира билет, като избира по един и същи пол.
- Проверете дали потребителят може да резервира билет, като въведе възраст над 60 години.
- Проверете дали потребителят може да резервира билет, като въведе възраст под 60 години.
- Проверете дали потребителят може да резервира билет, като въведе валидна възраст, по-голяма от 5.
- Проверете дали потребителят не може да резервира, като въведете възраст под 5 години.
Промяна:
- Проверете дали потребителят може да модифицира полето за име.
- Проверете дали потребителят може да модифицира полето за пол.
- Проверете дали потребителят може да променя възрастовото поле.
Концесия:
жизнен цикъл на развитие на системата на водопада
- Проверете дали потребителят може да получи концесия, като изберете „ Възрастен гражданин ”Опция.
- Проверете дали потребителят може да получи концесия, като изберете „ Инвалиди / инвалиди ”Опция.
Изглед:
- Проверете дали потребителят може да види резервирания билет.
Отказ:
- Проверете дали потребителят може да отмени билета.
По този начин тестовите случаи казват какво точно трябва да бъде тествано в детайли. Тестовите случаи трябва да бъдат написани на прост език и трябва да бъдат лесно разбираеми. Тя трябва да бъде написана в подходящ формат, както е поискано от съответния клиент.
Тестови данни
Някои проекти се нуждаят от предварителни данни от клиента, преди да продължат с изпълнението на тестовия случай. Данните от теста трябва да се прилагат за извършване на тестване.
Пример: В болничния портал за инжектиране е важно да получите подробности за пациента, за да проверите опцията за напомняне за инжектиране.
Тук „подробности за пациента“ са данните от теста.
Предложено четене => Данни от теста - значение и техники за подготовка с примери
RTM / Матрица за проследяване на изискванията
- Както подсказва името, това просто означава, че трябва да картографирате всяко изискване със съответния тестов случай.
- Помага ни да проверим дали сме покрили всички изисквания в нашите тестови случаи или не.
- Помага при преработката или следващите поредни издания на проект.
- Клиентът може лесно да провери състоянието ни на покритие и да знае процеса ни на тестване.
Резюме на теста
Резюме на тестовия отчет обобщава всички извършени тестови дейности и резултатите от теста се компилират в него. Тук трябва да се спомене цялата информация за теста, като членове, участващи в тестването, цели, обхват, подробности за клиента, използван подход на теста, резултати от теста, доклад за дефекти и т.н.
Въпреки това, резюмето на теста трябва да бъде изготвено съгласно съвета на клиента. По този начин е полезен документ и за клиента за преглед на цялостното представяне.
Доклад за закриване на теста
Това означава, че ще затворим проекта след тестване и отстраняване на дефекти. По този начин тук трябва да предоставим подробен анализ на изпълнението на тестовете.
Тук трябва да се споменат откритите и отстранени дефекти. Общото покритие на изискванията се вижда в този доклад. Обикновено се изготвя от ръководителя на екипа или мениджъра. Всички критерии за изход трябва да бъдат изпълнени съответно.
Доклад за инцидент
Докато изпълнява изпълнението на формацията, ако потребителят открие дефекти, трябва да се изведе доклад за инцидент (IR). Това означава, че има дефект и по този начин изпълнението трябва да бъде спряно. Сега трябва да изпратим доклад за инцидент на клиента, за да го помолим за разрешение да изпълни областите с грешки отново като отделен тестов случай.
Това наистина е черна марка и не се очаква от тестер. Всички дефекти трябва да бъдат открити в самия процес на сухо. Ако бъде пропуснато и намерено при официално изпълнение, то става IR.
Пример:
Ако пропусна определена функционалност в мобилното тестване, кажете „ промяна на скрийнсейвъра ' опция. Тогава, докато изпълнявам тестов случай, се заключвам и няма да мога да продължа по-нататък поради тази опция. След това вдигам IR и пиша отделен тестов случай, за да изпълня опцията за скрийнсейвър.
инструменти за непрекъснато разгръщане в devops
Заключение
Артефактите, които се изпращат на заинтересованите страни от софтуерен проект по време на STLC, са известни като Test Deliverables. Разгледахме най-важните тестови резултати в тази статия.
Надяваме се, че тази статия ви е помогнала да научите повече за тестовите резултати при тестване на софтуер !!
Препоръчително четене
- Разлика между плана за тестване на ефективността и стратегията за тестване на ефективността
- Как да подготвим план за тестване и да напишем тестови случаи за ERP приложение - ERP тестване Част-2
- Урок за план за тестване: Ръководство за писане на документ за план за тест на софтуер от нулата
- Тествайте концепция, процес и стратегия за управление на данните
- Какво са тестовите данни? Изпробвайте техниките за подготовка на данните с пример
- Как се пишат тестови случаи: Крайното ръководство с примери
- Как да напиша документ за тестова стратегия (с примерен шаблон за тестова стратегия)
- Разлика между тестовия план, тестовата стратегия, тестовия случай, тестовия скрипт, тестовия сценарий и условията на теста