1. Técnicas de Pruebas
1.1. Proporcionan distintos criterios para generar casos de prueba que detecten fallos en el programa
2. Se divide en
3. Técnicas estáticas
3.1. Detentan las causas de los defectos
3.2. No ejecutan la aplicación
3.3. Se llevan a cabo a nivel de especificaciones
3.4. No ejecutan código
3.5. Realizan análisis estático del código
3.6. Revisiones de todos los documentos del proyecto
4. Análisis Estático
4.1. Su objetivo es detectar defectos del código fuente y en los modelos del software, sin realizar ejecución del mismo.
4.2. Estas pruebas ayudan a la detección temprana de defectos que no se encuentran fácilmente tanto del código y diseño.
5. Según ISTQB Defectos Típicos
5.1. •Referencias a una variable con una valor definido
5.2. •Interfaces inconsistentes entre módulos
5.3. •Variables que no se utilizan o que se declaran de forma incorrecta.
5.4. •Código inaccesible y ausencia de lógica.
5.5. •Infracciones de los estándares así como de la sintaxis de código y modelos de software
6. Revisiones
6.1. Permiten la detección y corrección temprana de posibles defectos, reducción de tiempo y dinero invertido en el desarrollo y pruebas de software
7. Según ISTQB Defectos Típicos
7.1. •Defectos de requisitos
7.2. •Desviaciones de los estándares
7.3. •Defectos de diseño
7.4. •Especificaciones de interfaz incorrecta
8. Tipos de Revisiones
8.1. Revisión Informal
8.1.1. •Los revisores carecen de instrucciones técnicas
8.1.2. •Los resultados no tienes que estar documentados
8.1.3. •El objetivo es obtener defectos de forma barata
8.1.4. •Se lleva a cabo por parte del líder técnico
8.2. Revisión Guiada
8.2.1. •Varia de formarles a informales
8.2.2. •Se lleva a cabo por parte del autor de un documento del proyecto
8.2.3. •El objetivo es encontrar defectos e implantar un entendimiento en común
8.3. Revisión Técnica
8.3.1. •Varia de formarles a informales
8.3.2. •El objetivo es debatir, tomar decisiones, etc, para alcanzar un consenso.
8.3.3. •Se documenta el proceso
8.3.4. •Se realiza un informe de revisión
8.4. Inspección
8.4.1. Examen visual de documentos para detectar defectos o no cumplimientos:
8.4.1.1. No cumplimiento de estándares de desarrollo
8.4.1.2. Recopilación de métricas e informe con conclusiones
8.4.2. Personas involucradas
8.4.2.1. Revisor
8.4.2.1.1. Persona involucrada en la revisión, identifica las anomalías, defectos del producto
8.4.2.2. Escriba
8.4.2.2.1. Persona que registrará en un acta cada defecto y sugerencia para la mejora durante la revisión
8.4.2.3. Moderador
8.4.2.3.1. Principal responsable de una inspección, quien mediará entre los distintos puntos de vista
8.5. Walkhought
8.5.1. Técnica de revisión por personas con el mismo nivel de conocimiento
8.5.2. Permite la creación de software fácil de leer y mantener
9. Asegurar Calidad de un producto de software
9.1. Evaluación de Entrada
9.2. Gestión de la preparación
9.3. Planeación de la revisión
9.4. Descripción de los procedimientos
9.5. Preparación de la revisión
9.6. Inspección Grupal
9.7. Seguimiento
9.8. Final de la inspección
10. Clasificación de Pruebas en el proceso de pruebas
10.1. Pruebas Unitarias
10.1.1. Comprobar el correcto funcionamiento de una unidad de código
10.1.1.1. Caja Blanca
10.1.1.1.1. Ejecución lógica y de código
10.1.1.2. Pruebas de Flujo de control
10.1.1.2.1. Encuentra errores en la parte lógica del programa
10.1.1.3. Pruebas de flujo de datos
10.1.1.3.1. Prueba las variables y definiciones en el programa
10.1.1.4. Pruebas de bifurcación
10.1.1.4.1. Define si algún bucle esta correctamente implementado
10.1.1.5. Pruebas de caminos básicos
10.1.1.5.1. lograr que cada sentencia de código se ejecute mínimo una vez
10.2. Pruebas de Integración
10.2.1. Prueba que todos los elementos unitarios que componen el software funcionen juntos correctamente
10.2.1.1. Técnica Bing Bang
10.2.1.1.1. Se integran todos los componentes del software, se prueba el sistema como un todo
10.2.1.2. Técnica Top Dowm
10.2.1.2.1. Valida desde la parte general a la especifica
10.2.1.3. Técnica Bottom up
10.2.1.3.1. Valida desde la parte especifica a general
10.2.1.4. Técnica Middle-out
10.2.1.4.1. Valida el eje central del software
10.2.1.5. Estrategias combinadas
10.2.1.5.1. Definir la estrategia inicial propuesta con más estrategias sin afectar el objetivo
10.3. Pruebas Funcionales
10.3.1. No ejecución del programa
10.3.2. Técnicas de caja negra
10.3.3. Variables de entrada y salida
10.4. Pruebas No Funcionales
10.4.1. Técnicas de caja blanca
10.4.2. Usabilidad
10.4.3. Disponibilidad
10.4.4. Compatibilidad
10.5. Pruebas de Aceptación
10.5.1. Determina si cumplen con las necesidades y/o requerimientos de las empresas y sus usuarios
10.5.1.1. Alfa
10.5.1.1.1. Validación durante el desarrollo
10.5.1.1.2. Asegurar el cumplimiento de los requisitos
10.5.1.2. Beta
10.5.1.2.1. Realización de validación del sistema por parte del usuario
10.5.1.2.2. Uso del software en ambiente real
10.5.1.3. Pruebas de regresión
10.5.1.3.1. Pruebas al programa que ha tenido modificaciones
10.5.1.3.2. Intenta descubrir errores
10.5.1.3.3. Carencias de funcionalidad
11. Técnica de caja negra
11.1. Pruebas de comportamiento
11.2. Se encuentran funciones incorrectas o faltantes
11.3. Variables de entrada y salida
12. Análisis de valor al limite
12.1. Mayor número de errores encontrados
12.2. valor limite
12.3. valor por debajo y encima del limite
12.4. casos de prueba en los extremos
13. Clases de valores límite
13.1. Rango de Valores
13.2. Número de Valores
13.3. Conjunto de valores
13.4. Debe ser
14. Pruebas de tabla de decisión
14.1. Reflejar los requisitos del sistema
14.2. Documentar el diseño del sistema interno
14.3. Condiciones de activación
14.4. Combinaciones de verdadero y falso
15. Técnicas dinámicas
15.1. •Detentan los fallos
15.2. •Se ejecuta la aplicación
15.3. •Utilizadas para el diseño de casos de prueba
15.4. •Pruebas de caja negra y blanca
15.5. •Búsqueda de errores en funciones
15.6. •Demostrar que las funciones son operativas
16. Técnicas de Caja Blanca
16.1. Lógica Interna
16.2. Garantizar todos los caminos
16.3. Verificación interna y procedimiental
17. Pruebas de ruta básica
17.1. Método de prueba de caja blanca
17.2. Diseñar un caso de prueba por cada camino independiente del programa
17.3. Garantiza que se prueben los caminos al menos una vez
18. Representación
19. Grafo de Flujo
19.1. Representación de los caminos que puede tomar un programa durante su ejecución.
19.2. Notación: (Secuencia, if, while, until, case)
19.3. Cada estructura de control tiene su símbolo en la notación
19.4. Tienen un punto de entrada y un punto de salida
19.5. Condiciones compuestas: AND, OR NAND, NOR
19.6. Un nodo creado se llama nodo predicado
20. Se divide en 3 partes
20.1. Nodo
20.1.1. Cualquier punto terminal de un segmento
20.2. Aristas
20.2.1. Flechas en el grafo
20.3. Regiones
20.3.1. Áreas acotadas por los nodos y aristas
21. Modelo estructural
21.1. Existe un solo nodo inicial
21.2. Existe un solo nodo final
21.3. Cada nodo representa una secuencia de instrucciones, que puede ser vacía.
21.4. La relación entre los nodos es una relación de “el control pasa a”.
21.5. Un nodo puede tener uno o dos sucesores,
21.6. Un nodo puede tener uno o muchos antecesores
21.7. Un nodo tendrá dos sucesores si existen dos caminos posibles, dependiendo de una condición
21.8. Los casos de for, while, until y case se pueden reducir a grupos de nodos con dos sucesores
22. Rutas de programa independientes
22.1. Introduce una nueva condición o lineas de instrucciones en el programa
22.2. Linea independiente que recorre una arista donde no se ha pasado
23. Complejidad ciclomática
23.1. Permite definir el número de caminos independientes del conjunto básico de un programa
23.2. Permite saber el número de pruebas a realizar , asegurando que se ejecute al menos una vez todas las líneas del programa
23.3. Se puede hallar con el número de regiones del grafo de flujo
24. Se define
24.1. V(G) = E – N + 2
24.1.1. E: número de aristas del grafo de flujo
24.1.2. N: número de nodos del grafo de flujo