APLICAÇÃO DE TESTES DE SOFTWARE UTILIZANDO A ARQUITETURA ORIENTADA A SERVIÇOS (SOA). by Israel Kraisch

TCC

FACULDADE DE TECNOLOGIA SENAI FLORIANÓPOLIS

APLICAÇÃO DE TESTES DE SOFTWARE UTILIZANDO A ARQUITETURA ORIENTADA A SERVIÇOS (SOA).

ISRAEL KRAISCH RODRIGO TOMASELLI

APLICAÇÃO DE TESTES DE SOFTWARE UTILIZANDO A ARQUITETURA ORIENTADA A SERVIÇOS (SOA).

2009 Florianópolis 2009

Israel Kraisch – Rodrigo Tomaselli

APLICAÇÃO DE TESTES DE SOFTWARE UTILIZANDO A ARQUITETURA ORIENTADA A SERVIÇOS (SOA)

Florianópolis (SC) Julho, 2009

Israel Kraisch – Rodrigo Tomaselli

APLICAÇÃO DE TESTES DE SOFTWARE UTILIZANDO A ARQUITETURA ORIENTADA A SERVIÇOS (SOA).

Trabalho de Conclusão de Curso apresentado à Banca Examinadora do Curso de Pós-Graduação em Engenharia de Software com UML da Faculdade de Tecnologia do SENAI/Florianópolis como requisito parcial para obtenção do título de especialista em Engenharia de Software sob a orientação do Professor MSc. Sergio Akio Tanaka.

Florianópolis (SC) Julho, 2009

Israel Kraisch – Rodrigo Tomaselli

APLICAÇÃO DE TESTES DE SOFTWARE UTILIZANDO A ARQUITETURA ORIENTADA A SERVIÇOS (SOA)

Trabalho de Conclusão de Curso apresentado à Banca Examinadora do Curso Engenharia de Software com UML da Faculdade de Tecnologia SENAI Florianópolis em cumprimento a requisito parcial para obtenção do título de especialista em Engenharia de Software.

APROVADA PELA COMISSÃO EXAMINADORA EM FLORIANÓPOLIS, 15 DE NOVEMBRO DE 2009.

Prof. Carlos Martins, Dr., (SENAI/SC) Coordenador(a) de TCC

Prof. Sergio Akio Tanaka, MSc., (SENAI/Florianópolis)

Orientador(a)

Prof. Ruy Tsutomu Nishimura, MSc., (SENAI/Florianópolis)

Examinador

DEDICATÓRIA

Para nossas esposas Anelise e Taís. Obrigado por seu amor e apoio.

AGRADECIMENTOS

Agradecemos a Deus por nos ter dado a vida, inteligência e saúde para termos condições de realizar mais esta etapa de nossas vidas.

Aos nossos pais e familiares e, principalmente, as nossas esposas e filhos pelo apoio nos momentos de dificuldade, pela compreensão nos momentos de nervosismo e nas horas em que estivemos ausentes para a dedicação ao estudo e pelo interesse em nossa formação.

Aos mestres que contribuíram para nossa formação.

Aos colegas de classe pelas contribuições e troca de experiências.

A Autus Informática Ltda, empresa onde trabalhamos e que nos incentivou a realizar este curso, e pelo constante incentivo ao desenvolvimento pessoal e profissional aos seus colaboradores.

EPÍGRAFE

“O futuro tem muitos nomes. Para os fracos é o inalcançável. Para os temerosos, o desconhecido. Para os valentes é a oportunidade.” Victor Hugo

Kraisch, Israel – Tomaselli, Rodrigo. Aplicação de Testes de Software utilizando a arquitetura orientada a serviços (SOA). Florianópolis, 2009. 78f. Trabalho de Conclusão de Curso de Pós Graduação Latu Sensu - Curso Engenharia de Software com UML. Faculdade de Tecnologia do SENAI, Florianópolis, 2009.

RESUMO Este trabalho apresenta a aplicação de testes sobre programas componentizados, utilizando a arquitetura orientada a serviços (SOA). Através de um estudo de caso apresenta-se neste, os conceitos da tecnologia SOA, e de testes de software. As ferramentas utilizadas na aplicação dos testes foram SOAP-UI devido a sua documentação que é de fácil entendimento e sua disponibilidade gratuita; e as normas IEEE 829 e IEEE 730 - 1998, por conter as regras básicas para direcionar os testes de software, bem como os artigos e publicações que compõem a bibliografia, e auxiliaram no entendimento do escopo do trabalho realizado. O ensaio foi aplicado ao conjunto de programas que compõem um produto de CRM de uma empresa da região de Joinville, que no momento da realização deste trabalho, não possuía documentações técnicas sobre seus componentes, e nem procedimentos ou documentos de teste, a não ser procedimentos empíricos realizados de forma manual. Os métodos utilizados para o ensaio foram baseados no entendimento da tecnologia SOA, das técnicas de teste e das ferramentas pesquisadas. Como resultado, da pesquisa, o teste foi realizado aplicando-se principalmente a técnica de caixa branca, onde foi necessário recorrer ao fonte dos programas para realizar os procedimentos de teste, e utilizamos a ferramenta SOAP-UI para criar os cenários e a execução dos testes, bem como a documentação técnica necessária para o entendimento dos componentes do aplicativo de CRM. Com a realização deste trabalho, foi possível entender melhor os conceitos de SOA e de testes, e identificar que “testar SOA” exige planejamento, muito conhecimento técnico, principalmente das linguagens de programação utilizadas, e das regras de negócio que compõem cada componente do conjunto de programas. Com este trabalho identificou-se que a ferramenta utilizada não seria a ideal, e instigou-se a busca e a análise de novas ferramentas para testes não só para o aplicativo de CRM, mas para os demais programas que a empresa onde este trabalho foi realizado. Palavras-chave: SOA; Integração; WebService.

ABSTRACT

This paper presents the application of testing on component based programs using the service-oriented architecture (SOA). The concepts of SOA technology, and software testing are presented through a case study . The tools used on the tests were: SOAP-UI because of its easy to understand and free documentation; the IEEE standards 829 e IEEE 730 - 1998 because they contain the basic rules to guide the software testing; were also used articles and publications that make up the blibliografy and assisted in understanding of the scope of work. The test was applied to the set of programs that make up a CRM product, which, at the time of this work, did not have technical documentation on components and documents or procedures on testing, except for empirical procedures performed manually. The methods used for the test were based on the understanding of SOA technology the testing techniques and tools surveyed. As a result of the research, the test was performed mainly by applying the white box technique, where it was necessary to supply the programs to perform the testing procedures,and use the tool SOAP-UI to create scenarios and run tests, and the documentation necessary for the technical understanding of CRM application components. With this work, we are able to better understand the concepts of SOA and testing, and identify that "SOA testing " requires planning, much technical knowledge, especially of the programming languages used and the business rules that make up each component of all programs. This study identified that the tool used was not ideal, and urged for a search and analysis of new tools for testing not only for the CRM application, but for other programs on the company where this work was performed. Key words: SOA; Integration; WebServices.

LISTAS DE ABREVIATURAS E SIGLAS

BPO – Business Process Outsourcing HTML – HyperText Markup Language OO – Orientado a Objeto QA – Quality Assurance SSL – Secure Sockets Layer SOAP – Simple Object Access Protocol UML – Unified Model Language XML – Extensible Markup Language W3C – World Wide Web Consortium WSDL – WebServices Description Language UDDI – Universal Discovery, Description and Integration TI – Tecnologia da Informação DDT – Test-Driven Development

LISTAS DE ILUSTRAÇÕES (FIGURAS, TABELAS E QUADRO) Figura 1 – Esquema demonstrativo adaptado, do paradigma de FIND-BIND-EXECUTE – Fonte: Dos Autores (2007) ....................................................................................................... 24 Figura 2 – Camadas de abstração do SOA - Fonte: Dos Autores (2009)................................. 25 Figura 3 – Modelo de abstração de SOA para equipes de TI – Fonte: Dos Autores (2009) .... 28 Figura 4 – Interação tradicional entre browser e servidor web. Fonte: Dos Autores (2007) ... 30 Figura 5 - Interação entre browser e um WebService – Fonte: Dos Autores (2007) ............... 31 Figura 6 – Ambiente de execução dos testes – Fonte: Dos Autores (2009)............................. 45 Figura 7 – Ambiente de execução dos testes II – Fonte: Dos Autores (2009). ........................ 48 Quadro 1 – Requisição SOAP Com parâmetros incorretos......................................................40 Quadro 2 – Resposta de Requisição SOAP Incorreta..............................................................41 Quadro 3 – Requisição correta ao método verifyAccountAcces.............................................42 Quadro 4 – Resposta a requisição ao método verifyAccountAcces, permitindo o acesso.......43

SUMÁRIO

INTRODUÇÃO .......................................................................................................... 12 1.1 DELIMITAÇÃO DO TEMA ................................................................................... 13 1.2 OBJETIVOS............................................................................................................. 13 ESTA SEÇÃO APRESENTA OS OBJETIVOS GERAIS E ESPECÍFICOS DO TRABALHO ........................................................................................................................ 13 1.3 JUSTIFICATIVA ..................................................................................................... 14 1.4 METODOLOGIA..................................................................................................... 15 1.5 TIPO DA PESQUISA .............................................................................................. 16 2 REVISÃO DE LITERATURA.................................................................................. 17 2.1 DESAFIOS EMPRESARIAIS NO CENÁRIO ATUAL ......................................... 17 2.2 A ARQUITETURA ORIENTADA A SERVIÇOS (SOA)...................................... 20 2.3 SOA E MUNDO DOS NEGÓCIOS ......................................................................... 33 2.4 TESTES DE SOFTWARE ....................................................................................... 34 2.5 DESENVOLVIMENTO ORIENTADO POR TESTES .......................................... 40 2.6 CONSIDERAÇÕES SOBRE O CAPÍTULO .......................................................... 41 3 RESULTADOS E DISCUSSÕES ............................................................................. 43 3.1 EXPERIMENTOS.................................................................................................... 44 3.2 CONSIDERAÇÕES SOBRE O CAPÍTULO .......................................................... 49 4 CONCLUSÕES E RECOMENDAÇÕES ................................................................ 51 4.1 CONSIDERAÇÕES FINAIS ................................................................................... 52 REFERÊNCIAS ..................................................................................................................... 53 APÊNDICES ........................................................................................................................... 56 ANEXOS ................................................................................................................................. 75

INTRODUÇÃO

A demanda por programas, cada vez mais integrados e cujos processos sejam os melhores possíveis, tem tornado a área de Tecnologia da Informação (TI) das empresas cada vez mais complexa, ou seja, são muitos conjuntos de programas envolvidos em processos sistêmicos, além dos recursos de hardware que demandam cada vez mais infra-estrutura para executá-los. Nos dias atuais, um produto ou serviço deve ser o máximo possível flexível e adaptável às necessidades de cada cliente, ou seja, feito sob medida. Tal demanda traz consigo, o desafio de integração entre produtos e serviços oferecidos, bem como a integração dos processos e sistemas internos.

Como proposta de solução, para resolver este cenário caótico em que se busca a integração de diversos conjuntos heterogêneos de programas, para as mais diversas áreas de negócio, surge à arquitetura baseada em serviços services oriented architecture (SOA). A tecnologia tem como objetivo facilitar a integração destas aplicações através da exposição de serviços, que podem ser acessados diretamente por qualquer outro aplicativo, desde que este tenha o acesso e respeite a padronização necessária.

Conhecer SOA e o que a tecnologia propõe, permitirá às empresas fornecedoras de sistemas de informação, bem como aos seus clientes, a descoberta de novas maneiras para diferenciar suas empresas na atual economia globalizada, e instigar as mesmas a buscarem novas estratégias de concorrência.

Com o tempo de ciclo de vida dos produtos cada vez menor, dado às demandas cada vez mais crescentes pela personalização as empresas têm que estar preparadas para criar, dispor e conseguir o retorno do investimento de modo rápido sob pena de perder oportunidades, deixando a concorrência livre para absorver esta demanda.

A necessidade de velocidade e eficiência nestas adaptações traz desafios para as áreas de TI das empresas e seus fornecedores de software, principalmente o de entregar programas

cada vez mais confiáveis, estáveis e com o nível de qualidade ditado pelo cliente, tanto dos produtos como do atendimento das necessidades e seus anseios. O destaque crescente do software como elemento de sistema e os “custos” envolvidos associados às falhas destes são forças propulsoras para uma atividade de teste cuidadosa e bem planejada. É comum uma empresa fabricante deste tipo de produto, gastar até 50% do esforço de projeto total em teste. O presente trabalho versa sobre a aplicação de metodologias de testes sobre aplicações construídas, integradas ou que estejam expostas na forma usual da tecnologia SOA, bem como gera uma pesquisa das metodologias de teste e ferramentas existentes, e que sejam aplicáveis à tecnologia. Esta pesquisa irá apresentar os conceitos de SOA, testes, a importância destes dois conceitos no âmbito das empresas, bem como trará informações sobre as ferramentas, métodos e a própria tecnologia.

1.1 DELIMITAÇÃO DO TEMA Testes unitários de programas componentizados, baseados em SOA.

1.2 OBJETIVOS Esta seção apresenta os objetivos gerais e específicos do trabalho

1.2.1 Objetivo Geral Este trabalho tem como principal objetivo “Compreender como pode ser testado um componente de software desenvolvido utilizando SOA”. Para atingí-lo, espera-se antes alcançar os objetivos específicos listados no tópico seguinte.

1.2.2 Objetivos Específicos a) identificar a diferença da arquitetura SOA de outras arquiteturas de software; b) pesquisar metodologias de auditoria e testes aplicáveis a SOA;

c) pesquisar e estudar as ferramentas que podem ser utilizadas para aplicar os testes.

1.3 Justificativa Em uma empresa da região de Joinville, existe um conjunto de programas que contém uma camada SOA chamado de CRM, na qual já se tentaram aplicar testes de verificação das unidades, regras de negócios e do sistema integrado de componentes. Porém, as ferramentas empregadas exigiram um alto custo e mão de obra que necessitou ser treinada durante a aplicação dos testes. Isto acabou por não apresentar o resultado esperado e a concepção original do projeto abandonada. É válido ressaltar que fatores externos, como a complexidade do ambiente devido à componentização, a instabilidade devido ao volume de manutenções e retrabalhos, demandas de implementação por parte dos stakeholders para a evolução do produto, também contribuíram para a inviabilização do projeto. O principal motivo da realização deste trabalho é que atualmente, a aplicação é testada manualmente, e não há a assertividade e qualidade esperadas, não existem também técnicas bem como processos definidos para a realização dos testes. O que existe é um procedimento empírico e sem garantia satisfatória, baseado em cenários predefinidos. O resultado deste trabalho poderá servir de base para a aplicabilidade de testes unitários utilizando ferramentas que possibilitem assertividade e qualidade no processo de manutenção do conjunto de programas, bem como para a definição de procedimentos e técnicas que possam auxiliar a equipe de auditoria na difícil tarefa de testar e recolher resultados que possam identificar as falhas para a tomada de ações buscando a garantia da qualidade do produto, além de sugerir mudanças na metodologia de desenvolvimento demonstrando o processo de desenvolvimento orientado por testes. No intuito de facilitar os testes e aplicar uma melhor qualidade a este software propõese o estudo de ferramentas para verificar a possibilidade de uso. O entendimento de SOA em si é uma das maiores dificuldades, pois ela não é um simples código de programa que se possa classificar (como pode ser feito com programação estruturada e orientada a objeto), mas sim, todo um conjunto de regras para o desenvolvimento de uma aplicação.

