Анализът на граничните стойности – обикновено съкращаван като BVA – е често срещана техника за тестване на черни кутии. Подходът проверява за софтуерни дефекти чрез проверка на входните стойности на границите на допустимите диапазони.
В тази статия ще разгледаме какво представлява тестването на граничния анализ, защо е полезно и ще разгледаме някои различни подходи, техники и различни инструменти за тестване на границите.
Какво представлява анализът на граничната стойност при тестването на софтуер?
Анализът на граничните стойности е вид функционално изпитване. Този тип тестване се занимава с проверка на това дали всяка функция на софтуера отговаря на изискванията и спецификациите. В случая на гранично тестване тази функционалност включва начина, по който софтуерът се справя с различни входни данни.
BVA е техника за тестване на софтуер, която потвърждава как софтуерът ще реагира на входни данни в границите на входните данни или около тях. По същество всеки вход има допустими диапазони. Например може да имате поле за парола за влизане, което приема пароли между 8 и 12 символа. При граничното тестване ще се проверяват пароли с дължина на символите 7, 8, 12 и 13.
Смята се, че границите на границите, т.е. 7, 8, 12 и 13, са по-склонни към грешки, отколкото числата вътре в границите, например 9, 10 и 11. Макар че ползите от това могат да изглеждат незначителни в пример за поле, което приема между 8 и 12 символа, те стават по-очевидни, когато трябва да напишете тестови случаи за полета, които приемат между 1 и 20 символа или числа между 1 и 1000 и т.н.
Така че, за да се спести време и да се намали броят на тестовите случаи в рамките на функционалното тестване, анализът на граничните стойности разглежда стойностите:
- При минимална стойност
- Непосредствено под минималната стойност
- При максимална стойност
- Непосредствено над максималната стойност
Предимства на анализа на граничните стойности при изпитване
Граничното тестване има няколко убедителни предимства за екипите по осигуряване на качеството.
#1. По-добро качество на софтуера
Кошмарният сценарий за тестващите е грешки и дефекти, които остават незабелязани. При толкова много неща, които трябва да се проверят, някои дефекти могат да се промъкнат през пролуките. Тестването на границите доказва функционалността на областите в софтуера, в които е по-вероятно да има грешки, което води до по-добро изграждане на софтуера и в крайна сметка до по-надеждно и стабилно приложение.
#2. Повишено покритие на тестовете
BVA в тестването на софтуер е толкова полезен, защото помага да се намали броят на тестовите случаи, необходими за цялостно покритие на тестовете. Анализът на граничните стойности гарантира, че важните стойности и че всяка стойност може да бъде тествана по-обстойно.
#3. Ранно откриване на дефекти
Тестването на граничните стойности е част от подход, който дава приоритет на ранното откриване на дефекти. Откриването на грешки в началото на процеса означава, че екипите за разработка могат да спестят време и пари, без дори да споменаваме факта, че е много по-лесно да се отстраняват грешки в ранните етапи на разработката.
#4. Ефективност
Тестването на гранични стойности е изключително ефективно, тъй като намалява изискването за много тестови случаи. Всъщност намаляването на входящите данни до всички, освен тези, които е най-вероятно да предизвикат проблеми, може значително да спести време на екипите за тестване както при писането, така и при изпълнението на тестовите случаи.
Недостатъци на анализа на граничните стойности при изпитване
Разбира се, нито една техника за тестване на софтуер не е съвършена или без ограничения. Макар че анализът на граничните стойности има много предимства, съществуват някои ограничения при работата с тази техника за функционално тестване.
#1. Тесен обхват
BVA работи по границите или ръбовете на валидните входове за данни. Като цяло тя игнорира средните входове, като смята, че те ще бъдат наред, ако валидните входове по ръбовете са наред. Въпреки това не е без прецедент, че някои от тези стойности, които не са тествани, могат да имат проблеми.
#2. Прекалено опростен
Анализът на границите е свързан с опростяване на нещата. Макар че този подход работи за намаляване на тестовите случаи, той не е толкова подходящ за много сложни области с множество граници, взаимодействия или зависимости. Всъщност тя трудно се справя със сложни сценарии, което означава, че трябва да проучите други техники за адекватно покритие.
#3. Предположения
Всеки процес, който се опитва да повиши ефективността, рискува да пропусне определени грешки. BVA се фокусира върху границите на границата на обхвата. По този начин той трябва да направи предположения за други входящи данни, които попадат от двете страни на граничните стойности. Тестерите трябва да намерят баланс между ефективността и покритието, което представлява малък риск, ако се използва само гранично тестване.
#4. Разчитане на точни спецификации и изисквания
Ефективната BVA зависи от качеството и точността на спецификациите и документацията за изискванията. Всякакви непроверени грешки в тези документи могат да се пренесат в изпитването на граничните стойности и да доведат до специфични грешки, които остават непроверени и неоткрити до критичните късни етапи на разработката.
#5. Разчитане на класове на еквивалентност
Извършването на задълбочена BVA изисква задълбочени познания за класовете на еквивалентност. Точното задаване на тези класове изисква опит и известна информация за приложението.
Предизвикателства при анализа на граничните стойности
в областта на софтуерното тестване
Вече трябва да сте наясно с плюсовете и минусите на граничното тестване. Въпреки това, ако искате да приложите този подход в собственото си тестване на софтуер, трябва да сте наясно с различните предизвикателства, които трябва да преодолеете.
Ето някои от предизвикателствата при прилагането на тестването на гранични стойности при тестването на софтуер.
#1. Очертаване на границите
Идентифицирането на границите в простите системи не представлява голямо предизвикателство за компетентните тестери. Съществуват обаче и по-сложни ситуации, като например:
- Сложни входни области с разнообразни входни променливи или сложни взаимоотношения
- Недокументирани граници, които не са ясно описани в документите за спецификация
- Динамични граници, които се променят в зависимост от действията на потребителя или други условия.
#2. Двусмислени изисквания
Лошо написаните или неясни документи с изисквания могат да попречат на определянето на граничните стойности. Яснотата, пълнотата и ангажиментът за изчерпателна спецификация изискват време, но в крайна сметка ще се отплатят.
#3. Експертиза
Анализът на граничните стойности може да бъде измамно сложен. Всъщност екипите за изпитване се нуждаят от персонал с опит и познания в областта, за да разберат тънките нюанси на техниката. Нещо повече, тестващите трябва да имат известни познания за софтуера или поне да разполагат с надеждни документи за спецификация, на които да се опрат.
#4. Грешки
Анализът на границите има за цел да намали броя на тестовите случаи, необходими за проверка на валидните и невалидните входове. Дефектите, които са извън тестовия обхват, обаче могат лесно да останат незабелязани. Освен това грешките “извън единицата” са често срещани грешки при кодирането, които могат да се появят на границите или в близост до тях. Тестващите трябва да са наясно с тези сценарии и да предвидят мерки за тестване.
#5. Експлозия на тестовия случай
При наличието на множество входни граници тестовите случаи скоро могат да станат сложни и да се размножат извън контрол. В тези ситуации времето и парите, които можете да спестите с граничното тестване, се губят, което подкопава ползите от решението. Подобен ефект могат да имат и сложните софтуерни комплекси с много комбинации или пермутации.
#6. Ограничения на инструмента за анализ
Инструментите за автоматизация на софтуерни тестове могат да помогнат на екипите да извършат адекватен анализ на граничните стойности. Въпреки това, дори в най-добрите случаи, тези инструменти изискват известна ръчна намеса както при тестването, така и при създаването на тестове. Тази ситуация може да се влоши при сложни конструкции с взаимодействия с много променливи.
Различни видове гранични стойности
тестване при тестване на софтуер
В книгата ” Софтуерно тестване: Йоргенсен и Байрън ДеВрис описват четири различни вида тестване на граничната стойност, които са:
1. Тестване на нормални гранични стойности (NBVT)
- Тества валидни входни стойности в краищата на входната област
- Изследва минималните и максималните стойности заедно с входните данни точно над и под границата
- Това е класическият тип анализ на граничните стойности
2. Изпитване на надеждни гранични стойности (RBVT)
- Подобно на NBVT по-горе, но включва и невалидни входове.
- Тестове на границите и непосредствено след тях, но също така отчита невалидни входни данни.
- Фокусира се върху откриването на грешки от екстремни или неочаквани резултати
3. Тестване на граничните стойности в най-лошия случай (WBVT)
- Проверява поведението на софтуера, като използва крайно валидни и невалидни стойности
- Изследва стойности на границата на входните области и стойности отвъд тези граници
- Опитва се да разбере поведението на софтуера при по-екстремни условия.
4. Изпитване на граничните стойности в най-лошия случай (RWBVT)
- Използва комбинация от RBVT и WBVT за най-задълбочено тестване на граничните стойности
- Тества валидни и невалидни входни стойности както в типични, така и в крайни граници
- Предоставя най-добрата възможност за откриване на дефекти, свързани с границите
Тези подходи се различават по изчерпателност, като RWBVT е най-изчерпателен. Въпреки това тестващите трябва да признаят допълнителните инвестиции на време и усилия, необходими за разкриването на това допълнително ниво на откриване на дефекти.
Еквивалентно разделяне и гранична стойност
анализ: прилики и разлики
Еквивалентното разделяне и анализът на граничните стойности често се използват в комбинация един с друг. Всъщност двете техники се допълват в голяма степен. Те обаче описват различни подходи за валидиране на въведените данни. Вижте приликите и разликите между тях.
1. Сходства
Еквивалентното разделяне и анализът на граничните стойности са чудесна двойка. Ето някои от приликите между двете техники.
- И двете са техники за тестване на “черна кутия”, което означава, че се фокусират върху входовете и изходите, които могат да бъдат тествани без предварително познаване на изходния код на приложението.
- И двете са част от задълбочен подход към входящите данни за тестване
- И двете помагат на тестерите да намерят баланс между цялостно покритие на тестовете, без да пишат прекалено много тестови случаи.
2. Различия
За да изследваме разликите между разделянето по еквивалентност и анализа на граничните стойности, трябва да разгледаме всяка от тях поотделно.
Разделяне по еквивалентност
- Разделя входните данни на класове на еквивалентност, които трябва да доведат до сходни резултати на системата.
- Използва се една представителна стойност от всеки клас и системата се тества с тази стойност.
- Той се занимава с идентифицирането на валидни и невалидни класове на еквивалентност
Анализ на граничната стойност
- Изпитва стойностите на границите или ръбовете на класовете на еквивалентност
- Тестване на редица стойности, включително минимални, максимални и стойности от двете страни на границата.
- Търси грешки, които се намират на ръба на границите
Примери за еквивалентно разделяне и анализ на граничните стойности
За да затвърдите разбирането си за еквивалентното разделяне и анализа на граничните стойности, ето няколко примера.
Пример за еквивалентно разделяне:
Да речем, че имате поле за въвеждане на данни за регистрация на автомобили. Обикновено регистрационните номера на автомобилите в САЩ съдържат между 6 и 7 символа. С цел опростяване ще оставим без внимание специалните регистрационни табели.
Валидни данни = Табели 6 или 7 знака
Невалидни данни = Табели с >6 или >7 символа.
Пример за анализ на граничните стойности:
При използване на същия пример с регистрационния номер, както по-горе, граничният анализ ще провери
Валидни данни = Табели с 6 или 7 знака
Невалидни данни = табели с 5 или 8 знака, а в някои случаи – с 4 и 9 знака.
Пример за анализ на граничната стойност
Може би най-добрият начин за пълно разбиране на концепцията е да разгледате още един или два примера за анализ на гранични стойности.
Пример за изпитване на гранична стойност #1
За да разгледаме по-подробно тестването на гранични стойности, нека разгледаме пример за домейн за проверка на възрастта.
Имаме поле, в което потребителят може да въведе възрастта си.
Граничните стойности са:
- Минимална възраст = 18 години
- Максимална възраст = 120 години
Пример за гранични тестови случаи:
Съществуват общо шест тестови случая:
- 17, 18 и 19, които са съответно под минимума, минимум и над минимума
- 119, 18 и 19, които са съответно под максимума, максимум и над максимума
Пример за изпитване на гранична стойност № 2.
В следващия пример за тестване на границите ще разгледаме уебсайт с минимална отстъпка при покупка на стойност 20 % за поръчки на стойност 100 и повече долара.
В този пример покупка на стойност над 600 USD води до 25% отстъпка. Тестът за гранична стойност ще се отнася за вложения между 100 и 600 USD.
Граничните стойности са:
Минимална квалифицирана отстъпка = 100 USD
Максимална отстъпка = 600 USD
Пример за гранични тестови случаи:
Отново генерираме общо шест тестови случая, които са:
- 99,99 USD, 100 USD и 100,01 USD, които са съответно под минималния размер, минималния размер и над минималния размер.
- 599,99 USD, 600 USD и 600,01 USD, които са съответно под максималния размер, максималния размер и над максималния размер.
Точно ли е граничното тестване при тестването на софтуер?
В научната статия ” Тестване на черната кутия с методите на разделяне на еквивалентността и анализ на граничните стойности” авторите изследват използването на разделяне на еквивалентността и анализ на граничните стойности за тестване на академична информационна система за университета Mataram в Индонезия.
Авторите са използвали популярния инструмент за тестване с отворен код Selenium за своите тестове и са провели общо 322 тестови случая. Тестовете за еквивалентност и анализът на граничните стойности разкриха около 80 неуспешни случая, което доведе до приблизително съотношение 75:25 между валидните и невалидните резултати от тестовете. Като цяло използването на комбинацията от еквивалентно разделяне и BVA при тестването на софтуер доведе до задълбочено и полезно тестване на софтуера.
Най-добри инструменти за тестване на граничната стойност
Макар че специалните софтуерни инструменти за тестване на граници са рядкост, има много забележителни инструменти за тестване, които могат да се справят с тази задача.
#3. TestCaseLab
TestCaseLab е базиран в облака инструмент за управление на тестове, който може да помогне при тестването на BVA. Софтуерът позволява на екипите да създават и управляват тестови казуси от интуитивния си и привлекателен потребителски интерфейс. TestCaseLab е гъвкав и функционален, но има своите ограничения, включително ограничени възможности за отчитане и персонализиране.
#2. Micro Focus UFT One
Micro Focus UFT One е инструмент за тестване на софтуер с фокус върху функционалното и регресионното тестване. Той поддържа различни платформи, устройства и тестване на API и предлага широки възможности за интеграция. Той предлага създаване на тестове без код и с ключови думи и може да помогне на екипите да създават лесно тестови случаи за анализ на граничната стойност. Има някои ограничения, които трябва да вземете предвид, като например стръмната крива на обучение и липсата на мощност в сравнение с инструменти като ZAPTEST.
#1. ZAPTEST
ZAPTEST е цялостен инструмент за автоматизирано тестване на софтуер с разширени възможности за RPA. Той е създаден, за да предостави на тестващите лесен за използване и надежден набор от инструменти за автоматизация на тестването, които могат да помогнат за проверка на софтуера по различни начини, включително с BVA при тестване на софтуер.
Някои от най-убедителните случаи на използване на ZAPTEST за подпомагане на анализа на граничната стойност включват генериране на тестови случаи, обработка на тестови данни, изпълнение на тестове и докладване и анализ. С редица шаблони и високо ниво на персонализация, съчетани със създаване на тестови случаи без код, потребителите на ZAPTEST могат бързо и лесно да създават и управляват надеждни тестови случаи за всички видове граничен анализ.
Освен генерирането и управлението на тестови случаи, възможностите на RPA на ZAPTEST могат да помогнат на екипите за тестване по други начини при тестването на анализа на граничната стойност. Например можете да автоматизирате изпълнението на тестови случаи, да генерирате тестови данни и да изграждате мощни интеграции с други инструменти за тестване.
Съвети за изпитване на гранични стойности
- Комбинирайте анализ на граничните стойности с разделяне по еквивалентност, за да сте сигурни, че тестовите ви случаи обхващат различни входни сценарии
- Използване на сценарии за невалидни входни данни (т.е. отрицателно тестване), за да се провери как софтуерът се справя с грешки и неочаквани входни данни.
- Инвестирайте време в определяне на граничните стойности за различните типове данни, като текст, числа, булеви стойности и др.
- Приоритизиране на тестването на граничната стойност за критични функционалности или области, в които е по-вероятно да възникнат грешки.
- Използвайте реалистични данни, които представляват вида данни, които потребителите ще въвеждат във вашите домейни.
Заключителни мисли
Анализът на граничните стойности е полезен подход за функционално тестване. Когато разполагате с домейн за въвеждане, трябва да проверите дали той приема валидни данни и изпраща съобщения за грешка, когато получи невалидни данни. Тестването с граничен анализ помага да се провери тази функционалност по ефективен начин, като се създават само тестовите случаи, необходими за цялостно тестване.
При граничното тестване се разглеждат стойности в приемливия диапазон или около него и се проверява как системата реагира на тези входни данни. Резултатът е много спестено време и намалени усилия, тъй като не е необходимо да създавате излишни тестови случаи. В забързания свят на разработката на софтуер, в който крайните срокове сякаш идват бързо, екипите за тестване се нуждаят от всякаква помощ.
