Tecnológico Nacional de México.

Instit

utInstituto Tecnológico Superior de la Sierra

Norte de Puebla.

“Creatividad y Tecnología para la excelencia de México.”

Proyecto
“Sistema de Ventas para Abarrotería.”

Alumna:
Alexica Zephir Solís Riveros

Materia: Pruebas de Software.

Catedrático: L.I Ricardo Flores Hernández.

Grupo: A
Semestre: 10°
Enero-junio
Introducción.
El Sistema de Ventas es un programa para llevar un control de la información de
contactos de forma electrónica, en éste se pueden dar de alta los contactos del
usuario, así como su edición o actualización de datos y bajas de éstos, en la
presente prueba se revisa que el programa cumpla con los requisitos expedidos por
el cliente, además de que cada elemento que contiene el software cumpla con lo
que debe hacer, ya sean cajas de texto, botones, etc.

El resultado de esta prueba afecta a las categorías de operación (OPE), de gerencia

(GER) y de alta dirección (DIR).

Si se encuentra alguna falla en el software se regresa a la categoría de operación

(OPE), en el área de desarrollo y mantenimiento de software en donde se harán las
correcciones necesarias para asegurar la calidad total del producto.

Antecedentes y Propósito
Antecedentes
El lenguaje C# está basado en el lenguaje C incorporando muchas más
herramientas nuevas que permiten la programación orientada a objetos, facilitando
la utilización de herramientas más potentes para la mejora del software.

Como está basado en C, los sistemas programados en C# no requieren de una

máquina muy potente.

En anteriores pruebas, se encontraron que en el diseño del sistema se tenían

errores de ortografía. A partir de ahora se debe hacer énfasis en la revisión de
ortografía de cada parte del diseño e impresión de caracteres ya sean letras,
números o especiales.
Propósito de la Evaluación
La “Calidad de un producto” hace referencia a que el producto salga con el más alto
porcentaje de efectividad. La idea principal es hacer un producto con mucha calidad
y esto se realiza teniendo en cuenta la calidad como objetivo a cada momento y
realizando las actividades necesarias para que esto se logre. Este plan de pruebas
es necesario para el aseguramiento de la calidad del sistema. Con este plan se
seleccionan y se coordinan las actividades para asegurar la calidad del software
durante el ciclo de vida del proyecto y aún después al ser entregado al cliente. Los
objetivos que se pretenden alcanzar con la aplicación del plan de pruebas son las
siguientes:

 Encontrar la mayor cantidad de errores como sea posible, ya sea tanto en los
TextBox, como la ortografía que hay en las Labels, los botones, los
ComboBox.

 Supervisar si se cumple las especificaciones de diseño establecidas por el

cliente.

 Supervisar si se cumple los requisitos del análisis que se hicieron en la

planificación del diseño y desarrollo del software.

 Realizar pruebas las pruebas necesarias de rendimiento y capacidad del

sistema.

 Encontrar los problemas importantes y determinar los riesgos percibidos en

cuanto a la calidad del producto.

Motivadores de la prueba
Los principales elementos que crearon la necesidad de realizar este plan de pruebas
se enlistan a continuación:

 Que los botones realizaran las acciones para los que estaban diseñados

 Que los Labels tuvieran una buena ortografía

 Requerimientos funcionales

 Requerimientos no funcionales

 Cambios en los Requerimientos

 Que tenga configurada una buena tabulación.

Objetos a ser Evaluados
Los componentes del software que serán evaluados son los siguientes:

I. TextBox

II. Labels

III. Combobox

IV. Botones

V. DataGridView

Id del Nombre Descripción Fecha de

Objeto Evaluación
txtUser Textbox Este textbox sirve para introducir el 20/04/2018
nombre de usuario en el login.
txtClave Textbox En él se introduce la contraseña la 20/04/2018
cual se almacena en la base de
datos.
Botón Cuando es pulsado verifica en la 20/04/2018
button1 base, si existe el usuario accede a
la aplicación en caso contrario le da
un mensaje de error.
button2 Botón Cuando es pulsado el usuario se 20/04/2018
sale de la aplicación
Id del Objeto Nombre Descripción Fecha de
Evaluación
btnPro Botón Sirve para pasar a la ventana 21/04/2018
de productos donde
podremos ingresar, borrar,
actualizar e incluso consultar
los productos registrados con
anterioridad.
btnProvedores Botón Sirve para pasar a la ventana 21/04/2018
de proveedores donde
podremos ingresar, borrar,
actualizar e incluso consultar
los Proveedores registrados
con anterioridad.
btnUsuarios Botón Sirve para pasar a la ventana 21/04/2018
de Usuarios donde podremos
ingresar, borrar, actualizar e
incluso consultar los Usuarios
registrados con anterioridad.
btnVentas Botón Sirve para pasar a la ventana 21/04/2018
de Ventas donde podremos
ingresar, borrar, actualizar e
incluso consultar las Ventas
registradas con anterioridad.
btnEmpleados Botón Sirve para pasar a la ventana 21/04/2018
de Empleados donde
podremos ingresar, borrar,
actualizar e incluso consultar
los Empleados registrados
con anterioridad.
btnClientes Botón Sirve para pasar a la ventana 21/04/2018
de Clientes donde podremos
ingresar, borrar, actualizar e
incluso consultar los Clientes
registrados con anterioridad.
btnCategoria Botón Sirve para pasar a la ventana 21/04/2018
de Categoria donde podremos
ingresar, borrar, actualizar e
incluso consultar los
Categoria registrados con
anterioridad.
btnCargo Botón Sirve para pasar a la ventana 21/04/2018
de Cargos donde podremos
ingresar, borrar, actualizar e
incluso consultar los Cargos
registrados con anterioridad.
 btnDV Botón Sirve para pasar a la ventana 21/04/2018
