UNIVERSIDAD NACIONAL AGRARIA DE LA SELVA

FACULTAD DE INGENIERIA EN INFORMÁTICA Y SISTEMAS

TEMA: PRUEBAS UNITARIAS

CURSO: CONSTRUCCIÓN DE

INVESTIGADORES:

 SIMON SANTIAGO ALEX

 CARRILLO TOLEDO LUIS FERNANDO
 CHUMBE CORDOVA SALVADOR
 TRINIDAD EVARISTO ADER
 BANDAN VICHARRA IVAN
 CARDENAS PAREDES FRANCO

DOCENTE:

JULCA CELESTINO, Juan

Tingo María – Perú

2018
 I. INTRODUCCIÓN

Cada día que pasa, el software es pieza fundamental en el funcionamiento de

maquinaria, instalaciones, equipamientos, sistemas expertos, financieros y
biomédicos, etc.

 Sistemas software en la actualidad:

 Características: mayor tamaño, importante nivel de seguridad y
bienestar, y complejidad.
 Aspectos clave: calidad del producto, precio competitivo, reducción de
costes, etc.

El plan de pruebas de software se diseña, construye y ejecuta con el objetivo de

seleccionar los componentes que se van a probar, de esta forma se busca validar
y verificar que los requerimientos funcionales y no funcionales de la herramienta
SIAMP se cumplan. Igualmente, el documento de pruebas permite continuar el
proceso de trazabilidad de los documentos para de esta forma dar una correcta
ejecución al proceso de ingeniería de requerimientos. Al ejecutar el plan de
pruebas, es posible recopilar información sobre los posibles errores, defecto o
fallas que se presenten en el prototipo de software, de esa forma es posible aplicar
las correcciones pertinentes al prototipo, buscando asegurar la calidad del mismo
y el correcto cumplimiento de los requerimientos de la aplicación.

El plan de pruebas de software se diseña, construye y ejecuta con el objetivo de

seleccionar los componentes que se van a probar, de esta forma se busca validar
y verificar que los requerimientos funcionales y no funcionales de la herramienta
SIAMP se cumplan. Igualmente, el documento de pruebas permite continuar el
proceso de trazabilidad de los documentos para de esta forma dar una correcta
ejecución al proceso de ingeniería de requerimientos. Al ejecutar el plan de
pruebas, es posible recopilar información sobre los posibles errores, defecto o
fallas que se presenten en el prototipo de software, de esa forma es posible aplicar
las correcciones pertinentes al prototipo, buscando asegurar la calidad del mismo
y el correcto cumplimiento de los requerimientos de la aplicación.

II. OBJETIVOS

El plan de pruebas de software se diseña, construye y ejecuta con el objetivo

de seleccionar los componentes que se van a probar, de esta forma se busca
validar y verificar que los requerimientos funcionales y no funcionales de la
herramienta SIAMP se cumplan. Igualmente, el documento de pruebas permite
continuar el proceso de trazabilidad de los documentos para de esta forma dar
una correcta ejecución al proceso de ingeniería de requerimientos. Al ejecutar
el plan de pruebas, es posible recopilar información sobre los posibles errores,
defecto o fallas que se presenten en el prototipo de software, de esa forma es
posible aplicar las correcciones pertinentes al prototipo, buscando asegurar la
calidad del mismo y el correcto cumplimiento de los requerimientos de la
aplicación.
 III. MARCO TEÓRICO

¿POR QUÉ SON NECESARIAS LAS PRUEBAS?

}ARIANE 5 Vuelo 501 (04/06/1996), primera

prueba de vuelo del sistema de lanzamiento del
Ariane 5. No fue un éxito ya que 37 segundos
después del lanzamiento, la lanzadera explotó
debido a un mal funcionamiento del software de
control.

MOTIVO: fallo software, el módulo de control no

se había probado lo suficiente.

CARACTERISTICAS DE LAS PRUEBAS

 Más importancia y protagonismo día a día.

 Mejoran la calidad del software.

 Mejoran la satisfacción de los requisitos.

 Ahorra tiempo y recursos durante el desarrollo.

 Su objetivo: localizar y subsanar el mayor número de deficiencias lo antes

