uso, o que facilitaria (posteriormente) a obtenção da especificação formal a partir dos mesmos requisitos. A plataforma de hardware foi um versão com tecnologia GSM (Global System for
Mobile Communications) [Wik06a] considerada estável. A estabilidade foi importante para
implantação de uma ferramenta de instrumentação de código utilizada para medir a cobertura estrutural e análise de redundância (para mais informações sobre o processo de instrumentação consultar [Soa06]).
6.3.2 Geração da Especificação Formal
A etapa seguinte do estudo, o Passo 2, foi gerar uma especificação formal e definir o processo de comportamento (PC) partindo das especificações de requisitos e casos de uso da aplicação de mensagens escolhida no passo anterior do estudo. Isto foi realizado pela equipe do projeto de pesquisa do CIn-BTC (especializada em linguagem natural) em dois passos. No primeiro passo, a equipe transcreveu manualmente as informações sobre as funcionalidades e comportamentos encontrados na documentação original da aplicação para um formato de inglês padronizado1. Neste formato, as palavras e regras gramaticais são predefinidas e encontram-se todas arma- zenadas em uma base de conhecimento que pode ser enriquecida e ampliada. Os requisitos funcionais são descritos em termos de ações do usuário, estados e respostas do sistema, e clas- sificados em fluxos (principal, alternativos e de exceções). Partindo das descrições em inglês padronizado, no passo seguinte, a ferramenta de processamento de linguagem natural (Figura 6.4 na cor cinza clara) foi empregada para traduzir as referidas descrições para CSP (uma espe- cificação CSP). Desta maneira, cada frase do Inglês padronizado (utilizada para descrever ação do usuário, estado e resposta do sistema) foi convertida em um evento CSP específico.
Uma característica relevante da especificação CSP obtida é que a mesma não lida com va- riáveis (os processos não contêm variáveis). As variações entre os fluxos principal, alternativos e de exceções ocorrem a partir da especificação de diferentes prefixos. Cada partição de equi- valência (ver Análise do Valor Limite na Seção 2.3) dos valores de entradas, saídas e estados do sistema encontrados na especificação em inglês padronizado, se tornou um prefixo diferente da especificação CSP. Devido a esta simplificação, o tamanho do alfabeto da especificação ob- tido foi mais reduzido e menos expressivo em se comparando com um modelo com variáveis explícitas.
A aplicação de mensagens contava com um conjunto grande de testes manuais criados a partir dos requisitos. Estes testes continham muitas informações complementares baseadas na experiência dos testadores e projetistas de teste. Por isto, seria incoerente comparar os testes gerados automaticamente a partir da especificação formal com os testes pré-existentes, pois os últimos continham informações e cenários complementares que não estavam nos requisitos (vinham da experiência do projetista de testes e de outras documentações não oficiais). Clara- mente, estas informações não seriam encontradas nos testes gerados pela ferramenta, porque a especificação usada como entrada para gerá-los não conheceria tais informações. A saída foi enriquecer a representação em inglês padronizada dos requisitos com os comportamentos
1Caso a especificação padrão do processo estivesse no formato de Inglês padronizado, não seria necessário
complementares, e obter uma nova especificação CSP que os englobasse. 6.3.3 Definição dos Pseudo Propósitos de Teste e Geração dos Testes
Em seguida, no Passo 3 do estudo de caso, foi definido um pseudo propósito de teste para cada requisito da aplicação, como também um para cada uma das informações complementa- res usadas para enriquecer a especificação. A partir do alfabeto de eventos da especificação CSP (gerada no passo anterior do estudo) foram definidos 9 pseudo propósitos de teste (6 base- ados nos requisitos e 3 baseados em informações complementares). A definição dos propósitos foi a atividade que mais demandou esforço deste estudo, dada a dificuldade em definí-los ma- nualmente. Uma dificuldade encontrada nesta definição foi o tamanho reduzido do alfabeto de eventos da especificação, que continha em sua maioria eventos de significação muito abs- trata, por exemplo, um único evento da especificação é utilizado para expressar a ação enviar mensagem (independente de quantos tipos de mensagem existem). Este tipo de abstração deu origem a propósitos de teste cuja seleção de testes foi menos precisa, pois faltavam eventos mais específicos do alfabeto da especificação capazes de descrever variações de um mesmo comportamento (no exemplo anterior, faltavam eventos distintos para cada tipo de mensagem enviada).
Os 9 pseudo propósitos de teste foram então empregados como entrada de ATG, junto com a especificação, para gerar os casos de teste CSP. Foram gerados, em poucos segundos, 37 casos de teste. É praticamente inviável (para o usuário que desconhece CSP) executar os casos de teste diretamente especificados em CSP, pois o significado do alfabeto de eventos é de difícil compreensão. Para facilitar a leitura e execução destes testes, os mesmo foram traduzidos para uma notação de Inglês padronizado para especificar casos de teste. Esta última tradução foi realizada por um ferramenta de processamento de linguagem natural (que na Figura 6.4 corresponde a seta que leva da caixa Casos de Teste CSP para a caixa Casos de Teste Linguagem Natural).
6.3.4 Avaliação dos Testes
Finalmente, no Passo 4 do estudo, foi realizada a comparação quantitativa e qualitativa dos conjuntos de testes gerados automaticamente por ATG (obtidos no passo anterior deste estudo) com o conjunto de testes gerados manualmente (pela atividade Projeto Manual representada na Figura 6.3). O primeiro conjunto contém 37 testes contra 84 do segundo. A primeira explicação para essa diferença (47 testes) está relacionada as características da especificação CSP utilizada que estão relacionadas a seguir.
• A especificação possui um nível de abstração muito alto, portanto gera casos de teste com
o mesmo nível de abstratação (ver comentário da Seção 6.3.2). A abstração dos even- tos da especificação fez com que alguns testes gerados automaticamente pudessem ser relacionados com quatro diferentes testes que foram especificados manualmente. Como exemplo dessa situação, um teste CSP que descreve o fluxo de envio de uma mensagem (independente do tipo) equivale a quatro testes projetados manualmente para o mesmo fluxo. Os testes manuais especificavam o mesmo fluxo do teste CSP, com a diferença de
6.3 APLICAÇÃO DO ESTUDO 91