1

DESENVOLVIMENTO DE APLICAÇÃO VOLTADA PARA GERAÇÃO AUTOMÁTICA DE CASOS DE TESTE1

Bruna de Quadros Willand <willand.bruna@gmail.com> Edemar Costa <edemar.costa@gmail.com> – Orientador

Universidade Luterana do Brasil (ULBRA) – Curso de Análise e Desenvolvimento de Sistemas – Campus Canoas Av. Farroupilha, 8.001 – Bairro São José – CEP 92425 - 900 – Canoas – RS

24 de junho de 2011

RESUMO O objetivo desta pesquisa é apresentar uma ferramenta que facilite a criação de casos de testes gerados na

etapa de desenvolvimento e homologação de um software. O aplicativo irá rastrear a página, verificando seus objetos (links, campos numéricos e tamanho de caracteres) e, a partir daí, gerar os casos de teste mais comuns para cada item, sendo estes casos baseados em casos de teste pré-definidos e armazenados em banco de dados para consultas.

Palavras-chave: Casos de teste; Teste de software; Homologação.

ABSTRACT Title: “Development Application directed to Automatic Generation of Test Cases”

The objective of this research is to provide a tool that facilitates the creation of test cases generated in the stage of development and approval of software. The application will crawl the page, making sure your objects (links, numeric fields, character size), and then generate test cases for each common item, such cases will be based on predefined templates and stored in the database for queries..

Key-words: Test Cases; Software Testing; Approval.

1 INTRODUÇÃO

Durante o processo de desenvolvimento de um sistema há muitas etapas que exigem alto nível de complexidade e, com isso, a probabilidade de ocorrência de problemas aumenta, tanto na análise quanto na fase de codificação - que consiste na execução do projeto. O teste de software ganhou força no final dos anos 90, pois as empresas sentiram a necessidade de sistemas seguros e ágeis que poupassem tempo durante o processo de desenvolvimento, a fim de reduzir, consideravelmente, retrabalhos que geravam acúmulo de horas e, consequentemente, aumento de custos. Com isso o processo de validação começou a evoluir e começou-se a gerar artefatos e a se criar ferramentas para dar suporte a estes documentos, tudo isso para completar o ciclo de desenvolvimento.

Hoje em dia existem ferramentas que controlam todas as etapas do teste, desde o cadastro de requisitos

até o reporte de defeitos e também a execução de casos de teste. Este último tem grande importância, pois irá auxiliar na homologação da aplicação, a partir da geração de possibilidades válidas e inválidas que o sistema deve aceitar ou não. Numa situação ideal, no desenvolvimento de casos de teste, espera-se encontrar o subconjunto dos casos de teste possíveis com a maior probabilidade de encontrar a maioria dos erros (MYERS, 2004).

Motivada a reduzir custos e acúmulo de horas em projetos de sistemas Web, a ferramenta facilitará a

geração de casos de teste mais comuns e que, muitas vezes, são esquecidas na execução. Ao longo do processo de desenvolvimento será feita uma pesquisa e a seleção dos cenários mais críticos. , Com o resultado desta pesquisa será criada uma base de casos de teste para a aplicação (em quê?). Estes casos serão pesquisados e selecionados junto com um analista de homologação para melhor compreensão e seleção destes. Os dados serão armazenados em banco e serão pesquisados a cada iteração que o usuário solicitar. Logo após será feito um comparativo com outras ferramentas disponíveis atualmente no mercado, levando em consideração a produtividade e os recursos oferecidos por cada uma. 1 Artigo final da disciplina de Projeto: Redes de Computadores e Análise e Desenvolvimento de Sistemas , submetido ao Curso de Analise e

Desenvolvimento de Sistemas da Universidade Luterana do Brasil, Câmpus Canoas.

2

2 REFERENCIAL TEÓRICO Neste capítulo serão apresentados ao leitor os conceitos dos assuntos relacionados com o estudo

deste artigo, tais como: teste de software, plano e casos teste, teste funcional e analista de teste.

2.1 Teste de Software Segundo Glen Myers (1979), “Teste de software é o processo de executar um programa ou sistema

com a intenção de encontrar defeitos”.

Já Bill Hertzel (1988), define que teste é “qualquer atividade que a partir da avaliação de um atributo ou capacidade de um programa ou sistema seja possível determinar se ele alcança os resultados desejados”. De forma geral, teste de software é um processo de validação que visa avaliar o comportamento de uma aplicação baseado no que foi especificado. Considerando isso, é inválida a afirmação de que um sistema, depois de testado, estará livre de defeitos. Isso porque os sistemas estão ficando cada vez mais complexos e com inúmeras funcionalidades, sendo quase impossível prever todas as possibilidades e alternativas de entrada de dados, considerando também a lógica do desenvolvedor.

Na figura 1 é possível analisar os custos dos defeitos em várias etapas do processo de desenvolvimento. De acordo com o desenho, nas fases de levantamento de requisitos, o custo das correções não é alto. Já na fase de análise de requisitos o custo é ainda menor.

% do Custo de

Desenvolvimento % dos erros introduzidos

% dos erros encontrados

Custo relativo de correção

Análise de Requisitos 5 55 18 1

Projeto 25 30 10 1 – 1.5

Codificação e teste de unidade 50

Teste 10 10 50 1 – 5

Validação e Documentação

10

Manutenção 5 22 10 - 100

Figura 1 – Cenário atual de desenvolvimento (Fonte: DevMedia)

