El primer módulo del curso. Esperamos que te guste. 1

El primer módulo del curso. Esperamos que te guste.
1
En todos los módulos encontrarás una primera transparencia de objetivos de cada
uno de los módulo.
2
Todo el módulo tiene un boletín de ejercicio. Utiliza el boletín como una guía para
seleccionar los ejercicios que te resulten más interesantes o retadores. Además
encontrarás propuesta para comentar en foros, o ejercicios on-line en la plataforma
de enseñanza virtual.
3
El índice del módulo
4
Vamos a comenzar repasando algunas definiciones básicas que se utilizan en el
ámbito de la prueba del software. Es importante que todos usemos las mismas
palabras para referirnos a los mismos conceptos.
5
Una prueba se puede resumir como una entrada, una acción y un resultado.
Comprobamos si ese resultado es el esperado o no para determinar si la prueba se
pasó con éxito o falló.
6
Dos ejemplos que siguen el patrón anterior.
7
Si no buscamos un error difícilmente lo encontraremos escribiendo pruebas. Aunque
escribimos pruebas para mitigar la sensación de inseguridad y de duda, debemos
evitar que las pruebas nos den una falsa sensación de seguridad.
8
Esta clasificación está tomada de Métrica v3 aunque refleja muy bien las fases de
pruebas más comunes en la literatura de pruebas
Las primeras pruebas a aplicar dentro del proceso de prueba del sistema software
son las pruebas unitarias, de integración que verifican los componentes del sistema
software y su interrelación. Sin embargo, como hemos visto en una diapositiva
anterior, estas pruebas no son suficiente para garantizar la calidad del sistema.
Necesitamos una fase de pruebas que nos garantice que ese código sin errores realiza
lo que se espera de él: la fase de pruebas del sistema.
A continuación veremos cada una de estos tipos en más detalle.
9
La definición de Métrica v3 es muy genérica para no atarse a ningún lenguaje /
paradigma de programación concreto. A lo largo del curso, nuestros componentes
serán las clases y los métodos Java o de lenguajes similares (Python, JavaScript, etc.).
10
Los resultados esperados en las pruebas de integración suelen ser los mismos que los
resultados de las pruebas unitarias. La diferencia es que dichos resultados en las
pruebas de integración se calculan con los componentes reales del sistema que
entrarán en producción.
11
Las pruebas del sistema recogen las pruebas de los requisitos del sistema. Cualquier
cosa que se defina como un requisito debe tener algún tipo de prueba que verifique
su correcta implementación en el sistema.
12
El entorno de producción es aquella plataforma (máquinas, sistemas operativos, etc.)
que se utilizarán durante la vida del software.
13
El concepto de prueba de aceptación puede variar según la literatura. En Métrica V3
(de dónde hemos tomado esta clasificación) las pruebas de aceptación las realizan
principalmente los usuarios.
En otras referencias (generalmente del mundo ágil) las pruebas de aceptación son
pruebas del sistema diseñadas por los usuarios o creadas a partir de datos y ejemplos
proporcionados por usuarios.
En este curso no nos vamos a preocupar de esta distinción.
14
Hay varios sub-tipos distintos de pruebas dentro de los tipos de pruebas. Por
ejemplo, una de las fases en las que más tipo de pruebas distintas está documentada
en la literatura es la fase de prueba del sistema
Como norma, cada posible requisito o característica del sistema es susceptible de ser
verificada por una prueba del sistema. Dado que podemos tener muchos tipos de
requisitos: funcionales, de datos, de interfaz de usuario, de accesibilidad, etc.
También podemos tener muchos tipos de pruebas distintas.
15
Las técnicas de prueba nos indican cuantas pruebas se deben desarrollar y qué debe
comprobar cada una de las pruebas. Son una guía para saber qué pruebas tenemos
que hacer.
16
Sin notas.
17
Aquí vamos a ver técnicas que nos permitirán definir qué casos de prueba
necesitamos para poder probar un fragmento de código
18
Ejemplos de casos de prueba posibles.
19
Ejemplo de valores límite.
20
Esta técnica hace que salte una alarma en nuestra cabeza cada vez que escribimos un
bucle if o un bucle for / while que puede no ejecutarse ni siquiera una vez.
21
¿Cómo podríamos escribir una prueba automática que comprobara los resultados
esperados? Veremos la respuesta en el capítulo de Mocking.
22
Un conjunto (implementación de la interfaz java.util.Set)
23
Un conjunto (implementación de la interfaz java.util.Set)
En esta prueba podemos ver que la información de entrada de cada una de las
pruebas (filas) no es solo el valor a introducir en el conjunto sino también el estado
en el que está dicho conjunto. Es necesario tener en cuenta el estado previo de lo
que vamos a probar como parte de la definición de la prueba.
24
Vamos a ver qué características tienen las buenas pruebas unitarias.
25
La idea que el concepto “testable code” quiere expresar es escribir código que sea
sencillo de probar. Vamos a ver a continuación cómo podemos hacer esto.
26
Para terminar te proponemos enlaces a materiales adicionales para profundizar.
27
Enlaces y referencias en Internet para leer más.
28
Enlaces y referencias en Internet para leer más.
29