7 principles software testing
Седем принципа на софтуерното тестване: Включително повече подробности за групирането на дефекти, принципа на Парето и парадокса на пестицидите.
Сигурен съм, че всички са наясно с „ Седем принципа на софтуерното тестване ”.
Тези основни принципи на тестване помагат на екипите за тестване да използват своето време и усилия, за да направят процеса на тестване ефективен. В тази статия ще научим подробно за два принципа, т.е. Групиране на дефекти, принцип на Парето и парадокс на пестицидите .
Какво ще научите:
- Седем принципа на софтуерното тестване
Седем принципа на софтуерното тестване
Преди да разгледаме задълбочено тези два принципа, нека да разберем накратко седемте принципа на софтуерното тестване.
Нека да изследваме !!
# 1) Тестването показва наличието на дефекти
Всяко приложение или продукт се пуска в производство след достатъчно количество тестове от различни екипи или преминава през различни фази като тестване на системната интеграция, тестване за приемане от потребителя и бета тестване и т.н.
Така някога сте виждали или чували от някой от тестващия екип, че са тествали софтуера изцяло и няма дефект в софтуера ? Вместо това, всеки екип за тестване потвърждава, че софтуерът отговаря на всички бизнес изисквания и функционира според нуждите на крайния потребител.
В индустрията за тестване на софтуер никой няма да каже, че има без дефект в софтуера, което е напълно вярно, тъй като тестването не може да докаже, че софтуерът е без грешки или без дефекти.
Целта на тестването обаче е да се открият все повече скрити дефекти, използвайки различни техники и методи. Тестването може да разкрие неоткрити дефекти и ако не бъдат открити дефекти, това не означава, че софтуерът не съдържа дефекти.
Пример 1 :
Помислете за приложение за банково дело, това приложение е щателно тествано и преминава през различни фази на тестване като SIT, UAT и т.н. и понастоящем в системата не са установени дефекти.
Въпреки това може да има вероятност в производствената среда действителният клиент да изпробва функционалност, която рядко се използва в банковата система и тестерите са пренебрегнали тази функционалност, поради което до момента не е открит дефект или кодът никога не е бил докосван от разработчиците .
Пример 2:
Виждали сме няколко реклами за сапуни, пасти за зъби, миене на ръце или спрейове за дезинфекция и т.н. по телевизията.
Помислете за реклама за ръчно измиване, която казва по телевизията, че 99% микроби могат да бъдат премахнати, ако се използва това специфично измиване на ръцете. Това ясно доказва, че продуктът не е 100% без микроби. По този начин в нашата концепция за тестване можем да кажем, че нито един софтуер не е без дефекти.
# 2) Ранно тестване
Тестерите трябва да се включат на ранен етап от жизнения цикъл на разработката на софтуер (SDLC). По този начин дефектите по време на фазата на анализ на изискванията или всякакви дефекти в документацията могат да бъдат идентифицирани. Разходите за отстраняване на такива дефекти са много по-ниски в сравнение с тези, които се откриват по-късно на етапите на тестване.
Помислете за изображението по-долу, което показва как разходите за отстраняване на дефекти се увеличават, когато тестването преминава към живо производство.
(изображение източник )
Горното изображение показва, че разходите, необходими за отстраняване на дефект, открит по време на анализа на изискванията, са по-малки и продължават да се увеличават, докато преминаваме към фазата на тестване или поддръжка.
Сега въпросът е колко рано трябва да започне тестването ?
След като изискванията са финализирани, тестерите трябва да се включат за тестване. Тестването трябва да се извърши върху документи за изисквания, спецификация или друг вид документ, така че ако изискванията са неправилно дефинирани, то може да бъде поправено незабавно, вместо да бъдат фиксирани във фазата на разработване.
# 3) Изчерпателно тестване не е възможно
Не е възможно да се тестват всички функционалности с всички валидни и невалидни комбинации от входни данни по време на действителното тестване. Вместо този подход се разглежда тестване на няколко комбинации въз основа на приоритет, като се използват различни техники.
Изчерпателното тестване ще отнеме неограничени усилия и повечето от тези усилия са неефективни. Също така сроковете на проекта няма да позволят тестване на толкова много комбинации. Следователно се препоръчва да се тестват входните данни, като се използват различни методи като равномерно разделяне и анализ на гранична стойност.
Например ,Ако предположим, че имаме поле за въвеждане, което приема само азбуки, специални символи и числа от 0 до 1000. Представете си колко комбинации ще се появят за тестване, не е възможно да се тестват всички комбинации за всеки тип вход.
Усилията за тестване, необходими за тестване, ще бъдат огромни и това също ще повлияе на сроковете и разходите на проекта. Следователно винаги се казва, че изчерпателното тестване на практика не е възможно.
# 4) Тестването зависи от контекста
На пазара се предлагат няколко домейна като банково дело, застраховане, медицина, пътувания, реклама и др. И всеки домейн има редица приложения. Също така за всеки домейн техните приложения имат различни изисквания, функции, различна цел на тестване, риск, техники и т.н.
Различните домейни се тестват по различен начин, като по този начин тестването се базира чисто на контекста на домейна или приложението.
Например ,тестването на банково приложение е различно от тестването на всяко приложение за електронна търговия или реклама. Рискът, свързан с всеки тип приложение, е различен, поради което не е ефективно да се използва един и същ метод, техника и тип тестване, за да се тестват всички видове приложения.
# 5) Групиране на дефекти
По време на тестването може да се случи така, че повечето открити дефекти да са свързани с малък брой модули. Причините за това може да са множество, като модулите може да са сложни, кодирането, свързано с такива модули, да е сложно и т.н.
Това е принципът на Парето за тестване на софтуер, където 80% от проблемите се намират в 20% от модулите. Ще научим повече за групирането на дефекти и принципа на Парето по-късно в тази статия.
# 6) Пестицид Парадокс
Принципът на пестицида Парадокс казва, че ако един и същ набор от тестови случаи се изпълняват отново и отново през определен период от време, тогава този набор от тестове не са достатъчно способни да идентифицират нови дефекти в системата.
За да се преодолее този „Парадокс на пестицидите“, наборът от тестови случаи трябва редовно да се преразглежда и преразглежда. Ако е необходимо, може да се добави нов набор от тестови случаи и съществуващите тестови случаи могат да бъдат изтрити, ако не могат да открият повече дефекти от системата.
# 7) Липса на грешка
Ако софтуерът е тестван изцяло и ако не бъдат открити дефекти преди пускането, можем да кажем, че софтуерът е 99% без дефекти. Но какво, ако този софтуер е тестван срещу грешни изисквания? В такива случаи дори намирането на дефекти и отстраняването им навреме не би помогнало, тъй като тестването се извършва при грешни изисквания, които не са според нуждите на крайния потребител.
Например, да предположим, че приложението е свързано със сайт за електронна търговия и изискванията срещу функционалността „Кошница или кошница“, която е погрешно интерпретирана и тествана. Тук дори намирането на повече дефекти не помага за преместването на приложението в следващата фаза или в производствената среда.
Това са седемте принципа на софтуерното тестване.
Сега нека изследваме Групиране на дефекти, принцип на Парето и парадокс на пестицидите в детайл .
Групиране на дефекти
Докато тестват какъвто и да е софтуер, тестерите най-често срещат ситуация, при която повечето открити дефекти са свързани с някаква специфична функционалност, а останалите функционалности ще имат по-малък брой дефекти.
Групирането на дефекти означава малък брой модули, съдържащи повечето от дефектите. По принцип дефектите не се разпределят равномерно в цялото приложение, а дефектите са концентрирани или централизирани в две или три функционалности.
Понякога е възможно поради сложността на приложението, кодирането може да бъде сложно или сложно, разработчикът може да направи грешка, която може да повлияе само на конкретна функционалност или модул.
Клъстерирането на дефекти се основава на „ Принцип на Парето ”Което е известно още като Правило 80-20 . Това означава, че 80% от откритите дефекти се дължат на 20% от модулите в приложението. Концепцията за принцип на Парето първоначално е дефинирана от италиански икономист - Вилфродо Парето .
Ако тестерите разгледат 100 дефекта, няма да е ясно дали има някакво основно значение срещу тези 100 дефекта. Но ако тези 100 дефекта са категоризирани по някои специфични критерии, тогава може да е възможно тестерите да разберат, че голям брой дефекти принадлежат само на няколко специфични модула.
Например ,нека разгледаме изображението по-долу, което е тествано за едно от банковите приложения и показва, че повечето дефекти са свързани с функционалността „Овърдрафт“. Останалите функционалности като Обобщена сметка, Превод на средства, Постоянни инструкции и др., Имат ограничен брой дефекти.
(изображение източник )
Горната снимка гласи, че има 18 дефекта около функционалността на овърдрафта от общо 32 дефекта, което означава, че 60% от дефектите се намират в модула „Овърдрафт“.
Следователно тестерите се концентрират предимно върху тази област по време на изпълнение, за да открият все повече дефекти. Препоръчително е тестерите да имат подобен фокус и върху останалите модули по време на тестване.
Когато се тества един и същ код или модул, отново и отново, използвайки набор от тестови случаи, отколкото по време на първоначалните итерации, тогава броят на дефектите е голям, но след известна итерация броят на дефектите значително ще намалее. Групирането на дефекти показва, че предразположената към дефекти зона трябва да бъде тествана задълбочено по време на регресионното тестване.
Парадокс на пестицида
Когато се установи, че един от модулите има повече дефекти, тестерите полагат допълнителни усилия, за да тестват този модул.
След няколко итерации на тестване, качеството на кода се подобрява и броят на дефектите започва да намалява, тъй като повечето дефекти са отстранени от екипа на разработчиците, тъй като разработчиците също са предпазливи, докато кодират определен модул, където тестерите са открили повече дефекти.
Следователно в един момент повечето дефекти се откриват и отстраняват, така че в този модул не се откриват нови дефекти.
Понякога обаче може да се случи така, че да бъдете изключително предпазливи по време на кодиране на един конкретен модул (тук в нашия случай „ Овърдрафт ”Модул), разработчикът може да пренебрегне останалите модули, за да го кодира правилно, или промените, направени в този конкретен модул, могат да имат отрицателно въздействие върху другите функционалности като Обобщена сметка, Превод на средства и Постоянни инструкции.
Когато тестерите използват същия набор от тестови случаи, за да изпълнят модула, където са открити повечето дефекти (модул за овърдрафт), след отстраняването на тези дефекти от разработчиците тези тестови случаи не са много ефективни за намиране на нови дефекти. Като цялостен поток на овърдрафта, модулът е тестван щателно и разработчиците също са написали кода за този модул внимателно.
Необходимо е да се преразгледат и актуализират тези тестови случаи. Също така е добра идея да добавите нови тестови случаи, за да могат да се открият нови и повече дефекти в различни области на софтуера или приложението.
Превантивни методи за пестицид Парадокс
Има два варианта, чрез които можем да предотвратим парадокса на пестицидите, както е показано по-долу:
да се) Напишете нов набор от тестови случаи, които ще се фокусират върху различна област или модули (различни от по-ранните дефектни модули - Пример: “Овърдрафт”) на софтуера.
б) Подгответе нови тестови случаи и добавете към съществуващите тестови случаи.
В „ метод А ”, Тестерите могат да намерят повече дефекти в другите модули, в които не са били фокусирани по време на по-ранното тестване или разработчиците не са били особено предпазливи по време на кодирането.
В горния ни пример тестерите могат да намерят повече дефекти в модулите Резюме на сметки, Прехвърляне на средства или Постоянни инструкции, използвайки новия набор от тестови случаи.
Но може да се случи тестерите да пренебрегнат по-ранния модул ( Пример: „Овърдрафт“), където повечето дефекти са открити в по-ранната итерация и това може да е риск, тъй като този модул (Овърдрафт) може да е бил инжектиран с новите дефекти след кодиране на останалите модули.
В „ метод Б ”, Се подготвят нови тестови случаи, за да могат да се открият нови потенциални дефекти в останалите модули.
Тук в нашия пример новосъздадените тестови случаи ще могат да помогнат при идентифицирането на дефекти в модулите като Резюме на акаунта, Превод на средства и Постоянни инструкции. Тестерите обаче не могат да игнорират по-ранните дефектни модули ( Пример: „Овърдрафт“), тъй като тези нови тестови случаи са обединени със съществуващите тестови случаи.
Съществуващите тестови случаи бяха по-фокусирани върху модула „Овърдрафт“, а новите тестови случаи бяха насочени към останалите модули. Следователно всички набори от тестови случаи се изпълняват най-малко веднъж, дори на всеки модул се случва промяна на кода. Това ще гарантира, че правилната регресия се изпълнява и дефектът може да бъде идентифициран поради тази промяна на кода.
Използвайки втория подход, общият брой тестови случаи значително нараства и води до повече усилия и време, необходими за изпълнение. Това очевидно ще окаже влияние върху сроковете на проекта, а най-важното и върху бюджета на проекта.
Следователно, за да се преодолее този проблем, излишните тестови случаи могат да бъдат прегледани и след това премахнати. Има много тестови случаи, които стават безполезни след добавяне на нови тестови случаи и модифициране на съществуващите тестови случаи.
Необходимо е да се провери кои тестови случаи са неуспешни, за да се идентифицират дефектите в последните 5 повторения (да приемем 5 повторения) и кои тестови случаи не са много важни. Възможно е също така единичният поток, обхванат в няколко тестови случая, да бъде обхванат в други тестови случаи от край до край и тези тестови случаи с единичен поток могат да бъдат премахнати.
Това от своя страна ще намали общия брой тестови случаи.
Например ,имаме 50 тестови случая, за да покрием един конкретен модул, и видяхме, че от тези 50 тестови случая 20 тестови случая не успяха да открият нов дефект в последните няколко итерации на тестване (да приемем 5 повторения). Така че тези 20 тестови случая трябва да бъдат прегледани щателно и ние трябва да проверим колко важни са тези тестови случаи и съответно може да се вземе решение дали да се запазят 20-те тестови случая или да се премахнат.
Преди да премахнете какъвто и да е тест, проверете дали функционалният поток, обхванат в тези тестови случаи, е обхванат в друг тест. Този процес трябва да се спазва във всички модули, така че общият брой тестови случаи значително да се намали. Това ще гарантира, че общият брой на тестовите случаи е намален, но все още има 100% покритие на изискванията.
Това означава, че всички останали тестови случаи покриват всички бизнес изисквания, поради което няма компромис с качеството.
Заключение
Софтуерното тестване е съществена стъпка в SDLC, тъй като проверява дали софтуерът работи според нуждите на крайния потребител или не.
Тестването идентифицира възможно най-много дефекти. Следователно, за да се извърши тестването ефективно и ефикасно, всеки трябва да е наясно и наистина да разбира седемте принципа на софтуерното тестване, тъй като те са известни като стълбовете за тестване.
Повечето тестери са внедрили и са изпитали тези принципи по време на действителното тестване.
кой е най-добрият adblock за хром
Като цяло терминът принцип означава правилата или законите, които трябва да се спазват. Следователно всеки в индустрията за тестване на софтуер трябва да следва тези седем принципа и ако някой пренебрегне някой от тези принципи, това може да струва огромно за проекта.
Честито четене !!
Препоръчително четене
- Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
- Тестване на софтуер QA Assistant Job
- Курс за тестване на софтуер: Към кой институт за тестване на софтуер трябва да се присъединя?
- Изборът на софтуерно тестване като кариера
- Тестване на софтуер Техническо съдържание Writer Работа на свободна практика
- Какво представлява техниката за изпитване на базата на дефекти?
- Някои интересни въпроси за интервю за тестване на софтуер
- Обратна връзка и рецензии на курсове за софтуерно тестване