Você está na página 1de 5

Estudo Dirigido 4 Engenharia de Computao Tpicos 2, Sistemas de Informaes - UFG 2012 Aluno: Andr Campos Rodovalho 064896

Testes de Software
1- O que ? Teste de software o processo de executar programas com o objetivo de encontrar defeitos. Estes erros feitos inadvertidamente podem ter se propagado do projeto ou ser de cunho codificativo. Um projeto bem organizado tem um plano para testes, e sua estratgia desenvolvida pelo gerente de projeto, engenheiros de software ou especialistas em testes. Testes de desenvolvedor focam na verificao, isto , garantir que o software implementa corretamente uma funo especfica. Testes de Reviso de Configurao focam na validao, isto , conferir se os requisitos do cliente foram satisfeitos. 2- Objetivo O desenvolvimento de software utilizando tcnicas e boas prticas em anlise, projeto e codificao no oferecem a total garantia de qualidade do produto obtido, apesar de melhor-la significativamente. Por esta razo, uma etapa fundamental na obteno de um alto nvel de qualidade do software a ser produzido a realizao de procedimentos de teste. O foco evitar transtornos e prejuzos que sero causados caso os erros apaream durante o seu uso, estando implantado. Desgastes certamente acontecero com o cliente nesta situao. Em especial haver imputao de responsabilidade por danos caso falhas causadas pelo software em sistemas crticos (aqueles sistemas dos quais dependem vidas humanas, como controle de voo e a superviso de reatores nucleares) sejam detectadas. No caso de programas com este nvel de sensibilidade, a atividade de teste pode custar de 3 a 5 vezes o valor gasto nas demais atividades de desenvolvimento do software. 3- Premissas de um bom teste Em geral h ferramentas e formas para automatizar todas as tcnicas. Porm isso no elimina o carter subjetivo do que seja software bem testado, j que na maioria das vezes impossvel cobrir todas as quase infinitas possibilidades de dados de entrada, e consequentemente caminhos lgicos a serem atingidos em execuo. Para auxiliar nessas questes foram propostos critrios de teste. Tais critrios podem ser classificados em critrio de seleo e critrio de adequao. Os critrios de seleo auxiliam a escolher os casos de teste que tenham uma maior probabilidade de revelar defeitos. Os critrios de adequao estabelecem predicados que devem ser satisfeitos para que a atividade de teste seja considerada satisfatria ou mesmo encerrada.

A escolha do subconjunto de dados a ser utilizado para o teste pode ser feita com base em aspectos estruturais do software (obtido a partir do cdigo-fonte) ou em aspectos funcionais (a partir da especificao do programa).

Figura 1 Auditoria de Software

Um aspecto de importncia no processo de validao a chamada reviso de configurao. Ela consiste em garantir que todos os elementos de configurao do software tenham sido adequadamente desenvolvidos e catalogados corretamente com todos os detalhes necessrios que devero servir de apoio fase de manuteno do software. Esta reviso, algumas vezes denominada auditoria, est ilustrada na Figura 1. 4- Tcnicas de Testes Uma primeira diviso que pode ser estabelecida em relao ao teste de software corresponde forma de utilizao do cdigo obtido na etapa de implementao (ou codificao). Segundo esta tica, pode-se organizar os testes em estticos e dinmicos. Os testes estticos so aqueles realizados sobre o cdigo fonte do software, utilizando como tcnica bsica a inspeo visual. Este tipo de teste de simples implementao, uma vez que no h necessidade de execuo do programa para obter-se resultados. Os testes dinmicos so os procedimentos baseados na execuo do cdigo objeto (binrio ou equivalente) do programa, sendo esta execuo realizada com base em subconjuntos de dados o jogo de teste. 4.1 Teste Estrutural ou Caixa Branca Tambm chamado teste orientado lgica, a tcnica avalia o comportamento interno e detalhes procedimentais do componente de software. Essa tcnica trabalha diretamente sobre o cdigo fonte do componente de software para avaliar aspectos tais como: teste de condio, teste de fluxo de dados, teste de ciclos, teste de caminhos lgicos, cdigos nunca executados. Os caminhos lgicos definidos no software so exaustivamente testados, pondo prova conjuntos bem definidos de condies ou laos. Durante o teste, o status do programa pode ser examinado diversas vezes para eventual comparao com condies de estado esperadas para aquela situao.

