FISP

Faculdades Integradas de So Paulo

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

Teste de Software

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.

- 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 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?

Defeitos nos dados

Defeitos de controle

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? 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? 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 entrada/sada

Defeitos de interface

Defeitos de Gerenciamento de armazenamento 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 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

Defeitos em dados

Defeitos de controle Defeitos de entrada/sada Defeitos de interface

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.