Меню

Какво е тестване на компоненти или модули (научете с примери)

what is component testing

Опитайте Нашия Инструмент За Премахване На Проблемите

Какво е тестване на компоненти, наричано още модулно тестване при тестване на софтуер:

Компонентът е най-ниската единица от всяко приложение. И така, тестване на компоненти; както подсказва името, е техника за тестване на най-ниската или най-малката единица от всяко приложение.

Тестването на компоненти понякога се нарича и тестване на програма или модул.

Приложението може да се мисли за комбинация и интеграция на много малки отделни модули. Преди да тестваме цялата система, е важно всеки компонент ИЛИ най-малката единица на приложението да бъде тестван щателно.

компютърни инструменти за ремонт и оптимизиране на Windows 10

В този случай модулите или блоковете се тестват независимо. Всеки модул получава вход, извършва някаква обработка и генерира изхода. След това изходът се валидира спрямо очакваната функция.

Какво е тестване на компоненти

Софтуерните приложения са огромни по своята същност и е предизвикателство да се тества цялата система. Това може да доведе до много пропуски в покритието на теста. Следователно, преди да преминете към тестване на интеграция или функционално тестване, препоръчително е да започнете с тестване на компоненти.

Прочетете също=> Разлика в единица, интеграция и функционално тестване

Какво ще научите:

Тестване на компоненти

Това е един вид тестване на бяла кутия.

И така, тестването на компоненти търси грешки и проверява функционирането на модулите / програмите, които могат да се тестват отделно.

Съществува тестова стратегия и план за тестване на компонентите. И за всеки компонент има тестов сценарий, който ще бъде допълнително разбит в тестовите случаи. Диаграмата по-долу представя същото:

Тестване на компоненти

Целта на тестването на компоненти

Основната цел на тестването на компонентите е да се провери поведението вход / изход на тестовия обект. Той гарантира, че функционалността на тестовия обект работи правилно и напълно в съответствие с желаната спецификация.

Входни данни за тестване на ниво компонент

Четирите основни входа за тестване на ниво компонент са:

  • План за тестване на проекта
  • Системни изисквания
  • Спецификации на компонентите
  • Внедряване на компоненти

Кой извършва тестване на компоненти?

Тестването на компоненти се извършва от QA услуги или тестера.

Какво се тества при тестване на компоненти?

Тестването на компоненти може да вземе предвид проверката на функционални или специфични нефункционални характеристики на системните компоненти.

Това може да бъде тестване на поведението на ресурсите (например определяне на изтичане на памет), тестване на производителността, структурно тестване и др.

Когато е приключило тестването на компоненти?

Тестването на компоненти се извършва след модулно тестване.

Компонентите се тестват веднага след създаването им, така че има шанс резултатите, извлечени от тествания компонент, да зависят от други компоненти, които от своя страна не са разработени към момента.

В зависимост от модела на жизнения цикъл на разработката тестването на компоненти може да се извършва изолирано с други компоненти на системата. Изолацията се прави, за да се предотвратят външни влияния.

Така че, за да тестваме този компонент, ние използваме Stubs и Driversза симулиране на интерфейса между софтуерните компоненти.

Интеграционното тестване се извършва след тестване на компоненти.

Тестова стратегия за тестване на компоненти

В зависимост от дълбочината на тестване нивото на тестване на компонентите е разделено на две части:

  1. Тестване на компоненти в малък (ctis)
  2. Тестване на компоненти в големи (CTIL)

Когато тестването на компоненти се извършва изолирано с други компоненти, то се нарича като тестване на компоненти в малки. Това се прави, без да се обмисля интеграция с други компоненти.

Когато тестването на компоненти се извършва без изолация с други компоненти на софтуера, тогава това се нарича като тестване на компоненти. Това се случва, когато има зависимост от функционалния поток на компонентите и по този начин не можем да ги изолираме.

Ако компонентите, от които имаме зависимост, все още не са разработени, тогава използваме фиктивни обекти вместо действителните компоненти. Тези фиктивни обекти са мъниче (наричана функция) и драйвер (повикваща функция).

