Your SlideShare is downloading. ×

Fase De Pruebas Angel Chucho

10,707

Published on

Published in: Automotive
1 Comment
0 Likes
Statistics
Notes
  • Be the first to like this

No Downloads
Views
Total Views
10,707
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
359
Comments
1
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Ángel Antonio Carvajal C. Jesús Antonio Hoyos Perdomo FASE DE PRUEBAS DEL SOFTWARE
  • 2. PRUEBAS DE MODULO Y PRUEBAS DE INTEGRACION
  • 3. FASES DE PRUEBAS FASES DE PRUEBAS PRUEBAS DE MODULO (Sueltos Sistemáticas) PRUEBAS DE INTEGRACION (Varios Módulos) PRUEBAS DE ACEPTACION (Clientes) Caja Blanca (Código escrito) Caja Negra (Funcionalidad) 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 Opaca Pruebas funcionales (código) Prueba de E/S Prueba incluida por los datos Involucran Módulos. Estructurales(Personaliza llamada de Módulos) Funcionales (Como la caja negra, funcionabilidades conjuntas Pruebas 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
  • 4. FASE DE PRUEBAS Una vez que el programa está introducido en la memoria del ordenador, es necesario depurar posibles errores. La experiencia demuestra que hasta el programa más sencillo contiene errores y, por lo tanto, este es un paso de vital 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.
  • 5.  
  • 6.
    • 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.
  • 7.
    • 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.
  • 8.
    • 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.
  • 9. 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.
  • 10.
    • 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.
  • 11.
    • 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.
  • 12. TIPOS DE PRUEBAS
    • Pruebas unitarias
    • Pruebas funcionales
    • Pruebas de Integración
    • Pruebas de validación
    • Pruebas de sistema
    • Caja blanca (sistemas)
    • Caja negra (sistemas)
  • 13. CONTINUACION
    • Pruebas de aceptación
    • Pruebas de regresión
    • Pruebas de carga
    • Pruebas de prestaciones
    • Pruebas de recorrido
    • Pruebas de mutación
  • 14. 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.
  • 15. 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 prueba Casos de prueba Entorno para la prueba de unidad
  • 16. Características
    • Para que una prueba unitaria o de modulo sea buena 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.
  • 17. PRUEBAS 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.
  • 18. Continuació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.
  • 19.
    • 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.
  • 20.
    • 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:
  • 21.
    • 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.
  • 22.
    • 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.
  • 23.
    • 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.
  • 24. Integració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.
  • 25. INTEGRACION DESCENDENTE M 1 M 3 M 2 M 6 M 5 M 7 M 8 M 4
  • 26.
    • 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 M 1 , M 2 y M 5.
    • A continuación se integrara M 8 , o M 6, para un funcionamiento adecuado de M 2
  • 27.
    • 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 M 2 , M 3 y M 4.
    • Luego el siguiente nivel de control M 5 , M 6 y M 7.
  • 28. 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
  • 29.
    • Se puede implementar una estrategia de integración ascendente mediante los siguiente pasos:
    • Se combinan los módulos de bajo nivel en grupos ( a veces llamados construcciones) que realicen una subfuncion especifica del software.
    • Se escribe un controlador para coordinar la entrada y salida de los casos de prueba.
    • Se prueba el grupo.
    • Se eliminan los controladores y se combinan los grupos moviéndose hacia arriba por la estructura del programa.
  • 30. M c M b Ma D 3 D1 D2 GRUPO 1 GRUPO 2 GRUPO 3
  • 31.
    • 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 M a.
    • Los controladores D 1 y D 2 se eliminan y los grupos interaccionan directamente con M a.
    • De forma similar, se elimina el controlador D 3 del grupo 3 antes de la integración con el modulo M b.
  • 32.
    • Tanto M a como M b se integraran finalmente con el modulo M c y así sucesivamente.
    • A medida que la integración progresa hacia arriba, disminuye la necesidad de controladores de prueba diferentes
  • 33.  

×