Pruebas de Software

Antes de la aplicacin de mtodos para el diseo de casos de prueba efectivos, un ingeniero del software deber entender los principios bsicos que guan las pruebas del software. A todas las pruebas se les debera poder hacer un seguimiento hasta los requisitos del cliente. Como hemos visto, el objetivo de las pruebas del software es descubrir errores. Se entiende que los defectos ms graves (desde el punto de vista del cliente) son aquellos que impiden al programa cumplir sus requisitos.

Las pruebas deberan planificarse mucho antes de que empiecen. La planificacin de las pruebas pueden empezar tan pronto como est completo el modelo de requisitos. La definicin detallada de los casos de prueba puede empezar tan pronto como el modelo de diseo se ha consolidado. Por tanto, se pueden planificar y disear todas las pruebas antes de generar ningn cdigo.

El principio de Pareto es aplicable a la prueba del software. Dicho de manera sencilla, el principio de Pareto implica que al 80 por 100 de todos los errores descubiertos durante las pruebas se les puede

hacer un seguimiento hasta un 20 por 100 de todos los mdulos del programa. El problema, por supuesto, es aislar estos mdulos sospechosos y probarlos concienzudamente.

Las pruebas deberan empezar por lo pequeo y progresar hacia lo grande. Las primeras pruebas planeadas y ejecutadas se centran generalmente en mdulos individuales del programa. A medida que avanzan las pruebas, desplazan su punto de mira en un intento de encontrar errores en grupos integrados de mdulos y finalmente en el sistema entero.

No son posibles las pruebas exhaustivas. El nmero de permutaciones de caminos para incluso un programa de tamao moderado es

excepcionalmente. Por este motivo, es imposible ejecutar todas las combinaciones de caminos durante las pruebas. Es posible, sin embargo, cubrir adecuadamente la lgica del programa y asegurarse de que se han aplicado todas las condiciones en el diseo a nivel de componente.

Para ser ms eficaces, las pruebas deberan ser realizadas por un equipo independiente. Por ms eficaces queremos referirnos a pruebas con la ms alta probabilidad de encontrar errores (el objetivo principal de las pruebas). E ingeniero del software que cre el sistema no es el ms adecuado para llevar a cabo las pruebas para el software.

Existen, de hecho, mtricas que podran usarse para medir la facilidad de prueba en la mayora de sus aspectos. A veces, la facilidad de prueba se usa para indicar lo adecuadamente que un conjunto particular de pruebas va a cubrir un producto. Tambin es empleada por los militares para indicar lo fcil que se puede comprobar y reparar una herramienta en plenas maniobras. Esos dos significados no son lo mismo que facilidad de prueba del software. La siguiente lista de comprobacin proporciona un conjunto de caractersticas que llevan a un software fcil de probar.

Operatividad. Cuanto mejor funcione, ms eficientemente se puede probar.

El sistema tiene pocos errores (los errores aaden sobrecarga de anlisis y de generacin de informes al proceso de prueba).

Ningn error bloquea la ejecucin de las pruebas.

El producto evoluciona en fases funcionales (permite simultanear el desarrollo y las pruebas).

Observabilidad. Lo que ves es lo que pruebas.

Se genera una salida distinta para cada entrada.

Los estados y variables del sistema estn visibles o se pueden consultar durante la ejecucin.

Los estados y variables anteriores del sistema estn visibles o se pueden consultar (por ejemplo, registros de transaccin).

Todos los factores que afectan a los resultados estn visibles. Un resultado incorrecto se identifica fcilmente.

Los errores internos se detectan automticamente a travs de mecanismos de auto-comprobacin. Se informa automticamente de los errores internos.

El cdigo fuente es accesible.

Controlabilidad. Cuanto mejor podamos controlar el software, ms se puede automatizar y optimizar.

Todos los resultados posibles se pueden generar a travs de alguna combinacin de entrada.

Todo el cdigo es ejecutable a travs de alguna combinacin de entrada.

El ingeniero de pruebas puede controlar directamente los estados y las variables del hardware y

del software.

Los formatos de las entradas y los resultados son consistentes y estructurados.

Las

pruebas

pueden

especificarse,

automatizarse

reproducirse

convenientemente.

Capacidad de descomposicin. Controlando el mbito de las pruebas, podemos aislar ms rpidamente los problemas y llevar a cabo mejores pruebas de regresin.

El sistema software est construido con mdulos independientes. Los mdulos del software se pueden probar independientemente.

