Pruebas en el desarrollo de Software

Pruebas en el desarrollo de Software

Get Started. It's Free
or sign up with your email address
Pruebas en el desarrollo de Software by Mind Map: Pruebas en el desarrollo de Software

1. Propósito de la pruebas

1.1. evaluar la calidad

1.2. verificar la corrección del producto

1.3. asegurar la calidad

1.4. competitividad comercial

1.5. reducción de costos y riesgos

1.6. incremento de productividad

2. Planeación de las pruebas

2.1. Alcance de las pruebas

2.1.1. Determina funcionalidades del software que serán probadas durante el proceso de pruebas.

2.2. Tipos de pruebas

2.2.1. En este punto se determina qué tipos de pruebas requiere el producto

2.3. Estrategia de pruebas

2.3.1. Hace énfasis en determinar a través de un análisis de riesgos sobre en que funcionalidades debemos centrar nuestra atención.

2.4. Criterios de salida

2.4.1. Se define de manera formal, bajo qué condiciones se puede considerar que una actividad de pruebas fue finalizada

2.5. Otros...

2.5.1. Tal y como se realiza en cualquier plan de proyecto, se debe incluir una estimación de tiempos, los roles y/o recursos que serán parte del proceso, la preparación del entorno de pruebas, etcétera.

3. Caso de pruebas

3.1. precondiciones

3.2. valores de estrada

3.3. requisitos

3.4. prioridad

3.5. resultados esperados

3.6. identificador único

3.7. postcondiciones

4. Características de un probador

4.1. curioso

4.2. aptitud para la comunicación

4.3. no creer todo lo dicho por los desarrolladores

4.4. atento a los detalles

5. Existen...

5.1. Pruebas modulares

5.1.1. Pruebas que validan la correcta funcionalidad del Módulo o subsistema

5.2. Pruebas de integración

5.2.1. Pruebas que aseguran el correcto funcionamiento del flujo de trabajo

6. Calidad de Sofware

6.1. “La totalidad de la funcionalidad y prestaciones de un producto de software que están relacionadas con su capacidad de satisfacer las necesidades explícitas o implícitas”.

7. TIPOS DE PRUEBAS

7.1. Funcionales

7.1.1. validación requerimientos

7.1.1.1. validar las necesidades del cliente.

7.1.2. Datos entrada y salida

7.1.2.1. Ejecución de las entradas para esperar la salida correcta

7.2. No Funcionales

7.2.1. revisan las características implícitas del sistema

7.2.1.1. carga

7.2.1.1.1. Pruebas a un sistema cubriendo la demanda esperada.

7.2.1.2. rendimiento

7.2.1.2.1. Rapidez con la cual un sistema se ejecuta

7.2.1.3. estrés

7.2.1.3.1. Someter a la aplicación a una carga mucho mayor a la esperada

7.2.1.4. fiabilidad

7.2.1.4.1. en qué sistema operativo operará, cuál será el navegador de preferencia

7.2.1.4.2. El sistema debe ser confiable a los usuarios

7.2.1.5. mantenibilidad

7.2.1.5.1. el código siempre debe estar comentado

7.2.1.6. portabilidad

7.2.1.6.1. en qué sistema operativo operará, cuál será el navegador de preferencia

7.3. Estructurales

7.3.1. Revisión de la estructura del código

7.3.1.1. el código debe ser ejecutado con los casos de prueba diseñados

7.4. Asociadas al cambio

7.4.1. Validar funcionalidad

7.4.1.1. validar que la funcionalidad siga igual después de una modificación al código

7.4.2. Prueba de regresión

7.4.2.1. Repetir una prueba de funcionalidad que ya ha sido verificada

7.4.3. Repetición de pruebas

7.4.3.1. Pruebas tras corrección de errores

8. Ventajas

8.1. Evaluar la calidad

8.2. Verificar la corrección del producto

8.3. Asegurar la calidad

8.4. Ayudar a los administradores

9. Fundamentos de prueba

9.1. Atributos funcionales

9.1.1. Adecuación

9.1.2. Exactitud

9.1.3. Seguridad

9.1.4. Cumplimiento de la función

9.2. atributos no funcionales