Apesar da importncia do teste de caixa branca, no se deve guardar a falsa ideia de que a realizao de testes de caixa branca num produto de software vai oferecer a garantia de 100% de correo deste ao seu final. Isto porque, mesmo no caso de programas de pequeno e mdio porte, a diversidade de caminhos lgicos pode atingir um nmero bastante elevado, representando um grande obstculo para o sucesso completo desta atividade. 4.2 Teste Funcional ou Caixa Preta Quando se fala em teste Caixa Preta de software, refere-se a todo teste que implica na verificao do funcionamento do software atravs de suas interfaces, o que, geralmente, permite verificar a operacionalidade de todas as suas funes. Tambm chamado teste orientado a dado ou orientado a entrada e sada, a tcnica avalia o comportamento externo do componente de software, sem se considerar o comportamento interno do mesmo. Dados de entrada so fornecidos, o teste executado e o resultado obtido comparado a um resultado esperado previamente conhecido. Como detalhes de implementao no so considerados, os casos de testes so todos derivados da especificao. Quanto mais entradas so fornecidas, mais rico ser o teste. Numa situao ideal todas as entradas possveis seriam testadas, mas na prtica isso impossvel. 4.3 Teste Baseado em Erros A tcnica de teste baseada em defeitos utiliza certos tipos de defeitos conhecidos e comuns para derivar requisitos de teste. O foco dessa abordagem est nos possveis erros que o programador ou projetista podem cometer durante o desenvolvimento do software, e que so manjados j que muitas vezes eles se repetem independente de quem codifica. Erro causado pela diviso por zero um exemplo de erro manjado. Semeadura de Erros e Anlise de Mutantes so dois critrios tpicos dessa tcnica. Os casos de teste gerados so especficos para demonstrar a presena ou ausncia dos defeitos. 4.4 Teste Alfa e Beta Apesar do esforo na validao de um software, na maioria das vezes extremamente difcil para o desenvolvedor prever as diferentes maneiras como o software ser utilizado. Principalmente no caso de softwares interativos, os usurios muitas vezes experimentam comandos e entradas de dados as vezes no previstos, o que pode ser um verdadeiro atentado robustez de um sistema. Da mesma forma, dados de sada ou formatos de apresentao de resultados podem parecer timos para o analista, mas completamente inadequados para o usurio. Quando um software construdo sob demanda, uma bateria de testes de aceitao envolvendo o cliente conduzida. A durao dos testes de aceitao pode variar entre algumas semanas e vrios meses, dependendo da complexidade ou natureza da aplicao. No caso de um software de prateleira, ou outros que so destinados utilizao por um grande conjunto de usurios, os editores de software fazem uso de um processo

