Oppaat

Näin testaat sovelluksen ennen julkaisua: käytännön testaussuunnitelma

Sovelluksen testaaminen ennen julkaisua tarkoittaa, että listaat ne muutamat polut, jotka käyttäjän on pystyttävä suorittamaan, ajat jokaisen niistä uutena käyttäjänä kannettavalla ja puhelimella ja kokeilet tapoja, joilla ne voivat mennä pieleen: tyhjä data, huono syöte, toinen tili, hidas yhteys. Testaa rahaan tai yksityisiin tietoihin liittyvät asiat erityisen huolellisesti ja toista pääpolut live-URL-osoitteessa julkaisun jälkeen. Lopuksi katso, kun joku, joka ei ole koskaan nähnyt sovellusta, yrittää käyttää sitä.

Tähän ei tarvita QA-tiimiä eikä testauskehystä. Tarvitset listan, tunnin tai kaksi ja kurinalaisuutta klikata sen läpi.

Vaihe 1: Kirjaa ylös tärkeät polut

Polku on alusta loppuun kulkeva tehtävä, jonka käyttäjä tulee tekemään. Useimmissa sovelluksissa on kolmesta kuuteen sellaista, jotka oikeasti ovat tärkeitä. Varaussovelluksessa esimerkiksi:

  1. Rekisteröidy ja vahvista tili
  2. Löydä tunti ja varaa se
  3. Peruuta varaus
  4. Maksa tuntikortti
  5. Henkilökunta: näe päivän varaukset

Jos olet kirjoittanut käyttäjätarinat, niiden hyväksymiskriteerit ovat jo testitapauksiasi. Jos et ole, kirjoita yksi rivi per polku ja kuvaa, mitä ”onnistuminen” tarkoittaa.

Järjestä ne tärkeysjärjestykseen. Polut, jotka tuottavat rahaa tai joita jokainen käyttäjä käyttää (rekisteröityminen, kirjautuminen, ydintoiminto), testataan ensin ja perusteellisimmin.

Vaihe 2: Testaa onnellinen polku uutena käyttäjänä

”Onnellinen polku” tarkoittaa polkua, joka menee täsmälleen niin kuin on tarkoitettu. Testaa se niin kuin vieras sen kokisi:

  • Käytä yksityistä selainikkunaa, jotta et ole kirjautunut sisään etkä ole tallentanut mitään.
  • Käytä uutta tiliä, jossa on oikea sähköpostiosoite, jonka voit tarkistaa.
  • Aloita etusivulta tai linkistä, älä sivulta, jonka olet lisännyt kirjanmerkkeihin rakentaessasi.

Uudet käyttäjät eivät ole tallentaneet mitään. Monet virheet näkyvät vain, kun lista on tyhjä, profiilissa ei ole kuvaa tai mitään ei ole vielä ostettu. Oma tilisi, täynnä testidataa, piilottaa ne.

Vaihe 3: Yritä rikkoa se

Toista nyt jokainen polku ja tee väärin tarkoituksella.

Kokeile tätäMitä tarkistat
Lähetä lomakkeet tyhjinä tai pelkillä välilyönneilläPakolliset kentät toimivat ja viesti on selkeä
Hyvin pitkä teksti, emoji, aksentilliset nimetUlkoasu pysyy ehjänä ja data tallentuu oikein
Väärät muodot: kirjaimia puhelinkentässä, menneisyyden päivämääräValidointi sekä sivulla että palvelimella
Kaksoisnapsauta lähetyspainikettaEi kaksoistilauksia tai kaksoisvarauksia
Selaimen takaisin-painike kesken prosessinEi rikkinäistä tilaa tai kadonnutta dataa
Lataa jokainen sivu uudelleenData säilyy; ei tyhjää sivua tai 404:ää
Kirjaudu ulos ja paina takaisinYksityiset sivut eivät näy
Kaksi välilehteä, joissa muokataan samaa asiaaViimeinen tallennus ei hiljaa pyyhi ensimmäistä

Uudelleenlataus kannattaa nostaa esiin: jos sovellus toimii, kun klikkaat läpi, mutta syvemmällä sivulla uudelleenlataus näyttää 404:n, katso näin korjaat 404-virheet julkaisun jälkeen.

Vaihe 4: Testaa oikeudet kahdella tilillä

Tämä on tärkein testi sovelluksille, joissa on tilejä, ja se, joka usein jätetään väliin.

Luo kaksi tavallista käyttäjää, A ja B, sekä (jos sovelluksessasi on sellainen) ylläpitäjä.

  • Tilillä A luo tietue. Kirjaudu B:nä. Näkeekö B sen, voiko hän muokata tai poistaa sen? Ei saisi, ellei suunnittelu sitä salli.
  • Kopioi A:n tietueen URL-osoite. Kirjaudu B:nä ja avaa se suoraan.
  • Avaa tavallisena käyttäjänä ylläpitosivut kirjoittamalla niiden URL-osoitteet.
  • Kirjaudu täysin ulos ja kokeile samoja URL-osoitteita.

