5.3 JaBUTiWS: uma instânciação do Serviço de Teste da abordagem BISTWS
5.3.4 Um exemplo de uso da abordagem BISTWS para testar um serviço isola-
A implementação da abordagem BISTWS usando o serviço JaBUTiWS é apresentada nesta seção por meio do exemplo de um serviço chamado ShippingWS e que foi transformado em um serviço testável. ShippingWS é um serviço que tem por objetivo calcular o custo da entrega de uma encomenda com base no CEP de origem, CEP de destino, peso e tipo de serviço de entrega. Além disso, o serviço também possui uma operação para a consulta de um endereço com base em um CEP.
O cálculo da encomenda é feito com base em uma tabela disponibilizada pelo provedor do serviço e que leva em consideração as distâncias entre os CEPs de origem e de destino, o tipo de entrega (1 - sedex e 2 - básico) e o peso da encomenda. Encomendas com peso acima de 500g são sempre tarifadas com o tipo de entrega 1, mesmo se a requisição for para a entrega do tipo 2.
CAPÍTULO 5. UMA INSTÂNCIAÇÃO DA ABORDAGEM BISTWS 65 A seguir são apresentadas as tarefas executadas pelas perspectivas do desenvolvedor para de- senvolver e transformar ShippingWS em um serviço testável e do integrador para realizar o teste de ShippingWS isoladamente.
Desenvolvedor
Inicialmente o desenvolvedor criou ShippingWS usando a linguagem Java e gerou um pacote .war para publicar o serviço. O diagrama de classes do serviço é apresentado na Figura 5.3. A interface de ShippingWS possui duas operações: calcShippingPrice and getAddress. A interface é implementada pela classe Shipping que usa as classes PriceMgr e ZipMgr.
Shipping
<<service interface>>
ShippingWS
float calcShippingPrice(srcZip, dstZip, weight, service) String getAddress(zipCode)
float calcShippingPrice(srcZip, dstZip, weight, service) String getAddress(zipCode)
ZipMgr
String getState(zipCode) String getAddress(UF, zipCode)
PriceMgr
float calcSedexPrice(srcZip, dstZip, weight) float calcBasicPrice(weight)
Figura 5.3: Diagrama de classes de ShippingWS.
O desenvolvedor utilizou o JaBUTiWS para instrumentar ShippingWS e gerar uma versão testável do serviço. Para isto ele criou um script acionado por uma interface gráfica para facilitar a invocação do JaBUTiWS e a geração de serviços testáveis. A interface gráfica criada e utili- zada para instrumentar ShippingWS é mostrada na Figura 5.4. O desenvolvedor informou o endereço de JaBUTiWS, a localização do pacote .war contendo ShippingWS, o nome da classe que implementa a interface do serviço e a pasta em que o pacote contendo a versão testável de ShippingWSdeverá ser retornado. O desenvolvedor também indicou que a instrumentação e o relatório de cobertura deste serviço pode ser feito para o nível 3 (serviço, operações da interface, classes e métodos).
Após a instrumentação, a interface de ShippingWS recebeu novas operações para apoiar o teste estrutural. A nova interface de ShippingWS pode ser vista na Tabela 5.3.
O desenvolvedor publicou como metadados do tipo a priori os casos de teste utilizados para testar o serviço em tempo de desenvolvimento juntamente com a versão testável de ShippingWS. Os casos de teste publicados pelo desenvolvedor podem ser vistos na Tabela 5.4 e alcançam 100%
CAPÍTULO 5. UMA INSTÂNCIAÇÃO DA ABORDAGEM BISTWS 66
Figura 5.4: Interface gráfica usada para gerar um serviço testável «service interface»
ShippingWS
float calcShippingPrice(String srcZip, String dstZip, weight, service) String getAddress(String zipCode)
void startTrace(String userID, String sessionID) void stopTrace(String userID, String sessionID)
XML getCoverage(String userID, String sessionID, String level) XML getMetadata(String type)
Tabela 5.3: Interface de ShippingWS com as operações de teste
de cobertura para todos os critérios estruturais implementados pelo JaBUTiWS e considerados na análise de cobertura (todos-nós, todas-arestas e todos-usos).
Integrador
Um integrador resolveu testar o serviço ShippingWS isoladamente antes de usá-lo em sua aplicação. Para isto criou um conjunto de casos de teste que considerou relevante para testar o serviço. Os casos de teste criados pelo integrador podem ser vistos na Tabela 5.5.
Após especificar os casos de teste, o integrador criou um script para testar ShippingWS e ob- ter a análise de cobertura estrutural dos casos de teste executados. O diagrama de sequência que representa o script de teste criado pode ser visto na Figura 5.5. No início do teste o integrador invocou a operação startTrace para informar ao serviço ShippingWS que uma sessão de
CAPÍTULO 5. UMA INSTÂNCIAÇÃO DA ABORDAGEM BISTWS 67
Tabela 5.4: Casos de teste fornecidos como metadado do tipo a priori de ShippingWS
TC-ID Entrada Saída esperada Descrição
CalcShippingPrice srcZip, dstZip, weight, service Saída esperada Descrição 01 13566580, 19500000, 0.3, 1 11.9 Entrega tipo 1
02 13566580, 13566580, 0.4, 2 6.85 Entrega tipo 2 e peso ≤ 500g 03 13566580, 13566580, 0.7, 2 11.2 Entrega tipo 2 e peso > 500g
04 13566, 13566580, 0.7, 2 ZipFault Entrega tipo 2 e CEP de origem inválido 05 13566580, 130, 0.7, 2 ZipFault Entrega tipo 2 e CEP de destino inválido 06 13566580, 13566580, -0.5, 2 InputFault Entrega tipo 2 e peso inválido
07 13566580, 13566580, 0.5, 3 InputFault Tipo de entrega inválido
GetAddress zipCode Saída esperada Descrição
01 09040240 R. Laura Teste com CEP válido
02 1340, ZipFault Teste com CEP inválido
Tabela 5.5: Casos de teste criados pelo integrador para testar ShippingWS isoladamente CalcShippingPrice srcZip, dstZip, weight, service Saída esperada
calc-01 13564390, 03356001, 0.4, 1 13.4 calc-02 60150190, 50060001, 0.4, 2 11.5 calc-03 13566580, 13566580, 0.7, 2 19.1
GetAddress zipCode Saída esperada
address-01 63100000 R. Santo Antonio
teste seria iniciada e que era necessário registrar as informações de sua execução. Em seguida o integrador executou os casos de teste para a operação calcShippingPrice e depois exe- cutou os casos de teste para a operação getAddress. Durante a execução dos casos de teste ShippingWSfez o rastreamento das estruturas internas exercitadas e armazenou em um arquivo chamado infoExec. Ao terminar de executar os casos de teste, o integrador informou ao serviço testável que a sessão de teste havia encerrado e requisitou uma análise de cobertura estrutural. Neste momento, ShippingWS invocou o JaBUTiWS informando o identificador do projeto em que o serviço foi instrumentado e as informações de execução registradas durante a sessão de teste. O JaBUTiWS localizou os requisitos de teste de ShippingWS utilizando o identificador de projeto e verificou quais requisitos foram cobertos pelas informações de execução recebidas. Em seguida, o JaBUTiWS gerou um relatório de cobertura estrutural e o enviou a ShippingWS que repassou o relatório ao integrador.
O relatório da cobertura estrutural obtida pelos casos de teste criados pelo integrador pode ser visto na Tabela 5.6. O relatório foi feito considerando 4 níveis de abstração: o serviço todo, as operações da interface, as classes que compõem o serviço e os métodos que compõem as classes. Para cada nível de abstração são apresentadas as coberturas para os critérios todos-nós, todas- arestas e todos-usos. Para cada cobertura é apresentado o número de requisitos de teste cobertos sobre o número de requisitos de teste existentes e a porcentagem de cobertura alcançada.
No relatório de cobertura apresentado é possível perceber que o integrador não conseguiu al- cançar uma cobertura de 100% com os casos de teste feitos pelo desenvolvedor. Nesta situação, o integrador obteve os metadados gerados sob demanda fornecidos por ShippingWS e pode per-
CAPÍTULO 5. UMA INSTÂNCIAÇÃO DA ABORDAGEM BISTWS 68 Integrador ShippingWS JaBUTiWS 1: startTrace(tester121,001) 4: stopTrace(tester121,001) 5: getCoverage(tester121,001,3) 5.1: getCoverage(projectID,infoExec) loop 2: calcShippingPrice(dadosCT) 2.1: registra(infoExec) COBERTURA ESTRUTURAL COBERTURA ESTRUTURAL loop 3: getAddress(dadosCT) 3.1: registra(infoExec)
Figura 5.5: Diagrama de sequência usado pelo integrador para testar ShippingWS ceber que não havia criado casos de teste para exercitar o serviço em situações em que os dados são inválidos. Tendo feito isto, o integrador criou mais casos de teste e conseguiu alcançar 100% de cobertura em todos os critérios e para todos os níveis de abstração.