miten kirjoittaa testitapaukset syntymäaikaa varten: ILMAINEN yksityiskohtainen toiminnallinen Testausesimerkki

tässä artikkelissa puhun siitä, miten suunnitella testitapaukset syntymäaikaa (DOB) varten.

tämä toiminto on erittäin tärkeä, sillä sillä on monia käyttötarkoituksia.

jotkut näistä käyttötarkoituksista sisältävät muun muassa turvallisuuden ja tunnistamisen.

voit vapaasti käyttää koelaukkua ja muuttaa sitä tarpeidesi mukaan.

nyt ennen kuin jatkat, kannattaa opetella lisää koejuttujen kirjoittamisesta.

mitkä ovat tärkeimmät asiat, jotka kannattaa testata syntymäajan toimivuutta varten?

syntymäaika on vain yksi kenttä.

se on kuitenkin mielestäni yksi tärkeimmistä kentistä käyttäjän profiilin rekisteröinnissä.

hajotetaan alkuaineet;

1. päivä (tekstikenttä)
2. kuukausi (tekstikenttä)
3. vuosi (tekstikenttä)
4. ovatko kaikki elementit voimassa?

skenaariot, joissa käyttäisit Syntymäaikatoimintoa

• tilin / käyttäjän rekisteröinti
• käyttäjän iän tarkistaminen, kun hän rekisteröityy tuotteeseen tai palveluun
• kirjautumistunnusten palauttaminen, Kun käyttäjä unohtaa
• Admin – käyttäjä osana turvallisuuskysymyksiä

tarkastellaan tarkemmin edellä mainittuja skenaarioita

Skenaario 1: syntymäajan testitapaukset-käyttäjän iän todentaminen

iän todentamista käytetään niin monilla eri alustoilla. Alla on muutamia testiskenaarioita, joita kannattaa harkita.

• käyttäjä haluaa luoda some – / sähköpostitilin ja hänen tulee olla vähintään 13-vuotias.
• käyttäjä hakee Yhdistyneen kuningaskunnan väliaikaista ajokorttia. Alaikäraja on 17 vuotta.
• rajoitetun tuotteen tai palvelun ostaminen verkosta. Esimerkiksi katsomassa rajoitettuja YouTube-videoita, jotka edellyttävät ikätarkastusta.
• alkoholin tai pelipalveluiden ostaminen netistä!

skenaario 2: Syntymäajan Testaustapaukset-kirjautumistunnusten palauttaminen Kun käyttäjä unohtaa

• kun käyttäjä unohtaa tunnuksensa, järjestelmä voi pyytää lisätarkistusta käyttäjän henkilöllisyyden todistamiseksi.

skenaario 3: syntymäajan testitapaukset – Järjestelmän ylläpitäjä kysyy DOB: ltä osana turvakysymysten sarjaa

• samanlainen kuin yllä oleva skenaario kuitenkin inhimillisellä elementillä. Tämä skenaario on, jos sovelluksen järjestelmänvalvoja käyttäjä haluaa tarkistaa, että käyttäjä soittaa On todellakin kuka he sanovat olevansa ja DOB on osa joukko turvallisuuden vahvistamista kysymyksiä.

Business and Functional Requirements

kannattaa aina yrittää saada joitakin vaatimuksia, jos testauksesta tulee laadukas.

sanon aina ei-testaaville kollegoilleni, että spesifikaatioon perustuvina testaajina olemme vain niin hyviä kuin mitä meillä on.

ota huomioon Bisnesanalyytikkoystäväni.

eritelläänpä joitakin esimerkkivaatimuksia, jotka olen luonut sinulle.

olen yrittänyt olla yksityiskohtainen, mutta en halua mennä yli laidan.

jos mahdollista, sinun tulisi aina yrittää luoda Requirements Traceability Matrix (RTM), johon voit tallentaa kaikki projektisi vaatimukset.

