El documento discute diferentes tipos y técnicas de pruebas de software, incluyendo pruebas basadas en valores de entrada, condiciones de frontera, valores no esperados, combinaciones de pruebas, rutas de ejecución, cobertura de código, pruebas guiadas por datos, pruebas pairwise, y pruebas basadas en riesgos. El autor argumenta que la cobertura de código por sí sola no es suficiente y que se deben considerar factores como los valores de entrada y las rutas de ejecución para realizar pruebas efectivas.

1. ¿En qué la estamos regando
en pruebas de software?
Agustín Ramos
@MachinesAreUs

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;
}

3. ¿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;
}

4. ¿Cuántos tipos de pruebas necesita esta función?
Valores en rangos esperados
Condiciones de frontera.
Valores no esperados (e.g. nulos)
Combinaciones de los anteriores
Valores que ejerciten las distintas rutas.

5. ¿Cuántas rutas de ejecución tiene este
programa?
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;
}

6. 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.)

7. Entonces…
¿Cuándo vas a acabar de probar?

8. Para empezar…
¿Cómo sabes que has probado lo
suficiente?

9. ¿Cobertura?

10. Cobertura
“Tenemos cobertura a nivel de código superior al 90%,
lo cual es indicador de nuestro alto nivel de calidad”

11. ¿Cobertura?
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.

12. ¡A trabajar!

13. Data Driven Testing
(DDT)

14. Data Driven Testing
Same test
Many input/output
pairs.
Test

15. 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
|

16. DDT en Spock
class HelloSpock extends spock.lang.Specification {
def "length of Spock's and his friends' names"() {
expect:
name.size() == length
!
where:
name | length
"Spock" | 5
"Kirk" | 4
"Scotty" | 6
}
}

17. ¿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…

18. ¿Cuál es el P.E.X?
Explosión combinatorial

19. N-wise testing

20. 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 %

21. Ejemplo de Pairwise Testing
http://www.pairwise.org/tools.asp

22. Pairwise Testing
Pairwise Testing In The Real World

23. Pruebas Basadas en Riesgos

24. 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.
No hay riesgo => No hay pruebas.
Decisión de negocio

25. ¿Qué es el Riesgo?
!

26. 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

27. Análisis de Riesgos + Pruebas
!

28. 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

29. Property-Based Testing

30. Property-Based Testing
Si tenemos una función
reverse :: String -> String
Entonces una propiedad puede definirse como:
reverse (reverse xs) == xs
Y podemos permitir que herramientas como
QuickCheck generen “aleatoriamente" ejemplos de xs y
verifiquen que estos ejemplos cumplan con la propiedad

31. Property Based …
+
PairWise Testing?

32. Complexity Brings More
Complexity

33. … and “More is Different”
Phillip Anderson
Science, Vol. 177, No. 4047, 1972

34. Test me M@#3rfvkc3R
Test this M@+3rfükC3r !

35. Architecture Testing

36. Testing /= Checking
!
http://www.developsense.com/blog/2009/08/testing-vschecking/

37. Test Data Generation
!
https://gist.github.com/MachinesAreUs/
d236e9ca726dd554dad0