10 vinkkiä parempaan testaukseen

Verkkokehitys on nyt monimutkaisempaa kuin muutama vuosi sitten. Verkkosuunnittelutyökalut , selaimen ominaisuudet, käyttöliittymän kehykset ja parhaat käytännöt muuttuvat melkein kuukausittain, ja päivitettävää on aina. Ja tähän liittyy riski. Kuinka voimme olla varmoja, ettei näillä muutoksilla ole tahattomia sivuvaikutuksia?

Testauksessa on kyse riskien lieventämisestä. Jos käyttäjällä on vaikeuksia käyttää sivustoa, hän ei todennäköisesti palaa takaisin ja hyppää todennäköisemmin kilpailijan luokse. Tarkistamalla kaikki päätökset, jotka tehdään sivuston kehittämisen yhteydessä, se vähentää mahdollisuutta, että käyttäjillä on pienempi kokemus (loistava sivujen ylläpito auttaa sinua analysoimaan sivustosi ongelmia).

kuinka maalata kuin mestarit

On selvää, että on enemmän käyttäjän testaus kuin vain varmistaa, että kooditietokannassa ei ole virheitä. Suunnitteluprosessin läpikäynnin testaamiseksi on olemassa vaiheita, joilla voidaan varmistaa, että kaikkea luotua ohjaa käyttäjän todellinen tarve.



Haluatko tehdä verkkosivuston ilman vaivaa? Kokeile a verkkosivujen rakentaja .

01. Kirjoita paljon yksikkötestejä

kolmio jaettuna päästä päähän, integraatioon ja yksikköön

Pidä useita yksikötestejä, mutta vähemmän integrointi- ja end-to-end-testejä tasapainon löytämiseksi nopeuden ja tehokkuuden välillä

Rakentamaton koodi on virheen edeltäjä ja aihe jatkuu tiellä. Sen lisäksi, että se on vaikea ymmärtää ja mahdoton päivittää, se myös vaikeuttaa testaamista. Kun niin monta kappaletta luottaa suoraan toisiinsa, testien on suoritettava kaikki koodi kerralla. Tämän vuoksi on vaikea nähdä, mikä ei toimi, kun aika tulee.

Kukin hakemuksen osa tulisi jakaa omaan huolenpitoonsa. Esimerkiksi sisäänkirjautumislomake voi sisältää tyyliteltyjen syötteiden ja painikkeiden lisäksi tietokantakyselyjä, todennusta ja reititystä. Jokainen näistä on loistava ehdokas omalle luokalle, toiminnolle tai komponentille.

Kiinteän koodikannan perusta on hyvä joukko testejä. Näiden tulisi kattaa kaikki koodit ja olla nopeasti ajettavissa. Useimmilla yksikkötesteillä ja niiden kehyksillä on sama rakenne:

 describe('DateLocale', function() {   test('provides the day in the correct language', function() {     var date = new DateLocale('en');     date.setDate(new Date(1525132800000));     expect(date.getDay()).toBe('Tuesday');   }); }); 

'Kuvaa' -lohko tarkoittaa testattavaa koodikappaletta. Sen sisällä on joukko testejä, jotka asettavat skenaarion ja vertaavat odotettua tulosta todelliseen tulokseen. Jos ne eivät täsmää, testi epäonnistuu ja voimme tutkia asiaa tarkemmin.

Luomalla ja suorittamalla yksikkötestejä tiedostoja vaihdettaessa voimme olla varmoja siitä, että mikään ei ole vahingossa rikkonut kunkin koodinpätkän odotettua toiminnallisuutta. Nämä kappaleet voidaan pudottaa myös muihin projekteihin tarvittaessa. Koska sille on jo kirjoitettu testejä, voimme olla varmoja, että kyseisessä yksikössä ei ole alusta alkaen mitään ongelmia.

On paljon työkaluja, jotka auttavat kirjoittamaan yksikkötestejä, kuten On , Jasmiini ja AVA . Paras sopivuus riippuu kunkin projektin tarpeista, mahdollisista puitteista ja lopulta kehittäjien mieltymyksistä.

02. Käytä tarvittaessa testituplaa

sinon.js-käyttäjän testaus

Sinonilla on käyttövalmiit menetelmät yleisten selainohjelmointirajapintojen, kuten setInterval ja XMLHttpRequest, väärentämiseksi

Vaikka se saattaa tuntua haitalliselta, se voi olla helppo testata enemmän kuin alun perin oli tarkoitettu. Jos toiminto riippuu esimerkiksi ulkoisesta kirjastosta, kaikki kirjastosta tulevat virheet epäonnistuvat muissa testeissä, vaikka kirjoittamamme koodi olisi äänetön.

