INSTRUCTIVO PRUEBA DE LA CAJA

BLANCA

Cdigo: DD-I-02
Versin: 01
Vigencia: 2014-1123
Pgina 1 de 6

1. OBJETIVO
Describir el paso a paso para el desarrollo de la prueba de la caja blanca en
software.
2. ALCANCE
Este instructivo aplica para la realizacin de la prueba de caja blanca al software
desarrollado en CAROTECH SAS.
3. DESARROLLO
1. Verificar la correspondencia del diagrama de componentes con el cdigo fuente
del proyecto.
El diagrama de componentes concuerda correctamente con el cdigo implementado.
2. Verificar la correspondencia del diagrama arquitectnico (macro
arquitectnico) con el cdigo fuente del proyecto.
El diagrama de arquitectnico corresponde correctamente con el despliegue propuesto
para la aplicacin.
3. Verificar la correspondencia del diagrama de clases con el cdigo fuente del
proyecto.
El diagrama de clases corresponde correctamente con el cdigo implementado.
4. Verificar la legibilidad del cdigo
La legibilidad del cdigo tiene una valoracin subjetiva, por lo que no se puede afirmar
con certeza si un cdigo es legible o no; sin embargo puede basarse en las maneras ms
frecuentes de codificacin, y las costumbres del grupo de desarrollo.
Aunque la legibilidad no represente un riesgo directo sobre la funcionalidad de un
algoritmo, es muy importante al momento de auditar, modificar y escalar un software.
Las siguientes indicaciones deben ser tomadas como sugerencias, y se deja a discrecin
del desarrollador seguirlas o no.
Archivo PBKDF2.cs:
Se recomienda colocar referencia de donde se extrajo este cdigo para evitar malos
entendidos en las licencias.
Archivo SincronizeHandler.cs:
Se recomienda usar minsculas para la primera letra del nombre de los mtodos de
las clases.
Archivo frmIngreso.cd:

Este documento impreso es una COPIA NO CONTROLADA

INSTRUCTIVO PRUEBA DE LA CAJA

BLANCA

Cdigo: DD-I-02
Versin: 01
Vigencia: 2014-1123
Pgina 2 de 6

Se recomienda usar minsculas para la primera letra del nombre de los mtodos de
las clases.
Se recomienda colocar los mensajes a usuario en variables estticas para facilitar la
traduccin del software posteriormente.
Se recomienda no tener funciones sin contenido.

Archivo frmPrincipal.cs:
Se recomienda declarar los atributos en lneas independientes.
Se recomienda no dejar atributos sin especificar su accesibilidad.
Se recomienda so sobre cargar el mtodo constructor de las clases.
5. Verificar que las funcionalidades estn completas
1. Requerimientos funcionales
5.1.1.Registrar el tanqueo de los vehculos registrados
1. Al presionar el boton de guardado en button memmory la aplicacin se tilda hasta que
se coloque un button memmory, es preferible que tenga un tiempo lmite.
2. El requisito si se cumple.
5.1.2.Guardar el historial de tanqueos en el button-link de cada vehiculo
1. El requisito se cumple pero el mensaje de advertencia por tiempo de espera aparece
antes en todos los caasos.
5.1.3.Sincronizar los datos recolectados con el servidor
1. El requisito si se cumple.
5.1.4.Actualizar la base de datos de vehculos de la pda
1. El requisito si se cumple.
2. Requerimientos no funcionales
5.2.1.Verificar que el buttonlink se encuentre conectado antes de iniciar la
aplicacin.
1. El requisito si se cumple.
5.2.2.Coincidir con la identidad corporativa.
1. Los colores no coinciden con la identidad corporativa de la empresa cliente ni o del
software como tal.
5.2.3.Verificar el estado de almacenamiento del button memmory.
1. El software ni verifica el estado del button memory, sin embargo la aplicacin no se
tilda cuando el este llega a su mxima capacidad.
5.2.4.Atender correctamente con las las reglas bsicas de usabilidad.
5.2.4.1. Pantalla de login
1. El botn de inicio de sesion no es muy explcito.
2. Los nombres estn escritos en ingles.
5.2.4.2. Pantalla principal
1. No existe un boton para cerrar sesin.
2. Aunque los botones represental la accin que realizan son un poco pqueos
dificultando su identificacin a simple vista.
3. La aplicacin no me indique que acciones debo realizar primero antes que las otras.
4. El mensaje campos vacios no me indica que campos estan vacos.

Este documento impreso es una COPIA NO CONTROLADA

INSTRUCTIVO PRUEBA DE LA CAJA

BLANCA

Cdigo: DD-I-02
Versin: 01
Vigencia: 2014-1123
Pgina 3 de 6

5. Es preferible mostrar el nombre del activo, no su id(identificacion de base de datos).

Observaciones
El software en general cumple con los requerimientos funcionales, pero se recomienda
atender a los requerimientos no funcionales colocados en este documento.
3. Verificacin de patrones de diseo
o Para el proceso de sincronizacin de activos y usuarios es preferible usar el
patrn de Fabrica Abstracta (Abstract Factory).
o El preferible usar un filtro para aplicar el paradigma de programacin orientada
a aspectos (POA) para realizar el log en toda la aplicacin (esto es opcional).
o Es preferible aplicar un patrn de singleton a la clase PBKDF2 (creando la
fbrica en otra clase).
o Para el inicio alternativo cuando no est contactado el buttonlink se recomienda
usar El patrn de Fbrica Abstracta (Abstract Facxtory).
o Para el manejo de los hilos se recomienda usar una mquina de estados como
una clase independiente a la principal.

4. Verificar la eficiencia de los algoritmos de las funcionalidades

Se recomienda aplicar los patrones mencionados anteriormente.
5. VERIFICAR ESCALABILIDAD DEL PROYECTO
Se recomienda aplicar los patrones mencionados anteriormente.

6. ANEXOS
Anexar todos los modelos y cualquier tipo de documento anexo necesario para realizar las
pruebas.

Este documento impreso es una COPIA NO CONTROLADA

INSTRUCTIVO PRUEBA DE LA CAJA

BLANCA

Vista Fisica

Este documento impreso es una COPIA NO CONTROLADA

Cdigo: DD-I-02
Versin: 01
Vigencia: 2014-1123
Pgina 4 de 6

INSTRUCTIVO PRUEBA DE LA CAJA

BLANCA

Diagrama de clases

Este documento impreso es una COPIA NO CONTROLADA

Cdigo: DD-I-02
Versin: 01
Vigencia: 2014-1123
Pgina 5 de 6

INSTRUCTIVO PRUEBA DE LA CAJA

BLANCA

Diagrama de componentes

Este documento impreso es una COPIA NO CONTROLADA

Cdigo: DD-I-02
Versin: 01
Vigencia: 2014-1123
Pgina 6 de 6