Мени

Врхунски водич за тестирање валидације

validation testing ultimate guide

Истражите важност валидацијског тестирања:

Шта ћете научити:

Шта је тестирање валидације?

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

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

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

Испитивање ваљаности

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

Алати попут ХП центра за квалитет, селена, аппија итд. Користе се за извођење теста валидације и тамо можемо да сачувамо резултате теста. Исправан план испитивања, извођења тестова, извештаји о кваровима, извештаји и показатељи важни су за испоруку.

Из перспективе компаније, тест валидације на једноставан начин спроводи се у следећим корацима:

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

кораци за проверу ваљаности

Истражимо сада више о валидацији у детаље.

ктп питања и одговори за искусне

Разлика између верификације и валидације

Хајде да их разумемо на примеру на једноставан начин.

Пример:

Захтев клијента:

Предложена ињекција не сме бити тежа од 2 цм.

Верификациони тест:

  • Помоћу контролне листе, прегледа и дизајна проверите да ли је ињекција ињекција која тежи више од 2 цм.

Тест валидације:

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

Укључене фазе

  • Квалификација дизајна: То укључује израду плана испитивања на основу пословних захтева. Све спецификације морају бити јасно наведене.
  • Квалификација инсталације: То укључује инсталацију софтвера засновану на захтевима.
  • Оперативна квалификација: То укључује фазу тестирања на основу спецификације корисничких захтева.

Ово може укључивати Испитивање функционалности:

    • Јединствено тестирање - Црна кутија, бела кутија, сива кутија.
    • Интеграционо тестирање - Одозго, одоздо према горе, Велики прасак.
    • Тестирање система - Испитивање разума, дима и регресије.
  • Квалификација перформанси: УАТ (тестирање прихватљивости корисника) - Алфа и Бета тестирање.
  • Производња

фазе укључене у испитивање валидације

Квалификација дизајна

Квалификација за дизајн једноставно значи да дизајн софтвера морате припремити на такав начин да задовољава корисничке спецификације. Првенствено морате да набавите Документ о спецификацији корисничких захтева (УРС) од клијента да настави са дизајном.

Тест стратегија:

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

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

У неколико пројеката, план испитивања и стратегија испитивања могу се уградити као један документ. Одвојени стратешки документи су такође припремљени за сложени пројекат (углавном у техници аутоматизације).

Компоненте плана валидационог теста:

  • Опис пројекта
  • Разумевање захтева
  • Обим испитивања
  • Нивои испитивања и распоред испитивања
  • Покрени израду плана
  • Хардверско-софтверски и кадровски захтеви
  • Улоге и одговорности
  • Претпоставка и зависности
  • Ризици и ублажавање
  • Извештај и метрика

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

Разумевање захтева: По добијању УСР, морате да поменете разумљиве захтеве са ваше стране. Такође можете поднети појашњења ако их има. Ово представља основни или тест критеријум за тестирање.

Обим тестирања: Опсег мора детаљно обухватити модуле, заједно са карактеристикама на високом нивоу. Морате да кажете клијенту које све захтеве бисте покрили током тестирања.

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

Нивои испитивања и распоред испитивања: Морате напоменути колико рунди тестирања треба да се спроведе. Укупан напор за пројекат тестирања процењује се помоћу стандардних техника процењивања као што је процена Тест Цасе Поинт (ТЦП) итд.

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

Пример:

Дизајн веб странице је пројекат који се разматра.

Нивои испитивања укључују:

Ниво 1: Испитивање дима
Ниво 2: Јединствено тестирање
Ниво 3: Интеграционо тестирање
Ниво 3: Тестирање система
Ниво 3: Прихватање тестирање

Распоред испитивања:

  1. Подношење плана - 1 дан
  2. Дизајн тест случајева - Дан 2
  3. Суво покретање и исправљање грешака - 4. дан
  4. Ревиев- 5. дан
  5. Формално трчање - 6. дан
  6. Испоруке послате на одобрење - 8. дан
  7. Извештаји - 10. дан

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

На пример, када користите Алат ХП Куицк Тест Профессионал за извршење, број трчања ће бити приказан на картици Рунс у плану теста.

