Clase 11. Anlisis dinmico, 2 parte.

Continuamos con el mismo tema de la clase anterior, pero esta vez nos ocuparemos principalmente de la fase de prueba. Nos detendremos brevemente en algunas de las nociones bsicas que subyacen en las actividades de prueba y analizaremos las tcnicas ms extendidas. Por ltimo, recopilaremos algunas directrices prcticas para ayudarle en sus propias tareas de prueba.

11.1 Fase de prueba

Si adopta un enfoque sistemtico, la fase de prueba resultar mucho ms efectiva y mucho menos complicada. Antes de empezar, considere los siguientes puntos: qu propiedades desea probar; qu mdulos desea probar y en qu orden; cmo va a generar los casos de prueba; cmo va a comprobar los resultados; cmo sabr si ha terminado. Para decidir qu propiedades desea probar es necesario conocer el dominio del problema, con el fin de saber qu clase de fallos son ms importantes, as como el programa, para saber lo difcil que va a resultar descubrir los tipos de errores. La eleccin de mdulos es ms sencilla. Pruebe sobre todo los mdulos que sean crticos, complejos o que estn escritos por el peor de sus programadores (o por el ms aficionado a utilizar trucos brillantes dentro del cdigo). O tal vez el mdulo que se escribi a altas horas de la noche, o justo antes del lanzamiento El diagrama de dependencia modular sirve para determinar el orden. Si el mdulo depende de otro que an no est implementado, tendr que escribir un stub (o esqueleto de un mdulo) que har el papel del mdulo que est fallando durante la fase de prueba. El stub proporciona el rendimiento necesario para la prueba. Es posible, por ejemplo, buscar respuestas en una tabla en lugar de realizar la computacin verdadera. La comprobacin de los resultados puede resultar complicada. Algunos programas como el Foliotracker que va a construir en los ejercicios 5 y 6 ni siquiera tienen comportamiento repetitivo. En otros, los resultados son slo la punta del iceberg y para comprobar que las cosas marchan bien, ser necesario verificar las estructuras internas. Ms adelante hablaremos de cmo generar casos de prueba y cmo saber cuando el trabajo est completo.

11.2 Pruebas de regresin

Es muy importante ser capaz de volver a ejecutar las pruebas cuando se modifica el cdigo.

Por esta razn, no es buena idea realizar pruebas especficas que no pueden ser repetidas. Puede parecer un trabajo arduo, pero a largo plazo, resulta menos laborioso construir un conjunto prctico de pruebas que pueden ser reejecutadas a partir de un archivo. Es lo que se denomina pruebas de regresin. Un enfoque de la fase de prueba que recibe el nombre de test first programming, y que es parte de la nueva doctrina de desarrollo denominada extreme programming, apuesta por la construccin de pruebas de regresin antes incluso de que se haya escrito el cdigo de aplicacin. JUnit, el marco de pruebas que ha utilizado, fue concebido para esto. La construccin de pruebas de regresin para un sistema grande es una empresa importante. Es posible que slo la ejecucin de los scripts dure una semana. Por lo tanto un rea de investigacin que es muy interesante actualmente es intentar determinar qu pruebas de regresin pueden omitirse. Si sabe qu casos de prueba aplicar a las partes del cdigo, podr determinar que un cambio local en una parte del cdigo no exige que todos los casos sean reejecutados.

11.3 Criterios
Para entender cmo se generan y evalan las pruebas, podemos pensar de manera abstracta sobre la finalidad y la naturaleza de la fase de prueba. Suponga que tenemos un programa P que debe cumplir una especificacin S. Asumiremos, para que sea ms sencillo, que P es una funcin que transforma las entradas de datos en salida de datos, y S es una funcin que recibe una entrada de datos y una salida de datos y devuelve un tipo booleano. Nuestro objetivo al realizar las pruebas es encontrar un caso de prueba t tal que: S (t, P(t)) sea falso: esto es, P produce un resultado para la entrada t que no es permitido por S. Llamaremos a t un caso de prueba fallido, aunque en realidad es un caso de prueba con xito, ya que nuestra finalidad es encontrar errores. Una suite de pruebas T es un conjunto de casos de prueba. Ahora nos hacemos la siguiente pregunta: cundo una suite puede considerarse suficientemente buena? En lugar de intentar evaluar cada suite de forma que dependa de la situacin, podemos aplicar criterios generales. Puede pensar en un criterio como una funcin: C: Suite, Program, Spec ~ Boolean que recibe una suite de pruebas, un programa y una especificacin, y devuelve verdadero o falso de acuerdo con el hecho de que la suite sea suficientemente buena para el programa y la especificacin dados, todo ello de forma sistemtica. La mayora de los criterios no incluyen ambos, el programa y la especificacin. Si slo se incluye el programa se denomina criterio basado en el programa. Tambin se utilizan

