Kas yra pagrįstas vieneto testų (ir kodėl)% kodas?

Jei norėtumėte nurodyti minimalų kodo procentinį vienetų testų aprėptį, galbūt net kaip reikalavimą įsipareigoti saugyklai, kas tai būtų?

Paaiškinkite, kaip atėjote į savo atsakymą (nes jei visa, ką darėte, pasirinkote numerį, tada galėčiau tai padaryti pats;)

435
18 сент. sveikatą nustato 18 sep. 2008-09-18 07:25 '08 at 7:25 2008-09-18 07:25
@ 30 atsakymų

Ši Alberto Savoy proza ​​tiksliai atsako į šį klausimą (gražiai linksmu būdu):

http://www.artima.com/forums/flat.jsp?forum=106>

Testivus dėl bandymų apimties

Anksčiau ryte programuotojas paprašė didžiojo meistro:

"Aš esu pasirengęs parašyti kai kuriuos vieneto testus. Kokį kodą turėčiau pateikti?"

Didysis kapitonas atsakė:

„Nesijaudinkite dėl aprėpties, tiesiog parašykite gerus testus.“

Programuotojas nusišypsojo, nulenkė ir paliko.

...

Vėliau tą pačią dieną antrasis programuotojas uždavė tą patį klausimą.

Didysis meistras nurodė verdančio vandens puodą ir sakė:

"Kiek jums reikia įterpti ryžių grūdų?"

Programuotojas, atrodęs nesuprantamas, atsakė:

„Kaip aš galiu jums pasakyti? Tai priklauso nuo to, kiek žmonių turite maitinti, kaip jie yra alkani, kokie kiti maisto produktai jums tarnauja, kiek ryžių turite prieigą ir tt“

„Tikrai“, - sakė didysis šeimininkas.

Antrasis programuotojas nusišypsojo, nulenkė ir paliko.

...

Iki dienos pabaigos, trečiasis programuotojas atėjo ir paprašė to paties klausimo apie kodo aprėptį.

"Aštuoniasdešimt procentų ir ne mažiau!" Meistras atsakė griežtai, pataikė savo kumštį ant stalo.

Trečiasis programuotojas nusišypsojo, nulenkė ir paliko.

...

Po šio paskutinio atsakymo jaunasis studentas kreipėsi į didįjį meistrą:

"Didysis meistras, šiandien aš jus klausiau, atsakydamas į tą patį klausimą apie kodo aprėptį su trimis skirtingais atsakymais. Kodėl?"

Didysis meistras pakilo iš kėdės:

"Atneškite šviežią arbatą ir papasakokite apie tai."

Užpildę puodelius karštos žaliosios arbatos, nuostabus vedlys pradėjo atsakyti:

„Pirmasis programuotojas yra naujas ir tik pradeda dirbti su testavimu. Dabar jis turi daug kodų ir testų. Jis turi daug ką nuveikti, nes šiuo metu sutelkiant dėmesį į kodo aprėptį būtų prastai ir visiškai nenaudinga. Jis gali nerimauti dėl aprėpties vėliau. "

„Antrasis programuotojas, kita vertus, turi daug patirties programavimo ir testavimo srityse. Kai aš atsakiau, klausdamas jos, kiek ryžių grūdų turėjau įdėti į puodą, padėjau jai suprasti, kad reikalingų bandymų kiekis priklauso nuo veiksnių skaičiaus ir žino tuos veiksnius geriau nei aš, ar jos kodas yra pabaigoje? Nėra vieno, paprasto, atsakingo ir shes pakankamai protingo, kad galėtume dirbti su tiesa.

„Akivaizdu, - sakė jaunasis studentas“, bet jei nėra paprasto atsakymo, kodėl atsakėte į trečiąjį „aštuoniasdešimties procentų“ programuotoją? "

Didysis meistras juokėsi taip sunkiai ir garsiai, kad jo skrandis rodo, kad jis gėrė daugiau nei tik žalioji arbata, flopavo aukštyn ir žemyn.

"Trečiasis programuotojas nori tik paprastų atsakymų - net jei nėra paprastų atsakymų ... ir tada ne, sekite juos vistiek."

Jaunas mokinys ir pilkas plaukuotas didysis meistras baigė gerti arbatą kontempliatyvioje tyloje.

18 сент. Atsakymą pateikė Jon Limjap 18 rugsėjis 2008-09-18 07:30 '08, 7:30, 2008-09-18 07:30

