Upload
barbara-cristina-palma-cabral-da-conceicao-istqb-ctfl
View
205
Download
0
Embed Size (px)
Citation preview
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
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/