3.4 Técnicas e critérios de teste para serviços
3.4.1 Teste de Unidade
O teste de unidade pode ser considerado a mais básica e natural estratégia de teste aplicada a qualquer sistema (Bozkurt et al., 2012). Este tipo de teste pode ser aplicado por qualquer uma das perspectivas de teste de serviços. A maioria dos trabalhos publicados para o teste de unidade baseia-se na geração de casos de teste a partir das especificações. Um resumo dos trabalhos de teste de unidade de serviços pode ser visto na Tabela 3.1. As abordagens aqui listadas consideram, geralmente, a operação do serviço ou da aplicação como uma unidade, mas existem casos em que a menor unidade do sistema é o serviço ou a própria aplicação. Na primeira coluna da tabela apa- rece a técnica de teste utilizada na abordagem. Na segunda coluna aparece o recurso utilizado pela abordagem como base para a geração de casos de teste e/ou a ferramenta utilizada e/ou desenvol- vida para automatizar a abordagem. Na terceira coluna são listados os autores da abordagem. Em alguns destes trabalhos as mesmas técnicas utilizadas para o teste de unidade podem ser usados para testar a integração entre operações do mesmo serviço.
O arquivo WSDL é a especificação das interfaces dos serviços, incluindo suas operações, tipos e protocolos utilizados. Diversas abordagens baseiam-se nessa especificação para a geração au- tomática de casos de teste com base em critérios de particionamento em classes de equivalência, análise de valor-limite, exceções e mutação com base nos tipos, mensagens e portas definidas (Bai et al., 2005; Sneed e Huang, 2006; Mei e Zhang, 2005; Siblini e Mansour, 2005; Bertolino et al., 2007; Bartolini et al., 2009b; Bai et al., 2008; Ye et al., 2010). Enquanto algumas abordagens usam o WSDL original, outras abordagens propuseram aumentar ou transformar as informações do WSDL em outras especificações por meio de marcações semânticas para facilitar a geração de
CAPÍTULO 3. TESTE DE SERVIÇOS 27
Tabela 3.1: Abordagens de teste de unidade
Técnica Recurso Autores
Funcional WSDL Tsai et al. (2002b)
Funcional WSDL Bai et al. (2005)
Funcional WSDLTEST/WSDL Sneed e Huang (2006)
Funcional WSDL Bertolino et al. (2007)
Funcional OWL-S Bai et al. (2008)
Funcional WS-TAXI/WSDL Bartolini et al. (2009b)
Funcional WSDL Li et al. (2009)
Funcional BPEL Ye et al. (2010)
Funcional Takuan/BPEL Palomo-Duarte et al. (2010)
Funcional BPEL Ilieva et al. (2010)
Funcional Outros Bozkurt e Harman (2011) Baseado em Modelos WSDL-S Sinha e Paradkar (2006a)
Baseado em erros Msg SOAP Offutt e Xu (2004) Baseado em erros Msg SOAP Xu et al. (2005)
Baseado em erros WSDL Mei e Zhang (2005)
Baseado em erros WSDL Siblini e Mansour (2005) Baseado em erros Msg SOAP Almeida e Vergilio (2006)
Baseado em erros WSDL Wang et al. (2008)
Estrutural - Bartolini et al. (2011a)
casos de teste significativos (Tsai et al., 2002b; Wang et al., 2008) ou para fazer a verificação e validação do serviço com base em técnicas de verificação de modelos (Tsai et al., 2005).
Bozkurt e Harman (2011) acreditam que a geração automática de casos de teste é importante, porém muitas vezes os dados de teste não são realísticos e significativos. A geração manual de casos de teste é mais realística e significativa, porém propensa a erros e custosa. Assim, eles introduzem uma abordagem de geração de casos de teste realísticos e automatizados por meio de ontologias e dados de teste de serviços e projetos relacionados.
Offutt e Xu (2004) e Xu et al. (2005) apresentaram uma técnica de teste baseada na modifica- ção/mutação de dados. O método consiste em modificar a mensagem de requisição enviada aos serviços e analisar a resposta. Almeida e Vergilio (2006) estenderam os operadores de perturbação de mensagens em XML definidas por Offutt e Xu (2004) e Xu et al. (2005) e desenvolveram uma ferramenta para automatizar o processo.
Realizar o teste de unidade de um serviço que é uma composição de serviços é semelhante ao teste de um serviço simples. Palomo-Duarte et al. (2010) criaram uma ferramenta para gerar, dinamicamente, invariantes de um serviço composto especificado como um processos BPEL. As invariantes propostas refletem a lógica interna do processo e são geradas a partir da execução de casos de teste. Ilieva et al. (2010) também propuseram o uso de uma ferramenta chamada TASSA para testar processos BPEL por meio de simulações. A ferramenta é capaz de injetar dados na simulação, analisar as dependência entre as operações e gerar casos de teste.
CAPÍTULO 3. TESTE DE SERVIÇOS 28 Bartolini et al. (2011a) propuseram uma abordagem chamada de SOCT (Service-Oriented Co- verage Testing) para a criação de serviços testáveis com o objetivo de aumentar a testabilidade dos serviços e possibilitar o teste estrutural. Nessa abordagem, os desenvolvedores devem inserir instruções no serviço para que detalhes de sua execução sejam enviados a um serviço chamado TCov. Os integradores podem testar os serviços testáveis e utilizar o serviço TCov para obter um relatório de cobertura estrutural da sessão de teste realizada. Uma ilustração da abrdagem é apre- sentada na Figura 3.2. O relatório de cobertura estrutural feito por TCov depende dos critérios de teste implementados pelo desenvolvedor na instrumentação do serviço. A avaliação dessa proposta foi feita por meio de uma implementação de TCov e de serviços testáveis na linguagem PHP.
Desenvolvedor/ Fornecedor
Testable
Service
instrumentaTCov
registra detalhes de execução Integrador executa casos de teste obtém cobertura estruturalFigura 3.2: Uma ilustração da abordagem SOCT
Um fator que pode dificultar a adoção da abordagem SOCT é o fato do desenvolvedor ter que instrumentar o serviço para que informações de sua execução sejam coletadas. A instrumentação manual pode ser propensa a erros e representa um esforço adicional para o desenvolvedor. A vantagem desta estratégia é que, não dependendo de instrumentação automática, a abordagem é independente de tecnologias de implementação.
Pela análise dos trabalhos relacionados ao teste de unidade, é evidente que a maioria das abor- dagens baseia-se nas especificações dos serviços para gerar e avaliar seus casos de teste, pois o código fonte dos serviços não está disponível. A única exceção é o trabalho de Bartolini et al. (2011a), que tem o objetivo de aumentar a testabilidade dos serviços e permitir o teste estrutural mesmo quando os clientes externos não possuem implementação do serviço.