Please enable JavaScript.
Coggle requires JavaScript to display documents.
pruebas de Software - Coggle Diagram
pruebas de Software
Pruebas de caja blanca
Las pruebas de caja blanca, permiten probar la lógica interna del programa y su estructura, realizando las siguientes acciones:
Comprobación de todas las decisiones lógicas
Comprobación de todos los bucles
Recorrido de todo los caminos independientes de cada componente
Implementación de situaciones extremas o limites
Ejecución de todas las sentencias (al menos una vez)
Pruebas de caja negra
En este tipo de pruebas se considera el software como una caja negra, sin preocuparse por los detalles procedimentales de los programas. De esta manera, los datos de entrada deben generar una salida coherente con las especificaciones; si no es así, es porque se ha encontrado un error el cual debe ser corregido para poder continuar con las pruebas
Las dos técnicas mas comunes son:
partición de equivalencia
Análisis de valores limite
Prueba de camino básico
Esta técnica fue propuesta por Tom McCabe y consiste en definir un conjunto básico de caminos usando la medida de complejidad llamada complejidad ciclomática (VG)
La complejidad ciclomática determina el numero de caminos a probar, mediante la siguiente formula:
V(G) = #Aristas - #Nodos + 2
Los pasos en las pruebas de caminos básicos son:
Determinar la complejidad ciclomática del grafo
Determinar los caminos linealmente independientes
Dibujar grafo de flujo
Diseñas los casos de prueba
Prueba de bucle
Para esta prueba se tiene que representar de forma grafica los bucles que pueden ser simples, anidados, concatenados y no estructurados
Prueba de condición
Esta prueba evalúa las condiciones lógicas contenidas en un modulo del programa, las cuales pueden ser simples o compuestas
Condición simple
Es una variable lógica (true o false),o una expresión relacional de la forma: El operador relacional>E2, donde el E2 son expresiones aritmética, y el operador relaciona es uno de los siguiente: <,>,<=,>=,=,!=
Condición compuesta
Se compone de dos o mas condiciones simples y operadores lógicas de tipo NOT, AND, OR y paréntesis
Prueba de estructura de datos locales
Estas pruebas aseguran la integridad de los datos durante todos los pasos de la ejecución del modulo
Control de errores como overflow, underflow, división por cero, etc.
Comparaciones entre variables del mismo tipo
Declaración correcta de variable
Uso adecuado de los limites en los arreglos
Inicialización de todas las variables utilizadas
Integridad de datos
Partición de equivalencia
En este tipo de prueba, la entrada de un programa se divide en clases de datos de los cuales se pueden derivar casos de prueba, teniendo en cuenta las siguientes reglas:
Si la entrada es un rango o un valor especifico, se define una clase de equivalencia valida y dos invalidas
Si la entrada es un valor lógico, se define una clase de equivalencia valida y otra invalida
Análisis de valores limite
Después de probar todos los casos en la técnica de partición de equivalencia, se prueban los valores fronterizos de cada clase (valores limite)
Estrategia de pruebas
La prueba de software se realiza desde hacia fuera del sistema
Pruebas de validación: se comprueba el cumplimiento de los requisitos
Pruebas del sistema: se prueba el software y otros elementos del sistema como un todo
Pruebas de integración: se centra en el diseño y la construcción de arquitectura del software, analizando el flujo de información entre unidades a través de las interfaces
Pruebas de aceptación: el usuario valida que el producto se ajusta a sus requerimientos
Pruebas unitarias o de unidad: se comprueba la lógica, funcionalidad y especificación de cada unidad (componente, clase u objeto) del sistema de manera aislada con respecto al resto de unidades
Pruebas unitarias
Corresponden a la evaluación de cada uno de los bloques mas pequeños son identificación propia en el sistema, y es realizada por el programador en su entorno de desarrollo
Las pruebas unitarias usan técnicas de caja blanca, para lo cual se crean módulos conductores y módulos resguardo
Un modulo conductor o controlador es un "programa principal" que recibe a través de la interfaz datos de caso de prueba, y los pasa al componente que se desea probar. Los módulos resguardo (en ingles stubs) o "subprogramas tontos", se utilizan para sustituir componentes que son subordinados o llamados desde el componente que se desea probar. finalmente se generan reportes con los resultados obtenidos
Pruebas de integración
No es suficiente con probar el funcionamiento correcto de cada módulo, se requiere además del funcionamiento en conjunto. Por tal razón, se hacen necesarias las pruebas de integración, las cuales generalmente implementan técnicas de caja negra.
Existen dos estrategias básicas para realizar la combinación de módulos en las pruebas de integración: integración ascendente e integración descendente.
Pruebas de integración ascendente
En estas pruebas se implementan las siguientes fases:
Eliminación de conductores y combinación de grupos en movimiento hacia arriba según la estructura del programa
Se realizan pruebas de regresión
Probar el grupo
Construcción de un modulo conductor para coordinar la E y S de los casos de prueba
Combinación de los componentes de nivel mas bajo en grupos
Pruebas de integración descendente
cada vez que se integra un modulo nuevo, se realiza una prueba
Los resguardos se sustituyen por los módulos reales
Se realizan pruebas de regresión
El modulo de control principal de control principal se usa como conductor de pruebas, y los módulos inmediatamente subordinas son reemplazados por resguardos
Pruebas de integración sándwich
En este tipo de pruebas se aplica la integración ascendente en los módulos inferiores, y de manera paralela se realiza integración descendente en los componentes superiores. La integración termina cuando ambas técnicas se encuentran en un punto intermedio de la estructura de componentes.
pruebas de regresión
Cada vez que se agrega un nuevo componente o módulo en las pruebas de integración, el software cambia y se generan nuevas rutas en el flujo de datos. De esta manera, se requieren prueba de regresión en las cuales se ejecute algún tipo de pruebas ya realizadas, sean de ascendentes, descendentes o sándwich.
Pruebas de validación
En la pruebas de validación se verifica el cumplimiento de los requisitos de usuario, con participación del desarrollador y el usuario. Se utiliza la técnica de caja negra, dividida en dos partes:
En las pruebas de validación se encuentran las pruebas alfa y las pruebas beta.
Pruebas alfa: son realizadas por el cliente en el lugar de desarrollo, y se prueba el sistema aunque no estén terminadas todas las funcionalidades.
Pruebas beta: Son realizadas por los potenciales consumidores en su entorno, sin presencia del desarrollador.
Validación de utilidad, facilidad de uso y ergonomía de la interfaz de usuario.
Validación por parte del usuario de los resultados
Pruebas del sistema
En este tipo de pruebas se verifica el cumplimiento de los requisitos especificados, probando el sistema integrado en su entorno de hardware y software.
Pruebas de aceptación
Estas pruebas son realizadas en e! entorno del usuario, para validar la aceptación por parte del cliente, comprobando que el sistema está listo para ser implantado. El usuario puede definir los casos de prueba.