Kodo aprėptis yra klaidinanti metrika, jei tikslas yra 100% aprėptis (vietoj 100% visų funkcijų tikrinimo).

  • Jūs galite gauti 100% paspaudę visas eilutes. Tačiau vis tiek galite praleisti bandymą tam tikra seka (loginiu keliu), kuriame šios linijos krenta.
  • Jūs negalite gauti 100%, bet vis dar išbandėte visus savo kodo kelius 80% / freq. Bandymai, kuriais patikrinama kiekviena „mesti„ ExceptionTypeX “ar panašią apsauginę programinę įrangą, kurią įvedėte, yra„ malonu turėti “„ neturėtų būti “

Taigi pasitikėkite savimi ar savo kūrėjais ir padenkite kiekvieną kelią per savo kodą. Būkite pragmatiški ir nesiekite stebuklingo 100% aprėpties. Jei esate TDD kodas, turite gauti 90% + aprėptį kaip premiją. Naudokite kodą, kad išryškintumėte praleistus kodo gabalus (neturėtų būti, jei esate TDD, nors .. kadangi rašote kodą tik norint išlaikyti testą. Be partnerio testo kodo negali būti.)

67
18 сент. Gishu rugsėjo 18 d. atsakymas 2008-09-18 07:33 '08, 07:33, 2008-09-18 07:33

Kodo aprėptis yra didelė, tačiau funkcinė aprėptis dar geriau. Nemanau, kad parašysiu kiekvieną eilutę. Bet aš tikrai manau, kad parašėte 100% visų funkcijų, kurias norėčiau pateikti (netgi dėl papildomų vėsių savybių, kurias aš su manimi atvedžiau ir kurios nebuvo aptartos susitikimų metu).

Nesijaučiu, jei turiu kodą, kuris nebus įtrauktas į bandymus, bet man nerūpi, jei pertvarkau savo kodą ir galiu elgtis kitaip. Todėl vienintelis tikslas yra 100% funkcionalumas.

36
28 апр. atsakymas pateikiamas tofi9 balandžio 28 d 2009-04-28 01:56 '09, 1:56 val. 2009-04-28 01:56

Mano mėgstamiausias aprėpties kodas pažymėtas 100%. Žvaigždutė atsiranda, nes aš norėčiau naudoti įrankius, leidžiančius pažymėti tam tikras eilutes kaip eilutes, kurių neatsižvelgiama. Jei aš padengsiu 100% „skaičiuojamų“ linijų, esu pasirengęs.

Pagrindinis procesas:

  • Parašau savo testus, kad galėčiau įgyvendinti visus funkcionalumus ir ekstremalius atvejus, kuriuos galiu galvoti (paprastai dirbdamas iš dokumentacijos).
  • Paleidžiu kodo taikymo priemones
  • Aš manau, kad bet kokios eilutės ar keliai, kurie nėra laikomi, ir bet kokie mano nuomone nesvarbūs arba nepasiekiami (dėl gynybinio programavimo).
  • Rašau naujus testus, kad būtų padengtos trūkstamos linijos, ir tobulinti dokumentaciją, jei šie ribiniai atvejai nėra paminėti.

Taigi, jei mano personalas ir aš pridėsime naują kodą ar pakeisime bandymus ateityje, yra ryški linija, kad galėtume pasakyti, ar mes praleidome kažką svarbaus - aprėptis sumažėjo žemiau 100%. Tačiau tai taip pat suteikia lankstumo sprendžiant įvairius bandymų prioritetus.

17
07 окт. atsakymą pateikė Eponymous 07 okt. 2014-10-07 18:58 '14, 18:58, 2014-10-07 18:58

Priimtas atsakymas suteikia gerą argumentą - nėra vieno numerio, kuris būtų prasmingas kaip standartas kiekvienam projektui. Yra projektų, kuriems tiesiog nereikia tokio standarto. Tais atvejais, kai priimtinas atsakymas nėra tinkamas, mano nuomone, aprašoma, kaip šis sprendimas gali būti priimtas šiam projektui.

Aš tai padarysiu. Aš nesu testavimo ekspertas ir džiaugiuosi matydamas protingesnį atsakymą.

Kada nustatyti kodo aprėpties reikalavimus

