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

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

Тестовият план е шаблон за провеждане на дейности по тестване на софтуер като дефиниран процес, който е напълно наблюдаван и контролиран от мениджъра за тестване. Планът за тестване се изготвя от ръководителя на теста (60%), мениджъра на теста (20%) и от инженера по тестването (20%).

Видове тестови планове

Има три вида тестов план

• Главен тестов план
• План за тестване на фази
• Тестване на специфични тестови планове

Главен тестов план

Главният тестов план е вид тестов план, който има множество нива на тестване. Той включва пълна тестова стратегия.

План за тестване на фази

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

Специфични тестови планове

Специфичен тестов план, предназначен за основни типове тестване като тестване на сигурността, тестване на натоварване, тестване на производителността и т.н. С други думи, специфичен тестов план, предназначен за нефункционално тестване.

Как да напишем тестов план

Създаването на тестов план е най-важната задача от процеса на управление на тестовете. Съгласно IEEE 829, следвайте следните седем стъпки, за да подготвите тестов план.

• Първо, анализирайте структурата и архитектурата на продукта.
• Сега проектирайте тестовата стратегия.
• Определете всички цели на теста.
• Определете зоната за тестване.
• Дефинирайте всички използваеми ресурси.
• Планирайте всички дейности по подходящ начин.
• Определете всички резултати от теста.

Компоненти или атрибути на плана за тестване

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

Цели: Състои се от информация за модули, функции, тестови данни и т.н., които показват целта на приложението, означава поведението на приложението, целта и т.н.

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

• В обхват
• Извън обхвата

В обхват: Това са модулите, които трябва да бъдат тествани стриктно (подробно).

Извън обхват: Това са модулите, които не трябва да бъдат тествани строго.

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

Сега как решаваме кои характеристики да не бъдат тествани?

Имаме следните аспекти, по които можем да решим коя функция да не бъде тествана:

• Както виждаме по-горе Помогне характеристиките няма да бъдат тествани, тъй като са написани и разработени от техническия писател и прегледани от друг професионален писател.
• Нека приемем, че имаме едно приложение, което има P, Q, R и S функции, които трябва да бъдат разработени въз основа на изискванията. Но тук функцията S вече е проектирана и използвана от друга компания. Така че екипът за разработка ще закупи S от тази компания и ще се интегрира с допълнителни функции като P, Q и R.

Сега няма да извършваме функционално тестване на функцията S, защото тя вече е била използвана в реално време. Но ние ще направим интеграционното тестване и системното тестване между функциите P, Q, R и S, защото новите функции може да не работят правилно с функцията S, както можем да видим на изображението по-долу:

• Да предположим, че в първото издание на продукта, елементите, които са разработени, като напр P, Q, R, S, T, U, V, W…..X, Y, Z . Сега клиентът ще предостави изискванията за новите функции, които подобряват продукта във втората версия и новите функции са A1, B2, C3, D4 и E5.

След това ще напишем обхвата по време на тестовия план като

Обхват

Функции за тестване

A1, B2, C3, D4, E5 (нови функции)

P, Q, R, S, T

Характеристики, които не се тестват

W…..X, Y, Z

Следователно първо ще проверим новите функции и след това ще продължим със старите функции, защото това може да бъде засегнато след добавянето на новите функции, което означава, че ще засегне и областите на въздействие, така че ще направим един кръг от регресивно тестване за P, Q , R…, T функции.

Методология на теста:

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

Например, за самостоятелно приложение, като напр Адобе Фотошоп , ще извършим следните видове тестове:

Тестване на дим → Функционално тестване → Тестване на интеграция → Тестване на системата → Тестване за adhoc → Тестване за съвместимост → Тестване на регресия → Тестване за глобализация → Тестване за достъпност → Тестване за използваемост → Тестване за надеждност → Тестване за възстановяване → Тестване за инсталиране или деинсталиране

И да предположим, че трябва да тестваме https://www.jeevansathi.com/ приложение, така че ще извършим следните видове тестове:

Приближаване

Този атрибут се използва за описание на потока на приложението, докато се извършва тестване и за бъдеща справка.

Можем да разберем потока на приложението с помощта на следните аспекти:

Като напишете сценариите на високо ниво Като напишете графиката на потока

Като напишете сценариите на високо ниво

Например , да предположим, че тестваме Gmail приложение:

• Влезте в Gmail - изпраща имейл и проверява дали е в страницата Изпратени елементи
• Влезте в …….
• ……
• …....

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

