Testes Automatizados de Software

8,109 views
7,814 views

Published on

Palestra sobre testes automatizados de software, dada no .NET Architects Day 2009, em 27/06/09.

Published in: Technology

Testes Automatizados de Software

  1. 1. Testes Automatizados de Software Seu software faz realmente o que você quer? Mauricio Aniche mauricio@aniche.com.br
  2. 2. Objetivos • Por quê testar? • Como testar? E o mais importante: MOTIVAR VOCÊ A TESTAR!
  3. 3. test all the f*cking time...
  4. 4. Por quê testar? Prejuízos de aproximadamente $59.5 bilhões na economia dos EUA (Fonte: NIST/2002) É impossível garantir que o software funcione corretamente, sem erros. O cliente não comprou software que falha. PORQUE SIM!
  5. 5. E por que as pessoas não testam? Porque demora! Meu projeto está atrasado! Porque sou programador, e programador não testa! Compilou, tá funcionando! Tá pronto... Só falta testar!
  6. 6. Revisões de código Análises Formais Versões alfa & beta Testes automatizados! “Inspecionar para prevenir defeitos é bom; Inspecionar para encontrar defeitos é desperdício.” Shigeo Shingo
  7. 7. Erro, Defeito Ou Falha?
  8. 8. test all the f*cking time...
  9. 9. Anatomia de um bug Usuário executou um pedaço de código não testado. A ordem em que o usuário executou as ações foram diferentes da ordem em que foi testado. O usuário informou uma combinação de valores de entrada não testados. O ambiente do usuário não foi simulado.
  10. 10. Observando seu sistema... Os usuários enxergam o sistema a partir do exterior... Os testadores espiam um pouco por debaixo dos panos... Os desenvolvedores veem tudo... E você precisa considerar todos esses pontos de vista!
  11. 11. Classificação Caixa branca Caixa preta Caixa cinza
  12. 12. Fases de Teste de unidade de integração de sistema ... diferentes tipos de testes, como aceitação, performance, stress, etc.
  13. 13. Testes de Regressão
  14. 14. Testes Manuais Díficil Demorado e cansativo Executado poucas vezes Cobre poucos casos Sem documentação
  15. 15. Testes Automatizados Rodam rápido Cobrem muitos casos Segurança na manutenção Ajudam na documentação
  16. 16. Muitas vantagens... Eficiência Segurança Flexibilidade Robustez … etc!
  17. 17. test all the f*cking time...
  18. 18. Você consegue ... Simular grandes quantidades de dados ou usuários. Medir o tempo de execução de certas partes do programa. Encontrar gargalos.
  19. 19. Além disso ... Você tem segurança em caso de mudanças. Testes de regressão são executados. Servem de documentação.
  20. 20. Ajuda a codificar? Programe sempre pensando na testabilidade do código. Seu código ganhará em qualidade e flexibilidade!
  21. 21. Facilidade de Manutenção Você pode refatorar sem medo. Adição de novas funcionalidades sem medo de danificar outras partes do sistema. Chega de NÃO ENCOSTA NO QUE ESTÁ FUNCIONANDO!
  22. 22. Reprodutibilidade
  23. 23. test all the f*cking time...
  24. 24. Primeiros passos Código dos testes devem ser simples. Podem conter erros. Devem fazer parte da manutenção. Devem ser independentes. Não devem exigir intervenção humana.
  25. 25. NUnit Framework para testes de unidade. Muito simples de usar. Open source. www.nunit.org
  26. 26. Criando um teste... using NUnit.Framework; [TestFixture] [Test] [SetUp] [TearDown] [Ignore]
  27. 27. Assert’s Assert.AreEqual Assert.AreSame Assert.Greater Assert.IsTrue Assert.IsNull Assert.GreaterOrEqual Assert.IsEmpty ...
  28. 28. Exemplo public class Calculadora { using NUnit.Framework; public int soma(int a, int b) { [TestFixture] return a + b; public class CalculadoraTest { } [Test] public int subtracao(int a, int b) { public void TestaSomaSimples() { return a - b; Calculadora c = new Calculadora(); } Assert.AreEqual(3, c.soma(1,2)); } } [Test] Public void TestaSubtracaoSimples() { Calculadora c = new Calculadora(); Assert.AreEqual(5,c.subtracao(6,1)); } }
  29. 29. Vendo os resultados...
  30. 30. É hora de sujar as mãos!
  31. 31. test all the f*cking time...
  32. 32. Técnicas de Modelagem Partição de Equivalência Análise do Valor Limite Grafo de Causa-Efeito
  33. 33. Mock Objects Simulam objetos reais. Úteis quando temos objetos que são difíceis de criar, reproduzir, lerdos, que ainda não existem, etc. Você pode setar expectativas desse objeto.
  34. 34. Testar sai caro? ... É mais barato do que não testar!
  35. 35. Ferramentas
  36. 36. Testar é legal!
  37. 37. Célebre citação... "The idea of "unit tests" appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t. Otherwise, lots of time is wasted on activities that I simply never need to perform or even think about. Nothing needs to be "mocked up"." Donald Knuth
  38. 38. Citações "Program testing can be used to show the presence of bugs, but never to show their absence." Edsger W. Dijkstra “Whenever you are tempted to type something into a print statement or a debugger expression, write it as a test instead.” Martin Fowler. “Any program feature without an automated test simply does not exist.” Kent Beck.
  39. 39. TESTE O TEMPO TODO!
  40. 40. Agradecimentos Bryan Liles, por ter me cedido o uso do TATFT. Palestras da Agilcoop.
  41. 41. Bibliografia •Delamaro, et. al. Introdução ao teste de software. Campus. 2007. •Pressman, R.S. “Software Engineering : A Practitioner's Approach”, ed. McGraw-Hill, Science/Engineering/Math, 2006. •Teles, V.M. “Extreme Programming: Aprenda como encantar seus usuários desenvolvendo software com agilidade e alta qualidade”, ed. Novatec, 2004. •Whittaker, J.A. “What Is Software Testing? And Why Is It So Hard? ”. IEEE Software, Jan/Fev 2000, p. 70-79. •Vincenzi, M.R.; Maldonado, J. C.; Delamaro, M. E.; Spoto E. S.; Wong, W. E. •“Software Baseado em Componentes: Uma Revisão sobre Teste”, in: “Desenvolvimento Baseado em Componentes: Conceitos e Técnicas”. ed. Ciência Moderna, 2005. •Myers, Glenford J. The Art of Software Testing. Ed. Wiley, 2004.
  42. 42. Dúvidas? mauricio@aniche.com.br Twitter: @mauricioaniche

×