Análise e Modelagem de Teste

Divide os dados em partições (partições de equivalência), onde todos os elementos desta partição serão processados da mesma forma pelo objeto de teste, ou seja, se um defeito for detectado para um valor, o mesmo defeito também será detectado para outros valores da mesma partição.

Qualquer elemento de dados pode ser particionado. Ex.: Entradas, saídas, itens de configuração, valores internos, relacionados ao tempo e parâmetros de interface.

Podem ser divididas em Partições Válidas e Partições inválidas. As partições válidas contém valores válidos que devem ser processados pelo objeto de teste. As partições inválidas contém valores inválidos que devem ser ignorados ou rejeitados pelo objeto de teste.

Each Choice Coverage (ECC): Cobertura de Cada Escolha, é um critério de cobertura simples, no qual exige que os casos de teste executem cada partição de cada conjunto de partições pelo menos uma vez.

Os itens de cobertura são as partições de equivalência que foram identificadas. Para 100% de cobertura, os casos de teste devem executar todas as partições (válidas e inválidas), pelo menos 1 vez. O resultado é expresso em porcentagem, sendo a fórmula: O Número de Partições Executadas dividido pelo Número Total de Partições existentes, no qual o resultado representado pela letra 'Y', será convertido em porcentagem resultando na porcentagem de Cobertura alcançada pelo Particionamento de Equivalência, representado pela letra 'C'

É baseada na execução dos limites de valor das partições de equivalência. Os valores mínimo e máximo de uma partição são seus valores de limite, onde os desenvolvedores tem maior probabilidade de cometer erros. Existe a BVA de 2 valores e a BVA de 3 valores.

BVA de 2 valores:

• Para cada valor limite há dois itens de cobertura, sendo o valor limite e seu vizinho mais próximo pertencente a partição seguinte (vizinha).
• Para atingir 100% de cobertura todos os valores limites identificados devem ser executados.

A cobertura é medida da seguinte forma e expressa em porcentagem (C): Número de Valores limites executados, dividido pelo número total de valor limite identificado (Y).

BVA de 3 valores:

• Para cada valor limite há três itens de cobertura, sendo o valor limite, seu vizinho da partição seguinte e seu vizinho da mesma partição.
• Para atingir 100% de cobertura todos os valores limites e seus vizinhos devem ser executados.

A cobertura é medida da seguinte forma e expressa em porcentagem (C): Número de Valores limites executados mais seus vizinhos, dividido pelo número total de valor limite identificado mais seus vizinhos (Y)

O exemplo a seguir mostra como o BVA de 3 valores tem uma cobertura maior que o BVA de 2 valores, pois abrange não apenas seu vizinho adjacente da próxima partição, mas também seu vizinho da mesma partição:

É uma forma eficaz de registrar regras complexas como as Regras de Negócios. Nesta tabela são definidas condições e ações resultantes do sistema. Uma tabela completa cobre todas as combinações de condições, mas pode ser simplificada excluindo ou fundindo condições inviáveis ou que não afetam o resultado.

	Ação 1	Ação 2
Condição 1	Resultado 1.1	Resultado 1.2
Condição 2	Resultado 2.1	Resultado 2.2

Linha: Condições e seus resultados de acordo com a ação, chamados de Ações Resultantes.
Coluna: Regra de decisão (combinação única de decisão) e Ações Associadas.

Aqui serão tratados dois tipos de tabelas de decisão, são elas:

• Entrada Limitada: Todos os valores das Condições e Ações são mostrados como Verdadeiro e Falso (Booleano). Exceto os valores irrelevantes ou inviáveis.
• Entrada Estendida: Alguns ou todos os valores das Condições e Ações podem apresentar valores múltiplos (ex.: intervalos).

As notações podem ser :

Notação	Significado
V	Verdadeiro. A ação foi satisfeita.
F	Falso. A ação não foi satisfeita.
—	O valor da condição é irrelevante para o resultado.
N/A	Não Aplica. A condição é inviável para regra.
X	A ação deve ocorrer.
	Em branco. A ação não deve ocorrer.

A cobertura é feita nas colunas que tem combinações viáveis. Para atingir 100%, todas as colunas devem ser executadas, sendo medida da seguinte forma: O Número total de colunas executadas é dividido pelo total de colunas viáveis, sendo o resultado representado pela letra 'Y', e então espresso na forma de porcentagem, representado pela letra 'C'.

Modela o comportamento de um sistema, mostrando seus possíveis estados e suas transições. A transição é acionada por um evento, qualificada por uma Condição de Proteção que pode ou não existir.

Podemos utilizar um diagrama ou uma tabela para representar os testes de transição de estado, ele representa uma sequência de eventos, que pode resultar em uma sequência de alterações. Um caso de teste pode abranger várias transições entre estados.

• Diagrama de Transição de Estado: Mostra apenas as transições válidas em forma de diagrama.
  