O capítulo 2 apresenta os principais conceitos utilizados neste trabalho, tais como, a arquitetura SOA, onde se abordou o impacto do uso de sofware baseado nesta arquitetura, suas vantagens e desvantagens, os principais desafios no uso de SOA, o cenário atual das empresas e das equipes de TI com relação ao uso de programas componentizados bem como métodos de teste aplicáveis a tecnologia, como testar e porque testes são importantes para as empresas na atualidade. O capítulo 3 apresenta os resultados e discussões, a pesquisa e a escolha de ferramentas para o uso como ensaio de testes de componentes de software baseados em WebService utilizando-se da arquitetura SOA, também neste capítulo é demonstrado um teste unitário utilizando a ferramenta escolhida. Finalmente no capítulo 4, apresenta-se a conclusão e recomendações, onde apesar do estudo para a busca de soluções em que se pudessem testar a camada SOA do aplicativo de CRM de maneira mais assertiva, concluiu-se que as dificuldades que se apresentaram foram as mesmas já enfrentadas e justificadas, e que a ferramenta utilizada também não seria a ideal, onde recomenda-se um novo estudo da aplicabilidade de testes de software com uma nova proposta apresentada pela equipe de testes e auditoria da empresa onde este trabalho fora realizado.

1.4 METODOLOGIA Esse capítulo tem como objetivo apresentar as técnicas de pesquisas para o desenvolvimento do presente trabalho. Para a seqüência desta pesquisa, pretende-se cumprir as etapas relacionadas abaixo: a) Entender o que significa o conceito de “orientação a serviço” b) Compreender a arquitetura SOA c) Entender os protocolos envolvidos d) Conhecer metodologias de auditoria e testes e) Pesquisar ferramentas que podem ser utilizadas para aplicar os testes f) Verificar a aplicabilidade das metodologias de auditoria e testes estudadas, a arquitetura SOA utilizando as ferramentas pesquisadas g) Verificar possibilidade de automação dos testes utilizando as ferramentas estudadas.

1.5 Tipo da Pesquisa A pesquisa foi desenvolvida seguindo os procedimentos técnicos relativos à pesquisa bibliográfica e experimental. Bibliográfica, visto que se baseia na leitura e estudo de livros, artigos, e internet. E experimental, onde para o desenvolvimento das etapas relacionadas, selecionam-se as variáveis que seriam capazes de influenciá-lo, definem-se as formas de controle e de observação dos efeitos que a variável produz no objeto. Para Lakatos e Marconi (2003), pesquisa de campo é "aquela utilizada com o objetivo de conseguir informações e/ou conhecimentos acerca de um problema, para o qual se procura uma resposta, ou uma hipótese, que se queira comprovar, ou, ainda, descobrir novos fenômenos ou as relações entre eles". Segundo Gil (1999) as pesquisas de campo exploratórias e descritivas visam proporcionar maior familiaridade com o problema em questão, tornando público o objetivo de descrever as características de determinada população se torna mais objetivo, envolvendo o uso de técnicas padronizadas de coleta de dados, questionários e observação sistemática. Quanto a sua natureza, essa pesquisa será de caráter básico, pois objetiva gerar conhecimentos novos úteis para o avanço da ciência sem aplicação prática prevista, envolvendo verdades e interesses universais. Como forma de abordagem do problema, a pesquisa será do tipo qualitativa pois, segundo Gil(2002), a interpretação dos fenômenos e a atribuição de significados são básicas no processo de pesquisa qualitativa e não requer o uso de métodos e técnicas estatísticas. Os passos para a obtenção dos resultados podem ser definidos de maneira relativamente simples. A análise qualitativa depende de muitos fatores, como a natureza dos dados coletados, a extensão da amostra, os instrumentos de pesquisa e os pressupostos teóricos que nortearam a investigação. Do ponto de vista de seus objetivos, esta pesquisa é, em sua essência, descritiva, tratando-se da observação sistemática e da realização de levantamentos necessários para o entendimento de suas etapas.

REVISÃO DE LITERATURA Este capítulo visa contextualizar o leitor quanto aos desafios, tanto técnicos como de

negócio, enfrentados pelas empresas e suas equipes de Tecnologia da Informação (TI); aborda a proposta de SOA como sugestão para minimizar estes desafios, e apresenta os principais conceitos sobre testes de software.

2.1 Desafios Empresariais no cenário atual No cenário atual, em que as empresas estão sob forte competitividade, o sucesso de uma empresa depende da agilidade, de como são realizadas suas atividades, principalmente as ligadas à tecnologia da informação (TI). A demanda por aplicativos, cada vez mais integrados e cujos processos sejam os melhores possíveis, tem tornado a área de TI das empresas cada vez mais complexa, ou seja, são muitos conjuntos de programas envolvidos em processos sistêmicos, além dos recursos de hardware que demandam cada vez mais infra-estrutura para executá-los. Segundo Benedete Junior (2007), para a evolução, e em muitos casos para a própria sobrevivência, as empresas enfrentam cada vez mais desafios, dentre eles citados: a) concorrência – novas empresas trazem novas idéias, produtos concorrentes geralmente com estruturas menores, obrigando as empresas já estabelecidas a se renovarem; b) globalização – a concorrência já não é apenas local, empresas de porte internacional podem fazer frente, comprar antigos concorrentes, o contrário também é válido, ou seja, empresas locais expandindo seus negócios para novos mercados, adaptando-se a culturas e leis onde se fizerem presentes; c) aquisições e incorporações – para enfrentar a concorrência, as empresas utilizam estratégias de modo a aumentar seu porte adquirindo concorrentes, ou produtos e serviços complementares. Trazem, com isso, desafio de integração entre produtos e serviços oferecidos, bem como a integração dos processos e sistemas internos;

d) clientes mais exigentes – nos dias atuais, um produto ou serviço deve ser o máximo possível flexível e adaptável às necessidades especificas de cada cliente, ou seja, feito sob medida, une-se a esta condição o alto nível de qualidade tanto dos produtos como do atendimento das necessidades e anseios do cliente, para estes casos, as empresas se utilizam de mecanismos e estratégias de gerenciamento do relacionamento com o cliente – CRM; e) menor tempo de vida dos produtos e serviços – com o tempo de ciclo de vida dos produtos cada vez menor, dado às demandas cada vez mais crescentes pela personalização citada no item anterior (d), as empresas têm que estar preparadas para criar, dispor e conseguir o retorno do investimento de modo rápido sob pena de perder oportunidades, deixando a concorrência livre para absorver esta demanda; f) integração com clientes, parceiros e fornecedores – A cadeia produtiva da empresa depende de insumos, produtos e serviços que devem estar integrados e de forma confiável. Uma empresa pode fazer parte da cadeia produtiva de seu cliente ou até de seu fornecedor, sendo fundamental a capacidade de se integrar rapidamente, para aproveitar oportunidades de negócio; g) normas, regulamentos, inspeções – os processos internos e resultados devem ser transparentes, confiáveis e conformes com as leis, regras e melhores práticas de mercado para que a empresa possa acessar a novos mercados.

Esses fatores fazem com que as empresas estejam em constante processo de evolução e adaptação às novas realidades do negócio. A necessidade de velocidade e eficiência nestas adaptações traz mais um desafio: O relacionamento interno das áreas de negócio da empresa com a sua equipe de TI. As empresas dependem de suas áreas de tecnologia para projetarem seus novos produtos, produzí-los, para se relacionar com seus clientes e fornecedores, e para conduzir e evoluir seus processos internos. Uma área de TI ágil pode contribuir significativamente para que o negócio possa fazer frente aos desafios do mercado. Entretanto, o que normalmente se vê é uma TI não

suficientemente alinhada ao negócio, o que pode limitar a evolução da empresa e fazê-la perder oportunidades.(BENEDETE, 2007).

2.1.1 Desafios no âmbito da Tecnologia da Informação A maioria das empresas que constroem, e mesmo as que solicitam novos programas, não conseguem ainda separar os processos (regras de negócio) das demais funções do aplicativo, construindo assim aplicativos que não podem ser componentizados e reutilizáveis. De acordo com (NEXTG, 2007) as equipes de TI são constantemente desafiadas a atender as necessidades de negócio e tecnologia das empresas, estes desafios são causados por: a) aumento da demanda – o negócio sempre precisa de novos sistemas, novas funcionalidades. As equipes de TI das empresas geralmente, não conseguem dar vazão aos projetos, criando “filas” de atendimento. O que gera oportunidades como a BPO. Apesar dos esforços em novas metodologias e ferramentas de desenvolvimento, a produtividade baseada nas tecnologias atuais ainda não é suficiente; b) prazos curtos – outrora, sistemas costumavam levar anos para serem entregues. Com o advento da Internet e ferramentas colaborativas, os prazos têm se reduzido, chegando a ocorrer necessidades que devem ser atendidas em poucos dias; c) qualidade – sistemas que são executados em modo “batch” (envolvendo grandes lotes de registros, sem interação com o cliente, geralmente executados no período noturno) já não são aceitáveis, não há espaço nem tempo para erros, ou re-processamentos, em caso de falhas. Hoje, praticamente todos os sistemas estão “on-line”, com clientes aguardando o resultado, em tempo real. Uma falha pode resultar em grande perda monetária e de imagem para a empresa; d) disponibilidade – com foco em atendimento local, os sistemas normalmente tinham um intervalo de tempo em que ficavam “fora do ar” (a janela “batch”). A equipe de TI utilizava este intervalo para gerar cópia das bases de dados, disponibilizar alterações e manutenções nas aplicações, sem causar impacto

para os clientes. Hoje, os sistemas são acessados de qualquer lugar do mundo e os clientes trabalham a qualquer hora e não mais limitados ao “horário comercial”, ou seja, os sistemas devem estar onipresentes e disponíveis. A disponibilidade destas aplicações e da infra-estrutura de base é constantemente monitorada e medida em frações, entre 99,97% e 99,99%; e) integração – aqui o desafio é integrar sistemas construídos em épocas, com tecnologias, padrões e plataformas diferentes entre si, o que costuma consumir grande parte dos investimentos, para que conjuntos sistemas construídos pela TI das empresas, pacotes adquiridos do mercado, aplicações incorporadas na aquisição/fusão com outras empresas e sistemas externos (de clientes, parceiros ou fornecedores) funcionem de modo integrado; f) novas tecnologias – ferramentas e tecnologias se tornam obsoletas em pouco tempo, e geram grande impacto em capacitação e atualizações de hardware, software e mesmo das aplicações, obrigando as equipes de TI à atualização constante; g) custos – para manter a empresa competitiva, as equipes de TI, devem procurar aumentar a produtividade e diminuir os custos, sempre analisando o mercado em busca de ferramentas que possam auxiliar os usuários dos sistemas e automatizar tarefas; h) controles – mecanismos de controle e monitoração são necessários para aferir e garantir atributos como segurança, qualidade e conformidade com normas do mercado e com acordos de nível de serviço (SLA), que cada vez mais regem o relacionamento (prestação de serviços) entre a empresa e seus clientes e parceiros. O conceito de SOA vem justamente ao encontro destas necessidades, ou seja, flexibilizar a arquitetura para que não seja necessário descartar um aplicativo e seu legado, bastando que se construa um serviço que possa acessá-lo, aproveitando assim, senão o todo, pelo menos partes deste sistema, com SOA é possível fazer o re-uso de software, o que reduz o esforço de desenvolvimento de novas aplicações, diminuindo custos, atendendo com mais agilidade novos requisitos de negócios (NEXTG, 2007).

2.2 A Arquitetura Orientada a Serviços (SOA)

Quando se ouve falar em SOA (“Service Oriented Architecture” ou “Arquitetura Orientada a Serviços”), normalmente o termo é associado à tecnologia WebService (esta será descrita mais adiante).

2.2.1 Conceituando SOA A Arquitetura Orientada a Serviços, como o próprio nome diz é uma “arquitetura”, ou seja, um conjunto de princípios, padrões e orientações que englobam desde a visão de negócio até suas possíveis alternativas tecnológicas(BENEDETE, 2007). SOA reuniu os esforços dos principais provedores de tecnologia (como a IBM®, Microsoft®, SAP®, Oracle®) em torno de um conjunto de padrões e tecnologias que tornam possíveis a interoperabilidade e re-uso de aplicações, independentemente de linguagens e plataformas de hardware ou software(BIEBERSTEIN, 2006). A arquitetura descreve uma categoria de aplicativos compostos cujo princípio fundamental é que suas funcionalidades sejam implementadas e disponibilizadas na forma de serviços, fracamente acoplados, orquestrados e organizados em um “barramento de serviços” formados pelos componentes: provedor de serviços, que disponibiliza contratos; interfaces acessíveis através de WebService (ou outra forma de comunicação baseada em computação distribuída utilizando o paradigma de request/reply) e o consumidor de serviço, separando a lógica comercial e oferecendo transparência de local para provedores e consumidores de serviços. A definição de SOA deve ser ajustada ao público alvo, ou seja, para as equipes de negócio, deve-se enfatizar a flexibilidade na adaptação e disponibilização de novos negócios, baseados em processos e serviços bem definidos, já para o pessoal de tecnologia, devem-se detalhar os aspectos tecnológicos, para não tornar a definição abstrata ou abrangente demais.

2.2.2 Algumas definições, e termos de SOA: • Arquitetura – “A arquitetura de software de um programa ou sistema computacional é a estrutura ou estruturas do sistema, as quais compreendem

elementos de software, as propriedades externamente visíveis desses elementos, e o relacionamento entre eles” (BASS, CLEMENTS, KAZMAN., 2003). “Ou seja, arquitetura são modelos e padrões que permitem documentar, facilitar o entendimento e direcionar as diversas dimensões da construção das aplicações, como exemplos, a localização e armazenamento dos dados, os mecanismos com que os usuários interagem com os sistemas e como os programas se conversam ”(BENEDETE, 2007). • WebService – “É uma família de tecnologias que consistem de especificações, protocolos e padrões da indústria, cujo objetivo é permitir que aplicações (mesmo baseadas em diferentes plataformas de hardware e software ou linguagens) possam se comunicar de uma maneira segura e consistente. WebService é uma implementação tecnológica dos conceitos de SOA e, por isso, normalmente se confunde com a mesma ”(BENEDETE, 2007). • Processos de negócio – “É um conjunto de tarefas logicamente relacionadas para se obter um resultado de negócio definido”(BIEBERSTEIN, 2006). A Gartner define processo de negócio, como “Um conjunto de atividades e tarefas executadas por recursos (pessoas e sistemas) usando uma variedade de informações (documentos, imagens, conhecimento), interagindo de várias maneiras (seqüencialmente ou de maneira não prevista), guiadas por políticas e princípios (objetivos, regras de negócio)”.(AREVOLO, 2006). • Serviços – Do ponto de vista do negócio, são as funcionalidades providas pela empresa para seus clientes e parceiros, por exemplo, um serviço de saque, um serviço de abertura de contas. Do ponto de vista de TI, trata-se de um componente de aplicação cujas funcionalidades estão disponíveis para outros sistemas ou usuários.(BENEDETE, 2007). • Componentes – “São pedaços de software que podem ser reutilizados, pois foram desenvolvidos com esta preocupação (interface padrão e outras regras) ”(BENEDETE, 2007). • Reutilização – “O re-uso é um dos pilares da SOA, pois é ele que possibilita o ganho de velocidade na construção de novas aplicações, a redução dos custos e aumento da qualidade, através do reaproveitamento de componentes prontos, testados e confiáveis” (BENEDETE, 2007).

