Меню

Какво е тестване на интеграция (урок с пример за тестване на интеграция)

what is integration testing

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

Какво е тестване за интеграция: Научете с примери за тестване на интеграция

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

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

Списък с уроци, обхванати в тази поредица:

Урок # 1: Какво е тестване на интеграция? (Този урок)
Урок # 2: Какво е инкрементално тестване
Урок № 3: Какво е тестване на компоненти
Урок № 4: Непрекъсната интеграция
Урок №5 Разлика между модулното тестване и интеграцията
Урок # 6: Топ 10 Инструменти за тестване на интеграция

какво е интеграционно тестване

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

Какво е интеграционно тестване?

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

Основната функция или цел на това тестване е да тества интерфейсите между блоковете / модулите.

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

Основната функция или цел на това тестване е да тества интерфейсите между блоковете / модулите.

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

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

Защо тест за интеграция?

Смятаме, че тестването за интеграция е сложно и изисква известно развитие и логически умения. Вярно е! Тогава каква е целта на интегрирането на това тестване в нашата стратегия за тестване?

Ето няколко причини:

  1. В реалния свят, когато се разработват приложения, той се разделя на по-малки модули и на отделните разработчици се възлага 1 модул. Логиката, внедрена от един разработчик, е съвсем различна от друга разработка, така че става важно да се провери дали логиката, внедрена от разработчика, е в съответствие с очакванията и правилната стойност в съответствие с предписаните стандарти.
  2. Много пъти лицето или структурата на данните се променят, когато преминават от един модул в друг. Някои стойности се добавят или премахват, което причинява проблеми в по-късните модули.
  3. Модулите също взаимодействат с някои инструменти на трети страни или API, които също трябва да бъдат тествани, че данните, приети от този API / инструмент, са верни и че генерираният отговор също е според очакванията.
  4. Много често срещан проблем при тестване - Честа промяна на изискванията! :) Много пъти разработчикът използва промените, без да ги тества. По това време интеграционното тестване става важно.

Предимства

Има няколко предимства на това тестване и малко от тях са изброени по-долу.

  • Това тестване гарантира, че интегрираните модули / компоненти работят правилно.
  • Интеграционното тестване може да започне, след като модулите за тестване са налични. Не се изисква другият модул да бъде завършен, за да се направи тестване, тъй като Stubs и Drivers могат да се използват за същото.
  • Той открива грешките, свързани с интерфейса.

Предизвикателства

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

# 1) Интеграционното тестване означава тестване на две или повече интегрирани системи, за да се гарантира, че системата работи правилно. Трябва да се тестват не само връзките за интеграция, но трябва да се направи изчерпателно тестване, като се има предвид околната среда, за да се гарантира, че интегрираната система работи правилно.

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

# две) Управлението на тестовете за интеграция става сложно поради няколко фактора, участващи в него като база данни, платформа, среда и т.н.

# 3) Въпреки че интегрира всяка нова система със старата система, тя изисква много промени и усилия за тестване. Същото важи и при интегрирането на всякакви две стари системи.

# 4) Интегрирането на две различни системи, разработени от две различни компании, е голямо предизвикателство, тъй като не е сигурно как една от системите ще повлияе на другата система, ако се направят промени в някоя от системите.

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

Видове тестове за интеграция

По-долу е даден вид тестова интеграция заедно с нейните предимства и недостатъци.

Подход за Големия взрив:

Подходът от Големия взрив интегрира всички модули наведнъж, т.е.не се интегрира модулите един по един. Той проверява дали системата работи според очакванията или не е интегрирана веднъж. Ако в напълно интегрирания модул се открие някакъв проблем, става трудно да се разбере кой модул е ​​причинил проблема.

Подходът на Големия взрив е трудоемък процес за намиране на модул, който сам има дефект, тъй като това ще отнеме време и след като дефектът бъде открит, поправянето му би струвало скъпо, тъй като дефектът се открива на по-късния етап.

Подход с голям взрив

Предимства на подхода на Големия взрив:

  • Това е добър подход за малки системи.

Недостатъци на подхода на Големия взрив:

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