posible.
COSTE DE LOS DEFECTOS

 Coste de eliminar un defecto se incrementa con el tiempo de permanencia de

dicho defecto.

 La detección de errores en etapas tempranas permite su corrección a menor

coste.

¿Qué aspectos debe contemplar una prueba bien definida?

PROPIEDAD SIGNIFICADO
Identificador Código único de la prueba
Valores de entrada Descripción de los datos de entrada de
un objeto de prueba
Resultados esperados Datos de salida que se espera se
produzcan
Precondiciones Situación previa a la ejecución de la
prueba o características
de un objeto de prueba antes de
ejecutar un caso de prueba
Postcondiciones Características un objeto de prueba
tras la ejecución de la
prueba

Dependencias Relación u orden de dependencia

entre casos de pruebas
Acciones Pasos a llevar a cabo para ejecutar la
prueba

Requisito vinculado Relación de requisitos que se

pretenden validar con la
ejecución de la prueba
LA CALIDAD EN CADA ETAPA DEL CICLO DE DESARROLLO SOFTWARE

CICLO DE VIDA SOFTWARE:

marco de referencia que define el enfoque general del desarrollo

software, indicando los procesos y actividades a realizar desde la definición del

producto

software hasta su finalización de uso; así como los entregables que se van a
generar y entregar

al cliente (ISO 12207).

Pruebas a través del ciclo de vida: Modelo-V

• El modelo-v general es el modelo de desarrollo software más utilizado.

• Desarrollo y pruebas son dos ramas iguales. Cada nivel de desarrollo tiene su
correspondiente

nivel de pruebas.

• Las pruebas (rama derecha) son

diseñadas en paralelo al desarrollo

(rama izquierda).

• Las actividades del proceso de

pruebas tiene lugar a través del ciclo

de vida software completo

Pruebas a través del ciclo de vida: Modelo-V

 • Rama de desarrollo software

 Definición de requisitos

o Documentos de especificación

 Diseño funcional del sistema

o Diseño del flujo funcional del programa

 Diseño técnico del sistema

o Definición de arquitectura/interfaces

 Especificación de los componentes

o Estructura de los componentes

 Programación

o Creación de código ejecutable

PRUEBAS UNITARIAS: Alcance

 Sólo se prueban componentes individuales (clases, funciones, módulos, etc.)

 Cada componente se prueba de forma independiente.

 Descubre errores producidos por defectos internos

 Los casos de prueba podrá ser obtenidos a partir de:

 Código fuente, modelo de datos, Diseño software.
 Se pueden realizar pruebas de caja blanca y de caja negra para probar
los módulos completamente.

 Las pruebas de caja negra (los casos de prueba) se pueden

especificar antes de que programar el modo, no así las
pruebas de caja blanca.

PRUEBASDE INTEGRACIÓN: Alcance

 Las pruebas de integración comprueban la interacción mutua entre

componentes
(subsistemas) software entre sí. Se asumen que los componentes ya han sido
aprobados.

 Tendencia a intentar una integración no incremental:

• Combinar todos los módulos y probar el sistema en su conjunto.
• Resultado previsible: CAOS !!!

 Recomendación: aplicar integración incremental:

 El software se prueba en pequeñas porciones.
 En la detección y resolución de errores es más: Fácil,
controlable y gestionable.

 Los casos de prueba podrá ser obtenidos a partir de:

 Especificación de interfaces, diseño de la arquitectura y
modelo datos

PRUEBAS DE SISTEMA: Alcance

 Consiste en probar (lo más exhaustivamente posible) el software completo para

verificar que:
 Se cumplen los requisitos funcionales establecidos
 Se cumplen aspectos no funcionales de calidad: usabilidad, eficiencia,
portabilidad,
seguridad, etc.

 La calidad software es observada desde el punto de vista del usuario y en

un entorno de pruebas coincidente (en lo posible) con entorno real.

 Los casos de prueba podrá ser obtenidos a partir de:

 Especificaciones funcionales, casos uso, procesos negocio

 Para la generación de casos de prueba se utilizan técnicas