• Caixa-preta – São componentes que podem ser utilizados por outras aplicações, sem que haja preocupação de como foram construídos (tecnologias, linguagens) (BENEDETE, 2007). • Fracamente acoplados – É uma abordagem para construção de aplicações que foca na simplicidade e autonomia entre os componentes. Os programas interagem (trocam dados) de uma maneira que a dependência entre eles é minimizada, facilitando a alteração ou mesmo a troca de um deles (BENEDETE, 2007). • Orquestrados – As ferramentas que compõe a infra-estrutura SOA provêm componentes para gerenciar (orquestrar) as interações (fluxo) entre os serviços dentro de um processo de negócio.(BENEDETE,2007). • Nível de serviço – “São acordos que definem características de como o serviço deve ser provido, por exemplo: tempo de resposta, disponibilidade e quantidade de falhas. A definição dos níveis de serviço está diretamente ligada às melhores práticas da gestão de processos de negócio ”(BENEDETE,2007). • Framework – É uma estrutura básica de software e padrões, construída para auxiliar

organizar

modo

desenvolver

outras

aplicações

(BENEDETE,2007). • Uso de padrões – Embora conceitualmente SOA possa ser implementado com qualquer tecnologia, o uso das tecnologias como WebService é fator que difere e pode garantir o sucesso da SOA frente a outras abordagens e arquiteturas orientadas à comunicação distribuída. SOA está baseada no uso de padrões que são amplamente aceitos pela indústria de TI, e a maioria dos grandes fornecedores

software

ferramentas

para

desenvolvimento

está

gradativamente migrando suas ofertas de produtos não só para suportar SOA, mas também utilizá-la como solução interna para construção de seu software (BENEDETE,2007). Uma das mais importantes características sobre SOA é que ela libera o negócio das restrições da tecnologia, ou seja, "SOA permite aos responsáveis pela empresa a tomar decisões

negócio

suportadas

pela

tecnologia

invés

tomar

decisões

DETERMINADAS ou LIMITADAS pela tecnologia" (HURWITZ,2007). SOA pode ser bem representada a partir do processo, chamado de "find-bind-execute paradigm" o que significa aproximadamente paradigma de "procura-consolida-executa". Tal

conceito é análogo a "Ciclo de Deming" (PDCA) aplicado aos serviços, que define o ciclo que envolve o planejamento, a execução, o monitoramento e a tomada de ação pró-ativa para a melhoria da qualidade, exemplificado pela Figura 1:

Figura 1 – Esquema demonstrativo adaptado, do paradigma de FIND-BIND-EXECUTE – Fonte: Dos Autores (2007)

a) O usuário do serviço é a aplicação que solicita um serviço. A aplicação solicita através dos registros de serviço (contratos) as informações referentes à localização do serviço. O registro de serviço é uma aplicação que retorna as informações para uso de um serviço; b) O provedor de serviços funciona de forma semelhante a um sistema de páginas amarelas de uma lista telefônica, oferecendo os serviços para que possam ser encontrados de forma fácil. Como exemplo a arquitetura tem-se um E-commerce qualquer. A requisição é realizada através de um cliente. O cliente que pode ser um navegador internet qualquer, este solicita o preço de um determinado produto, o WebService recebe e processa o pedido e retorna uma resposta contendo o preço do produto. A abordagem SOA permite substituir ou atualizar componentes individuais no aplicativo sem afetar outros componentes ou o processo como um todo. Além disso, podem-se especificar independentemente caminhos alternativos através dos quais os componentes do aplicativo trocam mensagens (NETBEANS, 2009).

2.2.3 Camadas de abstração da SOA Modelos de abstração facilitam o entendimento de conceitos por organizarem idéias, funcionalidades e documentações no nível de detalhe mais adequado para cada tipo de necessidade. A Figura 2 mostra as diversas camadas que compõe a SOA e pode ser utilizada para descrever o conceito para as equipes de negócio de maneira a propor o claro entendimento de como funciona a arquitetura, facilitando a apresentação da arquitetura a equipes de negócio.

Figura 2 – Camadas de abstração do SOA - Fonte: Dos Autores (2009)

a) camada corporativa – descreve o negócio da empresa, identifica os processos de negócio chave da empresa - que são essenciais para sua vantagem competitiva - e que, portanto, devem ser controlados da maneira mais próxima possível; e os processos de suporte, que podem até ser delegados para

parceiros. Há diversos frameworks, a exemplo do framework de Zachman disponível no Anexo I (ZACHMAN,2008) ...“publicado no livro “A Framework for Information Systems Architecture” em 1987 de autoria de Zachman, em que o autor, introduzia o conceito de arquitetura de sistemas de informação. As idéias propostas resultaram de conhecimentos e experiências de outras disciplinas mais antigas (arquitetura, engenharia da produção) e rapidamente se tornaram numa referência para todos aqueles que têm algum interesse no tema da arquitetura de sistemas de informação. Infelizmente, e apesar da relevância do tema, muitos destes conceitos continuam desconhecidos entre as equipes de TI. De acordo com autor, a arquitetura é o “conjunto de representações descritivas (modelos) relevantes para a descrição de um objeto, de forma a que este possa ser construído de acordo com os requisitos (de qualidade) e mantido ao longo da sua vida útil”. Esta definição é consideravelmente genérica e informal e não indica o âmbito do termo arquitetura; de fato, no caso da abordagem proposta por Zachman, ela refere-se quer aos sistemas de informação quer à empresa, uma vez que o mesmo modelo apresenta relativamente a cada conceito a perspectiva do negócio e dos sistemas de informação. O Framework de Zachman é uma estrutura lógica de classificação e apresentação dos modelos de uma organização relevantes para a respectiva gestão, bem como para o desenvolvimento dos seus sistemas...”...” Nesta perspectiva, modelar um sistema significa determinar e representar um conjunto de informação, sobre vários tópicos (colunas da matriz), relevante para vários intervenientes (linhas da matriz).”... (SILVA, A. M. R.; VIDEIRA C. A. E.,

2001) e metodologias que se aplicam a camada corporativa, mas SOA introduz novos artefatos e considerações de arquitetura, principalmente por habilitar o estabelecimento de parcerias (clientes, fornecedores) nas camadas de processo e serviço; b) camada de processos – nesta camada é que os processos de negócio são identificados e caracterizados. Cada processo é único no atendimento de uma determinada área funcional e pode ser composto de diversos sub-processos. Os sub-processos podem ser decompostos para expor suas dependências da camada de serviço. Como se podem confundir os conceitos de serviço e de processo de negócio, considera-se que os processos são definidos uma única vez e usados dentro de um contexto único, já os serviços podem ser reaproveitados em diversos contextos com diferentes processos de negócio, departamentos ou linhas de negócio; c) camada de serviços – é responsável por mapear os serviços que provêm às funcionalidades básicas, técnicas e de negócio. O negócio identifica as funções críticas para atender o negócio, como identificação do cliente ou cálculo de taxas, enquanto os especialistas de TI criam funções técnicas para suportar os requisitos do negócio, como serviços de segurança;

d) camada de componentes – é a camada onde são mapeados os componentes que têm potencial para se transformarem em serviços, normalmente através de técnicas “bottom-up” (análise das aplicações e identificação de funções que devem ser promovidas a serviços, por terem o potencial de servirem a mais sistemas). Componentes são os blocos de construção de serviços na arquitetura SOA e embora vários sejam construídos com esta finalidade, a maioria será reaproveitada a partir de aplicações já existentes, através de técnicas de encapsulamento; e) camada de objetos – esta camada identifica e caracteriza uma larga quantidade de classes de objetos, seus atributos e relacionamentos. Embora SOA reaproveite os conceitos de interface originados na orientação a objetos, ela o estende, pois tem-se que identificar que a classe não apenas é pública, ou seja, que pode ser utilizada por outras aplicações através de chamadas nativas da plataforma, mas sim que ela é importante o suficiente para ser promovida a componente/serviço, e assim pode ser chamada por mecanismos de maior poder de abstração, como WebService. Esta decisão muitas vezes envolve os cenários de uso da função, para balancear requisitos não funcionais como desempenho e desacoplamento.

Em contrapartida a Figura 3, provê as equipes de TI, uma demonstração da interação entre as camadas como um exemplo prático, aqui se abstrai ainda mais as camadas. Demonstra-se a interação entre as camadas de processos com a camada de serviços, seus componentes de serviço, a interação da camada de serviços com a camada de integração, seus sistemas legados e componentes.

Camada de Negócios

B2 B1 B5

B1 B5

B3 B4

Camada de Serviços

Camada de Integração

Figura 3 – Modelo de abstração de SOA para equipes de TI – Fonte: Dos Autores (2009)

2.2.4 O modelo WebService Os WebServices representam um novo modelo de arquitetura representando um grande avanço tecnológico. Propõem a comunicação por protocolos padrões como o HTTP e XML promovendo a evolução de serviços, onde às lógicas de negócio são expostas através de regras de programáticas (SOA-RM, 2009). Por definição, WebServices são serviços distribuídos na WEB que processam mensagens SOAP codificadas em XML enviadas através do protocolo HTTP. O principal motivo do crescimento desta tecnologia é devido ao SOA, que consiste em uma coleção de serviços autônomos identificados por URLs, com interfaces criadas através de WSDL e processamento de mensagens XML.

2.2.4.1 Vantagens do uso de WebServices Existem inúmeras vantagens no uso de sistemas baseados em WebService, principalmente por proporcionar de forma simples e rápida oportunidades que seriam impossíveis de serem concretizadas devido à alta complexidade e custo em outras tecnologias equivalentes. O sucesso de uso dependerá de uma boa avaliação e estudo para a aplicação desta tecnologia. Nem tudo pode ser resolvido através de WebService, mas em geral consegue-se: • integrar sistemas legados com baixo custo; • diminuir custos operacionais; • diminuir custo/tempo no desenvolvimento de sistemas; • aproximar-se mais com seus clientes e parceiros comerciais; • prospecção de novos mercados e negócios.

O que vai ao encontro da maioria das necessidades já expostas como desafios para as equipes de TI e para as empresas no cenário atual dos negócios. A arquitetura orientada a serviços difere de sistemas orientados a objetos (OO) e sistemas procedurais no que diz respeito à ligação entre os componentes. Em geral sistemas OO e procedurais são conectados através de chamadas baseadas em tipos e nomes e, em uma SOA, a ligação consiste na troca de mensagens - o que permite estabelecer restrições para o envio/recebimento de informações separando de forma clara a estrutura comportamental da estrutura de descrição. Como visto anteriormente, um WebService e uma aplicação de software que pode ser acessada remotamente através de diferentes linguagens e protocolos. Normalmente, um WebService e identificado através de urls como qualquer outra página web. Na maioria dos sistemas web a resposta a requisições na Internet é feita através de chamadas efetuadas por um navegador web, resultando no retorno de conteúdo em texto no formato HTML. A Figura 4 ilustra melhor esta interação:

Figura 4 – Interação tradicional entre browser e servidor web. Fonte: Dos Autores (2007)

Webservices e consumidores de WebService são geralmente associados a negócios do tipo B2B. Isto acontece quando a empresa que provê o serviço também é cliente de outro serviço. Os WebServices são projetados para suportar interação e interoperabilidade podendo ser, ou não, de arquiteturas diferentes. O acesso ao WebService é semelhante na forma de acesso tradicional à internet, a diferença encontra-se no conteúdo que é enviado na requisição do cliente e o retorno do servidor. Os clientes de um WebService enviam mensagens SOAP contendo chamadas a um método e parâmetros que por ventura sejam necessários. O servidor por sua vez interpreta esta chamada e retorna a informação XML resultante do processamento, conforme demonstrado na Figura 5. Por ser uma troca de dados em formato amigável pode ser transferida de um computador para outro não importando: • O tipo ou modelo de computador e/ou sistema operacional usado. • O lugar no mundo em que o servidor ou cliente se encontra. • A linguagem em que foi implementado o software cliente/servidor. • A necessidade de o cliente conhecer as versões de protocolos e software que estão sendo utilizadas no servidor.

Figura 5 - Interação entre browser e um WebService – Fonte: Dos Autores (2007)

2.2.4.2 Desvantagens do uso de WebServices Os WebServices resolveram importantes questões que eram, até então, de difícil solução na comunicação entre sistemas, porém, não é uma “solução mágica” e deve ser analisada quanto ao atendimento dos requisitos da aplicação a ser construída ou acoplada. Existem ainda questões polêmicas e não previstas pelo protocolo SOAP, dentre as quais a segurança, o suporte e as transações, a exemplo do artigo “SOA is dead; Log life Services“ em que a autora, apresenta o artigo como um obituário, indicando que SOA morreu no dia 01/01/2009, devido à recessão econômica mundial, e que apenas sobrevive, através dos diversos produtos gerados a partir da tecnologia, e que dependem de serviços, indicando inclusive que SOA fracassou e que não entregou, exceto em raras exceções, os benefícios que prometia, e que embora o termo que define SOA esteja morto, a exigência de arquitetura orientada a serviços é mais forte do que nunca. Esta mesma autora, dentre outros especialistas da área, estará presente no 2º Simpósio Internacional de SOA que realizar-se-á na Holanda,

nos dias 22 a 30 de Outubro deste ano para defender seu ponto de vista abordando o que chama de “A ressurreição de SOA”. (Manes, 2009) Como os serviços funcionam sobre o protocolo HTTP que por sua vez não é seguro, a única opção atualmente e agregar ao seu serviço o uso do SSL (secure socket layer). O SSL protege com boa segurança o envio de informações, porém, torna as transações mais lentas sendo, muitas vezes, inadequado a grandes volumes de transferência de dados. Não há garantia que determinada transação será completada em dependência de outras, principalmente se os provedores de serviços forem web services de fornecedores distintos. A falta de padrões também prejudica o desenvolvimento dos serviços, a autenticação, a comunicação de feedback dos resultados são itens que não estão totalmente padronizados e dependem das implementações de cada desenvolvedor. Desempenho é uma questão que também deve ser observada, visto que todo serviço trafega através da Internet. Como a velocidade de transmissão na Internet é variável e não se podem controlar, sistemas onde desempenho seja vital não são candidatos a adotarem esta tecnologia. O processamento envolvido é outro ponto crucial. Como os dados são trocados em formato XML, o que na pratica é um formato de texto, há grande consumo de processamento para a conversão dos dados. Se os dados forem complexos (como binários e imagens) a codificação e decodificação destes dados podem levar tempo, o que pode causar a impressão ao usuário de que o programa está “travado” ou ainda provocar a desconexão do serviço por limite de tempo de execução. Os web services herdam, por sua vez, as deficiências inerentes à implementação de SOA.

2.2.4.3 Itens básicos de uma implementação de Web services Basicamente, hoje, é possível implementar web service utilizando componentes prontos de grupos conhecidos no mercado, como o Apache Group que implementa componentes de código aberto, ou de fornecedores comerciais como Microsoft ou IBM, entre outros.