Хардверско-софтверски и кадровски захтеви:

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

Улоге и одговорности: То подразумева додељивање задатака повезаним улогама одговорним за спровођење различитих нивоа тестирања.

На пример,

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

  1. Тест Леад: Дизајн плана испитивања
  2. Члан тима 1: Дизајн и извршење протокола 1,2.
  3. Члан тима 2: Дизајн и извршење протокола 3,4.
  4. Члан тима: Припрема извештаја, прегледа и показатеља.

Претпоставка и зависности: То значи да ће овде бити укључене претпоставке изнете током дизајна и зависности идентификоване за испитивање.

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

Извештај и показатељи: Овде се морају навести фактори који су коришћени за тестирање и извештавање заинтересованих страна.

Пример мобилне апликације дат је у наставку:

метрике

Квалификација инсталације

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

На пример, Нова апликација каже да „абц“ треба тестирати на мобилним уређајима (Андроид 4.3.1) и прегледачу (Цхроме 54), у том случају морамо водити евиденцију о следећем:

која је компанија тренутно лидер у услугама веб хостинга заснованих на облаку?
  • Проверите да ли је дато одговарајуће овлашћење за проверу веб локације апликације „абц“.
  • Погледајте да ли су доступни уређаји који се користе за тестирање апликације као што су мобилни (андроид / иос), прегледач-Цхроме, Интернет Екплорер са потребном верзијом.
  • Проверите да ли су исправно инсталиране са наведеним верзијама (нпр. Цхроме 54, Андроид верзија 4.3.1).
  • Проверите да ли је апликацији доступна и у прегледачу и на мобилном уређају.

Оперативна квалификација

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

Тестирање валидације, генерално, врши се у следећој хијерархији.

Хијерархија испитивања валидације

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

Функционално испитивање и његове врсте

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

Кратко ћемо погледати његове врсте.

# 1) Јединствено тестирање:

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

Јединствено тестирање раде сами програмери. Овде су трошкови исправљања грешака мањи у поређењу са осталим нивоима тестирања.

Пример:

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

# 2) Тестирање црне кутије:

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

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

# 3) Испитивање беле кутије:

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

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

# 4) Тестирање сиве кутије:

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

Интеграционо испитивање и његове врсте

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

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

најбоље бесплатно чишћење регистра за Виндовс 10

Одозго на доле приступ:

Одозго на доле приступ

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

Приступ одоздо према горе:

Приступ одоздо према горе

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

Испитивање система и његове врсте

Тестирање комплетног система / софтвера назива се системско тестирање. Систем је у потпуности тестиран према спецификацијама функционалних захтева. Испитивање система врши се према функционалним и нефункционалним захтевима. Тестирање црне кутије је углавном пожељно за ову врсту тестирања.

# 1) Испитивање дима:

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

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

# 2) Испитивање исправности:

У испитивању исправности испитане су главне функционалности модула апликације која се тестира. У тестирању веб странице која има 3 картице, тј. Стварање профила, образовање, пријава итд., У ИРЦТЦ , главне функционалности свих ових картица морају се проверити без да се иде дубље.

Менији, подменији, картице морају бити тестирани у свим модулима. То је подскуп регресивног испитивања, јер се испитивање врши само у главном току, а не у дубини.

# 3) Испитивање регресије:

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

Квалификација перформанси

УАТ (Испитивање прихватљивости корисника):

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

Алфа и Бета тестирање:

Алфа тестирање програмери раде на апликацији пре објављивања на локацији за развој софтвера. Укључује тестирање црно-белих кутија. Бета тестирање се врши на страни купца након што се производ развије и примени.

Узорци случајева или протокола за проверу ваљаности

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

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

=> Преузми узорке случајева провере ваљаности: Тест случаја за пријаву на Гмаил

Закључак

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

Сваки написан тест треба да буде оштар, сажет и разумљив чак и обичном човеку. Испитивач за проверу ваљаности треба да осигура да се прави производ развија према наведеним захтевима.

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

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

Надам се да би вам овај чланак обогатио знање о концепту тестирања валидације !!

Препоручено читање

^