Download
1 / 57
570 likes | 709 Views
Teste de Software. LABORATÓRIO DE TECNOLOGIA DA INFORMAÇÃO APLICADA. Rafael Marchioli Bernardes rafael.bernardes@ltia.fc.unesp.br. Contexto.
E N D
Teste de Software LABORATÓRIO DE TECNOLOGIA DA INFORMAÇÃO APLICADA Rafael Marchioli Bernardes rafael.bernardes@ltia.fc.unesp.br
Contexto • Em 1983 quase teve inicio a III Guerra Mundial, o software de alerta a ataque Soviético indicou um ataque americano, que só não levou a guerra porque o Tenente Coronel Stanislav Petrov considerou o alarme falso e impediu o contra-ataque.
Contexto • Em 1998 um erro de navegação na nave Polar Mars Lander fez com que a mesma se aproximasse demais do solo e se destruisse, tudo devido a problemas com a conversão de padrões de medidas americas e européais. • O Bug do Milênio custou Milhões
Importância • mais de 30% dos projetos são cancelados antes de serem finalizados. • mais de 70% dos projetos falham nas entregas das funcionalidades esperadas. • os custos extrapolam em mais de 180% os valores originalmente previstos. • os prazos excedem em mais de 200% os cronogramas originais.
Caso de Estudo • A DELL conseguiu um ROI de “apenas” 225% em “apenas” 6 meses de implantação do Team System . (http://download.microsoft.com/download/3/3/8/3382e892-c592-4185-b011-27dffc25862d/G98-MicrosoftVisualStudioTeamSystemROICaseStudy-Dell.pdf)
Custo dos Bugs • Cenário 1 : Bug encontrado durante o desenvolvimento Este cenário é o ideal. O desenvolvedor escreve o código, cria os testes unitários, verifica que alguns métodos estão com erros, os corrige e pronto. Desde que ele termine dentro do prazo, o seu custo adicional é zero.
Custo dos Bugs • Cenário 2 : Bug encontrado durante a fase de homologaçãoDesta vez o desenvolvedor também foi cuidadoso, no entanto, ele não testou uma integração do código que ele acabou de desenvolver com outro código já existente. Isso vai gerar erro de integração. O testador vai identificar o erro, registrá-lo, colocar os passos para reprodução e outras informações necessárias, esse bug será triado por um team leader, que encaminhará para um programador que precisará entender o que é esse bug, tentará reproduzi-lo para depois corrigir e só então gerar uma nova build para ser publicada. Ah, o testador terá que verificar se o bug foi realmente corrigido.Bom, estimando isso em horas, podemos colocar 2 horas para o testador, mais 3 horas do desenvolvedor e do team leader. Se assumirmos uma valor médio de R$ 40,00 por hora, já temos um prejuízo de R$ 200,00 com apenas um bug.
Custo dos Bugs • Cenário 3 : Bug encontrado em produção Dessa vez vamos falar do pior cenário, o cliente achou o bug. Primeiro que você vai ouvir um monte de abobrinha do cliente, e com razão. Você vai ter que dar um suporte telefônico pra ele, tentar entender o que ele está dizendo, dificilmente você terá um cenário igual ao dele, você perderá tempo montando o cenário, depois que conseguir reproduzir o bug irá registrá-lo, o programador terá que entender, corrigir, gerar uma build, ir pra teste, publicar no cliente, testar novamente. Ufa!!! Nessa brincadeira, você perdeu tempo do gerente do projeto, analista de negócio, team leader, programador, testador e do implantador.Assumindo duas horas pra cada recurso, que ainda é pouco, e um valor médio, dessa vez ,de R$ 50,00 por hora.A brincadeira ficou R$ 600,00. Bugzinho caro né?Vamos fazer uma continha simples agora. 15 bugs por mês no cenário 2, mais 2 bugs do cenário 3 e no final de um ano temos um gasto com bugs em apenas um projeto de R$ 50.400,00.Resumindo:Bugs em um ano de projeto: R$ 50.400,00Estabelecer uma equipe de Testes e adequar metodologias: Alguns poucos mil reaisVer seu cliente feliz com o sistema sem bugs e renovando contratos: não tem preço
Cenário • Cada caso é um caso, cada projeto é um projeto. • Existem inúmeras áreas a serem exploradas no assunto. • Ajudarcadadesenvolvedorindividualmente a terumamelhornoção do todo, e colaborar com o aumentodaqualidadedurante o desenvolvimento. • Aplicar a Teorianosprojetosporvir.
“Testing is the process of demonstrating that errors are notpresent.”“The purpose of testing is to show that a program performs its intended functions correctly.”
Atividades de teste Definir objetivo a ser testado e seus respectivos test cases levando em consideração: • Entrada correta de Dados • Calcular os resultados devidos • Armazenar os resultados da execução • Analisar os resultados
Inspeções e Walkthroughs A inspeção do codigooutestehumano, envolve a leitura do codigo e costumaajudar a identificar de 30a 70 % dos erros. Na inspeção é importanteque entre os 3 ou 4 envolvidosapenas um seja o desenvolvedor original, jaquenormalmente o desenvolvedorfazinspeçõestendenciosas. Durante a revisão as seguintestarefasocorrem: 1. O programadornarralinhaporlinha a lógica do programa, enquantoosoutroparticipantesfazemperguntas, quemacha a maioria dos erroscostuma ser o próprioprogramador, ouseja a simples leituraemvozaltaparaumaplatéia é extremamenteeficaznabuscaporerros. 2.O Programa é analizado com relação a seguintelista de inspeção: • 1-Data Reference errors (inicialização, ponteiros, arrays) • 2-Data declaration errors (Tipos, inicializações) • 3-Computation Errors (Operações entre tipos/tamanhosdiferentes) • 4-Comparison Errors (Operadorescorretos, tipos de dados) • 5-Control-Flow Errors (Loop, desvios) • 6-Interface Errors (Parametros , qtdes e tipos) • 7-Input/Output Errors (Open e Close) Walkthroughs sãomuitoparecidos com inspeçõesporemnelerealizamos test cases como se fossem testes de mesa.
Test Cases Oque levar em consideração ao escrever test cases: -Especificação de requerimentos e funcionalidades -Código Fonte -Domínios de Entrada e Saída -Casos de Uso -Fault model (previsão de erros)
Unit Testing • Executar cada linha de código • Executar/Avaliar cada expressão e condição lógica • Garantir que cada unidade realize aquilo que propõe e que não possua erros
Visual Studio Team System • Possuidiversosrecursosquevisamajudar/automatizar o trabalho dos Testers • Suportaosseguintestipos de testes: • Unit Tests • Web Tests • Load Tests • Generic Tests • Manual Tests • Ordered Tests
Code Craftsmanship A man who practices a craft with great skill
Oqueháem um nome: • Identidade • Comportamento • Reconhecimento • Nomeações claras são marcas registradas de um bom código
Como deve ser um nome: • Descritivo • Tecnicamente correto • Tamanho e tons corretos • Variaveis->Substantivos • Funções->Verbos que descrevam a função logica • Classes->Substantivos com a primeira maiuscula • Macros->TUDO MAIUSCULO
Code Craft: • Nunca sacrifique clareza, organização e ou padronização em nome do desempenho. • Estabeleça padrões de forma que no final de um projeto não se possa identificar pelo código quem escreveu oq • Use os nomes a seu favor e não contra vc, a mente humana guarda no maximo 7 nomes por vez em uma linha de pensamento, aproveite o espaço com algo que seja auto-descritivo
Formas de Debugging: • Brute Force • Usa prints de variáveis e outrasinfosafim de delinear o modocomo o programa é executado • Cause Elimination • Usadeduçãoatravesda info obtidaatravés do erroparaencontrar a causa do mesmo • Backtracking • Voltandoospassosqueantecederam o errochega-se aoproblema
Formas de Debugging: • Indução • A partir de pistas parte-se para o todoprocurandoligações • Dedução • Parte-se de umapremissaouteoriageral e poreliminaçãochega-se aoproblema • Testando • Usa-se testes oucasos de testes paraencontrarmais info ou o probemsi.
Debugging best practices: • Pense • Caiu em um impasse? “Sleep on it” • Continua em um impasse? Descreva o problema a outra pessoa. • Use ferramentas apenas como segunda opção • Evite fazer experiencias, esse é o seu ultimo recurso.
Assertions e Tracing: • Assert • É umadeclaração de quedeterminadacondiçãodeve ser verdadeiraemdeterminada parte do código • Só é executadaem Debug Mode • Trace • Muitoparecido com o metodoprintf, tedámais info sobre o problema • Comentários • Semcomentários
