300 Capítulo 8 Testando os Programas

como as estratégias top-down e hottom-up, e outras estratégias no nível da integração. O plano resultante para com-
binar os componentes em um só, algumas vezes, é chamado de plano de integração do sistema.
Para cada estágio de teste, o plano descreve em detalhes os métodos a serem utilizados para realizar cada
teste. Por exemplo, o teste de unidade pode ser composto de walkthroughs informais ou de inspeções formais,
seguidas pela análise da estrutura do código, e então, pela análise do desempenho real do código. O plano identi-
fica qualquer apoio automatizado, incluindo as condições necessárias para a utilização da ferramenta. Essa infor-
mação ajuda a equipe de teste a planejar suas atividades e a agendar os testes.
Uma lista detalhada de casos de teste acompanha cada método ou técnica de teste. O plano também explica
como os dados de teste serão gerados e como quaisquer dados de saída ou informações de estado serão obtidos. Se
um banco de dados for utilizado para acompanhar os testes, os dados e a saída, o banco de dados e seu uso tam-
bém serão descritos.
Consequentemente, à medida que lemos o plano de testes, temos um quadro completo de como e por que os
testes serão realizados. Ao escrevermos os planos de testes à medida que projetamos o sistema, somos obrigados
a entender os objetivos gerais do sistema. Na verdade. algumas vezes, a perspectiva dos testes nos encoraja a ques-
tionar a natureza do problema e se o projeto é apropriado.
Muitos clientes especificam o conteúdo dos planos de testes na documentação de requisitos. Por exemplo,
quando um sistema está sendo construido, o Departamento de Defesa dos EUA fornece os padrões de documenta-
ção de sistemas ao desenvolvedor. Os padrões explicam que o plano de testes:
é uma ferramenta para orientar... O teste, que contém o cronograma dos eventos e a lista de materiais necessários para efetuar
um teste amplo de um sistema de dados automatizado completo. As partes do documento dirigidas ao pessoal de recursos huma-
nos devem ser apresentadas em uma linguagem que não seja técnica, e as partes voltadas ao pessoal de operação deverão ser
apresentadas com terminologia apropriada (Departamento de Defesa dos EUA, 1977).

Investigaremos os detalhes desse exemplo de plano de testes, no Capítulo 9.

8.7 FERRAMENTAS AUTOMATIZADAS DE TESTE

Existem muitas ferramentas automatizadas para nos ajudar a testar os componentes do código, e já mencio-
namos várias delas neste capítulo, tais como os provadores de teoremas c as ferramentas de execução simbólica,
Mas, em geral, existem diversos pontos no processo de teste em que as ferramentas são úteis, se não essenciais.

Ferramentas para análise de código

Há duas categorias de ferramentas para análise de código. A análise estática é realizada quando o programa
não está sendo executado; a análise dinâmica é feita quando o programa está sendo executado. Cada tipo de fer-
ramenta fornece informações sobre o código em si ou sobre o caso de teste que está sendo executado.
Análise estática. Diversas ferramentas podem analisar um programa-fonte antes que ele seja executado. As
ferramentas que investigam a correção de um programa ou do conjunto de componentes podem ser agrupadas em
quatro tipos:
1. Analisador de código: a sintaxe dos componentes é avaliada automaticamente. Os comandos podem
ser ressaltados, se a sintaxe estiver errada, se uma construção tende a apresentar defeitos, ou se um item
não foi definido.
2. Verificadores de estrutura: essa ferramenta gera um grafo dos componentes submetidos como entra-
da. O grafo retrata o fluxo lógico, e a ferramenta verifica problemas estruturais.
3. Analisador de dados: a ferramenta revê as estruturas de dados, as declarações de dados e as interfaces
entre os componentes, e registra os links impróprios entre os componentes, definições de dados em con-
flito e uso ilegal de dados.
4. Verificador de sequência: a ferramenta verifica as sequências de eventos. Se a codificação estiver na
sequência cerrada, os eventos são ressaltados.
Por exemplo, um analisador de código pode gerar uma tabela de símbolos para registrar onde uma variável é
primeiro definida e quando ela é utilizada, apoiando estratégias de teste, tais como o teste definição-uso. De manei-
ra semelhante, um verificador de estrutura pode ler um programa e determinar a localização de todos os /o0ps. mar-
 Seção 8.7 Ferramentas Automatizadas de Teste 301

