Шта је интеграционо тестирање?
ТЕСТИРАЊЕ ИНТЕГРАЦИЈЕ дефинисано је као врста тестирања где су софтверски модули интегрисани логички и тестирани као група. Типични софтверски пројекат састоји се од више софтверских модула, кодираних од различитих програмера. Сврха овог нивоа тестирања је да разоткрије недостатке у интеракцији између ових софтверских модула када су интегрисани
Тестирање интеграције усредсређено је на проверу комуникације података између ових модула. Отуда се такође назива и „И & Т“ (интеграција и тестирање), „тестирање низа“ и понекад „тестирање нити “ .
- Шта је интеграционо тестирање?
- Зашто интеграционо тестирање?
- Пример интеграционог тест случаја
- Приступи, стратегије, методологије испитивања интеграције
- Приступ Великог праска:
- Инкрементални приступ
- Шта су Стуб анд Дривер?
- Интеграција одоздо према горе
- Интеграција одозго надоле:
- Хибридна / Сендвич интеграција
- Како се врши интеграционо тестирање?
- Кратак опис планова за испитивање интеграције:
- Критеријуми за улазак и излаз из интеграционог тестирања
- Најбоље праксе / смернице за интеграционо тестирање
Зашто интеграционо тестирање?
Иако је сваки софтверски модул јединствено тестиран, недостаци и даље постоје из различитих разлога попут
- Модул, генерално, дизајнира појединачни програмер чије се разумевање и логика програмирања могу разликовати од осталих програмера. Тестирање интеграције постаје неопходно како би се потврдило да софтверски модули раде јединствено
- У време развоја модула, постоје велике шансе да клијенти промене захтеве. Ови нови захтеви можда неће бити јединствено тестирани и стога постаје неопходно тестирање системске интеграције.
- Интерфејси софтверских модула са базом података могу бити погрешни
- Спољни хардверски интерфејси, ако их има, могу бити погрешни
- Неадекватно руковање изузецима може изазвати проблеме.
Кликните овде ако видео снимку није доступан
Пример интеграционог тест случаја
Интеграцијски тестни случај разликује се од осталих тестних случајева у смислу да се углавном фокусира на интерфејсе и проток података / информација између модула . Овде приоритет треба дати интеграцијским везама, а не јединственим функцијама које су већ тестиране.
Примери примера тестова интеграције за следећи сценарио: Апликација има 3 модула, на пример „Страница за пријављивање“, „Поштанско сандуче“ и „Избриши е-пошту“ и сваки од њих је интегрисан логички.
Овде се не концентришите много на тестирање странице за пријављивање, јер је то већ учињено у јединственом тестирању. Али проверите како је повезан са страницом поштанског сандучета.
Слично томе, поштанско сандуче: Проверите његову интеграцију у модул Делете Маилс.
ИД тест случаја | Циљ тест случаја | Опис тест случаја | Очекивани резултат |
---|---|---|---|
1 | Проверите везу интерфејса између модула Пријава и поштанско сандуче | Унесите податке за пријављивање и кликните на дугме Пријава | Да буде усмерен на поштанско сандуче |
2 | Проверите везу интерфејса између поштанског сандучета и модула за брисање поште | У поштанском сандучету одаберите е-пошту и кликните на дугме за брисање | Изабрани е-маил треба да се појави у директоријуму Избрисано / Смеће |
Приступи, стратегије, методологије испитивања интеграције
Софтверски инжењеринг дефинише низ стратегија за извршавање интеграционог тестирања, наиме.
- Приступ Великог праска:
- Инкрементални приступ: који се даље дели на следеће
- Одозго на доле приступ
- Приступ одоздо према горе
- Сендвич приступ - комбинација одозго надоле и одоздо према горе
Испод су различите стратегије, начин њиховог извршавања и њихова ограничења као и предности.
Тестирање великог праска
Тестирање великог праска је приступ интеграцијског тестирања у којем се све компоненте или модули одједном интегришу и затим тестирају као јединица. Овај комбиновани скуп компонената сматра се целином током тестирања. Ако све компоненте у јединици нису довршене, процес интеграције се неће извршити.
Предности:
- Погодно за мале системе.
Мане:
- Локализација кварова је тешка.
- С обзиром на огроман број интерфејса које треба тестирати у овом приступу, неке везе интерфејса које треба тестирати могу се лако пропустити.
- Будући да интеграционо тестирање може започети тек након што су дизајнирани „сви“ модули, тим за тестирање ће имати мање времена за извршавање у фази тестирања.
- Будући да се сви модули испитују одједном, високо ризични модули нису изоловани и тестирани по приоритету. Периферни модули који се баве корисничким интерфејсима такође нису изоловани и тестирани на приоритету.
Инкрементално тестирање
У приступу инкременталног тестирања , тестирање се врши интегрисањем два или више модула који су међусобно логички повезани и затим се тестира на правилно функционисање апликације. Тада се остали сродни модули поступно интегришу и поступак се наставља све док се сви логички повезани модули не интегришу и успешно тестирају.
Инкрементални приступ се, заузврат, спроводи помоћу две различите методе:
- Одоздо према горе
- Топ Довн
Стубс анд Дриверс
Стубс анд Дриверс су лажни програми у интеграционом тестирању који се користе за олакшавање активности тестирања софтвера. Ови програми делују као замена за моделе који недостају у тестирању. Они не примењују целокупну програмску логику софтверског модула, али симулирају комуникацију података позивајућим модулом током тестирања.
Стуб : позива га модул који се тестира.
Возач : позива модул да се тестира.
Испитивање интеграције одоздо према горе
Тестирање интеграције одоздо према горе је стратегија у којој се прво тестирају модули нижег нивоа. Ови тестирани модули се затим даље користе за олакшавање тестирања модула вишег нивоа. Процес се наставља све док се не тестирају сви модули на највишем нивоу. Једном када се модули нижег нивоа тестирају и интегришу, формира се следећи ниво модула.
Дијаграмски приказ :
Предности:
- Локализација грешке је лакша.
- Не губи се време чекајући да се сви модули развију за разлику од Биг-банг приступа
Мане:
- Критични модули (на највишем нивоу софтверске архитектуре) који контролишу ток апликације тестирају се последњи и могу бити склони оштећењима.
- Рани прототип није могућ
Тестирање интеграције одозго надоле
Тестирање интеграције одозго надоле је метода у којој се тестирање интеграције одвија од врха до дна пратећи контролни ток софтверског система. Прво се тестирају модули вишег нивоа, а затим модули нижег нивоа и интегришу се како би се проверила функционалност софтвера. Стубс се користе за испитивање ако неки модули нису спремни.
Дијаграмски приказ:
Предности:
- Локализација кварова је лакша.
- Могућност добијања раног прототипа.
- Критични модули се тестирају на приоритету; могле би се прво наћи и отклонити главне недостатке у дизајну.
Мане:
- Потребне су многе Стубс.
- Модули нижег нивоа су неадекватно тестирани.
Испитивање сендвича
Испитивање сендвича је стратегија у којој се модули највишег нивоа тестирају са модулима нижег нивоа, а истовремено се нижи модули интегришу са врхунским модулима и тестирају као систем. То је комбинација приступа одозго према доле и одоздо према горе, па се зато назива хибридним тестирањем интеграције . Користи оба квара као и возаче.
Како се врши интеграционо тестирање?
Поступак тестирања интеграције, без обзира на стратегије тестирања софтвера (размотрене горе):
- Припремите план интеграционих тестова
- Дизајнирајте тест сценарије, случајеве и скрипте.
- Извршење тест случајева, праћено пријављивањем недостатака.
- Праћење и поновно тестирање недостатака.
- Кораци 3 и 4 се понављају док завршетак интеграције не буде успешан.
Кратак опис планова за испитивање интеграције:
Садржи следеће атрибуте:
- Методе / приступи испитивању (као што је горе разматрано).
- Обим и ван опсега Предмети интеграцијског испитивања.
- Улоге и одговорности.
- Предуслови за интеграционо тестирање.
- Окружје за тестирање.
- Планови ризика и ублажавања.
Критеријуми за улазак и излаз из интеграционог тестирања
Критеријуми за улазак и излазак у фазу тестирања интеграције у било ком моделу развоја софтвера
Критеријуми за улазак:
- Јединствено тестиране компоненте / модули
- Све грешке високог приоритета исправљене и затворене
- Сви модули који се успешно довршавају и интегришу.
- Интеграциони тестови План, тест случај, сценарији који ће бити потписани и документовани.
- Потребно тест окружење које треба поставити за тестирање интеграције
Излазни критеријуми:
- Успешно тестирање интегрисане апликације.
- Извршени тест случајеви су документовани
- Све грешке високог приоритета исправљене и затворене
- Технички документи који се подносе, а затим напомене уз издање.
Најбоље праксе / смернице за интеграционо тестирање
- Прво одредите стратегију интеграционог тестирања која би могла да се усвоји, а касније припремите тест случајеве и податке о тестовима у складу с тим.
- Проучите архитектонски дизајн апликације и идентификујте критичне модуле. Треба их тестирати на приоритету.
- Набавите дизајн интерфејса од Архитектонског тима и креирајте тест случајеве како бисте детаљно верификовали све интерфејсе. Интерфејс са базом података / спољним хардвером / софтверском апликацијом мора бити детаљно тестиран.
- Након тест случајева, подаци о тестовима имају кључну улогу.
- Увек припремите лажне податке пре извршења. Не бирајте податке са теста током извршавања тест случајева.