2.2 Plano de Teste O Plano de teste é um dos artefatos gerados durante o desenvolvimento de um sistema e é através

deste documento que serão definidas as metas e os objetivos dos testes, identificando tipos e técnicas a serem aplicadas, bem como os recursos necessários e os produtos que serão liberados. Embora o plano de teste seja elaborado no início do projeto, este documento é atualizado no decorrer de todo o ciclo de desenvolvimento do sistema, ou seja, esta fase de planejamento é contínua.

Em algumas empresas, os planos de teste são considerados informais. Em contrapartida, em outras organizações eles são altamente formalizados e, por vezes precisam de aprovação externa. Logo, o formato e o conteúdo destes arquivos deve variar para atender às necessidades de uma organização, especificamente. Esta etapa caracteriza-se pela definição de uma proposta de testes baseada nas expectativas do cliente em relação aos prazos, aos custos e à qualidade esperada, possibilitando dimensionar a equipe e estabelecer um esforço de acordo com as necessidades apontadas pelo mesmo.

3

2.3 Casos de Teste Segundo Glen Myers (1979), o caso de teste deve especificar a saída e os resultados esperados do

processamento. Numa situação ideal, no desenvolvimento de casos de teste, espera-se encontrar o subconjunto dos casos de teste possíveis, com a maior possibilidade de encontrar erros. Basicamente, caso de teste é o documento que possui as inúmeras possibilidades de entradas e ações a serem executada, sendo tudo isso com um resultado esperado. Este é o documento que irá auxiliar o testador e o analista a validarem se o sistema atingiu as suas funcionalidades especificadas durante a fase de levantamento de requisitos. O analista de teste é responsável por este artefato e é ele que fará qualquer alteração ao longo do processo de desenvolvimento e de teste.

Uma das tarefas mais complicadas do analista é buscar um conjunto de casos de teste que satisfaça as necessidades do cliente e que este contenha as inúmeras possibilidades de erros nas interações feitas pelo usuário ou que foram inseridas no código ao longo do desenvolvimento.

A seguir são listadas as fases da construção de casos de teste, com a finalidade de evitar a duplicação de esforços:

Nível 1. Neste nível, os casos de teste são escritos a partir da especificação básica disponível e documentação do usuário.

Nível 2. Este é o estágio prático, no qual os casos de teste escrito dependem do fluxo e funcionalidade do sistema real da aplicação.

Nível 3. Este é o estágio em que você vai agrupar alguns casos de teste e escrever um procedimento de teste. Procedimento de teste nada mais é do que um grupo pequeno de casos de teste, sendo no máximo 10.

2.4 Teste Funcional No início de um projeto são levantados todos os requisitos funcionais e não funcionais de um sistema.

É nesta etapa que o cliente informa o que deseja no sistema. Os requisitos funcionais são diretamente ligados às funcionalidades do software e descrevem as funções que o sistema deverá executar. Já os requisitos não-funcionais descrevem as restrições do sistema. Os testes funcionais, também chamados de teste de caixa preta, devem abranger estes dois tipos de requisitos, que são parte do sistema e devem ser mapeados ao realizar a homologação, no decorrer do processo. Neste tipo de teste são inseridos dados de entrada com saídas já previstas, sendo avaliadas ao final de todo o fluxo. Para isso, é preciso realizar a análise dos requisitos do sistema e a criação de dados de entrada e dados de saída. É possível ver o fluxo completo na figura 2.

Figura 2 – Fluxo de execução do teste funcional

4

Segundo Pressman (2002), “O teste funcional procura, entre outras coisas, mostrar que os requisitos funcionais do software são satisfeitos que a entrada é adequadamente aceita, que a saída esperada é produzida e que a integridade das informações externas é mantida; por isso, não existe preocupação com a estrutura lógica interna do sistema”.

Os pontos designados por Pressman são descritos nos casos de teste, onde serão levantadas todas as possíveis entradas e saídas exatas. Nos casos devem ser descritos todos os tipos de validações, mensagens de erros previstas e aplicação das regras de negócio levantadas.

2.5 Analista de teste O analista de teste é responsável por identificar e definir os testes necessários através de casos,

monitorando a abrangência dos testes e avaliando a qualidade geral obtida ao testar os itens do sistema. Este papel também envolve a especificação dos dados de teste necessários para teste funcionais e a avaliação do resultado dos testes conduzidos em cada ciclo de teste. Em algumas vezes, ele também é responsável pela execução de testes mais específicos, como por exemplo, testes de desempenho, de estresse e de homologação, onde exige um maior conhecimento e uma maior responsabilidade. A figura 3 mostra as tarefas deste profissional.

Figura 3 – Tarefas do Analista de teste

O cotidiano de um analista de teste pode variar dependendo do local de trabalho, mas as tarefas apresentadas acima são exemplos clássicos das funções deste profissional. É de responsabilidade dele a maior parte das tarefas no processo de planejamento dos testes.

3 FERRAMENTAS PARA CONTROLE DE CASOS DE TESTE EXISTENTES A seguir serão apresentadas breves descrições de duas ferramentas de criação de casos de teste: HP

Quality Center, produzida pela HP e o TestLink, que é uma ferramenta Open Source. Ambas possuem características muito similares na criação e no controle de casos de teste.

As ferramentas utilizadas no processo teste são completas e robustas. No que diz respeito à utilização em grande escala e possuem todos os itens para organização e planejamento do processo de teste, contendo módulos específicos para planejamento ligados aos casos de teste e suas execuções. Possuem todas as atividades do processo de análise de testes e também de execução, podendo controlar todas as tarefas pelas ferramentas.