Ratkaisu tähän on lisätä paikkamerkkejä - tai 'testitupla' - tälle toiminnallisuudelle, jotka käyttäytyvät samalla tavalla, mutta antavat meille aina odotetun tuloksen. Kolme pääkokeen nelinpeliä ovat pilkka, tynkä ja vakooja.

Mock on luokka tai esine, joka vain pitää paikkansa todellisella. Niillä on sama käyttöliittymä, mutta ne eivät tarjoa mitään käytännön toimintoja.

Tynkä on samanlainen kuin pilkka, mutta se reagoi ennalta ohjelmoituun käyttäytymiseen. Näitä käytetään tarpeen mukaan sovelluksen tiettyjen osien simulointiin sen testaamisen aikana.

Vakooja keskittyy enemmän siihen, miten kyseisen käyttöliittymän menetelmiä kutsuttiin. Niitä käytetään usein tarkistamaan, milloin toiminto on käynnissä, kuinka monta kertaa se suoritettiin ja mitä argumentteja se toimitettiin. Tämä on niin, että tiedämme, että oikeita asioita hallitaan oikeaan aikaan.

Kirjastot, kuten Jos ei , Testin kaksinkertainen ja Nock tarjoavat upeita, valmiita testinäkymiä. Jotkut sviitit, kuten Jasmine, tarjoavat myös oman sisäänrakennetun tuplahuoneen.

kuinka tehdä kuvioita kuvittajaan

03. Tarkista, miten komponentit toimivat yhdessä

Kun koodi on jaettu erillisiin komponentteihin, meidän on testattava, voivatko ne toimia yhdessä. Jos todennuskerros ei ymmärrä esimerkiksi mitä tietokannasta palautetaan, kukaan ei voi kirjautua sisään. Näitä kutsutaan integraatiotesteiksi. He tarkistavat, miten osa sovelluksesta toimii toisen kanssa. Vaikka yksikötestit on tarkoituksella eristetty toisistaan, integraatiotestit kannustavat kommunikoimaan näiden kahden osapuolen välillä.

Kuten yksikötesteissä, integraatiotestin tavoitteena on tarkistaa lopputulos aiotulla tavalla. Sisäänkirjautumisesimerkissä se voi olla tarkistus siitä, onko 'viimeksi kirjautunut' aikaleima päivitetty tietokantaan.

Koska kerralla käsitellään enemmän, integraatiotestit ovat tyypillisesti hitaampia kuin yksikötestit. Sellaisena niitä pitäisi olla vähemmän ja heidän pitäisi juosta harvemmin. Ihannetapauksessa nämä suoritettaisiin vasta, kun ominaisuus on valmis, jotta mikään ei olisi muuttunut.

Samoja yksikkötesteissä käytettyjä ohjelmistosarjoja voidaan käyttää integrointitestien kirjoittamiseen, mutta niiden pitäisi pystyä suorittamaan erikseen, jotta asiat menevät nopeasti.

04. Seuraa kunkin käyttäjän polkua

Puppeteer-näyttö

Puppeteer voi hallita Chromen päätöntä versiota ikään kuin se olisi käyttäjä. Se voi luoda kuvakaappauksia ongelmien visualisoimiseksi

Automaattisen teknisen testauksen huipputaso tunnetaan nimellä 'end-to-end' tai 'toiminnallinen' testaus. Kuten nimistä voi päätellä, tämä taso kattaa kaikki toiminnot, jotka käyttäjä voi tehdä alusta loppuun. Ne simuloivat todellisia skenaarioita ja sitä, miten käyttäjä todennäköisesti toimii vuorovaikutuksessa lopputuotteen kanssa.

Näiden testien rakenne heijastaa usein kehitysprosessin aikana luotuja käyttäjäkertomuksia. Aiemman esimerkin jatkamiseksi voi olla testi, jolla varmistetaan, että käyttäjä voi syöttää käyttäjätunnuksensa ja salasanansa kirjautumislomakkeeseen.

Koska ne luottavat käyttöliittymän suorittamiseen, ne on päivitettävä käyttöliittymän muuttuessa. Pitkät latausajat voivat myös aiheuttaa ongelmia. Jos toimintoa ei voida suorittaa riittävän nopeasti, testi epäonnistuu, mikä johtaa vääriin positiivisiin tuloksiin.

