Teste de Software. Competência: Entender as técnicas e estratégias de testes de Software

Transcrição

1 Teste de Software Competência: Entender as técnicas e estratégias de testes de Software

2 Conteúdo Programático Introdução O que é teste de software? Por que é necessário testar um software? Qual a causa dos problemas? O que pode ser testado? Custo da Correção dos Defeitos. Verificação x Validação. Estratégias de Teste.

3 O que é teste de software? Processo de executar o software de uma maneira controlada com o objetivo de avaliar se o mesmo se comporta conforme o especificado; Processo utilizado para revelar defeitos em software, e estabelecer que o mesmo atingiu um determinado grau de qualidade.

4 Por que é necessário testar um software? Garantir que todos os requisitos estão implementados e sem erros; Tentar encontrar algo que na verdade não queremos encontrar; Provar que o software tem erros; Evitar defeitos no cliente. QUALIDADE ECONOMIA SEGURANÇA CONFIABILIDADE

5 PESSOAS!! Qual a causa dos problemas? ERRO -> Ação humana que produz um resultado incorreto; DEFEITO (BUG) -> manifestação de um erro no software. Se executado, o defeito pode causar uma falha; FALHA -> diferença indesejável entre o observado e o esperado. (defeito encontrado).

6 Objetivos do Teste de Software Encontrar defeitos; Prevenir defeitos; Garantir confiança sobre o nível de qualidade; Prover informações.

7 O que pode ser testado? Modelos de Processos; Regras de Negócio; Especificação de Requisitos; Modelos de Análise; Documentos do Projeto; Arquitetura; Códigos.

8 Custo da correção dos defeitos De acordo com a regra 10 de Myers, o custo da correção de um defeito tende a ser cada vez maior quanto mais tarde for detectado. Custo Design Especificação Código Teste Produção Tempo

9 Verificação x Validação Verificação: Responsável em provar que o artefato atende aos requisitos especificados em sua fase anterior (inspeções e revisões). Nós construímos o sistema corretamente?. Validação: Responsável em provar que o produto atende aos requisitos solicitados pelo usuário. Nós construímos o sistema correto?.

10 1. Técnicas de testes: Teste Caixa Branca; Teste Caixa Preta. Estratégias de Teste 2. Estágios (Níveis) de testes: Unidade; Integração; Sistema; Aceitação.

11 1. Técnicas de testes 1.1.Caixa Branca (Teste Estrutural): Tem como objetivo encontrar defeitos na estrutura interna ou no código do software. Geralmente é realizada pelos programadores nos seus próprios códigos, pois envolve conhecimento detalhado do software; Testar: Lógica do código, suas cláusulas, características técnicas, configurações, estrutura de controle, acesso a dados e interface.

12 1. Técnicas de testes 1.2.Caixa Preta (Teste Funcional): Tem como objetivo determinar se os requisitos foram atendidos pelo software. Necessita do conhecimento dos requisitos.

13 Definem o momento do ciclo de vida do software em que são realizados os testes. 2.1.Teste Unitário Executados pelos desenvolvedores durante o processo de construção. Objetivos: Reduzir custo dos defeitos; Testar os componentes individuais certificando-se de que as entradas e saídas são válidas; Testar a estrutura interna do sistema.

14 2.2.Teste Unitário Contexto OO O conceito de unidade se modifica -> o encapsulamento guia a definição de classes e objetos. Uma classe encapsulada é usualmente o foco do teste unitário. Diferenças: Convencional: foco no detalhes algoritmo de um módulo e os dados que fluem através da interface do módulo. OO: é guiado pelas operações encapsuladas na classe e pelo estado de comportamento da classe.

15 2.2. Teste de Integração Executado para garantir que as unidades testadas (teste unitário) funcionem corretamente quando integradas. Caracterizado por testar as interfaces ente os componentes, interações de diferentes partes de um sistema como o sistema operacional, arquivos, hardware ou interfaces entre sistemas.

16 2.2. Teste de Integração OO Software orientado a objetos não tem uma estrutura óbvia de controle hierárquico. Duas Estratégias: Teste baseado no caminho de execução. Teste baseado no uso.