3.1 HP Quality Center O software Quality Center é um aplicativo que permite o uso de todos os aspectos essenciais de

gerenciamento de testes. Esta ferramenta permite o gerenciamento de requisitos funcionais e não-funcionais, o planejamento e o agendamento de testes, a análise de resultados e o gerenciamento de defeitos. As informações podem ser analisadas de diferentes formas por esta ferramenta, desde relatórios até gráficos. Permite exportar para arquivos .xls e .doc, integrando-se, assim, com outras ferramentas que utilizam estes documentos.Pode também ser integrada com ferramentas de automação, tornando o processo de teste centralizado em apenas uma ferramenta, ligando um script de automação a um caso de teste específico. Todas as etapas da execução dos testes podem ser inseridas e mapeadas no Quality Center, considerando também que o sistema possui grande preocupação com segurança e controle de permissões.

5

A gestão de defeitos é bem estruturada, sendo possível adicionar defeitos ao longo da execução dos testes, especificando o passo onde ocorreu o erro. Possui, também, controle de versões de execução dos testes onde são definidos quais os casos devem ser executados para determinada versão, podendo, assim, separar as tarefas entre a equipe.

A Figura 4 ilustra a interface de gerenciamento de um caso de teste no Quality Center.

Figura 4 – Tela do software HP Quality Center

Através deste software é possível seguir um processo de teste bem definido, onde se tem a

especificação dos requisitos, seguida pela criação do planos/casos de teste, a execução dos casos e, por fim, um controle da própria ferramenta na gestão de defeitos, permitindo ter todo o controle do fluxo dos requisitos atendidos ou não pelo sistema.

3.2 TestLink Testlink é uma ferramenta para gerenciamento de caso de teste e serve também para organizá-los em

planos de teste. Os planos de teste permitem aos membros da equipe executar os casos de teste e manter a lista de defeitos atualizada, gerando resultados dinamicamente, verificando os requisitos do software e priorizando as tarefas. A ferramenta é desenvolvida em PHP e banco de dados MySql. Ela funciona integrada com ferramentas de controle de defeitos, o que pode auxiliar o processo de homologação. A Figura 5 ilustra a interface de gerenciamento de um caso de teste no TestLink.

Figura 5 – Tela do software Testlink

6

O Testlink tem um foco voltado para a análise e execução dos testes e leva em consideração o processo de homologação e suas dependências. Por ser uma ferramenta Open Source, tem inúmeros sites que auxiliam na inserção de novos recursos via programação.

4 PROBLEMA – PROCESSO DE TESTE ATUAL

A empresa objeto do estudo de caso deste artigo - com atuação na área de construção de experiências digitais de marca (sites), teve sua equipe de testes desfeita. Como consequência dessa desestruturação, o processo de criação de planos e casos de teste foi perdido, assim como o processo de execução destes artefatos. A nova equipe de teste passou a necessitar de uma maneira mais ágil de criar esses artefatos para ganhar tempo no processo de homologação.

Os principais problemas levantados pela empresa são: (a) a falta de descrição dos processos da equipe de teste anterior, sendo que o conhecimento está no funcionário e não em documentações; (b) o processo da empresa deve ser passado aos novos funcionários, sendo que isso também consome tempo da equipe de desenvolvimento; (c) a priorização no início da execução dos testes; (d) a necessidade de alguns clientes terem acesso aos casos de teste de sua aplicação, como os indícios de teste.

Juntamente com a equipe de desenvolvimento foi possível realizar a análise dos processos da área de teste e obter o funcionando da área com uma visão macro. A partir daí, foi possível detectar junto com a nova equipe onde o processo de teste pode vir a ter um atraso significativo até chegar à execução e resultado no processo de homologação.

Os pontos críticos da organização são a documentação dos cenários e, em paralelo, os testes nas aplicações que são desenvolvidas durante esse período, sendo este o principal desafio. Como o processo de teste levaria muito tempo para ser automatizado, chegou-se a conclusão que a tarefa de criação de casos de teste deveria ser mais rápida e a solução encontrada deveria ser eficaz para todos os projetos.

4.1 Modelagem e descrição do novo processo de teste Segue a descrição do novo processo definido pelo coordenador da área de desenvolvimento e a

analista de teste. Como é possível verificar na figura 6, há duas fases de documentação: uma de planejamento, ou seja, o que deve e o que não deve ser testado e outra, que é a criação da documentação para executar os testes (casos). A leitura da documentação é utilizada em todo o processo. Através dessas especificações poderá ser feito todo o planejamento e promessas de prazos, bem como a base para a criação dos casos de teste. Todo o fluxo pode ser retornado, caso os requisitos do sistema mudem ou ocorra algum erro em uma das etapas. Esse processo acompanha o ciclo de vida do sistema. Como já foi levantado, o processo possui muitas fases de documentação, o que pode vir a atrasar as outras atividades. P ara iniciar uma tarefa a outra deve estar concluída, isto é, as atividades se tornam dependentes uma das outras. Outro problema levantado durante a análise do fluxo do processo é a quantidade de profissionais que são designados para determinada tarefa. O analista de teste, por exemplo, é sobrecarregado com as tarefas de análise, leitura da documentação, criação de casos de teste e o resultado dos testes ao gerente do projeto.

7

Figura 6 – Modelagem do novo processo de teste