Като напишете графиката на потока

Графиката на потока е написана, тъй като писането на сценариите от високо ниво отнема малко време, както можем да видим на изображението по-долу:

Ние създаваме графики на потока, за да постигнем следните предимства като:

• Покритието е лесно
• Сливането е лесно

Подходът може да бъде класифициран в две части, които са както следва:

• Подход отгоре надолу
• Подход отдолу нагоре

Успение Богородично

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

Риск

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

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

План за смекчаване или план за действие при извънредни ситуации

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

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

Във всеки продукт, предположение което ще направим е, че всичките 3 тестови инженери ще бъдат там до завършването на продукта и на всеки от тях са присвоени различни модули като P, Q и R. В този конкретен сценарий, риск може да е така, ако тестващият инженер напусне проекта по средата му.

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

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

как да извикате метод в java

• Гледната точка на клиента
• Ресурсен подход
• Техническо становище

Роля и отговорност

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

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

Роля: Тест мениджър

Име: Райън

Отговорност:

• Подгответе (напишете и прегледайте) тестовия план
• Проведете срещата с екипа за разработка
• Проведете срещата с екипа за тестване
• Проведете срещата с клиента
• Провеждане на една месечна среща
• Подпишете бележката за изданието
• Справяне с ескалации и проблеми

Роля: Водещ тест

Име: Харви

Отговорност:

• Подгответе (напишете и прегледайте) тестовия план
• Провеждайте ежедневна среща за изправяне
• Прегледайте и одобрете тестовия случай
• Подгответе RTM и отчети
• Задайте модули
• График за обработка

Роля: Инженер по тестване 1, Инженер по тестване 2 и Инженер по тестване 3

Име: Луис, Джесика, Дона

Задайте модули: M1, M2 и M3

Отговорност:

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

График

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

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

Например

• Писане на тестови случаи
• Процес на изпълнение

Проследяване на дефекти

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

Следват различни аспекти на проследяването на дефекти:

Техники за проследяване на грешката
…..
……
……
……Инструменти за проследяване на грешки
Можем да коментираме името на инструмента, който ще използваме за проследяване на бъгове. Някои от най-често използваните инструменти за проследяване на грешки са Jira, Bugzilla, Mantis и Trac и др.<Тежест
Тежестта може да бъде както следва:
Блокер или шоустопер
…..
….. (Обяснете го с пример в тестовия план)
Например , ще има дефект в модула; не можем да отидем по-нататък, за да тестваме други модули, защото ако грешката е блокирана, можем да продължим да проверяваме други модули.
Критичен
……
….. (Обяснете го с пример в тестовия план)
В тази ситуация дефектите ще се отразят на бизнеса.
майор
….
…. (Обяснете го с пример в тестовия план)
Незначителен
…..
….. (Обяснете го с пример в тестовия план)
Тези дефекти са тези, които засягат външния вид и усещането на приложението.Приоритет
Високо-P1
…..
Среден-P2
…..
Нисък P3
…..
…..
P4

Следователно, въз основа на приоритета на грешки като висок, среден и нисък, ние ще го категоризираме като P1, P2, P3 и P4.

Тестови среди

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

The софтуерна конфигурация означава подробности за различни Операционна система като Windows, Linux, UNIX и Mac и различни Браузъри като Google Chrome, Firefox, Opera, Internet Explorer , и така нататък.

И на хардуерна конфигурация означава информация за различни размери на RAM, ROM и процесорите .

Например

• The Софтуер включва следното:

сървър

Забележка: Горните сървъри са услугите, които се използват от тестващия екип за тестване на приложението.

Клиент

Забележка: Горните подробности предоставят различните операционни системи и браузъри, в които тестващият екип ще тества приложението.

• The Хардуер включва следното:

сървър : Sun StarCat 1500

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

клиент:

Той има следната конфигурация, която е както следва:

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

Процес за инсталиране на софтуера
……
…..
…..

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

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

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

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

Критериите за участие съдържат следните условия:

• Тестването на бялата кутия трябва да приключи.
• Разберете и анализирайте изискването и подгответе тестовите документи или когато тестовите документи са готови.
• Тестовите данни трябва да са готови.
• Изградете или приложението трябва да бъде подготвено
• Модулите или функциите трябва да бъдат присвоени на различните тестови инженери.
• Необходимият ресурс трябва да е готов.

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

