1. Elementos de aseguramiento de la calidad (10)
1.1. Estandares
1.2. Revisiones y auditorias
1.3. Pruebas
1.4. Colección y análisis de los errores
1.5. Educación
1.6. Administración del cambio
1.7. Administración de los proveedores
1.7.1. paquetes contenidos en una caja
1.7.2. shell personalizado
1.7.3. Software Contratado
1.8. Administración de la seguridad
1.9. Seguridad.
1.10. Administración de riesgos
2. Prueba de Aplicaciones Convencionales (Capitulo 18)
2.1. Comprobabilidad
2.1.1. Operatividad.
2.1.2. Observabilidad
2.1.3. Controlabilidad
2.1.4. Descomponibilidad
2.1.5. Simplicidad
2.1.5.1. Simplicidad Funcional
2.1.5.2. Simplicidad estructural
2.1.5.3. Simplicidad de código
2.1.6. Estabilidad
2.1.7. Comprensibilidad
2.2. Carateristicas de las pruebas
2.2.1. Una buena prueba tiene una alta probabilidad de encontrar un error.
2.2.2. Una buena prueba no es redundante
2.2.3. Una buena prueba debe ser “la mejor de la camada”
2.2.4. Una buena prueba no debe ser demasiado simple o demasiado compleja
2.3. La prueba de caja negra / pruebas de comportamiento
2.3.1. tipos de errores a encontrar
2.3.1.1. 1) funciones incorrectas o faltantes
2.3.1.2. 2) errores de interfaz,
2.3.1.3. 3) errores en las estructuras de datos o en el acceso a bases de datos externas,
2.3.1.4. 4) errores de comportamiento o rendimiento
2.3.1.5. 5) errores de inicialización y terminación.
2.3.2. ayuda a responder las siguientes preguntas
2.3.2.1. ¿Cómo se prueba la validez funcional?
2.3.2.2. ¿Cómo se prueban el comportamiento y el rendimiento del sistema?
2.3.2.3. ¿Qué clases de entrada harán buenos casos de prueba?
2.3.2.4. ¿El sistema es particularmente sensible a ciertos valores de entrada?
2.3.2.5. ¿Cómo se aíslan las fronteras de una clase de datos?
2.3.2.6. ¿Qué tasas y volumen de datos puede tolerar el sistema?
2.3.2.7. ¿Qué efecto tendrán sobre la operación del sistema algunas combinaciones específicas de datos?
2.3.3. Metodos de prueba basados en graficos
2.3.3.1. Modelado de flujo de transacción.
2.3.3.2. Modelado de estado finito
2.3.3.3. Modelado de flujo de datos
2.3.3.4. Modelado de temporización
2.3.4. Partición de equivalencia
2.3.5. Análisis de valor de frontera
2.3.6. Prueba de arreglo ortogonal
2.3.7. PRUEBA BASADA EN MODELO
2.3.8. PRUEBA PARA ENTORNOS, ARQUITECTURAS Y APLICACIONES ESPECIALIZADOS
2.3.8.1. Pruebas de interfaces gráficas de usuario
2.3.8.2. Prueba de arquitecturas cliente-servidor
2.3.8.2.1. Pruebas de función de aplicación
2.3.8.2.2. Pruebas de servidor
2.3.8.2.3. Pruebas de base de datos
2.3.8.3. Pruebas de documentación
2.3.8.4. Prueba para sistemas de tiempo real
2.3.9. patrones para pruebas
2.3.9.1. 1. Proporcionan un vocabulario para quienes solucionan problemas. “Oiga, usted sabe, debemos usar un objeto nulo
2.3.9.2. 2. Enfocan la atención en las fuerzas que hay detrás de un problema. Esto permite que los diseñadores [de caso de prueba] entiendan mejor cuándo y por qué se aplica una solución.
2.3.9.3. 3. Alientan el pensamiento iterativo. Cada solución crea un nuevo contexto en el que pueden resolverse nuevos problemas.
2.3.9.4. Ejemplos
2.3.9.4.1. PairTesting
2.3.9.4.2. SeparateTestInterface
2.3.9.4.3. ScenarioTesting
2.4. La prueba de caja blanca del software / prueba de caja de vidrio
2.4.1. prueba de ruta o trayectoria básica
2.4.2. rutas de programa independiente
2.4.2.1. pruebas ciclomaticas v(G)
2.4.2.1.1. regiones
2.4.2.1.2. nodos predicados + 1
2.4.2.1.3. aristas - nodos + 2
2.4.2.2. rutas linealmente independientes
2.4.2.3. Matrices de grafo
2.4.2.3.1. El enlace ponderado proporciona información adicional acerca del flujo de control.
2.4.3. Prueba la estructura de control
2.4.3.1. La prueba de condición
2.4.3.2. Prueba de bucle
2.4.3.2.1. Bucles simples.
2.4.3.3. Prueba de flujo de datos
2.4.3.4. Bucles no estructurados