differences between unit testing
Подробно сравнение на единица, интеграция и функционално тестване:
За всяко софтуерно приложение както тестването на модули, така и тестването за интеграция са много важни, тъй като всеки от тях използва уникален процес за тестване на софтуерно приложение.
Но всеки един или дори и двата не може да замени функционалното тестване в нито един момент.
Какво ще научите:
- Единично тестване срещу интеграционно тестване срещу функционално тестване
- Какво е единично тестване?
- Какво е тестване на интеграция?
- Единично тестване срещу тестване на интеграция
- Функционално тестване
- Точна разлика
- Заключение
- Препоръчително четене
Единично тестване срещу интеграционно тестване срещу функционално тестване
Единично тестване означава отделно тестване на отделни модули на приложение (без никакво взаимодействие със зависимости), за да се потвърди, че кодът прави нещата правилно.
Интеграционно тестване означава проверка дали различните модули работят добре, когато се комбинират заедно като група.
Функционално тестване означава тестване на парче функционалност в системата (може да взаимодейства със зависимости), за да се потвърди, че кодът прави правилните неща.
Функционалните тестове са свързани с тестове за интеграция, но те означават тестове, които проверяват цялостната функционалност на приложението с целия код, работещ заедно, почти тест за супер интеграция.
Единичното тестване обмисля проверка на отделен компонент на системата, докато тестването на функционалност отчита проверка на работата на приложението спрямо предвидената функционалност, описана в спецификацията на системните изисквания. От друга страна, интеграционното тестване обмисля проверка на интегрирани модули в системата.
И най-важното, за да оптимизирате възвръщаемостта на инвестицията (ROI), вашата кодова база трябва да има възможно най-много модулни тестове, по-малко интеграционни тестове и най-малък брой функционални тестове.
Това е илюстрирано най-добре в следната тестова пирамида:
char към низ c ++
Единичните тестове са по-лесни за писане и по-бързи за изпълнение. Времето и усилията за прилагане и поддържане на тестовете се увеличават от единично тестване до функционално тестване, както е показано в горната пирамида.
Пример:
Нека разберем тези три вида тестване с опростен пример.
E.g . За функционален мобилен телефон основните необходими части са „батерия“ и „сим карта“.
Пример за единично тестване - Батерията се проверява за нейния живот, капацитет и други параметри. Сим картата се проверява за нейното активиране.
Пример за тестване на интеграция - Батерията и SIM картата са интегрирани, т.е.сглобени, за да стартират мобилния телефон.
Пример за функционално тестване - Функционалността на мобилния телефон се проверява от гледна точка на неговите характеристики и използването на батерията, както и съоръженията за SIM карти.
Видяхме пример от гледна точка на неспециалисти.
Нека сега вземем технически пример за страница за вход:
Почти всяко уеб приложение изисква своите потребители / клиенти да влязат. За това всяко приложение трябва да има страница „Вход“, която съдържа следните елементи:
- Акаунт / потребителско име
- Парола
- Бутон за вход / вход
За единично тестване, следните случаи могат да бъдат тестовите случаи:
- Дължина на полето - полета за потребителско име и парола.
- Стойностите на полето за въвеждане трябва да са валидни.
- Бутонът за вход се активира само след като в двете полета се въведат валидни стойности (Формат и по дължина).
За интеграционно тестване следните случаи могат да бъдат тестовите случаи:
- Потребителят вижда приветственото съобщение след въвеждане на валидни стойности и натискане на бутона за вход.
- Потребителят трябва да бъде отворен към страницата за приветствие или началната страница след валидно въвеждане и щракване върху бутона Login.
Сега, след като модулните и интеграционни тестове са направени, нека видим допълнителното тестови случаи, които се разглеждат за функционално тестване:
- Очакваното поведение се проверява, т.е.може ли потребителят да влезе, като щракне върху бутона за вход след въвеждане на валидни стойности на потребителско име и парола.
- Има ли приветствено съобщение, което да се появи след успешно влизане?
- Има ли съобщение за грешка, което трябва да се появи при невалиден вход?
- Има ли съхранени бисквитки на сайта за полета за вход?
- Може ли инактивиран потребител да влезе?
- Има ли връзка „забравена парола“ за потребителите, които са забравили паролите си?
Има много повече такива случаи, които идват на ум на функционален тестер, докато извършват функционално тестване. Но разработчикът не може да вземе всички случаи, докато изгражда тестови случаи на Unit и Integration.
По този начин има много сценарии, които тепърва ще бъдат тествани дори след тестване на модули и интеграция.
Сега е време да проучим един по един модулни, интеграционни и функционални тестове.
Какво е единично тестване?
Както подсказва името, това ниво включва тестване на „Единица“.
Тук модулът може да бъде най-малката част от приложение, което може да се тества, било то най-малката индивидуална функция, метод и др. Разработчиците на софтуер са тези, които пишат модулните тестови случаи. Целта тук е да съответства на изискванията и очакваното поведение на устройството.
По-долу има няколко важни точки относно модулното тестване и неговите предимства:
- Единичното тестване се извършва преди тестване на интеграция от разработчици на софтуер, който използва техники за тестване на бяла кутия .
- Единичното тестване не само проверява положителното поведение, т.е. правилния изход в случай на валиден вход, но също така и грешките, които възникват при невалиден вход.
- Намирането на проблеми / грешки на ранен етап е много полезно и намалява общите разходи по проекта. Тъй като модулното тестване се извършва преди интегрирането на кода, откритите на този етап проблеми могат да бъдат решени много лесно и тяхното въздействие също е много по-малко.
- Единичен тест тества малки парчета код или отделни функции, така че проблемите / грешките, открити в тези тестови случаи, са независими и не засягат останалите тестови случаи.
- Друго важно предимство е, че модулните тестови случаи опростяват и улесняват тестването на кода. Така става по-лесно разрешаването на проблемите и на по-късен етап, тъй като трябва да се тества само последната промяна в кода.
- Единичният тест спестява време и разходи и е за многократна употреба и лесен за поддръжка.
JUnit ( Java рамка ), PHPUnit (PHP framework), NUnit (.Net framework) и др. Са популярни инструменти за модулно тестване, които се използват за различни езици.
Какво е тестване на интеграция?
Интеграционното тестване е тестване на интеграцията на различни части на системата заедно. Първо се интегрират две различни части или модули на системата и след това се извършва тестване за интеграция.
Целта на теста за интеграция е да се провери функционалността, надеждността и производителността на системата, когато е интегрирана.
Интеграционното тестване се извършва първо на модулите, които са първоначално тествани, а след това интегриращото тестване определя дали комбинацията от модулите дава желания изход или не.
Интеграционното тестване може да се извършва от независими тестери или от разработчици.
Има 3 различни типа подходи за тестване на интеграция. Нека обсъдим накратко всеки един от тях:
безплатно изтегляне на пълна версия на
а) Подход за интеграция на Големия взрив
При този подход всички модули или модули се интегрират и тестват едновременно като цяло. Това обикновено се прави, когато цялата система е готова за интеграционно тестване в един момент от времето.
Моля, не бъркайте този подход на интеграционно тестване със системно тестване, тества се само интеграцията на модули или модули, а не цялата система, както се прави при системното тестване.
Основният подход на Големия взрив предимство е, че всичко интегрирано се тества наведнъж.
Една основна недостатък е, че става трудно да се идентифицират неуспехите.
Пример: На фигурата по-долу блок 1 до блок 6 са интегрирани и тествани с помощта на подхода на Големия взрив.
б) Подход отгоре надолу
Интеграцията на модулите / модулите се тества от нива отгоре надолу стъпка по стъпка.
Първата единица се тества индивидуално чрез писане тест STUBS . След това по-ниските нива се интегрират едно по едно, докато последното ниво се събере и тества.
Подходът отгоре надолу е много органичен начин за интегриране, тъй като е в съответствие с това как нещата се случват в реалната среда.
Единственият загриженост с този подход е, че основната функционалност е тествана в края.
в) Подход отдолу нагоре
Единиците / модулите се тестват от ниско до най-високо ниво, стъпка по стъпка, докато всички нива на модули / модули бъдат интегрирани и тествани като едно цяло. Извикани програми за стимулиране ШОФЬОРИ се използват в този подход. По-лесно е да се открият проблеми или грешки на по-ниските нива.
Майорът недостатък този подход е, че проблемите на по-високо ниво могат да бъдат идентифицирани само в края, когато всички единици са интегрирани.
Единично тестване срещу тестване на интеграция
След като имахме достатъчно дискусии относно модулното тестване и интеграционното тестване, нека бързо да разгледаме разликите между двете в следващата таблица:
Единично тестване | Интеграционно тестване |
---|---|
Извършва се в началната фаза на тестване и след това може да се извърши по всяко време | Трябва да се извърши след модулно тестване и преди тестване на системата |
Тества единичния компонент на цялата система, т.е. тества единица в изолация. | Тества системните компоненти, работещи заедно, т.е.тества съвместната работа на множество единици. |
По-бързо за изпълнение | Може да работи бавно |
Няма външна зависимост. Всяка външна зависимост се подиграва или потиска. | Изисква взаимодействие с външни зависимости (напр. База данни, хардуер и др.) |
Просто | Комплекс |
Провежда се от разработчика | Провежда се от тестер |
Това е вид тестване на бяла кутия | Това е вид тестване на черна кутия |
Евтина поддръжка | Скъпа поддръжка |
Започва от спецификацията на модула | Започва от спецификацията на интерфейса |
Единичното тестване има тесен обхват, тъй като просто проверява дали всяка малка част от кода прави това, което е предназначена. | Той има по-широк обхват, тъй като обхваща цялото приложение |
Резултатът от модулното тестване е подробна видимост на кода | Резултатът от интеграционното тестване е подробната видимост на интеграционната структура |
Разкрийте проблемите във функционалността само на отделни модули. Не излага интеграционни грешки или общосистемни проблеми. | Разкрийте грешките, възникващи, когато различни модули взаимодействат помежду си, за да формират цялостната система |
Функционално тестване
ДА СЕ техника за тестване на черна кутия , където функционалността на приложението се тества, за да генерира желания изход при предоставяне на определен вход, се нарича „Функционално тестване“.
разлика между здравословното състояние и тестването на дим
В нашата процеси за тестване на софтуер , ние правим това, като пишем тестови случаи според изискванията и сценариите. За всяка функционалност броят на написаните тестови случаи може да варира от един до много.
Тестовите случаи се състоят основно от следните части:
- Резюме на теста
- Предпоставки (ако има такива)
- Стъпки за въвеждане на тест
- Данни от теста (ако има такива)
- Очаквана продукция
- Бележки (ако има такива)
„Въз основа на изискванията“ и „На базата на бизнес сценарий“ са двете форми на функционално тестване, които се провеждат.
При тестване на базата на изисквания се създават тестови случаи според изискването и се тестват съответно. При функционално тестване на бизнес сценарий тестването се извършва, като се имат предвид всички сценарии от бизнес гледна точка.
Въпреки това, основният недостатък на функционалното тестване е вероятната излишък при тестване и възможността за пропускане на някои логически грешки.
Точна разлика
Нека да разгледаме разликите им.
Ето някои от основните:
Единично тестване | Интеграционно тестване | Функционално тестване | |
---|---|---|---|
Определение и цел | Тестване на най-малките единици или модули поотделно. | Тестване на интеграция на две или повече единици / модули, комбинирани за изпълнение на задачи. | Тестване на поведението на приложението според изискването. |
Сложност | Изобщо не е сложен, тъй като включва най-малките кодове. | Малко по-сложни от единичните тестове. | По-сложни в сравнение с модулни и интеграционни тестове. |
Техники за тестване | Техника за тестване на бяла кутия. | Техника за тестване на бяла кутия и черна кутия. Тестване на сива кутия | Техника за тестване на черна кутия. |
Основно внимание | Отделни модули или модули. | Интеграция на модули или блокове. | Цялата функционалност на приложението. |
Грешка / Обхванати проблеми | Единичните тестове откриват проблеми, които често могат да възникнат в модулите. | Тестовете за интеграция откриват проблеми, които могат да възникнат при интегриране на различни модули. | Функционалните тестове откриват проблеми, които не позволяват на приложението да изпълнява своята функционалност. Това включва и някои базирани на сценарии проблеми. |
Проблем бягство | Няма шанс за бягство. | По-малък шанс за избягване на проблема. | Повече шансове за избягване на проблема, тъй като списъкът с тестове, които трябва да се изпълнят, винаги е безкраен. |
Прочетете също => Какво е тестване на характеристики
Заключение
Всички тези три вида тестване са свързани.
За да се постигне пълно покритие, се изисква да има модулни тестове за пътищата / редовете на кода, функционални и интеграционни тестове, за да се гарантира, че ‘единиците’ работят съвместно.
Надявам се, че тази статия ще ви даде ясна представа за модулното, интеграционното и функционалното тестване заедно с разликите им, въпреки че има много повече от тези форми на тестване !!
Препоръчително четене
- Най-добри инструменти за тестване на софтуер 2021 г. [Инструменти за автоматизация на QA теста]
- Spock за интеграция и функционални тестове със селен
- Функционално тестване срещу нефункционално тестване
- Изтегляне на eBook за тестване на Primer
- Топ 10 Инструменти за тестване на интеграция за писане на тестове за интеграция
- Основни разлики между тестване на черна кутия и тестване на бяла кутия
- Пълно ръководство за функционално тестване с неговите типове и пример
- Функционално тестване срещу тестване на производителността: Трябва ли да се прави едновременно?