Мени

Тест покривеност у тестирању софтвера (савети за максимизирање покривености тестирањем)

test coverage software testing

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

Комплетан водич за покривање тест тестирања софтвера: Како тестирати више, уштедети време и постићи боље резултате тестирања:

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

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

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

како уклонити елемент низа у јави

Шта је покривеност тестом?

Једноставно речено, покривеност је „Шта тестирамо и колико тестирамо?“

Обухват тестовима помаже у праћењу квалитета тестирања и помаже тестерима да креирају тестове који покривају подручја која недостају или нису потврђена.

покривеност тестом

Већина тимова израчунава покривеност само на функционалним захтевима. Такође је поштено јер прво и најважније апликација треба да ради оно што треба. Ако не, његова брзина или сигурност или једноставност употребе - ништа од тога није важно.

Међутим, ако је посвећен и независан нефункционално испитивање тимови раде на перформансама, сигурности, тестирању употребљивости итд., онда ће морати да прате своје захтеве све до извршења путем аналитике покривености тестом.

Проверите покривеност и покривеност кодом

Покривеност тестом често се меша са покривањем кода. Иако су основни принципи исти, то су две различите ствари.

Покривеност кодом заиста говори о праксама јединственог тестирања које морају бар једном да циљају сва подручја кода и то раде програмери.

Покривеност тестом је, с друге стране, тестирање сваког захтева бар једном и очигледно је активност КА тима.

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

На пример , Неки тимови захтевају покривање захтева ако постоји барем један тест случај против њега. Понекад је покривено ако му је додељен бар један члан тима. Или, ако се изврше сви тест случајеви повезани с тим.

  • Ако је креирано 10 захтева и 100 тестова - када ових 100 тестова циља свих 10 захтева и не изоставља ниједан - ово називамо адекватним покривањем тестирања на нивоу дизајна.
  • Када се изврши само 80 креираних тестова и циља само 6 захтева. Кажемо да 4 захтева нису покривена иако је урађено 80% тестирања. Ово је статистика покривености на нивоу извршења.
  • Када је само 90 тестова који се односе на 8 захтева доделило тестере, а остали нису, кажемо да је покривеност задатка тестом 80% (8 од 10 захтева).

Такође је важно када треба израчунати покривеност.

Ако то учините прерано у процесу, видећете пуно празнина јер ствари још увек нису потпуне. Стога се генерално саветује да сачекајте до последње изградње односно Финал Регрессион Буилд. Ово ће дати тачну покривеност тестовима изведеним за дате Захтеве.

Такође прочитајте => Процес управљања објављивањем и применом

Моје искуство

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

Била сам у праву - и такође у криву.

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

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

Увећајте покривеност тестом за мање времена

Ево мог искуства из једног од тадашњих интервјуа:

Како се осигуравате да је покривеност тестом потпуна или максимална? Био сам упитан.

Умммм ... Обавезно тестирам сваку функционалност , Рекао сам.

С. о кажете да када тестирате све функционалности, осећате да сте покрили максимум апликације / производа, у смислу тестирања , интервјуер је узвратио.

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

Слажем се, али моје питање је - да ли ће вам пружити самопоуздање да је покривеност тестирањем максимална или потпуна? анкетар није био расположен да ме пусти.

Сада сам постајао нестрпљив, непознат због чињенице да ћу научити једну од најважнијих тема о тестирању софтвера - ' Тест покривеност ” .

Уместо да репродукујем одломке интервјуа, овде сумирам оно што сам тога дана сазнао о покривању тестирањем. Али пре тога, разјаснимо једну ствар - покривеност тестирањем никада не значи знати да ли тестирате довољно или не, нити значи да тестирате савршено или не.

Значење покривености теста

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

Покривеност производа - Које сте аспекте производа погледали?

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

Пример # 1:

Ако је „нож“ производ, ви тестирате; само се не концентришите на проверу да ли поврће / воће правилно сече. Треба потражити и друге аспекте, на пример - корисник би требало да буде у стању да се с њим удобно носи.

Пример # 2:

Ако је „нотепад“ апликација, ви тестирате, провера релевантних карактеристика је неопходна.

