what is incremental testing
С помощта на тази статия ще разгледам един от важните подходи за интеграция - Инкрементално тестване.
До края на този раздел публиката ще има добри познания за следното:
- Какво е допълнително тестване?
- Неговата цел
- Методологии
- Предимства
- Недостатъци
Какво ще научите:
- Какво е инкрементално тестване
Какво е инкрементално тестване
Инкременталното тестване, известно още като Инкрементално тестване на интеграция, е един от подходите на Интеграционното тестване и включва неговите основни концепции.
Това е като тест, който съчетава модул и интеграция стратегия за тестване .
При това тестване тестваме всеки модул поотделно във фаза на модулно тестване и след това модулите се интегрират постепенно и се тестват, за да се осигури гладък интерфейс и взаимодействие между модулите.
При този подход всеки модул се комбинира постепенно, т.е. един по един, докато всички модули или компоненти се добавят логически, за да се направи необходимото приложение, вместо да се интегрира цялата система наведнъж и след това да се извърши тестване на крайния продукт. Интегрираните модули се тестват като група, за да се осигури успешна интеграция и поток на данни между модулите.
Както при интеграционното тестване, основният фокус на това тестване е да се проверят интерфейсът, интегрираните връзки и потокът от информация между модулите. Този процес се повтаря, докато модулите се комбинират и тестват успешно.
Пример
Нека разберем тази концепция с пример:
Системното или софтуерното приложение се състои от следните модули:
Подход за инкрементално тестване на интеграция
- Всеки модул, т.е. M1, M2, M3 и др., Се тества индивидуално като част от модулното тестване
- Модулите се комбинират постепенно, т.е. един по един и се тестват за успешно взаимодействие
- На Фиг2 Модул М1 и Модул М2 са комбинирани и тествани
- На фиг.3 е добавен и тестван модул M3
- На Фиг4 е добавен Модул М4 и е извършено тестване, за да се гарантира, че всичко работи успешно заедно
- Останалите модули също се добавят постепенно на всяка стъпка и се тестват за успешна интеграция
Фиг
Фиг
как да отворите apk файл в windows
Фиг
Цел на допълнителния тест
- За да се гарантира, че различните модули работят успешно заедно след интеграцията
- Идентифицирайте дефектите по-рано и във всяка фаза. Това дава възможност на разработчиците да идентифицират къде е проблемът. Както ако тестването след интегриране на M1 и M2 е успешно, но когато се добави M3, тестът се проваля; това ще помогне на разработчика при разделянето на проблема
- Проблемите могат да бъдат решени в ранната фаза без много преработка и с по-малко разходи
Методологии за допълнително тестване на интеграцията
Преди да започнем с тази тема, бих искал да дам кратко въведение Щипки и шофьори тъй като ще използваме тези термини често.
Stubs и драйверите са псевдо код или фиктивен код, използвани в Интеграция или тестване на компоненти когато един или повече модули не са разработени, но се изисква да се тества някой друг модул.
Стъбс се използват в подхода за тестване отгоре надолу и са известни като „наречени програми“. Стъпките помагат да се симулира интерфейсът между модулите на долния лост, които не са налични или разработени.
Шофьори се използват в подхода за тестване отдолу нагоре и са известни като „програми за извикване“. Драйверите помагат да се симулира интерфейсът между модули от най-високо ниво, които не са разработени или са налични.
Въпрос, който може да възникне при някои от нас, е защо да не изчакаме, докато всички модули на приложенията бъдат разработени, вместо да използваме заглушител / драйвер, преди да започнем тестването?
Простият отговор е, че увеличава времето за изпълнение на проекта, тъй като тестерите ще седят без работа, докато не бъдат разработени всички модули. Освен това това затруднява кореновия анализ на дефекта. Този тип подход на тестване е известен като Big-Bang Integration testing.
Сега, когато покрихме Stubs и драйвери, нека преминем към различни методологии на допълнителното тестване:
# 1) отгоре надолу
Както подсказва името, тестването се извършва отгоре надолу, т.е. от централния модул до подмодула. Модулите, оформящи горния слой на приложението, се тестват първо.
Този подход следва структурния поток на тестваното приложение. Недостъпните или неразработени модули или компоненти се заменят със заглушки.
Нека разберем това с пример:
- Модул : Вход за уебсайт, известен още като L
- Модул : Поръчка aka O
- Резюме на поръчката на модул, известна още като OS (Все още не е разработена)
- Модул : Плащане aka P
- Модул Плащане в брой, известен още като CP
- Модул Дебитно / кредитно плащане, известен още като DP (Все още не е разработен)
- Модул Wallet Payment aka WP (все още не е разработен)
- Модул: Отчитане aka R (все още не е разработено)
как да направя makefile c ++
Отгоре надолу Подходен подход за тестване на интегрална интеграция
Ще бъдат изведени следните тестови случаи:
Тест 1: Модул L и модул O ще бъдат интегрирани и тествани
Тест 2: Модули L, O и P ще бъдат интегрирани и тествани
Тест3: Модули L, O, P и R ще бъдат интегрирани и тествани.
И така нататък се получават други тестови случаи.
Този тип тестване, при който всички модули в даден слой са първоначално интегрирани и тествани, е известен като „ширина първо“. Друга категория е „първо дълбочина“.
Следните тестови случаи ще бъдат изведени за „първо дълбочина“:
Тест 1: Модул L и модул O ще бъдат интегрирани и тествани
Тест 2: Модули L, O и OS ще бъдат интегрирани и тествани
Тест3: Модул L, O, OS, P ще бъде интегриран и тестван
Тестов случай4: Модул L, O, OS, P, CP ще бъде интегриран и тестван
И така нататък се получават други тестови случаи.
Предимства на методологията отгоре надолу
- Ранно излагане на архитектурни дефекти
- Той очертава работата на приложението като цяло в ранните етапи и помага за ранното разкриване на дизайнерските дефекти
- Основните контролни точки се тестват рано
Отличия на методологията отгоре надолу
- Значителни модули се тестват в края на цикъла
- Много е трудно да се напишат условия за изпитване
- Стъблото не е идеалното изпълнение на свързания модул. Той просто симулира потока от данни между два модула
# 2) Отдолу нагоре
При този подход тестването се извършва отдолу нагоре, т.е. модулите от долния слой се интегрират и тестват първо, а след това последователно се интегрират други модули, докато се придвижваме нагоре. Недостъпните или неразработени модули се заменят с драйвери.
Нека разгледаме по-долу споменатия пример за по-добро разбиране:
Модулите Ранг, Марки, Процент и Спортен клас все още не са разработени, така че те ще бъдат заменени със съответния драйвер:
Отдолу нагоре подход за тестване на допълнителна интеграция
Ще бъдат изведени следните тестови случаи:
Тест 1: Единично тестване на модул Практика и теория
Тест 2: Интегриране и тестване на модули Марки - Практическа теория
Тестово дело3 : Интегриране и тестване на модули Процент-марки-Практическа-теория
Тестов случай4: Единично тестване на модулен спортен клас
Тестов случай5: Интегриране и тестване на модули Ранг-Спортен клас-Процент-Марки-Практическа-Теория
Предимства на методологията отдолу нагоре
- Тази методология е много полезна за приложения, където се използва дизайнерски модел отдолу нагоре
- По-лесно е да създадете условия за тестване при подход отдолу нагоре
- Да започнете тестване на най-долното ниво в йерархията означава тестване на критични модули или функционалност на ранен етап. Това помага за ранното откриване на грешки
- Интерфектните дефекти се откриват на ранен етап
Отличия на методологията отдолу нагоре
- Драйверите са по-трудни за писане, отколкото мъниче
- Дефектите в дизайна се улавят на по-късния етап
- При този подход нямаме работещо приложение, докато не бъде изграден последният модул
- Драйверът не е цялостно изпълнение на свързания модул. Той просто симулира потока от данни между два модула.
# 3) Тестване на сандвич
Този подход е хибрид на методологията отгоре надолу и отдолу нагоре. Stub и драйверите се използват за непълни или неразработени модули.
Подход за тестване
- Идентифициран е среден слой, от който се правят тестове отдолу нагоре и отгоре надолу. Този среден слой е известен още като целеви слой
- Целевият слой се идентифицира според евристичния подход, т.е.изберете слой, който позволява минимално използване на Stubs и драйвери
- Тестването отгоре надолу започва от средния слой и се движи надолу към модули от по-ниско ниво. Този слой под средния слой е известен като Долен слой
- Тестването отдолу нагоре също започва от средния слой и се придвижва нагоре към модулите на горния слой. Този слой над средния слой е известен като горен слой
- С използването на заглушители и драйвери, потребителският интерфейс и функциите на модулите от по-ниско ниво се тестват съответно
- В крайна сметка остава само средният слой за изпълнение на финалния тест
Пример:
Следните тестови случаи могат да бъдат извлечени със стратегията за тестване на сандвич:
Тест 1: Тествайте A, X, Y и Z поотделно - където тест A се подлага на тест за най-горния слой, а тест X, Y и Z - под тестове на долния слой
Тест 2: Тест A, G, H и I
Тест3: Тест G, X и Y
Тестов случай4: Тестова ръка Z
Тестов случай5: Тест A, G, H, I, X, Y и Z
Предимства на методологията за тестване на сандвичи
- Това е много полезно за голям проект, който има различни подпроекти
- Методологията за тестване отгоре надолу и отдолу нагоре може да работи едно до друго
Отличителни черти на методологията за тестване на сандвич
- Преди обединяването на модулите подсистемите и техните интерфейси не се тестват задълбочено
- По-високи разходи поради участието на методология за тестване отгоре надолу и отдолу нагоре
- Този тип тестване не се препоръчва за система, в която модулите са силно взаимозависими
Заключение
Допълнителното тестване е част от теста за интеграционно тестване. При този подход на тестване, интеграционното тестване се извършва на отделния модул като част от модулното тестване, а в следващата фаза модулите или компонентите на приложението се интегрират постепенно и тестването се извършва на комбинирани модули като група.
От трите методологии на Incremental Integration Testing, изборът на коя методология да избере зависи от структурата на приложението, а също и от позицията на високорисковите модули.
И трите методологии на постепенното тестване попадат в хоризонтална категория поради следните поведенчески аспекти:
- И трите методологии се фокусират върху тестване на слоеве
- Всички те обмислят структурен или йерархичен дизайн
- Всички те интегрират слоевете постепенно
Предимства:
С този подход за тестване е по-лесно да се идентифицират дефектите рано и също така помага на разработчика да определи причината за проблема. Тъй като използва основите на структурираното тестване, този подход за тестване е много ефективен и точен.
Недостатъци:
Този тип подход за тестване отнема много време поради използването на заглушители и драйвери. Освен това се повтаря.
За автор: Този полезен урок е написан от Neha B. Тя е ISTQB сертифициран водещ анализатор на качеството с 8+ години опит.
Уведомете ни, ако имате въпроси / предложения.
Препоръчително четене
- Най-добри инструменти за тестване на софтуер 2021 г. [Инструменти за автоматизация на QA теста]
- Какво е тестване на компоненти или модули (научете с примери)
- Изтегляне на eBook за тестване на Primer
- Функционално тестване срещу нефункционално тестване
- Какво е тестване за издръжливост при тестване на софтуер (примери)
- Учебник за тестване по двойки или за всички двойки с инструменти и примери
- Видове тестване на софтуер: Различни видове тестване с подробности
- Урок за тестване на обем: Примери и инструменти за тестване на обем