Pruebas de software

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 1

 Objetivos
⚫ Discutir las diferencias entre las pruebas de
validación y pruebas de defecto
⚫ Describir los principios y componentes de
sistema de pruebas
⚫ Describir las estrategias para generar casos
de prueba del sistema
⚫ Comprender las características esenciales
del instrumento utilizado para la prueba de
automatización

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 2

 Tópicos expuestos
⚫ Pruebas del sistema
⚫ Pruebas de componentes
⚫ Diseño de casos de prueba
⚫ Automatización de las pruebas

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 3

 El proceso de pruebas
⚫ Ensayos de los componentes
• Pruebas de cada uno de los componentes del programa;
• Por lo general, la responsabilidad del desarrollador de
componentes (excepto a veces para los sistemas
críticos);
• Las pruebas se derivan de la experiencia del
desarrollador.
⚫ Sistema de pruebas
• Ensayos de grupos de componentes integrados para
crear un sistema o sub-sistema;
• La responsabilidad de un equipo de pruebas
independientes;
• Las pruebas se basan en un sistema de especificación.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 4

 Fases de prueba

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 5

 Pruebas de Defectos
⚫ El objetivo de las pruebas defecto es
descubrir defectos en los programas
⚫ El éxito de una prueba defecto es una
prueba que causa un programa a
comportarse de una manera anómala
⚫ Las pruebas no muestran la presencia de la
ausencia de defectos

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 6

 Objetivos del proceso de prueba
⚫ Pruebas de validación
• Para demostrar que el promotor y el sistema cliente que
el software cumple con sus requisitos;
• El éxito de una prueba muestra que el sistema funciona
según lo previsto.
⚫ Defecto de prueba
• Para descubrir los vicios o defectos en el software que su
comportamiento es correcto o no en conformidad con las
especificaciones del mismo;
• El éxito de una prueba es una prueba que hace que el
sistema realice correctamente y de manera expone un
defecto en el sistema.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 7

 El proceso de pruebas de
software

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 8

 Políticias de Pruebas
⚫ Pruebas exhaustivas sólo puede mostrar un
programa está libre de defectos. Sin embargo, la
prueba exhaustiva es imposible,
⚫ Políticas de pruebas definen el enfoque que se
utilizará en la selección de pruebas de sistema:
• Todas las funciones a través de los menús de acceso
deben someterse a prueba;
• Combinaciones de las funciones accesibles a través del
mismo menú que se han de analizar;
• Cuando la entrada del usuario es necesario, todas las
funciones debe ser probado con la entrada correcta e
incorrecta.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 9

 Sistema de pruebas
⚫ Implica la integración de componentes para
crear un sistema o subsistema.
⚫ Puede implicar un incremento de las
pruebas que se entrega al cliente.
⚫ Dos fases:
• Integración de las pruebas - la prueba de
equipo de tener acceso al código fuente del
sistema. El sistema está probado como
componentes integrados.
• Noticia de prueba - la prueba de equipo de
prueba el sistema completo a ser entregadas
en una caja de negro.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 10
 Pruebas de integración
⚫ Involucra la construcción de un sistema a partir de
sus componentes y las pruebas para los problemas
que surgen de las interacciones de componentes.
⚫ De arriba abajo la integración
• Desarrollar el esqueleto del sistema y poblar
estos con los componentes.
⚫ La integración de abajo hacia arriba
• Integrar los componentes de la infraestructura a
continuación, agregue los componentes
funcionales.
⚫ Para simplificar la localización de errores, los
sistemas deben ser cada vez más integrado.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 11

 Incremento de la integración de
pruebas

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 12

 Pruebas de enfoques
⚫ Validación de arquitectura
• De arriba abajo la prueba de integración es mejor en
descubrir los errores en la arquitectura del sistema.
⚫ Sistema de demostración
• De arriba hacia abajo integración permite un número
limitado de pruebas de demostración en una fase
temprana en el desarrollo.
⚫ Prueba de ejecución
• Suelen ser más fáciles con la integración de abajo hacia
arriba la prueba.
⚫ Prueba de observación
• Problemas con ambos enfoques. Código adicional puede
ser necesario para observar las pruebas.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 13

 Ensayo
