Capítulo 8 Teste de Software 1

Transcrição

1 Capítulo 8 - Teste de Software Capítulo 8 Teste de Software 1

2 Assuntos abordados Testes de desenvolvimento Desenvolvimento orientado a testes Testes de liberação Testes com utilizadores Capítulo 8 Teste de Software 2

3 Teste O teste tem a intenção de mostrar que um programa faz o que se pretende fazer e de descobrir defeitos do programa antes de ser colocado em uso. Quando se testa um software, executa-se um programa usando dados artificiais. Verifica-se os resultados do teste para erros, anomalias ou informações sobre os atributos não-funcionais do programa. Pode revelar a presença de erros não a sua ausência. O teste é parte de um processo de verificação e validação mais geral, que também inclui técnicas de validação estáticos. Capítulo 8 Teste de Software 3

4 Objetivos do teste Para demonstrar que o software atende os seus requisitos. Para software personalizado, isto significa que deve haver pelo menos um teste para cada requisito no documento de requisitos. Para produtos de software genéricos, isso significa que não deve haver testes para todos os recursos do sistema, além de combinações desses recursos, que serão incorporadas no lançamento do produto. Para descobrir situações em que o comportamento do software seja incorreto, indesejável ou não esteja em conformidade com a sua especificação. testes de defeito está preocupado com extrair o comportamento do sistema indesejável, tais como falhas no sistema, as interacções indesejadas com outros sistemas, cálculos incorrectos e corrupção de dados. Capítulo 8 Teste de Software 4

5 O teste de validação e defeito A primeira meta leva a testes de validação Espera-se que o sistema execute corretamente, usando um determinado conjunto de casos de teste que refletem o uso esperado do sistema. O segundo objetivo leva ao teste de defeito Os casos de teste são projetados para expor defeitos. Os casos de teste em teste de defeito não precisam refletir como o sistema é usado normalmente. Capítulo 8 Teste de Software 5

6 Objetivo do processo de teste Testes de validação Para demonstrar que o software atende aos seus requisitos Um teste bem sucedido mostra que o sistema funciona como pretendido. Teste de defeito Para descobrir falhas ou defeitos no software, onde o seu comportamento está incorreto ou não está em conformidade com a sua especificação Um teste bem sucedido é um teste que faz com que o sistema funcione de forma incorreta e assim expõe um defeito no sistema. Capítulo 8 Teste de Software 6

7 A modelo de teste de programa de entrada-saída Capítulo 8 Teste de Software 7

8 Verificação vs validação Verificação: Está-se a desenvolver o produto correto. O software deve estar de acordo com sua especificação. Validação: "Está-se a desenvolver corretamente o produto. O software deve fazer o que o utilizador realmente precisa. Capítulo 8 Teste de Software 8

9 V & V Objetivo da V & V é estabelecer a confiança de que o sistema está 'apto para o efeito'. Depende do propósito, as expectativas do utilizador e o mercado ambiente do sistema Propósito do programa O nível de confiança depende do grau de importância do software para a organização. Expectativas do utilizador Os utilizadores podem ter baixas expectativas de certos tipos de software. Ambiente do mercado Conseguir um produto para o mercado, no início, pode ser mais importante do que encontrar defeitos no software. Capítulo 8 Teste de Software 9

10 Inspecções e testes A inspeção preocupa-se com a análise estática do sistema, para descobrir problemas (verificação estática). O teste preocupa-se com o comportamento do programa quando está em execução (verificação dinâmica). O sistema é executado com dados de teste e é observado o seu comportamento operacional. Capítulo 8 Teste de Software 10

11 Inspeções e testes Capítulo 8 Teste de Software 11

12 Inspeções de software Envolvem as pessoas que examinaram a representação de origem, com o objetivo de descobrir anomalias e defeitos. Inspeções não exigem a execução de um sistema antes da implementação. Podem ser aplicados a qualquer representação do sistema (requisitos, dados de configuração, os dados de ensaio, etc.). São uma técnica eficaz para descobrir erros de programa. Capítulo 8 Teste de Software 12

