Pruebas, validación y verificación de Software

Comienza Ya. Es Gratis
ó regístrate con tu dirección de correo electrónico
Rocket clouds
Pruebas, validación y verificación de Software por Mind Map: Pruebas, validación y verificación de Software

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. Técnicas dinámicas

10.1. •Detentan los fallos

10.2. •Se ejecuta la aplicación

10.3. •Utilizadas para el diseño de casos de prueba

10.4. •Pruebas de caja negra y blanca

10.5. •Búsqueda de errores en funciones

10.6. •Demostrar que las funciones son operativas

11. Técnicas de Caja Blanca

11.1. Lógica Interna

11.2. Garantizar todos los caminos

11.3. Verificación interna y procedimiental

12. Pruebas de ruta básica

12.1. Método de prueba de caja blanca

12.2. Diseñar un caso de prueba por cada camino independiente del programa

12.3. Garantiza que se prueben los caminos al menos una vez

13. Representación

14. Grafo de Flujo

14.1. Representación de los caminos que puede tomar un programa durante su ejecución.

14.2. Notación: (Secuencia, if, while, until, case)

14.3. Cada estructura de control tiene su símbolo en la notación

14.4. Tienen un punto de entrada y un punto de salida

14.5. Condiciones compuestas: AND, OR NAND, NOR

14.6. Un nodo creado se llama nodo predicado

15. Se divide en 3 partes

15.1. Nodo

15.1.1. Cualquier punto terminal de un segmento

15.2. Aristas

15.2.1. Flechas en el grafo

15.3. Regiones

15.3.1. Áreas acotadas por los nodos y aristas

16. Modelo estructural

16.1. Existe un solo nodo inicial

16.2. Existe un solo nodo final

16.3. Cada nodo representa una secuencia de instrucciones, que puede ser vacía.

16.4. La relación entre los nodos es una relación de “el control pasa a”.

16.5. Un nodo puede tener uno o dos sucesores,

16.6. Un nodo puede tener uno o muchos antecesores

16.7. Un nodo tendrá dos sucesores si existen dos caminos posibles, dependiendo de una condición

16.8. Los casos de for, while, until y case se pueden reducir a grupos de nodos con dos sucesores

17. Rutas de programa independientes

17.1. Introduce una nueva condición o lineas de instrucciones en el programa

17.2. Linea independiente que recorre una arista donde no se ha pasado

18. Complejidad ciclomática

18.1. Permite definir el número de caminos independientes del conjunto básico de un programa

18.2. Permite saber el número de pruebas a realizar , asegurando que se ejecute al menos una vez todas las líneas del programa

18.3. Se puede hallar con el número de regiones del grafo de flujo

19. Se define

19.1. V(G) = E – N + 2

19.1.1. E: número de aristas del grafo de flujo

19.1.2. N: número de nodos del grafo de flujo

20. Cobertura de Sentencias

20.1. Se trata de ejecutar con los casos de prueba cada sentencia e instrucción al menos una vez

21. Cobertura de Decisiones / Condiciones

21.1. Se escribe los casos suficientes para que cada condición tenga al menos una resultado verdadero y otro falso.

22. Criterio de condición múltiple

22.1. Decisiónes multicondicional y unicondicional, se combinan para que se cumpla el criterio de condición múltiple

23. Cobertura de Decisiones / Condiciones

23.1. Se escribe los casos suficientes donde cada condición tenga al menos una resultado verdadero y otro falso

24. Criterio de condición múltiple

24.1. Cada sentencia se ejecuta al menos una vez

24.2. Se ejecuta todas las posibles combinaciones posibles de resultados

25. Clasificación de Pruebas en el proceso de pruebas

25.1. Pruebas Unitarias

25.1.1. Comprobar el correcto funcionamiento de una unidad de código

25.1.1.1. Caja Blanca

25.1.1.1.1. Ejecución lógica y de código

25.1.1.2. Pruebas de Flujo de control

25.1.1.2.1. Encuentra errores en la parte lógica del programa

25.1.1.3. Pruebas de flujo de datos

25.1.1.3.1. Prueba las variables y definiciones en el programa

25.1.1.4. Pruebas de bifurcación

25.1.1.4.1. Define si algún bucle esta correctamente implementado

25.1.1.5. Pruebas de caminos básicos

25.1.1.5.1. lograr que cada sentencia de código se ejecute mínimo una vez

25.2. Pruebas de Integración

25.2.1. Prueba que todos los elementos unitarios que componen el software funcionen juntos correctamente

25.2.1.1. Técnica Bing Bang

25.2.1.1.1. Se integran todos los componentes del software, se prueba el sistema como un todo

25.2.1.2. Técnica Top Dowm

25.2.1.2.1. Valida desde la parte general a la especifica

25.2.1.3. Técnica Bottom up

25.2.1.3.1. Valida desde la parte especifica a general

25.2.1.4. Técnica Middle-out

25.2.1.4.1. Valida el eje central del software

25.2.1.5. Estrategias combinadas

25.2.1.5.1. Definir la estrategia inicial propuesta con más estrategias sin afectar el objetivo

25.3. Pruebas Funcionales

25.3.1. No ejecución del programa

25.3.2. Técnicas de caja negra

25.3.3. Variables de entrada y salida

25.4. Pruebas No Funcionales

25.4.1. Técnicas de caja blanca

25.4.2. Usabilidad

25.4.3. Disponibilidad

25.4.4. Compatibilidad

25.5. Pruebas de Aceptación

25.5.1. Determina si cumplen con las necesidades y/o requerimientos de las empresas y sus usuarios

25.5.1.1. Alfa

25.5.1.1.1. Validación durante el desarrollo

25.5.1.1.2. Asegurar el cumplimiento de los requisitos

25.5.1.2. Beta

25.5.1.2.1. Realización de validación del sistema por parte del usuario

25.5.1.2.2. Uso del software en ambiente real

25.5.1.3. Pruebas de regresión

25.5.1.3.1. Pruebas al programa que ha tenido modificaciones

25.5.1.3.2. Intenta descubrir errores

25.5.1.3.3. Carencias de funcionalidad

26. Técnica de caja negra

26.1. Pruebas de comportamiento

26.2. Se encuentran funciones incorrectas o faltantes

26.3. Variables de entrada y salida

27. Pruebas de Partición de equivalencia

27.1. Divide los valores de entrada y salida

27.2. Se procesan de la misma forma

27.3. Se aplica a datos válidos o no válidos

28. Clases de equivalencia

28.1. Rango de valores

28.2. Número de valores

28.3. Conjunto de valores

28.4. Debe ser

29. Análisis de valor al limite

29.1. Mayor número de errores encontrados

29.2. valor limite

29.3. valor por debajo y encima del limite

29.4. casos de prueba en los extremos

30. Clases de valores límite

30.1. Rango de Valores

30.2. Número de Valores

30.3. Conjunto de valores

30.4. Debe ser

31. Pruebas de tabla de decisión

31.1. Reflejar los requisitos del sistema

31.2. Documentar el diseño del sistema interno

31.3. Condiciones de activación

31.4. Combinaciones de verdadero y falso

32. Pruebas de transición de estado

32.1. Estado inicial

32.2. Recorrer diferentes estados

32.3. Desencadenar cambios de estados

32.4. Precondiciones y poscondiciones

32.5. Las sentencias y condiciones del estado

33. Pruebas de casos de uso

33.1. Todas maneras de utilizar el sistema

33.2. Caminos útiles de utilizar el sistema

33.3. Lo que hará y no hará el sistema

33.4. Descubrir defectos en todos los caminos útiles

33.5. Diseña pruebas de aceptación