FACULDADE DE TECNOLOGIA SENAI FLORIANPOLIS

ISRAEL KRAISCH RODRIGO TOMASELLI

APLICAO DE TESTES DE SOFTWARE UTILIZANDO A ARQUITETURA ORIENTADA

A SERVIOS (SOA).

Florianpolis 2009

TCC

APLIC

AO

DE

TESTES D

E SO

FTWA

RE

UTILIZA

ND

O A

ARQ

UITETU

RA

OR

IENTA

DA

A SER

VI

OS

(SOA)

.

2009

Israel Kraisch Rodrigo Tomaselli

APLICAO DE TESTES DE SOFTWARE UTILIZANDO A ARQUITETURA ORIENTADA A SERVIOS (SOA)

Florianpolis (SC) Julho, 2009

Israel Kraisch Rodrigo Tomaselli

APLICAO DE TESTES DE SOFTWARE UTILIZANDO A ARQUITETURA ORIENTADA A SERVIOS (SOA).

Trabalho de Concluso de Curso apresentado Banca Examinadora do Curso de Ps-Graduao em Engenharia de Software com UML da Faculdade de Tecnologia do SENAI/Florianpolis como requisito parcial para obteno do ttulo de especialista em Engenharia de Software sob a orientao do Professor MSc. Sergio Akio Tanaka.

Florianpolis (SC) Julho, 2009

Israel Kraisch Rodrigo Tomaselli

APLICAO DE TESTES DE SOFTWARE UTILIZANDO A ARQUITETURA ORIENTADA A SERVIOS (SOA)

Trabalho de Concluso de Curso apresentado Banca Examinadora do Curso Engenharia de Software com UML da Faculdade de Tecnologia SENAI Florianpolis em cumprimento a

requisito parcial para obteno do ttulo de especialista em Engenharia de Software.

APROVADA PELA COMISSO EXAMINADORA EM FLORIANPOLIS, 15 DE NOVEMBRO DE 2009.

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

Prof. Sergio Akio Tanaka, MSc., (SENAI/Florianpolis) Orientador(a)

Prof. Ruy Tsutomu Nishimura, MSc., (SENAI/Florianpolis) Examinador

DEDICATRIA

Para nossas esposas Anelise e Tas.

Obrigado por seu amor e apoio.

AGRADECIMENTOS

Agradecemos a Deus por nos ter dado a vida, inteligncia e sade para termos condies 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 compreenso nos momentos de nervosismo e nas horas em que estivemos ausentes para a dedicao ao estudo e pelo interesse em nossa formao.

Aos mestres que contriburam para nossa formao.

Aos colegas de classe pelas contribuies e troca de experincias.

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

EPGRAFE

O futuro tem muitos nomes. Para os fracos o inalcanvel.

Para os temerosos, o desconhecido. Para os valentes a oportunidade.

Victor Hugo

Kraisch, Israel Tomaselli, Rodrigo. Aplicao de Testes de Software utilizando a arquitetura orientada a servios (SOA). Florianpolis, 2009. 78f. Trabalho de Concluso de Curso de Ps Graduao Latu Sensu - Curso Engenharia de Software com UML. Faculdade de Tecnologia do SENAI, Florianpolis, 2009.

RESUMO

Este trabalho apresenta a aplicao de testes sobre programas componentizados, utilizando a arquitetura orientada a servios (SOA). Atravs de um estudo de caso apresenta-se neste, os conceitos da tecnologia SOA, e de testes de software. As ferramentas utilizadas na aplicao dos testes foram SOAP-UI devido a sua documentao que de fcil entendimento e sua disponibilidade gratuita; e as normas IEEE 829 e IEEE 730 - 1998, por conter as regras bsicas para direcionar os testes de software, bem como os artigos e publicaes que compem a bibliografia, e auxiliaram no entendimento do escopo do trabalho realizado. O ensaio foi aplicado ao conjunto de programas que compem um produto de CRM de uma empresa da regio de Joinville, que no momento da realizao deste trabalho, no possua documentaes tcnicas sobre seus componentes, e nem procedimentos ou documentos de teste, a no ser procedimentos empricos realizados de forma manual. Os mtodos utilizados para o ensaio foram baseados no entendimento da tecnologia SOA, das tcnicas de teste e das ferramentas pesquisadas. Como resultado, da pesquisa, o teste foi realizado aplicando-se principalmente a tcnica de caixa branca, onde foi necessrio recorrer ao fonte dos programas para realizar os procedimentos de teste, e utilizamos a ferramenta SOAP-UI para criar os cenrios e a execuo dos testes, bem como a documentao tcnica necessria para o entendimento dos componentes do aplicativo de CRM. Com a realizao deste trabalho, foi possvel entender melhor os conceitos de SOA e de testes, e identificar que testar SOA exige planejamento, muito conhecimento tcnico, principalmente das linguagens de programao utilizadas, e das regras de negcio que compem cada componente do conjunto de programas. Com este trabalho identificou-se que a ferramenta utilizada no seria a ideal, e instigou-se a busca e a anlise de novas ferramentas para testes no s para o aplicativo de CRM, mas para os demais programas que a empresa onde este trabalho foi realizado.

Palavras-chave: SOA; Integrao; WebService.

Kraisch, Israel Tomaselli, Rodrigo. Aplicao de Testes de Software utilizando a arquitetura orientada a servios (SOA). Florianpolis, 2009. 78f. Trabalho de Concluso de Curso de Ps Graduao Latu Sensu - Curso Engenharia de Software com UML. Faculdade de Tecnologia do SENAI, Florianpolis, 2009.

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 Informao

DDT Test-Driven Development

LISTAS DE ILUSTRAES (FIGURAS, TABELAS E QUADRO)

Figura 1 Esquema demonstrativo adaptado, do paradigma de FIND-BIND-EXECUTE Fonte: Dos Autores (2007) .......................................................................................................24 Figura 2 Camadas de abstrao do SOA - Fonte: Dos Autores (2009).................................25 Figura 3 Modelo de abstrao de SOA para equipes de TI Fonte: Dos Autores (2009) ....28 Figura 4 Interao tradicional entre browser e servidor web. Fonte: Dos Autores (2007) ...30 Figura 5 - Interao entre browser e um WebService Fonte: Dos Autores (2007) ...............31 Figura 6 Ambiente de execuo dos testes Fonte: Dos Autores (2009). ............................45 Figura 7 Ambiente de execuo dos testes II Fonte: Dos Autores (2009). ........................48 Quadro 1 Requisio SOAP Com parmetros incorretos......................................................40 Quadro 2 Resposta de Requisio SOAP Incorreta..............................................................41 Quadro 3 Requisio correta ao mtodo verifyAccountAcces.............................................42 Quadro 4 Resposta a requisio ao mtodo verifyAccountAcces, permitindo o acesso.......43

SUMRIO

1 INTRODUO ..........................................................................................................12 1.1 DELIMITAO DO TEMA ...................................................................................13 1.2 OBJETIVOS.............................................................................................................13 ESTA SEO APRESENTA OS OBJETIVOS GERAIS E ESPECFICOS DO TRABALHO ........................................................................................................................13 1.3 JUSTIFICATIVA .....................................................................................................14 1.4 METODOLOGIA.....................................................................................................15 1.5 TIPO DA PESQUISA ..............................................................................................16

2 REVISO DE LITERATURA..................................................................................17 2.1 DESAFIOS EMPRESARIAIS NO CENRIO ATUAL .........................................17 2.2 A ARQUITETURA ORIENTADA A SERVIOS (SOA)......................................20 2.3 SOA E MUNDO DOS NEGCIOS .........................................................................33 2.4 TESTES DE SOFTWARE .......................................................................................34 2.5 DESENVOLVIMENTO ORIENTADO POR TESTES ..........................................40 2.6 CONSIDERAES SOBRE O CAPTULO ..........................................................41

3 RESULTADOS E DISCUSSES .............................................................................43 3.1 EXPERIMENTOS....................................................................................................44 3.2 CONSIDERAES SOBRE O CAPTULO ..........................................................49

4 CONCLUSES E RECOMENDAES ................................................................51 4.1 CONSIDERAES FINAIS ...................................................................................52

REFERNCIAS .....................................................................................................................53 APNDICES ...........................................................................................................................56 ANEXOS .................................................................................................................................75

1 INTRODUO

A demanda por programas, cada vez mais integrados e cujos processos sejam os melhores possveis, tem tornado a rea de Tecnologia da Informao (TI) das empresas cada vez mais complexa, ou seja, so muitos conjuntos de programas envolvidos em processos sistmicos, alm dos recursos de hardware que demandam cada vez mais infra-estrutura para execut-los.

