Se ei ole sinä; Suuri osa laadunvarmistuksesta on vikojen lokalisointia

Suuri osa laadunvarmistuksesta on vikojen lokalisointi.

Toki testisuunnittelutekniikat auttavat meitä valitsemaan testiskenaarioita ja tehostamaan asioita. Mutta mitä vian lokalisointi tarkalleen ottaen on , ja miten voimme tehdä siitä vähemmän tuskallisen?

Aloitetaan perusasioista

Lokalisointi on kuin leikkiä etsivää: "Missä ja milloin asiat menivät pieleen?" Ilman asianmukaista lokalisointia viasta voi tulla kuuma peruna, joka heitetään käyttöliittymän, taustajärjestelmän ja minkä tahansa kehitystiimin välillä. Aikaa menee hukkaan, ja mahdollisesti jopa kontekstia.

Ajattele vikojen lokalisointia labyrintissa navigoimisena, ja sovelluspyynnöt ja lokit ovat lankakertojasi. Mutta eikö olisi helpompaa saada kartta tästä labyrintista, jopa luonnos, sen sijaan, että vain kompastelisit langan kanssa? Siinä sovelluksen arkkitehtuuri tulee esiin.

Mikä on sovellusarkkitehtuuri?

Näin järjestelmän eri osat toimivat yhdessä. Labyrinttimetaforamme kannalta se on, kuinka yksi osa liittyy toiseen, mitkä käytävät mihin johtavat.

Erotan kaksi pääarkkitehtuuria: asiakas-palvelin ja taustajärjestelmä.

• Asiakas-palvelin-arkkitehtuuri näyttää meille, kuinka asiakas ja palvelin ovat vuorovaikutuksessa.
• Taustaarkkitehtuuri määrittää, kuinka taustaosa käsittelee asiakaspyyntöjä.

Muutama sana asiakas-palvelin-arkkitehtuurista

Yleensä on kahta tyyppiä:

• Ohut asiakas
• Paksu asiakas

Tyyppi vaikuttaa siihen, kuinka paljon tietoa asiakas säilyttää ja käsittelee itse. On muitakin tapoja määrittää tämä, mutta pysyn siinä, minkä kanssa olen itse työskennellyt.

Useimmat mobiili- ja verkkosovellukset ovat ohuita asiakkaita. Kaikki tiedot tallennetaan palvelimelle ja asiakassovellus pyytää tietoja tai pyytää niiden käsittelyä. Rekisteröityminen, kirjautuminen, ilmoitusten tilaaminen – kaikki nämä ovat puheluita palvelimelle. Koko palvelimen käsittely on piilotettu asiakkaalta. Vastauksena pyyntöön asiakas saa tietokannasta kerätyt ja käsitellyt tiedot tai vahvistuksen pyynnön onnistumisesta.

Paksuissa asiakassovelluksissa asiakas suorittaa suurimman osan käsittelystä itse: lisää dataa tietokantaan, tuottaa raportteja, laskee summia ja luo asiakirjoja. Ne asennetaan usein paikallisesti, mutta ei aina. Esimerkkejä paksuista asiakkaista ovat offline-pelit, AutoCAD ja jotkin 1C-versiot.

Nyt tutkitaan taustaarkkitehtuuria

Kaksi yleistä lähestymistapaa ovat:

• Monoliittinen
• Mikropalvelut

Kun melkein kaikki käsitellään yhdessä paikassa, se on monoliitti.

Jos käsittelypyyntöjä lähetetään muille järjestelmän palveluille, kyseessä on todennäköisesti mikropalveluarkkitehtuuri.

Monoliittisessa arkkitehtuurissa vian lähteen paikantaminen voi olla hankalaa, koska eri tiimit ja palvelut jakavat tyypillisesti saman koodikannan, mikä tarkoittaa, että muutoksilla voi olla odottamattomia seurauksia.

Toisessa tapauksessa palvelut erotetaan toisistaan, jokaisella on oma koodikantansa, eli yhden palvelun muutoksilla on vain vähän vaikutusta muihin.

Organisaatiorakenne ja vastuualueet

Otsikko kuulostaa pelottavalta, mutta se kertoo vain kuka tekee mitä ja kuka on vastuussa mistäkin labyrintin osasta (sovelluksesta). Kuvittele, että meillä on iso yritys: pankki, markkinapaikka, ruuan toimituspalvelu – voit nimetä sen. Mitä suurempi ja monimutkaisempi sovelluksemme, sitä enemmän ihmiset työskentelevät sen parissa. Ja mitä enemmän ihmisiä on, sitä enemmän heidät on jaettava ryhmiin, joista jokainen vastaa omasta kehitysalueestaan.

Esimerkiksi yksi tiimi voi käsitellä ylennyksiä, kun taas toinen on vastuussa maksuista. Jos sovelluksemme tarjoaa erilaisia palveluita, tiimit saattavat olla vastuussa yksittäisistä palveluista, kuten sähköisestä dokumentinhallinnasta, kirjanpidosta tai julkisista hankinnoista.

Sinun ei tarvitse tietää kaikkea ja kaikkia, mutta jos on dokumentaatiota, joka kertoo, mikä tiimi mistäkin alueesta vastaa, on parasta pitää se kirjanmerkkeinä.

Laittamalla kaikki yhteen

