Implementação de um ambiente para gestão de processos de testes de software baseado em ferramentas de software livre.

Transcrição

1 Implementação de um ambiente para gestão de processos de testes de software baseado em ferramentas de software livre. Gustavo Rossarolla Forgiarini, Angelina Torres de Oliveira, Cristiano Rech Meneguzzi, Rafaela Lisboa Carvalho, Duncan Dubugras Alcoba Ruiz, Karin Becker, Bernardo Copstein, Flávio Moreira de Oliveira Pontifícia Universidade Católica do Rio Grande do Sul (PUCRS) Faculdade de Informática Caixa Postal Porto Alegre RS Brazil {gforgiarini, atorres, crm, rcarvalho, duncan, kbecker, copstein, Resumo: O presente artigo documenta os estudos realizados na implementação de um ambiente para gestão de processos de teste de software do projeto CWf-Flex. Este projeto está na fase final de desenvolvimento de um ambiente computacional para dar suporte adequado à descrição e execução de processos de teste de software, sob o ponto de vista de controle e acompanhamento. O projeto tem, como pré-requisitos, a execução por navegadores Web e o emprego de ferramentas de software livre no seu processo de desenvolvimento. O ambiente está baseado na tecnologia de automação de workflow como referência no seu desenvolvimento e implantação, bem como na eventual adoção de frameworks para a implementação dos diferentes componentes do ambiente. A principal contribuição é a adoção de uma arquitetura de software que alia o uso somente de ferramentas de código aberto com um alto grau de flexibilidade para a incorporação modular de novas funcionalidades. Abstract: The present article documents the studies accomplished in the implementation of an environment for the management of software-testing processes in the context of the project CWf-Flex. This project is in the final phase of development of a computing environment to provide proper support to the description and execution of software-testing processes, by the point of view of management. The project has, as requirements, the running under Web browsers and the use of opensource tools in the development process. The proposed environment is based on the workflow-automation technology as the reference in design and implementation, as well as in the use of convenient frameworks, for the implementation of different components of the environment. The main contribution is the adoption of a software architecture that allies the exclusive use of open-source tools with a high degree of flexibility for the modular incorporation of new functionalities. 1. Introdução Ultimamente, devido a grande demanda no uso de ferramentas de tecnologia da informação, cresceu muito a preocupação com a qualidade dessas ferramentas, tornando as atividades de teste de software cada vez mais importantes. Um processo de teste de software consiste na execução de uma série de atividades de teste sobre um produto, com a finalidade de encontrar falhas existentes no mesmo. O objetivo é detectar, tanto quanto possível, o maior número de falhas de um software, antes que o mesmo entre em uso, ou que seja comercializado. Para efetivar um processo de testes de um dado software, é definido o respectivo plano de testes, detalhado em casos de teste. Em um plano de testes de software há, tipicamente, um número bastante significativo de casos de testes a serem executados. Este plano descreve: (1) todas as características que o ambiente computacional deve oferecer para que o plano possa ser executado, (2) as habilidades que os profissionais envolvidos devem possuir, (3) os

2 casos de testes a serem realizados sobre o software, e (4) a seqüência de realização dos casos de testes, bem como os procedimentos a adotar em caso de detecção de falhas. Dependendo da gravidade da falha detectada, a execução de um processo de testes pode ser interrompido. Laboratórios de teste de software têm por objetivo aglutinar recursos humanos e computacionais adequados para realizar tais testes em softwares. Para um melhor controle da execução dos mesmos, a gestão dos laboratórios costuma subdividir o plano em blocos de casos de testes, para que estes sejam distribuídos entre os testadores. Além disso, pode ocorrer que distintos blocos de casos de testes, sem dependência entre si, sejam alocados para diferentes testadores, permitindo uma eventual execução em paralelo dos mesmos. Uma outra característica em processos de teste de software é que os recursos computacionais empregados ficam dedicados exclusivamente ao seu bloco de caso de teste até o termino da sua execução. Isso é necessário para (tentar) garantir que somente defeitos do software sendo testado sejam detectados, e não de algum outro software que outrora tenha sido instalado ou testado, e que não faça parte da especificação desse ambiente. Logo, pode-se constatar que tanto o projeto de um plano de testes como sua execução, constitui-se de diversas atividades complexas e inter-relacionadas, que demandam recursos humanos e computacionais. Algumas destas atividades podem ser executadas em paralelo, outras não. Em qualquer caso, é necessário controlar e acompanhar a execução das atividades, bem como o direcionamento e compartilhamento dos resultados, além de efetuar a alocação de recursos adequadamente. O projeto CWf-Flex propõe-se, justamente, a desenvolver uma ferramenta computacional para dar o suporte adequado à descrição e execução de processos de teste de software, pelo ponto de vista de controle e acompanhamento. O objetivo do projeto é o desenvolvimento de um ambiente para gestão de processos de teste de software, baseado na tecnologia de workflow e no uso de ferramentas de software livre, com alocação de recursos. A principal motivação do projeto é a carência existente nos gerenciadores atuais de workflow em não levarem em conta que os recursos a serem alocados podem ter disponibilidade limitada (computadores, etc.) e podem requerer uso exclusivo. Mesmo que a alocação de recursos humanos esteja contemplada na maioria dos sistemas de workflow, é praticamente inexistente o suporte ao agendamento prévio de acordo com compromissos já assumidos por cada ator [Bastos, 2001, Ruiz, 2002], ou seja, não é levada em conta sua disponibilidade. A conformidade dos produtos para automação de processos de workflow com padrões hoje existentes [WfMC, 1998, 2002], não é muito expressiva até porque esses padrões têm evoluído bastante. Por fim, são produtos de alto custo de aquisição e de manutenção. Como resultado do projeto, espera-se que o ambiente desenvolvido permita a alocação eficiente de recursos para a execução das atividades de teste de software de acordo com as capacidades requeridas, além de fornecer agilidade, confiabilidade e uma visão abrangente de todas as etapas de execução de um projeto de teste de software, através da tecnologia de Workflow. Este artigo documenta os estudos feitos para a definição da arquitetura de software adotada na implementação do projeto, considerando um ambiente típico de execução na Web, e com o uso de ferramentas de software livre. Para tanto, é discutida a arquitetura proposta, bem como, a descrição dos frameworks adotados na implementação dos diferentes módulos. O trabalho está organizado da seguinte maneira. O capítulo 2 apresenta os objetivos, atividades previstas e resultados esperados no contexto do projeto CWf-Flex. O capítulo 3 descreve a arquitetura de implementação do ambiente e a seqüência típica de operação do ambiente de execução, enquanto o capítulo 4 descreve a seqüência de desenvolvimento do ambiente de execução e apresentadas as dificuldades e soluções encontradas durante a implementação. Por fim, o capítulo 5 tece considerações sobre o estágio em que a pesquisa se encontra, bem como quais serão os próximos passos da mesma.

3 2. Projeto CWf-Flex O principal objetivo do projeto CWf-Flex é especificar e implementar um ambiente flexível e aberto para a descrição e acompanhamento da execução dos processos de teste de software, bem como a correspondente alocação de recursos humanos e computacionais para o desenvolvimento das atividades envolvidas em cada instância de processo a ser executada. O projeto define três ambientes distintos para a ferramenta computacional: (1) ambiente de descrição, (2) modelo formal de execução, e (3) ambiente de execução. O ambiente de descrição é o meio que possibilita a entrada de modelos de processos de teste, de forma diagramática. O modelo de referência adotado é o definido em [Bastos, 2001] e utiliza a extensão de diagramas de atividades UML proposto por [Bastos, 2002]. Esse ambiente foi desenvolvido sobre o ArgoUML [ArgoUML, 2004], de acordo com o requisito do projeto para uso somente de ferramentas de código aberto. Além disso, esse ambiente foi concebido para ser independente do ambiente de execução, na medida em que a interação entre esses ambientes é feita pelo modelo formal de execução. As especificações resultantes são exportadas para o ambiente de execução através do modelo formal de execução. A documentação completa desse ambiente está em [Velasco, 2004], e não é tratado neste artigo. O modelo formal de execução é o padrão de comunicação entre o ambiente de descrição e o ambiente de execução. O mesmo permite descrever modelos de workflow, em XML, e as especificações necessárias para realizar o controle de alocação de recursos nos processos de testes. Esse modelo é conforme a especificação XPDL da WfMC (modelo de descrição de processos de workflow em XML, via XML-Schemas) [WfMC, 2002], e utiliza os próprios recursos de extensão da XPDL para incorporar funcionalidades adicionais. Devido a falta de espaço, essa extensão também não será tratada neste artigo. O ambiente de execução é o ambiente que possibilita o controle e o acompanhamento das execuções de processos de teste através da tecnologia de workflow, considerando recursos computacionais como recursos de produção (uso exclusivo, tempo necessário para configuração e de utilização). Para tanto, esse ambiente recebe modelos descritos no modelo formal de execução. Além disso, todas as informações referentes ao laboratório de teste de software em si são apropriadas diretamente nesse ambiente (engenheiros de teste, testadores, equipamentos computacionais disponíveis, habilidades de cada recurso, etc.). O resultado esperado, ao final do projeto, é um ambiente computacional completo que possibilite a descrição, acompanhamento e a execução de atividades de teste de software, através da tecnologia de workflow, agregando recursos de forma eficiente, e possibilitando, aos usuários e profissionais da área de teste de software, facilidades no desempenho de suas funções. Para os gestores de laboratórios de teste de software, espera-se um ambiente leve e flexível, que forneça agilidade, confiabilidade e uma visão geral de todas as etapas de um processo de teste de software. 3. Arquitetura de Implementação do Ambiente de Execução O crescente uso de ferramentas de tecnologia da informação, cuja execução se dá por navegadores Web, tem se tornado comum nas grandes e pequenas empresas. Isso decorre da integração que essas aplicações têm com os sistemas legados das empresas, isto é, não é necessário eliminar ou substituir sistemas já existentes, mas sim integrá-los. Porém, o desenvolvimento deste tipo de ferramenta requer mais do que simplesmente um conjunto de páginas JSP; é necessário ter organização, padronização e facilidade de implantação, para que se obtenha o desenvolvimento de sistemas modulares e de fácil manutenção.

4 Por tratar-se justamente de uma ferramenta Web, não se caracteriza como uma boa técnica manter misturados códigos de acesso a dados, regras de negócio e códigos de apresentação, pois essa mistura pode gerar muitos problemas no seu desenvolvimento e dificultar em muito a sua manutenção. Sendo assim, para o ambiente de desenvolvimento do projeto CWf-Flex foi adotada uma arquitetura dividida em três camadas: apresentação, regras de negócio e persistência de dados, como mostrado na Figura 1. A camada de apresentação e de regras de negócio estão contidas no servidor Web, bem como as páginas JSP. A tecnologia J2EE foi utilizada no desenvolvimento da ferramenta como um todo, possibilitando com isso, a portabilidade do sistema entre diferentes sistemas operacionais e, em especial, Linux. Servidor Web - Apache Jakarta Tomcat Browser Paginas Html e Jsp WebWork2 Camada de Apresentação Hibernate Camada de Regras de Negócio PostgreSQL Camada de Persistência de dados Figura 1 - Arquitetura de implementação do ambiente. A camada de apresentação do projeto CWF-flex segue o paradigma MVC(Model View Controller). Isso faz com que o projeto tenha padronização no código e também, rapidez no desenvolvimento sem que haja perda em qualidade na ferramenta. Dentre as características esperadas de um framework que implemeta o paradigma MVC, destacam-se: Separação entre dados (Model), apresentação (View) e controle (Controller). Gerência das relações entre o modelo e a apresentação. Responsabilidades mais claramente definidas. Redução no esforço de implementação da camada de apresentação. O framework MVC contemplado para a camada de apresentação do projeto é o WebWork2 [WebWork2, 2004]. Trata-se de uma opção bastante difundida e de fácil adaptação, que agrega ao projeto uma estrutura lógica de tratamento de dados, além de ser responsável pela realização da comunicação entre o modelo e a visualização, trazendo, com isso, maior reusabilidade, responsabilidades mais definidas além de reduzir os esforços de implementação na camada de apresentação. Já para a camada de regras de negócio, a alternativa adotada é o Hibernate [Hibernate, 2004]. O Hibernate é um framework de persistência de dados que provê o mapeamento Objeto-Relacional, constitui-se de uma biblioteca de classes Java (hibernate.jar), e se estabelece como uma camada adicional entre a aplicação e o banco de dados. Seu objetivo é eliminar a necessidade de redigir instruções SQL nas classes de negócio, atuando como uma interface entre os dois paradigmas: orientado a objetos (OO) e relacional. Características: Suporta todas as propriedades da OO como herança, polimorfismo e composição. Open Source o que garante o livre acesso ao código fonte. Suporte a múltiplos SGDBs - Oracle, DB2, MySQL, PostgreSQL entre outros. O Funcionamento do Hibernate consiste na criação dos objetos a serem persistidos com base em um documento de mapeamento (escrito em XML). Esse documento serve para descrever os campos que devem ser persistidos, as associações, bem como as subclasses dos objetos persistentes. Esses documentos de mapeamento são compilados na inicialização da aplicação e provêm, ao framework, as informações necessárias sobre cada classe.

5 Por fim, para a camada de persistência de dados, optou-se pelo o SGDB PostgreSQL, por ser um SGBD relacional e orientado a objetos, que tem seu código fonte aberto, ser multiplataforma, além de ter confiabilidade e estabilidade reconhecidas. 3.1 Seqüência típica de operação do Ambiente de Execução Primeiramente, no módulo de cadastro básico do ambiente, é feita a inserção dos dados referentes a um laboratório de teste de software como, por exemplo, papéis dos participantes, participantes (humanos e máquinas), capacidades dos participantes humanos, configurações de máquinas e clientes. Já a inclusão de um projeto implica na carga de um arquivo XPDL. Este arquivo contém todos os dados do plano e a correspondente validação do mesmo frente aos cadastros do laboratório. Para cada plano carregado, é realizada a correspondente alocação de recursos, que caracteriza uma das principais funcionalidades do ambiente e que acontece quando um engenheiro de teste seleciona o plano para o qual deseja efetuar a correspondente alocação de recursos. O engenheiro de teste seleciona cada uma das atividades e informa qual participante será responsável pela execução da mesma, de acordo com suas capacidades e disponibilidades em sua agenda. A alocação de recursos é um processo repetitivo, executado até que todas as atividades tenham seus recursos alocados. Para cada atividade a ter recursos alocados, o ambiente apresenta as propriedades da mesma, para permitir que o engenheiro selecione um participante adequado e disponível. Ao escolher um participante, são apresentadas suas propriedades e, em especial, sua agenda de compromissos já assumidos. O engenheiro confirma que deseja alocar, ou não, este participante para a execução da atividade. Caso positivo, o sistema apropria os dados no banco de dados, tornando o participante indisponível, no período informado, para a execução de outras atividades. A disponibilidade para execução de atividades por parte dos testadores (humanos) é verificada considerando duas condições: os horários de trabalho do participante, e os compromissos já assumidos para execução de atividades de teste. O objetivo é respeitar os horários definidos para cada participante como à disposição para a execução de teste. 4. Implementação do Ambiente de Execução As etapas de pesquisa e definição da arquitetura de implementação, do ambiente de execução, definiram um ambiente de desenvolvimento Web totalmente open-source. Para o desenvolvimento das classes e conexões dos frameworks contemplados no projeto optou-se pela utilização da plataforma de desenvolvimento Eclipse [Eclipse, 2004]. Trata-se de um ambiente bastante flexível e que permite a integração de diversos tipos de plugins, facilitando assim a criação, integração e utilização das ferramentas, com significativo ganho de tempo. 4.1 Descrição da seqüência de desenvolvimento do ambiente de execução A especificação da ferramenta foi feita em UML [Oliveira 2004]. Foram descritos casos de uso para cada funcionalidade do sistema e um diagrama de classes global. Além disso, foi definido o modelo lógico de dados para implementação no SGBD escolhido. A produção do script de criação do banco de dados foi feita via uma ferramenta adequada. Por fim, esse script foi executado no PostgreSQL. Realizado isso, através da plataforma Eclipse com o plugin Hibernate, foi feito o mapeamento desta base de dados para um modelo Objeto- Relacional, para posterior interação com o framework WebWork Recursos utilizados do Hibernate Para o projeto, foi utilizado o plugin Hibernate Synchronizer, que gera código para a camada de persistência do Hibernate. Códigos que são gerados com o plugin: (a) Objetos de

6 negócio, (b) Objetos de chaves compostas, (c) Objetos de enumeração, (d) Objetos de componentes, (e) Subclasses e (f) Objetos de DAO. Dois componentes do Hibernate se sobressaem, pois, são eles que garantem o seu funcionamento: hibernate.cfg e XML Mapping. Hibernate.cfg: é o arquivo que contém as configurações da conexão com o banco de dados. Nele é definido: o tipo do banco, url, driver, username, pasword e dialect, que estão em destaque na figura 2, respectivamente. Figura 2: Exemplo de arquivo de configuração da conexão com o banco de dados. XML Mapping: é o arquivo onde são registradas as informações a respeito do mapeamento das classes e suas respectivas tabelas relacionais. Cada classe é mapeada para uma tabela. Além disso, são registradas informações sobre os relacionamentos, cardinalidades e identificadores. Na figura 3 podemos observar o mapeamento do objeto persistente Capability, descrito em formato XML. No arquivo está em destaque, primeiramente, o pacote onde o arquivo foi criado, e seu respectivo nome. Em seguida, destacam-se os dois campos deste objeto (IdCapability e DescriptionCapability) e suas propriedades. Figura 3: Mapeamento do objeto persistido descrito em formato XML. Outro recurso oferecido pelo Hibernate, é que os comandos de pesquisa são feitos através de uma linguagem simples, chamada HQL Hibernate Query Language. Esses são

7 traduzidos para comandos SQL do SGBD adotado. Portanto, com o Hibernate, tem-se de um lado a conexão com o SGBD e, pelo outro, a implementação do mapeamento de classes persistentes do ambiente de execução. 4.3 Recursos utilizados do WebWork2 O WebWork2 funciona em conjunto com um arquivo escrito em XML chamado XWork. Este permite implementar diversos padrões de desenvolvimento, provendo variadas funcionalidades para o processamento de comandos. A combinação do framework com o arquivo XWork permite a separação entre a camada de visualização e a de regras de negócio. A figura 4 mostra em destaque a ação AddCapability no arquivo Xwork, com os seguintes recursos implementados no projeto: Ações: o gerenciamento de actions e comandos é a característica mais importante do WebWork2, pois é assim que são acionados os métodos criados nas classes Java. Interceptadores: com os interceptors, uma ação pode ser interceptada antes e/ou depois de sua execução, podendo ter seu fluxo desviado ou redirecionado. Além disso, múltiplos interceptors podem ser utilizados para uma mesma ação. Redirecionamento: como resultado de uma ação sempre é originado um redirecionamento. Ao ser chamada uma ação, esta retorna para onde deseja redirecionar a aplicação na camada de visualização. Figura 4: Exemplo de arquivo Xwork do WebWork2. A figura 5 mostra a validação da ação AddCapability. O WebWork2 automatiza a validação dessa ação com a criação de um arquivo em XML que possui o mesmo nome da classe Java que ele visa validar, mais o nome da ação. Esta nomenclatura é especialmente importante, pois, é justamente esta coincidência que realiza a ligação da classe com sua ação. Este tipo de validação além de ser bastante eficiente, independe da programação Java. Figura 5: validação da ação AddCapability. 5. Considerações finais Este trabalho apresentou os estudos realizados para implementação do ambiente de execução do projeto CWf-Flex, descreveu a arquitetura adotada e destacou os temas em que foi necessária uma especial atenção por parte da equipe: automação de workflow,

8 desenvolvimento de aplicações WEB, bancos de dados, teste de software, além de um grande conhecimento adquirido sobre ferramentas open-source. Além disso, foi mencionada a adoção do padrão XPDL para descrição de workflows com extensões adequadas, como formalismo para troca de especificações de planos de teste de software. Com isso, obteve-se um alto grau de independência entre as ferramentas de descrição e de execução. O ambiente de execução foi implementado usando a tecnologia J2EE, em uma arquitetura dividida em três camadas, que exigiu, em especial, uma busca sobre ferramentas /frameworks de software livre disponíveis. É importante ressaltar que as ferramentas e frameworks utilizados elevaram o nível de produtividade no desenvolvimento do ambiente, e proporcionaram uma implementação em módulos e de fácil manutenção. Sendo assim, o ambiente foi desenvolvido com a preocupação de deixar pontos que possibilitem uma fácil agregação de novos módulos, em futuras versões. 5.1 Próximas etapas A implantação do ambiente em um laboratório de teste de software é a fase atual do projeto. Ao colocar a ferramenta em execução, espera-se verificar o atendimento aos seus requisitos, o nível de conforto em seu uso, e a qualidade das informações geradas sobre a produtividade da equipe, fornecidas aos gestores. Com isso espera-se aferir a qualidade da implantação feita e realimentar o processo de desenvolvimento da mesma. Também está sendo iniciado um estudo para a proposição de um método de modelagem voltado às características oferecidas, bem como um estudo de outras áreas de sua aplicação. Bibliografia ArgoUML. ArgoUML Documentation. último acesso: julho/2004. BASTOS, R.M.; RUIZ, D.D.A. Towards an Approach to Model Business Processes using Workflow Modeling Techniques in Production Systems. In: HICSS- 34, 2001, Maui, Hawaii, EUA. Proceedings of the 34 th HICSS. Los Alamitos, CA, EUA: IEEE Computer Society, BASTOS, R.M.; RUIZ, D.D.A. Extending UML Activity Diagram for Workflow Modeling in Production Systems. In: HICSS-35, 2002, Big Island, Hawaii, USA. Proceedings of the 35 th HICSS. Los Alamitos, CA, USA: IEEE Computer Society, Eclipse - Website of the Eclipse Foundation. último acesso: junho/2004. Hibernate - A Hitchhiker's Guide to Hibernate. último acesso: junho/2004. OLIVEIRA, A.T. et al. (2004) CWf-Flex Especificação do ambiente de execução. Porto Alegre, PPGCC- PUCRS, 2004 (Relatório CWf-Flex 01/2004). Object Management Group. Workflow Management Facility Specification, V1.2. Needham MA: OMG, RUIZ, D.D.A.; BASTOS, R.M.. C-Wf: a Model to Represent Workflow Business Processes in Production Systems. Journal of Applied System Studies, Cambridged, England, v. 3, n. 1, VELASCO, L.H.; et al. (2004) Workflow Designer: Uma ferramenta para modelar processos de Workflow. Porto Alegre, FACIN-PUCRS, 2004 (Trabalho de conclusão 01/2004). Workflow Management Coalition. Interface 1: Process Definition Interchange Process Model. Hampshire UK: WfMC, Nov (Ofificial Realease 7.04). Workflow Management Coalition. Workflow Process Definition Interface XML Process Definition Language. Hampshire UK: WfMC, October (WFMC-TC-1025, Final Draft 1.0) WebWork2 - Documentation Wiki. último acesso: junho/2004.