Nos dias atuais, um produto ou servio deve ser o mximo possvel flexvel e adaptvel s necessidades de cada cliente, ou seja, feito sob medida. Tal demanda traz consigo, o desafio de integrao entre produtos e servios oferecidos, bem como a integrao dos processos e sistemas internos.

Como proposta de soluo, para resolver este cenrio catico em que se busca a integrao de diversos conjuntos heterogneos de programas, para as mais diversas reas de negcio, surge arquitetura baseada em servios services oriented architecture (SOA). A tecnologia tem como objetivo facilitar a integrao destas aplicaes atravs da exposio de servios, que podem ser acessados diretamente por qualquer outro aplicativo, desde que este tenha o acesso e respeite a padronizao necessria.

Conhecer SOA e o que a tecnologia prope, permitir s empresas fornecedoras de sistemas de informao, 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 estratgias de concorrncia.

Com o tempo de ciclo de vida dos produtos cada vez menor, dado s demandas cada vez mais crescentes pela personalizao as empresas tm que estar preparadas para criar, dispor e conseguir o retorno do investimento de modo rpido sob pena de perder oportunidades, deixando a concorrncia livre para absorver esta demanda.

A necessidade de velocidade e eficincia nestas adaptaes traz desafios para as reas de TI das empresas e seus fornecedores de software, principalmente o de entregar programas

cada vez mais confiveis, estveis e com o nvel 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 so foras propulsoras para uma atividade de teste cuidadosa e bem planejada. comum uma empresa fabricante deste tipo de produto, gastar at 50% do esforo de projeto total em teste.

O presente trabalho versa sobre a aplicao de metodologias de testes sobre aplicaes construdas, 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 aplicveis tecnologia.

Esta pesquisa ir apresentar os conceitos de SOA, testes, a importncia destes dois conceitos no mbito das empresas, bem como trar informaes sobre as ferramentas, mtodos e a prpria tecnologia.

1.1 DELIMITAO DO TEMA Testes unitrios de programas componentizados, baseados em SOA.

1.2 OBJETIVOS Esta seo apresenta os objetivos gerais e especficos 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 alcanar os objetivos especficos listados no tpico seguinte.

1.2.2 Objetivos Especficos

a) identificar a diferena da arquitetura SOA de outras arquiteturas de software;

b) pesquisar metodologias de auditoria e testes aplicveis a SOA;

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

1.3 Justificativa

Em uma empresa da regio de Joinville, existe um conjunto de programas que contm uma camada SOA chamado de CRM, na qual j se tentaram aplicar testes de verificao das unidades, regras de negcios e do sistema integrado de componentes. Porm, as ferramentas empregadas exigiram um alto custo e mo de obra que necessitou ser treinada durante a aplicao dos testes. Isto acabou por no apresentar o resultado esperado e a concepo original do projeto abandonada. vlido ressaltar que fatores externos, como a complexidade do ambiente devido componentizao, a instabilidade devido ao volume de manutenes e retrabalhos, demandas de implementao por parte dos stakeholders para a evoluo do produto, tambm contriburam para a inviabilizao do projeto.

O principal motivo da realizao deste trabalho que atualmente, a aplicao testada manualmente, e no h a assertividade e qualidade esperadas, no existem tambm tcnicas bem como processos definidos para a realizao dos testes. O que existe um procedimento emprico e sem garantia satisfatria, baseado em cenrios predefinidos.

O resultado deste trabalho poder servir de base para a aplicabilidade de testes unitrios utilizando ferramentas que possibilitem assertividade e qualidade no processo de manuteno do conjunto de programas, bem como para a definio de procedimentos e tcnicas que possam auxiliar a equipe de auditoria na difcil tarefa de testar e recolher resultados que possam identificar as falhas para a tomada de aes buscando a garantia da qualidade do produto, alm de sugerir mudanas 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 prope-se o estudo de ferramentas para verificar a possibilidade de uso.

O entendimento de SOA em si uma das maiores dificuldades, pois ela no um simples cdigo de programa que se possa classificar (como pode ser feito com programao estruturada e orientada a objeto), mas sim, todo um conjunto de regras para o desenvolvimento de uma aplicao.

O captulo 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 cenrio atual das empresas e das equipes de TI com relao ao uso de programas componentizados bem como mtodos de teste aplicveis a tecnologia, como testar e porque testes so importantes para as empresas na atualidade.

O captulo 3 apresenta os resultados e discusses, 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, tambm neste captulo demonstrado um teste unitrio utilizando a ferramenta escolhida.

Finalmente no captulo 4, apresenta-se a concluso e recomendaes, onde apesar do estudo para a busca de solues 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 tambm no 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 captulo tem como objetivo apresentar as tcnicas de pesquisas para o desenvolvimento do presente trabalho. Para a seqncia desta pesquisa, pretende-se cumprir as etapas relacionadas abaixo:

a) Entender o que significa o conceito de orientao a servio 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 automao dos testes utilizando as ferramentas

estudadas.

1.5 Tipo da Pesquisa

A pesquisa foi desenvolvida seguindo os procedimentos tcnicos relativos pesquisa bibliogrfica e experimental. Bibliogrfica, 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 variveis que seriam capazes de influenci-lo, definem-se as formas de controle e de observao dos efeitos que a varivel produz no objeto.

Para Lakatos e Marconi (2003), pesquisa de campo "aquela utilizada com o objetivo de conseguir informaes e/ou conhecimentos acerca de um problema, para o qual se procura uma resposta, ou uma hiptese, que se queira comprovar, ou, ainda, descobrir novos fenmenos ou as relaes entre eles".

Segundo Gil (1999) as pesquisas de campo exploratrias e descritivas visam proporcionar maior familiaridade com o problema em questo, tornando pblico o objetivo de descrever as caractersticas de determinada populao se torna mais objetivo, envolvendo o uso de tcnicas padronizadas de coleta de dados, questionrios e observao sistemtica.

Quanto a sua natureza, essa pesquisa ser de carter bsico, pois objetiva gerar conhecimentos novos teis para o avano da cincia sem aplicao prtica prevista, envolvendo verdades e interesses universais.

Como forma de abordagem do problema, a pesquisa ser do tipo qualitativa pois, segundo Gil(2002), a interpretao dos fenmenos e a atribuio de significados so bsicas no processo de pesquisa qualitativa e no requer o uso de mtodos e tcnicas estatsticas.

Os passos para a obteno dos resultados podem ser definidos de maneira relativamente simples. A anlise qualitativa depende de muitos fatores, como a natureza dos dados coletados, a extenso da amostra, os instrumentos de pesquisa e os pressupostos tericos que nortearam a investigao.

Do ponto de vista de seus objetivos, esta pesquisa , em sua essncia, descritiva, tratando-se da observao sistemtica e da realizao de levantamentos necessrios para o entendimento de suas etapas.

2 REVISO DE LITERATURA

Este captulo visa contextualizar o leitor quanto aos desafios, tanto tcnicos como de negcio, enfrentados pelas empresas e suas equipes de Tecnologia da Informao (TI); aborda a proposta de SOA como sugesto para minimizar estes desafios, e apresenta os principais conceitos sobre testes de software.

2.1 Desafios Empresariais no cenrio atual

No cenrio atual, em que as empresas esto sob forte competitividade, o sucesso de uma empresa depende da agilidade, de como so realizadas suas atividades, principalmente as ligadas tecnologia da informao (TI). A demanda por aplicativos, cada vez mais integrados e cujos processos sejam os melhores possveis, tem tornado a rea de TI das empresas cada vez mais complexa, ou seja, so muitos conjuntos de programas envolvidos em processos sistmicos, alm dos recursos de hardware que demandam cada vez mais infra-estrutura para execut-los.

Segundo Benedete Junior (2007), para a evoluo, e em muitos casos para a prpria sobrevivncia, as empresas enfrentam cada vez mais desafios, dentre eles citados:

a) concorrncia novas empresas trazem novas idias, produtos concorrentes geralmente com estruturas menores, obrigando as empresas j estabelecidas a se renovarem;

b) globalizao a concorrncia j no apenas local, empresas de porte internacional podem fazer frente, comprar antigos concorrentes, o contrrio tambm vlido, ou seja, empresas locais expandindo seus negcios para novos mercados, adaptando-se a culturas e leis onde se fizerem presentes;

c) aquisies e incorporaes para enfrentar a concorrncia, as empresas utilizam estratgias de modo a aumentar seu porte adquirindo concorrentes, ou produtos e servios complementares. Trazem, com isso, desafio de integrao entre produtos e servios oferecidos, bem como a integrao dos processos e sistemas internos;

