Apresentação testes white box
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
231
On Slideshare
231
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
1
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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/