Pruebas de Software

Es una actividad en la cual un sistema o uno de sus componentes se ejecutan previamente en cirscunstancias previamente especificadas.

Tipos de Prueba Caja Negra

Las pruebas de caja negra se centran en lo que se espera de un mdulo, es decir, intentan encontrar casos en que el mdulo no se atiene a su especificacin. Por ello se denominan pruebas funcionales, y el probador se limita a suministrarle datos como entrada y estudiar la salida, sin preocuparse de lo que pueda estar haciendo el mdulo por dentro. Las pruebas de caja negra estn especialmente indicadas en aquellos mdulos que van a ser interfaz con el usuario (en sentido general: teclado, pantalla, ficheros, canales de comunicaciones, etc etc) Este comentario no obsta para que sean tiles en cualquier mdulo del sistema. Las pruebas de caja negra se apoyan en la especificacin de requisitos del mdulo. De hecho, se habla de "cobertura de especificacin" para dar una medida del nmero de requisitos que se han probado. Es fcil obtener coberturas del 100% en mdulos internos, aunque puede ser ms laborioso en mdulos con interfaz al exterior. En cualquier caso, es muy recomendable conseguir una alta cobertura en esta lnea. El problema con las pruebas de caja negra no suele estar en el nmero de funciones proporcionadas por el mdulo (que siempre es un nmero muy limitado en diseos razonables); sino en los datos que se le pasan a estas funciones. El conjunto de datos posibles suele ser muy amplio (por ejemplo, un entero). A la vista de los requisitos de un mdulo, se sigue una tcnica algebrica conocida como "clases de equivalencia". Esta tcnica trata cada parmetro como un modelo algebrico donde unos datos son equivalentes a otros. Si logramos partir un rango excesivamente amplio de posibles valores reales a un conjunto reducido de clases de equivalencia,

entonces es suficiente probar un caso de cada clase, pues los dems datos de la misma clase son equivalentes. El problema est pues en identificar clases de equivalencia, tarea para la que no existe una regla de aplicacin universal; pero hay recetas para la mayor parte de los casos prcticos:

si un parmetro de entrada debe estar comprendido en un cierto rango, aparecen 3 clases de equivalencia: por debajo, en y por encima del rango.

si una entrada requiere un valor concreto, aparecen 3 clases de equivalencia: por debajo, en y por encima del rango.

si una entrada requiere un valor de entre los de un conjunto, aparecen 2 clases de equivalencia: en el conjunto o fuera de l.

si una entrada es booleana, hay 2 clases: si o no. los mismos criterios se aplican a las salidas esperadas: hay que intentar generar resultados en todas y cada una de las clases.

Durante la lectura de los requisitos del sistema, nos encontraremos con una serie de valores singulares, que marcan diferencias de comportamiento. Estos valores son claros candidatos a marcar clases de equivalencia: por abajo y por arriba. Una vez identificadas las clases de equivalencia significativas en nuestro mdulo, se procede a coger un valor de cada clase, que no est justamente al lmite de la clase. Este valor aleatorio, har las veces de cualquier valor normal que se le pueda pasar en la ejecucin real. La experiencia muestra que un buen nmero de errores aparecen en torno a los puntos de cambio de clase de equivalencia. Hay una serie de valores denominados "frontera" (o valores lmite) que conviene probar, adems de los elegidos en el prrafo anterior. Usualmente se necesitan 2 valores por frontera, uno justo abajo y otro justo encima.

Limitaciones
Lograr una buena cobertura con pruebas de caja negra es un objetivo deseable; pero no suficiente a todos los efectos. Un programa puede pasar con holgura millones de pruebas y sin embargo tener defectos internos que surgen en el momento ms inoportuno (Murphy no olvida).