car comandos que nunca são executados, notar a presença de ramificações do meio de um /o0p, e assim por dian-
te. Um analisador de dados pode notificar quando um denominador pode ter o valor zero, Ele também pode veri-
ficar se os argumentos de uma sub-rotina são fornecidos da maneira conveniente. Os componentes de entrada €
saida de um sistema podem ser submetidos a um verificador de sequência, a fim de determinar se os eventos estão
codificados na sequência apropriada, Por exemplo, um verificador de sequência pode assegurar que todos os arqui-
vos são abertos antes de serem modificados.
Características estruturais e medições estão incluídas na saida de muitas ferramentas de análise estática, de
modo que possamos entender melhor os atributos do programa. Por exemplo, os grafos de fluxo são frequentemen-
te suplementados com uma lista de todos os caminhos possíveis ao longo do programa, permitindo planejar os
casos de teste para o de caminhos. Também recebemos informações sobre o fan-in e fan-out, o número de opera-
dores e operandos em um programa. o número de pontos de decisão c as diversas medidas da complexidade estru-
tural do código. Na Figura 8.18, vemos um exemplo de saída a partir de um programa de análise estática, que com-
para os achados de uma parte especifica do código com as informações históricas contidas em um grande banco
de dados. A comparação envolve não somente as medições, tais como profundidade de aninhamento. acoplamen-
to e número de decisões, mas também informações sobre os potenciais defeitos c variáveis não inicializadas.
Informações como essas alertam sobre a facilidade de realizar testes e sobre possíveis defeitos que podemos que-
rer remover antes que os testes formais sejam iniciados.
Análise dinâmica. Muitas vezes, os sistemas são dificeis de serem testados, porque diversas operações para-
lelas são realizadas simultancamente, Essa situação é especialmente verdadeira para os sistemas de tempo-rcal,
Nesses casos, é dificil prever as condições e gerar casos de teste que sejam representativos. As ferramentas auto-
matizadas possibilitam que a equipe de testes obtenha os estados dos eventos durante a execução do programa, pre-
servando a visualização das condições. Essas ferramentas são, algumas vezes, chamadas de monitores de progra-
ma, porque observam ce relatam o comportamento do programa.
Um monitor pode mostrar o número de vezes que um componente é chamado ou que uma linha de código é
executada. Essas estatísticas informam aos usuários sobre a cobertura de comandos ou de caminhos de seus casos
de teste, De modo semelhante, um monitor pode relatar se um ponto de decisão é ramificado em todas as direções.
fornecendo, assim, informações sobre a cobertura de ramificação, Estatisticas resumo também são relatadas, for-
necendo uma visão de alto nivel da porcentagem de comandos, caminhos e sentenças cobertos pelo conjunto de
casos de teste executados. Essas Informações são importantes quando os objetivos de teste são declarados em ter-
mos de cobertura. Por exemplo, foi exigido, sob contrato, que o sistema de controle de tráfego aéreo de Londres
tivesse 100 por cento de cobertura dos comandos em seus testes (Pfleeger e Hatton, 1997).
Informações adicionais podem ajudar a equipe de testes a avaliar o desempenho do sistema. Estatisticas
podem ser geradas sobre variáveis específicas: por exemplo, seu primeiro valor, último valor, minimo e máximo.
Os pontos de interrupção podem ser definidos no sistema, de modo que quando uma variável se mantém ou exce-
de certo valor, a ferramenta de teste relata a ocorrência. Algumas ferramentas param quando os pontos de interrup-
ção são atingidos, permitindo que o responsável pelo teste examine o conteúdo da memória ou os valores de itens
de dados específicos. Algumas vezes, é possível modificar os valores à medida que o teste progride.

Defeitos em linha |»
o

Defeitos de interface
ooo o

Aninhamento
YW

Decisões
VV

Caminhos

Variáveis não iniciadas

VV

Acoplamento extemo
-

Ruim Médio Bom

FIGURA 8.18 Saída da análise estática.
302 Capítulo 8 Testando os Programas