Em geral, podem ser desenvolvidos por qualquer linguagem de programação baseadas em sockets. Duas organizações importantes, O World Wilde Web Consortium (W3C) e a Organization for the Advancement of Structured Information Standards (OASIS) controlam e desenvolvem especificações e padronização para a arquitetura SOA e dos web services (entre outros), assim, se um software for construído dentro dos padrões recomendados por estas organizações, a troca de um fornecedor de software que utilize os padrões estabelecidos não deve causar impacto na operação do cliente, já que a estrutura base de provimento e utilização do serviços será a mesma. Existem cinco itens básicos nesta arquitetura: • HTTP: Hipertext Transport Protocol usado para transportar as informações pela rede ou internet. • XML: Extensible Markup Language é utilizada na de definição e semântica dos dados. • SOAP: Simple Object Access Protocol é o formato de mensagens para chamada de métodos remotos. • WSDL: Web services Description Language descreve as características oferecidas pelo serviço. • UDDI: Universal Discovery, Description and Integration descreve um tipo especial de registro que lista os web services na Internet. • Não se abordará cada item da implementação básica, até porque estão em constante adaptação sendo possível verificar cada tópico através das referências definidas pela W3C e pela OASIS, no Anexo II, encontra-se um mapa descrevendo como pode ser feita a implementação de web service explanado de forma abrangente.

2.3 SOA e mundo dos negócios Existente apenas acerca de seis anos (NEXTG, 2007), SOA ainda não é aplicada em sua essência. Apenas poucas empresas de grande porte estão realizando um movimento de conversão e ou adaptação, de suas aplicações para este novo conceito.

Uma recente previsão da Gartner diz que: “SOA será utilizada parcialmente em mais de 50% das novas aplicações de missão crítica e processos de negócio criados em 2007, e mais de 80% até 2010 (70% de probabilidade)” (NATIS, 2006). Também segundo a Gartner, “Organizações que comecem sua transformação para BPM durante 2006 e 2007 serão recompensadas pelo domínio de suas indústrias por volta de 2010. Ter uma arquitetura de processos (parte de uma arquitetura de negócios) e alinhar as iniciativas de BPM com as iniciativas de SOA são atividades chaves a serem realizadas em 2007”. Utilizando a abordagem SOA estão surgindo movimentos de terceirização da regras de negócio, originando os chamados Business Process Outsourcing – BPO, empresas especializadas em mapear, integrar, automatizar e aperfeiçoar programas e processos de negócio, e que executam os mais variados serviços, que uma organização não deseja ou não precisa executar com recursos próprios, para que estas organizações, possam concentrar seus investimentos no que realmente faz parte de seu core business.

2.4 Testes de Software Esta seção aborda a conceituação de Testes de Software buscando identificar maneiras e ferramentas para realizar testes em SOA, onde descreve-se os principais conceitos e termos relacionados ao processo de teste de software. Serão apresentados termos usuais apenas para conceituar o leitor e não serão discutidos em profundidade cada tópico apresentado. Em trabalho relacionado

(PERES, R.; NOGUEIRA, A. R., 2004), os autores apresentam

individualmente cada tópico conceituando testes de software com maior profundidade, os conceitos abordado também podem ser encontrados na normas IEEE 829 -1998 e IEEE 730 – 1998 (IEEE, 2009). A seguir apresentamos uma sintese baseada no trabalho relacionado e na norma de referencia citada, para a implementação de testes de software.

2.4.1 Nivelamento conceitual Teste é um conjunto de atividades que podem ser planejadas antecipadamente e conduzidas sistematicamente. Por essa razão, um gabarito para teste de software - um conjunto de passos no qual se podem alocar técnicas de projeto de casos de teste e métodos de

teste específico - deve ser definido para o processo de engenharia de software (PRESSMAN,1995; NEMETZ,1997). A atividade de teste de software é um elemento crítico da garantia de qualidade de software e representa a última revisão de especificação, projeto e codificação. O destaque crescente do software como elemento de sistema e os “custos” envolvidos associados às falhas de software são forças propulsoras para uma atividade de teste cuidadosa e bem planejada. É comum uma organização de software gastar até 50% do esforço de projeto total em teste. Esta é a razão que leva a maioria das pessoas a acreditar que o software não é bem testado antes de ser fornecido ao cliente. A seguir são citados alguns objetivos do teste de software de acordo com (BEIZER,1990; LINNENKUGEL,1990; MYERS,1979):

a) a atividade de teste é um processo, de executar um programa com a intenção de descobrir um ou vários erros; b) um bom caso de teste é aquele que tem uma elevada probabilidade de revelar um erro ou um conjunto de erros ainda não descoberto; c) para que um teste seja considerado bem-sucedido este deverá revelar um erro ainda não descoberto. Dentre as citações de (MYERS,1979) pode-se dizer que a atividade de teste de software é o processo de revisar especificações, projetos e programas com a intenção de descobrir erros. Alguns dos principais itens que são comuns aos autores e pesquisadores, referenciados neste trabalho, do assunto teste de software e que descrevem os fundamentos e princípios desta atividade estão relacionados abaixo (PRESSMAN,1995; CHANG,1999; ROCHA,2001; NIELSEN,1993; NEMETZ,1997):

a) a atividade de teste não prova a ausência de erros, apenas a existência dos mesmos; b) bons casos de teste são aqueles que encontram falhas no sistema até então não descobertas; c) bons casos de teste são projetados levando em conta os requisitos do projeto;

d) um critério que pode ser adotado para determinação do esforço a ser gasto na atividade de teste de software é verificar qual o grau de severidade das conseqüências ocasionadas pelo seu mau funcionamento; e) a probabilidade de encontrar um erro numa determinada parte do sistema é proporcional ao número de erros já encontrados nesta parte; f) o nível de esforço previsto para testes deve levar em consideração a integridade e criticidade do projeto, o custo por mau funcionamento, os requisitos de qualidade e acurácia especificados. g) os autores estudados em sua maioria, concordam que os programas devem, preferencialmente, ser testados por pessoas que não estão envolvidas no processo de desenvolvimento, mas sim por uma equipe independente. Pode ocorrer também a interação dos desenvolvedores com a equipe independente, justificando as decisões tomadas durante o projeto, ajudando também na revisão do projeto. Testes desafiam as suposições, riscos e as incertezas e trata-as por meio de demonstrações concretas e avaliações imparciais, evitando abordagens que não avaliem o software de forma adequada e efetiva, expondo os problemas e pontos fracos e, não abordagens negativas ou destrutivas (PERES, R.; NOGUEIRA, A. R., 2004).

Para que testes de software possam ser aplicados, na busca de atingir os objetivos e princípios da atividade conforme já descritos acima, foram ao longo do tempo criadas e aperfeiçoadas metodologias que descrevem as melhores práticas para “testar software”, como se analisará.

2.4.1.1 Termos usuais: COQ - Cost of Quality, custo gasto em atividades relacionados ao processo de garantia de qualidade. O COQ inclui o custo de prevenção, medição, correção, materiais, equipamentos, etc.

Caso de Teste - conjunto de passos que descrevem um cenário de teste cuja principal função é comparar as respostas aos estímulos gerados por esses passos com um resultado esperado. Plano de Testes - documento que descreve o escopo das atividades de teste, a abordagem, os recursos humanos envolvidos, os componentes a serem testados, os prazos para a execução, riscos, a mitigação dos riscos, etc. Suite de Testes - indica um conjunto de casos de testes que são agrupados para um objetivo comum. Automação de Testes - testes podem ser automatizados por meio da utilização de ferramentas e frameworks especializados para os tipos de testes a serem realizados. Bug - representa qualquer tipo de defeito de software. Debug - processo onde o desenvolvedor depura o programa a fim identificar a causa de um defeito. Veja Também Bug.

2.4.2 Estratégias de teste 2.4.2.1 Estratégia de testes Bottom-up Nesse tipo de teste cada módulo ou componente é testado individualmente e, pouco a pouco, os demais componentes são combinados e testados. Em alguns casos simuladores ou mocks, são utilizados no lugar dos componentes reais para substituírem componentes que são necessários, porém ainda não disponíveis. 2.4.2.2 Estratégia de testes Top-Down Nesta estratégia de teste, a aplicação é testada como um todo do início ao fim do ponto de vista do usuário final. Ou seja, o sistema é gerado por completo, instalado em um ambiente pré-determinado e o testador executa os casos de teste, simulando situações de uso reais.

2.4.3 Tipos de Testes 2.4.3.1 Testes Funcionais (Caixa Preta) Nessa estratégia, os testes são executados por meio do fornecimento de dados de entrada ao componente ou ao conjunto de programas, que está sendo testado e pela análise do resultado produzido, porém, sem entendimento ou verificação do processo que produziu o resultado, utilizado geralmente para verificar uma função completa encontra-se de acordo com os requisitos especificados. 2.4.3.2 Testes de Configuração, instalação e suportabilidade Nessa categoria de testes, os testes são executados contra todos os ambientes (hardware e software) suportados. Para manter uma matriz contendo as plataformas/ambientes suportadas e o estado da execução dos testes contra essas plataformas/ambientes, ao surgir um novo sistema operacional ou equipamento de hardware, esta matriz pode ser atualizada, e os testes aplicados ao novo ambiente operacional. 2.4.3.3 Testes de Integração ou Subsistemas Nesta estratégia de testes, os diversos sistemas que compõem uma solução de software são combinados e configurados num ambiente semelhante ao ambiente onde serão usados na situação real. Dessa maneira é possivel testar o fluxo das operações do começo ao fim do ponto de vista do usuário final. Também conhecido como Testes de Sistema 2.4.3.4 Testes de Carga, Volume, demanda e contenção Essa categoria de teste tem a função de aplicar uma carga de operações ou transações simultâneas contra a aplicação a fim de conferir se a aplicação atende os requisitos de performance ou resposta. 2.4.3.5 Testes de recuperação de falhas Classe de testes cuja principal função é avaliar como a aplicação lida com problemas inesperados e desastres.

2.4.3.6 Testes de Regressão Essa abordagem tem a função de garantir que os módulos ou componentes da aplicação que não foram modificadas ainda funcionam corretamente após o programador modificar alguma outra parte da aplicação. 2.4.3.7 Teste de valores limites Técnica de teste utilizada para selecionar os dados que farão parte da execução de um teste por meio dos limites (máximo e mínimos) das entradas e saídas (procedimentos ou funções) de um componente de software. 2.4.3.8 Teste de unidade ou componente Os testes de unidade ou de componentes envolvem algumas combinações de testes estruturais e funcionais, verificando a menor unidade do projeto de software, neste teste os caminhos mais importantes são testados para descobrirem erros nos fontes dos programas. 2.4.3.9 Testes de Cobertura São testes realizados para verificar o percentual de abrangencia da qualidade minima exigida, previamente determinada, usualmente este indice é de 75% a 85% de falhas descoberta e seneadas antes da entrega ao usuário final, o que depende de muitos fatores, dentre ele o nível de segurança exigido. 2.4.3.10 Testes de Aceitação São testes conduzidos de forma que garantam que o programa atinja as necessidades do usuário final por meio da execução de cenários e dados de testes reais. Veja também Testes Integrados. 2.4.3.11 Criterios de Aceitação e Falha Comparação com o resultado esperado de um caso de testes a fim de determinar se o teste passou ou falhou. 2.4.3.12 Processo de Verificação Garante que o software está sendo desenvolvido conforme os padrões e processos definidos pela organização.

2.4.3.13 Processo de Validação (Alfa e Beta) Garante que o sistema está sendo desenvolvido conforme as definições dos requisitos a buscando o atendimento das necessidades do cliente.

2.5 Desenvolvimento Orientado por Testes Com o surgimento de metodologias de desenvolvimento orientadas a objeto, houve a promoção de uma importante prática de testes: escrevê-los primeiro. O que também promoveu a refatoração contínua dos programas, isso para que os códigos destes programas sejam escritos com maior qualidade, com maior clareza e menos duplicidade. Muitas obras atuais de literatura sobre a programação orientada a objetos, sejam para qual for à metodologia aplicada, apóiam a abordagem de Test-Driven Development (Desenvolvimento Orientado por Testes ou DDT).

Na abordagem DDT para programas orientados a objetos, os códigos de testes são escritos antes de a classe ser testada e o desenvolvedor escreve os códigos de teste para cobrir a maior parte possível do código de produção (LARMAN, 2007).

2.5.1 Vantagens da abordagem DDT: • Testes de unidade são realmente escritos - Geralmente os programadores evitam escrever testes unitários, deixando a atividade em segundo plano, nesta abordagem, o teste unitário é o ponto de partida para o programador realizar o desenvolvimento. • Satisfação do programador que conduz à escrita de testes mais consistentes – O programador se sente desafiado “psicologicamente” a escrever o código de programas para que estes “passem nos testes” , deixando a sensação de meta alcançada, • Clareza de interface e comportamento detalhado – A prática de detalhar o comportamento de uma classe (unidade de programa) sem que a mesma exista, ou partes ainda não existam, força ao programador ou analista que ele pense em cada detalhe do código que esta para construir, e esse raciocínio promove

melhoras e esclarece detalhes de projeto, que podem inclusive originar solicitações de mudança de projeto por prever detalhes que poderiam ser pegos apenas em fases mais tardias de testes, o que comumente acontece em projetos em que a abordagem não é utilizada. • Verificação provável, repetível e automatizada – À medida que se vão construindo códigos de testes, estes vão sendo acumulados e podem ser utilizados para verificação e correções de uma forma significativa. Podem-se aplicar os testes construídos de forma que seja possível a regressão, e verificação da evolução de um componente ou até do programa em seu estágio atual de programação e a aplicação pode ser realizada de forma automatizada, o que justifica o investimento inicialmente penoso em escrever os testes antecipadamente. • Assertividade e Confiança – Ao modificar um código de programa existente, pode-se aplicar os testes preexistentes, para verificar se a manutenção do código, causou impacto ou erro, fornecendo uma resposta mais rápida para ajustar o programa (LARMAN, 2007).

2.6 Considerações sobre o capítulo Nesse capítulo foram apresentados os principais conceitos e padrões utilizados por serviços web na concepção de sistemas. Esses padrões são caracterizados pela independência de plataforma de hardware e software, proporcionando maior abertura aos sistemas que utilizem SOA. Além dos padrões e especificações tais como SOAP, WSDL e UDDI, que formam a base dos serviços web, foram apresentados também os principais desafios encontrados pelas empresas e por suas equipes de TI no que tange a utilização de sistemas baseados em SOA, bem como os principais conceitos de teste de software de maneira a produzir o entendimento básico para que se possa testar um sistema produzido utilizando a abordagem SOA. Para as empresas que produzam baseados em SOA que, como se demonstrou nos capítulos anteriores, é muito recente, sugere-se que se definam estratégias para a padronização de procedimentos principalmente de desenvolvimento dos programas e de sua documentação, bem como de testes que sejam aplicáveis a estes programas ou sistemas, para a promoção de melhorias tanto do produto final como do ambiente de trabalho conforme apresentou-se no tópico “Desenvolvimento Orientado por Testes”.

Desta forma, obtém-se um ganho na redução da manutenção, e conseqüentemente redução nos custos com testes e retrabalhos, pois através das técnicas abordadas nos capítulos anteriores, ao se reutilizar os cenários de teste e verificar os erros que um conjunto de programas integrados através de SOA possa apresentar logo na sua fase inicial de construção, obtendo-se então um número maior de programas a se manter funcionando durante o processo de construção, sendo que a cada nova iteração no processo de desenvolvimento, ou manutenção, os testes já aplicados podem ser reaplicados, para a melhoria e refinamento, contínuos dos programas gerados. As empresas que utilizam sistemas baseados em SOA também podem se beneficiar de igual maneira, visto que suas equipes de TI, podem produzir cenários de testes a partir das técnicas de testes apresentadas e antes de colocar um sistema em produção, verificar se o mesmo atende as necessidades de determinado departamento ou negócio. A seguir, será apresentado um caso pratico da aplicação de procedimentos de testes, planejados e de uma ferramenta de testes a um sistema que utilizam componentes SOA em sua infra-estrutura.