de caja negra

PRUEBAS DE ACEPTACIÓN: Alcance

 Son pruebas para aceptar formalmente el software. Son las pruebas de sistema
del
cliente/usuario.

 Es conveniente haber definido los criterios de aceptación verificables de

manera previa y consensuada.

 Están enfocadas a demostrar que no se cumplen los requisitos,

criterios de aceptación o el contrato.

 El usuario selecciona casos de prueba concretos para sus pruebas de

aceptación, según las prioridades de su negocio.

 Las pruebas se realizarán en el entorno del cliente (real) y se

utiliza técnicas de caja negra.
HERRAMIENTAS DE TESTING: EL SOPORTEPARA AUTOMATIZAR
ACTIVIDADES DE TESTING

• Herramientas de gestión de pruebas

–Bugzilla Testopia
–FitNesse
–qaManager
–qaBook
–RTH (open source)
–Salome-tmf
–Squash TM
–Test Environment Toolkit
–TestLink
–Testitool
–XQual Studio
–Radi-testdir
–Data Generator
• Herramientas para pruebas funcionales
–Selenium-
–Soapui
–Watir (Pruebas de aplicaciones web en Ruby)
–WatiN (Pruebas de aplicaciones web en .Net)
–Capedit
–Canoo WebTest
–Solex
–Imprimatur
–SAMIE
–ITP
–WET
–WebInject
Herramientas Open Source
• Herramientas para pruebas
de carga y rendimiento
–FunkLoad
–FWPTT load testing
–loadUI
–jmeter

52
• Herramientas de calidad
del Producto Software
–PMD
–Check Style
–SONAR-
–.Simian

• Herramientas de gestión de pruebas

–HP Quality Center/ALM
–QA Complete
–qaBook
–T-Plan Professional
–SMARTS
–QAS.Test Case Studio
–PractiTest
–SpiraTest
–TestLog
–ApTest Manager
–Zephyr
• Herramientas para pruebas funcionales
–QuickTest Pro
–Rational Robot
–Sahi
–SoapTest
–Test Complete
–QA Wizard
–Squish
–vTest
–Internet Macros
• Herramientas para pruebas
de carga y rendimiento
–HP LoadRunner
–LoadStorm
–NeoLoad
–WebLOAD Professional
–Forecast
–ANTS – Advanced .NET Testing System
–Webserver Stress Tool
–Load Impact
53
• Herramientas de calidad del
Producto Software
–ChecKing QA
–Kiuwan
–Google CodePro Analytix
–.Simian

• Herramientas Todo en Uno

–Test Studio– Una herramienta para pruebas
de rendimiento, carga, pruebas automáticas,
gestión de pruebas y test exploratorio.
• Herramientas para pruebas
sobre teléfonos móviles
–Testdroid- Herramienta para pruebas
automatizadas para Android
 IV. PROCEDIMIENTO

- MATERIALES:
-Una computadora portátil
-JAVA instalado
-tener conocimientos sobre pruebas de software

-PROCEDIMIENTO:

1. Se abre el programa instalado (JAVA)

2. Creamos una clase
3. Validamos variables

4. A continuación se muestra un ejemplo práctico con test unitarios y de

integración entre dos componentes. Se trata de resolver una
ecuación de primer grado del tipo: ax + b = c, donde a, b y c son
números enteros. Por lo tanto la solución a dicha ecuación es x = (c -
b) / a

En el código "a" lo llamamos parte1, "b" lo llamamos parte2, "+" o "-"

es el operador y "c" es la parte3.

El proyecto tienes 2 clases: EcuacionPrimerGrado con el método que

tiene la fórmula para resolver la ecuación y Parseador, que se
encarga de realizar el parseo de la cadena con la ecuación.

package com.softtek.ecuacion;

/**
* Ecuacion de primer grado
* Solucion: x = (c - b) / a
* es decir: x = (parte3 - parte2)/parte1
*/
public class EcuacionPrimerGrado {

private Parseador parseador = new Parseador();

