FISP

Faculdades Integradas de So Paulo

Engenharia de Software II
Engineering Software Ian Somerville Ed. 2007
Validao e Verificao
Teste de Software

Marcos Francisconi

Abril de 2011

Resumo do Capitulo 22 do livro Engenharia de Software Ian Sommerville - 2007

Verificao e Validao.
Durante e depois do processo de implementao o programa precisa ser verificado para
assegurar que atende as especificaes e funcionalidades desejadas pelas pessoas que esto
pagando por ele. Verificao e Validao (V&V) o nome dado a esta checagem e processo de
analise. Verificao e Validao no so a mesma coisa. A explicao mais sucinta entre as duas
pode se dar atravs de duas questes:
Validao: Estamos construindo o produto certo?
Verificao: Estamos construindo de maneira certa, o produto?
Talvez quando voc checar isso, encontre especificaes funcionais e requerimentos no
funcionais. Validao um processo mais generalizado.
O objetivo da validao garantir que o sistema do software satisfaa as expectativas dos
clientes. O objetivo final da verificao e validao e estabelecer que o software esta enquadrado
dentro da proposta. Isso significa que o sistema deve ser bom o suficiente para seu uso
pretendido.
De acordo com Sommerville existem trs critrio para validar o software:
1-Funo do Software: O nvel de confiana exigido dependes de quo crtico o software de uma
organizao. Por exemplo, o nvel de confiana necessrio para o software que usado para
controlar um sistema de segurana crtica muito maior do que o exigido para um sistema
prottipo de software que foi desenvolvido para demonstrar algumas idias novas.
2 - Expectativas dos usurios. uma triste reflexo sobre a indstria de software que muitos
usurios tm baixas expectativas de seu software e no so surpreendidos quando ele falha
durante o uso. Eles esto dispostos a aceitar estas falhas do sistema, quando os benefcios do
uso compensam as desvantagens. No entanto, a tolerncia de falhas no sistema do usurio tem
vindo a diminuir desde 1990. As empresas de software devem dedicar mais esforos verificao
e validao.
3 - Ambiente de marketing. Quando um sistema comercializado, os vendedores do sistema deve
levar em conta programas concorrentes, o preo que os clientes esto dispostos a pagar por um
sistema e os prazos requeridos para a entrega desse sistema. Quando uma empresa tem poucos
concorrentes, pode decidir lanar um programa antes que ele tenha sido totalmente testado e
depurado, porque eles querem ser o primeiro no mercado. Quando os clientes no esto
dispostos a pagar preos altos por software, eles podem estar dispostos ter mais tolerancia a
falhas de software. Todos esses fatores devem ser considerados ao decidir quanto esforo deve
ser gasto no processo de V & V.
Existem duas abordagens a serem consideradas do processo de validao e verificao, so elas:
1

- Inspees de software ou de reviso de pares.

Analisar e controlar as representaes do sistema, com o documento de requisitos, diagramas

de design e o cdigo fonte do programa. Voc pode usar as inspeces em todas as fases do
processo. As inspees podem ser complementadas por uma anlise automtica do codigofonte de um sistema ou documentos associados. Inspees de software e anlise
automatizada, so as tcnicas de V & V esttica, pois voc no precisa executar o software
em um computador.
2

- Teste de software.

Envolve a execuo como a implementao do software com dados de teste. Voc examina
os resultados do software e seu comportamento Operacional para verificar que ele est
executando, conforme a necessidade. Teste uma tcnica dinmica de verificao e
validao.
Apesar de inspees de software serem agora amplamente utilizados, o teste do programa
ser sempre, a verificao do software e tcnica de validao. Testar, envolve o uso do
programa, utilizando dados reais, processados pelo programa. Voc descobre os defeitos do
programa ou insuficincias, examinando as sadas do programa, procura de anomalias.
Existem dois tipos de testes que podem ser utilizados em diferentes fases do processo de
software:
1 - teste de validao. Pretende mostrar que o software o que o cliente quer que ele
atenda os requisitos. Como parte do teste de validao, voc pode utilizar testes estatsticos
para testar o desempenho dos programas e confiabilidade, e verificar como ele funciona em
condies operacionais.
2

- teste de defeito. Destina-se a revelar os defeitos no sistema ao invs de simular a sua

utilizao operacional. O objetivo do teste encontrar defeitos iconsistentes entre um
programa e as suas especificaes.