Pirma, kodėl pirmiausia norite nustatyti tokį standartą? Apskritai, kai norite įvesti empirinį pasitikėjimą savo procesu. Ką turiu omenyje empiriniu tikrumu? Na, tikrasis tikslas yra teisingumas . Daugumoje programų mes negalime tai žinoti visuose įėjimuose, todėl sutinkame, kad kodas yra gerai išbandytas . Tai labiau atpažįstama, tačiau vis dar yra subjektyvus standartas: visada bus galima aptarti, ar su juo susitiko. Šios diskusijos yra naudingos ir turi atsirasti, tačiau jos taip pat kelia netikrumą.

Kodo aprėptis yra objektyvus aspektas. Kai pamatysite savo aprėpties ataskaitą, nėra dviprasmiškumo, ar standartai buvo įvykdyti. Ar tai tiesa? Visai ne, bet jis turi aiškų ryšį su kodo išbandymu, kuris, savo ruožtu, yra geriausias būdas padidinti pasitikėjimą jo teisingumu. Kodo aprėptis yra išmatuojamas neapibrėžtinų savybių, apie kurias mes rūpinamės, apytikslis.

Kai kurie konkretūs atvejai, kai empirinis standartas gali pridėti vertę:

  • Patenkinti suinteresuotąsias šalis. . Daugeliui projektų yra įvairių dalyvių, kurie domisi programinės įrangos kokybe, kurie negali dalyvauti kasdieniniame programinės įrangos kūrime (vadovai, techniniai vadovai ir kt.). Sakydami: „mes ketiname rašyti visus testus, kuriuos mums tikrai reikia“, nėra įtikinami: jie turi būti visiškai pasitikėti arba tikrinami nuolat atidžiai stebint (su sąlyga, kad jie netgi turi techninį supratimą apie tai). Išsiaiškinti išmatuojamus standartus ir paaiškinti, kaip jie priartina realistiškus tikslus.
  • Normalizuoti komandos elgesį. Suinteresuotosios šalys, jei dirbate komandoje, kurioje keli žmonės rašo kodą ir testus, yra daugybė dviprasmiškumo, kas laikoma „patikrinta“. Ar visi jūsų kolegos turi tą pačią idėją, kokio lygio testavimas yra pakankamai geras? Galbūt ne. Kaip ją suderinti? Raskite metriką, su kuria jūs visi sutinkate, ir sutinku, kad tai yra pagrįstas apytikslis. Tai ypač (bet ne išimtinai) naudinga didelėms komandoms, kuriose vadovai, pavyzdžiui, negali tiesiogiai kontroliuoti jaunesnių kūrėjų. Pasitikėjimo tinklai, bet be objektyvių matavimų, lengvai tampa nesuderinami su grupės elgesiu, net jei visi elgiasi sąžiningai.
  • Būti sąžiningai. Net jei esate vienintelis jūsų projekto kūrėjas ir tik suinteresuota šalis, galite turėti tam tikrų programinės įrangos savybių. Vietoj subjektyvaus įvertinimo, kaip gerai išbandoma programinė įranga (kuri reikalauja darbo), galite naudoti kodo aprėptį kaip pagrįstą apytikslį ir leisti mašinoms ją įvertinti.

Kokie rodikliai naudojami

Kodo aprėptis nėra viena metrika; Yra keli skirtingi aprėpties matavimo būdai. Kurį, kurį galite nustatyti, priklauso nuo to, ką naudojate šiam standartui.

Kaip pavyzdžius galiu naudoti du bendrus rodiklius, kai galite juos naudoti norėdami nustatyti standartus:

  • Operatoriaus pareiškimas . Kokia procentinė paraiškų dalis buvo baigta testavimo metu? Naudinga žinoti apie jūsų kodo fizinį pasiekimą : kiek kodo aš parašiau, kad aš iš tikrųjų išbandžiau?
    • Toks aprėptis palaiko silpnesnį teisingumo argumentą, tačiau taip pat lengviau jį pasiekti. Jei paprasčiausiai naudosite kodo aprėptį, kad įsitikintumėte, jog kažkas yra išbandoma (o ne kaip bandymo, kuris viršija tai, kokybė), tuomet galbūt operatoriaus pasiekiamumas yra pakankamas.
  • Atsparus atspindys . Jei yra šakotosios logikos (pvz., if ), ar buvo įvertintos šios šakos? Tai geriau supranta jūsų kodo loginį pasiekimą : Kiek iš galimų kelio, kurį mano kodas gali atlikti, išbandžiau?
    • Tokio tipo aprėptis yra daug geresnis rodiklis, kad programa buvo išbandyta kaip išsamios įvesties rinkinio dalis. Jei naudojate kodo aprėptį kaip geriausią empirinį aproksimavimą, kad būtų užtikrintas teisingumas, turite nustatyti standartus, pagrįstus filialų aprėpimu ar panašiais.

