Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Puede usar los requisitos y los modelos arquitectónicos para ayudarle a organizar las pruebas del sistema y sus componentes. Esta práctica ayuda a asegurarse de probar los requisitos que son importantes para los usuarios y otras partes interesadas, y le ayuda a actualizar las pruebas rápidamente cuando cambian los requisitos. Si usa Microsoft Test Manager, también puede mantener vínculos entre los modelos y las pruebas.
Para ver qué versiones de Visual Studio admiten estas características, consulte Compatibilidad de versiones con herramientas de arquitectura y modelado.
Pruebas del sistema y del subsistema
Las pruebas del sistema, también conocidas como pruebas de aceptación, significan probar si se cumplen las necesidades de los usuarios. Estas pruebas se preocupan por el comportamiento visible externamente del sistema en lugar del diseño interno.
Las pruebas del sistema son muy valiosas al extender o rediseñar un sistema. Ayudan a evitar introducir errores al cambiar el código.
Al planear cualquier cambio o extensión en un sistema, resulta útil empezar con un conjunto de pruebas del sistema que se ejecutan en el sistema existente. A continuación, puede ampliar o ajustar las pruebas para probar los nuevos requisitos, realizar los cambios en el código y volver a ejecutar el conjunto completo de pruebas.
Al desarrollar un nuevo sistema, puede empezar a crear pruebas tan pronto como comience el desarrollo. Al definir pruebas antes de desarrollar cada característica, puede capturar los debates de requisitos de una manera muy específica.
Las pruebas del subsistema aplican los mismos principios a los componentes principales de un sistema. Cada componente se prueba por separado de otros componentes. Las pruebas del subsistema se centran en el comportamiento visible en las interfaces de usuario o la API del componente.
Derivar pruebas del sistema 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, se escriben pruebas que corresponden a los elementos principales del modelo de requisitos. Visual Studio le ayuda a mantener esa relación al permitirle crear vínculos entre las pruebas y las partes del modelo. Para obtener más información sobre los modelos de requisitos, consulte Requisitos de usuario del modelo.
Escribir pruebas para cada caso de uso
Si usa Microsoft Test Manager, puede crear un grupo de pruebas para cada caso de uso que haya definido en el modelo de requisitos. Por ejemplo, si tiene un caso de uso Pedir una comida, que incluye Crear pedido y Añadir artículo al pedido, puede crear pruebas tanto para estos casos de uso en general como para sus detalles más específicos.
Estas directrices pueden ser útiles:
Cada caso de uso debe tener varias pruebas, para las rutas de acceso principales y resultados excepcionales.
Al describir un caso de uso en el modelo de requisitos, es más importante definir su condición posterior, es decir, el objetivo que se logra, que describir en detalle los procedimientos que sigue el usuario para lograr el objetivo. Por ejemplo, la condición posterior al pedido de una comida podría ser que un restaurante está preparando una comida para un Cliente y que el Cliente ha pagado. La poscondición es el criterio que las pruebas deben verificar.
Base las pruebas independientes en las cláusulas separadas de la poscondición. Por ejemplo, cree pruebas independientes para notificar al restaurante del pedido y para tomar el pago del cliente. Esta separación tiene estas ventajas:
Los cambios en distintos aspectos de los requisitos se producen con frecuencia de forma independiente. Al separar las pruebas en diferentes aspectos de esta manera, facilita la actualización de las pruebas cuando cambian los requisitos.
Si el plan de desarrollo implementa un aspecto del caso de uso antes de otro, puede habilitar las pruebas por separado a medida que avanza el desarrollo.
Al diseñar las pruebas, separe la elección de datos de prueba del código o script que determina si se ha logrado la condición posterior. Por ejemplo, una prueba de una función aritmética simple podría ser: Entrada 4; compruebe que la salida es 2. En su lugar, diseñe el script como: Elija una entrada; multiplique la salida por sí misma y compruebe que el resultado es la entrada original. Este estilo le permite variar las entradas de prueba sin cambiar el cuerpo principal de la prueba.
Vinculación de pruebas a casos de uso
Si usa el Administrador de pruebas para diseñar y ejecutar las pruebas, puede organizar las pruebas bajo requisitos, casos de uso o elementos de trabajo del caso de usuario. Puede vincular estos elementos de trabajo a casos de uso en su modelo. Esto le permite realizar un seguimiento rápido de los cambios en los requisitos de las pruebas y le ayuda a realizar un seguimiento del progreso de cada caso de uso.
Para vincular pruebas a un caso de uso
En el Administrador de pruebas, cree un requisito y base un conjunto de pruebas en él.
El requisito que usted cree es un elemento de trabajo en Team Foundation Server. Puede ser un elemento de trabajo como una Historia de usuario, un Requisito o un Caso de uso, según la plantilla de proceso que utilice el proyecto con Team Foundation. Para obtener más información, consulte Acerca de las herramientas ágiles y la administración de proyectos de Agile.
Vincule el elemento de trabajo de requisito a uno o varios casos de uso del modelo.
En un diagrama de casos de uso, haga clic con el botón derecho en un caso de uso y, a continuación, haga clic en Vincular al elemento de trabajo.
Agregue al conjunto de pruebas, casos de prueba que comprueben los casos de uso.
Normalmente, cada historia de usuario o elemento de trabajo de requisitos se vinculará a varios casos de uso en tu modelo, y cada caso de uso se vinculará a varias historias de usuario o requisitos. Esto se debe a que cada caso de usuario o requisito cubre un conjunto de tareas que desarrollan varios casos de uso. Por ejemplo, en una iteración temprana de su proyecto, podría desarrollar la historia de usuario básica en la que un cliente puede elegir elementos de un catálogo y estos sean entregados. En una iteración posterior, la historia podría ser que el usuario paga al completar el pedido y el proveedor recibe el dinero después de enviar los productos. Cada historia agrega una cláusula a la poscondición del caso de uso de Order Goods.
Puede crear vínculos independientes de los requisitos a las cláusulas de la condición posterior escribiendo esas cláusulas en comentarios independientes en el diagrama de casos de uso. Puede vincular cada comentario a un elemento de trabajo de 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, las interfaces y las enumeraciones, de un modelo de requisitos describen los conceptos y las relaciones en términos de cómo piensan y comunican los usuarios sobre su negocio. Excluye los tipos que solo se refieren al diseño interno del sistema.
Diseñe las pruebas en términos de estos tipos de requisitos. Esta práctica le ayuda a garantizar que, cuando se analizan los cambios en los requisitos, es fácil relacionar los cambios con los cambios necesarios en las pruebas. Permite analizar las pruebas y sus resultados previstos directamente con los usuarios finales y otras partes interesadas. Esto significa que las necesidades de los usuarios se pueden mantener fuera del proceso de desarrollo y evita el diseño accidental de las pruebas en torno a posibles errores en el diseño.
En el caso de las pruebas manuales, esta práctica implica la adhesión al vocabulario del modelo de requisitos en los scripts de prueba. En el caso de las pruebas automatizadas, esta práctica implica el uso de los diagramas de clases de requisitos como base para el código de prueba y la creación de funciones de acceso y actualización para vincular el modelo de requisitos al código.
Por ejemplo, un modelo de requisitos puede incluir tipos como Menú, Elemento del Menú, Pedido y asociaciones entre ellos. Este modelo representa la información almacenada y tratada por el sistema de pedidos de comidas, pero no representa las complejidades de su implementación. En el sistema de trabajo, puede haber varias realizaciones diferentes de cada tipo, en bases de datos, en interfaces de usuario y en API. En un sistema distribuido, puede haber varias variantes de cada instancia almacenadas en diferentes partes del sistema al mismo tiempo.
Para probar un caso de uso como Agregar elemento a pedido, un método de prueba podría incluir código 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 usa las clases del modelo de requisitos. Las asociaciones y atributos se realizan como propiedades de .NET.
Para que esto funcione, las propiedades de las clases deben definirse como funciones o descriptores de acceso de solo lectura, que acceden al sistema para recuperar información sobre su estado actual. Los métodos que simulan casos de uso como AddItemToOrder deben conducir el sistema a través de su API o a través de una capa debajo de su interfaz de usuario. Los constructores de objetos de prueba como Order y MenuItem también deben conducir el sistema para crear los elementos correspondientes dentro del sistema.
Muchos de los accesores y actualizadores ya estarán disponibles a través de la API estándar de la aplicación. Pero es posible que algunas funciones adicionales tengan que escribirse para habilitar las pruebas. Estos accesos y actualizadores adicionales a veces se conocen como "instrumentación de prueba". Dado que dependen del diseño interno del sistema, es responsabilidad de los desarrolladores del sistema proporcionarlos, mientras que los evaluadores escriben el código de las pruebas en términos del modelo de requisitos.
Al escribir pruebas automatizadas, puede usar pruebas genéricas para encapsular los descriptores de acceso y los actualizadores.
Pruebas para reglas de negocio
Algunos requisitos no están directamente relacionados con ningún caso de uso. Por ejemplo, la empresa DinnerNow permite a los clientes elegir entre muchos menús, pero requiere que, en cada pedido, todos los elementos elegidos sean de un solo menú. Esta regla de negocios se puede expresar como una invariable sobre las asociaciones entre Pedidos, Menús y Elementos en el modelo de clase de requisitos.
Una regla invariable de este tipo rige no solo todos los casos de uso definidos actualmente, sino también cualquier otro caso de uso que se defina más adelante. Por lo tanto, resulta útil escribirlo por separado de cualquier caso de uso y probarlo por separado de los casos de uso.
Derivación de pruebas del subsistema a partir de modelos
En el diseño de alto nivel de un sistema grande, puede identificar componentes o subsistemas. Estos representan partes que se pueden diseñar por separado, o se encuentran en equipos diferentes, o son módulos reutilizables que se pueden volver a enlazar de muchas maneras.
Puede aplicar a cada componente principal los mismos principios que usa para el sistema completo. 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 para mostrar los componentes principales y sus interacciones. Para obtener más información, consulta Modelar la arquitectura de la aplicación.
En cualquier caso, puede establecer una relación entre los elementos del modelo y las pruebas del subsistema de la misma manera que lo haría entre el modelo de requisitos y las pruebas del sistema.
Aislar componentes con interfaces proporcionadas y demandadas
Resulta útil identificar todas las dependencias que tiene un componente en otras partes del sistema o los servicios externos, y representarlas como interfaces necesarias. Este ejercicio suele dar lugar a un rediseño que deja mucho más desacoplado el componente y se separa fácilmente del resto del diseño.
Una ventaja de este desacoplamiento es que el componente se puede ejecutar para realizar pruebas al reemplazar los servicios que normalmente usa con objetos simulados. Estos son componentes que se configuran con fines de prueba. Un componente ficticio proporciona la interfaz que requiere el componente, respondiendo a las consultas con datos simulados. Los componentes ficticios forman parte de un arnés de prueba completo que puede conectarse a todas las interfaces del componente.
Una ventaja de las pruebas simuladas es que puede desarrollar el componente mientras que los demás componentes cuyos servicios usarán todavía están en desarrollo.
Mantener las relaciones entre las pruebas y el modelo
En un proyecto típico que realiza una iteración cada pocas semanas, se mantiene una revisión de requisitos cerca del principio de cada iteración. En la reunión se describen las características que se van a entregar en la siguiente iteración. Se puede usar un modelo de requisitos para ayudar a analizar los conceptos, escenarios y secuencias de acciones que se desarrollarán. Las partes interesadas de la empresa establecen prioridades, los desarrolladores realizan estimaciones y los evaluadores garantizan que el comportamiento esperado de cada característica se capture correctamente.
Escribir pruebas es la manera más eficaz de definir un requisito y también es una manera eficaz de asegurarse de que una persona tiene una comprensión clara de lo que se requiere. Sin embargo, mientras que la escritura de pruebas tarda demasiado tiempo en realizarse durante un taller de especificación, la creación de modelos se puede realizar mucho más rápidamente.
Desde un punto de vista de pruebas, se puede ver un modelo de requisitos como una abreviatura de las pruebas. Por lo tanto, es importante mantener la relación entre las pruebas y el modelo en todo el proyecto.
Adjuntar casos de prueba a elementos de modelo
Si el proyecto usa el Administrador de pruebas, puede vincular las pruebas a los elementos del modelo. Esto le permite encontrar rápidamente las pruebas afectadas por un cambio en los requisitos y le ayuda a realizar un seguimiento de la medida en que se ha realizado un requisito.
Puede vincular pruebas a todo tipo de elemento. Estos son algunos ejemplos:
Asocie un caso de uso a las pruebas que lo ponen a prueba.
Escriba las cláusulas de la poscondición o objetivo de un caso de uso en comentarios que están vinculados al caso de uso y, a continuación, vincule las pruebas a cada comentario.
Escriba reglas invariables en comentarios en diagramas de clases o diagramas de actividad y vincútelos a pruebas.
Vincular pruebas a un diagrama de actividad o a actividades individuales.
Vincule un conjunto de pruebas al componente o subsistema que prueba.
Para vincular pruebas a un elemento o relación de modelo
En el Administrador de pruebas, cree un requisito y base un conjunto de pruebas en él.
El requisito que usted cree es un elemento de trabajo en Team Foundation Server. Puede ser un elemento de trabajo como una Historia de usuario, un Requisito o un Caso de uso, según la plantilla de proceso que utilice el proyecto con Team Foundation. Para obtener más información, consulte Acerca de las herramientas ágiles y la administración de proyectos de Agile.
Vincule el elemento de trabajo de requisito a uno o varios elementos del modelo.
En un diagrama de modelado, haga clic con el botón derecho en un elemento, comentario o relación y, a continuación, haga clic en Vincular al elemento de trabajo.
Agregue al conjunto de pruebas, casos de prueba que comprueben el requisito expresado en el elemento de modelo.