Критериите за излизане съдържат следните условия:

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

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

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

Автоматизация на тестовете

В това ще решим следното:

• Коя функция трябва да бъде автоматизирана и коя не трябва да бъде автоматизирана?
• Кой инструмент за автоматизация на тестове ще използваме в коя рамка за автоматизация?

Ние автоматизираме тестовия случай само след първото издание.

Тук възниква въпросът на какво основание ние ще решите кои характеристики трябва да бъдат тествани?

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

Сега, как решаваме кои функции няма да бъдат тествани?

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

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

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

Оценка на усилието

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

Доставка на теста

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

План за тестване Тестови случаи Тестови скриптове RTM (Матрица за проследяване на изискванията) Доклад за дефект Доклад за изпълнение на теста Графики и показатели Бележки към изданието

Графики и показатели

Графика

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

Както виждаме, имаме пет различни графики, които показват различните аспекти на процеса на тестване.

Графика 1: В това ще покажем колко дефекта са идентифицирани и колко дефекта са коригирани във всеки модул.

Графика 2: Фигура едно показва колко критични, големи и незначителни дефекти са идентифицирани за всеки модул и колко са коригирани за съответните им модули.

Графика 3: В тази конкретна графика ние представяме изградете мъдра графика , което означава, че във всяка компилация колко дефекта са идентифицирани и коригирани за всеки модул. Въз основа на модула сме определили грешките. Ще добавим Р за да покаже броя на дефектите в P и Q, и ние също добавяме С за да покаже дефектите в P, Q и R.

Графика 4: Водещият тест ще проектира Анализ на тенденции на грешки графика, която се създава всеки месец, и я изпращайте и на ръководството. И това е точно като прогноза, която се прави в края на продукта. И тук също можем оценете корекциите на грешки както можем да наблюдаваме това дъга има възходяща тенденция в изображението по-долу.

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

Метрика

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

Например

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

Бележка освобождаване: Това е документ, който се изготвя по време на пускането на продукта и се подписва от Мениджъра на теста.

В изображението по-долу можем да видим, че крайният продукт е разработен и внедрен на клиента, а името на най-новата версия е Бета .

The Бележка освобождаване се състои от следното:

• Ръководство за употреба.
• Списък с висящи и открити дефекти.
• Списък с добавени, модифицирани и изтрити функции.
• Списък на платформата (операционна система, хардуер, браузъри), на която е тестван продуктът.
• Платформа, в която продуктът не е тестван.
• Списък с коригирани грешки в текущата версия и списък с коригирани грешки в предишната версия.
• Процес на инсталиране
• Версии на софтуера

Например

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

Шаблон

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

• Шаблон за тестов случай
• Шаблон за преглед на тестов случай
• RTM шаблон
• Шаблон за доклад за грешка
• Доклад за изпълнение на теста

Нека видим един образец на документ за тестов план

Страница 1

Страница3-страница18

Страница-20

В страница 1 ние основно попълваме само Версии, автор, коментари и преглед от полета и след като мениджърът го одобри, ние ще споменем подробностите в Одобрен до и дата на одобрение полета.

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

Забележка:

Кой пише плана за теста?

• Тестово олово → 60%
• Тест мениджър→20%
• Тестов инженер→20%

Следователно, както виждаме от по-горе, в 60% от продукта тестовият план е написан от Test Lead.

Кой преглежда тестовия план?

• Тестово олово
• Тест мениджър
• Тест инженер
• Клиент
• Екип за развитие

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

Кой одобрява тестовия план?

• Клиент
• Тест мениджър

Кой пише тестовия случай?

• Тестово олово
• Тест инженер

Кой преглежда тестовия случай?

• Тест инженер
• Тестово олово
• Клиент
• Екип за развитие

Кой одобрява тестовите случаи?

• Тест мениджър
• Тестово олово
• Клиент

Насоки за план за тестване

• Свийте тестовия си план.
• Избягвайте припокриване и излишък.
• Ако смятате, че не се нуждаете от раздел, който вече е споменат по-горе, изтрийте този раздел и продължете напред.
• Бъдете конкретни. Например, когато посочите софтуерна система като част от тестовата среда, тогава споменете версията на софтуера вместо само името.
• Избягвайте дългите параграфи.
• Използвайте списъци и таблици, когато е възможно.
• Актуализирайте плана, когато е необходимо.
• Не използвайте остарял и неизползван документ.

Значение на тестовия план

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