validation testing ultimate guide
Разгледайте значението на тестовете за валидиране:
Какво ще научите:
- Какво е тестване за валидиране?
- Разлика между проверка и проверка
- Включени етапи
- Примерни случаи на тестове за проверка или протокол
- Заключение
- Препоръчително четене
Какво е тестване за валидиране?
Тестването за валидиране е процесът за гарантиране дали тестваният и разработен софтуер отговаря на нуждите на клиента / потребителя. Логиката на бизнес изискванията или сценариите трябва да бъдат подробно тествани. Всички критични функционалности на приложението трябва да бъдат тествани тук.
Като тестер винаги е важно да знаете как да проверите бизнес логиката или сценариите, които са ви дадени. Един такъв метод, който помага за подробна оценка на функционалностите, е процесът на валидиране.
Винаги, когато бъдете помолени да извършите тест за валидиране, това носи голяма отговорност, тъй като трябва да тествате всички критични бизнес изисквания въз основа на нуждите на потребителя. Не трябва да има дори едно пропускане на изискванията, зададени от потребителя. Следователно задълбочените познания за проверка на валидността са много важни.
Като тестер трябва да прецените дали резултатите от изпълнението на теста отговарят на посочените в документа за изискванията. Всяко отклонение трябва да се докладва незабавно и това отклонение се нарича грешка.
Инструменти като Център за качество на HP, Селен, Апиум и др. Се използват за извършване на тест за валидиране и можем да съхраняваме резултатите от теста там. Правилният план за изпитване, изпълненията на теста, доклади за дефекти, отчети и показатели са важните резултати, които трябва да бъдат изпратени.
От гледна точка на компанията, тестът за валидиране в прости се извършва чрез следните стъпки:
- Вие събирате бизнес изискванията за тестване за валидиране от крайния потребител.
- Подгответе бизнес плана и го изпратете за одобрение на участващите на място / заинтересованите страни.
- След одобряване на плана започвате да пишете необходимите тестови случаи и да ги изпращате за одобрение.
- След като бъдете одобрени, започвате да завършвате тестването с необходимия софтуер, среда и изпращате резултатите, както е поискано от клиента.
- След одобрение на резултатите, тестването на UAT се извършва от клиента.
- След това софтуерът отива за производство.
отделна верижна хеш таблица c ++ изпълнение
Нека сега разгледаме повече за валидирането в детайли.
Разлика между проверка и проверка
Нека ги разберем с пример по прост начин.
Пример:
Изискване на клиента:
Предложената инжекция не трябва да тежи над 2 cm.
Тест за проверка:
- Проверете дали инжекцията е инжекцията, която не тежи над 2 см, като използвате контролен списък, преглед и дизайн.
Тест за валидиране:
- Проверете дали инжекцията не тежи над 2 см, като използвате ръчно или автоматизирано тестване.
- Трябва да проверите всеки възможен сценарий, свързан с инжекционното тегло, като използвате всеки подходящ метод за тестване (функционални и нефункционални методи).
- Проверете за измервания по-малки от 2 cm и над 2 cm.
Проверка | Проверка |
---|---|
Процесът просто проверява дизайна, кода и програмата. | Той трябва да оцени целия продукт, включително кода. |
Включени отзиви, разходки, инспекции и проверка на бюро. | Включени са функционални и нефункционални методи за тестване. Извършва се задълбочена проверка на продукта. |
Той проверява софтуера със спецификация. | Той проверява дали софтуерът отговаря на нуждите на потребителя. |
Включени етапи
- Квалификация за дизайн: Това включва създаване на тестов план въз основа на бизнес изискванията. Всички спецификации трябва да бъдат споменати ясно.
- Квалификация за инсталиране: Това включва инсталиране на софтуер въз основа на изискванията.
- Оперативна квалификация: Това включва фаза на тестване, базирана на спецификацията на потребителските изисквания.
Това може да включва Тестване на функционалността:
-
- Единично тестване - Черна кутия, Бяла кутия, Сива кутия.
- Интеграционно тестване - Отгоре надолу, отдолу нагоре, Голям взрив.
- Тестване на системата - Тестване на здравословността, дима и регресията.
- Квалификация за изпълнение: UAT (Тест за приемане от потребителя) - Алфа и бета тестване.
- Производство
Квалификация за дизайн
Квалификацията за дизайн просто означава, че трябва да подготвите дизайна на софтуера по такъв начин, че да отговаря на потребителските спецификации. Преди всичко трябва да вземете Документ за спецификация на потребителските изисквания (URS) от клиента, за да се пристъпи към проектирането.
Тестова стратегия:
Този документ формира основата за изготвяне на тестовия план. Обикновено се изготвя от ръководителя на екипа или ръководителя на проекта. Той описва как ще продължим да тестваме и да постигнем желаната цел.
За да се включат всички процедури, трябва да бъде разработен подходящ план и да бъде одобрен от заинтересованите страни. Така че уведомете ни компонентите на плана за тестване.
В няколко проекта планът за изпитване и тестовата стратегия могат да бъдат включени като един документ. Изготвят се и отделни стратегически документи за сложен проект (предимно в техника на автоматизация).
Компоненти на плана за тестване на валидация:
- Описание на проекта
- Разбиране на изискванията
- Обхват на тестване
- Нива на изпитване и график на изпитване
- Стартирайте създаването на план
- Изисквания към хардуер-софтуер и персонал
- Роли и отговорности
- Предположение и зависимости
- Рискове и смекчаване
- Отчет и показатели
Описание на проекта: Тук трябва да изясните цялото описание на приложението, предоставено ви за тестване. Той трябва да включва всички функционалности на приложението.
Разбиране на изискванията: След като получите USR, трябва да споменете разбираните изисквания от ваша страна. Можете също така да повдигнете разяснения, ако има такива. Това е основата или критериите за изпитване за тестване.
Обхват на тестване: Обхватът трябва да включва модулите в детайли, заедно с характеристиките на високо ниво. Трябва да кажете на клиента какви изисквания бихте покрили при тестването си.
От бизнес гледна точка може да бъде поискано тестване за валидиране за критичните изисквания на приложението. Това просто означава, че казвате какво ще бъде обхванато и какво не .
Нива на тестване и график на тестване: Трябва да споменете колко кръга тестове трябва да бъдат проведени. Цялостното усилие за проекта за тестване се изчислява, като се използват стандартните техники за оценка като оценка на Test Case Point (TCP) и т.н.
Както подсказва името график на теста описва как ще се проведе тестването. Също така трябва да се посочва как и кога ще бъде извършено одобрението и ще бъдат извършени прегледи.
Пример:
Дизайнът на уеб страница е разглежданият проект.
Нивата на тестване включват:
Ниво 1: Тестване на дим
Ниво 2: Единично тестване
Ниво 3: Интеграционно тестване
Ниво 3: Тестване на системата
Ниво 3: Изпитване за приемане
График на теста:
- Подаване на план - Ден 1
- Дизайн на тестови случаи - Ден 2
- Сухо бягане и отстраняване на грешки - Ден 4
- Преглед- Ден 5
- Официално бягане - Ден 6
- Резултати, изпратени за одобрение - Ден 8
- Доклади - Ден 10
Изпълнете създаването на план: Планът за изпълнение маркира броя на изпълненията, необходими за тестване. Всяко бягане, което изпълнявате на място, ще бъде отбелязано от екипа на място.
въпроси за интервю за оракул и отговори за опитни
Например, когато използвате Инструмент HP Quick Test Professional за изпълнение, броят на изпълненията ще бъде показан в раздела Runs на тестовия план.
Изисквания към хардуер-софтуер и персонал:
- Хардуерни и софтуерни изисквания като устройства, версии на браузъра, IOS, инструменти за тестване, необходими за проекта.
- Персонал означава назначаване на лицата, необходими за тестване. Тук можете да споменете броя на отборите.
- В случай, че имате нужда от допълнителни членове за тестване, можете да поискате на място в зависимост от обхвата на тестване. Просто когато броят на тестовите случаи се увеличи, това означава, че имате нужда от повече членове на екипа, за да ги изпълните.
Роли и отговорности: Това предполага възлагане на задачи на съответните роли, отговорни за провеждането на различните нива на тестване.
Например,
Едно приложение трябва да бъде тествано от екип, състоящ се от 4 члена, за да изпълни 4 протокола за проверка и можете да делегирате отговорностите, както следва:
- Тестово ръководство: Изготвяне на план за изпитване
- Член на отбора 1: Проектиране и изпълнение на протоколи 1,2.
- Член на отбора 2: Проектиране и изпълнение на протоколи 3,4.
- Член на екипа: Изготвяне на доклади, преглед и показатели.
Предположение и зависимости: Това означава, че предположенията, направени по време на проектирането, и зависимостите, идентифицирани за тестване, ще бъдат включени тук.
Рискове и смекчаване: Рискове, свързани с планирането на теста, като наличност на желаната среда, компилация и др., Заедно с планове за смекчаване и извънредни ситуации.
Отчет и показатели: Тук трябва да се споменат фактори, които са били използвани за тестване и доклади до заинтересованите страни.
Пример за мобилно приложение е даден по-долу:
Квалификация за инсталиране
- Квалификацията за инсталиране съдържа подробности като коя и колко тестови среди ще бъдат използвани, какво ниво на достъп се изисква за тестерите във всяка среда заедно с необходимите тестови данни. Тя може да включва съвместимост на браузъра, инструменти, необходими за изпълнение, устройства, необходими за тестване и др. Разработваната система трябва да бъде инсталирана в съответствие с изискванията на потребителя.
- Тестови данни може да са необходими за тестване на някои приложения и те трябва да бъдат предоставени от подходящия човек. Това е жизненоважна предпоставка.
- Някои приложения може да изискват база данни. Трябва да съхраняваме всички данни, необходими за тестване, в база данни, за да потвърдим спецификациите.
Например, Ново приложение казва, че „abc“ трябва да бъде тествано в мобилни устройства (Android 4.3.1) и браузър (Chrome 54), в такъв случай трябва да следим следното:
- Проверете дали е дадено подходящо разрешение, за да проверите сайта на приложението „abc“.
- Вижте дали устройствата, използвани за тестване на приложението, като мобилни (android / ios), браузър-Chrome, Internet Explorer с необходимата версия са налични.
- Проверете дали те са инсталирани правилно с посочените версии (Например: Chrome 54, Android версия 4.3.1).
- Уверете се, че приложението е достъпно както в браузъра, така и в мобилното устройство.
Оперативна квалификация
Експлоатационната квалификация гарантира, че всеки модул и подмодул, проектирани за приложението в теста, функционира правилно, както се очаква в желаната среда.
Тестване за валидиране като цяло се извършва в следната йерархия.
Функционалното тестване играе основна роля в тестовете за валидиране. Това просто означава, че трябва да проверите функционалността на приложението от всяко споменато критично изискване. Това проправя пътя за картографиране на изискванията, споменати в документа за функционална спецификация, и гарантира, че продуктът отговаря на всички споменати изисквания.
Функционално тестване и неговите видове
Както подсказва името, функционалното тестване е тестване на функциите, т.е. какво трябва да прави софтуерът. Функционалностите на софтуера ще бъдат дефинирани в документа за спецификация на изискванията.
Нека да разгледаме набързо неговите видове.
# 1) Тестване на единица:
Единичното тестване е тестване на отделните единици / модули / компоненти / методи на дадената система. Валидирането на полето, управлението на оформлението, проектирането и т.н. се тестват с различни входове след кодирането. Всеки ред от кода трябва да бъде валидиран за отделните тестови случаи.
Единичното тестване се извършва от самите разработчици. Тук цената за отстраняване на грешки е по-малка в сравнение с другите нива на тестване.
Пример:
Оценяването на цикъл на кода за функция казва, че изборът на пол е пример за тестване на единица.
# 2) Тестване на черна кутия:
Тестването на поведението на дадено приложение за желаните функционалности спрямо изискванията, без да се фокусират вътрешните детайли на системата, се нарича Тестване на черната кутия. Обикновено се извършва от независим екип за тестване или от крайните потребители на приложението.
Приложението се тества със съответни входове и се тества, за да се провери дали системата се държи по желание. Това може да се използва за тестване както на функционални, така и на нефункционални изисквания.
# 3) Тестване на бяла кутия:
Тестване на бяла кутия не е нищо друго освен подробна проверка на програмния код по код. Цялата работа на приложението зависи от написания код, поради което е необходимо да тествате кода много внимателно. Трябва да проверите всяка единица и нейната интеграция като цялостен модул поетапно.
Тестер с познания по програмиране е задължителен критерий тук. Това ясно установява дали има някакво отклонение в работния процес на приложението. Полезно е както за разработчиците, така и за тестерите.
# 4) Тестване на сива кутия:
Тестването на сива кутия е комбинация от тестване на бяла кутия и черна кутия. Тук са известни частични познания за структурата или кода на тестваната единица.
Интеграционно тестване и неговите видове
Отделните компоненти на софтуера, които вече са тествани при модулно тестване, са интегрирани и тествани заедно, за да се тестват техните функционалности като цяло, за да се осигури поток от данни в модулите.
Това се прави от самите разработчици или от независим екип за тестване. Това може да стане след като са тествани две или повече единици.
Подход отгоре надолу:
При този подход първо се тестват най-горните единици, а след това поетапно се тестват единиците от по-ниското ниво. Необходими са тестови щифтове, които могат да се използват за симулиране на по-ниско ниво, които може да не са налични по време на началните фази.
Подход отдолу нагоре:
При този подход първо се тестват долните модули, интегрирани и след това тестваните единици от по-високо ниво. Необходими са тестови клещи, които могат да се използват за симулиране на единици от по-високо ниво, които може да не са достъпни през началните фази.
Тестване на системата и нейните типове
Тестването на цялостната система / софтуер се нарича системно тестване. Системата е тествана напълно в съответствие със спецификациите за функционални изисквания. Тестването на системата се извършва спрямо функционалните и нефункционалните изисквания. Тестването на черна кутия обикновено се предпочита за този тип тестване.
# 1) Тестване на дим:
Когато строителите дават компилацията да тества първоначално, ние трябва да тестваме цялостно компилацията. Това се нарича тестване на дим. Трябва да заявим дали компилацията е в състояние на допълнителни тестове или не.
За да извършите валидиране, се нуждаете от правилна компилация. Следователно тестването на дим първо се извършва от екипа за тестване. Работният процес на тестваното приложение трябва да бъде тестван или с тестовите случаи, или без него. Тестовият случай, обхващащ целия поток, е полезен за това тестване.
# 2) Тестване на разумността:
При тестване за здравословно състояние се тестват основните функционалности на модулите на тестваното приложение. При тестване на уебсайт, който има 3 раздела, т.е. създаване на профил, образование, влизане и т.н., в IRCTC , основните функционалности на всички тези раздели трябва да бъдат проверени, без да се задълбочава.
Менютата, подменютата, разделите трябва да бъдат тествани във всички модули. Това е подмножество на регресионното тестване, тъй като тестването се извършва само на основния поток, а не в дълбочина.
# 3) Тестване на регресия:
За всяко издание на проекта екипът за разработка може да въведе определени промени. Валидирането, ако въведените нови промени не са повлияли на работния поток на системата, се нарича Регресионно тестване. Тук трябва да бъдат тествани само някои тестови случаи, свързани с новите изисквания.
как да конфигурирам junit в eclipse
Квалификация за изпълнение
UAT (Тест за приемане от потребителя):
Това е последната фаза на тестване, която се прави, за да се гарантира, че системата се държи според изискванията, отговарящи на посочените изисквания. Това се прави от клиента. След като клиентът сертифицира и изчисти тестването на системата, продуктът може да отиде за внедряване.
Алфа и бета тестване:
Алфа тестването се извършва от разработчиците на приложението преди пускането на сайта за разработка на софтуер. Включва тестване на черно-бяла кутия. Бета тестването се извършва от страна на клиента, след като продуктът е разработен и внедрен.
Примерни случаи на тестове за проверка или протокол
С моя опит написах този протокол за вход в Gmail.
Задълбочената проверка на покритата функционалност за вход е това, което всъщност е валидиране. Но бих искал да спомена, че използваният стил на колоните на изреченията може напълно да се различава и зависи от изискванията на клиента.
=> Изтеглете примерни случаи за проверка на валидността: Тест за вход в Gmail
Заключение
Е, валидирането е свързано с подробен анализ на функционалностите на продукта. Като тестер за валидиране, винаги трябва да помните да отчитате отклоненията там и там, за да получите оптимални резултати при тестване.
Всеки написан тест трябва да бъде остър, кратък и разбираем дори за обикновения човек. Тестерът за валидиране трябва да гарантира, че се разработва правилният продукт в съответствие с посочените изисквания.
Като ръководство за тестване за валидиране, аз разгледах процеса, свързан с валидирането.
Квалификация за проектиране, която включва плана за валидиране, Квалификация за инсталиране, която говори за инсталиране на хардуер-софтуер, Оперативна квалификация, която включва цялото тестване на системата, Квалификация за производителност, която включва тестване за приемане от потребителя, което предоставя разрешение за производство.
Надявам се, че тази статия ще е обогатила вашите познания за концепцията за тестване за валидиране !!
Препоръчително четене
- Най-добри инструменти за тестване на софтуер 2021 г. [Инструменти за автоматизация на QA теста]
- Алфа тестване и бета тестване (Пълно ръководство)
- Основни разлики между тестване на черна кутия и тестване на бяла кутия
- Функционално тестване срещу нефункционално тестване
- Изтегляне на eBook за тестване на Primer
- Пълно ръководство за тестване за проверка на компилация (BVT тестване)
- Какво е системно тестване - Ръководство за крайни начинаещи
- Ръководство за тестване на сигурността на уеб приложения