Partindo do pressuposto que os modelos de desenvolvimento tenham sido desenvolvidos na etapa de projeto, as etapas da abordagem devem ser realizadas repetidamente até que todas as classes do sistema tenham sido devidamente testadas e integradas. A seguir, são apresentadas em detalhes cada uma dessas etapas do processo de aplicação da abordagem bem como todos os artefatos e ferramentas utilizados durante o processo.
3.2
Adaptação dos Modelos de Desenvolvimento para Teste
de Integração
Devido aos problemas associados com a integração big-bang (Seção 2.1.2), as classes precisam ser integradas uma de cada vez, ou em alguns casos especiais, em pequenos clusters [11]. Nesse contexto, em teste de integração para software OO é essencial identificar uma ordem de prioridade das classes para os testes, ou seja, estabelecer critérios de precedência entre as classes para verificar o funcionamento conjunto das mesmas. Em outras palavras, uma das questões fundamentais do teste de integração é a escolha da ordem de integração, ou seja, a ordem na qual as classes são integradas.
Independente da estratégia de teste de integração escolhida, as classes são integradas com outras que, por definição, já se encontram desenvolvidas e testadas individualmente, ou seja, o código da classe foi examinado e revisado, e defeitos, porventura existentes, já foram removidos. No entanto, em algumas situações, as classes podem estar em fases distintas do ciclo de desenvolvimento do software. Enquanto algumas podem estar prontas para executar testes de integração, outras podem ainda estar em fase de codificação ou em fase de testes individuais (teste de unidade). Assim, quando existirem classes necessárias à integração que ainda não estão disponíveis, é preciso que sejam criados emuladores de testes, ou seja, pedaços de software construídos para simular partes do software que ainda não estão disponíveis, para dar prosseguimento aos testes.
A forma ou ordem de integração das classes pode influenciar os tipos de teste a serem
feitos, e, consequentemente o custo e a eficácia do teste. Por isto, é tão importante
considerar o processo de teste associado ao processo de desenvolvimento. Uma estratégia ruim pode levar à construção de muitos emuladores ou à combinação de classes não testadas previamente, dificultando o processo de localização de defeitos. Existem, na literatura,
3.2 Adaptação dos Modelos de Desenvolvimento para Teste de Integração 32
alguns trabalhos que propõem metodologias/estratégias para planejar o teste de integração a partir de modelos UML, especificamente de diagramas de classes, com o intuito de analisar as dependências entres as classes e servem como base para que elas sejam testadas em uma ordem/sequência de integração que minimize os esforços gastos para realizar o teste de integração [22, 29, 42].
Uma vez que já existem estratégias que fazem análise de dependências entre classes e encontram ordens de integração eficientes para testes de integração de software OO, e o foco da abordagem aqui proposta é apenas na geração dos casos de teste, na abordagem é considerado que a ordem de integração já foi definida, ou por outras abordagens, ou a critério do testador. A ideia é, além de simplificar a abordagem, reutilizar estratégias eficientes. No entanto, para que fosse possível a geração dos casos de teste de acordo com a ordem de integração definida, foi preciso a adaptação dos modelos de desenvolvimento. Para isso, foi desenvolvido um perfil UML 2.0 no intuito que apenas os artefatos (classes e emuladores) necessários para o teste de integração fossem considerados de acordo com a ordem de integração escolhida pelo testador, a cada etapa do modelo incremental.
Perfis UML são mecanismos para extensão dos diagramas UML para adaptá-los à semântica de domínios específicos. Eles permitem que qualquer meta-classe da especificação de UML seja anotada com estereótipos que representam um conceito específico de um domínio. Conforme descrito, foi definido um perfil UML 2.0, chamado de Integration Order
Profile (IOP), para adicionar aos modelos UML características que indicam quais classes
devem ser agrupadas para os testes e a ordem de integração entre elas. Neste perfil, o papel de cada classe do sistema no teste de integração é especificado com estereótipos (stereotype) a serem aplicados em classes do diagrama de classes.
O conjunto de estereótipos do perfil IOP e a meta-classe que deve ser estendida
com eles pode ser visto na Figura 3.4. Conforme mostrado na figura, os quatro
estereótipos especificados devem ser aplicados à meta-classe Classifier uma vez que ela é um meta-elemento usado para modelar classes, objetos e componentes em modelos UML. Além disso, é importante destacar que o elemento Classifier a ser anotado com os estereótipos deve ser do tipo Class ou Interface, conforme descrito na restrição OCL também mostrada na figura. As semânticas associadas a cada estereótipo do perfil IOP são:
3.2 Adaptação dos Modelos de Desenvolvimento para Teste de Integração 33
Figura 3.4: Integration Order Profile (IOP).
novo componente (também chamado de classe ou entidade), o qual já foi testado individualmente, é integrado e então disponibilizado para o teste de
integração. Nesse contexto, o elemento (meta-classe Classifier) estereotipado
com «ClassToBeIntegrated» representa o componente a ser integrado, ou seja, o componente a ser verificado em nível de teste de integração a cada passo. É importante enfatizar que um, e somente um, elemento Classifier do diagrama de classes deve ser anotado com este estereótipo. Nos modelos de teste a serem gerados, o elemento anotado com este estereótipo corresponderá ao SUT (System Under Test), e será anotado com o estereótipo «SUT» conforme descrito pelo perfil de teste U2TP;
• «DependingClass». Os elementos anotados com este estereótipo correspondem
aos componentes que são dependentes do elemento estereotipado com
«ClassToBeIntegrated». Esta anotação é importante porque, em teste de integração, muitas vezes é preciso considerar não apenas a classe a ser integrada, mas também
as suas dependências. Elementos anotados com este estereótipo não podem ser
estereotipados com «ClassToBeIntegrated» ao mesmo tempo;
• «IntegratedClass». Os elementos anotados com este estereótipo correspondem aos componentes que já foram testados individualmente e integrados para o teste de integração. Elementos anotados com este estereótipo não podem ser estereotipados
3.2 Adaptação dos Modelos de Desenvolvimento para Teste de Integração 34
como «ClassToBeIntegrated» ao mesmo tempo. Porém, podem ser anotados como «DependingClass». Nos modelos de teste a serem gerados, os elementos anotados com este estereótipo serão considerados integralmente para os testes;
• «NonIntegratedClass». Os elementos anotados com este estereótipo correspondem aos componentes que ainda não foram integrados, ou seja, ainda não estão disponíveis para o teste de integração. Teste do nível de integração é, portanto, muitas vezes confrontado com o problema que o SUT necessita de funcionalidades de outros componentes que não estão prontos para a integração. Neste caso, emuladores, que simulam funcionalidades ausentes dos componentes requeridos para o SUT prover seu serviço, são necessários, conforme mostrado na Seção ( 2.1.2). Dessa forma, nos modelos de teste, os elementos anotados com «NonIntegratedClass» serão substituídos por emuladores e anotados como componentes de teste («TestComponent») de acordo com o perfil de teste U2TP, uma vez que se tratam de componentes construídos especificamente para testes. Elementos estereotipados com «NonIntegratedClass» não podem ser estereotipados com «ClassToBeIntegrated» ao mesmo tempo. Porém, podem ser anotados como «DependingClass». Além disso, elementos não identificados com nenhum estereótipo são considerados como «NonIntegratedClass».
Figura 3.5: Exemplo de aplicação do perfil IOP.
A Figura 3.5 acima ilustra um digrama de classes UML com um exemplo de aplicação do perfil IOP. Neste diagrama, a classe ObjectManager é a classe a ser integrada (anotada com