difference between test plan
На примерима сазнајте која је разлика између плана испитивања, стратегије тестирања, тест случаја, скрипте за тест, сценарија и услова испитивања:
Тестирање софтвера укључује неколико основних, као и важних концепата којих сваки испитивач софтвера треба да буде упознат.
Овај чланак ће објаснити различите концепте тестирања софтвера заједно са њиховим упоређивањем.
Тест план вс Тест Стратеги, Тест Цасе вс Тест Сцрипт, Тест Тест вс Тест Цондитион анд Тест Тест вс Тест Суите су детаљно објашњени за ваше лако разумевање.
=> Кликните овде за комплетну серију водича за план испитивања
Горње питање које је поставио Саси Ц. најчешће је постављано питање у нашем Час тестирања софтвера и увек кажем нашим учесницима да са искуством тешко примећујемо ове речи и да оне постају део нашег речника.
Али често их забуна окружује и у овом чланку покушавам да дефинишем неколико уобичајених термина.
Разни концепти за тестирање софтвера
У наставку су наведени различити концепти тестирања софтвера заједно са њиховим поређењем.
Почнимо!!
Шта ћете научити:
- Разлика између плана и стратегије испитивања
- Разлика између тест случаја и тест скрипте
- Разлика између сценарија теста и услова теста
- Разлика између поступка испитивања и скупа тестова
- Закључак
Разлика између плана и стратегије испитивања
Стратегија тестирања и план испитивања су два важна документа у животном циклусу тестирања било ког пројекта. Овде покушавамо да вам пружимо детаљно знање о стратегији испитивања и документима плана испитивања.
План испитивања
План испитивања може се дефинисати као документ који дефинише обим, циљ и приступ тестирању софтверске апликације. План испитивања је термин и испоручив.
План теста је документ који наводи све активности у КА пројекту, распоређује их, дефинише обим пројекта, улоге и одговорности, ризике, критеријуме за улазак и излазак, циљ теста и све остало чега се можете сјетити.
План теста је како ја волим да зовем „супер документ“ који наводи све што треба да се зна и треба. Молимо вас проверите овај линк за више информација и узорак.
План испитивања биће израђен на основу захтева. Током додељивања посла инжењерима за тестирање, из неких разлога један од тестера бива замењен другим. Овде се испитни план ажурира.
Стратегија тестирања описује приступ тестирања и све остало што га окружује. Разликује се од теста, у смислу да је стратегија теста само подскуп теста. То је хардцоре тест документ који је у одређеној мери генерички и статичан. Такође постоји аргумент око тога на којим нивоима се користи стратегија или план тестирања, али заиста не видим никакву разлику.
Пример: План теста даје информације о томе ко ће и када тестирати. На пример, Модул 1 тестираће „Кс тестер“. Ако тестер И из неког разлога замени Кс, план теста мора бити ажуриран.
Документ плана испитивања
Тест план је документ који пружа комплетне информације о задацима тестирања у вези са софтверским пројектом. Пружа детаље као што су Обим тестирања, Врсте тестирања, Циљеви, Методологија испитивања, Напор тестирања, Ризици и непредвиђени случајеви, Критеријуми издања, Испоручиви резултати итд. Прати могуће тестове који ће се покренути на систему након кодирања.
Очигледно је да се план испитивања мења. У почетку ће се израдити нацрт плана испитивања заснован на тадашњој јасноћи пројекта. Овај почетни план ће се мењати како пројекат буде напредовао. Руководилац тест тима или вођа теста могу припремити документ плана теста. Описује спецификације и подложан је променама на основу истих.
Шта тестирати, када тестирати, ко ће тестирати и како тестирати биће дефинисано у плану теста. План тестирања разврстаће листу проблема, зависности и основних ризика.
Врсте плана испитивања
Испитни планови могу бити различитих врста на основу фазе испитивања. У почетку ће постојати план главног теста за целокупно извршење пројекта. Одвојени планови испитивања могу се креирати за одређене типове испитивања као што су тестирање система, тестирање интеграције система, тестирање прихваћања корисника итд.
Други приступ је да постоје одвојени планови испитивања за функционално и нефункционално испитивање. У овом приступу, тестирање ће имати засебан план испитивања.
Садржај документа о плану испитивања ( Структура плана испитивања ИЕЕЕ-829 )
Тешко је извући јасан формат плана теста. Формат плана испитивања може се разликовати у зависности од пројекта који се ради. ИЕЕЕ је дефинисао стандард за планове испитивања који су описани као структура плана испитивања ИЕЕЕ-829.
Испод можете пронаћи ИЕЕЕ препоруке за стандардни садржај плана испитивања:
- Идентификатор плана испитивања
- Увод
- Испитни предмети
- Питања софтверског ризика
- Карактеристике које треба тестирати
- Карактеристике које се не тестирају
- Приступ
- Критеријуми за пролаз / неуспех (или) критеријуми за прихватање
- Критеријуми суспензије и захтеви за наставак
- Испитни резултати
- Пробни задаци
- Захтеви заштите животне средине
- Потребе за кадровима и обуком
- Одговорности
- Распоред
- Одобрења
Предложено читање => Водич за план испитивања - савршен водич
како проверити губитак пакета у мрежи
Тест Стратеги
Стратегија тестирања је скуп смерница које објашњавају дизајн теста и одређују како тестирање треба обавити.
Пример: Стратегија тестирања укључује детаље попут „Појединачне модуле треба да тестирају чланови тест тима“. У овом случају, ко то тестира, није важно - дакле, то је генеричко и промена у члану тима не мора да се ажурира, одржавајући је статичном.
Документ о стратегији испитивања
Сврха стратегије тестирања је да дефинише приступ тестирања, врсте тестова, тест окружења и алате који ће се користити за тестирање и детаље на високом нивоу како ће стратегија тестирања бити усклађена са другим процесима. Документ о стратегији тестирања замишљен је као живи документ и биће ажуриран ** када добијемо више јасности у вези са захтевима, СЛА параметрима, тест окружењем и приступом управљања зградом итд.
Стратегија тестирања намењена је комплетном пројектном тиму који чине пројектни спонзори, пословна мала и средња предузећа, развој апликација / интеграција, партнери за интеграцију система, тимови за конверзију података, тимови за управљање изградњом / издавањем, као што су технички водичи, архитектонски водичи и тимови за постављање и инфраструктуру.
** Неки тврде да једном дефинисана стратегија тестирања никада не би требало да се ажурира. У већини пројеката тестирања обично се ажурира како пројекат напредује.
Испод су важни одељци које документ о стратегији испитивања треба да садржи:
# 1) Преглед пројекта
Овај одељак може започети давањем прегледа организације, након чега следи кратки опис пројекта. Може садржати детаље у наставку
- Каква је била потреба за пројектом?
- Које циљеве ће пројекат постићи?
Табела скраћеница: Боље је укључити табелу са акронимима до којих би читач докумената могао да дође док се позива на документ.
# 2) Опсег захтева
Опсег захтева може обухватати опсег примене и функционални опсег
Обим примене дефинише систем који се тестира и утицај на систем због нове или промењене функционалности. Сродни системи се такође могу дефинисати.
| Систем | Утицај (нова или промењена функционалност) | Повезани систем |
|---|---|---|
| Описује како тестирати, када тестирати, ко ће тестирати и шта тестирати. | Описује се коју врсту технике треба следити и који модул тестирати. | |
| Систем А. | Нова побољшања и исправке грешака | • Систем Б. • Систем Ц. |
Функционални опсег дефинише утицај на различите модуле у систему. Овде ће бити објашњени сви сродни системи с обзиром на функционалност.
| Систем | Модул | Функционалност | Повезани систем |
|---|---|---|---|
| Систем Ц. | Модул 1 | Функционалност 1 | Систем Б. |
| Функционалност 2 | Систем Ц. |
# 3) План испитивања на високом нивоу
План испитивања је засебан документ. У стратегију испитивања може се укључити план испитивања на високом нивоу. План испитивања на високом нивоу може садржати циљеве и обим испитивања. Обим теста треба да дефинише и обим и активности изван обима.
# 4) Тест приступ
Овај одељак описује приступ тестирања који ће се следити током животног циклуса тестирања.
Према горњем дијаграму, испитивање ће се вршити у две фазе, тј. Стратегија и планирање теста и извршење теста. Фаза стратегије и планирања теста биће једнократна за целокупан програм, док ће се фазе извођења теста поновити за сваки циклус целокупног програма. Горњи дијаграм приказује различите фазе и резултате (исход) у свакој фази приступа извршењу.
Приступ тестирању треба да садржи доње потпоглавље
а) Распоред испитивања: Објасните предложени временски оквир пројекта у овом пододељку
б) Приступ функционалном испитивању: Коришћење овог пододељка даје преглед сваке фазе и одговарајућих критеријума за улазак и излазак. Различите фазе тестирања су јединствено тестирање, тестирање система, тестирање системске интеграције, тестирање прихватљивости корисника и тестирање од краја до краја.
ц) Тестирање кључних показатеља учинка:
- Приоритизација тест случаја: Дефинишите приступ приоритизацији тест случаја тако да у случају временских ограничења тест тим може извршити сценарије високог приоритета. Требало би да постоји споразум између заинтересованих страна у вези са могућим ризицима који су повезани са неизвршењем свих планираних сценарија.
- Приоритизација дефеката: Следећа тема коју ћемо овде обрадити је стратегија приоритизације дефеката. Дефинишите ниво приоритета и дајте опис сваком нивоу попут критичног, високог, средњег, итд. Такође
- Време обнављања недостатака: Време отклањања недостатака дефинише се као време између тренутка када је квар први пут подигнут и када је квар отклоњен и долази на поновно испитивање. Брзи преокрет осигурава брзо тестирање и придржавање временског распореда пројекта. За сваки ниво приоритета квара дефинишите време обраде.
| Приоритетни ниво | Време преокрета недостатака |
|---|---|
| 1 - Критично | Време одзива: 2 сата или мање Исправите спремност за миграцију: 1 радни дан или мање |
# 5) Тест покривеност
Овај одељак описује процесе које ће КА тим следити у циљу оптимизације покривања пословних / функционалних захтева у тестним сценаријима и тест случајевима. Матрица сљедивости захтјева: (РТМ) се може користити за праћење свих захтева са одговарајућим тест сценаријима и тест случајевима.
# 6) Тест окружење
Дефинишите различита доступна КА окружења. Наведите која тестирања ће се обавити у ком окружењу и ко ће их обавити. Направите резервни план за заштиту животне средине за збрињавање хитних случајева. Приступ сваком окружењу треба регулисати и јасно га позивати.
Алати за тестирање који ће се такође користити могу се поменути у овом одељку.
| Активност | Оруђе | Примедбе |
|---|---|---|
| Управљање тестом | ХП АЛМ | Наведите разлог употребе овог алата |
| Управљање недостацима | ЈИРА | Наведите разлог употребе овог алата |
# 7) Исходи и показатељи квалитета
Наведите све КА резултате
| С. Но. | Испоручиво |
|---|---|
| један | Документ о стратегији испитивања |
| два | Матрица сљедивости захтјева |
| 3 | СТ тест скрипте |
| 4 | Резиме теста |
| 5 | Списак сценарија прихватљивих за аутоматизацију |
Наведите све показатеље КА
| # | Назив метрике | Метричка дефиниција | Метричка формула | Метричка јединица мере | Извештаји у којима ће се користити метрика |
|---|---|---|---|---|---|
| један | Метрике покривености захтева (РЦМ) | Обухватање захтева КА-ом | Однос # тестираних захтева према # идентификованих захтева | % | Недељни извештај о стању квалитета, Резиме теста |
| два | Тест Цовераге | Обухват извршеног тест случаја | Однос броја извршених тест случајева / планираног броја тест случајева | % | Дневни извештај о извршењу, Недељни извештај о стању квалитета, Резиме теста |
# 8) Управљање недостацима
Јасно дефинишите стратегију управљања недостацима креирањем тока рада, методологијом праћења недостатака и поступком тријаже дефеката. Наведите одговорност за недостатке за улоге сваког испитивача. Периодична анализа кварова и анализа узрока узрока побољшаће укупан квалитет испитивања
# 9) Управљање комуникацијама
Поставите смернице за извештаје о статусу, статусне састанке и офф-схоре комуникацију.
# 10) Претпоставке, ризици и зависности
Опишите претпоставке на којима се заснива пројекат. То могу укључивати време, ресурсе и системске могућности. Опишите све зависности као што су други пројекти, доступност привремених ресурса, други рокови који могу утицати на пројекат
# 11) Додатак
У овај одељак укључите ствари као што су улоге и одговорности, радна временска зона и референце
Додатна литература=> Водич за писање документа добре стратегије тестирања .
Тест план Вс Тест Стратеги
| ТЕСТ ПЛАН | ТЕСТ СТРАТЕГИЈА |
|---|---|
| Изведен је из спецификације софтверских захтева (СРС). | Изведен је из документа о пословним захтевима (БРС). |
| Припрема га вођа теста или менаџер. | Развијају га менаџер пројекта или пословни аналитичар. |
| ИД плана теста, карактеристике које ће се тестирати, технике тестирања, задаци тестирања, карактеристике пролазе или не успевају, резултати теста, одговорности и распоред итд. Су компоненте плана теста. | Циљеви и делокруг, формати документације, процеси тестирања, структура извештавања тимова, стратегија комуникације са клијентима итд. Су компоненте стратегије тестирања. |
| Ако се догоди нова функција или промена захтева који се десио, документ теста плана се ажурира. | Стратегија тестирања одржава стандарде током припреме документа. Такође се назива и статичким документом. |
| План теста можемо припремити појединачно. | У мањим пројектима стратегија тестирања се често налази као део плана тестирања. |
| Можемо припремити план тестирања на нивоу пројекта. | Стратегију тестирања можемо користити на више пројеката. |
| Спецификације можемо описати помоћу плана испитивања. | Тест стратегија описује опште приступе. |
| План испитивања ће се мењати током пројекта. | Стратегија тестирања се обично неће променити након што буде одобрена. |
| План теста се пише након одјаве са захтева. | Стратегија тестирања се прави пре плана испитивања. |
| Планови испитивања могу бити различитих врста. Постојаће главни план и засебни план испитивања за различите врсте испитивања, као што су системски план, план испитивања перформанси итд. | За пројекат ће постојати само један документ о стратегији испитивања. |
| План испитивања треба да буде јасан и сажет. | Стратегија тестирања пружа свеобухватне смернице за пројекат у руци. |
Разлика између ова два документа је суптилна. Тест стратегија је статички документ о пројекту на високом нивоу. С друге стране, план теста ће одредити шта тестирати, када тестирати и како тестирати.
Разлика између тест случаја и тест скрипте
По мом мишљењу, ова два појма могу се користити наизменично. Да, кажем да нема разлике. Тест случај је низ корака који нам помажу да извршимо одређени тест на апликацији. Тест скрипта је такође иста ствар.
Сада постоји једна школа мишљења да је тест случај термин који се користи у окружењу ручног тестирања, а скрипта за тест користи се у окружењу аутоматизације. То је делимично тачно због нивоа удобности тестера у одговарајућим пољима, као и због тога како се алати односе на тестове (неки позивају тест скрипте, а неки их позивају на тест случајеве).
Дакле, у ствари, тест скрипта и тест случај су кораци које треба извршити на апликацији да би се потврдила њена функционалност ручно или аутоматизацијом.
Додатна литература=> Како написати ефикасне тест случајеве? и Пример предлошка за тестни случај .
| ТЕСТ СЛУЧАЈ | ТЕСТ СЦЕНАРИЈ |
|---|---|
| Основни је образац за тестирање апликације у низу. | Једном када се развијемо, скрипта ће га покретати више пута док се захтев не промени. |
| То је корак по корак поступак који се користи за тестирање апликације | То је скуп упутстава за аутоматско тестирање апликације. |
| Термин Тест Цасе се користи у окружењу за ручно тестирање. | Термин Тест Сцрипт се користи у окружењу за аутоматизацију тестирања. |
| Ради се ручно. | То се врши у формату скриптирања. |
| Развијен је у облику шаблона. | Развијен је у облику скриптирања. |
| Шаблон тест случаја укључује ИД тест одела, податке о тестирању, поступак испитивања, стварне резултате, очекиване резултате итд. | У Тест Сцрип-у можемо користити различите наредбе за развој скрипте. |
| Користи се за тестирање апликације. | Такође се користи за тестирање апликације. |
| Пример: Морамо да верификујемо дугме за пријаву у апликацији, Кораци укључују: а) Покрените апликацију. б) Проверите да ли се приказује дугме за пријаву или не. | Пример: Желимо да кликнемо на дугме са сликом у апликацији. Сценариј укључује: а) Кликните на дугме Слика. |
Разлика између сценарија теста и услова теста
Тест сценарио: То је начин да дефинишете све могуће начине за тестирање апликације. То је једна изјава која покрива све могуће начине тестирања апликације.
Тест услов: Услов испитивања је спецификација коју испитивач мора следити за тестирање апликације.
Ово је показивач у једном реду који тестери креирају као почетни, прелазни корак у фазу дизајнирања теста. Ово је углавном једноредна дефиниција „Шта“ коју ћемо тестирати с обзиром на одређену особину. Обично су тест сценарији улазни подаци за креирање тест случајева.
У агилним пројектима, тест сценарији су једини излази за дизајн теста и није написан ниједан тест случај који следи након њих. Тест сценарио може резултирати вишеструким тестовима.
Примери тест сценарија:
- Потврдите да ли администратор може додати нову земљу
- Потврдите да ли администратор може да избрише постојећу земљу
- Потврдите да ли се постојећа држава може ажурирати
Услови испитивања су, с друге стране, специфичнији. Може се грубо дефинисати као циљ / циљ одређеног теста.
Пример услова испитивања: У горњем примеру, ако бисмо тестирали сценарио 1, можемо тестирати следеће услове:
- Унесите назив државе као „Индија“ (важеће) и проверите да ли је додата држава
- Унесите празно поље и проверите да ли се земља додаје.
- У сваком случају су описани конкретни подаци и циљ теста је много прецизнији.
Додатна литература=> 180+ примера сценарија за тестирање веб и десктоп апликација.
| ТЕСТ СЦЕНАРИО | ТЕСТ УСЛОВ |
|---|---|
| Ово су изјаве у једном реду које објашњавају шта ћемо тестирати. | Услов испитивања описује главни циљ тестирања апликације. |
| То је поступак за тестирање апликације на све могуће начине. | Услови испитивања су статичка правила која треба поштовати да бисте тестирали апликацију. |
| Тест сценарији су улаз за стварање тест случајева. | Главни циљ даје тестирање апликације. |
| Тест сценарио обухвата све могуће случајеве за тестирање апликације. | Услови испитивања су врло специфични. |
| Смањује сложеност. | Омогућава системску грешку. |
| Тест сценарио може бити појединачни или група тест случајева. | Циљ је тест случајева. |
| Писањем сценарија биће лако разумети функционалност апликације. | Услови испитивања су врло специфични. |
| Примери сценарија испитивања: # 1) Потврдите да ли администратор може додати нову земљу. # 2) Потврдите да ли администратор може да избрише постојећу земљу. # 3) Потврдите да ли се постојећа држава може ажурирати. | Примери услова испитивања: # 1) Унесите назив државе као „Индија“ и проверите да ли је додата држава. # 2) Оставите празна поља и проверите да ли се земља додаје. |
Разлика између поступка испитивања и скупа тестова
Поступак тестирања је комбинација тест случајева заснованих на одређеном логичком разлогу, попут извршавања ситуације од краја до краја или нечег сличног. Редослед извођења тест случајева је фиксиран.
Поступак испитивања: То није ништа друго до тест животни циклус. Постоји 10 корака у животном циклусу тестирања.
Су:
- Процена напора
- Иницијација пројекта
- Студија система
- План теста
- Тест тест случај
- Тест Аутоматион
- Извршите тест случајеве
- Пријави недостатке
- Регресија тестирање
- Анализа и резиме извештаја
На пример , ако бих тестирао слање е-поште са Гмаил.цом, редослед тест случајева које бих комбиновао да бих формирао тест процедуру био би:
- Тест за проверу пријаве
- Тест за састављање е-поште
- Тест за причвршћивање једног / више прилога
- Форматирање е-поште на потребан начин помоћу различитих опција
- Додавање контаката или адреса е-поште у поља То, БЦЦ, ЦЦ
- Слање е-поште и осигурање да се приказује у одељку „Послате поруке“
Сви горенаведени тестови су груписани да би се на крају постигао одређени циљ. Такође, поступци испитивања имају неколико комбинованих случајева у било ком тренутку.
С друге стране, тест пакет је листа свих тест случајева који се морају извршити као део тест циклуса или фазе регресије итд. Не постоји логичко груписање на основу функционалности. Редослед извршења саставних тест случајева може или не мора бити важан.
Тест Суите: Тест Суите је контејнер који садржи скуп тестова који помажу тестерима у извршавању и извештавању о статусу извршења теста. Може потрајати било које од три стања, тј. Активно, у току и завршено.
Пример скупа тестова : Ако је тренутна верзија апликације 2.0. Претходна верзија 1.0 је можда имала 1000 тест случајева да би је у потпуности тестирала. За верзију 2 постоји 500 тест случајева за само тестирање нове функционалности која је додата у новој верзији.
Дакле, тренутни тестни пакет би био 1000 + 500 тест случајева који укључују и регресију и нову функционалност. Суите је такође комбинација, али не покушавамо да постигнемо циљну функцију.
Пробни пакети могу садржати 100 или чак 1000 примерака.
| ПОСТУПАК ТЕСТА | ТЕСТ СУИТЕ |
|---|---|
| Стварање испитних поступака заснива се на току испитивања од краја до краја. | Пробни пакети се креирају на основу циклуса или на основу обима. |
| Комбинација је тест случајева за тестирање апликације. | То је група тест случајева за тестирање апликације. |
| То је логично груписање засновано на функционалности. | Не постоји логичко груписање на основу функционалности. |
| Поступци испитивања су производи који се испоручују у процесу развоја софтвера. | Изводи се као део тест циклуса или регресије. |
| Редослед извршења је фиксан. | Редослед извршења можда није важан. |
| Поступак испитивања садржи случајеве од краја до краја. | Пакет за тестирање садржи све нове функције и случајеве регресије. |
| Поступци испитивања кодирани су на новом језику који се зове ТПЛ (језик поступка испитивања). | Пакет за тестирање садржи случајеве ручног тестирања или скрипте за аутоматизацију. |
Закључак
Концепти за тестирање софтвера играју главну улогу у животном циклусу тестирања софтвера.
Јасно разумевање горенаведених концепата, као и њихово поређење, веома је важно за сваки испитивач софтвера да би ефикасно спровео поступак тестирања.
Овакви чланци су обично изврсна полазна основа за дубље расправе. Стога, молим вас, у коментарима испод наведите своје мисли, договоре, несугласице и било шта друго. Радујемо се вашим повратним информацијама.
Такође поздрављамо ваша питања о тестирању софтвера уопште или било чему што је повезано са вашом каријером тестирања. Њима ћемо се детаљније позабавити у наредним постовима из исте серије.
Срећно читање !!
=> Посетите овде за комплетну серију водича за план испитивања
ПРЕВ Туториал |. | СЛЕДЕЋА Лекција
Препоручено читање
- Водич за план тестирања: Водич за писање документа софтверског плана испитивања од нуле
- Како написати документ стратегије тестирања (са узорком предлошка стратегије тестирања)
- Како се припремити за писање тест случајева [Савети за продуктивност]
- Шта је тестни сценарио: Предложак тестног сценарија са примерима
- Разлика између плана испитивања учинка и стратегије испитивања учинка
- Како писати тест случајеве: Крајњи водич са примерима
- Узорак предлошка плана тестирања софтвера са форматом и садржајем
- Тест сценариј против тест случаја: Која је разлика између њих?