13 Vantagens de inspeções Durante os testes, os erros podem mascarar (ocultar) outros erros. Como a inspeção é um processo estático, não existe a preocupação com as interações entre erros. Versões incompletas de um sistema podem ser inspecionadas, sem custos adicionais. Bem como a procura de defeitos do programa, uma inspeção pode também considerar atributos de qualidade mais amplas de um programa, como a conformidade com os padrões, portabilidade e facilidade de manutenção. Capítulo 8 Teste de Software 13

14 Inspecções e testes Inspeções e testes são técnicas de verificação complementares e não opostas. Ambos devem ser usadas durante o processo de V & V. As inspeções podem verificar a conformidade com uma especificação, mas não verificam a conformidade com os requisitos reais do cliente. Inspeções não podem verificar características nãofuncionais, como desempenho, usabilidade, etc. Capítulo 8 Teste de Software 14

15 Modelo do processo de teste de software Capítulo 8 Teste de Software 15

16 Fases de testes Testes de desenvolvimento, onde o sistema é testado durante o desenvolvimento para descobrir erros e defeitos. Testes de release, onde uma equipa de teste, testa uma versão completa do sistema antes de ser implantado no cliente. Testes de utilizador, onde os utilizadores ou potenciais utilizadores de um sistema testam o sistema no seu próprio ambiente. Capítulo 8 Teste de Software 16

17 Testes de desenvolvimento Capítulo 8 Teste de Software 17

18 Testes de desenvolvimento Testes de desenvolvimento, incluem todas as atividades de testes que são realizados pela equipa de desenvolvimento do sistema. Teste de unidade, onde são testados unidades individuais do programa ou classes de objectos. O teste de unidade deve-se concentrar em testar a funcionalidade de objetos ou métodos. Teste de componentes, em que várias unidades individuais são integradas para criar componentes compostos. o teste de componentes deve-se concentrar em testar interfaces de componentes. Teste do sistema, onde alguns ou todos os componentes de um sistema estão integrados e o sistema é testado como um todo. O teste do sistema deve se concentrar em testar interações de componentes. Capítulo 8 Teste de Software 18

19 O teste de unidade O teste de unidade é o processo de testar componentes individuais isoladamente. É um processo de teste de defeito. As unidades podem ser: As funções individuais ou métodos dentro de um objeto Classes de objetos com vários atributos e métodos Componentes compostos com interfaces definidas, utilizadas para aceder à funcionalidade. Capítulo 8 Teste de Software 19

20 Testes de classe de objeto Cobertura de teste completo de uma classe envolve Testar todas as operações associadas a um objeto Definir e interrogar todos os objetos atributos Exercitando o objeto em todos os estados possíveis. Capítulo 8 Teste de Software 20

21 Interface da estação de metereologia objecto Capítulo 8 Teste de Software 21

22 Testes da estação meteorológica Necessidade de definir casos de teste para reportweather, Calibre, teste, inicialização e encerramento. Usa-se um modelo de estado, para identificar sequências de transições de estado a ser testados e as sequências de eventos para causar estas transições Por exemplo: Desligar -> Executar-> Desligar Configurar-> Executar-> Testar -> Transmitir -> Executar Executar-> Recolher Dados-> Executar -> Resumir -> Transmitir -> Executar Capítulo 8 Teste de Software 22

23 Testes automatizados Sempre que possível, o teste de unidade deve ser automatizado para que os testes sejam executados e verificados sem intervenção manual. Em testes de unidade automatizado, faz-se uso de um quadro de automação de teste (tal como JUnit) para escrever e executar os testes do programa. Frameworks de Testes Unidade, fornecem classes de teste genéricos que se estendem para criar casos de teste específicos. Eles podem, em seguida, executar todos os testes que são implementados e criar os respetivos relatório. Capítulo 8 Teste de Software 23

24 Componentes de testes automatizados Uma parte da configuração, onde se inicializa o sistema com o caso de teste, ou seja, as entradas e saídas esperadas. A parte da chamada, onde se chama o objeto ou método a ser testado. Uma parte da afirmação, onde se compara o resultado da chamada com o resultado esperado. Se a afirmação for avaliada como verdadeira, o teste foi bem sucedido se for falso, então ele falhou. Capítulo 8 Teste de Software 24

