Voitot:
- Kyky lukea mittareita, kuten linja-, haara- ja kuntokattavuus karttana, ei luottamuslauseena, ja ymmärtää, että korkea kattavuus voi antaa näennäisluottamusta
- Kyky asettaa vaatimusalue koodin laajuuden viereen ja tehdä jäljitettävyysaukot näkyväksi tekoälyn avulla
- Kyky pisteyttää ominaisuuksia kaavalla riski = todennäköisyys × vaikutus, ohjata rajoitettu testausponnistelu suurimmalle riskille ja dokumentoida tarkoituksellinen soveltamisalan ulkopuolinen toiminta
Et voi testata kaikkia ohjelmistoja ikuisesti; Aika ja resurssit ovat rajalliset. Todellinen kysymys on siis: mihin rajalliset testausponnistelut laitetaan? Kaksi käsitettä vastaa tähän kysymykseen. Testin kattavuus – mittari, joka mittaa, kuinka paljon koodia tai vaatimuksia testit koskettavat – edustaa testattavaa. Riskipohjainen testaus - lähestymistapa, jossa määritetään testien prioriteetti alueen huononemisen todennäköisyyden ja sen huonontuessaan aiheuttaman vahingon mukaan - suuntaa ponnistelut suurimmalle riskille. Tekoäly (AI) on tehokas analyysikumppani molemmissa: se näyttää kattavuusaukot, ehdottaa riskialueita. Mutta keskeinen varoitus säilyy: tekoälyn näkemien kiikarien määrä voi olla harhaanjohtavaa; Jopa 100 % rivipeitto voidaan saavuttaa testeillä, jotka eivät vahvista mitään. Sinun tehtäväsi on lukea laajuus karttaa, ei luottamusta.
Kattavuuslukujen lukeminen oikein
Laajuustyyppejä on useita, eivätkä kaikki ole yhtä merkityksellisiä:
- Rivin peitto: kuinka monta koodiriviä suoritettiin vähintään kerran. Yleisin mutta heikoin kriteeri; Se, että linja toimii, ei ole todiste siitä, että se toimii oikein.
- Haarojen kattavuus: onko jokainen jos haara (sekä tosi että epätosi) testattu. Merkittävämpää kuin rivi.
- Kunnon kattavuus: Testataan jokainen osaehto monimutkaisissa olosuhteissa erikseen.
- Polun kattavuus: loogisten polkujen yhdistelmät koodin sisällä. Se on kattavin, mutta käytännössä vaikeasti saavutettavissa.
Varoitus: Kattavuusprosentti ei ole "laatupiste". 100 % rivipeitto kertoo, että rivit toimivat; ei sillä, että se tuottaa oikean tuloksen (pseudo-pass yksikössä 1). Käytä laajuutta vastauksena kysymykseen "mistä en ole koskaan katsonut", ei vakuutuksena siitä, että "kaikki on testattu".
Tarkkaile kuolleita kulmia
Kattavuusmittarit mittaavat vain, kuinka suuri osa koodista on suoritettu; ei näe: (1) testaamattomia vaatimuksia (koodi on olemassa, mutta liiketoimintasääntö on väärä), (2) koodi puuttuu (ei mahdollisuuksia ohjaukselle, jota ei koskaan kirjoitettu), (3) data/tila-yhdistelmät, (4) käytettävyys, suorituskyky, turvallisuus. Siksi vaatimuskattavuus (jokainen hyväksymiskriteeri on täytettävä vähintään yhdellä testillä) tulisi sijoittaa koodin kattavuuden viereen. Tekoäly on erittäin hyödyllinen vaatimustestikartoituksen (jäljitettävyysmatriisin) tuottamisessa.
Riskipohjainen testaus: mihin panostamme?
Riski = todennäköisyys (rikkoutumismahdollisuus) × vaikutus (vaurio, jos se rikkoutuu). Tekoälyn avulla voit pisteyttää ominaisuusluettelon näille kahdelle akselille ja luoda lämpökartan. Suuri todennäköisyys × korkeat verkkotunnukset (maksu, todennus, tietojen eheys) ansaitsevat intensiivisimmän testauksen; matala × matala alue (harvoin käytetty valintanäyttö) valotestaus riittää.
alueella
todennäköisyys
Vaikutus
Riski
Testitiheys
Maksukulku
keskikokoinen
erittäin korkea
korkea
Syvä + automaatio
todennus
keskikokoinen
erittäin korkea
korkea
Syvä + turvallisuus
Tuotehaku
korkea
keskikokoinen
Keskikorkea
Automaatio + löytö
Profiilikuva
alhainen
alhainen
alhainen
valon ohjaus
Ohje-sivu
alhainen
liian matala
liian matala
arvostelu
Kiikaritähtäimen jahtaamisen ansa
Kattavuusprosentin asettamisella tavoitteeksi (esim. "joukkueen on läpäistävä 90 %:n kattavuus") on vaarallinen sivuvaikutus: kehittäjät ja testaajat keskittyvät prosenttiosuuden kasvattamiseen todellisen riskin puuttumisen sijaan. Tuloksena on usein paisunut kaukoputki ilman väitteitä tai triviaaleja testejä – numero näyttää hyvältä, mutta suojaa ei ole. Tämä on ilmiö, jossa kriteeri korruptoituu, kun siitä itsestään tulee tavoite: "kun mitta tulee tavoitteeksi, se lakkaa olemasta hyvä mitta". Käytä laajuutta diagnostiikkatyökaluna, ei suorituskykyraporttikorttina.
Terveellisempi lähestymistapa on lukea laajuus suuntaavasti: "Miksi sivukonttorin kattavuus on juuttunut 40 %:iin kriittisessä maksumoduulissa?" Kysymys kuuluu "onko kokonaiskattavuus 90%?" Se on paljon arvokkaampi kuin kysymys. Pyydä tekoälyä erittelemään laajuusraportti moduulien ja riskitason mukaan; Korosta korkean riskin alueita alhaisella peitolla. Siten soveltamisalasta tulee kompassi, joka ohjaa työtä eikä sokea prosentti.
Varoitus: Slogan "100% kattavuus" on ansa. Joidenkin koodien (yksinkertaiset lisälaitteet, automaattisesti luodut osat) testaus on vähäistä; siellä käytetty ponnistus varastetaan riskialttiiden yritysten säännöistä. Tavoitteena on testata jokaista tärkeää käyttäytymistä ja riskiä, ei jokaista riviä.
Heikko kehote / Vahva kehote
Heikko: "Lisää testauksen kattavuutta."
Vahva: "Kun otetaan huomioon tämä hyväksymiskriteeriluettelo ja nämä olemassa olevat testitapaukset. (1) Taulukko, mitkä hyväksymiskriteerit eivät ole täyttyneet mitkään testit (vaatimusten kattavuusaukko). (2) Anna kullekin ominaisuudelle pisteet 1-5 todennäköisyys- ja vaikutusakselilla; sijoitus riskin mukaan = todennäköisyys × vaikutus. (3) Ehdota rajoitetulla aikavälilläni, mitkä 5 aloitusarvoa, joten en ottaisi suurimman riskin rivillä. kriteeri priorisoi liiketoimintariski. Kriteerit: [...] Testit: [...]"
Tehokas kehote; yhdistää laajuuden liiketoimintariskiin ja priorisoi rajoitetun työvoiman.
Neljä kopioitavaa mallia
1) Vaatimusalueen aukko:
Ottaen huomioon seuraavat hyväksymiskriteerit ja nämä testitapaukset. Tuota jäljitettävyystaulukko: jokainen kriteeri -> sen täyttävä testi(t). Kriteereitä, joilla ei ole testejä, kutsutaan "KATTAVAIKKO" ja testejä, jotka eivät liity mihinkään kriteeriin, kutsutaan "TARVITTAESSA?" Arvosana: Kriteerit: [...] / Testit: [...]
2) Riskipisteet:
Arvostele tämä ominaisuuksien/moduulien luettelo 1-5 todennäköisyyden (rikkomisen todennäköisyys) ja törmäyksen (vaurio, jos rikkoutuessa) akseleilla. Riski = todennäköisyys × vaikutus. Lajittele taulukkoon ja määritä suositeltu testaustyyppi (yksikkö/API/UI/tiedustelu/turvallisuus) jokaiselle korkean riskin alueelle. Lista: [...]
3) Soveltamisalan tulkinta:
Seuraava kattavuusraportti annettiin (rivi %, haara %). Kerro minulle tämä:- Mitä nämä luvut EIVÄT todista?- Mitkä ovat alueet, jotka voivat olla vaarassa korkeasta rivipeitosta huolimatta?- Mitä lisätestausta suosittelisit aukkoihin, joita kattavuus ei näe (vaatimus, tietoyhdistelmä, suojaus)?Raportti: [liitä]
4) Rajoitettu aikasuunnitelma:
[X tuntia] lähetykseen jäljellä. Seuraavassa on annettu riskiluokitus ja kattavuusaukot. Tänä aikana laaditaan tärkeysjärjestyksessä testaussuunnitelma, joka pienentää maksimiriskiä. Ilmoita selkeästi, mitä EI tietoisesti testata, ja hyväksytyt riskit. Tiedot: [...]
kolme minilaukkua
Tapaus 1 – 100 % kattavuus, nolla luottamusta. Yksi joukkue ylpeili 94 prosentin linjapeitolla. "Scope interpretation" -analyysi osoitti, että suurin osa testeistä oli väittämättömiä, mikä tarkoittaa, että ne suorittivat linjoja, mutta eivät vahvistaneet mitään. Todellinen suojakatto oli paljon pienempi. Ryhmä ei keskittynyt lukuihin vaan mutaatiotestaukseen (yksikkö 10); todellinen virhesaannin määrä kaksinkertaistui.
Tapaus 2 – Riskikartalla korjattu prioriteetti. Yksi tiimi käytti 40 % testaustyöstään harvoin käytetyssä raportointinäytössä, ohittaen maksuvirran, koska se "vain toimii". Tekoälyn riskipisteytys osoitti tämän epätasapainon. Työvoimaa jaettiin uudelleen; Kaksi viikkoa myöhemmin maksuvirrasta löydettiin erittäin vaikuttava bugi, joka suljettiin ennen käyttöä.
Tapaus 3 – Tietoinen soveltamisalan ulkopuolella. Neljä tuntia julkaisun jälkeen tiimi päätti, mitä testata ja mitä tietoisesti ohittaa "rajoitetun aikataulun" -mallin avulla. Kaksi korkean riskin puroa testattiin syvällä; matalan riskin mieltymysnäyttö dokumentoitiin "hyväksytyksi riskiksi" ja ohitettiin. Päätös oli avoin ja perusteltu; Versio ilmestyi turvallisesti.
Yleisiä virheitä
- Peittoprosentti erehtyy laatuun. Korkean rivikattavuuden lukeminen "testatuksi" varmistukseksi.
- Katson vain koodin kattavuutta. Vaatimusten kattavuuden ohittaminen (kunkin hyväksymiskriteerin testaus).
- Testaa yhtä riskiä ottamatta. Työvoiman kohdentaminen vähäriskisille alueille ja kriittisten virtojen laiminlyönti.
- Piilostuminen soveltamisalan ulkopuolelle. Ei dokumentoi sitä, mitä ei testattu, kun aikaa ei ollut tarpeeksi; Julkaisun jälkeisiä yllätyksiä.
- Tekoälyn riskipisteiden hyväksyminen ilman kysymystä. AI ei täysin tunne tuotteen kontekstia; Säädä pisteitä asiantuntevalla silmällä.
Yhteenvetona
Testin kattavuus ja riskiperusteinen testaus ovat kaksi työkalua ohjata rajoitettu vaiva oikeaan paikkaan. Kattavuusmittarit (viiva, haara, kunto, polku) näyttävät, mitä kosketettiin, mutta eivät todista, että se toimi oikein. Laajuus on kartta, luottamus ei. Aseta vaatimusten kattavuus koodin kattavuuden viereen. Pistele ominaisuudet kaavalla riski = todennäköisyys × vaikutus ja suuntaa ponnistelu suurimmalle riskille. Tekoäly tekee aukot näkyviksi, tekee riskejä, suunnittelee rajoitetun ajan; mutta lopullisen prioriteetin ja "tietoisen opt-out" -päätöksen tekee asiantuntija, joka tuntee liiketoimintakontekstin.
Sovellustehtävä
Valitse moduuli omasta projektistasi. Suorita "vaatimusten laajuuden aukko" -malli tekoälyllä ja selvitä, mitä hyväksymiskriteerejä ei testata. Järjestä sitten moduulin aliominaisuudet todennäköisyys × vaikutusakselilla "riskipisteytyksen" avulla. Jaa (hypoteettinen) 3 tunnin testausaika, joka sinulla on "rajoitetun aikataulun" mukaisesti; Kirjoita ylös, mitä et tietoisesti testaa ja hyväksytyt riskit. Lisää konkreettinen testi, joka sulkee löytämäsi suurimman riskin kattavuusraon.
tarkistuslista
- [ ] Luen peittoprosentin karttana, en laatuna.
- [ ] Koodipeitton lisäksi poistin myös vaatimuskaton.
- [ ] Arvostin piirteet todennäköisyys × vaikutus ja asetin ne riskin mukaan.
- [ ] Suuntasin testaustyön suurimmalle riskille.
- [ ] Olen dokumentoinut alueita, joita ei ole tietoisesti testattu ja tunnustanut riskin.
- [ ] Tarkistin tekoälyn riskipisteet tuotekontekstini perusteella.