Тестване на софтуер

Софтуерното тестване е процес на изследване и проучване на софтуер с цел получаване на информация за качеството на продукта и услугата, която се изпитва. Процесите на софтуерното тестване са неразделна част от софтуерното инженерство и осигуряване на качеството на софтуера.
Съществуващите методи на тестване на софтуер не позволяват еднозначно и напълно да се видят, проявят и установят всички дефекти и правилното функциониране на една програма, така че методите на тестване работят в рамките на формалния процес на проверка върху изследвания или разработвания софтуер.
Тестването на софтуер е изследване, което се прави с цел да се даде информация на всички заинтересовани страни за качеството на продукта или услугата. То трябва да даде обективна и безпристрастна оценка на софтуера, която да позволи на бизнеса да прецени и разбере рисковете от употребата му. Техниките за тестване могат да включват изпълнение на програмата с цел откриването на грешки (бъгове). Тестването на софтуер може да се разглежда като процес на валидация и верификация, че дадена компютърна програма/приложение/продукт:
Тестването на софтуера, в зависимост от избрания метод на тестване, може да се проведе по всяко време в процеса на разработка. В традиционния случай повечето тестове се провеждат след като изискванията са формулирани и етапът на писане на код е приключил. За сравнение, при гъвкавия подход на разработка, тестването е продължителен процес, който обхваща целия период на разработката, а не една отделна фаза накрая. Методологията на тестване е в пряка зависимост от метода на разработка.
Процесът на тестване не може да открие всички грешки в даден софтуер, поради тяхното разнообразие. Вместо това, той прави сравнения, служещи за съпоставка на състоянието и поведението на продукта. Създават се „оракули“ – принципи или механизми за разпознаване на проблеми. Те може да са във формата на:
Основната цел на тестовете е да се открият софтуерни дефекти с цел тяхното отстраняване. Тестването не може да установи дали продуктът ще действа нормално при всички обстоятелства, а по-скоро при какви обстоятелства спира да действа нормално. Обхватът на тестовете може да включва проверка на самия код, неговата работа в различни среди и при различни условия, както и допълнителни аспекти: прави ли това, което се очаква и изисква от него. В съвременната индустрия често компанията, която извършва тестовете, е различна от компанията разработчик. Провеждащият тестовете има различни роли и резултатите от тестовете могат да окажат влияние върху модела и процеса на разработка.
Всеки софтуер има целева група клиенти. Например потребителите на игри се различават в изискванията и очакванията си от потребителите на банков софтуер. Следователно всяка организация, която разработва софтуер, се стреми да прецени дали продуктът им ще се приеме от крайните потребители, купувачите, инвеститорите и други заинтересовани страни. Тестването на софтуера се стреми да помогне с тази оценка.
Не всички дефекти са породени от грешки в кода. Един чест източник на скъпоструващи дефекти е „разминаване в изискванията“, което води до пропуски в работата на разработчиците. То може да се прояви на не-оперативно ниво (не засяга сериозно работата на продукта) – например:
Софтуерните дефекти често се появяват в следната последователност. Разработчик допуска грешка (error), която довежда до дефект (defect, fault, bug) в изходния код (source code). Ако този дефект се изпълни, програмата в дадена ситуация ще даде грешен резултат, което може да предизвика срив (failure). Не всички дефекти задължително предизвикват срив. Например дефектите в неизползван/мъртъв код (dead code) няма да имат никакъв ефект. Един дефект може да се превърне в срив при промяна на обстоятелствата. Примери за подобна промяна са нова машина (хардуерен проблем), промяна във входните данни (софтуерен проблем) или съвместната работа на дадената програма с друг софтуер (комуникационен проблем). Един дефект може да доведе до различни по причина сривове.
Фундаменталният проблем на тестването на софтуер е невъзможността да се тестват всички възможни входни данни, комбинации от условия и изисквания. Това означава, че разнообразието от дефекти в един софтуер е безкрайно голямо и колкото по-рядко се проявяват те, толкова по-трудно е да се открият чрез тестове. Още повече, че не-операционните аспекти на софтуера (как трябва да бъде, а не какво трябва да прави) са често доста субективни.
Пример: Според разработчика даденият софтуер се очаква да обслужва не повече от десет хиляди потребители, докато инвеститорът иска продукт с капацитет поне сто хиляди потребители.
Софтуерните разработчици не могат да тестват абсолютно всичко, но те могат да използват комбинирани тестове, за да си осигурят покритието, което им трябва. Комбинираните тестове позволяват да се постигне по-голямо покритие с по-малко тестове. В зависимост от това дали се търси скорост, или дълбочина на тестово проникване може да се използват комбинирани тестове за изграждане на структурирани вариации от тестове.
Според проучване на Националния институт за стандарти и технологии в САЩ от 2002 година, „софтуерните грешки костват на САЩ близо 59.5 милиарда долара годишно“. Над една трета от тези загуби могат да се избегнат, ако се прилага по-добро тестване на софтуера.
Общоприето е, че колкото по-рано се открие даден дефект, толкова по-евтино е да се отстрани. Съществуват различни изследвания за това колко ще струва отстраняването на даден дефект в зависимост от етапа на разработка, на който е възникнал, спрямо момента, в който е открит. Пример: Дефект, възникнал при определяне на изискванията, ще струва 10 – 100 пъти повече да се отстрани на етап продукт в продажба, отколкото ако е бил открит още при възникването си.
Политики за поетапно пускане в продажба и облачните технологии биха намалили подобни загуби, защото не се изисква изтегляне на продукт от продажба и бракуване на физически носители.
Разликата на precondition от предварително условие е, в това, че предварителното условие се базира на вече реализирани прекондиции или това са контекстите при AI прогностиката.
През 20 век тестването на софтуера се извършва предимно от самите програмисти, като по-късно се появява идеята за „софтуерен тестър“ или област за софтуерно тестване, като професионална област, като този термин се използва общо за всеки специалист извършващ дейността. В различни периоди и в зависимост от различните цели на тези специалисти са се обособили различни роли: мениджър, водещ на тест екип, анализатор на тестове, разработчик на тестове, тестър (извършващ тестовете), разработчик на автоматични тестове и системен администратор на тестовите машини. С това тестването на софтуер постепенно се е обособява и като отделна професия, която дори има своите подварианти, различни отдели и т.н.
Отделянето на дебъгването (debugging – намиране и отстраняване на дефекти, бъгове) от тестването на софтуер е първоначално представено от Гленфорд Дж. Майерс през 1979 г. Въпреки че неговото внимание е насочено към тестове, целящи срив („успешен тест е този, който намери бъг“), става ясно, че по това време сред програмистите нараства желанието да се отделят фундаментални дейности по разработката (като „дебъгването“) от чистата верификация (виж т.11.1).
През 1988 Дейв Гелперин и Уйлям Хетцел класифицират фазите и целите на тестването на софтуер през годините:
Има много начини за тестване на софтуер. Статичните методи са:
За динамични се считат методи, които изискват кодът да се изпълни, програмата да се натовари с предварително подготвени тестови данни или сценарии. В практиката статичните методи често се прескачат за сметка на динамичните.
Методи, които разчитат само на преглед на кода, са статични, а тези, които изискват да се види и неговата работа, са динамични.
Динамичните тестове могат да започнат преди програмата да е на 100% завършена, като тогава говорим за тестове на отделните градивни единици – например функции и методи. Някои типични техники за това са употребата на драйвери (drivers) или работа в режим на дебъгване.
Статичните методи са свързани с верификация (verification), а динамичните с валидация (validation). Виж т.11.1.
Методите за тестване на софтуер традиционно се разделят на две групи – метод на отворената кутия (на английски: white-box) и метод на затворената кутия (на английски: black-box). Основната разлика идва от фокуса на разработчика – дали се интересува повече как работи софтуерът, или дали работи според изискванията. Оттук и аналогията:
Методът на отворената кутия (известен още като clear box testing, glass box testing, transparent box testing, и structural testing) е метод за тестване на софтуер, който тества вътрешните структури или начина на действие на приложението, но не и неговата функционалност (за разлика от затворената кутия). Той се основава на вътрешния изглед на системата, както и на уменията за програмиране на този, който тества. Специалистът, който тества, избира входни данни, за да проследи обработката им от системата и определя съответните резултати. Това е аналогично на тестването „възли в схема“ (in-circuit testing, ICT).
Методът на отворената кутия може да се прилага на ниво модул (unit), на интеграционно и системно ниво, но обикновено се прави на ниво модул. Един от начините е тестване на пътя (на английски: path testing). Може да се тества път в рамките на модула, път между отделни модули по време на интеграция, както и между подсистемите по време на тестване на системно ниво. Въпреки че този метод може да разкрие много грешки или проблеми, той не може да открие неизпълнени части на спецификацията или липсващи изисквания.
Методът на отворената кутия включва:
Методът на отворената кутия работи на ниво изходен код за предотвратяване на всякакви скрити грешки по-късно. Тестовете използват техниките за тестване, посочени по-горе, както и промяната на обсега условие/решение. Методът използва тези техники като насоки за създаване на среда без грешки чрез проучване на всякакъв чуплив код. Те изпълняват всеки видим път на изходния код, като целият смисъл на тестването е да се узнае коя линия на кода се изпълнява и да се определи какъв трябва да бъде правилният изход.
Основната процедура на White-box тестването включва разбирането на изходния код, което изисква способности на високо ниво, за да може да се тества правилно и пълно. Програмистът трябва да има широки познания за приложението, да знае какви тестовете да създаде, така че всеки видим път да бъде тестван. Когато изходният код е разбран, може да се анализира за тестване. Това са трите основни стъпки, които се правят при white-box тестването, с цел създаване на тестовете:
White-box тестването е един от двата най-мащабни метода за тестване, използвани днес. Той има три предимства:
Въпреки че white-box тестването има много предимства, то не е съвършено и има някои недостатъци:
При тестовете за проникване white-box тестването обяснява методологията, където „white hat hacker“ има пълни познания по системата, която е атакувана. Целта на white-box теста за проникване е да симулира злонамерен хакер, който има познания и евентуално основните пълномощия за целевата система.
Тестването тип затворена/черна кутия разглежда софтуера като „черна кутия“, изучавайки функционалността без каквито и да са познания за вътрешното устройство. Човекът, който извършва теста, е само наясно какво би трябвало дадения софтуер да върши, но не и как го прави. Тестването тип черна кутия включва: еквивалентно разпределение (equivalence partitioning), анализ на граничните стойности (boundary value analysis), таблици за промяна на състоянието (state transition tables), тестване на таблиците за взимане на решение (decision table testing), стрес тестване (fuzz testing), тестване базирано на модел (model-based testing), тестване за определени ценарии (use case testing), изследователско тестване (exploratory testing) и тестване основаващо се на спецификацията (specification-based testing).
Тестването основаващо се на спецификация цели да тества функционалността на софтуера като се придържа към зададени изисквания. Това ниво на тестване обикновено изисква да се зададат конкретни и обстойни тестови случаи на тестера, който от своя страна може да потвърди за зададен вход. Изходната информация (или поведение) е или не е както се очаква от зададените тестови случаи. Въпросните тестови случаи се сформират на база спецификациите и изискванията, т.е. въз основа на това за какво е предназначена дадено приложение. То използва описване на външността на софтуера, включително спецификации, които комбинира, за да изгради конкретни тестови случаи. Тези тестове могат да са функционални или нефункционални, въпреки че обикновено са функционални.
Тестването основаващо се на спецификация може да бъде необходимо за гарантирането на правилната функционалност, но не е достатъчно, за да предпази от сложни или високо-рискови ситуации.
Едно от преимуществата на техниката на черната кутия, че познания по програмиране на са необходими. Каквито и пристрастия да са имали програмистите, най-вероятно тестера може да има различни и може да наблегне на различни аспекти от функционалността. От друга страна, тестването тип черна кутия се счита за „разходка в тъмен лабиринт без фенерче“, защото тестерите не изследват сорс кода. Има случаи, когато тестерите правят много тестове да проверят нещо, което може да се провери само с един тест или да оставят някои части от програмата нетествани.
Този метод на тестване може да бъде приложен на всички нива от софтуерното тестване: компонентно (unit), интеграционно (integration), системно (system) и крайно/приемно (acceptance). Той обикновено обхваща по-голямата част, ако не и цялата от тестването на високите нива, но също така доминира и при звеновото тестване.
Целта на визуалното тестване е да осигури на разработчиците възможността да изследват какво се случва в момент на софтуерен проблем, като предоставят информация по такъв начин, че разработчиците да могат лесно да намерят информацията, която им е необходима.
В същността на визуалното тестване е идеята, че показвайки на някого проблема (или пълното спиране), вместо простото му описване, е много по информативно и ясно за разбиране. Затова и визуалното тестване изисква записване на целия тестови процес, като записва всичко, което се появява на тестовата система във видео формат. Изходните видеота са допълнени с видео на самия тестер в реално време, както и допълнителен аудио коментар от негова страна.
Визуалното тестване има редица преимущества. Качеството на комуникация е невероятно подобрена, защото тестерите могат да покажат проблема (както и събитията, които водят до него) на разработчиците, сравнено само с простото описване на проблема, както и нуждата да се пресъздадат всички проблеми в програмата, които могат да спрат да се проявяват в много от случаите. Разработчиците ще имат всички данни, които са им необходими за дадения проблем и могат да се фокусират изцяло върху причинителите на грешката и как би могло тя да бъде отстранена.
Визуалното тестване и особено подходящо за среди, които използват методи на постоянна връзка (agile methods) в тяхната разработка на софтуер, тъй като методите с постоянна връзка изискват силна комуникация между тестерите и разработчиците, както и сътрудничество между членовете на малките екипи.
Специфичното тестване (ad hoc testing) и изследователското тестване са важни методологии за проверка на целостта на софтуера, защото изискват по-малко време за подготовка и изпълнение и въпреки това важните бъгове могат да бъдат открити бързо. При специфичното тестване, където тестването се извършва по импровизиран начин, визуалното записване на самия тест е изключително важно.
Визуалното тестване намира широко приложение при възприемането на клиентите и тестването на ползваемостта, защото теста може да бъде използван от много различни хора занимаващи се в процеса на разработка. За клиента е лесно да предостави обратна връзка, както и детайлен доклад за бъговете. За потребителите на програмата, визуалното тестване може да запише всички действия от екрана на потребителя, както и техния глас и видео, за да предостави пълна картина за момента на настъпване на дадения проблем.
Тестване тип частично отворена/сива кутия изисква да се има знание за вътрешното устройство на структурите от данни и за алгоритмите с цел на съставянето на тестовете, докато самите тестове се изпълняват на ниво потребители или черна кутия. Не е необходимо тестерите да имат пълен достъп до сорс кода на софтуера. Изменянето на входната информация и форматирането на изходната, не се води за сива кутия, защото входа и изхода са видимо извън „черната кутия“, която представлява системата, която се тества. Това разграничаване е особено важно когато провеждаме интегриращи тестове между два модула код, написани от различни разработчици, където само интерфейсите са предоставени за тестове.
Все пак тестове, които изискват изменяне на информация от съвкупностите с данни, като например бази данни или лог файлове, се класифицират като сива кутия, тъй като при нормални операции потребителите не могат да променят информация от въпросните съвкупности на данни. Тестването тип сива кутия може също така да имплементира в себе си проектирането с обратна връзка (reverse engineering) с цел да определи например гранични стойности или съобщения за грешка.
Като се знае основната концепция за това как работи софтуерът, тестерите правят по-добре информирани тестови избори, докато тестват софтуера отвън. Обикновено на тестерите ползващи сива кутия им е позволено да задават изолирани тестови среди, които предоставят достъп до базите данни. Тестерът може да наблюдава състоянието на даден продукт по време на тестването и извършване на конкретни действия, като изпълняване на SQL заявки към базата данни, последвани от изпълняване на заявки, които потвърждават, че очакваните промени са се изпълнили. Тестването тип сива кутия осъществява интелигентни тестови сценарии, основаващи се на ограничена информация. Това особено се отнася за работата с типовете данни, обработка на изключения и така нататък.
Тестовете често се групират на база това на кой етап от разработката на софтуера се провеждат или върху какво се фокусират. Според SWEBOK (Software Engineering Body of Knowledge), разговорното название на ISO/IEC TR 19759:2005 (международен стандарт за разработка на софтуер), има три нива на тестове:
Тези нива не са обвързани с конкретен модел за разработка и са по-общи. Други групи тестове се идентифицират според обекта на тестване.
Тестовете на ниво отделна градивна единица или както са известни „тестове на компонентите“, са тестове, които проверяват правилното функциониране на отделен сегмент от кода, обичайно на ниво функция. В обектно-ориентираното програмиране (ООП) това са най-често класовете, техните конструктори и деконструктори.
Този вид тестове обикновено се пишат от самите разработчици в процеса на разработка (white-box style), за да проверят дали определена функция работи според изискванията. Една функция може да се тества многократно с различни тестове, за да се обхванат граничните случаи и разклоняването на кода. Тестването на това ниво не е достатъчно, за да гарантира работата на даден софтуер като цяло, а по скоро за да гарантира, че градивните блокове функционират нормално сами за себе си.
Тестовете на отделните градивни единици включва прилагането на широка гама превантивни и диагностични мерки, за да се намали рискът, времето и стойността на разработка. Извършва се от самите разработчици или специализирани софтуерни инженери в периода на изграждане на продукта (етап от разработката). Вместо да променя традиционния фокус при качествения контрол, този модел само го усилва. Целта е да се отстранят грешките по кода преди той въобще да бъде предаден за качествен контрол. Стремежът е както да се подобри качеството на крайния продукт, така и да се повиши ефективността на процесите по разработка и контрол на качество.
В зависимост от очакванията на организацията разработчик, тестовете на ниво градивни единици могат да включват статични методи като анализ на кода, анализ на преноса на данни, анализ на различни статистики (метрики), преглед от други разработчици и други практики за проверка на код.
Тестовете на ниво интеграция имат за цел да проверя взаимовръзките и съвместната работа на отделните компоненти, когато са поставени в една среда. Компонентите може да се интегрират на вълни или накуп (известно още като Големият Взрив – „big bang“). Счита се, че варианта на вълни е по-добър, защото позволява новопоявили се дефекти да се открият и отстранят по-бързо преди да се интегрира следващата вълна и дефектите са се мултиплицират.
Тестовете на ниво интеграция изваждат на преден план проблеми при свързването и съвместната работа на интегрираните компоненти (units, модули). Прогресивно нарастващи групи елементи се тестват спрямо архитектурния план на програмата и се сливат, докато целия софтуер не заработи като единна система.
Тестовете на системно ниво проверяват дали системата като цяло отговаря на изискванията. В допълнение, тези тестове трябва да гарантират, че програмата, освен че работи според очакванията, не разрушава или поврежда средата, в която работи, и не причинява други процеси в същата среда да спрат да функционират нормално (това включва проверка за употребата на споделената памет, употребата на прекомерно много ресурси, изземане достъпи, блокиране или нарушаване работата на други процеси).
След пускане на продукта в продажба или въвеждането му в клиентска фирма, следва да се проведат приемни тестове, за да се гарантира не само правилната работа на софтуера, но и съответствието му с началните изисквания, клаузите на договора, помощната документация и очакванията на клиента.
Целта на тестовете за приемане на системата е получаване на одобрението на клиента за системата и е първа стъпка към реалната експлоатация на софтуера. Тестовете се изпълняват от гледна точка на клиента и с неговото участие – включват се не само потребителите на системата, но и екипът, който ще я обслужва. Предназначението им е да се установи дали системата отговаря на изискванията и дали е готова да бъде внедрена. Технически погледнато тестовете за приемане на системата са подобни на системните тестове, но при първите клиентът взима участие в провеждането на тестовете и тестовете се провеждат в реалните за приложението условия. Изходът от тези тестове дава възможност на клиента да реши дали да приеме или не системата. Това решение се взема въз основа на предварително дефинирани критерии за приемане и ясни правила и метрики, които дефинират условията за покритието им. Най-често стъпките за приемане се описват в Процедура за приемане на системата. Основната цел на тестовете за приемане е да се определи дали системата изпълнява изискванията към нея.
Някои софтуерни системи имат сложни инсталационни процедури. Тестването на тези процедури е изключително важна част от тестовия процес. Грешка по време на инсталирането на системата може да попречи на потребителя да я използва. Много е важно как точно протича процесът на инсталиране, тъй като един сложен процес на инсталация може да откаже потребителя от по-нататъшна работа със системата. Съществен момент, който често се пропуска, е изследване на процедурата за деинсталация на софтуера и качеството, с което се възстановяват системните ресурси след прилагането. Инсталационните тестове гарантират, че софтуерът е инсталиран коректно и работи нормално с хардуера на потребителя.
Честа причина за сривове и грешки (реални или предполагаеми) е липсата на съвместимост на софтуера с други приложения, операционната система (или нейната версия), средата и вида устройство, на което се ползва (например едно десктоп приложение, което се инсталира на инфо терминал в гара или се отваря през уеб браузър). Пример за проблемна съвместимост е практиката на разработчиците да създават и тестват софтуер само за последните версии на даден продукт (някой потребители може все още да нямат достъп до него), без да проверят дали техния софтуер може да работи с файлове генерирани от предни версии / модели (MS Word 95 не може да отваря файлове с разширение .docx без допълнителен пач). Това довежда до неочаквания ефект най-новите програми да не работят с по-стари операционни системи или хардуер, което спира разпространението им. За да се избегне подобен проблем често се налага писането на пачове, допълнителни модули или библиотеки, което отнема време и средства.
Регресионното тестване означава да се тества отново вече тествана част от системата след промяна по някоя нейна функционалност. Целта е да се установи дали след отстраняване на даден дефект, не е възникнал нов дефект в работещ клон на софтуера. Тестовете трябва да проверят дали:
Регресионното тестване се извършва например след отстраняване на дефекти, при внедряване на системата в нова среда, при замяна на някой компонент или при добавяне на нови функционалности към системата. Важна предпоставка за този тип тестове е анализът на влиянието на промените – т.е. да се определи кои точно области на системата ще бъдат засегнати от промените (affected areas).
Този тип тестове се използват за проверка и оценка на времето за отговор и реакция на систематата и използването на паметта при обичайното натоварване, както и при извънредни ситуации (свръхнатоварване). Фокусът е върху извънредните ситуации – като например обработването на големи количества данни, наличие на голям брой потребители, които работят едновременно в системата и времето за реакция на системата в този случай. За осъществяването на тези тестове могат да се използват сценариите от функционалните тестове. Тестовете за производителност се разделят на два подтипа – за натоварване (load) и стрес тестове (stress).
При тестовете за натоварване (load testing) се тества производителността на системата при различни натоварвания както и възможността ѝ да продължи да работи нормално при тези условия.
Стрес тестовете (Stress testing) се използват за намиране на грешки, дължащи се на ограничени ресурси или конкуренция за тях. Недостатъчно памет или дисково пространство могат да помогнат за откриване на дефекти в софтуерния продукт, които при нормални обстоятелства не се забелязват. Стрес тестовете също могат да се използват и за установяване на максималното натоварване, с което може да се справи обекта на тестването при конкретната конфигурация.
Този тип тестове се използват за проверка на възможността на системата да възстанови нормалната си работа след редица хардуерни, софтуерни, мрежови и други проблеми без да има загуба на данни. Тестването протича като системата се подлага на извънредни ситуации (хардуерна повреда, входно-изходни грешки, грешки в данните), за да се предизвика повреда. След това се проверява реакцията на системата и времето, за което тя се възстановява след аварията. Проверява се адекватността на процедурата за възстановяване, ако има такава. За целта могат да се използват функционалните тестове, като по време на серия от трансакции се симулира появата на повреда – в захранване, в комуникациите, в целостта на данните.
Този тип тестове са много субективни и зависят от профила на крайния потребител на системата. Няколко съображения трябва да се имат предвид, когато се изпълняват тестовете:
Чрез тестовете за сигурност се правят опити да се нарушават проверките за сигурност на системата. Например могат да се създадат тестови сценарии, които нарушават механизмите за сигурност на система за управление на бази данни. Познати са следните нива на сигурност: системно, мрежово и приложно. Предмет на разглеждане тук са тестовете на приложно ниво. Един от начините за създаване на такива тестове е да се проучат проблемите със сигурността, възникнали при подобни системи. След това да се създадат тестови сценарии, които симулират тези проблеми върху тестваната система. Този тип тестове са особено важни за интернет приложенията. На следващата фигура е показан обхвата на тестовете за сигурност.
Ръководството за потребителя на системата трябва да бъде достатъчно пълно, точно и ясно написано. По тази причина за всички примери, описани в документацията, трябва да се създадат тестови сценарии, с които да се тества системата.
Най-важните изисквания към документацията на системата са тя да бъде актуална, пълна и стилът ѝ да бъде съобразен със спецификацията и компютърната култура на нейните потребители.
Често в уеб приложения се ползва този модел (известен още като случаен контролиран експеримент). На потребителя се предлагат два сайта с напълно идентично съдържание и функционалност, като се внася промяна в един-единствен компонент – създават се версия А и версия Б на сайта. На случаен принцип при зареждане на сайта се избира коя версия да се зареди и се отчитат промени в статистиките на сайта в зависимост от това коя версия се ползва. Най-често с тези тестове се следи как потребителите реагират на дадена промяна.
Пример: Онлайн магазин създава две версии на страницата си за промоции. Следи се коя версия генерира повече продажби, по-дълъг престой на потребителя, повече кликове. Така се отчита кой модел на промоции е по-ефективен от икономическа гледна точка. Значението на този вид тестове е доста голямо, защото за минимални промени в продукта/сайта, може да се генерират големи допълнителни печалби.
След като тестването на отделните компоненти на софтуера е завършило, отделните единици се интегрират във функционални групи и се тестват отново. Целта на този тип тестване е да се открият скрити дефекти и несъответствия в интерфейсите между отделните модули, използването на паметта, обмена на информация с базите данни. Могат да се открият и грешки в изчисленията (отклонения в изчисленията, които са били допустими за отделните модули, но които могат да се натрупат до неприемливо ниво в хода на експлоатация на системата). Конкуренцията за едни и същи ресурси в даден момент, както и проблеми с времената (за изпращане и получаване на съобщения, за реакция на системата) не могат да се открият по време на тестването на компонентите, но могат да се идентифицират в този сравнително ранен етап от разработката на софтуера. Интеграционното тестване включва голям набор от дейности – като се започне от тестването на няколко модула и се стигне до тестване на цялата система. Интегрирането на модулите инкрементално (стъпка по стъпка) е систематичен начин за интеграция, чрез който продуктът се „сглобява“ и тества на малки парчета, за да може грешките да се откриват, изолират и редактират по-лесно. Инкременталната интеграция може да се извършва отгоре-надолу (top-down) или отдолу-нагоре (bottomup).
При метода отгоре-надолу интеграцията се осъществява като се започне с модула, който е най-високо в йерархията.
Интеграцията по метода „отгоре-надолу“, протича по следния начин:
При използването на този метод възникват няколко проблема:
Другият подход – „отдолу-нагоре“ – се осъществява по следния начин:
Този подход също има недостатъци. Например цялостната програма не съществува, докато не се интегрира и последният модул. Проблемите с времената и конкуренцията за ресурси се откриват доста късно в процеса на интеграция. В много организации разработчиците на софтуер са отговорни и за изпълняването на интеграционните тестове. Те използват т.нар. Big Bang подход. Всички модули се интегрират наведнъж и след това се изпълняват тестовете. Обикновено възникват доста проблеми и тъй като всички части от софтуера са интегрирани, много трудно се установяват проблемните модули.
При „Big bang“ подхода, отделните модули не се интегрират докато не приключи самото им разработване. Интеграцията по метода „Big bang“ е подходяща когато се иска да се спести време. Не се налага допълнителна работа по имплементирането на стъбове и драйвъри. Въпреки това, ако тестовите случаи (test cases) и техните резултати не се отчитат правилно, целият процес на интеграция може да се усложни или дори да не завърши. Много често се налага отделните модули да се разделят наново, за да се установи възникнала грешка. Недостатъците на този подход са доста: