paper pruebas de software
TRANSCRIPT
Pruebas de softwarePaulo César Guerrero.
Faculta de ingeniería, Universidad San Martin, Colombia
AbstractEl presente artículo acoge las características de los diferentes tipos de prueba que pueden establecerse sobre un software. El informe parte desde conceptos previos como prueba, validación y verificación hasta representar un ciclo de pruebas. Posterior a ello se establecen o describen cuatro tipos de pruebas (unitarias, integración, sistema, aceptación) planteando la forma como interactúan los entes participantes de desarrollo y control sobre la ejecución de las mismas.
Palabras Clave Pruebas, software, caja blanca, caja negra, calidad, operaciones, entradas, salidas, desarrollo, evaluación, depuración, planificación, diseño, usuario, Alpha, Beta.
I. INTRODUCCIÓN
A diario sometemos cualquier situación, 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 técnicas o métodos con el fin de evaluar la calidad o estado del producto y ofrecerle al cliente un “excelente” producto. En conjunto las técnicas tienen como objetivo general verificar y validar un software, independientemente de las características y el entorno donde se desarrollen, además 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 diseño e implementación 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 evalúa de forma paralela el proceso implementado dentro del desarrollo y a mayor índice de errores y/o gastos en la re implementación ($$$$$$$$$) , menor es el índice de confiabilidad frente al proceso implementado por el grupo, rencaminando el objetivo del articulo Las Pruebas de software inicio la síntesis de su finalidad y aplicación.
II. EL PROCESO DE LAS PRUEBAS
Las pruebas se deben iniciar desde la etapa de análisis y planteamiento de requerimientos, con el fin de evitar interpretaciones incorrectas y desviación de expectativas es por ello que el desarrollo de pruebas esta sujeto al control intrínseco que se establece frente a dos instancias: validación y verificación.La validación se basa en el planteamiento ¿Estamos construyendo el producto correcto? Y la verificación ¿Estamos construyendo de forma correcta el producto? [2].
La primera instancia pretende evaluar si con el producto generado se están cumpliendo las expectativas del cliente y la segunda controla la especificación 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:
Figura1. Ciclo completo de las pruebas [3]
De acuerdo con esta propuesta el desarrollo de pruebas inicia con la obtención de información donde se detalle el proyecto y particularidades del software, lo que desencadena la planificación y diseño en detalle de las pruebas, a partir de ello se establecen ejecuciones programadas con las que se establecen valoraciones para iniciar en su depuración o corrección otra variante de la evaluación es el análisis de errores que ayudara en la prevención 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 intervención de cada uno de los entes participantes:
Pruebas Unitarias Pruebas Integración Pruebas de Sistema Prueba de Aceptación
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 métodos de caja blanca y caja negra, en primera instancia Caja Blanca es una técnica que basa su operación en el examen detallado de rutas lógicas del software.
Figura 2. Pruebas de Caja Blanca
Una de las técnicas mas utilizadas es la Complejidad Ciclomática de McCabe.“Este indicador fue desarrollado en 1976 por Thomas J. McCabe y refleja directamente el número de caminos independientes que un programa puede tomar durante su ejecución. Cualquier desarrollador que haya probado código en su vida, sabe que la cantidad de pruebas necesarias para ejercitar un determinado lugar del código es directamente proporcional a su árbol de decisiones” [4].
Figura 4. Complejidad Ciclomática V(g).
Como elemento complementario para estas pruebas se da el uso del método de Caja Negra que basa su operación 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).
Figura 4. Pruebas de Caja BlancaIV. PRUEBAS DE INTEGRACIÓN
Las pruebas de integración acogen componentes o módulos del producto y los evalúa en conjunto para establecer índices de comunicación 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 integración 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 integración: La integración incremental y la no incremental. La integración incremental consiste en combinar el conjunto de módulos ya probados (al principio será un conjunto vacío) con los siguientes módulos a probar. Luego se va incrementando progresivamente el número de módulos unidos hasta que se forma el sistema completo. En la integración no incremental o Big Bang se combinan todos los módulos 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 integración, 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 están:
Pruebas negativas: se trata de que el sistema falle para ver sus debilidades.
Pruebas de recuperación: se simulan fallas de software y/o hardware para verificar la eficacia del proceso de recuperación.
Pruebas de rendimiento: tiene como objeto evaluar el rendimiento del sistema integrado en condiciones de uso habitual.
Pruebas de resistencia o de estrés: comprueban el comportamiento del sistema ante situaciones donde se demanden cantidades extremas de recursos (número de transacciones simultáneas anormal, excesivo uso de las memorias, etc.).
Pruebas de seguridad: se utilizan para testear el esquema de seguridad intentando vulnerar los métodos utilizados para el control de accesos no autorizados al sistema [6].
V. PRUEBAS DE ACEPTACIÓN
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 AlphaGeneralmente se realizan por usuarios finales dentro de la organización que desarrolló el software (espacio físico).
B. Pruebas BetaGeneralmente se realizan por un subconjunto seleccionado de los clientes reales, fuera de la compañía 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 documentación frente al estudio del código.
Reducen el costo del cambio. Permiten realizar reimplementación. Restringe las características a implementar. Hacen que el desarrollo sea más rápido. [7]
Las pruebas son elementos que el grupo desarrollador debe aplicar constantemente en la evolución 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 aplicación de ellas nos puede conducir a proyectos caóticos de alto costo y poco atractivos para el usuario.
CONCLUSIONES
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 técnicas de caja blanca y caja negra.
Las técnicas de caja negra se implementan con el propósito de verificar requerimientos funcionales.
Las técnicas de caja negra brindan aprobación sobre el código desarrollado.
Las pruebas deben ser diseñadas y ejecutadas por personal diferente al involucrado en el proceso de análisis 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 evaluación 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 diseño y ejecución de las pruebas.
REFERENCIAS
[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. Análisis y diseño de aplicaciones informáticas de gestión, una perspectiva de ingeniería del software, pages 419-469. Alfaomega, 2004.[4] Gómez Diego, “Cómo entender la Complejidad Ciclomática” [Online]. Available: http://www.dosideas.com/noticias/metodologias/320-como-entender-la-complejidad-ciclomatica.html.[5] Polo Usaola Macario, “Pruebas de Sistemas de Información” Departamento de Tecnologías y Sistemas de Información, p. 23.[6] Suarez Pablo, Fontela Carlos, “Documentación y pruebas Antes del paradigma de objetos”, p. 10-13.[7] Universidad distrital Francisco José de Caldas , “Visión general de las pruebas de software” [Online]. Available: http://gemini.udistrital.edu.co/comunidad/grupos/arquisoft/index.php?id=80&type=1