Esittely
Monissa projekteissa, joiden kanssa työskentelin, ihmiset eivät räätälöineet TestRailia itselleen ja tyytyvät standardiasetuksiin. Siksi tässä artikkelissa yritän kuvata esimerkin yksittäisistä asetuksista, jotka voivat auttaa sinua parantamaan työsi tehokkuutta. Otetaan esimerkiksi mobiilisovelluskehitysprojekti.
Pieni vastuuvapauslauseke. Tämä artikkeli ei sisällä kuvausta TestRailin perustoiminnallisuuksista (sitä varten on monia oppaita) eikä myyntiilmauksia, jotka kuvaavat värikkäästi, miksi sinun täytyy valita tämä toimittaja luodaksesi arkiston testeillä.
Perustelusuunnitelma (mitä toteutetaan)
-
Yleiset vaatimukset
-
Ehdottomasti kenen tahansa pitäisi pystyä käsittelemään tapaus.
-
Tapausten tulee olla relevantteja mahdollisimman pitkään
-
Tapausten tulee kattaa mobiilisovelluksen toiminnallisuus mahdollisimman perusteellisesti, mikäli tämä ei ole ristiriidassa kahden ensimmäisen kohdan kanssa
-
-
Jaa TestCase ja TestScenario
-
Nopea sukupolvi TestRun eri tyyppejä
-
Savu
-
Taantua
-
Vaikutustestit jne.
-
-
Tapauksen tuen optimointi
-
Luopuminen "kuolleista" kovakoodatuista kuvakaappauksista ja siirtyminen "liikkuvaan dataan"
-
vaatimukset
Kenttien muokkaamiseen tarvitaan järjestelmänvalvojan oikeudet
Projektityypin valitseminen
Valittavana on kolme projektityyppiä:
Valitsemme oletustyypin. Kaikki kotelot ovat käytettävissä samaan aikaan. Käytämme älykästä suodatusta ja hallitsemme dynaamisesti kaikkia tapauksia kerralla.
Kenttien lisääminen nähdäksesi luettelon testitapauksista
Lisätään kenttä, joka näyttää prioriteettitestitapaukset:
Voit myös lisätä muita kenttiä.
Testitapauskenttien ja -tunnisteiden määrittäminen
Avaa asetusvalikko:
Tarvitsemme seuraavat kentät:
Yhteenveto-kenttä (testitapauksen otsikko)
Tämä kenttä on jo olemassa, olemme vasta systematisoimassa sen käyttöä. Jaamme tapaukset TestCaseen ja TestScenarioon. Suuren tapausluettelon luettavuuden parantamiseksi on parempi sopia etukäteen yhteenvedon kirjoittamisen säännöistä.
Testitilanne:
Esimerkki: TestScenario - Perusskenaario mobiilisovelluksen käyttöön
Testitapaus:
Esimerkki: Päänäyttö - Valtuutusosio - Anna kirjautumistunnus
Kaiken kaikkiaan tapauksen yhteenvedossa näemme klassisen käsityksen: "mitä, missä, milloin". Erottelemme myös visuaalisesti korkean tason testiskriptit ja matalan tason testitapaukset automatisointiin sopivimmassa muodossa.
"StartScreen" -tunniste (näyttö, josta TestScenario alkaa; myös monet testitapaukset voivat koskettaa viereisiä näyttöjä)
Mihin sitä mahdollisesti tarvitaan: poistamme tekstistä tapausten tyypilliset vaiheet, jotka johtavat käyttäjän nykyisen testitapauksen näytölle. (tyypilliset vaiheet tietyn testitilanteen luomiseen) Kaikki tyypilliset vaiheet kaikille testitapauksille kirjoitetaan yhteen tiedostoon. Kirjoitan siitä tarkemmin erikseen.
Luo uusi kenttä:
Täytä uuden kentän osat:
Tässä tapauksessa luomme valintakentän arvoluettelosta. Syötä tämän kentän arvot:
Huomaa, että id-arvot eivät ala ykkösellä eivätkä ole peräkkäisiä. Miksi tämä tehdään? Asia on siinä, että jos meillä on testitapauksia, joissa syötetty tunnus on tallennettu,
ja sen jälkeen meidän on luotava kolmas näyttö kahden olemassa olevan näytön väliin,
sitten meidän on kirjoitettava tunnus uudelleen, ja koska olemassa olevien tekstitapausten tagit on jo liitetty siihen, ne yksinkertaisesti poistetaan. Siitä tulee erittäin epämiellyttävää.
Tag "Screen" (näytön nimi, joka vaikuttaa TestCaseen)
Mitä saatat tarvita: yksi iskutestauksen ankkureista. Esimerkiksi kehittäjät tekivät uuden hienon ominaisuuden. Meidän on testattava sitä, mutta tätä varten meidän on ymmärrettävä, mitä tämä ominaisuus tarkalleen ottaen voi vaikuttaa. Oletuksena voimme lähteä siitä paradigmasta, että sovelluksen eri näytöillä (Activities) on eri luokkia ja ne muodostavat siksi sovelluksen eri komponentit. Tietysti tässä tapauksessa tarvitaan yksilöllistä lähestymistapaa.
Esimerkki: home_screen, MapScreen, PayScreen jne.
"MovableData" -kenttä (linkki välityspalvelintietokantaan, jossa on muutettavissa olevat testitiedot)
Seuraavaksi yritämme ratkaista ongelman tietojen relevanssin ylläpitämisessä testitapauksissa:
-
Linkit nykyisiin asetteluihin (tämä on paljon parempi kuin kuolleiden kuvakaappausten ottaminen)
-
Tyypillisiä vaiheita näytölle pääsemiseksi testitilanteessa
-
SQL-kyselyt
-
Linkit ulkoisiin tietoihin ja muihin tietoihin
Sen sijaan, että kirjoittaisit testitietoja jokaiseen testitapaukseen, luomme yhden ulkoisen tiedoston ja linkitämme siihen kaikissa testitapauksissa. Näitä tietoja päivitettäessä meidän ei tarvitse käydä läpi kaikkia testitapauksia ja muuttaa niitä, vaan näitä tietoja on mahdollista muuttaa vain yhdessä paikassa. Jos joku valmistautumaton avaa testitapauksen, hän näkee testitapauksen rungossa linkin tiedostoon ja vihjeen, että hänen täytyy mennä siihen saadakseen testitietoja.
Pakkaamme kaikki nämä tiedot yhteen ulkoiseen tiedostoon, joka on kaikkien projektissa olevien käytettävissä. Voit esimerkiksi käyttää Google Sheetiä tai Exceliä ja määrittää haun tiedostosta. Miksi juuri nämä myyjät? Tosiasia on, että lähdemme siitä paradigmasta, että jokaisen tiimin henkilön pitäisi pystyä avaamaan ja läpäisemään testitapaus ilman, että hänen tarvitsee ensin asentaa mitään työkaluja.
varten Google-arkki voit käyttää SQL-kyselyitä. Esimerkki:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")varten kunnostautua Voit määrittää käteviä pikahakumakroja. (suodatus) Esimerkki .
Itse asiassa idea ei ole uusi, ja se on kuvattu ensimmäisen testaajan kirjassa "Testing dot com". (Kirjoittaja Savin Roman) Integroimme juuri Roman Savinin ehdottamat menetelmät TestRailiin. Voit tehdä tämän luomalla kentän, jossa on linkki luotuun tiedostoon:
täytä linkin oletusarvo niin, että jokaisessa uudessa testitapauksessa on jo linkki:
Jos ulkoisen tiedoston sijainti muuttuu (varaamme mahdollisen ylivoimaisen esteen), voit kätevästi muuttaa yhtä tai useampaa kenttää kerralla kaikissa testitapauksissa:
Kenttä "Kuvaukset" (testitapauksen kuvaus tai idea, vakioohjeet)
Mitä saatat tarvita: Tähän tekstikenttään laitamme lyhyen kuvauksen testitapauksesta ja vakioohjeet.
Esimerkiksi: Kaikki testitiedot (nykyiset asettelut, työkalujen käyttö ja muut tiedot) tästä testitapauksesta on merkitty linkeillä {...} ja sijaitsevat MovableData-tiedostossa. Linkki MovableDataan vastaavaan kenttään yläreunassa.
Tag "Component" (mobiilisovelluskomponentti)
Mihin sitä saatetaan tarvita: iskutestaukseen. Jos mobiilisovellus voidaan jakaa komponentteihin (jotka vaikuttavat toisiinsa mahdollisimman vähän), niin yhden komponentin muutokset riittävät (joillakin riskeillä) tarkistettavaksi saman komponentin sisällä ja niiden suorittamiseen on vähemmän syytä. yleisiä regressioita kaikesta. Jos on tietoa, että yksi komponentti voi vaikuttaa toiseen, kootaan iskuntestausmatriisi.
Esimerkkikomponentit: GooglePay, Tilaus, Käyttäjät, Kartta, Valtuutus jne.
Tag "TAG" (muut tunnisteet suodatukseen)
Testitapauksen merkitseminen tageilla mielivaltaista suodatusta varten.
Erittäin hyödyllinen:
-
TestRunin nopea kääntäminen erilaisiin tyypillisiin tehtäviin: savu, regressio jne.
-
ovatko testit automatisoitu vai jo automatisoitu?
-
muita tageja
Esimerkki: Smoke, Automated, WhiteLabel, ForDelete jne.
Kenttien näyttöjärjestyksen asettaminen testitapauksessa
Olemme luoneet paljon uusia kenttiä, on aika järjestää ne sopivaan järjestykseen:
Luodaan TestRun
Luomme nyt uuden testiajon nykyisillä tapauksilla savutestauksen suorittamiseen kolmella napsautuksella:
Muita hyödyllisiä vinkkejä
-
Jos TestRaililla on useita projekteja, älä unohda luoda uusia kenttiä vain projektillesi, muuten naapuritiimien kollegat hämmästyvät erittäin uusien epätavallisten kenttien ilmestymisestä. Paikallinen pyörtyminen on mahdollista.
2. Tapaukset, joissa on paljon kenttiä, on helpompi kopioida samanlaisesta ryhmätyypistä kuin luoda uusia:
3. Tilit voidaan jakaa. Esimerkiksi: yksi ylläpitäjä, useita käyttäjiä.
Johtopäätös
Yllä kuvatut esimerkit on toteutettu useissa hankkeissa ja ne ovat osoittaneet tehokkuutensa. Toivon, että ne auttavat parantamaan ymmärrystäsi tästä työkalusta ja auttavat sinua luomaan tehokkaita ja käteviä "testivarastoja". Olisin erittäin kiitollinen, jos kuvailet kokemuksiasi TestRailin käytöstä ja hyödyllisiä vinkkejä kommenteissa.
viitteet:
Kirja:
Kiitos paljon huomiostanne!
Lähde: will.com