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.

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

13. Pirâmide dos Testes Automatizados
Tester
Developer
Fonte:

14. Frameworks
 Junit 4 ou TestNG
◦ Ambos integram com Maven, Spring, Cucumber,
Selenium, DBUnit, Emma Test Coverage
◦ Diferenças:
Detalhes em: http://www.mkyong.com/unittest/junit-4-vs-testng-comparison/