Fase De Pruebas Angel Chucho
-
Upload
angelcarvajal -
Category
Automotive
-
view
10.791 -
download
1
Transcript of Fase De Pruebas Angel Chucho
![Page 1: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/1.jpg)
Ángel Antonio Carvajal C.Jesús Antonio Hoyos Perdomo
FASE DE PRUEBAS DEL SOFTWARE
![Page 2: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/2.jpg)
PRUEBAS DE MODULOPRUEBAS DE MODULOY Y
PRUEBAS DE PRUEBAS DE INTEGRACIONINTEGRACION
![Page 3: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/3.jpg)
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
![Page 4: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/4.jpg)
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.
![Page 5: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/5.jpg)
![Page 6: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/6.jpg)
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.
![Page 7: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/7.jpg)
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.
![Page 8: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/8.jpg)
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.
![Page 9: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/9.jpg)
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.
![Page 10: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/10.jpg)
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.
![Page 11: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/11.jpg)
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.
![Page 12: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/12.jpg)
TIPOS DE PRUEBAS
Pruebas unitarias Pruebas funcionales Pruebas de Integración Pruebas de validación Pruebas de sistema Caja blanca (sistemas) Caja negra (sistemas)
![Page 13: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/13.jpg)
CONTINUACION
Pruebas de aceptación Pruebas de regresión Pruebas de carga Pruebas de prestaciones Pruebas de recorrido Pruebas de mutación
![Page 14: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/14.jpg)
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.
![Page 15: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/15.jpg)
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
![Page 16: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/16.jpg)
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.
![Page 17: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/17.jpg)
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.
![Page 18: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/18.jpg)
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.
![Page 19: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/19.jpg)
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.
![Page 20: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/20.jpg)
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:
![Page 21: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/21.jpg)
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.
![Page 22: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/22.jpg)
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.
![Page 23: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/23.jpg)
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.
![Page 24: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/24.jpg)
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.
![Page 25: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/25.jpg)
M1
M3M2
M6M5 M7
M8
M4
INTEGRACION DESCENDENTEINTEGRACION DESCENDENTE
![Page 26: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/26.jpg)
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
![Page 27: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/27.jpg)
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.
![Page 28: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/28.jpg)
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
![Page 29: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/29.jpg)
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.
![Page 30: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/30.jpg)
Mc
MbMa
D3D1 D2
GRUPO 1
GRUPO 2
GRUPO 3
![Page 31: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/31.jpg)
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.
![Page 32: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/32.jpg)
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
![Page 33: Fase De Pruebas Angel Chucho](https://reader033.fdocuments.net/reader033/viewer/2022052218/558b9717d8b42acc378b46d4/html5/thumbnails/33.jpg)