Date post: | 25-Jun-2015 |
Category: |
Automotive |
Upload: | angelcarvajal |
View: | 10,785 times |
Download: | 1 times |
Ángel Antonio Carvajal C.Jesús Antonio Hoyos Perdomo
FASE DE PRUEBAS DEL SOFTWARE
PRUEBAS DE MODULOPRUEBAS DE MODULOY Y
PRUEBAS DE PRUEBAS DE INTEGRACIONINTEGRACION
FASES DE PRUEBASF
AS
ES
DE
PR
UE
BA
S
PRUEBAS DE MODULO (Sueltos
Sistemáticas)
PRUEBAS DE INTEGRACION
(Varios Módulos)
PRUEBAS DE ACEPTACION
(Clientes)
Caja Blanca (Código escrito)
Caja Negra (Funcionali
dad)
Cobertura de Segmento (Secuencia de sentencias sin punto de decisión)Cobertura de Ramas (Recorre toda las posibles salidas.Cobertura de Condición/Decisión (Expresión Booleana correcta)Cobertura de Bucles (While, DoWhile, For “ciclos”).
Cobertura de Requisitos:Prueba de caja OpacaPruebas funcionales (código)Prueba de E/SPrueba incluida por los datos
Involucran Módulos.Estructurales(Personaliza llamada de Módulos)Funcionales (Como la caja negra, funcionabilidades conjuntasPruebas Finales (Consideran todo el Sistema)Técnicas de Diseño: - Diseño Descendente (Módulos Generales) - Diseño Ascendente (Módulos Base). - Codificación Incremental (se codifica solo parte de cada modulo y se van añadiendo funcionalidades.
- Las realiza el cliente antes de pasar en producción- Errores que solo el cliente Detecta.- Técnicas: - Entorno Controlado (Alfa) - Entorno sin controles se queda en el producto (Beta)
DISEÑO:ANGEL
FASE DE PRUEBASFASE DE PRUEBAS
Una vez que el programa está Una vez que el programa está introducido en la memoria del introducido en la memoria del ordenador, es necesario depurar ordenador, es necesario depurar posibles errores. La experiencia posibles errores. La experiencia demuestra que hasta el programa demuestra que hasta el programa más sencillo contiene errores y, por lo más sencillo contiene errores y, por lo tanto, este es un paso de vital tanto, este es un paso de vital importancia.importancia.
Los errores más frecuentes son los sintácticos o de escritura, por habernos equivocado durante la codificación. Para corregirlos, basta con localizar el error (que generalmente nos marcará el propio ordenador) y subsanarlo.
Más peliagudos son los errores de análisis o diseño. Un error en fases tan tempranas dará lugar a un programa que, aunque corre en la máquina, no hace lo que se esperaba de él y, por lo tanto, no funciona.
Estos errores obligan a revisar el análisis y el diseño y, en consecuencia, a rehacer todo el trabajo de especificación, codificación y pruebas. La mejor forma de evitarlos es realizar un análisis y un diseño concienzudos antes de lanzarnos a teclear código como un loco.
Existen varias técnicas, relacionadas con los controles de calidad, para generar software libre de errores y diseñar baterías de prueba que revisen los programas hasta el límite de lo posible, pero que quede claro: ningún programa complejo está libre de errores al 100% por más esfuerzos que se hayan invertido en ello.
La importancia de la detección oportuna
En la cadena de valor del desarrollo de un software específico, el proceso de prueba es clave a la hora de detectar errores o fallas. Conceptos como estabilidad, escalabilidad, eficiencia y seguridad se relacionan a la calidad de un producto bien desarrollado.
Las aplicaciones de software han crecido en complejidad y tamaño, y por consiguiente también en costos. Hoy en día es crucial verificar y evaluar la calidad de lo construido de modo de minimizar el costo de su reparación. Mientras antes se detecte una falla, más barato es su corrección.
El proceso de prueba es un proceso técnico especializado de investigación que requiere de profesionales altamente capacitados en lenguajes de desarrollo, métodos y técnicas de testeo y herramientas especializadas. El conocimiento que debe manejar un ingeniero de prueba es muchas veces superior al del desarrollador de software.
TIPOS DE PRUEBAS
Pruebas unitarias Pruebas funcionales Pruebas de Integración Pruebas de validación Pruebas de sistema Caja blanca (sistemas) Caja negra (sistemas)
CONTINUACION
Pruebas de aceptación Pruebas de regresión Pruebas de carga Pruebas de prestaciones Pruebas de recorrido Pruebas de mutación
PRUEBAS DE MODULO
En programación, una prueba unitaria es una forma de probar el correcto funcionamiento de un módulo de código. Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado. Luego, con las Pruebas de Integración, se podrá asegurar el correcto funcionamiento del sistema o subsistema en cuestión.
RESULTADOS
Conductor
Modulo que se va a probar
Resguardo Resguardo
Interfaz
Estructuras de datos locales
Condiciones límite
Caminos Independientes
Caminos de manejo de errores
Casos de prueba
Casos de prueba
Casos de prueba
Casos de pruebaCasos de prueba
Entorno para la prueba de unidad
Características
Para que una prueba unitaria o de modulo sea Para que una prueba unitaria o de modulo sea buenabuena se deben cumplir los siguientes requisitos: se deben cumplir los siguientes requisitos:
Automatizable: No debería requerirse una intervención manual. Esto es especialmente útil para integración continúa. Completas: Deben cubrir la mayor cantidad de código. Repetibles o Reutilizables: No se deben crear pruebas que sólo puedan ser ejecutadas una sola vez. También es útil para integración continua. Independientes: La ejecución de una prueba no debe afectar a la ejecución de otra. Profesionales: Las pruebas deben ser consideradas igual que el código, con la misma profesionalidad, documentación, etc.
PRUEBAS DE INTEGRACIONPRUEBAS DE INTEGRACION
Las pruebas de integración son aquellas que se realizan en el ámbito del desarrollo de software una vez que se han aprobado las pruebas unitarias.
Únicamente se refieren a la prueba o pruebas de todos los elementos unitarios que componen un proceso, hecho en conjunto, de una sola vez.
ContinuaciónContinuación
Consiste en realizar pruebas para verificar que un gran conjunto de partes de software funcionan juntos.
Las pruebas de integración (algunas veces llamadas Integración y Testeo (&t) es la fase del testeo de software en la cual módulos individuales de software son combinados y testeados como un grupo. Son las pruebas posteriores a las pruebas unitarias y preceden el testeo de sistema.
El objetivo es coger los módulos probados individualmente y construir una estructura de programa que este de acuerdo con lo que dicta el diseño.
Un novato del mundo del software podría, una vez que ha hecho la prueba individual a cada modulo, cuestionar de forma aparentemente legitima lo siguiente: si todos los módulos funcionan bien por separado, ¿Por qué dudar de que funcionen bien todos juntos?Por supuesto, el problema es ponerlos todos juntos (interacción).Puede suceder lo siguiente:
Los datos se pueden perder en una interfaz.
Un modulo puede tener un efecto adverso e inadvertido sobre otro.
Las subfunciones, cuando se combinan, pueden no producir la función principal deseada.
La imprecisión aceptada individualmente puede crecer hasta niveles inaceptables
Las estructuras de datos globales pueden presentar problemas, etc.
A menudo hay una tendencia a intentar una integración no incremental; es decir, a construir el programa mediante un enfoque de <big bang>. Se combinan todos lo módulos por anticipado. Se prueba todo el programa en conjunto. !Normalmente se llega al caos!. Se encuentra un gran conjunto de errores. La corrección se hace difícil, puesto que es complicado aislar las causas al tener delante el programa entero en toda su extensión.Una vez que se corrigen esos errores aparecen otros y el proceso continua en lo que parece un ciclo sin fin.
La integración incremental es la antítesis del enfoque del <big bang>. El programa se construye y se prueba en pequeños segmentos en los que los errores son mas fáciles de aislar y de corregir, es mas probable que se puedan probar completamente las interfaces y se puede aplicar un enfoque de prueba sistemática.
Las pruebas de integración pueden ser: Prueba de integración descendente. Pruebas de integración ascendente.
Integración DescendenteIntegración Descendente
La integración descendente es un planteamiento incremental a la construcción de la estructura de programas. Se integran los módulos moviéndose hacia abajo por la jerarquía de control, comenzando por el modulo de c0ntrol principal (programa principal). Los módulos subordinados al modulo de control principal se van incorporando a la estructura, bien de forma primero-en-profundidad, o bien de forma primero-en-anchura.
M1
M3M2
M6M5 M7
M8
M4
INTEGRACION DESCENDENTEINTEGRACION DESCENDENTE
La integración primero-en-profundidad integra todos los módulos de un camino de control principal de la estructura.
La selección del camino principal es arbitraria y depende de las características especificas de la aplicación. Por ejemplo, si se elige el camino del lado izquierdo, se integraran primero los módulos M1, M2 y M5.
A continuación se integrara M8, o M6, para un funcionamiento adecuado de M2
Después se construyen los caminos de control central y derecho. La integración primero-en-anchura incorpora todos los módulos directamente subordinados a cada nivel, moviéndose por la estructura de forma horizontal. Según la figura anterior los primeros módulos que se integran son M2, M3 y M4.
Luego el siguiente nivel de control M5, M6 y M7.
PRUEBAS DE INTEGRACION ASCENDENTE
Empieza la construcción y la prueba con los módulos atómicos (es decir, módulos de los niveles mas 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
Se puede implementar una estrategia de integración ascendente mediante los siguiente pasos:1.Se combinan los módulos de bajo nivel en grupos ( a veces llamados construcciones) que realicen una subfuncion especifica del software.2.Se escribe un controlador para coordinar la entrada y salida de los casos de prueba.3.Se prueba el grupo.4.Se eliminan los controladores y se combinan los grupos moviéndose hacia arriba por la estructura del programa.
Mc
MbMa
D3D1 D2
GRUPO 1
GRUPO 2
GRUPO 3
En la integración, según el esquema anterior, se combinan los módulos para formar los grupos 1, 2 y 3.
Cada uno de los grupos se somete a prueba mediante un controlador (mostrado como un bloque punteado). Los módulos de los grupos 1 y 2 son subordinados de Ma.
Los controladores D1 y D2 se eliminan y los grupos interaccionan directamente con Ma.
De forma similar, se elimina el controlador D3 del grupo 3 antes de la integración con el modulo Mb.
Tanto Ma como Mb se integraran finalmente con el modulo Mc y así sucesivamente.
A medida que la integración progresa hacia arriba, disminuye la necesidad de controladores de prueba diferentes