Cristopher Coronel N5A

PRUEBA UNITARIA
Clase con método Suma
Este método, recibe como parámetro dos valores enteros y devuelve la suma ambos.

private int sumar(int a, int b)

{
return (a + b);
}

También se puede hacer desde el menú Prueba → Nueva prueba.

Una vez implementado el método necesitamos probarlo. Para ello creamos nueva
primera prueba unitaria. Si seleccionamos el método Sumar, en el menú contextual
tendremos la opción de
crear una prueba unitaria.

La prueba la podremos crear en un nuevo proyecto de test o en uno ya existente.

Como es nuestra primera prueba, lógicamente, lo incluiremos en un nuevo proyecto
de test. Crearemos al menos un proyecto de Test por cada proyecto que se tenga en
la aplicación, en lugar de crear un único proyecto de test que englobe todas las
pruebas de tu aplicación.
Cristopher Coronel N5A

El nuevo proyecto que se crea es un proyecto normal y corriente. La única

peculiaridad que tiene una referencia de Microsoft.VisualStudio.
QualityTools.UnitTestFramework. Si nos fijamos en el Explorador de soluciones
podremos ver el nuevo proyecto que se ha agregado nuestra solución.

En este paso no se crea la prueba, sólo la estructura de proyectos, clases y métodos.

Es labor de desarrollador, en base a las especificaciones del módulo, el desarrollo de
las pruebas. Es
importante que el desarrollador realice tantas pruebas como sea necesario para cubrir
al máximo la funcionalidad del módulo que se prueba.
El código del método de prueba que tanto la clase como el método son clases y
métodos normales, con la única peculiaridad que el método está decorado con el
atributo TestMethod.

Cuando hemos creado el proyecto de Test, en la solución han aparecido dos nuevos
ficheros:
Sample.vsmdi y LocalTestRun.testrunconfig.
Cristopher Coronel N5A

Si hacemos doble-click sobre el archivo vsmdi podremos acceder al editor de la lista

de pruebas unitarias.

Desde aquí podremos ver, lanzar o depurar todas las pruebas unitarias que contiene
la solución. Y digo que contiene la solución, porque este fichero es común para todos
los proyectos de Test de la solución. Si éste contiene 2 proyectos de Test, desde la
lista de
pruebas unitarias veremos todas las pruebas de los dos proyectos.
El fichero LocalTestRun.testrunconfig lo que nos va a permitir es configurar algunos
aspectos relacionados con la ejecución de las pruebas, como activar el análisis de la
cobertura de código.

Una vez que tenemos la estructura de nuestro método de prueba tendremos que
implementar la prueba. Si pasamos 1 y 2 en los parámetros de entrada el método
sumar nos tiene que devolver 3. Es decir, sabiendo los parámetros de entrada y lo que
hace el método que estamos probando, sabremos lo que tiene que devolver.
El objetivo de la prueba es comprobar que el método Sumar hace exactamente lo que
se espera de él. Si el método Sumar en lugar de 3 devolviese 7, porque se ha
equivocado al sumar, la prueba unitaria fallaría.
Una vez hecha prueba recuerda eliminar la sentencia Assert.Inconclusive . Esta
sentencia se incluye cuando se crea la prueba e indica que el resultado de la prueba
no es concluyente. De
Cristopher Coronel N5A

esta manera se marcan las pruebas que no están implementados.

Una vez, hecha la prueba sólo tenemos que ejecutarla. Desde la ventana de lista de
pruebas podemos ejecutar todas las pruebas o sólo aquellas que seleccionemos. En
la parte inferior, en la
ventana de resultados de la prueba veremos el resultado de la ejecución de los
mismos.

En la prueba podéis ver cómo usando la sentencia Assert.AreEqual se comprueba si

el resultado del método Sumar corresponde con el resultado esperado.
La clase Assert es parte del Framework y que se incluye dentro de la referencia
Microsoft.VisualStudio.QualityTools.UnitTestFramework. Esta clase nos proporciona
algunos métodos para comprobar los resultados de los métodos que están sometidos
a la prueba;
IsFalse, IsNull, AreSame, etc
Parece por tanto, que toda prueba debería terminar con una cláusula de este tipo para
comprobar si la prueba ha sido correcta o no. Pues bien, esto no es así.
Aunque seguramente usaremos alguno de los métodos de la clase Assert en la
mayoría de las situaciones no es de uso obligatorio. Si no usamos esta cláusula, la
ejecución de la prueba dará un resultado correcto siempre y cuando la ejecución de la
misma no genere una excepción.

Por ejemplo, vamos a modificar nuestro método suma para que sólo sume valores
positivos y si alguno de los parámetros que recibe es menor que 0, que devuelva una
excepción.
Cristopher Coronel N5A

