Abordagens de Testes Ágeis White Box

ou Structural Testingou Code-based Testing

Bárbara Palma Cabral – ISEB-ISTQB-CTFLAnalista de Testes e Qualidade de Software

barbaracabral@gmail.com

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

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

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

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

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

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:

Abordagens

TDD – Test Driven DevelopmentBDD – Behavior Driven

DevelopmentATDD – Acceptance Test Driven

Development

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:

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:

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

Método

Cada user story deve ser transformada em um teste de aceitação

User StoryFuncionalidade: Tela de login

Como um usuárioEu quero incluir meus dadosDe modo que eu consiga acessar o sistema

Teste de Aceitação baseado em comportamentoCenário: O usuário acessa o sistema

Dado que eu estou na tela de loginQuando eu informo meu login “teste” e minha senha “1234”E clico em “Acessar”Então o sistema exibe a página principal

Pirâmide dos Testes Automatizados

Tester

Developer

Fonte:

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/