⚫ El proceso de pruebas de la liberación de un
sistema que se distribuirá a los clientes.
⚫ Objetivo principal es aumentar la confianza
del proveedor de que el sistema cumple con
sus requisitos.
⚫ Ensayo suele ser negro o caja de pruebas
funcionales
• Basado en la especificación del sistema único;
• Probadores no tienen conocimiento de la
aplicación del sistema.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 14

 Pruebas de caja-negra

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 15

 Directrices de ensayo
⚫ Pruebas indirectas son las directrices para las pruebas del
equipo ayudan a elegir las pruebas que ponen de manifiesto
defectos en el sistema
• Elegir los insumos que la fuerza del sistema para generar
todos los mensajes de error;
• Diseño de los insumos que causan desbordamiento de
buffers;
• Repita la misma serie de entrada o de entrada en varias
ocasiones;
• Fuerza no válidos los resultados que se generan;
• Fuerza de resultados de cálculo es demasiado grande o
demasiado pequeño.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 16

 Pruebas de hipótesis

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 17

 Sistema de pruebas

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 18

 Casos de uso
⚫ Casos de uso puede ser una base para
obtener las pruebas de un sistema. Ayudan
a identificar las operaciones de la prueba y
ayudar a diseñar los casos de prueba.
⚫ Secuencia de una sociedad asociada
diagrama, las entradas y salidas que se
creará para realizar los ensayos que pueden
ser identificados.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 19

 Recoger datos meteorológicos
secuencia gráfica

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 20

 Pruebas de rendimiento
⚫ Parte de ensayo puede implicar la prueba, el
propiedades emergentes de un sistema,
tales como el rendimiento y la fiabilidad.
⚫ Pruebas de rendimiento en general, la
planificación de una serie de pruebas donde
la carga se aumentó constantemente hasta
que el rendimiento del sistema se convierte
en inaceptable.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 21

 Prueba de tensión
⚫ Ejerce el sistema más allá de su máxima carga.
Haciendo hincapié en el sistema a menudo causa
de los defectos
Salido a la luz.
⚫ Destacando la falta de prueba de comportamiento
del sistema .. Sistemas no debe fallar
catastróficamente. Los controles de pruebas de
tensión inaceptable pérdida de datos o servicio.
⚫ Pruebas de tensión que es de especial interés para
los sistemas distribuidos que pueden presentar
como una grave degradación
Red pasa a ser sobrecargado.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 22
 Ensayos de los componentes
⚫ Componente o unidad de pruebas es el proceso de
pruebas de componentes individuales de forma
aislada.
⚫ Se trata de un defecto del proceso de pruebas.
⚫ Componentes pueden ser:
• Individuales dentro de las funciones o métodos
de un objeto;
• Clases de objetos con varios atributos y
métodos;
• Compuesto de componentes con interfaces
definidas utiliza para acceder a su
funcionalidad.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 23
 Prueba de Clases de objeto
⚫ Cobertura completa de los ensayos de una
clase implica
• Pruebas de todas las operaciones relacionadas
con un objeto;
• Ajuste y el interrogatorio de todos los atributos
de los objetos;
• El objeto en el ejercicio de todos los posibles
estados.
⚫ Herencia hace más difícil el diseño de
pruebas de clase de objeto ya que la
información de la prueba no es localizado.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 24
 Estación meteorológica de
objetos de interfaz

WeatherStation
iden tifier
rep or tWeather ()
calibrate (instruments)
test ()
star tup (instrumen ts)
shutdown (instrumen ts)

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 25

 Prueba de Estación
meteorológica
⚫ Necesidad de definir los casos de prueba
para reportWeather, calibración, ensayo,
inicio y apagado.
⚫ Utilizando un modelo de estado, identificar
las secuencias de las transiciones de estado
de la prueba y el caso de las secuencias de
causar estas transiciones
⚫ Por ejemplo:
• Esperando -> Calibración -> Pruebas ->
Transmisión de -> en espera

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 26

 Pruebas de Interfaz
⚫ Los objetivos son detectar fallas debido a la
interfaz de errores o no válidos los
supuestos sobre las interfaces.
⚫ Particularmente importante para el desarrollo
orientado a objetos como los objetos se
definen por sus interfaces.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 27

 Pruebas de Interfaz

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 28

 Tipos de interfaz
