Skip to content

DV

Jump to bottom
Javier López edited this page May 22, 2022 · 3 revisions

Data Validation

Estrategias de generación de datos

Parametrización de Datos

Con el objetivo de seguir lo aprendido, y el consejo "si de forma automatizada quieren datos generar, el tipo de oráculo asociado a los datos no pueden olvidar." diseñamos un sistema de generación de datos que utilizamos para implementar los tres tipos de pool de datos.

Diseño

Parte de la generación de los datos a partir de un esquema, todos los esquemas están definidos en el objeto scenarios. Cada esquema está ajustado para cumplir las necesidades del escenario.

Un ejemplo de un esquema de un escenario, Nombre de máxima longitud en el formulario crear miembro:

Scenarios = {
  maxlongname: {
    title: 'Max long name (191)',
    model: 'member',
    oracle: true,
    data: { name: { length: 191 } },
  },
  ...
}

Esto especifica el título que tendrá el nombre de la prueba, el modelo (formulario) que va a ser probado, el resultado de evaluar el oráculo de la prueba, y data donde describimos el esquema de los datos. En este caso un nombre de 191 caracteres. Todos los escenarios específicos de datos se encuentran en el objeto

Para generar los datos este esquema se pasa el identificador maxlongname a la función getData, esta por su parte los pasa a una función que da opciones por defecto y llama la función generadora correspondiente esta, estas en la mayoría de los casos llaman a otra función generadora que se encarga de que el string cumpla con las características esperadas.

De esta forma es generado los datos usando a faker.js parametrizado para contar con oráculo definido.

Aleatorio (random)

Usando la estrategia de parametrización delineada, la función getData recibiendo el pool type random genera una sola tupla de datos. Estos datos son retornados y se procede a correr el escenario con ellos.

Apriori

Usando la estrategia de parametrización delineada anteriormente a la ejecución generamos un data pool con un seed para cada uno de los escenarios definidos de un tamaño definido por defecto (100 alternativas). Para generar el data pool apriori se corre el comando npm run gendatapool cuyos resultados se guardan en el archivo pool.json

Datos de este data pool son usados cuando llamados a la función getData usan pool de tipo apriori. Siguiendo la ejecución de la función podemos ver que es leído la primera vez que se requiere un dato de este. Estos datos son retornados y se procede a correr el escenario con ellos.

Dinámico

Se genera de similar forma que el data pool apriori, sin embargo no se le hace seed y se genera al vuelo en el primer llamado a la función getData con tipo de pool dynamic.

Ejecución de escenarios parametrizados

Ejecución en CI

Los casos del tipo data de validación de funcionarios se encuentran en el archivo data.spec.ts como los escenarios están parametrizados se corren en un ciclo, usando la funcionalidad de parametrizar de playwright. Un paso a paso de la ejecución de un escenario.

  1. Se toma el objeto Scenarios donde están todos los test parametrizados.
  2. Se itera sobre cada uno de los escenarios
  3. Se escoge un datapool de manera rotativa, es decir primero de apriori, luego random, luego dyanmic.
  4. El título, modelo y oráculo se utilizan para generar el nombre el escenario en una función, llamada al momento de crear el test parametrizado.
  5. Playwright crea todos los test, antes de correrlos.

Ahora miremos el proceso de ejecución de una prueba, ya habiendo visto como se montó la parametrización.

  1. Se llama la función runScenario esta se encargará de correr los métodos adecuados dependiendo a la configuración del escenario y el tipo de pool utilizdo.
  2. La función primeramente obtienes la tupla de datos que va a utilizar, llamando a getData usando el pool configurado, dicha información viene en un objeto Cookie que hace parte de la firma de runScenario. De esta forma se obtiene una tupla de datos a utilizar.
  3. Se realiza el login.
  4. Dependiendo a que modelo (Member, Staff o Tag) se crear la página respectiva y se llama al método respectivo. Estos métodos tienen un diseño especial:
    • Consiste en que insertan los datos de la tupla en los campos esperados y presionan guardar, y tienen un watchdog de feedbacks claros que da Ghost, determinando de esa forma muy rápidamente si se grabó exitosamente o fallo el guardado. De esta forma retornan un boolean y este es usado para comparar con el oráculo definido en la parametrización.
  5. De esta forma se ejecuta la prueba con datos parametrizados y oraculo definido.