vaatimuksen tunnus	vaatimuksen kuvaus	huomautukset
REQ-DOB-0001	järjestelmän on tallennettava syntymäaika.
REQ-DOB-0002	syntymäajan on oltava Iso-Britanniassa. esimerkiksi kentän päivämäärämuodon on oltava alla olevassa järjestyksessä. pp/kk / vvvv D = päivä (numeerinen muoto)M = kuukausi (numeerinen muoto)Y = vuosi (numeerinen muoto)	jos tarvitaan pudotusvaihtoehto, käyttöliittymä voi päivittää ja näyttää vähimmäisaloituspäivän, joka = 13 vuotta vanha. se voi hyväksyä myös manuaalisen syötön.
REQ-DOB-0003	manuaalinen DOB-lomakkeen merkintä järjestelmän on annettava käyttäjälle mahdollisuus syöttää syntymäaika manuaalisesti	tätä vaatimusta voidaan laajentaa sisältämään päivämäärä – /kalenteriohjausvaihtoehto. yksinkertaisuuden vuoksi käytämme kuitenkin manuaalista lomakevaihtoehtoa. käytettävyyden kannalta päivämääränvalitsin on vähemmän työläs ja altis vähemmille validointiongelmille.
REQ-DOB-0004	käyttäjän ikärajoitus käyttäjän vähimmäisikä on 13 vuotta. järjestelmän pitäisi automaattisesti hylätä kaikki alle 13-vuotiaat käyttäjät nykyisestä päivämäärästä alkaen.
REQ-DOB-0005	Day Field Validation the day field must be a valid number from between 1 to 31. DFBR1-Day field Business Rule 1 järjestelmä hylkää kaikki arvot, jotka ovat alle 1 ja yli 31.
REQ-DOB-0006	Month Field Validation a valid month field will be a number from 1 to 12. kuukausi 1 tarkoittaa tammikuuta ja kuukausi 12 joulukuuta. MFBR1-Month Field Business Rule 1 kun käyttäjä syöttää kuukauden numeerisena arvona, järjestelmän tulee validoida, onko päiväarvo oikea.
REQ-DOB-0007	Year Field Validation the year field is a 4 character numeeric value that should be back no further than 125 years from the current year. esimerkiksi jos tänään on 1.syyskuuta 2021, varhaisin päivä, johon järjestelmä voi mennä, on 1. syyskuuta 1896.	elossa on useita yli 110-vuotiaita ihmisiä, minkä seurauksena olen lisännyt vielä yhden, mutta varautuneemman.
REQ-DOB-0008	karkausvuosi validointi jos henkilö on syntynyt karkausvuonna, järjestelmän pitäisi validoida; syntymävuosi oli itse asiassa karkausvuosi. syntymäaika ei karkausvuonna ole 1. Maaliskuuta. jos niiden kirjoittama vuosi on virheellinen, järjestelmän tulee näyttää Virheilmoitus.	Huom: joissakin maissa karkausvuoden maksamatta jättäminen helmikuun 28. päivään katsotaan laittomaksi. tässä tapauksessa käytämme Yhdistyneen kuningaskunnan oikeudellista näkökulmaa, joka on käyttää 1. Maaliskuuta.
REQ-DOB-0009	validoi oikea päivämäärä kun käyttäjä syöttää koko syntymäajan, järjestelmän tulee tarkistaa sen voimassaolo. Yrityssääntö 1: validoi päivä oikean kuukauden mukaan.
REQ-DOB-0010	syntymäajan laskeminen

käyttäjän matka

testitapaukseen sisältyy tyypillisesti positiivinen ja negatiivinen validointi. Se näyttää jotain seuraavista;

• käyttäjä navigoi rekisteröintisivulle
• pyydettäessä käyttäjä syöttää kelvottoman syntymäajan
• käyttäjä syöttää voimassa olevan syntymäajan (mutta erehdyksessä alle 13-vuotias)
• järjestelmä näyttää virheilmoituksen, jossa käyttäjälle ilmoitetaan, että hän ei voi rekisteröityä, jos hän on alle 13-vuotias
• käyttäjä syöttää oikean päivämäärän syntymä (joka on yli 13-vuotias)
• järjestelmä käsittelee ja validoi päivämäärän oikeaksi.

syntymäajan testitapaus esimerkki