d) clientes mais exigentes nos dias atuais, um produto ou servio deve ser o mximo possvel flexvel e adaptvel s necessidades especificas de cada cliente, ou seja, feito sob medida, une-se a esta condio o alto nvel de qualidade tanto dos produtos como do atendimento das necessidades e anseios do cliente, para estes casos, as empresas se utilizam de mecanismos e estratgias de gerenciamento do relacionamento com o cliente CRM;

e) menor tempo de vida dos produtos e servios com o tempo de ciclo de vida dos produtos cada vez menor, dado s demandas cada vez mais crescentes pela personalizao citada no item anterior (d), as empresas tm que estar preparadas para criar, dispor e conseguir o retorno do investimento de modo rpido sob pena de perder oportunidades, deixando a concorrncia livre para absorver esta demanda;

f) integrao com clientes, parceiros e fornecedores A cadeia produtiva da empresa depende de insumos, produtos e servios que devem estar integrados e de forma confivel. 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 negcio;

g) normas, regulamentos, inspees os processos internos e resultados devem ser transparentes, confiveis e conformes com as leis, regras e melhores

prticas de mercado para que a empresa possa acessar a novos mercados.

Esses fatores fazem com que as empresas estejam em constante processo de evoluo e adaptao s novas realidades do negcio. A necessidade de velocidade e eficincia nestas adaptaes traz mais um desafio:

O relacionamento interno das reas de negcio 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 negcio possa fazer frente aos desafios do mercado. Entretanto, o que normalmente se v uma TI no

suficientemente alinhada ao negcio, o que pode limitar a evoluo da empresa e faz-la perder oportunidades.(BENEDETE, 2007).

2.1.1 Desafios no mbito da Tecnologia da Informao

A maioria das empresas que constroem, e mesmo as que solicitam novos programas, no conseguem ainda separar os processos (regras de negcio) das demais funes do aplicativo, construindo assim aplicativos que no podem ser componentizados e reutilizveis.

De acordo com (NEXTG, 2007) as equipes de TI so constantemente desafiadas a atender as necessidades de negcio e tecnologia das empresas, estes desafios so causados por:

a) aumento da demanda o negcio sempre precisa de novos sistemas, novas funcionalidades. As equipes de TI das empresas geralmente, no conseguem dar vazo aos projetos, criando filas de atendimento. O que gera oportunidades como a BPO. Apesar dos esforos em novas metodologias e ferramentas de desenvolvimento, a produtividade baseada nas tecnologias atuais ainda no suficiente;

b) prazos curtos outrora, sistemas costumavam levar anos para serem entregues. Com o advento da Internet e ferramentas colaborativas, os prazos tm se reduzido, chegando a ocorrer necessidades que devem ser atendidas em poucos dias;

c) qualidade sistemas que so executados em modo batch (envolvendo grandes lotes de registros, sem interao com o cliente, geralmente executados no perodo noturno) j no so aceitveis, no h espao nem tempo para erros, ou re-processamentos, em caso de falhas. Hoje, praticamente todos os sistemas esto on-line, com clientes aguardando o resultado, em tempo real. Uma falha pode resultar em grande perda monetria 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 cpia das bases de dados, disponibilizar alteraes e manutenes nas aplicaes, sem causar impacto

para os clientes. Hoje, os sistemas so acessados de qualquer lugar do mundo e os clientes trabalham a qualquer hora e no mais limitados ao horrio comercial, ou seja, os sistemas devem estar onipresentes e disponveis. A disponibilidade destas aplicaes e da infra-estrutura de base constantemente monitorada e medida em fraes, entre 99,97% e 99,99%;

e) integrao aqui o desafio integrar sistemas construdos em pocas, com tecnologias, padres e plataformas diferentes entre si, o que costuma consumir grande parte dos investimentos, para que conjuntos sistemas construdos pela TI das empresas, pacotes adquiridos do mercado, aplicaes incorporadas na aquisio/fuso 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 capacitao e atualizaes de hardware, software e mesmo das aplicaes, obrigando as equipes de TI atualizao 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 usurios dos sistemas e automatizar tarefas;

h) controles mecanismos de controle e monitorao so necessrios para aferir e garantir atributos como segurana, qualidade e conformidade com normas do mercado e com acordos de nvel de servio (SLA), que cada vez mais regem o relacionamento (prestao de servios) 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 no seja necessrio descartar um aplicativo e seu legado, bastando que se construa um servio que possa acess-lo, aproveitando assim, seno o todo, pelo menos partes deste sistema, com SOA possvel fazer o re-uso de software, o que reduz o esforo de desenvolvimento de novas aplicaes, diminuindo custos, atendendo com mais agilidade novos requisitos de negcios (NEXTG, 2007).

2.2 A Arquitetura Orientada a Servios (SOA)

Quando se ouve falar em SOA (Service Oriented Architecture ou Arquitetura Orientada a Servios), normalmente o termo associado tecnologia WebService (esta ser descrita mais adiante).

2.2.1 Conceituando SOA

A Arquitetura Orientada a Servios, como o prprio nome diz uma arquitetura, ou seja, um conjunto de princpios, padres e orientaes que englobam desde a viso de negcio at suas possveis alternativas tecnolgicas(BENEDETE, 2007).

SOA reuniu os esforos dos principais provedores de tecnologia (como a IBM, Microsoft, SAP, Oracle) em torno de um conjunto de padres e tecnologias que tornam possveis a interoperabilidade e re-uso de aplicaes, independentemente de linguagens e plataformas de hardware ou software(BIEBERSTEIN, 2006).

A arquitetura descreve uma categoria de aplicativos compostos cujo princpio fundamental que suas funcionalidades sejam implementadas e disponibilizadas na forma de servios, fracamente acoplados, orquestrados e organizados em um barramento de servios formados pelos componentes: provedor de servios, que disponibiliza contratos; interfaces acessveis atravs de WebService (ou outra forma de comunicao baseada em computao distribuda utilizando o paradigma de request/reply) e o consumidor de servio, separando a lgica comercial e oferecendo transparncia de local para provedores e consumidores de servios.

A definio de SOA deve ser ajustada ao pblico alvo, ou seja, para as equipes de negcio, deve-se enfatizar a flexibilidade na adaptao e disponibilizao de novos negcios, baseados em processos e servios bem definidos, j para o pessoal de tecnologia, devem-se detalhar os aspectos tecnolgicos, para no tornar a definio abstrata ou abrangente demais.

2.2.2 Algumas definies, 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 visveis desses elementos, e o relacionamento entre eles (BASS, CLEMENTS, KAZMAN., 2003). Ou seja, arquitetura so modelos e padres que permitem documentar, facilitar o entendimento e direcionar as diversas dimenses da construo das aplicaes, como exemplos, a localizao e armazenamento dos dados, os mecanismos com que os usurios interagem com os sistemas e como os

programas se conversam (BENEDETE, 2007). WebService uma famlia de tecnologias que consistem de especificaes,

protocolos e padres da indstria, cujo objetivo permitir que aplicaes (mesmo baseadas em diferentes plataformas de hardware e software ou linguagens) possam se comunicar de uma maneira segura e consistente. WebService uma implementao tecnolgica dos conceitos de SOA e, por isso, normalmente se confunde com a mesma (BENEDETE, 2007).

Processos de negcio um conjunto de tarefas logicamente relacionadas para se obter um resultado de negcio definido(BIEBERSTEIN, 2006). A Gartner define processo de negcio, como Um conjunto de atividades e tarefas executadas por recursos (pessoas e sistemas) usando uma variedade de informaes (documentos, imagens, conhecimento), interagindo de vrias maneiras (seqencialmente ou de maneira no prevista), guiadas por polticas e princpios (objetivos, regras de negcio).(AREVOLO, 2006).

Servios Do ponto de vista do negcio, so as funcionalidades providas pela empresa para seus clientes e parceiros, por exemplo, um servio de saque, um servio de abertura de contas. Do ponto de vista de TI, trata-se de um componente de aplicao cujas funcionalidades esto disponveis para outros sistemas ou usurios.(BENEDETE, 2007).

Componentes So pedaos de software que podem ser reutilizados, pois foram desenvolvidos com esta preocupao (interface padro e outras regras) (BENEDETE, 2007).

Reutilizao O re-uso um dos pilares da SOA, pois ele que possibilita o ganho de velocidade na construo de novas aplicaes, a reduo dos custos e aumento da qualidade, atravs do reaproveitamento de componentes prontos, testados e confiveis (BENEDETE, 2007).

Caixa-preta So componentes que podem ser utilizados por outras aplicaes, sem que haja preocupao de como foram construdos (tecnologias, linguagens) (BENEDETE, 2007).

