Pré-visualização parcial do texto
Baixe tipos de testes de software e outras Notas de estudo em PDF para Informática, somente na Docsity!
Cap. 18 Técnicas de teste de software 791 18.1.3 PROJETO DE CASOS DE TESTE O projeto de teste de software e de outros produtos trabalhados por engenha- ria pode ser tão desafiador quanto o projeto inicial do próprio produto. Contudo, por razões que já foram discutidas, os engenheiros de software muitas vezes tratam a atividade de teste como uma reflexão tardia, desen- volvendo casos de teste que podem “parecer certos”, mas que apresentam pouca garantia de estar completos. Relembrando os objetivos da atividade de teste, devemos projetar testes que tenham a mais alta probabilidade de descobrir a maioria dos erros com uma quantidade mínima de tempo e esforço. No decorrer da década passada, uma variedade rica de métodos de projeto de casos de teste evoluiu para software. Esses métodos oferecem ao desenvolvedor uma abordagem sistemática ao teste. O que é mais importan- te, os métodos oferecem um mecanismo que ajuda a garantir a integridade do teste e proporciona a mais alta probabilidade de revelar erros no software. Qualquer produto (e muitas outras coisas) trabalhado por engenha- ria pode ser testado de duas maneiras: (1) conhecendo-se a função específica que um produto projetado deve executar, testes podem ser realizados para demonstrar que cada função é totalmente operacional; (2) conhecendo-se o funcionamento interno de um produto, testes podem ser realizados para garantir que “todas as engrenagens se encaixam”, ou seja, que a operação interna do produto tem um desempenho de acordo com as especificações e que os componentes internos foram adequadamente postos à prova. A pri- meira abordagem de teste é chamada teste de caixa preta (black box) e a segunda, teste de caixa branca (white box). Quando se considera o software de computador, a expressão teste de caixa preta refere-se aos testes que são realizados nas interfaces do software. Não obstante eles sejam projetados com o propósito de descobrir erros, os testes de caixa preta são usados para demonstrar que as funções do software são operacionais; que a entrada é adequadamente aceita e a saída é correta- mente produzida; que a integridade das informações externas (por exemplo, arquivos de dados) é mantida. Um teste de caixa preta examina alguns aspectos de um sistema sem se preocupar muito com a estrutura lógica interna do software. O teste de caixa branca do software baseia-se num minucioso exame dos detalhes procedimentais. Os caminhos lógicos através do software são testados, fornecendo-se casos de teste que põem à prova conjuntos específicos 792 Engenharia de Software Cap. 18 de condições e/ou laços. O “status do programa” pode ser examinado em vários pontos para determinar se o status esperado ou estabelecido corres- ponde ao status real. Numa primeira observação, poderia parecer que um teste de caixa branca efetuado muito cuidadosamente levaria a “100% de programas corre- tos”. Tudo o que precisamos fazer é definir todos os caminhos lógicos, desenvolver os casos de teste para pô-los à prova e avaliar os resultados, ou seja, gerar os casos de teste para pôr à prova exaustivamente a lógica de programa. Infelizmente, testes exaustivos apresentam certos problemas logísticos. Porque, mesmo para pequenos programas, o número de caminhos lógicos possíveis pode ser muito grande. Por exemplo, considere o fluxograma mostrado na Figura 18.2. O projeto procedimental ilustrado pelo fluxograma poderia corresponder a um programa PASCAL de 100 linhas com um único laço que pode ser executado não mais do que 20 vezes. Há aproximadamente 1014 caminhos que podem ser executados! 19 ce Lo] o ce (O) r Laço = 20 vezes Figura 18.2 Problemas com os testes exaustivos. 794 Engenharia de Software Cap. 18 * Erros lógicos e pressuposições incorretas são inversamente propor- cionais à probabilidade de que um caminho (path) de programa seja executado. Erros tendem a se infiltrar em nosso trabalho quando projetamos e implementamos funções, condições ou con- troles que estejam fora da função principal. O processamento cotidiano tende a ser bem entendido (e bem esmiuçado), enquanto o processamento de um “caso especial” tende a “cair por terra”. * Muitas vezes acreditamos que um caminho lógico não tem a probabilidade de ser executado quando, de fato, ele pode ser executado regularmente. O fluxo lógico de um programa às vezes é contra-intuitivo, querendo isso dizer que nossas pressuposições inconscientes sobre o fluxo de controle e de dados podem levar-nos a cometer erros de projeto que são descobertos somente quando se inicia a atividade de teste do caminho. - Erros tipográficos são aleatórios. Quando um programa é tradu- zido para código-fonte de linguagem de programação, é provável que alguns erros de digitação ocorram. Muitos deles serão desco- bertos por mecanismos de verificação de sintaxe, mas outros passarão sem ser detectados até que os testes se iniciem. E provável que exista um erro tipográfico tanto num caminho lógico obscuro como num caminho da corrente principal. Cada uma dessas razões oferece um argumento para a realização de testes da caixa branca. Os testes de caixa preta, não importa quão cuidadosos sejam, podem não revelar os tipos de erros observados anteriormente. Con- forme Beizer declarou [BEI90]: “Os bugs escondem-se pelos cantos e congre- gam-se nas fronteiras”. Os testes de caixa branca têm maior probabilidade de descobri-los. 18.3 TESTE DE CAMINHO BÁSICO O teste de caminho básico é uma técnica de teste de caixa branca inicialmente proposta por Tom McCabe [MCCT76]. O método de caminho básico possibilita que o projetista do caso de teste derive uma medida da complexidade lógica 816 | Engenharia de Software Cap. 18 18.5 TESTE DE CAIXA PRETA Os métodos de teste de caixa preta concentram-se nos requisitos funcionais do software. Ou seja, esse teste possibilita que o engenheiro de software derive conjuntos de condições de entrada que exercitem completamente todos os requisitos funcionais para um programa. O teste de caixa preta não é uma alternativa para as técnicas de caixa branca. Ao contrário, trata-se de uma abordagem complementar que tem a probabilidade de descobrir uma classe de erros diferente daquela dos métodos de caixa branca. O teste de caixa preta procura descobrir erros nas seguintes catego- rias: (1) funções incorretas ou ausentes; (2) erros de interface; (3) erros nas estruturas de dados ou no acesso a bancos de dados externos; (4) erros de desempenho; e (5) erros de inicialização e término. Ao contrário do teste de caixa branca, que é executado cedo no processo de teste, o teste de caixa preta tende a ser aplicado durante as últimas etapas da atividade de teste (veja o Capítulo 19). Uma vez que o teste de caixa preta deliberadamente desconsidera a estrutura de controle, a atenção se concentra no domínio de informação. Testes são projetados para responder às seguintes perguntas: Como a validade funcional é testada? * Quais classes de entrada constituirão bons casos de teste? * O ssistema é particularmente sensível a certos valores de entrada? * Como as fronteiras de uma classe de dados são isoladas? Quais índices de dados e volumes de dados o sistema pode tolerar? * Que efeito terão combinações específicas de dados sobre a opera- ção do sistema? Ao aplicar técnicas de caixa preta, derivamos um conjunto de casos de teste que satisfaz aos seguintes critérios [MY E79]: (1) casos de teste que reduzem, numa contagem que seja maior que 1, o número de casos de teste adicionais que devem ser projetados para se conseguir testes razoáveis; e (2) casos de teste que nos dizem algo sobre a presença ou ausência de classes de erros, em vez de um erro associado somente ao teste específico que se tem em mãos. 818 Engenharia de Software Cap. 18 Código de área: em branco ou número de três dígitos. Prefixo: número de três dígitos que não se iniciam por 0 ou 1. Sufixo: número de quatro dígitos. Senha: valor alfanumérico de seis dígitos. Comandos: “cheque”, “depósito”, “pagamento de conta” etc. As condições de entrada, associadas a cada elemento de dados para a aplicação bancária, podem ser especificadas como: Código de | condição de entrada, booleana — o código de área pode área: ou não estar presente; condição de entrada, intervalo — os valores definidos entre 200 e 999, com exceções (por exemplo, nenhum valor > 905) e requisitos (por exemplo, todos os códigos de área têm 0 ou 1 como segundo dígito) específicos. Prefixo: condição de entrada, intervalo — valor especificado > 200. Sufixo: condição de entrada, valor — extensão de quatro dígi- tos. Senha: condição de entrada, booleana — uma senha pode ou não estar presente. condição de entrada, valor — string de seis caracteres. Comando: — condição de entrada, conjunto — contendo os comandos anotados acima. Aplicando-se as diretrizes para a derivação de classes de equivalên- cia, os casos de teste para cada item de dados do domínio de entrada poderiam ser desenvolvidos e executados. Os casos de teste são selecionados de forma que o maior número de atributos de uma classe de equivalência seja exerci- tado de uma só vez. Cap. 18 Técnicas de teste de software 829 18.8 RESUMO O objetivo principal do projeto de casos de teste é derivar um conjunto de testes que tenha uma alta probabilidade de revelar defeitos no software. Para atingir esse objetivo, duas categorias diferentes de técnicas de projeto de casos de teste são usadas: o teste de caixa preta e o teste de caixa branca. Os testes de caixa branca focalizam a estrutura de controle do programa. Os casos de teste são derivados para garantir que todas as instruções do programa tenham sido exercitadas pelo menos uma vez duran- te os testes e que todas as condições lógicas tenham sido exercitadas. Os testes de caminho básico, uma técnica de caixa branca, faz uso de grafos de programa (ou matrizes de grafo) para derivar o conjunto de testes linearmen- te independentes que garantirá cobertura. Os testes de fluxo de dados e das condições póem à prova a lógica do programa, e os testes de laços comple- mentam outras técnicas de caixa branca ao proporcionar um procedimento para exercitar laços de vários graus de complexidade. Hetzel [HET84] descreve os testes de caixa branca como “testes em pequeno porte” (testing in the small). A implicação dessa colocação é que os testes de caixa branca que consideramos neste capítulo são tipicamente aplicados a componentes de programa pequenos (por exemplo, módulos ou pequenos grupos de módulos). Os testes de caixa preta, por outro lado, ampliam o nosso foco e poderiam ser denominados “testes em grande porte” (testing in the large). Os testes de caixa preta são projetados para validar os requisitos funcionais, sem se preocupar com o funcionamento interno de um programa. As técnicas de teste de caixa preta concentram-se no domínio de informações do software, derivando os casos de teste ao dividir a entrada e a saída de uma maneira que proporcione uma satisfatória cobertura de teste. O particiona- mento de equivalência divide o domínio de entrada em classes de dados que provavelmente exercitarão uma função de software específica. A análise do valor de fronteira prova a capacidade que um programa tem de manipular dados nos limites da aceitabilidade. O grafo de causa-efeito é uma técnica que possibilita que o analista valide conjuntos complexos de ações e condições. 