Jos löydät tässä ongelman, älä julkaise ennen kuin se on korjattu. Tarkistuksen on tapahduttava palvelimella, ei pelkästään piilottamalla nappi. Tekoälyllä rakennettujen sovellusten tietoturvatarkistuslista menee syvemmälle.

Vaihe 5: Testaa oikeilla laitteilla

Avaa sovellus oikealla puhelimella, ei vain kapealla selainikkunalla.

  • Voitko napauttaa jokaista nappia zoomaamatta?
  • Peittääkö näppäimistö kentän, johon kirjoitat?
  • Vierivätkö taulukot ja leveä sisältö vai rikkovatko ne sivun vaakasuunnassa?
  • Onko teksti luettavaa ilman nipistämistä?

Testaa vähintään yhdellä iPhonella (Safari) ja yhdellä Android-puhelimella (Chrome), jos saat lainata niitä. Safarissa on erityisesti omia oikkujaan päivämäärien, videon ja kiinteiden elementtien kanssa.

Vaihe 6: Testaa raha ja sähköposti päästä päähän

Kaikki, mikä veloittaa kortteja tai lähettää sähköpostia, tarvitsee täyden läpikäynnin.

Maksut. Käytä maksupalveluntarjoajasi testitilaa ja testikorttinumeroita. Tarkista onnistunut maksu, hylätty kortti ja peruttu kassa. Varmista, että tilaus tai tilaus näkyy sovelluksessasi maksun jälkeen eikä vain palveluntarjoajan hallintanäkymässä. Jos sovelluksesi tukeutuu webhookeihin (viestit, jotka maksupalvelu lähettää palvelimellesi), tarkista että ne saapuvat julkaistuun sovellukseen, eivät vain kehitysympäristöön. Vaihda ennen julkaisua live-avaimiin ja tee yksi pieni oikea ostos, jonka hyvität.

Sähköpostit. Rekisteröidy oikeilla osoitteilla kahdessa tai kolmessa eri palvelussa. Tarkista, että viestit saapuvat, eivät ole roskapostissa ja että jokainen linkki viittaa live-verkkotunnukseen eikä esikatseluosoitteeseen.

Vaihe 7: Tarkista nopeus ja virheet

  • Avaa selaimen kehitystyökalut (oikea napsautus → Tarkasta) ja katso Konsoli-välilehti jokaisella pääsivulla. Punaiset virheet kannattaa korjata, vaikka mitään ei näytä rikkinäiseltä.
  • Lataa sivusto puhelimella mobiilidatalla, ei Wi-Fi:llä. Jos ensimmäinen näkymä kestää useita sekunteja, tarkista ensin kuvien koko.
  • Aja ilmainen tarkistus, kuten Lighthouse Chromen kehitystyökaluissa, nopeuden ja saavutettavuuden nopeaan arvioon.

Vaihe 8: Testaa julkaistu sovellus, ei vain esikatselua

Esikatselu ja julkaistu sovellus eivät ole sama ympäristö. Ennen kuin kerrot julkaisusta kenellekään, toista pääpolut live-URL-osoitteessa:

  • Ovatko kaikki ympäristömuuttujat ja salaisuudet asetettu julkaistulle sovellukselle?
  • Käyttääkö se oikeaa tietokantaa oikealla datalla?
  • Käyttävätkö kirjautumisen uudelleenohjaukset ja sähköpostilinkit live-verkkotunnusta?
  • Lataako syvän sivun uudelleenlataus oikein?

Vaihe 9: Seuraa, kun joku toinen käyttää sitä

Anna yhdelle tai kahdelle ihmiselle tavoite (”varaa jooga-tunti lauantaiksi”), ei ohjeita. Seuraa, älä auta, ja kirjoita ylös kohdat, joissa he epäröivät. Se on nopein tapa löytää epäselvä sanamuoto ja piilotetut napit. Laajempaa versiota varten katso näin järjestät beta-testauksen.

Kun he kohtaavat virheen, kirjaa se kunnolla ylös: askeleet, odotettu tulos ja todellinen tulos. Oppaamme hyvän virheraportin kirjoittamisesta näyttää muodon.

Tekoälyn käyttö testaamiseen

Jos rakennat tekoälyllä, voit pyytää sitä suunnittelemaan ja ajamaan testit:

Listaa tämän sovelluksen tärkeimmät käyttäjäpolut ja jokaiselle niistä reunatapaukset, jotka todennäköisimmin hajoavat: tyhjät tilat, virheellinen syöte, oikeudet ja uudelleenlataus. Laadi niistä tarkistuslista, jonka voin käydä läpi.

Kirjaudu kahdella eri testikäyttäjällä ja tarkista, voiko käyttäjä B nähdä tai muuttaa mitään, minkä käyttäjä A loi, myös avaamalla A:n tietueiden URL-osoitteet suoraan. Raportoi löydöt ennen kuin korjaat mitään.

