O teste de sistemas baseados em componentes pode ser visto por duas perspectivas: a do desen- volvedor e a do cliente. O desenvolvedor cria componentes genéricos, independentes de contexto e que atendem a um determinado conjunto de requisitos. Para o desenvolvedor não há muitas res- trições na atividade de teste porque ele é o proprietário do componente. É possível então testar seus componentes usando as técnicas adequadas à situação e ao seu processo de desenvolvimento. O cliente, por sua vez, tem duas possibilidades: testar o componente isoladamente e/ou testar sua integração com outros componentes no sistema em que será usado. Em ambos os casos, o encapsulamento reduz o nível de controle e observação que os cliente tem sobre os componentes, o que faz com que eles apresentem baixa testabilidade (Wang et al., 1997) e traga dificuldades para a atividade de teste, uma vez que o cliente fica impedido de aplicar técnicas de teste baseadas na implementação.
Além do encapsulamento, outro fator que reduz a testabilidade de um componente é a falta de especificações detalhadas e informações sobre o seu desenvolvimento e detalhes internos (Beydeda e Gruhn, 2003).
Existem pesquisadores que afirmam que a baixa testabilidade dos componentes de software não é uma limitação significativa porque eles não precisam ser testados novamente antes de serem integrados em uma aplicação porque já foram adequadamente testados pelos seus desenvolvedo- res ou então foram amplamente reusados em outras aplicações e contextos (Meijler e Nierstrasz, 1997). Weyuker (1998), entretanto, afirma que essa concepção sobre o teste de componentes é um erro e apresenta o exemplo do foguete Ariane 5 para motivar tanto a necessidade de testar os componentes antes de serem reusados quanto a necessidade de aplicar técnicas de teste baseadas em implementação juntamente com as técnicas de teste baseadas em especificação e interface.
O foguete Ariane 5 reusou um componente de sua versão anterior, o foguete Ariane 4, que implementa um sistema de referência inercial (SRI - Inertial Reference System). No teste de um sistema complexo como o de um foguete, nem sempre todos os componentes estão integrados no sistema ao mesmo tempo, pois às vezes o componente de software está embutido em um compo- nente físico que será integrado ao foguete posteriormente. Durante os testes do foguete foi usado um simulador do componente SRI. Os testes foram realizados para todos os tipos de situações aos
CAPÍTULO 2. TESTE DE COMPONENTES DE SOFTWARE 10 quais o foguete poderia ser submetido segundo os requisitos especificados e nenhuma falha foi encontrada.
No lançamento do foguete, entretanto, o componente SRI apresentou uma falha. A anoma- lia interna do componente SRI ocorreu durante a execução de uma conversão de dados de um número de 64 bits em ponto flutuante para um inteiro de 16 bits com sinal. Isso ocorreu porque ne- nhum teste foi realizado para saber se o componente funcionaria corretamente quando submetido à contagem regressiva, à sequência de tempo do lançamento e à trajetória real do Ariane 5. Uma explicação para ausência deste teste é que nos requisitos do sistema não havia uma especificação dos dados relacionados à trajetória do foguete (LIONS, 1996).
É possível identificar dois motivos principais para a falha ocorrida com o foguete Ariane 5 (LIONS, 1996). O primeiro é a falta do requisito com os dados da trajetória do foguete. Esse problema motiva a adoção de técnicas baseadas em implementação em conjunto com técnicas baseadas em especificação. A técnica funcional procura garantir que todos os requisitos funcionais do sistema foram testados, mas ela não pode garantir que todos os requisitos do sistema foram especificados. O uso da técnica de teste estrutural procura garantir que todas as partes do código foram executadas, sem se preocupar com os requisitos. A combinação dessas técnicas faz com que o testador procure executar todas as partes do código enquanto testa todos os requisitos. Se alguma parte do código não foi testada, é possível que não haja requisitos explícitos relativos ao trecho de código que não foi executado e por isso nenhum caso de teste foi criado para executá-lo. Não há garantias de que o teste estrutural teria detectado a falta do requisito no foguete Ariane 4, mas o uso desse tipo de teste oferece mais confiança aos testadores.
O segundo motivo foi o risco assumido pelos desenvolvedores do foguete Ariane 5 de que o componente SRI estava validado pelo seu uso na versão anterior do foguete. Esse é um risco que não pode ser corrido por desenvolvedores de software e motiva a ideia de testar os componen- tes reusados antes e depois de serem integrados a uma aplicação, usando tanto os requisitos do componente quando do sistema em que ele será integrado.
Além da necessidade de testar um componente de software em diferentes fases, como no teste de unidade, integração e sistema, Brenner et al. (2006) afirmam que os sistemas baseados em componentes e os componentes em si devem ser testados também em tempo de execução. Eles apresentam a seguinte classificação para as fases de teste: teste em tempo de desenvolvimento e teste em tempo de execução. O teste em tempo de desenvolvimento é feito pelo desenvolvedor antes de disponibilizar seus componentes para uso. O teste em tempo de execução é realizado pelo cliente e pode ser dividido em duas etapas: teste em tempo de implantação e teste em tempo de serviço.
No teste em tempo de implantação o cliente deve testar a integração entre os componentes usados para compor a aplicação. Nesta atividade aplicam-se estratégias de integração (bottom-up ou top-down, por exemplo) e heurísticas de ordenação para reduzir o esforço de teste na criação de driverse stubs.
CAPÍTULO 2. TESTE DE COMPONENTES DE SOFTWARE 11 No teste em tempo de serviço deve-se testar os componentes de uma aplicação enquanto ela está em operação. Esta atividade é realizada com o objetivo de descobrir se os componentes continuam atendendo aos requisitos especificados. Particularmente, o teste em tempo de serviço pode ser usado para descobrir se componentes distribuídos usados em sistemas relacionados à computação ubíqua continuam disponíveis ou se foram substituídos.