Nämä testit suoritetaan myös hitaasti. Pullonkaula tulee yleensä selaimen ajamisesta, joka ei ole yhtä nopea kuin komentorivi, mutta on välttämätön oikean ympäristön jäljittelemiseksi. Sellaisena nämä suoritetaan harvemmin kuin integraatiotestit - yleensä ennen muutosten työntämistä tuotantoon.

Työkalut, kuten Seleeni ja Puppeteer voi auttaa end-to-end-testien kirjoittamisessa. Niiden avulla selaimia voidaan ohjata koodilla automatisoimaan muuten toistuva manuaalinen prosessi.

05. Aseta tulosbudjetit

Pingdom-näyttö

Pingdom voi myös auttaa seuraamaan käyttäjävirtoja koko vierailun ajan, mikä voi auttaa määrittelemään muutoksen onnistumisen

Nykyaikainen käyttöliittymäkehitys sisältää usein kimpun luomisen jokaiselle projektille, jossa on paljon raskasta omaisuutta. Näillä voi olla haitallinen vaikutus suorituskykyyn olematta varovainen.

Webpackissa on tapa seurata suorituskykyongelmia, kuten nippu ja omaisuuden koko. Säätämällä 'performance' -objektia webpack.config.js-tiedostossa se voi antaa varoituksia, kun tiedostot kasvavat liian suuriksi ja miten siihen voidaan parhaiten puuttua. Nämä voivat jopa heittää virheitä, jotka voivat estää rakennuksen onnistumisen varmistaakseen, ettei loppukäyttäjiin vaikuta kielteisesti.

On myös tärkeää testata useilla laitteilla, jotka ovat samanlaisia ​​kuin sivuston kävijät. Mobiilikäyttöinen lähestymistapa suunnitteluun ja kehitykseen varmistaa, että matalien laitteiden käyttäjät eivät jää odottamaan sivun renderointia.

Verkkosivutesti tarjoaa kattavan yleiskatsauksen verkkosivuston suorituskyvystä sekä vinkkejä sen parantamiseen. Live-palvelut, kuten Pingdom osaa seurata sivuston suorituskykyä reaaliaikaisten käyttäjien kanssa todellisen datan saamiseksi.

Varmista, että pidät yksityiskohtaiset muistiinpanot kaikista havainnoista, joihin tiimisi pääsee käsiksi pilvitallennus .

06. Kehitä esteettömyyttä varten

Matt crouch -verkkokehittäjän kuvakaappaus

kuinka tehdä paperinen kasvonaamio
Osana tarkastusprosessiaan Lighthouse testaa sivuston yleisiä esteettömyyskäytäntöjä ja korostaa, mitä parantaa

Jokaisen verkkosivuston tulisi olla kaikkien saatavilla. Vaikka esteettömyystestaus viittaa yleisesti vammaisiin, kokonaisuutena tehdyt muutokset hyödyttävät kaikkia luomalla helpommin lähestyttävän ja helposti navigoitavan sivuston.

On työkaluja, jotka voivat tunnistaa automaattisesti yleisimmät ongelmat, kuten huonot semanttiset merkinnät tai puuttuvan kuvien alt-tekstin. Majakka Esimerkiksi toimii Chrome-kehitystyökalujen sisällä ja antaa välitöntä palautetta analysoidun sivun esteettömyydestä.

Automaattiset työkalut eivät pysty havaitsemaan kaikkea - esimerkiksi kone ei voi tietää, onko kuvan vaihtoehtoinen teksti sopiva. Manuaalista testausta ei voida korvata eri vammaisten käyttäjien rinnalla. Laitteet perustetaan käyttäjän yksilöllisiin tarpeisiin, ja meidän on varmistettava, että ne otetaan huomioon.

07. Työskentele äärimmäisyyksiin

Reunatapaukset ovat yleinen aihe - erityisesti merkkijonojen pituus ja sisältö. Oletuksena pitkät sanat venyttävät säilöä ja aiheuttavat virtausongelmia sivulla. Mutta mitä tapahtuu, jos joku päättää käyttää merkkejä eri aakkosista tai käyttää emojia?

Asioista tulee pysyvämpi, kun näitä merkkijonoja tallennetaan tietokantaan. Pitkät merkkijonot voidaan katkaista ja koodausongelmat saattavat vääristää viestiä. Kaikkien testitietojen tulisi sisältää nämä tarkastukset.

Fuzz-testaus on automatisoitu tekniikka, joka pommittaa rajapintaa satunnaisella syötöllä stressitestin muodossa. Testin tarkoituksena on varmistaa, ettei odottamattomista - mutta mahdollisista - käyttäjän toimista aiheudu odottamattomia ongelmia.

