Fundamentos de Testes de Software

Maio 2014

Quem Sou Eu?

● Aline Zanin;● Graduada em Análise e Desenvolvimento de

Sistemas - UPF 2011;● Especialista em Qualidade de Software -

Unisinos 2013;● Mestranda PUCRS - Ciência da Computação ● Pesquisadora - Centro de Pesquisa em

Engenharia de Sistemas PUCRS -DELL

Agenda

● Porque Testar;● Tipos de Testes;● Metodologia de Testes;● 7 Fundamentos de Testes;● Casos de Teste;● Cenários de Testes;● Conclusão.

Oque são testes?

Teste é o processo de executar um programa com o objetivo de verificar sua conformidade em relação aos requisitosespecificados.

Porque Testar Seu Software?

● De acordo com estatísticas um cliente insatisfeito comenta com outras cinco pessoas no mínimo que está insatisfeito enquanto um cliente satisfeito elogia a apenas uma pessoa.

● O desenvolvedor, é o responsável pela criação do software sendo assim se realizar testes irá seguir o “caminho feliz”

Porque Testar Seu Software?

● Quando cliente se depara com uma falha em seu sistema ocorre uma quebra de confiança.

● Uma falha que atinge o cliente pode causar danos financeiros milhares de vezes maior que o custo de teste*

*Segundo o National Institute of Standards and Technology (NIST), dos EUA, os custos diretos dos erros de software representam 0,6 % do PIB americano, o equivalente a US$ 293 bilhões.

Regra10 de Myers

DefeitoQualquer condição que causa um desvio de um resultado baseado no que diz um requisito, um documento de especificação, um documento do usuário, um padrão, ou conforme a experiência ou percepção do técnico, que requeira investigação.

Erro

O Erro pode ser um resultado de um defeito ou uma falha, como um retorno esperado, que por causa de uma falha teve um valor diferente do que esperado.

Falha

Esta mais ligada ao hardware, como uma rede inacessível, queda de energia. Uma falha pode ocorrer por causa de um erro, ou não.

Princípios FundamentaisPrincípio 1 – Teste demonstra a

presença de defeitosO teste pode demonstrar a presença de defeitos, mas não pode provar que eles não existem. O Teste reduz a probabilidade que os defeitos permaneçam em um software, mas mesmo se nenhum defeito for encontrado, não prova que ele esteja perfeito.

Princípios Fundamentais

Princípio 2 – Teste exaustivo é impossível

Testar tudo (todas as combinações de entradas e pré-condições) não é viável, exceto para casos triviais. Em vez do teste exaustivo, riscos e prioridades são levados em consideração para dar foco aos esforços de teste.

Princípios Fundamentais

Princípio 4 – Agrupamento de defeitos

Um número pequeno de módulos contém a maioria dos defeitos descobertos durante o teste antes de sua entrega ou exibe a maioria das falhas operacionais.

Princípios Fundamentais

Princípio 5 – Paradoxo do Pesticida

Pode ocorrer de um mesmo conjunto de testes que são repetidos várias vezes não encontrarem novos defeitos após um determinado momento.

Princípios Fundamentais

Princípio 6 – Teste depende do contexto

Testes são realizados de forma diferente conforme o contexto. Por exemplo, softwares de segurança crítica são testados diferentemente de um software de comércio eletrônico.

Princípios Fundamentais

Princípio 7 – A ilusão da ausência de erros

Encontrar e consertar defeitos não ajuda se o sistema construído não atende às expectativas e necessidades dos usuários.

Tipos de Testes de Software.

- Caixa Branca

Feito junto ao código durante o processo de desenvolvimento.

- Caixa Preta

Executado a nível de aplicação, sem contato com código.

Tipo de Testes de Software.

Teste Funcional Testar as funcionalidades, requerimentos, regras de negócio presentes na documentação. Validar as funcionalidades descritas na documentação (pode acontecer de a documentação estar inválida)

Teste de InterfaceVerifica se a navegabilidade e os objetivos da tela funcionam como especificados e se atendem da melhor forma ao usuário.

Teste de Performance Verifica se o tempo de resposta é o desejado para o momento de utilização da aplicação.

Teste de VolumeTestar a quantidade de dados envolvidos (pode ser pouca, normal, grande, ou além de grande).

Teste de Unidade Teste em um nível de componente ou classe. É o teste cujo objetivo é um “pedaço do código”.

Teste de Integração Garante que um ou mais componentes combinados (ou unidades) funcionam. Podemos dizer que um teste de integração é composto por diversos testes de unidade*1

Tipo de Testes de Software.Teste de regressão Toda vez que algo for mudado, deve ser testada toda a

aplicação novamente.

Teste de aceitação do usuárioTesta se a solução será bem vista pelo usuário. Ex: caso exista um botão pequeno demais para executar uma função, isso deve ser criticado em fase de testes. (aqui, cabem quesitos fora da interface, também).

Testes de stress Testar a aplicação sem situações inesperadas. Testar caminhos, às vezes, antes não previstos no desenvolvimento/documentação.

Testes de ConfiguraçãoTestar se a aplicação funciona corretamente em diferentes ambientes de hardware ou de software.

Tipo de Testes de Software.

Testes de Instalação Testar se a instalação da aplicação foi OK.

Teste de cargaVerifica o funcionamento da aplicação com a utilização de uma quantidade grande de usuários simultâneos.