Ejecución de escenarios no parametrizados

Playwright

Ejecución en CI

Los escenarios corridos en las dos semanas anteriores, todos utilizaron datos random. Los test se pueden encontrar en la carpeta e2e-playwright/

Kraken

Ejecución en CI

Los escenarios corridos en las dos semanas anteriores, todos utilizaron datos random. Los features se encuentran en la carpeta features/

Escenarios

Los siguientes son los escenarios de validación realizados. Nos centramos como fue especificado en clase en los formularios y que estos presenten los datos correctamente.

Leyenda:

  • Member: se refiere al formulario de creación de miembro
  • Staff: se refiere al formulario de edición de perfil de staff.
  • Member fun: se refiere a funcionalidad de diferentes features de member.
  • Post fun: se refiere a funcionalidad de diferentes features de post.
  • Tool: Esta columna especifica en que herramienta corrieron los tests.
    • Pw: Playwright
    • Kr: Kraken
  • Pool: el tipo de data pool usado para ese escenario.
  • Tipo/Clase Oráculo/Escenario (+ | -): Todos los oráculos son definidos, sin embargo El signo (+) significa escenario positivo y (-) escenario negativo.
  • [BUG]: Este label en el nombre del escenario significa que este escenario debería arrojar una respuesta contraria a la que arrojó. Por esto se marcaron de esa manera.

Nuestro grupo por ser de 3 integrantes requiere 90 escenarios. Todos los escenarios incluyen realizar el login y navegar hacia la funcionalidad.