Fracamente acoplados uma abordagem para construo de aplicaes que foca na simplicidade e autonomia entre os componentes. Os programas interagem (trocam dados) de uma maneira que a dependncia entre eles minimizada, facilitando a alterao ou mesmo a troca de um deles (BENEDETE, 2007).

Orquestrados As ferramentas que compe a infra-estrutura SOA provm componentes para gerenciar (orquestrar) as interaes (fluxo) entre os servios dentro de um processo de negcio.(BENEDETE,2007).

Nvel de servio So acordos que definem caractersticas de como o servio deve ser provido, por exemplo: tempo de resposta, disponibilidade e quantidade de falhas. A definio dos nveis de servio est diretamente ligada s melhores prticas da gesto de processos de negcio (BENEDETE,2007).

Framework uma estrutura bsica de software e padres, construda para auxiliar e organizar o modo de desenvolver outras aplicaes (BENEDETE,2007).

Uso de padres 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 comunicao distribuda. SOA est baseada no uso de padres que so amplamente aceitos pela indstria de TI, e a maioria dos grandes fornecedores de software e ferramentas para desenvolvimento est gradativamente migrando suas ofertas de produtos no s para suportar SOA, mas tambm utiliz-la como soluo interna para construo de seu software (BENEDETE,2007).

Uma das mais importantes caractersticas sobre SOA que ela libera o negcio das restries da tecnologia, ou seja, "SOA permite aos responsveis pela empresa a tomar decises de negcio suportadas pela tecnologia ao invs de tomar decises 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 anlogo a "Ciclo de Deming" (PDCA) aplicado aos servios, que define o ciclo que envolve o planejamento, a execuo, o monitoramento e a tomada de ao 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 usurio do servio a aplicao que solicita um servio. A aplicao solicita atravs dos registros de servio (contratos) as informaes referentes localizao do servio. O registro de servio uma aplicao que retorna as informaes para uso de um servio;

b) O provedor de servios funciona de forma semelhante a um sistema de pginas amarelas de uma lista telefnica, oferecendo os servios para que possam ser encontrados de forma fcil.

Como exemplo a arquitetura tem-se um E-commerce qualquer. A requisio realizada atravs de um cliente. O cliente que pode ser um navegador internet qualquer, este solicita o preo de um determinado produto, o WebService recebe e processa o pedido e retorna uma resposta contendo o preo do produto.

A abordagem SOA permite substituir ou atualizar componentes individuais no aplicativo sem afetar outros componentes ou o processo como um todo. Alm disso, podem-se especificar independentemente caminhos alternativos atravs dos quais os componentes do aplicativo trocam mensagens (NETBEANS, 2009).

2.2.3 Camadas de abstrao da SOA

Modelos de abstrao facilitam o entendimento de conceitos por organizarem idias, funcionalidades e documentaes no nvel de detalhe mais adequado para cada tipo de necessidade. A Figura 2 mostra as diversas camadas que compe a SOA e pode ser utilizada para descrever o conceito para as equipes de negcio de maneira a propor o claro entendimento de como funciona a arquitetura, facilitando a apresentao da arquitetura a equipes de negcio.

Figura 2 Camadas de abstrao do SOA - Fonte: Dos Autores (2009)

a) camada corporativa descreve o negcio da empresa, identifica os processos de negcio chave da empresa - que so essenciais para sua vantagem competitiva - e que, portanto, devem ser controlados da maneira mais prxima possvel; e os processos de suporte, que podem at ser delegados para

parceiros. H diversos frameworks, a exemplo do framework de Zachman disponvel 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 informao. As idias propostas resultaram de conhecimentos e experincias de outras disciplinas mais antigas (arquitetura, engenharia da produo) e rapidamente se tornaram numa referncia para todos aqueles que tm algum interesse no tema da arquitetura de sistemas de informao. Infelizmente, e apesar da relevncia do tema, muitos destes conceitos continuam desconhecidos entre as equipes de TI. De acordo com autor, a arquitetura o conjunto de representaes descritivas (modelos) relevantes para a descrio de um objeto, de forma a que este possa ser construdo de acordo com os requisitos (de qualidade) e mantido ao longo da sua vida til. Esta definio consideravelmente genrica e informal e no indica o mbito do termo arquitetura; de fato, no caso da abordagem proposta por Zachman, ela refere-se quer aos sistemas de informao quer empresa, uma vez que o mesmo modelo apresenta relativamente a cada conceito a perspectiva do negcio e dos sistemas de informao. O Framework de Zachman uma estrutura lgica de classificao e apresentao dos modelos de uma organizao relevantes para a respectiva gesto, bem como para o desenvolvimento dos seus sistemas...... Nesta perspectiva, modelar um sistema significa determinar e representar um conjunto de informao, sobre vrios tpicos (colunas da matriz), relevante para vrios 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 consideraes de arquitetura, principalmente por habilitar o estabelecimento de parcerias (clientes, fornecedores) nas camadas de processo e servio;

b) camada de processos nesta camada que os processos de negcio so 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 dependncias da camada de servio. Como se podem confundir os conceitos de servio e de processo de negcio, considera-se que os processos so definidos uma nica vez e usados dentro de um contexto nico, j os servios podem ser reaproveitados em diversos contextos com diferentes processos de negcio, departamentos ou linhas de negcio;

c) camada de servios responsvel por mapear os servios que provm s funcionalidades bsicas, tcnicas e de negcio. O negcio identifica as funes crticas para atender o negcio, como identificao do cliente ou clculo de taxas, enquanto os especialistas de TI criam funes tcnicas para suportar os requisitos do negcio, como servios de segurana;

d) camada de componentes a camada onde so mapeados os componentes que tm potencial para se transformarem em servios, normalmente atravs de tcnicas bottom-up (anlise das aplicaes e identificao de funes que devem ser promovidas a servios, por terem o potencial de servirem a mais sistemas). Componentes so os blocos de construo de servios na arquitetura SOA e embora vrios sejam construdos com esta finalidade, a maioria ser reaproveitada a partir de aplicaes j existentes, atravs de tcnicas 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 orientao a objetos, ela o estende, pois tem-se que identificar que a classe no apenas pblica, ou seja, que pode ser utilizada por outras aplicaes atravs de chamadas nativas da plataforma, mas sim que ela importante o suficiente para ser promovida a componente/servio, e assim pode ser chamada por mecanismos de maior poder de abstrao, como WebService. Esta deciso muitas vezes envolve os cenrios de uso da funo, para balancear requisitos no funcionais como desempenho e desacoplamento.

Em contrapartida a Figura 3, prov as equipes de TI, uma demonstrao da interao entre as camadas como um exemplo prtico, aqui se abstrai ainda mais as camadas. Demonstra-se a interao entre as camadas de processos com a camada de servios, seus componentes de servio, a interao da camada de servios com a camada de integrao, seus sistemas legados e componentes.

Camada de

Integrao

Camada de

Servios

Camada de

Negcios

B1

B2B3

B4

B5 B6

B1

B2B3

B4

B5 B6

B7 B8 B9

B7 B8 B9

Figura 3 Modelo de abstrao 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 avano tecnolgico. Propem a comunicao por protocolos padres como o HTTP e XML promovendo a evoluo de servios, onde s lgicas de negcio so expostas atravs de regras de programticas (SOA-RM, 2009).

Por definio, WebServices so servios distribudos na WEB que processam mensagens SOAP codificadas em XML enviadas atravs do protocolo HTTP.

O principal motivo do crescimento desta tecnologia devido ao SOA, que consiste em uma coleo de servios autnomos identificados por URLs, com interfaces criadas atravs de WSDL e processamento de mensagens XML.

2.2.4.1 Vantagens do uso de WebServices

Existem inmeras vantagens no uso de sistemas baseados em WebService, principalmente por proporcionar de forma simples e rpida oportunidades que seriam impossveis de serem concretizadas devido alta complexidade e custo em outras tecnologias equivalentes. O sucesso de uso depender de uma boa avaliao e estudo para a aplicao desta tecnologia. Nem tudo pode ser resolvido atravs 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;

prospeco de novos mercados e negcios.

O que vai ao encontro da maioria das necessidades j expostas como desafios para as equipes de TI e para as empresas no cenrio atual dos negcios.

A arquitetura orientada a servios difere de sistemas orientados a objetos (OO) e sistemas procedurais no que diz respeito ligao entre os componentes.

Em geral sistemas OO e procedurais so conectados atravs de chamadas baseadas em tipos e nomes e, em uma SOA, a ligao consiste na troca de mensagens - o que permite estabelecer restries para o envio/recebimento de informaes separando de forma clara a estrutura comportamental da estrutura de descrio.