25 Escolher casos de teste de unidade Os casos de teste deve mostrar que, quando usado como esperado, o componente que se está a testar faz o que é suposto fazer. Se houver defeitos no componente, estes devem ser revelados pelos casos de teste. Isto leva a 2 tipos de casos de teste de unidade: A primeira delas deve refletir o funcionamento normal de um programa e deve mostrar que o componente funciona como esperado. O outro tipo de caso de teste deve ser baseado na experiência em testes de onde surgem os problemas comuns. Deve usar entradas anormais para verificar que estas sejam devidamente processados e não falha do componente. Capítulo 8 Teste de Software 25

26 Estratégias de teste Testes de partição, onde se identifica grupos de entradas que têm características comuns e devem ser processados da mesma maneira. Deve-se escolher os testes dentro de cada um desses grupos. Base dos teste, onde se usam diretrizes de teste para escolher casos de teste, baseados nessas diretrizes. Essas diretrizes refletem a experiência prévia dos tipos de erros que os programadores muitas vezes fazem ao desenvolver componentes. Capítulo 8 Teste de Software 26

27 Testes de partição Os dados de entrada e resultados de saída, muitas vezes caem em classes diferentes, onde todos os membros de uma classe estão relacionados. Cada uma dessas classes é uma partição de equivalência ou domínio em que o programa se comporta de uma forma equivalente para cada membro da classe. Os casos de teste devem ser escolhidos de cada partição. Capítulo 8 Teste de Software 27

28 Equivalência particionamento Capítulo 8 Teste de Software 28

29 Equivalência partições Capítulo 8 Teste de Software 29

30 Diretrizes gerais de testes Escolher entradas que forçam o sistema a gerar todas as mensagens de erro Repetir a mesma entrada várias vezes Forçar saídas inválidas Capítulo 8 Teste de Software 31

31 Testes de componentes Componentes de software são muitas vezes componentes compostos por vários objetos que interagem entre si. Por exemplo, no sistema de estação de meteorologia, o componente de reconfiguração inclui objetos que lidam com cada aspeto da reconfiguração. Acessa-se a funcionalidade desses objetos através da interface do componente definido. Componentes compostos de teste devem, portanto, concentrar-se em mostrar que a interface componente se comporta de acordo com a sua especificação. Capítulo 8 Teste de Software 32

32 Teste de interface Objetivos são detetar falhas devido a erros de interface ou suposições inválidas sobre interfaces. Tipos de interface Parâmetro - Os dados transmitido de um método ou processo para outro. Memória partilhada - Bloco de memória é partilhado entre os procedimentos ou funções. Procedimentos - Subsistema encapsula um conjunto de procedimentos para ser chamado por outros subsistemas. Passagem de mensagens - Solicitar serviços de outros subsistemas Capítulo 8 Teste de Software 33

33 Erros de interface Uso indevido de interface Incompreensão da interface Erros de temporização Capítulo 8 Teste de Software 35

34 Diretrizes de teste de interface Testes de design, para que os parâmetros para a chamada de um procedimento estão nos extremos das suas escalas. Testar sempre ps parâmetros de ponteiro com ponteiros nulos. Testes de design que fazem com que o componente falhe. Use testes de stresse em sistemas de passagem de mensagens. Em sistemas de memória partilhada, variar a ordem em que os componentes são ativados. Capítulo 8 Teste de Software 36

35 Teste do sistema Teste do sistema durante o desenvolvimento envolve a integração de componentes para criar uma versão do sistema e, em seguida, testar o sistema integrado. O foco do teste do sistema é testar as interações entre os componentes. Verificações de teste do sistema que os componentes são compatíveis, interagir corretamente e transferir os dados certos no momento certo através das interfaces. Teste do sistema testa o comportamento emergente do sistema. Capítulo 8 Teste de Software 37

36 Teste do sistema e componente Durante os testes do sistema, componentes reutilizáveis que foram desenvolvidos separadamente podem ser integrados com componentes recémdesenvolvidos. O sistema completo é então testado. Componentes desenvolvidos por diferentes membros da equipa ou sub-equipas podem ser integrados nesta fase. Teste de sistema é colectivo em vez de um processo individual. Em algumas empresas, o teste do sistema pode envolver uma equipa de teste sem envolvimento de designers e programadores. Capítulo 8 Teste de Software 38

