Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Tema 3: Diseño y Realización de pruebas.

Entornos de Desarrollos
by

Manuel Manzano López

on 21 January 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Tema 3: Diseño y Realización de pruebas.

Tema 3:
Diseño y Realización de pruebas.

Ciclo de vida de desarrollo de software.
Documentación de la prueba.
La documentación de las pruebas que se generarán importante para posteriores consultas, según la metodológia Metrica v3, que se basa en los estándares y normas.
Etapa 4: Pruebas.

La realización de pruebas al software desarrollado es necesario, para la corrección de los posibles errores humanos, que se han podido producir en el propio desarrollo.

Procedimientos y casos de pruebas.
Para poder diseñar procedimientos para los diferentes casos de prueba, teniendo en cuenta la complejidad de los programas es necesario realizar un equilibrio entre la cantidad de recursos (tiempo) y la probabilidad de detectar los errores.
Validaciones.
Si bien todo lo anterior es referenciado a los tipos de pruebas, el diseño de las mismas, y las herramientas, tienen que ver con la parte del proceso de verificación en la etapa de pruebas, en este caso es el proceso de validación, en la que se someterá a pruebas de caja negra, para que el cliente decida si realmente cumple con los requisitos establecidos por el mismo en la etapa de análisis.
Tipos de pruebas.
De caja negra (Black box Testing).
De caja blanca (White box Testing).
Pruebas de caja Negra.
Son pruebas a nivel de interfaz de la aplicación, se centra en los resultados obtenidos y conocidos, a partir de la entradas.
Pruebas de caja blanca.
Son pruebas que se centran en el código propio de la aplicación, en como se maneja los datos.

Etapas:

1. ANÁLISIS DE REQUISITOS.
Se especifican los requisitos funcionales y no funcionales del sistema.
2. DISEÑO.
Se divide el sistema en partes y se determina la función de cada una.
3. CODIFICACIÓN.
Se elige un Lenguajes de Programación y se codifican los programas.
4. PRUEBAS.
Se prueban los programas para detectar errores y se depuran.
5. DOCUMENTACIÓN.
De todas las etapas, se documenta y guarda toda la información.
6. EXPLOTACIÓN.
Instalamos, configuramos y probamos la aplicación en los equipos del cliente.
7. MANTENIMIENTO.
Se mantiene el contacto con el cliente para actualizar y modificar la aplicación
Tipos de pruebas:
En la etapa de pruebas del software, existen varios tipos de pruebas pero en general se pueden distinguir las siguientes:
De caja negra o funcionales
Particiones equivalentes.
Esta prueba se centra en reducir el conjunto total de entradas posibles a un número reducido que pueda sustituir en la prueba al conjunto.
Análisis de valores límites.
Esta prueba se centra en realizar la prueba con los valores máximo y mínimos o los valores de los extremos del conjunto de valores posibles.
Pruebas aleatorias.
Las pruebas aleatorias constan de la generación de valores al azar. Esta prueba no es adecuada para entornos interactivos
Ejemplo:
Una función que acepta números caracteres dentro de un intervalo, se generán varios valores al azar dentro de dicho intervalo.
Se pueden distinguir las siguientes :
Particiones equivalentes.
Análisis de valores límites.
Pruebas aleatorias.
Cobertura de sentencias.
La cobertura de sentencias se centra en la realización de pruebas de tal forma que cada una de las sentencias se ejecuten al menos una vez y evitar código no utilizado.
Cobertura de decisiones.
La cobertura de decisiones se centra en la realización de pruebas de cada decisión , y se evalúe en el caso de ser cierto y en el caso de ser falso.
Cobertura de condiciones.
Este tipo de prueba genera los casos para que cada condición se ejecute al menos una vez, en el caso de que la condición sea cierta o sea falsa.
Ejemplo:
El ejemplo de cobertura de condiciones se ejecuten según la condición, variable booleana o, expresiones entre operador relacional, ==, <=, >=, <, >, !=
Cobertura de condiciones o decisiones.
La cobertura de condiciones o decisiones es aquella que cubre ambos tipos de pruebas.
Cobertura de camino de prueba.
Se puede dividir en dos caso:
Que cada camino se ejecute una vez.
Que cada camino se ejecute tres veces:
Pruebas de Caja blanca o estructurales.
Las pruebas estructurales según el tipo de camino para la obtención de los resultados o cobertura lógica pueden ser :
Cobertura de sentencias.
Cobertura de decisiones.
Cobertura de condiciones.
Cobertura de condiciones y decisiones.
Cobertura de caminos.
Cobertura del camino de prueba.
Ejemplo:
Este tipo de prueba se realiza, en sentencias de código consecutivas o secuenciales.

