Pruebas de Software

Asignatura: Ingeniera de Software

Carrera: Ingeniera en Informtica /04
Alumna: de Paula, Luisina Alejandra
Matrcula: 65812

Ao: 2014

Pruebas de Software
Las pruebas intentan demostrar que un programa hace lo que se intenta que haga.
Al probar el software, se ejecuta un programa con datos artificiales
El proceso de Prueba tiene dos metas distintas:
1- Demostrar al desarrollador y al cliente que el software cumple con los
requerimientos. (Prueba de validacin)
2- Encontrar situaciones donde el comportamiento del software sea
incorrecto, indeseable o no est de acuerdo con su especificacin.
(Pruebas de Defectos/Verificacin).

Pruebas de Validacin y Verificacin

Boehm plante dos preguntas bsicas para diferenciar los dos tipos de
pruebas:
1- VALIDACIN: Construimos el producto correcto?
2- VERIFICACIN: Construimos bien (de manera correcta) el
producto?
Las pruebas pueden mostrar slo la presencia de errores, mas no su
ausencia. (Edsger Dijkstra)

Pruebas de Validacin y Verificacin

El objetivo final de los procesos de verificacin y validacin es establecer
confianza de que el sistema de software es adecuado.
El nivel de confianza adquirido depende de:
1. Propsito del Software: Cuanto ms crtico sea el software, ms importante debe
ser su confiabilidad.
2. Expectativas del usuario: A algunos usuarios no les sorprende que el sistema falle.
(La necesidad de prueba es baja).
3. Entorno de Mercado: Se debe considerar el producto de la competencia (cuando un
producto de software es comercializado).

Inspecciones
Se enfocan principalmente en el cdigo fuente de un sistema.
Se utiliza conocimiento del sistema para descubrir errores.
Ventajas sobre las pruebas:
Durante las pruebas los errores pueden ocultar a otras fallas
Las versiones incompletas se inspeccionan sin costos adicionales.
No solo busca defectos, sino tambin aspectos de calidad (portabilidad, estndares
y mantenibilidad).

Etapas donde se realizan

pruebas e inspecciones

Etapas de pruebas
Por lo general, un sistema de software comercial debe pasar por tres etapas
de pruebas:
Pruebas de desarrollo: El sistema se pone a prueba durante el proceso de
desarrollo del software para descubrir errores (bugs) y defectos.
Versiones de Prueba: Un equipo de prueba por separado experimenta una
versin completa del sistema, antes de presentarlo a los usuarios.
Pruebas de usuario: Donde los usuarios reales o potenciales de un sistema
prueban el sistema en su propio entorno.

Pruebas de desarrollo
Caractersticas:

Incluyen todas las actividades de prueba que realiza el equipo que elabora el sistema.
El examinador del software puede ser el programador que dise dicho software.
Algunos procesos de desarrollo usan parejas de programador/examinador.
Durante el desarrollo, las pruebas se realizan en tres niveles:
1. Pruebas de Unidad: Se ponen a prueba unidades de programa o clases de objetos. Se comprueba
la funcionalidad de objetos (clases) y mtodos de cada uno de ellos.
2. Pruebas de Componente: Partes individuales del sistema se integran para crear componentes
compuestos. (Interfaces)
3. Pruebas del sistema: Algunos o todos los componentes del sistema se integran y se prueba el
comportamiento del sistema como un todo.

Pruebas de Unidad
Cuando las pruebas de unidad evalan los objetos o las clases, deben tener en cuenta:
Probar todas las operaciones asociadas con el objeto.
Establecer el valor o que tipo de datos ir en cada uno de los atributos del objeto o clase.
Simular el objeto segn todos los posibles estados que pueda tomar.

Ejemplo:
Para probar los estados de la estacin meteorolgica, se usa un modelo de
estado. Hay que probar cualquier secuencia posible de transicin de estado,
aunque en la prctica ello resulte muy costoso. Por ejemplo:

Pruebas de Unidad
Prueba de particin: Grupos de entradas con caractersticas comunes que se
procesan de la misma forma.

Particiones de equivalencia