Yra daug kitų rodiklių (linijos aprėptis yra panaši į operatoriaus aprėptį, tačiau daugialypių operatorių atveju gaunami skirtingi skaitiniai rezultatai, pavyzdžiui: sąlyginė aprėptis ir maršrutų aprėptis yra panašios į filialų aprėptį, tačiau atspindi išsamesnę galimų programų vykdymo pertvarkymų apžvalgą.)

Kiek procentų reikia

Galiausiai, grįžkite prie pradinio klausimo: jei nustatysite kodų aprėpties standartus, kas tai turėtų būti?

Tikiuosi, kad šiuo metu aišku, kad kalbame apie artėjimą prie pradžios, todėl bet koks mūsų pasirinktas skaičius bus apytiksliai esantis.

Kai kuriuose kambariuose galite pasirinkti:

  • 100% . Galite tai pasirinkti, nes norite įsitikinti, kad viskas yra išbandyta. Tai nesuteikia jums jokios idėjos apie testo kokybę, bet pasakoja, kad kai kurie kokybės bandymai palietė kiekvieną taikomąją programą (ar šaką ir pan.). Vėlgi, tai grįžta į pasitikėjimo lygį: jei jūsų aprėptis yra mažesnė nei 100%, žinote, kad kai kurie jūsų kodo pogrupiai nebuvo išbandyti.
    • Kai kurie gali teigti, kad tai kvaila, ir turėtumėte patikrinti tik tas jūsų kodo dalis, kurios yra tikrai svarbios. Sakyčiau, kad jūs taip pat turėtumėte remti tik tas jūsų kodekso dalis, kurios yra tikrai svarbios. Kodo aprėptis taip pat gali būti patobulinta ištrinant išbandytą kodą.
  • 99% (arba 95%, kiti skaičiai devintajame dešimtmetyje). Tais atvejais, kai norite perteikti 100 proc. Analogišką pasitikėjimo lygį, bet išlaikyti tam tikrą rezervą sau, kad nesijaudintumėte dėl atsitiktinio kodo kampo, kurį sunku pasiekti bandymams.
  • 80% . Šį skaičių matiau kelis kartus, ir aš nežinau, iš kur jis kilęs. Manau, kad tai gali būti keista 80-20 taisyklė; Paprastai tikslas yra parodyti, kad dauguma jūsų kodo yra patikrinta. (Taip, 51% taip pat bus „dauguma“, bet 80% daugiau atspindi tai, ką dauguma žmonių reiškia labiausiai). Tai tinka tais atvejais, kai vidutinis atvejis, kai „išbandytas“ nėra aukštas prioritetas (jūs nežinote, jie nenori išleisti išlaidų bandymams su mažomis sąnaudomis), tačiau tai yra pakankamai prioritetas, kurį norėtumėte turėti kai kuriems standartams.

Aš nematau mažiau nei 80% praktikoje ir vargu ar galiu įsivaizduoti atvejį, kai jie galėtų būti įdiegti. Šių standartų vaidmuo - didinti pasitikėjimą teisingumu, o skaičiai, mažesni nei 80%, ypač neskatina pasitikėjimo. (Taip, tai yra subjektyvi, bet vėlgi, norėdami nustatyti standartą, ateityje norėtumėte atlikti subjektyvų pasirinkimą ir tada naudoti objektyvų matavimą.)

Kitos pastabos

Pirmiau pateikta prielaida, kad tikslas yra teisingumas. Kodas apima tik informaciją; tai gali būti susiję su kitais tikslais. Pvz., Jei esate susirūpinęs dėl techninės priežiūros, jūs tikriausiai rūpinatės laisvu sukabinimu, kurį galima įrodyti bandomumu, kuris, savo ruožtu, gali būti matuojamas (tam tikruose modeliuose) su kodo aprėptimi. Taigi, jūsų kodo aprėpties standartas suteikia empirinį pagrindą, kaip suderinti „priežiūros“ kokybę.

16
09 янв. atsakymas pateikiamas killscreen 09 Jan 2016-01-09 23:44 '16 at 11:44 pm 2016-01-09 23:44