de Detalle de Venta donde
podremos ingresar, borrar,
actualizar e incluso consultar
los Detalle de ventas
registrados con anterioridad.

Id del Objeto Nombre Descripción Fecha de

Evaluación
txtIdP Textbox Este textbox sirve para 22/04/2018
introducir el número de Id de
los productos a registrar,
borrar, actualizar o consultar
dentro de la base.
txtNombre Textbox Este textbox sirve para 22/04/2018
introducir el nombre de los
productos a registrar, borrar,
actualizar o consultar dentro
de la base.
txtPrecio Textbox Este textbox sirve para 22/04/2018
introducir el precio del
producto a registrar, borrar,
actualizar o consultar dentro
de la base.
dtpFecha DatePicker Este DatePicker sirve para 22/04/2018
introducir la fecha de los
productos a registrar, borrar,
actualizar o consultar dentro
de la base.
txtExistencia Textbox Este textbox sirve para 22/04/2018
introducir el número de
 existencia que hay de los
productos a registrar, borrar,
actualizar o consultar dentro
de la base.
txtIdCat Textbox Este textbox sirve para 22/04/2018
introducir el número de Id de
las categorías de los
productos a registrar, borrar,
actualizar o consultar dentro
de la base.
dgvProducto DataGridView Este DataGridView sirve para 22/04/2018
mostrar los diferentes
productos que se han
registrado o actualizado
dentro de la base.
Button1 botón Este botón sirve para agregar
los diferentes productos
dentro de la base.
Button2 botón Este botón sirve para borrar
los diferentes productos
dentro de la base.
Button3 botón Este botón sirve para
actualizar los diferentes
productos dentro de la base.
Button4 botón Este botón sirve para
consultar los diferentes
productos dentro de la base.
Button5 botón Este botón sirve para
consultar los diferentes
productos dentro de la base.
Button6 botón Este botón sirve para cerrar la
ventana de productos y abrir el
menú principal otra vez.
 Id del Nombre Descripción Fecha de
Objeto Evaluación
txtIdProv Textbox Este textbox sirve para introducir 23/04/2018
el número de Id de los provedores
a registrar, borrar, actualizar o
consultar dentro de la base.
txtNombre Textbox Este textbox sirve para introducir 23/04/2018
el nombre de los provedores a
registrar, borrar, actualizar o
consultar dentro de la base.
Textbox Este textbox sirve para introducir 23/04/2018
txtIdProd el Id del producto a cargo del
provedorr dentro de la base.
dtpFecha DatePicker Este DatePicker sirve para 23/04/2018
introducir la fecha de entrega de
los productos a registrar, borrar,
actualizar o consultar dentro de la
base.
Button10 botón Este botón sirve para agregar los 23/04/2018
diferentes proveedores dentro de
la base.
Button11 botón Este botón sirve para borrar los 23/04/2018
diferentes proveedores dentro de
la base.
Button12 botón Este botón sirve para actualizar 23/04/2018
los diferentes proveedores dentro
de la base.
Button13 botón Este botón sirve para consultar 23/04/2018
los diferentes proveedores dentro
de la base.
Button14 botón Este botón sirve para consultar 23/04/2018
los diferentes proveedores dentro
de la base.
Button15 botón Este botón sirve para cerrar la 23/04/2018
ventana de proveedores y abrir el
menú principal otra vez.

Id del Objeto Nombre Descripción Fecha de

Evaluación
txtUser Textbox Este textbox sirve para 24/04/2018
introducir el nombre de
usuario dentro de la base.
TxtNombreDeuS Textbox Este textbox sirve para 24/04/2018
introducir el nombre de los
productos a registrar,
borrar, actualizar o
consultar dentro de la base.
TxtUsuario Textbox Este textbox sirve para 24/04/2018
introducir el Usuario a
registrar, borrar, actualizar
o consultar dentro de la
base.
txtNombre Textbox Este textbox sirve para 24/04/2018
introducir el nombre de los
usuarios a registrar, borrar,
actualizar o consultar
dentro de la base.
txtApePatU Textbox Este textbox sirve para 24/04/2018
introducir el apellido
paterno del usuario a
registrar, borrar, actualizar
 o consultar dentro de la
