O desenvolvimento de testes de um modelo
Em Microsoft Visual Studio Ultimate, você pode usar os requisitos e modelos arquitetônicos para ajudá-lo a organizar os testes de 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 testes.
Sistema e teste de subsistema
Teste de sistema, também conhecido como testes de aceitação, significa que o teste se os usuários necessidades sejam atendidas. Esses testes estão preocupados com o comportamento visível externamente do sistema em vez do design interno.
Os testes de sistema são muito valiosos quando estender ou reprojetar um sistema. Elas ajudam a evitar a introdução de bugs quando você alterar o código.
Quando você planejar qualquer alteração ou a extensão de um sistema, é útil iniciar com um conjunto de testes de sistema executado 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 os testes que correspondem aos principais elementos do modelo de requisitos. Visual Studio Ultimateajuda você a manter o 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..
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 no seu modelo de requisitos. Por exemplo, se você tiver um caso de uso ordem refeição, que inclui criar pedido e Adicionar Item de pedido, 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 você descrever 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, pode ser a pós-condição da ordem refeição um restaurante está preparando uma refeição para um cliente e o cliente tem pago. A pós-condição é o critério que devem verificar se os seus testes.
Testes separados base as cláusulas separadas 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:
Alterações em diferentes aspectos dos requisitos freqüentemente ocorrerem 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: Entrada 4; Verifique se a saída 2. Em vez disso, o script como de design: Escolha 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.
Testes de casos de uso de vinculação
Se você estiver usando Test Manager para projetar e executar os testes, você pode organizar seus testes de requisito, use case, ou itens de trabalho do usuário matéria. 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ê controlar o progresso de cada caso de uso.
Para vincular os testes para um caso de uso
Em Test Manager, crie um requisito básicos e uma suíte de testes do proprietário. Para saber como fazer isso, consulte Criando um plano de teste usando requisitos ou histórias de usuários.
O requisito de 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 clique em Link para o Item de trabalho. Para obter mais informações, consulte Como: Link de elementos de modelo para os itens de trabalho.
Adicione o conjunto de teste, casos de teste para verificar 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 cada caso de uso irá vincular a vários requisitos ou histórias de usuários. Isso ocorre porque cada história de usuário ou requisito abrange um conjunto de tarefas desenvolver vários casos de uso. Por exemplo, em uma iteração de início do projeto, você pode desenvolver a história de usuário básica, um cliente pode escolher os itens de um catálogo e 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 depois que ele envia as mercadorias. Cada matéria adiciona uma cláusula de pós-condição de caso de uso de mercadorias da ordem.
Você pode criar links separados dos requisitos para as cláusulas da pós-condição escrevendo essas cláusulas em comentários separados em um diagrama de caso de uso. Você pode vincular a 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 é, 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 possibilita discutir os testes e seus resultados pretendidos diretamente com os usuários finais e outros participantes. Isso significa que os usuários necessidades podem ser mantidas 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 de requisitos em scripts de teste. Os testes automatizados, essa prática envolve usando 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 modelo pode incluir tipos de Menu, o Item de 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. 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, por exemplo, 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. Atributos e associações são percebidos como.Propriedades de rede.
Para fazer esse trabalho, as propriedades das classes devem ser definidas como o funções somente leitura ou acessadores, que acessar o sistema para recuperar informações sobre seu estado atual. Os 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 da interface do usuário. Os construtores de objetos de teste como, por exemplo, 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'. Pois eles dependem do design interno do sistema, é responsabilidade dos desenvolvedores do sistema para fornecer a eles, enquanto 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 de regras de negócios
Alguns requisitos não estão diretamente relacionados a 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 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 são definidos no momento, mas também os outros casos de uso que serão definidos posteriormente. Portanto, é útil para escrevê-la 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 para 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 a casos de teste para elementos de modelo.
Desempenho e qualidade de outra requisitos de serviço podem anotados nos comentários em caso de uso, atividade ou diagramas de seqüência. Você poderá vinculá-las também para itens de trabalho de requisitos e suas suítes de teste.
Diagramas de seqüência e atividade para testes
Se seus requisitos ou modelos de arquitetura 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 como você pode usar para o sistema completo. 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 fornecidas e necessárias
É útil para identificar todas as dependências de um componente possui em outras partes do seu sistema ou a serviços externos e para representar esses 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 que ele normalmente 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 se 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 usará 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 abordar os conceitos, cenários e as seqüências de ações que serão desenvolvidas. Os acionistas da empresa Defina 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 eficiente para definir um requisito, e também é uma maneira eficaz de garantir que uma pessoa tenha um entendimento claro do que é necessário. No entanto, enquanto a escrita de testes muito demorado 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 em todo o projeto.
A anexação de casos de teste para elementos de modelo
Se seu projeto usa Test Manager, você pode vincular os testes para os elementos de modelo. Isso lhe permite localizar 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 para todos os tipos de elemento. Aqui estão alguns exemplos:
Vincule a um caso de uso para os testes que exercício a ele.
Escrever as cláusulas de pós-condição casos de uso ou objetivo, até os comentários sã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 atividades individuais.
Vincule a uma suíte de testes para o componente ou subsistema que ele testa.
Para vincular os testes para um elemento de modelo ou o relacionamento
Em Test Manager, crie um requisito básicos e uma suíte de testes do proprietário. Para saber como fazer isso, consulte Criando um plano de teste usando requisitos ou histórias de usuários.
O requisito de 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, direito de um elemento, o comentário ou a relação e, em seguida, clique em Link para o Item de trabalho. Para obter mais informações, consulte Como: Link de elementos de modelo para os itens de trabalho.
Adicione o conjunto de teste, casos de teste, verifique se o requisito expresso em um elemento de modelo.
Consulte também
Conceitos
O desenvolvimento de modelos de Design de Software
Requisitos do usuário de modelagem.