Cobertura de caminos
La cobertura de caminos se refiere a que una vez se cumple una decisión y/o condición se ejecutan sentencias secuencialmente, de principio a fin, apareciendo el concepto de camino, que puede tomar un programa. A cada camino es necesario realizar una prueba que los recorra. La realización de esta prueba se realiza con la cobertura de camino de prueba.
Primera vez no se entra en el interior.
Segunda se entra ejecutándolo una vez.
Tercera vez se entra ejecutándolo dos veces más.
De regresión.
Pruebas de regresión.
La pruebas de regresión son pruebas que se realizan cuando se produce un cambio en el código del programa, como por ejemplo una actualización, o una mejora o corrección de un error.
No solo se realiza la prueba al componente corregido, modificado, o mejorado sino que se debe de realizar pruebas de tres tipos, para comprobar que no produce efectos no deseados:
Pruebas que englobe el programa en conjunto.
Pruebas a los componentes que serán afectados por los cambios realizados.
Pruebas en los componentes que han sido modificados.
Existen tres procedimientos para el diseño de las pruebas:
Enfoque funcional o de caja negra
, este tipo de pruebas se centran en que mediante unas entrada y se recibe una salida adecuada, solo se centra en los resultados, no en la implementación
Enfoque aleatorio
, este procedimiento realiza las pruebas a partir de modelos obtenidos aleatoriamente, que ponen a prueba la entrada.
Enfoque estructural o de caja blanca
, este tipo de pruebas se centran en la implementación interna propia del programa, se ha de hacer pruebas a cada uno de los diferentes caminos del programa.
Punto de ruptura.(Breakpoint)
Es una funcionalidad, en la que se permite indicar hasta que línea de código, se quiere ejecutar, y a partir de esa línea analizar, el estado de las variables, el camino que se esta siguiendo, si son los correctos o no, se puede indicar varios puntos, continuar la ejecución, parar la ejecución... o ejecutar paso a paso.
Tipos de ejecución.
Existen diferentes tipos de ejecución en el depurador:
Examinadores de variables.
En los examinadores de variables, en conjunto con la ejecución paso a paso en el proceso de depuración, se muestra que valores van tomando las distintas variables, y poder controlar el proceso si con anterioridad los valores de entradas conocidos no devuelve el valor esperado.
Depurador
Herramientas de depuración.
Todo entorno de desarrollo independientemente del lenguaje utilizado para la programación, incorpora una herramienta conocidas como depurador.
En el proceso de programación se pueden producir dos tipo errores:
Errores de compilación
Errores lógicos.
Errores de compilación.
El ; al final de una sentencia.
Referenciado de una variable inexistente.
Variable no inicializada.
Errores lógicos.
Llamados bugs, no impide la ejecución pero muestra resultados erróneos.
Bucles mal inicializados, o con sentencias que nunca se cumplen.
En el caso de los errores de compilación el propio IDE, muestra avisos y/o sugerencias para corregirlos, pero en el caso de los errores lógicos existe el propio depurador, que proporcionará información, para la corrección de los errores.
Se distingue las siguientes funciones de un depurador.
Ejecución paso a paso, ejecuta el código linea a linea.
Ejecución paso a paso por procedimiento, es lo mismo pero en métodos o funciones, que se han depurado con anterioridad, devuelve solo el resultado.
Ejecución hasta una instrucción.
Ejecución del programa hasta el final, sin importar las instrucciones intermedias.
En este proceso de se intenta encontrar errores pero desde el punto de vista de lo requisitos.
En este caso solo existen dos posibles casos:

