Pruebas de software

Paulo Csar Guerrero.

Faculta de ingeniera, Universidad San Martin, Colombia
paulo.guerrrero@netservice.com.co

Abstract El presente artculo acoge las caractersticas de los diferentes tipos de prueba que pueden establecerse sobre un software. El informe parte desde conceptos previos como prueba, validacin y verificacin hasta representar un ciclo de pruebas. Posterior a ello se establecen o describen cuatro tipos de pruebas (unitarias, integracin, sistema, aceptacin) planteando la forma como interactan los entes participantes de desarrollo y control sobre la ejecucin de las mismas. Palabras Clave Pruebas, software, caja blanca, caja negra, calidad, operaciones, entradas, salidas, desarrollo, evaluacin, depuracin, planificacin, diseo, usuario, Alpha, Beta.

La primera instancia pretende evaluar si con el producto generado se estn cumpliendo las expectativas del cliente y la segunda controla la especificacin inicial de lo que se esta construyendo. A partir de este punto las pruebas son las

herramientas que me permiten validar o verificar el producto construido, para iniciar el ciclo de pruebas debemos tener en cuenta el siguiente esquema:

I.

INTRODUCCIN

A diario sometemos cualquier situacin, proceso, persona o tarea a pruebas exhaustivas con el fin de obtener indicadores que nos permita determinar el estado en el que se encuentran, en el desarrollo de software se aplican tcnicas o mtodos con el fin de evaluar la calidad o estado del producto y ofrecerle al cliente un excelente producto. En conjunto las tcnicas tienen como objetivo general verificar y validar un software, independientemente de las caractersticas y el entorno donde se desarrollen, adems de los recursos y los factores vinculados al proceso de desarrollo [1]. Las pruebas de software se han convertido en un proceso radical dentro del ciclo del desarrollo ya que dentro de su orden es una de las ultimas que se aplican, requieren de gran tiempo para su diseo e implementacin y se plantea que entre mas se encuentre mucho mejor pero frente a este ultimo tem discrepo en el sentido en que las pruebas de software evala de forma paralela el proceso implementado dentro del desarrollo y a mayor ndice de errores y/o gastos en la re implementacin ($$$$$$$$$) , menor es el ndice de confiabilidad frente al proceso implementado por el grupo, rencaminando el objetivo del articulo Las Pruebas de software inicio la sntesis de su finalidad y aplicacin. II. EL PROCESO DE LAS PRUEBAS

Figura1. Ciclo completo de las pruebas [3]

De acuerdo con esta propuesta el desarrollo de pruebas inicia con la obtencin de informacin donde se detalle el proyecto y particularidades del software, lo que desencadena la planificacin y diseo en detalle de las pruebas, a partir de ello se establecen ejecuciones programadas con las que se establecen valoraciones para iniciar en su depuracin o correccin otra variante de la evaluacin es el anlisis de errores que ayudara en la prevencin de futuros desarrollos. Cabe anotar que en este ciclo no se aprecia un esquema controlado de pruebas es por ello que debemos plantear diferentes tipos de prueba que asegure el papel o intervencin de cada uno de los entes participantes: Pruebas Unitarias Pruebas Integracin Pruebas de Sistema Prueba de Aceptacin

Las pruebas se deben iniciar desde la etapa de anlisis y planteamiento de requerimientos, con el fin de evitar interpretaciones incorrectas y desviacin de expectativas es por ello que el desarrollo de pruebas esta sujeto al control intrnseco que se establece frente a dos instancias: validacin y verificacin. La validacin se basa en el planteamiento Estamos construyendo el producto correcto? Y la verificacin Estamos construyendo de forma correcta el producto? [2].

III.

PRUEBAS UNITARIAS

El primer elemento probatorio a considerar en el desarrollo de evaluaciones del producto son las pruebas unitarias o modulares ya que te permiten constatar el funcionamiento inicial o definitivo de trozos o secciones del producto. Para realizar estas pruebas se utilizan mtodos de caja blanca y caja negra, en primera instancia Caja Blanca es una tcnica que basa su operacin en el examen detallado de rutas lgicas del software.

Figura 4. Pruebas de Caja Blanca

IV.

PRUEBAS DE INTEGRACIN

Figura 2. Pruebas de Caja Blanca

Una de las tcnicas mas utilizadas es la Complejidad Ciclomtica de McCabe. Este indicador fue desarrollado en 1976 por Thomas J. McCabe y refleja directamente el nmero de caminos independientes que un programa puede tomar durante su ejecucin. Cualquier desarrollador que haya probado cdigo en su vida, sabe que la cantidad de pruebas necesarias para ejercitar un determinado lugar del cdigo es directamente proporcional a su rbol de decisiones [4].

