Processo de Verificação e Validação. Conceitos de testes de software.

1. TESTE DE SOFTWARE
Verificação e Validação
Aula 02
Joeldson Costa Damasceno
joeldsoncosta@gmail.com

2. VERIFICAÇÃO E VALIDAÇÃO
Conceitos
Livro referência:

3. Verificação e Validação
V&V é um processo aplicado para melhorar a qualidade dos produtos e a
produtividade dos processos de software.
Permite os desenvolvedores identificar problemas de software o mais
rápido possível e corrigi-los antes de entregarem aos usuários.
Permite identificar e corrigir problemas nas atividades de
desenvolvimento para aumentar a produtividade de novos projetos de
software.

4. Permite que se determine sistematicamente se os requisitos de um
sistema estão sendo corretamente tratados e implementados.
Diminui as chances de retrabalho desde as primeiras fases do
desenvolvimento de software.
Contribui diretamente para o atendimento dos prazos e custos do
projeto.
Verificação e Validação

5. Verificação e Validação
Em cada fase do desenvolvimento os requisitos ou componentes
são verificados para ver se estão completos ou corretos.
Cada fase de desenvolvimento atende aos requisitos e às
condições impostas pela fase anterior e o sistema ou componente
final está aderente com os requisitos especificados.

6. PROBLEMAS
Erros? Falhas? Defeitos? Existe diferença?

7. Requisitos incompletos e incorretos indicam problemas no produto
que podem se manifestar por meio de falhas, caso não sejam
corrigidos, durante a operação e uso do software. A IEEE descreve
várias definições de problemas que podem ocorrer:
– Erro (error, mistake);
– Defeito (bug, fault, defect);
– Falha (failure).
Problemas

8. (IEEE) Uma ação humana que produz um resultado incorreto.
Exemplos:
• Os desenvolvedores cometem erros (enganos) quando
interpretam mal as necessidades dos clientes.
• Os usuários cometem erros (enganos) quando operam um
sistema em desacordo com as intenções dos desenvolvedores.
Erros causam defeitos >>
Erro - error, mistake

9. (IEEE) Implementado dentro de um artefato.
Exemplos:
• Requisitos inconsistentes com as necessidades do cliente.
• Requisitos funcionais do sistema em desacordo com os
requisitos do negócio.
Os defeitos podem ou não se manifestar em falhas >>
Defeito - bug, fault, defect

10. (IEEE) A incapacidade de um sistema ou componente em executar
as funções requeridas dentro de um nível de desempenho
requerido.
Exemplos:
• Manifestação de um defeito no sistema ou software.
• Apresentação de data incorretas.
• Tela azul no monitor do computador.
Falha – failure

11. TÉCNICAS DE V&V

12. Podem ser divididas em estáticas e dinâmicas.
Técnicas de V&V

13. TÉCNICAS ESTÁTICAS

14. Nas técnicas estáticas, a avaliação de um produto de software é realizada por
um grupo de revisores, com intuito de identificar defeitos. Elas podem ser:
a) Revisões Técnicas e Walkthroughs: Indicadas para todas as fases do ciclo de
desenvolvimento de software.
• Revisões Técnicas permitem avaliar um produto de software para terminar a
sua adequação ao uso pretendido. Identificar discrepância entre especificações
e padrões aprovados.
• Walkthroughs permitem também avaliar um produto de software. O objetivo é
identificar anomalias, melhorar o produto, considerar alternativas de
implementação e avaliar conformidade a padrões e especificações.
Técnicas Estáticas

15. b) Inspeções: Indicadas para a fase de codificação.
• Inspeções têm por objetivo detectar identificar anomalias no produto de
software.
As técnicas de inspeções de software são/devem ser aplicadas em todas
as fazes do ciclo de desenvolvimento de software. Isso justifica-se porque
os defeitos podem ocorrer em códigos, arquitetura, requisitos,
especificações e documentação em geral.
Técnicas Estáticas