Como visto anteriormente, um WebService e uma aplicao de software que pode ser acessada remotamente atravs de diferentes linguagens e protocolos. Normalmente, um WebService e identificado atravs de urls como qualquer outra pgina web. Na maioria dos sistemas web a resposta a requisies na Internet feita atravs de chamadas efetuadas por um navegador web, resultando no retorno de contedo em texto no formato HTML. A Figura 4 ilustra melhor esta interao:

Figura 4 Interao tradicional entre browser e servidor web. Fonte: Dos Autores (2007)

Webservices e consumidores de WebService so geralmente associados a negcios do tipo B2B. Isto acontece quando a empresa que prov o servio tambm cliente de outro servio. Os WebServices so projetados para suportar interao e interoperabilidade podendo ser, ou no, de arquiteturas diferentes.

O acesso ao WebService semelhante na forma de acesso tradicional internet, a diferena encontra-se no contedo que enviado na requisio do cliente e o retorno do servidor. Os clientes de um WebService enviam mensagens SOAP contendo chamadas a um mtodo e parmetros que por ventura sejam necessrios. O servidor por sua vez interpreta esta chamada e retorna a informao XML resultante do processamento, conforme demonstrado na Figura 5. Por ser uma troca de dados em formato amigvel pode ser transferida de um computador para outro no 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 verses de protocolos e software que esto sendo utilizadas no servidor.

Figura 5 - Interao entre browser e um WebService Fonte: Dos Autores (2007)

2.2.4.2 Desvantagens do uso de WebServices

Os WebServices resolveram importantes questes que eram, at ento, de difcil soluo na comunicao entre sistemas, porm, no uma soluo mgica e deve ser analisada quanto ao atendimento dos requisitos da aplicao a ser construda ou acoplada.

Existem ainda questes polmicas e no previstas pelo protocolo SOAP, dentre as quais a segurana, o suporte e as transaes, a exemplo do artigo SOA is dead; Log life Services em que a autora, apresenta o artigo como um obiturio, indicando que SOA morreu no dia 01/01/2009, devido recesso econmica mundial, e que apenas sobrevive, atravs dos diversos produtos gerados a partir da tecnologia, e que dependem de servios, indicando inclusive que SOA fracassou e que no entregou, exceto em raras excees, os benefcios que prometia, e que embora o termo que define SOA esteja morto, a exigncia de arquitetura orientada a servios mais forte do que nunca. Esta mesma autora, dentre outros especialistas da rea, estar presente no 2 Simpsio 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 ressurreio de SOA. (Manes, 2009)

Como os servios funcionam sobre o protocolo HTTP que por sua vez no seguro, a nica opo atualmente e agregar ao seu servio o uso do SSL (secure socket layer). O SSL protege com boa segurana o envio de informaes, porm, torna as transaes mais lentas sendo, muitas vezes, inadequado a grandes volumes de transferncia de dados.

No h garantia que determinada transao ser completada em dependncia de outras, principalmente se os provedores de servios forem web services de fornecedores distintos.

A falta de padres tambm prejudica o desenvolvimento dos servios, a autenticao, a comunicao de feedback dos resultados so itens que no esto totalmente padronizados e dependem das implementaes de cada desenvolvedor.

Desempenho uma questo que tambm deve ser observada, visto que todo servio trafega atravs da Internet. Como a velocidade de transmisso na Internet varivel e no se podem controlar, sistemas onde desempenho seja vital no so candidatos a adotarem esta tecnologia.

O processamento envolvido outro ponto crucial. Como os dados so trocados em formato XML, o que na pratica um formato de texto, h grande consumo de processamento para a converso dos dados. Se os dados forem complexos (como binrios e imagens) a codificao e decodificao destes dados podem levar tempo, o que pode causar a impresso ao usurio de que o programa est travado ou ainda provocar a desconexo do servio por limite de tempo de execuo.

Os web services herdam, por sua vez, as deficincias inerentes implementao de SOA.

2.2.4.3 Itens bsicos de uma implementao de Web services

Basicamente, hoje, possvel implementar web service utilizando componentes prontos de grupos conhecidos no mercado, como o Apache Group que implementa componentes de cdigo aberto, ou de fornecedores comerciais como Microsoft ou IBM, entre outros.

Em geral, podem ser desenvolvidos por qualquer linguagem de programao baseadas em sockets.

Duas organizaes importantes, O World Wilde Web Consortium (W3C) e a Organization for the Advancement of Structured Information Standards (OASIS) controlam e desenvolvem especificaes e padronizao para a arquitetura SOA e dos web services (entre outros), assim, se um software for construdo dentro dos padres recomendados por estas organizaes, a troca de um fornecedor de software que utilize os padres estabelecidos no deve causar impacto na operao do cliente, j que a estrutura base de provimento e utilizao do servios ser a mesma.

Existem cinco itens bsicos nesta arquitetura:

HTTP: Hipertext Transport Protocol usado para transportar as informaes pela rede ou internet.

XML: Extensible Markup Language utilizada na de definio e semntica dos dados.

SOAP: Simple Object Access Protocol o formato de mensagens para chamada de mtodos remotos.

WSDL: Web services Description Language descreve as caractersticas oferecidas pelo servio.

UDDI: Universal Discovery, Description and Integration descreve um tipo especial de registro que lista os web services na Internet.

No se abordar cada item da implementao bsica, at porque esto em constante adaptao sendo possvel verificar cada tpico atravs das referncias definidas pela W3C e pela OASIS, no Anexo II, encontra-se um mapa descrevendo como pode ser feita a implementao de web service explanado de forma abrangente.

2.3 SOA e mundo dos negcios

Existente apenas acerca de seis anos (NEXTG, 2007), SOA ainda no aplicada em sua essncia. Apenas poucas empresas de grande porte esto realizando um movimento de converso e ou adaptao, de suas aplicaes para este novo conceito.

Uma recente previso da Gartner diz que: SOA ser utilizada parcialmente em mais de 50% das novas aplicaes de misso crtica e processos de negcio criados em 2007, e mais de 80% at 2010 (70% de probabilidade) (NATIS, 2006).

Tambm segundo a Gartner, Organizaes que comecem sua transformao para BPM durante 2006 e 2007 sero recompensadas pelo domnio de suas indstrias por volta de 2010. Ter uma arquitetura de processos (parte de uma arquitetura de negcios) e alinhar as iniciativas de BPM com as iniciativas de SOA so atividades chaves a serem realizadas em 2007.

Utilizando a abordagem SOA esto surgindo movimentos de terceirizao da regras de negcio, originando os chamados Business Process Outsourcing BPO, empresas especializadas em mapear, integrar, automatizar e aperfeioar programas e processos de negcio, e que executam os mais variados servios, que uma organizao no deseja ou no precisa executar com recursos prprios, para que estas organizaes, possam concentrar seus

investimentos no que realmente faz parte de seu core business.

2.4 Testes de Software

Esta seo aborda a conceituao 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. Sero apresentados termos usuais apenas para conceituar o leitor e no sero discutidos em profundidade cada tpico apresentado. Em trabalho relacionado (PERES, R.; NOGUEIRA, A. R., 2004), os autores apresentam individualmente cada tpico conceituando testes de software com maior profundidade, os conceitos abordado tambm 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 implementao de testes de software.

2.4.1 Nivelamento conceitual Teste um conjunto de atividades que podem ser planejadas antecipadamente e

conduzidas sistematicamente. Por essa razo, um gabarito para teste de software - um conjunto de passos no qual se podem alocar tcnicas de projeto de casos de teste e mtodos de

teste especfico - deve ser definido para o processo de engenharia de software (PRESSMAN,1995; NEMETZ,1997).

A atividade de teste de software um elemento crtico da garantia de qualidade de software e representa a ltima reviso de especificao, projeto e codificao.

O destaque crescente do software como elemento de sistema e os custos envolvidos associados s falhas de software so foras propulsoras para uma atividade de teste cuidadosa e bem planejada. comum uma organizao de software gastar at 50% do esforo de projeto total em teste. Esta a razo que leva a maioria das pessoas a acreditar que o software no bem testado antes de ser fornecido ao cliente.

A seguir so 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 inteno de descobrir um ou vrios erros;

b) um bom caso de teste aquele que tem uma elevada probabilidade de revelar um erro ou um conjunto de erros ainda no descoberto;

c) para que um teste seja considerado bem-sucedido este dever revelar um erro ainda no descoberto.

Dentre as citaes de (MYERS,1979) pode-se dizer que a atividade de teste de software o processo de revisar especificaes, projetos e programas com a inteno de descobrir erros. Alguns dos principais itens que so comuns aos autores e pesquisadores, referenciados neste trabalho, do assunto teste de software e que descrevem os fundamentos e princpios desta atividade esto relacionados abaixo (PRESSMAN,1995; CHANG,1999; ROCHA,2001; NIELSEN,1993; NEMETZ,1997):