Стъпки за тестване на интеграцията:

  1. Подгответе интеграция План за тестване.
  2. Подгответе сценарии за интеграция и тестови случаи.
  3. Подгответе скриптове за автоматизация на теста.
  4. Изпълнете тестови случаи.
  5. Съобщете за дефектите.
  6. Проследявайте и тествайте повторно дефектите.
  7. Повторното тестване и тестване продължават, докато интеграционното тестване не приключи.

Тестови подходи за интеграция

Има фундаментално 2 подхода за извършване на тестова интеграция:

  1. Подход отдолу нагоре
  2. Подход отгоре надолу.

Нека разгледаме фигурата по-долу, за да тестваме подходите:

Интеграция 1

Подход отдолу нагоре:

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

В този случай модулите B1C1, B1C2 и B2C1, B2C2 са най-ниският модул, който е единично тестван. Модули B1 и B2 все още не са разработени. Функционалността на модули B1 и B2 е, че той извиква модулите B1C1, B1C2 и B2C1, B2C2. Тъй като B1 и B2 все още не са разработени, ще ни трябва програма или „стимулатор“, който ще извика модулите B1C1, B1C2 и B2C1, B2C2. Тези програми за стимулиране се наричат ШОФЬОРИ .

С прости думи, ШОФЬОРИ са фиктивни програми, които се използват за извикване на функциите на най-ниския модул в случай, че извикващата функция не съществува. Техниката отдолу нагоре изисква драйверът на модула да подава вход за тестов случай към интерфейса на тествания модул.

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

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

Подход отгоре надолу

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

частен сървър на world of warcraft ванилия

В контекста на нашата фигура тестването започва от модул A, а по-ниските модули B1 и B2 са интегрирани един по един. Сега тук по-ниските модули B1 и B2 всъщност не са достъпни за интеграция. Така че, за да тестваме най-горните модули А, ние разработваме „ STUBS ”.

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

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

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

Нека да заключим някаква разлика между Stubs и Driver :

СтъбсШофьор
Използва се в подхода отгоре надолуИзползва се в подход отдолу нагоре
Най-добрият модул се тества първоПърво се тестват най-ниските модули.
Стимулира по-ниското ниво на компонентитеСтимулира по-високото ниво на компонентите
Фиктивна програма на компоненти от по-ниско нивоФиктивна програма за компонент от по-високо ниво

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

Интеграцията започва със средния слой и се движи едновременно нагоре и надолу. В случай на нашата фигура, нашето тестване ще започне от B1 и B2, където едното рамо ще тества горния модул A, а другото рамо ще тества долните модули B1C1, B1C2 & B2C1, B2C2.

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

Тест за интеграция на GUI приложение

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

Всички разбираме, че уеб приложението е многостепенно приложение. Имаме преден край, който е видим за потребителя, имаме среден слой, който има бизнес логика, имаме още среден слой, който прави някои проверки, интегрира някои API на трети страни и т.н., след това имаме заден слой, който е база данни.

Пример за тестване на интеграция:

Нека проверим долния пример:

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

Софтуер GenNext разработих този продукт за мен и по-долу беше архитектурата:

Интеграция 2

ЛУК - Модул на потребителския интерфейс, който е видим за крайния потребител, където са дадени всички входове.
BL - Модулът Business Logic, който разполага с всички изчисления и специфични за бизнеса методи.
VAL - Това е модулът за проверка, който има всички проверки на коректността на въведеното.
CNT - Дали модулът за съдържание има цялото статично съдържание, специфично за въведените от потребителя входове. Това съдържание се показва в отчетите.
IN - Модулът Engine е, този модул чете всички данни, които идват от BL, VAL и CNT модул и извлича SQL заявката и я задейства в базата данни.
Планировчик - Това е модул, който планира всички отчети въз основа на избора на потребителя (месечно, тримесечно, полугодишно и годишно)
DB - Дали е базата данни.

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