Teste de validao:
Pretende mostrar que o software atende aos seus requisitos;
Um teste bem sucedido aquele que mostra que um requisito foi adequadamente implementado.
Teste de defeitos:
Testes projetados para descobrir defeitos de sistema;
Um teste de defeitos bem sucedido aquele que reve a presena de defeitos em um sistema.
Teste e debugging
Teste e debugging e de defeitos so processos distintos.Verificao e validao est relacionada
ao estabelecimento da existncia de defeitos em um programa.Debugging est relacionado
localizao e repararao desses defeitos.O debugging envolve a formulao de uma hiptese
sobre o comportamento do programa e o teste dessas hipteses para encontrar o defeito de
sistema.
Inspees de software
Envolvem pessoas que examinam uma representao original com o objetivo de descobrir
anomalias e defeitos.Inspees no requerem a execuo de um sistema, por isso, podem ser
usadas antes da implementao.Podem ser aplicadas em qualquer representao do sistema
(requisitos, projeto, dados de configurao Tm se mostrado uma tcnica efetiva para descobrir
erros de programa.
dados de teste, etc.).
Sucesso das inspees
Muitos defeitos diferentes podem ser descobertos em uma nica inspeo. Em teste, um defeito
pode mascarar um outro, por isso, vrias execues so necessrias. Domnio de reuso e
conhecimento de programao de modo que os revisores tm maior probabilidade de j terem
visto os tipos de erros que normalmente surgem.

Inspees e testes
Inspees e testes so complementares, e no tcnicas de verificao opostas. Ambos devem ser
usados durante o processo de V & V. Ass inspees podem verificar a conformidade com uma
especificao, mas no a conformidade com os requisitos reais do cliente. As inspees no
podem verificar caractersticas no funcionais, tais como desempenho, usabilidade, etc.
Inspees de programa
Abordagem formalizada para revises de documentos. Voltadas explicitamente para deteco de
defeitos (no correo). Defeitos podem ser erros lgicos, anomalias no cdigo que poderiam
indicar uma condio errnea (por exemplo, uma varivel no iniciada) ou no conformidade com
padres.
Apesar do sucesso das inspeces, que provou ser difcil a introduo de inspees formais em
muitas organizaes de desenvolvimento de software.
Os engenheiros de software com experincia em programa de testes s vezes so relutantes em
aceitar que as inspees podem ser mais eficazes para deteco de defeitos de testes.
Os gerentes so suspeito porque as inspees requerem custos adicionais durante a concepo e
desenvolvimento. Eles no desejam ter mais risco ainda, de que no haver nenhum programa
de testes correspondentes ao oramento. No h dvida de que as inspeces "front-load de
software V & V" custam e resultam em reduo de custos somente aps as equipes de
desenvolvimento, aplicarem a experincia no seu uso. Alm disso, existem os problemas prticos
da organizao de inspeces: Inspees precisam de tempo para organizar e parece atrasar o
processo de desenvolvimento. difcil convencer um gerente duramente pressionado que esse
tempo pode ser feito mais tarde, porque menos tempo ser gasto na depurao do programa.
Abaixo segue um esquema que representa as principais etapas do processo de inspeo do
codigo-font.

Acontecem frequentemente falhas falhas de so detectadas pela tcnica de inspeo do codigofonte, abixo segue uma tabela exemplificando as pricipais.:
Classe de defeitos

Defeitos nos dados

Defeitos de controle

Checagem de inspeo
Todas as variveis do programa so iniciadas antes de seu uso?
Todas as constantes foram denominadas
O limite superior de vetores deve ser igual ao tamanho do vetor ou ao
tamanho 1?
Se as strings de caracteres so utilizadas, um delimitador
explicitamente designado?
Existe alguma possibilidade de overflow de buffer?
Para cada declarao condicional, a condio est correta?
Cada lao est certo para terminar?

As declaraes compostas esto corretamente entre parnteses?

Em declaraes case, todos os casos so levados em conta?
Se um identificador break requerido aps cada caso em declaraes
case, esse identificador foi includo?

Defeitos de
entrada/sada

Defeitos de interface

Todas as variveis de entrada so utilizadas?

