Artigo Engenharia de Software 6 - Planejamento de Testes a partir de Casos de Uso

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (3)  (0)

O artigo apresenta uma estratégia indicando como testes podem ser obtidos a partir dos casos de uso especificados para um projeto.

Esse artigo faz parte da revista Engenharia de Software 6 edição especial. Clique aqui para ler todos os artigos desta edição

 

Validação, Verificação e Teste

Planejamento de Testes a partir de Casos de Uso

 

De que se trata o artigo:

O artigo apresenta uma estratégia indicando como testes podem ser obtidos a partir dos casos de uso especificados para um projeto.

Para que serve:

Durante o desenvolvimento de um software, diversas estratégias para teste podem ser aplicadas. Ao longo deste artigo iremos adotar uma estratégia de geração de testes baseada em especificação, representada pelos casos de uso de um sistema. Assim, partiremos desta informação para a geração de casos e procedimentos (roteiros) de teste. Desta forma, este artigo apresenta de forma prática como efetuar a geração de casos de teste.

Em que situação o tema é útil:

A cada dia as atividades de teste de software vêm tendo sua importância aumentada dentro das organizações de desenvolvimento de software. O tema deste artigo agrega conhecimento a este cenário através do apoio às atividades do analista de testes.

 

Se observarmos nos diferentes livros tradicionais de Engenharia de Software, veremos que sempre existe um capítulo ou seção destinado a Teste de software. Porém, eles normalmente apresentam apenas informações básicas sobre esta atividade, como por exemplo, os diferentes níveis de teste que podem ser aplicado (ex: unidade, integração ou sistema), as técnicas de teste que podem ser aplicadas (ex: técnica funcional ou estrutural) e os critérios para seleção dos testes associados a estas técnicas. Por exemplo, no artigo “Introdução a Teste de Software” publicado na edição 01 da Engenharia de Software Magazine discutimos sobre alguns desses critérios: Particionamento em classes de equivalência, Análise do Valor Limite e Grafo de Causa-Efeito. Para cada critério, vimos como aplicá-los e um exemplo da sua aplicação para a geração de casos de teste. Mais informações sobre esses critérios de seleção dos testes podem ser obtidas em ROCHA (2001).

No entanto, no desenvolvimento de um software real normalmente os problemas são bem mais complexos do que aqueles tradicionalmente usados quando estamos conhecendo esses critérios para seleção dos testes (ex: indicar qual o maior valor em um conjunto, indicar se um campo número só contém caracteres válidos, dentre outros). Normalmente os problemas a serem resolvidos são representados através de cenários, que podem ser facilmente representados por Diagramas de Casos de Uso da UML (www.uml.org) aliada a uma descrição do que cada caso de uso deve fazer.

Ao longo deste artigo iremos discutir uma possível estratégia indicando como testes podem ser obtidos a partir dos casos de uso especificados para um projeto. Entendemos que podem existir diferentes estratégias para isso, então iremos apresentar apenas uma possibilidade que pode ser facilmente aplicada para o teste de formulários de cadastro, normalmente existentes em sistemas de informação.

Estratégias de Teste de Software

Durante o desenvolvimento de um software, diversas estratégias para teste podem ser aplicadas. De acordo com PRESSMAN (2005), essas estratégias podem ser categorizadas da seguinte forma:

·         Baseadas em implementação: utiliza o código como elemento para a geração dos testes. É uma atividade cara, sob o ponto de vista de recursos necessários para a sua realização, e bastante complexa quando o tamanho do código se torna bastante grande. É totalmente dependente de apoio ferramental.

·         Baseadas em especificação: utiliza um documento de especificação como base para geração dos testes. Assim, tenta-se cobrir as imposições e restrições descritas nos requisitos estabelecidos para o sistema. A automação da geração dos testes nesse caso é mais complicada, caso não se tenha um formalismo para a elaboração da especificação do sistema.

"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?