La sección de pruebas de su documentación indica el enfoque que usted ha elegido para verificar y validar su sistema. (En un sistema real, esto podría incluir tanto las pruebas de usuario para determinar la idoneidad del sistema como solución al problema descrito en la sección de requisitos, como la ejecución de suites de prueba para verificar la corrección algorítmica del código). Del mismo modo que no debería comunicar el diseño de su sistema presentando el código o incluso enumerando las clases, no debería únicamente enumerar las pruebas realizadas. En vez de hacer esto, explique cómo se seleccionaron las pruebas, por qué éstas bastaron, por qué un lector debería creer que no se ha omitido ninguna prueba importante y por qué debería creer que el sistema realmente funcionará como se desee cuando se ponga en práctica.
- Estrategia (1 - 2 páginas). Una explicación de la estrategia general de las pruebas:blackbox y/o glassbox, top down (de arriba hacia abajo) y/o bottom up (de abajo hacia arriba), tipos de test beds (bancos de prueba) y manejadores de tests que se han utilizado, fuentes de datos del test, suites de prueba, métrica de cobertura, comprobación en tiempo de compilación frente a sentencias en tiempo de ejecución, razonamientos sobre su código, etc. Es posible que quiera usar técnicas distintas (o combinaciones de técnicas) en las diferentes partes del programa. Justifique sus decisión en cada caso.
Explique qué tipo de errores
espera encontrar (¡y cuáles no!) con su estrategia. Comente qué aspectos del
diseño dificultaron o facilitaron la validación.
- Resultados del test (1/2 - 2 páginas). Resumen de qué pruebas se han realizado y cuáles no, si es que queda alguna: qué módulos se han probado, y si se han probado a fondo. Indique el grado de confianza del código: ¿Qué tipo de defectos se han eliminado? ¿Cuáles son los que podrían quedar?
No hay comentarios:
Publicar un comentario