a) a atividade de teste no prova a ausncia de erros, apenas a existncia dos mesmos;

b) bons casos de teste so aqueles que encontram falhas no sistema at ento no descobertas;

c) bons casos de teste so projetados levando em conta os requisitos do projeto;

d) um critrio que pode ser adotado para determinao do esforo a ser gasto na atividade de teste de software verificar qual o grau de severidade das conseqncias ocasionadas pelo seu mau funcionamento;

e) a probabilidade de encontrar um erro numa determinada parte do sistema proporcional ao nmero de erros j encontrados nesta parte;

f) o nvel de esforo previsto para testes deve levar em considerao a integridade e criticidade do projeto, o custo por mau funcionamento, os requisitos de qualidade e acurcia especificados.

g) os autores estudados em sua maioria, concordam que os programas devem, preferencialmente, ser testados por pessoas que no esto envolvidas no processo de desenvolvimento, mas sim por uma equipe independente. Pode ocorrer tambm a interao dos desenvolvedores com a equipe independente, justificando as decises tomadas durante o projeto, ajudando tambm na reviso do projeto.

Testes desafiam as suposies, riscos e as incertezas e trata-as por meio de demonstraes concretas e avaliaes imparciais, evitando abordagens que no avaliem o software de forma adequada e efetiva, expondo os problemas e pontos fracos e, no 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 princpios da atividade conforme j descritos acima, foram ao longo do tempo criadas e aperfeioadas metodologias que descrevem as melhores prticas 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 preveno, medio, correo, materiais, equipamentos, etc.

Caso de Teste - conjunto de passos que descrevem um cenrio de teste cuja principal funo comparar as respostas aos estmulos 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 execuo, riscos, a mitigao dos riscos, etc.

Suite de Testes - indica um conjunto de casos de testes que so agrupados para um objetivo comum.

Automao de Testes - testes podem ser automatizados por meio da utilizao 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 Tambm Bug.

2.4.2 Estratgias de teste

2.4.2.1 Estratgia de testes Bottom-up

Nesse tipo de teste cada mdulo ou componente testado individualmente e, pouco a pouco, os demais componentes so combinados e testados. Em alguns casos simuladores ou mocks, so utilizados no lugar dos componentes reais para substiturem componentes que so necessrios, porm ainda no disponveis.

2.4.2.2 Estratgia de testes Top-Down

Nesta estratgia de teste, a aplicao testada como um todo do incio ao fim do ponto de vista do usurio final. Ou seja, o sistema gerado por completo, instalado em um ambiente pr-determinado e o testador executa os casos de teste, simulando situaes de uso reais.

2.4.3 Tipos de Testes

2.4.3.1 Testes Funcionais (Caixa Preta) Nessa estratgia, os testes so executados por meio do fornecimento de dados de

entrada ao componente ou ao conjunto de programas, que est sendo testado e pela anlise do resultado produzido, porm, sem entendimento ou verificao do processo que produziu o resultado, utilizado geralmente para verificar uma funo completa encontra-se de acordo com os requisitos especificados.

2.4.3.2 Testes de Configurao, instalao e suportabilidade

Nessa categoria de testes, os testes so executados contra todos os ambientes (hardware e software) suportados. Para manter uma matriz contendo as plataformas/ambientes suportadas e o estado da execuo 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 Integrao ou Subsistemas

Nesta estratgia de testes, os diversos sistemas que compem uma soluo de software so combinados e configurados num ambiente semelhante ao ambiente onde sero usados na situao real. Dessa maneira possivel testar o fluxo das operaes do comeo ao fim do ponto de vista do usurio final. Tambm conhecido como Testes de Sistema

2.4.3.4 Testes de Carga, Volume, demanda e conteno

Essa categoria de teste tem a funo de aplicar uma carga de operaes ou transaes simultneas contra a aplicao a fim de conferir se a aplicao atende os requisitos de performance ou resposta.

2.4.3.5 Testes de recuperao de falhas

Classe de testes cuja principal funo avaliar como a aplicao lida com problemas inesperados e desastres.

2.4.3.6 Testes de Regresso

Essa abordagem tem a funo de garantir que os mdulos ou componentes da aplicao que no foram modificadas ainda funcionam corretamente aps o programador modificar alguma outra parte da aplicao.

2.4.3.7 Teste de valores limites

Tcnica de teste utilizada para selecionar os dados que faro parte da execuo de um teste por meio dos limites (mximo e mnimos) das entradas e sadas (procedimentos ou funes) de um componente de software.

2.4.3.8 Teste de unidade ou componente

Os testes de unidade ou de componentes envolvem algumas combinaes de testes estruturais e funcionais, verificando a menor unidade do projeto de software, neste teste os caminhos mais importantes so testados para descobrirem erros nos fontes dos programas.

2.4.3.9 Testes de Cobertura

So 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 usurio final, o que depende de muitos fatores, dentre ele o nvel de segurana exigido.

2.4.3.10 Testes de Aceitao

So testes conduzidos de forma que garantam que o programa atinja as necessidades do usurio final por meio da execuo de cenrios e dados de testes reais. Veja tambm Testes Integrados.

2.4.3.11 Criterios de Aceitao e Falha

Comparao 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 Verificao

Garante que o software est sendo desenvolvido conforme os padres e processos definidos pela organizao.

2.4.3.13 Processo de Validao (Alfa e Beta) Garante que o sistema est sendo desenvolvido conforme as definies 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 promoo de uma importante prtica de testes: escrev-los primeiro. O que tambm promoveu a refatorao contnua dos programas, isso para que os cdigos destes programas sejam escritos com maior qualidade, com maior clareza e menos duplicidade.

Muitas obras atuais de literatura sobre a programao orientada a objetos, sejam para qual for metodologia aplicada, apiam a abordagem de Test-Driven Development (Desenvolvimento Orientado por Testes ou DDT).

Na abordagem DDT para programas orientados a objetos, os cdigos de testes so escritos antes de a classe ser testada e o desenvolvedor escreve os cdigos de teste para cobrir a maior parte possvel do cdigo de produo (LARMAN, 2007).

2.5.1 Vantagens da abordagem DDT:

Testes de unidade so realmente escritos - Geralmente os programadores evitam escrever testes unitrios, deixando a atividade em segundo plano, nesta abordagem, o teste unitrio o ponto de partida para o programador realizar o desenvolvimento.

Satisfao do programador que conduz escrita de testes mais consistentes O programador se sente desafiado psicologicamente a escrever o cdigo de programas para que estes passem nos testes , deixando a sensao de meta alcanada,

Clareza de interface e comportamento detalhado A prtica de detalhar o comportamento de uma classe (unidade de programa) sem que a mesma exista, ou partes ainda no existam, fora ao programador ou analista que ele pense em cada detalhe do cdigo que esta para construir, e esse raciocnio promove

melhoras e esclarece detalhes de projeto, que podem inclusive originar solicitaes de mudana 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 no utilizada.

Verificao provvel, repetvel e automatizada medida que se vo construindo cdigos de testes, estes vo sendo acumulados e podem ser utilizados para verificao e correes de uma forma significativa. Podem-se aplicar os testes construdos de forma que seja possvel a regresso, e verificao da evoluo de um componente ou at do programa em seu estgio atual de programao e a aplicao pode ser realizada de forma automatizada, o que justifica o investimento inicialmente penoso em escrever os testes antecipadamente.

Assertividade e Confiana Ao modificar um cdigo de programa existente, pode-se aplicar os testes preexistentes, para verificar se a manuteno do cdigo, causou impacto ou erro, fornecendo uma resposta mais rpida para ajustar o programa (LARMAN, 2007).

2.6 Consideraes sobre o captulo

Nesse captulo foram apresentados os principais conceitos e padres utilizados por servios web na concepo de sistemas. Esses padres so caracterizados pela independncia de plataforma de hardware e software, proporcionando maior abertura aos sistemas que utilizem SOA. Alm dos padres e especificaes tais como SOAP, WSDL e UDDI, que formam a base dos servios web, foram apresentados tambm os principais desafios encontrados pelas empresas e por suas equipes de TI no que tange a utilizao de sistemas baseados em SOA, bem como os principais conceitos de teste de software de maneira a produzir o entendimento bsico 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 captulos anteriores, muito recente, sugere-se que se definam estratgias para a padronizao de procedimentos principalmente de desenvolvimento dos programas e de sua documentao, bem como de testes que sejam aplicveis a estes programas ou sistemas, para a promoo de melhorias tanto do produto final como do ambiente de trabalho conforme apresentou-se no tpico Desenvolvimento Orientado por Testes.