Todas as variveis de sada tem um valor designado antes de sarem?
Entradas inesperadas podem fazer com que os dados sejam
corrompidos?
Todas as chamadas de funes ou mtodos tem o nmero correto de
parmetros?
Os tipos formais e reais de parmetros combinam?
Os parmetros esto na ordem certa?
Se os componentes acessam memria compartilhada, eles tm o mesmo
modelo de estrutura de memria compartilhada?

Defeitos de
Gerenciamento de
armazenamento

Se uma estrutura encadeada modificada, todos os ponteiros foram

corretamente redesignados?
Se o armazenamento dinmico utilizado, foi alocado espao correto?
O espao explicitamente liberado, depois que no mais necessrio?

Defeitos de
gerenciamento de
excees

Todas as possveis condies de erros foram levadas em conta?

Analisador esttico automtico

So softwares que analisam o cdigo-fonte e enviam uma lista de problemas.
Analisadores estticos so ferramentas de software para processamento de texto fonte. Eles
varrem o texto do programa e tentam descobrir condies potencialmente errneas e chamam a
ateno da equipe de V & V. Eles so muito efetivos como um auxlio para as inspees so um
suplemento, mas no um substituto para as inspees.
Segue alguns exemplos de falhas detectveis utilizando-se uma analise esttica automtica.:
Classe de defeitos

Defeitos em dados

Defeitos de controle
Defeitos de
entrada/sada
Defeitos de interface

Checagem da anlise esttica

Variveis utilizadas antes da inicializao
Variveis declaradas, mas nunca utilizadas
Variveis atribudas duas vezes, mas nunca utilizadas entre as
atribuies
Possveis violaes de limites de vetor
Variveis no declaradas
Cdigo inacessvel
Condies que nunca se tornam verdadeiras

Variveis geradas duas vezes sem tarefa de impedimento.

Desacordo quanto ao tipo de parmetro
Desacordo quanto ao nmero de parmetros

No utilizao dos resultados de funes

Funes e procedimentos no chamados
Defeitos de
gerenciamento de
armazenamento

Ponteiros no designados
Aritmtica de ponteiro

Anlise de fluxo de controle:

Verifica loops com mltiplos pontos de sadas ou de entrada, encontra cdigo inacessvel, etc.
Anlise de uso de dados:
Detecta variveis no iniciadas, variveis escritas duas vezes sem uma tarefa de impedimento,
variveis que so declaradas mas nunca usadas, etc.
Anlise de interface:
Verifica a consistncia das declaraes de rotina e procedimentos e seus usos.
Anlise de fluxo de informao:
Identifica as dependncias das variveis de entrada e de sada. No detecta anomalias em si,
mas destaca as informaes para inspeo ou reviso de cdigos.
Anlise de caminho:
Identifica caminhos atravs do programa e estabelece as declaraes executadas naquele
caminho. Novamente, potencialmente til no processo de reviso. Ambos os estgios geram
uma grande quantidade de informaes, por isso, devem ser usados com cuidado.
Uso de anlise esttica - Em C e Java
Particularmente valiosa quando uma linguagem tal como C, que tem tipagem fraca, usada e,
por isso, muitos erros no so detectados pelo compilador. Menos adequado em custo para
linguagens como Java, que tm verificao tipo forte e que pode, portanto, detectar muitos erros
durante a compilao.
Verificao e mtodos formais
Mtodos formais podem ser usados quando uma especificao matemtica do sistema
produzida.Eles so a tcnica fundamental de verificao esttica.Envolvem anlise matemtica
detalhada da especificao, e podem desenvolver argumentos formais que um programa est em
conformidade com a sua especificao matemtica.
Argumentos a favor dos mtodos formais.
A produo de uma especificao matemtica requer uma anlise detalhada dos requisitos, por
isso, a descoberta de erros mais provvel. Podem detectar erros de implementao antes do
teste quando o programa analisado em paralelo com a especificao.
Argumentos contra os mtodos formais.
Requerem notaes especializadas que no podem ser compreendidas por especialistas de
domnio.Desenvolver uma especificao muito dispendioso, mas mais dispendioso mostrar
que um programa atende essa especificao.Pode ser possvel atingir o mesmo nvel de
confiana em um programa mais barato usando outras tcnicas de V & V.

Resumo do Capitulo 23 do livro Engenharia de Software Ian Sommerville - 2007

Teste de software.
Finalmente, aps a entrega do sistema, o cliente pode uma srie de testes de aceitao para verificar
que o sistema executa, conforme especificado.
Este modelo do processo de teste apropriado para desenvolvimento de grandes sistemas, mas para
sistemas menores, ou para sistemas que so desenvolvidos atravs da viso de script ou reutilizao,
h menos etapas distintas no processo.O objetivo da fase de testes componente descobrir os
defeitos atravs de testes componetes programa individual.
Teste de sistema envolve a integrao de dois ou mais componentes que implementam sistema e que
possui funes e, em seguida, testar esse sistema integrado.
O teste de software usado para verificar que requisitos funcionais e no-funcionais foram
devidamente implementados. A limitao dessa abordagem (Teste de Software), entretanto, que
na fase em que ele acontece, muitas vezes difcil de se conseguir alguma qualidade no produto.
Isso porque muitas empresas ainda usam o modelo Waterfall, ou modelo cascata, que foca
justamente a atividade de teste de software somente no final do modelo, ou seja, caso algum
defeito seja encontrado (erros em requisitos, por exemplo) todo ciclo dever ser inicializado
novamente. O teste de software na verdade, foca quase que exclusivamente as atividades de
verificao e validao.
O processo de teste consiste em varios tipos de teste como seguem, explicando cada um.:
Teste de componentes
Teste de componentes individuais de programa, geralmente de responsabilidade do
desenvolvedor do componente (exceto algumas para sistemas crticos), os testes so derivados
da experincia do desenvolvedor.
Teste de sistema
Teste de grupos de componentes integrados para cria um sistema ou um subsistema, a
responsabilidade de uma equipe independente de teste e os testes so baseados em uma
especificao de sistema.
Teste de defeitos
A meta do teste de defeitos descobrir defeitos em programas. Um teste de defeitos bem
sucedido aquele que faz um programa se comportar de uma maneira anmala. Os testes
mostram a presena e no a ausncia de defeitos.
Teste de validao
Utilizado para demonstrar ao desenvolvedor e ao cliente do sistema que o software atende aos
seus requisitos. Um teste bem sucedido mostra que o sistema opera conforme pretendido.
Teste de defeitos
Utilizado para descobrir falhas ou defeitos no software nos locais em que o comportamento no
est correto no est em conformidade com a sua especificao. Um teste bem sucedido
aquele que faz o sistema executar incorretamente e, assim, expor um defeito no sistema.

Somente testes exaustivos podem mostrar que um programa est livre de defeitos. Contudo,
testes exaustivos so impossveis.As polticas de teste definem a abordagem a ser usada na
seleo de testes de sistema:
Todas as funes acessadas por meio de menus devem ser testadas, as combinaes de funes
acessadas por meio dos mesmos menus devem ser testadas, onde as entradas de usurio so
fornecidas, todas as funes devem ser testadas com entradas corretas e incorretas.
Teste de Sistema
Envolve a integrao de dois ou mais componentes para criar um sistema ou subsistema. Pode
envolver o teste de um incremento para ser entregue ao cliente. Duas fases:

Teste de integrao a equipe de teste tem acesso ao cdigo fonte do sistema e o sistema
testado medida que os componentes so integrados.

Teste de releases a equipe de teste testa o sistema completo a ser entregue como uma
caixa-preta.

Diretrizes de teste
Diretrizes so recomendaes para a equipe de teste para auxili-los a escolher os testes que
revelaro defeitos no sistema.
Escolher entradas que forcem o sistema a gerar todas as mensagens de erro;
Projetar entradas que causem overflow dos buffers;
Repetir a mesma entrada ou srie de entradas vrias vezes;
Forar a gerao de sadas invlidas;
Forar resultados de clculo a serem muito grandes ou muito pequenos.
Teste de desempenho
Parte do teste de releases pode envolver teste de propriedades emergentes de um sistema, tais
como desempenho e confiabilidade. Testes de desempenho envolvem, geralmente, o
planejamento de uma srie de testes onde a carga constantemente aumentada at que o
desempenho do sistema se torne inaceitvel.
Teste de estresse
So exerccios do sistema alm de sua carga mxima de projeto. O estresse de um sistema
causa, freqentemente, o surgimento de defeitos ele testa o comportamento de falha, pois os
sistemas no devem falhar catastroficamente. O teste de estresse verifica uma perda inaceitvel
de servio ou de dados e ainda particularmente relevante para sistemas distribudos que podem
exibir degradao severa quando uma rede se torna sobrecarregada.
Teste de componentes
Teste de componente ou unitrio o processo de teste de componentes individuais isolados e
um processo de teste de defeitos. Os componentes podem ser:
Funes individuais ou mtodos de um objeto;

Classes de objeto com vrios atributos e mtodos;

Componentes compostos com interfaces definidas usadas para acessar sua funcionalidade.
Teste de classe de objeto
A abrangncia do teste completo de uma classe envolve:
Teste de todas as operaes associadas com um objeto;
Atribuir e interrogar todos os atributos de objeto;
Exerccio do objeto em todos os estados possveis.
A herana torna mais difcil o projeto de testes de classe de objeto quando as informaes a
serem testadas no so localizadas.
Teste de interfaces
Teste de interfaces projetado para descobrir defeitos nas interfaces dos componentes
compostos.Os objetivos so detectar defeitos devido a erros de interface ou suposies invlidas
sobre interfaces, mas particularmente importante para o desenvolvimento orientado a objetos
quando os objetos so definidos pelas suas interfaces.
Teste baseado em requisitos
Um princpio geral de engenharia de requisitos que os requisitos devem ser testveis. O teste
baseado em requisitos uma tcnica de teste de validao onde voc considera cada requisito e
deriva um conjunto de testes para esse requisito.
Teste de parties
Dados de entrada e resultados de sada caem freqentemente em classes diferentes, onde todos
os membros de uma classe so relacionados e cada uma dessas classes uma partio de
equivalncia ou domnios onde o programa se comporta de maneira equivalente para cada
membro da classe.Casos de teste devem ser escolhidos a partir de cada partio.
Teste estrutural
Algumas vezes chamado de teste caixa-branca a derivao de casos de teste de acordo com a
estrutura do programa. O conhecimento do programa usado para identificar casos de teste
adicionais. O objetivo exercitar todas as declaraes do programa (no todas as combinaes
de caminhos).
Teste de caminho
O objetivo do teste de caminho assegurar que o conjunto de casos de teste tal que cada
caminho pelo programa executado pelo menos uma vez. O ponto de partida do teste de
caminho um fluxograma de programa que mostra os ns que representam as decises do
programa e arcos que representam o fluxo de controle. Declaraes com condies so, portanto,
ns no fluxograma.
Automao de teste
Teste uma fase dispendiosa do processo. Os workbenches de teste fornecem uma variedade de
ferramentas para reduzir o tempo necessrio e os custos totais de teste.Sistemas tais como o
JUnit apiam a execuo automtica de testes.A maioria dos workbenches de teste so sistemas
abertos porque as necessidades de teste so especficas da organizao.Eles so, algumas
vezes, difceis de integrar com workbenches de projeto e anlise fechados.

Adaptao do workbench de testes

Scripts podem ser desenvolvidos para simuladores de interface de usurio e padres para
geradores de dados de teste. Sadas de teste podem ser preparadas manualmente para
comparao. Comparadores de arquivos para propsitos especficos podem ser desenvolvidos.
Uma quantidade significativa de tempo e esforo geralmente necessria para criar uma bancada
de testes exaustivos. Para estes sistemas, os custos de teste geral pode ser de at 50% dos
custos totais de desenvolvimento por isso rentvel investir em suporte de alta qualidade e
ferramentas CASE para o teste. No entanto, como diferentes tipos de sistemas requerem
diferentes tipos de testes de suporte, ferramentas de testes off-the-shelf podem no estar
disponveis.
Concluso:
Os testes podem mostrar a presena de defeitos em um sistema mas eles no podem provar que
no haja defeitos remanescentes. Desenvolvedores de componentes so responsveis pelo teste
de componentes, j o teste de sistema de responsabilidade de uma equipe separada.O teste de
integrao o teste de incrementos do sistema e o teste de release envolve teste de um sistema
a ser liberado para um cliente.Usar experincia e diretrizes para projetar casos de teste em teste
de defeitos.
Teste de interfaces projetado para descobrir defeitos nas interfaces dos componentes
compostos.O particionamento de equivalncia uma maneira de descobrir casos de teste todos
os casos em uma partio devem se comportar da mesma maneira.A anlise estrutural baseia-se
na anlise de um programa e na derivao de testes a partir desta anlise.A automao de testes
reduz os custos pelo apoio ao processo de teste com uma variedade de ferramentas de software.