1) O documento discute os conceitos e técnicas de teste de software, incluindo os objetivos dos testes, diferentes tipos de testes e estratégias de teste. 2) São descritos os conceitos de defeito, erro e falha, além das diferenças entre teste e depuração. 3) São apresentadas as etapas de um processo de teste, incluindo teste de unidade, integração, validação e sistema.

1. Professor Roberto Nunes
Gerenciamento e Qualidade de
Software

2. São técnicas empregadas durante o processo de
desenvolvimento de um software.
Visam detectar antecipadamente falhas nos
vários artefatos produzidos durante o processo de
desenvolvimento.
“O teste consiste em
executar o programa com
a intenção de encontrar
erros (bugs)”.
Myers, 1979.
O que é Teste de Software?

3. Martin Pol
Em linhas gerais, podemos dizer que o objetivo dos testes é encontrar
defeitos: desta forma os testes são conduzidos para demonstrar a
ausência de qualidade expressa pela presença de defeitos, para tal se
faz necessário um processo (planejamento, especificação, execução,
análise de resultados), considerando-se sempre os riscos do negócio e
a qualidade do produto. (Visão do processo, projeto, requisito, risco
de negócio e a qualidade para o negócio).
Fonte: Software Testing – A Guide to the Tmap Approach – Martin Pol e outros.
O que é Teste de Software?

4. É preciso garantir que os erros serão
eliminados.
Aumentar a qualidade do produto.
Reduzir o custo
Porque testar Software?

5. Aumento de falhas devido a ausência de qualidade;
Aumento dos custos de suporte;
Aumento dos custos de desenvolvimento;
Falta de confiabilidade do produto no mercado;
Insatisfação dos clientes e usuários;
Perda de mercado;
A falta de teste

6. Abordagem Estratégica ao Teste de
Software
A atividade de teste inicia-se no nível de módulos e
prossegue “para fora” na direção da integração de todo o
sistema baseado em computador diferentes técnicas de
teste são apropriadas e diferentes pontos do tempo.
A atividade de teste é realizada pela equipe de
desenvolvimento ou por um grupo de teste independente.
Atividades de teste e de depuração são diferentes, a
depuração deve ser acompanhada de uma estratégia de
teste.

7. Características genéricas
Reforçando:
• Vai do nível de componentes até o sistema;
• Técnicas distintas para momentos diferentes;
• Executados tanto pelo desenvolvedor como por
grupo independente;
• depuração deve fazer parte de qualquer
estratégia de teste.

8. Organizando os testes
• Conflito de interesses: desenvolvedores testam para
mostrar que o programa funciona e não para encontrar
erros.
• Psicologicamente: desenvolver é construtivo e testar é
destrutivo;
• O desenvolvedor deve ser o responsável pelos testes
individuais dos componentes;
• A função do grupo independente de teste (ITG) é eliminar
o conflito de interesses. São pagos para encontrar erros;
• O ITG deve trabalhar em conjunto com a equipe
desenvolvimento do projeto.

9. Uma Estratégia de Teste de Software
A
U
D
I
V
R
ST
S
Engenharia de Sistema
Requisitos
Projeto
Código
Teste de Integração
Teste de Validação
Teste de Sistema
Teste de Unidade

10. Uma Estratégia de Teste de Software
• Uma estratégia de teste de software pode ser vista como uma
espiral
• o teste unitário inicia-se no vértice da espiral e concentra-se em
cada unidade do software de acordo com o que é implementado
no código fonte

11. Uma Estratégia
4 etapas executadas sequencialmente:
1. Testes de unidade:
Foco em cada componente individual, garantindo que a função
apropriada de cada componente está sendo realizada;
2. Testes de integração:
Foco na verificação e construção do programa, resultado da
integração dos componentes;
3. Testes de validação:
Foco na validação dos requisitos funcionais, de comportamento,
e de desempenho;
4. Testes de sistema:
Uma vez validado, o software deve ser combinado com outros
elementos (hardware, pessoas, dados). Verifica que a
função/desempenho do sistema como um todo é alcançada.

12. Teste de Especificações de Requisitos;
Teste de Modelos de Análise;
Testes Baseados em Modelos;
Teste de Regras de Negócio;
Teste de Unidade;
Teste de Integração;
Teste de Validação;
Teste de Sistema;
Teste de recuperação;
Teste de Segurança;
Teste de estresse;
Teste de desempenho;
Teste de Interface;
Teste de Carga;
Teste de Funcionalidade;
Teste de Usabilidade;
Teste de Portabilidade;
Teste de Compatibilidade;
Teste de documentos do projeto;
Teste de Aceitação;
Testes Alfa e Beta;
Testes para Arquiteturas Cliente/Servidor;
Testes para Sistemas de Tempo Real;
Testes da Estrutura Central;
Testes de Caixa Preta;
Testes de Caixa Branca;
Testes de Caminho Base;
Testes de Implantação;
Testes de Métodos Aplicáveis a Classes;
Testes derivados de modelos de comportamento;
Testes para Aplicações Orientadas a Objeto e Design
Orientado a Objetos;
Testes de Componentes, Navegação e Configuração;
Testes de Conteúdo;
Testes de Interface do Usuário;
Testes de Segurança e Desempenho;
O que testar?