Desta forma, obtm-se um ganho na reduo da manuteno, e conseqentemente reduo nos custos com testes e retrabalhos, pois atravs das tcnicas abordadas nos captulos anteriores, ao se reutilizar os cenrios de teste e verificar os erros que um conjunto de programas integrados atravs de SOA possa apresentar logo na sua fase inicial de construo, obtendo-se ento um nmero maior de programas a se manter funcionando durante o processo de construo, sendo que a cada nova iterao no processo de desenvolvimento, ou manuteno, os testes j aplicados podem ser reaplicados, para a melhoria e refinamento, contnuos dos programas gerados.

As empresas que utilizam sistemas baseados em SOA tambm podem se beneficiar de igual maneira, visto que suas equipes de TI, podem produzir cenrios de testes a partir das tcnicas de testes apresentadas e antes de colocar um sistema em produo, verificar se o mesmo atende as necessidades de determinado departamento ou negcio.

A seguir, ser apresentado um caso pratico da aplicao de procedimentos de testes, planejados e de uma ferramenta de testes a um sistema que utilizam componentes SOA em sua infra-estrutura.

3 RESULTADOS E DISCUSSES Na maioria das bibliografias pesquisadas no 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 bsicos de testes ou de SOA, no h uma referncia conclusiva a qual se possam apoiar e embasar prticas de teste de software nesta tecnologia.

Foram pesquisadas ferramentas que pudessem auxiliar na tarefa de testar a arquitetura orientada a servios, porm muito poucas referncias 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 prtica e aplicao dos testes de software sobre o software componentizado, utilizando a tecnologia SOA (CRM), foram seguidas metodologias de teste conforme as sugeridas e verificadas na reviso bibliogrfica deste trabalho.

Utilizou-se dos artefatos de plano de testes, casos e cenrios de testes, e o relatrio de aprovao da execuo dos testes.

Para a execuo dos procedimentos utilizou-se a seguinte tcnica:

Observaram-se os requisitos de testes presentes no banco de requisitos, a partir destes foi gerado o plano de testes (vide Apndice I), com o objetivo de registrar a estratgia de testes a ser adotada, para a coordenao e conduo dos testes, os nveis 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 critrios de concluso e aceitao dos testes.

No projeto de teste tambm definiu-se os requisitos a serem testados, as categorias de testes, os tipos de testes bem com a priorizao dos mesmos onde delimitou-se o escopo de testes para definir com preciso o que ser coberto pelo teste e tambm o que no ser coberto, bem como as ferramentas utilizadas para a realizao dos cenrios de teste.

Os defeitos da soluo encontrados pelos testes foram registrados em planilha de testes e medio de qualidade dos testes realizada atravs dos indicadores: densidade de falha e eficcia de testes, no decorrer do trabalho.

Outro artefato utilizado para a execuo de testes o documento de projeto de testes (vide Apndice II) que contm as orientaes de validao e ambiente devem ser atendidas na execuo dos requisitos de testes do projeto. Um requisito de teste contm informaes gerais que determinam como testes anteriormente especificados pelo plano de testes devem ser conduzidos.

A execuo dos testes realizou-se aplicando-se os testes descritos no plano e projeto de testes sobre produto CRM na verso 2.7 Release 24 que na sua infra-estrutura utiliza o produto Microsoft Soap Toolkit e o servidor de aplicaes Jboss 4.0.4 com o modulo Axis 1.1 para as transaes 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 verso 3.0.1 Open Source, da empresa Eviware, os critrios de escolha para se chegar opo se deram pela leitura dos descritivos das ferramentas, onde estavam informadas a cobertura e os processos que poderiam ser verificados, foram levados em considerao a adequao da ferramenta a linguagem de programao, pois algumas das escolhidas se aplicavam apenas a determinadas linguagens e deste modo foram descartadas; a portabilidade, ou seja, possibilidade de execuo em diversos sistemas operacionais; e principalmente pelo fator preo, j que a maioria das ferramentas pesquisadas proprietria 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 seo apresenta a descrio de alguns experimentos realizados com o objetivo de avaliar as funcionalidades da implementao da camada SOA de um software de CRM, sendo que o servio utilizado tem a caracterstica de devolver mensagens SOAP com a resposta de desafio, verificando se o usurio tem a permisso para acessar determinado registro de um cliente.

A Figura 6 demonstra o ambiente de execuo dos testes.

Figura 6 Ambiente de execuo dos testes Fonte: Dos Autores (2009).

O teste foi realizado, de maneira a importar os arquivos descritores dos servios a serem testados. Para a amostra, utilizou-se o servio Team_OpportunityTeam cujo descritor e a documentao do servio foram utilizados para a realizao dos testes mencionados.

A partir da importao do arquivo e os mtodos do servio exposto como demonstra a Figura 6, pde-se criar requisies com o intuito de obter as respostas dos mtodos, a ferramenta por si cria requisies de exemplo, porm de difcil entendimento, foi necessrio recorrer documentao e ao monitor HTTP da ferramenta para que fosse possvel entender como as requisies e respostas eram trocadas no uso do aplicativo CRM.

Aps a compreenso mnima do uso dos mtodos, puderam-se criar requisies HTTP que obtivessem os retornos. Durante os ensaios, aplicaram-se aos mtodos parmetros incorretos e ou vazios, como demonstra o Quadro 1.

Quadro 1 Requisio SOAP Com paramentos incorretos.

? ? ? ?

Cujos parmetros 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 requisio pela ferramenta de testes:

Quadro 2 Resposta de Requisio SOAP Incorreta.

soapenv:Server.userException java.lang.NumberFormatException: For input string: "?"

Aplicou-se tambm, parmetros que apresentavam a resposta da requisio como correta, como a requisio conforme o demonstrado no Quadro 3, realizada para o mtodo verifyAccountAcces que realiza a verificao ao perguntar ao servidor se determinado usurio

cujo cdigo 1 possui acesso a determinado cliente cujo seu cdigo 19410 alm da localizao do usurio para identificar seu idioma.

Quadro 3 Requisio correta ao mtodo verifyAccountAcces.

resourceId

1

resourceType

1

locale

"pt"

1 19410

Como resposta apresentada no Quadro 4, a requisio do servio obteve a expresso true o que identifica que o usurio tem acesso a conta solicitada e pode verificar suas oportunidades.

Quadro 4 Resposta a requisio ao mtodo verifyAccountAcces, permitindo o acesso.

true

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

Figura 7 Ambiente de execuo dos testes II Fonte: Dos Autores (2009).

3.2 Consideraes sobre o captulo

A ferramenta de testes que utilizou-se na aplicao dos testes SoapUI, como j abordamos, uma ferramenta open source escrita em Java cuja principal funo consumir e testar web service. Neste contexto, o SoapUI facilita todo o processo de criao e depurao dos testes por meio de uma interface grfica visual e intuitiva. Dentre as suas principais caractersticas, podemos destacar as seguintes:

a) instalao simples e fcil;

b) ampla documentao (no site);

c) importao e gerao automtica das requisies descritas no WSDL;

d) capacidade de gerenciar um nmero ilimitado de requisies para cada operao;

e) gerenciamento de mltiplo endpoints reference (uma entidade, recurso ou processador para onde as mensagens dos Web services so encaminhadas) para cada web service;

f) validao das requisies e respostas contra as suas definies no WSDL;

g) possibilita testes funcionais, de carga e stress;

h) execuo de diversos procedimentos de testes em paralelo;

i) editores com realce de sintaxe e formatao automtica;

Identificamos como ponto fraco da ferramenta, a manuteno dos cenrios de testes devido a atualizao da ferramenta durante a fase de experimentao (iniciamos com a verso 1.9 e conclumos com a 3.0.1) , que no mais eram executados em razo da troca dos padres de protocolo imposta pela evoluo do mesmo pelo W3C, a ferramenta deveria prever este tipo de situao e validar as tags dos arquivos informando a restrio, fato que no ocorreu, provocando erros de anlise do resultado esperado.

A ferramenta atendeu-nos no processo de teste unitrio e funcional de web services, que tinnhamos como objetivo nesta pesquisa.

Ainda, para a execuo de outros tipos de teste, caso se deseje aplica-los, faz-se necessria a anlise de outras ferramentas para a montagem de um framework para os demais tipos de testes que possam ser aplicados.

4 CONCLUSES E RECOMENDAES Os testes com a ferramenta indicada, apresentaram as mesmas dificuldades do processo

de testes anteriormente aplicado ao CRM, e de como testar melhor uma aplicao, ou seja, tempo para aprendizagem, capacitao, e complexidade, porm serviram para um melhor entendimento do conceito de SOA.

