Introdución
En moitos proxectos cos que traballei, a xente non personalizou TestRail por si mesmo e facíase coa configuración estándar. Polo tanto, neste artigo intentarei describir un exemplo de configuracións individuais que poden axudarche a mellorar a eficiencia do teu traballo. Por exemplo, tomemos un proxecto de desenvolvemento de aplicacións móbiles.
Unha pequena exención de responsabilidade. Este artigo non contén unha descrición da funcionalidade básica de TestRail (hai moitas guías sobre isto) e expresións de vendas que describen de xeito colorido por que cómpre escoller este provedor en particular para crear un repositorio con probas.
Plan de xustificación (que se vai implementar)
-
Requisitos xerais
-
Absolutamente calquera debe ser capaz de aprobar o caso.
-
Os casos deben seguir sendo relevantes durante o maior tempo posible
-
Os casos deben cubrir a funcionalidade da aplicación móbil o máis exhaustivamente posible na medida en que isto non contradiga os dous primeiros puntos.
-
-
Divídese en TestCase e TestScenario
-
Xeración rápida de TestRun de varios tipos
-
Fume
-
Regresar
-
Probas de impacto, etc.
-
-
Optimización de soporte de casos
-
Abandonar capturas de pantalla codificadas "mortas" e cambiar a "datos móbiles"
-
requisitos
Para editar campos necesitarás acceso de administrador
Selección dun tipo de proxecto
Hai tres tipos de proxectos para escoller:
Seleccionaremos o tipo predeterminado. Todos os casos estarán dispoñibles nel ao mesmo tempo. Usaremos o filtrado intelixente e xestionaremos todos os casos de forma dinámica á vez.
Engadindo campos para ver unha lista de casos de proba
Engademos un campo para mostrar casos de proba prioritarios:
Tamén pode engadir outros campos.
Configurar campos e etiquetas de casos de proba
Abre o menú de configuración:
Necesitaremos os seguintes campos:
Campo "Resumo" (encabezado do caso de proba)
Este campo xa existe, só estamos a sistematizar o seu uso. Dividiremos os casos en TestCase e TestScenario. Para unha mellor lexibilidade dunha gran lista de casos, é mellor acordar previamente as regras para escribir un resumo.
Escenario de proba:
Exemplo: TestScenario - Escenario básico para usar unha aplicación móbil
Caso de proba:
Exemplo: Pantalla principal - Sección de autorización - Introduza o inicio de sesión
En total, vemos no resumo do caso o entendemento clásico: "que, onde, cando". Tamén separamos visualmente os scripts de proba de alto nivel e os casos de proba de baixo nivel na forma máis adecuada para a automatización.
Etiqueta "StartScreen" (a pantalla desde a que comeza TestScenario; ademais, moitos casos de proba poden tocar pantallas adxacentes)
Para o que poida ser necesario: eliminaremos do texto o texto dos casos típicos pasos que levan ao usuario á pantalla do caso de proba actual. (pasos típicos para crear unha situación de proba específica) Todos os pasos típicos de todos os casos de proba escribiranse nun ficheiro. Vou escribir sobre iso con máis detalle por separado.
Crea un campo novo:
Encha os compoñentes do novo campo:
Neste caso, estamos creando un campo de selección dunha lista de valores. Introduza os valores deste campo:
Teña en conta que os valores de identificación non comezan por un e non son consecutivos. Por que se fai isto? A cuestión é que se temos casos de proba co identificador introducido rexistrado,
e despois teremos que crear unha terceira pantalla entre as dúas existentes,
entón teremos que reescribir o id, e como as etiquetas dos casos de texto existentes xa están unidas a el, simplemente eliminaranse. Será moi desagradable.
Etiqueta "Pantalla" (nome da pantalla que afecta a TestCase)
O que podes necesitar: unha das ancoraxes para as probas de impacto. Por exemplo, os desenvolvedores fixeron unha nova función interesante. Necesitamos probalo, pero para iso necesitamos entender o que pode afectar exactamente esta función. Por defecto, podemos partir do paradigma de que diferentes pantallas (Actividades) dunha aplicación teñen diferentes clases e, polo tanto, constitúen diferentes compoñentes da aplicación. Por suposto, neste caso é necesario un enfoque individual.
Exemplo: pantalla_inicio, MapScreen, PayScreen, etc.
Campo "MovableData" (ligazón a unha base de datos proxy con datos de proba modificables)
A continuación, trataremos de resolver o problema de manter a relevancia dos datos nos casos de proba:
-
Ligazóns a deseños actuais (isto é moito mellor que facer capturas de pantalla mortas)
-
Pasos típicos para chegar á pantalla cunha situación de proba
-
Consultas SQL
-
Ligazóns a datos externos e outros datos
En lugar de escribir datos de proba dentro de cada caso de proba, crearemos un ficheiro externo e enlazaremos a el en todos os casos de proba. Ao actualizar estes datos, non teremos que pasar por todos os casos de proba e cambialos, senón que será posible cambiar estes datos nun só lugar. Se alguén non está preparado abre un caso de proba, verá no corpo do caso de proba unha ligazón a un ficheiro e unha indicación de que debe ir a el para obter datos de proba.
Empaquetaremos todos estes datos nun ficheiro externo, que estará dispoñible para todos os que participen no proxecto. Por exemplo, pode usar Google Sheet ou Excel e configurar unha busca no ficheiro. Por que estes vendedores en particular? O caso é que partimos do paradigma de que calquera persoa do equipo debería poder abrir e pasar un caso de proba sen ter que instalar previamente ningunha ferramenta.
Para Folla de Google pode usar consultas SQL. Exemplo:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")Para Resaltar Podes configurar macros de busca instantánea convenientes. (filtrado) Exemplo .
En realidade, a idea non é nova e descríbese no libro do primeiro probador "Testing dot com". (autor Savin Roman) Só estamos integrando os métodos propostos por Roman Savin en TestRail. Para iso, cree un campo cunha ligazón ao ficheiro creado:
encha o valor predeterminado da ligazón para que cada novo caso de proba xa teña unha ligazón:
Se a localización do ficheiro externo cambia (prevemos calquera caso de forza maior), podes cambiar comodamente un ou máis campos á vez en todos os casos de proba:
Campo "Descricións" (descrición ou idea dun caso de proba, instrucións estándar)
O que pode necesitar: Neste campo de texto colocaremos unha breve descrición do caso de proba e instrucións estándar.
Exemplo: Todos os datos de proba (diseños actuais, uso de ferramentas e outros datos) deste caso de proba indícanse mediante ligazóns {...} e sitúanse no ficheiro MovableData. Ligazón a MovableData no campo correspondente na parte superior.
Etiqueta "Compoñente" (compoñente da aplicación móbil)
Para que pode ser necesario: para probas de impacto. Se unha aplicación móbil se pode dividir en compoñentes (que se afectan o menos posible entre si), entón os cambios nun compoñente serán suficientes (con algúns riscos) para ser verificados dentro do mesmo compoñente, e haberá menos motivos para levar a cabo. regresións xerais de todo. Se hai información de que un compoñente pode afectar a outro, recompílase unha matriz de proba de impacto.
Exemplos de compoñentes: GooglePay, Pedido, Usuarios, Mapa, Autorización, etc.
Etiqueta "TAG" (Outras etiquetas para filtrar)
Etiquetar un caso de proba con etiquetas para filtrar arbitrariamente.
Moi útil para:
-
compilando rapidamente TestRun para varias tarefas típicas: fume, regresión, etc.
-
as probas estarán automatizadas ou xa automatizadas?
-
calquera outra etiqueta
Exemplo: Smoke, Automated, WhiteLabel, ForDelete, etc.
Configurar a orde de visualización dos campos no caso de proba
Creamos moitos campos novos, é hora de organizalos nunha orde conveniente:
Creando TestRun
Agora imos crear unha nova proba con casos actuais para realizar probas de fume en tres clics:
Outros consellos útiles
-
Se TestRail ten varios proxectos, non te esquezas de crear novos campos só para o teu proxecto, se non, os compañeiros dos equipos veciños sorprenderán moito a aparición de novos campos pouco comúns. É posible un desmaio local.
2. Os casos cun gran número de campos son máis fáciles de copiar dun tipo de grupo similar que de crear outros novos:
3. As contas pódense compartir. Por exemplo: un administrador, varios usuarios.
Conclusión
Os exemplos descritos anteriormente foron aplicados en varios proxectos e demostraron a súa eficacia. Espero que che axuden a mellorar a túa comprensión desta ferramenta e che axuden a crear "almacenamentos de proba" eficaces e cómodos. Agradeceríache moito que nos comentarios nos describas a túa experiencia co uso de TestRail e consellos útiles.
Referencias:
Libro:
Moitas grazas pola túa atención!
Fonte: www.habr.com