Que se cumplan los requisitos que se establecieron en la fase análisis.
En caso contrario, que exista una alteración de los mismos e incluso que no se cumplan, en cuyo caso se ha de corregir.
Pruebas de Código.
En el caso del enfoque funcional, existen unas pruebas de código, que son:
Valores límites
, en este caso se centra en realizar pruebas con los valores limites no incluidos en la equivalencias.
Equivalencias
, en este caso se centra en realizar pruebas con los valores, máximo, mínimo e intermedio, dado un intervalo, como valores de entrada de prueba.
Pruebas de Código
En el caso del enfoque estructural, existe la prueba de código:
Cubrimiento, que consiste en evaluar, las funciones, sentencias, condiciones y decisiones, que se ejecutan.
Pruebas de Código.
Las pruebas de código, que se realizan en el enfoque aleatorio, se utiliza generadores automáticos de pruebas.
Normas de Calidad.
Las pruebas que se realizan a los programas desarrollados, tienen que realizarse bajo unas normas de normalización, que estandarice el proceso, las pruebas siguen las siguientes normas :
Normas o Estandares
Estándar BSI.
BS 7925-1, Pruebas de software. Parte 1. Vocabulario.
BS 7925-2, Pruebas de software. Parte 2. Pruebas de los componentes software.
Estándar IEEE.
IEEE estándar 829, Documentación de la prueba de software.
IEEE estándar 1008, Pruebas de unidad
Otros estándares ISO / IEC 12207, 15289
Otros Estándares.
La norma ISO/IEC 29119 de pruebas de software, unifica los estándares anteriormente mencionados en una sola norma.
Además están las pruebas unitarias.
Pruebas Unitarias.
Concepto.
Las pruebas unitarias o pruebas de unidad son aquellas pruebas, que se efectúan en un módulo de código.
Un módulo de código es la parte más pequeña en la que se puede dividir los programas, en general, una función o método.
Requisitos.
Automatizable.
Completa.
Reutilizable.
Independiente.
Profesionales.
Ventajas.
Fomentan el cambio, ante cualquier cambio de código se evita introducir nuevos errores.
Simplifica la integración.
Documenta el código.
Separación de la interfaz y la implementación.
Los errores están mas localizados.
Herramientas para realizar pruebas.
Herramienas para Java
Jtiger.
Framework de pruebas unitarias para Java (1.5).
TestNG.
Esta inspirado en JUnit y NUnit.
Herramientas para otros lenguajes.
CppUnit:
Framework de pruebas unitarias para el lenguaje C++.
Nunit:
Framework de pruebas unitarias para la plataforma .NET.
SimpleTest: Entorno de pruebas para aplicaciones realizadas en PHP.
PHPUnit: framework para realizar pruebas unitarias en PHP.
FoxUnit: framework OpenSource de pruebas unitarias para Microsoft Visual FoxPro
MOQ: Framework para la creación dinámica de objetos simuladores (mocks).
Junit.
JUnit
Framework de pruebas unitarias creado por Erich Gamma y Kent Beck.
Es una herramienta de código abierto.
Multitud de documentación y ejemplos en la web.
Se ha convertido en el estándar de hecho para las pruebas unitarias en Java.
Soportado por la mayoría de los IDE como eclipse o Netbeans.
Es una implementación de la arquitectura xUnit para los frameworks de pruebas unitarias.
Posee una comunidad mucho mayor que el resto de los frameworks de pruebas en Java.
Soporta múltiples tipos de aserciones.
Desde la versión 4 utiliza las anotaciones del JDK 1.5 de Java.
Posibilidad de crear informes en HTML.
Organización de las pruebas en Suites de pruebas.
Es la herramienta de pruebas más extendida para el lenguaje Java.
Los entornos de desarrollo para Java, NetBeans y Eclipse, incorporan un plugin para Junit.
En entornos de desarrollo como NetBeans, JUnit es una herramienta de automatización de pruebas que nos permite elaborar pruebas. Mediante clases de prueba, para cada una de las clases de la aplicación desarrollada, definiendo que métodos son los que se van a someter a prueba.
Plan de Pruebas:
Al principio se desarrollará una planificación general, se inicia el proceso de Análisis del Sistema.
Especificación del diseño de pruebas.
Es la ampliación y detalle del plan de pruebas.
Especificación de un caso de prueba.
Los casos de prueba se concretan a partir de la especificación del diseño de pruebas.
Especificación de procedimiento de prueba.
A partir de un caso de prueba se detalla el modo en que van a ser ejecutados cada uno de los casos de pruebas.
Registro de pruebas.
Se registrarán los sucesos que tengan lugar durante las pruebas.
Informe de incidente de pruebas.
Cada incidente, defecto detectado, solicitud de mejora, etc, dará lugar a un informe de prueba.
Informe sumario de pruebas.
Se resumirá las actividades de prueba vinculadas a uno o más especificaciones de diseño de pruebas.
Ejemplo:
Una función con un intervalo
(0<=valor AND valor=>100);
aplicando particiones equivalentes, se realiza la prueba con {0,50 u otro valor,100} estos valores, se define como clase equivalente.
Ejemplo:
Una función que acepta valores de entrada, tal que el anterior ejemplo, (0<=valor AND valor=>100); aplicando el análisis de valores de límites, se realiza pruebas con valores que no sean representados por la clase equivalente anterior, {-1, 101}
División.
a, b,c,r;
If(b!=0)
c=a/b;
if(b<0)
c=c*-1;
end if
Mostrar c;
If(0!=(a%b))
r=a%b;
Mostar "El resto" r;
end if
then
Mostrar “No se puede dividir por cero”;
end if