Nämä ääripäät eivät rajoitu vain sisältöön. Hitaita yhteyksiä, matalan luokan laitteita ja pienempiä näyttöjä käyttäviä ei pitäisi saada odottamaan. Tavoitteena on aina nopeampi suorituskykymittari, kuten aika maalata, näiden käyttäjien palvelemiseksi.

Lyhyesti sanottuna lähes kaikki kehityksen näkökohdat ovat ennakoitua monimuotoisempia. Käytä tosielämän tietoja mahdollisimman varhaisessa vaiheessa varmistaaksesi, että sivusto pystyy selviytymään kaikista mahdollisista tilanteista.

08. Pidä silmällä regressioita

Kun ominaisuuksia lisätään tai muutetaan, testit on suoritettava uudelleen. On tärkeää asettaa etusijalle ne, joihin muutos todennäköisesti vaikuttaa. Testipaketti Jest pystyy määrittämään, mikä on muuttunut Git-sitoutumisten perusteella. Sitten se voi määrittää, mitkä testit suoritetaan ensin, jotta saadaan nopein palaute.

Visuaaliset regressiotyökalut, kuten PhantomCSS voi havaita, kun tyylit ovat muuttuneet. Jestissä on samanlainen käsite esineille tai käyttöliittymäkomponenteille, joita kutsutaan tilannekuvatesteiksi. Nämä sieppaavat jokaisen testin alkutilan. Kun jotain muuttuu, testi epäonnistuu, kunnes muutos on vahvistettu.

09. Testaa aikaisin, testaa usein

Kun tiukat aikataulut määrittävät julkaisut, kehittäjien on helppo antaa tuotteen luoda ja testaajat testata suoritusta. Todellisuudessa tämä voi johtaa paljon hukkaan kehitysaikaa.

paras kynä galaxy-välilehdelle a

Tavanomaisuus testata kukin uusi ominaisuus aikaisin tarkoittaa, että idea voidaan tarkistaa varmistaakseen, että se suuntasi oikeaan suuntaan. Paperimallien ja mallien avulla on helppo testata idea ilman koodia.

Testaamalla ominaisuutta säännöllisesti sen kehittyessä voimme olla varmoja, että se täyttää käyttäjän tarpeet. Jos tarvitaan pieniä muutoksia, ne on helpompi toteuttaa pienemmissä vaiheissa.

On myös tärkeää saada ideoita todellisille käyttäjille. Alfa- ja beetatestauskierrokset voivat tuoda ongelmat esiin riittävän ajoissa korjata ne vain vähän. Myöhempien kierrosten tulisi sisältää kohdennetut väestötiedot, jotka liittyvät lopulliseen loppukäyttäjään.

Lopuksi pidä nämä kierrokset mahdollisimman pieninä. Neilsenin tutkimuksessa todettiin, että viisi käyttäjää riittää saadakseen käsityksen siitä, mikä toimii ja mikä ei. Jos testattava elementti pidetään pienenä, saatu palaute riittää seuraavan testikierroksen polttoaineeksi.

10. Kannusta testikulttuuria

Testit voivat olla hyödyllisiä vain silloin, kun niitä käytetään säännöllisesti. Kaikkien projektiin osallistuvien on oltava aluksella, jotta he voivat olla tehokkaimpia.

Jatkuvan integroinnin (CI) työkalut automatisoivat mahdollisimman monta tarkistusta ennen kuin päivitys laskeutuu koodipohjaan. Nämä voivat suorittaa yksikkötestejä, tarkistaa kattavuuden ja tunnistaa yleiset ongelmat automaattisesti ja ilmoittaa niistä, jos ongelmia ilmenee. Koodia kaikilla ongelmilla ei voida lisätä projektiin.

Ominaisuuden kehittämisestä erilliset ihmiset voivat suorittaa laadunvarmistustestejä, jotka voivat toimia lopputarkastuksina varmistaakseen, että kaikki vaaditut toiminnot ovat läsnä ja toimivat.

Jos virheet pääsevät erilaisten tarkastusten läpi, varmista, että käytössä on prosessi niiden ilmoittamiseksi sekä sisäisesti että ulkoisesti. Nämä raportit voivat muodostaa perustan uusille testeille tulevaisuudessa varmistaakseen, että tämä ongelma ei koskaan tule uudelleen esiin.

Tämä artikkeli julkaistiin alun perin 307 -lehdessä netto , maailman myydyin verkkosivujen suunnittelijoille ja kehittäjille suunnattu lehti. Osta numero 307 täältä tai tilaa täällä .

Aiheeseen liittyvät artikkelit: