Teste de software - Processo de Verificação e Validação

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

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

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.

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.

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.

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

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

(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

(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

(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

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

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

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

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

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

• 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

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

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

• 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.

• 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).

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

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

• 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

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

❶
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

❷
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.

❸
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.

❹
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.

❺
Ele deve ser planejado por se tratar de uma atividade importante
que exige estratégias e recursos.

❻
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”

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

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

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

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.

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

Teste de software - Processo de Verificação e Validação

Mais conteúdo relacionado

Mais procurados (20)

Destaque (20)

Semelhante a Teste de software - Processo de Verificação e Validação (20)

Mais de Joeldson Costa Damasceno (18)

Último (20)

Teste de software - Processo de Verificação e Validação