base.
txtApeMatU Textbox Este textbox sirve para 24/04/2018
introducir el apellido
materno del usuario a
registrar, borrar, actualizar
o consultar dentro de la
base.
dgvUsuarios DataGridView Este DataGridView sirve 24/04/2018
para mostrar los diferentes
Usuarios que se han
registrado o actualizado
dentro de la base.
Button1 botón Este botón sirve para 24/04/2018
agregar los diferentes
Usuarios dentro de la base.
Button2 botón Este botón sirve para 24/04/2018
borrar los diferentes
Usuarios dentro de la base.
Button3 botón Este botón sirve para 24/04/2018
actualizar los diferentes
Usuarios dentro de la base.
Button4 botón Este botón sirve para 24/04/2018
consultar los diferentes
Usuarios dentro de la base.
Button5 botón Este botón sirve para 24/04/2018
consultar los diferentes
Usuarios dentro de la base.
Button6 botón Este botón sirve para cerrar 24/04/2018
la ventana de Usuarios y
abrir el menú principal otra
vez.
Id del Objeto Nombre Descripción Fecha de
Evaluación
txtIdV Textbox Este textbox sirve para 25/04/2018
introducir el Id de la venta que
ya se realizó y se registra en la
base
txtP Textbox En él se introduce el Id de 25/04/2018
productos la cual se almacena
en la base de datos.
txtIdE Textbox En él se introduce el Id de 25/04/2018
Empleados la cual se
almacena en la base de datos.
txtIdClienteS Botón Cuando es pulsado el usuario 25/04/2018
se sale de la aplicación
dtpFechaV DatePicker Este DatePicker sirve para 25/04/2018
mostrar los diferentes
Usuarios que se han
registrado o actualizado
dentro de la base.
dgvVenta DataGridView Este DataGridView sirve para 25/04/2018
mostrar los diferentes
Usuarios que se han
registrado o actualizado
dentro de la base.
Button1 botón Este botón sirve para agregar 25/04/2018
los diferentes Usuarios dentro
de la base.
Button2 botón Este botón sirve para borrar 25/04/2018
los diferentes Usuarios dentro
de la base.
 Button3 botón Este botón sirve para 25/04/2018
actualizar los diferentes
Usuarios dentro de la base.
Button4 botón Este botón sirve para 25/04/2018
consultar los diferentes
Usuarios dentro de la base.
Button5 botón Este botón sirve para 25/04/2018
consultar los diferentes
Usuarios dentro de la base.
Button6 botón Este botón sirve para cerrar la 25/04/2018
ventana de Usuarios y abrir el
menú principal otra vez.

Ámbito de las Pruebas

El conjunto de tareas necesarias para conseguir el objetivo del proyecto son el
verificar uno por uno cada uno de los componentes del sistema, se revisarán desde
el primer TextBox hasta el último, también se revisarán las ubicaciones de cada uno
de los componentes; en cuanto a los Labels se refiere se realizará una revisión
exhaustiva con respecto a la ortografía en la redacción al igual que con los
ComboBox y que los botones cumplan con las especificaciones para las cuales
fueron diseñados. No se considera importante la revisión de la forma en que se
muestran los resultados ya que se busco la mejor alternativa para que éstos fueran
presentados al cliente.

Dentro del Ámbito

La estructura de pruebas que está en uso en la iteración actual, se podrá utilizar
para probar la implementación de la solución en su entorno, es decir, las que
prueban que verdaderamente el sistema cumple con lo que se estableció como
elemental o prioritario, es decir, la satisfacción del cliente. Estas pruebas se
describen en la sección Casos de prueba, incluida más adelante. Las características
a ser evaluadas son:

 Revisión de TextBox

 Revisión de Labels (Hacer énfasis en ortografía)

 Revisión de Combobox

 Revisión de Botones

 Revisión de DataGridView
Fuera del Ámbito
 Revisión ortográfica

Ésta quedó excluida de las otras pruebas, porque el cliente hace énfasis en cuanto
a la presentación de su aplicación. Es decir que no tenga nada de fallos, acentuando
la revisión ortográfica.

Lista de Ideas de las Pruebas

Las pruebas serán identificadas siguiendo la técnica de generación de casos de
prueba a través de los casos de uso, detallando los siguientes pasos:

 Para cada caso de uso, se identifican los posibles caminos, estableciendo

los escenarios.

 Para cada uno de los caminos, se identifican los conjuntos de valores de

entrada y precondiciones, al igual que el resultado esperado.

 Se hace, a través de una tabla, un resumen por cada caso de uso que
muestre los distintos caminos posibles con sus entradas y salidas.

Los recursos utilizados para la identificación de las pruebas se mencionan a

continuación:

 El documento de especificación de requerimientos del software.

 El documento de arquitectura de software.

 Generación de pruebas de sistema a partir de la especificación funcional.

 Mejora de la calidad de los requisitos mediante la generación de pruebas.

 Especificación e implementación de casos de prueba.

Enfoque de las Pruebas
Los tipos de pruebas que se realizarán al software son:

 Pruebas de Función

 Pruebas de Interfaces de usuario

 Pruebas de Desempeño

 T-01: Pruebas de Función

Objetivo: El objetivo principal de esta prueba es que el programa

realice las funciones especificadas por el cliente en el
contrato.

