LABORATÓRIO DE TECNOLOGIA DA INFORMAÇÃO APLICADA

Apresentação em tema: "LABORATÓRIO DE TECNOLOGIA DA INFORMAÇÃO APLICADA"— Transcrição da apresentação:

1

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

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

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
“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 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 Static & dynamic Analysis
Tipos de Testes Black 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 In this type of testing, the software is tested for the functional requirements. The tests are written in order to check if the application behaves as expected The application is tested against heavy load such as complex numerical values, large number of inputs, large number of queries etc. which checks for the stress/load the applications can withstand The application is tested against heavy loads or inputs such as testing of websites in order to find out at what point the web-site/application fails or at what point its performance degrades It is the least formal method of testing. One of the best uses of ad hoc testing is for discovery. Reading the requirements or specifications (if they exist) rarely gives you a good sense of how a program actually behaves. A test of new or repaired equipment by turning it on. If it smokes... guess what... it doesn't work! The term also refers to testing the basic functions of software. Recovery testing is basically done in order to check how fast and better theapplication can recover against any type of crash or hardware failure etc Volume testing is done against the efficiency of the application. Huge amount of data is processed through the application (which is being tested) in order to check the extreme limitations of the system The basic notion is that you take the huge space of possible tests of an individual variable and subdivide it into subsets that are (in some way) equivalent. Then you test a representative from each subset. They provide meaningful combinations of functions and variables rather than the more artificial combinations you get with domain testing or combinatorial test design. Static analysis involves going through the code in order to find out any possible defect in the code. Dynamic analysis involves executing the code and analyzing the output. Security Testing is carried out in order to find out how well the system can protect itself from unauthorized access, hacking – cracking, any code damage etc. which deals with the code of application. This type of testing needs sophisticated testing techniques. A kind of testing in which, the application is tested for the code that was modified after fixing a particular bug/defect

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 Code Craft:

27 Code Craft:

28 Code Craft:

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

33 Debbuging

34 Formas de Debugging: Brute Force Cause Elimination Backtracking
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 Dedução Testando
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 Trace Comentários
É 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 Advanced Breakpoints:

46 Advanced Breakpoints:

47 Advanced Breakpoints:

48 Watch Window:

49 The Set Next Statement Command:

50 Alterando o Banco Durante o Debug:

51 Alterando o Banco Durante o Debug:

52 PEX:

53 Extreme Programming

54 12 práticas de XP

55 12 práticas de XP Refatoração (do inglês Refactoring) é o processo de modificar um sistema de software para melhorar a estrutura interna do código sem alterar seu comportamento externo.

56 12 práticas de XP

57 Dúvidas???