37 Teste de caso de uso Os casos de uso desenvolvidos para identificar interações do sistema pode ser usado como uma base para testes do sistema. Cada caso de uso geralmente envolve vários componentes do sistema, assim o teste do caso de uso, força as interações entre componentes. Os diagramas de sequência associados com os casos de uso, documenta os componentes e interações que estão a ser testados. Capítulo 8 Teste de Software 39

38 Políticas de teste É impossivel existir todas as politicas de testes, de modo que os teste que definem a cobertura de teste de sistema exigido podem ser desenvolvidos. Exemplos de políticas de teste: Todas as funções do sistema que são acedidas através de menus devem ser testadas. Combinações de funções (por exemplo, formatação de texto) que são acedidas através do mesmo menu devem ser testadas. Se for fornecido login ao utilizador, todas as funções devem ser testadas com a entradas corretas e incorretas. Capítulo 8 Teste de Software 42

39 Desenvolvimento orientado a testes Capítulo 8 Teste de Software 43

40 Desenvolvimento orientado a testes Test-driven development (TDD) é uma abordagem ao desenvolvimento em que são efetuados teste na fase de desenvolvimento. Testes são escritos antes do código e 'passar' os testes é o driver crítico do desenvolvimento. Desenvolve-se código de forma incremental, juntamente com um teste para esse incremento. Não passar para o próximo incremento até que o código que se desenvolveu passe no respetivo teste. TDD foi introduzido como parte de métodos ágeis como Extreme Programming. No entanto, também pode ser usado em processos de desenvolvimento orientada para o plano. Capítulo 8 Teste de Software 44

41 TDD Capítulo 8 Teste de Software 45

42 Atividades do processo de TDD Identificar o incremento da funcionalidade que é necessário. Isto deve normalmente ser pequeno e implementável em algumas linhas de código. Escrever um teste para esta funcionalidade e implementar estes como um teste automatizado. Executar o teste, juntamente com todos os outros testes que têm sido implementados. Inicialmente, não se implementa a funcionalidade de modo que o novo teste falhe. Implementar a funcionalidade e voltar a executar o teste. Uma vez que todos os testes são executados com êxito, implementa-se o próximo incremento da funcionalidade. Capítulo 8 Teste de Software 46

43 Benefícios do desenvolvimento orientado a testes Cobertura do código Cada segmento de código que se escreve tem pelo menos um teste associado de modo que todo o código escrito tem pelo menos um teste. Testes de regressão Um conjunto de testes de regressão é desenvolvido de forma incremental como um programa é desenvolvido. Depuração simplificada Quando um teste falha, ele deve ser óbvio onde reside o problema. O código recém-escrito precisa ser verificado e modificado. Documentação do sistema Os próprios testes são uma forma de documentação que descreve o que o código deve fazer. Capítulo 8 Teste de Software 47

44 Testes de regressão Testes de regressão testa o sistema para verificar que as mudanças não têm 'quebrado' código previamente feito. Num processo de testes manuais, testes de regressão são caros, mas, com testes automatizados, é simples e direto. Todos os testes são executados novamente toda vez que uma alteração no programa é feita. Os testes devem correr 'com sucesso' antes da mudança estar comprometida. Capítulo 8 Teste de Software 48

45 Release testing Capítulo 8 Teste de Software 49

46 Release testing Testes de release é o processo de testar uma versão particular de um sistema que se destina para uso fora da equipe de desenvolvimento. O objetivo principal do processo de teste de release é convencer o fornecedor do sistema que é bom o suficiente para uso. testes de release têm que mostrar que o sistema oferece a sua funcionalidade, tem bom desempenho e confiabilidade, e que não falha durante o uso normal. Testes de release são geralmente um processo de teste da caixa preta, onde apenas os testes são derivados a partir da especificação do sistema. Capítulo 8 Teste de Software 50

47 Testes de release e testes de sistema Testes de release são uma forma de teste de sistema. Diferenças importantes: Uma equipa separada que não foi envolvida no desenvolvimento do sistema, deve ser responsável por testes de release. Teste do sistema pela equipa de desenvolvimento, deve se concentrar em descobrir erros no sistema (testes de defeito). O objetivo do teste de release é para verificar se o sistema atende os seus requisitos e é bom o suficiente para uso externo (teste de validação). Capítulo 8 Teste de Software 51