Käsittele tekoälyn testiraporttia ensimmäisenä läpikäyntinä. Klikkaa silti rahaan ja oikeuksiin liittyvät polut itse läpi.

Testaaminen Mythexissä

Mythexissä komento /test käynnistää sovellustestauksen: agentti ohjaa selainta live-esikatseluun, klikkaa sivujen läpi, ottaa kuvakaappauksia ja raportoi rikkoutuneet polut chatissa. Se toimii parhaiten tietylle polulle, kuten ”testaa rekisteröityminen ja tunnin varaaminen”. Korjaa löydökset komennolla /fix tai tavallisella viestillä ja aja /test uudelleen. Sovellustestaus käyttää esikatselua, joten tarkista pääpolut julkaistussa URL-osoitteessa itse julkaisun jälkeen. Katso Sovellustestaus dokumentaatiosta ja oppaamme tekoälyllä rakennetun sovelluksen virheenkorjauksesta, kun jokin epäonnistuu.

Yleisimmät virheet

  • Testataan vain itsenä. Ylläpitäjätilisi, jossa on paljon dataa, piilottaa tyhjien tilojen ja oikeuksien virheet.
  • Testataan vain kannettavalla. Monilla sivustoilla suurin osa kävijöistä tulee puhelimella.
  • Toisen tilin ohittaminen. Datan vuotaminen käyttäjien välillä on vakavin virhe, jonka kanssa sovellus voi julkaistua.
  • Esikatseluun luottaminen. Live-sovelluksella on eri asetukset; testaa sekin.
  • Korjataan virheitä ilman lähialueen uudelleentestausta. Yhden lomakkeen korjaus voi rikkoa toisen, joka jakaa koodia.

Ennen julkaisua -tarkistuslista

  • Pääpolut listattu ja järjestetty tärkeysjärjestykseen
  • Jokainen polku läpäisee uutena käyttäjänä yksityisessä ikkunassa
  • Tyhjä, virheellinen, pitkä ja kaksoissyöte käsitelty
  • Uudelleenlataus toimii jokaisella sivulla
  • Käyttäjät eivät näe eivätkä muuta toistensa dataa, ei edes URL-osoitteen kautta
  • Ylläpitosivut estetty tavallisilta käyttäjiltä ja kirjautumattomilta vierailijoilta
  • Toimii oikealla iPhonella ja Android-puhelimella
  • Maksut testattu: onnistuminen, hylkäys, peruutus ja sovellus päivittyy sen jälkeen
  • Sähköpostit saapuvat, eivät mene roskapostiin ja linkittävät live-verkkotunnukseen
  • Ei punaisia virheitä konsolissa pääsivuilla
  • Pääpolut toistettu julkaistussa URL-osoitteessa
  • Vähintään yksi ulkopuolinen henkilö kokeili sovellusta, kun seurasit

Kysymykset

Kuinka paljon pienen sovelluksen pitää testata ennen julkaisua?

Riittävästi, jotta olet varma, että pääpolut toimivat täysin uudelle käyttäjälle puhelimella ja kannettavalla, että käyttäjät eivät näe toistensa tietoja ja että rahaan liittyvät toiminnot toimivat päästä päähän. Useimmille pienille sovelluksille se on muutama keskittynyt tunti, ei viikkoja.

Tarvitsenko automaattisia testejä MVP:lle?

Et välttämättä. Ydinpolkujen manuaalinen testaus löytää useimmat julkaisun estävät virheet. Automaattiset testit alkavat maksaa itsensä takaisin, kun muutat sovellusta usein ja haluat nopeasti varmistaa, ettet rikkonut sitä, mikä aiemmin toimi.

Testaanko esikatselussa vai live-sovelluksessa?

Molemmissa. Testaa perusteellisesti esikatselussa ja toista sitten pääpolut julkaistussa sovelluksessa, sillä puuttuvat ympäristömuuttujat, eri tietokanta tai reititysasetukset voivat saada live-version toimimaan eri tavalla.

Kuka muu kuin minä voi testata sovellustani?

Ainakin yksi ihminen, joka ei ole koskaan nähnyt sitä. Anna hänelle tavoite, ei ohjeita, ja seuraa ilman apua. Rakentajat välttävät tiedostamattaan polut, jotka hajoavat.

Mythex · Pricing · Rakenna mitä tahansa tekoälyllä · Verkkosivu- ja sovellusmallipohjat · Mythex vertailussa · Tekoälysovellusten rakentamisen sanasto · Ilmaiset työkalut tekoälysovellusten rakentamiseen · English

English አማርኛ العربية Български বাংলা Bosanski Català Čeština Dansk Deutsch Ελληνικά Español Español (España) Eesti فارسی Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Bahasa Indonesia Íslenska Italiano 日本語 ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu Македонски മലയാളം Монгол मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)