RESULTADOS E DISCUSSÕES Na maioria das bibliografias pesquisadas não foi abordado o assunto “como testar

SOA”, as bibliografias pesquisadas mostram que basicamente a forma de testar depende da ferramenta utilizado para o teste e reportam apenas os conceitos básicos de testes ou de SOA, não há uma referência conclusiva a qual se possam apoiar e embasar práticas de teste de software nesta tecnologia. Foram pesquisadas ferramentas que pudessem auxiliar na tarefa de testar a arquitetura orientada a serviços, porém muito poucas referências foram obtidas. Durante a pesquisa encontraram-se as seguintes ferramentas: Compuware DevPartner Studio, SoapUI (Eviware), TestMaker 5.0 (PushToTest), Peta (Verit), LiSA (iTKO), SoapTest (ParaSoft), Fault Factory (ExtraData), SOAPSonar (Crosscheck Networks), TestComplete (AutomatedQA). Para a prática e aplicação dos testes de software sobre o software componentizado, utilizando a tecnologia SOA (CRM), foram seguidas metodologias de teste conforme as sugeridas e verificadas na revisão bibliográfica deste trabalho. Utilizou-se dos artefatos de plano de testes, casos e cenários de testes, e o relatório de aprovação da execução dos testes. Para a execução dos procedimentos utilizou-se a seguinte técnica: Observaram-se os requisitos de testes presentes no banco de requisitos, a partir destes foi gerado o plano de testes (vide Apêndice I), com o objetivo de registrar a estratégia de testes a ser adotada, para a coordenação e condução dos testes, os níveis de teste a serem abordados, os tipos de teste a serem executados, o escopo de requisitos a ser testado, as ferramentas e ambientes empregados nos testes e os critérios de conclusão e aceitação dos testes. No projeto de teste também definiu-se os requisitos a serem testados, as categorias de testes, os tipos de testes bem com a priorização dos mesmos onde delimitou-se o escopo de testes para definir com precisão o que será coberto pelo teste e também o que não será coberto, bem como as ferramentas utilizadas para a realização dos cenários de teste.

Os defeitos da solução encontrados pelos testes foram registrados em planilha de testes e medição de qualidade dos testes realizada através dos indicadores: densidade de falha e eficácia de testes, no decorrer do trabalho. Outro artefato utilizado para a execução de testes é o documento de projeto de testes (vide Apêndice II) que contém as orientações de validação e ambiente devem ser atendidas na execução dos requisitos de testes do projeto. Um requisito de teste contém informações gerais que determinam como testes anteriormente especificados pelo plano de testes devem ser conduzidos. A execução dos testes realizou-se aplicando-se os testes descritos no plano e projeto de testes sobre produto CRM na versão 2.7 Release 24 que na sua infra-estrutura utiliza o produto Microsoft® Soap Toolkit e o servidor de aplicações Jboss™ 4.0.4 com o modulo Axis 1.1 para as transações web service de SOA utilizando o protocolo SOAP. Como ferramenta de testes dentre as pesquisadas para o estudo optou-se por utilizar o “SOAPUI” na versão 3.0.1 Open Source, da empresa Eviware, os critérios de escolha para se chegar à opção se deram pela leitura dos descritivos das ferramentas, onde estavam informadas a cobertura e os processos que poderiam ser verificados, foram levados em consideração a adequação da ferramenta a linguagem de programação, pois algumas das escolhidas se aplicavam apenas a determinadas linguagens e deste modo foram descartadas; a portabilidade, ou seja, possibilidade de execução em diversos sistemas operacionais; e principalmente pelo fator preço, já que a maioria das ferramentas pesquisadas é proprietária e exige licenciamento para o uso, cujo tempo para uso é limitado entre 15 a 30 dias tempo insuficiente para a pesquisa.

3.1 Experimentos Esta seção apresenta a descrição de alguns experimentos realizados com o objetivo de avaliar as funcionalidades da implementação da camada SOA de um software de CRM, sendo que o serviço utilizado tem a característica de devolver mensagens SOAP com a resposta de desafio, verificando se o usuário tem a permissão para acessar determinado registro de um cliente. A Figura 6 demonstra o ambiente de execução dos testes.

Figura 6 – Ambiente de execução dos testes – Fonte: Dos Autores (2009).

O teste foi realizado, de maneira a importar os arquivos descritores dos serviços a serem testados. Para a amostra, utilizou-se o serviço Team_OpportunityTeam cujo descritor e a documentação do serviço foram utilizados para a realização dos testes mencionados. A partir da importação do arquivo e os métodos do serviço exposto como demonstra a Figura 6, pôde-se criar requisições com o intuito de obter as respostas dos métodos, a ferramenta por si cria requisições de exemplo, porém de difícil entendimento, foi necessário recorrer à documentação e ao monitor HTTP da ferramenta para que fosse possível entender como as requisições e respostas eram trocadas no uso do aplicativo CRM. Após a compreensão mínima do uso dos métodos, puderam-se criar requisições HTTP que obtivessem os retornos. Durante os ensaios, aplicaram-se aos métodos parâmetros incorretos e ou vazios, como demonstra o Quadro 1.

Quadro 1 – Requisição SOAP Com paramentos incorretos. <soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:opp="http://opportunityteam.team.xxcrm.crm.xxxx.com"> <soapenv:Header/> <soapenv:Body> <opp:verifyHierarchyTeamAccess soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <in0 xsi:type="dat:valueObject" xmlns:dat="http://www.xxxx.com"> <Map xsi:type="x-:Map" xmlns:x-="http://xml.apache.org/xml-soap">  <item xsi:type="x-:mapItem"> <key xsi:type="xsd:string">?</key> <value xsi:type="xsd:string">?</value> </item> </Map> </in0> <in1 xsi:type="xsd:int">?</in1> <in2 xsi:type="xsd:int">?</in2> </opp:verifyHierarchyTeamAccess> </soapenv:Body> </soapenv:Envelope>

“Cujos parâmetros incorretos, ou em branco, causaram respostas de falha A falha apresentada no Quadro 2, tem como causa a passagem de uma string “?” onde se espera um inteiro, identificada na resposta da requisição pela ferramenta de testes: Quadro 2 – Resposta de Requisição SOAP Incorreta. <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <soapenv:Fault> <faultcode>soapenv:Server.userException</faultcode> <faultstring>java.lang.NumberFormatException: For input string: "?"</faultstring> <detail/> </soapenv:Fault> </soapenv:Body> </soapenv:Envelope>

Aplicou-se também, parâmetros que apresentavam a resposta da requisição como correta, como a requisição conforme o demonstrado no Quadro 3, realizada para o método verifyAccountAcces que realiza a verificação ao perguntar ao servidor se determinado usuário

cujo código é “1” possui acesso a determinado cliente cujo seu código é “19410” além da localização do usuário para identificar seu idioma. Quadro 3 – Requisição correta ao método verifyAccountAcces. <soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:opp="http://opportunitycrud.opportunity.xxcrm.crm.xxxx.com"> <soapenv:Header/> <soapenv:Body> <opp:verifyAccountAccess soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <in0 xsi:type="dat:valueObject" xmlns:dat="http://www.xxxx.com"> <Map xsi:type="x-:Map" xmlns:x-="http://xml.apache.org/xml-soap"> <item xsi:type="x-:mapItem">  <key xsi:type="xsd:string">resourceId</key>  <value xsi:type="xsd:int">1</value> </item> <item xsi:type="x-:mapItem">  <key xsi:type="xsd:string">resourceType</key> <!-- Codigo do Grupo de

Usuario-->

<value xsi:type="xsd:string">1</value> </item> <item xsi:type="x-:mapItem">  <key xsi:type="xsd:string">locale</key>  <value xsi:type="xsd:string">"pt"</value> </item> </Map> </in0>  <in1 xsi:type="xsd:int">1</in1> <in2 xsi:type="xsd:int">19410</in2> </opp:verifyAccountAccess> </soapenv:Body> </soapenv:Envelope>

Como resposta apresentada no Quadro 4, a requisição do serviço obteve a expressão “true” o que identifica que o usuário tem acesso a conta solicitada e pode verificar suas oportunidades. Quadro 4 – Resposta a requisição ao método verifyAccountAcces, permitindo o acesso.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <ns1:verifyAccountAccessResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="http://opportunitycrud.opportunity.xxcrm.crm.xxxx.com"> <ns1:verifyAccountAccessReturn href="#id0"/> </ns1:verifyAccountAccessResponse> <multiRef id="id0" soapenc:root="0" soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="ns2:return" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns2="http://www.xxxx.com"> <data xsi:type="xsd:boolean">true</data> </multiRef> </soapenv:Body> </soapenv:Envelope>

A Figura 7 exemplifica o uso da ferramenta SOAPUI para a realização do teste acima descrito.

Figura 7 – Ambiente de execução dos testes II – Fonte: Dos Autores (2009).

3.2 Considerações sobre o capítulo A ferramenta de testes que utilizou-se na aplicação dos testes SoapUI, como já abordamos, é uma ferramenta open source escrita em Java cuja principal função é consumir e testar web service. Neste contexto, o SoapUI facilita todo o processo de criação e depuração dos testes por meio de uma interface gráfica visual e intuitiva. Dentre as suas principais características, podemos destacar as seguintes: a) instalação simples e fácil; b) ampla documentação (no site); c) importação e geração automática das requisições descritas no WSDL; d) capacidade de gerenciar um número ilimitado de requisições para cada operação; e) gerenciamento de múltiplo endpoints reference (uma entidade, recurso ou processador para onde as mensagens dos Web services são encaminhadas) para cada web service; f) validação das requisições e respostas contra as suas definições no WSDL; g) possibilita testes funcionais, de carga e stress; h) execução de diversos procedimentos de testes em paralelo; i) editores com realce de sintaxe e formatação automática; Identificamos como ponto fraco da ferramenta, a manutenção dos cenários de testes devido a atualização da ferramenta durante a fase de experimentação (iniciamos com a versão 1.9 e concluímos com a 3.0.1) , que não mais eram executados em razão da troca dos padrões de protocolo imposta pela evolução do mesmo pelo W3C, a ferramenta deveria prever este tipo de situação e validar as tags dos arquivos informando a restrição, fato que não ocorreu, provocando erros de análise do resultado esperado. A ferramenta atendeu-nos no processo de teste unitário e funcional de web services, que tinnhamos como objetivo nesta pesquisa.

Ainda, para a execução de outros tipos de teste, caso se deseje aplica-los, faz-se necessária a análise de outras ferramentas para a montagem de um framework para os demais tipos de testes que possam ser aplicados.

CONCLUSÕES E RECOMENDAÇÕES Os testes com a ferramenta indicada, apresentaram as mesmas dificuldades do processo

de testes anteriormente aplicado ao CRM, e de como testar melhor uma aplicação, ou seja, tempo para aprendizagem, capacitação, e complexidade, porém serviram para um melhor entendimento do conceito de SOA. A principal dificuldade enfrentada foi que a documentação dos serviços expostos não existia. Este fato deve-se a forma de implementação do aplicativo CRM, que foi construído de modo a que o seu código fonte fosse fechado, ou seja, aplicação proprietária, com a exposição de web service, porém sem a documentação técnica de sua implementação de tal modo que na tentativa de obter o entendimento, utilizou-se da extração de documentos da ferramenta SoapUI, como indicado no tópico “Resultados e Discussões”,

diferentemente de outros

serviços em que foi possível contato durante a execução do trabalho como “Google SOAP Search API” cujo uma ampla documentação de implementação e uso esta disponível (GOOGLE, 2009) e Flickr, sendo esta, disponível em português (FLICKR, 2009). Chegou-se a conclusão, portanto, de que a ferramenta SoapUI não seria a mais indicada no momento para a execução dos testes unitários que foram propostos. Ainda durante a pesquisa, verificou-se a descontinuidade do aplicativo CRM, devido à mudança de modelo de produção de software adotado pelo contratante, para a construção de um novo aplicativo em nova arquitetura. Portanto concluiu-se que os testes sugeridos, bem como a ferramenta e o modelo não seriam mais aplicáveis. Durante a execução deste trabalho, e em paralelo a ele, houveram discussões e pesquisas por parte de outros integrantes da equipe de auditoria e testes da empresa onde este trabalho estava sendo aplicado, e nestas também se buscavam outras ferramentas alternativas, para os testes não só da aplicação a que se propõe este trabalho, mas para as outras aplicações em que a equipe de testes aplica a auditoria. Como resultado da pesquisa feita por parte dos integrantes da equipe de auditoria, foi contratada uma consultoria especializada para delimitar o escopo mais amplo para a aplicação de testes a todos os aplicativos produzidos em nossa empresa, e que durante o 2° Seminário Catarinense de Qualidade e Teste de Software ocorrido entre os dias 10 a 12 de Setembro de

2009, da qual fomos participantes, culminou na escolha por parte da empresa de uma das ferramentas citadas em nosso trabalho, chamada TestComplete da empresa AutomatedQA, e na qual a equipe de testes e auditoria será treinada para o uso. Como trabalho futuro propõe-se o estudo de aplicabilidade da ferramenta elegida pela equipe de auditoria e testes da empresa ao novo produto de software CRM, proposto pelo contratante, com a ferramenta escolhida pela empresa para os testes.

4.1 Considerações Finais Por fim, este trabalho possibilitou um aprendizado abrangente em diversos aspectos referentes a SOA, web service e testes de software, possibilitando que os conhecimentos adquiridos fossem repassados para a equipe da empresa onde este foi realizado. Foi possível verificar que testes em componentes SOA que não tiveram sua documentação devidamente gerada durante os processos de análise e desenvolvimento, geram enormes dificuldades para a área de testes, consumindo o mais importante e escasso de todos os recursos: tempo. A importância de que a ferramenta de testes e métodos de testes que serão aplicados ao produto final sejam definidos já no início do processo de desenvolvimento foi confirmada. Isto sendo realizado, ganha-se tempo e maior assertividade em todas as etapas de construção de um software.

REFERÊNCIAS AREVOLO, W. Business Process Management Scenario: The Future of BPM Suites. São Paulo: Gartner, 2006. BASS, CLEMENTS, KAZMAN. Software Architecture in Practice (2nd edition). EUA: Addison-Wesley, 2003. BEIZER, B. “Software testing techniques.” 2nd ed. New York: Van Nostrand Reinhold Company, 1990. BENEDETE Junior, Antonio Carlos. Roteiro para a definição de uma arquitetura SOA utilizando BPM. - Monografia (MBA em Tecnologia da Informação) - Escola Politécnica da Universidade de São Paulo - São Paulo, 2007. BIEBERSTEIN, N. et al. Service Oriented Architecture (SOA) Compass. NJ, EUA: IBM, 2006. CHANG, J.: RICHARDSON, D. J. “Structural Specification-Based Testing: Automated Support and Experimental Evaluation”. France: Proceedings of the 7th European Software Engineering Conference(ESEC/FSE’99), 1999. GIL, Antonio Carlos. Métodos e técnicas de pesquisa social. São Paulo: Atlas, 1999. GIL, Antonio Carlos. Como elaborar projetos de pesquisa. São Paulo: Atlas, 2002. HURWITZ, J. et al. Service Oriented Architecture for Dummies. EUA: Wiley, 2007. LAKATOS, E. M. e MARCONI, M. A. Fundamentos da Metodologia Científica. 5a. ed. São Paulo: Atlas, 2003. LARMAN, Craig. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos e ao desenvolvimento iterativo / Craig Larman; tradução Rosana Vaccare Braga ... [et al.] – 3ª. ed. – Porto Alegre : Bookman, 2007 LINNENKUGEL, U.; MÜLLERBURG, M. “Test data selection criteria ofr (software) integration testing”. In: First Integrational Conference on System Integration, Morristown, NJ, 1990, p. 709-717. MYERS, G. “The Art of Software Testing.”. New York: John Willey & Sons, 1979. 170 p. NATIS, Y. Predicts 2007: SOA Advances. EUA: Gartner, id: G00144445, Novembro de 2006. NIELSEN, J. “Usability Engineering”. AP Professional, Mountain View EUA, 1993. 362 p. NEMETZ, F.; Winckler M. A. A.; de Lima, J. V. “Evaluating Evaluation Methods for Hypermedia Applications”. Short Paper publicado na seção Poster no Proceedings em CDROM do ED-MEDIA & ED-TELECOM. Calgary, CA, 1997.

