Fundamentos de Testes de Software

1.831 visualizações

Publicada em

Fundamentos sobre Equipes, Papeis, Estágios, Tipos, Abordagens, Técnicas, Modelos, Processos de Testes de Software

Publicada em: Tecnologia
0 comentários
9 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.831
No SlideShare
0
A partir de incorporações
0
Número de incorporações
84
Ações
Compartilhamentos
0
Downloads
110
Comentários
0
Gostaram
9
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Fundamentos de Testes de Software

  1. 1. https://www.facebook.com/alvarofpinheiroaulas/ br.linkedin.com/in/alvarofpinheiro/ TESTES DE SOFTWARE http://www.alvarofpinheiro.eti.br
  2. 2. “O objetivo do Teste de Software é encontrar bugs, encontrá-los o mais cedo possível e garantir que os bugs sejam corrigidos” (Patton, 2005) http://www.alvarofpinheiro.eti.br
  3. 3. TESTES DE SOFTWARE INTRODUÇÃO http://www.alvarofpinheiro.eti.br
  4. 4. O que é um bug?  Várias definições existem em cada empresa  Um bug é: um defeito, falta, problema, incidente, anomalia, CR, etc.  Empresas usualmente perdem um bom tempo discutindo isso  Mas normalmente a conclusão é que um bug é apenas um bug  Uma definição mais formal de bug pode ser feita se pensando quando um bug ocorre [Patton, 2005]  Um bug ocorre quando uma ou mais das opções abaixo for verdadeira:  O software NÃO faz algo que a especificação diz que ele deveria fazer  O software FAZ algo que a especificação diz que ele NÃO deveria fazer  O software faz algo que a especificação não menciona  O software NÃO faz algo que a especificação NÃO menciona, mas deveria mencionar  O software é difícil de usar, entender, ou na visão do testador pode ser visto pelo usuário final como não estando correto http://www.alvarofpinheiro.eti.br
  5. 5. Bugs clássicos:  CD-ROM Rei Leão da Disney  Lançado em 1994  Primeiro CD-ROM da Disney (muita propaganda e grandes vendas)  Lançado antes no natal  Não foi testado em diferentes configurações de PCs e não informava a configuração mínima  Bug do ano 2000  Computadores não estavam preparados para o ano 2000  Sistema de Telefones de AT&T nos EUA  Toda a rede caiu por causa de um switch case errado  Sistema de Foguetes em Nara e Agência Européia  O foguete explodiu no lançamento pois o código feito na Nasa estavam no sistema métrico inglês e o da agência Européia no sistema internacional http://www.alvarofpinheiro.eti.br
  6. 6. Qual o custo de um bug?  O custo de um bug está diretamente associado a fase do ciclo de desenvolvimento em que o bug é encontrado  Um bug encontrado durante a especificação pode custar 1 dolar. O mesmo bug encontrado no release pode custar 100x mais http://www.alvarofpinheiro.eti.br
  7. 7. Por que bugs ocorrem?  Usualmente a razão de um bug ocorrer, depende do tamanho e do tipo do sistema Sistemas de Média e Grande Porte Sistemas de Pequeno Porte http://www.alvarofpinheiro.eti.br
  8. 8. Por que bugs ocorrem?  Problemas de especificação são a principal causa de bugs  Mais de 50%  Em Sistemas Pequenos  Problemas no código são a principal causa de bugs: 75%  Erros durante a construção (low level design + code + unit tests + integração) correspondem por pelo menos 35% dos erros  Quanto maior o projeto menor o número de erros na construção é maior o número na especificação  Problemas se especificação são em geral o maior causador de bugs em um software  Quanto maior o software, maior o número de erros na arquitetura e design de alto níve http://www.alvarofpinheiro.eti.br
  9. 9. Tipos de Bug  Vários estudos buscaram definir tipos de bug e suas porcentagens de ocorrência  Nenhum dos estudos foi muito conclusivo, mas vários pontos importantes foram levantados  O escopo dos erros é limitado: 85% dos erros podem ser corrigidos modificando apenas 1 rotina (classe) [Endres, 1975]  Maioria dos erros não está no código, mas no domínio da aplicação e não são problema do código em si  Vários erros são simples erros de digitação: 35% dos erros de código são erros de digitação [Weiss, 1975]. http://www.alvarofpinheiro.eti.br
  10. 10. Tipos de Bug  Maioria dos erros são simples de corrigir  85% dos erros podem ser corrigidos em menos de 1 hora  Apenas 1% dos erros levam mais que alguns dias para corrigir  80% do esforço de manutenção é gasto em apenas 20% dos erros  Os erros são concentrados em partes específicas do código  80% dos erros está em apenas 20% do código [Endres, 1975]  50% dos erros pode ser encontrado em 5% do código [Jones, 2000]  Os testes que buscam identificar quais são essas partes específicas do código podem reduzir em muito o custo de manutenção  Algumas vezes é melhor reescrever as rotinas nos quais os erros estão concentrados http://www.alvarofpinheiro.eti.br
  11. 11. Por que testes precisam se realizados?  Existem várias técnicas de encontrar bugs  Nenhuma técnica consegue garantir que TODOS os bugs sejam encontrado  Testes de software é uma das possíveis técnicas que podem ser aplicadas  Nenhuma técnica consegue encontrar mais de 85% dos bugs  Testes unitários + testes de componente + testes de sistemas atingem no máximo 60% dos bugs http://www.alvarofpinheiro.eti.br
  12. 12. Por que testes precisam se realizados?  Testes precisam ser realizados, mas não são suficientes para garantir que todos os bugs sejam encontrados  O ideal é combinar diferentes técnicas para garantir que a maioria dos bugs sejam encontrados o mais cedo possível  Algumas organizações chegam a atingir 95% de bugs encontrados combinando diferentes técnicas  Vários estudos comparam eficiência de técnicas de encontrar bugs  Grupo de programadores com média de 11 anos de experiência  Avaliou um código com 15 erros conhecidos  3 técnicas foram usadas  Testes contra a especificação  Execução de testes unitários e de sistemas  Inspeções da especificação e dos testes unitários  Em média apenas 5 erros foram encontrados  Testes usualmente atingem no máximo 50-60% de cobertura [Johnson 1994] http://www.alvarofpinheiro.eti.br
  13. 13. O que testar?  Definir o que testar no software é uma decisão fundamental  Essa definição deve levar em conta a “qualidade final” do software  Qualidade do produto  “satisfação final do usuário”  Satisfação do usuário  “experiência de uso” do software  Caso a “experiência de uso” seja boa a satisfação final do usuário será boa, mesmo que o software ainda apresente bugs Todas as funcionalidades que apresentam riscos para a qualidade do software DEVEM ser testadas http://www.alvarofpinheiro.eti.br
  14. 14. Riscos  É importante identificar quais os possíveis problemas que podem causar dificuldades na realização das atividades de teste?  Cada possível problema é chamado de “risco”  Para cada risco deve-se avaliar pelo menos  Probabilidade de ocorrer  Plano de contingência caso o risco de torne um fato  Prioridade do risco  Outros aspectos podem ser avaliados para cada risco de acordo com o processo de gerenciamento de risco da organização http://www.alvarofpinheiro.eti.br
  15. 15. O que testar? Experiência de uso Software Usuário Testes Testes Software Usuário Os testes estão cobrindo As áreas com riscos para qualidade http://www.alvarofpinheiro.eti.br
  16. 16. Conceitos em Testes de Software  Processos de Testes  Estágios de Teste  Tipos de Teste  Abordagens de Teste  Procedimentos de Teste  Projetos de Testes  Técnicas de Testes  Ferramentas de Testes http://www.alvarofpinheiro.eti.br
  17. 17. Foco de Teste  O foco dos testes muda de acordo com o estágio de testes sendo realizado, assim como o testador realizando a atividade  Este foco varia de  Testes de estruturais  Testes comportamentais  Testes reais Desenvolvedor Engenheiro de Testes Usuário Testes Estruturais Testes Comportamentais Testes Reais http://www.alvarofpinheiro.eti.br
  18. 18. Foco de Teste – Testes Estruturais  Buscam encontrar erros internos no software.  Focam diretamente no código  Encontram erros como  Um método pode estar recebendo um inteiro de 24 bits e tentando guardá-lo em 16 bits  Um algoritmo específico pode não estar tratando todos os possíveis fluxos de execução  Testes estruturais estão associados ao estágios de teste unitários e de componente  Eles são realizados então pelo desenvolvedor de software ou por um desenvolvedor de software em testes (testes de componente) http://www.alvarofpinheiro.eti.br
  19. 19. Foco de Teste – Testes Comportamentais  Encontram erros de mais alto nível no domínio da aplicação e não mais no código  Focam nas funcionalidades do sistema como um todo  Encontram erros como  Um usuário sem permissão conseguem realizadas operações sensíveis do sistemas  O sistema não implementa uma determinada regra de negócio como deveria  Testes comportamentais estão associados aos testes de sistema  Eles são realizados usualmente por engenheiros de teste http://www.alvarofpinheiro.eti.br
  20. 20. Foco de Teste – Testes Reais  Encontram erros no sistema como um todo, mas agora focando nas necessidades finais do usuário  Usuários reais tendem a encontrar problemas que não são vistos pelos engenheiros de teste  Os tipos de erros encontrados podem ser parecidos com os encontrados nos testes comportamentais  Também podem ser encontrados erros como  Uma funcionalidade bem importante pode estar escondida em um sub-menu em vez de estar exposta mais claramente  A forma como o sistema foi implementado não está resolvendo o problema do usuário  Estes testes usualmente são realizados por usuários finais  Os testes reais estão associados a um teste de aceitação http://www.alvarofpinheiro.eti.br
  21. 21. Procedimento de Teste  O procedimento de testes está diretamente relacionado ao conceito de caso de teste  Cada caso de teste está associado a um diferente “cenário” a ser testado  Para cada requisito existem diferentes cenários a serem testados  Para validar um caso de testes é necessário  Definir o ambiente no qual o teste será realizado  Definir a entrada deste caso de teste  Definir a saída esperada para cada entrada  Definir os passos a serem realizados para executar os testes  O conjunto de passos acima determina o que um procedimento de testes http://www.alvarofpinheiro.eti.br
  22. 22. Resultado de Testes  Quando cada caso de teste é executado, o seu resultado deve ser coletado  Existem diferentes abordagens para definir o resultado de um caso de teste especifico  A mais comum define as seguintes opções  Passou  todos os passos do caso de testes foram executados com sucesso para todas as entradas  Falhou  nem todos os passos foram executados com sucesso para uma ou mais entradas  Bloqueado  o teste não pode ser executado, pois o seu ambiente não pode ser configurado, ou pode alguma dependência externa http://www.alvarofpinheiro.eti.br
  23. 23. Testes: Cerificações O maior problema das certificações são a falta de padronização em seus conteúdos. Por isso, é indicado se que escolha o programa que mais se adéqua as necessidades da empresa e se incentive as pessoas a tirá-la e a experiência é insubstituível. American Society for Quality’s (ASQ) Certified Software Quality Engineer (CSQE); Quality Assurance Institute’s (QAI) Certified Software Test Engineer (CSTE) International Institute for Software Testing’s (IIST) Certified Software Test Professional (CSTP) Institute of Electrical and Electronic Engineers’ (IEEE) Certified Software Development Professional (CSDP) British Computer Society’s (BCS) Information Systems Examination Board (ISEB) http://www.alvarofpinheiro.eti.br
  24. 24. Testes: Modelo de Documento Missão: <uma breve sentença sobre a missão dessa sessão> Áreas: <area1 do requisito1> <area2 do requisito2> <...etc> Início: <data e hora de início> Testador: <nome do testador> Tarefas: <descrição das atividades> Duração: <os valores são "curta", "normal", ou "longa”> Preparação da Sessão: <% da duração da sessão gasta na preparação, entre 0-100> Projeto e Execução de Testes: <% da duração da sessão gasta procurando bugs, entre 0-100> Investigação e Reportagem dos Bugs: <% da duração da sessão gasta investigando problemas, 0-100> Descrição x Oportunidade: <descrição da duração da sessão que foi gasta na missão de investigação> Arquivos de Dados: <a sintaxe é o formato do aquivo ex.: "foo.bat“ e se não houver arquivos de dados, #N/A> Notas dos Testes: <formato de texto livre> Bugs: <listar os bugs com uma tag #BUG, o formato do texto é livre e se não houverem bugs, usar #N/A> Exemplo para Bugs encontratos: #BUG Título do bug Passos para reprodução: 1 - … 2 - … Resultado: ... Esperado: ... Issues: <o mesmo formato da sessão de BUG acima, se não houverem ISSUES, use #N/A> http://www.alvarofpinheiro.eti.br
  25. 25. TESTES DE SOFTWARE EQUIPES http://www.alvarofpinheiro.eti.br
  26. 26. Equipes de Testes Existem várias maneiras de se organizar testes, porém a forma que se mostra mais adequada é a criação de um grupo independente de teste.E independência significa reconhecer os engenheiros de teste como especialistas, ou seja, não são desenvolvedores e respondem a uma gerência independente da gerência de desenvolvimento. É importante salientar, que engenheiros de teste possuem responsabilidades diferentes e, consequentemente, evoluem diferentemente, e que devem ser imparciais e não se influenciarem pela pressão do desenvolvimento. http://www.alvarofpinheiro.eti.br
  27. 27. Equipes de Testes: Times Independentes A funcão principal desse time é fazer testes, seja para um ou vários produtos. Ele não deve estar subordinado a mesma gerência de desenvolvimento, o que faz com que esse time não sofra as pressões internas de prazo de entrega do produto. Essa maneira tem uma grande vantagem de ter profissionais especializados em testes e a garantia de que os testes podem ser realizados tão bem quanto o desenvolvimento do sistema. Sua desvantagem é que, por passarem a existir dois times onde um tem a missão de encontrar problemas no que o outro desenvolveu, pode começar a haver desentendimentos entre esses eles. Entretanto, isso pode ser minimizado a nível gerencial, lembrando sempre que ambos estão contribuindo para a qualidade do produto final que é parte do esforço de ambos; estimulando a comunicação entre os times; inicializando o processo de teste o quanto antes. http://www.alvarofpinheiro.eti.br
  28. 28. Equipes de Testes: Times Integrados Os engenheiros de teste e os engenheiros de sistemas fazem parte de um mesmo time. Normalmente, é o que acontece em empresas projetizadas. Como todos fazem parte de um mesmo time, é mais fácil fazer com que os testes sejam iniciados cedo. Contudo, pelo mesmo motivo, é difícil captar bons recursos, pois, geralmente eles já estão em outras equipes. Um outro problema que ocorre com frequência é que, pelo fato do gerente ser encarregado tanto do desenvolvimento quanto do teste, ele pode se sentir mais tentado a entregar o produto no prazo acordado para não ferir seu cronograma, fazendo com que o serviço de teste seja comprometido por encurtar o tempo anteriormente planejado para o teste. http://www.alvarofpinheiro.eti.br
  29. 29. Equipes: Desenvolvedores São responsáveis por desenvolver e testar os sistema os problemas de comunicação são eliminados; a priorização da correção de bugs torna-se mais fácil; o bom conhecimento do design e do código faz com que seja mais fácil de encontrar qual a razão do bug. Porém, outros problemas vêm à tona, como: a falta de um conhecimento mais aprofundado do negócio limita o nível de teste a ser feito; a falta de conhecimento técnico de tipos, estratégias, métodos, processos de teste dificulta à realização do serviço de teste; a experiência com programação faz com que eles fiquem tentados, e às vezes limitados, a testar apenas o que o sistema deve fazer, não criando cenários de teste onde se tem de fato a maior probabilidade de encontrar bugs. http://www.alvarofpinheiro.eti.br
  30. 30. Equipes: Coordenadores de Testes Quando não existe grupo de testes, um coordenador de teste Deve ser escolhido para formar e liderar um time temporário de teste que poderá ser composto por desenvolvedores, engenheiros de qualidade, vendedores, usuários, etc. O coordenador escolhido deve ter um perfil pré-estabelecido para que se tenha sucesso nesse modelo, como por exemplo: experiência, credibilidade, boa comunicação e habilidades de gestão. Ainda assim, ele irá enfrentar problemas com a captação de recursos, pois como o time é temporário, os melhores recursos não serão facilmente cedidos por seus gerentes definitivos. A falta de pessoas experientes, de um ambiente de teste, de casos de teste já existentes, são outros problemas que o coordenador terá de encarar. Um dos motivos de se usar essa estratégia é quando se tem a necessidade emergente de se fazer teste e não se tem tempo, dinheiro e conhecimento para se formar um time de testes. http://www.alvarofpinheiro.eti.br
  31. 31. Equipes: Time de Qualidade Em algumas organizações o time de qualidade é responsável também pelos testes. O fato das habilidades necessárias serem bastante parecidas, ajuda os engenheiros de qualidade a terem uma maior empatia pelas atividades de teste e, consequentemente, desempenhá-las com sucesso. Um fator preocupante nessa estratégia é que testes seria uma responsabilidade a mais para o time o que pode dificultar fazer com que os testes sejam realizados com eficiência. http://www.alvarofpinheiro.eti.br
  32. 32. Equipes: Terceirização Terceirizar testes pode ser uma boa solução quando há falta de verba pra fazer teste internamente, falta de conhecimento técnico em testes ou falta de um ambiente propício. É importante salientar que apesar de estar contratando um serviço bem melhor do que o que possa ser oferecido de forma rápida internamente, o contratado possivelmente não terá o entendimento do negócio tão bem quanto o contratante. Além disso, o fato de se terceirizar os testes não elimina a responsabilidade da qualidade do produto que está sendo desenvolvido. Por isso, é importante que haja um acompanhamento do serviço que está sendo prestado. Para se ter sucesso nessa estratégia é recomendável que se tenha um bom contrato, contratar as pessoas certas, estabelecer entregas bem definidas, ter padrões de qualidade e ter uma boa visão do serviço do contratado. http://www.alvarofpinheiro.eti.br
  33. 33. Equipes: Empresa de V&V Normalmente, são realizados por um contratante independente e ao final do desenvolvimento, o que reduz maiores riscos de ter um produto funcionando com defeitos mas também pode elevar consideravelmente os custos. Por ser extremamente caro contratar uma empresa de Validade e Verificação (V&V), elas são geralmente contratadas quando se tem projetos do governo, quando se corre risco de vida no uso do sistema, em projetos de prestígio nacional, etc. http://www.alvarofpinheiro.eti.br
  34. 34. Papeis: Gerente de Testes São pessoas que precisam lidar com organizações que processam muitas linhas de comunicação formal e informal. Eles precisam lidar com recursos com vários níveis de habilidades, ferramentas, orçamentos e estimativas. O gerente é quem está à frente do time os representando nas mais diversas situações dentro e fora da empresa, o que pode afetar a percepção que as pessoas que estão fora do time de teste têm sobre este time. Deve atuar como provedor de informações, servindo de canal de comunicação de informações entre o trabalho realizado pela equipe e os stakeholders do projeto. Algumas informações importantes, por exemplo, seriam: status reports, planos, estimativas, relatórios de eficiência. http://www.alvarofpinheiro.eti.br
  35. 35. Papeis: Engenheiro de Testes Os requisitos para essa função são: Conhecimento do negócio da aplicação; Conhecimento técnico de testes; e Habilidades específicas. E as habilidades são: Dinamismo; Pensamento crítico; Comunicativo; Criatividade; Curiosidade; Maturidade; Trabalho em equipe; Facilidade de relacionamento interpessoal; Auto-motivação; Iniciativa; e Atenção aos detalhes. Fontes são: Desenvolvedores, excelentes para testes unitários, integração. E testes automáticos;Usuários, pois possuem um bom conhecimento do negócio do sistema, mas possuem pouco conhecimento técnico; Suporte, estão acostumados a descobrir problemas normalmente enfrentados pelos colaboradores da Empresa; Techinical Writers, produzem documentos técnicos e prestam bem atenção aos detalhes, podendo serem ótimos em reportar bugs, criar e organizar suites e ciclos de teste, elaborar o plano de testes; Engenheiros de Qualidade, dão importância a qualidade do software e da utilização do processo. http://www.alvarofpinheiro.eti.br
  36. 36. Quem é o testador?  O testador está diretamente associado a definição de teste de software  O testador  Encontra o bug  Busca encontrá-lo o mais cedo possível  Garante que o bug está corrigido  Um bug corrigido não necessariamente implementa em mudança no código  Correção de um manual  Correção de treinamento  Etc.  O testador deve ser responsável por verificar realmente se o bug foi corrigido http://www.alvarofpinheiro.eti.br
  37. 37. Quem é o testador?  Por que o testador é necessário?  Os testes feitos por desenvolvedores  Tendem a verificar apenas o “caminho feliz”  Normalmente são otimistas  Não são sofisticados  Organizações iniciais tem usualmente 5 testes de “caminho feliz” para cada teste de “caminho alternativo”  Organizações maduras usualmente tem o oposto - 5 de caminho alternativo para cada um de caminho feliz  Desenvolvedores normalmente só conseguem enxergar 50-60% dos casos de teste do seu código  O Testador tem um perfil diferente do desenvolvedor  São exploradores  Gostam de encontrar problemas  Criativos no uso do software  Visão das diferentes situações em que o software pode ser usado http://www.alvarofpinheiro.eti.br
  38. 38. Principais Papéis em Testes  Pode-se identificar 4 papéis principais para as atividades de testes  Gerente de Testes  Monta o plano de testes e faz o acompanhamento de todas as atividades relativas aos testes  Projetista de Testes  Identifica os casos de teste e escreve os procedimentos para cada um deles  Desenvolvedor de Testes  Implementa os casos de teste automático que foram projetados pelo projetista  Testador  Executa os casos de teste e preenche o resultado de testes  Estes papéis podem ou não ser realizados pela mesma pessoa  Isso depende de cada organização ou do tamanho / escopo do projeto  Existem outros termos que podem ser usados para descrever os papéis em atividades de teste  Durante o restante do módulo serão usados os termos definidos acima http://www.alvarofpinheiro.eti.br
  39. 39. TESTES DE SOFTWARE CICLO DE VIDA DE UM BUG http://www.alvarofpinheiro.eti.br
  40. 40. Ciclo de Vida de um Bug  O ciclo de vida de um bug determina os vários estágios pelos quais o bug passa durante o desenvolvimento do software  Este ciclo de vida precisa ser definido nas organizações  O processo de controle de mudanças é responsável pode definir o ciclo de vida  O ciclo de vida pode ser bem simples  Aberto: bug identificado no teste  Resolvido: bug resolvido  Fechado: solução verificada http://www.alvarofpinheiro.eti.br
  41. 41. Ciclo de Vida de um Bug  O ciclo de vida também pode ser bem complexo  Aberto  Resolvido como não corrigir  Resolvido como corrigido  Fechado como corrigido http://www.alvarofpinheiro.eti.br
  42. 42. Ciclo de Vida de um Bug  Algumas organizações adotam para o bug um ciclo de vida similar ao de desenvolvimento de um software  Iniciado: bug descrito  Análise: bug analisado e especificado  Implementação: bug implementado  Testes: bug testado  Fechado: bug fechado de o teste for correto http://www.alvarofpinheiro.eti.br
  43. 43. Ciclo de Vida de um Bug  O ciclo de vida genérico para um bug pode ser como o apresentado abaixo  O estado importante a ressaltar e o de análise  Nele o bug é avaliado para identificar se é ou não para ser corrigido  Esse papel é executado por um CCB http://www.alvarofpinheiro.eti.br
  44. 44. Ciclo de Vida Revisado Rejeitado Aberto Atribuído Trabalho Fechado Reaberto Adiado http://www.alvarofpinheiro.eti.br
  45. 45. TESTES DE SOFTWARE MODELOS http://www.alvarofpinheiro.eti.br
  46. 46. Engenharia de Software  As atividades de testes são inseridas no contexto das atividades de engenharia de software  TODO software segue um ciclo de vida  Existem vários modelos de ciclo de vida que podem ser adotados durante o desenvolvimento  O modelo de ciclo de vida usualmente direciona  Quais testes serão rodados  Quando os testes serão rodados  Os seguintes modelos serão discutidos  Cascata  V  Incremental  Codificar e testar http://www.alvarofpinheiro.eti.br
  47. 47. Modelo Cascata  Fases seqüências que produzem o software  Ao final de cada fase uma revisão interna deve validar se é possível passar a fase seguinte  A princípio só se deve passar a fase seguinte com a anterior finalizada  Foco principal é garantir que a especificação é bem feita antes de iniciar as fases seguintes http://www.alvarofpinheiro.eti.br
  48. 48. Modelo Cascata  O modelo em cascata é ideal para softwares bem conhecidos  Sem grandes surpresas durante a especificação  Tecnologia bem conhecida da equipe  A fase de testes é bem natural e é executada após toda a codificação  Principal vantagem para os testes  A especificação normalmente é bem feita e detalhada  Principal problema  Os testes só são executados no final  O custo de corrigir um problema é mais alto http://www.alvarofpinheiro.eti.br
  49. 49. Modelo V  Variação do modelo em cascata  Associa diferentes tipos de teste de acordo com a fase do ciclo de vida  Testes de aceitação usualmente estão associados aos requisitos  Testes de Integração usualmente estão associados ao design  Testes de componente usualmente estão associados ao código http://www.alvarofpinheiro.eti.br
  50. 50. Modelo V  O modelo V define diferentes estágios de testes para serem executados  Pode ser visto como uma extensão do modelo em cascata  Ainda existe a ênfase na especificação  Cada fase precisa ser finalizada antes do início da fase seguinte  Também é ideal para softwares com requisitos conhecidos  A grande vantagem do modelo é:  Identificar os diferentes estágios de teste que validam aspectos do ciclo de vida do software  Permite um melhor planejamento dos testes que precisam ser executados  “Quebra” os testes em diferentes focos  A principal desvantagem é:  Os testes ainda são rodados apenas após o código estar pronto http://www.alvarofpinheiro.eti.br
  51. 51. Modelo Incremental  Desenvolvimento é “quebrado” em várias iterações  Cada interação pode ser vista como uma pequena cascata  Cada interação passa por todas as fases do ciclo  Em maior ou menor escala  Requisitos são adicionados ao software em cada iteração http://www.alvarofpinheiro.eti.br
  52. 52. Modelo Incremental  O modelo incremental busca usar as vantagens do cascata  Focar em ter uma boa especificação  Mas sendo realista  Nem toda a especificação pode estar pronta no início do desenvolvimento  As iterações podem ser repetidas até que o software esteja estável  Ao final cada iteração é necessário  Determinar os objetivos da próxima iteração  Avaliar os riscos  Avaliar os testes  Avaliar os requisitos que já estão implementados  Planejar a iteração seguinte http://www.alvarofpinheiro.eti.br
  53. 53. Modelo Incremental  A principal vantagem para os testes é  Os testes são rodados várias vezes (ao final de cada iteração)  Os bugs podem ser antecipados  Os testadores usualmente podem (e devem ser) envolvidos no projeto desde o início  A principal desvantagem para os testes é  Algumas vezes não fica claro que testes devem ser rodados ao final de cada iteração  O esforço de planejamento de testes é maior  Mas esse esforço normalmente é compensado  É necessária uma equipe de testes mais experiente para planejar e executar testes neste modelo http://www.alvarofpinheiro.eti.br
  54. 54. Modelo Codificar e Testas  Parte de uma especificação informal  Ênfase em codificação  Não existe ênfase em outras fases do desenvolvimento  Como a especificação não é clara os testes também não são  Mas os testes são executados várias vezes  É ideal para projetos pequenos e com equipe pequena  Principal vantagem para os testes  Vários ciclos de testes  Custo de correção não é alto  Principal desvantagem para os testes  Planejamento e qualidade dos testes normalmente não é boa http://www.alvarofpinheiro.eti.br
  55. 55. Modelo Ágeis  Muito parecido com o codificar e testar  Foco em fechar várias versões do software  Integração continua  Especificação de requisitos informal  Mas o cliente final DEVE ficar próximo a equipe de desenvolvimento para validar os requisitos  Mas os testes  São mais formais  Devem ser automatizados  Garantir que sempre serão rodados  São executados a cada integração  Cliente pode participar da validação  Principal vantagem para os testes  Automatização  Sai a figura do testador e entra a do desenvolvedor de testes  Principal desvantagem  É necessário o uso de uma ferramenta para automatização http://www.alvarofpinheiro.eti.br
  56. 56. Modelo Ágeis: TDD  Test Driven Development  Modelo de Desenvolvimento Orientado a Testes  É uma das principais técnicas associadas a modelos ágeis  A idéia é que os testes sejam desenvolvidos antes do código  TFD: Test First Design  O passos para usar TDD são:  Escreve um caso de teste e executa um caso de teste  Falhando, implementa o código para passar no teste  Passando, continua o desenvolvimento e escreve um novo caso de testes  TODA a fase de implementação de um modelo ágil pode ser feita com TDD http://www.alvarofpinheiro.eti.br
  57. 57. TESTES DE SOFTWARE PROCESSO http://www.alvarofpinheiro.eti.br
  58. 58. Processo de teste Processo de Desenvolvimento Análise Projeto Implementação Testes Produto Final http://www.alvarofpinheiro.eti.br
  59. 59. Processo de Testes  Os processos de teste são seqüências de ações, operações que são executadas com o objetivo de  Encontrar problemas no software  Encontrá-los o mais cedo possível  Aumentar a percepção de qualidade geral do software  Garantir que o usuário final tenha um software que atende as suas necessidades  De forma geral, o processo de teste pode ser separado em 4 grandes ações  Planejar  entender o que precisa ser testado e definir como  Preparar  selecionar e montar todo o ambiente para execução  Executar  executar os testes e coletar o resultado  Avaliar  verificar os resultados e métricas para melhorar os testes http://www.alvarofpinheiro.eti.br
  60. 60. Processo de Testes  O primeiro passo para realizar as atividades relacionadas a testes em uma organização é definir um processo de testes  Este processo deve:  Definir as principais atividades que precisam ser seguidas durante os testes  Definir papéis e responsabilidades das atividades de teste  Definir as ações associadas a cada atividade  Definir as entradas e saída de cada um das atividades  Associar possíveis templates de documento a cada uma das atividades  As principais atividades que podem ser identificadas em um processo de testes são:  Planejar Testes  Projetar Testes  Implementar Testes Automáticos  Executar Testes  Avaliar Resultados http://www.alvarofpinheiro.eti.br
  61. 61. Planejar Testes  Objetivo da Atividade  Planejar as atividades de testes que serão realizadas durante o ciclo de vida do software  Responsável pela atividades  Gerente de Testes com apóio do gerente de projetos  Principais Passo  Definir estágios de testes que serão executados  Definir tipos de teste que serão necessários em cada estágio  Entender os requisitos que precisarão ser testados  Definir se algum teste será ou não automatizado  Estimar o esforço necessário para projetar e implementar os testes  Estimar o esforço necessário para executar os testes  Definir que recursos de hardware e software serão necessário para a execução dos testes (definir ambiente de testes)  Definir riscos, dependências e premissas dos testes  Montar cronograma das atividades de testes  Associar este cronograma com o cronograma principal do projeto  Artefato Gerado  Plano de Testes http://www.alvarofpinheiro.eti.br
  62. 62. Planejar Testes  É importante notar que as atividades podem mudar de acordo com o tipo de projeto  O planejamento de testes DEVE ser executado  Após ou em paralelo com as atividades de requisitos  O gerente de testes deveria ser alocado junto com o gerente de projetos  Assim como o projetista de testes DEVE ser alocado no projeto junto com o analista de requisitos  Determinar que estágios e tipos de teste serão realizados é uma das principais atividades  A atividade mais difícil de executar é a estimativa  Durante o módulo seguinte a atividade de planejamento de testes será mais detalhada http://www.alvarofpinheiro.eti.br
  63. 63. Planejar Testes: Possível Estrutura de um Plano de Testes  Introdução  Estágios de Testes  Critérios de Entrada  Critérios de Saída  Tipos de Testes  Critérios de Entrada  Critérios de Saída  Ambiente de Testes  Recursos de Hardware  Recursos de Software  Riscos, Dependências e Premissas  Cronograma http://www.alvarofpinheiro.eti.br
  64. 64. Projetar Testes de Sistema  Objetivo  Identificar os casos de teste e escrever o procedimento de testes para cada um deles  Definir qual dos casos de teste vai ser automatizado  Responsável pela atividade  Projetista de Testes  Principais Passos  Avaliar os requisitos funcionais e não funcionais  Verificar quais os tipos de testes precisarão ser executados  De acordo com isso outros passos precisarão ser realizados  Para cada requisito definir os cenários de testes associados a eles  Para cada cenário definir um caso de teste  Para cada caso de testes definir  Entradas e saídas  Pré e pós condições  Passos para execução do caso de teste  Artefato de Saída  Projeto de Testes http://www.alvarofpinheiro.eti.br
  65. 65. Projetar Testes de Sistema: avaliar especificação  Primeiro passo para projetar os testes de sistema é avaliar a especificação do software  Essa avaliação pode ser feita  Durante uma revisão formal da especificação  Após os requisitos serem fechados e antes de se projetar os testes  O ideal é que o projetista de teste participe da revisão dos testes  Requisitos NÃO devem ser fechados sem a avaliação pela equipe de testes  Cada requisito funcional precisa ser verificado para garantir  Completude  Corretude  Precisão  Consistência  Relevância  Viabilidade  Testabilidade http://www.alvarofpinheiro.eti.br
  66. 66. Projetar Testes de Sistema : avaliar especificação  Completude  Existe algo faltando no requisito? Ele contém todas as informações necessários para o seu entendimento  Corretude  O requisito apresentado realmente resolve o problema que ele se propõe?  Precisão  A descrição do requisito está clara? Existe alguma parte que pode interpretada erradamente?  Consistência  Os requisitos são consistentes entre si? Alguma requisito é contraditório com outro?  Relevância  O requisito realmente é um requisito? Ou é algum aspecto de design que deveria ser tratado posteriormente? http://www.alvarofpinheiro.eti.br
  67. 67. Projetar Testes de Sistema : avaliar especificação  Viabilidade  É possível implementar esse requisito ? A tecnologia atual permite que ele seja implementado?  Testabilidade  O requisito pode ser testado ? É possível gerar um procedimento de testes que valide se o requisito está implementado corretamente?  Os requisitos funcionais NÃO devem ser esquecidos  É necessário garantir que estes estão claramente especificados  Qual o requisito de segurança?  Existe requisito de performance? Qual é?  Existe alguma restrição de ambiente? Qual o banco de dados e o servidor de aplicação que deve usado?  Existem alguma restrição de tecnologia? http://www.alvarofpinheiro.eti.br
  68. 68. Projetar Testes de Sistema : avaliar especificação  Outros aspecto importante a avaliar são os termos usados na descrição dos requisitos  Termos como  Sempre ou nunca: é necessário verificar se eles realmente significam isso no requisito  Bom, rápido, pequeno, estável: palavras assim não denotam requisitos testáveis e devem ser evitadas  Se .. Então ..: sempre que um Se.. Então for entrado e importante especificar o que ocorre no senão  Etc. : TODOS os etc. devem ser removidos da especificação http://www.alvarofpinheiro.eti.br
  69. 69. Projetar Testes de Sistema  Os casos de teste de sistema são caixa preta e são executados sobre todo o sistema  A avaliação dos requisitos é a atividade principal  O ideal é que o projetista de testes participe da revisão dos requisitos para garantir que  Cada requisito está claramente especificado  Cada requisito é testável  Os cenários de cada requisito são claramente definidos  Os requisitos funcionais estão corretamente especificados  Sem as informações acima não é possível projetar os casos de teste corretamente  A baixa qualidade dos testes está diretamente associada a baixa qualidade dos requisitos  A atividade de projetar testes será melhor detalhada no módulo seguinte http://www.alvarofpinheiro.eti.br
  70. 70. Projeto de Testes Unitário  Objetivo  Avaliar uma unidade de código antes que esta seja integrada ao restante do sistema  Responsável pela atividade  Desenvolvedor  Principais passos  Determinar abordagem de testes: caixa branca ou preta  Am ambos os casos é necessário  Avaliar o código  Identificar que stubs precisam ser implementados  Identificar que fluxos de execução precisam ser testados  Avaliar a interface da unidade a testar  Baseado nas informações acima, definir os casos de testes e definir o procedimento de testes  Artefato de Saída  Procedimentos de testes unitários http://www.alvarofpinheiro.eti.br
  71. 71. Projeto de Testes Unitário  Os stubs vão garantir o isolamento da unidade  Os testes unitários usualmente são definidos em código  Os casos de teste e procedimentos podem ser documentos em um projeto de testes unitários  Ou podem ficar apenas no código sob controle do desenvolvedor  Projetos de testes unitários são de difícil manutenção  Os testes unitários podem ser automatizados para facilitar a manutenção e a execução posterior  Quanto melhor os testes unitários menor o número de problema que serão encontrados durante a integração  Testes unitários fazem parte do processo de desenvolvimento e normalmente NÃO são tratados como parte do processo de testes http://www.alvarofpinheiro.eti.br
  72. 72. Projeto de Testes de Componente  Objetivo  Mesmo dos testes unitários, mas agora considerando o componente como unidade  Responsável pela atividade  Projetista de Testes  Principais passos  Mesmos dos testes unitários, com exceção de verificar a abordagem  Testes de componente usualmente são caixa preta  Artefato de Saída  Projeto de testes de componente  Como a interface do componente é bem definida e controlada, o projeto de testes de componente usualmente é feito e documentado  Testes de componente são usualmente definidos em código e podem ser automatizados http://www.alvarofpinheiro.eti.br
  73. 73. Projeto de Testes de Componente  O projeto de testes está altamente associado ao tipo de interface do componente  Este tipo pode ser  Web service  Interface de uma classe  HTTP ou Socket  Serial  Objeto remoto (CORBA, COM, RMI)  Um protocolo de comunicação é implementado em cima de uma dessas interfaces  Este protocolo é que precisa ser testado  Quando a interface é programática o teste se terna mais similar a um teste unitário de uma classe  Web service e objetos remotos http://www.alvarofpinheiro.eti.br
  74. 74. Projeto de Testes de Componente  Alguns Exemplos de componentes testáveis  Software POS que ler cartões de crédito  Um software que POS se comunica com um leitor de cartão de crédito via serial  O leitor de cartão tem um protocolo bem definido  Esse protocolo é implementado pelo software do POS  O POS precisa ser testado para suportar todos os possíveis dados que podem ser enviados pelo leitor  Software de atendimento médico. Componente que implementa regras de negócio para aceitar um paciente  Esse componente encapsula todas as regras para aceitar ou não um paciente  Ele é disponibilizado através de uma interface Java  TODAS as possíveis situações em que um paciente pode ser aceitou ou não precisam ser validadas  Dessa validação vai depender uma grande parte da funcionalidade do software http://www.alvarofpinheiro.eti.br
  75. 75. Projeto de Testes: Possível Estrutura do Projeto  Introdução  Ambiente de Testes  Requisito 1  Caso de Teste 1  Pre-condição  Pós-condição  Cenário  Procedimento  Entradas / Saídas  Caso de Teste N  Requisito M http://www.alvarofpinheiro.eti.br
  76. 76. Implementar Testes de Sistema e/ou Componente  Objetivo  Caso alguns dos procedimento de testes possa ser automatizados, eles devem ser implementados segundo o procedimento  Responsável pela atividade  Desenvolvedor de testes  Principais passos  Configurar a ferramenta de automação de testes  Determinar os dados de entrada e saída de cada caso de teste  Determinar o procedimento a ser executado em cada caso de teste  Implementar os scripts de teste na linguagem determinada pela ferramenta  Validar os scripts de teste unitariamente  Artefato de Saída  Scripts de teste implementados http://www.alvarofpinheiro.eti.br
  77. 77. Implementar Testes de Sistema e/ou Componente  A implementação dos testes é totalmente direcionada pela ferramenta de testes  É importante que cada organização defina uma ferramenta de testes padrão  Testes de componente são mais fáceis de automatizar  Cada componente tem uma interface bem definida  Essa interface é sempre programática  Testes de sistema são mais complexos  Em geral envolvem interação com o usuário  Existem ferramentas que permitem a automatização de testes com interfaces gráficas, mas  Mudanças de interface são mais comuns que mudanças  Isso torna a manutenção dos testes complicada  É necessário avaliar o custo benefício de automatizar os testes de sistemas  Não necessariamente todos os testes devem ser automatizados  Alguns testes são melhor e mais rapidamente executados por testadores http://www.alvarofpinheiro.eti.br
  78. 78. Implementar Testes de Sistema e/ou Componente  Existem várias vantagens de automatizar os testes  Velocidade de execução: testes automáticos são mais rápidos de executar  Eficiência: enquanto os testes estão sendo executados, os testadores podem ser alocados em outras atividades  Corretude: casos de testes automáticos nunca comentem erros durante a execução. Os passos sempre são repetidos da mesma forma  Simulação / emulação: ferramentas de testes podem ser usadas como stubs ou test drivers  Simplificação: alguns testes seriam tão complexos que rodar manualmente que a automação acaba sendo a única forma de executá-los  A corretude é uma das principais vantagens, mas também é uma limitação  Os testadores conseguem enxergar problemas que os testes automáticos não identificam  Os passos executados por um testador podem variar de uma execução para outra http://www.alvarofpinheiro.eti.br
  79. 79. Implementar Testes de Sistema e/ou Componente  Alguns fatos importantes em relação a automação  Mudanças no software  Os software muda e isso torna os testes falhos  É necessário atualizar os casos de testes automáticos da mesma forma que os manuais  Testes se sistema automatizados são complexos de implementar  Testes de sistema validam especialmente interação com o usuário  Existem ferramentas para validar essa UI, mas são complexas de usar  Vários bugs de UI podem escapar  Não se pode confiar apenas na automação  O olho do testador vai conseguir encontrar problemas que a ferramenta não  Algumas ferramentas são “invasivas”  Modificam o código sendo testado  O código final pode não ser correto devido a isso http://www.alvarofpinheiro.eti.br
  80. 80. Implementar Testes de Sistema e/ou Componente  Conclusões  Automatizar testes é uma excelente prática, mas deve ser feita com cuidado  A ferramenta de automatização deve ser bem escolhida  Deve se avaliar quais testes valem a pena serem automatizados  Avaliar o custo-benefício da automatização  Não se deve confiar apenas nos testes automáticos http://www.alvarofpinheiro.eti.br
  81. 81. Executar Testes  Objetivo  Executar os testes planejados e coletar os resultados  Responsável pela atividade  Testador  Principais passos  Os testes a executar devem ser definidos pelo projetista / gerente de testes  Para testes manuais, o testador deve seguir o procedimento de testes aplicando todas as entradas e verificando as saídas  Para testes automáticos e testados deve configurar a ferramenta de testes e colocar os scripts de teste para rodar  Os resultados de testes devem coletados  Artefato de Saída  Resultado de testes http://www.alvarofpinheiro.eti.br
  82. 82. Executar Testes  O setup para a execução de testes automáticos pode ser bem demorado  Essa atividade NÃO deve ser sub-estimada  Os testes manuais devem ser realizados com muito cuidado pelo testador  Alguns testes podem ser exploratórios  O testados deve se prender ao procedimento  Mas caso algum problema fora do procedimento seja encontrado, ele tem obrigação de reportar o problema  O testador também deve validar se o procedimento de testes está correto  Problemas no procedimento também devem ser reportados  Na dúvida, o testador DEVE reportar como erro  É melhor ter um falso positivo que deixar um bug passar  O testador deve na medida do possível dominar os requisitos que estão sendo testados http://www.alvarofpinheiro.eti.br
  83. 83. Executar Testes: passo-a-passo para executar testes  Selecionar que casos de testes serão executados de acordo com o planejamento  Atribuir os casos de testes para os testadores  Executar o caso de teste e reportar os bugs. Capturar informações continuamente levando em conta as execuções anteriores  Fazer o setup do ambiente de testes de acordo com o procedimento  Entrar os dados especificados e esperar pelas saídas determinadas  Avaliar os resultados, comportamentos e estado final do software. Pesquisar qualquer diferença com o resultado esperado  Caso ocorra um problema no software, reportar  Caso um problema seja encontrado no caso de teste, reportar  Capturar as informações sobre o teste que foi executado  Resolver possíveis issues que estejam bloqueando os testes  Reportar os resultados periodicamente http://www.alvarofpinheiro.eti.br
  84. 84. Executar Testes: passo-a-passo para executar testes  Durante a execução de um caso de teste, este pode está em diferentes estados  Em alguns software é importante identificar estes possíveis estados  Os estados algumas vezes estão associados aos resultados dos testes  Alguns possíveis estados genéricos  Queued  Block  Skip  In Progress  Pass  Warn  Fail  Closed http://www.alvarofpinheiro.eti.br
  85. 85. Executar Testes: passo-a-passo para executar testes  Queued  Caso de teste atribuído a um testador e esperando para ser executado  Block  Execução bloqueada por alguma razão  Skip  Execução não realizada por alguma razão  In Progress  Caso de teste sendo executado  Pass  Caso de teste passado  Warn  Algum comportamento não ocorreu como esperado, mas o problema não parece grave  Fail  Algum comportamento grave ocorrer  Closed  Após um teste Fail ou de Warn, o software foi corrigido e o problema fechado http://www.alvarofpinheiro.eti.br
  86. 86. Avaliar Resultados  Objetivo  Consolidar os dados gerados pela execução dos testes e avaliar os resultados para poder tomar decisões em relação ao projeto  Responsável pela atividade  Gerente de Testes  Principais passos  Coletar toda a informação sobre os resultados dos diferentes estágios  Avaliar se todos os testes que estavam planejados foram realmente executados  Caso algum problema tenha ocorrido durante a execução, isso deve ser avaliado  Reportar os resultados para o restante do projeto do software  Avaliar se os critérios esperados de resultados de testes foram atingidos.  Caso não tenha sido buscar identificar se ocorreu algum problema durante os testes  Artefato de Saída  Resultado dos testes http://www.alvarofpinheiro.eti.br
  87. 87. Avaliar Resultados  A avaliação dos resultados é fundamental pois é a conclusão de cada uma das execuções de teste  Ela é a base para tomadas de decisões gerenciais de todo o projeto  Caso os testes estejam falhando mais que o esperado, alguma ação precisará ser tomada  Caso os testadores estejam com problema para executar os testes alguma ação  Caso o procedimento de testes esteja com muitos problema, ele provavelmente deverá ser revisto http://www.alvarofpinheiro.eti.br
  88. 88. Avaliar Resultados: Informações Importantes de consolidar  Várias informações podem ser consolidadas na avaliação da execução dos testes  Quantidade de Testes Planejados  Número total de casos de testes que foram planejados para execução  Quantidade de Testes Executados  Número total de casos de testes que foram realmente executados  Quantidade de Testes Passados  Número total de casos de testes que passaram  Quantidade de Testes Falhos  Número total de casos de testes que falharam  Quantidade de Testes Bloqueados  Número total de casos de testes bloqueados  Quantidade de Bugs Encontrados  Número total de bugs encontrados durante os testes  Tempo total de execução dos testes  Tempo total de execução dos testes http://www.alvarofpinheiro.eti.br
  89. 89. Avaliar Resultados: Informações Importantes de consolidar  As informações listadas anteriormente podem ser combinadas em diferentes métricas  Estas métricas são usadas para  Acompanhar o processo de testes  Avaliar a eficácia dos testes  Avaliar a eficiência dos testes  Avaliar o custo dos testes  O módulo seguinte vai detalhar as possíveis métricas em testes de software http://www.alvarofpinheiro.eti.br
  90. 90. Planejamento de Testes Reflexão  Foram encontrados defeitos? Quantos?  Algum defeito foi corrigido?  Houve alguma preocupação com a classificação dos defeitos?  Quantos dos defeitos eram muito críticos?  Como os defeitos foram reportados?  Existe algum plano de correção dos defeitos?  Todos os recursos necessários para realização dos testes estavam presentes?  O ambiente estava configurado?  Quem participou da execução?  Que versão da release era essa? Ela estava estável?  Os testes acabaram?  Quais os próximos passos? http://www.alvarofpinheiro.eti.br
  91. 91. Planejamento de teste Planejamento:  Quem executará os testes?  Que partes serão testadas? (tempo/recurso)  Quando serão executados os testes (cedo)  Como serão realizados os testes? (especificação/implementação)  Quanto devemos testar? http://www.alvarofpinheiro.eti.br
  92. 92. Planejamento de teste Principais atividades do planejamento: • Determinar o escopo e os riscos e identificar o objetivo dos testes; • Determinar a abordagem de teste (caixa-preta/ caixa-branca); • Determinar os recursos necessários (pessoas, máquinas, ambiente de teste); • Determinar a estratégia de teste; • Montar cronograma das tarefas • Determinar critérios de entrada e saída. http://www.alvarofpinheiro.eti.br
  93. 93. Planejamento de Testes  Planejar os testes significa  Identificar que estágios de testes serão executados (estratégia de testes)  Identificar os ciclos de testes  Identificar o que será testado  Identificar os recursos necessários para os testes  Identificar os riscos, dependências e premissas dos testes  Definir um cronograma das atividades de testes  O gerente de testes é o responsável principal por realizar essas atividades  A principal saída da atividade de planejamento de testes é o  Plano de Testes http://www.alvarofpinheiro.eti.br
  94. 94. TESTES DE SOFTWARE PROJETO http://www.alvarofpinheiro.eti.br
  95. 95. Projeto de Teste Entradas e Saídas Planejamento de Testes Plano de Projeto Cronograma do Projeto Informações sobre o sistema Plano de teste http://www.alvarofpinheiro.eti.br
  96. 96. Projeto de Teste Atividades do Projeto de Teste Análise dos requisitos Especificação dos casos de teste Seleção de casos de teste http://www.alvarofpinheiro.eti.br
  97. 97. Projeto de Teste Entradas e Saídas Projeto de Teste Plano de Teste Documento de requisitos Base de teste (plano de negócio, documento de marketing, plano de projeto, etc) Casos de teste http://www.alvarofpinheiro.eti.br
  98. 98. TESTES DE SOFTWARE ABORDAGENS http://www.alvarofpinheiro.eti.br
  99. 99. Abordagem de Teste  Existem 2 abordagens principais na execução de testes  Caixa Preta  Caixa Branca  Testes caixa preta são aqueles nos quais o testador não vê o “interior” do objeto que está sendo testado  Usualmente executados por um testador que é diferente do desenvolvedor  Avalia todas as diferentes entradas e suas respectivas saídas para garantir que o software se comporta como especificado  Associado a estágios de teste como sistema ou componente http://www.alvarofpinheiro.eti.br
  100. 100. Abordagem de Teste  Testes caixa branca são aqueles nos quais o testador sabe como funciona o “interior” do objeto sendo testado  Usualmente são executados pelo próprio desenvolvedor  São fortemente associados aos testes unitários  Avalia TODOS os caminhos lógicos do código para garantir que TODOS os fluxos são executados corretamente  Busca encontrar bugs, mas bugs no código e não bugs na especificação, por exemplo  A grande maioria dos software realiza apenas testes caixa preta  Quando testes caixa branca são executados, eles não são formalizados  Não existe procedimento bem definido  Não existe resultado de testes documentado  Caso um procedimento de testes caixa branca seja escrito, existe grande chance dele ser descartado após a execução dos testes http://www.alvarofpinheiro.eti.br
  101. 101. Testes Positivos e Testes Negativos  Testes positivos verificam se o caminho feliz é executado corretamente  Testes negativos verificam as exceções  Testes positivos  Garantem que o software funciona minimamente como esperado  Garantem que o software não quebra para as suas operações principais  Não levam o software aos seus limites para identificar possíveis falhas  Testes negativos  Buscam realmente quebrar o software  Focam em identificar problemas  Garantem que o software funciona em diversas situações diferentes  Ambos os tipos de testes devem ser realizados http://www.alvarofpinheiro.eti.br
  102. 102. TESTES DE SOFTWARE TÉCNICAS http://www.alvarofpinheiro.eti.br
  103. 103. Técnicas de Teste –Análise de requisitos  Análise de requisitos  Começar a pensar na matriz de rastreabildiade:  Identificar quais testes serão impactados quando determinado requisito for modificado  Saber se existem teste para cada requisito  Avaliar grau de cobertura http://www.alvarofpinheiro.eti.br
  104. 104. Técnicas de Teste – Seleção de casos de teste Técnicas de Teste  Baseada na especificação (caixa-preta)  Baseada na estrutura (caixa-branca)  Baseada na experiência http://www.alvarofpinheiro.eti.br
  105. 105. Técnicas de Teste – Seleção de casos de teste  Técnicas de Teste  Baseada na especificação (caixa-preta) 1. Partição por equivalência 2. Análise de valores limites 3. Tabelas de decisão / Tabela Causa-Efeito 4. Testes derivados de casos de uso  Baseada na estrutura (caixa-branca)  Baseada na experiência http://www.alvarofpinheiro.eti.br
  106. 106. Técnicas de Teste – Seleção de casos de teste  Técnicas de Teste  Baseada na especificação (caixa-preta)  Baseada na estrutura (caixa-branca)  Cobertura e Teste baseado em instruções  Cobertura e Teste baseado em laços de decisões  Baseada na experiência http://www.alvarofpinheiro.eti.br
  107. 107. Técnicas de Teste – Seleção de casos de teste  Técnicas de Teste  Baseada na especificação (caixa-preta)  Baseada na estrutura (caixa-branca)  Baseada na experiência  Error guessing  Testes Exploratórios http://www.alvarofpinheiro.eti.br
  108. 108. Técnicas de Teste – Testes vs. Inspeções  Inspeções dos artefatos buscam validar os artefatos antes que a próxima fase do desenvolvimento seja iniciada  Vários estudos indicam que o custo de encontrar um erro com inspeção é menor que o custo de encontrar com testes [Kaplan 1995]  3,5 horas de esforço para encontrar um erro com inspeção  15-25 horas de esforço para encontrar um erro com testes  Isso não significa que testes não são necessários  Mas que outras técnicas também podem ser aplicadas http://www.alvarofpinheiro.eti.br
  109. 109. Técnicas de Teste – Encontrar Bugs  Inspeção de Software  Processo formal de verificação do software  Pode ser aplicado para praticamente todos os artefatos gerados durante o ciclo de desenvolvimento  Tem o custo mais alto de aplicar, mas também é o que produz o melhor resultado  Combinação de inspeções na especificação, design e código podem encontrar até 85% dos bugs de um software  Como o processo é formal, ele é fácil de mensurar e de acompanhar  Prototipação  Ajuda no levantamento e definição dos requisitos  Dá uma boa visão para o cliente do que vai ser o software final  Reduz bastante as duvidas de usabilidade e de como as funções devem ser implementadas http://www.alvarofpinheiro.eti.br
  110. 110. Técnicas de Teste – Encontrar Bugs  Programação por pares  Técnica definida em XP (Extreme Programming)  2 desenvolvedores por computador  1 programador digita  1 programador procura por erros  Possui várias vantagens  Facilita mentoring de novos desenvolvedores  Dissemina a cultura da empresa  Pode chegar a encontrar a mesma quantidade de problemas da inspeção  É mais aplicável para a fase de codificação  Walkthroughs e Code Reading  Similar a inspeção, mas sem o formalismo de um processo http://www.alvarofpinheiro.eti.br
  111. 111. TESTES DE SOFTWARE ESTÁGIOS http://www.alvarofpinheiro.eti.br
  112. 112. Unidade, Componente e Integração  Um software em geral é quebrado em diferentes componentes (ou módulos principais)  Cada componente é quebrado em unidades (sub-componentes)  Estes unidades precisam ser integradas em componentes  Os componentes precisam ser integrados no software como um todo http://www.alvarofpinheiro.eti.br
  113. 113. Unidade, Componente e Integração  Testes precisam ser executados  Na unidade para garantir que esta funciona separadamente  No componente para garantir que quando as unidades foram integradas, eles continuam funcionando  No sistema como um todo para garantir que os componentes integrados funcionam corretamente  O escopo de cada um desses testes é bem diferente  Todos buscam encontrar bugs  Mas tipos diferentes de busca usualmente são encontrados  Um teste não substitui o outro http://www.alvarofpinheiro.eti.br
  114. 114. Estágios de Teste  O termos “Estágio de Teste” é usualmente aplicado ao teste que está associado a uma determinada fase do ciclo de desenvolvimento  Relembrado o Modelo V, tem-se:  Testes Unitários  Testes de Componente  Testes de Integração  Testes de Sistema  Testes de Aceitação http://www.alvarofpinheiro.eti.br
  115. 115. Estágios de Teste  Testes Unitários  Executados pelo desenvolvedor para validar a unidade que está sendo implementada  Testes de Componente  Executado pelo testador para validar um componente específico do software  Testes de Integração  Executado pelo testador para garantir que vários componentes funcionam corretamente juntos  Testes de Sistema  Executados pelo testador para garantir que as funcionalidades do software estão de acordo com a especificação  Testes de Aceitação  Executados pelo usuário para garantir que o software faz o que foi inicialmente requisitos pelo usuário  Cada um destes estágios será melhor detalhado posteriormente http://www.alvarofpinheiro.eti.br
  116. 116. Estágios e Tipos de Testes  Anteriormente foi listado brevemente alguns estágios e diferentes tipos de testes  Os seguintes estágios e tipos serão abordados  Estágios  Testes Unitários  Testes de Componente  Testes de Sistema  Testes de Aceitação  Tipos de Teste  Testes de Carga  Testes de Performance  Testes de Uso de Memória  Testes de Usabilidade  Teste de Configuração  Testes de Compatibilidade  Testes de Documentação http://www.alvarofpinheiro.eti.br
  117. 117. Estágios – Testes Unitários  Testes unitários são testes isolados executados sobre uma rotina, classe ou pequena arte do programa  Esses testes são executados pelo próprio desenvolvedor para garantir que a sua unidade pode ser integrada com o resto do software  Dois aspectos fundamentais  Os testes são isolados  Os testes são implementados e executados pelo próprio desenvolvedor  Testes isolados  Stubs devem ser implementados para suprir alguma parte da funcionalidade ou gerar valores errados para validar a unidade  Os componentes externos a unidade em testes devem ser simuladas  Testes executados pelo desenvolvedor  Os testes são normalmente rodados no ambiente de desenvolvimento  Os casos de testes focam apenas na unidade em testes sem se preocupar com a interação com outras unidades http://www.alvarofpinheiro.eti.br
  118. 118. Estágios – Testes Unitários  Testes unitários podem ter a abordagem caixa branca ou caixa preta  Testes caixa branca são bem importantes pois ajudam a validar todos os fluxos de execução  A formalização de casos de testes unitário  É feita em algumas organizações  Principal dificuldade é dá manutenção nos casos de testes  Na maioria das vezes os casos de teste são jogados fora após os testes (especialmente os caixa branca)  O resultado do testes unitários algumas vezes também é formalizado  Mas a sua análise não tem tanto sentido em algumas situações http://www.alvarofpinheiro.eti.br
  119. 119. Estágios – Testes Unitários  Automação de testes unitários  É uma das principais formas de garantir que os casos de teste não sejam “jogados fora”  Existem várias ferramentas que focam na automação dos casos de testes  Gerar / implementar os scripts de testes  Executar os scripts de testes  Coletar os resultados da execução  Estas ferramentas rodam os testes sem intervenção do desenvolvedor  Principal vantagem  Facilita a manutenção dos testes  Os Testes podem ser rodados automaticamente para garantir que as unidades não quebraram  Principal problema  O custo de especificar e implementar os scripts é alto  É necessário avaliar o custo / benefício para cada software (ou para cada parte do software) http://www.alvarofpinheiro.eti.br
  120. 120. Estágios – Testes Unitários  Processo de desenvolvimento orientado a testes unitários  Atualmente existem processos de desenvolvimento orientados a testes unitários  TDD (Test Driven Development)  O princípio fundamental é  Desenvolver o teste antes do código  Principal vantagem  Casos de teste estão sempre atualizados  O código é feito para passar nos testes  O requisito é bem entendido antes de iniciar a implementação  Os testes são pensados com muito cuidado  Novos casos de testes podem ser facilmente adicionados  Principal desvantagem  Custo do desenvolvimento dos testes  É necessário avaliar beneficio de acordo com o projeto  A equipe precisa ter maturidade para entender a importância dos testes e saber implementar os casos de teste http://www.alvarofpinheiro.eti.br
  121. 121. Estágios – Testes Unitários  Passos para identificar casos de testes unitário caixa preta  Avaliar a interface da rotina a testas  Avaliar os parâmetros e seus possíveis valores  Avaliar TODOS os possíveis retornos de acordo com cada possível combinação de parâmetros  Encontrar os limites dos parâmetros que vão fazer com que o retorno mude  Avaliar todos os possíveis erros que podem ser gerados  Encontrar as combinações de parâmetros que devem gerar erro  Passos para identificar casos de testes unitários caixa branca  Avaliar todos os fluxos de execução da rotina  Avaliar as funções que são usadas internamente e seus retornos  Avaliar como vai se comportar a rotina caso as funções internas retornem valores diferentes do esperado  Avaliar se todos os possíveis fluxos de execução são tratados  Avaliar se todos os fluxos codificados realmente podem ser atingidos http://www.alvarofpinheiro.eti.br
  122. 122. Estágios – Testes Unitários: Exemplo  Considerando o código abaixo /** * Retorna a lista de contas bancarias de uma determinada pessoa * @param id identificar de uma pessoa */ Vector getContas (IDPessoa id) { Vector resultado = new Vector (); for (int i = 0; i < contas.size(); i++) { Conta c = contas.elementAt(i); if (c.getIDPessoal().equals (id)) { resultado.addElement(c); } } return resultado; } Os seguintes casos de teste unitários caixa preta podem ser identificados:  Passar como parâmetro um ID de pessoa nulo  Passar como parâmetro um ID de pessoa inválido  Passar como parâmetro um ID de pessoa que tem apenas uma conta  Passar como parâmetro um ID de pessoa que não tem conta http://www.alvarofpinheiro.eti.br
  123. 123. Estágios – Testes de Componente  Muito parecidos com os testes unitários. Definição quase igual:  Esses testes são executados pelo próprio desenvolvedor para garantir que a sua unidade pode ser integrada com o resto do software  A principal diferença é que  Testes de componente devem ser implementados por uma equipe diferente da equipe de desenvolvimento  A equipe de desenvolvimento executa os testes de componente, mas uma equipe externa também pode executá-los  Testes de componente são aplicáveis quando o software é grande em vários componentes que interagem entre si  Os componentes  São compostos por diferentes unidades internas  Tem uma interface bem definida que é utilizado por outros componentes  Usam serviços providos por componentes externos http://www.alvarofpinheiro.eti.br
  124. 124. Estágios – Testes de Componente  A equipe de testes separada pode  Estudar a especificação do componente  Desenvolver um conjunto de testes para o componente (que podem ser ou não automatizados)  Executar esses testes para cada versão do componente que for fechada  Os testes de componente garantem que  Cada componente está funcionando conforme a sua especificação individualmente  Com isso os componentes podem ser integrados e o software completo pode ser testado http://www.alvarofpinheiro.eti.br
  125. 125. Estágios – Testes de Componente  A principal vantagem de se usar testes de componentes é  Uma equipe diferente da desenvolvimento vai pensar nos casos de teste  Isso garante uma melhor qualidade e cobertura dos testes (como foi visto anteriormente)  A principal desvantagem  É necessário definir claramente os componentes do software  O desenvolvimento também precisa ser “quebrado” em componentes  Isso pode não ser simples de fazer em alguns projetos  Quando testes de componente são realizados, usualmente é definido um estágio chamado de Testes de Integração  Todas as unidades são integradas e os problema de integração são resolvidos antes do teste de sistemas  Os testes de integração podem ser bem complexos de executar, casos o software seja muito grande http://www.alvarofpinheiro.eti.br
  126. 126. Estágios – Testes de Componente: Exemplo  Considerando uma interface de um componente HTTP que recebe parâmetros via HTTP GET /** * HTTP GET htp://servername/getConta?pessoaID=<idNumber> * Retorna: idConta1;idConta2;idConta3;..;idContaN */ Os seguintes casos de teste podem ser identificados:  Tentar ter acesso a uma página diferente do servidor (getPessoa)  Tentar ter acesso a página getConta, mas sem nenhum parâmetro  Tentar ter acesso a página getConta, mas com um parâmetro diferente de pessoaID  Tentar ter acesso a página getConta, mas com mais de um parâmetro  Tentar ter acesso a página getConta com o parâmetro pessoaID como segundo parâmetro  Tentar passar o parâmetro via HTTP POST http://www.alvarofpinheiro.eti.br
  127. 127. Estágios – Testes de Sistema  Valida a funcionalidade principal do software  Tem como objetivo garantir que o software está implementando corretamente o que foi especificado  É direcionado então para especificação do software  Os casos de teste são definidos, especificados e executados por uma equipe de testes separada  Esta é equipe pode até ser uma organização separada da organização que faz o desenvolvimento  Aspectos subjetivos do software também devem ser avaliados  Qualidade geral da UI do software  Facilidade de uso do software  Performance do software  Facilidade instalação  Clareza das mensagens  etc http://www.alvarofpinheiro.eti.br
  128. 128. Estágios – Testes de Sistema: Exemplo  Considerando o seguinte caso de uso UC001: Listar contas Precondição: usuário logado no sistema no menu principal Fluxo Principal: 1. O usuário seleciona a opção listar contar. O sistema apresenta uma lista de pessoas (pode executar fluxo alternativo 2 ou 3) 2. O usuário seleciona uma pessoa específica. O sistema retorna um formulário com a lista de contas dessa pessoa (pode executar fluxo alternativo 1) Fluxo alternativo 1. A pessoa não tem contas: uma mensagem é apresentando indicando que a pessoa selecionada não tem contas 2. O usuário não tem permissão de acesso: uma mensagem de erro é apresentada indicando que o usuário não tem permissão 3. Nenhuma pessoa cadastrada no sistemas: a lista é apresentada vazia Os seguintes casos de teste podem ser identificados:  Listar as contas de uma pessoa que não tem contas  Listar as contas de uma pessoa que tem várias contas  Entrar com um usuário que não tem permissão de listar pessoas e tentar listar pessoas  Entrar no sistema sem nenhuma pessoa cadastrada  Listar contas de uma pessoa e em seguida listar de outras pessoas http://www.alvarofpinheiro.eti.br
  129. 129. Estágios – Testes de Aceitação  São os testes realizados pelo usuário que contratou o desenvolvimento do sistema  Valida que a necessidade inicial do cliente quando o desenvolvimento do software foi contratada foi atendida  Foco não é na especificação, mas na necessidade do cliente  Por mais que especificações sejam escritas e aprovadas pelo cliente  É comum que alguma necessidade não seja totalmente atendida  Algumas vezes a necessidade original foi implementada de outra forma  Outros problemas como  Usabilidade, performance ou estabilidade do software também podem ser identificados  A organização que desenvolveu o software não tem muito controle sobre a aceitação  Um processo de aceitação pode ser definido, mas o cliente também pode ter seu processo interno http://www.alvarofpinheiro.eti.br
  130. 130. Estágios – Testes de Aceitação: Exemplo  Considerando o caso de uso de listar contas de uma pessoa  A necessidade do cliente é:  Ter um cadastro de pessoas  Ter um cadastro das contas de cada pessoa  Poder visualizar em uma mesma tela as pessoas e suas respectivas contas  Os seguintes casos de teste podem ser identificados:  Entrar no sistema e verificar se a tela de lista de pessoas apresenta todas as pessoas cadastradas  Verificar se é possível selecionar uma pessoa e ver suas contas na mesma tela  Verificar se todas as contas de uma determinada pessoa realmente são apresentadas http://www.alvarofpinheiro.eti.br
  131. 131. Sequência de Estágios de Testes Unitário Componente Integração Sistema Aceitação Desenvolvedores Engenheiro de Testes Cliente ou Usuário http://www.alvarofpinheiro.eti.br
  132. 132. Seqüência de Estágios de Testes  Vantagens de quebrar os testes em diferentes estágios  Cada estágio foca em problemas diferentes  Os testes estruturais garantem a estabilidade do software, antes de se buscar encontrar problemas comportamentais  Os testes comportamentais são rodados em um software estável  É mais fácil de fazer o acompanhamento do projeto  Cada estágio deve ser iniciado o mais cedo possível  Bugs devem ser encontrados o quanto antes  O momento de iniciar cada estágio deve ser determinado no plano de testes O plano de testes deve focar em quais estágios de teste? Testes de aceitação fazem parte do planejamento de testes? http://www.alvarofpinheiro.eti.br
  133. 133. TESTES DE SOFTWARE TIPOS http://www.alvarofpinheiro.eti.br
  134. 134. Tipos de Testes: Unitários É o processo de verificação de que o código faz o que a especificações diz que ele deve fazer. Seu propósito é verificar se toda lógica necessária está presente e que funciona adequadamente de maneira automática. Testes unitários é uma atividade tipicamente realizada por desenvolvedores. É de sua responsabilidade provar que o software produzido faz exatamente o que se supõe que ele deve fazer e que não há nenhuma funcionalidade faltando. Testes de unitários são escritos a partir da perspectiva do programador. Eles asseguram que um determinado método de uma classe realiza com êxito a um conjunto de tarefas específicas. Cada teste confirma que o método produz os resultados esperados, quando recebe uma entrada conhecida. http://www.alvarofpinheiro.eti.br
  135. 135. Tipos de Testes: Funcionais Servem para dizer que o código deve fazer as coisas certas. São escritos a partir da perspectiva do usuário. Estes testes confirmam que o sistema deve fazer o que os usuários estão à espera que faça. Muitas vezes o desenvolvimento de um sistema computacional é relacionado à construção de uma casa. Embora esta analogia não seja completamente apropriada, dado as especificidades de cada projeto. Este modelo pode ser estendido e utilizado na compreensão das diferenças entre testes de unidade e testes funcionais. Teste de unidade se assemelha a um inspetor de obras visitando uma casa em construção. Ele está focado nos diversos sistemas internos da casa, a fundação, o sistema hidráulico, rede elétrica, canalização, e assim por diante. Por outro lado, testes funcionais neste cenário são análogos a visitação do dono da casa a esta mesma construção. Ele assume que os sistemas internos irão comportar-se adequadamente, já que o inspetor de construção realizou bem sua tarefa. http://www.alvarofpinheiro.eti.br
  136. 136. Tipos de Testes: TestDriver e Stub de Testes  Um test driver é um componente de software que simula as entradas reais do software  Por exemplo, um software de calculadora recebe números e operações  Um test driver para este software pode entrar um grande combinação diferente de números e combinações para validar a calculadora http://www.alvarofpinheiro.eti.br
  137. 137. Tipos de Testes: TestDriver e Stub de Testes  O stub de test é utilizado para testar o software de baixo para cima  O stub simula resultados que são retornados por um determinado componente que o software depende http://www.alvarofpinheiro.eti.br
  138. 138. Tipos de Teste  Frequentemente confundidos com os estágios de teste  “Tipos de Testes” identificam os diferentes testes que podem ser realizados em cada um dos estágios  Cada tipo pode estar associado a um estágio específico, ou pode ser realizado a partir dos testes de componente  Tipos também estão associados com cada domínio de aplicação  No desenvolvimento de jogos são realidades testes de jogabilidade (só aplicável a jogo)  Em aplicações que usam banco de dados são realizados testes de volume de carga no banco  Alguns tipos de teste comuns  Testes de carga  Testes de configuração  Testes de compatibilidade  Testes de performance  Testes de documentação  Testes de internacionalização  Testes de usabilidade http://www.alvarofpinheiro.eti.br
  139. 139. Tipos de Teste  Testes de carga  Foco em garantir um número específico de transações no banco de dados (alto volume de dados e alto número de transações)  É aplicável a partir dos testes de componente  Testes de configuração  Verifica se o software funciona com diferentes configurações de hardware e software  Está associado aos requisitos não-funcionais / restrições do software  Usualmente é aplicável a partir dos testes de integração  Testes de compatibilidade  Verifica se um determinado software está aderente a um padrão que ele deveria implementar  Usualmente é executado durante o teste de sistema http://www.alvarofpinheiro.eti.br
  140. 140. Tipos de Teste  Testes de performance  Garantir que a velocidade de execução do sistema é adequada (tempo para carregar uma página web por exemplo)  Associado aos requisitos não funcionais  Pode ser executado a partir dos testes de integração  Testes de documentação  Garantir que a documentação do software está do acordo com o que foi realmente implementado  Tem mais sentido ser executado durante os testes de sistema  Testes de internacionalização  Garantir que o software funciona em diferentes línguas e com configurações dependentes de pais (meda, timezone, etc.)  Testes de usabilidade  Verifica se as funções do sistema realmente são “fáceis” de serem realizadas  Deve ser executado durante os testes de sistema http://www.alvarofpinheiro.eti.br
  141. 141. Testes de Regressão  Considere o seguinte cenário  Durante a execução dos testes de sistema de um software encontra-se um erro após a execução de 70% dos testes  Este erro é corrigido e uma nova versão é gerada  Que testes devem ser executados após isso?  Os 30% restantes  E também pode-se regredir e executar todos os outros testes que já foram executados  A execução dos testes que já foram rodados é chamado de Testes de Regressão  Um testes de regressão completo significa que TODOS os testes serão rodados novamente http://www.alvarofpinheiro.eti.br
  142. 142. Tipos – Testes de Carga  Associado principalmente a softwares que usam bancos de dados  É um tipo de testes  Caixa preta  Principal objetivo é verificar como o software se comporta com diferentes cargas de banco de dados  Precisa de diferentes scripts para popular o banco  Está associado aos requisitos, mas também ao modelo de dados do software  Algumas vezes a implementação assume alguns comportamentos do modelo de dados  Dados dependentes da implementação do código e vice-versa  Isso pode causar bugs na aplicação, pois os dados do banco deveria estar associados e serem dependentes apenas do modelo de dados  Esses testes podem ser automatizados, mas o ideal é que sejam manuais para identificar os comportamentos diferentes do software http://www.alvarofpinheiro.eti.br
  143. 143. Tipos – Testes de Performance  Verificar a performance da aplicação em diferentes cenários  Esta diretamente associado aos requisitos não funcionais do software  Os requisitos devem especificar a performance esperada do software  Caso isso não seja feito pode gerar frustração durante a aceitação do software  A performance também está associada ao número de usuário utilizando o software  Em sistemas Web, a performance tem que ser garantida até um número X de usuários  Existem ferramentas que ajudam a implementar scripts para validar a performance  Simular vários usuários conectados a aplicação  Estes testes também estão associados ao ambiente de deploy do software  Este ambiente influencia diretamente no resultado dos testes http://www.alvarofpinheiro.eti.br
  144. 144. Tipos – Testes de Performance: Exemplo  Considerando o caso de uso listar contas de uma pessoas  O software pode ter um requisito não funcional  Mostrar as contas de um pessoa específica em no máximo 5 segundos  Com uma base de até 10mil pessoas e 100mil contas  Com até 100 usuários logados simultaneamente  Os seguintes casos de teste podem ser identificados:  Montar uma base com este número de usuários e buscar listar as contas destes usuários repetidamente. Calcular a média de tempo para mostrar as contas http://www.alvarofpinheiro.eti.br
  145. 145. Tipos – Testes de Uso de Memória  Pode estar associado a diferentes tipos de software  Alguns sistemas embarcados tem um milite de memória para uso  Caso se passe deste limite o software não pode ser executado ou o custo do hardware vai ser elevado  O uso da memória física do hardware precisa ser acompanhado nos projetos, caso este seja um recurso crítico  Avaliar periodicamente quanta memória o software está usando  Os procedimentos de testes de sistema podem ser utilizados  Verificar quanta memória o software está usando em cada caso de uso  Testes exploratórios também podem ser utilizados para verificar o uso de memória  Estes testes precisam ser realizados em alguns sistemas desde a fase de codificação e testes unitários  O uso de memória também pode estar associado a requisitos funcionais http://www.alvarofpinheiro.eti.br
  146. 146. Tipos – Testes de Uso de Memória: Exemplo  Um sistema embarcado pode estar limitado ao uso de 4 MB de RAM  As placas com essa memória já foram encomendadas e estão na fábrica  É necessário implementar no código um controle que verifique quanto de memória RAM está sendo utilizada  Semanalmente deve se acompanhar  quando de memória usada vs. número de casos de uso implementados http://www.alvarofpinheiro.eti.br
  147. 147. Tipos – Testes de Usabilidade  Que atributos definem uma boa interface com o usuário?  Grande investimento é feito pelas empresas para responder essa pergunta  Com os atributos definidos, a UI do software pode ser definida para atingi-los  Algumas características de um boa UI  Segue um padrão determinado  Flexível  Intuitiva  Consistente  Confortável  Útil http://www.alvarofpinheiro.eti.br
  148. 148. Tipos – Testes de Usabilidade  Segue um padrão determinado  As empresas que fazem os sistemas operacionais definem padrões de UI para serem seguidos pelas aplicações  É importante identificar se estes estão ou não sendo seguidos  Flexível  Existem diferentes formas de executar a mesma função? Estas formas são claras para o usuário?  Intuitiva  A interface é “limpa”? As funções do software são obvias e fáceis de encontrar?  Consistente  Funções similares no software estão disponíveis da mesma forma?  Confortável  Mensagens de erro são mostradas no momento correto? A performance das operações é ideal?  Útil  As funções realmente estão funcionando e podem ser usadas? http://www.alvarofpinheiro.eti.br
  149. 149. Tipos – Testes de Usabilidade  Mesma mensagem de erro apresentada de forma diferente  Cada indicação passa um “mensagem” diferente para o usuário  O teste de usabilidade precisa garantir a consistência entre as “mensagens” http://www.alvarofpinheiro.eti.br
  150. 150. Tipos – Testes de Usabilidade  Um dos testes mais importantes realizados durante os testes de sistema  É um teste caixa preta que visa identificar se os casos de uso do software são “fáceis” de executar pelo usuário final  É realizado por um design de usabilidade  Foca na facilidade de uso (número de passos para executar uma função específica do software)  Identificar se as opções apresentadas para o usuário são claras de entender  Os casos de teste de usabilidade são extraídos da especificação e do modelo navegacional do software  Existem diferentes técnicas para realizar esses testes  Filmar usuários utilizado o software e avaliar o uso com psicólogos  Colocar o software em um ambiente real e deixar um observador tomando nota do uso do software  Etc. http://www.alvarofpinheiro.eti.br
  151. 151. Tipos – Testes de Usabilidade: Exemplo  Considerando o caso de uso lista contas  O usuário pode esperar que as contas de uma determinada pessoa sejam listadas  Com no máximo 1 clique  Na mesma tela que todas as pessoas  Sejam apresentadas em uma lista com rolagem  Um possível caso de teste deve verificar se essas condições são atendidas no software  Em relação ao número de cliques, pode-se filmar vários usuários diferentes para verificar se eles conseguem realizar a operação com apenas 1 clique  Algumas vezes existe a opção de fazer com 1 clique, mas isso não é claro para o usuário final http://www.alvarofpinheiro.eti.br
  152. 152. Tipos – Teste de Configuração  Atualmente existem diferentes plataformas de hardware e software nas quais um determinado software pode executar  Além disso, o software desenvolvido também possui diferentes configurações internas  Resumindo, os testes de configuração buscam  Identificar o comportamento do software em diferentes configurações de hardware  Identificar o comportamento do software em diferentes configurações de software  Identificar o comportamento do software em diferentes configurações internas do software  As possíveis plataformas de hardware e software nas quais o software deve funcionar  DEVEM ser mapeadas durante a especificação do software  DEVEM ser aprovadas pelo cliente  Partindo destas especificações os casos de teste precisam ser levantados http://www.alvarofpinheiro.eti.br
  153. 153. Tipos – Teste de Configuração  Os resultados desses testes devem ser acompanhados periodicamente  Estes testes precisam ser executados o mais cedo possível  Especialmente se alguma das restrições fora essencial (ex. o software precisa rodar com um monitor preto e branco)  O planejamento dos testes precisa  Incluir as diferentes configurações de hardware e software com ambiente para execução dos testes  Planejar em que momento estes testes devem ser realizados http://www.alvarofpinheiro.eti.br
  154. 154. Tipos – Teste de Configuração: Exemplo  O software pode ter como restrição utilizar banco de dados Oracle ou Posgresql  O caso de teste então deve  Configurar 2 ambientes de testes: 1 com cada banco de dados  Executar as funcionalidades básicas do software em ambos os ambientes  Caso alguma não funciona corretamente, o teste é falho  Em algumas situações TODOS os testes precisarão ser executados em ambos os ambientes http://www.alvarofpinheiro.eti.br
  155. 155. Tipos – Testes de Compatibilidade  Como garantir que um editor de testes realmente consegue abrir um documento do padrão MS Word?  Como garantir de controle bancário exporta suas contas corretamente para uma planilha excel?  Como garantir que um software bancário consegue se comunicar com um servidor padrão do banco central?  Estes problemas são testados através de um teste de compatibilidade http://www.alvarofpinheiro.eti.br
  156. 156. Tipos – Testes de Compatibilidade  É aplicável para software que  Implementam algum padrão específico e que precisam estar compatíveis com este  Interagem com alguma aplicação que em a sua interface padronizada  No primeiro caso, o software precisa ser valido quando ao padrão  Usualmente os organismos de padronização definem conjuntos de testes que validam as implementações  A execução destes testes precisam então ser planejadas para validar a implementação do software  No segundo caso, o software precisa  Garantir que está usando a interface padronizada corretamente (por exemplo, usar um porta USB)  Testes precisam ser especificados para as diferentes opções definidas no padrão http://www.alvarofpinheiro.eti.br
  157. 157. Tipos – Testes de Compatibilidade: Exemplo  O software de controle de contas pode ter como requisito não funcional suportar um formato binário padrão para contas  A organização que definiu o padrão binário para um arquivo de várias contas possui um conjunto de testes que valida o suporte ao formato  Um caso de teste então é  Executar o conjunto de testes no software em um caso de uso de importar contas  Para todos as diferentes entradas, o software deve se comportar corretamente http://www.alvarofpinheiro.eti.br
  158. 158. Tipos – Testes de Documentação  Diferentes documentações podem ser geradas para o software  Documentação para o usuário (help)  EULA  Garantia  Marketing  É fundamental verificar se estas documentações estão corretas e de acordo com o esperado  Requisitos podem e devem ser definidos para a documentação  Quem vai prover o texto do help? Em que língua? Se for escrito pela equipe, quem vai revisá-lo?  Quem vai fornecer o EULA? Quando ele será incluído no software  Casos de testes podem e DEVEM ser definidos para validar esses pontos  Verificar a consistência do help  Verificar de o material de marketing está consistente http://www.alvarofpinheiro.eti.br
  159. 159. Tipos – Testes de Documentação  Frequentemente os casos de teste de documentação são esquecidos  Como não é código a sua importância é minimizada  Dependências de documentação também são esquecidas  Quando o texto do EULA vai ser entregue?  Quem vai revisá-lo?  Mudanças de última hora são freqüentes  Erros encontrados de última hora também são muito freqüentes  Especialmente no help  Erros de documentação podem  Gerar processos contra a empresa que fez o software  Dá uma idéia de baixa qualidade do produto http://www.alvarofpinheiro.eti.br
  160. 160. TESTES DE SOFTWARE AUTOMAÇÃO http://www.alvarofpinheiro.eti.br
  161. 161. Testes: Automação Software que automatiza qualquer aspecto da verificação de um sistema de aplicações. É possível incluir ainda nesta definição a capacidade de gerar entradas e resultados esperados dos testes, a execução das suítes de testes sem a intervenção manual e finalmente a avaliação se o teste passou ou não. Lista de situações onde é indicativo o teste automático: Quando há uma grande quantidade de testes; Suporte a várias GUIs, redes, sistemas operacionais ou banco; Testes de performance; Quando é necessário repetir uma complexa lista de ações; e Avaliar uma grande quantidade de saída repetidamente. http://www.alvarofpinheiro.eti.br
  162. 162. Testes: Manuais Quando os testes automáticos não são indicados: Quando não se tem muito tempo; Testadores necessitam ter ideia do comportamento da aplicação; Situações que se necessita de criatividade; Em relação a diminuição dos cursos; Testar novos componentes. http://www.alvarofpinheiro.eti.br
  163. 163. Automação  Como escrever testes funcionais automáticos eficientemente  existem algumas orientações para decidir se o determinado teste de unidade que está sendo escrito é na verdade um teste funcional: 1. Se o de teste de unidade atravessa classe de fronteiras, ele pode ser um teste funcional. 2. Se o de teste de unidade ficar muito complexo, ele pode ser um teste funcional. 3. Se o de teste de unidade é frágil (ou seja, é um teste válido, mas é necessário atualizá-lo continuamente para lidar com diferentes mudanças do usuário), ele pode ser um teste funcional. 4. Se o de teste de unidade é mais difícil de escrever do que o código que deverá ser testado, ele pode ser um teste funcional.  Existe uma sintonia entre o teste unitários e os testes funcionais, e decidir onde está a linha de separação entre um e outro depende de caso a caso.  Quanto mais confortável se estiver com os testes unitários, mais claro será perceber quando um determinado teste está cruzando a linha de unidade para funcional. slide 163 de 99 http://www.alvarofpinheiro.eti.br

×