• Tabela de Transição de Estado: Baseada no Diagrama mostra as transições válidas e inválidas em forma de tabela.

  	Evento 1	Evento 2
  Estado 1	Transição 1.1	Transição 1.2
  Estado 2	Transição 2.1	Transição 2.2

  Coluna: Eventos e Condição de Proteção (se existir);
  Linha: Estados;
  Célula: transição, estado de destino e ações resultantes;

Exemplo: Uma lâmpada que evolui entre os estados “acesa” e “apagada”, conforme se liga e desliga um interruptor. "N/A" ou "Não se Aplica", representa os estados inválidos.
No Diagrama:

Na Tabela:

	Desligar	Ligar
Desligada	N/A	Ligada
Ligada	Desligada	N/A

A cobertura pode ser abordada de diferentes formas, aqui iremos falar de três, são elas:

• Cobertura de todos os estados: Os itens de cobertura são os estados. Para garantir 100% de cobertura, todos os estados devem ser visitados. A fórmula é:
  
  $\frac{\mathrm{Nº\; Estados\; Visitados}}{\mathrm{Nº\; Total\; de\; Estados}}=\mathrm{Y}$

  →

  $\frac{\mathrm{Y}*100}{\mathrm{Nº\; Total\; de\; Estados}}=\mathrm{C\%}$
  
  
• Cobertura de transições válidas (0-switch): Os itens de cobertura são todas as transições válidas. Para garantir 100% de cobertura, todas as transições válidas devem ser executadas. A fórmula é:
  
  
  $\frac{\mathrm{Nº\; Transições\; Válidas\; Executadas}}{\mathrm{Nº\; Total\; Transições\; Válidas}}=\mathrm{Y}$

  →

  $\frac{\mathrm{Y}*100}{\mathrm{Nº\; Total\; Transições\; Válidas}}=\mathrm{C\%}$
  
  
• Cobertura de todas as transições: Os itens de cobertura são todas as transições (válidas e inválidas), mostradas em uma tabela de estado. Para garantir 100% da cobertura, todas as transições devem ser executadas. A fórmula é:
  
  
  $\frac{\mathrm{Nº\; Transições\; Executadas}}{\mathrm{Nº\; Total\; Transições}}=\mathrm{Y}$

  →

  $\frac{\mathrm{Y}*100}{\mathrm{Nº\; Total\; Transições}}=\mathrm{C\%}$

A cobertura mais abrangente é a cobertura de todos as transições, logo em seguida a de transições válidas, após ela a de todos os estados. Isso se deve ao fato de que alguns estados podem ser alcançados sem necessariamente executar todas as transições, e ao executar todas as transições, tanto válidas quanto as inválidas, posso evitar o mascaramento de falhas e visitar todos os estados.

O objetivo é criar casos de teste que executem as instruções do código até um nível aceitável de cobertura. Uma instrução isolada em um caso de teste pode não detectar alguns defeitos associados que dependam de dados específicos, por exemplo um defeito que somente é detectado com o valor de entrada '1', mas o caso de teste referente a essa instrução tem como valor de entrada '2'.

100% de cobertura de Instrução significa que todas as intruções do código foram executadas ao menos uma vez, mas não garante que toda a lógica de decisão tenha sido testada. Exemplo: Uma instrução (função) tem uma condição (decisão) representada por um 'if' e um 'else', ao executar essa instrução pode ser que o 'if' seja executado, entretanto o 'else' não, sendo assim nem toda decisão dentro da instrução será coberta.

A cobertura é equivalente ao número de instruções executadas pelos casos de teste, dividida pelo número total de instruções executáveis no código, é representada em porcentagem:

Ramificação: É a transferência de controle entre dois nós no gráfico de fluxo de controle, ou seja, mostra as possíveis sequências nos quais as instruções do código-fonte são executadas. Cada transferência pode ser incondicional ou condicional, podendo representar uma lógica de decisão.

Uma ramificação executada pode não detectar defeitos em casos que exijam a execução de um caminho especifico no código.

100% de cobertura de Ramificação é igual a 100% de cobertura de instrução, mas não o contrário. Os itens de cobertura são ramificações, e o objetivo é criar casos de teste para executar todas até um nível aceitável de cobertura. A cobertura é medida da seguinte forma, onde o número total de ramificações executadas pelos casos de teste é dividido pelo número total de ramificações existentes, sendo expressa em porcentagem.

A implementação dos códigos é levada em consideração durantes os testes, o que ajuda na detecção de defeitos quando a especificação do software é vaga, desatualizada ou incompleta. Pode ser utilizada em testes estáticos, como execuções secas de código, são adequadas para revisar códigos prontos para execução, pseudocódigos e outras lógicas de alto nível.

Caso não tenha requisitos implementados esta técnica de teste não poderá detectar defeitos.

Ao contrário das técnicas de teste Caixa-preta, as técnicas de teste Caixa-branca fornecem cobertura real do código, com medidas objetivas que aumentam a confiança no código.