Стъбчета и драйвери

Преди да прескоча накратко за Stubs и Drivers, трябва да направя кратко за разлика между компонентни тестове и тестове за интеграция. Причината е - гредите и драйверите също се използват при тестване на интеграция, така че това може да доведе до известно объркване между тези две техники за тестване.

Техниката за интеграционно тестване е техника, при която последователно комбинираме 2 компонента и заедно тестваме интегрираната система. Данните от една система се прехвърлят към друга система и коректността на данните се проверява за интегрираната система.

За разлика от модулното тестване, при което единичният компонент / модул се тества щателно, преди да се интегрира с други компоненти. Така че, можем да кажем, че тестването на компоненти се извършва преди тестването на интеграция.

Както интеграция, така и компоненти Стъбчета и драйвери .

„Шофьори“ са фиктивни програми, които се използват за извикване на функциите на най-ниския модул, в случай че извикващата функция не съществува.

„Стъбс“ може да се нарича кодов фрагмент, който приема входовете / заявките от най-горния модул и връща резултатите / отговора

Както беше обяснено по-рано, компонентите се тестват индивидуално и независимо. Така че, може да има някои характеристики на компонентите, в зависимост от другия компонент, който не е разработен в момента. Така че, за да тестваме компонентите с тези „неразвити“ характеристики, трябва да използваме някои стимулиращи агенти, които да обработят данните и да ги върнат на извикващите компоненти.

По този начин ние гарантираме, че отделните компоненти са тествани щателно.

отделните компоненти се тестват щателно

Тук виждаме, че:

  • C1, C2, C3, C4, C5, C6, C7, C8, C9 ————— са компонентите
  • C1, C2 и C3 заедно правят Подединицата 1
  • C4 и C5 заедно правят подблока 2
  • C6, C7 и C8 заедно правят Подблок 3
  • Само C9 прави субединицата 4
  • Подблок 1 и Подединица 2 се комбинират, за да направят Бизнес блок 1
  • Подблок 3 и Подблок 4 се комбинират, за да направят Бизнес звено 2
  • Business Unit 1 и Business Unit 2 се комбинират, за да направят приложението.
  • Така че, в този случай тестването на компоненти ще бъде да се тестват отделните компоненти, които са C1 до C9.
  • The Нето стрелката между подблок 1 и подблок 2 показва точката за тестване на интеграцията.
  • По същия начин Нето стрелката между подблок 3 и подблок 4 показва точката за тестване на интеграцията
  • Зелената стрелка между Бизнес единица 1 и Бизнес единица 2 показва точката за тестване на интеграцията

Следователно ще направим:

  • СЪСТАВНА ЧАСТ тестване за C1 до C9
  • ИНТЕГРАЦИЯ тестване между подразделенията и бизнес звената
  • СИСТЕМА тестване на приложението като цяло

Пример

Досега трябва да сме установили, че тестването на компоненти е някаква техника за тестване на бяла кутия . Е, може и да е правилно. Но това не означава, че тази техника не може да се използва в техниката за тестване на черната кутия.

java добавяне към края на масива

Помислете за огромно уеб приложение, което започва със страница за вход. Като тестер (и това в гъвкав свят) не можехме да чакаме, докато цялото приложение бъде разработено и готово за тестване. За да увеличим времето си за пускане на пазара, трябва да започнем да тестваме рано. Така че, когато видим, че страницата за вход е разработена, трябва да настояваме тя да бъде предоставена за тестване.

Веднага след като имате на разположение страницата за вход, която можете да тествате, можете да изпълните всичките си тестови случаи (положителни и отрицателни), за да сте сигурни, че функционалността на страницата за вход работи според очакванията.

Предимствата на тестването на вашата страница за вход в този момент биха били:

кой е най-добрият анти шпионски софтуер
  • Потребителският интерфейс е тестван за използваемост (правописни грешки, логотипи, подравняване, форматиране и т.н.)
  • Опитайте се да използвате техники за отрицателно тестване като удостоверяване и упълномощаване. В тези случаи има огромна вероятност да се открият дефекти.
  • Използване на техники като SQL инжекции би гарантирало да се тества нарушаването на сигурността на много ранен етап.