En este caso, nos podría interesar hacer una prueba dónde comprobemos que no se
genera una excepción cuando los parámetros sean mayores que 0. En esa prueba no
sería necesario incluir ninguna sentencia de comprobación. Si le pasamos valores
positivos la prueba será correcta siempre y cuando no genera una excepción.
Del mismo modo, nos interesará hacer una prueba para comprobar que la validación
se hace correctamente y que se devuelve la excepción ArgumentException.
.
En este caso, deberemos decorar el método de prueba con el atributo
ExpectedException. Con este atributo estamos especificando que el resultado
esperado de la ejecución de la prueba es la
excepción ArgumentException. Si no se genera la excepción o la excepción no es
del tipo esperado, la prueba fallará.

PRUEBA DE INTEGRACION
Crear la aplicación
$ composer create-project laravel/laravel laravel-example-software-testing
$ cd laravel-example-software-testing
$ php artisan serve

Editar el archivo. env para usar sqlite DB_CONNECTION=sqlite y DB_DATABASE=/full-path-a-la-

base/software-testing-dev.sqlite y crear la base de datos usando sqlite3 /full-path-a-la-
base/software-testing-dev.sqlite.
Cristopher Coronel N5A

Se creará un campo Estudiante con los campos solicitados, para poder almacenar en una base de datos.

$ php artisan make:model -m Estudiante

$ php artisan migrate

Prueba de Integración
Un ejemplo de prueba de integración es usar más de 1 componente, en este caso podemos probar el uso de
la clase Estudiante ya en el contexto de creación desde un controlador. Para lo cual crearemos uno usando
php artisan make:controller --model=Estudiante EstudianteController y comenzaré a probar
la función create. Pero antes de comenzar en el controlador crearé una prueba de integración con php
artisan make:test CrearEstudianteTest. Al realizar un post con datos a /estudiantes que es donde
montamos el recurso en app/routes/web.php el error fallará con error status code 200 es diferente a 201
esperado.

Implemento la función store en el controlador tomando los datos del request y creando un estudiante.

Pero aún nos falta realizar la prueba con un estudiante que quiera registrarse que no sea menor de edad.
Actualizamos el test para enviar una persona adulta y al ejecutar va a funcionar sin problema, debemos
cambiar el test para esperar un resultado 422 entidad no procesable.

PRUEBA DE ACEPTACION
Cristopher Coronel N5A

Los resultados que se muestran en la tabla, son los obtenidos en Venezuela al realizar las pruebas con el
usuario final. Como se puede apreciar en la segunda revisión del módulo pasaporte solo se encontraron 19
señalamientos de 82 realizados en la primera etapa de pruebas, lo que demuestra la utilidad de las pruebas,
el resultado satisfactorio de las mismas así como la calidad lograda.

Como solución se propone una aplicación WEB cliente-servidor, ya que proporciona las siguientes
ventajas:

1. Permitirá centralizar los resultados del proceso de pruebas.

2. Permitirá a los desarrolladores estar sincronizados con los resultados de las pruebas.
3. Agilizará el trabajo de los ingenieros de pruebas.
4. Posibilitará llevar un historial por proyecto de las pruebas realizadas, por el cual se podrá comparar
incluso el estado y desempeño de las pruebas entre diferentes proyectos.

La plataforma para desarrollo será WAMP5 (Windows, Apache, MySQL y PHP5).

En la versión inicial se realizara la aplicación Web de forma tal que se recojan los resultados y las no
conformidades obtenidas luego de aplicar las pruebas, se podrá saber que ingeniero de prueba aplico cada
prueba; los demás ingenieros de pruebas podrán ver los señalamientos hechos por otros, y los miembros de
equipo de desarrollo también podrán hacerlo, esto no sustituye los documentos que se generan,
independientemente de esto se realizaran los documentos que corresponden al proceso, esto puede cambiar
en versiones posteriores, pues se quiere lograr que el sistema genere automáticamente los documentos de no
conformidades, el sumario de evaluación de pruebas y de listas de chequeo, así como las solicitudes de
cambio.

Con la automatización de este proceso se logra la eficacia de una forma más eficiente, es decir, se logran
realizar las pruebas, a los softwares producidos en nuestra universidad, con la mayor calidad posible
empleando menor esfuerzo y tiempo.

PRUEBA DE SISTEMA
 Empresas: Estos son los primeros usuarios a considerar ya que el sistema está enfocado

hacia ellos. La primera parte de estas pruebas se realizó en paralelo con el desarrollo del
Cristopher Coronel N5A

sistema ya que fueron las pruebas de contenido de los cuestionarios. Con estas pruebas se

buscó que cuando las preguntas se integraran al sistema, ya tuvieran un filtro de prueba

anterior.

Posteriormente, para llevar a cabo las pruebas del sistema, se generó un cuestionario

que sirviera como retroalimentación y se acompañó de una descripción general del

proceso y de lo que se esperaba de las pruebas. Las preguntas del cuestionario estaban

enfocadas a pruebas de usabilidad. El cuestionario que se les envió a las empresas, se

encuentra en el Apéndice C.

 Usuarios Comunes: Consideramos importante llevar a cabo pruebas con usuarios

comunes ya que muchas veces los usuarios que realizan las pruebas en las empresas

