TechCodeview

План тестирања је детаљан документ који описује области и активности тестирања софтвера. Он описује стратегију тестирања, циљеве, распоред тестирања, потребне ресурсе (људски ресурси, софтвер и хардвер), процену теста и резултате тестирања.

План тестирања је основа тестирања сваког софтвера. То је најважнија активност која обезбеђује доступност свих спискова планираних активности у одговарајућем редоследу.

План тестирања је шаблон за спровођење активности тестирања софтвера као дефинисаног процеса који у потпуности прати и контролише менаџер тестирања. План тестирања припрема водитељ теста (60%), менаџер за тестирање (20%) и тест инжењер (20%).

Врсте плана тестирања

Постоје три врсте плана тестирања

• Мастер тест план
• План фаза испитивања
• Тестирање специфичних планова испитивања

Мастер тест план

Главни план тестирања је тип плана тестирања који има више нивоа тестирања. Укључује комплетну стратегију тестирања.

План фаза испитивања

План фазног тестирања је тип плана тестирања који се бави било којом фазом стратегије тестирања. На пример, листа алата, листа тест случајева итд.

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

Специфичан план тестирања дизајниран за главне типове тестирања као што су тестирање безбедности, тестирање оптерећења, тестирање перформанси, итд. Другим речима, посебан план тестирања дизајниран за нефункционално тестирање.

Како написати план тестирања

Израда плана тестирања је најважнији задатак процеса управљања тестом. Према ИЕЕЕ 829, следите следећих седам корака да бисте припремили план тестирања.

• Прво, анализирајте структуру и архитектуру производа.
• Сада дизајнирајте стратегију тестирања.
• Дефинишите све циљеве теста.
• Дефинишите област тестирања.
• Дефинишите све употребљиве ресурсе.
• Распоредите све активности на одговарајући начин.
• Одредите све резултате теста.

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

План тестирања се састоји од различитих делова, који нам помажу да изведемо целокупну активност тестирања.

Циљеви: Састоји се од информација о модулима, карактеристикама, тестним подацима итд., који указују на циљ апликације значи понашање апликације, циљ итд.

Обим: Садржи информације које треба тестирати са одговарајућом апликацијом. Опсег се даље може поделити на два дела:

• У обиму
• Оут сцопе

У обиму: Ово су модули које треба ригорозно (детаљно) тестирати.

Ван опсега: Ово су модули, који не морају бити ригорозно тестирани.

На пример , Претпоставимо да имамо Гмаил апликацију за тестирање, где карактеристике које треба тестирати као такав Саставите пошту, послате ставке, пријемно сандуче, недовршене анд тхе карактеристике које се не тестирају као такав Помоћ , и тако даље, што значи да ћемо у фази планирања одлучити која функционалност треба да се провери или не на основу временског ограничења датог у производу.

Сада како одлучујемо које карактеристике неће бити тестиране?

Имамо следеће аспекте где можемо да одлучимо која карактеристика неће бити тестирана:

• Као што видимо изнад тога Помоћ карактеристике неће бити тестиране, јер их је написао и развио технички писац, а прегледао их је други професионални писац.
• Претпоставимо да имамо једну апликацију која има П, К, Р и С карактеристике, које треба развити на основу захтева. Али овде је С функцију већ дизајнирала и користила нека друга компанија. Дакле, развојни тим ће купити С од те компаније и интегрисати се са додатним функцијама као што су П, К и Р.

Сада нећемо вршити функционално тестирање функције С јер је већ коришћена у реалном времену. Али урадићемо тестирање интеграције и тестирање система између П, К, Р и С функција јер нове функције можда неће радити исправно са С функцијом као што можемо видети на слици испод:

• Претпоставимо да су у првом издању производа развијени елементи, као нпр П, К, Р, С, Т, У, В, В…..Кс, И, З . Сада ће клијент обезбедити захтеве за нове функције које побољшавају производ у другом издању и нове функције су А1, Б2, Ц3, Д4 и Е5.

Након тога ћемо написати обим током плана тестирања као

Обим

питхон рстрип

Карактеристике које треба тестирати

А1, Б2, Ц3, Д4, Е5 (нове функције)

П, К, Р, С, Т

Карактеристике које се не тестирају

В…..Кс, И, З

Због тога ћемо прво проверити нове карактеристике, а затим наставити са старим карактеристикама јер то може бити погођено након додавања нових карактеристика, што значи да ће утицати и на подручја утицаја, тако да ћемо урадити један круг регресијског тестирања за П, К , Р…, Т карактеристике.

Методологија тестирања:

Садржи информације о обављању различите врсте тестирања као што је функционално тестирање, тестирање интеграције и тестирање система, итд. на апликацији. У овом случају ћемо одлучити коју врсту тестирања; извршићемо на различитим функцијама на основу захтева апликације. И овде би требало да дефинишемо какву врсту тестирања ћемо користити у методологијама тестирања како би сви, попут менаџмента, развојног тима и тима за тестирање, могли лако да разумеју јер услови тестирања нису стандардни.

На пример, за самосталну примену као нпр Адобе Пхотосхоп , извршићемо следеће врсте тестирања:

Тестирање дима→ Функционално тестирање → Тестирање интеграције → Тестирање система → Адхоц тестирање → Тестирање компатибилности → Регресионо тестирање → Тестирање глобализације → Тестирање приступачности → Тестирање употребљивости → Тестирање поузданости → Тестирање опоравка → Тестирање инсталације или деинсталације

И претпоставимо да морамо да тестирамо хттпс://ввв.јеевансатхи.цом/ апликације, тако да ћемо извршити следеће врсте тестирања:

Приступ

Овај атрибут се користи за описивање тока апликације током извођења тестирања и за будућу референцу.

Можемо разумети ток апликације уз помоћ доле наведених аспеката:

Писањем сценарија на високом нивоу Писањем графика тока

Писањем сценарија на високом нивоу

На пример , претпоставимо да тестирамо Гмаил апликација:

• Пријавите се на Гмаил- шаље е-пошту и проверите да ли се налази на страници Послате ставке
• Пријавите се на …….
• ……
• …....

Ово пишемо да бисмо описали приступе који се морају предузети за тестирање производа и само за критичне карактеристике где ћемо писати сценарије високог нивоа. Овде се нећемо фокусирати на покривање свих сценарија јер одређени тест инжењер може одлучити које карактеристике треба тестирати или не.

Писањем графика тока

Графикон тока је написан зато што писање сценарија високог нивоа захтева мало времена, као што можемо видети на слици испод:

Правимо графиконе тока да бисмо остварили следеће предности као што су:

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

Приступ се може класификовати у два дела, а то су:

• Приступ од врха до дна
• Приступ одоздо ка врху

Претпоставка

Садржи информације о проблему или проблему који се можда догодио током процеса тестирања и када пишемо планове тестирања, осигуране претпоставке би биле направљене као што су ресурси и технологије, итд.

Ризик

Ово су изазови са којима треба да се суочимо да бисмо тестирали апликацију у тренутном издању и ако претпоставке не успеју, онда су укључени ризици.

На пример, ефекат за апликацију, датум објављивања постаје одложен.

План ублажавања или План за ванредне ситуације

То је резервни план који је спреман да превазиђе ризике или проблеме.

Хајде да видимо један пример за претпоставку, ризик и план за ванредне ситуације заједно јер су међусобно повезани.

У било ком производу, претпоставка направићемо да сва 3 тест инжењера буду ту до завршетка производа и сваком од њих су додељени различити модули као што су П, К и Р. У овом конкретном сценарију, ризик могло би бити то ако тест инжењер напусти пројекат усред њега.

Стога шема непредвиђених случајева биће додељен примарни и подређени власник свакој особини. Дакле, ако један тест инжењер оде, подређени власник преузима ту специфичну функцију и такође помаже новом тест инжењеру, тако да он/она може да разуме модуле који су им додељени.

Претпоставке, ризик и план ублажавања или непредвиђених ситуација су увек прецизни на самом производу. Различите врсте ризика су следеће:

• Перспектива купаца
• Приступ ресурсима
• Техничко мишљење

Улога и одговорност

Он дефинише комплетан задатак који треба да обави цео тим за тестирање. Када дође велики пројекат, онда Тест Манагер је особа која пише план тестирања. Ако постоје 3-4 мала пројекта, онда ће тест менаџер доделити сваки пројекат сваком водитељу теста. Затим, тест вођа пише план тестирања за пројекат, који му/јој је додељен.

Погледајмо један пример где ћемо разумети улоге и одговорност Тест менаџера, тест вође и тест инжењера.

буббле сорт јава

Улога: Тест менаџер

Име: Рајан

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

• Припремите (напишите и прегледајте) план тестирања
• Спроведите састанак са развојним тимом
• Водите састанак са тимом за тестирање
• Спроведите састанак са купцем
• Одржавајте један месечни станд уп састанак
• Одјавите белешку о издању
• Руковање ескалацијама и проблемима

Улога: Тест Леад

Име: Харвеи

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