A principal dificuldade enfrentada foi que a documentao dos servios expostos no existia. Este fato deve-se a forma de implementao do aplicativo CRM, que foi construdo de modo a que o seu cdigo fonte fosse fechado, ou seja, aplicao proprietria, com a exposio de web service, porm sem a documentao tcnica de sua implementao de tal modo que na tentativa de obter o entendimento, utilizou-se da extrao de documentos da ferramenta SoapUI, como indicado no tpico Resultados e Discusses, diferentemente de outros servios em que foi possvel contato durante a execuo do trabalho como Google SOAP Search API cujo uma ampla documentao de implementao e uso esta disponvel (GOOGLE, 2009) e Flickr, sendo esta, disponvel em portugus (FLICKR, 2009).

Chegou-se a concluso, portanto, de que a ferramenta SoapUI no seria a mais indicada no momento para a execuo dos testes unitrios que foram propostos.

Ainda durante a pesquisa, verificou-se a descontinuidade do aplicativo CRM, devido mudana de modelo de produo de software adotado pelo contratante, para a construo de um novo aplicativo em nova arquitetura.

Portanto concluiu-se que os testes sugeridos, bem como a ferramenta e o modelo no seriam mais aplicveis.

Durante a execuo deste trabalho, e em paralelo a ele, houveram discusses e pesquisas por parte de outros integrantes da equipe de auditoria e testes da empresa onde este trabalho estava sendo aplicado, e nestas tambm se buscavam outras ferramentas alternativas, para os testes no s da aplicao a que se prope este trabalho, mas para as outras aplicaes 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 aplicao de testes a todos os aplicativos produzidos em nossa empresa, e que durante o 2 Seminrio 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 prope-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 Consideraes 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 possvel verificar que testes em componentes SOA que no tiveram sua

documentao devidamente gerada durante os processos de anlise e desenvolvimento, geram enormes dificuldades para a rea de testes, consumindo o mais importante e escasso de todos os recursos: tempo.

A importncia de que a ferramenta de testes e mtodos de testes que sero aplicados ao produto final sejam definidos j no incio do processo de desenvolvimento foi confirmada. Isto sendo realizado, ganha-se tempo e maior assertividade em todas as etapas de construo de um software.

REFERNCIAS

AREVOLO, W. Business Process Management Scenario: The Future of BPM Suites. So 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 definio de uma arquitetura SOA utilizando BPM. - Monografia (MBA em Tecnologia da Informao) - Escola Politcnica da Universidade de So Paulo - So 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/FSE99), 1999.

GIL, Antonio Carlos. Mtodos e tcnicas de pesquisa social. So Paulo: Atlas, 1999.

GIL, Antonio Carlos. Como elaborar projetos de pesquisa. So 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 Cientfica. 5a. ed. So Paulo: Atlas, 2003.

LARMAN, Craig. Utilizando UML e padres: uma introduo anlise e ao projeto orientados a objetos e ao desenvolvimento iterativo / Craig Larman; traduo Rosana Vaccare Braga ... [et al.] 3. ed. Porto Alegre : Bookman, 2007

LINNENKUGEL, U.; MLLERBURG, 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 seo Poster no Proceedings em CD-ROM do ED-MEDIA & ED-TELECOM. Calgary, CA, 1997.

PERES, R.; NOGUEIRA, A. R. - Estudo Comparativo de Ferramentas para Automao de Testes de Software - Monografia de Ps-graduao em Engenharia de Software UNIFIL, 2004.

PRESSMAN, ROGER. S. Engenharia de Software. So Paulo: Makron Books, 1995.

PRESSMAN, ROGER S. - Engenharia de Software, - Software Engineering A Practitioners Approach 6th edition. - Traduo Rosangela Delloso Penteado, reviso tcnica Ferno Stella R. Germano, Jos Carlos Maldonato, Paulo Csar Masiero. 6.ed. So Paulo : McGraw-Hill, 2006.

ROCHA, A. R. C.; MALDONADO, J. C.; WEBER, K. C. (Ed.). Qualidade de software: teoria e prtica. So Paulo: Prentice-Hall, 2001. 303 p.

SILVA, A. M. R.; VIDEIRA C. A. E. UML, Metodologias e Ferramentas CASE - Linguagem de Modelao UML, Metodologias e Ferramentas CASE na Concepo e Desenvolvimento de Software - Edies Centro Atlntico - 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, Disponvel em: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&arnumber=741968&isnumber=16010 Acessado em: Setembro (2009)

FLICKR. Servios do Flickr Documentao API, Disponivel em: http://www.flickr.com/services/api/, Acessado em: Julho (2009).

MANES, Anne Thomas. SOA is dead; Log life Services - Burton Group Disponvel 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, Disponvel 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 Politcnica da Universidade de So Paulo Brazil - http://www.pcs.usp.br/%7Epcs5002/oasis/soa-rm-csbr.pdf, acessado em Setembro (2009).

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

APNDICES

APNDICE I PLANO DE TESTES

Plano de Testes

Cliente: Interno

Fornecedor: Interno

Projeto: CRM Aplicao de Testes a camada SOA

Histrico de Alteraes

Data Verso Descrio Autor

07/2009 1.0 Criao de Documento Israel/ Rodrigo

Contedo

1 Introduo .............................................................................................................................59 2 Estratgia de Testes ..............................................................................................................60

2.1 < ESCOPO EX.: IPP XXX >......................................................................................60 3 Gesto de Testes ...................................................................................................................67

3.1 REGISTRO DE RESULTADOS ..................................................................................67 3.2 MODELOS DE AUDITORIA ......................................................................................67 3.3 REGISTROS DE DEFEITOS ..................... ERRO! INDICADOR NO DEFINIDO.

4 Software Ferramentas de Testes.......................................................................................68 4.1 FERRAMENTAS..........................................................................................................68

5 Cronograma...........................................................................................................................68 6 Referncias............................................................................................................................68

Introduo

Este documento define o Plano de Testes do projeto CRM Aplicao de Testes a camada SOA, com o objetivo de registrar a estratgia de testes a ser adotada. Isto possibilitar uma bem-sucedida coordenao e conduo de testes no projeto.

Estratgia de Testes

Fluxo de Auditoria O fluxo bsico de auditoria a ser seguido nos desenvolvimentos esta ilustrado abaixo, e importante destacar que este fluxo o padro de desenvolvimento, porm, de acordo com os riscos particulares de cada projeto, tanto novos processos podem ser inseridos no fluxo como alguns processos podem ser retirados conforme excees que estiver descritas neste Plano de Testes.

Processo de Auditoria de Fontes/Arquitetura Nvel 1

Esta auditoria dever apenas iniciar quando os testes de programao foram realizados pelo programador e, a atividade foi liberada para a auditoria anexada dos seguintes documentos e registros especficos deste servio:

- Nmeros dos pacotes da atividade gerados pelo Sistema Compilador em todos os ambientes disponveis.

- Check-list de construo preenchido. - Listagem resultante da execuo de uma ferramenta de testes de caixa branca.

Caso os documentos necessrios descritos acima para o servio de construo no estiverem anexados, a auditoria dever ser reprovada pelo auditor de fontes. O tipo de erro a ser

registrado para este erro com origem construo dever ser DoctInad = Documentao Inadequada.

Caso os documentos necessrios estiverem anexados ao servio, o auditor de fonte dever primeiramente avaliar nestes anexos: - Se o check-list de construo foi preenchido de acordo com a necessidade do

desenvolvimento em questo. - Se a listagem de ferramenta de caixa branca no apresenta erros pertinentes ao

desenvolvimento realizado. - Verificar se o pacote da atividade foi gerado pelo Sistema Compilador, confirmando que

no houve erros de compilao nos programas alterados.

Caso estes anexos no 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 cdigos alterados e desenvolvidos verificando se as melhores tcnicas de

programao foram seguidas; - Verificar se o cdigo est de acordo com o solicitado no desenvolvimento, respeitando

principalmente as releases solicitadas para o desenvolvimento; - Verificar se os padres dos templates foram seguidos conforme manuais de padres de

programao (cdigos e interfaces); - Analisar a arquitetura dos principais objetos desenvolvidos ou alterados para analisar:

Se a estrutura de cdigo de fcil manuteno; Se o mesmo cdigo (regra) no foi duplicado em mais de um local do sistema; Se a alterao do cdigo respeitou a integrao do mesmo com outros dados externos

(objetos, mdulos, aplicativos); Se a alterao realizada respeita as limitaes dos bancos de dados Oracle e SQL; Se mtodos desnecessrios foram inclusos; Se problemas especficos foram resolvidos em solues ge