Kartta kädessä, lanka valmiina, kaivellaan labyrintiimme ja etsitään vian lähdettä. Kuvitellaanpa muutamia skenaarioita.

Skenaario 1

Kuvaa tämä: Testaamme keskusteluklubin verkkosivustoa.

Selaamme tuntiaikataulua, luemme tulevista istunnoista, kun jossain vaiheessa huomaamme kirjoitusvirheen.

Miten voimme nyt selvittää, mistä se sai alkunsa? Anna seikkailu alkaa!

Avaamme devToolsin, päivitämme sivun ja tarkastelemme pyyntöjä ja vastauksia. Koska meillä on ohut asiakas, löydämme kirjoitusvirheemme yhdestä vastauksesta – se tuli taustajärjestelmästä.

Nyt avaamme lokit ja etsimme taustajärjestelmän pyynnön tai vastauksen käsittelyä – tämä on lankamme taikapallosta. Voimme etsiä lokeja käyttämällä mitä tahansa pyynnön ja vastauksen tietoja, mutta on parempi käyttää yksilöllisiä arvoja: request xiid, pyynnön tunnus, puhelinnumero ja niin edelleen.

Etsimme merkinnän ja tarkistamme: saimmeko luokkatiedot tietokannasta vai toisesta palvelusta?

Jos tiedot ovat peräisin tietokannasta, voimme välittää ongelman tekniselle tuelle tietokannan kirjoitusvirheen korjaamiseksi.

Jos tieto tuli toisesta palvelusta, voimme välittää vian heille.

Onnittelut! Olemme valloittaneet ensimmäisen labyrinttimme: vika paikallistetaan ja siitä ilmoitetaan.

Skenaario 2

Nyt kuva testaamme rekisteröintilomaketta.

Annamme sähköpostiosoitteen, joitain tietoja ja keksityn salasanan. Napsautamme rekisteröintipainiketta ja saamme odottamatta virheilmoituksen.

On aika avata maaginen pallomme! Siirrymme rakastettuun Verkko-välilehteen devToolsissa ja katsomme, mikä meni pieleen: toistamme kaikki vaiheet ja tarkistamme palvelimen vastauksen.

Vastauksena pyyntöön saamme 400-koodin, jossa on tyhjä vastausteksti. Pitäisikö meidän juosta pois ja tehdä vikailmoitus käyttöliittymää vastaan? Mutta emme vieläkään tiedä, mikä meni pieleen ja mikä on korjattava. Usein tapahtuu 400-virhe, kun asiakkaan lähettämän ja palvelimen odotuksen välillä on ristiriita. Tähän voi olla monia syitä, mukaan lukien:

• Vanhentunut dokumentaatio tehtävässä
• Muutokset tehty ilman asiakirjoja
• Kirjoitusvirheet

Tarkastetaan asiakkaan pyyntö

Jos meillä on manuaalisesti kirjoitettua tai Swaggerissa tai OpenAPI:ssä luotua dokumentaatiota, varmistamme sen avulla, että:

• Lähetämme kaikki tarvittavat parametrit
• Parametriarvoilla on oikeat tietotyypit (esim. numeeriset arvot int-parametreille)

Miten muuten voimme tarkistaa pyynnön?

Vaikka meillä ei olisi asiakirjoja, voimme varmistaa:

• Syntaksin noudattaminen (esim. jos pyyntö lähetetään JSON-muodossa, sen tulee noudattaa JSON-syntaksia)
• Kirjoitusvirheet parametrien nimissä (esim. "mony" eikä "money", "doby" eikä "body")
• Kyrilliset merkit latinalaisten kirjainten joukossa (esim. "nimi" kirjoitettu kyrillisellä "e"-kirjaimella)

Onko kaikki kunnossa? Sitten on aika jatkaa matkaamme labyrintin läpi löytääksemme vastauksen. Otamme karttamme ja "laskumme" lokeihin.

Lokianalyysi

Tässä on kaksi mahdollista skenaariota:

• Virhe kirjataan lokiin pyynnön käsittelyn aikana
• Virheitä ei kirjata, mutta pyynnöt kirjataan

Jälkimmäisessä tapauksessa meidän on jatkettava matkaamme mikropalvelulabyrintin läpi ja etsittävä paikka, jossa pyyntömme käsiteltiin.

Kun löydämme virhelokin, tiedämme, mikä meni pieleen, mikä tarkoittaa, että lokalisointimme ja matkamme on valmis! Jäljelle jää vain kerätä seuraavat tiedot vikailmoitusta varten:

• Taustapyyntö
• Virheloki
• Suositeltu korjaus

Johtopäätös

Vian paikantaminen voi olla haastavaa. Joskus törmäät seinään: seuraamasi loki ei johda virheeseen tai tekee asioista hämmentävää. Tällaisissa tilanteissa otan yleensä pari askelta taaksepäin tai aloitan alusta.

Labyrintin tutkiminen voi viedä paljon aikaa. Matka voi olla vaikea ja täynnä vaaroja: joidenkin pyyntöjen käsittely voi olla mutkikasta ja lähettää pyyntöjä useille eri palveluille. Joskus on järkevää yksinkertaistaa tehtävää ja ottaa yhteyttä labyrintin arkkitehtiin – kehittäjiin.