• Припремите (напишите и прегледајте) план тестирања
• Одржавајте свакодневни станд уп састанак
• Прегледајте и одобрите тест случај
• Припремите РТМ и извештаје
• Доделите модуле
• Распоред руковања

Улога: Инжењер за испитивање 1, Инжењер за испитивање 2 и Инжењер за испитивање 3

Име: Лоуис, Јессица, Донна

Доделите модуле: М1, М2 и М3

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

• Напишите, прегледајте и извршите тестне документе који се састоје од тест случајева и тест сценарија
• Прочитајте, прегледајте, разумејте и анализирајте захтев
• Напишите ток апликације
• Извршите тестни случај
• РТМ за одговарајуће модуле
• Праћење дефекта
• Припремите извештај о извршењу теста и проследите га водитељу теста.

Распоред

Користи се за објашњење времена за рад, шта треба да се уради или овај атрибут покрива када тачно свака активност тестирања треба да почне и да се заврши? А тачни подаци се такође помињу за сваку активност тестирања за одређени датум.

Стога, као што можемо видети на слици испод, за одређену активност ће постојати датум почетка и датум завршетка; за свако тестирање одређене верзије, постојаће одређени датум.

На пример

• Писање тест случајева
• Процес извршења

Праћење дефекта

Обично се то ради уз помоћ алата јер не можемо ручно пратити статус сваке грешке. Такође коментаришемо како саопштавамо грешке које су идентификоване током процеса тестирања и шаљемо их назад развојном тиму и како ће развојни тим одговорити. Овде такође помињемо приоритет грешака као што су висок, средњи и низак.

Следе различити аспекти праћења дефекта:

Технике праћења грешке
…..
……
……
……Алати за праћење грешака
Можемо да коментаришемо назив алата који ћемо користити за праћење грешака. Неки од најчешће коришћених алата за праћење грешака су Јира, Бугзилла, Мантис и Трац, итд.<Озбиљност
Озбиљност може бити следећа:
Блоцкер или сховстоппер
…..
….. (Објасните то примером у плану тестирања)
На пример , биће квар у модулу; не можемо ићи даље да тестирамо друге модуле јер ако је грешка блокирана, можемо наставити да проверавамо друге модуле.
Критичан
……
….. (Објасните то примером у плану тестирања)
У овој ситуацији, недостаци ће утицати на пословање.
Главни
….
…. (Објасните то примером у плану тестирања)
Минор
…..
….. (Објасните то примером у плану тестирања)
Ови недостаци су они који утичу на изглед и осећај апликације.Приоритет
Хигх-П1
…..
Средњи-П2
…..
Лов-П3
…..
…..
П4

Стога, на основу приоритета грешака као што су високи, средњи и ниски, категорисаћемо их као П1, П2, П3 и П4.

Тест Енвиронментс

Ово су окружења у којима ћемо тестирати апликацију, а овде имамо две врсте окружења, а то су од софтвер и хардвера конфигурацију.

Тхе конфигурацију софтвера означава детаље о различитим Оперативни системи као такав Виндовс, Линук, УНИКС и Мац и разне Прегледачи као Гоогле Цхроме, Фирефок, Опера, Интернет Екплорер , и тако даље.

И тхе конфигурацију хардвера означава информације о различитим величинама РАМ, РОМ и процесори .

На пример

• Тхе Софтвер укључује следеће:

Сервер

Напомена: Горе наведени сервери су сервиси које тим за тестирање користи за тестирање апликације.

Клијент

Напомена: Горе наведени детаљи дају различите оперативне системе и претраживаче у којима ће тим за тестирање тестирати апликацију.

• Тхе Хардвер укључује следеће:

Сервер : Сун СтарЦат 1500

Тим за тестирање може да користи овај сервер да тестира своју апликацију.

Клијент:

примарни кључ и композитни кључ у скл

Има следећу конфигурацију, која је следећа:

Напомена: Он ће обезбедити конфигурацију система тест инжењера који је тим за тестирање.

Процес инсталирања софтвера
……
…..
…..

Развојни тим ће обезбедити конфигурацију како да инсталирате софтвер. Ако развојни тим још увек не обезбеди процес, онда ћемо га записати као развој заснован на задацима (ТБД) у плану тестирања.

Критеријуми за улазак и излазак

То је неопходан услов, који треба да буде задовољен пре почетка и заустављања процеса тестирања.

Критеријуми за улазак

Критеријуми за улазак садрже следеће услове:

• Тестирање беле кутије треба да буде завршено.
• Разумети и анализирати захтеве и припремити документе за тестирање или када су тест документи спремни.
• Подаци теста би требали бити спремни.
• Буилд или апликација мора бити припремљена
• Модули или карактеристике морају бити додељени различитим инжењерима за испитивање.
• Неопходан ресурс мора бити спреман.

Излазни критеријуми

Критеријуми за излазак садрже следеће услове:

• Када се изврше сви тест случајеви.
• Већина тест случајева мора бити положио .
• Зависи од озбиљности грешака, што значи да не сме постојати никакав блокатор или велика грешка, док неке мање грешке постоје.

Пре него што почнемо да обављамо функционално тестирање, све наведено Критеријуми за улазак треба следити. Након што смо извршили функционално тестирање и пре него што урадимо интеграцијско тестирање, онда Излазни критеријуми за функционално тестирање треба пратити јер се о % излазних критеријума одлучује на састанку и са развојним и са тест менаџером јер њихова сарадња може постићи проценат. Али ако се не поштују излазни критеријуми функционалног тестирања, онда не можемо наставити даље са тестирањем интеграције.

Ево на основу тежине грешке значи да би тим за тестирање одлучио да настави даље за наредне фазе.

Тест Аутоматион

При томе ћемо одлучити следеће:

• Која функција мора бити аутоматизована, а не аутоматизована?
• Који алат за аутоматизацију тестирања ћемо користити на ком оквиру за аутоматизацију?

Аутоматизујемо тест случај тек након првог издања.

Овде се поставља питање на основу чега ми воља одлучити које карактеристике треба тестирати?

На горњој слици, као што видимо да најчешће коришћене функције треба да се тестирају изнова и изнова. Претпоставимо да морамо да проверимо Гмаил апликацију где су основне функције Саставите пошту, послате ставке и пријемно сандуче . Тако да ћемо тестирати ове карактеристике, јер док обављамо ручно тестирање, потребно је више времена, а такође постаје монотон посао.

Сада, како одлучујемо које карактеристике неће бити тестиране?

Претпоставимо помоћ функција Гмаил апликације се не тестира изнова и изнова јер се ове функције не користе редовно, тако да не морамо често да је проверавамо.

Али ако су неке функције нестабилне и имају много грешака , што значи да нећемо тестирати те карактеристике јер се морају тестирати изнова и изнова током ручног тестирања.

Ако постоји функција која се мора често тестирати , али очекујемо промену захтева за ту функцију, тако да је не проверавамо јер је промена ручних тест случајева угоднија у поређењу са променом у скрипти за тестирање аутоматизације.

Процена напора

При томе ћемо планирати труд који сваки члан тима треба да уложи.

Тест Деливерабле

Ово су документи који су резултат тима за тестирање, који смо заједно са производом предали купцу. Укључује следеће:

План тестирања Тест случајева Тест Скрипте РТМ (матрица следљивости захтева) Извештај о грешци Извештај о извршењу теста Графикони и метрика Белешке о издању

Графикони и метрика

Граф

У овом случају ћемо разговарати о врстама графова ми ћемо послати, а такође ћемо дати узорак сваког графикона.

Као што видимо, имамо пет различитих графикона који приказују различите аспекте процеса тестирања.

Графикон 1: У овоме ћемо показати колико је дефеката идентификовано и колико недостатака је отклоњено у сваком модулу.

Графикон 2: Слика један показује колико је критичних, већих и мањих кварова идентификовано за сваки модул и колико је поправљено за њихове одговарајуће модуле.

Графикон 3: У овом конкретном графикону представљамо изградити мудар графикон , што значи да у свакој градњи колико је дефеката идентификовано и поправљено за сваки модул. На основу модула смо утврдили грешке. Додаћемо Р да прикажемо број недостатака у П и К, а такође додајемо С да покаже недостатке у П, К и Р.

Графикон 4: Тест провод ће дизајнирати Анализа тренда грешака графикон који се прави сваког месеца и шаље га и Управи. И то је исто као предвиђање које се ради на крају производа. А овде можемо и ми оцените исправке грешака како то можемо приметити арц има ан тенденција навише на слици испод.

Графикон 5: Тхе Тест Манагер је дизајнирао ову врсту графикона. Овај графикон има за циљ да разуме јаз у процени грешака и стварних грешака које су се појавиле, а овај графикон такође помаже да се унапреди процена грешака у будућности.

вештачка интелигенција и интелигентни агенти

метрике

Као и горе, креирамо график дистрибуције грешака који се налази на слици 1, а уз помоћ горе наведених података дизајнираћемо и метрику.