Descripción: En esta prueba se probará que cada elemento realice la

función específica para la cual fue diseñado.

Técnicas: Se probará cada uno de los elementos a prueba y error

usando un usuario que no tenga conocimiento absoluto
sobre lo que es el sistema.

Fases: 1.Fase de revisión de cajas de texto

2. Fase de revisión de botones

3. Fase de revisión de ComboBox

4.Fase de revisión de DataGridView

Entorno de Se realizará una prueba que verifique que cada caja de

prueba: texto envíe los datos al lugar que le fue asignado en la Base
de Datos, que cada una de las etiquetas concuerde con la
caja de texto que se le asigno en el diseño, se revisará que
al dar click al botón AddNew inserte el registro
correspondiente en la Base de Datos, al presionar el botón
Edit podamos modificar el registro que tenemos
Objetivo: El objetivo principal de esta prueba es que el programa
realice las funciones especificadas por el cliente en el
contrato.
seleccionado, al oprimir Delete elimine el registro
sellecionado, al dar click en Save nos guarde los cambios,
al presionar Cancel no guarde cambio alguno, y al dar click
en el botón click cierre la aplicación.

Hardware: El programa se puede ejecutar perfectamente en una

computadora que contenga un procesador celeron o
equivalente a 2.6 Ghz y 256 MB en RAM.

Software: En este caso solo se requiere que para la prueba se cuente

con el C# en cualquiera de sus distintas versiones.

Criterios de Éxito: Los botones funcionarán adecuadamente si cada uno

cumple con el propósito establecido en el diseño.
 T-02: Pruebas de Interfaces de usuario

Objetivo: Identificar que la interfaz sea apropiada para que el usuario

la pueda visualizar los datos de salida y meter los datos
correspondientes.

Descripción: Se revisará que haya un equilibrio en el acomodo de los

componentes, una correcta distribución de éstos, que la
interfaz este hecha en base al diseño.

Técnicas: Se comparara uno a uno los elementos de la interfaz contra

los del diseño verificando que efectivamente estén hechos
con base al diseño.

Entorno de Se compararán los componentes de la interfaz contra los

prueba: del diseño, si se encuentra alguna falla se reportará al
departamento correspondiente.

Hardware: El programa se puede ejecutar perfectamente en una

computadora que contenga un procesador celeron o
equivalente a 2.6 Ghz y 256 MB en RAM.

Software: En este caso solo se requiere que para la prueba se cuente

con el C# en cualquiera de sus distintas versiones.

Criterios de Éxito: El criterio de prueba satisfactorio se dará solamente si la

interfaz esta 100% hecha en base a lo que se establece en
el diseño.
 T-03: Pruebas de Interfaces Desempeño

Objetivo: El objetivo de la prueba de desempeño es proporcionar el

rendimiento del sistema, y verificar que éste sea bueno.

Descripción: Esta prueba nos indica si el rendimiento de la aplicación es

el óptimo, para no dejar duda alguna en el cliente a la hora
que éste lo pruebe.

Técnicas: Se revisará el desempeño del sistema en una computadora

con procesador celeron o equivalente a 2.6 Ghz

Entorno de Se realizará dentro de la empresa, en la máquina asignada

prueba: por la alta gerencia, y se comparará el resultado de la
prueba contra el que se da por óptimo.

Hardware: El programa se puede ejecutar perfectamente en una

computadora que contenga un procesador celeron o
equivalente a 2.6 Ghz y 256 MB en RAM.

Software: En este caso solo se requiere que para la prueba se cuente

con el C# en cualquiera de sus distintas versiones.

Criterios de Éxito: Para que se tenga un criterio de éxito debe funcionar la

aplicación perfectamente en la computadora con el
procesador celeron o equivalente a 2.6 Ghz y 256 MB en
RAM.
Herramientas para las Pruebas
Se hicieron una serie exhaustiva de pruebas de software, de soporte y de
productividad que se describen más adelante.

Software

En cuanto al software se requiere se utilizaron una serie de programas usados a

menudo para realizar auditorías que se describen a continuación:
Nombre Descripción

Es un completo sistema de soporte a

GRS (Global Reporting decisiones (DSS), que proporciona
System) visibilidad y control del proceso de
desarrollo de software

JKing QA es una herramienta de análisis

estático, pensada para facilitar y
JKing QA de ALS
automatizar el proceso de adopción de los
estándares de calidad.

Está centrada en los entornos de

IPS Performance Optimizer preproducción, que proporciona la garantía
de Hyperformix del rendimiento de principio a fin de las
aplicaciones.

Es una Suite de productos de Compuware,

para probar aplicaciones bajo condiciones
QACenter de Compuware
de producción pero sin que las máquinas
estén atendidas por los usuarios.

gaKing de ALS es la herramienta de

análisis estático, pensada para facilitar y
gaKing de ALS automatizar el proceso de certificación del
cumplimiento de los estándares de
codificación.

checKing es la una herramienta de

monitorización del proceso de desarrollo
checking de ALS
de software y sus resultados.

TrackRecord se ajusta a cualquier proceso

