1 / 20

The Art of Software testing

The Art of Software testing. MYERS. Saquen una hoja. Escribir un conjunto de casos de prueba, un conjunto de datos que van a testear bien el siguiente programa.

odette
Download Presentation

The Art of Software testing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. The Art of Software testing MYERS

  2. Saquen una hoja ... • Escribir un conjunto de casos de prueba, un conjunto de datos que van a testear bien el siguiente programa. • El programa lee tres enteros. Los tres valores representan la medida de los lados de un triángulo. El programa imprime un mensaje que determina si el triángulo es esacaleno, isóceles o equilátero.

  3. Evaluar el conjunto de los casos de prueba • Un caso de prueba que representa un triángulo válido • escaleno (1,2,3 / 2,5,10) • equilátero • isósceles (2,2,4) • Al menos tres casos de una posibilidad válida, en donde se permuten los datos (3,3,4 4,3,3 3,4,3) • uno con un 0 • uno con un valor negativo FI: En todo triángulo un lado es menor que la suma de los otros dos y mayor que su diferencia

  4. Evaluar el conjunto de los casos de prueba • la suma de dos de los números es igual al tercero (1,2,3) • idem anterior + la permutación de lugar • la suma de dos de los números es menor al tercero (1,2,4) • idem anterior + permutación del lugar • (0,0,0) • números no enteros • valor erróneo (asdfk dfjka aldj) • para cada caso de prueba especificó la salida

  5. Evaluar el conjunto de los casos de prueba Buenos programadores 7 u 8, entre 14

  6. Casos de Prueba • Caso de prueba son un conjunto de datos de entrada que me permiten obtener un valor de salida del sistema. • El objetivo es hallar cuál es el subconjunto de todos los casos de prueba que tiene una mayor probabilidad de detectar errores.

  7. Test de Unidad • Tipos • Caja Blanca • statement coverage • Decision coverage • decision / condition coverage • Multiple-condition coverage • Caja Negra • partición equivalente • análisis de los valores límites • Grafo de causa efecto • adivinación/suposición de errores

  8. Caja Blanca A > = 20 B

  9. Caja Blanca • Testeo exhaustivo de caminos o testeo exhaustivo de entradas • Imposibilidad real de hacerlo • No asegura la corrección del programa • No necesariamente machea las especificaciones • Pueden faltar caminos • Errores que se manifiestan dependiendo de los datos que estemos usando • Si bien el testeo exhaustivo de entradas es superior al testeo exhaustivo de caminos, ninguna de las dos estrategias son convenientes.

  10. Caja Blanca / Statement Coverage a v c X=X/A A>1 AND B=0 A B X 2 0 3 ace f b v e A=2 OR X>1 X=X+1 f d

  11. Caja Blanca / Decision / Coverage a v c X=X/A A>1 AND B=0 A B X 3 0 3 2 1 1 acd abe f b ve A=2 OR X>1 X=X+1 Si AND en vez de OR f d

  12. Caja Blanca / Decision/ Condition Coverage a A>1 A<=1 B=0 B=/0 A=2 A=/2 X>1 X<=1 c X=X/A A>1 AND B=0 b e A=2 OR X>1 X=X+1 A B X 2 0 4 1 1 1 ace abd d

  13. Caja Blanca / Condition Coverage A>1 A<=1 B=0 B=/0 A=2 A=/2 X>1 X<=1 a c X=X/A A>1 AND B=0 A B X 1 0 3 2 1 1 b abe abe e A=2 OR X>1 X=X+1 d

  14. Caja Blanca / Multiple Condition Coverage A B A X >1 =0 2 >1 >1 =/0 2 <=1 <=1 =0 =/2 >1 <=1 =/0 =/2 <=1 a c X=X/A A>1 AND B=0 b A B X 2 0 4 2 1 1 1 0 2 1 1 1 e A=2 OR X>1 X=X+1 d

  15. Caja Negra / Partición equivalente • Maximizar el número de errores encontrados en un número finito de casos de prueba • Incluir la mayor cantidad posible de condiciones de entrada en los casos de prueba para minimizar el número total de casos de prueba • Se debe tratar de particionar los dominios de las entradas del programa en un número finito de clases equivalentes (el test del valor representativo es equivalente al test de cualquier otro valor) • Se deben definir las clases equivalentes válidas y las no válidas

  16. Caja Negra / Partición Equivalente Identificación de los los casos de prueba a partir de la entrada • Rango de valores • una clase equivalente válida • dos clases inválidas • Número de valores • una clase equivalente válida • dos clases inválidas • Conjunto de valores de entradas, manejados en forma diferente por el programa • uno válido y otro inválido • “debe ser” • uno válido y otro inválido

  17. Caja Negra / Análisis de Valores límites • Un rango de valores para la entrada / salida • caso de prueba para los extremos del intervalo • caso de pruebas inválidos alrededor de los extremos • Un número de valores entrada / salida • un caso de prueba para el máximo y otro para el mínimo • un caso de prueba en los alrededores del número • Si la entrada o salida es un conjunto ordenado • focalizarse en el primero y último elemento

  18. Caja Negra / Grafo de causa efecto • Explora las circunstancias en donde se dan combinaciones de las entradas • Tabla de Decisión • Causas son las entradas • Efectos son las salidas • Columnas de la Tablas son los casos de Prueba

  19. Recomendación • Se recomienda hacer casos de testeo usando los métodos de caja negra y después desarrollar casos de testeo suplementarios de caja blanca, cuando sea necesario.

  20. Recomendación • Si las especificaciones contienen combinaciones de las entradas, comenzar con un grafo de causa efecto • Siempre usar análisis de los valores límites (entrada o salida), completando el anterior • Completar los casos de prueba, identificando las clases equivalentes para las entradas y las salidas. Usar suposición de errores para agregar adicionales casos de prueba • Examinar los casos de prueba considerando la lógica del programa.

More Related