PERES, R.; NOGUEIRA, A. R. - Estudo Comparativo de Ferramentas para Automação de Testes de Software - Monografia de Pós-graduação em Engenharia de Software – UNIFIL, 2004. PRESSMAN, ROGER. S. “Engenharia de Software”. São Paulo: Makron Books, 1995. PRESSMAN, ROGER S. - “Engenharia de Software”, - Software Engineering – A Practitioner’s Approach – 6th edition. - Tradução Rosangela Delloso Penteado, revisão técnica Fernão Stella R. Germano, José Carlos Maldonato, Paulo César Masiero. 6.ed. – São Paulo : McGraw-Hill, 2006. ROCHA, A. R. C.; MALDONADO, J. C.; WEBER, K. C. (Ed.). Qualidade de software: teoria e prática. São Paulo: Prentice-Hall, 2001. 303 p. SILVA, A. M. R.; VIDEIRA C. A. E. UML, Metodologias e Ferramentas CASE Linguagem de Modelação UML, Metodologias e Ferramentas CASE na Concepção e Desenvolvimento de Software - Edições Centro Atlântico - Porto Lisboa – Portugal, 2001 SITES: GOOGLE. “Google SOAP Search API”, Disponivel em: http://code.google.com/intl/pt-BR/apis/soapsearch/api_faq.html, Acessado em: Julho (2009). IEEE. IEEE 829- 1998 e IEEE 730-1998, Disponível em: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&arnumber=741968&isnumber=16010 Acessado em: Setembro (2009) FLICKR. Serviços do Flickr – Documentação API, Disponivel em: http://www.flickr.com/services/api/, Acessado em: Julho (2009). MANES, Anne Thomas. “SOA is dead; Log life Services” - Burton Group Disponível em: http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html, Acessado em: Setembro (2009) NEXTG. NEXT GENERATION CENTER “SOA – Service Oriented Architecture”, Disponivel em: http://www.nextg.com.br, Acessado em: Julho (2009). NETBEANS. NETBEANS COMMUNITY “Guias de aprendizado para aplicativos SOA e modelagem UML”, Disponível em: http://www.netbeans.org/kb/trails/soa_pt_BR.html, Acessado em: Julho (2009). SOA-RM. “SOA-RM v1.0 OASIS Standard Portuguese (Brazil)”; Escola Politécnica da Universidade de São Paulo — Brazil - http://www.pcs.usp.br/%7Epcs5002/oasis/soa-rmcsbr.pdf, acessado em Setembro (2009).

ZACHMAN. Zachman Institute for Framework Advancement (ZIFA), DisponĂvel em: http://www.zifa.com/, acessado em Agosto (2008).

APÊNDICES

APÊNDICE I PLANO DE TESTES

Plano de Testes

Cliente: Interno Fornecedor: Interno

Projeto: CRM – Aplicação de Testes a camada SOA

Histórico de Alterações Data 07/2009

Versão 1.0

Descrição Criação de Documento

Autor Israel/ Rodrigo

Conteúdo 1 2 3

4 5 6

Introdução.............................................................................................................................59 Estratégia de Testes ..............................................................................................................60 2.1 < ESCOPO – EX.: IPP XXX >......................................................................................60 Gestão de Testes ...................................................................................................................67 3.1 REGISTRO DE RESULTADOS ..................................................................................67 3.2 MODELOS DE AUDITORIA ......................................................................................67 3.3 REGISTROS DE DEFEITOS ..................... ERRO! INDICADOR NÃO DEFINIDO. Software – Ferramentas de Testes.......................................................................................68 4.1 FERRAMENTAS..........................................................................................................68 Cronograma...........................................................................................................................68 Referências............................................................................................................................68

Introdução Este documento define o Plano de Testes do projeto CRM – Aplicação de Testes a camada SOA, com o objetivo de registrar a estratégia de testes a ser adotada. Isto possibilitará uma bem-sucedida coordenação e condução de testes no projeto.

Estratégia de Testes Fluxo de Auditoria O fluxo básico de auditoria a ser seguido nos desenvolvimentos esta ilustrado abaixo, e importante destacar que este fluxo é o padrão de desenvolvimento, porém, de acordo com os riscos particulares de cada projeto, tanto novos processos podem ser inseridos no fluxo como alguns processos podem ser retirados conforme exceções que estiver descritas neste Plano de Testes.

Processo de Auditoria de Fontes/Arquitetura – Nível 1 Esta auditoria deverá apenas iniciar quando os testes de programação foram realizados pelo programador e, a atividade foi liberada para a auditoria anexada dos seguintes documentos e registros específicos deste serviço: -

Números dos pacotes da atividade gerados pelo Sistema Compilador em todos os ambientes disponíveis.

Check-list de construção preenchido.

Listagem resultante da execução de uma ferramenta de testes de caixa branca.

Caso os documentos necessários descritos acima para o serviço de construção não estiverem anexados, a auditoria deverá ser reprovada pelo auditor de fontes. O tipo de erro a ser

registrado para este erro com origem “construção” deverá ser “DoctInad” = Documentação Inadequada. Caso os documentos necessários estiverem anexados ao serviço, o auditor de fonte deverá primeiramente avaliar nestes anexos: - Se o check-list de construção foi preenchido de acordo com a necessidade do desenvolvimento em questão. - Se a listagem de ferramenta de caixa branca não apresenta erros pertinentes ao desenvolvimento realizado. - Verificar se o pacote da atividade foi gerado pelo Sistema Compilador, confirmando que não houve erros de compilação nos programas alterados. Caso estes anexos não estiverem de acordo, o auditor de fontes deverá reprovar a auditoria registrando os erros encontrados. Caso os anexos estiverem de acordo, o auditor deverá: - Analisar os códigos alterados e desenvolvidos verificando se as melhores técnicas de programação foram seguidas; - Verificar se o código está de acordo com o solicitado no desenvolvimento, respeitando principalmente as releases solicitadas para o desenvolvimento; - Verificar se os padrões dos templates foram seguidos conforme manuais de padrões de programação (códigos e interfaces); - Analisar a arquitetura dos principais objetos desenvolvidos ou alterados para analisar: Se a estrutura de código é de fácil manutenção; Se o mesmo código (regra) não foi duplicado em mais de um local do sistema; Se a alteração do código respeitou a integração do mesmo com outros dados externos (objetos, módulos, aplicativos); Se a alteração realizada respeita as limitações dos bancos de dados Oracle e SQL; Se métodos desnecessários foram inclusos; Se problemas específicos foram resolvidos em soluções genéricas; Se houve evoluções em API´s, será verificado se a evolução é necessária e, caso for, será analisado se os procedimentos padrões foram aplicados; Se foi desenvolvido o programa de conversão ou acerto na base de dados; Se as alterações realizadas não causaram impacto negativo na performance das rotinas envolvidas; Se nos desenvolvimentos realizados foram utilizadas as melhores técnicas de programação para melhor performance: acesso a registros, utilização de índices,...

Em caso de não OK (quantidade de falhas impacta na qualidade do teste ou existe algum erro que impede a continuação do teste), a atividade retornará para o programador para ajustes. O auditor de fontes deverá registrar os erros antes da reprovação da atividade observando a classificação dos erros encontrados conforme descrito mais abaixo neste documento, no tópico “Registro das Falhas” Os erros básicos deverão ser registrados como um tipo de erro “PRoIncor” = Procedimento Incorreto e, deverão ter como origem o processo de “construção”. Para verificar o conceito de erro básico, consultar o tópico “Conceito: Erros Básicos” neste documento. Uma vez que todas as falhas estiverem solucionadas, o auditor deverá dar o OK da auditoria de fontes.

Em caso de OK, a atividade será transferida para a auditoria de negócio. Fluxo do Processo

Processo de Auditoria de Negócio - Nível 2 Esta auditoria deverá apenas iniciar quando a auditoria de fontes/arquitetura foi realizada e, este nível de auditoria foi aprovado (auditoria OK). A auditoria de negócio consiste na execução de todos os cenários de testes informados no documento engenharia da função em desenvolvimento (vide projeto de testes), além da execução dos testes automatizados caso existentes para as rotinas alteradas. As falhas encontradas por esta auditoria deverão ser registradas observando a classificação dos erros encontrados conforme descrito mais abaixo neste documento, no tópico “Registro das Falhas”. Caso a não-conformidade resultar na necessidade de se parar os testes, seja pela quantidade de erros encontrados que impactam diretamente na qualidade do teste, ou seja, por uma situação que impede que os testes sejam continuados, a atividade deverá ser reprovada para que os ajustes necessários sejam realizados – ver tópico “Processo de Retorno da Atividade para Construção”. É importante salientar que os erros básicos deverão ser registrados como um tipo de erro “PRoIncor” = Procedimento Incorreto e, deverão ter como origem o processo de “construção”. Para verificar o conceito de erro básico, consultar o tópico “Conceito: Erros Básicos” neste documento. Uma vez ajustados os erros (retorno da atividade para o auditor), fica a cargo do auditor executar novamente todos os testes necessários, e em caso de problema não corrigido devolver a atividade para a construção. Uma vez que não foram mais encontradas falhas, o auditor deverá dar o OK da auditoria de negócio. Quando dado OK na auditoria de negócio a atividade deverá ser transferida para a auditoria de validação. Fluxo deste processo

Processo de Validação do Artefato - Nível 3 Esta auditoria deverá apenas iniciar quando a auditoria de negócio foi realizada e, este nível de auditoria foi aprovado. A validação, realizada pelo analista responsável pelo desenvolvimento, consiste na execução de testes genéricos aleatórios (testes exploratórios) considerados como importantes por este auditor. Estes testes são voltados à análise da funcionalidade para verificar se os requisitos funcionais do desenvolvimento estão de acordo com o que foi solicitado pelo cliente (usuário final ou gerente de produto responsável). O validador também deverá atualizar a planilha de testes com os erros encontrados por este nível de auditoria. As falhas deverão ser registradas observando a classificação dos erros encontrados conforme descrito mais abaixo neste documento, no tópico “Registro das Falhas”. É importante salientar que os erros básicos deverão ser registrados como um tipo de erro “PRoIncor” = Procedimento Incorreto e, deverão ter como origem o processo de “construção”. Para verificar o conceito de erro básico, consultar o tópico “Conceito: Erros Básicos” neste documento. Uma vez que não foram mais encontradas falhas, o auditor deverá dar o OK da auditoria de validação. Quando dado OK na auditoria de validação, a atividade será encerrada e transferida para a auditoria de quality. Fluxo deste processo

Processo de Quality - Nível 4 Esta auditoria, que será realizada pela Equipe de Testes, e ocorrerá apenas na liberação do ambiente de Quality da OS, onde o desenvolvimento (atividade) foi vinculado. Esta auditoria possui como objetivo executar os testes automatizados caso existentes com o intuito de executar testes regressivos por pacote.

Caso a auditoria esteja OK, o auditor registrará este OK, caso contrário, os erros encontrados deverão ser registrados e, esta auditoria será reprovada, sendo então esta atividade replanejada para outra OS. Fluxo deste processo

Conceito: Erros Básicos

Caracteriza-se como erro básico todo aquele que pode ser identificado nos testes do programador, não sendo necessário o conhecimento das regras de negócio envolvidas. Consideram-se erros básicos: • Erros de compilação: independente do ambiente – utilizar sistema compilador; • Erros apresentados na interface (ambiente solicitado para teste no tópico “Cenários de Testes” da engenharia): erros na execução do programa e, erros encontrados através da execução do check-list de programação, tópico “Verificações de Interface”; • Erros de programação, como por exemplo, situações onde a engenharia solicitava gravar em um determinado campo e o programa grava em outro; • Erros encontrados através da utilização das ferramentas de caixa branca, desde que estes erros forem ocasionados pelo desenvolvimento em questão. 4.1.1.1

Fase: Construção

Caracteriza-se como erro com origem na construção: - Erros básicos: para verificar o conceito de erro básico, consultar o tópico “Conceito: Erros Básicos” neste documento. -

Erros identificados a partir da execução dos cenários de testes descritos no projeto de testes: • Erros detectados pela simples utilização dos cenários de testes; • Erros de resultado, quando previsto na regra de negócio e no diagrama de ação da engenharia; • Erros de programação, quando identificados a partir da verificação de um cálculo ou regra de negócio específica. • Problemas de performance identificados pela forma que o programa foi desenvolvido. • Erros de menu, desde que disponibilizadas na engenharia as alterações a serem realizadas. • Erros de arquitetura: analisar checagens realizadas pela auditoria de arquitetura descritas acima neste documento.

4.1.1.2

Fase: Especificação

Caracteriza-se como erro com origem na especificação, todo aquele que é identificado a partir de testes extras não previstos nos cenários de testes e, que a engenharia não previu em seu desenvolvimento (regras de negócio e diagrama de ação) porém, estava dentro do escopo da função. É importante destacar que alguns erros podem possuir as mesmas características (tipos) que outros porém, foram originados por fases diferentes do processo. Seguem exemplos de erros com origem na fase de especificação: Erros de resultado, quando utilizada a troca de parâmetros de módulos ou programas; Erros de resultado em outro módulo ou programa; Situações identificadas em outras partes do produto ocasionadas pelos resultados gerados pela implementação. Sugestões de melhorias do programa ou função, como também de usabilidade do programa. Problemas de performance identificados pela forma que o dicionário foi definido na engenharia. Erros de menu, desde que não disponibilizadas na engenharia as alterações a serem realizadas. 4.1.1.3 Fase: Requisitos Caracteriza-se como erro com origem em requisitos, todo aquele que é identificado a partir de testes extras não previstos nos cenários de testes e, que a engenharia não previu em seu desenvolvimento (regras de negócio e diagrama de ação) e, o escopo do projeto também não previu. É importante destacar que alguns erros podem possuir as mesmas características (tipos) que outros porém, foram originados por fases diferentes do processo. Seguem exemplos de erros com origem na fase de especificação: Erros de resultado, quando utilizada a troca de parâmetros de módulos ou programas; Erros de resultado em outro módulo ou programa; Situações identificadas em outras partes do produto ocasionadas pelos resultados gerados pela implementação. 4.1.1.4

Fase:Testes

Caracteriza-se como erro com origem em testes, todo aquele que é identificado a partir de testes extras não previstos nos cenários de testes porém, a engenharia prevê esta alteração em seu desenvolvimento (regras de negócio e diagrama de ação). É importante destacar que alguns erros podem possuir as mesmas características (tipos) que outros porém, foram originados por fases diferentes do processo. Seguem exemplos de erros com origem na fase de testes: Erros de resultado, quando utilizada a troca de parâmetros de módulos ou programas ou releases;

