Teste de Unidade
O Teste de Unidade é uma verificação automatizada do funcionamento da menor unidade possível de um sistema, ou seja, consiste em validar os dados de entradas e saídas executando cada trecho de código de forma automática, normalmente, através de métodos públicos em um classe de teste.
Cada teste de unidade deve ser independente, para possibilitar que cada método de uma classe seja testado isoladamente, o que possibilita a manutenção e a escalabilidade dos testes em conjunto com o sistema. O teste de unidade é a primeira abordagem em matéria de confecção de testes mais robustos e confiáveis.
Testes Unitários são primeiramente escritos como uma boa prática para ajudar desenvolvedores a identificar e corrigir defeitos, refatorar o código e servir como documentação para uma unidade de programa sob teste. Para conseguir esses benefícios, testes unitários idealmente deveriam cobrir todos os caminhos possíveis em um programa. Um teste unitário geralmente cobre um caminho específico em uma função ou método. Porém um método de teste não é necessariamente uma entidade encapsulada e independente. Frequentemente existem dependências implícitas entre métodos de teste, escondidas no cenário de implementação de um teste.
- Adrian Kuhn
Algumas técnicas de Testes
Caixa-preta
Teste de caixa-preta é um tipo de teste que verifica a saída dos dados usando entradas de vários tipos. Tais entradas não são escolhidas conforme a estrutura do programa. Este tipo de teste também é conhecido como teste funcional, já que busca garantir que os requisitos funcionais do produto estão consistentes. É comumente realizado utilizando-se da experiência do usuário, ou seja, através da interface do produto. Também conhecido como teste comportamental, este tipo de teste tenta encontrar erros nas seguintes categorias:
- Funções incorretas ou omitidas;
- Erros de interface;
- Erros de estrutura de dados ou de acesso a base de dados externa;
- Erros de comportamento ou desempenho;
- Erros de iniciação e término.
- Aplicado durante os últimos estágios do teste, a atenção é focada no domínio da informação.
Caixa-branca
Teste de caixa-branca é uma técnica de teste que usa a perspectiva interna do sistema para modelar os casos de testes. Difere do teste de caixa-preta em que a perspectiva interna do sistema é desconsiderada, sendo testadas e mensuradas somente as interfaces do sistema.
Classe de equivalência
Teste com base na análise de classe de equivalência é uma forma de análise de teste de caixa preta que tenta reduzir o número total de testes possíveis para um conjunto mínimo de testes que revelarão o número máximo de erros possível. Isso consiste em um método que particiona o conjunto de entradas e saídas em um número finito de classe de equivalência que permitem a seleção de um valor de teste representativo para cada classe.
O teste que resulta do valor representativo para uma classe é chamado de "equivalente" aos outros valores na mesma classe, ou seja, espera-se que o objeto testado se comporte de forma semelhante. Se nenhum erro foi localizado no teste do valor representativo, conclui-se que todos os outros valores "equivalentes" também não identificariam quaisquer erros. Essa técnica pode ser aplicada para ajudar a analisar os testes mais significativos a serem conduzidos quando houver muitos testes potenciais a serem conduzidos no tempo disponível.
Análise de valor de limite
Essa técnica complementa o particionamento de equivalência. Para usar a análise do valor limite nos testes, descobrimos os limites do campo que queremos testar, está técnica de teste é utilizada para exercitar os limites do domínio de entrada.
A técnica nos diz que devemos testar um valor imediatamente abaixo do limite, o valor limite e um valor imediatamente acima do valor limite, ou seja, os valores próximos às extremidades das classes focalizando a seleção de Casos de Teste. Focaliza o teste em um ponto propício a erros, os limites de uma classe de equivalência. Os valores esperados de entrada e saída devem ser extraídos da especificação do componente, e então agrupados em conjuntos com fronteiras identificáveis.
Cada conjunto, ou partição, contém valores que se espera que sejam processados pelo componente da mesma forma. É importante considerar ambas as partições válidas e inválidas quando se projetam casos de teste.
Matriz ortogonal
O teste de matriz ortogonal é um ponto médio para problemas com domínio de entrada relativamente pequeno, mas grande demais para testes exaustivos. Esta técnica de teste é muito útil quando há um grande número de dados de entrada, e suas combinações não são viáveis e rentáveis de serem testadas individualmente. Testes de matriz ortogonal fornece cobertura suficientemente completa de um aplicativo com o número mínimo de casos de teste.
É melhor verificar apenas as combinações de dados que são suscetíveis de causar um defeito ao invés de checar todas as variantes possíveis. Se há muitas combinações de dados complicado pode ser muito difícil de determinar as combinações que devem ser verificadas.
Este método detecta e isola todas as falhas de modo singular (pela análise da informação sobre quais testes revelam erros, pode-se identificar quais valores de parâmetro causam a falha). Detecta todas as falhas de modo duplo. A aplicação da técnica de ***análise combinatória aos casos de teste, de forma que cada combinação escolhida pelo testador seja executada pelo menos uma vez. É conhecido como *3-wise, 4-wise, n-wise — quanto maior o N, mais meticuloso é o processo.
Na combinação 1-wise, cada valor de cada item é incluido pelo menos uma vez em um teste. Numa combinação 2-wise, todos os valores de um par de itens são combinados com os outros valores pelo menos uma vez em um teste, na 3-wise todos os valores de 3 itens são combinados pelos menos uma vez em cada caso… e assim sucessivamente.
Orientado a Objetos
O teste orientado a objetos consiste em realizar sequências de envios de mensagens. Essas sequências devem ser escolhidas de maneira a explorar o maior número possível de estados que um objeto possa assumir e as transições entre eles. Pode-se aplicar os testes do tipo caixa branca e caixa preta, contudo podem surgir algumas complicações como o encapsulamento e a herança. Algumas das vantagens dos testes orientados a objetos são:
- Redução no tamanho dos métodos através da utilização de heranças;
- Algoritmos menos complexos, ou seja, algoritmos com poucas linhas de código, o que aumenta a legibilidade e o entendimento do mesmo;
- Facilidade na localização e correção de defeitos;
- Encapsulamento, que previne muitos problemas causados pelo escopo de dados sem controle.
Baseado em Erros
Na técnica do teste com base em erro são procurados erros plausíveis, particularidades da implementação quem podem ocasionar defeitos. Aqui casos de teste são projetados para exercitar o projeto ou o código. Este teste é aplicado tanto a atributos quanto a operações. A determinação de erros plausíveis deve ser feita quando funções ou métodos são invocados, o comportamento da operação deve ser examinado.
O sistema deve satisfazer aos requisitos do cliente, o planejamento preliminar para criação de testes baseados em erros começa com o modelo de análise. sendo que três tipos de erros são encontrados neste contexto:
- Resultado inesperado;
- Uso da operação/mensagem errada;
- Invocação incorreta.
Essa técnica tem por objetivo verificar se o software está livre de erros típicos e comuns cometidos pelo desenvolvedor durante o ciclo de desenvolvimento de um software, especificamente durante a fase de implementação.
Base em cenário
O teste com base em cenário busca a validação do que o usuário precisar fazer em relação ao que o produto disponibiliza, ou seja, concentra-se no que o usuário faz, não no que o produto faz, detecta as tarefas por meio de casos de uso, que o usuário precisa realizar depois aplicá-las, bem como suas variantes, aos testes. Cenários descobrem erros de interação, mas para isto os casos de teste precisam ser mais complexos e mais realísticos do que os testes baseados em erro.
O tipo menos detalhado de documentação é o cenário de teste. Um cenário de teste é uma descrição de um objetivo que o usuário pode encontrar ao utilizar o programa. Tipicamente, um cenário de teste vai precisar de diferentes tipos de testes para garantir que o objetivo tenha sido bem testado. Já que os cenários de testes oferecem pouca informação sobre como completar o teste, os testadores tem uma grande flexibilização para buscar uma solução.
Assim como os casos de teste, a flexibilidade dos cenários oferecem prós e contras similares. O conhecimento de causa e as habilidades em testes podem facilitar os testadores a transformar os cenários em ideias concretas, escolher a abordagem mais lógica e rodar os testes que podem extrair os problemas importantes.
Mock Objects
Os mock objects (objetos simulados) são objetos que simulam o comportamento de objetos reais de forma controlada. São normalmente criados para testar o comportamento de outros objetos, ou seja, os mock objects são objetos “falsos” que simulam o comportamento de uma classe ou objeto “real” para que possamos focar o teste na unidade a ser testada.
Os mock objects são úteis quando os objetos reais são difíceis de criar ou impossíveis de serem incorporados no teste de unidade, em vez de usar o objeto real que faz a chamada, usa-se um mock object que simula o comportamento do objeto real.
Top comments (0)