Apresentação testes white box

  • 157 views
Uploaded on

 

More in: Software
  • 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
157
On Slideshare
0
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/