Introdução a Testes de Software - Unidade I

5,473 views

Published on

Introdução a teste de software;
Introdução a automação de teste de software; Básico sobre teste unitário

2 Comments
2 Likes
Statistics
Notes
No Downloads
Views
Total views
5,473
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
118
Comments
2
Likes
2
Embeds 0
No embeds

No notes for slide

Introdução a Testes de Software - Unidade I

  1. 1. Curso de Testes Automatizados de Software Unidade I Introdução
  2. 2. Agenda● Apresentação● Objetivos● Metodologia● Pré-requisitos● Conteúdo Pragmático● Introdução a teste de software● Introdução a automação de teste de software● Básico sobre teste unitário
  3. 3. Apresentação● Curso ● Testes Automatizados de Software - Introdução e Desenvolvimento● Realização ● SEPLAG● Carga horária ● 16 horas● Frequência ● 23/01, 24/01, 25/01 e 26/01 de 2012 ● 08:00 as 12:00
  4. 4. Objetivo● Demonstrar as tecnologias e boas praticas que envolvem a construção de testes de software.● Facilitar a construção e melhoramento dos processos de testes de software automatizados.
  5. 5. Metodologia● O conteúdo da disciplina será desenvolvido por meio de aulas expositivas, exercícios e discussões em sala de aula.
  6. 6. Pré-requisitos● Conhecimentos em Orientação a Objetos● Conhecimentos em Java● Ambiente de desenvolvimento instalado (Eclipse 3.x, Jboss Tools 3.x e Maven 2)
  7. 7. Conteúdo Pragmático● Unidade I ● Introdução a teste de software ● Introdução a automação de teste de software ● Básico sobre teste unitário● Unidade II ● Técnicas de Teste Unitários ● TestNG ● Mockito● Unidade III ● Testando com Banco de Dados ● DBUnit ● Testes Funcionais ● Selenium● Unidade IV ● Princípios e Filosofia de Testes Automatizados ● Introdução ao TDD
  8. 8. Algumas Duvidas● Testes de Software?● Testes Automatizados?● Por que testar?● Quando preciso testar?● Como testar?
  9. 9. Teste de Software● Definições ● É uma investigação conduzida para fornecer os interessados informações sobre a qualidade do produto ou serviço em teste. ● Também pode fornecer uma visão objetiva, independente do software para permitir identificar e compreender os riscos na implementação do software. ● Processo de validação e verificação de que um programa de software (aplicativo ou produto). – Cumpre com os requisitos que o orientaram na concepção e desenvolvimento – Funciona conforme esperado
  10. 10. Quando preciso testar?● Teste de software, dependendo do método teste empregado pode ser implementados a qualquer momento no processo de desenvolvimento.● Entretanto, a maioria do esforço de teste ocorre depois que as exigências foram definidas e o processo de codificação foi concluído. Como tal, a metodologia do teste é regido pela metodologia de desenvolvimento de software adotado.● Diferentes modelos de desenvolvimento focalizam o esforço de teste, em diferentes pontos no processo de desenvolvimento.
  11. 11. Visão geral● Teste nunca pode identificar completamente todos os defeitos no software● Em vez disso, ele fornece uma crítica ou comparação que compara o estado e o comportamento do produto contra princípios ou mecanismos pelos quais alguém pode reconhecer um problema. ● Ex.: Especificações, contratos, versões anteriores, produtos ou expectativa do usuário● Um estudo realizado pelo NIST em 2002 relata que os bugs de software custaram a economia dos EUA, 59,5 bilhões dólares anualmente. Mais de um terço desse custo poderia ser evitado se um melhor teste de software foi realizado
  12. 12. Conceitos importantes● Escopo● Funcional vs Não-Funcional● Bug e Falha● Combinações de entradas e pré-condições● Verificação e Validação● Garantia de Qualidade de Software (SQA)
  13. 13. Escopo● "Os testes podem apenas mostrar a presença de erros, não sua ausência", Dijkstra, et al. 1972● A principal finalidade do teste é detectar falhas de software de modo que os defeitos poção ser descobertos e corrigidos. Teste não pode estabelecer que um produto funciona corretamente em todas as condições, mas só pode demonstrar que ela não funciona adequadamente em condições específicas.● O escopo dos testes de software, muitas vezes inclui o exame de código, bem como a execução desse código em vários ambientes e condições.
  14. 14. Funcional vs Não-Funcional● Teste funcional ● Refere-se a atividades que verificar uma ação específica ou função do código.● Não-funcionais ● Refere-se a aspectos do software que não pode estar relacionada a uma função específica ou ação do usuário, tais como escalabilidade, desempenho, comportamento sob certas restrições, ou de segurança.
  15. 15. Bug e Falha● Geralmente o processo de falhas de software segue o seguinte: ● Um programador faz um erro, o que resulta em um bug no software de código-fonte . Se este defeito é executado, em certas situações o sistema irá produzir resultados errados, causando uma falha . Erro → Bug → Falha● Mas, nem todos os defeitos de software são causados por erros de codificação.
  16. 16. Combinações e Pré-condições● Um problema fundamental com teste de software é que os testes com todas as combinações e pré-condições (estado inicial) não é viável, mesmo com um simples produto.● Isto significa que o número de defeitos em um produto de software pode ser muito grande e defeitos que ocorrem com pouca frequência são difíceis de encontrar.● Mais significativamente os que envolvem requisitos não-funcionais: usabilidade , escalabilidade , desempenho , compatibilidade , confiabilidade.
  17. 17. Verificação e Validação● Verificação ● “Estamos construindo o produto corretamente?” ● O software está de acordo com suas especificações● Validação ● “Estamos construindo o produto corretamente?” ● O sistema atende às expectativas do usuário● As especificações nem sempre estão de acordo com as expectativas dos usuários.
  18. 18. Garantia de Qualidade de Software (SQA)● Teste de software é uma tarefa destinada a detectar defeitos de software.● QA (Garantia de qualidade) é implementação de políticas e procedimentos destinados a prevenir a ocorrência de defeitos em primeiro lugar.● Teste de software faz parte do processo de SQA.
  19. 19. Tipos de Testes de Software● Testes de Componente ● Testes de Unidade● Testes de Sistema ● Testes de Integração ● Testes Funcionais ● Testes de Carga● Testes de Aceitação ● Testes do cliente
  20. 20. Processos de Testes● Tradicional CMMI ou Modelo Waterfall ● Comumente os testes são realizados por um grupo independente de testadores após o desenvolvimento da funcionalidade.● Agile ou Extreme Programing ● Nestes processos geralmente adotam o TDD (Test Driving Development) onde os testes unitários são escritos e primeiro lugar.
  21. 21. Teste de Software● Motivação ● Garantir software que funciona conforme especificado e que atenda as expectativas do usuário ● Ocorrência de falhas humanas no processo de desenvolvimento é considerável ● Os custos na correção de falhas, justificam um processo de testes cuidadoso e bem planejado
  22. 22. Teste de Software● Finalidade ● Averiguar se todos os requisitos foram corretamente implementados ● Assegurar qualidade e corretude do software ● Reduzir custos de manutenção corretiva e retrabalho.
  23. 23. O que é Testar?●Testar é a maneira de obter feedback do software. Por estão razão éum elemento essencial no desenvolvimento “ágil” e “limpo”.
  24. 24. Visão Tradicional de Testes● N° de Bugs determina a qualidade do software
  25. 25. Teste de Desenvolvedores● Frist time, every time
  26. 26. Testes Automatizados
  27. 27. Testes Automatizados● Todos buscam automatizar os testes principalmente com objetivo de evitar retrabalho e reduzir custos. Mas recentemente a experiência de muitos Testadores e Gerente de Testes com ferramentas de automação, os deixaram menos que satisfeito. A causa é os autos custos de Manutenção devido ao problema de "Fragile Test".
  28. 28. Fragile Test● Testes automatizados usando ferramentas "recod and playback" ou "robot user", vem ganhado uma reputação ruim pelos seu primeiros usuários por não conhecerem suas limitações, são elas: ● Sensibilidade de comportamento ● Sensibilidade de interface ● Sensibilidade de dados ● Sensibilidade de contexto
  29. 29. Sensibilidade de Comportamento● Se determinada funcionalidade for alterado, provavelmente todos os testes desta funcionalidade iram falhar
  30. 30. Sensibilidade de interface● Testar logica de negocio via usuário de interface é uma má ideia!● Mesmo pequenas mudanças na interface podem fazer os testes falhar
  31. 31. Sensibilidade dos Dados● Todo teste assume um estado inicial dos dados, se e teste sofrem ao menos uma pequena alteração, os testes podem falhar.● Manter os testes imune as dados requer um grade esforço.
  32. 32. Sensibilidade do Contexto● O comportamento ou estado de coisas fora do sistema, podem afetar o seu comportamento e consequentemente ocasionar falha nos testes.
  33. 33. É Fato● As quatro sensibilidades existem, independentemente de qual tecnologia que usamos para automatizar os testes. Claro, algumas tecnologias podem nos dar maneiras de contornar esses problema, enquanto outros nos força para um caminho particular. A família xUnit (Junit, TestNG, ...) nos dá um grande grau de controle, só temos de aprender como usá-lo efetivamente.
  34. 34. Automação de Testes● Muito se fala sobre testes automatizados de unidade e aceitação como parte do desenvolvimento ágil de software● Escrever bons testes de código é difícil, e mantelos limpo e claro é mais difícil ainda.● O Principal causa disso é o fato de ser opcional ( o cliente não paga por isso) e com o tempo os teste vão sendo abandonados devido ao aumento de complexidade e/ou custo de manutenção.
  35. 35. Custos● O custo de escrever e manter conjuntos de testes tem sido um desafio particular.
  36. 36. Soluções● Mas felizmente, muitas equipes tem desenvolvido soluções que ajudam a enfrentar esses desafios.
  37. 37. Economia com Automação de Testes● Evidente, que sempre há custos construção e manutenção de uma suíte de testes.● Nosso objetivo deve ser o de tomar a decisão de fazer a automação de testes assegurando o não aumento nos custos de desenvolvimento de software.● Assim, o custo adicional de construção e manutenção de testes automatizados devem ser compensados com a redução na depuração/resolução de problemas diminuindo os custos de remediação dos defeitos que possam ter passado despercebidos até a fase de teste formal do projeto ou uso de produção.● A figura 1.0 mostra como o custo da automação é compensado pelos benefícios recebidos.
  38. 38. Economia com Automação de TestesFigura 1.0 - Um projeto de teste unitários automatizado com um bomretorno sobre o investimento. O custo-benefício quanto ao custo total éreduzido por boas práticas de teste.
  39. 39. Economia com Automação de Testes● Devemos ressaltar que, se os testes são difíceis de escrever, são difíceis de compreender, e necessitam de manutenção frequente, o custo total de desenvolvimento é caro.● E os benefícios podem não equilibrar o esforço despendido para manter os testes automatizados, a figura 1.1 demostra isso.
  40. 40. Economia com Automação de TestesFigura 1.1 Um projeto de teste unitário automatizado com um baixoretorno do investmeno e custo-benefício quanto ao custo total éaumentada por práticas de teste pobres.
  41. 41. Teste Automatizados● Objetivos para atingir a economia esperada: ● Os testes devem nos ajudar a melhorar a qualidade. ● Os testes devem nos ajudar a entender o SUT (system under test). ● Os testes devem reduzir (e não introduzir) riscos. ● Os testes devem ser fáceis de executar. ● Os testes devem ser fáceis de escrever e manter. ● Os testes devem requerer o mínimo de manutenção.
  42. 42. Os testes devem nos ajudar a melhorar a qualidade.● A razão tradicional para testarmos é garantir qualidade (QA). Procuramos responder as seguintes perguntas: O software é feito corretamente? O software faz a coisa certa?● Como: ● Testes como especificação ● Prevenir Bugs ● Localizar defeitos
  43. 43. Os testes devem nos ajudar a entender o SUT● Os teste podem mostrar como o código deve funcionar.● Como: ● Testes como documentação – Sem testes automatizados temos que estudar o código tetando responder à pergunta: “Qual deve ser o resultado se …?” – Se quisermos saber como o sistema faz alguma coisa, só precisamos executar os teste especifico e depurar se necessário
  44. 44. Os testes devem reduzir (e não introduzir) riscos.● Testes devem melhorar a qualidade do nosso software, ajuda-nos a documentar melhor os requisitos e evitar lentidão no desenvolvimento incremental. Esta é certamente uma forma de redução de riscos.● Outra forma de ajudar é verificar comportamento em situações que não podem ser identificada nos testes de caixa preta.● Como: ● Testes como Rede de Segurança ● Não causar danos – Mantenha a logica de produção fora do código de produção
  45. 45. Os testes devem ser fáceis de executar● O que torna fácil de executar testes? Quatro objetivos específicos respondem a esta pergunta: ● Testes devem ser totalmente automatizado para que eles possam ser executados sem qualquer esforço. ● Testes devem ser auto-verificáveis para que eles possam detectar e relatar quaisquer erros sem inspeção manual. ● Testes devem ser repetíveis para que eles possam ser executados várias vezes com o mesmo resultado. ● Idealmente, cada teste deve ser um teste independente que pode ser executado por si só.● O feedback deve está a um clique de distância
  46. 46. Os testes devem ser fáceis de escrever e manter● Testes de tornar-se complicada por duas razões: ● Tentamos verificar muitas funcionalidades em um único teste. ● Existem um “gap de expressividade” muito grande entre a linguagem de testes (ex. Java) e as relações e conceitos do domínio que estamos tentando expressar no teste.● Como: ● Testes simples – Uma condição para verificar por teste ● Testes expressivos ● Separação de interesses
  47. 47. Devem requerer o mínimo de manutenção.● A mudança é um fato da vida. E na verdade escrevemos software para facilitar as mudanças.● Sistema evolui em torno dos testes● Como: ● Testes robustos
  48. 48. Testes Automatizados – Metas Projeto Construção de TestesTestes como Especificação Total automatizaçãoTestes como Documentação Alto verificaçãoTestes como Rede de Segurança Teste que se pode repetirLocalizador de Defeitos Tete RobustoFácil de escrever ou manter Teste SimplesProver Qualidade Teste ExpressivoReduzir risco Separação de interessesPrevenir Bug Não cause danos
  49. 49. Básico de Testes Unitários● Definindo Testes Unitários● Explorando um simples exemplo● Um pouco de TDD
  50. 50. Definição● Testes Unitários não é um conceito novo em desenvolvimento de software● Kent Beck itroduzio o conceito de teste uninitario em Samalltalk.● Um teste de unidade é um pedaço de um código (normalmente um método) que invoca uma outra pedaço de código e verifica a veracidade de alguns pressupostos pós-ala. Se os pressupostos vir a ser errado, o teste de unidade falhou. A "unidade" é um método ou função.
  51. 51. Definição● A importância de escrever bons testes unitários● Todos nos já escrevemos testes unitários
  52. 52. Definição● Em testes clássicos, os desenvolvedores usam uma GUI (graphical user interface) para desencadear uma ação sobre a classe que eles querem para testar. Em seguida, verificam os resultados.
  53. 53. Propriedades de um “bom” teste unitário● Um teste unitário deve ter as seguintes propriedades: ● Deve ser automatizados e repetíveis. ● Deve ser fácil de implementar. ● Uma vez que é escrito, ele deve permanecer para uso futuro. ● Deve funcionar com o pressionar de um botão. ● Deve funcionar rapidamente.
  54. 54. Propriedades de um “bom” teste unitário● Muitas pessoas confundem ato de testar software com o conceito de teste unitário Então pergunte a si mesmo sobre os testes que escreveu até agora: ● Posso executar e obter resultados de um teste de unidade que eu escrevi duas semanas ou meses ou anos atrás? ● Qualquer membro de minha equipe pode executar e obter os resultados dos testes que eu escrevi há dois meses? ● Posso executar todos os testes unitários que eu escrevi em não mais do que alguns minutos? ● Posso executar todos os testes unitários que eu escrevi com um botão? ● Posso escrever um teste unitário básico em não mais do que alguns minutos?● Se você respondeu “Não” a alguma das questões acima, provavelmente você não está implementando testes unitários É algum outro tipo de teste tão importante quanto os testes unitários
  55. 55. Diferenças● Você pode perguntar, “O que eu estava fazendo até agora?”. Provavelmente testes de integração● Exite uma grande duvida sobre a diferença de testes unitários e testes de integração
  56. 56. Testes de Integração● Teste de integração consiste em testar dois ou mais módulos de softwares como um grupo.
  57. 57. Bom Teste Unitário● A definição ● Um teste unitário é uma parte automatizada de código que chama o método ou classe que está sendo testado e, em seguida, verifica algumas suposições sobre a lógica e comportamento desse método ou classe. Um teste de unidade é quase sempre escrito usando uma estrutura de testes unitário Pode ser escrito de forma fácil e executa rapidamente. É totalmente automatizado, confiável, legível e de fácil manutenção.
  58. 58. Um teste unitário simples● É possível escrever teste unitário automatizado sem usar um framework de teste.
  59. 59. SUT
  60. 60. Classe de Teste
  61. 61. Executando o Teste
  62. 62. Melhorando um pouco
  63. 63. Melhorando um pouco
  64. 64. Primeiro teste unitário● Frameworks de testes unitários (xUnit)● Escrevendo o primeiro teste unitário com Junit● Trabalhando com atributos do Junit● Compreendendo o estado dos testes
  65. 65. Frameworks para testes unitários● O frameworks de testes oferecem facilidades semelhantes ao que as IDEs nós proporcionam
  66. 66. Como os frameworks ajudam. Pratica de teste unitário Como o framework ajudaEscrever testes facilmente e Fornece ao desenvolvedor umade forma estruturada. biblioteca com: • Classes ou interfaces para herdar. • Atributos para colocar em seu código para observar seus testes para ser executado. • Classes de acessão que possuem métodos especiais que você invoca para verificar seu código.Execute um ou todos os testes - Quadro prevê um console ou Ferramenta GUI que:de unidade. • Identifica os testes em seu código. • Executa testes automaticamente. • Indica o estado durante a execução. • Pode ser automatizada por linha de comando.
  67. 67. Como os frameworks ajudam. Pratica de teste unitário Como o framework ajudaAnalisar os resultados do teste é Os consoles geralmente fornecemexecutado. informações, tal como: • quantos testes correu. • quantos testes não foi executada. • quantos testes falharam. • quais testes falharam. • os testes de razão, não. • A mensagens de assert que você escreveu • o local de código que falhou. • possivelmente um rastreamento de pilha completa de todas as exceções que fez com que o teste falhar.
  68. 68. xUnit● CppUnit para C++● JUnit para Java● Nunit para .Net● HUnit para Haskell● …
  69. 69. Projeto LogAn● Uma determinada empresa possui um vários sistemas que geram logs num formato privado. Estes logs devem ser lidos e determinados comportamentos identificados e notificados aos resposaveis.● Para resolver este problema daremos inicio ao projeto LogAn que começara bem simples.
  70. 70. Junit 4● O JUnit (junit.org) é um framework muito simples para facilitar a criação destes testes unitários e em especial sua execução. Ele possui alguns métodos que tornam seu código de teste bem legível e fácil de fazer as asserções.● Uma asserção é uma afirmação: alguma invariante que em determinado ponto de execução você quer garantir que é verdadeira. Se aquilo não for verdade, o teste deve indicar uma falha, a ser reportada para o programador, indicando um possível bug.● Escrito originalmente por Kent Beck (Extreme Programming) e Erich Gamma (Design Patterns)
  71. 71. Junit API● Principais Anotações ● @Test – Marca uma classe ou metodo como sendo parte de um teste. ● @BeforeClass – Executa um método antes da classe iniciar ● @AfterClass – Executa um metodo depois da classe iniciar ● @Before – Executa um método antes de qualquer metodo de teste ● @After – Executa um método depois de qualquer metodo de teste.
  72. 72. Junit API Resumida
  73. 73. Exercícios
  74. 74. Referências● Osherove, Roy. The art of unit testing : with examples in .NET. 2009● Meszaros, Gerard. XUnit test patterns : refactoring test code. 2007● http://en.wikipedia.org/wiki/Software_testing

×