miten testaat Verkkosovelluksiasi
ohjelmistoalalla jokainen testaa sovelluksiaan jollain tavalla. Monilla kehittäjäryhmillä on pitkälle kehitettyjä testausjärjestelmiä, jotka on integroitu hyvin jatkuvaan integraatioputkistoon, mutta niidenkin, joilla ei ole automaattisia testejä, on vielä keksittävä tapoja tarkistaa, että heidän koodinsa toimii tarkoitetulla tavalla.
verkkosivun Rakentaminen ja sen läpi napsauttaminen manuaalisesti selaimen avulla on monenlaista testaamista. Vaikka se ei ole hienostunein, sillä on silti merkitystä. Sama pätee myös konsolin cURL-ohjelman käynnistämiseen ja synteettisen pyynnön lähettämiseen juuri luomaasi API-päätepisteeseen.
tässä viestissä keskustellaan siitä, miten automatisoimme jo tekemämme manuaalisen testauksen ennen kuin sukellamme eri testityyppeihin ja-menetelmiin.
Automaattitestit
manuaaliset testit riittävät pienille sovelluksille, mutta näiden sovellusten kasvaessa niiden testattava pinta kasvaa niiden mukana aiheuttaen kaksi ongelmaa.
yksi, kun ihmiset joutuvat tekemään testejä aina, kun sovelluksen uusi versio on valmis, voi syntyä epäjohdonmukaisuuksia. Tämä pitää erityisesti paikkansa, jos testejä on paljon. Kaksi: kokeiden Suorittaja ei voi suorittaa muita tehtäviä. Isoilla sovelluksilla testaus voi kestää useita päiviä.
loogisin tapa ratkaista nämä kaksi asiaa on automatisoida nämä manuaaliset tehtävät. Verkkosovelluksille on olemassa kaksi päätyyppiä: KÄYTTÖLIITTYMÄTESTIT ja API-testit. Kaksi työkalua voi automatisoida ne.
UI-testit
UI-testit voidaan suorittaa nukketeatteri-nimisellä työkalulla. Nukketeatterin avulla voit automatisoida manuaalisen KÄYTTÖLIITTYMÄTESTIN JavaScriptin avulla. Se asennetaan NPM: n kautta seuraavalla komennolla:
$ npm i puppeteer
voit tämän jälkeen kirjoittaa komentosarjan, joka ohjaa Päättömää versiota Chromesta testien suorittamiseen. Tämä käsikirjoitus voi näyttää seuraavilta:
(async () => { const browser = await puppeteer.launch(); const page = await browser.newPage(); await page.goto('https://google.com', {waitUntil: 'networkidle2'}); const heading = await page.$('h1'); await browser.close(); if(!heading) console.log('No heading found!');})();
tässä script, olemme aloittamassa päätön esimerkki Chrome, navigoinnin example.com, ja etsivät H1 Elementti. Jos sitä ei ole olemassa, Virheilmoitus kirjataan.
API-testit
API-testit voidaan automatisoida Postmanin kautta. Postmanin mukana tulee graafinen käyttöliittymä HTTP-pyyntöjen rakentamiseen, joka voidaan tallentaa. Nämä pyynnöt voidaan suorittaa myöhemmin vain hiiren napsautuksella.
pääset alkuun lataamalla ja asentamalla Postman-käyttöliittymän. Seuraavat vaiheet tarvitaan luoda ja tallentaa pyynnön:
- valitse Luo kokoelma vasemmalla
- Enter my Collection as the collection name
- Click Create
- Click on the ellipsis (…) of My Collection vasemmalla
- Select Add Request
- Enter my Request as the request name
- Click Save to My Collection
pyyntö näkyy vasemmassa sivupalkissa juuri luodun kokoelmasi alla.
jos valitset sen, sinun täytyy syöttää example.com URL-osoitteena ja lisää testi. Jos haluat lisätä testin, Napsauta testit URL-syöttökentän alla olevasta välilehtipalkista.
tekstialue, johon voit kirjoittaa testin JavaScript ilmestyy. Seuraavassa on esimerkki testistä:
pm.test("Status code is 200", () => { pm.response.to.have.status(200);});
jos napsautat Tallenna oikeassa yläkulmassa näytön ja lähettää heti sen jälkeen, Pyyntösi lähetetään. Testi skripti suorittaa sitten määrittää, onko vastaus oli tila 200.
testityypit
on olemassa kolme erilaista testityyppiä. Niiden ymmärtäminen mahdollistaa oikeanlaisen testauksen valitsemisen ohjelmistopinon eri osille.
yksikkötestit
yksikkötestit ovat yksinkertaisin testityyppi. He tarkistavat koodin pienten osien oikeellisuuden. Yksikkötesti kattaa yleensä yhden kutsun johonkin tehtävään tai yhden tavan käyttää luokkaa.
yksikkötesti on yleensä koodin ensimmäinen “käyttäjä”. Joissakin testimenetelmissä testi on jopa kirjoitettava ennen varsinaisen sovelluskoodin käyttöönottoa.
Yksikkötestejä voidaan käyttää sekä backendin että frontendin kehittämisessä. Jotkut kehitystiimit käyttävät yksikkötestejä tarkistaakseen koodinsa pienten osien, kuten lomakkeiden tai valikoiden, renderöidyn Dom-ulostulon. Taustajärjestelmässä käytetään usein YKSIKKÖTESTEJÄ HTTP-palvelimen ja tietokannan tai muiden sovellusliittymien välisen koodin testaamiseen.
kolme yleisesti käytettyä testijuoksua yksikkötesteissä ovat:
– Jest-Jestiä käytetään enimmäkseen frontendin kehityksessä, koska siinä on ainutlaatuisia ominaisuuksia, kuten snapshot-testaus, jotka auttavat ongelmissa, kuten UI regressioissa. Jest opetusohjelma löytyy täältä.
‐ AVA—AVA on suosittu backendin kehityksessä, koska se on erikoistunut testien erittäin rinnakkaiseen suorittamiseen. Avan opetusohjelma löytyy täältä.
– PHPUnit-PHPUnit on suosittu viitekehys PHP: n yksikkötesteille. PHPUnit-opetusohjelma löytyy täältä.
jos yksikkötesti vaatii joitain ulkoisia resursseja, kuten verkkoyhteyksiä tai tietokantoja, niin todennäköisesti kirjoitat integraatiotestin. Tämän tyyppinen testi käsitellään seuraavaksi.
Integraatiotestit
täytäntöönpanon näkökulmasta integraatiotestit näyttävät yksikkötesteiltä. Erona on, että integrointitesteissä testataan pinon useita osia yhdessä. Ne voivat esimerkiksi testata, puhuvatko asiakas ja palvelin samaa protokollaa vai eivät, tai mikropalveluarkkitehtuurissa, toimivatko palvelut oikein yhdessä.
tarkastukset, jotka yleensä päätyisivät useampaan erilliseen yksikkötestiin, voidaan yhdistää yhdeksi integrointitestiksi, joka määrittää, toimiiko kaikki hyvin yhdessä.
Integraatiotestejä käytetään sekä frontendin että backendin kehityksessä. Niitä käytetään joskus näkemään, ovatko kaksi osaa vuorovaikutuksessa oikein, mutta niiden avulla voidaan myös määrittää, toimivatko yhden osan eri moduulit yhdessä tarkoitetulla tavalla.
integraatiotesteissä voi käyttää samoja testijuoksijoita kuin yksikkötesteissä. Kuitenkin, Postman, UI työkalu käytetään edellä automatisoida manuaalinen API testit, myös mukana Cli työkalu nimeltä Newman, joka voidaan integroida CI / CD putki.
Newmanilla voi ajaa vietyjä Postman-mallistoja, jolloin Postman-käyttöliittymällä voi luoda pyyntöjä ja testejä ja ajaa ne myöhemmin CLI: n kautta. Newmanin opetusohjelma löytyy täältä.
jos integraatiotesti vaatii vuorovaikutusta käyttöliittymän kanssa, sitä kutsutaan seuraavaksi KÄYTTÖLIITTYMÄTESTIKSI.
UI-testit
UI-testit ovat kehittyneimpiä testejä. He yrittävät jäljitellä käyttäjän käyttäytymistä automatisoidusti, jotta testaajien ei tarvitsisi napsauttaa sovelluksensa jokaista osaa manuaalisesti läpi.
KÄYTTÖLIITTYMÄTESTIT auttavat usein nappaamaan tietyn vuorovaikutuksen, joka johti käyttäjän virheeseen. Kun se on kaapattu, se voidaan toistaa yhdellä napsautuksella, jotta voidaan korjata vika ja estää sitä palaamasta uuteen versioon.
aiemmin mainittuja Jest-ja AVA-testijuoksijoita voi käyttää täällä, mutta yleensä tarvitset ylimääräisen kirjaston helpottamaan käyttöliittymän vuorovaikutusta selaimen kautta. Tällä hetkellä käytössä olevat kaksi pääkirjastoa ovat:
– Puppeteer—Puppeteer on JavaScript-kirjasto, jonka mukana tulee Päätön toteutus Chromesta, joka mahdollistaa KÄYTTÖLIITTYMÄTESTIEN ajamisen ohjelmallisesti taustalla. Nukketeatterin opetusohjelma löytyy täältä.
– Selenium-Selenium on kehys, joka mahdollistaa selaimen etäohjauksen WebDriver-nimisen kirjaston kautta. Seleenitutoriaali löytyy täältä.
testityyppejä on useampia kuin tässä listatut. Muilla voi olla erilaisia tavoitteita; esimerkiksi kuormitustesteillä yritetään löytää suorituskyvyn pullonkauloja. Muista, että tässä kuvatuille testeille annetaan joskus eri nimiä. Edellä esitetyt kolme tyyppiä ovat olennaisia toteuttaa aloittaessaan. Yhden käyttäminen on parempi kuin ilman automaattista testausta.
testimenetelmät
testimenetelmät ovat tapoja ajatella testausta. Alla kuvatut kolme ovat yleisimmin käytettyjä.
Test Driven Development (TDD)
TDD on käytetyin ja teknisin menetelmä. Se suosittelee, että kirjoitat testit ennen varsinaisen koodin, jonka haluat testata. Koska sinun täytyy kirjoittaa testi vain osa koodin olet toteuttamassa, testin tyyppi voit kirjoittaa on yksikkötesti.
yksikkötestit ovat melko rakeisia, joten tämän menetelmän käyttö johtaa ajan myötä monien testien kertymiseen. Tämä todellisuus, yhdistettynä siihen, että aloittelija TDD harjoittajat yleensä kirjoittaa triviaaleja testejä, voi johtaa luomiseen kasa hyödyttömiä testejä. Tämän välttämiseksi on tärkeää päivittää ja siivota testejä, kun tiimi on tutustunut TDD: hen ja testaukseen yleensä.
on tärkeää suorittaa testit usein, ei vain CI / CD-putkistossa, vaan myös paikallisesti kehityskoneellasi. Kirjoita testi, suorita se, nähdä sen epäonnistuvan, toteuttaa tarpeeksi, jotta testi läpäisee, ja toista prosessi.
Lue lisää Agile Alliancen kuvauksesta TDD: stä.
Acceptance Test Driven Development (ATDD)
ATDD on TDD: n muunnos, joka keskittyy enemmän yritystapauksiin ja vähemmän tekniseen toteutukseen. Tässä menetelmässä käytettävät testityypit ovat useimmiten integraatiotestejä, koska usein useita järjestelmän osia on käytettävä yhdessä liiketoiminnan tarpeen ratkaisemiseksi.
koska testit ovat vähemmän teknisiä, testaukseen kannattaa ottaa mukaan myös ei-teknisesti suuntautuneita ihmisiä. Tuotteiden omistajat ja asiakkaat voivat auttaa yritystapausten määrittelyssä, jotta kehittäjä voi kirjoittaa niille testin. Jos testiä ei voi suorittaa onnistuneesti, on selvää, että toiminnallisuutta on lisättävä.
ATDD toimii eri abstraktiotasolla kuin TDD, joten näitä kahta menetelmää voidaan käyttää yhdessä.
Lue lisää Agile Alliancen kuvauksesta TDD: stä.
Behavior Driven Development (BDD)
BDD on sekoitus TDD: tä ja ATDD: tä, ja sen tavoitteena on käyttää molempien maailmojen parhaita puolia tehdäkseen kokonaisjärjestelmästä vakaamman. BDD pyrkii määrittelemään järjestelmän testeillä, jotka havainnollistavat sen käyttöä.
ATDD: n tavoin BDD yrittää kaapata bisnesjuttuja. Kuitenkin, se vaatii myös kyseenalaistaa näitä käyttötapauksia “5 whys “koska” whys ” ovat puuttuva osa ATDD. Toki on parempi kysyä asiakkailta, mitä he haluavat sen sijaan, että luotetaan pelkästään kehittäjien panokseen. Mutta on myös tärkeää kyseenalaistaa molempien ryhmien oletukset.
BDD on myös TDD: n ja ATDD: n sekoitus abstraktiotasojen merkityksessä. TDD testaa vain sovelluksen pieniä osia ja ATDD testaa vain, miten nämä osat toimivat yhdessä. BDD edellyttää, että sovellat tätä menetelmää sovelluksesi suureen kokonaisuuteen ja sen pieniin osiin, mikä tekee BDD: stä kokonaisvaltaisemman lähestymistavan testaamiseen.
tarkempaa luettavaa löytyy Agile Alliancen kuvauksesta BDD: stä.
johtopäätös
vaikka mikään testaus ei ole kauheaa, manuaalinen testaus on parempi ja automatisoitu testaus paras.
sovelluksen koosta riippuen manuaalinen testi voi estää kehitystiimin jäseniä työskentelemästä muissa projekteissa päiviä tai jopa viikkoja, mikä maksaa työaikaa ja rahaa. Lisäksi yksitoikkoinen tehtävä suorittaa samat vuorovaikutukset uudelleen ja uudelleen voi johtaa liukastumisiin, jotka ilmenevät usein tyhjinä vikoina.
tietokoneet ovat erittäin hyviä toistamaan samaa tehtävää yhä uudelleen, joten on hyvä delegoida testaus skriptille ja vapauttaa kehittäjien aikaa. Jos nämä testit on integroitu CI / CD-putkistoon, jo kirjoitetut testit voidaan suorittaa implisiittisesti, kun uusi toimitus laskeutuu arkistoihisi.
testausmenetelmää kannattaa käyttää jo varhaisessa vaiheessa, sillä usein isot ongelmat aloittaessa ovat “mitä” ja “milloin” testata. Nämä menetelmät voivat auttaa selkeyttämään prosessia, joka tekee kirjoitustesteistä yhdenmukaisempia kaikille tiimin jäsenille.
Leave a Reply