Али други аспекти о којима треба водити рачуна су - апликација правилно реагује док истовремено користи друге апликације, апликација се не руши када корисник покуша да учини нешто необично , кориснику се пружају одговарајуће поруке упозорења / грешке, корисник може лако да разуме и користи апликацију, садржај помоћи доступан је по потреби.

у скруму који је одговоран за неиспуњавање сложених захтева на време

Ако не проучите поменуте сценарије, не можете да тврдите да је покривеност тестирања за апликацију потпуна.

Покривеност ризика - На које сте ризике тестирали?

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

Пример # 1:

Током испитивања авиона, ако вам испитивач каже да је у потпуности тестирао унутрашњи систем авиона и да ради у реду, али током лета није обухваћена само летачка способност авиона - каква би била ваша реакција?

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

Пример # 2:

Током тестирања веб локације за е-трговину, испитивач је узео у обзир сваки ефикасан фактор, али није узео у обзир ризик од броја корисника који истовремено приступају веб локацији и на дан Супер ПОНУДЕ, а тај ризик се сматрао великом грешком.

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

Покривеност захтевима - За које сте захтеве тестирали?

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

Пример # 1:

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

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

Пример # 2:

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

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

Такође читати => Како створити матрицу следљивости захтева

Како усвојити одговарајући метод покривања тестом?

Свест је све:

Прво, КА тим мора знати колико је посла укључено и где су задаци дизајна. На овај начин, они ће бити свесни да ли треба додати још тестова. Да бисте то урадили, можете користити РТМ као што је типична пракса.

=> Погледајте овај чланак да бисте сазнали више о њему и како га користити: Како створити матрицу сљедивости захтјева - тачан поступак са узорком предлошка

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

Табела као што је доле може бити корисна:

Тип тестаУкупно случајеваИзвршени предметиСтатусКоментари
Функционално1008050 пролаз, 30 неуспех
Компатибилност100педесет45 додавање, 5 неуспех
Употребљивост10010098 пас, 2 неуспех
Коначна регресија10010099 пасова, 1 неуспех

Како бити сигуран да је све тестирано?

  • Сваки испитивач треба да буде упознат са захтевима и методама испитивања
  • Дајте приоритет својим захтевима и усредсредите своју енергију тамо где је најпотребније
  • Будите информисани о томе како се одређено издање разликује од претходног, да бисте могли тачније да препознате критичне захтеве и усредсредите се на максимално позитивно покриће
  • Прилагодите аутоматизацију теста
  • Користите алате за управљање тестовима да увек остане у току
  • Паметан радни задатак - Усмерите своје најбоље ресурсе ка критичним задацима и пустите нове тестере да истражују више за нову перспективу
  • Одржавање а контролна листа за све задатке и разне активности
  • Више комуницирајте са својим развојним / Сцрум / БА тимовима да бисте стекли увид у понашање апликације
  • Пратите све своје циклусе израде и поправке
  • Идентификујте најутицајније проблеме у почетним верзијама (када је то могуће), тако да они каснији могу радити на бољој стабилности и доћи до оних подручја која су блокирана претходним проблемима

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

ефикасно тестирање

# 1)Преметање ресурса: Размењујте задатке између чланова вашег тима. Ово помаже у побољшању ангажовања и спречавању концентрације знања.

#два)Покривеност компатибилношћу: Обавезно сазнајте и укључите различитих прегледача и платформе да бисте тестирали своју пријаву.

# 3)Власништво: Учините тестерима одговорнима и дајте им слободу (уз праћење и подршку наравно) за модул / задатак на којем раде. Ово помаже у изградњи одговорности и омогућава им да испробају креативне начине уместо да следе претучене.

# 4)Рокови: Познавање рокова за објављивање пре почетка фазе тестирања помаже у ефикасном планирању

# 5)Комуникација : Останите у контакту са развојним тимом и другим тимовима између циклуса издања да бисте знали шта се догађа.

# 6)Одржавање РТМ-а: Делује као добар дериват од Заинтересоване стране или клијенти , на основу којих се може потврдити распоред издавања

Предности тестирања свести о покривености тестера:

Закључак

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

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

Са структуриранијим приступом, који има за циљ 100% покривеност захтева и ефикасне методе испитивања, нећете угрозити квалитет.

Надамо се да ће вам технике описане у овом чланку дати неке смернице.

Улијте своје коментаре и ставове о посту. Као и обично, волимо да се чујемо са вама.

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

^