tienen experiencia anterior con sistemas similares. Esto significa que ya pudieran estar

familiarizados con muchos aspectos del sistema y habría puntos del mismo que no se

considerarían. Las pruebas realizadas por los usuarios comunes son de usabilidad y

funcionalidad, ya que para hacer las evaluaciones de contenido se requiere de

experiencia en el campo.

 Desarrolladores: Las pruebas realizadas por los desarrolladores son pruebas de caja blanca

y de integración, con la finalidad de buscar errores a partir del conocimiento del código

fuente.

Resultados de las Pruebas

Las pruebas del sistema, se llevaron a cabo en el transcurso de dos semanas, al principio de

las cuales, se enviaron correos electrónicos con las instrucciones necesarias para llevar a

cabo las pruebas y con una explicación de las expectativas del proceso.

Una vez transcurrido el tiempo, se recopiló la información obtenida y se realizaron las

gráficas mostradas de la figura 5.2 a la figura 5.9. Cabe destacar que cada una de éstas fue
Cristopher Coronel N5A

evaluada en una escala de 1 a 5 siendo 1 “muy bajo” y 5 “muy alto”. En éstas se

cuantificaron los siguientes atributos del sistema:

Cristopher Coronel N5A

Amigable

Muy Alto 43%

Alto 29%

Muy Alto Alto

Medio Bajo
Muy Bajo

Amigable. Se refiere a la facilidad de interacción del sistema con el usuario sin tener que

consultar un manual o ayuda en línea.

Cristopher Coronel N5A

Legible

Bajo 14%
Muy Alto 43%

Alto 43%

Muy Alto Alto

Medio Bajo
Muy Bajo

Legibilidad. En esta prueba se evalúa el color de los textos, el contraste de los mismos con

el del fondo y el tamaño de la fuente, que debe ser adecuado para su legibilidad por la

mayoría de los usuarios.

Eficiencia. Es cuando las tareas que se llevan a cabo, pueden ser realizadas rápida y

fácilmente. (Ver figura 5.5)

Satisfacción

Medio
14%

Alto Muy Alto

29% 57%

Muy Alto Alto

Medio Bajo
Muy Bajo
Cristopher Coronel N5A

Figura 5.6
Cristopher Coronel N5A

Satisfacción. Es que tan a gusto quedo una persona con las tareas realizadas en el sistema.

(Ver figura 5.6)

Reversible

Bajo Muy Alto

14% 14%

Alto
29%

Medio
43%
Muy Alto Alto
Medio Bajo
Muy Bajo

Figura 5.7

Reversibilidad. Es la capacidad de un sistema para permitir deshacer las acciones

realizadas. (Ver figura 5.7)

Cristopher Coronel N5A

Autonomía

Medio 14%

Muy Alto 57%

Alto
29%

Muy Alto Alto

Medio Bajo
Muy Bajo

Figura 5.8

Autonomía. Se refiere a que los usuarios deben tener el control sobre el sistema en todo

momento. (Ver figura 5.8)

Interfaz Gráfica

Medio 14%
Alto 14%

Muy Alto 72%

Muy Alto Alto

Medio Bajo
Muy Bajo

Figura 5.9
Cristopher Coronel N5A

Interfaz Gráfica. Significa que tan placentero resulta la navegación en

el sistema gracias a la interfaz gráfica. Esto incluye las imágenes,

colores y posición de los elementos que conforman el sistema. (Ver

figura 5.9)

Como resultado de las pruebas solicitadas a las empresas, hubo

retroalimentación a manera de comentarios, pero nadie contestó el

cuestionario de pruebas, por lo que no se pudieron generar gráficas

sobre esto. La relación de las empresas y de su apoyo.

Relación Pruebas Empresa

Nombre de la Empresa Nombre del Contacto Apo Retroalimentaci
yo ón
Avantare Mariana Pérez-Vargas O No hubo respuesta No
BBVA Dina Zoridhy Medina No hubo respuesta No
Ramirez
CIMAT Carlos Montes de Oca V Probó el sistema No
Ddemesis Pedro Gómez Flores No hubo respuesta No
Gedas México Juan Carlos Benítez No hubo respuesta No
Grupo Consultor Rodrigo Bedolla y Cordero No hubo respuesta No
ITIA SA de CV Fernando Sánchez Probó el sistema No
Villalobos
Qualytel Juan Carlos Segovia M No hubo respuesta No
QuarkSoft Karina Cedillo Cázares Probó el sistema No
ServMet Consulting Raúl Méndez Quiroz No hubo respuesta No
Universidad Autónoma de
Baja California José de Jesús Zamarri Probó el sistema No
Validata Luis Gerardo Molina No hubo respuesta No
González
UDLA Verónica Díaz F Probó el sistema No
Cristopher Coronel N5A

PREGUNTAS DE TECNICAS DE PRUEBAS

https://docs.google.com/forms/d/e/1FAIpQLSfvK-CaRcHMJ-
pncOaQe1Sp7u88OGdwpiNaDePxszzDL04d2Q/viewform?usp=sf_link