17 2.2. Teste de Integração OO Teste baseado no caminho de execução. Integra o conjunto de classes necessárias para responder a uma entrada ou um evento do sistema. Cada caminho de execução é integrado e testado individualmente.

18 2.2. Teste de Integração OO Teste baseado no uso. Testa as classe independentes, ou seja, que não usam (ou que usam poucas) classes servidoras. Depois são testadas as classes dependentes.

19 2.3. Teste de Sistema Normalmente executado quando o software está funcionando totalmente. Objetivos: exercitar a operação do sistema de forma completa; Verificar se os módulos executam suas funções apropriadamente; Demonstrar que o sistema executa de modo funcional e operacional as funções especificadas; Verificar a Integração dos componentes de software em um ambiente similar ao de produção (hardware, software, pessoas e outros sistemas).

20 2.3. Teste de Sistema (continuação) Abordagens: Determinar como um módulo pode ser invocado através de outro módulo do mesmo sistema; Dados devem ser transmitidos de forma correta entre os módulos do mesmo sistema; Compatibilidade um módulo não deve causar impactos indesejáveis em outro módulo (funcionalidades e perfornance).

21 2.3. Teste de Sistema (continuação) Teste de Recuperação: Verifica a capacidade do sistema se recuperar de falhas e retornar o processo dentro de um tempo pré-estabelecido. Em alguns casos, um sistema deve ser tolerante a falhas, isto é, falhas de processamento não devem causar a interrupção da função global do sistema. Em outros casos, o processamento não deve ser continuado em caso de falhas. O sistema deve ser forçado a falhar de diversos modos para verificar:

22 2.3. Teste de Sistema (continuação) Teste de Recuperação: O sistema deve ser forçado a falhar de diversos modos para verificar: Reinicialização automática, Recuperação de dados,...

23 2.3. Teste de Sistema (continuação) Teste de Segurança: Qualquer sistema de computador que administra informação sensível é alvo para invasões (impróprias ou ilegais). Invasões: hackers, empregados descontentes, outros... O teste de segurança verifica se os mecanismos de proteção incorporados a um sistema vão de fato protegê-lo. O testador desempenha o papel de invasor! Objetivo: projetista -> tornar o custo da invasão maior do que o valor da informação.

24 2.3. Teste de Sistema (continuação) Teste de Estresse: São projetados para submeter o sistema a situações (quantidade, freqüência ou volume) anormais. Pergunta: Quanto nós podemos judiar disto antes que falhe?

25 2.3. Teste de Sistema (continuação) Teste de Desempenho: É projetado para testar o desempenho do sistema durante a execução, no contexto de um sistema integrado. Ocorre ao longo de todos os passos do processo de teste, mesmo o unitário. São frequentemente acoplados aos testes de Estresse. É necessário medir a utilização de recursos: Tempo de processamento, respostas a eventos...

26 2.4. Teste de Aceite/Validação (UAT) Verificar se a solução atende os objetivos do negócio e a seus requisitos (funcionalidades e usabilidade); Objetivo: Estabelecer confiança do sistema; São executados pelos usuários: Teste alfa: nas instalações da equipe de teste e/ou desenvolvimento; Teste beta: nas instalações do usuário, sem a supervisão da equipe de teste.

27 2.4. Teste de Aceite/Validação (UAT) Abordagens: Discussões com os usuários; Revisão dos requisitos do software para identificar áreas importantes ou funções a serem testadas; Dados utilizados devem ser iguais aos dados de produção; Aspectos de segurança do dado deve ser observados; Facilidade de help e usabilidade.

28 RESUMO Técnica CAIXA BRANCA (Estrutural) Teste Unidade (Nível Módulo) Testar comandos, estruturas de dados e caminhos lógicos; Teste Integração (Teste Subsistema) Testar a integração entre as interfaces/componentes dos módulos; Técnica CAIXA PRETA (Funcional) Teste de Sistema (Nível de Sistema) Testar funcionalidades, integração e desempenho; Teste de Aceite/Validação (Nível de Sistema) Demonstrar a conformidade dos requisitos.