TESTES EM APLICAÇÕES WEB

1,181 views
1,045 views

Published on

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

Published in: Software

TESTES EM APLICAÇÕES WEB

  1. 1. TESTES em aplicações web Cynthia Zanoni @cynthia_zanoni
  2. 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. 3. Testar é chato!
  4. 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. 5. E a síndrome...
  6. 6. (ou seja, já era!) Simples! Sua aplicação vai falhar(acredite!).
  7. 7. Estratégias e Planejamento de Teste
  8. 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. 9. APLICAÇÕES WEB == VÁRIOS AMBIENTES
  10. 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. 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. 12. Matriz de Gerenciamento de Risco
  13. 13. Fluxo
  14. 14. V A L I D A Ç Ã O
  15. 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. 16. TESTES
  17. 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. 18. Algumas ferramentas de testes:
  19. 19. Estilos de Testes Behaviour-Driven Development Domanin-Driven Design Test-Driven Development { } {
  20. 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. 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. 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. 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. 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. 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. 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. 27. A classe da conta bancaria: <?php class BankAccount { protected $balance = 0; public function getBalance() { return $this->balance; } } ?> Exemplo de implementação:
  28. 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. 29. DDD {Desenvolvimento Guiado por Design ou Desenvolvimento orientado a Domínio
  30. 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. 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. 32. O modelo é um universo composto por cinco itens principais:
  33. 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. 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. 35. Exemplo de um modelo.
  36. 36. Enfim...
  37. 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 :)

×