Baixe o app para aproveitar ainda mais
Prévia do material em texto
Victor Hugo Germano Teste de Software CTAI SENAISC Aula - 02 Victor Hugo Germano http://malditacomedia.blogspot.com Retrospectiva Por que testar? Unitários Unitários Transição de Estado Unitários Integração Transição de Estado Unitários Integração Transição de Estado Análise de Valor Limite Unitários Integração Transição de Estado Testes de Caminho Análise de Valor Limite Aceitação Unitários Integração Transição de Estado Testes de Caminho Análise de Valor Limite Unitários Unitários JUnit TDD TDD Escreva um teste que falhe TDD Escreva um teste que falhe Faça o teste passar TDD Escreva um teste que falhe Faça o teste passar Refatore Bom dia! Testes de Aceitação Testes de aceitação Por quê? Testes de aceitação Por quê? Direcionar o desenvolvimento do produto Testes de aceitação Pra quê? Verificar a completude de um requisito Testes de aceitação Como? Testes de aceitação • Idealmente escritos antes do desenvolvimento • Idealmente Automatizados • Garantem que o código faz exatamente o que se propõe a fazer Como? Tempo Tempo 1 Tempo 1 2 Tempo 1 2 3 Tempo 1 2 3 4 Tempo 1 2 3 4 Tempo 1 2 3 4 Explorar Requisitos Definir Testes de Aceitação para Use Cases Tempo 1 2 3 4 Explorar Requisitos Definir Testes de Aceitação para Use Cases Tempo 1 2 3 4 Explorar Requisitos Definir Testes de Aceitação para Use Cases Testes de aceitação garantes conformidade com os requisitos Tempo 1 2 3 4 Explorar Requisitos Definir Testes de Aceitação para Use Cases Testes de aceitação garantes conformidade com os requisitos Tempo 1 2 3 4 Explorar Requisitos Definir Testes de Aceitação para Use Cases Testes de aceitação garantes conformidade com os requisitos Tempo 1 2 3 4 Explorar Requisitos Definir Testes de Aceitação para Use Cases Testes de aceitação garantes conformidade com os requisitos Tempo 1 2 3 4 Explorar Requisitos Definir Testes de Aceitação para Use Cases Testes de aceitação garantes conformidade com os requisitos Tempo 1 2 3 4 Explorar Requisitos Definir Testes de Aceitação para Use Cases Testes de aceitação garantes conformidade com os requisitos Tempo 1 2 3 4 Explorar Requisitos Definir Testes de Aceitação para Use Cases Testes de aceitação garantes conformidade com os requisitos Mãos à obra! Selenium http://seleniumhq.org/ Selenium IDE \\172.16.4.19 <html> <head> <title>My Application Test Suite</title> </head> <body> <table> <tr><td><b>Suite Of Tests</b></td></tr> <tr><td><a href="./TestLogin.html">Test Login</a></td></tr> <tr><td><a href="./TestFormEntry.html">Test Form Entry</a></td></tr> <tr><td><a href="./TestFormSave.html">Test Form Save</a></td></tr> </table> </body> </html> Test Suite Exercício V Integrar Testes numa suite de testes de aceitação Exercício V Construir testes de aceitação Na página principal, devem haver links para outros serviços do google: orkut, email, Imagens e Mapas Na pagina de Busca avançada, selecionar o idioma Ingles e buscar por “linux” deve retornar a pagina da wikipedia em inglês como primeiro item da busca Uma consulta que não apresenta resultados deve apresentar uma mensagem de indicação Quando Parar de testar? Quando Parar de testar? Custo Quando Parar de testar? Custo Prazo Quando Parar de testar? Custo Prazo Cliente Criando Test Cases Test Cases Comunicação Test Cases Comunicação Encontrar problemas antes que o cliente o faça Test Cases Comunicação Encontrar problemas antes que o cliente o faça Evitar que problemas ocorram Test Cases Comunicação Encontrar problemas antes que o cliente o faça Evitar que problemas ocorram Auxiliar na tomada de decisão Aderência aos requisitos de negócio, não de sistema Test Cases Test Cases Redução de Riscos Medir a Qualidade Encontre as prioridades do projeto! Encontre as prioridades do projeto! Um único objetivo por vez! Encontre as prioridades do projeto! Um único objetivo por vez! Está tudo claro? Pergunte! Encontre as prioridades do projeto! Um único objetivo por vez! Pare e pense! Está tudo claro? Pergunte! Test Cases Qualidades Test Cases Qualidades Fácil de ler - Não há lugar para enrolação! Test Cases Qualidades Fácil de ler - Não há lugar para enrolação! Rápido de encontrar o resultado esperado - Interpretação em poucos segundos Test Cases Qualidades Fácil de ler - Não há lugar para enrolação! Rápido de encontrar o resultado esperado - Interpretação em poucos segundos Autoexplicativos - Não necessitam da especificação completa do sistma Test Cases Qualidades Fácil de ler - Não há lugar para enrolação! Rápido de encontrar o resultado esperado - Interpretação em poucos segundos Autoexplicativos - Não necessitam da especificação completa do sistma Curtos - Elimine todos os desperdícios! - Seja imperativo "clique no botão", "vá ao item 1" - Seja direto e simples, porém não simplório - Use nomes exatos e consistentes para campos, não seja genérico - Entre 10 e 15 passos - Siga convenções de nomes - Se não existem convenções, CRIE-AS!!! Easy to Test Language • Identificador • Descricao • Prioridade • Pre-condição • Dependências • Entradas • Instruções de utilização • Resultados esperados • Resultado Atual • Pós-condições • Resultado (passou/falhou) • Número da versao Atributos Comuns Linhas Gerais Linhas Gerais Escrever testes juntamente com os requisitos Linhas Gerais Escrever testes juntamente com os requisitos Descrevem o atual requisito Linhas Gerais Escrever testes juntamente com os requisitos Descrevem o atual requisito Siga um padrão, facilite a comunicação Linhas Gerais Escrever testes juntamente com os requisitos Descrevem o atual requisito Siga um padrão, facilite a comunicação Priorize seus testes por valor de negócio Linhas Gerais Escrever testes juntamente com os requisitos Descrevem o atual requisito Siga um padrão, facilite a comunicação Priorize seus testes por valor de negócio Agrupe testes por domínio Linhas Gerais Escrever testes juntamente com os requisitos Descrevem o atual requisito Siga um padrão, facilite a comunicação Priorize seus testes por valor de negócio Agrupe testes por domínio Foque no valor! Foque no resultado! Pratique!! A prática leva à perfeição Pratique!! Priorize! Remova desperdícios! A prática leva à perfeição Pratique!! Priorize! Remova desperdícios! A prática leva à perfeição Se possível, automatize! Seja preguiçoso! http://www.consiste.dimap.ufrn.br/~andre/casouso/ Exercício VI Sistema de Vendas Construir testes de aceitação para módulo Fazer Pedido Fazer Pedido - versão 4 Atores Cliente Pré-condição: O usuário deve ter feito "log-in" e obtido autorização do sistema Pós-condição: O pedido deve ter sido gravado no sistema e marcado como confirmado. Exercício VI Applying Use Cases: A Pratical Guide", Geri Schneider & Jason Winters, Addison-Wesley, 1998. Applying Use Cases: A Pratical Guide", Geri Schneider & Jason Winters, Addison-Wesley, 1998. Fazer Pedido - versão 4 Fluxo de eventos primário: 1. O casode uso começa quando po cliente seleciona "fazer pedido". 2. O cliente fornece seu nome e endereço. 3. Se o cliente fornece apenas o CEP, o sistema coloca automaticamente o a cidade e o estado. 4. Enquanto o cliente quiser pedir itens faça 1. O cliente fornece código do produto 2. O sistema fornece as descrição e preço do produto 3. O sistema atualiza o valor total 5. O cliente fornece as informações sobre cartão de crédito. 6. O cliente submete os dados ao sistema. 7. O sistema verifica as informações fornecidas, marca o pedido como "pendente" e envia as informações de pagamento para o sistema de contabilidade e pagamento. 8. Quando o pagamento é confirmado, o pedido é marcado como "confirmado" e o número de pedido (NP) é dado ao cliente. Fluxo de eventos secundário: A qualquer momento antes de submeter, o cliente pode selecionar cancelar. O pedido não é gravado e o caso de uso termina. No passo 7, se alguma informação estiver correta, o sistema pede ao cliente para corrigir a informação. Planejamento de Testes Por que Planejar? Por que planejar? Finalidade: • Localizar e documentar defeitos na qualidade do software. • Avisar de forma geral sobre a qualidade observada no software. • Validar as suposições feitas nas especificações de design e requisito através de demonstração concreta. • Validar as funções do software conforme projetadas. • Verificar se os requisitos foram implementados de forma adequada. Com Planejar? Teste antes, teste sempre! Teste antes, teste sempre! Comunique-se! Teste antes, teste sempre! Comunique-se! Comunique-se! Teste antes, teste sempre! Comunique-se! Comunique-se! Se puder, automatize! Teste antes, teste sempre! Comunique-se! Comunique-se! Se puder, automatize! Entenda o domínio do negócio Templates Introdução Introdução Visão Geral: - Escopo, métodos, Padroes Introdução Visão Geral: - Escopo, métodos, Padroes Requisitos: - Hardware, software, Pessoal Templates Template Interação Homem-Computador • descrição, • objetivos, • métodos, • objetos a serem testados, • eventos a serem testados, • verificação dos testes, • ferramentas de teste. Template Testes Funcionais • objetivos, • métodos, • funções a serem testadas, • projeto de dados para testes, • construção dos dados de teste, • verficação do teste, • ferramentas de teste Template Testes de regressão •Objetivos • O que não funciona mais e o que continua funcionando na nova versão • Dados para teste • quais casos serão reutilizados • Execução dos testes • Ferramentas de teste Template Testes de desempenho • Objetivos • Métodos de teste • Monousuário • Multiusuário • Criação dos dados de teste • Verficação do teste • Ferramentas de teste Template Testes de aceitação • Objetivos •Cenários de negócio a serem testados • Projeto dos casos de teste • Métodos de teste • Verficação do teste • Ferramentas de teste Template Testes de Sistema • Objetivos • cenários de negócio a serem testados • Projeto dos casos de teste • Métodos de teste • Verficação do teste • Ferramentas de teste Como documentar um Bug Documentar um Bug • Seja preciso • Seja claro - explique de forma que outros possam reproduzir o erro • Um bug por relatório • Nenhum bug é simples o suficiente para não ser registrado • Separe claramente fatos de especulações • Um printscreen vale mais que mil parágrafos Documentar um Bug “Eu estava usando o sistema e então ele deu pau” Documentar um Bug “Eu estava usando o sistema e então ele deu pau” -> Abra o sistema e vá ao item "Arquivo > Novo" -> Desenhe uma Reta -> Vá até a função "Salvar Como..." e salve o arquivo -> Tente abrir o arquivo novo -> Verifique a mensagem de erro O que testar? Análise de Risco & Prioridades Analise de Risco Use Case Cenário Risco Frequência Criticidade UserCase 1 Cenário A Alto Alta Baixa UserCase 2 Cenario B Médio Baixa Alta Analise de Risco Priorização Priorização Modelo Kano Priorização Modelo Kano Priorização Pelo Valor Percebido http://en.wikipedia.org/wiki/Kano_model Modelo Kano Must-have Obrigatórios http://en.wikipedia.org/wiki/Kano_model Modelo Kano Must-have Obrigatórios http://en.wikipedia.org/wiki/Kano_model Linear Quanto mais, melhor! Modelo Kano Must-have Obrigatórios http://en.wikipedia.org/wiki/Kano_model Linear Quanto mais, melhor! Exciters Necessidades não conhecidas Modelo Kano Modelo Kano http://www.acarlos.com.br/blog/ 2 Perguntas: Modelo Kano http://www.acarlos.com.br/blog/ 2 Perguntas: Funcional O que você acha de ter uma cerveja de graça no quarto de hotel todos os dias? Modelo Kano http://www.acarlos.com.br/blog/ 2 Perguntas: Funcional O que você acha de ter uma cerveja de graça no quarto de hotel todos os dias? DysFunctional Chegar em um hotel que não tem cerveja grátis, o que você acha? Modelo Kano DysFunction Question Like Q E E E L Expect R I I I M Neutral R I I I M Live with R I I I M Dislike R R R R Q Li ke Ex pe ct N eu tr al Li ve w ith D is lik e Fu nc tio na l Q ue st io n M - Mandatory L - Linear E - Exciter Q - Questionable R - Reverse I - Indifferent Benefício Relativo Benefício Relativo http://www.acarlos.com.br/blog/ Benefício Relativo Pré-requisito: Estimativas criadas http://www.acarlos.com.br/blog/ Benefício Relativo Pré-requisito: Estimativas criadas Benefits Penalties Sum(BV) Estimation BV/Est Feature 1 1 9 10 2 5 Feature 2 Feature 3 Feature 4 Feature 5 http://www.acarlos.com.br/blog/ Benefício Relativo Pré-requisito: Estimativas criadas Benefits Penalties Sum(BV) Estimation BV/Est Feature 1 1 9 10 2 5 Feature 2 2 3 5 5 1 Feature 3 Feature 4 Feature 5 http://www.acarlos.com.br/blog/ Benefício Relativo Feature 5 Feature 1 Feature 3 Feature 4 Feature 2 Benefício Relativo Pré-requisito: Estimativas criadas Benefits Penalties Sum(BV) Estimation BV/Est Feature 1 1 9 10 2 5 Feature 2 2 3 5 5 1 Feature 3 5 1.6 13 8 8 Feature 4 6 7 13 13 1 Feature 5 5 5 10 2 5 http://www.acarlos.com.br/blog/
Compartilhar