16. Durante o processo de inspeção alguns defeitos podem ser
identificados. Os tipos de defeitos podem ser caracterizados como:
• Incorreção: Implementação incorreta da especificação do
cliente/usuário.
• Ausência: Checagem de requisito especificado que não foi
incorporado no produto.
• Extra: Checagem de requisito não especificado e incorporado no
produto.
Tipos de Defeitos

17. Outra forma de ver os defeitos é pelo tipo de danos que eles podem causar no
software: Os feitos podem ser:
• Pequenos: Podem ser corrigidos rapidamente e não causam mau
funcionamento do software. Exemplos: defeitos de digitação, omissões em
textos eu precisam ser esclarecidos para seu entendimento e etc.
• Grandes: São defeitos relativos às especificações que podem causar mau
funcionamento do software. Exemplos: ausência de funções, problemas de
interfaces etc.
• Muito sério: São defeitos que podem comprometer o projeto ocasionando o
reprojeto total (ou quase) e a recodificação do software.
Classificação de Defeitos

18. TÉCNICAS DINÂMICAS

19. • A avaliação é feitas através de testes.
• Os testes podem ser estruturais (Teste Caixa Branca) ou
funcionais (Teste Caixa Preta).
• Para realizar os primeiros testes, a boa prática diz que se deve
verificar inicialmente se a menor unidade de software está
funcionando de acordo com as suas especificações. Nestes são
realizados os testes estruturais.
• Após a verificação das unidades, parte-se para os testes
funcionais para verificar o software como um todo.
Técnicas Dinâmicas

20. Atendem às seguintes características:
• O projeto de casos de teste usa a estrutura de controle procedimental do
software (fluxo de controle) para derivar casos de teste.
• Deve garantir que todos os caminhos independentes dentro de um módulo
tenham sido exercitados pelo menos uma vez.
• Devem exercitar todas as decisões lógicas para valores falsos ou verdadeiros.
• Devem executar todos os laços em suas fronteiras e dentro de limites
operacionais.
• Devem exercitar as estruturas de dados internas para garantir a sua validade.
Testes Caixa Branca

21. Os tipos mais comuns são (funcionais):
• Teste de integração:
– Testar um conjunto de módulos;
– Verificação do funcionamento com foco nas interfaces;
– A referencia utilizada é a especificação do projeto;
– Teste realizado pela equipe de desenvolvimento.
• Teste de validação:
– Verificar o software como um todo;
– Verificar se todas as exigências funcionais, comportamentais e de desempenho foram atendidas.
– A referencia utilizada é a especificação de requisitos funcionais e não funcionais;
– Teste realizado pela equipe de desenvolvimento.
Tipos de Testes Caixa Branca

22. • Teste de sistema:
– Medir o sistema em diferentes cenários verificado se todos os elementos do
sistema (hardware, software, banco de dados e pessoas) foram adequadamente
integrados e realizam as funções requeridas.
– A referencia utilizada é a especificação de requisitos;
– Realizado por uma equipe independente ou um usuário do sistema.
Tipos de Testes Caixa Branca

23. • Outros testes de sistema:
– Teste de recuperação: Força o sistema a apresentar falhas de diversas
maneiras e verifica se a recuperação (reiniciação do sistema e recuperação
de dados) é adequadamente executada.
– Teste de proteção: verifica se todos os mecanismos de proteção embutidos
em um sistema funcionam contra acessos indevidos.
– Teste de estresse: confrontar com situações anormais (altas exigências de
recursos de dados, alto número de interrupções, alta taxa de entrada de
dados, alta busca de dados em disco etc.)
– Teste de desempenho: teste do software no contexto de um sistema
integrado (tempos envolvidos, ciclos de processador, interrupções etc).
Tipos de Testes Caixa Branca

24. Atendem às seguintes características:
• Concentram-se nos requisitos funcionais do software.
• São uma abordagem complementar aos testes estruturais.
Testes Caixa Preta

25. Os tipos mais comuns são (estrutural):
• Teste de unidade:
– O objetivo é testar os módulos isoladamente verificando o
funcionamento conjunto dos algoritmos e as estruturas de dados.
– A referencia utilizada é a especificação de módulos, um documento
detalhado de cada módulo do software.
– Teste realizado por um programador.
Tipos de Testes Caixa Preta

