Viene de Parte 3

#

Variable

Variable

Variable

Condición 1

Condición 1

 

l

MIN_LEN

MAX_PATH

l<MIN_LEN

l>MAX_PATH

 

l

MIN_LEN

MAX_PATH

l=MIN_LEN

l>MAX_PATH

1

l

MIN_LEN

MAX_PATH

l>MIN_LEN

l>MAX_PATH

 

l

MIN_LEN

MAX_PATH

l<MIN_LEN

l=MAX_PATH

 

l

MIN_LEN

MAX_PATH

l=MIN_LEN

l=MAX_PATH

2

l

MIN_LEN

MAX_PATH

l>MIN_LEN

l=MAX_PATH

3

l

MIN_LEN

MAX_PATH

l<MIN_LEN

l<MAX_PATH

4

l

MIN_LEN

MAX_PATH

l=MIN_LEN

l<MAX_PATH

5

l

MIN_LEN

MAX_PATH

l>MIN_LEN

l<MAX_PATH

La cláusula numero 2 tiene un operador y dos variables que permiten diseñar los siguientes tres casos de prueba:

#

Variable 1

Variable 2

Condición 1

1

size.LowPart

MAX_FILE_SIZE

size.LowPart>MAX_FILE_SIZE

2

size.LowPart

MAX_FILE_SIZE

size.LowPart=MAX_FILE_SIZE

3

size.LowPart

MAX_FILE_SIZE

size.LowPart

Para tener una cobertura de código del 100% de las decisiones deberíamos hacer 16 casos de prueba (8 + 5 + 3). 

La última técnica estructural es el Path testing, con esta técnica buscamos recorrer todos los flujos de control presentes en el código; observando el CFD anterior podemos concluir que para tener una cobertura del 100% de los paths deberíamos hacer 8 casos de prueba.

Pruebas No Funcionales.

Para diseñar casos de prueba no funcionales, debemos investigar cuáles son los requerimientos no funcionales porque en el enunciado inicial no se mencionó nada sobre el tema. Debemos recordar que un requerimiento no funcional como “el método LoadFile debe ser rápido” no sirve para nada, porque no es medible y por lo tanto no podemos compararlo con nada. Un requerimiento funcional podría ser el método debe ejecutarse en 0.0000005 milisegundos. Las técnicas no funcionales incluyen pruebas de performance, stress, seguridad, usabilidad, accesibilidad y compatibilidad; en nuestro caso la usabilidad y accesibilidad no son importantes porque no tenemos interfaces de usuario finales.

 

Para medir el rendimiento y asegurarnos que cumple el requerimiento, podemos desarrollar nuestro propio código de prueba como el que sigue a continuación:

      time_t dt1;

      time(&dt1);

 

      char* fileContent=LoadFile(“C:\\doc.txt”, “rb+”,  GENERIC_READ, OPEN_EXISTING);

 

      time_t dt2;

      time(&dt2);

 

      double elapsedTime=difftime(dt1, dt2);

Otra opción es utilizar contadores de rendimiento junto con la herramienta Performance Monitor. Para las pruebas de stress, observamos que la función maneja archivos hasta de MAX_FILE_SIZE bytes, por lo cual hacemos pruebas que excedan ampliamente ese límite para ver el comportamiento, también podemos consumir la función de forma continua por largos periodos (por ejemplo toda una noche) para verificar que no degrade la memoria de la máquina.

 

Para hacer pruebas de seguridad nos podríamos concentrar en los bytes que se están leyendo del archivo, sin embargo como no es un requerimiento, solo buscamos las áreas expuestas por nuestra aplicación (por ejemplo: el puntero char* de retorno podría ser empleado para corromper el funcionamiento del método, por lo cual una recomendación o bug al respecto es sugerir un cambio en el diseño para que la memoria sea colocada y destruida por el consumidor).

 

En cuanto a compatibilidad, debemos investigar en que máquinas (32 ó 64 bits) debe correr el método, cuáles tipos de archivos se debe leer, que tipos de rutas de archivos están soportadas (rutas locales, rutas de red, URL’s, etc.); las respuestas a todas estas preguntas nos darán un número de casos de prueba proporcionales.

Las pruebas no funcionales como están basadas en requerimientos, deben ser definidas desde el diseño para mejorar el nivel de “testability” del código; existen muchas herramientas y posibles sets de pruebas, sin embargo solo nos enfocamos en las preguntas más básicas que se deben responder.

 

Conclusión.

Usualmente nos concentramos en las pruebas funcionales y dejamos a un lado otros aspectos inherentes a nuestro software, como la estructura del código y los requerimientos no funcionales. Si probamos eficientemente nuestro software, la calidad aumentará y como resultado, la satisfacción del cliente también. En total diseñé 71 casos de prueba.

Javier Andrés Cáceres Alvis
MVP WIndows Mobile
http://speechflow.spaces.live.com/
http://software.intel.com/en-us/blogs/author/javierandrescaceres/