Erros de resultado em outro módulo ou programa; Situações identificadas em outras partes do produto ocasionadas pelos resultados gerados pela implementação.

Fluxo dos Retrabalhos O líder do projeto, ao receber o retorno da atividade deverá reportar as falhas através de email para os responsáveis conforme abaixo: Programadores envolvidos (Erros com origem na construção); Engenheiro responsável (Erros com origem em requisitos e especificação); Engenheiro de teste responsável (Erros com origem em testes). Cada responsável, após análise das falhas com origem em sua fase, deverá reportar para o líder do projeto o que deverá ser realizado para resolver a falha em questão. O líder do projeto encaminhará o ajuste conforme solicitado pelos responsáveis para os programadores para que as alterações necessárias sejam realizadas. Durante as correções, deverão ser executados todos os processos novamente do desenvolvimento Após ajuste dos erros encontrados, a atividade deverá ser retornada para a auditoria informando, para cada falha, o parecer do ajuste realizado. Fluxo deste processo

IPP – Oportunidades O escopo de teste engloba todas as funções do produto padrão previstas no projeto

Nível Teste ( x ) Unidade ( x ) Integração

( ) Sistema (Quality) ( ) Sistema (Alfa)

( ) Aceitação (Beta)

Tipo de Testes ( x) Estrutural / Caixa Branca ( ) Interface ( x ) Funcional / Caixa Preta ( ) Regressão ( ) Regressão ( ( ( ( (

) Estresse/Carga ) Recuperação de Falhas ) Smoke Test ) Segurança/Controle Acesso ) Configuração/Instalação

( ( ( ( (

) Performance ) Integridade de Dados ) Funcional ) Conversão (Alterar Guia) ) Funcional / Caixa Preta

Execução ( x) Manual ( ) Automático ( x ) Manual ( ) Automático ( ( ( (

) Manual ) Automático ) Manual ) Automático

Release 2.7

Ambiente Windows XP MS SQL Server 2000 JBoss 4.04 Java 1.5 SDK MS SoapToolki t V3

( ) Manual

Requisitos Funcionais/Não Funcionais CRM - Oportunidade Critérios de Conclusão 1) A etapa de teste de sistema só pode iniciar quando 95% dos casos de teste tiverem sido executados e obtiverem exito 2) Os testes serão concluídos quanto todos os requisitos foram testados e os defeitos de criticidade alta e média foram corrigidos.

Gestão de Testes Registro de Resultados Os resultados dos testes serão armazenados na mesma planilha que contém seus valores de entrada. Esta planilha é um arquivo Excel (.xls) cujo nome segue o modelo abaixo: ‘PlanilhaTestes[NivelTeste][CódigoDoRequisito][NomeDoProjeto][NúmeroDoBuild].xls’. Modelos de Auditoria Conforme definido na estratégia de testes. A medição de qualidade dos testes será realizada através dos indicadores: densidade de falha e eficácia de testes, no decorrer do projeto.

Software – Ferramentas de Testes Ferramentas Casos de Teste e Planilhas de Teste. SoapUi – para o teste caixa branca na arquitetura SOA

Cronograma O cronograma detalhado do projeto está disponível em <deve ser inserido um link para o arquivo de cronograma>.

Referências Documento de Processos de Auditoria de Desenvolvimento

APÊNDICE II PROJETO DE TESTES

Detalhamento Execução de Testes

Cliente: Interno Fornecedor: Interno Projeto: CRM – Aplicação de Testes a camada SOA

Histórico de Alterações Data 07/2009

Versão 1.0

Descrição Criação de Documento

Autor Israel / Rodrigo

Conteúdo 1 2

Introdução.............................................................................................................................72 Orientações ...........................................................................................................................72 2.1 VALIDAÇÃO ...............................................................................................................73 3 Requisitos de Testes .............................................................................................................73 3.1 REQUISITO DE TESTE REUSÁVEL.........................................................................73 3.2 REQUISITO DE TESTE ESPECÍFICOS DO PROJETOERRO! INDICADOR NÃO DEFINID

Introdução Este documento descreve os requisitos e os procedimentos de teste a serem executados para o projeto CRM – Aplicação de Testes a camada SOA, com o objetivo de definir como os testes especificados no Plano de Testes serão realizados.

Orientações As orientações de validação e ambiente devem ser atendidas na execução dos requisitos de testes do projeto, conforme descrito a seguir:

Validação Check-list de Testes, Planilha de Testes Deverão ser informados, em cada campo disponível nos casos de testes, dados com o tamanho máximo e mínimo permitidos para análise das telas (tamanho dos campos). Haver quantidade de registros suficientes nos Grids para análise do funcionamento da paginação. Para os casos de testes que referenciam teste utilizando a função de pesquisa (zoom), estes deverão ocorrer somente após esta funcionalidade estar implementada. Verificar a existência de testes automáticos no momento da realização do teste de negócio e assim garantir o teste de regressão. Deverão ser realizados os testes de usabilidade pelo auditor de negócio, conforme solicitado no Plano de Testes deste projeto, para cada caso de teste de tela (não reutilizável) disponibilizado abaixo. Como resultado esperado, além do que foi descrito nestes, a tela deve possuir o design e a ergonomia de acordo com o que foi descrito na Interface Concreta. Todos os campos na tela deverão ter acesso através da tecla TAB, a ordem da navegação deve ter uma seqüência. Objetos que não podem ser alcançados por TAB devem ter uma tecla de atalho. As informações apresentadas nos GRID’s devem possibilitar sua seleção utilizando o mouse, ou o teclado. Todos os portlets ou telas que possuam acesso via menu deverão ser testados por este intermédio. Para os campos que possibilitem pesquisa pelo (zoom) o procedimento deverá ser executado novamente utilizando esta funcionalidade. Para os browsers que apresentarem barra de rolagem vertical ou horizontal, utilizar as barras e navegar até o primeiro/ultimo registro do browser, caso seja rolagem vertical, ou navegar até a primeira/última coluna do brwoser, caso seja rolagem horizontal. Em todas as telas, utilizar a tecla TAB para verificar se a navegações dos campos está sendo feita corretamente.

Requisitos de Testes Requisito de teste Reusável Requisito de testes: Testar a verificação acesso de um time a uma oportunidade de cliente via webservices Procedimentos: 1 a 7 Teste Executado pelo Programador: ( x ) Sim () Não Automatizar?: () Sim (x) Não

RecomendaĂ§Ăľes: <Informe particularidades de devem ser consideradas neste requisito de testes>

ANEXOS

ANEXO I FRAMEWORK DE ZACHMAN PARA ARQUITETURA CORPORATIVA

Framework Zachman para Arquitetura Corporativa – Tradução Livre Ordem

Camada

Limite de Contexto do Escopo

• 2

Conceitos de Modelo de Negócio

• 3

Quem (Pessoas) Lista de organizaçõe s importantes para o negócio Modelo de Fluxo

Quando (Tempo) Lista de eventos significant es para o negócio

Porque (Motivação) Lista de objetivos/estratégi as do negócio

Modelo Semântico ou Entidaderelacioname nto Modelo de Dados Lógico

Modelo de Processos de Negócio (BPM)

Sistema Logístico do Negócio

Cronogra ma Mestre

Plano de Negócio

Arquitetur a da Aplicação

Arquitetura de Sistema Distribuído

Arquitetura de Interface Humana

Estrutura de Processam ento

Modelo de Regras de Negócio

Modelo de Dados Físico

Desenho do Sistema

Arquitetura Tecnológica

Arquitetura de Apresentaçã o

Estrutura de Controle

Desenho de Regras

Definição de Dados

Programa

Arquitetura de Rede

Arquitetura de Segurança

Definição de Prazos

Especificação de Regras

Dados

Funções

Rede

Organização

Cronogra ma

Estratégia

Lista de locais onde o negócio opera

Imple mentad or

Corporaçã o Funcional

•

Onde (Rede)

Constr utor

Configuraç ão de Component es

•

Como (Função) Lista de processos que o negócio realiza

Projetis ta

Modelo Tecnológic o Físico

• 5

Dono

Modelo de Sistema Lógico

• 4

Planeja dor

O Que (Dados) Lista de coisas importantes para o negócio

Trabal hador

ANEXO II PADROES PARA WEBSERVICES

Version 3.0 · February 2007

The Internet Engineering Task Force (IETF) is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet.

The Web Services Interoperability Organization (WS-I) is an open industry organization chartered to promote Web services interoperability across platforms, operating systems and programming languages. The organization’s diverse community of Web services leaders helps customers to develop interoperable Web services by providing guidance, recommended practices and supporting resources. Specifically, WS-I creates, promotes and supports generic protocols for the interoperable exchange of messages between Web services.

The World Wide Web Consortium (W3C) was created in October 1994 to lead the World Wide Web to its full potential by developing common protocols that promote its evolution and ensure its interoperability. W3C has over 350 Member organizations from all over the world and has earned international recognition for its contributions to the growth of the Web. W3C is designing the infrastructure, and defining the architecture and the core technologies for Web services. In September 2000, W3C started the XML Protocol Activity to address the need for an XML-based protocol for application-to-application messaging. In January 2002, the Web Services Activity was launched, subsuming the XML Protocol Activity and extending its scope.

The Organization for the Advancement of Structured Information Standards (OASIS) is a not-for-profit, international consortium that drives the development, convergence, and adoption of e-business standards. The consortium produces more Web services standards than any other organization along with standards for security, e-business, and standardization efforts in the public sector and for application-specific markets. Founded in 1993, OASIS has more than 4,000 participants representing over 600 organizations and individual members in 100 countries.

Standards Bodies

profile, in the fashion of the WS-I profiles, that enables, among other things, basic B2B integration scenarios using Web services technologies.

왖 Reliable Asynchronous Messaging Profile (RAMP) is a

1.0 WS-I Working Draft

Reliable Asynchronous Messaging Profile (RAMP)

catalogues mechanisms that can be used to attach WS-I Profile Conformance Claims to Web services artefacts (e.g., WSDL descriptions, UDDI registries).

왖 Conformance Claim Attachment Mechanism (CCAM)

1.0 WS-I Final Specification

Conformance Claim Attachment Mechanism (CCAM)

Web services specification, along with clarifications and amendments to that specification which promote interoperability.

왖 SAML Token Profile is based on a non-proprietary

1.0 WS-I Working Group Draft

SAML Token Profile

Web services specification, along with clarifications and amendments to that specification which promote interoperability.

왖 REL Token Profile is based on a non-proprietary

1.0 WS-I Working Group Draft

REL Token Profile

Profile 1.0, based on a set of non-proprietary Web services specifications, along with clarifications and amendments to those specifications which promote interoperability.

왖 Basic Security Profile defines the WS-I Basic Security

1.0 WS-I Board Approval Draft

Basic Security Profile

Profile consists of those Basic Profile 1.0 requirements related to the serialization of the envelope and its representation in the message.

왖 Simple SOAP Binding Profile – The Simple SOAP Binding

1.0 WS-I Final Specification

Simple SOAP Binding Profile

complements the Basic Profile 1.1 to add support for interoperable SOAP Messages with attachments-based Web Services.

왖 Attachments Profile – The Attachment Profile 1.0

1.0 WS-I Final Specification

Attachments Profile

BP that includes a profile of SOAP 1.2.

왖 Basic Profile – The Basic Profile 2.0 is an update of WS-I

2.0 WS-I Working Group Draft

Basic Profile

1.1 by incorporating Basic Profile 1.1 errata, requirements from Simple SOAP Binding Profile 1.0, and adding support for WS-Addressing and MTOM.

왖 Basic Profile – The Basic Profile 1.2 builds on Basic Profile

1.2 WS-I Working Group Draft

Basic Profile

implementation guidelines for how related set of nonproprietary Web Service specifications should be used together for best interoperability.

왖 Basic Profile – The Basic Profile 1.1 provides

1.1 WS-I Final Specification

Basic Profile

provides a meta-language for expressing business processes and supporting entities.

왘 WS-BrokeredNotification

a general SOAP-based protocol for enumerating a sequence of XML elements that is suitable for traversing logs, message queues, or other linear information models.

왘 WS-Enumeration describes

family of related white papers and specifications that define a standard Web services approach to notification using a topicbased publish/subscribe pattern.

왘 WS-Notification is a

1.1 W3C Recommendation

XML 1.1

Language is a pared-down version of SGML, designed especially for Web documents. It allows one to create own customized tags, enabling the definition, transmission, validation, and interpretation of data between applications and between organizations.

왘 XML – Extensible Markup

XML Specifications

Systinet, Microsoft, Sonic Software, BEA Systems and Computer Associates Public Draft

WS-Enumeration

1.3 OASIS OASIS-Standard

WS-Notification

1.0 W3C Recommendation

XML 1.0

1.3 OASIS OASIS-Standard

WS-Topics

1.3 OASIS OASIS-Standard

WS-BaseNotification

1.3 OASIS OASIS-Standard

1.1 W3C Recommendation

Namespaces in XML

topic expression dialects that can be used as subscription expressions in subscribe request messages and other parts of the WS-Notification system.

왘 WS-Topics defines three

왘 XML – Extensible Markup

WS-BrokeredNotification

defines the interface for the NotificationBroker. A NotificationBroker is an intermediary, which, among other things, allows publication of messages from entities that are not themselves service providers.

왘 WS-BaseNotification

provides a simple method for qualifying element and attribute names used in XML documents by associating them with namespaces identified by IRI references.

왘 Namespaces in XML

1.0 W3C Recommendation

an abstract data set to provide a consistent set of definitions for use in other specifications that need to refer to the information in a well-formed XML document.

1.1 W3C Working Draft

AMD, Dell, Intel, Microsoft and Sun Microsystems Published Specification

WS-Management

1.0 W3C Recommendation

XML binary Optimized Packaging (XOP)

Binding provides transportneutral mechanisms to address Web services and messages.

왘 WS-Addressing – SOAP

provides transport-neutral mechanisms to address Web services and messages. This specification defines XML elements to identify Web service endpoints and to secure end-to-end endpoint identification in messages.

왘 WS-Addressing – Core

SOAP

Packaging (XOP) is an XML language for describing and constraining the content of XML documents.

왘 XML binary Optimized

1.1 W3C Note

SOAP

1.2 W3C Recommendation

SOAP

service consisting of a Transaction Service for Web Services.

왖 WS-Transaction Management (WS-TXM) defines a core infrastructure

1.0 · Arjuna Technologies, Fujitsu, IONA, Oracle and Sun Microsystems Committee Draft

WS-Transaction Management (WS-TXM)

management and coordination in a Web Services interaction of a number of activities related to an overall application.

왖 WS-Coordination Framework (WS-CF) allows the

1.0 · Arjuna Technologies, Fujitsu, IONA, Oracle and Sun Microsystems Committee Draft

WS-Coordination Framework (WS-CF)

for allowing multiple Web Services to share a common context.

왖 WS-Context (WS-CTX) is intended as a lightweight mechanism

1.0 Arjuna Technologies, Fujitsu, IONA, Oracle and Sun Microsystems Committee Draft

WS-Context (WS-CTX)

collection of three specifications aimed at solving problems that arise when multiple Web Services are used in combination. It proposes standard, interoperable mechanisms for managing shared context and ensuring business processes achieve predictable results and recovery from failure.

왖 WS-Composite Application Framework (WS-CAF) is a