Ejemplo:
El ejemplo de cobertura de decisiones según el operador lógico, AND, OR, NOT, entre dos condiciones.
Número es.
a;
If(a > 0)
Mostrar “El número es positivo”;
then
if(a==0)
Mostrar ”El número es cero”;
them
Mostrar ”El número es negativo”;
end if
end if

Ordenar números;
a,b,c;
If (a>b AND a>c AND b>c)
Mostrar a,b,c;
then if(a>b AND a>c AND b<c)
Mostrar a,c,b;
end if
end if
if (b>a AND b>c AND a>c)
Mostrar b,a,c;
then if(b>a AND b>c AND a<c)
Mostrar b,c,a;
end if
end if
if (c>a AND c>b AND a>b)
Mostrar c,a,b;
then if(c>a AND c>b AND a<b)
Mostrar c,b,c;
end if
end if

Sentencia 1;
Sentencia 2;
Sentencia 3;
:
:
if (Condición){
Sentencia 1;
Sentencia 2;
Sentencia 3;
:
:
} else{
Sentencia 1;
:
:
}
do {
Sentencia 1;
Sentencia 2;
Sentencia 3;
:
:
}while (Condición)
While (Condición){
Sentencia 1;
Sentencia 2;
Sentencia 3;
:
:}
Función par;
boolean numpar (int x) {
boolean par = false ;
if ((x%2)==0){
par=true;
} else {
par=false;
}
return par;
}
Se supone una función de entrada recibe números enteros y devuelve, si es par o no mediante un boolean.
Si la función es llamada una sola vez esta cubierta.
El cubrimiento de la función está cubierto para todos los valores enteros.
Para los valores de entrada de números pares se cubre la condición verdadera o true, hasta el retorno de la función,{0,2,4,6,..}.
Para los valores de entrada de números impares se cubre la condición falsa o false, hasta el retorno de la función, {1,3,5,...}
Los casos de prueba son { 0,2, 3, -2, -3}, para los casos de prueba {0,2,-2} se cumple el cubrimiento true son pares, incluido los números negativos, y para los casos {3,-3} se cumple el cubrimiento false, incluido los números negativos impares.
Función valorvalido;
String valorvalido (char x) {
boolean valido ;
if ((A<=x&&x<=Z)!!(a<=x&&x<=z){
valido=true;
} else {
valido=false;
}
return valido;
}

Se supone una función que recibe un carácter de entrada, y devuelve si es válido dentro de un rango .
La equivalencia del carácter de entrada debe de estar en el rango de las mayúsculas y las minúsculas, por debajo, en y por encima, de ambos interválos.
Si para la entrada correcta existe un true y para la incorreta un false
Cada opción tiene una salida.
El rango de prueba es:
A , Z y M. para el primer rango.
a, z y m. para el segundo rango.
Para el mismo ejemplo de equivalencias:
Los valores límites son:
Para el primer rango o equivalencia {A-1} y {Z+1}.
Para el segundo rango o equivalencia {a-1} y {z+1}.
Manuel Manzano López.
Fin de la Presentación.
Full transcript