Caja Blanca
Tambien se le conoce como Pruebas Transparentes o Pruebas Estructurales En estas pruebas estamos siempre observando el cdigo, que las pruebas se dedican a ejecutar con nimo de "probarlo todo". Esta nocin de prueba total se formaliza en lo que se llama "cobertura" y no es sino una medida porcentual de cunto cdigo hemos cubierto? Hay diferentes posibilidades de definir la cobertura. Todas ellas intentan sobrevivir al hecho de que el nmero posible de ejecuciones de cualquier programa no trivial es (a todos los efectos prcticos) infinito. Pero si el 100% de cobertura es infinito, ningn conjunto real de pruebas pasara de un infinitsimo de cobertura. Esto puede ser muy interesante para los matemticos; pero no sirve para nada. Para esta prueba se consideran tres puntos importantes 1. Conocer el desarrollo del sistema. 2. Considerar las reglas predefinidas npor cada algoritmo. 3. Comparar el desarrollo del programa.

Aunque las pruebas de caja blanca son aplicables a varios niveles unidad, integracin y sistema, habitualmente se aplican a las unidades de software. Su cometido es comprobar los flujos de ejecucin dentro de cada unidad funcin, clase, mdulo, etc. pero tambin pueden testear los flujos entre unidades durante la integracin, e incluso entre subsistemas, durante las pruebas de sistema.

A pesar de que este enfoque permite disear pruebas que cubran una amplia variedad de casos de prueba, podra pasar por alto partes incompletas de la especificacin o requisitos faltantes, pese a garantizar la prueba exhaustiva de todos los flujos de ejecucin del cdigo analizado.

Prueba de Estress
Es el acto de asegurar que el sistema funciona como se espera bajo grandes volmenes de transacciones, usuarios, carga y adems revisin tcnica. Adems evalua el

comportamiento del sistema bajo condiciones anormales como extrema carga, memoria insuficiente, no disponibilidad de servicio o hardware o recursos compartidos limitados. La misma permite comprender como y que reas del sistema colapsaran, de esta manera es posible planificar contingencias y actualizar el mantenimiento, planear y asignar recursos de antemano.

Tipos de Prueba de Stress Prueba de Stress de Componentes:

Con estas pruebas, se aslan los servicios y componentes que conforman el sistema, se infieren los mtodos de navegacin, de funcionamiento y de interfaz de estos servicios y componentes y se crea un cliente de prueba que llame a dichos mtodos. Para aquellos mtodos que tienen acceso a un servidor de base de datos o a cualquier otro componente, puede crear un cliente que proporcione datos simulados en el formato previsto. El equipo de prueba inserta datos simulados una y otra vez mientras observa los resultados. La idea es forzar cada componente de forma aislada ms de lo que la aplicacin podra experimentar en condiciones normales.

Prueba de Stress de Integracin:

Despus de forzar cada componente individual, deber someter a una situacin de stress a toda la aplicacin con todos sus componentes y servicios. Las pruebas de stress de integracin estn ntimamente relacionadas con las interacciones con otras estructuras de datos, procesos y servicios tanto de los componentes internos como de otros servicios externos de la aplicacin. Las pruebas de integracin comienzan con una comprobacin bsica del funcionamiento. Es necesario que conozca los recorridos codificados y las situaciones a las que se enfrentan los usuarios, que comprenda lo que intentan hacer estos y que identifique todas las maneras en las que el usuario se mueve por la aplicacin. Las secuencias de comandos de prueba debern probar la aplicacin de acuerdo con el uso previsto.. En lugar de realizar pruebas durante unos cuantos das o una semana, prolongue el perodo de pruebas a un mes, un trimestre o un ao y observe cmo funciona la aplicacin durante un perodo de tiempo ms largo.

Prueba de Huracn:
Se utilizan para simular efectos cclicos dentro de una tarea, sea hacen referencias a algunos tipos de pruebas en sistemas en forma de ciclos repetitivos para contemplar el diagnostico. El espcimen puede ser cualquier tipo de elemento usado en cualquier tipo de subcomponente o modulo del sistema auditado. Normalmente las pruebas de huracanes se hacen en mdulos, submdulos y partes de componentes de un sistema.