Ferramenta de integração contínua

Integração contínua consiste em integrar o trabalho diversas vezes ao dia, assegurando que a base de código permaneça consistente ao final de cada integração.

A este mesmo procedimento de construção podem ser adicionadas rotinas como:

• Execução de testes automatizados
• Geração de versões internacionalizadas de seu software
• Disponibilizar a versão atual em desenvolvimento para o cliente
• Criação de relatórios de código como:
• Cobertura de testes
• Inspeção de padrões de codificação
• Estatísticas de acoplamento

Todo o processo segue a arquitetura descrita na imagem abaixo:

O cenário acima pode ser descrito como: (Fonte: Continuous Integration)

1. O desenvolvedor envia o código para o controle de versão (SVN, CVS, etc). Enquanto isso a máquina de integração (servidor de Integração Contínua) está verificando o repositório buscando por modificações
2. Logo após um commit ser efetuado, o servidor ao verificar que alguma mudança ocorreu no repositório inicia o processo de build baixando os arquivos do Servidor de Controle de Versão. Assim, o script de build é executado, testes são realizados, relatórios gerados, e todo o projeto é integrado.
3. O Servidor de Integração envia por e-mail ou outros dispositivos o feedback sobre build para usuários específicos do projeto
4. O servidor volta ao estado de Poll buscando por mudanças no repositório

Com relação a ferramentas a serem utilizadas e a comparação entre elas temos 3 que se destacaram. Entre elas temos as ferramentas cruise-control, continuum e hudson.

Minha escolha pessoal é a utilização do Hudson. Entre as funcionalidades que mais me agradam estão:

• Permite a configuração de novos jobs através de interface web.
• Permite a realização de builds distribuídos.
• É um projeto mais ativo com mais desenvolvedores.
• Possui plugin para o eclipse.
• Possui instalador do windows.
• Utilização por parte de grandes projetos.
• Integração com o Maven, SVN, CVS e com outras ferramentas.
• Facilidade maior para configuração do que as outras ferramentas.

Controle de versão

A cada dia sistemas de versão concorrente vem sendo utilizados para os mais diversos fins. No passado era realidade apenas em grandes ambientes de desenvolvimento paralelo, onde literalmente dezenas de desenvolvedores demandavam acesso simultâneo aos mesmos arquivos, e ter um sistema de versão concorrente era imperativo para garantir adequadamente um ambiente de trabalho concorrente, e principalmente, garantir segurança desses dados, de forma que se um desenvolvedor interferisse negativamente no trabalho de outro, as mudanças em questão pudessem ser facilmente revertidas ao estado anterior.

Então o controle de versões é visto como uma extensão natural do processo de desenvolvimento, permitindo que se possa paralelizar o desenvolvimento de forma coerente e padronizada.

Hoje existem dezenas de opções de sistemas de versionamento de projetos, esses sistemas são conhecidos com SCM ou apenas VCS (Version Control System). Alguns sistemas VCS comerciais, mais conhecidos são:

• Clear Case
• Microsoft Team Foundation

E alguns sistemas de controle de versão livre, mais conhecidos são:

• CVS
• Subversion
• GIT

Outros sistemas menos conhecidos:

• Visual Source Safe
• PVCS
• SVK
• HG
• BZR
• Perforce

Temos como preferência utilizar sistemas open source e pelo conhecimento do CVS e do Subversion iremos basear os estudos e comparações nos dois sistemas.

O sistema aberto mais conhecido é o CVS, exatamente por existir a mais tempo, e ser a primeira implementação livre com um número de recursos que o tornasse viável a ser utilizado em todo tipo de ambiente, de qualquer porte, de projetos pequenos a gigantescos. O CVS é a opção de escolha mais comum, entre livres e comerciais. Ao menos por enquanto.

Subversion é uma ferramenta open-source de controle de versão (veja o tutorial sobre controle de versão de software para mais informações). Segue a licença de software livre nos moldes da licença Apache/BSD.

O projeto do Subversion iniciou em 2000 com a idéia de se construir um CVS melhor, isto é, mantendo o mesmo modelo de trabalho, mas consertando as falhas e limitações que o CVS apresenta. Desde então, vem atraindo uma comunidade cada vez maior de colaboradores e usuários.

O Subversion tem a maior parte das funcionalidades do CVS. De modo geral, a interface do Subversion segue à do CVS. Isto facilita a transição dos usuários do CVS para o Subversion.

Controle de Diretórios, Renomeações e Meta-Dados

Esta era uma das maiores reclamações sobre o CVS. Subversion não só controla a versão do conteúdo dos arquivos, mas também de diretórios, cópias, renomeações e meta-dados.

Operações Atômicas de commit