5 SOLUÇÃO PROPOSTA Como solução para os problemas relatados no item anterior, sugeriu-se o desenvolvimento de uma

ferramenta que auxiliasse a criação dos casos de teste, gerando modelos destes documentos de acordo com a página acessada e os campos contidos nesta.

O sistema desenvolvido utiliza o framework 4.0 e linguagem de programação C#. As informações são salvas no banco de dados Access 2010, muito usado em aplicações que necessitam de soluções rápidas. Ambas as tecnologias, mantidas pela Microsoft Corporation, foram escolhidas visando agilidade no processo de desenvolvimento e a possibilidades de futuras melhorias, sendo levada em consideração a disponibilidade de materiais para apoio e a pesquisa.

Para o desenvolvimento dos diagramas foi utilizado o sistema BizAgi e para a modelagem do banco de dados a ferramenta utilizada foi DBDesigner 4.0.

Para iniciar o desenvolvimento deste aplicativo será feito o levantamento dos requisitos funcionais, o levantamento de dados e a modelagem ER da aplicação e, somente após isso será detalhado o processo de execução do sistema com dados reais.

5.1 Descrição dos requisitos funcionais Nesta seção são listadas as principais telas que compõem o sistema e os requisitos funcionais de

acordo com as necessidades levantadas durante esta fase. Cadastro de projetos: O cadastro de projetos deve conter campos para o nome do projeto e descrição. Para iniciar sistema é preciso inserir um novo projeto ou abrir um projeto existente. Ao abrir o projeto são carregados todos os seus subitens em uma árvore de dados e estes subitens são as telas e casos de teste. Deverá ser carregado apenas um sistema por vez e para que outro projeto seja carregado deverá ser aberta uma tela que lista todos os projetos. O item de projeto na árvore deverá ser o nodo principal, onde todos os outros itens estarão associados a ele. Somente serão aceitos itens de telas ao nodo de projeto.

Cadastros de telas: Uma tela deve possuir um projeto associado a ela e não será possível adicionar telas sem um projeto estar carregado. É a partir deste item que será possível gerar os casos automaticamente. Deve possuir campos para nome, endereço e descrição. O campo endereço é a URL da tela, e é esse campo que o sistema carregará para gerar os casos. A tela só deverá conter casos de teste, não sendo possível adicionar itens de telas uma dentro da outra. É a partir desse cadastro que o sistema deverá solicitar a geração dos casos de teste ou simplesmente cadastrará tela solicitada.

Cadastro de casos de teste: Os casos devem possuir os seguintes campos para edição: nome, desenvolvido por, comentários e descrição.O campo de identificação deve ser gerado de forma automática, mas deve estar visível na tela de edição.A aplicação deve disponibilizar a opção de excluir um determinado caso.

8

Os casos de teste possuem descrição da sua execução, sendo necessários campos para passos e resultados e o campo de identificação devem ser visíveis, sendo possível inserir, alterar e excluir um passo. Ao adicionar um caso não é obrigatória a inserção dos passos e resultados. Um caso pode possuir anexos, sendo possível a inserção de arquivos com as seguintes extensões: .jpg, .png, .doc, .xls, .gif, .txt. Esses arquivos devem ter o nome de suas imagens salvas no banco de dados, como um campo de texto. A tela para inserção de anexos deve possuir um campo de nome e possuir a opção de exclusão, caso seja necessário. Da mesma forma que não é obrigatória a descrição de execução, os anexos não são.

Cadastro dos modelos: Deve possuir campos para nome e tipo de objetos, caso o objeto seja do tipo Input devem ser listados subtipos em outro campo. Os seguintes valores devem conter no campo de tipo de objetos: Imagem, Input e Link. Os valores que são listados no campo dos subtipos de Input são: Checkbox, Hidden, Password, Radio, Submit e Text. É através desse cadastro que o sistema deverá buscar os valores para relacionar aos campos de determinada página. Deverá ser possível visualizar todos os casos padrões adicionados e fazer a exclusão caso seja necessário.

Geração de casos de teste automaticamente: A tela para geração dos casos de teste só irá aparecer após a inserção de uma tela e quando o usuário solicitar, caso contrário, só será possível gerar casos de forma manual. Nesta tela de geração de casos de teste será disponibilizado um browser para acesso das páginas, sendo uma aplicação bem simplificada apenas para visualização de determinada página. Deverá conter a listagem dos objetos da página acessada, onde os objetos são os links, campos de texto e imagens. Tendo todos esses itens, será possível gerar os casos de acordo com a necessidade do usuário. Caso necessite gerar casos para apenas dois campos da página será feita a busca apenas para esses itens selecionados. Os outros casos, ligados a regras de negócio, poderão ser inseridos de forma manual.

5.2 Levantamento dos dados de casos padrões A elaboração dos casos de teste ao longo do tempo foi se tornando cada vez mais necessária, pois

muitos clientes passaram a exigir documentos que comprovassem a execução dos testes, bem como a cobertura dos casos frente à aplicação. Durante a análise foi identificado que era preciso um detalhamento mais completo dos casos que englobavam os sistemas já testados, verificando o que era comum para determinados objetos da tela e que sempre precisavam de uma atenção maior. Devido a esses pontos surgiu a necessidade de se realizar um levantamento dos casos que o sistema iria utilizar. Para isso foram analisadas as seguintes questões:

Que tipos de objetos o sistema irá reconhecer? Analisando as aplicações Web é possível ver que os conteúdos das páginas HTML não possuem inúmeros tipos objetos, ou então, esses tipos não variam de aplicação para aplicação. Isso torna a análise mais simplificada. Por exemplo, uma página contém campos INPUT, esse tipo de objeto por sua vez terá apenas alguns subtipos, que seriam Checkbox, Hidden, Password, Radio, Submit e Text, não é possível variar mais do que isso este campo. Essa análise é feita junto com o analista de teste e um profissional que tenha domínio no desenvolvimento de páginas HTML, podendo, assim, visualizar os itens de uma maneira mais objetiva.

De que forma o analista identificará quando um caso é relevante para outras aplicações? Ao longo do processo de análise e execução dos testes é possível identificar os casos que aparecem mais de uma vez em uma determinada página. Ao realizar essas tarefas em outro projeto, o analista já terá o conhecimento necessário e a possibilidade de verificar se esses casos não afetarão outras aplicações de forma negativa, gerando retrabalho ao excluir os casos que não são válidos.

Nem todos os casos serão aplicados a um determinado objeto, como o sistema tratará isso? Esse trabalho dependerá também do profissional que estiver criando e executando os casos de teste. Para essa tarefa de criação de casos padrões, é preciso que um analista de teste avalie quais casos realmente são necessários para tornar a aplicação uma ferramenta de auxílio e gere economia de tempo e esforço. A ferramenta não poderá auxiliar em todos os casos de teste, sendo que os casos de teste relacionados às regras de negócio ficam por responsabilidade do analista. Caso a aplicação insira modelos que não são válidos, basta exclusão destes.

9

5.3 Modelagem do banco de dados

Na figura 7 é possível analisar como a modelagem do banco foi construída, permitindo a visualização de como os casos de teste interagem com o restante das tabelas. Os modelos são inseridos em uma tabela separada, a qual armazena dados de referência que serão utilizados, posteriormente, pelos casos de teste.

A tabela de Telas armazena o código do projeto e é através desse valor que o sistema irá carregar todos os itens relacionados, sendo, ligada à tela esta a tabela de Objetos contendo o código da tela, isto só é aplicado quando o caso é gerado automaticamente, caso contrário não é adicionado objetos manualmente para uma tela. O mesmo acontece para os casos de teste, sendo que esses itens são adicionados em outra fase.

O usuário não terá acesso aos dados de objetos. Esse item existe apenas para a geração dos casos, não podendo ser alterado ou visualizado. Para identificar de qual item foi adicionado casos, irá ser inserido o nome do campo ao lado do caso.

Os casos de teste possuem itens relacionados, as tabelas de anexos e passos_resultados. A tabela de anexo contém apenas uma breve descrição do anexo e o nome que será armazenado. No campo de nome estará apenas o nome do arquivo solicitado, sendo que o arquivo físico estará em uma pasta criada para o projeto na raiz. O sistema permitirá a visualização e edição desse arquivo, não alterando o original.

Figura 7 – Modelagem de dados do sistema

A cada nova interação do usuário, nas ações de inserção, o sistema recarregará a árvore de projeto, buscando as suas telas relacionadas e os seus respectivos casos.

5.4 Processo de desenvolvimento de casos de teste com a aplicação Tendo a modelagem do banco definida e as especificações principais das telas, é possível gerar um

fluxo completo de criação de casos de teste com a ferramenta, de forma manual e automática. Na figura 8 é apresentado o fluxo de geração dos casos, não sendo citadas neste modelo as telas que compõem o sistema, mas, sim, o processo.

10

Figura 8 – Processo de criação de casos de teste com o sistema Foi verificado, através das especificações, que o usuário poderia abrir apenas um projeto por vez,

isso porque o grande número de casos poderia confundir o analista. O processo de inserção de tela poderia dar-se ao abrir um projeto ou ao criar um novo. Nesta próxima etapa o usuário tem uma decisão a tomar: gerar os casos de forma manual ou automática. Os processos anteriores a este são realizados para ambas as modalidades. Gerando de forma manual, o usuário irá executar a mesma ação diversas vezes até satisfazer as condições do usuário. Ao escolher a geração de forma automática, existem mais algumas etapas até chegar à conclusão da geração de casos de teste. Mas, isso é feito uma única vez, não havendo a necessidade de criar um caso por vez, facilitando o trabalho. Neste fluxo é importante notar que a geração dos casos de forma automática é feita em uma linha horizontal, o que não quer dizer que, após isso, não terá que ser inserido casos de forma manual, recomeçando o fluxo na edição dos casos de teste. No próximo item será descrita a página Web que servirá como objeto de teste, a partir da qual serão analisados os casos que servirão como modelos.

6 EXECUÇÃO DA APLICAÇÃO 6.1 Análise de teste para geração dos modelos de casos

Para iniciar os testes com a aplicação foi desenvolvida uma página Web com inúmeros objetos de interface, a fim de analisar quais casos são mais comuns a cada tipo de objeto.

A figura 9 apresentada a página HTML desenvolvida, que possuem três campos texto, cada um com suas validações de tamanho e número, um campo de senha, campos hidden que não devem aparecer, um campo de seleção de conteúdo, três botões, um checkbox, um radio, duas imagens, 2 links e uma caixa de texto (textarea).

11

Figura 9 – Página HTML desenvolvida para análise de casos de teste

Com a visualização da interface foi possível identificar os principais casos de teste para cada item, que são listados na Tabela 1. Para cada campo há testes específicos, sendo necessária a execução destes testes a cada alteração da página. Alguns casos são repetidos, mas para a execução dos testes é necessário alguns casos semelhantes, tendo diferenças na descrição dos seus passos.

