Técnicas y métodos de pruebas

Plática dada en grupos privados sobre algunos problemas inherentes al diseño, implementación y ejecución de pruebas de software, así como algunas técnicas para abordarlos.

Transcript

1. Técnicas y métodos de Pruebas Agustín Ramos @MachinesAreUs Enero 2017
2. Así que ya te decidiste a hacer pruebas automatizadas… • Unitarias • De integración • De aceptación / funcionales • De desempeño Solo tengo que decir…
3. Yarrrr so coool !!!
4. Ya te vi…
5. Algún día…
6. Tú
7. ¿Qué dificultades te has encontrado al implementar pruebas? • Toma su tiempo. • Requiere el uso de varios frameworks y técnicas. • Aumenta la cantidad de código que se tiene que escribir. • Hace que el ‘build’ sea más lento. • etc, etc,
8. ¿Y qué pasa si no automatizas pruebas? Cada que quiero probar una funcionalidad / cambio: • Tengo que levantar toda la aplicación / ambiente. • Tengo que seguir el flujo que me lleva a la llamada a mi función / método. • Depende de las configuraciones de mi máquina. Ahora imagina lo mismo para todas las funciones del sistema
9. El problema del testing
10. Ejemplo 1 ¿Cuántos diferentes casos de prueba se necesitan para probar ésta interfaz?
11. Ejemplo 2 ¿Cuántas pruebas necesita ésta función? function partition(items, left, right) { var pivot = items[Math.floor((right + left) / 2)], i = left, j = right; while (i <= j) { while (items[i] < pivot) { i++; } while (items[j] > pivot) { j--; } if (i <= j) { swap(items, i, j); i++; j--; } } return i; }
12. Ejemplo 2 ¿Cuántos tipos de pruebas necesita esta función? function partition(items, left, right) { var pivot = items[Math.floor((right + left) / 2)], i = left, j = right; while (i <= j) { while (items[i] < pivot) { i++; } while (items[j] > pivot) { j--; } if (i <= j) { swap(items, i, j); i++; j--; } } return i; }
13. • Valores en rangos esperados • Condiciones de frontera. • Valores no esperados (e.g. nulos) • Combinaciones de los anteriores • Valores que ejerciten las distintas rutas. ¿Cuántos tipos de pruebas necesita esta función?
14. function partition(items, left, right) { var pivot = items[Math.floor((right + left) / 2)], i = left, j = right; while (i <= j) { while (items[i] < pivot) { i++; } while (items[j] > pivot) { j--; } if (i <= j) { swap(items, i, j); i++; j--; } } return i; } ¿Cuántas rutas de ejecución tiene este programa?
15. Complejidad Ciclomática • Métrica. • Thomas J. McCabe, 1976 • Mide el número de rutas de ejecución linealmente independientes dentro de un programa. • Formalmente M = E − N + 2P • Aproximador: 2^N - 1 donde N es el número de bifurcaciones en el código (bloques if, where, for, etc.)
16. function partition(items, left, right) { var pivot = items[Math.floor((right + left) / 2)], i = left, j = right; while (i <= j) { while (items[i] < pivot) { i++; } while (items[j] > pivot) { j--; } if (i <= j) { swap(items, i, j); i++; j--; } } return i; } ¿Cuántas rutas de ejecución tiene este programa? 2^4 = 16 Necesitas aproximadamente 16 distintos casos de prueba, solo para saber que pasaste por todas las rutas de ejecución posibles
17. Entonces… ¿Cuándo vas a acabar de probar?
18. Para empezar… ¿Cómo sabes que has probado lo suficiente?
19. ¿Cobertura? (de líneas de código)
20. Cobertura “Tenemos cobertura a nivel de código superior al 90%, lo cual es indicador de nuestro alto nivel de calidad”
21. El que una línea de código que está “cubierta” (se ha ejecutado durante una prueba)…. no me dice nada del contexto en el cual se ejecutó (e.g. los parámetros de entrada de la función, el número de iteración si se encuentra dentro de un bloque, etc), y por lo tanto no me dice que no puede fallar o tener un comportamiento distinto en un contexto distinto. Cobertura
22. ¿Cuál es el PEX? Explosión combinatorial
23. Data Driven Testing (DDT)
24. Data Driven Testing • El mismo código de prueba • Muchos casos con diferentes entradas/ salidas. Test
25. DDT en Spock class Math extends Specification { def "maximum of two numbers”() { expect: Math.max(a, b) == c where: a | b || c 1 | 3 || 3 7 | 4 || 4 0 | 0 || 0 } }
26. DDT en Cucumber Feature: Addition I want to be told the sum of two numbers Scenario Outline: Add two numbers Given I have entered <input_1> into the calculator And I have entered <input_2> into the calculator When I press <button> Then the result should be <output> on the screen Examples: | input_1 | input_2 | button | output | | 20 | 30 | add | 50 | | 2 | 5 | add | 7 | | 0 | 40 | add | 40 |
27. ¿De dónde salen los casos? • A mano. • En general, no acabas. • ¿Cómo sabes que son suficientes? • ¡Son solo los que se te ocurren! • Generación automatizada. • Random. • ¿Cómo sabes que son suficientes? • Todas las posibles combinaciones de entradas/condiciones…
28. N-wise testing
29. Pairwise testing “Pairwise (a.k.a. all-pairs) testing is an effective test case generation technique that is based on the observation that most faults are caused by interactions of at most two factors. Pairwise-generated test suites cover all combinations of two therefore are much smaller than exhaustive ones yet still very effective in finding defects.” http://www.pairwise.org/ most ~ > 90 %
30. Ejemplo de Pairwise Testing http://www.pairwise.org/tools.asp
31. Pairwise Testing Pairwise Testing In The Real World
32. Pruebas Basadas en Riesgos
33. Pruebas Basadas en Riesgos • Dados recursos finitos ¿cómo escoger qué probar más y qué menos? • Estrategia: • Objetivo: Encontrar los defectos más importantes tan pronto como sea posible y con el menor costo. • Decisión de proyecto, dirigida por objetivos de negocio.
34. ¿Qué es el Riesgo?
35. Pruebas Basadas en Riesgos La fórmula R(f) = P(f) * C(f) R(f) - Riesgo calculado de la función f P(f) - Probabilidad de falla de la función f C(f) - Costo de falla de la función f
37. Pruebas Basadas en Riesgos • Formulación original (James Bach): http://www.satisfice.com/articles/hrbt.pdf • Presentación (con más tips): http://www.cs.tut.fi/tapahtumat/testaus04/schaefer.pdf