vaihe numero	testivaihe	vaatimus ID	odotettu tulos	todellinen tulos	Status (Pass / Fail)	positiivinen / negatiivinen testi
1	Access user registration form page for Application under Test (AUT)		käyttäjä laskeutuu käyttäjän rekisteröinti sivulla.			+
2	Ohita syntymäaika-kenttä ja täytä voimassa olevat tiedot lomakkeen loppuosassa		voimassa olevat tiedot täytetään kaikissa kentissä paitsi syntymäaika-kentässä.			+
3	negatiivinen testiskenaario ”päivän” kenttään syötetään virheellinen luku, kuten = >32.		päiväkentässä on virheellinen merkintä. esimerkiksi: 32/MM / VYY Huom.: riippuen siitä, miten vaatimukset on kirjoitettu, sovellus voi näyttää virheilmoituksen tässä vaiheessa tai kun kaikki päivämäärä kenttä on kansoitettu.			–
4	”kuukausi” – kenttään käyttäjä syöttää kelvollisen numeerisen arvon.		kelvollinen numeerinen arvo merkitään			+
5	”vuosi” – kenttään käyttäjä syöttää oikean arvon.		oikea syntymävuosi merkitään.			+
6	käyttäjä napsauttaa ’Lähetä’		järjestelmä näyttää virheilmoituksen, jossa varoitetaan, että Päiväkenttä on virheellinen. Huomautus: kaikkiin kenttiin on syötetty manuaaliset tiedot, jotta käyttäjä voi tehdä korjauksen. kentät ovat edelleen muokattavia..			+
7	negatiivinen testitapaus päiväkentässä käyttäjä syöttää tyhjään tilaan.		kaikki muut kentät ovat edelleen asuttuja ja päiväkenttä päivitetään tyhjäksi			–
8	käyttäjän napsautukset lähetä		järjestelmä näyttää virheilmoituksen, jossa varoitetaan, että Päiväkenttä on virheellinen. kaikissa kentissä on edelleen syötetyt manuaaliset tiedot, jotta käyttäjä voi tehdä korjauksen..			+
9	Testing of business rule in the ” day ”field käyttäjä syöttää arvon ”31”.		Päiväkenttään merkitään arvo ”31”.			–
10	kuukausi-kenttään käyttäjä syöttää arvon 09 Huomautus: 9 = syyskuu		Kuukausikentässä ilmoitetaan arvo ”09”.
11	vuosi-kenttään käyttäjä syöttää oikean arvon. esim.. 1985		oikea arvo merkitään ”vuosi” – kenttään.
12	käyttäjä napsauttaa ’Lähetä’		näytetään ’hyödyllinen’ Virheilmoitus. viestissä käyttäjälle kerrotaan, että syyskuussa ei ole 31 päivää. muutetaan vastaavasti.
13	käyttäjä hyvittää päiväarvo 30		Päiväkenttä on populaged with ’30’.
14	käyttäjä napsauttaa ’Lähetä’		järjestelmä; a) käsittelee lomakkeen b) validoi syntymäajan c) validoi liiketoimintasääntöjen vastaisesti ohjaa käyttäjän rekisteröitymisen vahvistussivulle.

en halunnut tehdä tästä testitapauksesta liian pitkää, mutta voit myös lisätä joitakin testivaiheita varmistaaksesi;

• käyttäjä on yli 13-vuotias
• käyttäjä, joka on syntynyt 29. Helmikuuta, on merkitty syntymäajaksi 1. Maaliskuuta (karkausvuotta lukuun ottamatta).
• validoi, että vuosi on enintään 125 vuotta kulunut nykyisestä päivämäärästä.

jos sinulla on kalenteriohjaus, että ”juttu”, jossa valitset päivämäärän hiirellä, tämän testaamisen pitäisi olla paljon helpompaa.

tämä johtuu siitä, että on vähemmän toiminnallisia testejä ja vähemmän testitietoja valmisteltavana.

osana rekisteröintiprosessia kannattaa harkita myös testitapauksia salasanan muutostoiminnallisuudesta.

Raja-Arvoanalyysi

alla on joitakin raja-arvoja, joita kannattaa miettiä.

Ikä

raja 1	Raja 2
0 -13	13 >

Ekvivalenssiosa

sinulla on useita osioita osana tätä testiä, ne ovat;

Ikä

Osio 1	Osio 2
0-12	>13

loistava lisä Regressiotestausohjelmaasi

rakastan tällaista yksityiskohtaista toiminnallista testiä. Miksi?

koska voin lisätä sen regressiotestipakkaukseeni.

kun sinulla on kaikki monimutkaiset yksityiskohdat, voit kirjaimellisesti suorittaa nämä testit sitä mukaa kuin Ja kun tarvitset niitä.

riippumatta siitä, ovatko testit manuaalisia vai automatisoituja.

Summary

toivottavasti yllä oleva olisi hyvä testitapaus syntymäajan funktionaalitestille.

rakastan ehdottomasti tällaisia mustan laatikon testaustekniikoita, kuten muistan tehneeni monia urallani.

jos joskus törmäät testipäiväkenttiin, saatat olla kiinnostunut myös kirjoittamaan testijuttuja kalenterisovellukseen.

Laadunvarmistusareenalla työskentely ei ole helppoa, mutta tämä on yksi ohjelmistotestaajana olemisen monista haasteista.