how effectively prepare test bed
Предизвикателства и най-добри практики за настройка на тестово пространство / тестова среда:
На няколко пъти тестерите установяват, че дефектите им биват отхвърляни поради проблеми с околната среда, или постоянно се възпроизвеждат дефектите по подобни причини. Докато откриването на най-много дефекти със сигурност трябва да бъде един от личните критерии за всеки тестер, повечето тестери също трябва да наблегнат на наличието на най-много валидни дефекти.
Как се постига това?
Освен другите аспекти като планиране на разнообразни тестови сценарии и задълбочено разбиране на договорената покупка, a трябва да се инвестира достатъчно време за настройка на тестовата среда или тестовата среда . На второ място, въпреки че разполагат с прогнозна сума за планиране на тестови случаи, тестерите също трябва фокусирайте енергиите си върху създаване на ефективни тестови данни .
Лично аз, като част от процеса на одит, забелязах, че най-голям брой валидни дефекти се откриват, когато са положени значителни усилия за правилното създаване на тестовата среда или тестовата среда и когато тестерът има задълбочени разбиране на вида на необходимата среда.
Също така видът на тестовите данни, предоставени на тестовата среда, може да разкрие някои много сериозни недостатъци в тествания код / функция, които могат да повлияят сериозно на качеството на продукта.
Тази статия разказва за това какво точно включва Test Bed: Това е двуетапен процес на настройка на тестовата среда и настройка на тестовите данни:
Част 1) По-ранната част на статията ще обсъди общ процес на настройка на тестовата среда , най-често срещани проблеми с настройката, пред които са изправени тестовете и указателите, които трябва да имате предвид, докато създавате Test Bed вместо тези предизвикателства.
Част 2) След като казахме толкова много по отношение на Тестовото легло в тази статия, струваше си да хвърлим малко светлина върху Поддръжка на тестовата среда аспекти също. Последната част на статията обсъжда втората част от настройката на тестовото легло, която включва тестовите данни, подхода за настройването му и някои ефективни Тествайте техниките за управление на данни .
С постоянния „голям взрив“ в разработването и тестването на софтуер, все по-голям фокус е върху приемането на различни методологии, за да се направи цялостният процес за осигуряване на качеството прозрачен, ефективен и адекватен.
В организациите се провеждат различни одити за качество, за да се гарантира, че работата на екипа за тестване може да бъде оценена по подходящ начин и да има измерими резултати с показателите, идентифицирани при инициализирането на цикъла на тестване. Тези резултати дават възможност да се установи къде се намира даден екип по отношение на осигуряването на оптимално качество на софтуера, който тестват.
Тези доклади също помагат на екипа да разбере възможностите за подобрение въз основа на наблюденията, направени по време на одита.
Излишно е да споменавам, че много очевиден показател за всеки тестващ екип би бил по отношение на общия брой открити дефекти спрямо брой валидни дефекти . Следователно един от въпросите, които очевидно се появяват, е - на какво се основава опитът да се открие някакъв дефект? Казано по друг начин, каква е основата, върху която може да се намери дефект?
Отговорът е единодушен - настройка на тестовото легло и / или тестовата среда. В рамките на екипите има зададени критерии за качество намаляване на отхвърлените дефекти като грешка в тестовата настройка / Потребителска грешка, невалидни конфигурации или в някои случаи дефектите, възникващи като избягвания от определен екип поради недостъпни конфигурации, непроверени конфигурации.
Нека започнем, като разгледаме по-отблизо дефинирането на това, което е пробно легло или тестова среда.
Какво ще научите:
Какво е тестово легло и тестова среда?
В много общ смисъл, Test Bed може да се определи като вид среда за разработка, при която внедряващите код или модули имат свободата да тестват своите модули без никакви смущения от екипа за тестване, в абсолютно ограничение.
Тестовото легло обаче не е специфично само за екип от разработчици. От гледна точка на тестовия екип или тестера, тъй като Test Bed не е нищо друго освен платформа, идентифицирана за тестване на софтуер / продукт, тя също е взаимозаменяемо наречена Test Environment.
Всяко тестово съоръжение или тестова среда трябва да бъде конфигурирано в съответствие с идентифицираната цел на теста за тестваното приложение / продукт / софтуер. В определени ситуации тестовото легло ще бъде съпоставянето на тестовата среда и тестовите данни, с които работи.
Компоненти на тестова среда
Всеки тест би имал своите специфични изисквания за тестова среда, но в много широк смисъл, всяка тестова среда / тестова среда ще се състои от хардуер, софтуер и мрежови елементи, за да поддържа необходимата конфигурация като минимум за шофиране и провеждане на конкретния тест .
Всеизвестен факт е, че разумно количество време на тестера се изразходва от екологични проблеми, които от своя страна влияят върху производителността и графиците на тестовете. Въпреки че видът на предизвикателствата варира за всеки тестов екип, някои от тях може да са често срещани.
Някои ключови предизвикателства, с които често се сблъскваме, са:
# 1) Отдалечена среда
Тестовите активи или среди са разположени предимно географски в сайтове, които са отдалечени за екипите. Това е едно от най-често срещаните предизвикателства пред тестовите екипи, в случай на възникнали проблеми, свързани с хардуер, фърмуер, софтуер, мрежи и др.
Екипите, консумиращи активите, ще трябва да разчитат силно на екипите за поддръжка в мястото, където са налични активите.
В същите редове, ако някой актив се нуждае от надстройка на фърмуера или надстройка на компилация, отново тестовият екип може да се нуждае от подкрепата на екипите за поддръжка, притежаващи средата, като отвори билети за поддръжка. Това може също да доведе до значително време и графици за тестване, особено в случаите на разлики в часовите зони.
# 2) Комбинирано използване между екипи
Най-често екипите за разработки и тестове използват едни и същи активи на околната среда. Въпреки че общата норма определя, че средите за разработка, изпитване и производство трябва да бъдат отделни, всъщност този идеален сценарий се постига много рядко. Става изключително неприятно за организациите да набавят отделни ресурси за всеки екип.
Следователно повечето организации налагат общото използване на околната среда между разработката и теста. Освен това, ако ресурсите за разработка и тестване се борят за използването на едни и същи активи едновременно, това води до хаос и разногласия в членовете.
# 3) Неефективно планиране за използване на ресурси за интеграция
В някои случаи за сценарии, нуждаещи се от тестване от край до край при което има интеграция на два или повече компонента, за да функционират заедно, отново може да има изискване за общо използване на ресурсите между тестовите екипи. Неефективното планиране по отношение на използването допринася много за околната среда, която се превръща в нестабилна, освен конфликт между екипите.
Най-очевидният ефект от това е, че проблем, който се забелязва за определен един или два пъти, може да доведе до напълно различно поведение в следващите изпълнения за същия сценарий. Ако за това вече е открит дефект, има големи шансове той да не бъде приет от разработката като валиден кандидат за поправка.
# 4) Конфигурация на сложен тест
Конфигурацията на Test Bed или Test Environment понякога е твърде сложна. Това ще създаде няколко предизвикателства, тъй като тестовият екип ще се нуждае от необходимите умения, за да разбере необходимите конфигурации. Понякога липсва база от знания на разположение на тестера, за да може да излезе с необходимата конфигурация.
В такива случаи тестерите могат сами да предизвикат грешка в тестовия стенд, като го конфигурират неправилно. Това би повлияло значително на тестовия случай и резултатите, които той произвежда.
# 5) Сложно време за настройка
В определени други времена, за всеки тестов случай, настройката на теста може да бъде твърде сложна за всеки идентифициран тестов случай. Това може да се дължи на голямо разнообразие от съвместно съществуващи технологии, които трябва да бъдат свързани заедно или множество компоненти, за да работят заедно в случаи на интеграционно тестване.
В тези случаи всеки от компонентите трябва да работи перфектно, за да осигури постоянни резултати, тъй като един компонент може да формира вход към следващия.
Най-добри практики за създаване на тестова среда
Разгледахме общата схема на предизвикателствата, пред които е изправен изпитателят преди или по време на изпълнението на теста. Повечето от нас са се сблъсквали с един или повече от тези проблеми в даден момент по време на етапите на нашия проект. Тези предизвикателства са съществували и вероятно ще продължат да съществуват в различна степен, защото не съществува идеалистична ситуация.
Като се има предвид, че предизвикателствата за настройка са неразделна част от работата на тестера и са неизбежни, ето няколко предложения как ефективно да подготвите настройката за тестване. Това може да помогне за минимизиране на дефектите, които могат да възникнат поради проблеми с настройката.
Съвет # 1) Разберете Изисквания за изпитване задълбочено и се образовайте
vr слушалки, които работят с xbox one
Винаги започвайте с основите и с най-очевидното! Когато спецификационен документ или документ за случай на употреба се пускат от екипа за разработка, неизменната стъпка за тестовия екип е да разбере изискванията за договорени покупки и след това да подготви документ за тестов случай, описващ подробно тестовите случаи.
Докато се извършва планирането на теста, то е така най-доброто практиката да включва и подробна информация за тестовата среда в документа за тестовия случай. Няма предположения, че след това тестващият ще прекара известно време, анализирайки каква тестова среда може да е необходима и съответно необходимите конфигурации.
Това може да се постигне чрез разговор с екипа / архитектите на разработчиците, за да се изгради добра база от знания. Това не само ще спести известно време в цикъла на изпълнение, но също така ще помогне на тестера да разпредели ефективно времето си на изпълнение между прости и сложни тестове.
Лично добрият резултат от това е, че много от нас откриха проблеми с настройката (които по своята същност биха попречили на последователното изпълнение на теста) в самото начало на цикъла, което ни даде време да канализираме и да получим необходимата помощ, за да решим тези проблеми - по този начин не удължаване на тестовия цикъл след неприемливи периоди.
Друго положително въздействие това би имало, че това значително би подобрило знанията на тестовия екип и би предотвратило ненужни дефекти. Въпреки че тази практика обобщава почти всички практики, които по своята същност са необходими за справяне с предизвикателствата за настройка на теста, споменати по-горе, все пак си струва да споменем и другите съвети.
Съвет # 2) Проверка на свързаността
Друг най-важен контролен пункт е да се уверите, че ресурсите или активите, които възнамерявате да използвате за тестване, са достъпни. В случай, че системата трябва да се стартира интегрирана с други машини, проверете тяхната свързаност помежду си, като използвате ping или telnet.
Също така, ако системите трябва да взаимодействат помежду си и са зад защитни стени, уверете се, че могат да се удостоверят чрез тези защитни стени, използвайки Основни опции за защита (BSO) и да проверите и за прокси. В случай, че забележите, че някои машини не са достъпни или се нуждаят от BSO удостоверяване, могат да бъдат подадени подходящи заявки за услуги, за да се изпълни изискването към екипа за поддръжка.
Това е особено полезно, когато околната среда е на отдалечени места и също така ще избегне ескалацията по отношение на машините и системите. В случай, че тестовият екип изисква достъп до който и да е ресурс или хранилище, това би помогнало за проактивно определяне на същото.
Съвет # 3)Проверка на мрежата и / или съхранението
Това е почти разширение на предишния съвет и ще се нуждае от определена друга проверка с по-голяма техническа дълбочина. Уверете се, че тестването, от което се нуждаете, има необходимата честотна лента и дали тестването ви се нуждае от интернет връзка. Също така, уверете се, че сте намерили начин да проверите дали мрежовата топология между системите и ресурсите е правилна.
На второ място, ако целта ви за тестване предполага необходимостта от съхранение, уверете се, че има съхранение и мрежова свързаност. Предимно отговорността на администратора е да го постави на място, но също така е голяма добавена стойност да имате някои работни и функционални познания за същото.
Съвет # 4) Проверете за необходимия хардуер и софтуер, лицензи
Много пъти се случва тестерите да започват изпълнението в системите, без да проверяват необходимия хардуер и софтуер, които може да са необходими. В резултат на това много пъти тестерът осъзнава почти по време на цикъла на тестване, че определена функционалност е достъпна само на по-високо ниво на хардуер или софтуер / фърмуер.
По това време тестващият ще сигнализира за блокиращ инструмент в неговото тестово усилие, което изяжда значително време за тестване. Следователно е безценна практика да има контролно-пропускателен пункт, който да отбелязва хардуера и софтуера, които са необходими преди това.
Много пъти може да има престой в надстройката на хардуера / софтуера, което се свежда до Съвет 1 където тестерът трябва да участва в проактивно планиране по отношение на хардуера. Някои от софтуера може да изискват лицензи, които може да изискват одобрения и действия от правния екип. Това действие, което се управлява от процеса, може отново да отнеме няколко дни, за да бъде изпълнено, което трябва да бъде планирано.
Съвет # 5)Браузъри и версии
Тестването, което правите, трябва да отразява какво ще извърши краен потребител . Той може да тества върху определен браузър на най-новите версии на всички браузъри. Следователно е задължително да идентифицирате различните видове браузъри, които биха били използвани за тестване, и да ги инсталирате в собствената си локална настройка за тестване.
На второ място, също така определете кои версии на браузърите трябва да се използват за тестване. Добра практика би била да започнете с браузър с по-ниска версия, като по този начин осигурите обратна съвместимост и след това надстроите до най-новата версия.
Съвет # 6)Планиране на използването на тестовата среда.
Предвид факта, че тестовият екип никога няма да има ситуация да разполага със собствени тестови ресурси, системи и активи - това е един от основните етапи в тестовото планиране за ефективно използване на тестовите ресурси.
как да отворите .jar файл windows 10
Това е особено необходимо, когато повече от един екип трябва да имат достъп до един и същ набор от ресурси или поради сценарий от край до край, който се състои от два или повече компонента, работещи заедно, или ситуация, при която настройката на теста е твърде сложна или сложна, за да се репликира много лесно и може да има множество членове в един и същ екип, които имат свои собствени цели за тестване с една и съща настройка.
Добра практика би била да се изработи подход за споделяне на времето, при който определен екип или човек да го използва за по-ранната половина, а останалите хора за втората половина. Понякога между тях може да се случи, че всеки от тях може да провежда независими тестове, които няма да попречат на другия.
Правейки това не само ще намали хаоса и конфликтите в членовете, но и ще осигури поведенческа стабилност на околната среда за по-дълго време.
Съвет # 7)Инструменти за автоматизация и техните конфигурации
Както знаем, всеки ред в теста ще има няколко повтарящи се теста, които ще бъдат част от цикъла на регресия, който ще трябва да бъде автоматизиран. Тестовият екип трябва да идентифицира какъв тип автоматизация би искал да направи и необходимите инструменти за това.
Въпреки че това не е необходимо да бъде част от подготовката на околната среда, аз все пак бих изброил това като най-добрата практика за автоматично идентифициране и конфигуриране на инструментите за автоматизация. Това напълно ще зависи от преценката на изпитателя, когато той иска да изпълни тази дейност, тъй като това не е задължителен фактор за осигуряване на готовност за изпитване.
Заключение
Тези съвети и трикове могат да формират добър критерий и отпечатък, за да гарантират готовността на тестовата среда за тестване. Несъмнено всеки екип е изправен пред свой собствен уникален набор от предизвикателства и горните съвети могат да бъдат адаптирани и персонализирани, за да отговарят на техните собствени нужди.
Всъщност източникът за изписване на целия този скелет от съвети идва от едно от заданията ми, където се сблъсках със сериозно сложни проблеми с настройката и ми отне почти година, за да започна дори да тествам!
Въпреки че ограниченията в тестовата среда бяха извън моя контрол, чувствах, че много от тези проблеми биха могли да бъдат докладвани по-рано, ако бях приложил тези съвети. Оттогава го прилагам за всяко задание, което ми попадне, и този скелет ми помогна много при проактивно намиране на проблеми с настройката и насочване на усилията ми за разрешаването им.
За автора: Тази статия е написана от Sneha Nadig. Тя работи като ръководител на теста с над 7 години опит в проекти за ръчно тестване и автоматизация.
В част 2 на тази статия ще видим процеса на настройка и поддръжка на тестовата среда и съвети за подготовка и управление на тестови данни. Междувременно, не се колебайте да публикувате вашите запитвания за подготовка на тестовата стая в коментари.
Препоръчително четене
- Как да извършите ефективно тестване след издаване и да сведете до минимум въздействието на изданието за клиенти на живо
- Как решавате кои дефекти са допустими за пускане в действие на софтуера?
- Как да подготвим и доставим изключителна презентация за QA тестване на екипа
- Процес на управление на дефекти: Как да управляваме ефективно дефекта
- 9 най-добри идеи за тестери, които да използват ефективно времето си на пейката
- Лидерство в тестването - Тествайте отговорностите на водещия и как да управлявате ефективно тестовия екип
- Как да планирате и управлявате ефективно проекти за тестване (Съвети)
- Процес на дефектна триация и начини за справяне с дефектната триажна среща