Quadro 1 – Casos de teste dos campos da página Web

12

Em uma aplicação real, uma página Web teria também uma série de regras de negócio. A seguir, são listados alguns exemplos de regras de negócio que completariam um ciclo de teste de uma determinada tela.

Deve entrar um valor numérico somente;

O valor inserido deve ser validado para verificar se está pré-cadastrado;

Deve ser validado, se já não foi realizado, um cadastro com aquele valor. Caso positivo, o código do campo não é mais válido;

Se o código for válido deve carregar as informações de cadastro;

Não deve constar nenhum registro com o e-mail cadastrado;

Apenas os usuários que têm permissão podem acessar a aba de projeto;

Para inserir um anexo é necessário ter um caso cadastrado;

Apenas os administradores podem inserir requisitos na aba de projetos;

Os usuários gerenciadores só podem editar os comentários dos casos de teste.

Ao finalizar essa análise, é possível perceber que, raramente, um profissional irá se lembrar de cadastrar todos os casos e, tão pouco, executar todos esses testes. Isso sem mencionar a questão do tempo utilizado da análise para criar todos esses casos.

6.2 Gerenciamento de casos de teste Tendo os modelos dos casos para cada campo já é possível inserir no sistema estes dados como

modelos de caso de teste. A geração de casos de forma automática não irá funcionar caso não tenham sido inseridos os modelos. Ao inserir o caso modelo é possível perceber que toda a inserção é fundamentada nos tipos e subtipos de objetos. Isso porque é a única forma de identificar o que um objeto representa na página, e que dados contêm.

No exemplo da figura 10 é mostrada a inserção de um caso à base de dados selecionando um tipo e um subtipo. Posteriormente será explicado como são gerados os casos a partir dos tipos de objetos.

Figura 10 – Cadastro de casos padrões

6.3 Gerenciamento de projetos e telas Após o cadastro dos casos modelos é hora de iniciar um projeto. Para esses exemplos será utilizada

uma aplicação real, a qual não terá revelado o nome. É possível abrir um projeto existente ou inserir um novo e não é disponibilizada a funcionalidade para abrir vários projetos. Isso porque ao carregar o projeto é armazenada a identificação no frame principal e esse número é utilizado durante todo o ciclo de testes. O próximo passo é criar uma tela para esse projeto.

O processo de criação de telas é bem simples. Como é possível ver na Figura 11, há apenas três

13

campos texto. Um dos campos mais importante desta tela é o de Endereço, porque esta será a URL que a tela de Geração de casos irá acessar e buscar os objetos. Além disso, é através desta tela que a geração de casos irá ser disponibilizada. Para que isso aconteça, o usuário terá que salvar esse registro.

Figura 11 – Cadastro de Telas

6.4 Geração de casos de teste Após a confirmação na etapa anterior, o form de Geração de casos é disponibilizado, já com a

identificação da tela e a URL que o sistema irá acessar. A identificação que o form recebe só será utilizada ao adicionar os dados no banco de dados. Tendo a página carregada basta clicar no botão Objetos que o sistema insere na lista tudo o que a página contém.

14

Figura 12 – Geração dos objetos Essa inserção na lista é muito importante porque, a partir disso, é possível visualizar os tipos e

subtipos de objetos que a página possui. A busca pelos objetos é feita por categorias onde, por exemplo, são verificadas em toda a página HTML quais são os objetos de link, tanto que os objetos são listados ordenados por tipos.

Tendo os objetos desejados selecionados é só clicar no botão Gerar. Após isso o sistema capta os objetos selecionados e insere no banco de dados, e para cada objeto é feito uma busca para selecionar os casos que se aplicam. Dependendo do caso, apenas o tipo não é suficiente, então é feita uma nova busca selecionando os subtipos.

Na figura 13 são apresentados os casos já gerados pela ferramenta. Mesmo selecionando poucos objetos é possível observar que o sistema gera um número grande casos. Estes casos são identificados com o nome do campo ao final de cada um para melhor entendimento.

Figura 13 – Criação dos casos e atualização na árvore

A cada nova inserção de telas ou casos de teste o sistema recarrega a árvore novamente para buscar a sua identificação.

6.5 Edição de um caso de teste Para finalizar o fluxo do processo exemplo, será feita a alteração de um registro. A maior parte dos

casos de teste possui, principalmente, uma descrição sobre sua execução. E isso está implementado na aba Passos, como mostra a figura 14. É possível adicionar, excluir e alterar os dados desta tela.

15

Figura 14 – Alteração de um caso de teste

Outra alteração que muitas vezes é utilizada é a adição de anexo em um registro. Nesta aplicação é salvo apenas o nome da imagem no banco de dados, sendo que o arquivo propriamente dito é copiado para uma pasta do projeto e pode ser visualizado ao clicar sobre o anexo. O arquivo original não é alterado de pasta ou de conteúdo.

7 ANÁLISE COMPARATIVA Nesta seção será apresentado um estudo comparativo das ferramentas Quality Center, Testlink e a

ferramenta apresentada neste artigo. Primeiramente, será apresentado um quadro com as suas funcionalidades. Logo após, serão apresentados os resultados dos testes realizados com três aplicações teste para o desenvolvimento de casos. O estudo contou com três profissionais de teste para a utilização das ferramentas. Foram relatados os casos e, ao final, o tempo que levaram para conclusão da tarefa.

