Enero – Mayo 2024
Ingeniería en Sistemas
Computacionales
Mtra. Ana Cecilia
Ruiz Calvillo
CALIDAD DE SOFTWARE
Tipos de Pruebas
Pruebas de Diseño
¿Qué es el Diseño?
• El diseño es el primer paso de la fase de desarrollo
de cualquier producto o sistema.
• “Es el proceso de aplicar distintas técnicas y
principios con el propósito de definir un dispositivo,
proceso o sistema con los suficientes detalles como
para permitir su realización física”
Tipos de Diseño
• El diseño de datos transforma el modelo del campo
de información, creado durante el análisis, en las
estructuras de datos que se van a requerir para
implementar el software.
• El diseño arquitectónico define las relaciones entre
los principales elementos estructurales del programa.
• El diseño procedimental transforma los elementos
estructurales en una descripción procedimental del
software.
¿Cómo probar el diseño?
• Se pueden realizar revisiones formales e informales
del diseño.
• Depende de la metodología de diseño seleccionada.
• Independiente de la metodología seleccionada existe
un conjunto de características deseables en el
diseño.
Características de un buen diseño
• Debe exhibir una organización jerárquica que haga
uso inteligente del control entre los componentes de
software.
• Debe ser modular; esto es, el software debe estar
dividido de forma lógica en elementos que realicen
funciones y subfunciones específicas.
• Debe contener representaciones distintas y
separadas de los datos y los procedimientos.
• Debe llevar a módulos que exhiban características
funcionales independientes.
• Debe llevar a interfaces que reduzcan la complejidad
de las conexiones entre los módulos y el entorno
exterior.
• Debe obtenerse mediante un método que sea
reproducible y que esté conducido por la información
obtenida durante el análisis de los requisitos de
software.
Revisiones de Diseño
• Generalmente se pueden realizar dos tipos
de revisiones al diseño.
– Revisión del diseño preliminar, que confirma la
traducción de los requisitos al diseño y se centra
en la arquitectura del software.
– Inspección del diseño, que centra su atención en
la corrección procedimental de los algoritmos, tal
como están implementados en los módulos del
programa.
Consideraciones del Diseño
• El diseño representa también un insumo para la
prueba.
• Nos permitirá refinar los casos de prueba iniciados en
la fase de requerimientos y diseñar las pruebas de
subsistema y de integración.
• Representa un insumo para la prueba de la
construcción.
Tipos de Pruebas
Pruebas Unitarias
• Todos los pasos de la ingeniería de software tienen
como objetivo final traducir las representaciones del
software a una forma que pueda ser “comprendida”
por la computadora.
• Las características del lenguaje de programación y el
estilo de programación pueden afectar
profundamente a la calidad y al mantenimiento del
software.
Etapa de Construcción (codificación)
• El paso de construcción traduce una representación
de software, dada por un diseño detallado, a una
realización en un lenguaje de programación.
• El paso inicial de traducción es un punto fundamental
dentro del contexto de la ingeniería del software.
• En el proceso de traducción puede aparecer “ruido”
en muchas formas:
– La interpretación equivocada de las
especificaciones del diseño detallado.
– La complejidad o restricciones de un lenguaje de
programación pueden conducir a un código fuente
confuso que resulte difícil de probar y mantener.
¿Como probar el código?
• Para la construcción (codificación) aplican algunas
técnicas que se utilizan en las revisiones de diseño y
requerimientos.
• Por ejemplo: revisiones entre colegas e inspecciones.
¿Qué son las pruebas unitarias?
• Prueba una unidad del código (objetos y clases).
• Realizadas generalmente por el desarrollador de la
unidad en un laboratorio.
• Valida que la unidad funcione según el diseño.
• Se aplican técnicas de caja blanca.
Tipos de Pruebas
Pruebas de Integración
¿Qué son?
• Prueba de módulos o unidades de código
relacionadas.
• Realizada generalmente por testers.
• Valida que las diferentes partes del sistema se
comuniquen según el diseño del sistema.
• Se aplican técnicas de caja blanca y negra.
Tipos de Pruebas
Pruebas de Sistema
¿Qué son?
• Se buscan diferencias entre la especificación
funcional del sistema y su comportamiento real.
• Debe verificarse la operación del software como un
todo.
• Realizada generalmente por testers.
• Se aplican técnicas de caja negra como pruebas de:
– Interfaz gráfica.
– Validación.
– Funcionamiento.
– Base de datos.
– Performance:
Carga: usuarios.
Volumen: datos.
Stress:concurrencia (usuarios haciendo lo mismo al
mismo tiempo), desempeño (funcione con tiempos
de respuesta adecuados al sistema.
– Seguridad: red, vulnerabilidad interior y exterior,
corromper contraseñas.
– Usabilidad.
– Recuperación.
– Instalación.
Base de datos
• Es un conjunto de datos relacionados entre sí.
• Por datos entendemos hechos conocidos que pueden
registrarse y que tienen un significado implícito.
• Una base de datos tiene las siguientes propiedades
implícitas:
– Representa algún aspecto del mundo real, en
ocasiones llamado minimundo.
– Es un conjunto de datos lógicamente coherente,
con cierto significado inherente.
– Se diseña, construye y prueba con datos para un
propósito específico.
• Un sistema de gestión de base de datos (DBMS):
– Conjunto de programas que permite a los usuarios
crear y mantener una base de datos.
– Software de propósito general que facilita el
proceso de definir, construir y manipular bases de
datos para diversas aplicaciones.
• Definir una base de datos implica especificar los tipos
de datos, las estructuras y las restricciones de los
datos mismos.
• Construir una base de datos es el proceso de guardar
los datos en algún medio de almacenamiento.
• Manipular una base de datos es realizar diversas
funciones tales como consultar los datos,
actualizarlos y generar informes.
¿Qué se debe probar de una BD?
• Validar Estructura: en general, se verifica si esa
base de datos no imposibilita llegar a satisfacer los
requerimientos, y si no hay inconsistencias entre los
requerimientos, el diseño lógico y el diseño físico.
– Arquitectura:
Si la estructura arquitectónica es apropiada; en
particular, si la elección de la plataforma tecnológica
(SO, DBMS, lenguaje de programación) no fuera
inapropiada desde el punto de vista de los
requerimientos.
– Rendimiento y normalización:
Si se está cargando, innecesariamente la capa de la
aplicación con validaciones que podrían o deberían
hacerse en la capa de base de datos (triggers,
stored procedures, etc).
Si existe redundancia en las tablas.
Si no existen las llaves apropiadas.
Si ocurre que las llaves generan ineficiencias.
Si los índices generados son adecuados.
– Seguridad:
Si hay problemas de integridad referencial (datos).
Si hay huecos en el acceso a la información
(usuarios).
Si el sistema para replicar y recuperar la
información es apropiado.
• Validar la documentación: en general, se verifica si
se siguieron estándares de diseño de base de datos,
y si se cuenta al menos con el mínimo de
documentación (al menos el diccionario de datos, la
estructura lógica de la base de datos y su
implementación:
– Si se siguieron los estándares de nomenclatura.
– Si hay inconsistencias o falta de actualización en
la documentación de la base de datos.
– Si los documentos están actualizados y completos,
si son consistentes, legibles y fácil de ser
mantenidos.
– Si existe y está actualizado el diccionario de datos.
Tipos de Pruebas
Pruebas de Aceptación
¿Qué son?
• Se buscan diferencias entre el sistema y la necesidad
del usuario.
• Realizada generalmente por usuarios con apoyo de
los testers.
• Se aplican técnicas de caja negra.
REFERENCIAS
• Kit, E. (1995), Software Testing in the real World:
Improving The Process. ACM Press. New York, NY,
USA.
• Myers, G. (2004), The Art of Software Testing.
(Second Edition). John Wiley & Sons, Inc. Hoboken,
New Jersey, USA.
• Gao, J. (2003), Testing and Quality Assurance for
Computer-Based Software. Artech House Pub., New
York, USA