de desarrollo y pruebas, ofreciendo un
TrackRecord de
sistema de rastreo que ayuda en la
Compuware
identificación y resolución de defectos de
software.

TestPartner es una herramienta que

automatiza las pruebas funcionales y de
TestPartner de Compuware regresión. Ha sido especialmente diseñada
para complejas aplicaciones basadas en
Microsoft, Java y tecnologías Web
 .TEST es una unidad de pruebas
automatizada y productos de análisis de
código estándar, que trabaja sobre clases
.TEST de Parasoft
escritas en la plataforma Microsoft .NET,
sin requerir que los desarrolladores
realicen un solo caso de prueba.

Fortify Security Tester, proporciona las

pruebas de seguridad eficaces a los
equipos de desarrollo y de aseguramiento
Security Tester Fortify de calidad (QA), permitiéndoles verificar la
adecuación a los estándares de seguridad,
y posibles vulnerabilidades en el código de
sus aplicaciones antes de su despliegue.

Es una herramienta de pruebas de carga

que ayuda a los equipos de pruebas,
QALoad desarrolladores y jefes de proyecto a
realizar pruebas de carga efectivas a
aplicaciones distribuidas.

Enterprise Architect provee soporte para

integrar los procedimientos de prueba con
Enterprise Architect
el modelo base.

Herramientas de Soporte y Productividad

Durante las pruebas se utilizaron las siguientes herramientas de supervisión del
sistema:
Nombre Tipo de herramienta Descripción

Lower CASE (L- CASE Son herramientas que

CASE) semiautorizan la generación
de código, crean programas
de detección de errores,
soportan la depuración de
programas y pruebas.

Integrated CASE (I- CASE Herramientas que engloban

CASE) todo el proceso de
desarrollo de software,
desde el análisis hasta la
implementación.

CAST (Computer- Herramientas de soporte a

Aided Software la prueba de software.
Testing)

IPSE (Integrated Herramientas que soportan

Programming todo el ciclo de vida,
Support Enviroment) incluyen componentes para
la gestión de proyectos y
gestión de la configuración.

Winstone de ZDnet Benchmark Herramienta que usa

(playback test) llamadas al sistema durante
actividades específicas de
una aplicación.

Dhrystone Benchmark Mide el rendimiento de una

aplicación.

Whetstone Benchmark Comprueba el rendimiento

de una computadora al
estar ejecutándose una
aplicación.
Lista de ideas de las pruebas
Nuestro proyecto se basó en dos listas de pruebas
El Desarrollo Guiado por Pruebas (o TDD) se suele describir como un ciclo de rojo-
verde-refactor, que se repite continuamente, para ir agregando nuevas
características o arreglar bugs. La siguiente lista de comprobación que comparte
Giorgio Sironi contiene un grupo de preguntas que deberíamos hacernos a nosotros
mismos mientras avanzamos por las fases de TDD, para no olvidarnos de la esencia
de esta técnica.
Rojo
El desarrollo de cualquier característica nueva tiene que empezar con una prueba
que falla.

¿Subiste el código al repositorio remoto o local? Si el código se rompe, es más

fácil revertir los cambios que re-escribir.

¿Ya escribiste código productivo? Si lo hiciste, comentalo o, mejor todavía,

eliminalo para no estar atado implícitamente a un API mientras escribís la prueba.

¿Elegiste la unidad apropiada para expandir? La clase modificada debería ser

una que siga teniendo cohesión luego del cambio, y a menudo se deberían agregar
clase nuevas en vez de acomodar la funcionalidad en las existentes.

¿Falla la prueba? Si no, re-escribirla para exponer la falta de funcionalidad.

¿Una parte de la prueba ya falla? Si es así, elimina el restante de la prueba; el

resto lo podrás agregar en métodos diferentes.

¿El nombre del método de prueba describe su propósito? Asegúrate de no

atarte a detalles de implementación.

¿Los mensajes de fallas son descriptivos sobre el problema? Asegúrate que

describan en dónde está fallando la funcionalidad, destacando la ubicación si se
rompiera en el futuro.

¿Los números y strings mágicos están expresados dentro de

constantes? ¿Hay código repetido? El refactor del código de pruebas es más fácil
cuando se hace tempranamente y mientras aún falla, ya que en este paradigma es
más importante hacer que siga fallando que hacer que pase.
Verde
Se debe escribir el código productivo necesario para que la prueba pase.
¿El código productivo hace pasar a la prueba? (así de simple)

¿Hay un subconjunto del código productivo que hace pasar a la prueba? Si es

así, comentá, o mejor todavía, elimina el código productivo innecesario. Cualquier
otra línea de código que escribas no tendrá cobertura, y serán líneas sin pruebas
que deberemos leer y mantener en el futuro.
Cualquier otra acción específica será llevada a cabo en la fase de Refactor.
Refactor
Mejorar la estructura del código para facilitar los cambios futuros y el mantenimiento.

¿Existe código repetido en la clase actual?

¿El nombre de la clase es el apropiado?

¿Los métodos públicos y protegidos tienen un nombre descriptivo? ¿Son

legibles? El refactor de renombrado es uno de los más poderosos.