Simplicidad. Cuanto menos haya que probar, ms rpidamente podremos probarlo.

Simplicidad funcional (por ejemplo, el conjunto de caractersticas es el mnimo necesario para cumplir los requisitos).

Simplicidad estructural (por ejemplo, la arquitectura es modularizada para limitar la propagacin de fallos).

Simplicidad del cdigo (por ejemplo, se adopta un estndar de cdigo para facilitar la inspeccin y el mantenimiento).

Estabilidad. Cuanto menos cambios, menos interrupciones a las pruebas.

Los cambios del software son infrecuentes.

Los cambios del software estn controlados.

Los cambios del software no invalidan las pruebas existentes.

El software se recupera bien de los fallos.

Facilidad de comprensin. Cuanta ms informacin tengamos, ms inteligentes sern las pruebas.

El diseo se ha entendido perfectamente.

Las dependencias entre los componentes internos, externos y compartidos se han entendido perfectamente.

Se han comunicado los cambias del diseo.

La documentacin tcnica es instantneamente accesible.

La documentacin tcnica est bien organizada.

La documentacin tcnica es especfica y detallada.

La documentacin tcnica es exacta.

Los atributos sugeridos por Bach los puede emplear el ingeniero del software para desarrollar una configuracin del software (por ejemplo, programas, datos y documentos) que pueda probarse.

Prueba de estructura de control

El mtodo de la prueba de condiciones se centra en la prueba de cada una de las.condiciones del programa. Las estrategias de prueba de condiciones (tratadas posteriormente en este captulo) tienen, generalmente, dos ventajas. La primera, que la cobertura de la prueba de una condicin es sencilla. La segunda, que la cobertura de la prueba de las condiciones de un programa da una orientacin para generar pruebas adicionales del programa.

El propsito de la prueba de condiciones es detectar, no slo los errores en las condiciones de un programa, sino tambin otros errores en dicho programa. Si un conjunto de pruebas de un programa P es efectivo para detectar errores en las condiciones que se encuentran en P, es probable que el conjunto de pruebas tambin sea efectivo para detectar otros errores en el programa P. Adems, si una estrategia de prueba es efectiva para detectar errores en una condicin, entonces es probable que dicha estrategia tambin sea efectiva para detectar errores en el programa.Se han propuesto una serie de estrategias de prueba de condiciones. La prueba de ramificaciones es, posiblemente, la estrategia de prueba de condiciones ms sencilla. Para una condicin compuesta C, es necesario ejecutar al menos una vez las ramas verdadera y falsade C y cada condicin simple de C. Prueba de caja blanca.

La prueba de caja blanca, denominada a veces prueba de caja de cristal es un mtodo de diseo de casos de prueba que usa la estructura de control del diseo procedimental para obtener los casos de prueba. Mediante los mtodos de prueba de caja blanca, el ingeniero del software puede obtener casos de prueba que (1) garanticen que se ejercita por lo menos una vez todos los caminos independientes de cada mdulo; (2) ejerciten todas las decisiones lgicas en sus vertientes verdadera y falsa; (3) ejecuten todos los bucles en sus lmites y con sus lmites operacionales; y (4) ejerciten las estructuras internas de datos para asegurar su

validez. En este momento, se puede plantear un pregunta razonable: Por qu emplear tiempo y energa preocupndose de (y probando) las minuciosidades lgicas cuando podramos emplear mejor el esfuerzo asegurando que se han alcanzado los requisitos del programa? O, dicho de otra forma, por qu no empleamos todas nuestras energas en la prueba de caja negra? La respuesta se encuentra en la naturaleza misma de los defectos del software:

Los

errores

lgicos

las

suposiciones

incorrectas

son

inversamente

proporcionales a la probabilidad de que se ejecute un camino del programa. Los errores tienden a introducirse en nuestro trabajo cuando diseamos e implementamos funciones, condiciones o controles que se encuentran fuera de lo normal. El procedimiento habitual tiende a hacerse ms comprensible (y bien examinado), mientras que el procesamiento de casos especiales tiende a caer en el caos.

A menudo creemos que un camino lgico tiene pocas posibilidades de ejecutarse cuando, de hecho, se puede ejecutar de forma normal. El flujo lgico de un programa a veces no es nada intuitivo, lo que significa que nuestras suposiciones intuitivas sobre el flujo de control y los datos nos pueden llevar a tener errores de diseo que slo se descubren cuando comienza la prueba del camino.

