A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Teste de Software LABORATÓRIO DE TECNOLOGIA DA INFORMAÇÃO APLICADA Rafael Marchioli Bernardes

Apresentações semelhantes


Apresentação em tema: "Teste de Software LABORATÓRIO DE TECNOLOGIA DA INFORMAÇÃO APLICADA Rafael Marchioli Bernardes"— Transcrição da apresentação:

1

2 Teste de Software LABORATÓRIO DE TECNOLOGIA DA INFORMAÇÃO APLICADA Rafael Marchioli Bernardes

3 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.

4 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

5 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.

6 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-c b dffc25862d/G98-MicrosoftVisualStudioTeamSystemROICaseStudy-Dell.pdf)

7 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.

8 Custo 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.

9 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$ ,00. Resumindo: Bugs em um ano de projeto: R$ ,00 Estabelecer uma equipe de Testes e adequar metodologias: Alguns poucos mil reais Ver seu cliente feliz com o sistema sem bugs e renovando contratos: não tem preço

10 Cená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.

11 Teste de Software Conceitos

12 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.

13 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

14 Inspeções e Walkthroughs A 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.

15 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)

16 Tipos de Testes Black BoxWhite Box Functional TestingUnit Testing Stress TestingStatic & dynamic Analysis Load TestingStatement Coverage Ad-hoc TestingBranch Coverage Exploratory TestingSecurity Testing Usability TestingMutation Testing Smoke Testing Recovery Testing Volume Testing Domain Testing Scenario testing Regression Testing User Acceptance Alpha Testing Beta Testing

17 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

18 Unit Testing

19 Visual 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

20 Manual Test

21 Web Test

22 Load Test

23 Ordered Test

24 Code Craftsmanship A man who practices a craft with great skill

25 Code Craft:

26

27

28

29 Oque há em um nome: Identidade Comportamento Reconhecimento Nomeações claras são marcas registradas de um bom código

30 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

31 Code Craft:

32 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

33 Debbuging

34 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

35 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.

36 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.

37 Debugging flowchart :

38 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

39 Assert:

40 Assert:

41 Trace:

42 Debbuging com VSTS

43 Breakpoint codes:

44 Advanced Breakpoints:

45

46

47

48 Watch Window:

49 The Set Next Statement Command:

50 Alterando o Banco Durante o Debug:

51

52 PEX:

53 Extreme Programming

54 12 práticas de XP

55

56

57 Dúvidas???


Carregar ppt "Teste de Software LABORATÓRIO DE TECNOLOGIA DA INFORMAÇÃO APLICADA Rafael Marchioli Bernardes"

Apresentações semelhantes


Anúncios Google