SIPTEST – System Intelligent Process Testing.
Arquitetura de integração das ferramentas selecionadas
SIPTEST - System Intelligent Testing
Link Consulting,SA | Pág. 0 de 14
Índice
1
Introdução................................................................................................................................................................ 2
2
Ferramentas selecionadas ....................................................................................................................................... 3
3
Especificação dos mecanismos de integração ......................................................................................................... 6
3.1
3.1.1
3.2
3.2.1
3.3
3.3.1
3.4
3.4.1
Integração entre ferramenta TestLink e SoapUI ............................................................................................ 6
Informação trocada entre ferramentas ..................................................................................................... 6
Integração entre ferramenta TestLink e Mantis ............................................................................................. 8
Informação trocada entre ferramentas ..................................................................................................... 8
Integração entre ferramenta SoapUI e Oracle Enterprise Repository ........................................................... 8
Informação trocada entre ferramentas ..................................................................................................... 9
Integração entre ferramenta Oracle Enterprise Repository e EAMS ........................................................... 10
Informação trocada entre ferramentas ................................................................................................... 11
SIPTEST - System Intelligent Process Testing
Link Consulting,SA | Pág. 1 de 14
1 Introdução
O objetivo deste documento é descrever a genericamente a arquitetura da solução nomeadamente no que diz
respeito às ferramentas selecionadas e aos seus mecanismos de integração.
No segundo capítulo é feita uma descrição das ferramentas que foram utilizadas na solução, as sua funcionalidades
e como se enquadram na arquitetura da solução.
No terceiro capítulo é feita uma descrição detalhada dos mecanismos de integração usados na importação e
exportação de informação entre as ferramentas.
SIPTEST - System Intelligent Process Testing
Link Consulting,SA | Pág. 2 de 14
2 Ferramentas selecionadas
Com vista a melhorar o seu processo de QA, a Link concebeu uma plataforma integrada para testes em arquiteturas
orientadas a serviços, cujos principais objetivos a que se propôs foram:
1) Permitir que os diferentes perfis comprometidos no desenvolvimento e governação de uma arquitetura
SOA (arquitectos, gestores de negócio, testadores funcionais, operações, key users), partilhem uma visão
unificada e consistente do progresso das iniciativas de QA.
2) Mitigar a necessidade de conhecimentos técnicos detalhados requeridos para a execução de testes aos
perfis mais funcionais.
3) Suportar processos de QA que abranjam tanto a fase prévia à entrada em produção dos serviços como o
acompanhamento após a entrada em produção.
A solução concebida resultou da integração de diversos tipos de ferramentas frequentemente utilizadas tanto na
área do Quality Assurance como na área das arquiteturas SOA. Isoladamente, cada uma destas ferramentas apenas
está vocacionada para garantir parte do processo de QA, ou apenas permite um acompanhamento parcial das
iniciativas SOA (sem abranger o QA).
Com a integração de vários tipos de ferramentas numa única plataforma, a Link procurou complementar as valências
de cada uma delas de forma a contribuírem para um processo de QA unificado e consistente.
SIPTEST - System Intelligent Process Testing
Link Consulting,SA | Pág. 3 de 14
Figura 1 – Plataforma Integrada para testes SOA
A plataforma integrada para testes em arquiteturas orientadas a serviços resulta da integração das seguintes
ferramentas:
TestLink: Ferramenta de gestão de testes (test management): Uma ferramenta de gestão de testes permite
que testadores funcionais ou key users registem as suas baterias de testes funcionais, bem como os resultados
da sua execução. Este tipo de ferramentas permite para cada teste que se pretenda executar especificar os seus
passos, os respetivos resultados esperados e, após a execução, registar o respetivo resultado.
Trata-se portanto de um tipo de ferramenta essencial para os testadores funcionais e key users, onde é
efetuado todo o planeamento das ações de QA e onde é registado a sua execução e progresso.
Mantis: Ferramenta de gestão de defeitos (bug tracking): Uma ferramenta de gestão de defeitos possibilita aos
testadores reportar às equipas de desenvolvimento os defeitos detetados durante a execução dos testes. De
forma genérica, este tipo de ferramentas permite gerir todo o ciclo de vida de um defeito, desde que é detetado
(aberto) até à sua correção e validação (fecho), bem como classificar os defeitos reportados quanto à sua
severidade e prioridade na correção.
É portanto um tipo de ferramenta crucial em qualquer processo de QA, que agiliza a comunicação entre
testadores e desenvolvimento no que respeita à deteção de defeitos e respetiva correção.
SoapUI: Ferramenta de automação de testes funcionais a serviços (API functional testing): Uma ferramenta de
automação de testes a serviços permite que testadores com um perfil técnico ou mesmo que membros das
equipas de desenvolvimento codifiquem e automatizem a execução de testes a serviços ou orquestrações de
serviços. Este tipo de ferramentas requer tanto um conhecimento das API’s dos serviços testados como domínio
da linguagem da ferramenta de automação utilizada.
É pois um tipo de ferramenta vocacionada para perfis mais técnicos, onde os testes que são registados estão
desprovidos de enquadramento funcional.
OER: Ferramenta de governação SOA (SOA governance): Uma ferramenta de governação SOA possibilita aos
arquitetos SOA monitorizar de ponta a ponta o ciclo de vida das iniciativas de governação SOA.
De forma genérica, um arquiteto poderá registar neste tipo de ferramenta todas as características relevantes de
um serviço bem como as suas relações com outros serviços ou entidades da arquitetura (serviços dependentes,
aplicações onde é utilizado, etc..).
De forma geral é omissa neste tipo de ferramentas informação relativa ao QA dos serviços (nº de casos de
testes previstos, testes passados, testes falhados, defeitos abertos, etc…), devido a não existir uma forma
expedita de atualizar este tipo de informação na ferramenta.
EAMS: Ferramenta de arquitetura empresarial (Enterprise Architecture): Uma ferramenta de arquitetura
empresarial permite representar diversos domínios de uma organização como processos de negócio, sistemas
SIPTEST - System Intelligent Process Testing
Link Consulting,SA | Pág. 4 de 14
de informação, serviços, orquestrações, infraestrutura, bem como as relações entre eles e a forma como estas
evoluem ao longo do tempo, permitindo aos gestores de negócio fazer análises preditivas e tomar decisões. Tal
como no caso anterior, também não é registado neste tipo de ferramentas informação sobre as iniciativas de
QA em curso devido à inexistência de uma forma expedita de atualizar este tipo de informação.
Como mencionado anteriormente, se considerados de forma isolada, os tipos de ferramentas acima descritos não
suportam um processo de QA de ponta a ponta, transversal aos diversos perfis comprometidos com a qualidade de
uma arquitetura SOA. Através da integração de todos estes tipos de ferramentas complementares numa única
plataforma pretende-se garantir que a informação relevante sobre os processos de QA flua entre os vários tipos de
ferramentas, promovendo assim a transparência e visibilidade para os vários tipos de perfis que as utilizam.
SIPTEST - System Intelligent Process Testing
Link Consulting,SA | Pág. 5 de 14
3 Especificação dos mecanismos de integração
3.1
Integração entre ferramenta TestLink e SoapUI
Esta secção descreve a interação/comunicação entre a ferramenta de gestão de testes TestLink e a ferramenta de
automação de testes funcionais a serviços SoapUI.
A ferramenta de automação de testes funcionais a serviços foi estendida com um mecanismo que permite que as
equipas de desenvolvimento (uma vez terminada a automação dos testes) possam associar os testes codificados aos
testes especificados na ferramenta de gestão de testes.
O resultado desta associação permitirá aos testadores funcionais despoletar a execução dos testes diretamente da
ferramenta de gestão de testes, bem como receber e registar os resultados da execução
3.1.1
Informação trocada entre ferramentas
a) Importação dos ficheiros SOAP
A execução dos casos de teste são feitos com base numa especificação, e essa especificação
encontra-se num ficheiro XML. Este ficheiro é criado e editado pela ferramenta SoapUI, onde um
utilizador com um perfil técnico automatiza os casos de teste, gerando assim um ficheiro XML.
Exemplo do ficheiro XML gerado pelo SoapUI:
<?xml version="1.0" encoding="UTF-8"?>
<con:soapui-project activeEnvironment="Default" name="globalweather" resourceRoot="" defaultScriptLanguage="Groovy" soapuiversion="4.5.1" abortOnError="false" runType="SEQUENTIAL" xmlns:con="http://eviware.com/soapui/config"><con:settings/><con:interface
xsi:type="con:WsdlInterface" wsaVersion="NONE" name="GlobalWeatherSoap" type="wsdl"
bindingName="{http://www.webserviceX.NET}GlobalWeatherSoap" soapVersion="1_1" anonymous="optional"
definition="http://www.webservicex.com/globalweather.asmx?wsdl" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance"><con:settings/><con:definitionCache type="TEXT"
rootPart="http://www.webservicex.com/globalweather.asmx?wsdl"><con:part><con:url>http://www.webservicex.com/globalweather.asmx?w
sdl</con:url><con:content><![CDATA[<wsdl:definitions targetNamespace="http://www.webserviceX.NET"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
xmlns:tns="http://www.webserviceX.NET" xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<wsdl:types>
<s:schema elementFormDefault="qualified" targetNamespace="http://www.webserviceX.NET">
<s:element name="GetWeather">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="CityName" type="s:string"/>
<s:element minOccurs="0" maxOccurs="1" name="CountryName" type="s:string"/>
</s:sequence>
</s:complexType>
</s:element>
<s:element name="GetWeatherResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="GetWeatherResult" type="s:string"/>
</s:sequence>
</s:complexType>
</s:element>
(…)
SIPTEST - System Intelligent Process Testing
Link Consulting,SA | Pág. 6 de 14
<wsdl:message name="GetCitiesByCountryHttpPostIn">
<wsdl:part name="CountryName" type="s:string"/>
</wsdl:message>
<wsdl:message name="GetCitiesByCountryHttpPostOut">
<wsdl:part name="Body" element="tns:string"/>
</wsdl:message>
<wsdl:portType name="GlobalWeatherSoap">
<wsdl:operation name="GetWeather">
<wsdl:documentation>Get weather report for all major cities around the world.</wsdl:documentation>
<wsdl:input message="tns:GetWeatherSoapIn"/>
<wsdl:output message="tns:GetWeatherSoapOut"/>
</wsdl:operation>
<wsdl:operation name="GetCitiesByCountry">
<wsdl:documentation>Get all major cities by country name(full / part).</wsdl:documentation>
<wsdl:input message="tns:GetCitiesByCountrySoapIn"/>
<wsdl:output message="tns:GetCitiesByCountrySoapOut"/>
</wsdl:operation>
</wsdl:portType>
(…)
<wsdl:service name="GlobalWeather">
<wsdl:port name="GlobalWeatherSoap" binding="tns:GlobalWeatherSoap">
<soap:address location="http://www.webservicex.com/globalweather.asmx"/>
</wsdl:port>
<wsdl:port name="GlobalWeatherSoap12" binding="tns:GlobalWeatherSoap12">
<soap12:address location="http://www.webservicex.com/globalweather.asmx"/>
</wsdl:port>
<wsdl:port name="GlobalWeatherHttpGet" binding="tns:GlobalWeatherHttpGet">
<http:address location="http://www.webservicex.com/globalweather.asmx"/>
</wsdl:port>
<wsdl:port name="GlobalWeatherHttpPost" binding="tns:GlobalWeatherHttpPost">
<http:address location="http://www.webservicex.com/globalweather.asmx"/>
</wsdl:port>
</wsdl:service>
(…)
É então, com base neste ficheiro XML que se irão executar os casos de teste, mas, de modo a serem
executados autonomamente a partir da ferramenta de gestão de testes, é necessário primeiramente
importar o ficheiro para o TestEngine (extensão ao motor de execução de testes do SoapUI
desenvolvido pela Link) através da ferramenta TestLink.
Quando se procede ao upload de um ficheiro (tipicamente com o nome ‘soapui-project.xml’) através
do TestLink, é então invocado o serviço upload (com os parâmetros: system=<nome do sistema>,
projectName=<nome do projecto>, testPlanName=<nome do plano de testes>, file=<conteúdo do
ficheiro>) no TestEngine que com base no projeto e plano de teste a executar, publica o ficheiro na
máquina onde o TestEngine se encontra a correr.
Desta forma, o TestEngine conhece qual o ficheiro a correr e quais os casos de testes que lhe estão
associados.
b) Execução do plano de testes
É a partir do TestLink que os testadores funcionais despoletarão a execução dos casos de teste,
cabendo depois ao TestEngine correr os casos de teste e publicar os resultados na ferramenta do
TestLink.
Após um testador funcional criar um plano de testes e inserir os casos de teste a executar na
ferramenta de gestão de testes, e após terem sido executados os passos descritos em a), a
ferramenta encontra-se apta para despoletar a execução dos testes.
SIPTEST - System Intelligent Process Testing
Link Consulting,SA | Pág. 7 de 14
O utilizador do TestLink dá indicação para correr os casos de teste, clicando no botão RUN, que
invoca o serviço Run (com os parâmetros: system=<nome do sistema>, entity=<estrutura json de um
plano de testes>) do TestEngine para executar os testes, indicando o projeto, o plano de testes, e os
casos de teste a executar. Esta invocação é feita por http via RESTful, de forma assíncrona. O
TestEngine executa os testes, com base na informação enviada no pedido http, e publica os
resultados no TestLink utilizando a API testlink-java-api (TestLink Java API interfaces TestLink PHP
xml-rpc API), para inserir na base de dados do TestLink o resultado da execução de cada caso de
teste. Após a execução, o utilizador ao atualizar a página web, acede ao resultado da execução no
TestLink.
3.2
Integração entre ferramenta TestLink e Mantis
Esta secção descreve a informação trocada entre a ferramenta de gestão de testes TestLink e a ferramenta de
gestão de defeitos Mantis.
Esta integração permite aos testadores funcionais, aquando da ocorrência de um defeito na execução de um teste,
proceder ao registo e atribuição dos mesmos às equipas de desenvolvimento diretamente a partir da ferramenta de
gestão de testes.
Desta forma todo o processo de reporte de um defeito poderá ser iniciado diretamente a partir da ferramenta de
gestão de testes, ficando o defeito aberto automaticamente associado ao teste onde foi detetado (princípio da
rastreabilidade).
3.2.1
Informação trocada entre ferramentas
a) Associar um defeito a um caso de teste
Após a execução dos casos de teste, é sempre possível que existam casos de teste que falharam
sendo necessário reportar um defeito. A ferramenta TestLink permite associar um defeito (publicado
no Mantis) a um caso de teste.
Quando um caso de teste tem o estado failed é possível associa-lo a um defeito, clicando em bug
management que abre uma janela para que o utilizador inserira o identificador do defeito reportado
no Mantis. Após o utilizador inserir o id e submete-lo, o TestLink obtém o estado atual do defeito no
Mantis, através de uma comunicação RPC, e na base de dados do TestLink associa ao caso de teste o
identificador do defeito. Sempre que se aceder ao caso de teste, obtém-se o estado atual do defeito
sempre através de uma comunicação RPC.
3.3
Integração entre ferramenta SoapUI e Oracle Enterprise Repository
Esta secção descreve a interação entre a ferramenta de automação de testes funcionais SoapUI e a ferramenta de
governação SOA OER. Estas duas ferramentas interagem na fase da publicação dos resultados da execução, quando
o TestEngine (extensão ao motor de execução de testes do SoapUI desenvolvido pela Link) terminar de executar os
testes.
SIPTEST - System Intelligent Process Testing
Link Consulting,SA | Pág. 8 de 14
Esta integração permite que os resultados da execução dos testes (resultados, erros, nº de execuções, etc…) sejam
propagados à ferramenta de governação SOA ficando associados aos respetivos serviços e orquestrações.
No sentido inverso esta integração permite também, sempre que for detetado um erro na execução de testes a um
serviço, informar a ferramenta de automação de testes funcionais, sobre quais os serviços dependentes do serviço
testado. Esta informação é por sua vez agregada ao resultado da execução dos testes e propagada até à ferramenta
de gestão de testes onde surgirá como um alerta aos testadores funcionais.
3.3.1
Informação trocada entre ferramentas
a) Obtenção de dependências entre serviços
A obtenção de dependências prende-se com a necessidade de o TestEngine conhecer quais os
serviços que dependem de que um serviço, quando a execução dos casos de teste desse serviço
falham, pois eventualmente os serviços que dependem do serviço em erro, encontram-se
comprometidos sendo necessário propagar esta informação até à ferramenta de gestão de testes
para que esta chegue ao conhecimento dos testadores funcionais.
O objetivo acima é alcançado utilizando a API REX (Repository Extensibility Framework,
http://docs.oracle.com/cd/E17904_01/doc.1111/e15754/overview.htm
e
http://docs.huihoo.com/oracle/middleware/fusion/11g/apirefs.1111/e16598/index.html),
que
permite obter informação sobre um dado serviço com base nas suas relações, utilizando os métodos
‘assetQuery’, ‘getRelationshipTypes’ e ‘assetRead’. Após a execução dos casos de teste o TestEngine
cria uma associação entre cada caso de teste e o seu serviço no OER, e deste modo, consegue-se
apurar que serviços têm casos de teste com erros, e assim, dos serviços que têm pelo menos um
caso de teste com erro, obtêm-se os serviços a que dele dependem, utilizando a API REX invocando
os métodos ‘assetCreate’, ‘assetAccept’, ‘assetRegister’, e ‘assetUpdate’. Após se obter esta
informação, ela é inserida na estrutura que representa o caso de teste a publicar no TestLink.
Quando esta informação for publicada, no TestLink surgirá a informação de que serviços poderão
ficar afetados devido ao caso de teste ter falhado.
b) Criação dos casos de teste
Aquando da publicação dos resultados da execução dos testes, caso um caso de teste não se
encontre declarado no OER, então o TestEngine efetua a sua criação para depois publicar o
resultado da sua execução.
Um caso de teste é criado durante o processo de publicação, onde se verifica primeiro a existência
do caso de teste no OER com base no nome (ou seja, prefixo do caso de teste no TestLink e o nome
do caso de teste). Caso este não exista, o caso de teste é criado utilizando a informação fornecida no
pedido de execução dos testes feito a partir do TestLink. O caso de teste é criado, utilizando a API
REX (Repository Extensibility Framework). Após a criação do caso de teste, os resultados da sua
execução poderão ser publicados.
c)
Criação das test suites
SIPTEST - System Intelligent Process Testing
Link Consulting,SA | Pág. 9 de 14
Aquando da publicação dos resultados, caso uma bateria de testes (test suite) não se encontre
declarada no OER, então o TestEngine efetua a sua criação, de modo a ela se poderem associar os
assets Functional – Test Cases e Business Process.
A criação de test suites é realizada aquando da publicação dos resultados da execução dos testes no
OER. Visto que os casos de teste estão associados a test suites ao nível do TestLink, antes de se
proceder à publicação dos casos de testes, o TestEngine verifica qual a test suite que está associada
aos casos de teste a publicar. Após isso o TestEngine irá validar se essa test suite já existe no OER.
Caso exista, prossegue com a publicação dos resultados dos casos de testes, caso contrário, cria de
raiz a test suite e associa a essa test suite aos Business Processes dos serviços que se encontram em
testes (como um serviço está associado a um Bussiness Process e o serviço a um caso de teste, então
consegue-se determinar qual o Bussiness Process que se deve associar à test suite). O processo de
criação do asset test suite é efetuado utilizando a API REX invocando os métodos ‘assetCreate’,
‘assetAccept’, ‘assetRegister’, e ‘assetUpdate’.
d) Publicação dos resultados de execução
Após o TestEngine executar os testes SOA, o resultado de cada caso de teste deverá então ser
registado e documentado no OER.
A publicação dos resultados dos casos de teste é efetuada utilizando a API REX invocando o método
‘assetUpdateCustomDataNode’, onde se acede ao asset Test Case, e se publica o resultado da
execução do caso de teste, com a data de execução, a data de planeamento de execução, resultado
da execução, o nome do caso de teste e test suite.
e)
Atualização do estado dos serviços com base nos testes executados
De acordo com a arquitetura no OER, um serviço encontra-se associado a um caso de teste, e com
base nessa associação consegue-se determinar o estado do serviço de acordo com os resultados dos
casos de teste.
Após executar os casos de teste, o TestEngine determina o serviço associado a cada caso de teste, e
posteriormente contabiliza-se os resultados dos casos de teste para determinar se o serviço se
encontra em erro ou correto. Depois, utiliza-se a API REX invocando o método ‘assetUpdate’ para
atualizar o estado do serviço.
3.4
Integração entre ferramenta Oracle Enterprise Repository e EAMS
A ferramenta de arquitetura empresarial EAMS permite visualizar de forma fácil as relações entre diversos
domínios (processos de negócio, aplicações, projetos, serviços, orquestrações) de uma organização e a forma
como essas relações se alteram ao logo do tempo.
Esta integração entre a ferramenta de governação SOA OER e a ferramenta de arquitetura empresarial EAMS,
tem o intuito de adicionar a esta ferramenta a possibilidade de visualizar as relações de conceitos associados
ao quality assurance (Ex: casos de testes, bateria de testes) e os restantes conceitos nela habitualmente
mapeados (Ex: serviços, orquestrações, aplicações, etc…).
SIPTEST - System Intelligent Process Testing
Link Consulting,SA | Pág. 10 de 14
3.4.1
Informação trocada entre ferramentas
a) Exportar a informação do OER
Após publicação dos resultados no OER, o utilizador pode exportar toda a informação para ser
consumida por outras ferramentas.
O utilizador acede à área de administração no OER e em importação e exportação clica para
exportar, e exporta todo o tipo de informação (assets, relações, tipos de dados). Esta ação resulta
num ficheiro zip com todos os dados da exportação.
b) Importar a informação para o EAMS
O EAMS permite consumir informação de uma ferramenta de governação, neste caso o OER. No
âmbito deste projeto, a informação consumida pelo EAMS permite a um utilizador visualizar
graficamente as relações entre assets, e permite também visualizar os resultados de execução e a
sua associação com os serviços e casos de teste.
A informação é importada para o EAMS com base num ficheiro XML que é criado com base na
informação do OER. Então, a partir do OER temos um zip que contém todas as relações e dados de
todos os assets, e esse zip é primeiro analisado e processado por um script que decompõe a
informação num único ficheiro (XML). Esse ficheiro é então adicionado numa diretória específica da
aplicação EAMS e quando a aplicação se inicia – carrega essa informação, ou quando esta já está a
correr basta recarregar os dados.
Exemplo da estrutura do ficheiro XML consumido pelo EAMS:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Rep>
<DT Uid="1" Nm="Service Types">
<DTP>
<P MTdt="" MT="Text" Nm="Id"/>
<P MTdt="" MT="Text" Nm="Name"/>
<P MTdt="" MT="Text" Nm="Default Value"/>
</DTP>
<DIs>
<DI Uid="145" Nm="Mediator Service">
<P MTUid="" MTsv="50438" Nm="Id"/>
<P MTUid="" MTsv="Mediator Service" Nm="Name"/>
<P MTUid="" MTsv="false" Nm="Default Value"/>
</DI>
<DI Uid="146" Nm="Split-Join Service">
<P MTUid="" MTsv="50439" Nm="Id"/>
<P MTUid="" MTsv="Split-Join Service" Nm="Name"/>
<P MTUid="" MTsv="false" Nm="Default Value"/>
</DI>
<DI Uid="147" Nm="EJB Service">
<P MTUid="" MTsv="50436" Nm="Id"/>
<P MTUid="" MTsv="EJB Service" Nm="Name"/>
<P MTUid="" MTsv="false" Nm="Default Value"/>
</DI>
<DI Uid="148" Nm="FileAdapter">
<P MTUid="" MTsv="50437" Nm="Id"/>
<P MTUid="" MTsv="FileAdapter" Nm="Name"/>
SIPTEST - System Intelligent Process Testing
Link Consulting,SA | Pág. 11 de 14
<P MTUid="" MTsv="false" Nm="Default Value"/>
</DI>
<DI Uid="149" Nm="Application Interface">
<P MTUid="" MTsv="50434" Nm="Id"/>
<P MTUid="" MTsv="Application Interface" Nm="Name"/>
<P MTUid="" MTsv="false" Nm="Default Value"/>
</DI>
<DI Uid="150" Nm="BPEL">
<P MTUid="" MTsv="50435" Nm="Id"/>
<P MTUid="" MTsv="BPEL" Nm="Name"/>
<P MTUid="" MTsv="false" Nm="Default Value"/>
</DI>
<DI Uid="151" Nm="Abap Proxy">
<P MTUid="" MTsv="50432" Nm="Id"/>
<P MTUid="" MTsv="Abap Proxy" Nm="Name"/>
(…)
<DI Uid="1269" Nm="{BPELMensal_CCarga_Out1.0}Endpoint/HTTPS_Port-2">
<P MTUid="" MTsv="1269" Nm="ID"/>
<P MTUid="" MTsv="a5a3da97-1af7-11e3-90f2-4dfbe146254a" Nm="GUID"/>
<P MTUid="" MTsv="50664" Nm="OER ID"/>
<P MTUid="" MTsv="http://192.168.24.49:7101/oer/index.jsp?assetid=50664" Nm="OER URL"/>
<P MTUid="" MTsv="{BPELMensal_CCarga_Out1.0}Endpoint/HTTPS_Port-2" Nm="Name"/>
<P MTUid="" MTsv="1.0" Nm="Version"/>
<P MTUid="1104" MTsv="{PI}BPELMensal_CCarga_Out" Nm="Deployment of [AUTO]"/>
<P MTUid="1964" MTsv="{http://edp.pt/ISU/PortalCliente}BPELMensal_CCarga_OutService.wsdl-2" Nm="Defines
[AUTO]"/>
<P MTUid="" MTsv="" Nm="Description"/>
<P MTUid="" MTsv="" Nm="Community"/>
<P MTUid="" MTsv="" Nm="Operations Owner"/>
<P MTUid="" MTsv="" Nm="Planned Downtime"/>
<P MTUid="" MTsv="" Nm="Start Date for Metrics Monitoring"/>
(…)
<DI Uid="2178" Nm="Test Execution_4">
<P MTUid="1151
" MTsv="Test Execution_4
" Nm="Functional - Test Case"/>
<P MTUid="" MTsv="1" Nm="Run"/>
<P MTUid="" MTsv="11 Nov 2013 12:00:00 AM GMT" Nm="Execution Date"/>
<P MTUid="" MTsv="Production" Nm="Environment"/>
<P MTUid="" MTsv="MES-11" Nm="Test Case ID"/>
<P MTUid="" MTsv="Functional" Nm="Test Type"/>
<P MTUid="" MTsv="Receive MMS different operator" Nm="Test Case Name"/>
<P MTUid="" MTsv="TS - MMS" Nm="Test Suite Name"/>
<P MTUid="" MTsv="Test Case 'Receive MMS different operator' failed the execution because the assertion type
'Contains - [Missing token [967809100] in Response]' in the Test Step 'Receive from '967809100''. The test case fail during the
execution, pay attention to the OER Dependencies. The interface [SuspendProvisionPortType] is interface of the following
services: ["Warning Suspend Provision(1.0)"] and each service depends of: Warning Suspend Provision(1.0) - [No
services depend on it.]" Nm="Note"/>
<P MTUid="" MTsv="10 Nov 2013 12:00:00 AM GMT" Nm="Planned Execution Date"/>
<R RUid="1151
" Rsv="MES-11:Receive MMS different operator
" Rdt="Functional - Test
Case
" Nm="2151"/>
</DI>
<DI Uid="2179" Nm="Test Execution_5">
<P MTUid="1140
" MTsv="Test Execution_5
" Nm="Functional - Test Case"/>
<P MTUid="" MTsv="1" Nm="Run"/>
<P MTUid="" MTsv="11 Nov 2
(…)
<P MTdt="" MT="Text" Nm="Timing"/>
<P MTdt="" MT="Text" Nm="Comments"/>
</DTP>
<DIs/>
</DT>
<DT Uid="2123" Nm="IP Ownership">
SIPTEST - System Intelligent Process Testing
Link Consulting,SA | Pág. 12 de 14
<DTP>
<P MTdt="" MT="Text" Nm="Organization"/>
<P MTdt="" MT="Text" Nm="Contact Email Address"/>
<P MTdt="" MT="Text" Nm="Contact Telephone Number"/>
</DTP>
<DIs/>
</DT>
</Rep>
SIPTEST - System Intelligent Process Testing
Link Consulting,SA | Pág. 13 de 14
Download