Los errores tipogrficos son aleatorios. Cuando se traduce un programa a cdigo fuente en un lenguaje de programacin, es muy probable que se den algunos errores de escritura. Muchos sern descubiertos por los mecanismos de comprobacin de sintaxis, pero otros permanecern sin detectar hasta que comience la prueba. Es igual de probable que haya un error tipogrfico en un oscuro camino lgico que en un camino principal.

Prueba de caja negra

Las pruebas de caja negra, tambin denominada prueba de comportamiento, se centran en los requisitos funcionales del software. O sea, la prueba de caja negra Permite al ingeniero del software obtener conjuntos de condiciones de entrada que ejerciten completamente todos los requisitos funcionales de un programa. La prueba de caja negra no es una alternativa a las tcnicas de prueba de caja blanca. Ms bien se trata de un enfoque complementario que intenta descubrir diferentes tipos de errores que los mtodos de caja blanca.

La prueba de caja negra intenta encontrar errores de las siguientes categoras: (1) funciones incorrectas o ausentes, (2) errores de interfaz, (3) errores en estructuras de datos o en accesos a bases de datos externas, (4) errores de rendimiento y (5) errores de inicializacin y de terminacin.

A diferencia de la prueba de caja blanca, que se lleva a cabo previamente en el proceso de prueba, la prueba de caja negra tiende a aplicarse durante fases posteriores de la prueba. Ya que la prueba de caja negra ignora

intencionadamente la estructura de control, centra su atencin en el campo de la informacin. Las pruebas se disean para responder a las siguientes preguntas:

Cmo se prueba la validez funcional?

Cmo se prueba el rendimiento y el comportamiento del sistema?

Qu clases de entrada compondrn unos buenos casos de prueba?

Es el sistema particularmente sensible a ciertos valores de entrada?

De qu forma estn aislados los lmites de una clase de datos?

Qu volmenes y niveles de datos tolerar el sistema?

Qu efectos sobre la operacin del sistema tendrn combinaciones especficas de datos?

Mediante las tcnicas de prueba de caja negra se obtiene un conjunto de casos de prueba que satisfacen los siguientes criterios : (1) casos de prueba que reducen, en un coeficiente que es mayor que uno, el nmero de casos de prueba dicionales que se deben disear para alcanzar una prueba razonable y (2) casos de prueba que nos dicen algo sobre la presencia o ausencia de clases de errores en lugar de errores asociados solamente con la prueba que estamos realizando.

Prueba de entornos especializados: Arquitecturas y aplicaciones

A medida que el software de computadora se ha hecho ms complejo, ha crecido tambin la necesidad de enfoques de pruebas especializados. Los mtodos de prueba de caja blanca y de caja negra tratados son aplicables a todos los entonos, arquitecturas y aplicaciones pero a veces se necesitan unas directrices y enfoques nicos para las pruebas.

En esta seccin se estudian directrices de prueba para entornos, arquitecturas y aplicaciones especializadas que pueden encontrarse los ingenieros del software.

Prueba de arquitectura cliente/servidor

La arquitectura cliente-servidor (C/S) representa un desafo significativo para los responsables de la pruebas del software. La naturaleza distribuida de los entornos cliente-servidor, los aspectos de rendimiento asociados con el proceso de transacciones, la presencia potencial de diferentes plataformas hardware, las complejidades de las comunicaciones de red, la necesidad de servir a mltiples clientes desde una base de datos centralizada (o en algunos casos, distribuida) y los requisitos de coordinacin impuestos al servidor se combinan todos para hacer

las pruebas de la arquitectura C/S y el software residente en ellas, considerablemente ms difciles que la prueba de aplicaciones individuales. De hecho, estudios recientes sobre la industria indican un significativo aumento en el tiempo invertido y los costes de las pruebas cuando se desarrollan entornos C/S.

Prueba de sistemas de tiempo-real

La naturaleza asncrona y dependiente del tiempo de muchas aplicaciones de tiempo real, aade un nuevo y potencialmente difcil elemento a la complejidad de las pruebas el tiempo. El responsable del diseo de casos de prueba no slo tiene que considerar los casos de prueba de caja blanca y de caja negra, sino tambin el tratamiento de sucesos (por ejemplo, procesamiento de interrupciones), la temporizacin de los datos y el paralelismo de las tareas (procesos) que manejan los datos. En muchas situaciones, los datos de prueba proporcionados al sistema de tiempo real cuando se encuentra en un determinado estado darn un proceso correcto, mientras que al proporcionrselos en otro estado llevarn a un error.