Casos de prueba de aceptación de escritura

14

Estamos integrando un proceso de prueba en nuestro proceso SCRUM. Mi nuevo rol es escribir pruebas de aceptación de nuestras aplicaciones web para automatizarlas más tarde. He leído mucho sobre cómo se deben escribir los casos de prueba, pero ninguno me dio consejos prácticos para escribir casos de prueba para aplicaciones web complejas, y en su lugar arrojaron principios contradictorios que me resultaron difíciles de aplicar:

  • Los casos de prueba deben ser cortos: Tome el ejemplo de un CMS. Los casos de prueba cortos son fáciles de mantener e identificar las entradas y salidas. Pero, ¿qué sucede si deseo probar una larga serie de operaciones (por ejemplo, agregar un documento, enviar una notificación a otro usuario, el otro usuario responde, el documento cambia de estado, el usuario recibe un aviso)? Me parece que los casos de prueba deberían representar escenarios completos. Pero puedo ver cómo esto producirá documentos de prueba abiertamente complejos.

  • Las pruebas deben identificar entradas y salidas: : ¿Qué pasa si tengo un formulario largo con muchos campos que interactúan, con diferentes comportamientos? ¿Escribo una prueba para todo o una para cada una?

  • Los casos de prueba deben ser independientes: ¿Cómo puedo aplicar eso si la operación de carga requiere que la operación de conexión sea exitosa? ¿Y cómo se aplica a la escritura de casos de prueba? ¿Debo escribir una prueba para cada operación, pero cada prueba declara sus dependencias, o debo reescribir todo el escenario para cada prueba?

  • Los casos de prueba deben estar ligeramente documentados: Este principio es específico de los proyectos Agile. Entonces, ¿tienes algún consejo sobre cómo implementar este principio?

Aunque pensé que escribir los casos de prueba de aceptación iba a ser simple, me sentí abrumado por cada decisión que tenía que tomar (FYI: soy un desarrollador y no un evaluador profesional). Entonces, mi pregunta principal es: ¿Qué pasos o consejos tiene para escribir casos de prueba de aceptación para aplicaciones complejas? Gracias.

Editar : para aclarar mi pregunta: soy consciente de que las pruebas de aceptación deben comenzar desde el requisito y considerar la aplicación completa como una caja negra. Mi pregunta se relaciona con los pasos prácticos para escribir el documento de prueba, identificar los casos de prueba, lidiar con las dependencias entre pruebas ... para aplicaciones web complejas

    
pregunta H-H 12.02.2011 - 00:02

4 respuestas

5

En mis suites de aceptación me he abstenido de usar controles específicos de la tecnología, es decir, para las aplicaciones web, no use css, no use elementos html si necesita completar un formulario. pruebas de aceptación

Uso pepino para mi aceptación y tengo lo siguiente

Given A xxx 
And I am on the xxx page
And a clear email queue
And I should see "Total Payable xxxx"
And I supply my credit card details
When I the payment has been processed
Then my purchase should be complete
And I should receive an email
When I open the email with subject "xxx"
Then I should see the email delivered from "xx"
And there should be an attachment of type "application/pdf"
And attachment 1 should be named "xxxx"
And I should be on the xxx page
And I should see my receipt

este ejemplo es devuelto por una aplicación web, pero aún puedo usar la prueba para probar contra una aplicación de escritorio, ya que los pasos se usan para configurar el SUT, no las pruebas de aceptación

esta prueba se encuentra al final de una compra que va

Generar - > Confirmar - > Pago - > Imprimir recibo

la prueba anterior es para el paso de pago, los otros pasos se configuran en otras pruebas Debido a que la aplicación puede configurarse en estos estados con datos o acciones http en este caso, el pago tiene un valor determinado que realiza los pasos de confirmación y el de confirmación genera los pasos para que sean un poco frágiles en el momento

    
respondido por el ssmithstone 12.02.2011 - 15:11
2

Primero debe definir Pruebas de aceptación .

Lo que parece describir es integración o pruebas del sistema .

Entonces, aunque no estoy 100% de acuerdo con las definiciones de wikipedia, todavía son válidas en gran medida.

Básicamente, el propósito de las pruebas de aceptación es verificar que los procesos "comerciales" que hacen uso del software que usted construyó realmente funcionan según lo previsto y se ajustan a su propósito, con datos de la vida real. Entonces, como tal, no construyes casos de prueba como haces pruebas de unidad o el resto. No se supone que se diseñe de la misma manera.

La pregunta que debe hacerse es "¿Cómo se usa el sistema?". Así que vamos a probarlo de la manera que se supone que debe ser utilizado. Por supuesto, ahora vuelve a poner su sombrero de ingeniería y cumple con los requisitos comerciales para derivar sus casos de prueba. Eso supone que tiene requisitos comerciales bien escritos.

Si no lo hace, no es demasiado tarde, debe sentarse con el usuario (s) o sus representantes (y el analista de negocios y la persona de diseño técnico) y escribir lo que esperan que el software entregue en términos comerciales (con la obvia advertencia de que esto es demasiado poco demasiado tarde, pero es mejor comenzar tarde que nunca, y por supuesto no introducir nuevas funciones). Esto es lo que serán sus casos de prueba.

Otra forma de hacerlo (nuevamente, si tiene un documento de este tipo) es revisar el manual del usuario. Aunque este es un paso eliminado de los requisitos comerciales reales, solo debe usarse si todo lo demás falla.

Cuando vas a comprar un automóvil, generalmente no profundizas mucho debajo del capó (a menos que seas un mecánico de automóviles). Solo te sientas al volante y verificas la comodidad, la facilidad de uso, el aspecto, los sonidos ... es decir, las cosas generales. Por lo general, confía en que si el automóvil estuviera en sus manos en primer lugar (al menos para un automóvil nuevo), en general es seguro y está bien construido (existe una garantía, usted ha hecho el trabajo de su casa y miró las especificaciones). ...). Así que ahora verifica si este es el automóvil que querrá conducir durante los próximos años.

Lo mismo con el software.

    
respondido por el asoundmove 12.02.2011 - 06:39
1

La información conflictiva puede ser frustrante y difícil de generalizar y aplicar a su situación específica. Ergo, es posible que tengas que hacer lo que mejor funcione en tu contexto.

No soy un gran fanático de los documentos de prueba largos, y he usado elementos visuales con bastante eficacia para algunos proyectos más pequeños. ¿Trata eso? ¿Como un diagrama de flujo (o cualquier otro diagrama UML como un diagrama de estado, etc.) en lugar de usar solo texto? Indique entradas, salidas, condiciones, bucles, carriles, estados, interacciones con otros componentes, etc., y luego indique si son exitosos, fallidos, transferidos, otros (?) Según sus criterios.

Puede ser un poco de trabajo al principio, pero puede ayudarte a mantenerte sano a largo plazo. Cualquiera que sea el método que elija, cuanto más trabaje con él, mejor lo logrará.

HTH, y buena suerte!

KM

    
respondido por el KM. 12.02.2011 - 01:33
0

Creo que ya has definido algunos buenos criterios. Su segundo punto es una buena manera de definir los ámbitos para sus pruebas, y sugiero también probar las condiciones de error y bufixes (defiendo que cada corrección de errores venga con al menos una nueva prueba de unidad). Puede parecer abrumador ahora, pero simplemente sumérgete, y después de adquirir un poco de experiencia, reconocer lo que hace que las buenas pruebas sean más fáciles.

    
respondido por el smithco 12.02.2011 - 01:32

Lea otras preguntas en las etiquetas