⚫ Parámetro interfaces
• Los datos transmitidos de un procedimiento a otro.
⚫ Interfaces de memoria compartida
• Bloque de memoria se comparte entre los procedimientos
o funciones.
⚫ Interfaces de procedimiento
• Sub-sistema engloba una serie de procedimientos para
ser llamado por otros subsistemas.
⚫ Mensaje pasando interfaces
• Sub-sistemas de solicitud de servicios de otros sub-
system.s

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 29

 Errores de Interfaz
⚫ Uso indebido de la interfaz
• Un componente de las llamadas pidiendo otro
componente realiza un error en el uso de su interfaz por
ejemplo, parámetros en el orden equivocado.
⚫ Interfaz malentendida
• Una llamada a componente incluye supuestos sobre el
comportamiento de los llamados componentes que son
incorrectos.
⚫ Errores de calendario
• El llamado y la convocatoria de componentes funcionan a
distintas velocidades y fuera de la fecha la información se
accede.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 30

 Directrices de la prueba de
Interfaz
⚫ Diseño de pruebas a fin de que los parámetros de
llamada a un procedimiento en el extremo final de
sus gamas.
⚫ Siempre pruebe los parámetros de puntero nulo con
punteros.
⚫ Diseño de pruebas que causan el componente falle.
⚫ Usar pruebas de tensión en sistemas de paso de
mensajes.
⚫ En los sistemas de memoria compartida, variar el
orden en que los componentes son activados.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 31

 Diseño de Casos de prueba
⚫ Implica el diseño de los casos de prueba
(entradas y salidas) que se utiliza para
probar el sistema.
⚫ El objetivo de la prueba de diseño es crear
un conjunto de pruebas que son eficaces en
la validación y el defecto de la prueba.
⚫ Enfoques de diseño:
• Requisitos basados en pruebas;
• Partición de pruebas;
• Pruebas estructurales.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 32

 Pruebas en base a requisitos
⚫ Un principio general de ingeniería de
requisitos es que los requisitos deben ser
comprobables.
⚫ Requisitos basados en las pruebas de
validación de pruebas es una técnica en la
que considera que cada requisito y obtener
un conjunto de pruebas de ese requisito.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 33

 LIBSYS requisitos

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 34

 LIBSYS pruebas

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 35

 Pruebas de Partición
⚫ Datos de entrada y salida de los resultados
a menudo se dividen en diferentes clases,
donde todos los miembros de una clase
están relacionados.
⚫ Cada una de estas clases de equivalencia
es una partición de dominio o cuando el
programa se comporta de forma equivalente
para cada miembro de la clase.
⚫ Casos de prueba deben ser elegidos en
cada partición.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 36
 Particiones de Equivalencia

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 37

 Particiones de equivalencia

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 38

 Especificación de rutina de
búsqueda

procedimiento de búsqueda (clave: ELEM; T: SEQ de ELEM;

Encontrados: a cabo en BOOLEAN; L: a cabo en ELEM_INDEX);

Condición previa
- La secuencia tiene al menos un elemento
T'FIRST <= T'LAST
Post-condición
- El elemento se encuentra y es referenciado por L
(Encontrado y T (L) = Key)
o
- El elemento no se encuentra en la gama
(No se encontró el
no (existe i, T'FIRST> = i <= T'LAST, T (i) = clave))

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 39

 Rutina de búsqueda – particiones
de entrada
⚫ Insumos que se ajusten a las condiciones
previas.
⚫ Insumos que una condición previa no se
sostiene.
⚫ Insumos que el elemento clave es un
miembro de
La matriz.
⚫ Insumos que el elemento clave no es
miembro de la matriz.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 40

 Directrices de ensayo
(secuencias)
⚫ Secuencias de prueba de software con el
que sólo tienen un valor único.
⚫ Utilice las secuencias de diferentes tamaños
en diferentes pruebas.
⚫ Obtener pruebas de manera que la primera,
media y últimos elementos de la secuencia
se accede.
⚫ Prueba con secuencias de longitud cero.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 41

 Rutina de búsqueda – particiones
