Teste de SoftwareTeste de Software

LABORATÓRIO DE TECNOLOGIA DA LABORATÓRIO DE TECNOLOGIA DA INFORMAÇÃO APLICADAINFORMAÇÃO APLICADA

Rafael Marchioli BernardesRafael Marchioli Bernardesrafael.bernardes@ltia.fc.unesp.brrafael.bernardes@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?????