Desarrollar pruebas en un modelo
En Microsoft Visual Studio Ultimate, puede utilizar modelos arquitectónicos y modelos de requisitos que le ayudarán a organizar las pruebas del sistema y sus componentes.De este modo, tendrá la seguridad de que pone a prueba los requisitos que son importantes para los usuarios y otras partes interesadas y podrá actualizar las pruebas de forma rápida y sencilla cuando cambien los requisitos.Si utiliza Microsoft Test Manager, también puede mantener vínculos entre los modelos y las pruebas.
Pruebas del sistema y subsistema
Las pruebas del sistema , que también se denominan pruebas de aceptación, comprueban si las necesidades de los usuarios se están satisfaciendo.Este tipo de pruebas se ocupan del comportamiento que se observa desde el exterior del sistema, y no de su diseño interno.
Las pruebas del sistema son muy útiles cuando se amplía o rediseña un sistema.Con ellas, resulta más difícil que se produzcan errores al modificar el código.
Si planea cambiar o ampliar un sistema, le resultará útil comenzar con un conjunto de pruebas para ejecutarlas en el sistema existente.Posteriormente, podrá ampliar o ajustar las pruebas para comprobar nuevos requisitos, realizar cambios en el código y ejecutar de nuevo el conjunto completo de pruebas.
Si está desarrollando un sistema nuevo, tan pronto como empiece el trabajo de desarrollo, comience a crear las pruebas.Si define las pruebas antes de desarrollar cada característica, podrá capturar los requisitos mencionados en las conversaciones con mucha precisión.
En las pruebas del subsistema, se aplican los mismos principios a los componentes principales de un sistema.Cada componente se prueba por separado.Las pruebas del subsistema se centran en el comportamiento que puede observarse en la API o las interfaces de usuario del componente.
Para obtener más información acerca de cómo ejecutar pruebas, vea Probar la aplicación.
Derivar pruebas del sistema a partir de un modelo de requisitos
Puede crear y mantener una relación entre las pruebas del sistema y un modelo de requisitos.Para establecer esta relación, escriba pruebas que correspondan a los elementos principales del modelo de requisitos.Visual Studio Ultimate le ayuda a mantener esa relación, permitiéndole crear vínculos entre las pruebas y los elementos del modelo.Para obtener más información sobre los modelos de requisitos, vea Crear modelos de los requisitos de los usuarios.
.gif "Dd409381.collapse_all(es-es,VS.110).gif")
Escribir pruebas para cada caso de uso
Si utiliza Microsoft Test Manager, puede crear un grupo de pruebas para cada uno de los casos de uso que definió en el modelo de requisitos.Por ejemplo, si tiene un caso de uso Pedir un menú, que incluye Crear pedido y Agregar elemento al pedido, puede crear pruebas para los casos de uso generales y los casos de uso más detallados.Para obtener más información sobre los casos de uso, vea Diagramas de casos de uso de UML: Instrucciones.
Las indicaciones que se muestran a continuación pueden servirle de ayuda:
Cada caso de uso debería tener varias pruebas, para las principales rutas de acceso y los resultados excepcionales.
Siempre que describa un caso de uso en el modelo de requisitos, es más importante definir su condición posterior, es decir, el objetivo que se consigue, que describir en detalle los procedimientos que el usuario sigue para lograr el objetivo.Por ejemplo, la condición posterior de Pedir un menú podría ser que un Restaurante prepare una comida para un Cliente y que ese Cliente pague.La condición posterior es el criterio que las pruebas deben comprobar.
Cree pruebas independientes en las distintas cláusulas de la condición posterior.Por ejemplo, cree pruebas diferentes para notificar el pedido al restaurante y para realizar el pago del cliente.Esta separación tiene las ventajas siguientes:
A menudo, los cambios se producen de forma independiente en los distintos aspectos de los requisitos.Al separar de este modo las pruebas en diferentes aspectos, resulta más fácil actualizarlas cuando los requisitos cambian.
Si el plan de desarrollo implementa un aspecto del caso de uso antes que otro, puede habilitar las pruebas individualmente a media que se avanza en el desarrollo.
Cuando diseñe las pruebas, separe la selección de los datos de prueba del código o script que determina si se ha cumplido la condición posterior.Por ejemplo, una prueba de una función aritmética simple podría ser: Escriba 4; compruebe que el resultado es 2.En lugar de esto, diseñe el script del siguiente modo: Elija una entrada; multiplique la salida por sí misma y compruebe que se obtiene la entrada original.Este estilo permite cambiar los datos de entrada de las pruebas sin necesidad de modificar el cuerpo principal de la prueba.
Vincular pruebas a casos de uso
Si está utilizando Test Manager para diseñar y ejecutar las pruebas, puede organizar las pruebas en función de los elementos de trabajo de los requisitos, los casos de uso y los casos de usuario.Puede vincular estos elementos de trabajo a los casos de uso de su modelo.De este modo, podrá seguir paso a paso y con rapidez los cambios de requisitos que afectan a las pruebas y le será más fácil hacer un seguimiento del progreso de cada caso de uso.
Para vincular las pruebas a un caso de uso
En Test Manager, cree un requisito y base en él un conjunto de pruebas.Para obtener información acerca de cómo hacerlo, vea Crear pruebas para elementos de trabajo pendiente de productos, casos de usuario o requisitos.
El requisito que crea es un elemento de trabajo de Team Foundation Server.Puede ser un elemento de trabajo de un caso de usuario, un requisito o un caso de uso, en función de la plantilla de proceso que el proyecto utilice con Team Foundation.Para obtener más información, vea Planear y seguir proyectos.
Vincule el elemento de trabajo del requisito a uno o varios casos de uso del modelo.
En un diagrama de casos de uso, haga clic con el botón secundario del mouse y, a continuación, haga clic en Vincular a elemento de trabajo.Para obtener más información, vea Vincular elementos de modelo con elementos de trabajo.
Agregue al conjunto de pruebas casos de prueba mediante los que se comprueben los casos de uso.
Normalmente, cada elemento de trabajo de un caso de usuario o un requisito estará vinculado a varios casos de uso del modelo y cada caso de uso estará vinculado a varios casos de usuario o requisitos.Esto se debe a que cada caso de usuario o requisito implica un conjunto de tareas que desarrollan varios casos de uso.Por ejemplo, en una iteración inicial del proyecto, podría desarrollar el caso de usuario básico en el que un cliente puede elegir elementos de un catálogo y recibirlos.En una iteración posterior, el caso podría encargarse del pago del usuario al completarse el pedido y del cobro del importe por parte del proveedor tras la entrega de los artículos.Cada caso agrega una cláusula a la condición posterior del caso de uso Pedir artículos.
Para crear vínculos independientes entre los requisitos y las cláusulas de la condición posterior, puede escribir estas cláusulas en comentarios distintos del diagrama de casos de uso.Puede vincular cada comentario a un elemento de trabajo de un requisito y vincular el comentario al caso de uso del diagrama.
Basar las pruebas en los tipos de requisitos
Los tipos, es decir, las clases, interfaces y enumeraciones de un modelo de requisitos describen los conceptos y relaciones en términos de cómo los usuarios conciben y transmiten su negocio.Se excluyen los tipos que tienen que ver exclusivamente con el diseño interno del sistema.
Diseñe las pruebas atendiendo a estos tipos de requisitos.De este modo, tendrá la seguridad de que cuando se discutan cambios en los requisitos, será sencillo relacionar estos cambios con las modificaciones que tengan que hacerse en las pruebas.Esto le permitirá debatir las pruebas y sus resultados deseados directamente con los usuarios finales y otras partes interesadas.Esto significa que las necesidades de los usuarios se pueden preservar con independencia del proceso de desarrollo y evita que se diseñen inadvertidamente pruebas en torno a posibles errores.
En lo que respecta a las pruebas manuales, esta práctica permite ajustarse al vocabulario del modelo de requisitos en los scripts de prueba.En lo que se refiere a las pruebas automatizadas, esta práctica implica el uso de diagramas de clases de requisitos como base del código de pruebas y la creación de descriptores de acceso y funciones de actualización que vinculen el modelo de requisitos con el código.
Por ejemplo, un modelo de requisitos podría incluir los tipos Menú, Elemento del menú y Pedido, así como asociaciones entre estos tipos.En este modelo se representa la información que se almacena en el sistema de administración de pedidos y con la que dicho sistema tiene que trabajar, pero no se representan las complejidades de su implementación.En el sistema activo, podría haber realizaciones diferentes de cada tipo, en bases de datos, interfaces de usuario y API.En un sistema distribuido, podría haber distintas variantes de cada instancia almacenadas al mismo tiempo en diferentes componentes del sistema.
Para realizar pruebas en un caso de uso como Agregar elemento al pedido, el código de un método de prueba podría ser similar al siguiente:
Order order = … ; // set up an order
// Store prior state:
int countBefore = order.MenuItems.Count;
// Perform use case:
MenuItem chosenItem = …; // choose an item
AddItemToOrder (chosenItem, order);
// Verify part of postcondition:
int countAfter = order.MenuItems.Count;
Assert (countAfter == countBefore = 1);
Observe que este método de prueba utiliza las clases del modelo de requisitos.Las asociaciones y atributos se realizan como propiedades de .NET.
Para llevar a cabo esta tarea, las propiedades de las clases deben estar definidas como descriptores de acceso o funciones de solo lectura, que obtienen acceso al sistema para recuperar información sobre su estado actual.Los métodos que simulan casos de uso, como AddItemToOrder, deben dirigir el sistema a través de su API o a través de un nivel inferior a su interfaz de usuario.Los constructores de objetos de prueba, como Order y MenuItem, también deben controlar el sistema para que se creen los elementos correspondientes dentro del sistema.
Muchos de los descriptores de acceso y actualizadores ya estarán disponibles a través de la API normal de la aplicación.Sin embargo, es posible que haya que escribir algunas otras funciones para habilitar las pruebas.Estos descriptores de acceso y actualizadores adicionales se denominan en ocasiones 'instrumentación de pruebas'.Dado que dependen del diseño interno del sistema, es responsabilidad de los desarrolladores del sistema proporcionarlos, puesto que los evaluadores escriben el código de las pruebas atendiendo al modelo de requisitos.
Cuando escriba pruebas automatizadas, puede utilizar pruebas genéricas para encapsular los descriptores de acceso y actualizadores.Para obtener más información, vea Crear una prueba automatizada que ejecuta una aplicación ejecutable mediante pruebas genéricas.
Pruebas para reglas de negocios
Algunos requisitos no tienen una relación directa con ningún caso de uso.Por ejemplo, en el negocio DinnerNow los clientes pueden elegir entre muchos Menús, pero es necesario que en cada Pedido todos los Elementos elegidos provengan de un único Menú.Esta regla de negocio se puede expresar como una regla invariable sobre las asociaciones entre Pedidos, Menús y Elementos en el modelo de clases de requisitos.
Una regla invariable de este tipo no solo rige todos los casos de uso que están definidos actualmente, sino también los casos de uso que se definirán posteriormente.Por consiguiente, conviene escribirla y probarla con independencia de los casos de uso.
Puede escribir una regla de negocio invariable como un comentario en un diagrama de clases.Para obtener más información, vea Diagramas de clases de UML: Instrucciones.
Para vincular las pruebas a una regla de negocio, puede vincular el comentario a un elemento de trabajo de un requisito o caso de usuario, que, a su vez, puede vincular a un conjunto de pruebas de Test Manager.Para obtener más información, vea Adjuntar casos de pruebas a elementos del modelo.
Los requisitos de rendimiento y otros requisitos de calidad del servicio pueden especificarse en los comentarios de los diagramas de casos de uso, actividades o secuencia.También puede vincularlos a los elementos de trabajo de los requisitos y sus conjuntos de pruebas.
Diagramas de secuencia y diagramas de actividades para pruebas
Si los modelos arquitectónicos o de requisitos incluyen diagramas de secuencia o actividades, puede escribir pruebas que se ajusten rigurosamente a los diagramas.
A veces, resulta útil diseñar pruebas que elijan de forma dinámica rutas diferentes a través de las bifurcaciones y bucles del diagrama.
Intente comprobar el estado del sistema después de cada mensaje o acción.Para ello, puede ser necesaria una instrumentación adicional.
Derivar las pruebas del subsistema de los modelos
En el diseño de alto nivel de un sistema grande, se pueden identificar componentes o subsistemas.Se trata de componentes que se pueden diseñar por separado, que están ubicados en equipos distintos o que son módulos reutilizables que pueden combinarse de muchas maneras.Para obtener más información, vea Diagramas de componentes de UML: Instrucciones.
A cada componente principal, se le pueden aplicar los mismos principios que se utilizan en todo el sistema.En un proyecto grande, cada componente puede tener su propio modelo de requisitos.En proyectos más pequeños, se puede crear un modelo arquitectónico o un diseño de alto nivel en el que se muestren los principales componentes y sus interacciones.Para obtener más información, vea Modelar la arquitectura de un sistema de Software.
En cualquier caso, puede establecer una relación entre los elementos del modelo y las pruebas del subsistema tal y como lo haría entre el modelo de requisitos y las pruebas del sistema.
Aislar componentes con interfaces proporcionadas y necesarias
Resulta útil identificar todas las dependencias que un componente tiene en otras partes del sistema o en servicios externos y representarlas como interfaces necesarias.Como resultado de esta práctica, a menudo es necesario rediseñar ciertos elementos que dejan al componente más aislado, lo que hace que sea más fácil separarlo del resto del diseño.
Una ventaja de esta desvinculación es que puede ejecutarse el componente para su comprobación sustituyendo los servicios que normalmente utiliza por objetos ficticios.Se trata de componentes que están configurados a efectos de las pruebas.Un componente ficticio proporciona la interfaz que el componente necesita, donde las consultas se responden con datos simulados.Los componentes ficticios forman parte de un agente de prueba completo que puede conectarse a todas las interfaces del componente.
Una ventaja de las pruebas ficticias es que se puede desarrollar el componente mientras que otros componentes cuyos servicios se van a utilizar están todavía en proceso de desarrollo.
Mantener las relaciones entre las pruebas y el modelo
En un proyecto normal en el que cada pocas semanas se realiza una iteración, se suele llevar a cabo una revisión de los requisitos al comienzo de cada iteración.En la reunión se debaten las características que se van a entregar en la próxima iteración.Se puede utilizar un modelo de requisitos que ayude a debatir los conceptos, escenarios y secuencias de acciones que se desarrollarán.Las partes interesadas en el negocio fijan las prioridades, los desarrolladores hacen las estimaciones y los evaluadores se aseguran de que el comportamiento que se espera de cada característica se está capturando de forma correcta.
Escribir pruebas es el mecanismo más eficaz para definir un requisito y también para tener la seguridad de que una persona tiene una visión clara de lo que se necesita.Sin embargo, mientras que la elaboración de pruebas lleva mucho tiempo durante un taller de especificación, la creación de modelos puede hacerse con mucha más rapidez.
Desde el punto de vista de las pruebas, un modelo de requisitos puede concebirse como una versión abreviada de las pruebas.Por tanto, es importante mantener la relación entre las pruebas y el modelo a lo largo de todo el proyecto.
Adjuntar casos de prueba a elementos del modelo
Si en su proyecto utiliza Test Manager, puede vincular las pruebas a los elementos del modelo.De este modo, podrá encontrar con mayor rapidez las pruebas que se van afectadas por un cambio de requisitos y le será más fácil hacer un seguimiento de hasta qué punto se ha aplicado un requisito.
Puede vincular las pruebas a todos los tipos de elementos.A continuación se muestran algunos ejemplos:
Vincule un caso de uso a las pruebas que lo cotejan.
Escriba las cláusulas de una condición posterior u objetivo de un caso de uso en los comentarios que están vinculados a dicho caso de uso y, a continuación, vincule las pruebas a cada comentario.
Escriba reglas invariables en los comentarios de los diagramas de clases o actividades y vincúlelas a las pruebas.
Vincule las pruebas a un diagrama de actividades o a actividades individuales.
Vincule un conjunto de pruebas al componente o subsistema que comprueba.
Para vincular las pruebas a un elemento o relación del modelo
En Test Manager, cree un requisito y base en él un conjunto de pruebas.Para obtener información acerca de cómo hacerlo, vea Crear pruebas para elementos de trabajo pendiente de productos, casos de usuario o requisitos.
El requisito que crea es un elemento de trabajo de Team Foundation Server.Puede ser un elemento de trabajo de un caso de usuario, un requisito o un caso de uso, en función de la plantilla de proceso que el proyecto utilice con Team Foundation.Para obtener más información, vea Planear y seguir proyectos.
Vincule el elemento de trabajo del requisito a uno o varios elementos del modelo.
En el diagrama de modelado, haga clic con el botón secundario del mouse en un elemento, comentario o relación y, a continuación, haga clic en Vincular a elemento de trabajo.Para obtener más información, vea Vincular elementos de modelo con elementos de trabajo.
Agregue al conjunto de pruebas los casos de prueba que comprueban el requisito expresado en el elemento del modelo.
Vea también
Conceptos
Desarrollar modelos para el diseño de software
Crear modelos de los requisitos de los usuarios