Técnica usada para prever a ocorrência de erros, defeitos e falhas com base no conhecimento do testador, podem estar relacionados a entrada, saída, lógica, cálculo, interface e dados. A experiência inclui:

• Como o aplicativo funcionou no passado.
• Os tipos de erros e seus defeitos que os desenvolvedores tendem a cometer.
• Tipos de falhas que ocorrem em outros aplicativos semelhantes.

O Ataque de Falhas é uma abordagem da Suposição de Erro no qual garante que o testador crie uma lista de possíveis erros, defeitos e falhas e então modele os testes para capturá-los.

Tem o objetivo de aprendizagem sobre o objeto de teste. Os testes são modelados, executados e analisados simultaneamente para o aprendizado.

O teste é baseado em sessões, onde cada sessão tem :

• Um período de tempo definido
• Uma carta de teste que contém os objetivos do teste
• Uma reunião depois da sessão onde é discutido os resultados do teste
• Os itens de cobertura são identificados durante a sessão de teste

São muito úteis quando há pouca especificação ou quando ela é inadequada, ou quando há uma significativa pressão de tempo. Complementa técnicas mais formais, como a de particionamento de equivalência. É mais eficaz com um testador experiente, com domínio e habilidades analíticas, curiosidade e criatividade.

O testador modela, executa e implementa os testes baseado em uma lista de verificação, também chamado de Checklist. Essa lista pode ser baseada na experiência do testador, no conhecimento do que é importante para o usuário ou em como o software costuma falhar.

Geralmente é feita em forma de perguntas, deve verificar cada item separadamente e podem ser criadas para dar suporte a vários tipos de teste, incluindo funcionais e não funcionais, como exemplo de teste não funcional temos as 10 heurísticas para teste de usabilidade de Nielsen.

Não deve conter itens que possam ser: Avaliados automaticamente, itens com critérios de entrada/saída ou itens muito gerais.

É necessário atualizar a lista constantemente, pois os mesmos erros podem não ser mais cometidos. Na ausência de casos de teste detalhados é uma boa prática, aumentando a cobertura e tendo menos repetibilidade.

História de Usuário é um recurso valioso para o usuário/comprador do software. Tem 3 aspectos críticos chamados de '3C', são eles:

• Cartão: meio que se descreve uma história de usuário
• Conversação: explicação de como o software será utilizado
• Confirmação: os critérios de aceite

O formato mais comum de escrita é:
Como [ator ou persona] eu quero [meta a ser cumprida] para que eu possa [valor de negócio resultante da função]

Pode ser usuado brainstorming e mapeamento mental para escrita colaborativa, o que permite a visão compartilhada do que deve ser entregue, levando em consideração: negócios, desenvolvimento e testes.

Boas histórias de usuários devem ser: Independentes, negociáveis, valiosas, estimáveis, pequenas e testáveis. Se um stakeholder não souber testar a história de usuário provavelmente ela deve ser revisada novamente.

Geralmente são resultados da escrita colaborativa. São condições que uma história de usuário deve atender para ser aceita pelos stakeholders e serem executadas pelos testes.

São usadas para:

• Definir o escopo da história de usuário
• Chegar a um consenso entre os stakeholders
• Descrever os cenários positivos e negativos
• Servir como base para o teste de aceite da história de usuário
• Permitir planejamento e estimativas precisas

Os formatos mais comuns de escrever critérios de aceite para histórias de usuário são:

• Orientado a Cenário (Ex.: BDD)
• Orientado por Regras (Ex.: lista de pontos de verificação)

Eles devem ser bem definidos e não ambíguos.

É uma abordagem que prioriza os testes.

Os casos de teste são criados antes da implementação da história de usuário. Podem ser executados de forma manual ou automatizada.

As etapas são :

1. ª etapa: A história de usuário (se definida) e seus critérios de aceite são analisados, discutidos e escritos pelos membros da equipe. Lacunas, ambiguidades e defeitos são corrigidos nesta etapa.
2. ª etapa: Criação dos casos de teste, no qual são baseados nos critérios de aceite e podem ser visto como exemplo de como o software funciona. Ajudando a equipe a implementar corretamente a história de usuário.

Durante o projeto de teste, as técnicas de teste Caixa-preta, Caixa-branca e Baseada na Experiência podem ser utilizadas.

No passo a passo, os primeiros casos de teste são positivos, confirmando o comportamento correto. Em seguida, a equipe deve realizar os testes negativos. Depois a equipe deve cobrir as características de qualidade não funcional.

• A linguagem utilizada normalmente é natural, para melhor compreensão dos stakeholders.
• Abrange todas as características das histórias de usuários, não indo além delas, mas podendo expor seus problemas.
• Dois casos de teste não devem descrever as mesmas características.
• Na automação os desenvolvedores escrevem o código de suporte a medida que implementam o recurso, tornando os testes requisitos executáveis.