Please enable JavaScript.
Coggle requires JavaScript to display documents.
4) Análise e Modelagem de Teste - Coggle Diagram
4) Análise e Modelagem de Teste
4.4 Técnicas de Teste Baseadas na Experiência
4.4.2 Testes Exploratórios
Essa abordagem complementa testes formais e é mais eficaz quando realizada por Testadores experientes, com habilidades analíticas, criatividade e conhecimento do domínio
Pode ser estruturado por sessões de teste, que seguem um período definido e usam uma carta de teste com objetivos para guiar o processo
Ele é útil quando há pouca documentação ou pouco tempo para testes
Consiste em modelar, executar e avaliar testes simultaneamente, enquanto o Testador aprende sobre o sistema
4.4.1 Suposição de Erro
A abordagem
ataques a falhas
complementa essa técnica, criando testes que identificam, expõem ou causam falhas, a partir de listas de possíveis defeitos baseadas na experiência, dados históricos ou conhecimento comum
Falhas em aplicativos semelhantes.
Erros comuns cometidos por desenvolvedores;
Funcionamento anterior do aplicativo;
É uma técnica usada para prever erros, defeitos e falhas em um software, baseada no conhecimento do testador
4.4.3 Testes baseados em Lista de Verificação
Usam listas de itens que o Testador deve verificar para garantir a qualidade do software
As listas são criadas com base na experiência, no conhecimento do usuário e nas falhas comuns do software
Os itens geralmente são perguntas específicas sobre requisitos, interface gráfica ou características de qualidade, cobrindo testes funcionais e não funcionais
4.5. Abordagens de Teste Baseadas na colaboração
4.5.3 Desenvolvimento Orientado por Teste de Aceite (ATDD)
Os testes devem:
Não descrever a mesma funcionalidade em dois casos diferentes.
Cobrir todas as características da história, sem ir além dela;
Ser claros para os stakeholders;
Ex: Como cliente, quero realizar login na plataforma para acessar meu perfil
O processo envolve:
Criação dos casos de teste: baseados nos critérios de aceite, cobrindo cenários positivos, negativos e características não funcionais (como performance e usabilidade).
Workshop de especificação: análise e definição da história de usuário e seus critérios de aceite pela equipe (clientes, desenvolvedores e Testadores).
1) Dado que o usuário informa um e-mail e senha corretos 2) Quando clica no botão de login
3) Então deve ser redirecionado para a página inicial
É uma abordagem que prioriza a criação de casos de teste antes da implementação da história de usuário
4.5.2 Critérios de Aceite
Os formatos mais comuns são:
Regras (listas de verificação ou tabelas de entrada e saída).
Cenários (Given/When/Then), usado no BDD;
Permitir planejamento e estimativas precisas.
Basear os testes de aceite;
Descrever cenários positivos e negativos;
Alinhar expectativas entre stakeholders;
Definir o escopo da história;
Definem as condições que a implementação de uma história de usuário deve atender para ser aceita pelos stakeholders, funcionando como condições de teste
4.5.1 Escrita colaborativa de histórias de usuários
Se não forem testáveis, podem estar mal definidas ou sem valor claro
Elas devem seguir o princípio INVEST: Independentes, Negociáveis, Valiosas, Estimáveis, Pequenas e Testáveis
Histórias de usuários são criadas de forma colaborativa, considerando negócios, desenvolvimento e testes
"Como [ator], quero [meta], para que [valor de negócio]"
Confirmação: critérios de aceite para validar a entrega.
Conversação: explicação sobre como o software será usado;
Cartão: descrição breve da história (em papel ou digital);
4.1 Visão geral das técnicas de teste
Baseadas na Experiência
Utilizam o conhecimento do testador para encontrar defeitos que outras técnicas podem não detectar, sendo complementares às demais abordagens
Caixa-Branca
Dependem da estrutura interna do software e só podem ser criadas após seu projeto ou implementação
Caixa-Preta
Baseadas no comportamento do software sem considerar sua estrutura interna, permitindo reutilização mesmo após mudanças na implementação
4.3 Técnicas de Teste Caixa-Branca
4.3.3 O valor do Teste Caixa-Branca
Essas técnicas podem ser aplicadas em
testes estáticos
, como revisões de código e execuções secas, e são úteis para avaliar pseudocódigo e lógicas modeladas em fluxogramas.
No entanto, não identificam requisitos ausentes
Analisa toda a implementação do software, facilitando a detecção de defeitos mesmo quando a especificação é incompleta ou desatualizada
4.3.2 Teste de Ramificação e Cobertura de Ramificação
Além disso, a cobertura de ramificação sempre inclui a cobertura de instrução, mas o inverso não é verdadeiro
Isso não assegura a detecção de todos os defeitos, especialmente aqueles que dependem da execução de caminhos específicos
Alcançar 100% de cobertura de ramificação garante que todas as decisões do código foram testadas, incluindo ambos os resultados de condições (true e false)
O teste de ramificação mede a cobertura das transferências de controle no código, considerando tanto ramificações condicionais (ex.: if, switch/case, loops) quanto incondicionais
4.3.1 Teste de Instrução e Cobertura de Instrução
Isso não assegura que todos os erros serão detectados, especialmente aqueles dependentes de dados ou relacionados à lógica de decisão
Uma cobertura de 100% garante que todas as instruções foram executadas pelo menos uma vez, aumentando a chance de identificar defeitos
O teste de instrução mede a cobertura das instruções executáveis no código, expressa em porcentagem
4.2 Técnicas de Teste Caixa-Preta
4.2.4 Teste de Transição de Estado
A cobertura de
todos os estados
é mais fraca que a de
transições válidas
, que é a mais utilizada. A cobertura de
todas as transições
é essencial para softwares críticos
Cobertura de todas as transições
: Testa todas as transições válidas e também tenta executar as inválidas.
Cobertura de transições válidas (0-switch)
: Testa todas as transições permitidas.
Cobertura de todos os estados
: Testa se todos os estados foram visitados.
O
Diagrama de Transição de Estado
modela o comportamento do sistema, mostrando estados possíveis e transições válidas, acionadas por eventos e, às vezes, acompanhadas de condições e ações
4.2.3 Teste de Tabela de Decisão
Ajuda a detectar lacunas ou contradições nos requisitos.
Identifica todas as combinações possíveis, evitando testes negligenciados.
As ações usam "X" para indicar que devem ocorrer e espaço em branco para indicar que não devem.
As condições podem ser booleanas (V para verdadeiro, F para falso) ou podem ter múltiplos valores (intervalos, partições de equivalência etc.).
Define-se uma tabela, onde:
Linhas
representam condições e ações do sistema.
Colunas
representam regras de decisão, ou seja, combinações específicas de condições e suas ações correspondentes.
É uma técnica usada para verificar a implementação de requisitos que envolvem diferentes combinações de condições e seus resultados
4.2.2 Análise de Valor de Limite (BVA)
BVA de 3 valores
Para cada valor de limite, são testados o valor de limite e seus dois vizinhos
BVA de 2 valores
Para cada valor de limite, são testados o valor de limite e o valor adjacente da partição próxima
Só pode ser aplicada a partições ordenadas
É uma técnica de teste baseada na execução dos limites das partições de equivalência
4.2.1 Particionamento de Equivalência (EP)
No caso de múltiplos conjuntos de partições (como múltiplos parâmetros de entrada, ex. sexo e idade), a Each Choice Coverage (ECC) exige que cada partição seja testada ao menos uma vez, sem considerar combinações
Para 100% de cobertura, todas as partições devem ser testadas pelo menos uma vez. A cobertura é expressa como a porcentagem de partições testadas
Partições válidas contêm valores que devem ser processados, enquanto partições inválidas contêm valores que devem ser ignorados ou rejeitados
Partições podem ser contínuas/discretas, ordenadas/não ordenadas, finitas/infinitas e não devem se sobrepor
Divide os dados em partições de equivalência, onde todos os valores dentro de uma partição devem ser processados da mesma forma pelo objeto de teste