IEEE 829 STANDARD: ESPECIFICACIONES DEL MODELO DE DISEÑO DE PRUEBA

Identificador de la prueba especificación de diseño Características para ser probados Enfoque refinamientos Comprobación de las funciones de identificación pasa / falla criterios

4.1.4 Prueba de diseño: Especificación de casos de prueba

Condiciones de prueba pueden ser bastante vaga, que cubre toda una amplia gama de posibilidades como vimos en nuestro ejemplo empresa de telefonía móvil (por ejemplo, un adolescente en el mediano oeste), o una condición de prueba pueden ser más específicos (por ejemplo, un cliente particular, masculino en pago por uso con menos de $ 10 de crédito). Sin embargo, cuando llegamos a hacer un caso de prueba, estamos obligados a ser muy específico; de hecho, ahora tenemos entradas específicas detalladas, no descripciones generales (por ejemplo, Jim Green, de 17 años, la vida en Grand Rapids, Michigan, con el crédito de $ 8,64, resultado esperado: añadir a Q4 campaña de marketing). Tenga en cuenta

que un caso de prueba cubre una serie de condiciones (Adolescente, varón, medio oeste zona, pago por uso, y el crédito de menos de $ 10).

Para una condición de prueba de "un cliente existente ', la entrada de caso de prueba debe ser 'Jim Green', donde Jim Green ya existe en la base de datos del cliente, o parte de esta prueba podría ser la creación de un registro de base de datos para Jim Green.

¡Un caso de prueba debe tener valores de entrada, por supuesto, pero sólo tener algunos valores a la entrada del sistema no es una prueba! Si usted no sabe lo que el sistema de apoyo plantea ver con las entradas, no se puede decir si la prueba es aprobada o no. ¿En caso de que estos casos de prueba detallados sean escritos? Pueden estar formalmente documentados, como describiremos a continuación. Sin embargo, es posible probar sin documentar un nivel de casos de prueba. Si das una aceptación del usuario experimentado tester con un fuerte conocimiento de los negocios una lista de condiciones de prueba de alto nivel, que probablemente podría hacer un buen trabajo de la prueba. Pero si usted le dio la misma lista para un nuevo testers que no conocía el sistema en absoluto, probablemente se perderá, por lo que se beneficiaría de tener casos de prueba más detallados.

Los casos de prueba se pueden documentar como se describe en el estándar IEEE 829 estándar para Documentación de prueba. Tenga en cuenta que el contenido descrito en la norma no todos lo hacen tienen que ser documentos físicos separados. Pero la lista de la norma de lo que necesita pista de mantenerse es un buen punto de partida, incluso si las condiciones de prueba y casos de prueba para una funcionalidad o característica dada mantienen todas en un solo documento físico.

Uno de los aspectos más importantes de un instrumento es que se evalúa que el sistema hace lo que se supone que debe hacer. Copeland dice 'En su esencia, la prueba es el proceso de la comparación de "lo que es" con "lo que debería ser" '. [Copeland, 2003] ¡Si nos limitamos a algunas entradas y pensar ‘que fue muy divertido, supongo que el sistema es probablemente correcto porque no se había estrellado “, ¡entonces esta es realmente una prueba! Nosotros no lo creemos. han observado que el sistema hace lo que hace, esto no es una prueba.

Boris Beizer refiere a esto como "la prueba para niños '[Beizer, 1990]. Puede que no sepamos lo que es la respuesta correcta en detalle cada vez, y todavía puede obtener algún beneficio de este enfoque a veces, pero no es realmente una prueba.

Con el fin de saber lo que el sistema debe hacer, tenemos que tener una fuente de información sobre el comportamiento correcto del sistema, esto se llama un "oráculo" o un oráculo de pruebas.

Esto no tiene nada que ver con las bases de datos o empresas que los fabrican. Viene de el griego antiguo oráculo de Delfos, que supuestamente podía predecir el futuro con infalible precisión. En realidad, sus respuestas eran tan vagas que la gente los interpretarse en la forma que querían tal vez un poco como especificaciones de requisitos!

Una vez que un determinado valor de entrada ha sido elegido, el testers necesita determinar qué resultado se espera de esa entrada y documentarla como parte del caso de prueba.

Los resultados esperados incluyen información que aparece en una pantalla en respuesta a una entrada, sino que también incluyen cambios en los datos y / o estados, y cualquier otra consecuencia de la prueba (por ejemplo, una carta a imprimirse durante la noche).

¿Qué pasa si no tomamos una decisión en los resultados esperados antes de correr una prueba? Podemos echar un vistazo a lo que produce el sistema y probablemente notará si algo era absolutamente incorrecta. Sin embargo, probablemente no notar pequeñas diferencias en cálculos o resultados que parecían mirar bien (es decir, son plausibles). De modo que lo haría concluir que la prueba había pasado, cuando en realidad el software no ha dado el resultado correcto. Las pequeñas diferencias en un cálculo pueden sumar a algo muy importante más adelante, por ejemplo, si los resultados se multiplican por un factor grande.

Lo ideal sería que los resultados esperados se pueden predecir antes de que se ejecute la prueba a continuación, su evaluación de si o no el software hizo lo correcto será más objetiva.

Para algunas aplicaciones puede que no sea posible predecir o saber exactamente un resultado esperado; que sólo podemos hacer un «control de razonabilidad '. En el caso de que tengamos un "oráculo parcial" sabemos cuándo algo está muy mal, pero probablemente tendría que aceptar algo que parecía razonable. Un ejemplo es cuando un sistema ha sido escrito para calcular algo donde puede que no sea posible producir manualmente los resultados esperados en un plazo de tiempo razonable porque los cálculos son tan complejos.

Además de los resultados esperados, en el caso de prueba también se especifica el entorno y otras cosas que deben estar en su lugar antes que la prueba se puede ejecutar (la pre- condiciones) y las cosas que deberían aplicarse cuando finalice la prueba (la pos- condiciones).