1. Criterios para completar las pruebas
1.1. Cada vez que el usuario ejecuta un programa de cómputo, el programa se pone a prueba.
2. ASPECTOS ESTRATÉGICOS
2.1. Especifican los requerimientos del producto en forma cuantificable mucho antes de comenzar con las pruebas.
3. ESTRATEGIAS DE PRUEBA PARA SOFTWARE CONVENCIONAL 2
3.1. Prueba de unidad
3.1.1. La prueba de unidad enfoca los esfuerzos de verificación en la unidad más pequeña del diseño de software
3.2. Pruebas de integración
3.2.1. Un neófito en el mundo del software podrá plantear una pregunta aparentemente legítima una vez que todos los módulos se hayan probado de manera individual
4. ESTRATEGIAS DE PRUEBA PARA SOFTWARE ORIENTADO A OBJETO3
4.1. Prueba de unidad en el contexto OO
4.1.1. Cuando se considera software orientado a objeto, el concepto de unidad cambia. La encapsula- ción determina la definición de clases y objetos.
4.2. ESTRATEGIAS DE PRUEBA PARA WEBAPPS
4.2.1. La estrategia para probar webapps adopta los principios básicos para todas las pruebas de software y aplica una estrategia y tácticas que se usan para sistemas orientados a objetos.
4.3. PRUEBAS DE VALIDACIÓN
4.3.1. Las pruebas de validación comienzan en la culminación de las pruebas de integración, cuando se ejercitaron componentes individuales, el software está completamente ensamblado como un paquete y los errores de interfaz se descubrieron y corrigieron.
4.4. Criterios de pruebas de validación
4.4.1. La validación del software se logra a través de una serie de pruebas que demuestran conformidad con los requerimientos.
4.5. Revisión de la configuración
4.5.1. Un elemento importante del proceso de validación es una revisión de la configuración. La intención de la revisión es garantizar que todos los elementos de la configuración del software se desarrollaron de manera adecuada, y que se cataloga y se tiene el detalle necesario para refor- zar las actividades de apoyo.
4.6. Pruebas alfa y beta
4.6.1. Virtualmente, es imposible que un desarrollador de software prevea cómo usará el cliente realmente un programa.
4.7. PRUEBAS DEL SISTEMA
4.7.1. Pruebas de recuperación
4.7.2. Pruebas de seguridad
4.7.2.1. Cualquier sistema basado en computadora que gestione información sensible o cause acciones que puedan dañar (o beneficiar) de manera inadecuada a individuos es un blanco de penetración inadecuada o ilegal.
4.7.3. Pruebas de esfuerzo
4.7.3.1. Los primeros pasos de la prueba del software dieron como resultado una evaluación extensa de las funciones y el rendimiento normales del programa.
4.7.4. Pruebas de rendimiento
4.7.4.1. Para sistemas en tiempo real y sistemas embebidos , el software que proporcione la función requerida, pero que no se adecue a los requerimientos de rendimiento, es inaceptable.
4.7.5. Pruebas de despliegue
4.7.5.1. En muchos casos, el software debe ejecutarse en varias plataformas y bajo más de un entorno de sistema operativo.