how effectively prepare test bed
Изазови и најбоље праксе у постављању тестног лежишта / тестног окружења:
У неколико наврата тестери откривају да се њихови недостаци одбијају због еколошких проблема или се стално понављају из сличних разлога. Иако отварање највећег броја недостатака сигурно мора бити један од личних показатеља сваког тестера, већина тестера такође мора нагласити да има највећи број ваљаних недостатака.
Како се то постиже?
Поред осталих аспеката попут планирања различитих сценарија испитивања и темељног разумевања ставке поруџбине, а мора се уложити довољно времена у постављање тестног лежишта или тестног окружења . Друго, упркос томе што имају процењени износ за планирање случајева испитивања, тестери такође морају усредсредите своје енергије на стварање ефикасних података о тестирању .
Лично, као део процеса ревизије, приметио сам да се највећи број валидних недостатака пронађе када се уложи доста труда у правилно стварање тестног окружења или тестног окружења и када испитивач детаљно проучи разумевање врсте окружења које је потребно.
Такође, врста података о испитивању који се достављају у окружење за тестирање могу открити неке врло озбиљне недостатке у коду / својству који се тестирају и који могу озбиљно утицати на квалитет производа.
Овај чланак говори о томе шта тачно подразумева Тест Бед: То је поступак у два корака подешавања тестног окружења и тест података:
Део 1) У ранијем делу чланка биће речи о општи поступак подешавања тестног окружења , који се најчешће суочавају са проблемима у подешавању са којима се суочавају тестови и показивачи, а које треба имати на уму приликом стварања пробног лежишта уместо ових изазова.
Део 2) Кад смо у овом чланку толико рекли у вези са Тест Бед-ом, вредело је бацити мало светла на Одржавање тестног окружења аспекти такође. У другом делу чланка се говори о другом делу поставке тестног лежишта који укључује податке о тесту, приступ њиховом постављању и неке ефикасне Тестирање техника управљања подацима .
Уз стални „велики прасак“ у развоју и тестирању софтвера, све је већи фокус на усвајању различитих методологија како би се укупан процес осигурања квалитета учинио транспарентним, ефикасним и адекватним.
Различите ревизије квалитета спроводе се у организацијама како би се осигурало да се учинак тима за испитивање може на одговарајући начин проценити и да има мерљиве резултате са мерилима идентификованим при иницијализацији циклуса испитивања. Ови резултати омогућавају утврђивање места одређеног тима у погледу обезбеђивања оптималног квалитета софтвера који тестирају.
Ови извештаји такође помажу тиму да разуме могућности за побољшање на основу запажања изнетих током ревизије.
Непотребно је напомињати да би врло очигледна метрика за било који тест тим била у односу на укупан број отворених недостатака у односу на број валидних недостатака . Отуда је једно од питања које се очигледно појављује - Шта је основа покушаја откривања било каквог недостатка? Другим речима, који је темељ на којем се може наћи недостатак?
Одговор је једногласан - подешавање тестног кревета и / или тестног окружења. Постоје тимови квалитета који се постављају унутар тимова смањити недостатке који се одбацују као грешка у подешавању теста / грешка корисника, неважеће конфигурације или у неким случајевима недостаци који настају као бекство од одређеног тима због недоступних конфигурација, непроверених конфигурација.
Кренимо од тога да ближе погледамо дефинисање шта је тестни кревет или тест окружење.
Шта ћете научити:
Шта је тестни кревет и тест окружење?
У врло генеричком смислу, Тест Бед би се могао дефинисати као нека врста развојног окружења, при чему имплементатори кода или модула имају слободу тестирања својих модула без икаквих сметњи од стране тима за тестирање, у апсолутном ограничењу.
Међутим, пробни лежај није специфичан само за развојни тим. Из перспективе тестног тима или тестера, будући да Тест Бед није ништа друго до платформа идентификована за тестирање софтвера / производа, он се такође наизменично назива Тест Енвиронмент.
Било који испитни простор или тест окружење мора бити конфигурисан у складу са идентификованим циљем испитивања за апликацију / производ / софтвер који се тестира. У одређеним ситуацијама, испитни лежај би био успоређивање тестног окружења и тест података са којима ради.
Компоненте тестног окружења
Било који тест имао би своје специфичне захтеве за тест окружење, али у врло широком смислу, било које тестно окружење / тест окружење састојало би се од хардвера, софтвера и мрежних делова који подржавају потребну конфигурацију у најмању руку за вођење и спровођење одређеног теста .
Добро је позната чињеница да разумну количину времена тестера троше еколошки проблеми, који заузврат утичу на продуктивност и распореде испитивања. Иако се врста изазова разликује за сваки тест тим, неки од њих могу бити уобичајени.
Неки кључни изазови са којима се често суочавају су:
# 1) Удаљено окружење
Пробна средства или окружења углавном су географски смештена на локацијама удаљеним од тимова. Ово је један од најчешћих изазова за тестне тимове, у случају било каквих проблема који се могу појавити у вези са хардвером, фирмвером, софтвером, умрежавањем итд.
Тимови који троше имовину морали би се у великој мери ослањати на тимове за подршку на месту где је имовина присутна.
У истим редовима ако је неком материјалу потребна надоградња фирмвера или надоградња верзије, поново ће тест тиму можда требати подршка тимова за подршку који поседују окружење отварањем улазница за подршку. Ово такође може да успори знатан временски распоред и кашњења, посебно у случајевима разлика у временским зонама.
# 2) Комбинована употреба између тимова
Тимови за развој и тестирање најчешће користе исте ресурсе окружења. Иако општа норма дефинише да развојно, тестно и производно окружење морају бити одвојени, у ствари овај идеални сценарио се врло ретко постиже. Организације постају изузетно непријатне по цијену прибављања засебних ресурса за сваки тим.
Стога већина организација налаже заједничко коришћење животне средине између развоја и теста. Уз то, ако се ресурси за развој и тестирање истовремено користе за употребу истих средстава, то доводи до хаоса и неслагања унутар чланова.
# 3) Неефикасно планирање употребе ресурса за интеграцију
У неким случајевима за сценарије којима је потребан тестирање од краја до краја при чему постоји интеграција две или више компоненти да би функционисале заједно, опет може постојати захтев за заједничком употребом ресурса између тестних тимова. Неефикасно планирање с обзиром на употребу увелико доприноси томе што животна средина постаје нестабилна, поред сукоба између тимова.
Најочитији ефекат овога је да проблем који се примети одређени једном или два пута може да произведе потпуно другачије понашање у следећим покретама за исти сценарио. Ако је недостатак већ отворен за ово, велике су шансе да га развојни тим не прихвати као важећег кандидата за поправак.
# 4) Конфигурација сложеног теста
Конфигурација тестног лежишта или тестног окружења је понекад превише сложена. Ово ће представљати неколико изазова, јер ће тест тиму бити потребне потребне вештине да би разумео потребне конфигурације. Понекад недостаје база знања доступна тестеру како би могао да смисли потребну конфигурацију.
У таквим случајевима, тестери могу сами да изазову грешку у тест-лежишту нетачном конфигурацијом. То би у великој мери утицало на тест случај и резултате које он даје.
# 5) Детаљно време подешавања
У одређеним другим временима, за сваки тест случај, подешавање теста може бити превише разрађено за сваки идентификовани тест случај. То би могло бити због широког спектра истовремених технологија које морају бити повезане заједно или више компонената да би се радило заједно у случајевима тестирања интеграције.
У тим случајевима свака компонента мора да ради савршено како би се осигурали доследни резултати, јер једна компонента може чинити улаз за следећу.
Најбоље праксе за постављање тестног окружења
Погледали смо широк преглед изазова са којима се испитивач суочава пре или током започињања теста. Већина нас се суочила са једним или више ових проблема у неком тренутку током прекретница у нашем пројекту. Ови изазови су постојали и вероватно ће и даље постојати у различитом степену, јер идеалистичка ситуација не постоји.
С обзиром да су изазови подешавања саставни део посла тестера и неизбежни, ево неколико предлога како ефикасно припремити поставку за тестирање. Ово би могло да помогне да се минимизирају кварови који могу настати због проблема са подешавањем.
Савет бр. 1) Разумети Темељно тестирајте захтеве и образујте се
Питања и одговори за интервју за тестирање софтвера за двогодишње искуство
Увек започните са основама и са најочигледнијим! Када развојни тим уведе документ са спецификацијама или документ о употреби, непроменљиви корак за тест тим је разумевање захтева ставке поруџбине, а затим припрема документа за тест који детаљно описује случајеве испитивања.
Док се спроводи планирање теста, јесте најбоље пракса да се у документ о случају теста укључе и детаљне информације о тестном окружењу. Нема нагађања о томе да ће тестер тада провести неко време анализирајући које тест окружење може бити потребно и сходно томе потребне конфигурације.
То се може постићи разговором са развојним тимом / архитектама како би се створила добра база знања. Ово не само да ће уштедети неко време у циклусу извршења, већ ће такође помоћи тестеру да ефикасно распореди време извршења између једноставних и сложених тестова.
Лично, добар исход овога је што су многи од нас открили проблеме са подешавањем (који би у суштини спречили доследно извршавање теста) на самом почетку циклуса, што нам је довело до времена да канализујемо и набавимо потребну помоћ да се ти проблеми реше - тако не продужавајући циклус испитивања преко неприхватљивих периода.
Још један позитиван утицај који би ово имало је да би ово у великој мери побољшало знање тест тима и спречило непотребне недостатке. Иако ова пракса сумира готово све праксе које су суштински потребне за суочавање са горе поменутим изазовима постављања теста, ипак је вредно споменути остале савете.
Савет бр. 2) Провера повезаности
Још једна најважнија контролна тачка је осигурати да су ресурси или средства која намеравате да користите за тестирање доступни. У случају да систем треба покренути интегрисан са другим машинама, проверите њихову међусобну повезаност помоћу пинг-а или телнета.
Такође, ако системи треба да комуницирају једни с другима и налазе се иза заштитних зидова, побрините се да се могу потврдити кроз ове заштитне зидове помоћу основних сигурносних опција (БСО) и проверити да ли има и проксија. У случају да приметите да неке машине нису доступне или им је потребна БСО потврда идентитета, могу се поднети одговарајући захтеви за услугу како би се тиму за подршку испунио захтев.
Ово је посебно корисно када је животна средина на удаљеним локацијама и такође ће избећи ескалацију у односу на машине и системе. У случају да тест тим захтева приступ било ком ресурсу или спремишту, ово би помогло у проактивном одређивању истих.
Савет бр. 3)Провера мреже и / или складишта
Ово је готово проширење на претходни савет и била би потребна још нека провера са већом техничком дубином. Уверите се да потребно тестирање има потребну пропусну опсег и да ли је за тестирање потребна интернет веза. Такође, обавезно пронађите начин да проверите да ли је мрежна топологија између система и ресурса тачна.
Друго, ако ваш циљ тестирања подразумева потребу за било којим складишним простором, уверите се да постоје складишна и мрежна повезаност. Углавном је одговорност администратора да то постави на место, међутим, такође је велика вредност имати неко исто радно и функционално знање.
Савет бр. 4) Проверите потребан хардвер и софтвер, лиценце
Много пута се догоди да тестери започну извршавање на системима без провере потребног хардвера и софтвера који би могли бити потребни. Као резултат тога, испитивач готово током циклуса тестирања схвата да су одређене функције доступне само на вишем нивоу хардвера или софтвера / фирмвера.
У то време тестер ће означити блокатор у свом тест напору који једе значајно време тестирања. Отуда је непроцењива пракса имати контролни пункт који бележи хардвер и софтвер који су претходно потребни.
Много пута може доћи до застоја у надоградњи хардвера / софтвера, на шта се све своди Савет 1 где испитивач мора да се укључи у проактивно планирање хардвера. За неки софтвер могу бити потребне лиценце које могу захтевати одобрења и радње правног тима. Ово је процес вођена акцијом, можда ће требати неколико дана да се испуни, што треба планирати.
Савет бр. 5)Прегледачи и верзије
Тестирање које радите мора да се одражава шта ће крајњи корисник извршити . Могао би да тестира на одређеном прегледачу на најновијим верзијама свих прегледача. Стога је обавезно идентификовати различите врсте прегледача који би се користили за тестирање и инсталирати их у вашем локалном подешавању теста.
Друго, такође идентификујте које верзије прегледача треба користити за тестирање. Добра пракса би била да започнете са прегледачем ниже верзије, обезбеђујући на тај начин повратну компатибилност, а затим надоградњу на најновију верзију.
Савет бр. 6)Планирање употребе тестног окружења.
С обзиром на чињеницу да тест тим никада неће имати ситуацију да поседује сопствене ресурсе, системе и средства за тестирање - једна од главних прекретница у планирању теста је ефикасно коришћење ресурса за тестирање.
тестирање интервјуа за искусне професионалце са одговорима
Ово је посебно потребно када више од једног тима мора да приступи истом скупу ресурса било због крајњег сценарија који се састоји од две или више компонената које раде заједно или због ситуације када је поставка теста превише разрађена или сложена да би се могла поновити. врло лако и може бити више чланова унутар истог тима који имају своје циљеве за тестирање са истим подешавањем.
Добра пракса би била развити приступ подјеле времена при чему га одређени тим или особа користи за ранију половину, а преостали људи за другу половину. Може бити негде између тога што ће бити уобичајено када свако од њих може да изврши независне тестове који неће ометати другог.
Ако ово урадите, не само да ћете смањити хаос и сукобе у члановима, већ ће такође обезбедити стабилност понашања у окружењу за дуже време.
Савет бр. 7)Алати за аутоматизацију и њихове конфигурације
Као што знамо, свака ставка у тестирању имаће неколико понављајућих тестова који ће бити део регресионог циклуса и који ће морати да се аутоматизују. Тест тим мора да утврди коју врсту аутоматизације жели да ради и потребне алате за њу.
Иако ово неопходно не треба да буде део припреме за животну средину, ипак бих ово навео као најбољу праксу да се алати за аутоматизацију идентификују и конфигуришу у складу с тим. Ово би у потпуности зависило од дискреционог права тестера када жели да обавља ову активност, јер то није обавезан фактор за обезбеђивање спремности за тестирање.
Закључак
Ови савети и трикови могу бити добар критеријум и отисак како би се осигурала спремност тестног окружења за тестирање. Без сумње, сваки тим се суочава са својим јединственим низом изазова, а горњи савети се могу прилагодити и прилагодити својим потребама.
У ствари, извор за исписивање овог целог костура савета потиче из једног од мојих задатака где сам се суочио са озбиљно сложеним проблемима око подешавања и требало ми је скоро годину дана да започнем тестирање!
Иако су ограничења у тест окружењу била ван моје контроле, осећао сам да би се о многим проблемима могло раније извести да сам применио ове савете. Од тада га примењујем за сваки задатак који ми се нађе на путу и овај костур ми је пуно помогао у проактивном проналажењу проблема са подешавањем и усмеравању мојих напора да их решим.
О аутору: Овај чланак написала је Снеха Надиг. Ради као водитељица теста са преко 7 година искуства у пројектима ручног и аутоматизованог тестирања.
У другом делу овог чланка видећемо поступак подешавања и одржавања тест окружења и савете за припрему и управљање подацима о тестирању. У међувремену, слободно постављајте упите за припрему тестног кревета у коментаре.
Препоручено читање
- Како ефикасно извршити тестирање након објављивања и умањити утицај издања на клијенте уживо
- Како одлучујете које су недостатке прихватљиве за покретање софтвера?
- Како припремити и предати изванредну презентацију о КА тестирању тиму
- Процес управљања недостацима: Како ефикасно управљати недостацима
- 9 најбољих идеја за тестере да ефикасно искористе време своје клупе
- Вођство у тестирању - тестирајте одговорности водећег лица и како ефикасно управљати тест тимом
- Како ефикасно планирати и управљати пројектима тестирања (савети)
- Поступак троструке неисправности и начини за руковање састанком за оштећене тријаже