7.1 Quanto às funcionalidades dos sistemas Quality Center: esta aplicação possui todas as funcionalidades de gerenciamento de um sistema de

software, que inclui a gestão de defeitos, o controle dos requisitos do sistema, o controle de versões a serem testadas, o planejamento dos testes do projeto, o desenvolvimento dos casos das aplicacões, a execução dos testes e, também a funcionalidade de integração com o sistema de automação de testes QuickTest Professional. Outra funcionalidade muito importante é restrição de algumas funcionalidades por usuário. Estes recursos em empresas de grande porte são muito importantes, pois há um grande número de testes a serem realizados e um grande número de pessoas a serem gerenciadas. Por ser uma ferramenta com muitas funcionalidades, o Quality Center tem um custo elevado e apenas as grandes empresas, na maioria das vezes, possuem sua licença de uso.

Testlink: é uma ferramenta de gerência de teste. Ele não registra defeitos, não automatiza casos de teste e nem gerencia builds do software. Na visão dos desenvolvedores desta aplicação, o mais importante é a gerência dos planos e casos. O TestLink faz o trabalho de organizar a elaboração, o planejamento, o cadastro de casos de teste e a execução destes. Nesta ferramenta é possível referenciar projetos, builds e até defeitos, mas não de uma forma completa. Também possui a funcionalidade de restrição por usuários.

Projeto final: a ferramenta desenvolvida nesse estudo registra os casos de teste de acordo com os projetos e suas respectivas telas, sendo necessário que o sistema gere alguns casos automaticamente, de acordo com componentes. Essa geração é realizada apenas em páginas Web. O sistema é simples, pois foi desenvolvido com foco em equipes de teste pequenas. No Quadro 2 são apresentadas as funcionalidades de cada ferramenta especificamente.

16

Funcionalidade/Ferramenta Quality Center Testlink Projeto TCC Planejamento dos testes do projeto X X Controle de requisitos das páginas

X X X

Criação de casos de teste manual

X X X

Execução de casos de teste

X X

Controle de versões dos testes executados

X X

Controle por projetos

X X X

Integração com sistema de automação

X

Criar casos automaticamente

X

Gestão de defeitos

X

Restrição por usuários X X

Quadro 2 – Funcionalidades das ferramentas comparadas

7.2 Casos de estudo Abaixo são listados os casos de estudo utilizados para realizar essa pesquisa. Os casos criados com

as ferramentas Quality Center e Testlink foram gerados no início do processo de desenvolvimento do artigo. O tempo estimado para desenvolver os casos de teste com cada ferramenta foi de oito horas para cada uma.

Página 1 - possui dois campos texto, sendo que 1 deles possui máscara e dois botões, O Quadro 3 apresenta os casos de teste desenvolvidos com a ferramenta Quality Center para as

regras de interface. Demonstra quais casos foram rastreados e qual a porcentagem do tempo para esse processo de análise. O mesmo acontece para outros itens.

Quadro 3 – Casos de teste da aplicação 1 Página 2 - possui um campo texto, dois campos de seleção e um botão.

O Quadro 4 apresenta os casos de teste desenvolvidos com a ferramenta Testlink.

Regras de interface – Quality Center 1. Testar o tamanho de caracteres do campo Nome. 2. Testar a inserção de caracteres especiais no campo Nome. 3. Testar se o campo Data esta com máscara definida corretamente. 4. Testar o tamanho de caracteres do campo Data. 5. Verificar se o campo Data aceita caracteres especiais. 6. Verificar se o botão Enviar esta com mouseover correto. 7. Verificar se o botão Limpar esta com o mouseover correto. 8. Verificar se o botão Limpar limpa os campos do formulário; 9. Verificar se o botão Enviar esta salvando os dados do formulário. 10. Verificar quais campos são obrigatórios.

Porcentagem de tempo para desenvolver esses casos: 40%

17

Quadro 4 – Casos de teste da aplicação 2

Página 3 – possui dois campos texto, um campo de seleção, um campo de senha e um botão.

Quadro 5 – Casos de teste da aplicação 5

7.3 Resultado Final Abaixo, na figura 16, é apresentado o resultado final do tempo em percentagem, o qual é utilizado

em análise, criação de casos de teste de interface e de negócios em cada ferramenta testada. É possível perceber que, com a ferramenta é possível ganhar tempo para se desenvolver as regras de negócio e isso quer dizer que sobra mais tempo para se desenvolver os casos das regras de negócio.

Regras de interface – Testlink 1. Testar o tamanho de caracteres do campo Endereço. 2. Testar a inserção de caracteres especiais no campo Endereço. 3. Verificar se é possível selecionar mais de um item no campo Estado. 4. Testar a seleção de um item do campo Estado. 5. Verificar quais cidades aparecem ao selecionar um determinado Estado. 6. Verificar se a ordenação dos valores do campo Estado esta correta. 8. Verificar se o botão Enviar esta com mouseover correto. 9. Verificar se a ordenação dos valores do campo Cidades esta correta. 10. Testar a seleção de um item do campo Cidade. 11. Verificar se é possível selecionar mais cidades. 12. Testar o envio do formulário através do botão Enviar.

Porcentagem de tempo para desenvolver esses casos: 44%

