"Dar mais atenção à execução dos testes do que ao projeto deles é um erro clássico." Brian Marick
O ciclo de vida do processo de teste é formado por várias etapas. Veja um modelo de macro atividades. Modelo 3P x 3E.
-->
Fluxo básico de atividades
Papéis envolvidos no processo de teste
A norma IEEE 829 apresenta um conjunto de documentos para as atividades de teste:
-->
-->
Padrões de Plano de Testes
-->
Equivalência de Padrões de Teste
Síntese - Um projeto de casos de teste visa projetar casos de entradas e saídas esperadas que testam o sistema.
Meta - criar um conjunto ce casos de teste eficazes para descobrir defeitos do programa e demonstrar que o sistema atende aos requisitos.
Como fazer?
Selecione uma caracteristica do sistema ou do componente que você vai testar.
Depois selecione um conjunto de entradas para executar aquelas características.
Documente as saídas esperadas.
-->
O ciclo de vida do processo de teste é formado por várias etapas. Veja um modelo de macro atividades. Modelo 3P x 3E.
Planejar - selecionar produtos e componentes e requisitos que serão testados.
Projetar - prepara o ambiente onde os testes serão executados.
Elaborar – implementar scripts manuais ou automáticos, programas e massas de dados.
Executar - os testes são executados e relatórios são gerados para posterior avaliação.
Avaliar resultados - gera um relatório consolidado dos erros mediante os relatórios gerados. A partir deste o líder toma conhecimento dos erros encontrados ou ocorridos para que possam ser iniciados os acertos necessários.
Fluxo básico de atividades
Papéis envolvidos no processo de teste
A norma IEEE 829 apresenta um conjunto de documentos para as atividades de teste:
Plano de teste – apresenta o planejamento para a execução de teste incluindo abrangência, abordagem, recursos e cronograma. Identifica os itens e as funcionalidades a serem testadas, as tarefas a serem realizadas e os riscos relacionados a atividade de teste.
Especificação de teste – coberta por 3 documentos:
Especificação do projeto de teste – refina a abordagem apresentada no plano de teste, identifica as funcionalidades e características a serem testadas pelo projeto e seus testes associados. Também identifica os casos e procedimentos de testes e apresenta critérios de aprovação. Em alguns casos é incluído ou incorporado ao plano de testes.
Especificação do caso de teste – define os casos de testes incluindo dados de entrada, resultados esperados, ações e condições gerais para os testes.
Especificação de procedimento de teste – especifica os passos para executar os procedimentos de casos de teste.
Relatórios de testes cobertos por 4 documentos:
Diário de teste – documenta qualquer evento que ocorra durante a atividade de teste e que requeira analise posterior.
Relatório Resumo de Teste – apresenta de forma resumida os conceitos das atividades de teste associados com uma ou mais especificações de projeto de testes e prove avaliações baseadas nesses resultados.
Relatório de encaminhamento de item de teste - identifica os itens encaminhados para teste no caso de equipes distintas de desenvolvimento e teste.
Relatório de incidente de teste – todos os defeitos encontrados durante o teste são registrados e passados para a equipe de desenvolvimento para as devidas correções.
É recomendável colocar um software que gerencie os defeitos.
-->
Plano de testes
Descreve o planejamento para execução do teste, incluindo a estratégia de testes, abrangência, abordagem, recursos e cronograma das atividades de teste. Identifica os itens e as funcionalidades a serem testadas, as tarefas a serem realizadas e os riscos associados com a atividade de teste.
-->
PMI – aplicado a qualquer tipo de projeto.
QAI e IEEE 829 – são adaptações do modelo PMI para projetos de testes.
Síntese - Um projeto de casos de teste visa projetar casos de entradas e saídas esperadas que testam o sistema.
Meta - criar um conjunto ce casos de teste eficazes para descobrir defeitos do programa e demonstrar que o sistema atende aos requisitos.
Como fazer?
Selecione uma caracteristica do sistema ou do componente que você vai testar.
Depois selecione um conjunto de entradas para executar aquelas características.
Documente as saídas esperadas.
-->
Caso de Teste
É a base para a execução dos testes pelos testadores.
Finalidade avaliar os requisitos especificados do sistema.
Envolvem:
-Entrada de dados
-Condições de execução
-Resultados esperados
Os casos de teste são elaborados com o auxilio das técnicas de teste, estas satisfazem os objetivos globais das estratégias de teste.
Cenário de teste (CE) – situação a ser testada. Podemos ter n’ casos de teste (CT).
Requisitos – casos de uso (CSU) – Cenário de Teste (CNT).
Vide os documentos de especificações da norma IEEE 829.
Segundo norma IEEE 829 o CT deve ter: tipo de caso, revisões, número, entre outros itens.
Execução dos testes
Teste estático – código é examinado, (Etapa: Verificação).
Métodos:
– walkthrough – revisão formal (por um grupo de pessoas – reuniões).
- Pair Programming – inspeções e programas em pares.
Teste dinâmico – validação do código, em módulos e na integração (Etapa: Validação).
Níveis de Teste: Unitário
Integrado
Sistema
Aceitação
Fases:
Preparar dados de teste – CT;
Executar testes – de acordo com o roteiro de teste;
Solucionar Ocorrências;
Elaborar relatórios finais;
Acompanhar a execução de teste.
Insumos:
CT
Estratégia
Plano de teste
Dados de teste
Ambiente de teste
Produtos:
Log de teste – registra a execução dos casos de teste;
Relatório de Ocorrências;
Resumo dos testes.
Para cada CT – um relatório de ocorrências.
Para cada PT – Resumo de teste.
Relatórios de Resultados de teste:
Norma IEEE 829
De Log – junto com o CT
Ocorrência – semelhante ao CT
Teste
Técnicas de Teste – gera os casos de teste
Nas aplicações convencionais:
Cx Branca – testa o código
Cx Preta – testa os requisitos
Teste Cx Preta – teste comportamental – aplicado ao último estágio do teste.
Teste baseado em grafo – analisa os relacionamentos em objetos (de dados, componentes (módulos) e elementos O.O.
Métodos:
-modelagem de fluxo de transação – passos para realizar uma operação. Use DFD (diagrama de fluxo de dados).
-modelagem de estado finito – nós representam as telas abertas em uma operação, as ligações são as transições entre telas. Use o diagrama de estado.
-modelagem de fluxo de dados – nós objetos de dados e as ligações são transformações que ocorrem para traduzir um objeto de dados em outro.
-modelagem de tempo – nós (objetos de programas, ligações, conexões seqüenciais entre estes objetos). O peso das ligações são usados para especificar o tempo de execução necessário para executar o programa.
Particionamento de equivalência – conjunto de dados válidos e inválidos para condições de entradas.
Análise de Valor Limite (BVA) – completa o particionamento de equivalência.
Testes de Matriz Ortogonal -
Este tipo de teste é aplicado a problemas nos quais o domínio de entrada é relativamente pequeno, mas grande demais para acomodar o teste exaustivo, é útil para encontrar erros associados com falhas de regiões – uma categoria de erros associada com lógica defeituosa em um componente de software.
Exemplo: considere um sistema que tem três itens de entrada: X, Y e Z, cada um desses itens de entrada possui três valores discretos associados a eles. Há então 3^3 = 27 possíveis casos de teste.
Quando o teste de matriz ortogonal ocorre, é criada uma matriz ortogonal L9 de casos de teste, com a propriedade de balanceamento.
A avaliação dos resultados de um caso de teste utilizando a matriz L9 ocorre do seguinte modo:
Detecta e isola todas as falhas de modo singular – uma falha de modo singular é um problema consistente com qualquer nível de qualquer parâmetro singular, exemplo se todos os casos de teste do fator P1 = 1 causam um erro de condição, temos uma falha de modo singular. Pela análise da informação sobre quais testes revelam erros, pode-se identificar quais valores de parâmetros causam a falha, este tipo de isolamento é importante para corrigir a falha.
Detecta todas as falhas de modo duplo – falha de modo duplo consiste se existe um problema consistente quando níveis específicos de dois parâmetros ocorrem simultaneamente. É uma indicação de incompatibilidade do par ou de interações danosas entre dois parâmetros de teste.
Falhas de multímodo – tais matrizes podem garantir a detecção apenas de falhas de modo singular e duplo. No entanto, muitas falhas de multímodo são também detectadas por esses testes.
Vale ressaltar que este tipo de teste permite projetar casos de teste que fornecem máxima cobertura com um número razoável de casos de teste, do que a estratégia exaustiva.
Teste aleatório para classe OO
Teste aleatório para classe OO
Para cada classe defini as possíveis operações da mesma aplicando algumas restrições de acordo com a natureza do problema, mesmo com tais restrições existe muitas permutações das operações. Gerando assim uma variedade de diferentes seqüências de operação que pode ser gerada aleatoriamente.
Para este tipo de teste o número de permutações possíveis pode ficar muito grande, aplicar o teste de matriz ortogonal pode ajudar a melhorar a eficiência deste teste.
Teste baseado em erro –
Teste baseado em cenário – concentra no que o usuário faz. Utiliza o CSU.
Teste da estrutura superficial (1) e profunda (2) –
(1) Os testes são baseados nas tarefas dos usuários.
(2) Refere-se a detalhes técnicos internos de um programa (exame do projeto e/ou código). Uso da UML (diagrama de colaboração) ou modelo de implantação.
Testes aplicáveis ao nível de classe
1) Teste aleatório para classe OO
A abordagem para o teste de partição de várias classes é semelhante à abordagem usada para o teste de partição de classes individuais, sendo uma única classe particionada. A seqüência de teste são expandidas para incluir aquelas operações invocadas por meio de mensagens para as classes colaboradoras, onde uma abordagem alternativa particiona os testes com base nas interfaces de uma classe particular.
Segue abaixo uma seqüência de passos para gerar casos de teste aleatórios para várias classes:
Para cada classe cliente, use a lista de operações de classe para gerar uma série de seqüências de teste aleatório. As operações vão enviar mensagens para outras classes servidoras.
Para cada mensagem gerada, determine a classe colaboradora e a operação correspondente no objeto servidor.
Para cada operação no objeto servidor (que foi invocado por mensagens enviadas pelo objeto cliente), determine as mensagens que ele transmite.
Para cada uma das mensagens, determine o nível seguinte de operações que são invocadas e incorpore-as à seqüência de teste.
2) Teste de partição do nível de classe
Este tipo de teste reduz o número de casos de teste necessários para exercitar a classe de um modo semelhante ao da partição de equivalência para software convencional. Entrada e saída são categorizadas e casos de testes são projetados para exercitar cada categoria. Veja as categorias de partição:
Partição baseada em estado – categoriza as operações de classes com base na sua capacidade de mudar o estado da classe. Os testes são projetados de modo que exercitem, separadamente as operações que mudam o estado e aquelas que não mudam o estado.
Partição baseada em atributo - categoriza as operações de classes com base nos atributos que elas usam que podem ser divididas em: operações que usam, operações que modificam e operações que não usam e nem modificam.
Seqüências de teste são então projetadas para cada partição.
Partição baseada em categoria - categoriza as operações de classes com base na função genérica que cada uma realiza.
Projeto de classe de teste Interclasse
Aqui observamos as classes e suas colaborações (uso do diagrama de colaboração).
1) Testes de várias classes
2) Testes derivados dos modelos de comportamento.
Teste de ambientes, arquiteturas e aplicações especializadas
Teste de IGU
Teste de arquiteturas cliente/servidor
Teste de função da aplicação
Teste de servidor
Teste de BD
Testes de transação
Testes de comunicação em rede
O teste cliente/servidor ocorre em três níveis:
Aplicações clientes individuais são testadas no modo “não conectado”, a operação do servidor e a rede subjacente não são consideradas;
O software cliente e as aplicações do servidor associadas são testadas em conjunto, mas as operações da rede não são explicitamente exercitadas;
A arquitetura completa cliente/servidor, incluindo operações e desempenho da rede, é testada.
Teste de documentação e dispositivo de ajuda
Teste de sistema de tempo real
Teste de tarefa
Comportamental
Intertarefas
Sistema
Teste Cx Branca
Teste de caminho básico
Notação de grafo de fluxo;
Caminhos independentes de programa;
Derivação de casos de teste.
Teste de estrutura de controle
Teste de condição
Teste de fluxo de dados
Teste de ciclo