На пример

На горњој слици чувамо евиденцију свих тест инжењера у одређеном пројекту и колико је дефеката идентификовано и отклоњено. Ове податке можемо користити и за будућу анализу. Када дође до новог захтева, можемо одлучити коме да обезбедимо изазовну функцију за тестирање на основу броја дефеката које су раније открили према горе наведеним показатељима. И бићемо у бољој ситуацији да знамо ко може веома добро да се носи са проблематичним карактеристикама и пронађе максималан број недостатака.

Напомена о издању: То је документ који се припрема током пуштања производа и потписује га Тест Манагер.

На доњој слици можемо видети да је финални производ развијен и примењен купцу, а име најновијег издања је Бета .

Тхе Напомена о издању састоји се од следећег:

• Упутство за коришћење.
• Списак нерешених и отворених недостатака.
• Листа додатих, измењених и избрисаних функција.
• Списак платформи (оперативни систем, хардвер, претраживачи) на којој је производ тестиран.
• Платформа на којој се производ не тестира.
• Листа грешака исправљених у тренутном издању и листа исправљених грешака у претходном издању.
• Процес инсталације
• Верзије софтвера

На пример

Претпостављам да Бета је друго издање апликације након првог издања Алпха је пуштен. Неки од дефеката идентификованих у првом издању и који су исправљени у каснијем издању. И овде ћемо такође истаћи листу новододатих, измењених и избрисаних функција од алфа издања до бета издања.

Темплате

Овај део садржи све шаблоне за документе који ће се користити у производу, а сви тест инжењери ће користити само ове шаблоне у пројекту да би одржали конзистентност производа. Овде имамо различите типове шаблона који се користе током целог процеса тестирања као што су:

• Шаблон за тест случаја
• Шаблон за преглед тестних случајева
• РТМ шаблон
• Шаблон извештаја о грешци
• Извештај о извршењу теста

Хајде да видимо један узорак документа плана тестирања

Страна 1

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

Страница-20

На страници 1 првенствено попуњавамо само Верзије, аутор, коментари и рецензије поља, а након што га менаџер одобри, навешћемо детаље у Одобрено до и датум одобрења поља.

Углавном план тестирања одобрава менаџер тестирања, а тест инжењери га само прегледају. А када дођу нове функције, изменићемо план тестирања и извршити неопходне измене Версион поље, а затим ће поново бити послато на даљи преглед, ажурирање и одобрење менаџеру. План тестирања мора бити ажуриран сваки пут када дође до било каквих промена. На страни 20, Референце наведите детаље о свим документима које ћемо користити за писање документа плана тестирања.

Белешка:

Ко пише план тестирања?

• Пробни потенцијал→60%
• Менаџер тестирања→20%
• Тест инжењер→20%

Према томе, као што видимо одозго да у 60% производа план тестирања пише Тест Леад.

Ко прегледа план тестирања?

• Тест Леад
• Тест Манагер
• Тест инжењер
• Цустомер
• Развојни тим

Инжењер тестирања прегледа план тестирања из перспективе свог модула, а менаџер тестирања прегледа план тестирања на основу мишљења корисника.

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

• Цустомер
• Тест Манагер

Ко пише тест случај?

• Тест Леад
• Тест Енгинеер

Ко прегледа тест случај?

нп нуле

• Тест Енгинеер
• Тест Леад
• Цустомер
• Развојни тим

Ко одобрава тест случајеве?

• Тест Манагер
• Тест Леад
• Цустомер

Смернице за план тестирања

• Скупите план тестирања.
• Избегавајте преклапање и сувишност.
• Ако мислите да вам није потребан одељак који је већ поменут изнад, избришите тај одељак и наставите даље.
• Бити јединствен. На пример, када наведете софтверски систем као део тестног окружења, наведите верзију софтвера уместо само имена.
• Избегавајте дугачке пасусе.
• Користите листе и табеле где год је то могуће.
• Ажурирајте план када је потребно.
• Немојте користити застарели и некоришћени документ.

Важност плана тестирања

• План тестирања даје правац нашем размишљању. Ово је као правилник који се мора поштовати.
• План тестирања помаже у одређивању неопходних напора да се потврди квалитет софтверске апликације која се тестира.
• План тестирања помаже тим људима да разумеју детаље теста који се односе на спољашњост као што су програмери, пословни менаџери, купци итд.
• Важни аспекти као што су распоред тестирања, стратегија тестирања, обим тестирања итд. су документовани у плану тестирања тако да менаџерски тим може да их прегледа и поново користи за друге сличне пројекте.