26. OUTROS TESTES DE SOFTWARE

27. • Teste Alfa: realizado pelo cliente no ambiente de
desenvolvimento do software.
• Teste Beta: realizado em um ou mais ambientes do cliente pelos
usuários.
Outros testes de software

28. PRINCÍPIOS IMPORTANTES

29. Segundo Hirama (livro referência) apesar da importância dos testes
de software, sua realização apresenta algumas dificuldades:
1. Falta de conhecimento necessário sobre testes por parte dos
desenvolvedores.
2. Simplificação quando o cronograma do projeto está comprometido.
Para isso, ele destaca alguns princípios importantes que deve ser seguidos >>
A atividade de testes

30. ❶
Teste completo não é possível, ou seja, testar todas as situações
não é possível. Não significa que se pode deixar algum requisito do
cliente sem teste.
TESTES - Princípios importantes

31. ❷
A atividade de teste é criativa e difícil, ou seja, ela exige boa
experiência dos testadores. É necessário conhecimento para ter
maior cobertura possível dos testes.
TESTES - Princípios importantes

32. ❸
Uma importante razão do teste é a prevenção de defeitos, ou seja,
o teste permite melhorar a qualidade do software detectando os
defeitos no software.
TESTES - Princípios importantes

33. ❹
O teste é baseado em risco, ou seja, o esforço de teste é
proporcional ao risco de negócio envolvido (resultados incorretos,
transação não autorizada, perda de desempenho,
comprometimento de segurança etc.) quanto maior o risco de
negócio mais teste devem ser realizados.
TESTES - Princípios importantes

34. ❺
Ele deve ser planejado por se tratar de uma atividade importante
que exige estratégias e recursos.
TESTES - Princípios importantes

35. ❻
O teste requer independência, ou seja, não basta planeja-lo, é
necessário ter visão crítica para analisar os resultados; uma boa
prática é “quem implementa não testa”
TESTES - Princípios importantes

36. QUALIDADE DO SOFTWARE

37. O teste:
– Ajuda a tornar a qualidade visível.
– É a maneira de medir a qualidade de software.
A qualidade do software está intimamente relacionada a
quantidade de erros descobertos.
+ erros descobertos + maior qualidade
Qualidade do software

38. Segundo Perry, a proporção de defeitos detectados em projeto de
software é:
Qualidade do software
36%
64%
Codificação
Análise e Projeto

39. EXTENSÃO DE TESTE

40. Extensão de teste
Custo de teste
Extensão do teste
Qualidade
Número de defeitos
Teste
Excessivo
Teste
Insuficiente

41. EXERCÍCIOS

42. 1. Em uma verificação de produtos ou documentos buscam-se erros, defeitos ou falhas?
Justifique.
2. A maior parte de defeitos é embutida nas fase iniciais do desenvolvimento de software. Sugira
formas de minimizar este problema.
3. Explica com suas palavras o que significam as questões “Estamos construindo certou o
produto?” para verificação e “Estamos construindo o produto certo?” para validação.
4. Escolha três produtos de desenvolvimento de software que devem passar por uma técnica
estática de V&V, Qual foi o critério usando para as escolhas?
5. A aplicação da técnica dinâmica de V&V, conhecido como teste de software, depende dos
programas estarem prontos. Como se poderia organizar os testes de maneira que sejam os
mais efetivos possíveis?
6. Qual a diferença entre técnicas estáticas e dinâmicas de V&V? O que podem ser verificados?
7. O teste é baseado em risco ao negócio. Cite uma área de negócio onde os testes devem ser
mais rigorosos. Justifique.
8. O que são teste caixa branca e caixa preta? Dê exemplos.
9. A finalidade dos teste de validação é verificar o atendimento de requisitos do cliente. Está
correto? Justifique.

43. PERGUNTAS ?

44. Referência
HIRAMA, Kechi. Engenharia de Software: qualidade e produtividade com tecnologia /
Kechi Hirama. Rio de Janeiro: Elsevier, 2011. ISBN 978-85-352-4882-1