Para sistemas de tempo-real, a obtenção de tantas informações quantas forem possíveis sobre um estado ou
uma condição específica, durante a execução, pode ser utilizada depois da execução, a fim de fomecer mais infor-
mações sobre o teste. O fluxo de controle pode ser rastreado “para trás” ou “para frente”, a partir de pontos de inter-
rupção, e a equipe de testes pode examinar as mudanças de dados que ocorrem.

Ferramentas para execução de testes

As ferramentas que descrevemos até agora tinham o foco no código. Outras ferramentas podem ser utiliza-
das para automatizar o planejamento e a execução de testes. Devido ao tamanho e à complexidade da maioria dos
sistemas atuais, as ferramentas automatizadas para a execução de testes são essenciais para lidar com números
muito grandes de casos de teste, que devem scr exccutados para testar totalmente um sistema.
Captura e repetição. Quando os testes são planejados, a equipe deve especificar, em um caso de teste, que
entrada scrá fornecida c qual o resultado esperado a partir das ações testadas. As ferramentas de captura e repe-
tição capturam as teclas digitadas, as entradas e respostas, à medida que o teste está sendo executado, e compara
a saída real com a que é esperada. As discrepâncias são relatadas à equipe de testes, e os dados capturados ajudam
a equipe a rastreá-las até chegar às suas raízes. Esse tipo de ferramenta é especialmente útil depois que um defei-
to foi encontrado c corrigido; cla pode scr utilizada para verificar sc a solução apresentada realmente corrigiu o
defeito, sem introduzir outros defeitos no código.
Stubs e drivers. Vimos, anteriormente, a importância dos stubs c dos drivers no teste de integração, Existem
ferramentas comerciais disponíveis para auxiliar na geração de stubs e drivers. Mas os drivers de teste podem ser
mais do que simplesmente um programa para exercitar um componente específico. O driver pode:
1. definir todas as variáveis de estado apropriadas à preparação de determinado caso de teste e. então, exe-
cutar o caso de teste
2. simular a inserção de dados pelo teclado e outras respostas a condições relacionadas a dados
3. comparar o verdadeiro resultado com a saída esperada e relatar as diferenças
4. rastrear quais caminhos foram percorridos durante a execução
5. redefinir as variáveis para preparar o novo caso de teste
6. interagir com um pacote de depuração, de modo que os defeitos sejam rastreados e corrigidos durante
o teste, se isso for desejado

Ambientes automatizados de teste. As ferramentas para execução de testes podem ser integradas com
outras, a fim de formar um amplo ambiente de testes. Frequentemente, as que descrevemos aqui estão conectadas
a um banco de dados de teste. ferramentas de medição, ferramentas para análise de código, editores de texto e fer-
ramentas de simulação ec modelagem, para automatizar o processo de teste tanto quanto for possível. Por exemplo,
os bancos de dados podem rastrear os casos de teste, armazenando os dados de entrada para cada caso, descreven-
do a saída esperada e registrando a verdadeira saida. Contudo, encontrar evidências de um defeito não é o mesmo
que localizar o defeito. O teste sempre envolverá o esforço manual requerido para rastrear um problema até sua
causa original. A automação auxilia, mas não necessariamente substitui essa função humana,

Geradores de casos de teste

O teste depende da definição cuidadosa e completa dos casos de teste. Por essa razão, é útil automatizar parte
do processo de geração de casos de teste. de modo que possamos garantir que nossos casos de teste cubram todas
as situações possiveis. Existem diversos tipos de ferramentas que nos ajudam nesse trabalho. Os geradores de
casos de teste estruturais basciam seus casos de teste na estrutura do código-fonte. Eles listam casos de teste para
os testes de caminhos, de ramificações ou de comandos, e, frequentemente, utilizam heuristicas para ajudar a obter
a melhor cobertura,
Outros geradores de casos de teste têm como basc o fluxo de dados, o teste funcional (ou seja, ao exercitar
todos os estados possíveis que afetam a conclusão de determinada função), ou o estado de cada variável no domi-
nio das entradas. Há outras ferramentas capazes de gerar conjuntos aleatórios de dados de teste, utilizados, na
maioria das vezes, para trabalhar com a modelagem da confiabilidade (como veremos no Capitulo 9).