Pruebas de Componentes
Se encarga de demostrar PRINCIPALMENTE que la interfaz entre los componentes
de un sistema, se comportan segn su especificacin.
Tipos de errores de interfaz:

Uso incorrecto de la interfaz

Mala interpretacin de la interfaz
Errores de temporizacin

Prueba de interfaz

Pruebas de Componentes
Tips (guidelines) para buenas pruebas de interfaz:
1. Examinar el cdigo a probar y listar cada llamado de un componente a otro.
2. Donde existan punteros como parmetros, probar que sucede si el puntero es nulo.
3. Realizar pruebas donde falle a propsito un componente.
4. Prueba de esfuerzos donde se pasan mensajes. Generar mayor cantidad de mensajes que
de costumbre para ver como reacciona el sistema.
5. Realizar que algunos componentes interacten con memoria compartida. Establecer el
orden correcto en que estos la usan y proponer rdenes adversos para ver como
reaccionar el sistema.

Pruebas del Sistema

Incluyen la integracin de componentes para crear una versin del sistema y
probarlo como un todo.
Demuestran si los componentes son compatibles entre si y que transmiten
datos correctos en el momento correcto.
Se confunden con las pruebas de componentes, pero poseen diferencias:
1. En las pruebas del sistema los componentes reutilizables y los sistemas nuevos
pueden integrarse.
2. Los componentes desarrollados por diferentes miembros de un equipo pueden
integrarse.

Pruebas del Sistema

Los casos de prueba son muy tiles para este tipo de pruebas
Un diagrama de secuencia puede identificar las operaciones que se probarn
Es difcil conocer que cantidad de pruebas que deben realizarse
Las pruebas exhaustivas son prcticamente imposibles
Formateo de cuadros de
texto al finalizar accin

Ejemplos de pruebas del Sistema:

Probar todas las funciones del sistema que partan de un men.

Experimentar combinacin de funciones. (Por ejemplo: al apretar botn que se formatee el texto de los Text
Fields).
Donde hayan entradas proporcionadas por el usuario, hay que probar como
respondern las funciones, tanto si son correctas como incorrectas.
Aviso de datos mal ingresados

Desarrollo dirigido por pruebas (TDD)

Caractersticas:
TDD (Test-Driven Development).
Se entrelazan el desarrollo de pruebas y el de cdigo.
El cdigo se desarrolla incrementalmente, junto con la prueba para ese
incremento.
No se realiza el prximo incremento, sin haber probado el anterior.
Se introdujo como parte de los mtodos giles (Programacin extrema)

Desarrollo dirigido por pruebas (TDD)

Pasos para un TDD:
1. Identificar el incremento de una funcionalidad a realizar.
2.
3.
4.
5.

Escribir una prueba para esta funcionalidad (automatizada).

Correr la prueba, junto con otras pruebas de otros incrementos.
Si falla, se implementa la funcionalidad y se vuelve a ejecutar la prueba.
Si todas las pruebas se realizan con xito, se avanza a implementar la siguiente
funcionalidad

Diagrama de un TDD bsico

Desarrollo dirigido por pruebas (TDD)

Ventajas:
Cobertura de cdigo: El cdigo se prueba a medida que se escribe.
Pruebas de regresin: Es posible volver atrs con las pruebas realizadas para demostrar
que los cambios no introdujeron nuevos bugs.
Depuracin Simplificada: Cuando falla una prueba, es evidente donde est el problema.
(Cdigo recin escrito).
Documentacin del Sistema: Las pruebas en si actan como una forma de documentacin.
Leer las pruebas suele facilitar la comprensin del cdigo.

Pruebas de Versin
Se pone a prueba una versin en particular del sistema.
La versin puede ser para clientes, usuarios, otros equipos de desarrollo, etc.
Las pruebas de versin y de sistema no son lo mismo:
Las pruebas de sistema se basan en las pruebas de Verificacin/defectos.
Las pruebas de versin, en el cumplimiento de requerimientos, es decir, pruebas de Validacin.
Tambin se llaman pruebas funcionales.

La principal meta es convencer al proveedor del sistema, que est es suficientemente apto para su uso.