Въпросите тук са:

  1. Как BL, VAL и CNT модулът ще четат и интерпретират изядените данни, въведени в UI модула?
  2. BL, VAL и CNT модулът получават ли правилните данни от потребителския интерфейс?
  3. В кой формат данните от BL, VAL и CNT се прехвърлят към EQ модула?
  4. Как EQ ще прочете данните и ще извлече заявката?
  5. Правилно ли е извлечена заявката?
  6. Получава ли планировщикът правилните данни за отчетите?
  7. Правилен ли е резултатът, получен от EN, от базата данни и както се очаква?
  8. Може ли EN да изпрати отговора обратно към модулите BL, VAL и CNT?
  9. Може ли потребителският интерфейс да чете данните и да ги показва по подходящ начин на интерфейса?

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

В нашия сценарий данните, въведени в потребителския интерфейс, се преобразуват в XML файл, който се интерпретира от 3-те модула BL, VAL и CNT. Модулът EN чете резултантния XML файл, генериран от 3-те модула, и извлича SQL от него и заявки в базата данни. Модулът EN също получава набора от резултати и го преобразува в XML файл и го връща обратно в модула на потребителския интерфейс, който преобразува резултатите в читава от потребителя форма и го показва.

В средата имаме модул за планиране, който получава набора от резултати от модула EN, създава и планира отчетите.

И така, къде се появява интеграционното тестване?

Е, тестването дали информацията / данните протичат правилно или не, ще бъде вашето тестване за интеграция, което в този случай би потвърдило XML файловете. Правилно ли се генерират XML файловете? Имат ли точните данни? Данните се прехвърлят ли правилно от един модул в друг? Всички тези неща ще бъдат тествани като част от теста за интеграция.

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

Няколко други условия за изпитване на пробата могат да бъдат както следва:

  • Опциите в менюто генерират ли правилния прозорец?
  • Могат ли прозорците да извикат тествания прозорец?
  • За всеки прозорец идентифицирайте извикванията на функциите за прозореца, които приложението трябва да разреши.
  • Идентифицирайте всички обаждания от прозореца към други функции, които приложението трябва да позволява
  • Идентифициране на обратими повиквания: затварянето на извикан прозорец трябва да се върне към прозореца за извикване.
  • Идентифицирайте необратими повиквания: извикващият прозорец се затваря, преди да се появи извиканият прозорец.
  • Тествайте различните начини за изпълнение на повиквания към друг прозорец, напр. - менюта, бутони, ключови думи.

Стъпки за започване на тестове за интеграция

  1. Разберете архитектурата на вашето приложение.
  2. Идентифицирайте модулите
  3. Разберете какво прави всеки модул
  4. Разберете как данните се прехвърлят от един модул в друг.
  5. Разберете как данните се въвеждат и получават в системата (входна и изходна точка на приложението)
  6. Разделете приложението според вашите нужди от тестване.
  7. Идентифицирайте и създайте условията на теста
  8. Вземете едно условие наведнъж и запишете тестовите случаи.

Критерии за влизане / излизане за тестване на интеграция

Критерии за влизане:

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

Критерии за изход:

  • Всички случаи на интеграционен тест са изпълнени.
  • Не се отварят критични и приоритетни дефекти P1 и P2.
  • Изготвен е протокол от изпитването.

Случаи на тестове за интеграция

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

И така, основната идея е да се тества дали интегрирането на два работещи модула работи, както се очаква, когато се интегрира.

За примерни случаи на тестове за интеграция за приложението Linkedin ще се включват:

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

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

Интеграцията е техника на бяла кутия или черна кутия?

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

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

Така че, не е конкретно, че тестването за интеграция е техника на черна кутия или бяла кутия.

Инструменти за тестване на интеграция

Налични са няколко инструмента за това тестване.

По-долу е даден списък с инструменти:

  • Тестер за рационална интеграция
  • Транспортир
  • Парна
  • ТЕСИ

За повече подробности относно горните инструменти проверете този урок:

Топ 10 Инструменти за тестване на интеграция за писане на тестове за интеграция

Тестване на системната интеграция

Тест за системна интеграция се прави, за да се тества цялостна интегрирана система .

Модулите или компонентите се тестват индивидуално при модулни тестове, преди да се интегрират компонентите.

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

Разлика между интеграционното тестване и системното тестване

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

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

Заключение

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

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

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

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

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

^