trminos como whitebox, clearbox, glassbox, o pruebas estructurales para describir fases de prueba que utilizan criterios basados en programas. Un criterio que slo incluye la especificacin se denomina criterio basado en la especificacin. El trmino blackbox se utiliza en asociacin con este criterio, para dar a entender que las pruebas se juzgan sin que se pueda analizar la parte interna del programa. Tambin se utiliza el trmino pruebas funcionales.

11.4 Subdominios
Los criterios prcticos se inclinan por una estructura y propiedades singulares. Por ejemplo, pueden aceptar una suite de casos T y sin embargo rechazar una suite T que es igual que T pero con algunos casos adicionales. Tambin tienden a no ser sensibles en lo que se refiere a las combinaciones de los casos de prueba escogidas. Estas caractersticas no son, necesariamente, buenas propiedades; simplemente surgen del modo sencillo en que la mayora de los criterios se definen. El dominio de los datos de entrada se divide en subregiones, algunas de las cuales se denominan subdominios, y cada una contiene un conjunto de datos de entrada. Los subdominios juntos engloban todos los dominios de los datos de entrada: esto es, toda entrada est en por lo menos un subdominio. Una divisin del dominio de datos de entrada en subdominios define un criterio implcito: que define que deba existir al menos un caso de prueba para cada subdominio. Por lo general los subdominios no son inconexos, por lo tanto, un nico caso de prueba puede estar en todos los subdominios. La idea que subyace tras el subdominio tiene dos aspectos. En primer lugar, es fcil (al menos conceptualmente) determinar si una suite de pruebas es suficientemente buena. En segundo lugar, esperamos que al exigir un caso de prueba de cada subdominio haremos que las pruebas se orienten a regiones de datos ms propensas a revelar fallos. De forma intuitiva, cada subdominio representa un conjunto de casos de prueba similares; deseamos maximizar el beneficio de la actividad de prueba escogiendo casos de prueba que no sean similares; es decir, casos de prueba que provengan de subdominios diferentes. En el mejor de los casos, un subdominio es revelador, lo que significa que cada caso de prueba que contiene hace que el programa falle o tenga xito. As, el subdominio agrupa casos verdaderamente equivalentes. Si todos los dominios son reveladores, una suite de pruebas que satisfaga el criterio ser completa, ya que tendremos la garanta de que encontrar cualquier fallo. En la prctica, sin embargo, resulta bastante difcil obtener subdominios reveladores, pero escogiendo con cuidado los subdominios es posible tener al menos algn subdominio cuya tasa de error la proporcin de entradas que conducen a salidas de datos errneas sea mucho mayor que la tasa de error media del dominio de datos de entrada como un todo.

11.5 Criterios de subdominio

El criterio ordinario y ms ampliamente utilizado en las pruebas basadas en programa es la

