Please enable JavaScript.
Coggle requires JavaScript to display documents.
Teste de Software - Nível de Componentes - Coggle Diagram
Teste de Software - Nível de Componentes
Verificação e Validação
Verificação: "Estamos criando o produto corretamente?"
Validação: "Estamos criando o produto certo?"
Atividades de Garantia de Qualidade (SQA)
Revisões técnicas
Auditorias de qualidade e configuração
Monitoramento de desempenho
Simulação
Estudo de viabilidade
Revisão de documentação
Revisão de base de dados
Análise de algoritmo
Teste de desenvolvimento
Teste de usabilidade
Teste de qualificação
Teste de aceitação
Teste de instalação
Importância do Teste
Último elemento para estimar a qualidade e descobrir erros
Qualidade incorporada durante o processo de engenharia de software
Testes confirmam a qualidade, mas não podem corrigir falhas de qualidade no final
Organizando o Teste de Software
Conflito de Interesses
Interesse em demonstrar que o programa funciona e está isento de erros
Tendência a projetar testes que mostram que o programa funciona
Desenvolvedores testando o próprio software
Papel do Desenvolvedor
Responsável pelo teste das unidades individuais (componentes)
Teste de integração para construção e teste da arquitetura completa do software
Grupo Independente de Teste (ITG)
Remove o conflito de interesses
Pago para encontrar erros
Colaboração com o desenvolvedor durante todo o projeto
Disponibilidade do desenvolvedor para corrigir erros encontrados
Envolvimento do ITG
Parte da equipe de desenvolvimento de software
Envolvimento durante a análise, projeto e especificação de testes
Relatório para a organização de garantia de qualidade do software
Grau de independência adquirido
Visão Global
Espirais de Desenvolvimento
Engenharia de sistemas até a codificação
Teste percorre a espiral do centro para o exterior
Teste de unidade, teste de integração, teste de validação, teste de sistema
Procedimento sequencial para testar cada componente e garantir a validação final
Critérios de "Pronto"
Desafio do Teste de Software
Questão sobre quando os testes podem ser considerados concluídos
Respostas pragmáticas e empíricas
Importância das atividades de garantia de qualidade contínua
Uso de técnicas estatísticas para determinar critérios de finalização dos testes
Planejamento e Manutenção de Registros
Estratégias de Teste de Software
Abordagem incremental vs. testes tardios
Importância do teste contínuo durante o desenvolvimento
Princípios para o Sucesso
Especificação quantificável dos requisitos do produto
Definição explícita dos objetivos do teste
Compreensão dos usuários e desenvolvimento de perfis
Ênfase no "teste do ciclo rápido"
Desenvolvimento de software robusto
Uso de revisões técnicas eficazes
Avaliação contínua da estratégia e dos casos de teste
Abordagem de melhoria contínua no processo de teste
Teste de Software Ágil
Estabelecimento do plano de teste antes do sprint
Revisão contínua do plano pelos envolvidos
Desenvolvimento e revisão contínua de casos de teste
Manutenção de Registros
Uso de documentos online para registros de testes
Exemplo de planilha no Google Docs para registro de casos de teste
Facilidade de acesso e análise durante reuniões de equipe
O papel do scaffolding
Definição
Scaffolding como estrutura temporária para criar um framework de teste
Necessidade de pseudocontrolador (driver) e pseudocontrolado (stub)
Ambiente de teste de unidade e sua ilustração na prática
Despesas indiretas associadas ao desenvolvimento de scaffolding
Importância do scaffolding para testes eficazes de componentes
Eficácia dos Custos dos Testes
Testes Exaustivos
Necessidade de processar todas as combinações possíveis de entradas e ordens de teste
Limitações e desafios de recursos para testes abrangentes
Seleção de módulos cruciais e complexos para foco dos testes de unidade
Técnicas para minimizar o número necessário de casos de teste
Projeto de Caso de Teste
Importância
Projeto prévio dos casos de teste antes do desenvolvimento do código
Assegura desenvolvimento de código que passa nos testes planejados
Requisitos e Casos de Uso
Engenharia de Requisitos
Coleta inicial com clientes para gerar histórias de usuário
Transformação em casos de uso e modelos de análise
Orientação para criação sistemática de casos de teste
Cobertura adequada de requisitos funcionais e não funcionais
Teste de Requisitos Não Funcionais
Uso de enunciados de aceitação do cliente para base dos casos de teste
Quantificação de critérios de aceitação e torná-los testáveis
Necessidade de técnicas especializadas para requisitos não funcionais
Casos de Teste Negativos
Inclusão de antirrequisitos para testar comportamentos indesejados
Uso de casos de teste negativos para garantir comportamento conforme esperado
Rastreabilidade
Importância do Rastreamento
Auditabilidade do processo de teste
Rastreamento de cada caso de teste aos requisitos ou histórias de usuário correspondentes
Desenvolvimento de um modelo de rastreamento para verificação completa
Teste de Caixa-Branca
Definição
Filosofia de projeto de casos de teste usando estrutura de controle
Objetivos de garantir cobertura de todos os caminhos independentes
Exercício de todas as decisões lógicas e ciclos dentro de limites operacionais
Verificação da validade de estruturas de dados internas
Teste de Caminho Básico
Proposta de Tom McCabe
Técnica de teste caixa-branca para medir a complexidade lógica de projetos procedimentais
Uso de grafo de fluxo para representar o fluxo de controle
Derivação de conjunto-base de caminhos de execução
Garantia de execução de todas as instruções do programa pelo menos uma vez durante o teste
Cálculo da complexidade ciclomática como métrica de software
Grafo de Fluxo
Representação
Desenho apenas quando a estrutura lógica do componente for complexa
Facilitação do seguimento dos caminhos de um programa
Caminho Independente
Definição
Caminho através do programa introduzindo novo conjunto de comandos de processamento ou condição
Inclusão de ao menos uma aresta não atravessada antes de definir o caminho
Exemplo de caminhos independentes para um grafo de fluxo dado
Complexidade Ciclomática
Métrica de Software
Medida quantitativa da complexidade lógica de um programa
Cálculo baseado no número de regiões ou nós predicados do grafo de fluxo
Limite superior para quantidade de testes necessários para abranger todos os comandos do programa
Teste de Estrutura de Controle
Variações do Teste de Estrutura de Controle
Ampliação da abrangência e melhoria da qualidade do teste caixa-branca
Discussão de técnicas adicionais como teste de condição e teste de fluxo de dados
Foco específico no teste de ciclo para validar construções de ciclo simples e aninhado
Estratégias para reduzir o número de testes necessários em ciclos aninhados
Teste de Condição
É um método de projeto de caso de teste que exercita as condições lógicas contidas em um módulo de programa.
Teste de Fluxo de Dados
Seleciona caminhos de teste de um programa de acordo com a localização de definições e usos de variáveis no programa.
Teste de Ciclo
É uma técnica de teste caixa-branca que se concentra exclusivamente na validade das construções de ciclo. Há duas diferentes classes de ciclos: ciclos simples e ciclos aninhados
Teste Caixa-Preta
Definição
Teste comportamental ou funcional que focaliza os requisitos funcionais do software
Complementa técnicas caixa-branca ao descobrir diferentes classes de erros
Encontra erros em funções incorretas ou ausentes, interfaces, estruturas de dados, desempenho, inicialização e término
Objetivos do Teste
Funções incorretas ou ausentes
Erros de interface
Erros em estruturas de dados ou acesso a bases de dados externas
Erros de comportamento ou desempenho
Erros de inicialização e término
Diferenças em Relação ao Teste Caixa-Branca
Aplicado durante estágios posteriores do teste
Desconsidera intencionalmente a estrutura de controle, focando no domínio das informações
Questões Chave
Como a validade funcional é testada?
Como o comportamento e desempenho do sistema são testados?
Quais classes de entrada farão bons casos de teste?
O sistema é particularmente sensível a certos valores de entrada?
Como as fronteiras de uma classe de dados são isoladas?
Quais taxas e volumes de dados o sistema pode tolerar?
Combinações específicas de dados terão quais efeitos sobre a operação do sistema?
Teste de Interface
Verificação de que o componente aceita informações na ordem e tipos de dados apropriados
Confirmação de que o componente retorna informações na ordem e formato de dados apropriados
Parte integrante do teste de integração, assegurando a compatibilidade com o ambiente do sistema
Uso de Pseudocontrolados e Pseudocontroladores
Importância
Facilitação do teste de componentes não independentes
Uso de stubs e drivers para simular partes do sistema
Inclusão de código de depuração para validação de dados repassados e recebidos
Particionamento de Equivalência
Método de teste caixa-preta que divide o domínio de entrada em classes de dados para criação de casos de teste
Descoberta eficiente de erros por meio de um único caso de teste representativo de uma classe de erros
Baseia-se na avaliação das classes de equivalência para condições de entrada
Derivação de classes de equivalência para valores numéricos, intervalos, conjuntos e condições booleanas
Análise de Valor Limite
Técnica de Teste
Seleção de casos de teste que usam valores limites
Complementar ao particionamento de equivalência
Diretrizes
Seleção de casos de teste nas "bordas" das classes de equivalência
Foco em valores limites para entrada e saída
Exemplo de aplicação em engenharia
Teste Orientado a Objetos
Encapsulamento
Controle das definições de classe e objetos
Empacotamento de atributos e operações
Teste de Conjunto
Comparação com Teste de Unidade Convencional
Foco nas operações encapsuladas pela classe
Controle do comportamento de estado da classe
Aplicação Bancária
Classe Conta com diversas operações
Restrições implícitas e permutações de operações
Teste Comportamental
Uso de Diagramas de Estado
Representação de transições de estados
Derivação de sequências de testes baseadas em comportamentos
Classe Conta
Diagrama de estado ilustrativo
Testes que cobrem todos os estados definidos