INSTRUCTIVO PRUEBA DE LA CAJA BLANCACdigo: DD-I-02Versin: 01Vigencia: 2014-11-23Pgina 6 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 cdigoLa 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: 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 completas1. Requerimientos funcionales

5.1.1. Registrar el tanqueo de los vehculos registrados1. 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 vehiculo1. 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 servidor1. El requisito si se cumple.5.1.4. Actualizar la base de datos de vehculos de la pda1. 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 login1. El botn de inicio de sesion no es muy explcito.2. Los nombres estn escritos en ingles.5.2.4.2. Pantalla principal1. 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.5. Es preferible mostrar el nombre del activo, no su id(identificacion de base de datos).

ObservacionesEl 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 Para el proceso de sincronizacin de activos y usuarios es preferible usar el patrn de Fabrica Abstracta (Abstract Factory). 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). Es preferible aplicar un patrn de singleton a la clase PBKDF2 (creando la fbrica en otra clase). Para el inicio alternativo cuando no est contactado el buttonlink se recomienda usar El patrn de Fbrica Abstracta (Abstract Facxtory). 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. ANEXOSAnexar todos los modelos y cualquier tipo de documento anexo necesario para realizar las pruebas.

Vista FisicaDiagrama de clases

Diagrama de componentes

Este documento impreso es una COPIA NO CONTROLADA