7 principles software testing
Седам принципа тестирања софтвера: Укључујући више детаља о кластеру дефеката, Парето принципу и парадоксу пестицида.
Сигуран сам да су сви свесни „ Седам принципа тестирања софтвера ”.
Ови основни принципи испитивања помажу тимовима за тестирање да искористе своје време и напор како би процес тестирања постали ефикасан. У овом чланку ћемо детаљно научити два принципа тј. Груписање дефеката, Паретов принцип и парадокс пестицида .
Шта ћете научити:
- Седам принципа тестирања софтвера
Седам принципа тестирања софтвера
Пре дубљег сагледавања та два принципа, хајде да укратко разумемо седам принципа тестирања софтвера.
Истражимо !!
# 1) Тестирање показује присуство недостатака
Свака апликација или производ пушта се у производњу након довољне количине тестирања од стране различитих тимова или пролази кроз различите фазе попут тестирања системске интеграције, тестирања прихватљивости корисника и бета тестирања итд.
Тако да ли сте икада видели или чули од било ког тима за тестирање да су у потпуности тестирали софтвер и да у њему нема квара ? Уместо тога, сваки тим за тестирање потврђује да софтвер испуњава све пословне захтеве и да функционише према потребама крајњег корисника.
У индустрији тестирања софтвера нико неће рећи да постоји без недостатка у софтверу, што је сасвим тачно, јер тестирање не може доказати да софтвер не садржи грешке или недостатке.
Међутим, циљ испитивања је пронаћи све више скривених недостатака користећи различите технике и методе. Тестирање може открити неоткривене недостатке, а ако се не пронађу недостаци, то не значи да је софтвер без недостатака.
Пример 1 :
Узмите у обзир банкарску апликацију, ова апликација је темељно тестирана и пролази кроз различите фазе тестирања као што су СИТ, УАТ итд., И тренутно у систему нису идентификовани недостаци.
Међутим, можда постоји могућност да у производном окружењу стварни купац испроба функционалност која се ретко користи у банкарском систему, а тестери су то функцију превидели, па до данас није пронађена ниједна грешка или програмери никада нису додирнули код .
Пример 2:
Видели смо неколико реклама за сапуне, пасте за зубе, средства за прање руку или спрејеве за дезинфекцију итд. На телевизији.
Размислите о огласу за прање руку који на телевизији каже да се 99% клица може уклонити ако се користи то посебно прање руку. Ово јасно доказује да производ није 100% без клица. Стога у нашем концепту тестирања можемо рећи да ниједан софтвер није без недостатака.
# 2) Рано тестирање
Тестери се морају укључити у раној фази животног циклуса развоја софтвера (СДЛЦ). Тако се могу утврдити недостаци током фазе анализе захтева или било који недостаци у документацији. Трошкови који су укључени у отклањање таквих недостатака врло су мањи у поређењу са онима који су пронађени током каснијих фаза испитивања.
Размотрите доњу слику која показује како се трошак отклањања квара повећава како се тестирање креће ка живој производњи.
(слика извор )
Горња слика показује да су трошкови потребни за отклањање квара утврђеног током Анализе захтева мањи и наставља се повећавати како се крећемо ка фази тестирања или одржавања.
Сад је питање колико рано треба да започне тестирање ?
Када се захтеви финализују, тестери морају да се укључе за тестирање. Тестирање треба извршити на документима захтева, спецификацијама или било којој другој врсти документа, тако да ако се захтеви нетачно дефинишу, онда се то може одмах поправити, уместо да се поправе у фази развоја.
# 3) Исцрпно тестирање није могуће
Током стварног тестирања није могуће тестирати све функционалности са свим важећим и неважећим комбинацијама улазних података. Уместо овог приступа, разматра се тестирање неколико комбинација на основу приоритета коришћењем различитих техника.
Исцрпно тестирање захтијеваће неограничене напоре и већина тих напора је неучинковита. Такође, временски рокови пројекта неће дозволити тестирање толиког броја комбинација. Стога се препоручује тестирање улазних података помоћу различитих метода попут еквивалентне партиције и анализе граничне вредности.
На пример ,Претпоставимо да имамо поље за унос које прихвата само абецеде, посебне знакове и бројеве од 0 до 1000. Замислите колико комбинација би се појавило за тестирање, није могуће тестирати све комбинације за сваки тип уноса.
Напори на тестирању потребни за тестирање биће огромни, а то ће такође утицати на временски распоред и трошкове пројекта. Стога се увек каже да исцрпно тестирање практично није могуће.
# 4) Тестирање зависи од контекста
На тржишту је доступно неколико домена као што су банкарство, осигурање, медицина, путовања, оглашавање итд., А сваки домен има низ апликација. Такође, за сваку домену, њихове апликације имају различите захтеве, функције, различиту сврху тестирања, ризик, технике итд.
Различити домени се различито тестирају, тако да се тестирање заснива искључиво на контексту домена или апликације.
На пример ,тестирање банкарске апликације разликује се од тестирања било које апликације за е-трговину или оглашавање. Ризик повезан са сваком врстом апликације је различит, па није ефикасно користити исти метод, технику и тип испитивања за тестирање свих врста апликација.
# 5) Груписање дефеката
Током тестирања може се догодити да је већина пронађених недостатака повезана са малим бројем модула. Разлози за то могу бити вишеструки, као што су модули сложени, кодирање таквих модула може бити сложено итд.
Ово је Парето принцип тестирања софтвера где се 80% проблема налази у 20% модула. Више о кластеру дефеката и Парето принципу сазнаћемо касније у овом чланку.
# 6) Парадокс пестицида
Принцип Пестициде Парадок каже да ако се исти низ тест случајева изводи изнова и изнова током одређеног временског периода, онда тај низ тестова није довољно способан да идентификује нове недостатке у систему.
Да би се превазишао овај „Парадокс пестицида“, скуп тест случајева треба редовно прегледати и ревидирати. Ако је потребно, може се додати нови скуп тест случајева, а постојећи тест случајеви могу се избрисати ако више не могу да пронађу недостатке у систему.
# 7) Одсуство грешке
Ако је софтвер у потпуности тестиран и ако пре издања нису пронађени недостаци, онда можемо рећи да је софтвер 99% без кварова. Али шта ако је овај софтвер тестиран на основу погрешних захтева? У таквим случајевима чак ни проналажење недостатака и њихово исправљање на време не би помогло јер се испитивање врши на погрешним захтевима који нису према потребама крајњег корисника.
На пример, претпоставимо да је апликација повезана са веб локацијом е-трговине и захтевима против функционалности „Кошарице или корпе за куповину“ која је погрешно протумачена и тестирана. Овде чак ни проналажење више недостатака не помаже премештању апликације у следећу фазу или у производно окружење.
Ово је седам принципа софтверског тестирања.
Сада истражимо Груписање дефеката, Паретов принцип и парадокс пестицида у детаљ .
Групирање дефеката
Током тестирања било ког софтвера, тестери се углавном сусрећу са ситуацијом у којој је већина пронађених недостатака повезана са неком одређеном функционалношћу, а остале функције ће имати мањи број недостатака.
Груписање дефеката значи мали број модула који садрже већину недостатака. У основи, кварови нису равномерно распоређени у целој апликацији, већ су дефекти концентрисани или централизовани у две или три функционалности.
Понекад је то могуће због сложености апликације, кодирање може бити сложено или незгодно, програмер може погрешити што може утицати само на одређену функционалност или модул.
Груписање дефеката заснива се на „ Парето принцип ”Који је познат и као Правило 80-20 . То значи да је 80% пронађених недостатака настало због 20% модула у апликацији. Концепт Парето принципа у почетку је дефинисао италијански економиста - Вилфродо Парето .
Ако тестери погледају 100 недостатака, тада неће бити јасно да ли постоји неко основно значење против тих 100 недостатака. Али ако је тих 100 дефеката категорисано према неким одређеним критеријумима, тестерима ће можда бити јасно да велики број дефеката припада само неколико специфичних модула.
На пример ,размотримо доњу слику која је тестирана за неку од банкарских апликација и показује да је већина недостатака повезана са функционалношћу „прекорачења“. Преостале функције попут Резимеа рачуна, Преноса средстава, Сталних упутстава итд. Имају ограничен број недостатака.
(слика извор )
Горња слика наводи да постоји 18 недостатака око функционалности прекорачења од укупно 32 недостатка, што значи да се 60% недостатака налази у модулу „прекорачење“.
Стога се тестери током извођења углавном концентришу на ово подручје како би пронашли све више недостатака. Препоручује се да тестери имају сличан фокус и на остале модуле током тестирања.
Када се исти код или модул тестира, изнова и изнова, користећи скуп тест случајева него током почетних итерација, тада је број дефеката висок, међутим, након неке итерације, број квара ће се значајно смањити. Груписање дефеката указује на то да ће подручје склоно дефектима бити темељно тестирано током регресионог тестирања.
Парадокс пестицида
Када се утврди да један од модула има више недостатака, тада тестери улажу додатне напоре да тестирају тај модул.
Након неколико итерација тестирања, квалитет кода се побољшава и број дефеката почиње да опада јер већину недостатака отклања развојни тим, јер су програмери такође опрезни док кодирају одређени модул у којем су тестери пронашли више недостатака.
Стога се у једном тренутку већина дефеката открије и отклони, тако да у том модулу нису пронађене нове грешке.
Међутим, понекад се може десити да, иако будемо изузетно опрезни током кодирања на одређеном модулу (овде у нашем случају, „ Прекорачење ”Модул), програмер може занемарити остале модуле да би га правилно кодирао или би промене направљене у том модулу могле имати негативан утицај на друге функционалности као што су Резиме рачуна, Пренос средстава и Трајна упутства.
Када тестери користе исти скуп тест случајева за извршавање модула где је пронађена већина недостатака (модул прекорачења), након што програмери отклоне те недостатке, ти тест случајеви нису много ефикасни за проналажење нових недостатака. Као крајњи крај протока прекорачења, модул се темељито тестира и програмери су такође опрезно написали код за тај модул.
Неопходно је ревидирати и ажурирати ове тестове. Такође је добра идеја да додате нове тестове како би се могло наћи нових и више недостатака у различитим областима софтвера или апликације.
Превентивне методе парадокса пестицида
Постоје две опције помоћу којих можемо спречити пестицидни парадокс као што је приказано доле:
до) Напишите нови сет тест случајева који ће се фокусирати на различита подручја или модуле (осим ранијих модула склоних дефектима - Пример: „Прекорачење рачуна“) софтвера.
б) Припремите нове тест случајеве и додајте постојећим тест случајевима.
У „ метода А. ”, Тестери могу да пронађу више недостатака у осталим модулима у којима нису били фокусирани током ранијег тестирања или програмери нису били посебно опрезни током кодирања.
У нашем горенаведеном примеру, тестери могу да пронађу више недостатака у модулима „Резиме рачуна“, „Пренос средстава“ или „Трајна упутства“ помоћу новог скупа тест случајева.
Али може се десити да тестери занемаре ранији модул ( Пример: „Овердрафт“), где је већина дефеката пронађена у ранијој итерацији, а то може представљати ризик јер је овом модулу (Овердрафт) можда убризган нови квар након кодирања осталих модула.
У „ метода Б. ”, Нови тест случајеви су припремљени тако да се у осталим модулима могу наћи нови потенцијални недостаци.
Овде у нашем примеру, новонастали тест примери ће моћи да помогну у идентификовању недостатака у модулима као што су Резиме рачуна, Пренос средстава и Стална упутства. Међутим, тестери не могу занемарити раније модуле склоне дефектима ( Пример: „Овердрафт“) јер су ови нови тест случајеви спојени са постојећим тест случајевима.
Постојећи тест случајеви били су више усредсређени на модул „Овердрафт“, а нови тест случајеви на осталим модулима. Дакле, сви скупови тест случајева се извршавају најмање једном, чак и када се догоди промена кода на било ком модулу. Ово ће осигурати да се изврши правилна регресија и да се квар може препознати због ове промене кода.
Користећи други приступ, укупан број тест случајева значајно расте и резултира са више напора и времена потребних за извршење. То ће очигледно утицати на временске рокове пројекта, а што је најважније и на буџет пројекта.
Стога, да би се превазишао овај проблем, сувишни тестови се могу прегледати, а затим уклонити. Много је тест случајева који постају бескорисни након додавања нових тест случајева и модификације постојећих тест случајева.
Неопходно је проверити који тест случајеви нису успели да би се идентификовали недостаци у последњих 5 итерација (претпоставимо 5 итерација) и који тест случајеви нису много важни. Такође може бити случај да појединачни проток обухваћен у неколико тест случајева може бити покривен у другим тест случајевима, а они случајеви који имају појединачни проток могу бити уклоњени.
То ће заузврат смањити укупан број тест случајева.
На пример ,имамо 50 тест случајева који покривају један одређени модул и видели смо да од ових 50 тест случајева 20 тест случајева није успело да открије нови квар у последњих неколико итерација тестирања (претпоставимо 5 итерација). Дакле, ових 20 тест случајева треба темељито прегледати, а ми морамо провјерити колико су ови тест случајеви важни и на основу тога се може донијети одлука о томе да ли ћемо задржати 20 тест случајева или их уклонити.
Пре уклањања било ког тест случаја, проверите да ли је ток функционалности обухваћен тим тест случајевима покривен другим тест случајем. Овај процес треба пратити на свим модулима како би се укупан број тест случајева значајно смањио. Ово ће осигурати смањење укупног броја тест случајева, али и даље постоји 100% покривеност потребама.
То значи да сви преостали тестови покривају све пословне захтеве, па стога нема компромиса у погледу квалитета.
Закључак
Тестирање софтвера је суштински корак у СДЛЦ-у јер се проверава да ли софтвер ради како крајњи корисник треба или не.
Тестирањем се идентификује што је више могуће недостатака. Стога, да би тестирање било ефикасно и ефикасно, сви треба да буду свесни и заиста разумеју седам принципа софтверског тестирања и познати су као стубови за тестирање.
Већина тестера су применили и искусили ове принципе током стварног тестирања.
шта је рачунарски оперативни систем
Генерално, појам принцип значи правила или законе којих се треба придржавати. Стога, сви у индустрији тестирања софтвера морају следити ових седам принципа, а ако неко игнорише било који од ових принципа, то може коштати огромне трошкове за пројекат.
Срећно читање !!
Препоручено читање
- Најбољи алати за тестирање софтвера 2021. године (КА Тест Аутоматион Тоолс)
- Посао за КА помоћника за тестирање софтвера
- Курс за тестирање софтвера: Који институт за тестирање софтвера да се придружим?
- Одабир тестирања софтвера за вашу каријеру
- Тестирање софтвера Технички садржај Вритер Фрееланцер Јоб
- Шта је техника испитивања заснована на недостацима?
- Нека занимљива питања за испитивање софтверског тестирања
- Повратне информације и прегледи курса за тестирање софтвера