Regras de interface – Projeto TCC 1. Verificar limite máximo de caracteres – campo Nome. 2. Verificar se o campo aceita caracteres especiais – campo Nome. 3. Testar se o campo é obrigatório - campo Nome. 4. Testar limite máximo de caracteres – campo CPF. 5. Verificar se o campo aceita caracteres especiais – campo CPF. 6. Testar se o campo é obrigatório – campo CPF. 7. Verificar máscara – campo CPF. 8. Verificar se foi digitado um valor válido – campo CPF. 9. Verificar limite de caracteres – campo Senha. 10. Verificar se a senha atende as especificações – campo Senha 11. Verificar se o valor do campo esta visível – campo Senha. 12. Testar se o campo é obrigatório – campo Senha. 13. Testar seleção de apenas um item – campo Estado. 14. Verificar se a seleção de algum item é obrigatória – campo Estado. 15. Testar se o formulário esta sendo salvo – botão Enviar 16. Testar o mouseover – botão Enviar. 17. Testar o mouseover – botão Enviar.

Porcentagem de tempo para desenvolver esses casos: 27%

18

Figura 16 – Resultados finais de cada ferramenta

Na fase de análise dos testes o tempo utilizado foi semelhante com as três aplicações, isso porque essa fase não depende da utilização de nenhuma ferramenta, mas, sim, do trabalho do profissional de teste. Mesmo sendo possível inserir dados de análise nas ferramentas, isso não foi realizado, levando-se em conta que o escopo do trabalho não era este.

Da mesma forma que a análise, o valor do tempo utilizado na criação dos casos de teste ligados às regras de interface também são semelhantes nas ferramentas Quality Center e Testlink. Na ferramenta desenvolvida, o tempo gasto foi bem menor, podendo assim ganhar tempo no desenvolvimento dos casos de regras de negócio ou até mesmo na execução dos testes.

8 MELHORIAS O projeto, mesmo com escopo limitado, permite a implementação de novas funcionalidades para

trabalhos futuros e para a utilização da aplicação em ambiente de produção o sistema necessita das seguintes melhorias:

Implantação de um banco de dados mais robusto, como por exemplo, SQL Server;

Permitir a execução dos casos de teste em suítes de testes, com controle de versões. Com isso não será preciso a integração com outras ferramentas de execução de teste.

Inserir um modelo para gerenciamento de planos de teste, tendo assim todo o controle do processo, não sendo mais necessário o controle através de documentos.

9 CONCLUSÃO Diante da necessidade de controlar os testes de um sistema e a exigência de alguns clientes de

possuírem estas informações, foi realizado um sistema para gestão de casos de teste. Com ele foi possível desenvolver inúmeros casos e descrever como foram analisados, gerando economia de tempo para a criação dos casos que envolvem regras de negócio.

19

No decorrer do desenvolvimento deste trabalho, foi possível aprofundar os conhecimentos relacionados aos processos de teste. A utilização do sistema feito neste estudo foi fundamental para o desenvolvimento dos casos de teste da empresa. A união deste sistema com o processo desenvolvido possibilitou o início do entendimento de todos os sistemas que a empresa mantinha manutenção e dos novos que a organização estava desenvolvendo. Seria inovador o desenvolvimento de sistemas de teste, facilitando o trabalho dos analistas e agilizando o trabalho de análise e teste, sendo capaz de reduzir os retrabalhos na criação dos casos de teste e dando a flexibilidade de customização destes.

10 AGRADECIMENTO(S) Ao final deste trabalho gostaria de agradecer ao orientador Edemar Costa por ter acreditado no meu

trabalho e nas minhas ideias. Também às pessoas que contribuíram para o desenvolvimento deste sistema, auxiliando no levantamento de requisitos e funcionalidades do mesmo. E ao Diógenes que tanto me ajudou nessa tarefa.

REFERÊNCIAS MYERS, Glenford J., John Wiley & Sons, The Art of Software Testing, 2, Nova Jérsei: 2004. 8 p.

MYERS, Glenford J., John Wiley & Sons, The Art of Software Testing, 2, Nova Jérsei: 2004. 5 p.

PRESSMAN, R. S., McGraw Hill, Engenharia de Software, 2002.

HETZEL, Bill. The Complete Guide to Software Testing - Second Edition, John Wiley & Sons, 1988 .

BARTIE Alexandre. Processo de Teste de Software – Parte 1 - iMasters. Disponível em: < http://imasters.com.br/artigo/6102/des_de_software/processo_de_teste_de_software_parte_01/ >. Acesso em: 30 de maio de 2011.

BARTIE Alexandre. Processo de Teste de Software – Parte 2 - iMasters. Disponível em: <http://imasters.com.br/artigo/6117/software/processo-de-teste-de-software-parte-2 / >. Acesso em: 30 de maio de 2011.

BARTIE Alexandre. Processo de Teste de Software – Parte 03 - iMasters. Disponível em: <http://imasters.com.br/artigo/6117/software/processo-de-teste-de-software-parte-03 / >. Acesso em: 30 de maio de 2011.

ÁVILA Ana Luiza. Artigo Engenharia de Software - Introdução à Engenharia de Requisitos. Disponível em: < http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=8034 >>. Acesso em: 10 de junho de 2011

Sem autor disponível. Papel: Analista de teste. Disponível em: <http://www.wthreex.com/rup/process/workers/wk_tstanl.htm >. Acesso em: 10 de junho de 2011.

IBM Corporation. Função: Analista de teste. Disponível em: < http://rjserver23.brq.com/rupport/rup/roles/rup_test_analyst,%7B8728060F-9DAD-42AD-B0B6-668C9AEA531D%7D.html >. Acesso em: 5 de junho de 2011.