Introducció
En molts projectes amb els quals vaig treballar, la gent no va personalitzar TestRail per si mateix i es va conformar amb la configuració estàndard. Per tant, en aquest article intentaré descriure un exemple de configuracions individuals que us poden ajudar a millorar l'eficiència del vostre treball. Per exemple, prenem un projecte de desenvolupament d'aplicacions mòbils.
Una petita exempció de responsabilitat. Aquest article no conté una descripció de la funcionalitat bàsica de TestRail (hi ha moltes guies sobre això) i expressions de vendes que descriuen de manera colorida per què cal triar aquest venedor en particular per crear un repositori amb proves.
Pla de justificació (què s'implementarà)
-
Requisits generals
-
Absolutament qualsevol persona hauria de poder aprovar el cas.
-
Els casos han de romandre rellevants durant el major temps possible
-
Els casos haurien de cobrir la funcionalitat de l'aplicació mòbil de la manera més exhaustiva possible, en la mesura que això no contradigui els dos primers punts.
-
-
Dividiu en TestCase i TestScenario
-
Generació ràpida de TestRun de diversos tipus
-
Fum
-
Regressió
-
Proves d'impacte, etc.
-
-
Optimització del suport de casos
-
Abandonar les captures de pantalla codificades "mortes" i canviar a "dades mòbils"
-
Requisits
Per editar camps necessitareu accés d'administrador
Selecció d'un tipus de projecte
Hi ha tres tipus de projectes per triar:
Seleccionarem el tipus predeterminat. Tots els casos estaran disponibles al mateix temps. Utilitzarem el filtratge intel·ligent i gestionarem dinàmicament tots els casos alhora.
Afegint camps per veure una llista de casos de prova
Afegim un camp per mostrar casos de prova prioritaris:
També podeu afegir altres camps.
Configuració de camps i etiquetes de casos de prova
Obriu el menú de configuració:
Necessitarem els següents camps:
Camp "Resum" (capçalera del cas de prova)
Aquest camp ja existeix, només estem sistematitzant-ne l'ús. Dividirem els casos en TestCase i TestScenario. Per a una millor llegibilitat d'una gran llista de casos, és millor acordar amb antelació les regles per escriure un resum.
Escenari de prova:
Exemple: TestScenario: escenari bàsic per utilitzar una aplicació mòbil
TestCase:
Exemple: Pantalla principal - Secció d'autorització - Introduïu l'inici de sessió
En total, veiem en el resum del cas l'enteniment clàssic: "què, on, quan". També separem visualment els scripts de prova d'alt nivell i els casos de prova de baix nivell de la forma més adequada per a l'automatització.
Etiqueta "StartScreen" (la pantalla des de la qual comença TestScenario; a més, molts casos de prova poden tocar pantalles adjacents)
Pel que pot ser necessari: eliminarem del text el text dels casos típics passos que porten l'usuari a la pantalla del cas de prova actual. (passos típics per crear una situació de prova específica) Tots els passos típics de tots els casos de prova s'escriuran en un sol fitxer. Escriuré sobre això amb més detall per separat.
Crea un camp nou:
Ompliu els components del camp nou:
En aquest cas, estem creant un camp de selecció a partir d'una llista de valors. Introduïu els valors d'aquest camp:
Tingueu en compte que els valors d'identificació no comencen per un i no són consecutius. Per què es fa això? La qüestió és que si tenim casos de prova amb l'identificador introduït registrat,
i després haurem de crear una tercera pantalla entre les dues existents,
aleshores haurem de reescriure l'identificador i, com que les etiquetes dels casos de text existents ja hi estan adjuntats, simplement s'eliminaran. Serà molt desagradable.
Etiqueta "Pantalla" (nom de la pantalla que afecta TestCase)
El que necessiteu: un dels ancoratges per a les proves d'impacte. Per exemple, els desenvolupadors van crear una nova característica fantàstica. Hem de provar-ho, però per això hem d'entendre què pot afectar exactament aquesta característica. Per defecte, podem partir del paradigma que diferents pantalles (Activitats) d'una aplicació tenen diferents classes i per tant constitueixen diferents components de l'aplicació. Per descomptat, en aquest cas cal un enfocament individual.
Exemple: pantalla_inici, MapScreen, PayScreen, etc.
Camp "MovableData" (enllaç a una base de dades proxy amb dades de prova canviables)
A continuació, intentarem resoldre el problema de mantenir la rellevància de les dades en casos de prova:
-
Enllaços a dissenys actuals (això és molt millor que fer captures de pantalla mortes)
-
Passos típics per arribar a la pantalla amb una situació de prova
-
Consultes SQL
-
Enllaços a dades externes i altres dades
En lloc d'escriure dades de prova dins de cada cas de prova, crearem un fitxer extern i enllaçarem amb ell en tots els casos de prova. Quan actualitzem aquestes dades, no haurem de revisar tots els casos de prova i canviar-los, sinó que serà possible canviar aquestes dades en un sol lloc. Si algú no està preparat obre un cas de prova, veurà al cos del cas de prova un enllaç a un fitxer i una pista que ha d'anar-hi per obtenir dades de prova.
Empaquetarem totes aquestes dades en un fitxer extern, que estarà disponible per a tothom del projecte. Per exemple, podeu utilitzar Google Sheet o Excel i configurar una cerca dins del fitxer. Per què aquests venedors en particular? El cas és que partim del paradigma que qualsevol persona de l'equip hauria de poder obrir i passar un cas de prova sense necessitat d'instal·lar prèviament cap eina.
Per Full de Google podeu utilitzar consultes SQL. Exemple:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")Per Sobresortir Podeu configurar macros de cerca instantànies convenients. (filtrat) Exemple .
De fet, la idea no és nova i es descriu al llibre del primer provador "Testing dot com". (autor Savin Roman) Només estem integrant els mètodes proposats per Roman Savin a TestRail. Per fer-ho, creeu un camp amb un enllaç al fitxer creat:
ompliu el valor predeterminat de l'enllaç de manera que cada nou cas de prova ja tingui un enllaç:
Si la ubicació del fitxer extern canvia (prevem qualsevol cas de força major), podeu canviar còmodament un o més camps alhora en tots els casos de prova:
Camp "Descripcions" (descripció o idea d'un cas de prova, instruccions estàndard)
Què podeu necessitar: En aquest camp de text col·locarem una breu descripció del cas de prova i instruccions estàndard.
Exemple: Totes les dades de prova (dissenys actuals, ús d'eines i altres dades) d'aquest cas de prova s'indiquen mitjançant enllaços {...} i es troben al fitxer MovableData. Enllaceu a MovableData al camp corresponent a la part superior.
Etiqueta "Component" (component d'aplicació mòbil)
Per a què podria ser necessari: per a proves d'impacte. Si una aplicació mòbil es pot dividir en components (que s'afecten el menys possible entre si), els canvis en un component seran suficients (amb alguns riscos) per comprovar-se dins del mateix component, i hi haurà menys motius per dur-los a terme. regressió general de tot. Si hi ha informació que un component pot afectar un altre, es compila una matriu de proves d'impacte.
Components d'exemple: GooglePay, Comanda, Usuaris, Mapa, Autorització, etc.
Etiqueta "TAG" (altres etiquetes per filtrar)
Etiquetar un cas de prova amb etiquetes per al filtratge arbitrari.
Molt útil per a:
-
compilant ràpidament TestRun per a diverses tasques típiques: fum, regressió, etc.
-
les proves estaran automatitzades o ja estan automatitzades?
-
qualsevol altra etiqueta
Exemple: Smoke, Automated, WhiteLabel, ForDelete, etc.
Configuració de l'ordre de visualització dels camps al cas de prova
Hem creat molts camps nous, és hora d'ordenar-los en un ordre convenient:
S'està creant TestRun
Ara crearem una nova prova amb casos actuals per realitzar proves de fum en tres clics:
Altres consells útils
-
Si TestRail té diversos projectes, no us oblideu de crear nous camps només per al vostre projecte, en cas contrari, els companys dels equips veïns es sorprendran molt per l'aparició de nous camps inusuals. És possible un desmai local.
2. Els casos amb un gran nombre de camps són més fàcils de copiar d'un tipus de grup similar que no pas crear-ne de nous:
3. Els comptes es poden compartir. Per exemple: un administrador, diversos usuaris.
Conclusió
Els exemples descrits anteriorment s'han implementat en diversos projectes i han demostrat la seva eficàcia. Espero que us ajudin a millorar la vostra comprensió d'aquesta eina i us ajudin a crear "emmagatzematges de prova" efectius i còmodes. Agrairia molt si descrius la teva experiència amb TestRail i consells útils als comentaris.
Enllaços:
Llibre:
Moltes gràcies per la seva atenció!
Font: www.habr.com