PRUEBAS DE SOFTWARE

SEMANA 02: Metodología de Pruebas de Software

Logro del Aprendizaje
Al finalizar la presente sesión el estudiante
conoce las metodologías de prueba de software,
principios y los tipos de prueba de software.
Contenido

1. Técnicas de Pruebas de Software

2. Siete Principios de las Pruebas
3. Tipos de Pruebas
4. Conclusión
5. Bibliografía
1. Tipos de Testing: Técnicas
Pruebas de Caja Negra: Pruebas en base a aun requerimiento como output sin
necesidad de conocer la estructura interna o códigos del programa. Puede ser
funcional o no funcional, aunque usualmentefuncional.
Pruebas de Caja Blanca: También conocido como “Glass Box”o “Clear Box”
Testing, para cuya ejecución es necesario tener conocimiento acerca de la
estructura interna y código fuente del programa

INPUT OUTPUT
Black Box
White Box Testing
Testing
2. Siete principios del proceso de prueba
❑ Principio 1: El proceso de prueba demuestra la presencia de
defectos, no su ausencia
✓ Las desviaciones identificadas a lo largo del proceso de prueba
demuestran la presencia de un fallo.
✓ La causa de un fallo puede no ser obvia.
✓ El proceso de prueba no puede demostrar la ausencia de defectos.
✓ Las pruebas reducen la probabilidad de la presencia de defectos
que permanezcan sin ser detectados.
✓ La ausencia de fallos no demuestran la corrección de un producto
software.
✓ El mismo proceso de prueba puede contener equivocaciones.
✓ Las condiciones de prueba pueden ser inapropiadas para detectar
los errores cometidos por el desarrollador.
2. Siete principios del proceso de prueba
❑ Principio 2: No es posible realizar pruebas exhaustivas.
✓ Pruebas exhaustivas (exhaustive testing)
▪ Es donde el conjunto de pruebas abarca todas las combinaciones de valores
de entrada y precondiciones.
✓ Explosión de casos de prueba (test case explosion)
▪ Define el incremento factorial del esfuerzo y costo en el caso de
pruebas exhaustivas.
✓ Pruebas de Muestra (sample test)
▪ Se realiza la prueba tomando un subconjunto de todos lo posibles
valores de entrada,
▪ Para elegir este subconjunto de valores se puede realizar en forma
sistemática o aleatoria.
▪ Probar todas las combinaciones posibles de entrada y precondiciones
sólo es económicamente viables en casos triviales.
2. Siete principios del proceso de prueba
❑ Principio 3: Pruebas temprana (early testing).
✓ Cuanto mas temprana es la detección de un defecto, menos costosa es
su corrección.
✓ Los defectos detectados en la fase de concepción (fase temprana) son
corregidos con menor esfuerzo y costo.
✓ Se obtiene una máxima rentabilidad cuando los defectos son corregidos
antes de la implementación.
✓ Los conceptos y especificaciones también pueden ser probados.
✓ La preparación de una prueba también consume costo.
✓ El proceso de prueba implica mas que sólo la ejecución de la prueba.
✓ Las actividades de prueba pueden ser preparadas antes de que el
desarrollo se haya completado.
✓ Las actividades de prueba deben ser ejecutadas en paralelo a la
especificación y diseño de software.
2. Siete principios del proceso de prueba
❑ Principio 4: Agrupamiento de defectos (defect clustering).
✓ Encuentre un defecto y encontrarás más defectos “cerca”, así
que si un defecto es encontrado es muy probable que haya
más defectos alrededor de este último
✓ Los defectos aparecen agrupados como hongos y cucarachas.
✓ Vale la pena investigar un mismo módulo donde se ha
detectado un defecto.
✓ Los probadores de software deben ser flexibles
✓ Habiendo detectado un defecto, es conveniente volver a
considerar el rumbo de las pruebas posteriores.
✓ La identificación de un defecto puede ser investigada con un
mayor grado de detalle, realizando pruebas adicionales o
modificando las existente.
2. Siete principios del proceso de prueba
❑ Principio 5: Paradoja del pesticida (paradoja de las plagas)
✓ Repetir las pruebas en las mismas condiciones no es efectivo es decir si
las pruebas se repiten una y otra vez, pierden efectividad.
✓ Cada caso de prueba debe contar con una combinación única de
parámetros de entrada para un objetivo de prueba particular, de lo
contrario no se podrá obtener información adicional.
✓ Si se ejecutan las mismas pruebas en forma reiterada no se podrán
encontrar nuevos defectos.
✓ Las pruebas deben ser revisadas/modificadas regularmente para los
distintos módulos de código.
✓ Es necesario repetir una prueba tras una modificación de código
(corrección de defectos, nueva funcionalidad).
✓ La automatización de pruebas es conveniente si un conjunto de casos de
prueba se ejecuta con frecuencia.
2. Siete principios del proceso de prueba
❑ Principio 6: Las pruebas dependen del contexto.
✓ Las pruebas deben adaptarse a los riesgos inherentes de su uso y al entorno de
la aplicación, por eso, dos sistemas nunca deben de ser probados de la misma
manera.
✓ Repetir las pruebas en las mismas condiciones no es efectivo es decir si las
pruebas se repiten una y otra vez bajo las mismas condiciones, pierden
efectividad.
✓ Objetivos de pruebas diferentes son probados de forma diferente.
✓ Entorno de prueba (test environment, cama de prueba – test bed) vs entorno
de producción (productión environment)
✓ Las pruebas tiene lugar en un entorno distinto del entorno de producción, por lo
que el entorno de pruebas debe ser muy similar al entorno de producción.
✓ Siempre habrá desviaciones entre el entorno de prueba y el entorno de
producción.
✓ Estas desviaciones ponen en tela de juicio las conclusiones que se obtuvieran
tras las pruebas.
2. Siete principios del proceso de prueba
❑ Principio 7: La falacia de la ausencia de errores.
✓ Un proceso de prueba adecuado detectará los fallos más importantes
✓ En la mayoría de los casos el proceso de prueba no detectará todos los
defectos del sistema (Principio 2), pero los defectos mas importantes
deberían ser detectados.
✓ La ausencia de errores, por si solo, no prueba la calidad del software.
✓ Encontrar “fallas” y reparar defectos no quiere decir que el sistema
cumple las expectativas y necesidades del usuario.
✓ La funcionalidad del software puede no satisfacer las necesidades y
expectativas de los usuarios.
✓ No se puede introducir calidad a través de las pruebas, la calidad tiene
que construirse desde el principio.
✓ La temprana participación del usuario en el proceso de desarrollo y el
uso de prototipos son medidas para evitar problemas.
2. Siete principios del proceso de prueba
❑ Las pruebas pueden ayudar a detectar defectos en el software, sin
embargo la mismas no pueden demostrar la ausencia de defectos.
❑ Para casos no triviales las pruebas exhaustivas son imposibles, la
prueba de muestra son necesarias.
❑ Las pruebas tempranas ayudan a reducir costes dado que los
defectos descubiertos en fases tempranas del proceso de
software son corregidas con menor esfuerzo.
❑ Los defectos se presentan agrupados.
❑ La repetición de pruebas idénticas no genera nueva información.
❑ Las pruebas dependen del contexto, es decir el entorno particular
determina la forma en la cual se ejecutarán la pruebas.
❑ Un software libre de fallos no implica su adecuación al uso.
2. Siete principios del proceso de prueba
Un equipo de prueba encuentra constantemente entre el 90% y el 95% de
los defectos presentes en el sistema bajo prueba. Mientras que el director de
pruebas entiende que se trata de un buen porcentaje de detección de
defectos para su equipo de pruebas y la industria, la alta dirección y los
ejecutivos siguen siendo decepcionado en el grupo de prueba, diciendo que
el equipo de pruebas no detecta, pierde, demasiados errores. Dado que los
usuarios de Internet están generalmente satisfechos con el sistema y que los
fallos que se han producido han sido en general de bajo impacto, cuál de los
siguientes principios de prueba que es más probable que ayude al director
de pruebas a explicar a estos gerentes y ejecutivos por qué algunos defectos
puedan no ser detectados?
a) Testing Exaustivo es imposible,
b) Los defectos tienden a agruparse. (Defect clustering )
c) Paradoja del pesticida (o de las plagas)
d) Falacia de la ausencia de errores.
1/06_06. Reflexión sobre el testing
https://www.youtube.com/wat?v=EwmI5NDKLBo
3.Tipos de Testing

