Abordagens de
Testes Ágeis White Box
ou Structural Testing
ou Code-based Testing
Bárbara Palma Cabral – ISEB-ISTQB-CTFL
An...
Características
 Objetivos:
◦ Testar a lógica da implementação
◦ Cobertura com testes da estrutura interna dos componente...
Técnicas
 Abordagens
◦ Covered-based
 O alvo é cobrir com testes um certo elemento do programa
◦ Fault-based
 O alvo é ...
Modelagem
 O projeto dos casos de teste deve focar em:
◦ Exercitar caminhos independentes dentro de um
módulo ou unidade
...
Processo
 Criar planos de Teste
◦ Identificar todos os cenários de teste e priorizá-los
 Definir o perfil do bloco de ap...
Testes Unitários
 O teste unitário se concentra na verificação da
menor unidade do projeto de software.
 Em sistemas con...
Agile Testing
 Desenvolvimento e Testes são integrados
◦ Todos testam, não somente o testador
 O testador traduz os requ...
Abordagens
 TDD – Test Driven Development
 BDD – Behavior Driven Development
 ATDD – Acceptance Test Driven
Development
Test Driven Development (TDD)
 Criação dos testes antes do desenvolvimento
◦ Criar um teste simples, que irá falhar
◦ Imp...
Acceptance Test Driven Development
(ATDD)
• Testes de Aceitação
– Time discute critérios através de exemplos onde todos da...
Behavior-driven Development (BDD)
 Princípios:
◦ Tudo é comportamento: A área de negócios e a de Tecnologia devem se refe...
Método
 Cada user story deve ser transformada em um teste de
aceitação
 User Story
Funcionalidade: Tela de login
Como um...
Pirâmide dos Testes Automatizados
Tester
Developer
Fonte:
Frameworks
 Junit 4 ou TestNG
◦ Ambos integram com Maven, Spring, Cucumber,
Selenium, DBUnit, Emma Test Coverage
◦ Difere...
Upcoming SlideShare
Loading in...5
×

Apresentação testes white box

219

Published on

Published in: Software
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
219
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Transcript of "Apresentação testes white box"

  1. 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. 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. 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. 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. 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. 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. 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. 8. Abordagens  TDD – Test Driven Development  BDD – Behavior Driven Development  ATDD – Acceptance Test Driven Development
  9. 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. 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. 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. 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. 13. Pirâmide dos Testes Automatizados Tester Developer Fonte:
  14. 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/
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×