1.0 · Arjuna Technologies, Fujitsu, IONA, Oracle and Sun Microsystems Committee Specification

WS-Composite Application Framework (WS-CAF)

transaction processing systems to wrap their proprietary protocols and interoperate across different hardware and software vendors.

왖 WS-Atomic Transaction defines protocols that enable existing

1.1 OASIS Committee Draft

WS-Atomic Transaction

coordination type that is to be used with the extensible coordination framework described in the WS-Coordination specification.

왖 WS-Business Activity provides the definition of the business activity

1.1 OASIS Working Draft

WS-Business Activity

protocols that coordinate the actions of distributed applications.

왖 WS-Coordination describes an extensible framework for providing

1.1 OASIS Working Draft

WS-Coordination

Transaction Specifications

protocol for managing systems such as PCs, servers, devices, Web services and other applications, and other manageable entities.

왖 WS-Management describes a general SOAP-based

Schema Definition Language is an XML language for describing and constraining the content of XML documents.

왘 XML Schema – XML

1.0 W3C Recommendation

WS-Addressing – SOAP Binding

1.0 W3C Recommendation

WS-Addressing – Core

XML Schema

Binding defines how the abstract properties defined in Web Services Addressing – Core are described using WSDL.

왘 WS-Addressing – WSDL

baseline set of operations that allow Web services to provide asynchronous notifications to interested parties.

왘 WS-Eventing defines a

authenticate message exchanges between parties including security context exchange and establishing and deriving session keys.

왖 WS-SecureConversation specifies how to manage and

BEA Systems, Computer Associates, IBM, Layer 7 Technologies, Microsoft, Netegrity, Oblix, OpenNetwork, Ping Identity Corporation, Reactivity, RSA Security, VeriSign and Westbridge Technology ·Public Draft

WS-SecureConversation

Web Services to securely interoperate. It uses WS-Security base mechanisms and defines additional primitives and extensions for security token exchange to enable the issuance and dissemination of credentials within different trust domains.

왖 WS-Trust describes a framework for trust models that enables

WS-Trust

trust relationships in a heterogeneous federated environment including support for federated identities.

왖 WS-Federation describes how to manage and broker the

1.0 IBM, Microsoft, BEA Systems, RSA Security, and VeriSign Initial Draft

WS-Federation

a Web Service consumer can supply a Username Token as a means of identifying the requestor by username, and optionally using a password (or shared secret, etc.) to authenticate that identity to the Web Service producer.

왘 XML Information Set is

1.0 W3C Candidate Recommendation

WS-Addressing – WSDL Binding

W3C Public Draft

WS-Eventing

XML Information Set

standardizes the terminology, concepts, operations, WSDL and XML needed to express the basic roles involved in Web services publish and subscribe for notification message exchange.

the use of the X.509 authentication framework with the WS-Security: SOAP Message Security specification.

language for describing Web services and how to access them. It specifies the location of the service and the operations (or methods) the service exposes.

Messaging Specifications

왖 WS-Security: X.509 Certificate Token Profile describes

왖 Web Service Description Language 1.1 is an XML-based

1.1 OASIS Public Review Draft

1.1 W3C Note

Security Assertion Markup Language (SAML) v1.1 assertions in the context of WSS: SOAP Message Security including for the purpose of securing SOAP messages and SOAP message exchanges.

WS-Security: X.509 Certificate Token Profile

based language for describing Web services and how to access them. It specifies the location of the service and the operations (or methods) the service exposes.

왖 WS-Security: SAML Token Profile defines the use of

Web Service Description Language 1.1

describes the concrete details for using WSDL 2.0 in conjunction with SOAP 1.1 protocol.

왖 Web Service Description Language SOAP Binding

왖 Web Service Description Language 2.0 Core is an XML-

1.1 OASIS Public Review Draft

2.0 W3C Candidate Recommendation

2.0 W3C · Working Draft

WS-Security: SAML Token Profile

Web Service Description Language 2.0 Core

SOAP messages with guaranteed delivery, no duplicates, and guaranteed message ordering. WS-Reliability is defined as SOAP header extensions and is independent of the underlying protocol. This specification contains a binding to HTTP.

Kerberos tickets and attach them to SOAP messages. As well, it specifies how to add signatures and encryption to the SOAP message, in accordance with WS-Security, which uses and references the Kerberos tokens.

왖 WS-Security: Kerberos Binding defines how to encode

1.0 Microsoft, IBM, OASIS Working Draft

WS-Security: Kerberos Binding

enhancements to SOAP messaging to provide message integrity and confidentiality. Specifically, this specification provides support for multiple security token formats, trust domains, signature formats and encryption technologies. The token formats and semantics for using these are defined in the associated profile documents.

왖 WS-Security: Username Token Profile describes how

1.1 OASIS Public Review Draft

왖 WS-Security: SOAP Message Security describes

WS-Security: Username Token Profile

1.1 OASIS Public Review Draft

to various features defined in the WS-Security specification.

왖 WS-SecurityPolicy defines how to describe policies related

1.1 IBM, Microsoft, RSA Security, VeriSign Public Draft

WS-SecurityPolicy

WS-Security: SOAP Message Security

means for applying security to Web Services.

왖 WS-Security is a communications protocol providing a

1.1 OASIS OASIS-Standard

WS-Security

Web Service Description Language 2.0 SOAP Binding

왖 WS-Reliability is a SOAP-based protocol for exchanging

1.1 OASIS OASIS-Standard

WS-Reliability

(WS-RM Policy) describes a domain-specific policy assertion for WS-ReliableMessaging that that can be specified within a policy alternative as defined in WS-Policy Framework.

왖 Web Services ReliableMessaging Policy Assertion

Web Services (WSDM-MOWS) addresses management of the components that form the network, the Web services endpoints, using Web services protocols.

Security Specifications

complex IT services and systems, including their structure, constraints, policies, and best practices.

왖 Servcie Modeling Language (SML) is used to model

IBM, BEA, BMC, Cisco, Dell, HP, Intel, Microsoft, Sun Draft Specification

Service Modeling Language

Web Services (WSDM-MUWS) defines how an IT resource connected to a network provides manageability interfaces such that the IT resource can be managed locally and from remote locations using Web services technologies.

defines a set of services supporting the description and discovery of businesses, organizations, and other Web services providers, the Web services they make available, and the technical interfaces which may be used to access those services.

왖 Universal Description, Discovery and Integration (UDDI)

3.0.2 OASIS OASIS-Standard

Universal Description, Discovery and Integration (UDDI)

dynamic discovery of services on ad-hoc and managed networks.

1.1 OASIS Committee Draft

WS-Reliable Messaging Policy Assertion (WS-RM Policy)

Web services to communicate reliable in the presence of software component, system, or network failures. It defines a SOAP binding that is required for interoperability.

왖 WS-ReliableMessaging describes a protocol that allows

1.0 OASIS OASIS-Standard

1.0 OASIS OASIS-Standard 왖 Web Service Distributed Management: Management Using 왖 Web Service Distributed Management: Management Of

Management Of Web Services (WSDM-MOWS)

Management Using Web Services (WSDM-MUWS)

Management Specifications

metadata to others through a Web services interface. Given only a reference to a Web service, a user can access a set of WSDL /SOAP operations to retrieve the metadata that describes the service.

왖 WS-MetadataExchange enables a service to provide

1.1 BEA Systems, Computer Associates, IBM, Microsoft, SAP, Sun Microsystems and webMethods Public Draft

WS-MetadataExchange

mechanisms for associating policies with the subjects to which they apply; the policies may be defined as part of existing metadata about the subject or the policies may be defined independently and associated through an external binding to the subject.

왖 WS-Discovery defines a multicast discovery protocol for

Microsoft, BEA Systems, Canon, Intel and webMethods Draft

1.2 W3C W3C Member Submission

왖 WS-PolicyAttachment defines two general-purpose

WS-Discovery

to address some common needs of Web Services applications.

왖 WS-PolicyAssertions provides an initial set of assertions

1.1 OASIS Committee Draft

WS-ReliableMessaging

1.1 BEA Systems, IBM, Microsoft, SAP Public Draft

(CDL4WS) is to specify a declarative, XML based language that defines from a global viewpoint the common and complementary observable behaviour, where message exchanges occur, and when the jointly agreed ordering rules are satisfied.

왖 Web Service Choreography Description Language

(CDL4WS) · 1.0 · W3C Candidate Recommendation

Web Service Choreography Description Language

WS-PolicyAssertions

WS-PolicyAttachment

the policies on intermediaries and endpoints (e.g. business rules, required security tokens, supported encryption algorithms, privacy rules).

왖 WS-Policy describes the capabilities and constraints of

1.5 W3C Working Draft

WS-Policy

XML file format that can be used to interchange process models between tools.

왖 XML Process Definition Language (XPDL) provides an

2.0 Final

XML Process Definition Language (XPDL)

how Web Service operations can be choreographed in the context of a message exchange in which the Web Service participates.

왖 Web Service Choreography Interface (WSCI) describes

(WSCI) · 1.0 · W3C Sun Microsystems, SAP, BEA Systems and Intalio · Note

Web Service Choreography Interface

Reliability Specifications

Metadata Specifications

왖 Business Process Management Language (BPML)

2.0 (BPEL4WS) provides a language for the formal specification of business processes and business interaction protocols using Web Services.

1.1 BPMI.org Final Draft

(BPEL4WS) · 2.0 OASIS, BEA Systems, IBM, Microsoft, SAP, Siebel Systems · Committee Draft

왖 Business Process Execution Language for Web Services

Business Process Management Language (BPML)

and structure of the (SOAP) messages that are exchanged, and the sequence and conditions in which the messages are exchanged.

왖 WS-Choreography Model Overview defines the format

1.0 · W3C Working Draft

WS-Choreography Model Overview

Business Process Execution Language for Web Services 2.0

1.1(BPEL4WS) provides a language for the formal specification of business processes and business interaction protocols using Web Services.

왖 Business Process Execution Language for Web Services

(BPEL4WS) · 1.1 · BEA Systems, IBM, Microsoft, SAP, Siebel Systems · OASIS-Standard

Business Process Execution Language for Web Services 1.1

Business Process Specifications

(DMCBDX) W3C Note

Describing Media Content of Binary Data in XML

XML-based protocol for exchange of information in a decentralized, distributed environment.

왘 SOAP is a lightweight,

1.0 · W3C Recommendation

Transmission Optimization Mechanism describes an abstract feature for optimizing the transmission and/or wire format of a SOAP message.

왘 SOAP Message

of Binary Data in XML (DMCBDX) specifies how to indicate the content-type associated with binary element content in an XML document and to specify, in XML Schema, the expected content-type(s) associated with binary element content.

왘 Describing Media Content

SOAP Message Transmission Optimization Mechanism (MTOM)

complements MTOM by defining mechanisms for describing and conveying non-XML resource representations in a SOAP 1.2 message.

왖 Resource Representation SOAP Header Block (RRSHB)

W3C Recommendation

Resource Representation SOAP Header Block (RRSHB)

accessing XML representations of Web service-based resources.

왖 WS-Transfer describes a general SOAP-based protocol for

W3C W3C Member Submission

WS-Transfer

concepts, message exchanges, WSDL and XML needed to monitor the lifetime of, and destroy WS-Resources. Additionally, it defines resource properties that may be used to inspect and monitor the lifetime of a WS-Resource.

왖 WS-ResourceLifetime is to standardize the terminology,

1.2 OASIS Working Draft

WS-ResourceLifetime

definition of the properties of a WS-Resource may be declared as part of the Web Service interface. The declaration of the WS-Resource properties represents a projection of or a view on the WS-Resource state.

왖 WS-ResourceProperties specifies the means by which the

1.2 OASIS Working Draft

WS-ResourceProperties

Services and WS-Resources can be aggregated or grouped together for a domain specific purpose.

왖 WS-ServiceGroup (WSRF) defines a means by which Web

1.2 OASIS Working Draft

WS-ServiceGroup (WSRF)

that may appear in fault messages. WS-BaseFaults defines an XML schema type for base faults, along with rules for how this base fault type is used and extended by Web Services.

왖 WS-BaseFaults (WSRF) defines a base set of information

1.2 OASIS Working Draft

WS-BaseFaults (WSRF)

specifications for accessing stateful resources using Web Services.

왖 Web Services Resource Framework (WSRF) defines a family of

1.2 OASIS OASIS-Standard

Web Services Resource Framework (WSRF)

Resource Specifications

set of interfaces and related semantics which standardize interactions with components providing user-facing markup, including the processing of user interactions with that markup.

왘 Web Services for Remote Portlets (WSRP) defines a

2.0 OASIS Committee Draft

Web Services for Remote Portlets (WSRP)

Presentation Specifications

innoQ Deutschland GmbH Halskestraße 17 D-40880 Ratingen Phone +49 21 02 77 162 -100 info@innoq.com · www.innoq.com

Web Services for Remote Portlets

innoQ Schweiz GmbH Gewerbestrasse 11 CH-6330 Cham Phone +41 41 743 01 11

Presentation Specifications

WS-Coordination Framework

WS-Context

WS-Transaction Management

WS-Composite Application Framework

WS-Coordination

WS-Atomic Transaction

WS-Business Activity

Transaction Specifications

XML Process Definition Language

Business Process Execution Language for Web Serv. 2.0

Business Process Management Language

WS-Choreography Model Overview

Web Service Choreography Interface

Web Service Choreography Description Language

Business Process Execution Language for Web Services

Business Process Specifications

Service Modeling Language

Management Using Web Services

Management Of Web Services

WS-Management

Management Specifications

Resource Representation SOAP Header Block (RRSHB)

WS-Transfer

WS-ResourceLifetime

WS-ResourceProperties

WS-ServiceGroup

WS-BaseFaults

Web Service Resource Framework

Resource Specifications

WS-Reliable Messaging Policy Assertion

WS-Reliability

WS-ReliableMessaging

Reliability Specifications

WS-SecureConversation

WS-Federation

WS-Trust

WS-SecurityPolicy

WS-Security: Username Token Profile

WS-Security: X.509 Certificate Token Profile

WS-Security: SAML Token Profile

WS-Security: Kerberos Binding

WS-Security: SOAP Message Security

WS-Security

Security Specifications

Web Service Description Language 2.0 SOAP Binding

Web Service Description Language 2.0 Core

Web Service Description Language 1.1

Universal Description, Discovery and Integration

WS-MetadataExchange

WS-Discovery

WS-PolicyAttachment

WS-PolicyAssertions

WS-Policy

Metadata Specifications

WS-Enumeration

WS-Eventing

WS-Addressing – SOAP Binding

WS-Addressing – WSDL Binding

WS-Addressing – Core

WS-BrokeredNotification

WS-Topics

WS-BaseNotification

WS-Notification

SOAP Message Transmission Optimization Mechanism

SOAP 1.2

SOAP 1.1

Security

Interoperability Issues

Messaging Specifications

Dependencies

Transaction Reliability

Security

Web Services Standards Overview Resource Reliability Basic Profile Transaction Meta

Resource

Security Metadata Reliab.

Metadata Messaging Metadata Metadata Messaging

Messaging Security Security Security Messaging

Messaging Transaction Security Mess.

Messaging Reliability Secur.

© innoQ Deutschland GmbH. All Rights Reserved. The poster may also contain references to other company, organisation, brand and product names. These company, organisation, brand and product names are used herein for identification purposes only and may be the trademarks of their respective owners. This poster is not to be reproduced or transmitted in any form or for any purpose without the express permission of innoQ Deutschland GmbH. · Copyright