Licenciatura en Sistemas - Ingeniería de Software I – 2022
Resumen de Bibliografía: Dr. Dario Rodriguez, Mg. Hernán Amatriain, Ing.
Romina Pontiroli
Equipo docente: Lic. Romina Mansilla
Rita Rocio Bustos
Calidad de Software
Proceso de Pruebas 2
Introducción 2
Planificación de la prueba 2
Diseño de la prueba 3
Determinación de los casos de prueba 3
Planificación del procedimiento de prueba 3
Ejecución de la prueba 3
Análisis y evaluación de la prueba 3
Métodos de prueba 11
Gestión de la Configuración 12
Objetivos 12
Elementos 12
Líneas base 13
Control de Cambios en la Configuración 13
Auditoría de la Configuración 14
Auditoría 14
1
Proceso de Pruebas
1. Introducción
La prueba del software es un elemento crítico para la garantía de calidad del software y representa una
revisión final de las especificaciones, del diseño y de la codificación. En cualquiera de los tipos de pruebas
es posible considerar distintos aspectos a probar, como ser: la funcionalidad del programa, el volumen de
transacciones y la concurrencia de las transacciones.
Existen distintos tipos de pruebas:
● Pruebas unitarias: El proceso de prueba se centra en los procesos lógicos internos del software,
asegurando que todas las sentencias estén probadas y en las funciones externas, buscando que la
entrada definida produzca resultados reales de acuerdo con los resultados requeridos. Las pruebas
de unidades aseguran que los programas de aplicaciones funcionen de forma adecuada cuando se
prueban de forma aislada con respecto a otros programas de aplicación.
● Pruebas de integración: se buscan errores en la interrelación entre los diferentes componentes del
sistema, o relación integral entre los subsistemas
● Pruebas del sistema: Las pruebas de sistemas aseguran que los programas de aplicaciones
escritos de forma aislada funcionen adecuadamente cuando se integran en el sistema global. La
entrada es la especificación de requerimientos del sistema.
● Pruebas que se realizan en la implementación: Pruebas de usuarios, pruebas de control de
calidad, pruebas piloto.
Las actividades básicas de un procedimiento de pruebas y la documentación de salida correspondiente a
cada una de estas actividades son las siguientes:
Planificación de la prueba
En la documentación para la planificación de la prueba se deberá indicar:
● Objetivo de la prueba, detectar fallas,
● Objetos a probar, funcionalidades, procesos, etc.,
● Características a probar, dónde se probará, bajo qué entorno, etc.,
● Características a no probar,
● Método de prueba, el método utilizado en el desarrollo de la prueba,
● Tamaño de la prueba, la cantidad de casos de prueba a realizar,
● Recursos tecnológicos o máquinas. Recursos humanos, mínimo óptimo 3 personas
asignadas, un planificador, un diseñador y un testeador,
● Reparto de responsabilidades, qué tareas tiene asignadas cada integrante,
● Plan de tiempo, Diagrama de Gantt,
● Productos a generar en el proceso de prueba, toda la documentación que tendrá la prueba
una vez finalizada.
2
Diseño de la prueba
En el diseño se deberá puntualizar con:
● Cómo llevar adelante la prueba para alcanzar el objetivo establecido,
● De qué forma se va a usar el método de prueba, brevemente qué método se utilizará y qué probará
ese método,
● Criterios para pasar la prueba, es el punto más importante e indica qué escala utilizaremos para
determinar si algo pasa la prueba o no.
Determinación de los casos de prueba
Determinar puntualmente los casos de prueba, es decir, enumerar uno a uno los casos de pruebas a probar,
indicar el resultado correcto esperado al realizar algún caso de prueba, pudiéndose utilizar una tabla de la
siguiente forma:
Planificación del procedimiento de prueba
Se especificarán los procedimientos que es necesario seguir durante la ejecución de la prueba.
Ejecución de la prueba
Es en sí la ejecución de la prueba propiamente dicha, de acuerdo a la planificación del procedimiento de
prueba.
Análisis y evaluación de la prueba
Se redactarán los informes necesarios sobre el resultado de las pruebas. Cada integrante involucrado
puede realizar informes de análisis y evaluación. Se deberá indicar en forma clara y concisa los resultados
de la prueba.
Ejemplo
Sobre la planificación de pruebas para un sistema que permite realizar un ABMC de una lista de números.
3
1. Plan de Pruebas
4
5
2. Documento de diseño de la prueba
6
3. Especificación de los casos de prueba
7
4. Especificación del procedimiento de prueba
8
5. Informe de los casos de prueba ejecutados
9
6. Informe de la prueba
10
Métodos de prueba
Los métodos de prueba proporcionan un mecanismo de ayuda para asegurar que las pruebas sean
completas y para conseguir una mayor probabilidad de descubrir errores en el software.
Principalmente los métodos de prueba se dividen en dos conjuntos, los que se basan en revisar la
codificación del software sin importar los datos de entrada o salida, y los que, por el contrario, no les
interesa la codificación sino los datos de entrada y salida del software. Las primeras se denominan técnicas
de caja blanca y las segundas técnicas de caja negra, ambos tipos de técnicas son complementarias.
11
Estilo de codificación
Se tiene en cuenta los parámetros para una buena codificación. 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. El
método de prueba de flujo de datos selecciona caminos de prueba de un programa de acuerdo con la
ubicación de las definiciones y los usos de las variables del programa. La prueba de bucles se centra
exclusivamente en la validez de las construcciones de bucles, y éstos pueden ser: simples, concatenados,
anidados y no estructurados.
Adivinación de errores
Se supone qué resultados son los que podrían producir errores.
Para el AVL se debe seleccionar: 1 valor mayor y 1 valor menor del campo a analizar.
Análisis de valores límite (AVL) y clases de equivalencia (CE)
Para cada una de las CE se deben elegir:
● Rangos: 1 caso correcto y 2 casos incorrectos,
● Lógicos: 1 caso válido y 1 caso inválido, y
● Textos: 1 caso correcto y 2 casos incorrectos.
Gestión de la Configuración
1. Objetivos
En términos muy generales, la Gestión de Configuración del Software (GCS) se puede definir como una
disciplina cuya misión es controlar la evolución de un sistema software. La Gestión de Configuración se
debe realizar a lo largo de todo el ciclo de vida del producto, tanto en el desarrollo como en el
mantenimiento, hasta que el producto se retira.
El objetivo de las actividades de Gestión de Configuración del Software es:
● Establecer y mantener la integridad de los productos generados durante un proyecto de desarrollo
de software y a lo largo de todo el ciclo de vida del producto. La integridad de un producto software
significa que el producto cumple las siguientes condiciones:
○ Satisface las necesidades del usuario (cumple todos los requisitos del usuario, tanto los
explícitos como los implícitos)
○ Cumple los requisitos de rendimiento
○ Se puede trazar su evolución desde que se concibió, y a través de todas las fases de su
ciclo de vida.
● Evaluar y controlar los cambios sobre ellos, es decir, controlar la evolución del sistema software.
● Facilitar la visibilidad sobre el producto.
2. Elementos
Al conjunto de toda la información y productos utilizados o producidos en un proyecto como resultado del
proceso de Ingeniería de Software se le denomina CONFIGURACIÓN DEL SOFTWARE. A cada uno de los
componentes de la configuración del software se le va a llamar ELEMENTO DE CONFIGURACIÓN DEL
SOFTWARE (ECS). El ECS es la unidad de trabajo para la GCS. Se pueden considerar como Elementos
de Configuración del Software los siguientes componentes:
● La especificación del sistema.
● El plan del proyecto software.
● La especificación de requisitos software.
● Un prototipo, ejecutable o en papel.
● El diseño preliminar.
12
● El diseño detallado.
● El código fuente.
● Programas ejecutables.
● El manual de usuario.
● El manual de operación e instalación.
● El plan de pruebas.
● Los casos de prueba ejecutados y los resultados registrados.
● Los estándares y procedimientos de ingeniería de software utilizados.
● Los informes de problemas.
● Las peticiones de mantenimiento.
● Los productos hardware y software utilizados durante el desarrollo.
● La documentación y manuales de los productos hardware y software utilizados durante el
desarrollo.
● Diseños de bases de datos.
● Contenidos de bases de datos.
3. Líneas base
Se puede definir una línea base como un punto de referencia en el proceso de desarrollo del software que
queda marcado por la aprobación de uno o varios Elementos de Configuración del Software, mediante una
revisión técnica formal.
La idea consiste en permitir cambios rápidos e informales sobre un elemento de Configuración del Software
antes de que pase a formar parte de una línea base, pero en el momento en que se establece una línea
base se debe aplicar un procedimiento formal para evaluar y verificar cada cambio.
El concepto clave para realizar esta actividad es el de Línea Base. Las líneas base se establecen en hitos
previamente especificados a lo largo del proceso de desarrollo.
Aunque se pueden definir las líneas base con cualquier nivel de detalle, las líneas base más comunes son:
● Línea Base Funcional, que se establece al finalizar la fase de análisis y especificación de los
requisitos del sistema, y comprende todos aquellos documentos en los que se define el problema a
resolver, los costes del proyecto, el plan de tiempos, y los diferentes requisitos funcionales, de
interoperabilidad y de interfaz del sistema.
● Línea Base de Distribución o Asignación de funciones, que se establece al finalizar la fase de
análisis y especificación de requisitos software, y comprende toda la documentación que gobernará
el desarrollo de cada uno de los componentes software que se han identificado en la especificación
del sistema, y la asignación o reparto de las diferentes funciones entre los distintos componentes
del sistema
● Línea Base de Diseño Preliminar, que se establece al finalizar la fase de diseño preliminar.
Comprende todos aquellos documentos en los que se define la arquitectura del producto software,
así como el Plan de Pruebas.
● Línea Base de Diseño, que se establece al finalizar la fase de diseño detallado. Comprende todos
aquellos documentos que contienen el diseño detallado del software y el plan de implementación, y
también la descripción de los casos de prueba.
● Línea Base de Producto, que se establece al finalizar la fase de pruebas. Comprende los
programas creados y todos aquellos documentos que contienen la información relativa a las
pruebas realizadas.
● Línea Base de Operación, que se establece al finalizar la fase de implantación. Comprende los
manuales de usuario, guías de operación y mantenimiento, manuales de formación, etc.
4. Control de Cambios en la Configuración
Es la actividad de Gestión de Configuración más importante y su objetivo es proporcionar un mecanismo
riguroso para controlar los cambios, partiendo de la base de que los cambios se van a producir.
Normalmente combina procedimientos humanos y el uso de herramientas automáticas.
Se pueden considerar fundamentalmente dos tipos de cambios:
● Corrección de un defecto: Los clientes tienden a clasificar todos los cambios en esta categoría.
13
● Mejora del sistema: Los programadores, sin embargo, los suelen clasificar aquí.
Por lo general se establecen varios niveles de control de cambios:
● Control de cambios informal: Antes de que el Elemento de Configuración del Software pase a
formar parte de una línea base, aquel que haya desarrollado el Elemento de Configuración del
Software podrá realizar cualquier cambio justificado sobre él.
● Control de cambios al nivel del proyecto o semi-formal: Una vez que el Elemento de
Configuración del Software pasa la revisión técnica formal y se convierte en una línea base, para
que el encargado del desarrollo pueda realizar un cambio debe recibir la aprobación de:
○ El director del proyecto, si es un cambio local
○ El Comité de Control de Cambios, si el cambio tiene algún impacto sobre otros
○ Elementos de Configuración del Software
● Control de cambios formal: Se suele adoptar una vez que se empieza a comercializar el
producto, cuando se transfieren los ECS a la Biblioteca Maestra. Todo cambio deberá ser aprobado
por el Comité de Control de Cambios.
5. Auditoría de la Configuración
Una auditoría es una verificación independiente de un trabajo o del resultado de un trabajo o grupo de
trabajos para evaluar su conformidad respecto de especificaciones, estándares, acuerdos contractuales u
otros criterios. La auditoría de la configuración es la forma de comprobar que efectivamente el producto que
se está construyendo es lo que pretende ser.
Se pueden diferenciar tres tipos de actividades:
● Revisiones de fase: Se realizan al finalizar cada fase del desarrollo y su objetivo es examinar los
productos de dicha fase. Las revisiones propias de la Gestión de configuración son aquellas en las
que se establecerán las líneas base. El objetivo de esta revisión es descubrir problemas, no
comprobar que todo está bien. Hay que ser capaz de desenmascarar los problemas ocultos y
sutiles, no sólo los que son obvios.
● Revisiones de cambios: Se realizan para comprobar que los cambios aprobados sobre una línea
base se han realizado correctamente.
● Auditorías: Se realizan al final del proceso de desarrollo de software y su objetivo es examinar el
producto en su conjunto.
Auditoría
La auditoría en informática es la revisión y evaluación de los controles, sistemas, procedimientos de
informática y de los equipos de cómputo, su utilización, eficiencia y seguridad, a fin de que por medio del
señalamiento de cursos alternativos se logre una utilización más eficiente y segura de la información que
servirá para una adecuada toma de decisiones.
La evaluación a desarrollar para la realización de la auditoría en informática deben hacerla personas con
alto grado de conocimiento en informática y con mucha experiencia en el área.
14