¿Hay código repetido en diferentes clases? ¿Existe un concepto de dominio

que está faltando? Podemos extraer hacia clases abstractas o hacer un refactor
de composición. Este alto nivel de refactor también debería aplicarse a las clases
de pruebas unitarias.

--generacion de casos de prueba

Procedimiento de prueba
Registrarse proporcionando todos los datos

GENERACIÓN DE CASOS DE PRUEBA Un caso de prueba especifica qué probar

en el sistema y está formado, además del nombre y una descripción opcional, por
un conjunto de entradas de prueba, de condiciones bajo las que se deben realizar
las pruebas, y de resultados esperados.3 Todo esto es realizado siempre con
determinados objetivos, como puede ser la comprobación de que la parte que está
siendo probada cumpla con los requerimientos para los que fue concebida y los
implemente correctamente, tal como se especifica en los casos de uso. En el caso
de las pruebas de sistema, que pretenden comprobar el funcionamiento de este
como un todo, los objetivos pueden ser otros, en correspondencia con el tipo de
prueba: pruebas de instalación, pruebas de configuración, pruebas negativas, etc.
En esta temática, Ivar Jacobson dió los primeros pasos en la utilización de los casos
de uso directamente en el proceso de prueba, siendo el primero en proponer la
generación de los siguientes casos de prueba:5 1. Casos correspondientes al flujo
básico del caso de uso. 2. Casos correspondientes a flujos alternos. 3. Casos que
surgen de requerimientos específicos para una instancia del caso de uso. 4. Casos
asociados a la prueba de características descritas en documentos asociados al caso
de uso. Más tarde, en el año 2001, Jim Heumann, trabajador de Rational SW
Corporation, publica un artículo en el que describe el proceso para llevar a cabo la
generación de casos de prueba directamente a partir de los casos de uso. Este
proceso está basado en RUP, y tiene tres pasos:2 1. Para cada caso de uso, obtener
el conjunto de todos sus escenarios. 2. Para cada escenario, identificar por lo menos
un caso de prueba y las condiciones bajo las que será ejecutado. 3. Para cada caso
de prueba, identificar los valores de entrada a utilizar en la prueba.

Caso de prueba Suite de pruebas

Resumen Resumen
Diseño de caso de prueba Diseño de suite de pruebas
Revisión formal Revisión formal
Elementos de desarrollo Condición previa
Enlaces de requisitos Condición posterior
Análisis de riesgo Análisis de riesgo
Condición previa Resultados esperados
Condición posterior Casos de prueba
Resultados esperados Registros de ejecución de suite de
pruebas
Scripts de prueba Adjuntos
Registros de ejecución de caso de Variables de ejecución
prueba
Adjuntos
Variables de ejecución

Ah partir de la especificación
ESPECIFICACION DE CASO DE USO

Ilustración 1 Casos de usos del sistema a implementar

LOGIN
FLUJO NORMAL. El usuario escribe sus credenciales (usuarios y contraseña) en
donde se indica en la pantalla del sistema, Al dar clic en el botón aceptar, valida las
credenciales y concede el acceso al sistema.
Flujo Alternativo 1. El usuario escribe incorrectamente sus usuarios y/o contraseña,
el sistema valida las credenciales y al no ser correctas el sistema manda un mensaje
de error con la leyenda "El Usuario y/o Contraseña son incorrectos, Inténtalo
nuevamente." El sistema limpia los cuadros de textos y vuelve a solicitar las
credenciales.

FLUJO ALTERNATIVO 2. El usuario escribe un nombre de usuario que no existe

en la Base de Datos del sistema, El sistema manda un mensaje con la leyenda “El
usuario escrito no existe, Favor de verificar." y nos regresa a la pantalla de solicitud
de credenciales, agregando un botón de nuevo registro por si el usuario aún no está
registrado en el sistema.

FLUJO ALTERNATIVO 3. El usuario ha escrito mal su Contraseña en 5 ocasiones

consecutivas, entonces mandará un mensaje el cual dirá la leyenda "¿Ha olvidado
su contraseña?, ¿desea recuperarla?" si el usuario desea recuperarla, tendrá que
ingresar unos datos para validar su credencial y así recuperar su contraseña.
PRECONDICION. El usuario debe de estar registrado en el sistema previamente
para que pueda tener acceso a la base de datos.

POSCONDICION. Al ser correctamente validadas las credenciales del usuario, da

acceso al sistema y muestra la pantalla principal con todas las opciones a las que
se tiene acceso para el control de la tienda.

Ilustración 2 Caso de Uso del PRODUCTO

 Producto

DESCRIPCIÓN
El Producto tiene 4 tareas a realizar que son:
ALTA: Donde se dará de alta en el sistema todos los productos existentes del
negocio.
BAJA: Donde se podrá eliminar aquellos productos que se desean quitar del
inventario o simplemente quitarlos por diferentes motivos
MODIFICACIONES: Donde se podrá actualizar información acerca de los
productos que se tienen de alta en el sistema
CONSULTA: Se podrá consultar todo lo que se tiene guardado acerca de los
productos con todas sus características.

