Hola a todos,

 

Mi propósito con este artículo es que a la siguiente función le diseñemos casos de prueba con base en las técnicas de pruebas de software que hemos visto:

 

LPCTSTR Open(LPCTSTR lpFilePath)

{

. . .

}

 

Dada la firma del método anterior, la pregunta es: ¿con que casos lo probaría?, lo primero que debemos tener en cuenta es reducir la ambigüedad por lo cual deberíamos responder la pregunta con otra pregunta ¿qué quiere probar exactamente?, seguramente obtendríamos la siguiente información:

 

·         Requerimientos Funcionales:      

  • Abrir el texto de un archivo.

·         Requerimientos No Funcionales:

  • El texto a ser retornado puede ser de máximo 1 Mb.
  • El método se ejecuta de forma asíncrona.
  • El método bloquea el archivo mientras esta siendo leído.
  • La latencia es de 15 seg.
  • El formato de la ruta debe ser el estándar de DOS; por ejemplo C: \holamundo.txt con un máximo de 256 caracteres.
  • El sistema operativo soportado debe ser Windows XP Professional en idioma inglés.

 

Con los requerimientos anteriores ya tenemos muchas más pistas de por donde empezar, como pueden estar pensando es un error muy común suponer demasiado, por lo cual es mejor aclarar la mayor cantidad de detalles.  La estrategia que recomiendo para empezar diseñar casos de prueba, es definir las tres dimensiones que deberían tener las pruebas: nivel, punto de vista y técnicas.

 

 

 

El nivel puede ser sistema, integración y unidad; en este caso el nivel será unidad porque el método no puede ser dividido en más partes. Los puntos de vista pueden ser: caja negra, blanca y gris; para nuestro ejemplo el punto de vista es gris porque conocemos algunos detalles de implementación (como los parámetros).

 

Con el nivel y el punto de vista definidos podemos elegir las técnicas de prueba. Para probar la funcionalidad podríamos seleccionar las siguientes técnicas:

·         Aleatoria: con esta técnica podríamos buscar una herramienta de generación de datos para generar rutas erróneas de 256 caracteres y verificar si la aplicación falla o advierte sobre el formato de la ruta.

·         Oráculo: con esta técnica deberíamos seleccionar una aplicación que tenga una funcionalidad semejante para considerarla verdadera (un oráculo) y compararlo con nuestro método.

·         Partición equivalente: con esta técnica definimos unos conjuntos de datos equivalentes (iguales) para probar, es decir si nos dicen que se van a trabajar con archivos hasta de 1 Mb., nos daría igual hacer mil pruebas de 1 KB hasta 1 Mb ó simplemente hacer una prueba de 1 Mb. porque los demás datos son equivalentes.

 

Para probar la estructura del método podríamos seleccionar las siguientes técnicas:

·         Inyección de fallos: con esa técnica enumeramos los escenarios de fallos, es decir rutas de más de 256 caracteres o rutas de archivos que no existan

·         Cobertura de código a nivel de función: todas las pruebas se ejecutarían con la métrica de cobertura de código de función debido a que no conocemos la cantidad de líneas.

 

Adicionalmente podríamos probar las siguientes calidades sistémicas:

·        Manifiestas: rendimiento (para verificar los 15 segundos de latencia), estrés (para superar el límite de 1 Mb.), carga (para probar que no contempla concurrencia), disponibilidad y confiabilidad.

·         Operacionales: seguridad en la integridad de los datos y compatibilidad con la configuración de software descrita.

·         Evolutivas: globalización para comprobar la correcta compilación y ejecución en idioma inglés.

 

Bueno espero que el ejemplo anterior les aclare una forma práctica de organizar los casos de prueba basado en las técnicas de prueba.