Teste de Software LABORATÓRIO DE TECNOLOGIA DA INFORMAÇÃO APLICADA Rafael Marchioli Bernardes...
Transcript of Teste de Software LABORATÓRIO DE TECNOLOGIA DA INFORMAÇÃO APLICADA Rafael Marchioli Bernardes...
Teste de SoftwareTeste de Software
LABORATÓRIO DE TECNOLOGIA DA LABORATÓRIO DE TECNOLOGIA DA INFORMAÇÃO APLICADAINFORMAÇÃO APLICADA
Rafael Marchioli BernardesRafael Marchioli [email protected]@ltia.fc.unesp.br
ContextoContexto
• 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.
ContextoContexto
• 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ânciaImportâ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 EstudoCaso 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 BugsCusto 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 BugsCusto dos Bugs• Cenário 2 : Bug encontrado durante a fase de homologação
Desta 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 BugsCusto 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árioCenário
• Cada caso é um caso, cada projeto é um projeto.
• Existem inúmeras áreas a serem exploradas no assunto.
• Ajudar cada desenvolvedor individualmente a ter uma melhor noção do todo, e colaborar com o aumento da qualidade durante o desenvolvimento.
• Aplicar a Teoria nos projetos por vir.
Teste de Software Teste de Software ConceitosConceitos
“TESTING IS THE PROCESS OF DEMONSTRATING THAT ERRORS ARE NOT
PRESENT.”
“THE PURPOSE OF TESTING IS TO SHOW THAT A PROGRAM PERFORMS ITS INTENDED
FUNCTIONS CORRECTLY.”
Atividades de testeAtividades 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 WalkthroughsInspeções e WalkthroughsA inspeção do codigo ou teste humano, envolve a leitura do codigo e costuma ajudar a identificar de 30 a 70 % dos erros. Na inspeção é importante que entre os 3 ou 4 envolvidos apenas um seja o desenvolvedor original, ja que normalmente o desenvolvedor faz inspeções tendenciosas. Durante a revisão as seguintes tarefas ocorrem:
1. O programador narra linha por linha a lógica do programa, enquanto os outro participantes fazem perguntas, quem acha a maioria dos erros costuma ser o próprio programador, ou seja a simples leitura em voz alta para uma platéia é extremamente eficaz na busca por erros.
2.O Programa é analizado com relação a seguinte lista 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/tamanhos diferentes)– 4-Comparison Errors (Operadores corretos, 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ão muito parecidos com inspeções porem nele realizamos test cases como se fossem testes de mesa.
Test CasesTest 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)
Tipos de TestesTipos de TestesBlack Box White Box
Functional Testing Unit Testing
Stress Testing Static & dynamic Analysis
Load Testing Statement Coverage
Ad-hoc Testing Branch Coverage
Exploratory Testing Security Testing
Usability Testing Mutation Testing
Smoke Testing
Recovery Testing
Volume Testing
Domain Testing
Scenario testing
Regression Testing
User Acceptance
Alpha Testing
Beta Testing
Unit TestingUnit 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
Unit TestingUnit Testing
Visual Studio Team SystemVisual Studio Team System
• Possui diversos recursos que visam ajudar/automatizar o trabalho dos Testers
• Suporta os seguintes tipos de testes:– Unit Tests– Web Tests– Load Tests– Generic Tests– Manual Tests– Ordered Tests
Manual TestManual Test
Web TestWeb Test
Load TestLoad Test
Ordered TestOrdered Test
Code CraftsmanshipCode CraftsmanshipA man who practices a craft with great skill
Code Craft:Code Craft:
Code Craft:Code Craft:
Code Craft:Code Craft:
Code Craft:Code Craft:
Oque há em um nome:Oque há em um nome:• Identidade• Comportamento • Reconhecimento• Nomeações claras são marcas registradas de
um bom código
Como deve ser um nome: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:Code Craft:
Code Craft: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
DebbugingDebbuging
Formas de Debugging:Formas de Debugging:
• Brute Force– Usa prints de variáveis e outras infos afim de
delinear o modo como o programa é executado• Cause Elimination– Usa dedução atraves da info obtida através do
erro para encontrar a causa do mesmo• Backtracking– Voltando os passos que antecederam o erro
chega-se ao problema
Formas de Debugging:Formas de Debugging:
• Indução– A partir de pistas parte-se para o todo procurando
ligações• Dedução– Parte-se de uma premissa ou teoria geral e por
eliminação chega-se ao problema• Testando– Usa-se testes ou casos de testes para encontrar
mais info ou o prob em si.
Debugging best practices: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.
Debugging flowchart :Debugging flowchart :
Assertions e Tracing:Assertions e Tracing:
• Assert– É uma declaração de que determinada condição deve
ser verdadeira em determinada parte do código– Só é executada em Debug Mode
• Trace– Muito parecido com o metodo printf, te dá mais info
sobre o problema
• Comentários– Sem comentários
Assert:Assert:
Assert:Assert:
Trace:Trace:
Debbuging com VSTSDebbuging com VSTS
Breakpoint codes:Breakpoint codes:
Advanced Breakpoints:Advanced Breakpoints:
Advanced Breakpoints:Advanced Breakpoints:
Advanced Breakpoints:Advanced Breakpoints:
Advanced Breakpoints:Advanced Breakpoints:
Watch Window:Watch Window:
The Set Next Statement CommandThe Set Next Statement Command::
Alterando o Banco Durante o Debug:Alterando o Banco Durante o Debug:
Alterando o Banco Durante o Debug:Alterando o Banco Durante o Debug:
PEX:PEX:
Extreme ProgrammingExtreme Programming
12 práticas de XP12 práticas de XP
12 práticas de XP12 práticas de XP
12 práticas de XP12 práticas de XP
Dúvidas?Dúvidas?????