de entrada

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 42

 Estructuras de ensayo
⚫ Blanca llamada en algún cuadro de la
prueba.
⚫ Derivación de casos de prueba de acuerdo
con la estructura de programas.
Conocimiento de que el programa se utiliza
para identificar casos de prueba adicionales.
⚫ Objetivo es ejercer la totalidad de las
declaraciones del programa (no todas las
combinaciones de camino).

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 43

 Estructuras de ensayo

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 44

Búsqueda binaria - equiv. particiones
⚫ Condiciones previas satisfecho, elemento clave en
la matriz.
⚫ Satisfecho las condiciones previas, no en el
elemento clave
Matriz.
⚫ Condiciones previas insatisfechas, elemento clave
en la matriz.
⚫ Condiciones previas no satisfechas, no en el
elemento clave para la matriz.
⚫ Matriz de entrada tiene un valor único.
⚫ Matriz de entrada tiene un número par de valores.
⚫ Matriz de entrada tiene un número impar de valores.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 45

 Búsqueda binaria particiones
equivalentes

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 46

 Búsqueda binaria - casos de
prueba

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 47

 Pruebas de rutas de acceso
⚫ El objetivo de la prueba de ruta de acceso
es garantizar que el conjunto de casos de
prueba es tal que cada camino a través del
programa se ejecuta al menos una vez.
⚫ El punto de partida para la ruta de acceso es
un programa de pruebas de flujo gráfico que
muestra los nodos que representan a las
decisiones del programa y arcos que
representan el flujo de control.
⚫ Estados con condiciones, por lo tanto, son
los nodos en el gráfico de flujo.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 48
 Gráfico de flujo binario de
búsqueda

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 49

 Caminos independientes
⚫ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 14
⚫ 1, 2, 3, 4, 5, 14
⚫ 1, 2, 3, 4, 5, 6, 7, 11, 12, 5,
⚫ 1, 2, 3, 4, 6, 7, 2, 11, 13, 5,
⚫ Casos de prueba deben ser derivados a fin
de que todos estos caminos se ejecutan
⚫ Un programa dinámico analizador se puede
utilizar para comprobar que los caminos han
sido ejecutados

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 50

 Automatización de Pruebas
⚫ Pruebas es un proceso caro fase. Pruebas de
laboratorio ofrecen una gama de herramientas para
reducir el tiempo requerido y el total de los costes
de ensayo.
⚫ Sistemas como JUnit apoyar la ejecución
automática de pruebas.
⚫ La mayoría de pruebas de laboratorio son sistemas
abiertos porque las pruebas son las necesidades
específicas de la organización.
⚫ A veces son difíciles de integrar en el diseño y
análisis cerrado laboratorio.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 51

 Un ensayo de trabajo

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 52

 Pruebas de trabajo de
adaptación
⚫ Secuencias de comandos pueden ser
desarrollados para la interfaz de usuario y
modelos de simuladores para los
generadores de los datos de los ensayos.
⚫ Prueba de los productos pueden tener que
estar preparados para la comparación
manualmente.
⚫ Especial para fines de comparación de
archivos se pueden desarrollar.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 53

 Puntos clave
⚫ Pruebas pueden mostrar la presencia de fallas en
un sistema, no puede demostrar que no hay otros
defectos.
⚫ Componente de los desarrolladores son los
responsables de las pruebas de componentes,
sistema de prueba está a cargo de un equipo.
⚫ Integración de pruebas está probando el sistema de
incrementos; ensayo implica un sistema de pruebas
a ser liberada a un cliente.
⚫ Utilice la experiencia y directrices para diseñar
casos de prueba en defecto de la prueba.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 54

 Puntos clave
⚫ Interfaz de las pruebas está diseñado para descubrir
defectos en las interfaces de componentes
compuestos.
⚫ Equivalencia de particionado es una forma de
descubrir casos de prueba - en todos los casos, una
partición debe comportarse de la misma manera.
⚫ Análisis estructural se basa en el análisis de un
programa de pruebas y se derivan de este análisis.
⚫ Prueba de automatización de pruebas reduce los
costes por apoyar el proceso de prueba con una
serie de herramientas de software.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 55