FLUJO NORMAL: al ingresar a la opción Mercancía se podrá tener acceso a

información de la misma, tal como es su cave, el nombre del producto, marca y
cantidad del mismo y por supuesto el precio y además se podrá implementar,
actualizar o eliminar algún dato.
FLUJO ALTERNATIVO: Al querer modificar cualquiera de los datos no se
encuentren disponibles por falta de actualización o falta de información
PRECONDICION: se deberá tener el control de todos los productos, es decir que
estén dados de alta para hacer las modificaciones que se requieren o solo visualizar
la información para que el usuario tenga la oportunidad de ver que productos le
hacen falta.

POSTCONDICION: Se ingresó correctamente a la opción y se mostró la información

de la mercancía existente.

Ilustración 3 Caso de uso del Empleado

EMPLEADO/TRABAJADORES
DESCRIPCIÓN
El Empleado tiene 4 tareas a realizar que son:

ALTA: Donde se dará de alta en el sistema todos los empleados que trabajan en
el negocio.

BAJA: Donde se podrá eliminar a los empleados que se dieron de baja o que
simplemente ya no trabajan ahí.
MODIFICACIONES: Donde se podrá actualizar la información acerca de los
empleados que se tienen de alta en el sistema

CONSULTA: Se podrá consultar todo acerca de los empleados con todas sus
características.

FLUJO NORMAL: al ingresar a la opción trabajadores se podrá tener acceso a

información de la misma, tal como es su cave, el nombre completo del empleado,
su edad, dirección y el teléfono de igual forma se podrá implementar, actualizar o
eliminar algún dato.

FLUJO ALTERNATIVO: Al querer modificar cualquiera de los datos no se

encuentren disponibles por falta de actualización o falta de información.

PRECONDICION: se deberá ingresar a la opción de empleados para poder checar

la información correspondiente y hacer las modificaciones correspondientes.

POSTCONDICION: Se ingresó correctamente a la opción, el dueño puede hacer

las modificaciones que requiere acerca de su empleado o bien, solo hizo la consulta
para saber algo en específico.

Ilustración 4 Caso de uso de Ventas

VENTAS

DESCRIPCIÓN
Las Ventas tiene 4 tareas a realizar que son:

ALTA: Donde se dará de alta las ventas que se realizaran en ese momento.

BAJA: Donde se podrá eliminar dichas ventas por cancelación o situaciones

similares.

MODIFICACIONES: Donde se podrá actualizar información acerca de la venta en

ese momento

CONSULTA: Se podrá consultar las ventas realizadas en el sistema.

FLUJO NORMAL: al ingresar a la opción Ventas se podrá tener acceso a

información de todas las ventas que se realizaron.

FLUJO ALTERNATIVO: Al querer modificar cualquiera de los datos no se

encuentren disponibles por falta de actualización o falta de información.

PRECONDICION: se deberá ingresar a la opción de Ventas para poder checar la

información correspondiente y hacer las modificaciones correspondientes.

POSTCONDICION: Se ingresó correctamente a la opción, el dueño puede hacer

las modificaciones que requiere acerca de su empleado o bien, solo hizo la consulta
para saber algo en específico.
Diagrama de actividades

---cada caso de uso

---para los caminos de entrada precondiciones y resultados esperados
RESULTADOS
Tabla Empleados

Tabla Tienda

Tabla sucursal

Tabla Proveedor
Tabla Pedidos

Tabla Mercancía

Concatenación
Proyección

Selección
---tabla donde se colocan casos de usos---actores interactuan con el sistema
genera una entrada y una salida
---Recursos utilizados para la identificación de las pruebas
(Por ahora no es muy importante, se podrá implementar más adelante para una
mejor seguridad),
Mediante un login será posible restringir la entrada al sistema de la base de datos.
Caso de uso Login (INICIO)
Actores Administrador/dueño, empleado
El administrado y empleado podrán
entrar al sistema para gestionar las
Descripción funciones que se desean hacer.

Caso de uso Empleado/Trabajadores

Actores Administrador/dueño, empleado
El administrador podrá entrar a esta
opción para modificar datos de su
Descripción personal

Caso de uso Producto

Actores Administrador/dueño, empleado
El administrador y empleado podrá
entrar a la opción de mercancía para
agregar la mercancía que haga falta o
Descripción regresar la que no se venda

Caso de uso Tipo

Actores Dueño/ empleado
El Dueño/ empleado se dirigirá a la
opción tipo para saber a qué categoría
Descripción pertenecen los productos
Caso de uso Ventas
Actores Administrador/Cliente
El administrador se encargará de la
venta para dar altas, bajas y
Descripción modificaciones en la base de datos.
 Caso de uso Detalle de Venta
Actores Dueño/ empleado
El Dueño/ empleado podrá realizar el
Descripción ticket de la venta
Definir el Enfoque de Pruebas

Propósito

 Para identificar cada técnica especifica que será empleada para permitir la prueba
deseada.
 Para resumir el trabajo de cada técnica incluyendo los tipos de prueba que
soportan.
 Para definir una arquitectura candidata para el sistema de automatización de
pruebas.