 public double obtenerResultado(final String ecuacion) {

int parte1 = parseador.obtenerParte1(ecuacion);

int parte2 = parseador.obtenerParte2(ecuacion);
int parte3 = parseador.obtenerParte3(ecuacion);
double resultado = Double.valueOf((parte3 - parte2)) /
Double.valueOf(parte1);
return resultado;
}

El Parseador tiene el siguiente código:

package com.softtek.ecuacion;

public class Parseador {

public int obtenerParte1(final String ecuacion) {

String[] partes1 = obtenerPartes12(ecuacion);

String parte1 = partes1[0].trim();

return Integer.valueOf(parte1.substring(0, parte1.length() - 1));

}

public int obtenerParte2(final String ecuacion) {

String[] partes1 = obtenerPartes12(ecuacion);

String parte2 = partes1[1].trim();

 String operador = obtenerOperador(ecuacion);

if ("-".equals(operador)) {
return Integer.valueOf(parte2) * (-1);
}

return Integer.valueOf(parte2);
}

public String obtenerOperador(final String ecuacion) {

if (ecuacion.indexOf('+') > 0) {
return "+";
} else {
return "-";
}
}

public int obtenerParte3(final String ecuacion) {

String[] partesEcuacion = ecuacion.split("=");
return Integer.valueOf(partesEcuacion[1].trim());
}

private String[] obtenerPartes12(final String ecuacion) {

String[] partesEcuacion = ecuacion.split("=");

String operador = obtenerOperador(ecuacion);

String[] partes1 = partesEcuacion[0].split("\\" + operador);

return partes1;
}
}
A continuación se muestra los tests unitarios del parseador. El SUT es la clase
Parseador y no tiene ninguna dependencia con ningún otro componente.

package com.softtek.ecuacion;

import static org.junit.Assert.assertEquals;

import org.junit.Test;

public class ParseadorTest {

private final Parseador parseador = new Parseador();

@Test
public void obtenerParte1Unidades() {

String ecuacion1 = "2x - 1 = 0";

int resultado = parseador.obtenerParte1(ecuacion1);

assertEquals(2, resultado);
}

@Test
public void obtenerParte2Suma() {

String ecuacion1 = "2x + 1 = 0";

int resultado = parseador.obtenerParte2(ecuacion1);

assertEquals(1, resultado);
}
 @Test
public void obtenerParte3Positivo() {

String ecuacion1 = "2x + 1 = 3";

int resultado = parseador.obtenerParte3(ecuacion1);

assertEquals(3, resultado);
}

@Test
public void obtenerOperadorSuma() {

String ecuacion2 = "2x + 1 = 0";

String operador = parseador.obtenerOperador(ecuacion2);

assertEquals("+", operador);
}
}

El resultado de la ejecución de los tests se visualiza de la siguiente forma con

Eclipse: 
A continuación, se muestra un ejemplo de un test de integración donde se verifica
la interacción del componente EcuacionPrimerGrado y el Parseador. Los test
comprueban que el resultado final de la ecuación es correcto.

package com.softtek.ecuacion;

import static org.junit.Assert.assertEquals;

import org.junit.Test;

public class EcuacionPrimerGradoIntegrationTest {

EcuacionPrimerGrado ecuacion = new EcuacionPrimerGrado();

@Test
public void solucionaEcuacionConMenos() {

Double result = ecuacion.obtenerResultado("2x - 1 = 0");

Double valueExpected = 0.5;

 assertEquals(valueExpected, result);
}

@Test
public void solucionaEcuacionConMas() {

Double result = ecuacion.obtenerResultado("2x + 1 = 0");

Double valueExpected = -0.5;

assertEquals(valueExpected, result);
}

@Test
public void solucionaEcuacionConParte3Mayor0() {

Double result = ecuacion.obtenerResultado("2x + 1 = 10");

Double valueExpected = 4.5;

assertEquals(valueExpected, result);
}

Ahora, si sólamente quisiéramos probar de forma unitaria el

método obtenerResultado de la clase EcuacionPrimerGrado debemos hacer
uso de los “dobles”. Pensad en implementar estos dobles vosotros mismos sin
hacer uso de ningún framework. Seguramente ya estáis pensando en crear una
interfaz para la clase Parseador y crear métodos que permitan hacer la sustitución
por un objeto fake...vamos, que se complica un poco.

Pues para esto podemos hacer uso de Mockito.

Con @InjectMocks establecemos el objeto sobre el cual se realizará la inyección
de los objetos marcados con @Mock, es necesario inicializar estos mocks
con MockitoAnnotations.initMocks(this); en un método de inicialización
con @Before. Para establecer comportamientos del mock Parseador se
utiliza when, antes de realizar la ejecución del test. A continuación podéis ver el
ejemplo:

package com.softtek.ecuacion;

import static org.junit.Assert.assertEquals;

import static org.mockito.Mockito.when;

import org.junit.Before;
import org.junit.Test;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.MockitoAnnotations;

public class EcuacionPrimerGradoMockitoTest {

@InjectMocks
private EcuacionPrimerGrado ecuacionPrimerGrado;

@Mock
private Parseador parseador;

@Before
public void inicializaMocks() {
MockitoAnnotations.initMocks(this);
}

@Test
public void solucionaEcuacionConMenos() {
String ecuacion = "2x - 1 = 0";
 when(parseador.obtenerParte1(ecuacion)).thenReturn(2);
when(parseador.obtenerParte2(ecuacion)).thenReturn(-1);
when(parseador.obtenerParte3(ecuacion)).thenReturn(0);

Double result =
ecuacionPrimerGrado.obtenerResultado(ecuacion);

Double valueExpected = 0.5;

assertEquals(valueExpected, result);
}

@Test
public void solucionaEcuacionConMas() {

String ecuacion = "2x + 1 = 0";

when(parseador.obtenerParte1(ecuacion)).thenReturn(2);
when(parseador.obtenerParte2(ecuacion)).thenReturn(1);
when(parseador.obtenerParte3(ecuacion)).thenReturn(0);

Double result =
ecuacionPrimerGrado.obtenerResultado(ecuacion);

Double valueExpected = -0.5;

assertEquals(valueExpected, result);
}
}
 V. CONCLUCIONES

Las pruebas unitarias tienen un gran beneficio en el desarrollo de aplicaciones por

un lado mejoran la calidad del software, reducen los tiempos de depuración y
evitan muchos errores de programación.
También facilitan la tarea de refactorizar nuestro código, porque se tiene una
mejor manera de comprobar que los métodos que estamos modificando siguen
funcionando tal como se espera que lo hagan.
Si te ha gustado esta entrada y quieres que te avisemos cada vez que se publique
nuevo contenido en el blog, puedes suscribirte a nuestro boletín, y te enviaremos
un mail con los nuevos posts.
Debemos asegurar la calidad de cualquier producto, también si es un producto de
software. No debemos subestimar el plan de pruebas ni escatimar el tiempo que le
dedicamos. Como profesionales debemos ofrecer un software robusto, libre de
errores y que sea mantenible.
Todo el código de este post lo podéis encontrar mi perfil de github, en el
proyecto practicaTesting.

VI. BIBLIOGRAFIA

1. Binder, R., Testing Object-Oriented Systems, American Programmer, 7(4),

22-29, 1994.
2. Clemons RK, Project Estimation with Use Case Points Disponible en
http://www.stsc.hill.af.mil/CrossTalk/2006/02/0602Clemmons.pdf
3. Chidamber, S.R. y Kemerer, C.F., A metrics suite for object-oriented design
,IEEE Trans. Software Engineering, 20(6),
476-493, 1994.
4. Churcher, N.I. and Shepperd, M.J., Towards Conceptual Framework for
Object-Oriented Metrics, ACM Software
16.http://www.javiergarzas.com/calidad-software
17.http://www.javiergarzas.com/2012/03/herramientas-de-calidad-
software.html
18.http://www.javiergarzas.com/herramientas-software-recomendadas
19.http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/388

ANEXOS
PANTALLASO DE EJEMPLO
REALIZADO EN CLASES