O desenvolvimento de testes de um modelo
Na Microsoft Visual Studio Ultimate, você pode usar os requisitos e modelos arquitetônicos para ajudá-lo a organizar os testes do seu sistema e seus componentes.Essa prática ajuda a garantir que você teste os requisitos que são importantes para os usuários e outros participantes e ajuda a atualizar os testes rapidamente quando os requisitos mudam.Se você usar Microsoft Test Manager, você também pode manter os vínculos entre os modelos e os testes.
Sistema e teste de subsistema
Sistema de teste, também conhecido como testes de aceitação, meio testando se as necessidades dos usuários que estão sendo atendidas.Esses testes estão preocupados com o comportamento visível externamente do sistema em vez do design interno.
Testes de sistema são muito valiosos quando estender ou reprojetar um sistema.Eles ajudam a evitar a introdução de bugs quando você altera o código.
Ao planejar qualquer alteração ou extensão a um sistema, é útil iniciar com um conjunto de testes de sistema que são executados no sistema existente.Em seguida, você pode estender ou ajustar os testes para testar os novos requisitos, faça as alterações no código e execute novamente o conjunto completo de testes.
Ao desenvolver um novo sistema, você pode começar a criar testes, desde o início de desenvolvimento.Definindo testes antes de desenvolver cada recurso, você pode capturar as discussões de requisitos de uma maneira muito específica.
Teste de subsistema aplica os mesmos princípios para os principais componentes de um sistema.Cada componente é testado separadamente de outros componentes.Subsistema testa o foco no comportamento visível em interfaces de usuário ou a API do componente.
Para obter mais informações sobre como executar testes, consulte Testando o aplicativo.
A derivação de testes de sistema de um modelo de requisitos
Você pode criar e manter uma relação entre um modelo de requisitos e testes de sistema.Para estabelecer essa relação, você pode escrever testes que correspondem aos principais elementos do modelo de requisitos.Visual Studio Ultimateajuda você a manter esse relacionamento, permitindo que você criar vínculos entre os testes e partes do modelo.Para obter mais informações sobre modelos de requisitos, consulte Requisitos do usuário de modelagem..
.gif "Dd409381.collapse_all(pt-br,VS.110).gif")
Escrever testes para cada caso de uso
Se você usar Microsoft Test Manager, você pode criar um grupo de testes para cada caso de uso que você definiu em seu modelo de requisitos.Por exemplo, se você tiver um caso de uso ordem refeição, que inclui criar pedido e Adicionar Item à ordem, você pode criar testes para ambos os gerais e casos de uso o mais detalhado.Para obter mais informações sobre casos de uso, consulte Diagramas de caso de uso UML: diretrizes.
Essas diretrizes podem ser úteis:
Cada caso de uso deve ter vários testes, para os caminhos principais e resultados excepcionais.
Quando apresentar um caso de uso do modelo de requisitos, é mais importante definir seu pós-condição, ou seja, a meta é alcançada de descrever detalhadamente os procedimentos que o usuário segue para atingir a meta.Por exemplo, a pós-condição da ordem refeição pode ser que um restaurante está preparando uma refeição para um cliente e que tenha efetuado o pagamento do cliente.A pós-condição é o critério que devem verificar se os seus testes.
Base testes separados em cláusulas de separado da pós-condição.Por exemplo, crie testes separados para notificar o restaurante da ordem e para fazer o pagamento do cliente.Essa separação tem as seguintes vantagens:
As alterações nos diferentes aspectos dos requisitos de ocorrerem com freqüência independentemente.Separando os testes em diferentes aspectos dessa maneira, você torna mais fácil atualizar os testes quando os requisitos mudam.
Se o plano de desenvolvimento implementa um aspecto do caso de uso antes de outro, você pode ativar os testes separadamente à medida que progride de desenvolvimento.
Ao projetar os testes, separe a escolha dos dados de teste do código ou script que determina se a pós-condição foi obtida.Por exemplo, um teste de uma função de aritmética simple pode ser: 4 de entrada; Verifique se a saída é 2.Em vez disso, criar o script como: escolher uma entrada; Multiplique o resultado por si só e verifique se o resultado é a entrada original.Esse estilo permite variar as entradas de teste sem alterar o corpo principal do teste.
A vinculação de testes para casos de uso
Se você estiver usando Test Manager para criar e executar os testes, você pode organizar os testes em caso de uso, requisito ou em itens de trabalho de história de usuário.Você pode vincular esses itens para casos de uso no seu modelo de trabalho.Isso permite que você rapidamente alterações de requisitos rastreamento dos testes e ajuda a você controla o andamento de cada caso de uso.
Para vincular os testes para um caso de uso
Na Test Manager, crie um requisito e basear uma suíte de testes.Para saber como fazer isso, consulte Criando testes para itens de Lista de Pendências de Produto, histórias do usuário ou requisitos.
O requisito que você cria é um item de trabalho em Team Foundation Server.Talvez seja um item de trabalho de história de usuário, requisito ou caso de uso, dependendo do modelo de processo que usa o seu projeto com Team Foundation.Para obter mais informações, consulte Planejando e acompanhando projetos.
Vincule o item de trabalho do requisito para um ou mais casos de uso no seu modelo.
Em um diagrama de caso de uso, um caso de uso com o botão direito e, em seguida, clique em Link para o Item de trabalho.Para obter mais informações, consulte Vincular elementos de modelo e itens de trabalho.
Adicione o conjunto de teste, casos de teste que verificam os casos de uso.
Em geral, cada item de trabalho do usuário matéria ou requisito irá vincular a vários casos de uso no seu modelo e vinculará cada caso de uso para várias histórias de usuários ou requisitos.Isso ocorre porque cada história de usuário ou requisito abrange um conjunto de tarefas que desenvolver vários casos de uso.Por exemplo, em uma iteração antecipada do seu projeto, você pode desenvolver a história de usuário básica na qual um cliente pode escolher itens de um catálogo e que elas sejam entregues.Em uma iteração mais recente, a história pode ser que o usuário paga quando concluir a ordem e o fornecedor recebe o dinheiro após enviar as mercadorias.Cada matéria adiciona uma cláusula da pós-condição do caso de uso de mercadorias da ordem.
Você pode criar links separados dos requisitos para as cláusulas da pós-condição gravando as cláusulas nos comentários separados de acordo com o diagrama de caso de uso.Você pode vincular cada comentário a um item de trabalho do requisito e vincular o comentário para o caso de uso no diagrama.
Testes de base nos tipos de requisitos
Os tipos, o que é, as classes, interfaces e enumerações, de um modelo de requisitos descrevem os conceitos e as relações em termos de como os usuários pensam e se comunicar sobre seus negócios.Ele exclui tipos preocupados apenas com o design interno do sistema.
Os testes em termos desses tipos de requisitos de design.Essa prática ajuda a garantir que, quando as alterações para os requisitos são discutidas, é fácil relacionar as alterações para as alterações necessárias nos testes.Ele torna possível discutir os testes e seus resultados pretendidos diretamente com os usuários finais e outros participantes.Isso significa que o dos usuários precisam pode ser mantidos fora do processo de desenvolvimento e evita o design inadvertido dos testes em torno de possíveis falhas no design.
Testes manuais, essa prática envolve segui o vocabulário do modelo requisitos nos scripts de teste.Para testes automatizados, essa prática envolve usando os diagramas de classe de requisitos como base para o seu código de teste e criar funções para vincular o modelo de requisito para o código de acessador e updater.
Por exemplo, requisitos de um modelo pode incluir tipos de Item de Menu, Menu, ordem e associações entre eles.Esse modelo representa as informações que são armazenadas e lidou com por que o sistema de pedidos de refeição, mas não representam as complexidades de sua implementação.O sistema em funcionamento, pode haver várias realizações diferentes de cada tipo, em bancos de dados em interfaces de usuário e nas APIs.Em um sistema distribuído, pode haver diversas variantes de cada instância armazenados em diferentes partes do sistema ao mesmo tempo.
Para testar um caso de uso, como adicionar Item à ordem, um método de teste pode incluir código semelhante a este:
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 esse método de teste usa as classes do modelo de requisitos.Associações e atributos são percebidos como.NET propriedades.
Para fazer esse trabalho, as propriedades das classes devem ser definidas como funções de somente leitura ou acessadores, que acessar o sistema para recuperar informações sobre seu estado atual.Métodos que simulam casos de uso, como AddItemToOrder deve unidade do sistema por meio de sua API ou através de uma camada abaixo de sua interface do usuário.Os construtores de objetos de teste como ordem e MenuItem devem também a unidade do sistema para criar itens correspondentes dentro do sistema.
Muitos dos acessadores e atualizadores já estará disponíveis por meio da API de normal do aplicativo.Mas, algumas funções adicionais talvez tenha que ser escrito para habilitar os testes.Esses acessadores adicionais e atualizadores também são conhecidas como 'instrumentação de teste'.Como eles dependem do design interno do sistema, é responsabilidade dos desenvolvedores do sistema para fornecer-lhes, ao passo que os testadores escrever o código dos testes em termos de modelo de requisitos.
Ao escrever testes automatizados, você pode usar testes genéricos para encapsular os acessadores e atualizadores.Para obter mais informações, consulte Criando um teste automatizado que executa um executável usando testes genéricos.
Testes para regras comerciais
Alguns requisitos não estão diretamente relacionados para qualquer um caso de uso.Por exemplo, os negócios do DinnerNow permite que os clientes escolham entre vários Menus, mas requer que cada ordem, todos os itens deverão ser de um único Menu escolhido.Esta regra de negócios pode ser expresso como uma constante indicando sobre as associações entre ordens, Menus e itens no modelo de classe de requisitos.
Uma regra invariável desse tipo controla não apenas a todos os casos de uso que são definidos no momento, mas também os outros casos de uso que serão definidos posteriormente.Portanto, é útil para escrevê-lo separadamente de qualquer caso de uso e testá-lo separadamente de casos de uso.
Você pode escrever uma regra de negócio invariável como um comentário em um diagrama de classe.Para obter mais informações, consulte Diagramas de classe UML: diretrizes.
Você pode vincular testes para uma regra de negócio, vinculando o comentário a um requisito ou usuário matéria item de trabalho, que você pode vincular a uma suíte de testes em Test Manager.Para obter mais informações, consulte anexando os casos de teste para elementos de modelo.
Outra qualidade de requisitos de serviço e o desempenho podem ser observados na comentários no caso de uso, atividade ou diagramas de seqüência.Você poderá vinculá-las também para itens de trabalho de requisitos e seus conjuntos de teste.
Diagramas de seqüência e atividade para testes
Se seus requisitos ou modelos de arquitetura de incluem a seqüência ou diagramas de atividade, você pode escrever os testes que seguem os diagramas diretamente.
Às vezes é útil para a criação de testes dinamicamente escolher caminhos diferentes por meio de loops e ramificações no diagrama.
Tente verificar o estado do sistema após cada mensagem ou ação.Isso pode requerer adicionais de instrumentação.
A derivação de testes do subsistema de modelos
No design de um grande sistema de alto nível, você pode identificar os componentes ou subsistemas.Elas representam partes que podem ser criados separadamente, estão localizados em computadores diferentes ou são módulos reutilizáveis que podem ser recombined de várias maneiras.Para obter mais informações, consulte Diagramas de componente UML: diretrizes.
Você pode aplicar a cada componente principal os mesmos princípios que você use para todo o sistema.Em um projeto grande, cada componente pode ter seu próprio modelo de requisitos.Em projetos menores, um modelo de arquitetura ou design de alto nível pode ser criado para mostrar os principais componentes e suas interações.Para obter mais informações, consulte A arquitetura de um sistema de Software de modelagem..
Em ambos os casos, você pode estabelecer uma relação entre os elementos de modelo e os testes do subsistema da mesma maneira como você faria entre o modelo de requisitos e os testes de sistema.
Isolar os componentes com Interfaces necessárias e fornecidas
Ele é útil para identificar todas as dependências de um componente tem em outras partes do seu sistema ou a serviços externos e para representar essas áreas como Interfaces necessárias.Neste exercício geralmente leva a alguns reformulação que deixa o componente muito mais desmembrado e facilmente separável do restante do seu design.
Aproveitar essa desassociação é que o componente pode ser executado para teste, substituindo com objetos fictícios os serviços geralmente usa.Esses são os componentes que estão configurados para fins de teste.Um componente de simulação fornece a interface que necessita de seu componente, respondendo às consultas com dados simulados.Os componentes de simulações fazem parte de um conjunto de teste completo que você pode conectar a todas as interfaces do componente.
Um benefício do teste de simulação é que você possa desenvolver seu componente enquanto os outros componentes cujos serviços que ele utilizará estão ainda em desenvolvimento.
Manter as relações entre testes e modelo
Em um projeto típico que realiza uma iteração em algumas semanas, uma análise dos requisitos é mantida próximo ao início de cada iteração.A reunião aborda os recursos que devem ser entregues na próxima iteração.Um modelo de requisitos pode ser usado para ajudar a discutir os conceitos, cenários e as seqüências de ações que serão desenvolvidas.Os acionistas da empresa a definir as prioridades, os desenvolvedores a fazer estimativas e os testadores garantem que o comportamento esperado de cada recurso é capturado corretamente.
Escrita de testes é a maneira mais eficaz para definir um requisito e também é uma maneira eficaz para garantir que uma pessoa tenha um entendimento claro do que é necessário.No entanto, ao passo que os testes de gravação demorar muito para fazer durante um workshop de especificação, criação de modelos pode ser feito muito mais rapidamente.
Do ponto de vista teste, um modelo de requisitos pode ser visto como um atalho para os testes.Portanto, é importante manter a relação entre os testes e o modelo ao longo do projeto.
A anexação de casos de teste para elementos de modelo
Se seu projeto usa Test Manager, você pode vincular os testes aos elementos no seu modelo.Isso permite que você localize rapidamente os testes afetados por uma alteração nos requisitos e ajuda a controlar a extensão à qual um requisito foi percebido.
Você pode vincular os testes a todos os tipos de elemento.Aqui estão alguns exemplos:
Vincule um caso de uso para os testes que exercício-lo.
Escrever as cláusulas de pós-condição casos de uso ou objetivo, até os comentários que estão vinculados ao caso de uso, e vincule testes para cada comentário.
Escrever regras invariável nos comentários dos diagramas de classe ou diagramas de atividade e vinculá-las para testes.
Testes de link para um diagrama de atividade ou para atividades individuais.
Vincule a uma suíte de testes para o componente ou subsistema que ele testa.
Para vincular os testes a um elemento de modelo ou relacionamento
Na Test Manager, crie um requisito e basear uma suíte de testes.Para saber como fazer isso, consulte Criando testes para itens de Lista de Pendências de Produto, histórias do usuário ou requisitos.
O requisito que você cria é um item de trabalho em Team Foundation Server.Talvez seja um item de trabalho de história de usuário, requisito ou caso de uso, dependendo do modelo de processo que usa o seu projeto com Team Foundation.Para obter mais informações, consulte Planejando e acompanhando projetos.
Vincule o item de trabalho do requisito para um ou mais elementos no seu modelo.
Em um diagrama de modelagem, o botão direito do mouse um elemento, comentário ou relacionamento e clique em Link para o Item de trabalho.Para obter mais informações, consulte Vincular elementos de modelo e itens de trabalho.
Adicione o conjunto de teste, casos de teste que verificam o requisito expresso em um elemento de modelo.
Consulte também
Conceitos
Desenvolvendo modelos para design de software
Requisitos do usuário de modelagem.