Дефектите, които бихте регистрирали на този етап, биха действали като „научени уроци“ за екипа за разработка и те ще бъдат внедрени в кодирането на поредната страница. Следователно, като тествате рано - вие сте осигурили по-добро качество на страниците, които тепърва ще бъдат разработени.

Тъй като останалите последователни страници все още не са разработени, може да са ви необходими заглушки, за да проверите функционалността на страницата за вход. Например ,може да искате проста страница, в която да се посочи „регистрирането успешно“, в случай на правилни идентификационни данни и изскачащ прозорец със съобщение за грешка в случай на неправилни идентификационни данни.

Можете да преминете през нашия по-ранен урок нататък Интеграционно тестване за да имате повече информация за Stubs и Drivers.

Как да напиша тестови случаи на компоненти?

Тестовите случаи за тестване на компоненти са получени от работни продукти, например софтуерно проектиране или модел на данни. Всеки компонент се тества чрез поредица от тестови случаи, където всеки тестов случай обхваща определена комбинация от вход / изход, т.е. частична функционалност.

По-долу е даден примерен фрагмент на тестов компонент за модул за вход.

По подобен начин можем да напишем и други тестови случаи.

тестови случаи

Тестване на компоненти срещу единично тестване

Първата разлика между тестването на компоненти и модулното тестване е, че първата се извършва от тестери, докато втората се извършва от разработчици или специалисти по SDET.

Единичното тестване се провежда на гранулирано ниво. От друга страна, тестването на компоненти се извършва на ниво приложение. При модулното тестване се проверява дали дадена програма или част от кода се изпълнява съгласно посоченото. При тестване на компоненти всеки обект на софтуера се тества отделно със или без изолация с други компоненти / обект на системата.

Така че тестването на компоненти прилича на модулно тестване, но се извършва на по-високо ниво на интеграция и в контекста на приложението (не само в контекста на тази единица / програма, както при модулното тестване).

Тестване на компонент срещу интерфейс срещу интеграция срещу системи

Съставна част , както обясних, е най-ниската единица на приложение, което се тества независимо.

An интерфейс е свързващият слой на 2-те компонента. Тестването на платформата или интерфейса, на който взаимодействат двата компонента, се нарича Интерфейсно тестване.

Сега тестването на интерфейса е малко по-различно. Тези интерфейси са предимно API или уеб услуги , така че тестването на тези интерфейси не би било подобно на техниката Black Box, а по-скоро бихте правили някакъв вид API тестване или тестване на уеб услуги, използвайки Потребителски интерфейс на SOAP или друг инструмент.

След като приключи интерфейсното тестване, идва Интеграционно тестване .

По време на теста за интеграция, ние комбинираме отделните тествани компоненти един по един и го тестваме постепенно. По време на интеграцията потвърждаваме, че отделните компоненти, когато се комбинират един по един, се държат според очакванията и данните не се променят при преминаване от 1 модул към друг модул.

След като всички компоненти са интегрирани и тествани, ние изпълняваме Тестване на системи за да тествате цялото приложение / система като цяло. Този тест потвърждава бизнес изискванията спрямо внедрения софтуер.

Заключение

бих го казал Единично тестване и Изпитването на компоненти се извършва едно до друго.

За разлика от модулното тестване, което се извършва от екипа за разработка, тестването на компоненти / модули се извършва от екипа за тестване. Винаги се препоръчва да се извърши тестване на компоненти, преди да се започне тестването на интеграция.

Ако тестването на компоненти е твърдо, ще открием по-малко дефекти в теста за интеграция. Ще има проблеми, но тези проблеми ще бъдат свързани с интеграционната среда или предизвикателствата в конфигурацията. Можете да се уверите, че функционалността на интегрираните компоненти работи добре.

Надявам се, че този урок е полезен за разбиране на тестването на компоненти, интеграция и система. Ако все още имате въпроси, не се колебайте да ни попитате в коментари.

Препоръчително четене

^