9.2.1. Usabilidad

9.2.2. Eficiencia

9.2.3. Mantenimiento

9.2.4. Portabilidad

9.2.5. Fiabilidad

10. Proceso básico de pruebas

10.1. Planeacion

10.2. Análisis y diseño de pruebas

10.3. Ejecución de pruebas

10.4. Evaluación de resultados

10.5. Cierre de pruebas

11. Etapas, técnicas, tipos de pruebas

11.1. Etapas

11.1.1. pruebas modulares

11.1.2. pruebas de integración

11.1.3. pruebas de sistema

11.1.4. pruebas de aceptacion

11.2. Técnicas

11.2.1. funcionales

11.2.2. no funcionales

11.2.3. estructurales

11.2.4. asociadas al cambio

11.3. Tipos

11.3.1. estáticas

11.3.2. dinámicas

12. Tipos de casos

12.1. casos de prueba positivos

12.2. casos de prueba negativos

12.3. happy path

13. ¿Que causa errores?

13.1. plazos de trabajo excesivos

13.2. presiones de tiempo

13.3. distracciones

13.4. mala interpretación de los requerimientos

14. Técnicas de pruebas

14.1. Estáticas

14.1.1. Centran su atención en la estructura lógica del programa no en los resultados

14.1.1.1. Ventajas

14.1.1.1.1. *Costos más bajos

14.1.1.1.2. *Los defectos en la documentación son detectados y corregidos de manera temprana

14.1.1.1.3. *Los documentos de alta calidad mejoran el proceso de desarrollo

14.1.1.2. Desventajas

14.1.1.2.1. Pueden presentarse situaciones de tensión con el autor

14.1.1.2.2. Inversión considerable de tiempo (10% - 15% del presupuesto total)

14.2. Dinamicas

14.2.1. Se ejecutan los programas, se selecciona y ejecuta la prueba y se analizan los resultados.

14.2.1.1. Caja negra

14.2.1.1.1. Comprueba que cada función del software es operativa

14.2.1.1.2. Garantiza que la entrada se acepta de forma adecuada

14.2.1.1.3. Produce una salida correcta

14.2.1.1.4. Encuentra errores en la base de datos, errores de la inicialización

14.2.1.1.5. Estudia

14.2.1.1.6. Identifica

14.2.1.1.7. En

14.2.1.2. Caja blanca

14.2.1.2.1. Asegura que la operación interna se ajusta a las especificaciones Comprueba los caminos lógicos del programa Ejemplo: Prueba de Bucle.

15. Etapas o niveles de pruebas

15.1. Verificación y validación

15.1.1. se describen las correspondientes actividades en pruebas para ello se utiliza el

15.1.1.1. modelo v

15.1.1.1.1. se debe llevar a cabo la verificación y validación

15.2. Pruebas unitarias

15.2.1. las pruebas se llevan a cabo tras la construcción de cada componente como

15.2.1.1. modulos

15.2.1.2. clases

15.2.1.3. undades

15.3. Pruebas integrales

15.3.1. comprueban la interacción entre componentes.

15.3.1.1. Ascendente

15.3.1.1.1. Cuando el desarrollo del sistema comienza con piezas unitarias y crece hasta formar módulos.

15.3.1.2. Descendente

15.3.1.2.1. se comienza a trabajar desde los módulos más grandes hasta llegar al detalle o a las partes unitarias.

15.3.1.3. Big Bang

15.3.1.3.1. el desarrollo no tiene un orden específico y puede ser al azar.

15.4. Pruebas de sistemas

15.4.1. probar el sistema integrado con el objeto de comprobar el cumplimiento de requisitos especificados.

15.4.1.1. se enfocan desde el punto de vista del usuario

15.4.1.2. se desarrollan utilizando casos de prueba funcionales y no funcionales.

15.4.1.3. confirmación de validación de requerimientos

15.5. Pruebas de aceptacion

15.5.1. son las pruebas de sistema por parte del cliente.

15.5.1.1. Prueba ALFA

15.5.1.1.1. validar que lo planteado se esta desarrollando correctamente

15.5.1.2. Prueba BETA

15.5.1.2.1. Estas se ejecutan en las dependencias del cliente.