2. DOCUMENTACIÓN DE PROGRAMAS. 5
1. PRUEBA DE PROGRAMAS
Podemos usar para la prueba de programas las siguientes:
– Pruebas de la caja blanca: Analizamos el código del programa (el programa por dentro)
o Pruebas del camino básico.
o Pruebas de la estructura de control:
§ Las pruebas de flujo de datos: seleccionamos diferentes caminos de prueba de forma que empleemos todas las variables, constantes…
§ La prueba de condiciones
§ La prueba de bucles
– Pruebas de la caja negra: No nos interesa el interior del programa, solo que funcione como es debido:
o El análisis de valores límite.
o La prueba de comparación. Se emplea en sistemas en tiempo real o en los que se necesita gran fiabilidad. La idea consiste en usar SW y HW que realizan las mismas funciones para evitar todos los errores posibles.
o La partición equivalente o clases de equivalencia.
1.1 Introducción
Van a tener una triple finalidad. (útiles para el programador, para medir la calidad del SW y para el cliente)
Si queremos obtener el máximo rendimiento de una prueba, debemos realizar un diseño de dicha prueba. Debemos incluir:
1. Planificación de la prueba.
2. Diseño de los casos de prueba.
3. Ejecuciones de las pruebas.
4. Recopilación de datos y evaluación de los resultados.
Una prueba de SW debe de ser los suficientemente flexible para promover la creatividad y la adaptabilidad del SW, y lo suficientemente rígido para permitir un buen seguimiento de la misma.
1.2 Pruebas del Software
Son un conjunto de actividades que permiten llevar a cabo una planificación y seguimiento ordenado de las mismas.
En estas pruebas, el ingeniero debe ayudarse de una plantilla para su seguimiento. Debe tener las siguientes características.
– Comienza a nivel de módulo y va avanzando hasta el sistema completo ya integrado.
– Podemos aplicar simultáneamente varias técnicas de prueba.
– La prueba la llevan a cabo el programado y un grupo de prueba.
– Podemos incluir la depuración dentro de las técnicas de prueba.
Debe integrar pruebas de bajo y de alto nivel. Debe de ser una guía tanto para el programador como para el director del proyecto.
1.2.1 Verificación y validación
Las pruebas del SW forman parte de lo que podemos denominar verificación y validación del SW.
Verificación: Comprueba si estamos desarrollando el SW correctamente.
Validación: Comprueba si estamos construyendo el producto correcto.
Las pruebas son la última oportunidad para corregir errores y mejorar la calidad del SW.
1.2.2 Organización de la prueba
· Los desarrolladores del SW empiezan probando cada uno de los módulos que han ido diseñando, hasta que llegar a las pruebas del sistema completo.
· Se van a encontrar bastantes errores en las pruebas modulares, pero no muchos en las pruebas del sistema.
· Para las pruebas del sistema son mucho mejores los grupos independientes de prueba o GIP.
· El GIP es un programador o usuario ajeno al programa. Su misión es probar las versiones beta del programa e informar de fallos a sus desarrolladores.
1.2.3 Una estrategia de prueba
Vamos a ver una estrategia de prueba que podríamos aplicar a la práctica.
1. Pruebas modulares: Tomamos cada módulo de nuestro sistema y los vamos probando.
2. Pruebas de integración: Tomamos cada módulo que componen el sistema y probamos su diseño y la construcción del SW.
3. Pruebas de validación: Partimos del SW ya ensamblado, y con los requerimientos del SW, comprobamos que son correctos.
4.Pruebas del sistema: Probamos el sistema ya completo. Es conveniente que lo realicen elementos externos a nuestro sistema.
1.2.4 Pruebas de la caja blanca
1.2.4.1 Pruebas de camino básico
Es una técnica de caja blanca y una prueba de unidad. Se obtiene una medida de la complejidad lógica de un programa.
Se puede definir un conjunto básico de caminos de ejecución. Con cada camino de ejecución generamos un caso de prueba, de esta forma garantizamos que se ejecuten todas las sentencias, al menos una vez.
En primer lugar, debemos estudiar el flujo de control de nuestro programa. (grafo de flujo) para representar el flujo de control de nuestro programa.
En el grafo de flujo cada construcción estructurada tiene un símbolo que lo representa, aunque se basan en 3 elementos:
– Nodo: Se dibuja como un círculo. Representa un conjunto de sentencias sin bifurcación.
– Aristas: Se dibujan como una flecha. Representan el flujo de control de nuestro programa. Deben empezar en un nodo y acabar en otro.
– Regiones: Áreas delimitadas por nodos y aristas. El exterior del grafo se cuenta como una región más. Para contar el número de regiones de un grafo, calculamos el número de áreas limitadas y no limitadas.
Camino independiente: Introduce un conjunto nuevo de sentencias o una condición nueva.
Conjunto básico: Contiene muchos caminos independientes. No es único, ya que con el mismo grafo podemos sacar diferentes caminos o formas de ejecutar todas las instrucciones.
1.2.4.2 Prueba de flujo de datos
Seleccionamos diferentes caminos, de forma que probemos todas las definiciones, variables y estructuras de datos de nuestros programas.
Una de las estrategias más empleadas es la “DU” (Definición-Uso) Define el camino de prueba más corto donde defina y se use al menos una vez la variable o estructura a estudiar.
1.2.4.3 Prueba de condiciones
Complementa a las anteriores pruebas. Nos centramos en estudiar cada una de las condiciones de nuestro programa. 2 tipos:
– Condición simple: Variable lógica, o expresión relacional, puede tener el operador de negación (NOT)
– Condición compuesta: 2 o más condiciones simples anidadas con los operadores OR, AND y NOT.
El propósito de esta técnica es encontrar errores en las condiciones del programa.
Las diferentes estrategias que podemos encontrar en estas pruebas son:
1. Prueba de ramificaciones: Para las condiciones compuestas, hemos de ejecutar, al menos una vez:
a. Cada condición simple-
b. El resultado de Verdadero y Falso.
2. Prueba del operador relacional: Realización de 3 pruebas para una expresión relacional. Valor1 OperadorRelacional1 Valor2. Probamos cuando valor2 es mayor, menor o igual que el valor1.
3. Prueba del operador relacional y de ramificación: Prueba híbrida de las dos anteriores.
1.2.4.4 Prueba de bucles
Es una prueba de unidad. Es complementaria de la prueba de camino básico. Se basa en estudiar la validez de todos los bucles del programa.
Esta técnica clasifica los bucles en 4 tipos:
1. Bucles simples: Si N es el número máximo de pasos permitidos, debemos aplicar:
a. Pasar por alto completamente el bucle.
b. Pasar solo una vez por el bucle.
c. Pasar 2 veces por el bucle.
d. Hacer m pasos por el bucle, donde m<n.
e. Hacer n-1, n, y n+1 pasos por el bucle.
2. Bucles anidados: Debemos usar una estrategia para reducir el número de pruebas:
a. Comenzamos por el bucle más interior.
b. Realizar las pruebas de bucles simples, para el bucle más interior.
c. Progresamos hacia fuera. Los bucles interiores toman valores usuales y los exteriores se mantienen en sus valores mínimos.
d. Continuamos hasta procesar todos los bucles.
3. Bucles concatenados: 2 casos:
a. Bucles independientes: Se trata a cada uno con la estrategia de prueba de los bucles simples.
b. Bucles dependientes: Usamos el enfoque de los bucles anidados.
Bucles no estructurados: Debemos rediseñarlos para reducirlo a uno de los casos anteriores.
1.2.5 Pruebas de la caja negra
1.2.5.1 Análisis de los valores límite
Estudiamos la entrada de datos en los casos en que está limitada por un rango o número de valores. Los errores suelen ocurrir en los límites de ese rango.
Se basa en elegir entradas cercanas a los límites del rango.
Supongamos que una condición de entrada donde el usuario ha de introducir un valor comprendido entre a y b. Debemos probar los siguientes casos:
1. Diseñamos casos de prueba para los valores a y b
2. Diseñamos casos de prueba para el valor que anterior a a, y el valor anterior a b.
1.2.5.2 Prueba de comparación
Se usa en los sistemas en tiempo real.
Consiste en introducir una serie de entradas y comprobar que en todos los sistemas dan la misma salida.
También puede usarse esta técnica en la sustitución de SW por una versión nueva. En ese caso probamos que las entradas producen las mismas salidas en las diferentes versiones.
1.2.5.3 Partición equivalente
No nos interesa como este escrito el programa. Sólo que funcione.
Estudiamos las entradas de los datos. Para preparar los casos de prueba debemos hacer 2 pasos:
1. Identificación de las clases de equivalencia: Cada condición de entrada se divide en una serie de valores (válidos o inválidos)
a. Rango: Definimos una clase válida, y 2 inválidas.
b. Valor específico: Se define una clase válida, y 2 inválidas.
c. Miembro de un conjunto: Se define una clase válida y otra inválida.
d. Lógica: Se define una clase válida y otra inválida.
2. Definición de los casos de prueba: Ahora vamos a diseñar los casos de prueba siguiente las siguientes directrices:
a. Escribir casos de prueba hasta que todas las clases de equivalencias válidas estén cubiertas. Cada caso de prueba debe cubrir tantas clases de equivalencias como sean posibles.
b. Escribir casos de pruebas hasta que todas las clases de equivalencias inválidas estén cubiertas. Una prueba cubre solo una clase de equivalencia.
2. DOCUMENTACIÓN DE PROGRAMAS
· A la hora de documentas un programa, podemos distinguir 2 tipos de documentación documentación interna (aparece en el código fuente)
· documentación externa (la que adjuntamos a nuestro programa)
2.1 Documentación interna
Se adjunta con el código fuente del programa. Para que nuestro programa sea más claro y comprensible para otros programadores y para los propios desarrolladores.
Debemos seguir unas normas.
Las herramientas que tenemos (identificadores de variables, constantes, funciones, tabulación, identación y comentarios)
Cada bloque de código debe de estar identado y correctamente tabulado.
Programa incomprensible | Programa fácil de comprender |
Program E1; Uses WinCRT; Const C= 166.386 Var P: Integer; Begin Readln(P); Write (P/C: 10: 2); End. | PROGRAM Euros; USES WinCrt; CONST Cambio= 166.386 VAR Pesetas: Integer; BEGIN Write (‘Introduzca la cantidad en pesetas:’); Readln(Pesetas); Writeln(Pesetas, ‘son’, Pesetas/Cambio: 10 : 2 , ‘euros.’); END |
Los comentarios son vitales para facilitar la lectura el código. Pero no hay que sobrecargar de comentarios el programa. Hay que poner los justos.
2.2 Documentación externa
Se pueden diferenciar 2 tipos, dependiendo de la persona a la que vaya dirigida.
Esta documentación incluirá todo lo generado en las diferentes fases de desarrollo de la aplicación, es decir, desde el análisis hasta la implantación de la misma.
2.2.1 Documentación para el experto
Incluiremos todos lo necesario tanto para el ingeniero del SW como para el programador.
Como mínimo esta documentación debe incluir:
– Listado del fuente de la aplicación: incluiremos el código fuente completo del programa con los comentarios.
– – Explicación de los algoritmos complicados que no se puedan ver a primera vista. (las expresiones complejas del programa, funciones o cálculos…)
– Especificación de los datos y formatos de entrada/salida tanto por pantalla como por impresora.
– Listado de los posibles errores generados por el programa y la forma de solucionarlos.
– Listado de todos los ficheros que usa o genera nuestra aplicación.
– Resumen de la aplicación.
– Lenguaje en el que ésta programada y entorno que usa.
– Descripción de las condiciones por defecto tomadas por programas, y las instrucciones necesarias para cambiarlas.
– Diagrama de flujo del programa o diagrama de objetos del mismo.
2.2.2 Documentación para el usuario
Documentación que va dirigida al usuario. En algunos casos será necesario realizar diferentes manuales de usuarios, dependiendo de la persona a la que va dirigida.
Debe darse impresa y si es posible en formato electrónico pdf.
Puntos que son son convenientes a tratar en el manual de usuario:
1. Requisitos del sistema: Debemos indicar tipo de ordenador, S.O, y los recursos HW necesarios para el funcionamiento …
2. Instalación: Pasos necesarios para introducir la aplicación en nuestro sistema. (instalación mínima, completa o personalizada)
3. Manejo del programa: Se explica cómo podemos sacarle el máximo rendimiento a la aplicación que estemos usando.
4. Errores: Detalla los posibles errores de funcionamiento o instalación de nuestra aplicación y la forma de solventar los mismos.
2.2.3 Autodocumentación
Documentación que viene con el propio programa. Es habitual que cualquier aplicación contenga menús de ayuda con información muy diferente:
– Autores del programa, versión del mismo, email para dudas.
– Índice de contenidos con información sobre términos, conceptos, operaciones, o comandos del programa.
– Tutoriales sobre el manejo del programa agrupados por niveles o tipos de usuarios.
– Asistentes o ayudantes.
– Ayuda contextual. Pula F1 o dejar el puntero del ratón sobre un elemento de la pantalla nos aparece una breve explicación o consejo.
2.2.4 Calidad en la documentación
Para que las normas tengas signo de calidad deben cumplir las siguientes condiciones:
– Debe ser fácil entender, emplear un lenguaje sencillo y transparente.
– Completo: ha de tratar todos los aspectos importantes obre los temas que aborde.
– Debe facilitar la localización de información con índices de contenidos (ejemplos, esquemas, referencias a otras páginas del manual…)