# Tool Pool Nombre
1. Pw dynamic Member: No name (+)
2. Pw random Member: Empty all fields (-)
3. Pw apriori Member: Long name (+)
4. Pw dynamic Member: Max long name (191) (+)
5. Pw random Member: Over max long name (192) (-)
6. Pw apriori Member: Very short name (+)
7. Pw dynamic Member: No email (-)
8. Pw random Member: Email normal (40) (+)
9. Pw apriori Member: Very long email: 100 (-)
10. Pw dynamic Member: Short email (+)
11. Pw random Member: Invalid email (-)
12. Pw apriori Member: No TLD email (-)
13. Pw dynamic Member: [BUG] Emoji email (-)
14. Pw random Member: [BUG] Email should allow multiple "@" (-)
15. Pw apriori Member: Email should allow multiple punctuation characters (+)
16. Pw dynamic Member: [BUG] Email should allow IP address as domain "whatever@[166.84.7.99]" (-)
17. Pw random Member: Email should not allow consecutive dots "." (-)
18. Pw apriori Member: Email should allow consecutive dots ".." if they are quoted " " (+)
19. Pw dynamic Member: Normal note (+)
20. Pw random Member: No note (+)
21. Pw apriori Member: Long note (near frontier 499 vs 500) (+)
22. Pw dynamic Member: Long note (over frontier 501 vs 500) (-)
23. Pw random Member: Long note (in frontier 500 vs 500) (+)
24. Pw apriori Member: label (1, normal) (+)
25. Pw dynamic Member: No label (+)
26. Pw random Member: Long label (in frontier 191 vs 191) (+)
27. Pw apriori Member: Long label (over frontier 192 vs 191) (-)
28. Pw dynamic Member: Many labels (50, normal length) (+)
29. Pw random Staff: No name (-)
30. Pw apriori Staff: Empty all fields (-)
31. Pw dynamic Staff: Long name (+)
32. Pw random Staff: Max long name (191) (+)
33. Pw apriori Staff: Over max long name (192) (-)
34. Pw dynamic Staff: No email (-)
35. Pw random Staff: [BUG] Emoji email (-)
36. Pw apriori Staff: [BUG] Email should allow multiple "@" (-)
37. Pw dynamic Staff: [BUG] Email should allow IP address as domain "whatever@[166.84.7.99]" (-)
38. Pw random Staff: Email should not allow consecutive dots "." (-)
39. Pw apriori Staff: Invalid email (-)
40. Pw dynamic Staff: Long bio (near frontier 199 vs 200) (+)
41. Pw random Staff: Long bio (over frontier 201 vs 200) (-)
42. Pw apriori Staff: Long bio (in frontier 200 vs 200) (+)
43. Pw dynamic Staff: Regular website (+)
44. Pw random Staff: Website without tld (e.g. no .com) (+)
45. Pw apriori Staff: Website without tld (e.g. no .com) (-)
46. Pw dynamic Staff: Long website (near frontier 1999 vs 2000) (+)
47. Pw random Staff: Long website (over frontier 2001 vs 2000) (-)
48. Pw apriori Staff: Long website (in frontier 2000 vs 2000) (+)
49. Pw dynamic Tag: Normal, valid data in all fields (+)
50. Pw random Tag: Without name tag (-)
51. Pw apriori Tag: without color tag (+)
52. Pw dynamic Tag: Color including the pound sign (#) (-)
53. Pw random Tag: Invalid color (a string) (-)
54. Pw apriori Tag: Fail tag (-)
55. Pw dynamic Tag: Empty all fields (-)
56. Pw random Tag: Only provide a name (+)
57. Pw apriori Tag: Description less than frontier (499 vs 500) (+)
58. Pw dynamic Tag: Description more than frontier (501 vs 500) (-)
59. Pw random Tag: Description in frontier (500 vs 500) (+)
60. Pw apriori Tag: Meta title less than frontier (299 vs 300) (+)
61. Pw dynamic Tag: Meta title in frontier (300 vs 300) (+)
62. Pw random Tag: Meta title over frontier (301 vs 300) (-)
63. Pw apriori Tag: Meta description less than frontier (499 vs 500) (+)
64. Pw dynamic Tag: Meta description in frontier (500 vs 500) (+)
65. Pw random Tag: Meta description over frontier (501 vs 500) (-)
66. Pw apriori Tag: Twitter title less than frontier (299 vs 300) (+)
67. Pw dynamic Tag: Twitter title in frontier (300 vs 300) (+)
68. Pw random Tag: Twitter title over frontier (301 vs 300) (-)
69. Pw apriori Tag: Twitter description less than frontier (499 vs 500) (+)
70. Pw dynamic Tag: Twitter description in frontier (500 vs 500) (+)
71. Pw random Tag: Twitter description over frontier (501 vs 500) (-)
72. Pw apriori Tag: Facebook title less than frontier (299 vs 300) (+)
73. Pw dynamic Tag: Facebook title in frontier (300 vs 300) (+)
74. Pw random Tag: Facebook title over frontier (301 vs 300) (-)
75. Pw apriori Tag: Facebook description less than frontier (499 vs 500) (+)
76. Pw dynamic Tag: Facebook description in frontier (500 vs 500) (+)
77. Pw random Tag: Facebook description over frontier (501 vs 500) (-)

Escenarios semanas anteriores mitad playwright, mitad kraken. Todos estos escenarios utilizan datos del pool random, con faker.js

# Tool Pool Nombre
78. Pw random Member fun: Create member (+)
79. Pw random Member fun: Create member with same name (+)
80. Pw random Member fun: Create member invalid email (-)
81. Pw random Member fun: Create member without name (+)
82. Pw random Member fun: Create member duplicate email
83. Pw random Member fun: Create member retry (+)
84. Pw random Member fun: Delete member (+)
85. Pw random Member fun: Filter member (+)
86. Pw random Member fun: Filter member delete (+)
87. Pw random Member fun: Filter member remove label (+)
88. Pw random Post fun: Create post (+)
89. Pw random Post fun: Create post without content (+)
90. Pw random Post fun: Create multiple post with the same title (+)
91. Pw random Post fun: Create post and edit it (+)
92. Pw random Post fun: Create post and delete it (+)
94. Kr random Member fun: Create member (+)
95. Kr random Member fun: Create member with same name (+)
96. Kr random Member fun: Create member invalid email (-)
97. Kr random Member fun: Create member without name (+)
98. Kr random Member fun: Create member duplicate email
99. Kr random Member fun: Create member retry (+)
100. Kr random Member fun: Delete member (+)
101. Kr random Member fun: Filter member (+)
102. Kr random Member fun: Filter member delete (+)
103. Kr random Member fun: Filter member remove label (+)
104. Kr random Post fun: Create post (+)
105. Kr random Post fun: Create post without content (+)
106. Kr random Post fun: Create multiple post with the same title (+)
107. Kr random Post fun: Create post and edit it (+)
108. Kr random Post fun: Create post and delete it (+)

Menú

Clone this wiki locally