Universidad de las Ciencias Informáticas
República de Cuba
“Propuesta de un proceso para la realización de pruebas a aplicaciones de software”.
Trabajo de Diploma en Opción al Título de
Ingeniero en Ciencias Informáticas
Autor:
Ismary Huerta Carralero
Tutor:
Ing. Wilfredo Ríos Milanes.
Ing. Kelvys Galvez Cabrera.
-2009-
Dedicatoria:
A mi mamá y a mis abuelos
Héctor y Melba…
Agradecimientos:
I Declaración de Autoría
Yo: Ismary Huerta Carralero, me declaro como único autor de este trabajo de diploma y autorizo a la Universidad de las Ciencias Informáticas (UCI) a que haga uso del mismo de la manera que estime conveniente.
Ing. Kelvys Galvez Cabrera Ing. Wilfredo Ríos Milanés
__________________ ____________________
Firma del Tutor Firma del Tutor
Ismary Huerta Carralero
_____________________
Firma del Autor
II
Índice.
Índice. ... II
Resumen. ... 5
Introducción. ... 6
Capítulo 1. “Marco Teórico de la Investigación”. ... 9
1.1 Introducción. ... 9
1.2 Calidad del software. ... 9
1.2.1 Definiciones de calidad del software. ... 9
1.2.2 Calidad a nivel de proceso. ... 10
1.2.3 Calidad a nivel de producto. ... 10
1.3 Concepto de prueba. ... 11
1.4 Objetivo de las pruebas. ... 11
1.4.1 Atributos que definen una buena prueba ... 12
1.5 Principios de las pruebas... 12
1.6 Niveles de Prueba. ... 13
1.6.1 Prueba de Desarrollador. ... 14
1.6.2 Prueba Independiente. ... 14
1.6.3 Prueba de Unidad. ... 14
1.6.4 Prueba de Integración. ... 14
1.6.5 Prueba de Sistema. ... 17
1.6.6 Prueba de Aceptación. ... 18
1.7 Tipos de Prueba. ... 18
1.8 Diseño de casos de prueba ... 19
1.9 Métodos de Prueba. ... 20
1.9.1 Pruebas de la caja blanca. ... 21
1.9.2 Pruebas de la caja negra: ... 25
1.10 Estrategia de prueba del software ... 29
1.11 Herramientas para el entorno de prueba. ... 30
1.11.1 WebKing ... 30
III
1.11.3 SOATest ... 32
1.11.4 JKingQA ... 33
1.11.5 JTest ... 33
1.11.6 Apache JMeter. ... 35
1.11.7 Selenium IDE. ... 35
1.12 Conclusiones. ... 35
Capítulo 2. “Proceso de pruebas propuesto”. ... 37
2.1 Introducción. ... 37
2.2 Proceso Actual. ... 37
2.2.1 Inicio de la revisión del producto. ... 37
2.2.2 Roles. ... 38
2.2.3 Artefactos. ... 38
2.2.4 Técnicas de prueba. ... 39
2.2.5 Conclusiones. ... 40
2.3 Solución Propuesta. ... 41
2.3.1 Diagrama de flujo del proceso propuesto. ... 41
2.3.2 Inicio de la revisión del producto. ... 42
2.3.3 Herramientas de apoyo. ... 43
2.3.4 Roles. ... 44
2.3.5 Artefactos. ... 46
2.3.6 Técnicas de prueba. ... 47
2.3.7 Actividades. ... 48
2.4 Conclusiones. ... 49
Capítulo 3. “Validación de la Solución”... 51
3.1 Introducción. ... 51
3.2 Caso de Estudio. ... 51
3.3 Requerimientos. ... 51
3.4. Aplicación de la solución propuesta. ... 54
3.4.1 Planificar pruebas. ... 54
IV
3.4.3 Realizar pruebas de unidad. ... 55
3.4.4 Realizar pruebas de integración. ... 59
3.4.5 Evaluar las pruebas. ... 59
3.5 Aplicación de las pruebas utilizando el proceso actual de la UCI... 60
3.6 Factibilidad de las soluciones ... 60
3.7 Opinión del líder de proyecto a testear. ... 63
3.8 Conclusiones. ... 63
Conclusiones. ... 64
Recomendaciones. ... 66
Referencias Bibliográficas. ... 67
Bibliografía Consultada. ... 69
Anexos. ... 71
Glosario de Términos. ... 97
5
Resumen.
Las pruebas del software son un elemento crítico para la garantía de calidad del software (Pressman, 2005). En la actualidad, en la Universidad de las Ciencias Informáticas existe un proceso donde se aplican métodos y técnicas para detectar los errores en los sistemas desarrollados. Este proceso no mide totalmente todos los aspectos necesarios para garantizar la calidad absoluta de los productos desarrollados, lo que puede influir negativamente en la imagen de la Universidad al liberar un sistema con problemas que pudiesen haber sido detectados.
Esta investigación, tiene como objeto de estudio los procesos de realización de pruebas para mejorar la calidad de los sistemas informáticos, centrando su campo de acción en el proceso de realización de pruebas para aplicaciones de software. Una vez realizado el estudio actual en la institución y al detectar la problemática existente se plantea como objetivo general en vista a solucionar la situación vigente, proponer un proceso para la realización de pruebas a aplicaciones que mejore el aseguramiento de la calidad de software, con el cual no se pretende criticar ni sustituir el proceso actualmente establecido por la dirección de Calidad de la Universidad sino contribuir al mejoramiento de la realización de pruebas del mismo. Para dar cumplimiento al objetivo principal se hizo necesario analizar los conceptos, metodologías y herramientas aplicadas a las estrategias de pruebas de software, analizar el mecanismo de realización de prueba establecido por la universidad, presentar un modelo general y apropiado al proceso de realización de pruebas de software y justificar la importancia de las pruebas en el ciclo de vida del software, como un medio de aseguramiento de calidad.
6
Introducción.
En el mundo de la computación tan cambiante hoy en día, y sobre todo de gran evolución tecnológica, se ha hecho necesario desarrollar procesos para asegurar la calidad de los productos software y obtener un mejoramiento continuo. Los procesos de desarrollo de software poseen reglas preestablecidas y deben ser aplicados en la creación del software de mediano y gran porte, ya que en caso contrario lo más seguro es que el proyecto no logre concluir o termine sin cumplir los objetivos previstos y con variedad de fallos inaceptables, es decir, fracasan. Los mecanismos de evaluación y mejora en el desarrollo de software han permitido que las empresas implementen los procesos de prueba que más se ajuste a sus necesidades y forma de trabajar.
En la universidad de las Ciencias Informáticas (UCI) existe un proceso de realización de pruebas pero no es el más eficiente ni el más óptimo para una Universidad que opta por la excelencia en los productos informáticos que desarrolla y obtener prestigio a nivel mundial en el campo de producción de software. Las pruebas a cada iteración se realizan al terminar la implementación de cada módulo o al terminar el sistema completo y no al terminar cada funcionalidad, de esta forma al detectar y por ende resolver cada error puede traer como consecuencias que surjan nuevos errores y en el peor de los casos haya que volver a implementar el módulo o el sistema completo. Si las pruebas se hicieran por funcionalidad serían más sencillos resolver los errores porque se centrarían en el problema y existe menos probabilidad de que se afecten funcionalidades adherentes a la misma. También esta el hecho de que a la hora de realizar las pruebas a los software, solo se incluyen las pruebas de caja negra, que son aquellas que se centran en detectar los errores a nivel de interfaz de los sistemas sin verificar el interior de los mismos. Es decir, son las encargadas de probar que cada botón de la interfaz del sistema, así como todas las funcionalidades del mismo funcionen correctamente y que estén validados todos los campos, además comprueban que todos los requisitos establecidos por el cliente estén garantizados en el producto. Sin embargo, las empresas internacionales de calidad de software además de utilizar las pruebas de caja negra utilizan las pruebas de caja blanca, que si evalúan el interior de los sistemas, es decir, el código, su implementación y los posibles errores que pueda generar una incorrecta definición de algún método que aparentemente funcione de manera correcta.
La no realización pruebas de caja blanca puede implicar que los productos que salen de la UCI no lleven la calidad requerida internacionalmente pues no están evaluados por todos los parámetros establecidos, por lo que estamos corriendo el riesgo de
7 liberar y vender un producto que al paso del tiempo no funcione con la calidad necesaria. Esto sería un error fatal que llevaría a la inconformidad del cliente que posiblemente nunca vuelva a establecer un contrato con la Universidad, además de atentar contra nuestra imagen como empresa productora de software en el mercado internacional.
Por lo anteriormente expuesto se hace necesario determinar la calidad de los productos elaborados por la UCI, entonces el problema científico quedaría formulado de la siguiente forma:
¿Cómo superar las deficiencias del proceso de realización de pruebas de software a través de un nuevo proceso de pruebas que mejore el aseguramiento de la calidad de software?
El objeto de estudio definido es el proceso de realización de pruebas para mejorar la calidad de los sistemas informáticos, siendo el campo de acción los métodos usados en la UCI para la realización de pruebas.
Para darle solución al problema planteado se definió como objetivo general de este trabajo proponer un proceso para la realización de pruebas a aplicaciones que mejore el aseguramiento de la calidad del software. Para dar cumplimiento al mismo se definieron los siguientes objetivos específicos:
Analizar los conceptos, metodologías y herramientas aplicadas a los procesos de realización pruebas de software.
Analizar el proceso de realización de pruebas establecido por la universidad.
Justificar un modelo general y apropiado al proceso de realización de pruebas de software.
Justificar la importancia del proceso de realización de pruebas en el ciclo de vida del software, como un medio de aseguramiento de calidad.
En la concepción de este trabajo se plantearon un conjunto de tareas de investigación, con el objetivo de que las mismas nos permitiesen realizar un trabajo satisfactorio, las cuales son:
Seleccionar y revisar una bibliografía que me permita actualizar los enfoques existentes sobre el tema de Pruebas de Calidad de Software.
Entrevistas con el personal del Laboratorio Central de Calidad de la Universidad de las Ciencias Informáticas para identificar el proceso de evaluación de la calidad de software en la universidad.
Estudio de los conceptos, metodologías y herramientas existentes y presentación de las mismas para el desarrollo de la investigación.
8 Selección del proyecto que será escogido como muestra.
Esta tesis está compuesta por tres capítulos. El primero se dedica al marco teórico referencial de la investigación, donde se realiza un análisis de los conceptos, metodologías y herramientas que son usados para lograr mediante las pruebas de software la calidad de los productos informáticos en el mundo.
En el segundo capítulo se muestra la metodología y el proceso implementado actualmente por la UCI para determinar la Calidad del producto desarrollado. Además se describe el proceso propuesto por esta investigación.
En el tercer y último capítulo se realiza una evaluación sobre la solución propuesta en el segundo capítulo. Se validan las soluciones buscando opiniones de clientes, así como diagramas que ilustren el cambio en la calidad de algunos sistemas evaluados.
También está compuesta por las conclusiones donde se realiza un breve resumen del resultado obtenido durante el transcurso del trabajo, las recomendaciones que abordan las posibles mejoras al trabajo y los aspectos a profundizar, se incluye un glosario de términos definido para el trabajo en el cual se añaden aquellos términos que se utilizan en el documento y no son comunes, las referencias bibliográficas y la bibliografía que no son más que una lista de libros, artículos, documentos, sitios en Internet, etc. que han sido utilizados como referencia durante el desarrollo de este trabajo. Por último se encuentran los anexos, y documentos que complementan el cuerpo del trabajo.
9
Capítulo 1. “Marco Teórico de la Investigación”.
1.1 Introducción.
“Las pruebas del software son un elemento crítico para la garantía de calidad del software” (Pressman, 2005). En este capítulo se abordan los aspectos relacionados con el proceso de pruebas, como son sus objetivos, los principios de la misma así como los niveles, tipos y estrategias de pruebas. El dominio, conocimiento y puesta en práctica de estos aspectos nos permitirá obtener un software con la calidad requerida.
También es objeto de interés analizar las herramientas usadas en el mundo para garantizar la eficacia de las pruebas y que faciliten la realización de las mismas.
1.2 Calidad del software.
La calidad del software es una preocupación a la que se dedican muchos esfuerzos, sin embargo, el software casi nunca es perfecto. Todo proyecto tiene como objetivo producir software de la mejor calidad posible, que cumpla, y si puede supere las expectativas de los usuarios.
1.2.1 Definiciones de calidad del software.
La calidad del software es el conjunto de cualidades que lo caracterizan y que determinan su utilidad y existencia. La calidad es sinónimo de eficiencia, flexibilidad, corrección, confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e integridad. (Carrasco, 1995)
Según Presuman: La calidad es la concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos con los estándares de desarrollo explícitamente documentados y con las características implícitas que se espera de todo software desarrollado profesionalmente (Pressman, 2005).
La IEEE en 1990 define calidad como el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario (Calero, 2007).
La norma ISO 8402 define calidad como el conjunto de características de una entidad, que le confieren la aptitud para satisfacer las necesidades establecidas y las implícitas (González, 2009).
Característica según la cual se demuestra que se ha creado un producto que cumple los requisitos acordados, medidos según medidas y criterios acordados, y que se produce siguiendo un proceso acordado. (RUP, 2006).
10 Según (Calero, 2007) “la calidad es la adecuación del producto al uso. Conformidad con requisitos y confiabilidad en el funcionamiento. Cero defectos…”
El American Heritage Dictionary define la calidad como “una característica o atributo de algo”. Como atributo de un elemento, la calidad se refiere a las características mensurables, cosas que se pueden comprar con estándares conocidos como longitud, color, propiedades eléctricas, maleabilidad etc. Sin embargo, el software en su gran extensión, como entidad intelectual es más difícil de caracterizar que los objetos físicos.
En el desarrollo de software, la calidad de diseño acompaña a la calidad de los requisitos, especificaciones y diseño del sistema. La calidad de concordancia es un aspecto centrado principalmente en la implementación, si la implementación sigue al diseño y el sistema resultante cumple con los objetivos de requisitos y de rendimiento, la calidad de concordancia es alta. Entonces a grandes rasgos la calidad es el grado con el cual el usuario percibe que el software cumple con sus expectativas.
La calidad del software puede medirse después de elaborado el producto. Pero esto puede resultar muy costoso si se detectan problemas derivados de imperfecciones en el diseño, por lo que es imprescindible tener en cuenta tanto la obtención de la calidad como su control durante todas las etapas del ciclo de vida del software.
Esto demuestra que un software debe tener relacionados enfoques de proceso, producto y efecto, a través de la aplicación de varios modelos y estándares como se menciona anteriormente, además garantizar que sea aceptado por clientes satisfechos: entonces, será un producto software con calidad.
1.2.2 Calidad a nivel de proceso.
Un proceso de software es un conjunto de actividades, métodos, prácticas y transformaciones que se llevan a cabo para construir y mantener un software (RUP, 2006). El control de calidad es un factor importante a tener en cuenta en cualquier proceso que se implemente, un error cometido en cualquiera de los procesos o subprocesos puede afectar gravemente en la calidad del proyecto y a su vez en el nivel de satisfacción del cliente.
1.2.3 Calidad a nivel de producto.
La calidad de un producto software se centra en el conjunto de cualidades que lo caracterizan, el objetivo de la calidad no es lograr un producto perfecto, sino obtener un producto que cumpla con las características necesarias y suficientes que precisa el cliente.
11 Según (Ceballos, 2008) la calidad del producto abarca los siguientes aspectos:
Calidad Interna: Medible a partir de las características intrínsecas.
Calidad Externa: Medible en el comportamiento del producto.
Calidad en Uso: Durante la utilización efectiva por parte del usuario.
1.3 Concepto de prueba.
Las pruebas es una actividad en la cual un sistema o componente es ejecutado bajo unas condiciones o requerimientos especificados, los resultados son observados y registrados, y una evaluación es hecha de algún aspecto del sistema o componente.
(IEEE, 1990)
La prueba de software es un elemento crítico para la garantía de la calidad del software y representa una revisión final de las especificaciones del diseño y de la codificación. (Fuentes, 2003)
La prueba de un sistema se define como el proceso de ejercitar o evaluar el sistema, por medios manuales o automáticos, para verificar que satisface los requerimientos o, para identificar diferencias entre los resultados esperados y los que producen el sistema (IEEE, 1990)
Comprobar la respuesta de un sistema a los estímulos y comparar esa respuesta a un estándar. Evaluar la calidad de la respuesta con respecto a la estándar. Dado un cierto software y una lista de las funciones que se supone que haga, descubrir si las realiza de la forma que se describe. Adicionalmente, descubrir si hace otras funciones que no se describan. (HUTCHESON, 2003)
“Las pruebas del software son el proceso de ejecución de un programa con la intención de descubrir un error.” (Pressman, 2005)
A grandes rasgos podemos decir que las pruebas de software no son más que la verificación constante del comportamiento del software a partir de un conjunto finito de casos de prueba, las cuales se pueden efectuar manuales o automatizadas comprobando la satisfacción de los requerimientos solicitados por el cliente.
1.4 Objetivo de las pruebas.
Un buen caso de pruebas es aquel que tiene una alta probabilidad de mostrar un error no conocido hasta entonces. Una prueba tiene éxito si descubre un error no detectado hasta entonces. (Pressman, 2005)
Con estos elementos se define cual es el objetivo fundamental de la prueba de un software. A continuación se enuncian algunas actividades que pueden considerarse como parte de los objetivos generales de las pruebas:
12 Encontrar y documentar defectos en la calidad de software.
Advertir sobre la calidad percibida del software.
Validar y probar las especificaciones hechas en el diseño y especificación de requerimientos a través de una demostración concreta. (Guerrero, 2009)
1.4.1 Atributos que definen una buena prueba
Según Pressman todos los investigadores le atribuyen diferentes características a las pruebas, pero la mayoría coinciden en qué una prueba es buena si tiene los siguientes atributos definidos (Pressman, 2005):
Alta probabilidad de encontrar un error: Para que esto se logre, el responsable de las pruebas debe entender el software e intentar desarrollar una imagen mental de cómo podría fallar el sistema.
No puede ser redundante: Este atributo es muy significativo porque muchas veces se piensa que la prueba debe cubrir todo el sistema sin comprender lo costoso que puede ser esto. Por eso no se debe realizar una prueba que tenga el mismo propósito que otra.
La mejor de la cosecha: Debido a las limitaciones de tiempo y recursos, cuando existen un grupo repruebas con propósito similar se debe escoger la que tenga la más alta probabilidad de descubrir una clase entera de errores.
1.5 Principios de las pruebas.
Se debe tener en cuenta que la prueba no puede asegurar la ausencia de defectos, sólo puede demostrar que existen defectos en el software (Pressman, 2005). Esa afirmación de gran relevancia pues aunque no se encuentren defectos en la prueba no quiere decir que el sistema esté libre de ellos, por lo tanto la presencia de defectos no puede tomarse como responsabilidad del equipo de prueba, no obstante la prueba debe ser vista como una oportunidad del equipo de desarrollo para demostrar que el software desarrollado cumple con las especificaciones planteadas por el cliente. Antes de la aplicación de métodos para el diseño de casos de prueba, se hace necesario conocer los principios básicos que guían las pruebas del software. Los principios más conocidos y fundamentales son (Pressman, 2005):
A todas las pruebas se le debería poder hacer un seguimiento hasta los requisitos del cliente. Como se ha visto el objetivo de las pruebas del software es descubrir errores. Se entiende que los defectos mas graves, desde
13 el punto de vista del cliente, son aquellos que impiden al programa cumplir sus requisitos.
Las pruebas deberían planificarse mucho antes de que empiecen. La planificación de los casos de pruebas puede comenzar tan pronto como esté completo el modelo de requisitos. La definición detallada de los casos de prueba pueden empezar tan pronto como el modelo de diseño se haya consolidado. Por tanto, se pueden planificar y diseñar todas las pruebas antes de generar ningún código.
El principio de Pareto es aplicable a la prueba del software. El principio de Pareto implica que al 80 por ciento de todos los errores descubiertos durante las pruebas surgen al hacer un seguimiento de sólo el 20 por ciento de todos los módulos del programa. El problema está en aislar estos módulos sospechosos y probarlos.
Las pruebas deberían empezar por lo pequeño y progresar hacia lo más grande. Las primeras pruebas planeadas y ejecutadas se centran generalmente en módulos individuales del programa y a medida que avanzan las pruebas, se concentran en encontrar errores en grupos integrados de módulos y finalmente al sistema completo.
No son posibles las pruebas exhaustivas. Esto es uno de los principios que debemos tener en cuenta a la hora de realizar las pruebas porque en un programa pequeño la cantidad de permutaciones de caminos es muy grande, por lo que es imposible cubrir todas las combinaciones de caminos. Es posible, sin embargo es posible cubrir adecuadamente la lógica del programa y asegurarse de que se han aplicado todas las condiciones del diseño procedimental.
Para ser más efectivas, las pruebas deberían ser conducidas por un equipo independiente. Se ha demostrado que el ingeniero de software que creó el sistema no es el más indicado para realizar las pruebas al sistema.
Una prueba que cumpla con estos principios tiene una alta probabilidad de cumplir el objetivo fundamental de las mismas, que es encontrar errores en el producto software.
Para lograr esto es muy útil la utilización de listas de comprobación o chequeo y definir el procedimiento a ejecutar.
1.6 Niveles de Prueba.
La prueba es aplicada para diferentes tipos de objetivos, en diferentes escenarios o niveles de trabajo. Se distinguen los siguientes niveles de pruebas:
14
1.6.1 Prueba de Desarrollador.
Es la prueba diseñada e implementada por el equipo de desarrollo. Tradicionalmente estas pruebas han sido consideradas solo para la prueba de unidad, aunque en la actualidad en algunos casos pueden ejecutar pruebas de integración. Se recomienda que estas pruebas cubran más que las pruebas de unidad. (RUP, 2006)
1.6.2 Prueba Independiente.
Es la prueba que es diseñada e implementada por alguien independiente del grupo de desarrolladores. El objetivo de estas pruebas es proporcionar una perspectiva diferente y en un ambiente más rico que los desarrolladores. Una vista de la prueba independiente es la prueba independiente de los stakeholders, que son pruebas basadas en las necesidades y preocupaciones de los stakeholders. (RUP, 2006)
1.6.3 Prueba de Unidad.
La prueba de unidad se centra en la verificación de los elementos más pequeños del software que se puedan probar. Normalmente, las pruebas de unidad se aplican a componentes representados en el modelo de implementación para verificar que se cubren los flujos de control y los flujos de datos y que funcionan como se esperaba. El programador realiza la prueba de unidad mientras se desarrolla la unidad. Los detalles de la prueba de unidad se describen en la disciplina de implementación. (RUP, 2006)
1.6.4 Prueba de Integración.
Es ejecutada para asegurar que los componentes en el modelo de implementación operen correctamente cuando son combinados para ejecutar un caso de uso. Se prueba un paquete o un conjunto de paquetes del modelo de implementación. Estas pruebas descubren errores o incompletitud en las especificaciones de las interfaces de los paquetes. Esta prueba debe ser responsabilidad de desarrolladores y de independientes, sin solaparse las pruebas. (RUP, 2006)
Es el proceso de combinar y probar múltiples componentes juntos. El objetivo es tomar los componentes probados en unidad y construir una estructura de programa que esté de acuerdo con lo que dicta el diseño.
Se llama integración incremental cuando el programa se construye y se prueba en pequeños segmentos en los que los errores son más fáciles de aislar y corregir, es más probable que se pueda probar completamente las interfaces y se puede aplicar un enfoque de prueba sistemática.
15 Las pruebas de integración atacan directamente a un acoplamiento paulatino de los módulos anteriormente probados, este tipo de prueba maneja dos conceptos fundamentales (Ver figura 1.1):
Figura 1.1. Flujo de los conceptos de Pruebas de integración descendente y ascendente.
1.6.4.1 Integración descendente (Top-Down):
Se integran los módulos moviéndose hacia abajo por la jerarquía de control.
Comenzando por el módulo principal, los módulos subordinados se van incorporando a la estructura, en forma primero en profundidad, que integra todos los módulos de un camino de control principal de la estructura, o primero en anchura, que incorpora todos los módulos directamente subordinados a cada nivel, moviéndose por la estructura de forma horizontal (Pressman, 2005).
Este proceso se realiza en una serie de cinco pasos (Pressman, 2005):
Se usa el módulo de control principal como controlador de la prueba, disponiendo de resguardos para todos los módulos directamente subordinados al módulo de control principal.
Dependiendo del enfoque de integración elegido se van sustituyendo los resguardos subordinados uno a uno por los módulos reales.
Se llevan a cabo pruebas cada vez que se integra un nuevo módulo.
Tras terminar cada conjunto de pruebas, se reemplaza otro resguardo con el módulo real.
Se hace la prueba de regresión para asegurarse de que no se han introducido errores nuevos.
16 El programa continúa desde el paso 2 hasta que se haya construido la estructura del programa entero.
Al aplicar esta estrategia pueden surgir algunos problemas, el más común se da cuando se requiere un proceso de los niveles más bajos de la jerarquía para poder probar adecuadamente los niveles superiores. Al principio de la prueba descendente, los módulos de bajo nivel se reemplazan por resguardos; por tanto, no pueden fluir datos significativos hacia arriba por la estructura del programa (Pressman, 2005). Para solucionar esto se tienen tres opciones (Pressman, 2005):
Retrasar muchas de las pruebas hasta que los resguardos sean reemplazados por los módulos reales.
Desarrollar resguardos que realicen funciones limitadas que simulen los módulos reales.
Integrar el software desde el fondo de la jerarquía hacia arriba.
1.6.4.2 Integración Ascendente (Bottom-Up):
Empieza la construcción y la prueba con los módulos de los niveles más bajos de la estructura del programa. Dado que los módulos se integran de abajo hacia arriba, el proceso requerido de los módulos subordinados a un nivel dado siempre están disponibles y se elimina la necesidad de resguardos. Se puede implementar una estrategia de integración ascendente mediante los siguientes pasos (Pressman, 2005):
Se combinan los módulos de bajo nivel en grupos que realicen una subfunción específica del software.
Se escribe un controlador para coordinar la entrada y la salida de los casos de prueba.
Se prueba el grupo.
Se eliminan los controladores y se combinan los grupos moviéndose hacia arriba por la estructura del programa.
A medida que la integración progresa disminuye la necesidad de controladores de prueba diferentes. La selección de una estrategia de integración depende de las características del software y de la planificación del proyecto. Una buena alternativa es usar una mezcla de las dos estrategias (Ascendente y Descendente) que use la descendente para los niveles superiores de la estructura, junto con la ascendente para los niveles subordinados.
A medida que progresa la prueba de integración, se deben identificar los módulos críticos. Un módulo crítico es aquel que tiene una o más de las siguientes características:
17 Está dirigido a varios requisitos del software
Tiene un mayor nivel de control Es complejo o propenso a errores.
Tiene unos requisitos de rendimiento muy definidos.
Los módulos críticos deben probarse lo antes posible.
1.6.4.3 Regresión.
Cada vez que se añade un nuevo módulo como parte de una prueba de integración, el software cambia. Estos cambios pueden causar problemas con funciones que antes trabajaban perfectamente. La prueba de regresión es la actividad que ayuda a asegurar que los cambios no introducen un comportamiento no deseado o errores adicionales. El conjunto de pruebas de regresión contiene tres clases diferentes de casos de prueba (Pressman, 2005):
Una muestra representativa de pruebas que ejercite todas las funciones del software.
Pruebas adicionales que se centran en las funciones del software que se van a ver probablemente afectadas por el cambio.
Pruebas que se centran en los componentes del software que ha cambiado.
No es práctico ni eficiente volver a ejecutar cada prueba de cada función del programa después de un cambio, a medida que progresa la prueba de integración el número de pruebas de Regresión puede crecer demasiado por lo que el conjunto de pruebas de Regresión debería diseñarse para incluir solo aquellas pruebas que traten una o más clases de errores en cada una de las funciones principales del programa. (Pressman, 2005)
1.6.5 Prueba de Sistema.
Son las pruebas que se hacen cuando el software está funcionando como un todo. Es la actividad de prueba dirigida a verificar el programa final, después que todos los componentes de software y hardware han sido integrados. En un ciclo iterativo estas pruebas ocurren más temprano, tan pronto como subconjuntos bien formados de comportamiento de caso de uso son implementados (RUP, 2006).
Tipos de Pruebas del Sistema
Prueba de Recuperación: Es una prueba del sistema que fuerza el fallo del software de muchas formas y verifica que la recuperación se lleva a cabo apropiadamente.
18 Prueba de Seguridad: Intenta verificar que los mecanismos de protección
incorporados en el sistema lo protegerán, de hecho, de acceso impropios.
Prueba de Resistencia: Están diseñadas para enfrentar a los programas con situaciones anormales.
Prueba de Rendimiento: Está diseñada para probar el rendimiento del software en tiempo de ejecución dentro del contexto de un sistema integrado.
1.6.6 Prueba de Aceptación.
Prueba de aceptación del usuario es la prueba final antes del despliegue del sistema.
Su objetivo es verificar que el software está listo y que puede ser usado por usuarios finales para ejecutar aquellas funciones y tareas para las cuales el software fue construido. (RUP, 2006)
1.7 Tipos de Prueba.
Las pruebas de software informático implican mucho más que la simple evaluación de las funciones, la interfaz y las características de tiempo de respuesta de un destino de la prueba. Las pruebas adicionales deben centrarse en características y atributos, como el destino de la prueba. (RUP, 2006)
Funcionalidad (Software, 2007):
Función: Pruebas fijando su atención en la validación de las funciones, métodos, servicios, caso de uso.
Seguridad: Asegurar que los datos o el sistema solamente es accedido por los actores deseados.
Volumen: Enfocada a verificar las habilidades de los programas para manejar grandes cantidades de datos, tanto como entrada, salida o residente en la BD.
Usabilidad (Software, 2007):
Usabilidad: Prueba enfocada a factores humanos, estéticos, consistencia en la interfaz de usuario, ayuda sensitiva al contexto y en línea, asistente documentación de usuarios y materiales de entrenamiento.
Fiabilidad (Software, 2007):
Integridad: Enfocada a la valoración de la robustez (resistencia a fallos).
Estructura: Enfocada a la valoración a la adherencia a su diseño y formación.
Este tipo de prueba es hecho a alas aplicaciones Web asegurando que todos los enlaces están conectados, el contenido deseado es mostrado y no hay contenido huérfano.
19 Stress: Enfocada a evaluar cómo el sistema responde bajo condiciones anormales. (Extrema sobrecarga, insuficiente memoria, servicios y hardware no disponible, recursos compartidos no disponible)
Rendimiento (Software, 2007):
Benchmark: es un tipo de prueba que compara el rendimiento de un elemento nuevo o desconocido a uno de carga de trabajo de referencia conocido.
Contención: Enfocada a la validación de las habilidades del elemento a probar para manejar aceptablemente la demanda de múltiples actores sobre un mismo recurso (registro de recursos, memoria, etc)
Carga: Usada para validar y valorar la aceptabilidad de lo límites operacionales de un sistema bajo carga de trabajo variable, mientras el sistema bajo prueba permanece constante. La variación en carga es simular la carga de trabajo promedio y con picos que ocurre dentro de tolerancias operacionales normales.
Performance profile: Enfocadas a monitorear el tiempo en flujo de ejecución, acceso a datos, en llamada a funciones y sistema para identificar y direccional los cuellos de botellas y los procesos ineficientes.
Soportabilidad (Software, 2007):
Configuración: Enfocada a asegurar que funciona en diferentes configuraciones de hardware y software. Esta prueba es implementada también como prueba de rendimiento del sistema.
Instalación: Enfocada a asegurar la instalación en diferentes configuraciones de hardware y software bajo diferentes condiciones (insuficiente espacio en disco, etc.)
1.8 Diseño de casos de prueba
El diseño de casos de prueba puede requerir tanto esfuerzo como el propio diseño inicial del producto, debemos diseñar pruebas que tengan la mayor probabilidad de encontrar el mayor número de errores con la menor cantidad de esfuerzo y tiempo posible. (Pressman, 2005)
Un caso de prueba es un conjunto de entradas de pruebas, condiciones de ejecución y resultados esperados desarrollados para cumplir un objetivo en particular ó una función esperada, es la entidad más simple que siempre es ejecutada como una unidad, desde el comienzo hasta el final.
Las bases para una prueba es el material fuente que suministra el estímulo para la prueba, las pruebas para los requerimientos están basadas en los documentos de los
20 requerimientos para las funciones están basadas en las especificaciones funcionales del diseño y para la lógica interna están basadas en las especificaciones internas del diseño o el código.
Cualquier producto de ingeniería puede ser probado de una de dos formas (Pressman, 2005):
Conociendo la función específica para la que fue diseñado el producto, se pueden llevar a cabo pruebas que demuestren que cada función es completamente operativa. Este caso se realiza sobre las interfaces y se le denomina prueba de caja negra.
Conociendo el funcionamiento del producto, se puede desarrollar pruebas que aseguren que “todas las piezas encajan”, o sea, que la operación interna se ajusta a las especificaciones y que todos los componentes internos se han comprobado en forma adecuada. Esta prueba se desarrolla en base a los caminos lógicos del modulo, se denomina prueba de caja blanca.
Los casos de pruebas deben verificar:
Si el producto satisface los requerimientos del usuario, tal y como se describe en las especificación de los requerimientos.
Si el producto se comporta como se desea, tal y como se describe en las especificaciones funcionales del diseño.
1.9 Métodos de Prueba.
Existen dos métodos fundamentales de Prueba: el método de la Caja Blanca y el método de la Caja Negra:
La prueba de la caja blanca del software comprueba los caminos lógicos del software proponiendo casos de prueba que se ejerciten conjuntos específicos de condiciones y/o bucles. Se puede examinar el estado del programa en varios puntos para determinar si el estado real coinciden con el esperado o mencionado. (Pressman, 2005)
La prueba de caja negra se refiere a las pruebas que se llevan a cabo sobre la interfaz del software. O sea, los casos de prueba pretenden demostrar que las funciones del software son operativas, que la entrada se acepta de forma adecuada y que se produce un resultado correcto, así como que la integridad de la información externa se mantiene. (Pressman, 2005)
La Figura 1.2. Representa gráficamente la filosofía de las pruebas de caja blanca y caja negra. Como se puede observar las pruebas de caja blanca necesitan conocer los
21 detalles procedimentales del código, mientras que las de caja negra únicamente necesitan saber el objetivo o funcionalidad que el código ha de proporcionar.
Figura 1.2. Representación de pruebas de Caja Blanca y Caja Negra
1.9.1 Pruebas de la caja blanca.
La prueba de la caja blanca es un método de diseño de casos de prueba que usa la estructura de control del diseño procedimental para derivar los casos de prueba.
Mediante los métodos de prueba de la caja blanca, el ingeniero de software puede obtener casos de prueba que garanticen que (Pressman, 2005):
Se ejercitan al menos una vez todos los caminos independientes de cada módulo.
Se ejercitan todas las decisiones lógicas en sus caras verdaderas y falsas.
Se ejecutan todos los bucles en sus límites y con sus límites operacionales.
Se ejercitan las estructuras de datos internas para asegurar su validez.
En estas encrucijadas se puede exponer una pregunta razonable:” ¿Por qué gastar tiempo y energía probando y preocupándose de las minuciosidades lógicas cuando podríamos gastar mejor el esfuerzo asegurando que se han alcanzado los requerimientos del programa?”. La respuesta se encuentra en la naturaleza misma de los defectos del software. (Pressman, 2005)
Los errores lógicos y las suposiciones incorrectas son inversamente proporcionales a la probabilidad de que se ejecute un camino del programa. Los errores tienden a producirse en nuestro trabajo cuando diseñamos o implementamos funciones, condiciones o controles que se encuentran fuera de lo normal. El procedimiento habitual tiende a hacer más comprensible, mientras que el procesamiento de “casos especiales” tiende a caer en el caos. (Pressman, 2005)
22 A menudo creemos que un camino lógico tiene pocas posibilidades de ejecutarse cuando, de hecho, se puede ejecutar de forma regular. El flujo lógico 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 diseño que solo se descubren cuando comienza la prueba del camino.
Los errores tipográficos son aleatorios. Cuando se traduce un programa a código fuente de un lenguaje de programación, es muy probable que se den algunos errores de escritura. Muchos serán descubiertos por los mecanismos de comprobación de sintaxis, pero otros permanecerán sin detectar hasta que comience la prueba. Es igual de probable que haya un error tipográfico en un oscuro camino lógico que en un camino principal. (Pressman, 2005)
Cada una de estas razones nos da un argumento para llevar a cabo las pruebas de caja blanca. Las pruebas de caja negra pueden pasarse los tipos de errores que acabamos de señalar. Como estableció Beizer: “Los errores se esconden en los rincones y se aglomeran en los límites”. Es mucho más fácil de descubrirlos con la prueba de caja blanca.
Se pueden combinar ambos métodos para llegar a un método que valide la interfaz del software y asegure selectivamente que el funcionamiento interno del software es correcto.
1.9.1.1 La prueba del camino básico:
La prueba del camino básico es una técnica de prueba de la caja blanca propuesta inicialmente por Tom McCabe. El método del camino básico permite al diseñador de casos de prueba derivar una medida de complejidad lógica de un diseño procedural y usar esa medida como guía para la definición de un conjunto básico de caminos de ejecución. Los casos de prueba derivados del conjunto básico garantizan que durante la prueba se ejecuta por lo menos una vez cada sentencia del programa. (Pressman, 2005)
Antes de considerar el método del camino básico se debe introducir una sencilla notación para la representación del flujo de control, denominada grafo de flujo. El grafo de flujo se utiliza para representar flujo de control lógico de un programa. Para ello se utilizan los tres elementos siguientes (Pressman, 2005):
Nodos: representan cero, una o varias sentencias en secuencia. Cada nodo comprende como máximo una sentencia de decisión (bifurcación).
Aristas: líneas que unen dos nodos.
23 Regiones: áreas delimitadas por aristas y nodos. Cuando se contabilizan las regiones de un programa debe incluirse el área externa como una región más.
Nodos predicados: Cuando en una condición aparecen uno o más operadores lógicos (AND, OR, XOR) se crea un nodo distinto por cada una de las condiciones simples. Cada nodo generado de esta forma se denomina nodo predicado
Cada construcción lógica de un programa tiene una representación. La Figura 1.4 muestra las representaciones que se utilizan.
Figura 1.4. Notación de grafo de flujo
1.9.1.2 La prueba de condición:
Es un método de diseño de casos de prueba que ejercita las condiciones lógicas contenidas en el módulo de un programa. (Pressman, 2005)
El método de la prueba de condiciones se centra en la prueba de cada una de las condiciones del programa. La estrategia de prueba de condiciones tiene, generalmente, dos ventajas. La primera, que la cobertura de la prueba de una condición es sencilla. La segunda, que la cobertura de la prueba de las condiciones de un programa da una orientación para generar pruebas adicionales del programa. El propósito de la prueba de condiciones es detectar no solo los errores de las condiciones de un programa, sino también otros errores en dicho programa.
(Pressman, 2005)
24 1.9.1.3 La prueba de flujo de datos:
Se selecciona caminos de prueba de un programa de acuerdo con la ubicación de las definiciones y los usos de las variables del programa (Pressman, 2005). Las estrategias de prueba de flujo de datos son útiles para seleccionar caminos de prueba de un programa que contenga sentencias if o bucles anidados. Se necesita conocer la estructura de cada condición o bloque, seleccionando un camino del programa, se determina si el camino es factible para el mismo.
1.9.1.4 La prueba de bucles:
Los bucles son la piedra angular de la mayoría de los algoritmos implementados en software. Y por ello debemos prestarle normalmente un poco de atención cuando llevamos a cabo la prueba del software. (Pressman, 2005)
La prueba de bucles es una técnica de prueba de caja blanca que se centra exclusivamente en la validez de las construcciones de bucles. Se pueden definir cuatro clases diferentes de bucles: Bucles simples, Bucles concatenados, Bucles Anidados, y bucles no estructurados. (Pressman, 2005)
Además de un análisis del camino básico que aísle todos los caminos de un bucle, se recomienda un conjunto especial de pruebas adicionales para cada tipo de bucles.
Estas pruebas buscan errores de inicialización, errores de indexación o de incremento y errores en los límites de los bucles.
Bucles Simples: A los bucles simples se les debe aplicar el siguiente conjunto de pruebas, donde n es el número máximo de pasos permitidos por bucle (Pressman, 2005):
Saltar totalmente el bucle.
Pasar una sola vez por el bucle.
Pasar dos veces por el bucle.
Hacer m pasos por el bucle con m<n.
Hacer n-1, n y n+1 pasos por bucle.
Bucles Anidados: Si extendiéramos el enfoque de prueba de los bucles simples a los bucles anidados, el número de posibles pruebas crecería geométricamente a medida que aumenta el nivel de anidamiento. Esto nos llevaría a un número impracticable de pruebas. Se sugiere un enfoque que ayuda a reducir el número de pruebas (Pressman, 2005):
Comenzar en el bucle más interior. Disponer todos los demás bucles en sus valores mínimos.
25 Llevar a cabo las pruebas de bucles simples con el bucle mas interno mientras se mantiene los bucles exteriores con los valores mínimos para sus parámetros de iteración. Añadir otras pruebas para los valores fuera de rango o para valores excluidos.
Progresar hacia afuera, llevando a cabo las pruebas para el siguiente bucle, pero manteniendo todos los demás bucles exteriores en sus valores mínimos y los demás bucles anidados con valores “típicos”.
Continuar hasta que se hayan probado todos los bucles.
Bucles Concatenados: Los bucles concatenados se pueden probar mediante el enfoque anteriormente definido para los bucles simple, mientras que cada uno de los bucles sea independiente del resto. Por ejemplo, si hay dos bucles concatenados y se usa el contador del bucle 1 como valor inicial del bucle 2, entonces los bucles no son independientes. Cuando los bucles no son independientes, se recomienda usar el enfoque aplicado para los bucles anidados. (Pressman, 2005)
Bucles No Estructurados: Siempre que sea posible, esta clase de bucles se deben rediseñar para que se ajuste a las construcciones de la programación estructurada.
(Pressman, 2005)
1.9.2 Pruebas de la caja negra:
Los métodos de prueba de la caja negra se centran en los requerimientos funcionales del software. O sea, le prueba de la caja negra permite al ingeniero del software derivar conjuntos de condiciones de entrada que ejerciten completamente todos los requerimientos funcionales de un programa. La prueba de la caja negra no es una alternativa a las técnicas de prueba de la caja blanca. Más bien se trata de un enfoque complementario que intenta descubrir diferentes tipos de errores que los métodos de la caja blanca. (Pressman, 2005)
Verifican las especificaciones funcionales y no consideran la estructura interna del programa.
Es hecha sin el conocimiento interno del producto.
No validan funciones ocultas (por ejemplo funciones implementadas pero no descritas en las especificaciones funcionales del diseño) por tanto los errores asociados a ellas no serán encontrados.
En otras palabras, la prueba de la caja negra se refiere a las pruebas que se llevan a cabo sobre la interfaz del software. O sea los casos de prueba pretenden:
Demostrar las funciones del software son operativas.
26 Que las entradas se aceptan de la forma adecuada y que se produce el
resultado correcto.
Así como la integrada de la información externa (por ejemplo archivos de datos) se mantiene.
La prueba de la caja negra intenta encontrar errores de las siguientes categorías (Pressman, 2005):
Funciones incorrecta o ausente Errores de interfaz
Errores en estructura de datos o en acceso a base de datos externas Errores de rendimiento
Errores de inicialización y de terminación.
A diferencia de la prueba de la caja blanca, que se lleva a cabo previamente en el proceso de prueba, la prueba de la caja negra tiende a ser aplicadas en posteriores fases de prueba. Ya que la prueba de la caja negra intencionadamente ignora la estructura de control, concentra su atención en el dominio de la información. Las pruebas se diseñan para responder a las siguientes preguntas (Pressman, 2005):
¿Cómo se prueba la validez funcional?
¿Qué clase de entrada compondrán unos buenos casos de prueba?
¿Es el sistema particularmente sensible a ciertos valores de entrada?
¿De qué forma están aislados los límites de una clase de datos?
¿Qué volúmenes y niveles de datos tolerará el sistema?
¿Qué efectos sobre la operación del sistema tendrán combinaciones específicas de datos?
Mediante las técnicas de prueba de la caja negra se derivan un conjunto de casos de prueba que satisfacen los siguientes criterios (Pressman, 2005):
Casos de prueba que reducen, en un coeficiente que es mayor que uno, el número de casos de prueba adicionales que se deben diseñar para alcanzar una prueba razonable,
Casos de prueba que nos dicen algo sobre la presencia o ausencia de clases de errores asociados solamente con la prueba en particular que se encuentra disponible.
27 1.9.2.1 Técnica Partición de la Equivalencia
La partición equivalente es un método de prueba de la caja negra que divide el dominio de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba. Un caso de prueba ideal descubre de forma inmediata una clase de error (por ejemplo procesamiento incorrecto de todos los datos de carácter) que de otro modo requerirían la ejecución de muchos casos antes de detectar el error genérico. La partición equivalente se dirige a la definición de casos de prueba que descubran clases de errores, reduciendo así el número total de casos de prueba que hay que desarrollar. (Pressman, 2005)
El diseño de casos de prueba para la partición equivalente se basa en una evaluación de las clases de equivalencia para una condición de entrada. Una clase de equivalencia representa un conjunto de estados válidos o inválidos para condiciones de entrada. Típicamente una condición de entrada es un valor numérico específico, un rango de valores, un conjunto de valores relacionados o una condición booleana (si o no). Las clases de equivalencia se pueden definir de acuerdo a las siguientes directrices (Pressman, 2005):
Si una condición de entrada especifica un rango, se define una clase de equivalencia válida y dos inválidas.
Si una condición de entrada requiere un valor especifico, se define una clase de equivalencia válida y dos inválidas.
Si una condición de entrada especifica un miembro de un conjunto, se define una clase de equivalencia válida y una inválidas.
Si una condición de entrada es booleana, se define una clase válida y una inválida.
Aplicando esas directrices para la derivación de clases de equivalencia, se pueden desarrollar y ejecutar casos de prueba para cada elemento de datos del dominio de entrada. Los casos de prueba se seleccionan de forma que se ejercite el mayor número de atributos de cada clase de equivalencia a la vez (Pressman, 2005). El objetivo es minimizar el número de casos de prueba, así cada caso de prueba debe considerar tantas condiciones de entrada como sea posible. No obstante, es necesario realizar con cierto cuidado los casos de prueba de manera que no se enmascaren faltas. Así, para crear los casos de prueba a partir de las clases de equivalencia se han de seguir los siguientes pasos:
Asignar a cada clase de equivalencia un número único.
28 Hasta que todas las clases de equivalencia hayan sido cubiertas por los casos de prueba, se tratará de escribir un caso que cubra tantas clases válidas no incorporadas como sea posible.
Hasta que todas las clases de equivalencia no válidas hayan sido cubiertas por casos de prueba, escribir un caso para cubrir una única clase no válida no cubierta.
La razón de cubrir con casos individuales las clases no válidas es que ciertos controles de entrada pueden enmascarar o invalidar otros controles similares. Por ejemplo, si tenemos dos clases válidas: “introducir cantidad entre 1 y 99” y “seguir con letra entre A y Z”, el caso 105 1 (dos errores) puede dar como resultado 105 fuera de rango de cantidad, y no examinar el resto de la entrada no comprobando así la respuesta del sistema ante una posible entrada no válida.
1.9.2.2 Técnica de Grafos Causa – Efecto.
El uso de grafos de causa – efecto es una técnica de casos de prueba que proporciona una concisa representación de las condiciones lógicas y sus correspondientes acciones. La técnica sigue cuatro pasos (Vázquez, 2001):
Se listan para un módulo las causas (condiciones de entrada) y los efectos (acciones), asignando un identificador a cada uno de ellos.
Se desarrolla un grafo causa – efecto.
Se convierte el grafo en una tabla de decisión.
Se convierten las reglas de la tabla de decisión a casos de prueba.
Si se ha usado una tabla de decisión como herramienta de diseño, los grafos causa – efecto ya no son necesarios.
1.9.2.3 Técnica Análisis de Valores Límites
La experiencia muestra que los casos de prueba que exploran las condiciones límite producen mejor resultado que aquellos que no lo hacen. Las condiciones límites son aquellas que se hallan en los márgenes de la clase de equivalencia, tanto de entrada como de salida. Por ello, se ha desarrollado el análisis de valores límite como técnica de prueba. Esta técnica nos lleva a elegir los casos de prueba que ejerciten los valores límite. Por lo tanto, el análisis de valores límite complementa la técnica de partición de equivalencia de manera que en lugar de seleccionar cualquier caso de prueba de las clases válidas e inválidas, se eligen los casos de prueba en los extremos y en lugar de centrarse sólo en el dominio de entrada, los casos de prueba se diseñan también considerando el dominio de salida. (Pressman, 2005)
29 Las pautas para desarrollar casos de prueba con esta técnica son (Pressman, 2005):
Si una condición de entrada especifica un rango de valores, se diseñarán casos de prueba para los dos límites del rango y otros dos casos para situaciones justo por debajo y por encima de los extremos.
Si una condición de entrada especifica un número de valores, se diseñan dos casos de prueba para los valores mínimo y máximo, además de otros dos casos de prueba para valores justo por encima del máximo y justo por debajo del mínimo.
Aplicar las reglas anteriores a los datos de salida.
Si la entrada o salida de un programa es un conjunto ordenado, habrá que prestar atención a los elementos primero y último del conjunto.
1.10 Estrategia de prueba del software
La estrategia de prueba describe el enfoque y los objetivos generales de las actividades de prueba, integra las técnicas de diseño de casos de prueba en una serie de pasos planificados que dan como resultado una correcta construcción del software (Pressman 2005).La estrategia nos permite conocer cada paso que se lleva a cabo como parte de la prueba, es decir, cuando se deben planificar y realizar cada uno de estos pasos así como el esfuerzo, tiempo y recursos que se van a requerir.
La estrategia define:
Técnicas de pruebas (manual o automática) y herramientas a ser usadas.
Qué criterios de éxitos y culminación de la prueba serán usados.
Consideraciones especiales afectadas por requerimientos de recursos o que tengan implicaciones en la planificación.
Las pruebas son un conjunto de actividades que se pueden planificar por adelantado y llevar a cabo sistemáticamente por lo que se debe definir en el proceso de la ingeniería del software una plantilla para las pruebas del software, esta plantilla estará compuesta por una serie de pasos mediante los cuales se describirán los métodos específicos de diseño de casos de prueba.
Existen varias estrategias de prueba del software las cuales proporcionan al ingeniero del software una plantilla para la prueba y todas tienen las siguientes características generales (Pressman, 2005):
Las pruebas comienzan a nivel de modulo hacia la integración de todo el sistema basado en computadoras.
30 Según el momento, son apropiadas diferentes técnicas de prueba.
La prueba la lleva a cabo el responsable del desarrollo del software y un grupo independiente de prueba.
La prueba y la depuración son actividades diferentes pero la depuración se debe incluir en cualquier estrategia de prueba.
Una estrategia de prueba del software debe incluir pruebas de bajo nivel que verifiquen que todos los pequeños segmentos de código fuente se han implementado correctamente, así como pruebas de alto nivel que validen las principales funciones del software frente a los requisitos del cliente. Más concretamente, los objetivos de la estrategia de prueba son:
Planificar las pruebas necesarias en cada iteración, incluyendo las pruebas de unidad, integración y las pruebas de sistema. Las pruebas de unidad y de integración son necesarias dentro de la iteración, mientras que las pruebas de sistema son necesarias sólo al final de la iteración.
Diseñar e implementar las pruebas creando los casos de prueba que especifican qué probar, cómo realizar las pruebas y creando, si es posible, componentes de prueba ejecutables para automatizar las pruebas.
Realizar diferentes pruebas y manejar los resultados de cada prueba sistemáticamente. Los productos de desarrollo de software en los que se detectan defectos son probados de nuevo y posiblemente devueltas a otra etapa, como diseño o implementación, de forma que los defectos puedan ser arreglados.
1.11 Herramientas para el entorno de prueba.
Dan soporte a las actividades de Aseguramiento de la calidad (AC), pruebas de integración, pruebas de sistema, diagnóstico o refinamiento de las aplicaciones en los entornos de producción que generalmente son difíciles de realizar de una forma integrada, comprenden herramientas de análisis estático, automatización de pruebas funcionales, de carga, de rendimiento, de estrés, etc. Entre estas herramientas podemos mencionar:
1.11.1 WebKing
Automatiza las pruebas Web de una aplicación y el análisis de riesgo del sitio, utilizando pruebas funcionales, pruebas de carga y ejecución de las pruebas de análisis de seguridad. (ALS, 2007)
31 WebKing es una herramienta de pruebas Web automatizada y multiplataforma, que proporciona pruebas exhaustivas y análisis de los sitios y aplicaciones Web para asegurar que cumplen con la fiabilidad, seguridad y metas de desarrollo necesarios para sostener su negocio con eficiencia. Un modo integrado de sistema múltiple, WebKing de Parasoft señala cuatro áreas de interés.
Riesgo del sitio Web.
Análisis funcional.
Pruebas de carga y rendimiento.
Análisis de la seguridad.
Esta herramienta permite la realización de pruebas complejas: análisis de riesgo del sitio Web, pruebas funcionales de carga y desarrollo de pruebas de seguridad y análisis. Además genera automáticamente un conjunto de pruebas funcionales para los caminos críticos de la aplicación, diseña automáticamente pruebas de carga realistas mediante el análisis de sus ficheros de carga del servidor y también verifica el cumplimiento de la accesibilidad y estándares de seguridad.
Estos datos ofrecen los siguientes beneficios (ALS, 2007):
Pruebas Web complejas y análisis en una sola prueba integrada.
La automatización de una tarea completa proporciona resultados inmediatos.
La automatización de la creación de las pruebas amplía la cobertura de las mismas.
Permite a los desarrolladores, al equipo de pruebas y analistas programadores, colaborar y aprovechar el trabajo del otro.
Visibilidad anticipada de errores y vulnerabilidades.
1.11.2 QALoad
Es una herramienta de pruebas para aquellas aplicaciones que estén sometidas a gran carga de usuarios.
Utilizando QALoad se puede emular la carga generada por cientos o miles de usuarios en la aplicación sin requerir la participación de los usuarios finales en sus equipos.
Puede repetir fácilmente las pruebas de carga variando las configuraciones del sistema para alcanzar una aproximación óptima a los escenarios reales de uso. Esta herramienta ofrece módulos configurables que facilitan el desarrollo de los scripts de prueba, estos módulos, llamados EasyScripts, permiten a los ingenieros de pruebas grabar el tráfico que genera la aplicación y convertirlo en un script de prueba. Los scripts de prueba resultantes reflejan el tráfico real generado por la aplicación y miden
32 el tiempo empleado para completar las transacciones y garantizar que el sistema sometido a las pruebas alcance las especificaciones para las que ha sido construido.
Otra de las características presente en esta herramienta es análisis exhaustivo, en cada sesión de prueba, QALoad ofrece las estadísticas de rendimiento en tiempo real y permite a los ingenieros de prueba insertar puntos de control dentro de los scripts para identificar y revisar áreas específicas del rendimiento del sistema, muestra los resultados de las pruebas en una amplia variedad de informes y gráficas, los datos de las sesiones de prueba se pueden exportar automáticamente a otros formatos para su revisión en detalle. Esta herramienta también nos permite obtener una vista integrada de los recursos del sistema cuando se integra con ServerVantage, el cual es un sistema que proporciona control del servidor y de la base de datos para asegurar la disponibilidad y rendimiento de los recursos del servidor. La integración entre ServerVantage y QALoad permite monitorizar los recursos del sistema mientras se genera una carga realista de la aplicación, los tiempos de respuesta de la aplicación y la utilización de recursos del sistema durante una prueba de carga pueden ser analizados conjuntamente lo que permite una identificación rápida de los cuellos de botella. Esta herramienta solo corre sobre el sistema operativo Windows. (ALS, 2007)
1.11.3 SOATest
Proporciona verificación instantáneas de servicios Web, simplifica el desarrollo SOA, automatiza las pruebas funcionales de cliente/servidor, pruebas de regresión, pruebas de carga/rendimiento entre otras. (ALS, 2007)
La automatización de pruebas de servicios Web permite a los usuarios verificar todos los aspectos asociados. SOATest localiza los elementos claves de los servicios Web y tales como la interoperabilidad, seguridad, cambio de mantenimiento y escalabilidad.
Es una herramienta multiplataforma, entre sus características más relevantes podemos señalar las siguientes (ALS, 2007):
Pruebas de servicios Web sin scripting
Verificación de consultas, validación y carga de pruebas.
Generación de informes detallados en HTML, XML y formatos de texto.
Gráficos y tablas en tiempo real.
SOATest Asegura la fiabilidad, calidad, seguridad e interoperabilidad de un servicio Web, realiza pruebas de intrusión integradas con pruebas funcionales, para completar la cobertura, también realiza una prevención de errores e identifica posibles errores a ocurrir. Además, verifica la integridad de los datos y la funcionalidad cliente/servidor mientras acelera el tiempo de mercado. (ALS, 2007)
33
1.11.4 JKingQA
Es una herramienta de análisis estático, pensada para facilitar y automatizar el proceso de adopción de los estándares de calidad para un departamento de calidad.
Funciona como aplicación independiente y proporciona información detallada de las violaciones de las reglas y buenas prácticas incumplidas por los desarrolladores.
JkingQA permite la verificación de más de 200 reglas de estándares de codificación Java, también nos brinda la posibilidad de incorporar reglas específicas para una empresa o proyecto específico, así como una documentación detallada de la violación infringida con código de ejemplo de cómo corregirlas. Selecciona y agrupa reglas para diagnósticos rápido del código para un conjunto reducido de reglas. Además nos da la posibilidad de configurar distintos niveles de severidad. (ALS, 2007)
Entre las ventajas de esta herramienta podemos mencionar las siguientes (ALS, 2007):
Evita que errores de programación sencillos, no detectados en la compilación, se conviertan en serios problemas en fases posteriores del ciclo de vida de las aplicaciones.
Mejora la fiabilidad de las aplicaciones.
Ayuda a mantener actualizados los conocimientos en el mejor uso del lenguaje Java.
Mejora el diseño y legibilidad del código.
Facilita la portabilidad del código y el trabajo en equipo, estableciendo normativas comunes, sin tener que documentar de manera exagerada el código.
Reduce los costes de desarrollo, soporte y mantenimiento.
1.11.5 JTest
Jtest 8.0 ofrece varios avances para las industrias desarrolladoras de software de alta calidad. Estos avances tecnológicos están concentrados en la realización de pruebas para ayudar a los equipos a verificar de manera automática la funcionalidad de aplicaciones cada vez más complejas, en empresas con sistemas en permanente cambio, todo esto para generar un incremento en la satisfacción del cliente, una reducción en tiempo de entrega del software así como una disminución del riesgo de generar software defectuoso o con problemas de vulnerabilidad. (ALS, 2007)
Esta es una de las principales herramientas para el entorno de prueba debido a sus características, entre las cuales podemos mencionar las siguientes (ALS, 2007):