Um conjunto de modificações a serem realizadas num commit é aceito como um todo ou nenhuma alteração é feita. Não há a possibilidade que apenas uma parte das alterações seja aceita quando enviadas ao repositório tal como acontecia no CVS. Além disso, os números de revisão estão atrelados a cada operação de commit e não aos arquivos.

Opções de Acesso à Rede

Subversion foi projetado para uma camada abstrata de acesso ao repositório, o que permite a implementação de novos mecanismos de rede. Um dos mecanismos existentes usa o protocolo WebDAV/DeltaV baseado em HTTP através do Apache 2. A outra opção é o servidor dedicado svnserve como opção ao Apache, e que pode ser combinado ao ssh.

Arquivos Binários e de Texto Tratados Consistentemente

Outro grande problema bastante conhecido é que o CVS que não funciona tão bem com arquivos binários. Por outro lado, o Subversion usa um algoritmo de diferenciação binário que funciona de modo idêntico tanto para arquivos texto (legíveis por humanos) quanto para arquivos binários (ilegíveis para humanos).

Ramificações e Rotulações em Tempo Constante

O tempo das operações de ramificação (branching) e rotulação (tagging) é constante, e não depende do tamanho do projeto no repositório. Esse resultado é obtido através da forma de implementação do Subversion para essas operações, que é feita como uma operação de cópia que resulta em links, ocupando pouco espaço e um intervalo de tempo constante.

Uso mais Eficiente da Rede

O protocolo de rede usa a largura de banda eficientemente enviando as diferenças entre cliente/servidor e servidor/cliente sempre que possível, ao contrário do CVS que envia as diferenças do servidor ao cliente, mas não do cliente ao servidor.

A seguir, é apresentado um pequeno quadro comparativo entre o CVS e o Subversion (SVN). Ressaltamos que este quadro não representa uma comparação completa.

Funcionalidade	CVS	SVN
Commit Atômico	X	V
Renomeações e cópias de arquivos e diretórios	X	V
Rastreamento de Fusões (Merge)	P	PF
Permissões de Repositório	P	V
Documentação Disponível	V	V
Portabilidade	V	V
Open Source	V	V
Interfaces Gráficas	V	V
Suporta Grande Repositório	V	V

Legenda:

(V) Possui tal funcionalidade

(X) Não possui tal funcionalidade

(P) Atende parcialmente o requisito

(F) Existe previsão para implementação da funcionalidade no futuro

(A) Informações insuficientes para classificação

Automação de testes de desempenho

O teste de desempenho mede e avalia o tempo de resposta, o número de transações e outros requisitos sensíveis ao tempo. Este tipo de teste é importante para verificar a disponibilidade do sistema sobre situações em que existe um grande número de transações. Este é normalmente um requisito não funcional muito importante em aplicações comerciais.

O software mais utilizado chama-se JMeter e é uma das ferramentas desenvolvidas dentro do projeto Jakarta. Ele esta disponível em http://jakarta.apache.org/jmeter. O JMeter permite testar diferentes componentes de um ambiente servidor, como servidores HTTP, FTP e SGBD.

Um de seus atrativos é o fato de permitir a execução de plano de testes que podem ser configurados graficamente. Outro atrativo é conseguir realizar os testes de desempenho com clientes distribuídos. Isto é importante, pois utilizando várias máquinas clientes consegue-se simular carga de maneira mais próximo do ambiente de produção.

Uma vez que o JMeter é uma ferramenta Open Source e consegue realizar os testes de desempenho de maneira simples e robusta esta será a ferramenta a ser utilizada.

Automação de testes funcionais e de aceitação

Testes funcionais são aqueles que encaram o sistema a ser testado como uma função que mapeia um conjunto de valores de entrada em um conjunto de valores de saída sem se preocupar com a forma como esse mapeamento foi implementado.

Um teste de aceitação (ou Story Test, ou Customer Test) descreve um cenário (de sucesso ou não) com uma expectativa do cliente em relação à história ou funcionalidade. Como o nome sugere, ele ajuda a equipe a entender quando uma história ou funcionalidade está completa ou aceita.

Diversas ferramentas e frameworks têm surgido para auxiliar sua vida. Entre as mais conhecidas temos o Selenium e o Watir podem facilitar sua vida no teste de aplicações web.

Percebemos que teremos um problema ao utilizar o Selenium quando o projeto funciona apenas no navegador internet explorer. Isto ocorre, pois o Selenion IDE que é uma ferramenta que facilita a gravação dos scripts é um addin para o mozilla firefox e quando o sistema não funciona no navegador mozilla não é possível o utilizar.

Situação ideal: Ter uma aplicação que funciona em ambos os browsers, gravar os scripts no Selenium e realizar os teste utilizando os navegadores.

Situação alternativa: Para aplicações que funcionam somente no navegador internet explorer, o que nos deixa como melhor opção a utilização do Watir que possui como facilidade o aplicativo IE Developer Toolbar.

