Мени

Функционално тестирање против тестирања перформанси: треба ли то радити истовремено?

functional testing vs performance testing

Испробајте Наш Инструмент За Елиминисање Проблема

Функционално тестирање против тестирања перформанси:

Разлике између Испитивање перформанси, испитивање оптерећења и тестирање напрезања су објашњени са примерима у нашем последњем упутству.

Тестирање софтвера покрива широк спектар подручја у којима може доћи до било какве провере или потврде функционалности софтвера. Повремено се нефункционални аспекти мање односе на функционалне аспекте. Не изводе се практично; истовремено током тестирања софтвера.

=> Кликните овде за комплетну серију водича за тестирање перформанси

Овај чланак објашњава додатне предности квалитета софтверског производа током различитих сценарија животног циклуса тестирања софтвера када се истовремено узимају и функционални и нефункционални.

испитивање функционалних перформанси 5

Шта ћете научити:

Брза разлика између тестирања перформанси и функционалног тестирања

Сл НОФункционално испитивање
Тестирање перформанси
1Да бисте проверили тачност софтвера са одређеним улазима у односу на очекивани излазДа би се верификовало понашање система у различитим условима оптерећења
дваМоже бити ручно или аутоматизовано
Може се ефикасно изводити ако је аутоматизован
3Један корисник изводи све операције
Неколико корисника изводи жељене операције
4Потребно је укључивање купаца, тестера и програмераПотребно је укључивање купаца, тестера, програмера, ДБА и Н / В менаџерског тима
5Пробно окружење за производњу није обавезно и захтеви за В / В су минималниЗахтева близину тестног окружења за производњу и неколико Х / В објеката за попуњавање терета

Зашто функционално испитивање и испитивање перформанси треба радити истовремено?

Функционално тестирање постаје много важније за свако издање софтвера. Стварно засновано на резултатима верификација и валидација у реплицираном производном или тестном окружењу су места где се тестирање обично дешава.

Цурење недостатака може постати једно од највећих проблема:

Испитивачи имају већу одговорност од програмера у погледу квалитета производа. У основи, они не желе да тестирани производ има цурење недостатака. Испитивачи обично обављају само функционална испитивања да би то постигли.

испитивање функционалних перформанси 1

Следи разговор између аМенаџер теста и тестер :

(Тест Манагер се назива „ТМ“, а Тестер „ТР“)

ТМ : Хеј друже ... Како стојимо са тестирањем производа „А“?

ТР : Да ... Напредујемо у већој мери.

ТМ : То је фантастично ... А какав је наш опсег у погледу испитивања перформанси док је функционално тестирање у току?

ТР : Не покривамо их, наши производи би требало да буду само у функционалном подручју, а не у нефункционалном подручју. Такође, тест окружење које користимо није тачна реплика продукције.

Из горњег разговора треба узети у обзир неколико питања:

  • Да ли функционално тестирање има фактор који зависи од перформанси?
  • Шта ако се перформансе софтвера погоршају, али испорука производа се одвија без провере перформанси?
  • Тестирање перформанси - да ли постоји заједно са процесом функционалног тестирања?

Постало је општа пракса да тестери не раде на нефункционалним аспектима, осим ако се то од њих тражи. Уобичајено је избегавање нефункционално испитивање док клијент не пријави проблеме са перформансама софтвера који се тестира.

Дакле, треба да размотрите 2 питања:

  1. Перформансе - утиче ли на функционално тестирање?
  2. Да ли држимо тестирање перформанси као засебну испоруку, чак и ако клијента забрињава?

Испитивање перформанси је важно !

алат за поправку софтвера виндовс виндовс 10

Софтвер ради на основу различитих архитектура и следећих модела, укључујући:

  1. Потребни модели одговора на одговор
  2. Системи засновани на трансакцијама
  3. Системи засновани на оптерећењу
  4. Системи засновани на репликацији података

Функционално тестирање понашања горе поменутог систематског модела зависи од перформанси система.

испитивање функционалних перформанси 2

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

Следи разговор између аклијента и менаџера теста.

(Клијент се назива „ЦЛ“, а менаџер теста као „ТМ“)

ЦЛ : Стога долазимо до решења које смо затражили, надам се да ће бити вишеструких понављања тестирања које се тренутно догађа.

ТМ : Да, то се може учинити. Као што сте рекли, биће већа вероватноћа поновног тестирања, желели бисмо да предложимо аутоматизацију која ће се бавити функционалним (регресионим) тестирањем.