13. Fonte: http://www.ufpi.br/subsiteFiles/pasn/arquivos/files/CursoTesteNovoPDFParte4.pdf

14. Defeito: resultado de um erro encontrado no código ou
documento;
Erro: ”engano” cometido por seres humanos;
Falha: resultado ou manifestação de um ou mais defeitos.
Exemplo: A aplicação entra em looping infinito, devido a um
erro de lógica, ocasionando o travamento da mesma.
Conceitos básicos

15. Depuração
A depuração tem como objetivo encontrar e corrigir as
causas dos erros de um software.
Depurar não é testar, mas sim uma consequência dos
mesmos.
Formas de depuração:
• Força bruta;
• “Backtracking”;
• Eliminação da causa.

16. Documentação
• Plano de testes
descreve a estratégia de integração como um todo, incluindo o
cronograma de integração, a descrição de overhead (stubs e
drivers), o ambiente de testes, recursos envolvidos, bem como
ferramentas e técnicas utilizadas
• Procedimento de testes
a sequência de integração e os testes correspondentes a cada fase
da integração são descritos. Uma lista de todos os casos de teste e
os resultados esperados deve ser incluída;
• Histórico
resultados dos testes, problemas, ou peculiaridades devem ser
registrados

17. Critério de finalização dos testes
Como saber que os testes executados foram suficientes?
Algumas respostas:
• Os testes nunca terminam.
Apenas ocorre uma transferência do ônus de testar, do
desenvolvedor para o usuário;
• Os testes terminam quando acaba o prazo e/ou o dinheiro;
• Aproximações empíricas buscam modelar falhas como uma
função do tempo de execução.
A idéia é prever o tempo total necessário para a execução de testes,
de modo a atingir um nível de confiabilidade aceitável.

18. Questões fundamentais
• Quantificar os requisitos do produto antes do início dos testes;
• Explicitar os objetivos dos testes;
• Desenvolver um perfil para cada categoria de usuário;
• Desenvolver um plano de testes que enfatize ciclos curtos;
• Construir software robusto que seja capaz de se auto-testar;
• Utilizar revisões formais como um filtro antes dos testes;
• Realizar revisões formais de modo a garantir a própria estratégia de
teste;
• Aplicar melhorias contínuas ao processo de testes.

19. Teste de Integração
O teste de integração é o processo de verificar se os componentes do
sistema, juntos, trabalham conforme descrito nas especificações do
sistema e do projeto do programa.
Na fase de teste de integração, o objetivo é encontrar falhas
provenientes da integração interna dos componentes de um sistema.
Geralmente os tipos de falhas encontradas são de transmissão de
dados.

20. Teste de Integração
Por exemplo, um componente A pode estar aguardando o retorno de
um valor X ao executar um método do componente B; porém, B pode
retornar um valor Y, gerando uma falha.
Não faz parte do escopo dessa fase de teste o tratamento de interfaces
com outros sistemas (integração entre sistemas).
Essas interfaces são testadas na fase de teste de sistema e não teste de
integração.

21. Teste de Integração na Prática
Muitos perguntam como fazer teste de integração com Junit testando
desde as camadas iniciais até o Banco de dados e nisso tudo juntando
vários componentes.
Algumas situações devem ser pensadas como: O que testar? Como
testar? Como manter o banco de dados sem sujeiras?
O que deve ser testado deve ser verificado pelo desenvolvedor o qual
precisa entender qual funcionalidade do sistema precisa de uma
verificação.

22. Teste de Integração na Prática
Por exemplo, o desenvolvedor pode querer testar como é feita uma
operação de débito numa conta corrente, nessa situação ele deve
verificar que o programa debitou uma certa quantia de dinheiro no
banco de dados e o resultado retornado do saldo trouxe a quantia
anterior ao débito subtraído da quantidade que foi inicialmente
passada.
A pergunta de como testar deve ser respondida utilizando Junit, sua IDE
como Eclipse e a linguagem de programação Java.
Por fim, deve ser feita uma estratégia que não deixe sujeiras no Banco
de dados após as operações terem sido concluídas.

23. Teste de Unidade
O teste de unidade tem o maior efeito sobre a qualidade do código
quando é parte integrante do fluxo de trabalho de desenvolvimento de
software.
Assim que você escrever uma função ou outro bloco de código do
aplicativo, crie testes de unidade que verifique o comportamento do
código em resposta a casos padrão, limite e incorretos de dados de
entrada e verifique se não houve nenhuma suposição explícita ou
implícita feita pelo código.
Com o desenvolvimento orientado por testes, você cria os testes de
unidade antes de escrever o código e, portanto, os testes de unidade
são usados tanto como documentação de design quando especificações
funcionais.