Las pruebas de integracin acogen componentes o mdulos del producto y los evala en conjunto para establecer ndices de comunicacin y flujo de datos, al integrar se determina cada modulo como elemento de Caja Negra (No se tiene en cuenta estructuras internas). Las pruebas de integracin se emplean para comprobar que las unidades de prueba, que han superado sus pruebas de unidad, funcionan correctamente cuando se integran, de manera que lo que se tiende a ir probando es la arquitectura software.[5] Existen principalmente dos tipos de integracin: La integracin incremental y la no incremental. La integracin incremental consiste en combinar el conjunto de mdulos ya probados (al principio ser un conjunto vaco) con los siguientes mdulos a probar. Luego se va incrementando progresivamente el nmero de mdulos unidos hasta que se forma el sistema completo. En la integracin no incremental o Big Bang se combinan todos los mdulos de una vez. [6] IV. PRUEBAS DE SISTEMA Las pruebas de sistema tienen como meta evidenciar que software o producto, ha superado las pruebas de integracin, y no posee deficiencias en el factor de interoperabilidad y portabilidad. Algunos grupos de desarrollo implementan pruebas que les permitan evaluar de forma macro todo el sistema entre ellas estn: Pruebas negativas: se trata de que el sistema falle para ver sus debilidades. Pruebas de recuperacin: se simulan fallas de software y/o hardware para verificar la eficacia del proceso de recuperacin. Pruebas de rendimiento: tiene como objeto evaluar el rendimiento del sistema integrado en condiciones de uso habitual. Pruebas de resistencia o de estrs: comprueban el comportamiento del sistema ante situaciones donde se demanden cantidades extremas de recursos (nmero de transacciones simultneas anormal, excesivo uso de las memorias, etc.). Pruebas de seguridad: se utilizan para testear el esquema de seguridad intentando vulnerar los mtodos utilizados para el control de accesos no autorizados al sistema [6].

Figura 4. Complejidad Ciclomtica V(g).

Como elemento complementario para estas pruebas se da el uso del mtodo de Caja Negra que basa su operacin en el desarrollo de sus entradas y sus salidas. Se aplican los criterios y se observan las salidas para definir operaciones correctas o depuraciones necesarias (su esquema es de tipo funcional).

V.

PRUEBAS DE ACEPTACIN CONCLUSIONES

Es una prueba que se lleva a cabo para determinar si el producto se ajusta a los criterios o requisitos establecidos por el cliente y determinar si es aceptado o no. En el desarrollo de este tipo de pruebas se tiene en cuenta dos etapas:

Pruebas de tipo Alpha Pruebas de tipo Beta.

A. Pruebas Alpha Generalmente se realizan por usuarios finales dentro de la organizacin que desarroll el software (espacio fsico). B. Pruebas Beta Generalmente se realizan por un subconjunto seleccionado de los clientes reales, fuera de la compaa antes de que el software sea disponible para todos los usuarios.

VI.

DEBEMOS GENERAR PRUEBA?

Al visualizar la gran cantidad de pruebas o formas como se deben implementar surge en ocasiones el interrogante Por qu tanto trabajo y no dejarlo para el final?, la respuesta a este interrogante se plantea en siete aspectos que demuestran lo contrario ellos son: Reducen la posibilidad de agregar defectos al software. Reducen la posibilidad de encontrar defectos en funcionalidades ya implementadas. Las pruebas son buena documentacin frente al estudio del cdigo. Reducen el costo del cambio. Permiten realizar reimplementacin. Restringe las caractersticas a implementar. Hacen que el desarrollo sea ms rpido. [7]

El desarrollo de pruebas tiene objetivo principal: identificar elementos que no aseguran en un 100% la calidad de un producto. Los diferentes tipos de pruebas representan su accionar sobre las tcnicas de caja blanca y caja negra. Las tcnicas de caja negra se implementan con el propsito de verificar requerimientos funcionales. Las tcnicas de caja negra brindan aprobacin sobre el cdigo desarrollado. Las pruebas deben ser diseadas y ejecutadas por personal diferente al involucrado en el proceso de anlisis o desarrollo para evitar correcciones sobre la marcha que puedan desencadenar fallas graves en el uso del producto por parte del usuario. El desarrollo de pruebas es proporcional al ndice de calidad final que se obtiene sobre un producto. El plan de pruebas es la pliego de control y evaluacin que deben seguir los integrantes del equipo de pruebas de un desarrollo de software, ya que en l se definieron las procedimientos que se deben realizar durante el diseo y ejecucin de las pruebas. REFERENCIAS

Las pruebas son elementos que el grupo desarrollador debe aplicar constantemente en la evolucin del software con el fin de asegurar la calidad constante en su trabajo. Debemos recordar que el hecho de no invertir tiempo en el desarrollo o aplicacin de ellas nos puede conducir a proyectos caticos de alto costo y poco atractivos para el usuario.

[1] (2012) The IEEE website. [Online]. Available: http://www.ecured.cu/index.php/Pruebas_de_Calidad_de_Software# Tipos_de_Pruebas_de_Software/ [2] Ian Somerville, Ingenieria de software , 7ma ed., Ed. Pearson, 2005,Pag. 472. [3] Mario G. Piattini, Jose A. Calvo-Manzano, Joaquin Cervera Bravo, and Luis Fernandez Sanz. Anlisis y diseo de aplicaciones informticas de gestin, una perspectiva de ingeniera del software, pages 419-469. Alfaomega, 2004. [4] Gmez Diego, Cmo entender la Complejidad Ciclomtica [Online]. Available: http://www.dosideas.com/noticias/metodologias/320-como-entenderla-complejidad-ciclomatica.html. [5] Polo Usaola Macario, Pruebas de Sistemas de Informacin Departamento de Tecnologas y Sistemas de Informacin, p. 23. [6] Suarez Pablo, Fontela Carlos, Documentacin y pruebas Antes del paradigma de objetos, p. 10-13. [7] Universidad distrital Francisco Jos de Caldas , Visin general de las pruebas de software [Online]. Available: http://gemini.udistrital.edu.co/comunidad/grupos/arquisoft/index.php ?id=80&type=1