- Unidad
- Integración
- Funcionalidad
- Usabilidad
- Sistema
- Performance
- Seguridad

REQS TESTS
Tipos de TestingValida que las unidades individuales de código
fuente están funcionando apropiadamente.
Una unidad es la parte mas pequeña testeable de
una aplicación. El objetivo de las pruebas de
unidad es aislar cada parte del programa y
Pruebas de Unidad mostrar que cada parte individual es correcto.
Tipos de Testing
Las pruebas de integración es un tipo de
pruebas en el cual diferentes módulos del
software se combinan y testean como un grupo.
El objetivo de este tipo de pruebas es verificar
funcionalidades, la performance y la
Pruebas de Integración confiabilidad de un producto.
Tipos de Testing

Utilizado para verificar si un producto cumple

con los requerimientos y especificaciones
Pruebas Funcionales funcionales.
Tipos de Testing
Este tipo de pruebas sirve para evaluar un
producto desde el punto de vista de un usuario y
su rápida adecuación al sistema.
Pruebas de Usabilidad Involucra input directo sobre como los usuarios
reales usarán el sistema.
Tipos de Testing
Es llevado a cabo en un sistema integrado y
completo para evaluar los requerimientos
especificados como un todo.
Este no debería requerir conocimiento del diseño
interno del código o lógica de programación.
Pruebas de Sistema Es ejecutado en la totalidad del sistema.
Tipos de Testing
Permite determinar que tan rápido algunos
aspectos del sistema funciona bajo una
particular carga de trabajo.
Es utilizado para determinar la velocidad o
Pruebas de efectividad de un software.
Performance
Tipos de TestingProceso para determinar que un sistema de
información protege los datos y mantiene la
funcionalidad tal y como se espera que fuese.
Básicamente, lo que se quiere verificar en este
tipo de pruebas es que el software brinde
confidencialidad, integridad, autenticación,
Pruebas de Seguridad autorización, disponibilidad y auditoría
Ciclo de vida

Planificación

Definición

Automatización

Ejecución

Reporte

Análisis
4. Conclusión

En esta sesión hemos aprendido los siguientes puntos:

1. Técnicas de Pruebas de Software
2. Siete Principios de las Pruebas
3. Tipos de Pruebas
5. Bibliografía

1. TÉCNICAS DE EVALUACIÓN DE SOFTWARENatalia (2006). Juristo, Ana

M. Moreno, Sira Vegas
2. https://itblogsogeti.com/2017/05/16/etica-empresarial-en-el-iot/

3. https://www.youtube.com/wat?v=EwmI5NDKLBo

4. https://slideplayer.es/slide/1053403/

5. http://oa.upm.es/40012/1/PFC_JOSE_MANUEL_SANCHEZ_PENO_3.
pdf
Preguntas?
Gracias
por su atención