ЦЛ : ОК сјајно, пошаљите нам свој приступ како бисмо могли да одобримо ово. Аутоматизација ће имати много већи учинак уз минималан напор.

ТМ : Баш тако. Радићемо на приступу и јавићемо вам се с доказом о концепту.

Из горњег разговора је јасно да је потреба клијената да оптимизују ефикасност.

Истраживање случаја

Компанија АБЦ ради на пројекту за развој софтвера А. Тестирање софтвера А ради компанија КСИЗ.

Уговор за компаније АБЦ и КСИЗ има одређена ограничења за њихову сарадњу. Свака дискусија између две компаније треба да се одвија једном недељно или три пута месечно. Систем ради на моделу режима захтева-одговора. Фазу развоја је завршила компанија АБЦ.

Сада је време да компанија КСИЗ изврши формално функционално тестирање на софтверу А. КСИЗ почиње да ради на тестирању софтвера А. Чврсто су се позабавили софтвером и дали су „Иди“ за имплементацију уживо након 2 циклуса тестирања.

Упркос сертификату о квалитету тима за тестирање, имплементација уживо није добро прошла. Било је пуно грешака у постпродукцији. Клијенти су се суочавали са великим бројем проблема, укључујући и прекид функционалности за све пословне процесе.

Па шта је садпроблем?

испитивање функционалних перформанси 3

  • Да ли је проблем у ограничењу сарадње између развојног и испитног тима?
  • Да ли је то што захтеви нису обухваћени 100%?
  • Да ли производ није тестиран у одговарајућем тестном окружењу?
  • Или било који други узрок?

Након пажљивог истраживања и анализе,закључени су следећи:

испитивање функционалних перформанси 4

  1. Било је мало зависних и међузависних апликација које су имале проблема са перформансама док су преузимале одговоре.
  2. Коришћени улази за тест нису били апсолутни.
  3. Није се водило рачуна о робусности софтвера.
  4. Много проблема са синхронизацијом између више независних апликација.
  5. Тестирање софтвера је извршило више поновних радова који нису узети у обзир.

Отуда послепоправне радњеТим за планирање је ускочио, предложено је следеће:

  1. Интеракција између развојног тима и тима за тестирање мора се повећати.
  2. Све зависне апликације морају бити повезане и укључене у тестирање функционалности система
  3. Вредност временског ограничења захтева и одговора треба повећати како би се добио простор за непроизводна окружења
  4. У функционалном тестирању морају се користити различити уноси у распону од једноставних до сложених
  5. Нефункционално испитивање, посебно испитивање перформанси и оптерећења, мора се обавити према савету поправног тима.
  6. Поред тестирања система, мора се извршити и тестирање системске интеграције.
  7. Мора се обезбедити минимални временски размак између било које две итерације тестирања. Ово је за поновно тестирање претходно идентификованих грешака.
  8. Све грешке идентификоване у претходним итерацијама треба да буду исправљене у тренутној итерацији.

Тест тим је спровео све предложене радње и за мало времена је откривен велики број недостатака.

Запажања:

  1. Распоред имплементације софтвера уживо се значајно побољшао оптимизацијом времена циклуса тестирања.
  2. Остварен је добар напредак у оптимизацији квалитета софтвера. Отуда је дошло до страховитог смањења броја улазница за подршку након примене.
  3. Поновни радови су смањени и тестирано је понављање уместо поновног рада. Између различитих понављања, примећена су боља побољшања у квалитету.

Закључак

Извођење нефункционалног тестирања током извршавања функционалног теста је повољније и додаће више предности укупном квалитету софтвера. Ово ће идентификовати грешке у перформансама (ограничено на окружење за тестирање и зависност) и тиме ће смањити ситуације претпоставки функционалних проблема.

Потребно је направити довољно планирања за извођење функционалних и нефункционалних испитивања (на минимални ниво) како би се одржао чврст однос међу осталим заинтересованим странама у пројекту.

Абоут Аутхор: Ово је чланак који је написао Нагарајан. Ради као пробни вођа са преко 6 година искуства у тестирању у различитим функционалним областима као што су банкарство, авиокомпаније, телеком у погледу ручног и аутоматизованог рада.

Наш предстојећи водич ће објаснити више о плану испитивања перформанси и стратегији испитивања.

=> Посетите овде за комплетну серију водича за тестирање перформанси

ПРЕВ Туториал |. | СЛЕДЕЋА Лекција

Препоручено читање

^