24. Teste de Unidade
O Gerenciador de Testes também pode executar estruturas de teste de
unidade de código aberto e de terceiros que implementaram interfaces
de complemento do Gerenciador de Testes.
Você pode adicionar muitas dessas estruturas por meio do gerenciador
de extensões do Visual Studio e da galeria do Visual Studio.
Você pode gerar os projetos de teste e métodos de teste rapidamente
do seu código ou criar os testes manualmente conforme a necessidade.
Ao usar o IntelliTest para explorar o código .NET, você pode gerar dados
de teste e um conjunto de testes de unidade

25. Teste Alfa e Beta
Os Testes Alfa são assim chamados por serem realizados no início, ou
seja, próximo ao final do desenvolvimento do aplicativo e antes dos
testes Beta.
Esses testes são realizados para verificar a aceitação do aplicativo, além
de possíveis bugs antes do lançamento para os usuários.
Os Testes Alfa são realizados em ambientes de laboratório* e
comumente são executados por funcionários internos que simulam
usuários reais, realizando tarefas típicas no aplicativo.
Nessa modalidade, problemas críticos ou correções podem ser
solucionados pelos desenvolvedores imediatamente.

26. Teste Alfa e Beta
Os testes Beta de um aplicativo são realizados por usuários reais em
ambientes reais e podem ser considerados como uma forma de teste de
aceitação do aplicativo.
Neste caso, a versão beta do aplicativo é liberada para um número
limitado de usuários reais para se obter feedback sobre a qualidade do
aplicativo.
Os testes Beta são fundamentais para reduzir riscos de falhas e fornecer
maior qualidade do app por meio da validação dos usuários.
Geralmente as maioria das questões ou feedback coletados no teste
Beta são implementados em versões futuras do aplicativo.

27. Teste Alfa e Beta
Este modelo de teste é dividido em duas categorias:
Beta Fechado: Formato usado para testes com grupos pequenos de
usuários (exemplo: uma empresa, um departamento ou usuários
específicos).
Caso o teste seja feito em um aplicativo já publicado em uma loja,
somente os usuários do grupo receberão atualizações da versão.
Beta Aberto: Formato usado para testes com grupos maiores de
usuários.
Nessa versão de testes qualquer usuário pode participar e enviar
feedback uma vez que o app estiver publicado na app stores.

28. Por que usar Teste Alfa e Beta?
Tanto o teste Alfa quanto o teste Beta possuem suas importâncias na
busca pela qualidade de um aplicativo. Confira abaixo algumas razões
para usar ambos:
• Reduz o risco de falhas do aplicativo por meio da validação dos
usuários.
• Ajuda a melhorar a relação com o usuários, além de aumentar a
satisfação com o app.
• Ajuda a fornecer uma melhor visão sobre a confiabilidade do
aplicativo em sua fase inicial
• Ajuda a detectar de maneira precoce erros em relação ao design
e funcionalidade.
• O feedback dos usuários durante a fase de testes não afetam a
avaliação pública do aplicativo.

29. Verificação e validação
Verificação e validação são procedimentos independentes que são
usados em conjunto para verificar se um produto, serviço ou sistema
atende aos requisitos e especificações e se cumpre sua finalidade.
Esses são componentes críticos de um sistema de gerenciamento de
qualidade , como o ISO 9000 .
As palavras "verificação" e "validação" às vezes são precedidas por
"independente", indicando que a verificação e validação devem ser
realizadas por um terceiro desinteressado.
"Verificação e validação independentes" podem ser abreviadas como
V&V.

30. Verificação e validação
As atividades de verificação e validação (V&V) servem para assegurar
que o software funcione de acordo com o que foi especificado.
A verificação tem como propósito averiguar se o software está de
acordo com as especificações preestabelecidas, e a validação é o
processo de confirmação de que o sistema está apropriado e
consistente com os requisitos.

31. Verificação e validação
Verificação
Fizemos o software corretamente?
Esta atividade se resume em responder a esta pergunta.
A verificação tem o objetivo de avaliar se o que foi planejado realmente
foi realizado. Ou seja, se os requisitos e funcionalidades documentados
foram implementados, além disso a verificação também pode ser
realizada para especificação de sistemas, para avaliar se os requisitos
estão sendo documentados como deveriam e ainda prever falhas ou
inconsistências entre requisitos.

32. Verificação e validação
Validação
Fizemos o software correto?
A validação tem o objetivo de avaliar se o que foi entregue atende as
expectativas do cliente. Ou seja, se os requisitos, independente do que
foi planejado, estão sendo implementados para atender a regra de
negócio do cliente, se o sistema é realmente aquilo que o cliente quer e
está pagando para ter.
A validação final do sistema é realizada pelo próprio cliente ou usuário.

33. Obrigado!
Bons Estudos.