El documento describe diferentes técnicas de pruebas de software, incluyendo pruebas de unidad, integración y sistemas. Explica que las pruebas de unidad prueban unidades individuales, las pruebas de integración verifican que las unidades funcionen juntas, y las pruebas de sistemas prueban el sistema completo. También cubre estrategias como el orden y alcance de las pruebas y la automatización para reducir el esfuerzo. Finalmente, describe procesos como inspecciones para revisar el trabajo de manera formal.

1. TÉCNICAS DE PRUEBAS
Ing. Noretsys Rodríguez
INGENIERÍA DEL SOFTWARE
TRAYECTO 3 – TRIMESTRE 3
BIENVENIDOS

2. Definición de Conceptos
 Falla: Ocurre cuando un programa no se
comporta de manera adecuada. Es una
propiedad estadística de un sistema en
ejecución.
 Defecto: tiene lugar en el código del
programa. La existencia de un defecto puede
ocasionar una falla.
 Error: acción humana que provoca que el
software contenga un defecto.

3. Niveles de pruebas
 Pruebas de unidad: solo una unidad es
probada, ejemplo: una clase módulo o
subsistema.
 Pruebas de integración: se verifica que las
unidades trabajen juntas correctamente.
Pueden ser realizadas mediante casos de uso
de pruebas.
 Pruebas de sistemas: verifica el sistema
completo o su aplicación como tal, desde el
punto de vista del usuario final.

4. Pruebas de unidad
 Pruebas de especificación o caja negra: verifica
las relaciones de entrada y salida de cada unidad.
Su objetivo es verificar “QUE” hace la unidad sin
averiguar como lo hace.
 Pruebas basadas en estados: verifica las
interacciones entre operaciones de una unidad
según cambios en los parámetros de entrada
salida.
 Prueba estructural o de caja blanca: verifica que
la estructura interna de cada unidad sea
correcta, es necesario conocer como está
implementada la unidad.

5. Pruebas de integración
 Después de haber probado todas las unidades
se deben integrar en unidades más grandes
hasta generar todo el sistema. En esta prueba
se incluyen:
 De paquetes de servicios.
 Casos de usos.
 Subsistemas.
 Sistema completo.

6. Pruebas de sistemas.
 Al principio las pruebas de casos de uaso se
hacen de manera independientes basadas en el
modelo de requisitos, luego se prueba el sistema
como un todo. Se ejecutan varios casos de uso
en paralelo sometiendo al sistema a varios tipos
de cargas. Las pruebas de sistemas involucran:
 Pruebas de operación.
 De escala completa.
 Negativas.
 Casos de uso.
 De documentación de usuario.

7. Estrategias de pruebas
 Existen múltiples estrategias de pruebas, las
más destacadas son:
 Orden de pruebas.
 Alcance de pruebas.
 Automatización de pruebas.

8. Orden de pruebas
 Define en que momento y orden se aplican las
pruebas.
 Existen dos enfoques:
 De arriba hacia abajo: se desarrollan inicialmente las
interfaces para probar los protocolos de alto nivel
antes de ir a los niveles inferiores.
 De abajo hacia arriba: se certifica las unidades de bajo
nivel y luego las interfaces.
 Depende de la estrategia de diseño, ya que, se
debe corresponder con el proceso de desarrollo.

9. Alcance de pruebas
 Tiene como propósito identificar el tipo,
número y casos de pruebas que se aplicarán
para revisar los diferentes aspectos del
sistema. El objetivo es seleccionar un número
pequeño pero razonable de casos de pruebas
donde la posibilidad de encontrar defectos y
fallas se alta.

10. Automatización de pruebas
 Tiene como propósito reducir el esfuerzo y
costo de las pruebas. Esto se logra mediante
programas de pruebas especiales asociados a
un conjunto de datos de pruebas.

11. Técnicas de pruebas
 Prueba de regresión: verifica el sistema luego de
haberle introducido cambios, ejemplo: tras
corregir una falla o defecto.
 Prueba de operación: verifica el sistema en
operación por un largo periodo de tiempo bajo
condiciones normales de uso. Mide la
confiabilidad.
 Prueba de escala completa: verifica el sistema en
su carga máxima mediante la asignación de
parámetros a su valor límite y la interconexión
del sistema con un máximo de equipos y usuarios
simultáneos.

12. Técnicas de pruebas
 Prueba de rendimiento o de capacidad: Mide
la capacidad de procesamiento y respuesta
del sistema bajo diferentes cargas,
incluyendo espacio de almacenamiento.
 Prueba de sobrecarga: prueba como se
comporta el sistema cuando se le aplica una
sobrecarga, más allá de las pruebas de escala
completa y rendimiento.
 Prueba negativa: mide el Estrés del sistema
en situaciones inesperadas.

13. Técnicas de pruebas
 Pruebas de casos de uso: Se llevan a cabo
pruebas directamente en la especificación de
requisitos. Se trata de verificar que el sistema
final cumple con las especificaciones del
usuario.
 Pruebas ergonómicas: prueba las interfaces
hombre – máquina, la congruencia del
sistema, usabilidad, amigabilidad.

14. Técnicas de prueba
 Pruebas de documentación de usuario:
Prueba que los documentos entregados al
usuario final sean congruentes con el sistema.
 Prueba de aceptación o validación: Es la
prueba por parte del usuario final, se realiza
en un ambiente real por un periodo extenso,
al te3rminar se toma la decisión de aprobar o
no el producto.

15. Proceso de Inspección
 Es un repaso detallado y formal del trabajo en
proceso.
 4 o 5 personas estudian el producto de trabajo
independientemente y luego se reúnen para
examinar el trabajo en detalle.
 El proceso se divide en 6 fases:
 Planificación:.
 Overview.
 Preparación.
 Examen.
 Retrabajo.
 Seguimiento.

16. Fases de la inspección
 Planificación: Cuando el desarrollador completa un
producto se forma el grupo de inspección y se designa un
moderador. El moderador asegura que el producto
satisfaga el criterio de inspección. Se le asignan diferentes
roles a las personas que integran el grupo de inspección, así
como la planificación de tiempos y recursos necesarios .
 Overview: Es una vista general es necesaria en éste
momento. Este es un paso opcional, pero no menos
importante, ya que en esta etapa se dará al grupo de
inspección un "background" y el contexto a cubrir por las
inspecciones.
 Preparación: Los inspectores se preparan individualmente
para la evaluación en la reunión, estudiando los productos
y el material relacionado. Se usan listas de chequeos para
ayudar a encontrar defectos comunes, el tiempo que
pueda llevar esta etapa depende de cuan familiarizado esté
el inspector con el trabajo que debe analizar.

17. Fases de la inspección
 Examen: En esta etapa, los inspectores se reúnen para analizar su
trabajo individual en forma conjunta. El moderador deberá
asegurarse que todos los inspectores están suficientemente
preparados. La persona designada como lector presenta el
producto , interpretando o parafraseando el texto, mientras que
cada participante observa en busca de defectos. Es
recomendable que este examen no dure mas de 2 horas ya que la
atención en busca de defectos va disminuyendo con el tiempo. Al
terminar con la reunión, el grupo determina si el producto es
aceptado o debe ser retrabajado para una posterior inspección.
 Retrabajo: El autor corrige todos los defectos encontrados por los
inspectores.
 Seguimiento: El moderador chequea las correcciones del autor. Si
el moderador está satisfecho, la inspección está formalmente
completa, y el "producto de trabajo" es puesto bajo el control de
configuración.

18. Gracias!