Turėčiau dar vieną pokštą apie bandymų aprėptį, kurią norėčiau pasidalinti.

Turime didžiulį projektą, kuriame, per „Twitter“, pažymėjau, kad su 700 vienetų testais turime tik 20% kodą .

Scottas Hanselmanas atsakė išmintingais žodžiais :

Ar tai 20% teisinga? Ar tai yra 20 proc. Galite pridėti dar 50 testų ir pridėti tik 2%.

Vėlgi, jis grįžta į mano Testivus kodo atsakymo atsakymą. Kiek ryžių turite įdėti į puodą? Tai priklauso nuo.

16
18 сент. Atsakymą pateikė Jon Limjap 18 sep . 2008-09-18 07:42 '08 at 7:42 2008-09-18 07:42

Jei tai būtų puikus pasaulis, 100 proc. Tačiau kadangi tai nėra puikus pasaulis, tai yra klausimas, ką turite. Todėl rekomenduoju mažiau dėmesio skirti tam tikram procentui ir daugiau dėmesio skirti kritinėms sritims. Jei jūsų kodas yra gerai parašytas (arba bent jau jo pagrįstas faksimilinis), turėtų būti keli pagrindiniai punktai, kai API gali būti veikiami kitu kodu.

Sutelkite savo bandymų pastangas į šias API. Įsitikinkite, kad API yra 1) gerai dokumentuotos ir 2) turi testavimo atvejus, kurie atitinka dokumentus. Jei laukiami rezultatai neatitinka dokumentų, turite kodą, dokumentaciją ar bandymų atvejus. Visi jie yra tinkami patikrinti.

Sėkmės!

7
18 сент. atsakymas pateikiamas 64BitBob 18 sep . 2008-09-18 07:30 '08, 7:30, 2008-09-18 07:30

85% būtų geras atspirties taškas tikrinimo kriterijams.

Priklausomai nuo išbandytų posistemių / komponentų kritiškumo, norėčiau pasirinkti daug aukštesnių strypų pristatymo kriterijams.

7
18 сент. Atsakymas duotas Stephbu 18 sep . 2008-09-18 07:27 '08, 07:27, 2008-09-18 07:27

Gerai suplanuotai sistemai, kai vieneto testai nuo pat pradžių paskatino vystymąsi, sakyčiau, kad 85% yra gana mažas skaičius. Mažos klasės, skirtos bandymams, neturėtų būti sudėtingesnės.

Tai lengva pašalinti šį klausimą iš kažko panašaus:

  • Dengtos linijos nėra lygios įrodyta logika, ir jūs neturėtumėte skaityti per daug procentais.

Tiesa, bet yra keletas svarbių punktų, susijusių su kodo aprėpimu. Mano patirtis rodo, kad ši metrika yra labai naudinga, kai naudojama teisingai. Tai pasakius, nematau visų sistemų, ir esu tikras, kad yra daug jų, kur sunku matyti kodo aprėpties analizę, pridėjus bet kokią realią vertę. Kodas gali būti toks skirtingas, o turimos bandymų sistemos apimtis gali skirtis.

Be to, mano argumentai daugiausia susiję su gana trumpais grįžtamojo ryšio ciklais. Produktui, kurį vystau, trumpiausias grįžtamasis ryšys yra gana lankstus, apimantis viską nuo klasės testų iki signalų perdavimo tarp procesų. Tikrinant pateiktą šalutinį produktą paprastai trunka 5 minutes, o tokiam trumpam grįžtamojo ryšio ciklo metu galite iš tikrųjų naudoti bandymo rezultatus (ir ypač kodo apimtį, kurią mes čia žiūrime), kad atmestume ar priimtume įvykį saugykloje.

Naudojant kodo aprėpties indikatorių, turėtumėte ne tik turėti fiksuotą (savavališką) procentą, kurį reikia atlikti. . Tai, mano nuomone, nesuteikia jums realios kodo aprėpties analizės naudos. Вместо этого определите следующие показатели:

  • Знак низкой воды (LWM), наименьшее количество незакрытых линий, которые когда-либо видели в тестируемой системе.
  • High Water Mark (HWM), самый высокий процент покрытия кода, который когда-либо видел для тестируемой системы.

Новый код можно добавить, только если мы не перейдем к LWM, и мы не опускаемся ниже HWM. Другими словами, покрытие кода не разрешено уменьшать , а новый код должен быть покрыт. Обратите внимание, как я говорю, должен и не должен (объясняется ниже).