48 Testes baseados em requisitos Testes baseados em requisitos, examina cada requisito e desenvolvimento de um teste ou testes para esse requisito. Requisitos do sistema Mentcare: Se um paciente é conhecido por ser alérgico a qualquer medicamento, então a prescrição da medicação deve resultar numa mensagem de aviso a ser emitida para o utilizador do sistema. Se um médico opta por ignorar um aviso de alergia, eles devem fornecer uma razão para que isso foi ignorado. Capítulo 8 Teste de Software 52

49 Teste de performance Parte dos ensaios de release pode envolver testes às propriedades emergentes de um sistema, tais como o desempenho e fiabilidade. Os testes devem refletir o perfil de uso do sistema. Os testes de desempenho geralmente envolvem o planeamento de uma série de testes onde a carga está em constante aumento até que o desempenho do sistema se torne inaceitável. Os testes de stress é uma forma de testes de desempenho em que o sistema é sobrecarregado deliberadamente para testar a sua falha no comportamento. Capítulo 8 Teste de Software 56

50 Testes com utilizadores Capítulo 8 Teste de Software 57

51 Testes com utilizadores Utilizador ou testes de cliente é uma etapa no processo de teste no qual os utilizadores ou clientes fornecem informações e conselhos sobre o teste do sistema. Testes com utilizadores é essencial, mesmo quando o sistema é abrangente e os testes de release foram realizados. A razão para isto é que influências do ambiente de trabalho do utilizador têm um efeito importante sobre a confiabilidade, desempenho, usabilidade e robustez de um sistema. Estes não podem ser replicados num ambiente de teste. Capítulo 8 Teste de Software 58

52 Tipos de testes com utilizadores Teste Alpha Os utilizadores do software trabalham com a equipe de desenvolvimento para testar o software no site do desenvolvedor. Teste beta A versão do software é disponibilizada para os utilizadorss, que lhes permitam experimentar e levantar problemas que eles descobrem com os programadores do sistema. Teste de aceitação Clientes testam o sistema para decidir se está ou não está pronto para ser aceite pelos programadores do sistema e implantado no ambiente do cliente. Principalmente para sistemas personalizados. Capítulo 8 Teste de Software 59

53 O processo de teste de aceitação Capítulo 8 Teste de Software 60

54 Fases do processo de teste de aceitação Definir critérios de aceitação Plano do teste de aceitação Derivar os testes de aceitação Executar os testes de aceitação Negociar os resultados dos testes Aceitar ou Rejeitar o sistema Capítulo 8 Teste de Software 61

55 Métodos ágeis e testes de aceitação Em métodos ágeis, o utilizador / cliente faz parte da equipa de desenvolvimento e é responsável pela tomada de decisões sobre a aceitabilidade do sistema. Os testes são definidos pelo utilizador / cliente e estão integrados com outros testes na medida em que são executados automaticamente quando são feitas alterações. Não há nenhum processo de teste de aceitação separado. Capítulo 8 Teste de Software 62

56 Pontos chave Teste só pode mostrar a presença de erros num programa. Ele não pode demonstrar que não existem falhas remanescentes. Testes de desenvolvimento são da responsabilidade da equipa de desenvolvimento de software. Uma outra equipa deve ser responsável por testar um sistema antes de ser entregue aos clientes. Ao testar o software, deve-se tentar 'quebrar' o software usando experiência e diretrizes para escolher os tipos de caso de teste que têm sido eficazes na descoberta de defeitos noutros sistemas. Capítulo 8 Teste de Software 63

57 Pontos chave Sempre que possível, deve-se escrever testes automatizados. Os testes estão embutidos num programa que pode ser executado a cada vez que uma alteração é feita para um sistema. Testar o desenvolvimento anterior é uma abordagem para o desenvolvimento em que os testes são escritos antes de o código ser testado. O teste de aceitação é um processo de teste de utilizador onde o objectivo é decidir se o software é bom o suficiente para ser implantado e utilizado no seu ambiente operacional. Capítulo 8 Teste de Software 64