Vous êtes sur la page 1sur 16

Construcción

1. Introducción
El punto de partida para el desarrollo del sistema de punto de ventas, es la definición de lo que se
necesita implementar, el planteamiento de un sistema que permita la eficacia de facilitar la
administración de los productos en la empresa y las ventas que genere el establecimiento.

Luego de la correcta selección y análisis de requirentes de un sistema de punto de ventas, el aspecto


más importante es la concepción y desarrollo de un proyecto de diseño de infraestructura que
provea un nivel de seguridad y necesidades acorde con el objetivo de la empresa establecidos. El
sistema de punto de ventas es un programa factible y de sencilla administración susceptible de un
mantenimiento efectivo y uso por los empleados o persona encargada de administrarlo.

El nivel de complejidad aceptado por la infraestructura y los requisitos obtenidos, guarda directa
relación con el tiempo de costos de implementación deseados por la empresa para los distintos
requisitos que se proporcionaron. Este sistema nos permite unificar criterios y clases
implementadas al diseño del sistema, es necesario conocer que es una necesidad de implementar
un sistema de puto de ventas del cual debe ser abordado de la mejor forma más efectiva posible.

1.1 Propósito
El proceso de diseño se inicia a partir de un análisis con el dueño de la empresa definido con los
criterios que se proporcionó al líder del proyecto y al programador, en el cual se establecen los
servicios y espacios físicos en el sistema para el establecimiento del sistema de punto de ventas.
Este programa típicamente indica los servicios y áreas funcionales y las dimensiones deseadas en
acorde con lo que se necesita en la empresa.

Proveerá al negocio la habilidad de computarizar, sistematizar y correlacionar la información de las


ventas. Dado que las cajas registradoras, incluyen aquellas con un complejo sistema de registro,
tienen una capacidad limitada para la colección de datos los sistemas de ventas pueden reunir
guardar y devolver reportes desarrollados sobre las tendencias del inventario y la información de
los clientes.

Adicionalmente los sistemas de punto de venta se integra más fácilmente con numerosas ventas y
pedidos al sistema incluyendo los pedidos via mail u online que se unen con las ventas hechas
personalmente.

1.2 Alcance
El alcance de este sistema de punto de venta es el manejo de inventario, implementando a las ventas
un código de barras para identificar la recepción, el rastreo y la venta de elementos del inventario.

El sistema de punto de venta podrá automatizar mucho del proceso de manejo y monitoreo del
inventario. El sistema de punto de venta también podrá monitorear el costo de los productos
vendidos, el precio de las compras, el precio de las ventas y los márgenes de ganancia, permitiendo
que los usuarios extraer reportes y determinar cuándo hacer un ajuste del precio al cliente.
1.3 Definiciones, Acrónimos y Abreviaturas

Término Definición

Acoplamiento (coupling) Medida del grado en el que un objeto o componente


depende de otro. Bajo acoplamiento minimiza las
dependencias y es una indicación de un buen diseño.
Agregación (aggregation) Relación en la que un objeto se compone o está
construido de uno o más objetos, de modo que la
colección completa representa un todo. Las relaciones de
agregación se especifican entre clases y se reflejan en
instancias de objetos.
Algoritmo (algorithm) Método que describe cómo se resuelve un problema en
término de las acciones que se ejecutan y especifica el
orden en que se ejecutan estas acciones. Los algoritmos
ayudan al programador a planificar un programa antes de
su escritura en un lenguaje de programación.
Ámbito de clase (scope class) Las variables privadas definidas fuera de los métodos
internos a la clase tienen ámbito de clase. Son accesibles
desde todos los métodos del interior de la clase, con
independencia del rden en que están definidas. Los
métodos privados también tiene ámbito de clase.
Análisis (análysis) Proceso de identificación, modelado y descripción de lo
que hace un sistema y de cómo trabaja
Aplicación (application) Programa autónomo Java tal como cualquier programa
escrito utilizando un lenguaje de alto nivel. Las
aplicaciones se pueden ejecutar desde cualquier
computadora con un intérprete Java. Las aplicaciones no
están sometidas a las restricciones impuestas los applets
de java. Una clase aplicación debe contener un método
main. Se utiliza como sinónimo de programa
Argumento (argument) Información pasada a un método. Los argumentos se
suelen llamar también parámetros. Unmétodo que espera
recibir argumentos debe contener una declaración de
argumentos formales por cada argumento actual como
parte de la cabecera del mismo. Cuando se invoca a un
método, los valores de los argumentos actuales 8reales)
se copia en los correspondientes argumentos formales.
Vease parámetro actual (actual parameter).
Array (array, vector, lista) Objeto contenedor que almacena una secuencia indexada
de los mismos tipos de datos. Normalmente los
elementos individuales se referencian por el valor de un
índice. El índice es un valor entero que , suele comenzar,
en 0 para el primer elementos, 1 para el segundo y así
sucesivamente.
Asociación (association) Una relación entre dos clases tales como una instancia de
una clase referencia a una instancia de otra clase.
AWT (ABSTRACT WINDOW Colección de clases (java.awt.*) que se utiliza para
TOOLKIT) implementar interfaces gráficas de usuario. Contiene
componentes tales como botones, etiquetas, campos de
texto, áreas de texto, barras de desplazamiento, cajas de
verificación y menús. Las clases de AWT proporcionan
una interfaz independiente de la plataforma para
desarrollo de programas visuales e interfaces gráficas de
usuario.
Biblioteca de clases (class library) Colección organizada de clases que proporciona un
conjunto de componentes y abstracciones reutilizables.
Bit Dígito binario que puede tomar dos valores posibles: 0 y
1. Los bits son elementos básicos de construcción de
programas y datos.
Bloque (block) Sentencias y declaraciones encerradas entre una pareja
de llaves (apertura y cierre, ´{´ y ´}´. Por ejemplo, un
cuerpo de una clase, es un bloque, al igual que el cuerpo
de un método, Un bloque delimita un nivel de ámbito.
Bolean (bolean, lógico) Tipos primitivos de datos en Java. El tipo bolean puede
tomar sólo dos valores: true (verdadero) y false (falso).
Bytecode (códigos de byte) Resultado de la compilación del código fuente Java. La
JVM (Java Virtual Machine) interpreta los bytecodes con
la finalidad de ejecutar un programa Java. El bytecode es
independiente de la máquina y se puede ejecutar en
cualquier máquina que tenga un entorno de ejecución.
Los bytecodes se almacenan en archivos class
Cabecera de la clase (class header) Cabecera de la definición de la clase. La cabecera
proporciona un nombre a la clase y define sus accesos.
También describe si es una clase ampliada (extends) de
una superclase o implementa interfaces (implements)
Clase (clase) Colección encapsulada de datos y operaciones que
actúan sobre los datos. El concepto de clase es
fundamental en programación orientada a objetos. Una
clase consta demétodos y datos. Los métodos de una
clase definen el conjunto de operaciones permitidas
sobre los datos de una clase (sus atributos). Una clase
puede tener muchas instancia de la clase u objetos.
Clase abstracta (abstract class) Superclase que contiene características comunes
compartidas por las subclases. Se declaran utilizando la
palabra reservada abstract. Las clases abstractas pueden
contener datos y métodos, pero no se pueden instanciar
(crear objetos); es decir, no se pueden crear objetos de
esta clase.
Clase cliente (client class) Clase que hace uso de otra clase.
Clase concreta (concrete class) Una clase diseñada para crear (tener) instancias de
objetos
Clase interna (inner class) Una clase interna es una clase empotrada en otra clase.
Las clases internas permiten definir pequeños objetos
auxiliares y unidades de comportamiento que hacen a los
programas más simples y concisos.
Clase miembro (member class) Término general utilizado para describir una clase
declarada dentro de otra declaración de clases.
Comentario (comment) Trozo de texto que tienen como objetivo documentar el
programa y mostrar cómo se ha construido. Los
comentarios no son sentencias de programación y son
ignorados por el compilador. En Java los comentarios
están precedidos por dos barras (//) en una línea o
encerrados entre /+ y */ en múltiples líneas.
Compilación (compilation) Proceso de traducción de un lenguaje de programación.
Normalmente este proceso implica la traducción de un
lenguaje de programación de alto nivel a lenguaje de
programación de bajo nivel, o el formato binario de un
conjunto de instrucciones específicas. La traducción dse
realiza con un programa denominado compilador. Un
compilador java traduce los programas en bytecodes.
Nombre dado al proceso de traducción del código fuente
a bytecodes
Compilador (compiler) Programa de software que realiza un proceso de
compilación (traducción del lenguaje fuente a lenguaje
máquina) de un programa escrito en un lenguaje de
programación de alto nivel. En el caso de Java, es un
programa que traduce el código fuente Java en bytecode.
El compilador de J2SDK se denomina javac.
Constante (constant) Una variable declarada en final en Java. Una constante
de la clase normalmente está compartida por todos los
objetos de la misma clase; por consiguiente, una
constante de clase se declara normalmente como static.
Una constante local es una constante declarada dentro de
un método.
Constante de la clase (class constant) Variable definida como final y static.
Constructor (constructor) Método especial utilizado para inicializar el estado de un
nuevo objeto. El constructor permite crear objetos
utilizando el operador new. El constructor tiene
exactamente el mismo nombre que la clase que lo
contiene. Los constructores se pueden sobrecargar con el
objetivo de facilitar la construcción de objetos con
diferentes tipos de valores iniciales.
Cuerpo de la clase (class body) Cuerpo de una definición de una clase que agrupa las
definiciones de los miembros de la clase: campos,
métodos y clases anidadas.
Declaración (declaration) Define las variables, métodos yc lasees en un programa.
Depuración (debugging) Proceso de encontrar, fijar y eliminar errores en un
programa. Para estas tareas se suele utilizar una
herramienta de programación conocida como depurador.
Diagrama de clases (class diagram). Una representación gráfica construida utilizando una
notación formal para visualizar y documentar las
relaciones entre clases de un sistema.
Diseño (diseño) Actividad de definir como se debe estructurar e
implementar un programa.
Excepción (exception) Un suceso (evento) no previsto que indica que un
programa ha fallado en alguna forma. Las excepciones se
representan por objetos excepción en java. Las
excepciones se manejan con un bloque de sentencias
try/catch.
Herencia (inheritance) Una relación entre clases en que una subclase se extiende
desde una superclase.
IDE (integrated development) Software para ayudar a lso programadores a escribir
código eficientemente.
Identificador (identifier) Nombre de una variable, método, clase, interfaz o
paquete.
IGU, Interfaz Gráfica de Usuario (GUI, Una interfaz es un programa que se implementa
Graphical User Interface) utilizando componentes AWT tales como cuadros,
botones, etiquetas, campos de texto, etc.
Implementación (implementation) La actividad de escribir, compilar, probar y depurar el
código de un programa.
Instancia (instance) Objeto de una clase
Instanciación (instantiation) Proceso de creación de un objeto de una clase.
Interfaz (interface) Una interfaz se trata como una clase especial de Java.
Cada interface se compila en un archivo independiente
de bytecode, tal como una clase ordinaria. No se puede
crear un instancia de la interfaz. La estructura de una
interfaz Java es similar al de una clase abstracta en la que
se puede tener datos y métodos. Los datos ,sin embargo
,deben ser constantes y los métodos pueden tener sólo
declaraciones sin implementación. En Java existe sólo
herencia simple y una clase puede heredar de una
supereclase. Esta restricción se puede superar por el uso
de una interfaz.
Mensaje (message) Una petición enviada a un objeto que solicita ejecutar
una operación determinada. El mensaje incluye un
nombre y una lista opcional de parámetros.
Método abstracto (abstract method) Método que sólo tiene signatura y no tiene cuerpo, y
debe estar contenido dentro de una clase abstracta. Su
implementación se realiza en la subclase. Se repreenta
mediante el modificador abstract. Los métodos
abstractos deben implementarse en una subclase no
abstracta incluso aunque no se utilicen.
Método de la clase (class method) Sinónimo de método estático. Un método que se puede
invocar sin crear una instancia de la clase. Para definir
métodos de clases, se ha de poner un modificador static
en la declaración del método.
Método de la instancia (Instance method) Un método (o procedimiento) declarado por un clase que
se llama por sus objetos de instancias (o los de las
subclases).
Palabra clave, reservada (keyword) En Java, una palabra clave (o palabra reservada) es una
palabra definida como parte del lenguaje de
programación, Un nombre de palabra reservada no se
puede utilizar para ningún otro propósito.
Palabra reservada, palabra clave (keyword) Palabra definida como parte del lenguaje Java /(vease en
Apéndice A ,la lista de palabras reservadas Java).
Programación controlada por sucesos La programación de gráficos en Java está controlada por
(event-drive programming) sucesos. En programación controlada por sucesos (o
enventos) los códigos se ejecutan por activación de
sucesos, tales como pulsar un botón o mover el ratón
Tipo de datos (data type) Los tipos de datos se utilizan para definir variables. Java
soporta los tipos de datos primitivos y tipos de datos
objeto.
Tipo de datos (data type) Tipo de dato que se utiliza para definir variables. Java
soporta tipos primitivos de datos y tipos de datos objeto.
Variable de clase (class variable) Sinónimo de variable estática.
Variable de instancia (instance variable) Una variable declarada en una clase. Un miembro dato
no estático de una clase. Una copia de un método de una
instancia existe en cada instancia de la clase que se crea.
Variable local (local variable) Variable definida en el interior de una definición de un
método.
Clase Principal (main class) Una clase que contiene un método principal (main).
Método (method) Una colección de sentencias que se agrupan juntos para
ejecutar una operación.
Análisis orientado a objetos OOA Análisis realizado en términos de objetos, clase y
(objetctoriented Analysis) relaciones de clases.
Operador (operator) Operaciones para valores de tipos primitivos de datos.
Ejemplos de operadores son +,-,*,/ y %
Programación orientada a objetos OOP Un enfoque de programación que implica organización
(objectoriented programming) de objetos y su comportamiento en clases de
componentes realizables.
Paquete (package) Colección de clases agrupadas juntas.
Programa (program) Un conjunto de instrucciones (o sentencias) que
describen alguna aplicación o actividad ejecutada en una
computadora.
Programador (progammer) Personas que diseña, escribe, prueba y depura
programas.
Lenguaje de programación (programming Notación utilizada por los programadores para escribir
language) programas . un lenguaje tiene una sintaxis (las palabras y
símbolos utilizadas para escribir códigos de programa),
una gramática (las reglas que definen una secuencia de
palabras y símbolos significativos y correctos) y
semántica. Java es un lenguaje de programación.
Inferencia de software (software Conjunto de etapas en la realización de un programa.
engineering) Estas etapas suelen ser de análisis, diseño
implementación , pruebas, entregas y mantenimiento.
Código fuente (source code) Texto de un programa antes de ser complilado. El texto
se crea y edita utilizando en editor ordinario y contiene
caracteres normales, legibles. El código fuente ser utiliza
para las personas para describir programas y sus
componentes han de ser lo más legibles y comprensibles
posibles.
Sentencia (statement) Una unidad de código que representa una acción o una
secuencia de acciones. Las sentencias se ejecutan en el
orden en que están escritas y siempre terminan en un
punto y coma.
Sintaxis (Syntax) Un conjunto de reglas que especifica la composición de
programas a partir de palabras reservadas, símbolos y
caracteres. La sintaxis define la estructura de los
programas legales en términos de cómo las palabras
reservadas y otros caracteres se pueden escribir y en qué
orden.
Etiqueta (tag) Una instrucción HTML que indica a un
navegador Web como visualizar un documento.
Las etiquetas se encierran entre corchetes tales
como, , , y.
Prueba/ probar (test) En términos de programación, la actividad de
verificación sistemática de que un programa funciona
correctamente.
Prueba (testing) Véase prueba
Unicode (unicode) Un sistema de codificación de caracteres internacionales
gestionados por el consorcio Unicode, Java soporta
Unicode.

2. Descripción general
El sistema de inicio con un punto de venta vasado en notas de remisión, cosa que limito los alcances
del personal en habilidades ya que se debía genera un reporte semanal para controlar ingresos, lo
que implico jornadas más largas, pues cotejar el dinero de la, venta con el reporte es una actividad
que se realiza con cautela y no se tiene la certeza que sea real pues el factor humano puede hacer
vulnerable.
Los nuevos modelos de negocio deben garantizar la buena canalización de recursos para el rápido
crecimiento de las empresas dentro de su mercado estandarizado, los sistemas que se utilizan
capacitando al personal y brindando seguimiento y satisfacción a los clientes finales.

El documento de construcción es describir los requerimientos del programador al realizar el sistema


de punto de ventas. Con los puntos que detallaremos en el documento como:

 Componentes
 El plan de pruebas unitarias
 Reporte de pruebas unitarias
 Justificación de las decisiones de la construcción.

El sistema que se diseñó está basado en facilitar el registro de ventas, además de complementar
algunos otros aspectos que sean importantes para la empresa, por ejemplo, el registro de los
clientes para poder dar crédito incluyendo a los proveedores, la cantidad de ventas que se realizan,
entre otros aspectos que el cliente nos especificó. La programación está diseñada para
complementar otros datos que resulten importantes para la empresa, pudiendo controlar la base
de datos del mismo sistema.

3. Componentes
Componentes necesarios para la construcción del sistema.

1. Interfaz de productos
a. Productos que tengan código de barras y aquellos que carezcan de código de barras.
b. Productos que se venden en diferentes unidades de medida: Por Unidad, Por
Volumen, Por peso.
c. El editor de productos permite agregar productos, eliminar productos, modificar
existentes, así como todos sus parámetros, precios, impuestos, etc.
2. Control de Caja
a. conocer el flujo de caja y el dinero en ella en cada momento.
b. Registrar ventas efectuadas con diferentes métodos de pago:
Efectivo, o crédito.
3. Control de Transacciones Particulares:
a. Devoluciones de dinero
b. Retiros por el Dueño
c. Mermas
d. Retiros por consumo interno
e. Descuentos
4. Control de Stock:
a. Conozca en cada momento el stock de sus productos, saber cuánto es necesario
realizar compras, Evitara posibles pérdidas.
5. Cajeros múltiples
a. Permite la utilización por varios cajeros, y controlar el rendimiento de cada uno por
separado.
6. Multi Usuario
a. Las funciones multiusuario le permitirán tener varios cajeros funcionando en un
mismo local:
b. Llevar un control por separado de sus funciones
c. Tener cajeros con privilegios adicionales, para realizar funciones administrativas
específicas.
d. Usuarios Administradores
7. Registro de Gastos:
a. Pago de Cuentas
b. Sueldos
c. Pago de Servicios y Compras.
8. Ingreso de Facturas:
a. El programa le permitirá ingresar directamente sus facturas, y llevar un listado de
clientes y proveedores.
9. Factura y Boleta Electrónica.
a. podrá imprimir directamente en el software las facturas y boletas autorizadas por
SII.
10. Informes y Estadísticas:
a. Toda la información ingresada en el software quedará almacenada, para su
posterior revisión y análisis, y así poder optimizar costos y procedimientos.
11. Códigos de barras
a. imprimir códigos de barras (u otros métodos de etiquetado) para que pueda
mantener cada uno de sus productos perfectamente etiquetado y rastreable.
12. Base de datos de clientes de búsqueda
a. Búsqueda de un cliente cada vez que llamen a alguien. Adjuntarán la venta al
nombre del cliente.
13. Propiedades personalizadas
a. permiten decidir qué datos se desea que se ingresen sobre sus clientes. Las
propiedades comunes incluyen números de teléfonos, correos o direcciones.

3.1 A implementar
1. Servicio FTP:

FTP(Protocolo de Transferencia de Archivos), es un protocolo de red para la


transferencia de archivos entre sistemas conectados a una red TCP (Tansmission
Control Protocol). Basada en la arquitectura cliente-servidor. Desde un equipo
cliente se puede conectar a un servidor para descargar archivos desde el o para
enviarle archios, independientemente del sistema operativo utilizado en cada
equipo.

2. Servidor FTP:

Un servidor FTP es un programa especial que se ejecuta en un equipo servidor


normalmente conectado a Internet (aunque estar conectado a otros tipos de redes,
LAN, MAN, etcétera). Su función es permitir el intercambio de datos entre
diferentes servidores/ordenadores.
3. Cliente FTP:

Cuando un navegador no esta equipado con la función FTP, o si se quiere cargar


archivos en un ordenador remoto, se necesitara utilizar un programa cliente FTP.

Un cliente FTP es un programa que se instala en el ordenador del usuario, y que


emplea el protocolo FTP. Para conectarse a un servidor FTP y Transferir archivos, ya
sea para descargarlos o para subirlos.

Para el desarrollo y la apropiada aplicación del sistema punto de ventas HERFRAN LUP no es
necesario que se contrate un servicio de FTP, el cual varia los costos ya que estos dependen de las
necesidades de cada usuario, para este caso no se requiere un servidor completo con capacidades
extremas, debido a que el sistema es aplicado en un negocio que se encuentra en crecimiento y que
cuanta con un solo servidor.

3.2 A modificar
1. Escáneres:

Dispositivo encargado de interpretar la información codificada en un código de barras


y transformarla en información que la computadora pueda procesar.

2. Impresora de recibos:

Es uno de los componentes indispensables, el encargado de emitir los


comprobantes de ventas, baucher y reportes como los son corte de caja y más.

3. Interfaz gráfica:

Permite al usuario interactuar visualmente con la computadora y el software en


tiempo real, siguiendo procesos necesarios para completar una venta o introducir
información al sistema.

4. Plan de pruebas unitarias


4.1 Descripción
Este tipo de pruebas son ejecutadas normalmente por el equipo de desarrollo, básicamente
consisten en la ejecución de actividades que le permitan verificar al desarrollador que los
componentes unitarios están codificados bajo condiciones de robustez, esto es, soportando el
ingreso de datos erróneos o inesperados y demostrando así la capacidad de tratar errores de
manera controlada. Adicionalmente, Las pruebas sobre componentes unitarios, suelen
denominarse pruebas de módulos o pruebas de clases, siendo la convención definida por el lenguaje
de programación la que influye en el término a utilizar. Por último, es importante que toda la
funcionalidad de cada componente unitario sea cubierta, por al menos, dos casos de prueba, los
cuales deben centrarse en probar al menos una funcionalidad positiva y una negativa.
Pruebas Unitarias, donde partes individuales del programa u objetos de las clases son probadas.
Estas pruebas se deben enfocar en probar las funcionalidades de objetos o métodos.

Las pruebas fomentan el cambio y la refactorización. Si consideremos que nuestro código es


mejorable podemos cambiarlo sin ningún problema. Si el cambio no estuviera realizado
correctamente las pruebas nos avisarán de ello. Seguramente la frase “si funciona no lo toques” a
más de uno familiar les resultará familiar. Si hubiera pruebas unitarias, no sería necesario
pronunciarla.

4.2 Requerimientos de las pruebas


1. Las pruebas unitarias se tienen que poder ejecutar sin necesidad de intervención manual.
Esta característica posibilita que podamos automatizar su ejecución.
2. Las pruebas unitarias tienen que poder repetirse tantas veces como uno quiera. Por este
motivo, la rapidez de las pruebas tiene un factor clave. Si pasar las pruebas es un proceso
lento no se pasarán de forma habitual, por lo que se perderán los beneficios que éstas nos
ofrecen.
3. Las pruebas unitarias deben poder cubrir casi la totalidad del código de nuestra aplicación.
Una prueba unitaria será tan buena como su cobertura de código. La cobertura de código
marca la cantidad de código de la aplicación que está sometido a una prueba. Por tanto, si
la cobertura es baja, significará que gran parte de nuestro código está sin probar.
4. Las pruebas unitarias tienen que poder ejecutarse independientemente del estado del
entorno.
5. Las pruebas tienen que pasar en cualquier ordenador del equipo de desarrollo.
6. La ejecución de una prueba no puede afectar la ejecución de otra. Después de la ejecución
de una prueba el entorno debería quedar igual que estaba antes de realizar la prueba.
7. Las diferentes relaciones que puedan existir entre módulos deben ser simulada para evitar
dependencias entre módulos.
8. Es importante conocer claramente cuál es el objetivo del test. Cualquier desarrollador
debería poder conocer claramente cuál es el objetivo de la prueba y su funcionamiento.
Esto sólo se consigue si se trata el código de pruebas como el código de la aplicación.
9. Es importante tener en cuenta que, aunque estas son las características de una buena
prueba, no siempre será posible ni necesario cumplir con todas estas reglas y será la
experiencia la que nos guiará en la realización de las mismas.

Se requiere un tester para probar el sistema de manera manual ya que no se cuenta con un sistema
para automatizarlo, además de que al programar el software no se orientó a las pruebas o a objetos
simulados(mocks).

Se utilizará la herramienta de Junit que viene como plugin con Netbeans en el cual se desarrolló el
sistema.
4.3 Estrategia de las pruebas
Las pruebas unitarias o unit testing son una forma de comprobar que un fragmento de código
funciona correctamente. Es un procedimiento más de los que se llevan a cabo dentro de una
metodología ágil de trabajo.

Las pruebas unitarias consisten en aislar una parte del código y comprobar que funciona a la
perfección. Son pequeños tests que validan el comportamiento de un objeto y la lógica.

El unit testing suele realizarse durante la fase de desarrollo de aplicaciones de software o móviles.

Para el desarrollo del punto de ventas se realizaron pruebas unitarias priorizando el login, nuestro
código no fue enfocado a pruebas sin embargo por medio de la herramienta Junit se realizaron las
pruebas.

Las demás pruebas se realizarán de manera manual como se menciona anterior mente donde se
simularán las acciones del usuario, por medio de ellas se detectan la mayor parte de los defectos y
de esta forma se logra estabilizar el sistema que se está probando.
4.3.1 Objetivo
Realizar pruebas unitarias en parte del código del login, como se menciono anterior mente el código
del sistema no fue enfocado a pruebas, se tomó la sección de Usuarios la cual se nos facilito el uso
de la herramienta Junit como dependencia para poder trabajar, nos crea una estructura que debe
de contener 3 partes arrange, act, v assert.

 Arrange (organizar). Es el primer paso de las pruebas unitarias. En esta parte se definen los
requisitos que debe cumplir el código.
 Act (actuar). Es el paso intermedio de las pruebas, el momento de ejecutar el test que dará
lugar a los resultados que deberás analizar.
 Assert (afirmar). En el último paso, es el momento de comprobar si los resultados obtenidos
son los que se esperaban. Si es así, se valida y se sigue adelante. Si no, se corrige el error
hasta que desaparezca.
4.3.2 Técnica
Velicamos la correcta implementación de las unidades internas Conexión e Encriptar, las estructuras
y sus relaciones, al implementar las pruebas de caja blanca hicimos énfasis en la reducción de
errores internos.

Los métodos de caja blanca o estructurales no permitieron derivar casos de prueba que garanticen
que todas las rutas independientes dentro del módulo se ejecuten al menos una vez, ejecuten los
lados verdadero y falso de todas las decisiones lógicas, ejecuten todos los ciclos dentro y en sus
límites operacionales, ejerciten las estructuras de datos internas para asegurar su validez

Algunos ejemplos de técnicas de caja blanca

 Prueba de ruta básica


 Complejidad ciclomática
 Pruebas de estructura de control
 Prueba de condición
 Prueba de flujo de datos
 Prueba de ciclos simples
 Prueba de ciclos anidados

4.3.3 Criterio de terminación


Para llevar a cabo las pruebas verificaremos el comportamiento del programa sobre un conjunto de
casos de prueba. Estos casos de prueba se generarán mediante técnicas y estrategias específicas de
pruebas que nos ayudarán a conseguir la búsqueda de los errores de un programa.
4.3.4 Consideraciones especiales
Al realizar las pruebas no se identificó ningún asuntos internos o externos que pudiese afectan a la
aplicación y ejecución de las pruebas.

4.4 Herramientas
JUnit

Es un conjunto de bibliotecas creadas por Erich Gamma y Kent Beck que son utilizadas en
programación para hacer pruebas unitarias de aplicaciones Java.

Es un conjunto de clases (framework) que permite realizar la ejecución de clases Java de manera
controlada, para poder evaluar si el funcionamiento de cada uno de los métodos de la clase se
comporta como se espera. Es decir, en función de algún valor de entrada se evalúa el valor de
retorno esperado; si la clase cumple con la especificación, entonces JUnit devolverá que el método
de la clase pasó exitosamente la prueba; en caso de que el valor esperado sea diferente al que
regresó el método durante la ejecución, JUnit devolverá un fallo en el método correspondiente.

JUnit es también un medio de controlar las pruebas de regresión, necesarias cuando una parte del
código ha sido modificado y se desea ver que el nuevo código cumple con los requerimientos
anteriores y que no se ha alterado su funcionalidad después de la nueva modificación.

El propio framework incluye formas de ver los resultados (runners) que pueden ser en modo texto,
gráfico (AWT o Swing) o como tarea en Ant.

En la actualidad las herramientas de desarrollo como NetBeans y Eclipse cuentan con plug-ins que
permiten que la generación de las plantillas necesarias para la creación de las pruebas de una clase
Java se realice de manera automática, facilitando al programador enfocarse en la prueba y el
resultado esperado, y dejando a la herramienta la creación de las clases que permiten coordinar las
pruebas.

4.5 Recursos
1. Diseño de las pruebas. Esto es, identificación de la técnica o técnicas de pruebas que se
utilizarán para probar el software. Distintas técnicas de prueba ejercitan diferentes criterios
como guía para realizar las pruebas. Seguidamente veremos algunas de estas técnicas.
2. Generación de los casos de prueba. Los casos de prueba representan los datos que se
utilizarán como entrada para ejecutar el software a probar. Más concretamente los casos
de prueba determinan un conjunto de entradas, condiciones de ejecución y resultados
esperados para un objetivo particular.
3. Cobertura de Sentencias: Se escriben casos de prueba suficientes para que cada
sentencia en el programa se ejecute, al menos, una vez.
4. - Cobertura de Decisión: Se escriben casos de prueba suficientes para que cada decisión en
el programa se ejecute una vez con resultado verdadero y otra con el falso.
5. - Cobertura de Condiciones: Se escriben casos de prueba suficientes para que cada
condición en una decisión tenga una vez resultado verdadero y otro falso.
6. - Cobertura Decisión/Condición: Se escriben casos de prueba suficientes para que cada
condición en una decisión tome todas las posibles salidas, al menos una vez, y cada decisión
tome todas las posibles salidas, al menos una vez.
7. - Cobertura de Condición Múltiple: Se escriben casos de prueba suficientes para que todas
las combinaciones posibles de resultados de cada condición se invoquen al menos una vez.
8. - Cobertura de Caminos: Se escriben casos de prueba suficientes para que se ejecuten todos
los caminos de un programa. Entendiendo camino como una secuencia de sentencias
encadenadas desde la entrada del programa hasta su salida.

4.6 Casos de prueba


4.6.1 Pruebas de Caja Blanca
Las pruebas de caja blanca (también conocidas como pruebas de caja de cristal o pruebas
estructurales) se centran en los detalles procedimentales del software, por lo que su diseño está
fuertemente ligado al código fuente.

4.6.1.1 Number de la clase


Clases del método registro de usuarios e ingreso al sistema

1. Conexion
2. Encriptar
4.6.1.2
<clases diseñadas para la seguridad, tales como métodos de cifrado de contraseñas y conexiones
de la base de datos. >

Método Recibe Regresa Excepción

< no se detectaron
< String >: <cadena de
<String>: < secuencia errores ocasionados
<Conexion> número y letras
ordenada de elementos > durante la ejecución
encriptadas>
>
Método Recibe Regresa Excepción

< no se detectaron
< bytes >: <cadena de
<String>: < secuencia errores ocasionados
<Encriptar> número y letras
ordenada de elementos > durante la ejecución
encriptadas>
>

Método Recibe Regresa Excepción

< byte >: < cifrado de bloque, < no se detectaron


<String>: <
un algoritmo de cifrado que errores ocasionados
<encrypst> secuencia ordenada
opera en bloques de 128 bits durante la ejecución
de elementos >
> >

Método Recibe Regresa Excepción

< no se detectaron
< byte >: < es un entero <String >: <cadena te
errores ocasionados
<descyptt> de 8 bits complemento a texto con la contraseña
durante la ejecución
dos. > desencriptada >
>

5. Reporte de pruebas unitarias


Al verificar el método encriptado no se detectaron problemas, sin embargo, se verifico si los
métodos cumplían con sus funciones al conectarse a la base de datos y al generar las contraseñas
encriptadas del usuario el base de datos.

Para cada tipo de usuario registrado, de determino mediante las pruebas realizadas que las
funciones, datos y transacciones funcionan como se esperaba sin ningún tipo de exención.

6. Justificación de las decisiones de la Construcción


Para poder registrar las pruebas en las clases se utilizó dos de las técnicas más utilizadas en las
pruebas las cuales son, técnica de caja banca y caja negra. Las Pruebas de Caja Negra, es una técnica
de pruebas de software en la cual la funcionalidad se verifica sin tomar en cuenta la estructura
interna de código, detalles de implementación o escenarios de ejecución internos en el software.

En las pruebas de caja negra, nos enfocamos solamente en las entradas y salidas del sistema, sin
preocuparnos en tener conocimiento de la estructura interna del programa de software. Para
obtener el detalle de cuáles deben ser esas entradas y salidas, nos basamos en los requerimientos
de software y especificaciones funcionales.
La técnica de prueba de caja blanca, al contrario de las pruebas de caja negra, consiste en verificar
la estructura interna de un programa.

Ya que el método de pruebas de caja negra, para encontrar todo los errores del programa sería muy
complejo, generando un caso de prueba para cada entrada, el numero de casos de prueba que
tenemos que utilizar seria muy elevado y no seria productivo, llevándonos a un retraso de la entrega
del programa al cliente.

Vous aimerez peut-être aussi