cobertura de sentencias: esto es, que cada sentencia o segmento de un programa deba ejecutarse al menos una vez. Por la definicin, se entiende por qu se trata de un criterio de subdominio: defina para cada sentencia del programa el conjunto de entregas que hacen que se ejecute y escoja al menos un caso de prueba para cada subdominio. Desde luego, el subdominio nunca se construye explcitamente; es una nocin conceptual. En vez de eso, lo que ocurre es que se ejecuta una versin instrumental del programa que registra cada sentencia ejecutada. Debe continuar aadiendo casos de prueba hasta que todas las sentencias sean ejecutadas. Existen ms criterios aparte de la cobertura de sentencias. El denominado cobertura de decisin o de condicin requiere que se ejecuten todas las aristas del grfico de flujo de control del programa: es como exigir que todas las ramas de un programa sean ejecutadas. No est tan clara la razn por la que este enfoque est considerado ms riguroso que la cobertura de sentencias. Piense en la posibilidad de aplicar este criterio a un procedimiento que devuelva el menor de dos valores: static int minimum (int a, int b) { if (a b) return a; else return b; Para este cdigo, la cobertura de sentencias requerir entradas con a menor que b y viceversa. Sin embargo, para el cdigo: static int minimum (int a, int b) { int result = b; if (b a) result = b; return result; un nico caso de prueba con b menor que a satisfar el criterio de la cobertura de sentencias, y el fallo se pasar por alto. La cobertura de decisin requerira un caso en el que el comando if no sea ejecutado, exponiendo de esta forma el fallo. Hay muchas formas de cobertura de condicin que exigen, de diversas formas, que las expresiones booleanas probadas como condicin sean evaluadas tanto para verdadero (true) como para falso (false). Una forma especfica de cobertura de condicin, conocida como MCDC, es exigida por una norma denominada DoD especfica para software de seguridad crtica, como los de aviacin. Esta norma, DO-178B, clasifica los fallos en tres niveles y exige un diferente nivel de cobertura para cada uno: Nivel C: el fallo reduce el margen de seguridad Ejemplo: link de datos va radio Requiere: cobertura de sentencia Nivel B: el fallo reduce la capacidad de la nave o de la tripulacin Ejemplo: GPS

Requiere: cobertura de decisin Nivel A: el fallo provoca la prdida de la nave Ejemplo: sistema de gestin de vuelo Requiere: cobertura MCDC Otra forma comn de criterio de subdominio de tipo basada en programa es la que se utiliza en las pruebas de casos lmite. Esto requiere la evaluacin de los casos lmite de cada condicin. Por ejemplo, si su programa prueba x < n, seran necesarios casos de prueba que produjeran x = n, x = n-1, y x=n+1.

Los criterios basados en especificacin tambin se presentan en trminos de subdominios. Como las especificaciones son por lo general informales esto es, no estn escritas en ninguna notacin precisa los criterios tienden a ser ms vagos. El planteamiento ms comn es definir los subdominios de acuerdo con la estructura de la especificacin y los valores de los tipos de datos subyacentes. Por ejemplo, los subdominios para un mtodo que inserte un elemento en un conjunto pueden ser: el conjunto est vaco el conjunto no est vaco y el elemento no est en el conjunto el conjunto no est vaco y el elemento est en el conjunto

Tambin puede, en la especificacin, utilizar cualquier estructura condicional para guiar la divisin en subdominios. Es ms, en la prctica, los encargados de realizar las pruebas utilizan sus conocimientos al respecto de los tipos de error que muchas veces surgen en los cdigos. Por ejemplo, si est probando un procedimiento que encuentra un elemento en un array, probablemente colocar el elemento al principio, en el medio y al final, simplemente porque estos casos son propensos a ser manipulados de forma diferente en el cdigo.

11.6 Viabilidad
La cobertura total es raramente posible. De hecho, incluso logrando una cobertura de sentencias del 100% es imposible alcanzar la cobertura total. Esta imposibilidad ocurre en razn del cdigo de programacin defensiva, cdigo que, en gran parte, nunca se debera ejecutar. Las operaciones de un tipo abstracto de datos, que no tienen ningn cliente, no se ejecutarn mediante casos de prueba independientemente del rigor aplicado, aunque se pueden ejecutar por pruebas de unidad. Se dice que un criterio es factible si es posible satisfacerlo. En la prctica, los criterios no suelen ser factibles. En trminos de subdominio, contienen subdominios vacos. La cuestin prctica es determinar si un subdominio esta vaco o no; si est vaco, no hay razn para tratar de encontrar un caso de prueba que lo satisfaga. Por regla general, cuanto ms elaborado sea el criterio, ms difcil llega a ser su

determinacin. Por ejemplo, la cobertura de caminos requiere que todos los caminos del programa sean ejecutados. Suponga que tengamos el siguiente programa: if C1 then S1; if C2 then S2; Entonces, para determinar si el camino S1;S2 es factible, necesitamos determinar si las condiciones C1 y C2 pueden ambas ser verdaderas. Para un programa complejo, no se trata de una tarea trivial y, en el peor de los casos, no es ms fcil que determinar la correccin del programa mediante razonamiento. A pesar de estos problemas, la idea de cobertura es muy importante en la prctica. Si existen partes importantes del programa que nunca han sido ejecutadas, ms vale que no confe demasiado en su exactitud!

11.7 Directrices prcticas

Ha de quedar claro por qu ni los criterios basados en programas, ni los basados en especificaciones son, por s solos, suficientes . Si slo se fija en el programa, pasar por alto errores de omisin. Si slo observa la especificacin, no detectar errores que surgen de problemas de implementacin, como, por ejemplo, cuando se alcanzan los lmites de un recurso computacional, caso en que se necesita un procedimiento de compensacin. En la implementacin de la clase ArrayList de Java, por ejemplo, el array de la representacin se sustituye cuando est lleno. Para probar este comportamiento, ser necesario insertar elementos suficientes en la ArrayList para que el array quede lleno. La experiencia sugiere que el mejor modo de realizar una suite de pruebas es utilizar el criterio basado en la especificacin para guiar el desarrollo de la suite y, para evaluar la suite, es mejor que se utilicen los criterios basados en el programa. De este modo, podr examinar la especificacin y definir subdominios de entrada. Basndose en estas premisas, usted puede escribir los casos de prueba. A continuacin, se ejecutan los casos y se mide la cobertura de las pruebas en relacin con el cdigo. Si la cobertura es inadecuada, bastara con aadir nuevos casos de prueba. En un entorno profesional, se utilizara una herramienta especial para medir la cobertura. En este curso, no exigiremos que aprenda a utilizar otra herramienta. En vez de eso, deber escoger casos de prueba suficientemente elaborados para que pueda argumentar que ha alcanzado una cobertura considerable del cdigo. Las certificaciones en tiempo de ejecucin, sobre todo las que representan comprobaciones de invariante, aumentarn de manera espectacular la fuerza de sus pruebas, esto es, podr hallar ms fallos con menos casos y ser capaz de solucionarlos ms fcilmente.