denominado teste alfa e teste beta. Os testes alfa so realizados com um cliente, ou numa amostra de clientes, sendo realizado nas instalaes do desenvolvedor do software. O software utilizado num ambiente controlado, o desenvolvedor observa o comportamento do cliente e registra as anomalias detectadas durante a utilizao. J os testes beta so conduzidos em uma ou mais instalaes do cliente pelo usurio final do software. Neste caso, praticamente impossvel haver um controle da parte do desenvolvedor sobre os erros encontrados. Estes normalmente so registrados pelo prprio usurio e encaminhados ao desenvolvedor na forma de um relatrio escrito. 4.5 Teste de Recuperao Neste tipo de teste, o objetivo observar a capacidade do sistema para recuperar-se da ocorrncia de falhas, num tempo previamente determinado. Em alguns casos (cada vez mais frequentes), exige-se que o sistema seja tolerante a falhas, ou seja, que nele seja previsto processamento que permita retomar seu funcionamento mesmo no caso de ocorrncia de algumas falhas. Neste tipo de teste, falhas so provocadas artificialmente (por injeo de falhas), de modo a analisar a capacidade do sistema do ponto de vista da recuperao. Os valores de tempo exigido para recuperao do sistema (seja por ao automtica ou devido interveno de um operador humano) devem ser registrados e confrontados aos valores especificados. 4.6 Teste de Segurana O teste de segurana visa garantir que o sistema no vai provocar danos irrecuperveis ou expor brechas sua regra de negcios. Por exemplo, num sistema de informao acadmica, um aluno deve ter acesso s notas obtidas nas disciplinas que cursou (histrico escolar), mas no deve ter a possibilidade de alterar seus valores. No teste de segurana, o analista deve desempenhar um papel semelhante ao de um cracker, tentando contornar todos os mecanismos de segurana implementados no mesmo. As aes a experimentar so as mais diversas: Derrubar o sistema como um todo. Acessar informaes confidenciais. Modificar informaes na bases de dados. Interferir no funcionamento do sistema. Introduzir vrus de computador no sistema. Sobrecarregar o sistema pela multiplicao de processos executados e etc.

4.7 Teste de Estresse O teste de estresse, como o nome indica, consiste em verificar como o sistema vai se comportar em situaes limite. Este limite pode ser verificado sob diferentes pontos de vista, dependendo das caractersticas do software. Alguns aspectos que podem ser observados neste contexto so: Limite em termos de quantidade de usurios conectados a um determinado

sistema servidor. Quantidade de utilizao de memria. Uso em diferentes verses de processadores. Quantidade de bloqueios encontrados num dado perodo de utilizao.

4.8 Teste de Desempenho Este tipo de teste consiste em verificar se os requisitos de desempenho esto sendo atendidos para o sistema como um todo. Este aspecto, torna-se crtico em aplicaes envolvendo sistemas embarcados e sistemas multimdias, que pertencem classe dos sistemas tempo-real. Nestes sistemas, o no atendimento a um requisito de tempo pode afetar de forma irreversvel a funo do sistema e, no caso de alguns sistemas (os chamados sistemas crticos), a no realizao desta funo ou o no atendimento a estes requisitos temporais pode resultar em prejuzos catastrficos (risco a vidas humanas ou grandes prejuzos financeiros). Os testes de desempenho so realizados, geralmente, com o auxlio de instrumentao de hardware e de software que permitam medir como os recursos do sistema esto sendo utilizados. O uso da instrumentao pode facilitar a coleta de dados e o registro de status do sistema nos seus diferentes pontos de funcionamento. 4.9 Teste Baseado em Mquinas de Estados Finitos geralmente utilizado para testar sistemas embarcados, protocolos de comunicao, sistemas de telecomunicaes e outros Sistemas Reativos, enfim; sistemas em que a especificao pode ser modelada como uma MEF (Mquina de Estados Finitos). O teste baseado em MEF consiste na gerao de um conjunto de casos de teste que consiga encontrar o mximo de defeitos possvel em uma implementao. Com isso, possvel verificar se a implementao da MEF est ou no de acordo com sua especificao. Dessa forma, o teste baseado em MEF considera que tanto a especificao quanto a implementao sejam modeladas por uma MEF. Assim, a implementao contm um defeito no caso em que possuir um comportamento diferente em relao especificao. Os defeitos podem ser dos seguintes tipos: Defeito de Inicializao: quando o estado inicial no o correto. Defeito de Transferncia: quando o estado atingido por uma transio no o correto. Defeito de Sada: quando a sada gerada por uma transio no a correta. Estados Faltantes: quando os estados da implementao precisam ser aumentados para torn-la equivalente especificao. Estados Extras: quando os estados da implementao precisam ser reduzidos para torn-la equivalente especificao.