Saturs
- 01. Uzrakstiet daudz vienību testu
- 02. Ja nepieciešams, izmantojiet testa dubultošanos
- 03. Pārbaudiet, kā komponenti darbojas kopā
- 04. Izpildiet katra lietotāja ceļu
- 05. Iestatiet veiktspējas budžetus
- 06. Izstrādāt pieejamību
- 07. Strādājiet līdz galējībām
- 08. Sekojiet līdzi regresijām
- 09. Pārbaudi agri, pārbaudi bieži
- 10. Veiciniet testa kultūru
Šobrīd tīmekļa izstrāde ir sarežģītāka nekā pirms dažiem gadiem. Tīmekļa dizaina rīki, pārlūka funkcijas, frontend sistēmas un paraugprakse mainās gandrīz katru mēnesi, un vienmēr ir ko atjaunināt. Un līdz ar to nāk risks. Kā mēs varam būt pārliecināti, ka šīm izmaiņām nebūs neparedzētu blakusparādību?
Pārbaude ir saistīta ar riska mazināšanu. Ja lietotājam ir problēmas ar vietnes izmantošanu, viņš, visticamāk, neatgriezīsies un drīzāk pāriet pie konkurenta. Pārbaudot katru lēmumu, kas tiek pieņemts, izstrādājot vietni, tas samazina iespēju, ka lietotājiem būs zemāka pieredze (izcils tīmekļa mitināšana palīdzēs jums analizēt jūsu vietnes problēmas).
Skaidrs, ka lietotāju testēšana ir saistīta ne tikai ar to, lai pārliecinātos, vai koda bāzē nav kļūdu. Ir izstrādes procesa pareizā procesa pārbaude, kas ļauj pārliecināties, ka visu, kas tiek izveidots, vada lietotāja reālas vajadzības.
Vai vēlaties izveidot vietni bez problēmām? Izmēģiniet vietņu veidotāju.
01. Uzrakstiet daudz vienību testu
Nestrukturēts kods ir kļūdu priekštecis, un tas tiek izdots tālāk pa ceļu. Tas ne tikai padara to grūti saprotamu un neiespējamu jaunināšanu, bet arī apgrūtina testēšanu. Tā kā visi gabali tieši paļaujas viens uz otru, testiem ir jānotiek ar visu kodu uzreiz. Tas apgrūtina to, kas īsti nedarbojas, kad pienāks laiks.
Katra lietojumprogrammas daļa jāsadala atsevišķi. Piemēram, pieteikšanās veidlapa var ietvert datubāzes vaicājumus, autentifikāciju un maršrutēšanu papildus ieveidotām pogām un pogām. Katrs no tiem ir lielisks kandidāts, kam ir sava klase, funkcija vai komponents.
Cietas koda bāzes pamats ir labs vienību testu kopums. Tiem vajadzētu aptvert visu kodu un ātri palaist. Lielākajai daļai vienību testu un to struktūru ir vienāda struktūra:
pre> description ("DateLocale", function () {test ("nodrošina dienu pareizajā valodā", function () {var date = new DateLocale ("lv"); date.setDate (new Date (1525132800000)); sagaidīt (date.getDay ()). toBe ("otrdiena");});}); / pre>
Bloks "aprakstīt" norāda, kāds koda fragments tiek pārbaudīts. Tajā ir vairāki testi, kas izveido scenāriju un salīdzina mūsu paredzamo rezultātu ar faktisko rezultātu. Ja tie nesakrīt, pārbaude neizdodas, un mēs varam turpināt izmeklēšanu.
Izveidojot un veicot vienības testus, mainot failus, mēs varam būt pārliecināti, ka nekas nejauši nav salauzis katra koda gabala paredzamo funkcionalitāti. Šos gabalus vajadzības gadījumā var nomest arī citos projektos. Tā kā tam jau ir uzrakstīti testi, mēs varam būt pārliecināti, ka tieši šai vienībai jau no paša sākuma nav problēmu.
Ir daudz rīku, kas palīdz rakstīt vienības testus, piemēram, Jest, Jasmine un AVA. Vislabākā atbilstība būs atkarīga no katra projekta vajadzībām, visām iesaistītajām sistēmām un galu galā izstrādātāja vēlmēm.
02. Ja nepieciešams, izmantojiet testa dubultošanos
Lai gan tas var šķist neproduktīvs, to var viegli pārbaudīt vairāk nekā sākotnēji paredzēts. Piemēram, ja funkcija ir atkarīga no ārējas bibliotēkas, jebkuras kļūdas, kas nāk no šīs bibliotēkas, neizdosies izturēt citus testus, pat ja mūsu uzrakstītais kods ir labs.
Risinājums tam ir pievienot šai funkcionalitātei vietturus vai “testa dubultus”, kas darbojas tāpat, bet vienmēr mums dod gaidīto rezultātu.Trīs galvenie testa dubultspēļi ir “izspēles”, “celmi” un “spiegi”.
Izsmiekls ir klase vai objekts, kas vienkārši ieņem īstā vietu. Viņiem ir tāda pati saskarne, taču tie nesniegs praktisku funkcionalitāti.
Stuls ir līdzīgs izspēlei, bet atbildēs ar iepriekš ieprogrammētu uzvedību. Tie tiks izmantoti pēc nepieciešamības, lai simulētu konkrētas lietojumprogrammas daļas, kamēr tā tiek testēta.
Spiegs vairāk koncentrējas uz to, kā tika sauktas metodes šajā saskarnē. Tos bieži izmanto, lai pārbaudītu, kad funkcija darbojas, cik reizes tā darbojās un kādi argumenti tika piegādāti, kad tā darbojās. Tas ir tāpēc, ka mēs zinām, ka pareizās lietas tiek kontrolētas īstajā laikā.
Tādas bibliotēkas kā Sinon, Testdouble un Nock nodrošina lielisku, gatavu testa dubultspēli. Dažos "suite" numuros, piemēram, Jasmine, ir arī iebūvēts divvietīgs numurs.
03. Pārbaudiet, kā komponenti darbojas kopā
Kad kods ir sadalīts atsevišķos komponentos, mums jāpārbauda, vai tie var darboties kopā. Piemēram, ja autentifikācijas slānis nesaprot, kas tiek atgriezts no datu bāzes, neviens nevarēs pieteikties. Tos sauc par “integrācijas testiem”. Viņi pārbauda, kā viena lietojumprogrammas daļa darbojas ar citu. Kamēr vienības testi ir apzināti izolēti viens no otra, integrācijas testi veicina saziņu starp šīm abām pusēm.
Tāpat kā ar vienības testiem, arī integrācijas testa mērķis ir pārbaudīt gala rezultātu. Mūsu pieteikšanās piemērā tā var būt pārbaude, vai datu bāzē ir atjaunināts laikspiedols "Pēdējoreiz pieteicies".
Tā kā vienlaikus tiek risināts vairāk, integrācijas testi parasti ir lēnāki nekā vienības testi. Kā tādu viņu vajadzētu būt mazāk un viņiem vajadzētu skriet retāk. Ideālā gadījumā tie darbotos tikai pēc funkcijas pabeigšanas, lai pārliecinātos, ka nekas nav mainījies.
Tos pašus komplektus, ko izmanto vienības testos, var izmantot integrācijas testu rakstīšanai, taču tiem vajadzētu būt iespējai izpildīt atsevišķi, lai lietas darbotos ātri.
04. Izpildiet katra lietotāja ceļu
Automātiskās tehniskās testēšanas augstākais līmenis ir pazīstams kā “end-to-end” vai “funkcionāls” tests. Kā norāda nosaukumi, šis līmenis aptver visas darbības, kuras lietotājs var veikt no sākuma līdz beigām. Tie simulē reālos scenārijus un to, kā lietotājs, iespējams, mijiedarbosies ar gatavo produktu.
Šo testu struktūra bieži atspoguļo lietotāju stāstus, kas izveidoti kā daļa no izstrādes procesa. Lai paplašinātu agrāku piemēru, var būt pārbaude, lai pārliecinātos, vai lietotājs pieteikšanās veidlapā var ievadīt savu lietotājvārdu un paroli.
Tā kā viņi paļaujas uz lietotāja saskarnes darbību, tie jāatjaunina, mainoties saskarnei. Arī ilgs ielādes laiks var radīt problēmas. Ja kādu darbību nevar pabeigt pietiekami ātri, pārbaude neizdosies, kā rezultātā tiks iegūti nepatiesi rezultāti.
Arī šie testi notiks lēni. Vājo vietu parasti rada pārlūkprogrammas palaišana, kas nav tik ātra kā komandrinda, bet ir nepieciešama, lai atdarinātu pareizo vidi. Tādējādi tie darbosies retāk nekā integrācijas testi - parasti pirms izmaiņu kopas iestumšanas ražošanā.
Tādi rīki kā Selenium un Puppeteer var palīdzēt rakstīt testus no gala līdz galam. Tie ļauj pārlūkprogrammām kontrolēt, izmantojot kodu, lai automatizētu to, kas citādi būtu atkārtots manuāls process.
05. Iestatiet veiktspējas budžetus
Mūsdienu front-end izstrāde bieži ietver visu projektu kopu izveidi ar daudziem smagiem aktīviem. Bez piesardzības tiem var būt kaitīga ietekme uz veiktspēju.
Webpack nāk ar veidu, kā sekot līdzi veiktspējas problēmām, piemēram, komplektam un aktīvu lielumam. Pielāgojot ‘performance’ objektu vietnē webpack.config.js, tas var izstarot brīdinājumus, kad faili kļūst par lielu un kā to labāk novērst. Tās var pat mest kļūdas, kas var apturēt būvniecības veiksmīgu darbību, lai pārliecinātos, ka galalietotāji netiek negatīvi ietekmēti.
Ir svarīgi pārbaudīt arī uz virkni ierīču, kas ir līdzīgas tām, kuras izmanto vietnes apmeklētāji. Pirmā mobilo ierīču pieeja dizainam un izstrādei nodrošina to, ka lietotāji lētākās ierīcēs neatstāj gaidīšanu, līdz lapa tiek renderēta.
WebPagetest sniedz visaptverošu pārskatu par vietnes veiktspēju, kā arī padomus par to, kā to uzlabot. Tiešraides pakalpojumi, piemēram, Pingdom, var reāllaika datiem izsekot vietnes veiktspējai, izmantojot tiešraides lietotājus.
Noteikti saglabājiet detalizētas piezīmes par visiem atklājumiem, kurus savai komandai var droši piekļūt mākoņa krātuvē.
06. Izstrādāt pieejamību
Katrai vietnei jābūt viegli pieejamai visiem. Kaut arī pieejamības testēšana parasti attiecas uz personām ar invaliditāti, veiktās izmaiņas kopumā nāks par labu visiem, izveidojot pieejamāku, viegli orientējamu vietni.
Ir rīki, kas var automātiski noteikt visbiežāk sastopamās problēmas, piemēram, sliktu semantisko marķējumu vai trūkstošo attēlu tekstu. Piemēram, Lighthouse darbojas Chrome izstrādātāja rīkos un sniedz tūlītēju atgriezenisko saiti par analizētās lapas pieejamību.
Automatizētie rīki nevar visu atklāt, piemēram, mašīnai nav iespējams zināt, vai attēla alternatīvais teksts ir piemērots. Manuālo testēšanu nevar aizstāt līdzās lietotājiem ar dažādu invaliditāti. Ierīces tiks izveidotas šī lietotāja unikālajām vajadzībām, un mums būs jāpārliecinās, ka tās tiek apmierinātas.
07. Strādājiet līdz galējībām
Edge lietas ir bieži sastopams problēmu cēlonis, īpaši virkņu garums un saturs. Pēc noklusējuma garie vārdi izstieps konteineru un radīs plūsmas problēmas lapā. Bet kas notiek, ja kāds nolemj izmantot rakstzīmes no cita alfabēta vai izmanto emocijzīmes?
Glabājot šīs virknes datu bāzē, problēmas kļūst pastāvīgākas. Garās virknes var būt saīsinātas, un kodēšanas problēmas var izkropļot ziņojumu. Šīs pārbaudes jāietver visos testa datos.
Fuzz testēšana ir automatizēta metode, kas bombardē saskarni ar nejaušu ievadi kā stresa testa formu. Testa mērķis ir pārliecināties, ka negaidītas - bet iespējamas - lietotāju darbību kopas nerada negaidītas problēmas.
Šīs galējības neaprobežojas tikai ar saturu. Lietotājus, kuriem ir lēni savienojumi, zemas klases ierīces un mazāki ekrāni, nevajadzētu likt gaidīt. Vienmēr tiecieties pēc ātrākas veiktspējas metrikas, piemēram, laika, lai pirmo reizi krāsotu, lai apmierinātu šos lietotājus.
Īsāk sakot, gandrīz visi attīstības aspekti ir daudzveidīgāki, nekā paredzēts. Izmantojiet reālās pasaules datus pēc iespējas agrāk, lai pārliecinātos, ka vietne spēj tikt galā ar visiem gadījumiem.
08. Sekojiet līdzi regresijām
Tā kā funkcijas tiek pievienotas vai mainītas, testi būs jāveic atkārtoti. Ir svarīgi noteikt prioritāti tiem, kurus šīs izmaiņas varētu ietekmēt. Testa komplekts Jest, pamatojoties uz Git apņemšanos, spēj noteikt, kas ir mainījies. Pēc tam tā var noteikt, kuri testi jāveic vispirms, lai sniegtu ātrāko atgriezenisko saiti.
Vizuālās regresijas rīki, piemēram, PhantomCSS, var noteikt, kad stili ir mainījušies. Līdzīgs jēdziens pastāv arī Jest attiecībā uz objektiem vai lietotāja saskarnes komponentiem, kurus sauc par momentuzņēmumu testiem. Tie uztver katra testa sākotnējo stāvokli. Kad kaut kas mainīsies, tests neizdosies, kamēr izmaiņas nebūs apstiprinātas.
09. Pārbaudi agri, pārbaudi bieži
Kad saspringtie grafiki nosaka izlaidumus, izstrādātājiem ir viegli ļaut izveidot produktu un testētājiem pārbaudīt izpildi. Patiesībā tas var novest pie daudz izšķērdēta izstrādes laika.
Lai pierastu agri pārbaudīt katru jauno funkciju, ideju var pārbaudīt, lai pārliecinātos, ka tā virzās pareizajā virzienā. Izmantojot papīra prototipus un maketus, ir viegli pārbaudīt ideju bez koda.
Regulāri pārbaudot funkciju, kad tā tiek izstrādāta, mēs varam būt pārliecināti, ka tā atbilst lietotāja vajadzībām. Ja ir nepieciešami kādi nelieli pielāgojumi, tos ir vieglāk īstenot mazākos posmos.
Ir arī svarīgi, lai idejas tiktu pārbaudītas ar reāliem lietotājiem. Alfa un beta testēšanas kārtas var atklāt problēmas pietiekami agri, lai tās labotu ar nelielu pieskaitāmo summu. Vēlākajās kārtās jāiekļauj mērķtiecīgi demogrāfiskie dati, kas ir saistīti ar gala lietotāju.
Visbeidzot, saglabājiet šīs kārtas pēc iespējas mazākas. Neilsena pētījums atklāja, ka pietiek ar pieciem lietotājiem, lai iegūtu priekšstatu par to, kas darbojas un kas ne. Ja pārbaudāmais elements tiek turēts neliels, iegūto atgriezeniskās saites diapazons būs pietiekams, lai veicinātu nākamo testēšanas kārtu.
10. Veiciniet testa kultūru
Pārbaudes var būt noderīgas tikai tad, ja tās regulāri lieto. Visiem, kas iesaistīti projektā, jābūt uz kuģa, lai palīdzētu viņiem būt visefektīvākajiem.
Nepārtrauktas integrācijas (CI) rīki automatizē pēc iespējas vairāk pārbaudes, pirms kāds atjauninājums nonāk kodabāzē. Tie var veikt vienības testus, pārbaudīt pārklājumu un automātiski identificēt kopīgās problēmas un atzīmēt tos, ja rodas kādas problēmas. Kodu ar jebkādiem jautājumiem nevar pievienot projektam.
Cilvēki, kas atdalīti no funkcijas izstrādes, var veikt kvalitātes nodrošināšanas (QA) testus, kas var darboties kā gala pārbaude, lai pārliecinātos, ka visa nepieciešamā funkcionalitāte ir pieejama un darbojas.
Ja kļūdas tiek veiktas, veicot dažādas pārbaudes, pārliecinieties, ka ir izveidots process, kā par tām ziņot gan iekšēji, gan ārēji. Šie pārskati var būt pamats jauniem testiem nākotnē, lai pārliecinātos, ka šī problēma nekad neatkārtojas.
Šis raksts sākotnēji tika publicēts 307 tīkls, pasaulē visvairāk pārdotais žurnāls tīmekļa dizaineriem un izstrādātājiem. Pērciet 307. numuru šeit vai abonēt šeit.