Rol: Diseñador de pruebas.

Frecuencia: Esta actividad es típicamente conducida múltiples veces por

iteración.

Pasos

 Examinar los motivadores de prueba y los elementos de prueba objetivo.

 Examinar la arquitectura de software.
 Considerar la apropiada amplitud y profundidad del enfoque de pruebas.
 Identificar técnicas de prueba existentes para rehusó.
 Identificar técnicas adicionales.
 Definir técnicas.
 Resumir la arquitectura de automatización de pruebas.
 Definir la estrategia de administración de la configuración de activos de pruebas.
 Contemplar la disponibilidad de activos reusables (assets).
 Capturar las conclusiones
 Evaluar y verificar los resultados
Artefactos de entrada.

 Modelo de despliegue.
 Plan de iteración.
 Directrices Específicas de Proyecto.
 Documento de Arquitectura de Software.
 Plan de Desarrollo de Software.
 Especificación de Requerimientos de Software.
 Arquitectura de Automatización de Pruebas.
 Configuración del Ambiente de Pruebas.
 Plan de Pruebas.
 Modelo de Casos de Uso.
 Visión.

---software de pruebas para el sistema nombre y para que se ocupo

¿Qué es una estrategia de RBT ?
El deseo de implantar en producción el software de forma rápida y con recursos
limitados crea la necesidad de establecer algún criterio de actuación cuando los
tiempos y recursos no son suficientes. El testing , como tal, tiene el objetivo de
reducir al mínimo la probabilidad de que un producto defectuoso llegue a los usuarios
finales.

Muchas veces el tiempo y la cantidad de recursos disponibles para las pruebas de un

producto son mucho menores que las estimaciones de planificación y esfuerzo
correspondientes. Algunas veces puede deberse a que el equipo de desarrollo entregue
la versión final del software fuera de plazo y el equipo de testing no consiga
replanificar el calendario de pruebas. Otras veces es la escasez en el número de
testers con el conocimiento funcional y habilidades técnicas deseadas para cumplir
con la planificación. Con independencia de las causas de la demora, el Test
Manager a menudo se enfrenta a la tarea de decidir qué probar antes de que el equipo
se quede sin el tiempo o el dinero asignado para la prueba. Cuando nos enfrentamos
a situaciones como éstas, un Test Manager a menudo tiene que tomar decisiones
desagradables. Puede haber una serie de factores en los que se pueden basar estas
decisiones. Sin embargo, una de las mejores maneras de manejar esta situación es
realizar RBT (Risk-based testing).

¿Qué son las Pruebas basadas en el riesgo (RBT)?… si entendemos que un riesgo
es un evento con un resultado potencialmente negativo que pueden ocurrir en
cualquier momento en el futuro, la ocurrencia (o no ocurrencia) de un riesgo no puede
garantizarse de antemano. Cuando se prueba un producto con un número limitado de
testers en una pequeña cantidad de tiempo, tenemos que reducir la cantidad de pruebas
que se pueden realizar.

Aquí es donde el concepto de RBT entra en juego: las pruebas basadas en el

riesgoimplican la comprensión de los riesgos asociados al lanzamiento de un producto
sin realizar pruebas exhaustivas en él. Puede haber algunas de las características de
una aplicación que son más susceptibles de ser utilizados por los usuarios finales en
comparación con otras características que se pueden usar en raras ocasiones. Por
ejemplo, en una aplicación de banca el modulo de apertura de cuentas es probable que
se utilice con mucha más frecuencia en comparación con otros módulos. Esta
información se utiliza en RBT con el fin de dar prioridad a la planificación de las
pruebas y determinar qué se puede probar dentro de la limitada cantidad de tiempo /
recursos disponibles para las pruebas.
Las premisas básicas para aplicar el RBT son:

1. Identificar posibles riesgos que pueden ocurrir si los módulos / funciones de una
aplicación no se prueban a fondo (o completamente).

2. Determinar el probable impacto de cada riesgo, así como la probabilidad de su

ocurrencia. ¿Qué ocurrirá si se produce el riesgo? ¿En cuánta pérdida monetaria (o de
otro tipo) se incurrirá, y cuál es la probabilidad de que ocurra? Asignar valores entre
0 y 1 para la probabilidad relativa de ocurrencia y de 0 a 3 para el impacto probable
de cada riesgo identificado. Asignar valores superiores a los riesgos con mayor
probabilidad de ocurrencia e impactos probablemente más altos, y los valores
comparativamente inferiores a los demás.

3. Multiplicar los valores de probabilidad relativa de ocurrencia y posible impacto

para cada riesgo identificado, con el fin de llegar a un valor numérico único para cada
uno de ellos.

4. Afrontar las actividades de pruebas que eliminen los riesgos con los más altos
valores numéricos (según lo calculado en el paso 3) en primer lugar. Actividades de
prueba posteriores deben ser dirigidas a la prevención de los riesgos con los siguientes
valores numéricos en forma decreciente.

La conclusión de todo esto es que siguiendo este enfoque, un Test Manager puede
garantizar que se realicen pruebas más eficaces con recursos y tiempo
limitados.