Testes de Segurança Testar a segurança da aplicação das mais diversas formas. Utilizar os diversos papéis, perfis, permissões, para navegar no sistema.

Técnicas de Testes de Software

● Partição de Equivalência;● Análise do Valor Limite;● Tabela de Decisão;● Teste de transição de estados;● Técnicas baseadas na experiência;

Por onde Começar

Um bom começo seria identificar os cenários que serão testados nesta aplicação

CENÁRIO DE TESTES ???

Cenário de Teste

Cenário de teste descreve o que deve ser testado amplamente. O cenário de testes é o passo inicial para a criação do caso de teste.

Ex: 01 - Cadastro de Clientes

Este cenário tem a cobertura do cadastro de clientes, aplicação deve permitir cadastrar clientes entre 18 e 65 anos.

Definir Cenários de TesteDescrição: O Analista de Teste com base nos requisitos de teste ou nos casos de uso, e usando o Plano de Teste como referência, deve definir os Cenários de Teste e que servirão posteriormente para a elaboração dos Procedimentos (ou Roteiro) de Teste. Responsáveis: Analista de TesteParticipantes: Analista de Sistemas, Testador Artefatos: Plano de Teste, Requisitos, Casos de Uso (testáveis)Ferramentas: Precisam ser definidas

· Fluxo Principal:o P 1 – Usuário seleciona o menu “Alterar Senha” o P 2 – O sistema gera um código aleatórioo P 3 – O sistema carrega a tela “Alteração de Senha”o P 4 – Usuário entra com sua identificação, a senha atual, a nova senha, a

confirmação da nova senha e o valor do código aleatório (A1)o P 5 – O usuário confirma a alteração (A2)o P 6 – O sistema valida a senha. (E1) (E2)o P 7 – O sistema emite a mensagem de indicação de sucessoo P 8 – O caso de uso é finalizado

· Fluxo Alternativo 1: O usuário não visualiza código aleatórioo A 1.1 – O usuário seleciona opção “Não consegui visualizar o código”o A 1.2 – O sistema retorna ao fluxo principal (P2)

· Fluxo Alternativo 2: O usuário cancela a alteraçãoo A 2.1 – O usuário seleciona a opção cancelaro A 2.2 – O sistema cancela a operaçãoo A 2.3 – O caso de uso é finalizado

·

Fluxo de Exceção 1: Confirmação de senha nova não confere com a mesmao E.1.1 – O sistema identifica que a nova senha fornecida e a

confirmação da mesma, não conferem.o E.1.2 – O sistema emite a mensagem “A confirmação da Nova Senha

não confere.”o E.1.3 – O sistema retorna ao fluxo principal (P4) para entrada da

confirmação da senha nova do usuário. Fluxo de Exceção 2: Campo Requerido Não Fornecido ou Inválido

o E.2.1 – Usuário não entra com campo requeridoo E.2.2 – O sistema emite a mensagem “Campo requerido ausente ou

inválido.”o E.2.3 – O caso de uso é finalizado

Cenário FluxoCenário 1 P1-P8

Cenário 2 P1-P4 / A1.1

Cenário 3 P1-P5 / A2.1-A2.3

Cenário 4 P1-P4 / E1.1-E1.3

Cenário 5 P1-P4 / E2.1-E2.3

Caso de teste é um conjunto de condições usadas para teste de software. Ele pode ser elaborado para identificar defeitos na estrutura interna do software, através de situações que exercitem adequadamente todas as estruturas utilizadas na codificação; ou ainda, garantir que os requisitos do software que foi construído sejam plenamente atendidos.

Casos de Testes

Fonte: Wikipedia =D

Casos de Teste Positivos:

Descrevem Operações que devem ser concluidas na aplicação.Ex: Efetuar Login com sucesso

Negativos:

Descrevem Operações que não devem ser concluidas na aplicação.Ex: Efetuar Login com usuário inválido.

Casos de TestesÉ importante que os casos de testes possuam as seguintes informações:

Identificador: um nome único que permita a identificação do caso de teste.Histórico de versões: lista as versões do documento, identificando o que foi alterado e o responsável por cada versão.Descrição: descreve o objetivo e o escopo do caso de teste.

Casos de Testes.Comportamento esperado: descreve o comportamento esperado do sistema durante e após a execução do teste. Nesta seção devem ser incluídas tanto as condições de sucesso, quanto as de falha.

Comportamento obtido: descreve o comportamento obtido através da execução do cenário de teste.

Histórico de execuções: descreve a data na qual o cenário de teste foi executado, qual foi o resultado do teste (passou ou falhou) e qual a forma de execução (automático ou manual).

Conclusão● Testes de software não garantem a ausência de defeitos,

porém, diminuem a incidência destes aumentando a qualidade do software.

● Diversas são as formas de organizar um processo de testes, a organização por cenários e casos de testes permite um mapeamento melhor da aplicação evitando que partes importantes não sejam testadas.

● Manter os artefatos de testes atualizados é vitál para ter um bom resultado com os testes.

?

aline.zanin@acad.pucrs.br

Referências - Mais informações

Brasiliam Software Testing Qualification Board http://www.bstqb.org.br/

Casos de Teste http://www.emersonrios.eti.br/Artigos/Microsoft%20PowerPoint%20-%20Casos%20de%20Teste%20de%20Software%20%20-

%203%20horas%20Conclu%C3%ADdo.pdf