O Watir é opensource e com seus comandos e funções particulares permite então que possamos controlar os objetos HTML e JavaScript presentes na aplicação Web, simulando os cliques em links, botões e os demais campos. Watir tem sido usado para testes de sistemas, testes funcionais e teste de aceitação do usuário. Como seu próprio nome diz (Web Application Testing in Ruby),

Para o uso do Watir torna-se necessário a instalação do interpretador Ruby e do pacote que contém o Watir. O Watir não utiliza da técnica conhecida como Record/Playback, onde o arquiteto de testes grava o script através do movimento do mouse e teclado.

Os scripts são escritos mesmo “na unha”, portanto o recomendado é que o responsável pelo uso do Watir tenha algum conhecimento de lógica de programação e dos atributos das tags HTML. Esse conhecimento em desenvolvimento se torna importante, visto que, estamos falando de programação de scripts e para que possamos ter um produto final de qualidade, podem ser aplicados todos os conceitos e boas práticas de programação.

Existe um facilitador que é a instalação do aplicativo IE Developer Toolbar que se integra na barra de ferramentas do Internet Explorer facilitando na identificação dos atributos utilizados na automação.

Gestão de testes

A gestão de testes é a parte principal de um processo de testes. A gestão é importante para o planejamento e controle das atividades de um projeto de teste. A gestão de testes pode ser implementada por meio de ferramentas automatizadas (test management system).

Estas ferramentas devem oferecer um repositório central e padronizado aonde os lideres de testes poderão criar suítes com os casos de teste, atribuir os casos de testes aos testadores, acompanhar o status da execução dos testes e emitir os relatórios com métricas e estatísticas.

Entre as ferramentas que auxiliam na gestão de testes temos:

• TestLink
• RTH
• Testopia
• TestMaster
• Testitool
• Test Case Web
• QaManager
  

Entre estas as ferramentas mais comentadas foram o TestLink e o RTH. A escolha do TestLink é hoje a escolha mais apropriada, pois seu desenvolvimento é o mais ativo e por ser uma ferramenta mais utilizada no mercado.

O TestLink é uma aplicação Open Source cujo principal objetivo é gerenciar as atividades de teste de um projeto tais como test cases e test suítes. Ele é útil, pois é possível organizar os requisitos, associar os test cases aos requisitos garantindo então a rastreabilidade entre eles. Outra vantagem é a integração com a ferramenta de gestão de defeitos Mantis que será também utilizada no sistema.

Outra vantagem é o sistema ser desenvolvido em php e utilizar a base de dados mysql, que também é a plataforma utilizada por outras ferramentas do sistema o que demandará menos recursos.

Gestão de defeitos

A gestão de defeitos é uma das atividades mais importantes de um processo de teste de software. Através da gestão de defeitos podemos acompanhar a qualidade do software em teste com base nos defeitos cadastrados pelos testadores ao longo de um ciclo de testes.

Podemos então, para realizar o controle e a gestão dos defeitos no sistema, utilizar sistemas automatizados que nos auxiliem. Estas ferramentas devem possuir um local aonde os testadores cadastram os bugs de forma organizada, devem possuir também um local para acompanhar o ciclo de vida dos defeitos e emitir relatórios de gestão.

Entre as ferramentas de gestão de defeitos temos três que são bastante utilizadas no mercado. Entre elas temos o Bugzilla, o Jira e o Mantis.

Segue abaixo uma tabela de comparação entre estas ferramentas:

System								Customizable workflow	Unicode support	LDAP user authen.
Bugzilla								No[9]	Yes	Yes
JIRA								Yes	Yes	Yes
Mantis Bug Tracker								Yes	Yes	Yes

Retirado de http://en.wikipedia.org/wiki/Comparison_of_issue

O Jira será excluído da comparação, pois o projeto não é um projeto livre e sim pago para projetos Comerciais. Ficamos então com a comparação entre o Mantis e o Bugzilla.

Comparando as duas ferramentas vemos então que o Mantis é mais simples de instalar e de utilizar, e possui segundo a matriz acima um workflow configurável o que o torna mais extensível. Minha escolha cai sobre o Mantis então por sua simplicidade e também por ser bastante robusto. A simplicidade ajuda a usuários não técnicos executar o cadastro de defeitos.

Entre as diversas funcionalidades oferecidas pelo Mantis temos:

• Pode ser executado em qualquer plataforma.
• Suporta vários bancos de dados.
• Suporta múltiplos mecanismos de autenticação.
• Ciclo de vida personalizável.
• Gerador interno de relatório de defeitos.
• Controle de acesso e permissão por usuário.
• Mecanismo para a criação de campos personalizáveis.
• Notificação por meio de e-mails automáticos.
• Integração com ferramentas de controle de versão.
• Interface webservices para integração com outras ferramentas.