Pruebas de Versin
Las pruebas de versin utilizan la ayuda de otros 3 tipos de prueba:
Pruebas basadas en Requerimientos:
Los requerimientos deben ser comprobables.
Se pueden llevar a cabo mediante casos de prueba.
Cada requerimiento deriva de un conjunto de pruebas de ste.
Son pruebas de validacin ms que de verificacin.
Se intenta demostrar que el sistema implement adecuadamente sus requerimientos.

Pruebas de Escenario:
Se crean escenarios tpicos de uso.
Se utilizan casos de uso.
Un escenario describe una forma de usar el sistema.
Los escenarios deben ser realistas.
Los usuarios REALES deben relacionarse con ellos.

Pruebas de Rendimientos:
Prueban el rendimiento y la confiabilidad.
Se disean para garantizar que el sistema procesa su carga pretendida.
En las pruebas se aumenta la carga hasta que el rendimiento del sistema sea inaceptable.
Demuestran que el sistema cumple con sus requerimientos y descubre nuevos errores
Construye perfiles operativos (conjunto de pruebas que reflejan la mezcla de trabajo que maneja el sistema)

Pruebas de Usuario
Los usuarios o clientes proporcionan entrada y asesora sobre las pruebas del
sistema.
Pueden haber pruebas formales o informales.
El entorno de trabajo del usuario es SUMAMENTE importante, y causa efectos
sobre la fiabilidad, rendimiento, uso, etc del sistema.
En la prctica, hay tres tipos de pruebas de usuario:
Pruebas alfa: Los usuarios trabajan con el equipo de desarrollo en conjunto.
Pruebas beta: Una versin del software se pone a disposicin de los usuarios para que experimenten y
descubran problemas que no encontraron los desarrolladores.
Pruebas de aceptacin: Los clientes prueban el sistema para decidir si est o no listo para ser aceptado
y usado.

Pruebas de Aceptacin
Se realizan sobre todo en sistemas personalizados.
Se llevan a cabo generalmente despus de las pruebas de versin.
Implica la prueba formal del sistema por parte del cliente.

ACEPTACIN = PAGO POR EL SISTEMA

Pruebas de Aceptacin
Las pruebas de aceptacin tienen 6 pasos:
1- Definir los criterios de aceptacin: Se definen los criterios entre usuarios y desarrolladores antes de firmar el contrato
2- Plan de pruebas de aceptacin: Se deciden los recursos, el tiempo y el presupuesto para las pruebas de aceptacin.
3- Derivar pruebas de aceptacin: Se disean pruebas para ver si el sistema es aceptable o no. Se dirige tanto a las caractersticas
funcionales como no funcionales.
4- Correr pruebas de aceptacin: Se ejecutan las pruebas. Debera ocurrir en el entorno real, pero sera poco posible.
5- Negociar los resultados de las pruebas: En caso que no se encuentren problemas, la prueba es concretada y el producto
aceptado.
6- Rechazo/aceptacin del sistema: El cliente y los desarrolladores deciden si aceptar o no el sistema.

Pro

Proceso de prueba de aceptacin

Cultura General
Qu es JUnit?
Es un conjunto de bibliotecas que son utilizadas en programacin para hacer pruebas
unitarias de aplicaciones Java. Permite realizar la ejecucin de clases Java de manera
controlada, para poder evaluar si el funcionamiento de cada uno de los mtodos de la clase
se comporta como se espera.
En funcin de algn valor de entrada se evala el valor de retorno esperado; Si cumple,
devolver que la clase pas la prueba, o viceversa si no lo hizo, adjuntando el fallo.
Tambin controla pruebas de regresin (parte del cdigo se modific y se ve si la nueva
cumple con los requisitos anteriores).
Netbeans y Eclipse cuentan con plugins que permiten que la generacin de las plantillas
necesarias para la creacin de las pruebas de una clase Java se realice de manera
automtica.

Ejemplo en Netbeans:
Test que se aplic a un sistema de gestin de estudiantes en una
universidad:

Ejemplo de Resultados Junit en Netbeans

GRACIAS!
PREGUNTAS?