Este documento discute abordagens de teste de caixa branca ou teste baseado em código, com foco em técnicas como cobertura de código, fluxo de controle e fluxo de dados. Resume os principais objetivos, características e técnicas deste tipo de teste, incluindo TDD, BDD, ATDD e frameworks como JUnit e TestNG.
Information quality in personality judgment: The value of personal disclosure
Apresentação testes white box
1. Abordagens de
Testes Ágeis White Box
ou Structural Testing
ou Code-based Testing
Bárbara Palma Cabral – ISEB-ISTQB-CTFL
Analista de Testes e Qualidade de Software
barbaracabral@gmail.com
2. Características
Objetivos:
◦ Testar a lógica da implementação
◦ Cobertura com testes da estrutura interna dos componentes
Características:
◦ A base para os testes é o código fonte do objeto sob teste (Test Object)
◦ A idéia geral é exercitar cada pequena parte do código pelo menos uma
vez
◦ O resultado esperado deve ser determinado utilizando os requisitos ou
especificações (não o código) e isto é feito ao checar se o resultado de
uma execução é uma falha
3. Técnicas
Abordagens
◦ Covered-based
O alvo é cobrir com testes um certo elemento do programa
◦ Fault-based
O alvo é alcançar com testes certo s tipos de falha (ex. mutation testing)
Estas falhas são definidas nas estratégias de testes, no modelo de estratégia
de falhas
Técnicas
◦ Control flow based Testing
Statement Testing
Branch/Decision Testing
Branch Condition Testing
Modified Condition Testing
◦ Data flow based Testing
Input/output
4. Modelagem
O projeto dos casos de teste deve focar em:
◦ Exercitar caminhos independentes dentro de um
módulo ou unidade
◦ Exercitar decisões lógicas em ambos caminhos
válidos e inválidos
◦ Exercitar loops nos seus valores limites (boundaries)
◦ Exercitar estruturas internas para garantir sua
validade
Os seguintes recursos (input) são necessários:
◦ Requisitos
◦ Especificações Funcionais
◦ Documentos de modelagem de alto nível
◦ Blocos de código fonte da aplicação
5. Processo
Criar planos de Teste
◦ Identificar todos os cenários de teste e priorizá-los
Definir o perfil do bloco de aplicação dos testes
◦ Esta etapa envolve estudar o código em tempo de execução para entender a utilização
dos recursos, tempo gasto em vários métodos e operações, área do código não
acessíveis, e assim por diante
Testar as sub-rotinas internas
◦ Esta etapa garante que as subrotinas ou as interface não-públicas podem manipular
todos os tipos de dados apropriadamente
Testar loops e estados condicionais
◦ Esta etapa foca em testar os loops e mecanismos condicionais para precisão e
eficiência de cada entrada diferente de dados
Realizar testes de segurança
◦ Entendimento das possíveis brechas de segurança observando a forma como a
aplicação manipula os dados
6. Testes Unitários
O teste unitário se concentra na verificação da
menor unidade do projeto de software.
Em sistemas construídos com uso de linguagens
orientadas a objetos, como Java , essa unidade pode
ser identificada como um método, uma classe ou mesmo
um objeto.
A partir de cada uma dessas unidades pode ser
definido um conjunto de dados de entrada e saída.
◦ Entrada: parâmetros
◦ Saída: valor de retorno, exceções ou o estado do objeto.
Ferramentas de Teste Unitário simulam dados de
entrada e verificam se os dados de saída/retorno
refletem realmente o comportamento esperado
7. Agile Testing
Desenvolvimento e Testes são integrados
◦ Todos testam, não somente o testador
O testador traduz os requisitos em testes de aceitação
◦ Os testes são automatizados
O desenvolvedor realiza os testes unitários
◦ Os testes são automatizados
Características:
◦ Feedback Contínuo
◦ Entrega de valor ao cliente
◦ Comunicação face-to-face
◦ Coragem
◦ Simplicidade
◦ Resposta a mudanças
◦ Auto-organização
◦ Foco em pessoas
Fonte:
8. Abordagens
TDD – Test Driven Development
BDD – Behavior Driven Development
ATDD – Acceptance Test Driven
Development
9. Test Driven Development (TDD)
Criação dos testes antes do desenvolvimento
◦ Criar um teste simples, que irá falhar
◦ Implementar um pequeno bloco, para passar no teste
◦ Representar cada bloco de código com testes
◦ Refatorar, remover duplicidade
Tools:
◦ JUnit
◦ TestNG
◦ DBUnit
Fonte:
10. Acceptance Test Driven Development
(ATDD)
• Testes de Aceitação
– Time discute critérios através de exemplos onde todos da
equipe devem ter a mesma definição de “done”.
– Durante a reunião de planejamento (Planning Meeting)
• Tools:
– FitNesse (Framework for Integrated Testing)
– Selenium
Fonte:
11. Behavior-driven Development (BDD)
Princípios:
◦ Tudo é comportamento: A área de negócios e a de Tecnologia devem se referir para o
sistema da mesma forma;
◦ Onde está o valor do negócio: Todo sistema deve ter comportamentos que sejam um
verificador do valor para o negócio;
◦ Faça o suficiente: Analisar, projetar e planejar tudo de cima para baixo, evitando o
detalhamento prematuro.
◦ Encoraja colaboração entre os desenvolvedores, analistas, QA e o pessoal não técnico
para o sucesso do projeto.
Comportamento?
◦ Um comportamento é descrito através de uma história (User Story)
Tools:
◦ Cucumber
◦ JBehave
◦ SpecFlow
◦ Selenium
12. Método
Cada user story deve ser transformada em um teste de
aceitação
User Story
Funcionalidade: Tela de login
Como um usuário
Eu quero incluir meus dados
De modo que eu consiga acessar o sistema
Teste de Aceitação baseado em comportamento
Cenário: O usuário acessa o sistema
Dado que eu estou na tela de login
Quando eu informo meu login “teste” e minha senha “1234”
E clico em “Acessar”
Então o sistema exibe a página principal