complete functional testing guide with its types
Подробен урок за функционално тестване с типове, техники и примери:
Какво е функционално тестване?
Функционалното тестване е вид тестване на черна кутия, което се извършва, за да се потвърди, че функционалността на приложение или система се държи според очакванията.
Това се прави, за да се провери цялата функционалност на дадено приложение.
СПИСЪК на уроците, обхванати в тази поредица:
Урок # 1: Какво е функционално тестване (този урок)
Урок # 2: Въпроси за интервю за тестване на функционалност
Урок № 3: Топ функционални инструменти за тестване на автоматизация
Урок № 4: Какво е нефункционално тестване?
Урок № 5: Разлика между единица, функционалност и Интеграция Тестване
Урок # 6 : Защо функционалното и функционалното тестване трябва да се правят едновременно
Инструменти:
Урок № 7: Функционална тестова автоматизация с Ranorex Studio
Урок № 8: UFT функционален инструмент Нови функции
Урок № 9: Функционална автоматизация на различни браузъри с помощта на инструмента за гарантиране на качеството на Parrot
Урок № 10: Урок на Jubula с отворен код за тестване на функционалността
Какво ще научите:
- Въведение в функционалното тестване
Въведение в функционалното тестване
Трябва да има нещо, което определя кое е приемливо поведение и кое не.
Това е посочено във функционална спецификация или спецификация на изискванията. Това е документ, който описва какво е разрешено на даден потребител да може да определи съответствието на приложението или системата с него. Освен това, понякога това може да доведе и до действителните бизнес сценарии, които да бъдат валидирани.
Следователно тестването на функционалност може да се извърши чрез две популярни техники :
- Тестване въз основа на изисквания: Съдържа всички функционални спецификации, които формират основа за всички тестове, които трябва да се проведат.
- Тестване въз основа на бизнес сценарии: Съдържа информация за това как системата ще се възприема от гледна точка на бизнес процеса.
Тестването и осигуряването на качеството са огромна част от процеса на SDLC. Като тестер трябва да сме наясно с всички видове тестове, дори ако не сме пряко ангажирани с тях ежедневно.
Тъй като тестването е океан, обхватът му наистина е толкова голям и имаме специални тестери, които се представят различни видове тестване . Най-вероятно всички ние трябва да сме запознати с повечето концепции, но няма да навреди да организираме всичко тук.
Видове функционални тестове
Функционалното тестване има много категории и те могат да се използват въз основа на сценария.
Най-известните видове са разгледани накратко по-долу:
Единичното тестване обикновено се извършва от разработчик, който пише различни кодови единици, които могат да бъдат свързани или несвързани, за да се постигне определена функционалност. Неговото, това обикновено включва писане на модулни тестове, които биха извикали методите във всяка единица и валидирали тези, когато се предадат необходимите параметри, а връщаната му стойност е според очакванията.
Покритието на кода е важна част от модулното тестване, където тестовите случаи трябва да съществуват, за да обхванат следните три:
i) Покритие на линията
ii) Покритие на пътя на кода
iii) Покритие на метода
Проверка на здравия разум : Тестване, което се прави, за да се гарантира, че всички основни и жизненоважни функции на приложението / системата работят правилно. Това обикновено се прави след тест за дим.
Тестване на дим : Тестване, което се извършва след всяко компилиране, се пуска, за да се гарантира стабилност на компилацията. Нарича се още тестване за проверка на компилация.
Тестове за регресия : Извършено тестване, за да се гарантира, че добавянето на нов код, подобрения, отстраняване на грешки не нарушава съществуващата функционалност или не причинява някаква нестабилност и все още работи в съответствие със спецификациите.
Регресионните тестове не трябва да бъдат толкова обширни, колкото действителните функционални тестове, но трябва да осигуряват точно размера на покритието, за да удостоверят, че функционалността е стабилна.
Тестове за интеграция : Когато системата разчита на множество функционални модули, които могат поотделно да работят перфектно, но трябва да работят последователно, когато са сглобени, за да се постигне сценарий от край до край, валидирането на такива сценарии се нарича Интеграционно тестване.
Тестване на бета / използваемост : Продуктът е изложен на действителния клиент в производство като среда и те тестват продукта. От това се извлича удобството на потребителя и се взема обратна връзка. Това е подобно на това при тестване за приемане от потребителя.
Нека представим това в лесна блок-схема:
Тестване на функционална система:
Тестване на системата е тестване, което се извършва на цялостна система, за да се провери дали тя работи според очакванията, след като всички модули или компоненти са интегрирани.
Тестване от край до край се извършва за проверка на функционалността на продукта. Това тестване се извършва само когато тестването за системна интеграция е завършено, включително както функционалните, така и нефункционалните изисквания.
=> Разлика между модулно, функционално и интеграционно тестване
Процес
Този процес на тестване има три основни стъпки:
Подход, техники и примери
Функционалното или поведенческо тестване генерира изход въз основа на дадените входове и определя дали системата функционира правилно според спецификациите.
Следователно изобразителното представяне ще изглежда както е показано по-долу:
Критерии за влизане / излизане
Критерии за влизане:
- Документът за спецификация на изискванията е дефиниран и одобрен.
- Подготвени са тестови случаи.
- Тестовите данни са създадени.
- Средата за тестване е готова, всички необходими инструменти са налични и готови.
- Пълно или частично приложение е разработено и тествано и е готово за тестване.
Критерии за изход:
- Изпълнението на всички функционални тестови случаи е завършено.
- Не са отворени критични грешки или P1, P2.
- Съобщените грешки са признати.
Включени стъпки
Различните стъпки, включени в това тестване, са посочени по-долу:
- Първата свързана стъпка е да се определи функционалността на продукта, който трябва да бъде тестван и включва тестване на основните функционалности, състояние на грешки и съобщения, тестване на използваемостта, т.е. дали продуктът е лесен за употреба или не и т.н.
- Следващата стъпка е да се създадат входни данни за функционалността, която ще бъде тествана съгласно спецификацията на изискването.
- По-късно, от спецификацията на изискванията, изходът се определя за тестваната функционалност.
- Изпълняват се подготвени тестови случаи.
- Действителният изход, т.е. изходът след изпълнение на тестовия случай и очаквания изход (определен от спецификацията на изискванията) се сравняват, за да се установи дали функционалността работи според очакванията или не.
Приближаване
Различни видове сценарии могат да бъдат разгледани и написани под формата на „тестови случаи“. Като хора от QA, всички знаем как изглежда скелетът на тестовия случай.
Той има най-вече четири части:
- Резюме на теста
- Предварителни условия
- Тестови стъпки и
- Очаквани резултати.
Опитът за автор на всякакъв вид тест е не само невъзможен, но и отнема много време и е скъп.
Обикновено бихме искали да разкрием максималните грешки, без избягвания със съществуващите тестове. Следователно QA трябва да използва техники за оптимизация и да стратегии как те биха подходили към тестването.
Нека обясним това с пример.
Примери за случаи на функционално тестване:
Вземете онлайн портал за HRMS, където служителят влиза в профила си със своя потребителски акаунт и парола. На страницата за вход има две текстови полета за потребителско име и парола и два бутона: Вход и Отказ. Успешното влизане отвежда потребителя до началната страница на HRMS и анулирането ще отмени влизането.
Спецификациите са, както е показано по-долу:
# 1) Полето за потребителски идентификатор отнема минимум 6 знака, максимум 10 знака, цифри (0-9), букви (a-z, A-z), специални знаци (разрешено е само подчертаване, точка, тире) и не може да остане празно. Потребителският идентификатор трябва да започва със знак или номер, а не със специални знаци.
# две) Полето за парола отнема минимум 6 знака, максимум 8 знака, цифри (0-9), букви (a-z, A-Z), специални знаци (всички) и не може да бъде празно.
Основният подход за тестване на този сценарий може да бъде класифициран в две широки категории:
- Положителни тестове и
- Отрицателно тестване
Разбира се, всяка от тези категории има своя подраздел от тестове, които ще бъдат проведени.
Положителни тестове са щастливи тестове на пътя, които се правят, за да се гарантира, че продуктът отговаря - поне основните изисквания, които са жизненоважни за използването на клиента.
Отрицателни сценарии се уверете, че продуктът се държи правилно, дори когато е подложен на неочаквани данни.
Предложено четене => Какво е отрицателно тестване и как да се пишат отрицателни тестови случаи
Сега, нека се опитам да структурирам техниките за тестване, като използвам блок-схема по-долу. Ще влезем в подробностите за всеки от тези тестове.
Техники за функционално тестване
# 1) Тестове, базирани на краен потребител / система
Тестваната система може да има много компоненти, които когато се обединят, постигат потребителския сценарий.
В Пример , клиентски сценарий ще включва задачи като зареждане на HRMS приложение, въвеждане на правилните идентификационни данни, отиване на началната страница, извършване на някои действия и излизане от системата. Този конкретен поток трябва да работи без никакви грешки за основен бизнес сценарий.
как да пиша uat тестови случаи
Някои проби са дадени по-долу:
Sl No | Обобщение | Предварително условие | Тестов случай | Очаквани резултати. |
---|---|---|---|---|
1. | Напълно привилегирован потребител може да прави промени в акаунта | 1) Потребителският акаунт трябва да съществува 2) Потребителят трябва да има необходимите привилегии | 1) Потребителят въвежда потребителския номер и паролата 2) Потребителят вижда разрешения за редактиране, за да модифицира самия акаунт 3) Потребителят променя информацията за акаунта и записва. 4) Потребителят излиза. | 1) Потребителят е влязъл в началната страница 2) Екранът за редактиране се представя на потребителя. 3) Информацията за акаунта се запазва 4) Потребителят се връща към страницата за вход |
2. | Друг валиден потребител без пълни привилегии | 1) Потребителският акаунт трябва да съществува 2) Потребителят трябва да има минималните привилегии | 1) Потребителят въвежда потребителския номер и паролата 2) Потребителят вижда разрешения за редактиране, за да модифицира само определени полета. 3) Потребителят променя само тези полета и записва. 4) Потребителят излиза. | 1) Потребителят е влязъл в началната страница 2) Екранът за редактиране се представя на потребителя само в определени полета. Полетата на акаунта са сиви. 3) Модифицираните полета се запазват 4) Потребителят се връща към страницата за вход |
Това е основен пример за това как се създават тестови случаи за ситуации. Форматът по-горе ще се прилага и за всички тестове по-долу. В името на силното концептуално заземяване съм подложил само няколко прости теста отгоре и отдолу.
# 2) Тестове за еквивалентност
В Разделяне на еквивалентност , данните от теста са разделени на различни дялове, наречени класове на данни за еквивалентност. Данните във всеки дял трябва да се държат по един и същи начин, следователно трябва да се тества само едно условие. По същия начин, ако едно условие в дял не работи, тогава никое от другите няма да работи.
Например , в горния сценарий полето за идентификация на потребителя може да има максимум 10 знака, така че въвеждането на данни> 10 трябва да се държи по същия начин.
# 3) Тестове за гранична стойност
Граничните тестове предполагат ограничения на данните за приложението и валидират поведението му.
Следователно, ако входовете се подават извън граничните стойности, тогава това се счита за отрицателно тестване. Така че минимум 6 знака за потребителя задават граничната граница. Тестове, написани, за да имат потребителски идентификатор<6 characters are boundary analysis tests.
# 4) Тестове, основани на решение
Тестовете, основани на решения, са съсредоточени около идеологията на възможните резултати от системата, когато е изпълнено определено условие.
В дадения по-горе сценарий могат незабавно да се изведат следните тестове, основани на решения:
- Ако са въведени грешни идентификационни данни, това трябва да посочи това на потребителя и да презареди страницата за вход.
- Ако потребителят въведе правилните идентификационни данни, той трябва да го отведе до следващия потребителски интерфейс.
- Ако потребителят въведе правилните идентификационни данни, но иска да отмени влизането, тогава той не трябва да отвежда потребителя до следващия потребителски интерфейс и да презарежда страницата за вход.
# 5) Тестове за алтернативен поток
Изпълняват се тестове за алтернативен път, за да се проверят всички възможни начини, които съществуват, различни от основния поток за изпълнение на функция.
# 6) Ad-hoc тестове
Когато повечето от грешките бъдат разкрити чрез горните техники, ad-hoc тестове са чудесен начин за разкриване на несъответствия, които не са наблюдавани по-рано. Те се изпълняват с мисленето за разбиване на системата и се проверява дали тя реагира грациозно.
Например , примерен тестов случай би бил:
- Потребителят е влязъл, но администраторът изтрива потребителския акаунт, докато изпълнява някои операции. Би било интересно да видим как приложението се справя грациозно с това.
Функционално срещу нефункционално тестване:
Нефункционални тестове фокусирайте се върху качеството на приложението / системата като цяло. Следователно, той се опитва да установи колко добре системата се изпълнява според изискванията на клиента, за разлика от функцията, която изпълнява.
=> Прочетете точната разлика тук
Функционална тестова автоматизация
Можем ли да автоматизираме функционални тестове?
С автоматизацията могат да се намалят ръчните усилия, да се спести време, да се избегне подхлъзване на грешки и да се увеличи ефективността.
Не е възможно обаче да се автоматизират всички и всичко. Това тестване може да бъде автоматизирано, но потребителят трябва да разработи тестови случаи за автоматизацията, които трябва да се извършат. Важно е да намерите правилните тестови случаи, които да бъдат автоматизирани заедно с подходящ инструмент.
Автоматизирането на функционални случаи може да има недостатъци, като например, че броят на тестовите случаи е много повече и се регресира отново и отново (което трябва да се направи), тогава разработчикът може да се сблъска с проблем при извършване на промени в кода.
Много пъти по време на извършване на анализ на дефекти, очевидната и многогодишна причина за бягство изглежда има липса на тестово покритие в определена функция.
Отново има няколко причини това да се случи, като липса на среда, липса на тестери, предоставяне на твърде много функции, по-малко време за покриване на всички аспекти на тестването и понякога просто пренебрегване.
Докато специалните тестови екипи могат да направят подробни тестове за всеки спринт или всеки тестов цикъл, дефекти винаги ще съществуват и винаги ще има дефекти, които могат да бъдат пропуснати. Това е една от основните потребности да има автоматизирана проверка на тестовете, като по този начин има значително подобрение в ефективността на цялостния тестов процес и обхвата на тестовите случаи.
Въпреки че автоматизираното тестване никога не може да замени ръчните тестове, наличието на идеална комбинация от двете ще се окаже жизненоважно за постигане на желаното качество в софтуерните проекти.
Съображения за автоматизация:
# 1) Изберете правилния инструмент за автоматизация : На пазара има няколко инструмента, за да изберете инструмент за автоматизация е истинска обезсърчителна задача! Можете обаче да направите списък с изисквания, въз основа на който можете да изберете кой инструмент за автоматизация да използвате.
Някои основни аспекти, за които трябва да помислите, включват:
- Изберете инструмент, който ще бъде лесен за използване от всички членове на QA на екипа, ако те все още нямат необходимите умения.
- Инструментът може да се използва в различни среди. За Пример : Могат ли скриптовете да се създават на една платформа на ОС и да се изпълняват на друга? Изисквате ли автоматизация на CLI, автоматизация на потребителския интерфейс, автоматизация на мобилни приложения или всичко друго?
- Инструментът трябва да притежава всички функции, от които се нуждаете. За Пример : Ако някои тестери не са добре запознати със скриптов език, инструментът трябва да има функция за запис и възпроизвеждане и след това да поддържа преобразуване на записания скрипт в желания скриптов език. По същия начин, ако имате нужда и от инструмента за поддръжка на автоматизирани тестове за изграждане, специфично отчитане и регистриране, то той трябва да може да направи и това.
- Инструментът трябва да може да поддържа повторната употреба на тестови случаи в случай на промени в потребителския интерфейс.
Инструменти за автоматизация : Има доста инструменти, които са на разположение за функционална автоматизация. Вероятно селенът е горещ фаворит, но има и други инструменти с отворен код, като Sahi, Watir, Robotium, AutoIt и т.н.
На пазара се предлагат няколко инструмента за автоматизация на тестовете. Но изборът на подходящ инструмент е много важен за организацията. Това може да зависи от изискването, лекотата на използване и цената играе основна роля тук.
По-долу са дадени някои от най-добрите функционални инструменти за тестване:
- Селен
- QTP
- Джунит
- Loadrunner
- САПУН
- TestComplete
=> Проверете този пълен списък с най-добрите инструменти за функционална автоматизация
# две) Изберете правилните тестови случаи за автоматизиране : Ако искате да извлечете най-доброто от автоматизацията, жизненоважно е да сте интелигентни относно тестовете, които избирате за автоматизиране. Ако има тестове, които изискват включване и изключване на някои настройки и конфигурации по време на изпълнението на теста, тогава те е най-добре да не бъдат автоматизирани.
Следователно можете да автоматизирате тестове, които:
- Трябва да се стартира многократно.
- Стартирайте с различни видове данни.
- Някои тестове P1, P2 отнемат много усилия и време.
- Тестове, които са склонни към грешки.
- Набор от тестове, които трябва да се изпълняват в различни среди, браузъри и т.н.
# 3) Специален екип за автоматизация : Това вероятно е пренебрегнато в повечето организации и автоматизацията е наложена на всички членове на екипа за QA.
Всеки член на екипа има различни нива на опит, набори от умения, нива на лихви, честотна лента за подпомагане на автоматизацията и др. Някои хора вероятно са по-квалифицирани в изпълнението на ръчни тестове, докато други могат да познават инструментите за скриптове и автоматизация.
В ситуации като тази е добра практика да се направи анализ на всички членове на екипа и да се накарат някои членове да се занимават само с автоматизация.
Дейността по автоматизация изисква време, усилия, знания и специален екип, който ще помогне да се постигнат необходимите резултати, вместо да се претоварват всички членове на екипа както с ръчно, така и с тестване за автоматизация.
# 4) Тестове, управлявани от данни: Автоматизираните тестови случаи, които изискват множество набори от данни, трябва да бъдат добре написани, за да могат да бъдат използвани повторно. Данните могат да бъдат записани в източници като текст или файл със свойства, XML файлове или да бъдат прочетени от база данни.
Какъвто и да е източникът на данни, създаването на добре структурирани данни за автоматизация прави рамката по-лесна за поддръжка и прави съществуващите тестови скриптове използвани с пълния си потенциал.
# 5) Промените в потребителския интерфейс не трябва да нарушават тестовете: Тестовите случаи, които създавате с помощта на избрания инструмент, трябва да могат да се справят с потенциалните промени в потребителския интерфейс. Например по-ранните версии на селен използваха местоположение за идентифициране на елементите на страницата.
Следователно, ако потребителският интерфейс се промени, тези елементи вече не са намерени на тези места и от своя страна ще доведат до масовия провал на тестовете.
Ето защо е важно предварително да разберете недостатъците на инструмента и да създадете тестовите случаи, така че да се изискват само минимални промени в случай на промени в потребителския интерфейс.
# 6) Често тестване: След като подготвите основна тестова група за автоматизация, планирайте да имате по-често изпълнение на тази група. Това има двупосочно предимство: Едното е, че можете да подобрите рамката за автоматизация и да я направите по-стабилна, а второто е, че ще уловите повече грешки в процеса.
Предимства
По-долу са изброени различните предимства на функционалното тестване:
- Това тестване възпроизвежда или е копие на това, което е действителната система, т.е.то е копие на това, което продуктът е в живата среда. Тестването е фокусирано върху спецификациите според употребата на клиента, т.е. системни спецификации, операционна система, браузъри и др.
- Той не работи върху каквито и да е, но и каквито и да било предположения за структурата на системата.
- Това тестване гарантира доставянето на висококачествен продукт, който отговаря на изискванията на клиента и гарантира, че клиентът е доволен от крайните резултати.
- Той осигурява доставка на продукт без грешки, който има всички функции, работещи според изискванията на клиента.
- Извършва се тестване въз основа на риска, за да се намалят шансовете за всякакъв вид риск в продукта.
Ограничения
Това тестване се прави, за да се гарантира, че продуктът работи според очакванията и цялото изискване е изпълнено и продуктът е точно според изискванията на клиента.
Въпреки това, той не отчита другите фактори като производителността на продукта, т.е. отзивчивост, време за пропускане и т.н., които са важни и са много необходими, за да бъдат част от тестването преди пускането на продукта.
Недостатъци
- Има много шансове за извършване на излишно тестване.
- Логически грешки могат да бъдат пропуснати в продукта.
- Това тестване се основава на изискването, ако в случай че изискването не е пълно или е сложно или не е ясно, извършването на това тестване при такъв сценарий става трудно и също може да отнеме много време.
Следователно и двата вида тестове са необходими за качествен продукт.
Заключение
Този урок подробно обсъжда всичко, което трябва да знаете за функционалното тестване, още от основите.
Функционалното тестване е един от важните процеси на тестване, тъй като проверява функционалността на даден продукт, който е най-необходим и наистина важен аспект на всеки продукт или приложение.
За автора: Санджай Залавадия - като вицепрезидент на клиентско обслужване за Зефир , носи над 15 години лидерски опит в ИТ и услугите за техническа поддръжка.
Надявам се, че някои от предложените от нас техники ще са полезни за всички читатели. Споделете вашите мисли в коментарите по-долу.
Предложено четене => Урок за тестване на функции
Препоръчително четене
- Функционално тестване срещу нефункционално тестване
- Алфа тестване и бета тестване (Пълно ръководство)
- Най-добри инструменти за тестване на софтуер 2021 г. [Инструменти за автоматизация на QA теста]
- Разликите между модулното тестване, интегрираното тестване и функционалното тестване
- Видове тестване на софтуер: Различни видове тестване с подробности
- Spock за интеграция и функционални тестове със селен
- Пълно ръководство за тестване за проверка на компилация (BVT тестване)
- Пълно ръководство за нефункционално тестване за начинаещи