• Save
TESTES EM APLICAÇÕES WEB
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

TESTES EM APLICAÇÕES WEB

on

  • 305 views

Um panorama sobre testes em aplicações Web.

Um panorama sobre testes em aplicações Web.
Dos conceitos à implementação.
Projeto acadêmico apresentado em Maio de 2013.

Statistics

Views

Total Views
305
Views on SlideShare
303
Embed Views
2

Actions

Likes
3
Downloads
0
Comments
0

1 Embed 2

http://www.slideee.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

TESTES EM APLICAÇÕES WEB Presentation Transcript

  • 1. TESTES em aplicações web Cynthia Zanoni @cynthia_zanoni
  • 2. "O Objetivo do teste da WebApp é exercitar cada uma das várias dimensões de qualidade da WebApp com intenção de encontrar erros ou descobrir tópicos que podem levar a falhas de qualidade." Engenharia de Software - Roger S Pressman
  • 3. Testar é chato!
  • 4. Algumas dificuldades encontradas ao testar uma aplicação: ● Falsa sensação de segurança. ● Olhar Viciado ● Concentração Polarizada: Nos concentramos em um único ponto. NÃO VEMOS OS DEMAIS
  • 5. E a síndrome...
  • 6. (ou seja, já era!) Simples! Sua aplicação vai falhar(acredite!).
  • 7. Estratégias e Planejamento de Teste
  • 8. Estabeleça o que é crítico. Faça um mapeamento das partes críticas do seu sistema e quais as conseqüências se elas não funcionarem. Métodos Ágeis: aplicar testes é uma rotina de métodos ágeis. Mas você não precisa deles para testar sua aplicação.
  • 9. APLICAÇÕES WEB == VÁRIOS AMBIENTES
  • 10. TESTES AUTOMATIZADOS A ideia de automatizar testes consiste em escrever um programa que seja capaz de preparar um cenário, controlar a execução do pedaço de software a ser testado, comparar resultados e gerar relatórios. Existe uma diversidade de frameworks para testes automatizados.
  • 11. TESTES AUTOMATIZADOS As vantagens de testes automatizados incluem a facilidade de rodar os testes repetida e rapidamente. Além da formalização e estruturação de casos de teste, quando não existe uma documentação formal para os mesmos, caso em que ouso dizer que é a maioria.
  • 12. Matriz de Gerenciamento de Risco
  • 13. Fluxo
  • 14. V A L I D A Ç Ã O
  • 15. ● Se os testes validassem especificações, não poderíamos prever correções de bugs e comportamentos de ambientes (lê-se erros que seu usuário encontrará acessando pelo IE!) ● Bugs não fazem parte de uma especificação. Logo.... TESTES vs. ESPECIFICAÇÕES TESTES NÃO VALIDAM ESPECIFICAÇÃO! NÃO CRIAM ESPECIFICAÇÕES!{
  • 16. TESTES
  • 17. Existem vários tipos de testes, que visam a qualidade de uma aplicação web em interface, ux, conteúdo, segurança, desempenho entre outros. Conheça alguns tipos de testes: Teste de Conteúdo; Teste de Interface; Teste de Semântica de Interface; Teste de Configuração; Teste de Segurança; Teste de Desempenho Teste de Banco de Dados; Teste de Navegação; Teste de Usabilidade; Teste de Compatibilidade;
  • 18. Algumas ferramentas de testes:
  • 19. Estilos de Testes Behaviour-Driven Development Domanin-Driven Design Test-Driven Development { } {
  • 20. BDD { É uma técnica de desenvolvimento ágil que visa integrar regras de negócios com linguagem de programação. A linguagem de negócio usada em BDD é extraída das estórias ou especificações fornecidas pelo cliente durante o levantamento dos requisitos. Desenvolvimento Orientado por Comportamento
  • 21. O Cucumber, utiliza Ruby e expressões regulares para definir o que qualquer expressão quer dizer. Para que seja possível executar uma User Storie utilizando o Cucumber, ela precisa ter uma estrutura básica. 1. Para o Cucumber, todas as User Stories referentes a uma funcionalidade do sistema estarão agrupadas em um arquivo com a extensão .feature 2. No início de cada arquivo existe um resumo da funcionalidade com um formato bem simples: um título, qual o problema a ser resolvido, qual ator trabalha nesta história e qual o resultado desejado.
  • 22. 3. Logo depois são definidos os cenários, que são as histórias em si, cada arquivo tem pelo menos um cenário. 4. Cada história, ou cenário é composto por uma descrição ou título, uma ou mais pré condições, uma ou mais ações e uma ou mais verificações. O Cucumber define algumas palavras chave para cada uma destas sessões, estas palavras chave podem ser traduzidas para diversas línguas. No próximo exemplo vamos utilizar as seguintes palavras-chave em português: Funcionalidade - Cenário - Dado - E - Quando - Então (Feature) (Scenario) (Given) (And) (When) (Then)
  • 23. É utilizado para testar o software antes mesmo dele ser feito. Pode parecer uma idéia estranha, mas dessa forma o programador programa pensando na interface das suas classes, e não na implementação. TDD {Desenvolvimento Orientado por Testes
  • 24. Vamos imaginar um um sistema de contas bancarias, aonde a conta bancaria deve começar com o seu valor em 0, deve ter métodos para tirar dinheiro e não pode ter valor negativo. O código seria o seguinte: Exemplo de implementação:
  • 25. A classe de testes ficaria da seguinte forma <?php require_once 'BankAccount.php'; class BankAccountTest extends PHPUnit_Framework_TestCase { protected $ba; protected function setUp() { $this->ba = new BankAccount; } Exemplo de implementação:
  • 26. public function testBalanceIsInitiallyZero() { $this->assertEquals(0, $this->ba->getBalance()); } public function testBalanceCannotBecomeNegative() { try { $this->ba->depositMoney(-1); } catch (BankAccountException $e) { $this->assertEquals(0, $this->ba->getBalance()); return; } $this->fail(); } } ?> Exemplo de implementação:
  • 27. A classe da conta bancaria: <?php class BankAccount { protected $balance = 0; public function getBalance() { return $this->balance; } } ?> Exemplo de implementação:
  • 28. Com a classe criada e o método getBalance o primeiro teste já será validado. Mas como os outros métodos não foram implementados teremos um fatal error. Fatal error: Call to undefined method BankAccount::depositMoney() Exemplo de implementação:
  • 29. DDD {Desenvolvimento Guiado por Design ou Desenvolvimento orientado a Domínio
  • 30. Trata-se de uma abordagem de design de software de forma disciplinada, abordando uma série de conceitos e técnicas sempre com foco no domínio do software. O pilar do DDD é conceitualizar em forma de Modelo o seu domínio. O Modelo pode ser feito de qualquer forma que possa ser entendido, Papel de pão, UML, Lego ou Massa de modelar. O que é o DDD?
  • 31. Seu propósito é atacar a complexidade no desenvolvimento de software, ou seja, o domínio do negócio, utilizando um conjunto de boas práticas de desenvolvimento. Essas boas práticas são comprovadamente capazes de construir aplicações com todas aquelas características desejáveis que sempre ouvimos falar: extensível, escalável, confiável, segura, fácil de manter, fácil de utilizar, flexível e que atende aos requisitos demandados. O que é o DDD?
  • 32. O modelo é um universo composto por cinco itens principais:
  • 33. Entidade: Tudo que tenha valor ao domínio (regra de negócio) deve possuir uma entidade. Objetos de valor: São objetos reconhecidos por seus atributos e geralmente são imutáveis. Por ex: Tipos de Conta são do tipo Corrente, Investimento, Crédito, Transitória e etc. Serviços: São ferramentas, pois não são entidades nem possuem objetos de valor. Se por exemplo você precisa enviar um relatório de contas correntes ao Banco Central Conhecendo os artefatos de um universo
  • 34. Factories:existem cenários quais são impossíveis de definir um objeto sem a criação dele através de uma Factory (Factory é um design pattern). Repositório: Não importa onde esteja alocado seu repositório, em algum momento você vai precisar guardar e recuperar um conjunto de informações como um objeto. Conhecendo os artefatos de um universo
  • 35. Exemplo de um modelo.
  • 36. Enfim...
  • 37. Referências Livro: Engenharia de Software - Roger S Pressman Web: DDD : http://sobrecodigo.com/domain-driven-design-um-rascunho-de-artigo/ Gerenciamento de Riscos: http://www.mindtools.com/pages/article/newPPM_78.htm Testes Automatizados: http://macoli.wordpress.com/2012/03/09/testes-de-software/ Sites das ferramentas citadas como exemplo. Leonardo Balter - Palestra BrazilJS Imagens: Google Images Bóris Rodrigues - acervo pessoal :)