Automação de Testes Utilizando Ferramentas Open Source

Transcrição

1 Universidade de Brasília Instituto de Ciências Exatas Departamento de Ciência da Computação Automação de Testes Utilizando Ferramentas Open Source Hugo Antônio de Azevedo Lousa Carla de Tunes Nunes Monografia apresentada como requisito parcial para conclusão do Bacharelado em Ciência da Computação Orientador Prof. Fernando Antônio de Araújo Chacon de Albuquerque Brasília 2006

2 Universidade de Brasília UnB Instituto de Ciências Exatas Departamento de Ciência da Computação Curso de Bacharelado em Ciência da Computação Coordenadora: Prof ā. Dr ā. Cláudia Nalon Banca examinadora composta por: Prof. Fernando Antônio de Araújo Chacon de Albuquerque (Orientador) CIC/UnB Prof ā. Dr ā. Célia Ghedini Ralha CIC/UnB Prof. Dr. Jorge Henrique Cabral Fernandes CIC/UnB - - CIP Catalogação Internacional na Publicação Hugo Antônio de Azevedo Lousa. Automação de Testes Utilizando Ferramentas Open Source/ Carla de Tunes Nunes, Hugo Antônio de Azevedo Lousa. Brasília : UnB, p. : il. ; 29,5 cm. Monografia (Graduação) Universidade de Brasília, Brasília, Qualidade de Software, 2. Garantia da Qualidade de Software, 3. Teste de Software, 4. Teste em Software Open Source, 5. Ferramentas Open Source de Automação de Teste CDU 004 Endereço: Universidade de Brasília Campus Universitário Darcy Ribeiro Asa Norte CEP Brasília DF Brasil

3 Universidade de Brasília Instituto de Ciências Exatas Departamento de Ciência da Computação Automação de Testes Utilizando Ferramentas Open Source Hugo Antônio de Azevedo Lousa Carla de Tunes Nunes Monografia apresentada como requisito parcial para conclusão do Bacharelado em Ciência da Computação Prof. Fernando Antônio de Araújo Chacon de Albuquerque (Orientador) CIC/UnB Prof ā. Dr ā. Célia Ghedini Ralha CIC/UnB Prof. Dr. Jorge Henrique Cabral Fernandes CIC/UnB - - Prof ā. Dr ā. Cláudia Nalon Coordenadora do Bacharelado em Ciência da Computação Brasília, 03 de Agosto de 2006

4 Agradecimentos Agradeço aos meus pais, pelo seu amor e por me proporcionarem as condições de estudo, mesmo em meio às dificuldades. Ao meu irmão, por ser sempre meu amigo e incentivador. Ao Terge, pelo carinho e pelos cafés no meio da madrugada. Aos amigos, por não me esquecerem mesmo quando ficava ausente por muito tempo. Ao meu orientador Fernando, pela preocupação com o nosso sucesso e pelas críticas construtivas. Ao professor Ralha, pela valiosa ajuda na configuração do LaTEX. E por fim, ao Hugo, por ter me convidado para participar desse projeto, por ter sido sempre um companheiro otimista e paciente e por ter se tornado um grande amigo. (Carla de Tunes Nunes) Agradeço primeiramente a Deus, por ter permitido estar aqui neste momento. Agradeço também à minha família, por ter trilhado o caminho por onde andei. Tenho que também agradecer os meus amigos que em Goiânia deixei, e também, os amigos que em Brasília fiz. Eles foram determinantes para que eu aguentasse a saudade de casa. Agradeço também ao Mateus e ao Vinícius, dois grandes amigos que considero irmãos nos cinco anos de convivência na República onde morei. Também agradeço à Laíla, pelo companheirismo e apoio dado nos momentos difíceis e nas noites mal dormidas. Ao professor Fernando, pelos conselhos e pelas broncas nos momentos certos durante a execução deste projeto e pelos ensinamentos e lições nas outras matérias, que marcaram e muito minha graduação. Também ao professor Ralha, um grande conhecedor da ferramenta LaTEX, utilizada em nosso projeto. Por fim, agradeço de coração à Carlinha, por ter aceitado o meu convite de trabalhar neste projeto e por ter sido fundamental em todos os passos que demos neste trabalho, e também por ter me ensinado o uso correto da crase. (Hugo Antônio de Azevedo Lousa)

5 Resumo Nosso trabalho trata da automação de testes utilizando ferramentas de software livre. Para alcançar nossos objetivos, faremos um estudo dos conceitos relativos à Qualidade de Software e a Garantia da Qualidade de Software. Dentro deste contexto, apresentaremos um estudo sobre a importância dos testes de software e alguns tipos existentes. Para focar no nosso contexto, faremos também um estudo do modelo de desenvolvimento open source e da garantia da qualidade em alguns projetos significativos. Mais especificamente, analisaremos a questão de como se dá a automação de teste de software, aplicando alguns exemplos de teste automatizado em um software produzido na Universidade de Brasília. E finalmente, traremos conclusões e propostas para trabalhos futuros. Palavras-chave: Qualidade de Software, Garantia da Qualidade de Software, Teste de Software, Teste em Software Open Source, Ferramentas Open Source de Automação de Teste

6 Abstract Our work is about testing automation using open source tools. To achieve our goals, we will study some concepts related to Software Quality and Software Quality Assurance. We will present a study about the importance of software testing and some existing types. We will study the open source development model and the software quality assurance of some important projects. We will analise how software automation is implemented, applying some examples of it on a software developed at the University of Brasilia. Finally, we will bring some conclusions and proposals for future works. Keywords: Software Quality, Software Quality Assurance, Software Testing, Testing in Open Source Software, Open Source Automated Testing Tools

7 Sumário Lista de Figuras 11 Lista de Tabelas 13 Capítulo 1 Introdução Objetivos Estratégia e Estrutura do Projeto Capítulo 2 Qualidade de Software Histórico do Problema da Qualidade de Software O que é Qualidade de Software Prevenção versus Detecção Capítulo 3 Garantia da Qualidade de Software Componentes da Garantia da Qualidade de Software Componentes de Pré-Projeto Componentes do Ciclo de Vida do Projeto do Software Componentes de Infra-Estrutura para Prevenção de Erros e Melhorias Componentes da Gerência de SQA Os Componentes Humanos da SQA Teste e Qualidade Teste atuando como uma técnica de avaliação da qualidade 24

8 Capítulo 4 Teste de Software Perspectiva Histórica Definição Fundamentos Tipos de Testes Testes de Caixa Preta Partições de Equivalência Testes de Estrutura (caixa branca) Testes de Caixa Cinza (Funcional e Estrutural) Testes de Caminho Testes de Unidade Testes de Integração Testes de Sistema Depuração Testes de Regressão Smoke Tests Capítulo 5 Processo de desenvolvimento em comunidades open source Processo de teste no desenvolvimento Processo de teste em comunidades open source Motivos do sucesso do modelo de desenvolvimento open source Principais desafios dos projetos open source Capítulo 6 Garantia de qualidade de importantes projetos de software livre Projeto OpenOffice Projeto Gnome Linux Projeto Mozilla Projeto Apache

9 Capítulo 7 Automação de Testes Categorias de ferramentas para automação de testes A promessa da automação do teste Problemas comuns em automação de teste Limitações da automação de teste Capítulo 8 Implementação Aspectos do Software a ser Testado Requisitos Funcionais Definição da Estratégia Teste Estrutural de Unidade Teste de Verificação de Aderência Teste Funcional de Sistema Projeto do Teste Escolha das Ferramentas Plano de Teste Implementação dos Testes Testes Estrutural de Unidade Testes de Verificação de Aderência Testes Funcionais de Sistema Execução dos Testes Testes Estruturais de Unidade Teste de Verificação de Aderência Testes Funcionais de Sistema Implementação das Correções Execução dos Testes de Regressão Resultados Teste Estrutural de Unidade

10 8.8.2 Teste de Verificação de Aderência Testes Funcionais de Sistema Capítulo 9 Conclusão Propostas para trabalhos futuros Apêndice A Plano de Teste 87 10

11 Lista de Figuras 4.1 Teste de caixa preta(sommerville, 2003, p. 378) Partições de Equivalência(Sommerville, 2003, p. 379) Testes de Integração Top-Down e Bottom-Up(Sommerville, 2003, p. 387) Fases do Desenvolvimento versus Tipos de Testes(Lewis, 2000, p. 44) Processo de Teste em Espiral(Lewis, 2000, p. 95) Gráfico de Tempo de Teste por Tamanho do Projeto(Zhao e Elbaum, 2003, p. 12) IssueZilla do Projeto OpenOffice (capturado de org) Smoke Tests do Projeto OpenOffice(capturado de openoffice.org) TestLink Uma ferramenta open source de automação da gerência de testes Exemplo da ferramenta Coverlipse Relatório da ferramenta Cobertura Exemplo de script gerado pelo editor do Abbot Interface Gráfica de Configuração do CheckStyle Arquivo XML utilizado pelo Checkstyle, definindo o padrão de codificação Exemplo de erro muito frequente encontrado pelo CheckStyle... 68

12 8.7 Caso de Uso UC Caso de Teste TC Script de Automação do Caso de Teste TC Roteiro para Execução dos Testes de Unidade Amortecimento das exceções : nenhum tratamento foi dado Aba Chechstyle Violations, com a lista de desvios encontrados Código-fonte com o desvio e o destaque dado pelo CheckStyle Aba Chechstyle Violations Chart, com um gráfico dos tipos de erros encontrados Exemplo de falha na execução do script automatizado do Abbot Exemplo de Relatório de Execução de Teste de Sistema Exemplo de Relatório de Execução de Teste de Sistema, quando todos os testes obtiveram sucesso

13 Lista de Tabelas

14 Capítulo 1 Introdução No mundo competitivo e altamente globalizado dos dias de hoje, cada vez mais algumas indústrias estão se preocupando com a qualidade dos produtos que produzem. Vários fatores podem influenciar essa preocupação, como o campo de atuação, o público alvo e a complexidade do produto. Objetivando o sucesso do seu negócio, as empresas tentam estar cada vez mais próximas das expectativas dos seus clientes. Nos vários tipos de indústrias, existem os mais diversos projetos. Por exemplo, na indústria automotiva, produtos são produzidos em larga escala, tendo como base exigências e perfil de um grupo grande de usuários. Já na indústria de software, existem também projetos que visam a produção de software em larga escala, seguindo a mesma linha do exemplo anterior, porém, grande parte dos projetos da indústria de software são desenvolvidos para uma aplicação restrita, atendendo às necessidades de um cliente específico. Dentro deste contexto, a qualidade dos artefatos produzidos vem se tornando cada vez mais importante nos projetos de software. Vários clientes, devido ao seu tipo de negócio, possuem requisitos de qualidade muito elevados, como por exemplo a indústria bélica ou a nuclear, onde falhas podem causar prejuízos catastróficos, tanto do ponto vista econômico quanto humano. Mesmo os clientes que procuram indústrias de software para desenvolver artefatos que apóiam os seus mais básicos processos, como folha de pagamento, controle de estoque e vendas, estão exigindo destas indústrias um padrão de qualidade mínimo. Para que haja uma garantia da qualidade dentro de um projeto de software, vários componentes são introduzidos no processo de desenvolvimento. Alguns desses componentes que formam um sistema de garantia de qualidade são, por exemplo: revisões de contrato, desenvolvimento de planos de qualidade, revisões de artefatos, teste de software, treinamento adequado e certificação da equipe envolvida no projeto, ações corretivas e preventivas, controle de documentação, geração e análise de métricas de qualidade, dentre outros [11]. Dentre os vários modelos de desenvolvimento de software existentes, um novo 14

15 modelo vem se tornando cada vez mais importante e ganhando mais força e notoriedade na comunidade de Tecnologia da Informação. Estamos falando do modelo de desenvolvimento open source, que apresenta características muito específicas em seu processo de desenvolvimento, especialmente no que se refere às medidas tomadas para que se garanta a qualidade do software. Um dos principais componentes de um sistema de garantia de qualidade é o teste de software, que está cada vez mais presente de forma sistemática dentro dos projetos de software. Prova disso é que a literatura de engenharia de software tradicional dedica capítulos inteiros sobre o assunto. O processo de teste consome tempo e recurso do projeto, sendo que algumas literaturas citam que 50% do tempo gasto em um projeto é dedicado à fase de teste [41]. Surgiu então a necessidade de automatizar parte deste processo, trazendo redução de tempo e custos envolvidos nesta etapa. Diante dessa problemática, o foco principal do nosso projeto foi automatizar parte do processo de testes de um software, para aumentar a qualidade do mesmo, utilizando ferramentas de automação de teste open source. 1.1 Objetivos Ao final desse projeto, pretendemos ter alcançado os seguintes objetivos: 1. Estudar sobre Qualidade de Software e Garantia da Qualidade de Software, verificando como testes se inserem nesse contexto; 2. Conhecer os principais tipos de testes e escolher, dentre eles, os que serão utilizados no nosso projeto; 3. Estudar o modelo de desenvolvimento open source e verificar como é garantida a qualidade do software nesses modelos, principalmente no que se refere à fase de testes. 4. Pesquisar projetos que seguem o modelo de desenvolvimento open source e verificar como são feitos os testes nesses projetos; 5. Pesquisar sobre automação de testes e verificar os vantagens e desvantagens dessa prática; 6. Conhecer ferramentas de automação de testes criadas seguindo o modelo de desenvolvimento open source; 7. Implantar um processo de teste em um software, com enfoque em automação; 8. Relatar as lições aprendidas ao aplicar testes automatizados em um sistema utilizando ferramentas open source. 15

16 1.2 Estratégia e Estrutura do Projeto Para alcançar os nossos objetivos, fizemos um estudo teórico sobre qualidade de software, teste de software, modelo de desenvolvimento open source e automação de testes. Essa pesquisa nos possibilitou delinear a estratégia de testes e os tipos de ferramentas a serem utilizadas, tendo consciência das vantagens e desvantagens de se utilizar uma ferramenta open source. O Capítulo 2 define o que é Qualidade de Software e explica como ela se tornou um quesito importante nos projetos de software. O Capítulo 3 apresenta uma definição para Garantia da Qualidade de Software e lista os componentes necessários para a obtenção dessa garantia, além de relacionar teste com qualidade. A seguir, no Capítulo 4 apresentamos o histórico dos testes na Computação, sua definição e explicamos sobre vários tipos de testes, nos concentrando nos tipos usados nesse projeto. O Capítulo 5 descreve o modelo de desenvolvimento open source, comparando o com alguns modelos de desenvolvimento tradicionais e explica os motivos para o sucesso desse novo modelo, assim como seus principais desafios. O capítulo seguinte, Capítulo 6, é uma extensão do capítulo anterior, onde fizemos não apenas uma pesquisa teórica sobre projetos open source em artigos e livros, mas também uma pesquisa prática, entrando em contato direto com gerentes e desenvolvedores dos projetos e participando de listas de discussão e fóruns relacionados. Isso foi necessário pela falta de referências suficientes sobre o assunto. O Capítulo 7 trata da automação de testes, um capítulo importante para nosso amadurecimento no sentido de como tratar a automação, iniciando nossa fase de implementação conscientes dos benefícios que isso nos traria e das limitações que nos depararíamos. Esse capítulo lista alguns tipos de ferramentas de automação existentes, cita as vantagens e os problemas que a automação provê, além das limitações dos testes automatizados em relação aos testes manuais. O Capítulo 8 descreve a nossa fase de implementação, onde descrevemos as atividades do processo de teste que conduzimos e os artefatos que geramos. Descrevemos como foi feito o trabalho de pesquisa de ferramentas de automação open source, como ocorreu a fase de instalação e configuração das mesmas e a criação dos scripts de teste. Em seguida, explicamos a fase de execução dos testes automatizados e a implementação das correções. Por fim, escrevemos o capítulo com nossas conclusões, Capítulo 9, onde também esboçamos alguns trabalhos futuros que podem ser feitos para dar continuação ao nosso projeto. 16

17 Capítulo 2 Qualidade de Software 2.1 Histórico do Problema da Qualidade de Software Alguns autores explicam que a indústria de software atualmente encontra problemas característicos de um período de crise. A definição de crise presente no Websters Dictionary, é que crise é um ponto decisivo no curso de algo; momento, etapa ou evento decisivo ou crucial. Contudo, para o processo de software, não se vê momentos cruciais, e sim uma mudança lenta e gradual [36]. Para se ter uma visão mais crítica sobre o que está ocorrendo com a indústria de software, deve-se investigar qual é a verdadeira natureza dos problemas relacionados a ela. Os problemas não se restringem ao fato de um software não funcionar corretamente. Pelo contrário, essa natureza abrange problemas relacionados a como se desenvolve software, como manter um volume cada vez maior de software, como atender a uma demanda cada vez maior por software [36]. Segundo Pressman [36], os problemas que a indústria de software sofre são apenas manifestações visíveis de outras dificuldades do processo de desenvolvimento, dentre elas: Não é dedicado tempo suficiente para a coleta de dados sobre o processo de desenvolvimento de software. Com dados extremamente escassos, não se pode avaliar novas ferramentas, métodos ou padrões; Freqüentemente o cliente está insatisfeito com o sistema que lhe foi entregue. Os projetos de software são levados a cobrir um vago indício das exigências do cliente. Geralmente porque a comunicação com o cliente é extremamente fraca; A qualidade de software é suspeita. Do início dos anos 90 para cá é que começou-se a entender a importância de um processo de teste de software 17

18 sistemático e completo, e também a conceber modelos e conceitos mais sólidos relacionados à confiabilidade e garantia da qualidade; Os softwares produzidos podem ser muito difíceis de manter. A atividade de manutenção consome a maior parte do montante financeiro gasto com a indústria de software. Em muitos projetos, a capacidade de se manter, ou seja, a manutenibilidade, é um requisito não-funcional, dentre tantos outros, que não é mapeado no início do projeto, e avaliado no momento da aceitação do software. 2.2 O que é Qualidade de Software No Webster s Dictionary, qualidade é definida como a característica essencial de algo, característica inerente ou distinta, grau ou nota de excelência. Se olharmos a literatura específica de computação, veremos que existem duas definições amplamente aceitas de qualidade de software. A primeira diz que qualidade é quando se atende aos requisitos [42]. Com essa definição, para se ter um software de qualidade, os requisitos devem ser, necessariamente, possíveis de se medir, e o software deve atender os requisitos. Para essa definição, qualidade é um estado binário, isto é, o software é um software de qualidade ou não. Os requisitos podem ser simples ou complexos, mas como eles são mensuráveis, pode-se determinar se a qualidade foi atingida ou não. Esta definição está associada à visão de quem produziu o software [42]. Outra definição de qualidade vislumbra o outro lado da moeda, o lado do cliente. Sua definição está intimamente ligada em observar se o software faz o que ele precisa. Deve haver uma descrição da finalidade do software, geralmente documentada na especificação de requisitos do software. O documento que contém os requisitos do software é o documento mais importante, e o processo de qualidade trabalha em cima disso. Além disso, os atributos de qualidade, ou seja, atributos não-funcionais, como dito no último item da seção 2.1, devem ser descritos, também, na especificação de requisitos do cliente. Alguns atributos de qualidade são: usabilidade (facilidade de uso da aplicação), portabilidade (capacidade do software ser executado em diversas arquiteturas de computador), reusabilidade (possibilidade de transferir componentes deste software para um outro software) [42]. Vários outros requisitos de qualidade serão indicados no Capítulo 3. Algumas outras definições de qualidade de software, mais formais que as anteriores merecem destaque, como por exemplo a definição da IEEE [1], que define qualidade de software como grau com o qual um sistema, componente ou processo atende às necessidades, ou expectativas do cliente ou do usuário. Existem também várias normas que regem o tocante de qualidade de software, como a norma ISO/IEC 9126 [39] e a NBR [13], sendo que a norma NBR se espelha na norma ISO e define que qualidade de software é a totalidade das características de um produto de software que lhe confere a capacidade de satisfazer necessidades implícitas e explícitas. Necessidades explícitas seriam aquelas expressas 18

19 na definição de requisitos propostos pelo produtor do software. Esses requisitos definem as condições em que o produto deve ser utilizado, seus objetivos, funções e o resultado esperado. Já as necessidades implícitas são aquelas que, embora não expressa nos documentos do produtor, são necessárias para o usuário, principalmente aqueles que não são percebidos, porém fundamentais para o usuário, pois a gravidade de sua ausência podem ter proporções inimagináveis, como por exemplo, um erro em um software hospitalar causar o óbito de um paciente. 2.3 Prevenção versus Detecção Qualidade dificilmente é atingida simplesmente avaliando um software já terminado. O alvo deve ser o de prevenir problemas ou deficiências com a qualidade nos primeiros momentos. Algumas medidas de garantia da qualidade incluem: estruturar o processo de desenvolvimento com um padrão de desenvolvimento de software e manter esse padrão com métodos, técnicas e ferramentas [42]. Além de avaliações do software, avaliações do próprio processo são essenciais para um bom plano de gerência da qualidade, como por exemplo, a documentação de padrões de codificação, prescrição e uso de padrões, métodos, técnicas e procedimentos para o backup de dados, gerência de mudanças e documentação de defeitos [42]. Gerenciar a qualidade tem usualmente diminuído os custos de produção porque quanto mais cedo um defeito é encontrado e corrigido, mais barato será sua correção. Apesar de o investimento inicial ser alto, a longo prazo se terá um software de alta qualidade e seus custos de manutenção serão reduzidos [42]. Na concepção de um projeto visando qualidade, adota-se uma visão que se obtém qualidade principalmente durante o projeto e concepção do software, fazendoo mais robusto, ou seja, menos sujeito à introdução de defeitos no processo de produção e menos passível de falhas conforme as condições e forma de uso [16]. 19

20 Capítulo 3 Garantia da Qualidade de Software A SQA (Garantia de Qualidade de Software ou, em inglês, Software Quality Assurance) é o conjunto de atividades necessárias para criar uma confiança adequada de que processos são estabelecidos e continuamente aprimorados visando a produção de software que atendam as especificações. Controle de Qualidade é o processo pelo qual a qualidade do produto é comparada com padrões aplicáveis e alguma ação é tomada quando uma não conformidade é encontrada [42]. Há também a definição do termo SQA segundo a norma IEEE 610 [1], que diz que a Garantia da Qualidade de Software é um padrão planejado e sistemático de ações para prover uma confiança adequada que um ítem ou produto está em conformidade com os requisitos técnicos estabelecidos. Já a norma NBR ISO 9000 [3] diz que Garantia da Qualidade é parte da gestão da qualidade focada em prover confiança de que os requisitos da qualidade serão atendidos. Segundo Galin [11], quando não se segue padrões determinados pela SQA ou há uma ausência de atividades que se relacionam com a SQA, freqüentemente o software produzido é de baixa qualidade, contendo as seguintes características: 1. O software entregue freqüentemente falha; 2. Conseqüências inaceitáveis decorrentes de falhas (crashes) do sistema, desde prejuízos financeiros e perda de vidas; 3. O sistema está constantemente indisponível para o propósito que foi criado; 4. Evoluções do sistema são caras; 5. Custos de detecção e remoção de defeitos no software são altos. A Garantia da Qualidade de Software é um esforço planejado que garante que um software cumpra os critérios citados acima e que possua atributos específicos daquele projeto como portabilidade, eficiência, reuso e flexibilidade. É uma coleção de atividades e funções utilizadas para monitorar e controlar um projeto 20

21 de software possibilitando que aqueles objetivos específicos sejam alcançados com nível de confiança desejado. Tudo isto não é responsabilidade somente do grupo que cuida da garantia de qualidade de software, mas sim de um consenso entre o gerente do projeto, o líder do projeto, os funcionários do projeto e os usuários, ou seja, dos stakeholders [42]. Esse esforço planejado ao qual nos referimos se deve ao fato de se montar um framework composto por vários componentes que devem estar presentes em um sistema de SQA. Dependendo das características da organização, do seu processo de desenvolvimento, da maneira como ela conduz seus projetos de software, das atividades de manutenção do software, e a equipe de profissionais, cada um dos componentes pode estar presente de maneira clara ou até estar ausente. Vários modelos de qualidade de software fazem um estudo e definem os artefatos, os processos e as atividades que devem estar presente em um framework de garantia da qualidade. Dentre estes podemos citar o CMMI SEI [19], conhecido internacionalmente como um modelo de sucesso para quem se preocupa com SQA. Para contextualizar a preocupação atual que se faz presente também no Brasil, nós fizemos uma pesquisa e encontramos iniciativas relevantes que tratam da questão de definição e implantação de frameworks de qualidade para o contexto brasileiro. Dentre os encontrados, temos o projeto MPSBR [5], que é um projeto estruturante que vai promover a qualificação de um grupo amplo de empresas compatível com os padrões de qualidade aceitos internacionalmente pela comunidade de software, a custos acessíveis para a grande maioria das empresas brasileiras. Há, também, um outro exemplo nacional, ainda em desenvolvimento, e que merece destaque pelo envolvimento de grandes empresas estatais nacionais da área de TI e até mesmo da Universidade de Brasília, que é o Programa Serpro de Melhoria do Processo de Desenvolvimento de Soluções [38]. 3.1 Componentes da Garantia da Qualidade de Software Como não é objetivo do trabalho analisar e avaliar cada um destes componentes, ou até mesmo sugerir um exemplo a ser usado, fizemos uma rápida citação de cada um dos componentes que tradicionalmente formam um framework de SQA, permitindo assim, uma melhor contextualização da atividade de testes dentro das atividades de SQA. Os componentes descritos nesta seção foram obtidos através do livro de Galin [11] Componentes de Pré-Projeto Os componentes do SQA citados a seguir são úteis na fase preparatória, antes de iniciar o trabalho no projeto em si: 21

22 Revisão de Contrato; Elaboração do Plano de Desenvolvimento e de Qualidade, podendo englobar outros Planos, como o de Teste Componentes do Ciclo de Vida do Projeto do Software O ciclo de vida do projeto é composto de dois estágios: o estágio do ciclo de vida do desenvolvimento em si e o estágio da operação manutenção. Os componentes dessa fase são: Revisões de documentos como relatórios de projeto, documentação de teste, planos, dentre outros; Opiniões de especialistas em pontos cruciais do projeto, principalmente naqueles em que a organização não possui experiência ou know how naquilo; Teste de Software, discutido e exemplificado principalmente no Capítulo 4; Serviços de Manutenção corretiva, adaptativa e de aperfeiçoamento da funcionalidade Componentes de Infra-Estrutura para Prevenção de Erros e Melhorias Os componentes da infra estrutura do SQA são: Instruções de Procedimentos e de Trabalho baseadas na experiência acumulada e no conhecimento da organização, contribuindo para o emprego correto e eficaz de tecnologias e rotinas estabelecidas pela organização; Apoio a Dispositivos de Qualidade, como o uso de templates e checklists, significando uma economia de tempo e contribuindo diretamente para uma uniformização e integralidade dos documentos; Treinamento, Instrução e Certificação da Equipe de Trabalho, ou seja, manter o recurso humano da organização em um patamar adequado ao nível de qualidade exigido pela mesma; Ações Corretivas e Preventivas, ou seja, fazer um estudo sistemático dos dados coletados através de exemplos de sucessos e erros, servindo como base para a implementação de soluções e melhorias; 22

23 Gerência de Configuração, controlando o processo de mudança na versão dos artefatos produzidos durante o projeto, desde a manutenção de registros de alteração até aprovação das mudanças; Controle da Documentação, definindo tipos e formatos de documentos a ser controlados e também definindo processos de revisão e aprovação para cada documento controlado Componentes da Gerência de SQA Os componentes de gerência de SQA incluem: Controle do Progresso do Projeto, detectando situações que possam induzir a desvios do que foi planejado, podendo-se tomar medidas corretivas; Métricas da Qualidade do Software, apoiando a sustentação das atividades de controle e iniciação de melhorias do processo; Custos da Qualidade do Software, onde se mapeia a soma total dos custos de qualidade, possibilitando ajustes futuros Os Componentes Humanos da SQA As seções 3.1.1, 3.1.2, e nos dão uma noção de quão complexa são as atividades de um framework de SQA, e que, portanto, precisam de forte apoio organizacional. Esse apoio organizacional advêm de pessoas, onde cada um concentra tarefas específicas. O mapeamento de cada conjunto de pessoas e sua função específica é: Gerência na SQA: define políticas de qualidade, aloca recursos, atribui papéis à equipe, provê sugestões de cronograma e orçamento; A Unidade de SQA: dedica todo o seu tempo nas atividades de SQA; Colaboradores, Comitês e Fóruns de SQA: são membros das equipes de desenvolvimento que possuem interesse especial em SQA e que podem contribuir resolvendo problemas localizados de qualidade. 23

24 3.2 Teste e Qualidade Teste atuando como uma técnica de avaliação da qualidade Um trocadilho, proposital ou não, ocorre quando uma organização nomeia um grupo de testes de grupo de garantia da qualidade. Dentre as várias definições para teste e garantia da qualidade, o dicionário de termos da IEEE [1] define os dois termos da seguinte maneira: Teste: atividades nas quais um sistema ou um componente é executado sob determinadas condições e os resultados são observados ou gravados, e uma avaliação é feita observando determinado comportamento do sistema ou do componente; Garantia da Qualidade: um padrão planejado e executado de maneira sistemática de todas as ações necessárias para prover confiança adequada de que um item ou um produto está de acordo com os padrões definidos nos requisitos, e um conjunto de atividades projetadas para avaliar o processo pelo qual os produtos são desenvolvidos. Essas definições mostram que teste é um subconjunto do processo de garantia de qualidade ou um processo complementar do próprio processo de teste. É consenso entre os experts da área industrial de que processo de teste (também conhecido como controle de qualidade) avalia o produto desenvolvido afirmando a presença ou a ausência (não garante a ausência completa) de defeitos, enquanto a garantia da qualidade orienta o processo de desenvolvimento na prevenção de defeitos [42]. Um problema significativo pode aparecer quando o cargo de gerente de teste é confundido com o do gerente da garantia da qualidade. Nesses casos o gerente de teste se torna o responsável pela qualidade do sistema, mas isso não é cabível. Primeiramente não se pode testar qualidade dentro do software, e, segundo, é que teste pode somente revelar defeitos no software. Teste está intimamente ligado à qualidade, deve estar alinhado com os riscos de qualidade, deve acontecer dentro de um contexto de gestão da qualidade. Finalmente, teste fornece ao projeto de desenvolvimento de software oportunidades de remover defeitos críticos que afetam a qualidade antes do software ser entregue ao cliente. Todavia, o processo de teste, de uma certa forma, estima a qualidade, porém não cria nem gerencia a qualidade no software testado. [42]. 24

25 Capítulo 4 Teste de Software 4.1 Perspectiva Histórica Hetzel [41] explica que aproximadamente 50% do tempo e mais de 50% do custo total da área de software são gastos no teste de programas ou sistemas em desenvolvimento. Ele comenta que testar sistemas é algo que a maioria dos programadores já fez por força ou obrigação, uma atividade na qual investem muito tempo e dinheiro. Mesmo assim, a definição de teste não é uma coisa muito clara ainda nos dias de hoje. Segundo se pensava então, os programas eram escritos, depois testados e depurados. Os testes eram considerados uma atividade secundária, englobando os esforços para detecção de erros e também sua correção e eliminação. Vários dos primeiros estudos publicados sobre o teste de software tratavam, na verdade, da depuração. A dificuldade da correção e eliminação dos erros foi vista durante muito tempo como um problema mais interessante. Só em 1957 o teste de programas foi nitidamente separado da depuração [41]. A partir do final da década de 1950 e durante a década de 1960, o teste de software vem assumindo uma importância crescente em decorrência de aspectos técnicos e econômicos. Os sistemas de computador eram falhos e deficientes, o custo e o impacto causado pela recuperação desses problemas tornava-se cada vez maior. Passou-se a dar ênfase a testes mais criteriosos por parte de usuários e gerentes de desenvolvimento, e o tempo e recursos dedicados ao teste e à depuração cresceram acentuadamente [41]. 4.2 Definição O teste é um processo que experimenta um sistema de forma manual ou automática, a fim de comprovar que o sistema atende às necessidades especificadas. 25

26 Também pode ser considerado como uma forma de identificar as diferenças entre os resultados esperados e os obtidos, ou seja, ele executa o programa a fim de encontrar erros. Uma definição bem interessante fornecida por Hetzel [41], onde a relação entre teste e qualidade é mostrada de forma explícita, é a seguinte: Teste é qualquer atividade que vise a avaliar uma característica ou recurso de um programa ou sistema. Teste é a medida da qualidade do software. 4.3 Fundamentos Segundo Hetzel [41], toda proposta de metodologia de software deve propiciar meios de resposta às seguintes perguntas: 1. O que deve ser testado? De todos os atributos (características) passíveis de mensuração e casos de teste disponíveis, como selecionar o subconjunto mais adequado a uma determinada situação? 2. Quando o teste deve ser encerrado? Como se chega aos resultados esperados? O que deve ser considerado satisfatório? Quando um teste é mal-sucedido, e quando é bem-sucedido? 3. Quem realiza o teste? Quem deve ficar a cargo do trabalho de teste (definir o que deve ser testado e avaliar os resultados)? Quem é responsável pelo teste, e como coordenar o trabalho de teste com o restante do esforço de desenvolvimento? 4.4 Tipos de Testes Há várias maneiras possíveis de se classificar tipos de testes. Pesquisamos várias fontes para buscar informações sobre quais os tipos de testes existentes e quais se adequariam às nossas necessidades. Procuramos expor aqui alguns dos testes mais bem estudados e com vasta bibliografia disponível. Alguns serão expostos mas não serão implementados no nosso projeto, como os testes de integração, porém, há uma seção sobre esse tipo de teste e suas diferentes estratégias de integração Testes de Caixa Preta Os testes funcionais, ou testes de caixa preta, são uma abordagem na qual os testes são derivados da especificação de programa ou de componente. O sistema é uma 26

27 caixa preta, cujo comportamento somente pode ser determinado estudando-se suas entradas e saídas relacionadas. A esse método também se dá o nome de testes funcionais, porque o testador está preocupado somente com a funcionalidade, e não com a implementação do software [18]. Os testes de caixa preta procuram erros em algumas categorias como erros de interface, erros de inicialização e término, erros nas estruturas de dados ou no acesso a bancos de dados externos e funções incorretas ou inexistentes [36]. A figura 4.1 ilustra o modelo de um sistema empregado em testes de caixa preta. Essa abordagem é igualmente aplicável a sistemas que são organizados como funções ou como objetos. Figura 4.1: Teste de caixa preta(sommerville, 2003, p. 378) O testador apresenta as entradas ao componente ou ao sistema e examina as saídas correspondentes. Se as saídas não são aquelas previstas, então o teste teve sucesso, ou seja, detectou um problema com o software [18]. Uma vantagem importante do teste de caixa preta é que os testes são direcionados ao que o programa ou sistema tem que fazer [42]. O principal problema para o responsável pelos testes de caixa preta é selecionar entradas que tenham grande probabilidade de ser membros do conjunto de valores que causem erros no sistema. Como não há conhecimento da estrutura ou lógica interna, poderia haver erros por parte do programador, o que não pode ser detectado com o teste de caixa preta [42]. Muitas vezes, a seleção desses casos de teste tem como base a experiência prévia dos engenheiros de teste. Eles utilizam o conhecimento de domínio para identificar casos de teste que possam revelar defeitos. Contudo, a abordagem sistemática da seleção de dados de teste através 27

28 das partições de equivalência, discutida na seção 4.4.2, pode também ser utilizada para complementar esse conhecimento eurístico [18]. Os testes de caixa preta não são uma alternativa para os testes de caixa branca (seção 4.4.3) e sim uma abordagem complementar que tem a probabilidade de descobrir uma classe de erros diferente. Os testes de caixa preta tendem a ser aplicados durante as últimas etapas da atividade de teste ao contrário dos de caixa branca, concentrando-se apenas nos tipos dos dados [36] Partições de Equivalência A partição de equivalência é um método que separa os domínios dos dados de entrada em categorias. Essas categorias podem ser de entradas válidas e inválidas, permitindo que casos de teste na mesma categoria sejam eliminados sem que se prejudique a eficácia dos testes [14]. Essas classes têm características comuns, como números positivos, números negativos, strings sem brancos, etc. Os programas normalmente se comportam de maneira similar para todos os membros de uma classe. Uma abordagem sistemática dos testes para a detecção de defeitos baseia-se em identificar todas as partições de equivalência que tenham de ser manuseadas por um programa, a fim de criar os casos de teste [18]. Na Figura 4.2, cada partição de equivalência é mostrada como uma elipse. As partições de equivalência de entradas são conjuntos de dados em que todos os membros do conjunto devem ser processados de maneira equivalente. As partições de equivalência de saída são saídas de programa que têm características comuns e, assim, podem ser consideradas uma classe distinta [18]. Uma vez identificado um conjunto de partições, escolhem-se então casos de teste a partir de cada uma dessas partições. Uma boa diretriz a seguir para a seleção de casos de teste é escolher casos de teste nos limites das partições e também casos próximos ao ponto médio da partição. O ponto em questão para essa diretriz é que os projetistas e os programadores tendem a considerar valores típicos de entradas, quando desenvolvem um sistema. Esses valores são testados escolhendose o ponto médio da partição. Os valores-limite são sempre atípicos e, em geral, os erros com esses valores são mais frequentes do que nas regiões centrais, apesar das razões para que isso aconteça não serem completamente claras [14; 18; 36]. As partições de equivalência podem ser identificadas utilizando-se a especificação do programa ou a documentação do usuário e pelo testador, utilizando sua própria experiência para prever que classes de valores de entrada podem detectar erros [18]. 28

29 Figura 4.2: Partições de Equivalência(Sommerville, 2003, p. 379) Testes de Estrutura (caixa branca) Os testes de estrutura consistem em uma abordagem de testes que são derivados do conhecimento da estrutura e da implementação do software, que tem por objetivo encontrar erros nessa estrutura através da criação de testes que exercitem suficientemente os possíveis caminhos de execução. Essa abordagem é, às vezes, chamada de testes de caixa branca, testes de caixa de vidro ou teste de caixa clara, para distingüí-los dos testes de caixa preta [14; 18]. Os testes de estrutura são, em geral, aplicados a unidades de programa relativamente pequenas, como sub-rotinas, ou às operações associadas com um objeto. Como o nome sugere, o testador pode analisar o código e utilizar conhecimento sobre a estrutura de um componente a fim de derivar os dados para o teste. A análise do código pode ser utilizada para descobrir quantos casos de teste são necessários para garantir que todas as declarações no programa ou componente sejam executadas pelo menos uma vez durante o processo de teste [18]. Os projetistas de testes utilizam os testes de caixa branca para garantir que todos os caminhos dentro de um módulo sejam exercitados pelo menos uma vez, exercitar todas as decisões lógicas para valores falsos ou verdadeiros, executar todos os laços em suas fronteiras e dentro de seus limites operacionais e exercitar as estruturas de dados internas para garantir a sua validade [36]. 29

30 A vantagem do teste de caixa branca em relação ao de caixa preta é que é completo e se concentra no código produzido. Como há conhecimento da estrutura interna ou lógica, erros de parte do programador têm uma probabilidade maior de serem detectados [42]. Uma desvantagem do teste de caixa branca é que não verifica se as especificações estão corretas, i.e., se concentra apenas na lógica interna e não verifica a lógica em relação à especificação. Também, se o algoritmo for muito complexo, o teste de caixa branca pode não executar todos os caminhos lógicos possíveis através do programa porque isso iria acabar em um número astronomicamente grande de testes [42]. Uma última desvantagem que pode ser mencionada é que ele geralmente é desenhado pelos desenvolvedores, já que, na maioria das vezes, eles são os únicos que conhecem bem o desenho e o código das unidades a testar. [14] Testes de Caixa Cinza (Funcional e Estrutural) O teste de caixa preta se concentra na funcionalidade do programa contra sua especificação. O teste de caixa branca se concentra nos caminhos de lógica. O teste de caixa cinza é a combinação dos dois. O responsável pelo teste estuda as especificações dos requisitos e se comunica com o desenvolvedor para entender a estrutura interna do sistema. O objetivo é acabar com especificações ambíguas e os lendo nas entrelinhas para construir testes apropriados. Um exemplo do uso do teste de caixa cinza é quando o testador percebe que uma certa funcionalidade parece ser reusada através de toda uma aplicação. Se quem está testando entra em contato com o desenvolvedor e entende a estrutura e arquitetura interna, muitos testes serão eliminados, porque será possível testar esta funcionalidade apenas uma vez [42] Testes de Caminho Os testes de caminho são uma estratégia de teste de estrutura, cujo objetivo é executar cada caminho de execução independente, por meio de um componente ou programa, além de caminhos de tratamento de erros. Quando cada caminho independente for executado, então todas as declarações no componente devem ter sido executadas pelo menos uma vez. Além do mais, todas as declarações condicionais são testadas para os casos verdadeiros e os falsos. Em um processo de desenvolvimento orientado a objetos, os testes de caminho podem ser utilizados quando são testados métodos associados a objetos [18; 36]. De modo geral, o número de caminhos em um programa é proporcional a seu tamanho. Como os módulos são integrados em sistemas, toma-se inviável utilizar as técnicas de testes de estrutura. As técnicas de teste de caminho são, por conseguinte, utilizadas principalmente nos estágios de testes de unidade e testes de módulo [18]. Os testes de caminho não testam todas as possíveis combinações de todos os caminhos no programa, pois é difícil selecionar um conjunto de caminhos 30

31 que ofereça uma cobertura adequada dos possíveis defeitos [14]. Para quaisquer componentes, à parte aqueles muito triviais, sem loops, esse é um objetivo impossível. Existe um número infinito de possíveis combinações de caminhos em programas com loops. Os defeitos que se manifestam quando surgem combinações particulares de caminhos podem ainda estar presentes, muito embora todas as combinações de programas tenham sido executadas pelo menos uma vez [18]. O objetivo dos testes de estrutura é assegurar que cada caminho de programa independente seja executado pelo menos uma vez. Em termos de programa, isso significa exercitar uma ou mais novas condições. Os ramos verdadeiros e falsos de todas as condições têm de ser executados pelo menos uma vez [18] Testes de Unidade O teste de unidade é um tipo de teste de caixa branca que têm por objetivo verificar um elemento que possa ser logicamente tratado como uma unidade de implementação. Normalmente, os testes de unidade são feitos pelos próprios desenvolvedores. Em um sistema orientado a objetos as unidades geralmente são as classes. Em alguns casos, pode ser conveniente tratar como unidade um grupo de classes correlatas [14]. Os testes de unidade servem para testar as interfaces dos módulos, verificando se as informações fluem para dentro e para fora da unidade de programa que se encontra sob teste de forma correta. Testam também a estrutura de dados para se ter a garantia de que os dados armazendados temporariamente mantêm sua integridade durante todos os passos de execução de um algoritmo, além de examinar as condições de limite para confirmarem que o sistema funciona da forma esperada nos limites estabelecidos. Todos os caminhos independentes e os caminhos de tratamento de erros são testados pelo menos uma vez. São feitos também testes de fluxo de dados ao longo da interface de um módulo antes que qualquer outro teste seja iniciado. Se os dados não entrarem e saírem adequadamente, todos os demais testes serão discutíveis [36] Testes de Integração No nosso projeto, não fizemos teste de integração por termos usado um software já pronto. Porém, por se tratar de uma categoria de testes bem conhecida, estudada e utilizada, sempre presente nos livros e materiais que usamos, dedicamos uma seção para esse tipo de teste e suas abordagens sem, no entanto, nos preocuparmos em fazer um estudo tão detalhado. Os testes de integração têm por objetivo verificar as interfaces entre as partes de uma arquitetura de um sistema, testando se as unidades implementadas em cada iteração funcionam corretamente quando postas em funcionamento juntamente com as implementadas em iterações anteriores [14]. Eles devem ser desenvolvidos 31

32 a partir da especificação do sistema e começar assim que as versões de alguns dos componentes do sistema estejam disponíveis [18]. A principal dificuldade que surge nos testes de integração é localizar erros descobertos durante o processo. Há complexas iterações entre os componentes de sistema e, quando uma saída anômala é descoberta, pode ser difícil encontrar a origem do erro. O ideal para se localizar os erros seria sempre utilizar uma abordagem adicional para a integração e os testes do sistema. Inicialmente, é necessário integrar uma configuração mínima do sistema e testar esse sistema. Em seguida, são adicionados componentes a essa configuração mínima, que é testada depois de cada componente adicionado [18] Integração Big-Bang Segundo Paula Filho [14], esse tipo de abordagem é provavelmente o método de integração mais freqüente na prática. As unidades são testadas individualmente e depois integradas de uma só vez. Esse tipo de integração é o que requer menos esforço, mas geralmente o resultado é desastroso. Diagnosticar um erro nessa situação é bastante complexo, pois é difícil isolar as causas. À medida que os erros são corrigidos, outros erros são introduzidos, por causa da desorganização do processo Testes Top-down e Bottom-up As estratégias de teste top-down e bottom-up (Figura 4.3) refletem abordagens diferentes da integração de sistema. Na integração top-down, os componentes de alto nível de um sistema são integrados e testados antes que seus projetos e sua implementação tenham sido completados. Na integração bottom-up, os componentes de nível inferior são integrados e testados antes que os componentes de nível superior tenham sido desenvolvidos [18]. Na integração top-down, os testes iniciais são realizados com a unidade principal, e cada nova unidade introduzida adiciona funionalidade ao sistema. As unidades subordinadas precisam ser simuladas por stubs. No início da integração, para que o teste seja eficaz, são necessários stubs muito sofisticados. [14] Por outro lado, os testes bottom-up envolvem integrar e testar os módulos de nível inferior na hierarquia e, então, subir na hierarquia de módulos, até que o módulo final seja testado. Essa abordagem não requer que o projeto de arquitetura de sistema esteja completo, de modo que pode começar em um estágio inicial do processo de desenvolvimento. Ele pode ser utilizado quando o sistema reutiliza e modifica componentes de outros programas [18]. Existe ainda o teste de integração chamado sanduíche, que é uma mesclagem das duas abordagens, top-down e bottom-up, onde partes da hierarquia mais alta são construídas conjuntamente com as do nível inferior. 32

33 Figura 4.3: Testes de Integração Top-Down e Bottom-Up(Sommerville, 2003, p. 387) Testes de Sistema Os testes de sistema são diferentes dos testes de unidade e de integração. Nos testes de unidade geralmente o testador tem controle completo sobre o processo de teste, tendo liberdade para criar seus próprios dados de teste e executar os testes. Nos testes de integração o testador pode agir sozinho ou com uma pequena equipe de testes ou de desenvolvimento. O processo de teste de sistema é um processo mais amplo, onde não se verifica se o código implementa adequadamente o código, mas seu objetivo principal é verificar se o sistema faz o que cliente quer que ele faça, se ele contém as funcionalidades requeridas e as executa corretamente [22]. Cada autor classifica os testes de sistema da maneira que acha mais adequada. Pressman [36] divide os testes de sistema em quatro categorias, que são testes de recuperação, testes de segurança, testes de estresse e testes de desempenho. Já Pfleeger [22] os classifica como testes funcionais, testes de desempenho, testes de aceitação e testes de instalação. Independentemente da forma como os testes de sistema são classificados, eles são planejados para exercitar o sistema como um todo e verificar se o sistema está pronto para de ser usado para o propósito que foi criado. 33

34 4.4.9 Depuração A depuração não é teste, mas sempre ocorre como uma consequência do teste, portanto, é uma atividade que não consegue ser desacoplada do processo de testes. O processo de depuração inicia-se com a execução de um caso de teste. O processo de depuração tenta ligar o sintoma encontrado no teste à causa real do erro, levando assim à correção do mesmo [36] Testes de Regressão O código de um software sofrerá alterações ao longo de um projeto, para a correção dos defeitos detectados, ou por causa da evolução do desenho ao longo das iterações. Alterações em certas unidades podem causar modificações do comportamento de outras unidades já testadas, por causa de efeitos colaterais. Os testes de regressão verificam novamente as unidades já testadas, para checar se eles continuam funcionando de maneira apropriada após as alterações. Uma bateria de testes de regressão consiste em um conjunto selecionado de testes de boa cobertura, que é executado periodicamente, de forma automatizada [14]. Testes de regressão são muito importantes, e sempre devem ser feitos após a fase de depuração ou depois de uma atualização ou manutenção do software. Caso contrário, as causas dos erros inseridos nessas etapas podem ser difíceis de serem encontrados depois, podendo, em alguns casos, causar prejuízos incalculáveis para empresas e clientes [22] Smoke Tests Smoke Testing é uma verificação relativamente simples para ver se o programa funciona. É também conhecido como ad hoc testing, isto é, teste sem um plano formal de teste. Em muitos projetos, ele é realizado em complementação ao teste formal. Algumas vezes, se o teste ocorre muito cedo ou muito tarde no ciclo de desenvolvimento do software, este pode ser o único tipo de teste que pode ser feito. Uma prática comum em várias empresas de software, por exemplo a Microsoft, é a construção diária de uma versão e execução dos smoke tests nessa versão. Smoke Tests devem ser completos o bastante para que, se o software passar, a pessoa que está testando possa assumir que o produto é estável o bastante para ser testado mais completamente [35]. Neste capítulo apresentamos definições, fundamentos e diferentes tipos e abordagens de testes, sendo que alguns foram abordados neste projeto e outros são utilizados no processo de garantia da qualidade de alguns projetos analisados no Capítulo 6. 34

35 Capítulo 5 Processo de desenvolvimento em comunidades open source O presente capítulo faz um estudo sobre o processo de desenvolvimento em comunidades open source apresentando os motivos do sucesso deste modelo, além dos seus principais desafios. É feita também uma comparação com alguns modelos de desenvolvimento tradicionais, como o desenvolvimento em cascata e em espiral. 5.1 Processo de teste no desenvolvimento O processo de teste é dependente do modelo de desenvolvimento de software adotado por um projeto. Dentre os vários modelos de desenvolvimento, identificamos alguns que são mais conhecidos e bem estudados. Escolhemos 2 modelos, em cascata e em espiral, para dar uma breve introdução e usá-los na comparação com o modelo de desenvolvimento open source. A metodologia do desenvolvimento em cascata consiste em fases distintas, desde os requisitos à codificação. Os testes ocorrem em paralelo com o ciclo de vida do desenvolvimento, sendo um processo contínuo, começando cedo no ciclo de vida da aplicação, não apenas depois da fase de codificação. Os testes ocorrem fora do ambiente de desenvolvimento porque neste modelo existem requisitos bem definidos e é muito mais eficiente que uma equipe separada verifique esses requisitos. O plano de testes é o principal documento de teste de software. Nele são encontrados os objetivos do teste, o escopo, estratégia e detalhes do teste [42]. À medida que o sistema evolui, o plano de testes é refinado e casos de teste são criados. Um caso de teste é um conjunto específico de dados, scripts de testes e resultados esperados, que guia o testador durante um teste [42]. A Figura 5.1 mostra uma correspondência entre desenvolvimento da aplicação e atividades de teste. 35

36 Figura 5.1: Fases do Desenvolvimento versus Tipos de Testes(Lewis, 2000, p. 44) Durante a execução do teste, o processo é invertido e começa com teste de unidade. Testes de integração são executados e combinam pedaços de código de testes individuais e de unidade. Quando essa fase termina, o sistema é testado como um todo [42]. O desenvolvimento em espiral incentiva a cooperação entre o time de garantia de qualidade e de desenvolvimento. A base desse argumento é que, em um ambiente de desenvolvimento rápido, os requisitos podem ou não estar disponíveis, em níveis de detalhamento variáveis. Sem essa cooperação, a equipe de teste teria uma tarefa difícil de definir os critérios de teste, portanto, a única alternativa possível é que os dois trabalhem juntos. No desenvolvimento em espiral, um sistema inicial pequeno mas funcional é construído e rapidamente entregue, e então incrementado em uma série de iterações [42]. Teste em espiral é um processo de trabalho feito a partir de uma base, onde se constrói um sistema de maneira incremental. Ao chegar ao final de cada fase, os desenvolvedores reexaminam a estrutura inteira e a revisam. O método em espiral é representado pela figura de quatro fases principais do desenvolvimento do sistema planejamento/análise, modelagem, codificação e teste/entrega em quadrantes, como mostra a figura 5.2. As fases de teste são planejamento de teste, criação de caso de teste, desenvolvimento de teste, e execução/avaliação de teste, respectivamente [42]. Como falamos no início dessa seção, o processo de teste é diferente em cada modelo de desenvolvimento. Veremos a seguir que o modelo de desenvolvimento open source traz uma nova perpectiva sobre processo de teste e desenvolvimento, não ocorrendo da mesma maneira explanada nas referências acadêmicas da área. 36

37 Figura 5.2: Processo de Teste em Espiral(Lewis, 2000, p. 95) 5.2 Processo de teste em comunidades open source Zhao e Elbaum [37] fizeram uma pesquisa sobre como são feitos os testes na maioria dos projetos open source. Algumas conclusões que eles obtiveram foi que o software open source introduziu uma nova dimensão em desenvolvimento de software distribuído em larga escala, porém, mostraram que as capacidades potenciais desse modelo não podem ser exploradas em todos os cenários. Também descobriram que muitas das atividades de controle de qualidade nesse ambiente ainda estão evoluindo. Shmidt e Porter [4] listam alguns domínios em que o software open source pode não ser efetivo ou desejável: Domínios altamente verticais: Certos domínios, como softwares voltados para a Medicina ou planejamento de recursos de negócios, requerem conhecimento técnico altamente especializado e não são padronizados. Estudantes de graduação ou programadores independentes não tem conhecimento suficiente ou interesse para trabalhar em tais assuntos. Domínios altamente competitivos: Em alguns domínios, como sistemas de transações online, os incentivos financeiros são tão altos que desenvolvedores dessa área não têm motivação para tornarem seu trabalho disponível gratuitamente para seus competidores ou usuários finais. Domínios de segurança máxima: Em domínios como sistemas de comando e controle para defesa com mísseis, assuntos de segurança são primordiais e há leis nacionais de segurança que restringem a disseminação de certos tipos de software. 37

38 Domínios confidenciais: Em domínios como controle do processo de planejamento de energia nuclear ou controle de vôos da aviação civil existem procedimentos de certificação rígidos que devem ser seguidos para validar que o software é suficientemente robusto para operações de missões críticas. O desenvolvimento e processos de garantia da qualidade (QA) na maioria dos projetos open source atuais não possuem rigor suficiente para passar nesses testes de certificação. Apesar disso, Zhao e Elbaum provaram algumas suposições sobre o modelo e puderam quantificar essas afirmações. Uma das descobertas que eles conseguiram foi que a maioria dos projetos pesquisados era desenvolvida por grupos muito pequenos, de no máximo 5 integrantes. Em contrapartida, esses projetos têm geralmente grupos de usuários de mais de 50 pessoas. Isso torna clara a grande participação dos usuários no desenvolvimento do projeto. Outra curiosidade foi de que a maioria dos desenvolvedores eram pessoas experientes e que se dedicavam ao desenvolvimento open source em seu tempo livre. Segundo seus dados, apenas 12% eram patrocinados pelo empregador e 5% dedicavam-se somente a isso. Um outro aspecto avaliado pelos pesquisadores foi o uso de ferramentas e processos de gerência de configuração de software, como o CVS, por exemplo. Entre os projetos analisados, 75% utilizam ferramentas de gerência de configuração, dentre eles, 89% usam CVS. As porcentagens são similares em relação a ferramentas de monitoramento de erros (bug tracking). Mais de 61% usam ferramentas de monitoramento de erros, e a maioria hospeda tais ferramentas em sítios web do próprio projeto. Através da pesquisa comprovou-se também que a documentação não tem um papel muito importante em tais projetos. Segundo eles, 84% dos entrevistados preparam uma lista TODO, 62% constróem guias de instalação e configuração e 20% têm planos de lançamento de versões (incluindo datas e conteúdo). Os pesquisadores achavam que a fase de testes parecia ter uma importância menor em projetos open source, porém, 58% dos projetos gastaram mais de 20% do tempo na fase de testes, enquanto mais de 15% dos projetos gastou mais de 40% de seu tempo em testes. Para eles, isso confirma a existência de uma atividade de teste que consome recursos consideráveis, apesar de parte da responsabilidade pelo teste ser passada ao usuário. Com base no gráfico abaixo, percebe-se que o tempo gasto com testes em projetos de grande porte é menor do que em projetos de pequeno porte. Também perceberam que somente 48% dos projetos usam uma bateria de testes de referência para apoiar os testes. Para Zhao e Elbaum, isso é surpreendente porque a falta dessa base indica a provável ausência de testes de regressão, o que poderia prejudicar a habilidade em gerar múltiplas versões confiáveis em um 38

39 Figura 5.3: Gráfico de Tempo de Teste por Tamanho do Projeto(Zhao e Elbaum, 2003, p. 12) curto espaço de tempo, o que não ocorre. Os projetos open source colocam mais ênfase em testes de campo, onde são testadas a performance e a funcionalidade do software sob as condições em que ele será usado, e revisões dos usuários, tirando vantagem da vontade dos mesmos em experimentar um produto ainda não lapidado, mas gratuito. (Vixie, 1999 apud Zhao e Elbaum). Essa participação do usuário constitui uma das bases do modelo open source (Raymond, 1999 apud Zhao e Elbaum), mas até o momento os pesquisadores não tinham claras evidências sobre a efetividade ou eficiência desse processo. Eles descobriram que sugestões dos usuários geram mais de 20% das mudanças em quase 50% dos projetos. Também perceberam que em quase 20% dos projetos, os usuários descobriram de 20% a 40% dos erros, e 44% dos entrevistados responderam que os usuários acharam erros difíceis (que dificilmente seriam encontrados pelos desenvolvedores). Godfrey e Tu [33], em um artigo onde estudam a evolução do sistema operacional Linux, contam que no começo do trabalho, esperavam constatar que o Linux tivesse uma taxa de crescimento mais lenta, por ser um projeto muito grande e por seu modelo de desenvolvimento não ser planejado e gerenciado tão rigidamente quanto nos projetos comerciais. Para surpresa dos autores, o sistema apresenta um crescimento em uma taxa linear por muitos anos. Mais uma vez, essa característica de ampla participação dos usuários torna-se um diferencial importante para os projetos open source. Porém, para eles, uma evolução planejada, a fase de testes e manutenção podem ser prejudicadas em alguns casos, pois esse modelo encoraja a ampla colaboração mas não necessariamente uma reflexão cuidadosa e reorganização. Como eles explicam, a qualidade do código é mantida por massiva depuração acontecendo paralelamente em vez de testes planejados. Schmidt e Porter [4] declaram que manter essa integridade é um dos desafios dos projetos open source. Em seu artigo que fala de qualidade de software em tais projetos, os pesquisadores explicam que o processo de desenvolvimento open source surgiu como uma abordagem efetiva para reduzir o tempo de ciclos e diminuir custos de mo- 39

40 delagem, implementação e garantia de qualidade para certos tipos de software, particularmente softwares de infra-estrutura, como sistemas operacionais, compiladores e ferramentas de processamento de linguagem, editores e middleware de distribuição. 5.3 Motivos do sucesso do modelo de desenvolvimento open source De acordo com Schmidt e Porter [4], que estudaram o processo de desenvolvimento de software open source, antes de compreender como melhorar a qualidade e a performance de um software, é importante entender porque esse modelo funciona tanto no seu processo em si quanto para o usuário final. Pela perspectiva do usuário final, projetos open source de sucesso funcionam pelas seguintes razões: Custos reduzidos de aquisição do software: O software open source é distribuído sem cobrança de taxas de licença pelo uso daquele software, embora muitas empresas relacionadas com os projetos open source cobram um determinado valor por consultoria e suporte técnico, como por exemplo a Red Hat. Além disso, os projetos open source usam tipicamente meios de distribuição de baixo custo, como a Internet, de modo que os usuários possam acessar o código-fonte, os exemplos, os testes da regressão, e informações de como se dá o desenvolvimento de maneira rápida e barata. Grande diversidade e escala: Softwares open source bem escritos e bem configurados podem ser movidos facilmente a uma variedade heterogênea de sistemas operacionais e compiladores. Além disso, como o código fonte está disponível, os usuários finais têm liberdade para modificar e adaptar o código fonte original para corrigir erros ou para responder às oportunidades do mercado com maior agilidade. Facilidade de colaboração: O fato de ser open source promove o compartilhamento dos programas e das idéias entre membros das comunidades de tecnologia. Essas comunidades têm necessidades similares, porém possuem diferentes estratégias de criação e implementação dessas necessidades. Esse processo de troca de idéias antes de implementá-las chama-se crossfertilization, podendo levar a novas descobertas e conclusões que provavelmente não ocorreriam sem colaboração entre essas comunidades. De uma perspectiva do processo de software, projetos open source bem-sucedidos funcionam pelas seguintes razões: Divisão escalar de trabalho: tendo mais gente testando o código, os erros são identificados muito mais rapidamente do que tendo apenas algumas pessoas 40

41 realizando os testes. Uma equipe de testadores conseqüentemente encontrará geralmente muito mais erros do que uma equipe de 10 testadores. As atividades do QA melhoram também pois não requerem tanta comunicação interpersonal comparada com as atividades de desenvolvimento de software, particularmente as atividades de análise e modelagem de projeto. Respostas e sugestões rápidas vindas dos usuários: Uma razão para o sucesso de esforços de desenvolvimento open source bem organizados, tais como o Linux, é o retorno rápido entre os desenvolvedores e os usuários. Além disso, o uso de ferramentas poderosas de gerência de configuração via Internet, tais como o CVS, permite que os usuários fiquem sincronizados em tempo real com as atualizações fornecidos pelos desenvolvedores. Estratificação Invertida: Em muitas empresas, as pessoas que testam o software são colocadas numa posição inferior a quem desenvolveu o software. O modelo do desenvolvimento open source inverte essa estratificação pois, em muitos casos, as pessoas que testam também são ótimos desenvolvedores de software e usam suas habilidades consideráveis em depuração para eliminar erros quando encontram problemas com o software. Esse modelo possibilita a ascensão desses desenvolvedores de grande habilidade, que não ficariam satisfeitos de terem a função de testar software no modelo tradicional de desenvolvimento. Maior oportunidade para a análise e validação do software: As técnicas de desenvolvimento no modelo open source podem ajudar a melhorar a qualidade do software permitindo o uso de técnicas poderosas de análise e de validação, tais como o teste de caixa-preta e a checagem de modelo. As ferramentas são eficazes, pois podem instrumentar e analisar sistemas de larga escala onde código open source é usado em muitos componentes e camadas, como por exemplo, drivers de rede para o sistema operacional e até middlewares e os programas em si. Em geral, o processo de desenvolvimento de software onde o código é fechado e os processos de QA raramente conseguem alcançar os benefícios esboçados acima tão rapidamente ou tão barato quanto o modelo open source [4]. 5.4 Principais desafios dos projetos open source De acordo com Schmidt e Porter [4], embora os projetos open source obtêm um claro êxito em softwares de infra-estrutura, a experiência de trabalho dos mesmos em vários projetos open source de larga escala por mais de uma década mostrou que desenvolvedores dos projetos open source enfrentam os seguintes desafios: 1. Alto custo de manutenção e evolução associado a garantia da qualidade (QA): Em geral, os objetivos gerais e os requisitos de qualidade do software 41

42 open source são similares aos outros tipos de software (por exemplo, evitar a ruptura de funcionalidades que estavam presentes em versões passadas e não estão mais na atual) e manutenção da confiança. É difícil, entretanto, de se assegurar a qualidade do software open source, que é obtida exclusivamente do seguinte contexto em que ela é desenvolvida: Versões beta sendo lançadas freqüentemente: Um diferencial do modelo open source é o curto espaço de tempo entre os feedbacks dos usuários e as ações da equipe de desenvolvimento, o que tipicamente resulta em lançamento de versões beta várias vezes num único mês. Embora este cronograma satisfaça alguns usuários que recebem reparos de maneira rápida, muitos outros usuários podem se frustrar quando estes estão em busca de uma versão mais estável, com menos lançamento de versões betas. Independência da plataforma: outro diferencial do software open source é a sua independência quanto à plataforma. A manutenção da independência da plataforma, no entanto, pode gerar o trabalho de ter que se manter a base do código fonte do software open source inerte das alterações contínuas que são feitas no sistema operacional e nos compiladores. Suporte para muitas configurações em tempo de compilação e tempo de execução: A disponibilidade do software em projetos open source incentiva os colaboradores mais importantes a aumentar o número de opções de configuração do software em tempo de execução e tempo de compilação. Embora esta flexibilidade aumente a aplicabilidade do software para uma escala maior de casos de uso, ela pode também aumentar em magnitude exponencial os custos de QA devido ao grande número de combinações possíveis que devem ser testadas via testes de regressão. Além disso, os projetos open source trabalham freqüentemente com um orçamento de QA muito curto ou às vezes ausente devido à ausência de cobrança pelo uso do software, sendo portanto difícil manter um grande número de versões e variantes ao mesmo tempo. 2. Assegurar a coerência das propriedades gerais do sistema: A natureza descentralizada de muitos projetos open source torna difícil manter um look and feel comum, padronização das APIs comuns, e garantir uma semântica consistente quando diferentes componentes são integrados. Como projetos open source crescem de maneira natural, baseados em contribuições de uma parte de desenvolvedores e usuários, é necessário gastar grande parte do tempo e do trabalho para garantir uma integridade na arquitetura e uma padronização das contribuições vindas de membros dispersos da comunidade. O modelo de desenvolvimento open source apresenta características únicas, bem distintas do modelo tradicional, possuindo vantagens em certos aspectos e desvantagens em outros. Este estudo foi importante para o nosso trabalho para termos 42

43 uma visão crítica, obtendo uma maturidade para escolhermos as ferramentas com sucesso e também entender como se dá o processo da garantia da qualidade neste modelo. 43

44 Capítulo 6 Garantia de qualidade de importantes projetos de software livre Após termos feito o estudo teórico sobre o modelo de desenvolvimento open source, procuramos sedimentar essas informações pesquisando sobre alguns projetos relevantes e verificar como era realmente feita a fase de testes em tais projetos. Encontramos muita dificuldade em encontrar material sobre o assunto, e o que está escrito nesse capítulo deve-se na maior parte a uma pesquisa prática nos sítios oficiais do projeto, além de comunicações eletrônicas com desenvolvedores e participação em listas de discussão e fóruns relacionados aos projetos. A única excessão foi o projeto Apache, onde a maior parte do material foi obtida através de um artigo. 6.1 Projeto OpenOffice O Departamento de Garantia da Qualidade do OpenOffice.org disponibiliza documentação de testes e desenvolve aplicações de teste, que será explicado com maiores detalhes posteriormente. Caso algum usuário ou desenvolvedor seja um profundo conhecedor da área de QA, o projeto está aberto para a participação ativa desses usuários, trazendo novas idéias e métodos. Mais especificamente, há a citação da necessidade de pessoal para trabalhar com algumas demonstrações básicas de casos de teste, testes de regressão e documentação do plano de ação do Departamento de QA [32]. Analisando mais a fundo a ferramenta chamada IssueZilla, tem-se uma noção de como se dá o processo das alterações. Para cada aplicação do pacote openoffice (Writer, Calc, Impress) disponível para vários sistemas operacionais (Windows, Machintosh, Linux e Solaris) existe um link que nos leva a uma tabela que contém informações de cada alteração comitada por algum desenvolvedor. Esses 44

45 links existem para facilitar que a equipe de QA encontre alterações defeituosas que possuam o estado unconfirmed e necessitem de uma triagem ou acompanhamento. Os links que requerem uma triagem possuem o estado unconfirmed e não possuem a chave oooqa. Os links que precisam de um acompanhamento, mas que já foram previamente revisados, possuem as chaves oooqa e/ou needmoreinfo. A figura 6.1 ilustra a tabela de links contendo os defeitos, retirada do site. Figura 6.1: IssueZilla do Projeto OpenOffice (capturado de openoffice.org) Como se pode reparar no exemplo da figura 6.1, na coluna State, temos o estado unconfirmed e a sua descrição. Encontramos também, no mesmo sítio, alguns cenários de teste focados em ações específicas do sistema como testes de instalação do pacote, testes de impressão de documentos, testes de ações relacionadas à edição, entre outros, como pode ser visto na figura 6.2. Dentro de cada uma dessas seções existe um ou mais cenários de teste com uma descrição detalhada do objetivo do teste, dos requisitos do teste, dos passos que devem ser executados no teste, e do resultado esperado. Participando da lista de discussão e lendo o histórico da mesma em [31], também encontramos um link, que contêm 45

46 Figura 6.2: Smoke Tests do Projeto OpenOffice(capturado de openoffice.org) um framework de teste automatizado que provê o teste de quase toda a aplicação automaticamente, disponível para download em todas as plataformas que o OpenOffice é lançado. Juntamente com os scripts de teste, é necessário fazer o download de uma aplicação chamada VCL TestTool, que executa os scripts no OpenOffice. Tanto para os scripts quanto para a aplicação é provida documentação de uso [30]. 6.2 Projeto Gnome Linux Ao entrar no sítio do Projeto Gnome, logo na página inicial vemos a seguinte frase: Your GNOME needs you! The bug hunt season has opened. Ao se clicar na frase, fomos levado na página inicial de QA do projeto, chamada também de BugSquad. Basicamente, o projeto acompanha os erros do Gnome, tentando estar certos de que os maiores erros não passem desapercebidos pelos desenvolvedores. Salientase a importância da participação de toda comunidade na tentativa de se buscar erros através do uso do software. Para reportar algum erro encontrado, é usado sistema de acompanhamento de bug chamado Bugzilla, hospedado em 46

47 Para se efetuar uma correção de um erro relatado, existe todo um protocolo que deve ser seguido e esse processo é assistido de perto pela equipe que gerencia a parte de desenvolvimento do projeto. Em trocado com Christian Kirbach, membro da equipe de QA do projeto, o mesmo nos informou que Gnome Desktop usa uma aplicação do tipo bug-buddy (termo utilizado para se referir à aplicações do tipo Deseja reportar o problema? ) que é chamada quando o Gnome trava. O próprio Christian reconheceu a pouca eficiência desse tipo de feedback do usuário, que na maior parte dos casos escolhe a opção Não desejo reportar o problema. Nos informou também que estão trabalhando para melhorar essa aplicação e torná-la mais amigável ao usuário. Essa aplicação basicamente cria um registro no sistema Bugzilla hospedado em [9]. Christian também relatou que atualmente a equipe de QA percorre esses registros do Bugzilla e vai manualmente analisando cada um com algumas técnicas que ele exemplifica como: procurar por problemas que possuem mais de uma entrada, eliminando-as; dar algumas permissões de resposta a erros no Bugzilla aos membros do Bugsquad como: descrição do erro mal-feita, erro não relacionado ao Gnome, erro duplicado. Outra observação de grande valia foi quando Christian nos contou que a equipe de QA está deficiente em potencial humano para geração de críticas e feedbacks que sejam úteis e construtivos. No fim, ele escreve que a equipe de QA está jogado para escanteio se comparado com a equipe de QA do KDE - uma outra alternativa de interface gráfica para o GNU/Linux. 6.3 Projeto Mozilla A equipe de QA do projeto Mozilla é uma extensa rede de voluntários da comunidade na Internet e de diversos funcionários da empresa Mozilla.org. Essa equipe encontra bugs quando se descobre que a maneira como o navegador Mozilla exibe o conteúdo é diferente da exibição esperada, seguindo especificações determinadas pela W3C [8], IETF [17] e alguns contribuidores do projeto Mozilla. Quando esse bug é encontrado, este é relatado no Bugzilla e é dado o devido tratamento. Existem várias maneiras de se contribuir com o projeto, de acordo com as atividades que são desenvolvidas pela equipe de QA. No Bugzilla, pode-se: confirmar bugs que foram reportados mas não foram confirmados ainda, antes de se passar para os desenvolvedores; tentar relacionar o bug com alguma área específica da aplicação, pois eles precisam ser enviados para o lugar certo; treinamento de membros novos no uso do Bugzilla; olhar os registros com o estado qawanted e ver se a pessoa que está contribuindo pode ajudar; participar do Bug Day toda terça-feira na rede irc://irc.mozilla.org/bugs. Na parte de testes, existe uma atividade no projeto chamada SmokeTest Nightly 47

48 Builds, onde diariamente, aproximadamente às 02:00 GMT, a árvore de versionamento dos arquivos do projeto é fechado e é montada uma distribuição com aqueles arquivos, e utilizando-se esta distribuição, executa-se os casos de teste. O código deve passar pelos testes nas três plataformas:win32, Mac e GNU/Linux. Os Smoke Tests são divididos em categorias que são baseadas em tipos de ações que o usuário pode fazer como: instalar, gerenciar perfil, navegar, exercitar o uso dos plugins do browser, entre outros. Cada uma destas categorias possui vários casos de teste. Por exemplo, na categoria navegação pode-se testar a barra de pesquisa do browser como também as funções da seção Meus Favoritos. Uma lista com as categorias e cada um dos testes destas categorias é encontrada em [26]. Para o desenvolvimento e execução dos testes, utiliza-se uma ferramenta chamada Testrunner, encontrada em Além dos smoke tests, são desenvolvidos também testes funcionais básicos. Uma lista de todos os testes feitos para o Firefox e para o ThunderBird pode ser encontrada no sítio [27]. De acordo com o mesmo, a equipe de QA está desenvolvendo a feramenta Litmus, que substituirá o TestRunner. Ele irá além do TestRunner em alguns aspectos como uma ferramenta de busca e de relatórios, o que é fundamental para o trabalho de QA no Mozilla [29]. Outra ferramenta utilizada pela equipe de QA do Mozilla é o Talkback, uma aplicação do tipo bug-buddy, como explicado na seção 6.1, que é executado quando algum software do Mozilla trava. [29] Para auxiliar no desenvolvimento, eles utilizam algumas ferramentas de extrema importância, como: Tinderbox [28] que exibe graficamente a evolução de uma certa distribuição; o LXR [25], que examina o código-fonte; o Bonsai [24], que define melhor onde alterações foram feitas. Há a preocupação de aumentar a capacidade de teste da equipe de QA do Mozilla, e para isso eles estão constantemente investigando algumas ferramentas que auxiliam o teste automatizado, diminuindo assim os testes manuais feitos pelos testadores da equipe de QA [29]. 6.4 Projeto Apache Apache HTTP Server é um Servidor Web bem conhecido. É licenciado pela Open Source Initiatives, com sua Apache License 2.0. A primeira versão do Apache foi lançada em dezembro de Atualmente possui mais de 10 milhões de usuários. O projeto é conduzido pela Apache Foundation que possui a marca registrada do produto e o projeto possui múltiplos associados como por exemplo a IBM. De acordo com Koponen e Hotti [40], o projeto Apache utiliza CVS como o servidor de versionamento e o Bugzilla como o servidor de gerenciamento de 48

49 defeitos. De acordo com Netcraft, o Apache é utilizado por mais de 70% dos servidores web e ele possui em torno de 40 milhões de usuários. No projeto Apache mais de 3000 pessoas têm submetido problemas. Além disso, aproximadamente 400 pessoas submeteram código ao projeto. Os planos do projeto Apache são mostrados no sítio do projeto: Os planos mostram linhas gerais do projeto atualmente e são discutidos nas listas de s do projeto. De acordo com o mesmo artigo do parágrafo acima, no projeto Apache qualquer um dos usuários pode submeter modificações ou relatar algum defeito. Alguns dos problemas são atribuídos aos membros centrais do projeto. Estes possuem uma área especial no projeto que não é divulgada pra o restante da comunidade. Os desenvolvedores executam testes antes de submeter a modificação. Existe um grupo que guia as ações que devem ser tomadas e esse grupo é composto por membros centrais. Esse grupo-guia revisa todas as alterações antes de serem aceitas. Uma nova versão do software é lançada quando um membro central, que é designado para ser o gerente da versão, faz um pedido de versão e os outros desenvolvedores desse grupo central aceitam aquele pedido de versão. Caso aceito, são criados os pacotes a partir do sistema de gerenciamento de versão e são lançados os arquivos de instalação daquela versão. Mais especificamente sobre a interação que é feita entre os usuários que reportam os problemas e os desenvolvedores, Mockus et. al. [12] explicam que existem várias maneiras de se relatar algum problema ou propor alguma melhoria. Os pedidos de mudança são relatados na lista de discussão dos desenvolvedores (dev@httpd.apache.org), no sistema de gerência de problemas (BUGDB). A lista de discussão dos desenvolvedores é o local onde são discutidas novas funcionalidades e arquivos de reparo (patches) para erros. No BUGDB é onde os erros são relatados. Os pedidos de mudança que são enviados para a lista de discussão dos desenvolvedores são atendidos com uma prioridade maior. Quando o relator do problema é um membro da comunidade de desenvolvimento, o relato geralmente contêm informação suficiente para analisá-lo. Essas mensagens recebem a atenção de todos os desenvolvedores ativos naquele momento. Os pesquisadores seguem explicando que, quando os membros chegam a um consenso a respeito do problema ou da melhoria, o próximo passo é encontrar um membro para trabalhar naquele problema. Os desenvolvedores centrais tendem a trabalhar com partes de código que lhes são mais familiares. Alguns trabalham nas partes de código relacionado a serviços centrais do Apache enquanto outros trabalham em funcionalidades que eles próprios desenvolveram. A arquitetura do Apache é projetada para separar suas funcionalidades mais centrais, das outras, que estão localizadas em módulos que podem ser selecionados separadamente para compilação e configuração. Os desenvolvedores mais importantes adquirem uma propriedade de trecho de código implícita. Seguindo o trabalho de Mockus [12], depois de decidido o trabalho em um problema, o próximo passo é identificar qual a solução. Em muitos casos, a primeira dificuldade nesta etapa não é identificar uma solução, mas sim decidir qual dentre as várias possibilidades é a mais apropriada. Quando há várias soluções alterna- 49

50 tivas, o desenvolvedor geralmente envia as alternativas para a lista de s dos desenvolvedores para que haja feedbacks dos outros desenvolvedores antes de implementar a solução. Fato esse explicado no trabalho de Mockus [12] foi confirmado por nós em visita feita aos arquivos da lista de desenvolvimento do projeto. Em várias mensagens dessa lista encontramos discussões de diferentes soluções a respeito, por exemplo, de conceitos que foram discutidos em matérias do bacharelado como Sistemas Operacionais, como alternativas de criação de threads em processos, alternativas de gerências de processos como semáforo, mutex e na área de Engenharia de Software vimos a discussão de alguns padrões de arquitetura de software. Mais especificamente sobre o processo de teste após cada uma dessas alterações, o trabalho de Mockus [12] afirma que uma vez escolhida a solução, o desenvolvedor faz as mudanças em uma cópia local do código fonte e testa as mudanças localmente. Este nível de teste é em termos comparáveis ao teste de unidade, e talvez ao teste funcional no contexto de desenvolvimento comercial, embora a complexidade do teste depende da visão e da experiência do desenvolvedor. Não existe nenhum teste adicional (por exemplo teste de regressão, teste de sistema) requerido antes do lançamento da versão, embora a revisão de código seja necessária antes ou depois de feita a confirmação da alteração. Ainda de acordo com estudo de Mockus [12], após o teste de unidade, o próprio desenvolvedor faz a confirmação da alteração e posta a mesma à lista de desenvolvimento dos desenvolvedores para revisão. Geralmente, alterações feitas na versão estável do código necessita de revisão antes de ser feita a confirmação. Neste capítulo visitamos varíos sítios de alguns projetos que consideramos relevantes, verificando como se dá o processo de garantia da qualidade, com enfoque no processo de teste. Para complementação da pesquisa, também fizemos a leitura de alguns artigos que tratavam do assunto. 50

51 Capítulo 7 Automação de Testes Um software deve ser testado para ter-se a confiança de que o mesmo trabalhará como deve em seu ambiente pretendido. O teste de software precisa ser eficaz em encontrar defeitos, mas deve também ser eficiente, executando os testes tão rapidamente e barato quanto possível [10]. Para Fewster e Graham [10], automatizar os testes pode significativamente reduzir o esforço requerido para certos tipos de testes, ou aumentar significativamente o número de testes que podem ser feitos em tempo limitado. Uma estratégia madura de automação de testes possibilitará que testes sejam executados, por exemplo, durante a noite, ou fora do expediente de trabalho, em máquinas que naquele momento não estariam sendo usadas. Os testes automatizados são passíveis de repetição, usando exatamente as mesmas entradas, com o mesmo tempo de repetição, algo que não pode ser garantido com o teste manual. Até mesmo as menores alterações de manutenção que vierem a ser feitas no código do software, podem ser fácil e rapidamente testadas de novo. A automação elimina também muito trabalho braçal. Quanto mais entediante for a execução do teste, mais se recomenda a utilização de uma ferramenta para automação [10]. Uma abordagem referenciada não só por Fewster e Graham [10], mas também por Zallar [21], é a clara separação entre dois perfis de profissionais envolvidos com a atividade de teste. Primeiramente, existe o testador, que é a pessoa responsável por gerar os melhores casos de teste, ou seja, identificam o menor número de casos de teste necessário para encontrar o maior número de erros possível. O automatizador de testes é o profissional que constrói e mantém os artefatos associados ao uso de uma ferramenta de execução do teste. É importante salientar que os dois perfis não são excludentes, e sim complementares, pois os casos de teste que um bom testador gera serão utilizados como início do trabalho do automatizador do teste, que fará os scripts que automatizam a execução dos testes. Isso não quer dizer que testadores não possam ser bons automatizadores, mas que os dois perfis exercitam habilidades diferentes. Fewster e Graham concluem afirmando que a habilidade em testar não é somente assegurar-se de que os casos do teste encontrem uma proporção elevada dos defeitos, mas também de assegurar-se de 51

52 que os exemplos do teste estejam bem projetados para evitar custos excessivos. Eles explicam que muitas organizações ficam surpresas ao descobrir que é mais caro automatizar um teste do que executá-lo uma vez manualmente. Depois de executado várias vezes, o teste automatizado se torna mais econômico. Entretanto, os testes automatizados custam geralmente mais para serem criados e mantidos. Os autores salientam a importância da preocupação quanto à manutenção quando os testes são automatizados, pois, atualizar todo um conjunto automatizado de testes pode custar tanto, se não mais, do que o custo de executar todos os testes manualmente. E por fim, afirmam que é possível haver automação de boa ou má qualidade. É a habilidade do automatizador do teste que determina quão fácil será adicionar novos testes automatizados, se serão fáceis de serem mantidos, e finalmente os reais benefícios que a automação de teste fornecerá. 7.1 Categorias de ferramentas para automação de testes Para a elaboração desta seção lemos alguns autores, encontrando referências principalmente em dois autores, Fewster e Graham [10], e Pressman [36]. Seguimos principalmente a classificação dos primeiros, por ser um material mais completo e atualizado, além de ser um livro que trata especificamente de automação de testes, enquanto o livro do Pressman refere-se à Engenharia de Software como um todo. As ferramentas de gerência de teste incluem ferramentas para ajudar no planejamento do teste, mantendo-se a par de quais testes foram executados, e assim por diante. Esta categoria inclui também ferramentas para ajudar a mapear os testes em relação aos requisitos, modelos, e código, assim como ferramentas de rastreamento de defeitos [10]. Um exemplo de ferramenta que pode ser citada aqui é a ferramenta TestLink, que faz a gerência de testes, podendo ser encontrada em No mesmo sítio, pode-se ter acesso a uma versão de avaliação, não necessitando a instalação da mesma em um servidor pessoal. A figura 7.1 nos mostra a quantidade de informações que esta ferramenta pode centralizar. As ferramentas de análise estática analisam o código sem executá-lo. Este tipo de ferramenta detecta determinados tipos de defeito muito mais eficazmente e barato do que pode ser conseguido por todos os outros meios [10]. Temos também uma segunda categoria de ferramentas, que são as de análise dinâmica, que analisam a resposta do sistema quando o mesmo é exercitado por alguma ferramenta de execução. A partir daqui, as ferramentas se dividem em dois 52

53 Figura 7.1: TestLink Uma ferramenta open source de automação da gerência de testes grandes grupos, as ferramentas de testes estruturais, que precisam instrumentar de alguma maneira o código e as ferramentas de teste funcionais, que exercitam as funcionalidades do sistema. Entre as ferramentas de teste estrutural, destacam-se as ferramentas de cobertura, que avaliam quanto do software sob teste foi exercitado por um conjunto de testes. As ferramentas de cobertura são mais usadas geralmente no nível de teste de unidade. Por exemplo, um dos critérios de parada para o teste estrutural é a cobertura de caminhos, melhor explicado no Capítulo 4, na seção 4.4.5, freqüentemente exigida quando se testa sistemas de segurança crítica ou relacionados a segurança [10]. Os simuladores são ferramentas que permitem que partes de um sistema sejam testadas de maneira que não seria possível no mundo real. Por exemplo, os procedimentos em projetos de energia nuclear podem ser testados em um simulador [10]. Uma outra classe de ferramentas são as chamadas ferramentas de capacidade. Ferramentas de teste de performance medem o tempo utilizado por vários eventos. Por exemplo, podem medir tempos de resposta sob circunstâncias típicas ou de carga. As ferramentas de teste de carga criam um tráfego intenso no sistema. Este tipo de ferramenta pode ser usado para testar volumes de dados grandes e, também, um número grande de transações concorrentes [10]. Esse é um tipo de 53

54 ferramenta bastante útil no teste de aplicações para WEB, verificando a capacidade de processamento do servidor de aplicações. As ferramentas da execução e de comparação de teste permitem que os testes sejam executados automaticamente e seus resultados serem comparados com resultados previstos. Estas ferramentas são aplicáveis à execução do teste em qualquer nível: unidade, integração, sistema, ou teste de aceitação. As ferramentas de repetição de captura, também conhecidas como capture replay, são ferramentas de execução e comparação do teste. Este é o tipo mais popular de ferramenta de teste em uso, segundo os autores [10]. 7.2 A promessa da automação do teste Para Fewster e Graham [10], a automação de teste pode permitir que algumas tarefas de teste sejam executadas de maneira mais eficiente do que se estivessem sendo feitas manualmente. Segundo os autores, os benefícios são os seguintes: Execução de testes existentes (de regressão) em uma nova versão de um programa: esta é talvez a tarefa mais beneficiada pela automação, particularmente em um ambiente em que muitos programas são modificados freqüentemente. O esforço envolvido para executar um conjunto de testes de regressão deve ser mínimo, dado que os testes existem e foram automatizados para funcionar em uma versão mais adiantada do programa, portanto deve ser possível selecionar os testes e iniciar sua execução com apenas alguns minutos de esforço manual. Executar mais testes mais freqüentemente: Um benefício claro da automação é a habilidade de executar mais testes em menos tempo e conseqüentemente de tornar possível executá-los mais freqüentemente. Isto trará uma confiança maior no software. A maioria das pessoas supõe que executarão os mesmos testes mais rapidamente com automação. Na verdade, elas tendem a executar mais testes, e esses testes são executados mais freqüentemente. Executar testes que seriam difíceis ou impossíveis de fazer manualmente: Tentar executar um teste real de larga escala de um sistema online com mais ou menos 200 usuários pode ser impossível, mas a entrada de 200 usuários pode ser simulada usando ferramentas de testes automatizados. Ao se testar manualmente, os resultados previstos incluem tipicamente as coisas óbvias que são visíveis ao verificador. Entretanto, há atributos que devem ser testados que não são fáceis de se verificar manualmente. Por exemplo, um objeto gráfico de interface com o usuário (GUI) pode provocar algum evento que não produz nenhuma saída imediata. Uma ferramenta de execução de teste pode certificar-se de que o evento seja provocado, o que não seria possível de verificar sem usar uma ferramenta. 54

55 Otimizar o uso dos recursos: Automatizar tarefas braçais e entediantes, tais como repetidamente digitar as mesmas entradas do teste, gera uma exatidão maior assim como melhora o ânimo da equipe, além de deixar mais tempo livre para os testadores hábeis dedicarem mais esforço no projeto casos de teste melhores. Consistência e repetibilidade dos testes: Os testes que são repetidos automaticamente serão repetidos todas as vezes da mesma forma (pelo menos as entradas serão, as saídas podem diferir devido ao sincronismo, por exemplo). Isto dá um nível de consistência aos testes que é muito difícil de conseguir manualmente. Lançamento mais adiantado ao mercado: Um conjunto dos testes que tenha sido automatizado uma vez, pode ser repetido muito mais rapidamente do que seria manualmente, assim que o tempo de teste decorrido pode ser encurtado. Confiança aumentada: Sabendo que um conjunto extensivo de testes automatizados funcionou com sucesso, pode haver uma confiança maior que não haverá surpresas desagradáveis quando o sistema for liberado (sempre considerando que os testes que estão sendo executados são testes bons). 7.3 Problemas comuns em automação de teste Há um número de problemas que podem ser encontrados durante a tentativa de se automatizar testes. Segue abaixo os problemas mais frequentes quando se tenta aplicar a automação de testes [10]. Expectativas não realistas: Há uma tendência otimista sobre o que pode ser conseguido com a utilização de uma ferramenta nova. É da natureza humana esperar que alguma solução proposta finalmente resolva todos os problemas que tem-se experimentado anteriormente. Os vendedores enfatizam os benefícios e os sucessos, e podem subestimar a quantidade de esforço necessária para conseguir reais benefícios. O efeito do otimismo e da conversa de vendedor juntos criam expectativas não realistas. Prática de teste fraca: Se a prática utilizada no processo de teste for pobre, com testes mal organizados, documentação pequena ou inconsistente, e testes que não são muito bons em encontrar defeitos, automatizar teste não é uma idéia boa. É preferível antes melhorar a eficácia dos testes do que melhorar a velocidade de execução dos testes. Expectativa de que a automação dos testes encontrará muitos defeitos novos: É mais provável que um teste encontre um defeito na primeira vez que é executado. Se um teste já foi executado e passou, ao executar o mesmo teste outra vez, haverá muito menos chance de se encontrar um defeito 55

56 novo, a menos que o teste esteja exercitando o código que foi mudado ou que poderia ser afetado por uma mudança feita em uma parte diferente do software. Sentimento falso de segurança: Apenas porque um conjunto de testes funciona sem encontrar defeitos, não significa que não há nenhum defeito no software. Os testes podem estar incompletos, ou podem conter defeitos neles mesmos. Se os resultados previstos estão incorretos, testes automatizados simplesmente preservarão aqueles resultados errados indefinidamente. Manutenção de testes automatizados: Quando o software é mudado, frequentemente é necessário atualizar algum, senão todos os testes, para que possam ser postos em funcionamento com sucesso. Isto é particularmente verdadeiro para testes automatizados. O esforço de manutenção do teste foi o que prejudicou muitas iniciativas de automação do teste. Quando é preciso mais esforço para atualizar os testes do que reexecutá-los manualmente, a automação do teste deve ser abandonada. Problemas técnicos: As ferramentas comerciais da execução de teste são produtos de software. Como produtos de software, não são imunes aos defeitos ou problemas de suporte. A interação da ferramenta com outro software, ou suas próprias funcionalidades, podem ser um problema sério. O ambiente tecnológico muda tão rapidamente que é difícil as empresas atualizarem suas ferramentas na mesma velocidade. Muitas ferramentas parecem ideais no papel, mas simplesmente não funcionam em alguns ambientes. As ferramentas comerciais de teste são produtos grandes e complexos, e um conhecimento técnico detalhado é necessário para que se possa obter o melhor da ferramenta. O treinamento fornecido pelo vendedor ou pelo distribuidor é essencial para todos aqueles que usarão a ferramenta diretamente. Questões organizacionais: Automatizar testes não é um exercício trivial, e necessita de apoio da gerência e conseqüentemente gerar uma mudança na cultura da organização. Tempo deve ser alocado para a escolha de ferramentas, para o treinamento, para experimentar e aprender o que é melhor, e para promover o uso da ferramenta dentro da organização. 7.4 Limitações da automação de teste Fewster e Graham [10] ainda alertam sobre as limitações da automação dos testes de software: Os testes automatizados não substituem os testes manuais: Não é possível e nem desejável que todos os testes sejam automatizados. Sempre haverá atividades que serão mais fáceis de se realizar manualmente, ou que sejam impossíveis de serem tranformadas em testes automatizados. Além disso, 56

57 testes que são executados raramente ou que sejam modificados constantemente não compensam o esforço requerido para se automatizar. Testes manuais encontram mais defeitos do que testes automatizados: Para automatizar um caso de teste, geralmente temos que executar o teste manualmente na primeira vez para verificar se o caso de teste está correto. Geralmente os erros são encontrados na primeira vez em que os testes são executados. Os testes automatizados não encontram novos erros, na verdade eles são usados para executar os testes outras vezes. Testes manuais inspiram mais confiança em relação à qualidade dos testes: Os testes automatizados apenas comparam se os resultados obtidos correspondem aos resultados esperados. Por essa razão, o mais importante é garantir que esses resultados esperados tenham sido escolhidos a partir de um caso de teste de qualidade. A automação de testes pode limitar o desenvolvimento de software: Testes automatizados são mais frágeis que testes manuais, pois podem se tornar totalmente inaplicáveis devido a pequenas mudanças no software. Como criação e a manutenção de testes automatizados custam mais, mudanças no software podem ser desestimuladas por motivos econômicos. Através do exposto neste capítulo, podemos perceber que automação veio para otimizar a execução dos testes, porém, não é uma atividade mágica que resolverá todos os problemas da atividade de teste. Ela possui vantagens e limitações, portanto deve ser feito um estudo da viabilidade e do custo-benefício de sua utilização em cada projeto em questão. 57

58 Capítulo 8 Implementação Este capítulo descreve a parte de implementação do nosso projeto, onde mapeamos e implementamos as atividades que são pertinentes a um processo de teste, com enfoque na automação do mesmo. Descrevemos as estratégias, as decisões que tivemos que tomar, as dificuldades encontradas, escolhas de ferramentas, experiência no uso das mesmas. Também salientamos alguns pontos importantes que aconteceram nesta etapa através de exemplos de código e capturas de tela. 8.1 Aspectos do Software a ser Testado A geração dos artefatos do processo de teste e sua automação foram aplicadas no software de vendas implementado no primeiro semestre de 2005 durante a disciplina Programação Orientada a Objetos, pelo aluno Ricardo Marques Porto. A linguagem de programação utilizada na implementação do sistema foi Java. O SGBD usado foi o Microsoft Access. A ferramenta de desenvolvimento do software foi o Eclipse IDE. O software é fortemente modularizado, possuindo alguns padrões de projeto implementados, como o padrão MVC (Model View Controller) [23], padrão Comando [7] para os comandos de acesso ao banco de dados, padrão Singleton para controladora de persistência, o padrão Builder [6] para criação e ligacão entre os subsistemas e as camadas do software. Não explicaremos em maiores detalhes o funcionamento de cada um desses padrões de projeto por fugirem do escopo do projeto. Porém, temos o pleno conhecimento de que estes padrões facilitaram muito o esforço de teste. 58

59 8.1.1 Requisitos Funcionais O levantamento dos requisitos funcionais que o sistema desenvolvido na matéria deveria conter foi feito ao longo de todo o semestre baseando-se na especificação do trabalho fornecida pelo professor da disciplina. O amadurecimento e a melhor definição dos requisitos funcionais também foram definidos durante todo o período letivo. Mesmo assim, não havendo uma formalização no processo de levantamento de requisitos e geração de casos de uso, alguns requisitos funcionais e suas regras de negócio não foram totalmente definidos, gerando uma certa flexibilidade na implementação de cada aluno. Basicamente, o sistema trata do processo de vendas de produtos de uma empresa, onde os principais componentes são os usuários, divididos em clientes e administrador, produtos e pedidos. Os usuários devem ser autenticados para terem acesso às funcionalidades do sistema. Os clientes podem pesquisar o cadastro de produtos, fazer pedidos, e acompanhar a situação de seus pedidos. O administrador é responsável por processar os pedidos, cadastrar produtos e clientes no sistema. Utilizamos os requisitos funcionais para a criação dos casos de uso, onde mapeamos os vários cenários de execução do sistema. Para cada cenário foi criado um ou mais casos de teste, seguindo a estratégia presente em [20]. 8.2 Definição da Estratégia Inicialmente, modelamos um processo de teste que possibilitasse a aplicação das diversas ferramentas que nos propusemos a utilizar. Porém, como nosso objetivo não era cobrir todo o sistema com o nosso teste, a primeira decisão foi aplicá-lo a dois dos quatro subsistemas, possiblitando que aplicássemos todas as atividades de teste que tínhamos mapeado apenas nesses subsistemas. Caso viéssemos a aplicar as atividades nos subsistemas restantes seria apenas uma repetição que não acrescentaria conhecimentos novos, e por isso decidimos não fazê-lo. Baseando-nos nas leituras anteriores à implementação, vimos que a primeira fase de um processo de teste sistemático consiste em definir qual a estratégia de teste deverá ser seguida, pois existe uma gama muito grande de testes possíveis de se fazer em um sistema. Além disso, a possibilidade de combinação de diferentes tipos de teste entre si traz ainda mais alternativas a se seguir. Tentamos definir a estratégia mais adequada ao nosso caso. No início definimos os tipos de teste que iríamos implementar. Decidimos que faríamos tanto testes estáticos quanto dinâmicos. Nos testes estáticos, decidimos verificar a aderência aos padrões de codificação que definimos de forma automatizada e nos testes dinâmicos, implementamos testes estruturais de unidade e testes funcionais de sistema, também automatizados. Isso nos trouxe uma experiência na utilização 59

60 das ferramentas que automatizam diferentes tipos de testes. As seções seguintes, 8.2.1, e contém as explicações acerca de cada uma das nossas escolhas Teste Estrutural de Unidade Primeiramente enfocamos no teste estrutural das unidades e um grande esforço foi gasto na definição do que realmente seriam nossas unidades. Segundo definição fornecida em [43], os testes de unidade são um tipo de atividade que visa testar pequenas partes ou unidades do sistema. O alvo desse tipo de teste são os métodos dos objetos ou mesmo pequenos trechos de código. Assim, o objetivo é o de encontrar falhas de funcionamento dentro de uma pequena parte do sistema funcionando independentemente do todo. A partir daí, decidimos que nossas unidades seriam as classes que representavam os tipos básicos e as entidades do sistema. A seguir, tivemos que decidir qual seria o ponto de parada dos nossos testes estruturais. Decidimos escolher primeiro a ferramenta e pararíamos quando o critério mais rígido suportado por aquela ferramenta fosse alcançado. Essa prática nos possibilitou diminuir drasticamente o número de casos de teste para os testes de sistema, focando nos testes das funcionalidades do mesmo, sem uma grande preocupação com os formatos de dados de entrada que foram utilizados nos casos de teste Teste de Verificação de Aderência A justificativa para implementar teste de verificação de aderência ao padrão de codificação foi baseada em várias leituras, dentre elas a que consideramos mais importante foi a do artigo [15], onde alguns fatores crucias que justificam esta estratégia foram mapeados, como: Grande tempo gasto com manutenção; O fato de raramente um software ser mantido apenas pelo próprio autor durante todo o ciclo de vida do software; Padrões de codificação implicam em melhor legibilidade, possibilitando aos desenvolvedores entender o código de forma mais rápida e completa; Pensando a nível de organização, criação e adequação a um padrão, implica em uniformidade dos produtos de software produzidos pela empresa. O critério de parada para o teste de aderência ao padrão de codificação foi que 100% do código das classes estivessem adequados ao padrão, não sendo encontrado desvio algum. 60

61 8.2.3 Teste Funcional de Sistema A escolha dos testes de sistema foi baseada na necessidade de se testar se a funcionalidade implementada está de acordo com o que foi feito durante a especificação. Nosso critério de parada foi criar casos de teste de sistema para os possíveis cenários dos casos de uso e, quando possível, automatizá-los. 8.3 Projeto do Teste Escolha das Ferramentas O estudo feito no capítulo 5 e 6 nos trouxe uma visão crítica a respeito do fucionamento e da estrutura das comunidades open source, como também o mapeamento dos principais sítios que concentram projetos open source. Além de nos mostrar que os projetos e produtos de tais comunidades possuem acertos e erros, pontos fortes e pontos fracos. Isso nos trouxe a plena consciência dos riscos e do trabalho que teríamos ao abrir mão do uso de ferramentas proprietárias com um suporte e atualização contínuos, e usarmos ferramentas open source. Uma característica interessante dos projetos open source que lemos e foi descrita na seção 5.2, e também mais detalhadamente no artigo [4], foi a velocidade de atualização das ferramentas, tanto no conserto dos bugs quanto na incorporação de novas funcionalidades, pois dos dias que fizemos os primeiros acessos aos sítios e download das ferramentas para o dia que escrevemos este capítulo, muitas ferramentas já se encontravam em versão mais autalizada Critérios Analisados Devido ao fato de existir uma grande quantidade de ferramentas de automação de testes disponíveis na Internet, o ponto de partida foi escolher um portal que concentrasse ferramentas open source para os mais variados tipos de testes. Em comunicação pessoal via correio eletrônico com Roland Weber, um dos autores do artigo [34], que foi de grande valia para o nosso trabalho, este nos indicou o sítio como ponto de partida para a pesquisa das ferramentas. O próximo critério que escolhemos foi observar a quantidade de vezes que a ferramenta que se aplicava à nossa necessidade foi carregada, escolhendo assim as mais acessadas. Um outro critério fundamental foi a facilidade de instalação e manuseio das mesmas, sendo que em algumas vezes chegamos a obter a ferramenta e não tivemos êxito na sua instalação e utilização. 61

62 O último critério foi analisar o grau de atividade da comunidade envolvida com aquela ferramenta, feita através da consulta do sítio da ferramenta, da observação do número de participantes do projeto e da leitura de mensagens nos fóruns do sítio. Um fato interessante que encontramos nessas pesquisas foi o aviso na seção de notícias de que um projeto não estava mais em atividade e indicava outras ferramentas equivalentes desenvolvidas por outros projetos que poderiam ser utilizadas, fato esse observado no projeto da ferramenta de automação de teste funcional de sistema Pounder, que pode ser encontrada no sítio http: //pounder.sourceforge.net. Outro ponto que nos chamou muita atenção, sendo decisivo na escolha da ferramenta Abbot, foi a presença, no sítio da própria ferramenta, de relatórios de testes feitos com o código desta. Os relatórios podem ser acessados pelas URLs e Ferramentas Escolhidas Para a verificação de aderência ao padrão de codificação, escolhemos a ferramenta Checkstyle, versão 4.0.9, encontrada em Um ponto a se destacar nesta ferramenta foi a facilidade de instalação e também de execução do teste, onde basicamente o que fizemos foi o acesso a URL e seguimos os passos descritos na seção Download and Installation. Já para os testes estruturais de unidade utilizamos o framework JUnit, versão 4.1, encontrado em O projeto de desenvolvimento desta ferramenta preocupa-se em criar um framework bem flexível, onde ele mesmo implementa vários padrões que possibilitam essa flexibilidade, vide sourceforge.net/doc/cookstour/cookstour.htm. Outro ponto forte é a integração com outros frameworks de teste, vide extension/index.htm. Essa é uma ferramenta vastamente conhecida e referenciada em bibliografias relacionadas a práticas e automação de teste, vide e index.htm. Em conjunto com o JUnit, para o cálculo da porcentagem de código que foi acessado pelos testes estruturais, utilizamos duas ferramentas. A primeira foi o Cobertura, versão 1.8, encontrada em e que funciona independentemente da IDE Eclipse. Já a segunda foi o plugin da IDE Eclipse chamado Coverlipse, versão , encontrado em sourceforge.net/, que foi instalado similarmente à ferramenta CheckStyle. Um ponto forte que percebemos foi que quanto maior a integração da ferramenta com a IDE utilizada para o desenvolvimento, mais fácil é sua instalação e execução 62

63 dos testes. Um ponto fraco que percebemos quando esta integração ocorre é a dificuldade de se gerar relatórios de execução do teste de maneira independente da IDE, tendo muitas vezes que recorrer a outras ferramentas que geram relatórios em formatos independentes, como por exemplo no formato html. O Cobertura e o Coverlipse nos forneceram, em conjunto, três critérios de parada nos testes estruturais. O primeiro deles é o critério de cobertura de linhas de código, suportado por ambas as ferramentas, onde dinâmicamente são armazenadas as linhas de código por onde o teste estrutural está passando. Um exemplo de figura da ferramenta Coverlipse é a figura 8.1. Figura 8.1: Exemplo da ferramenta Coverlipse O segundo critério é a cobertura dos possíveis caminhos existentes no trecho de código que está sendo exercitado pelo teste. Esses caminhos são gerados por alguma instrução que provoca um salto na execução do código, como instruções do tipo if-else e while. Esse critério é suportado pelo Cobertura. A figura 8.2 se refere ao Cobertura. O terceiro critério é o chamado all-uses, onde é feita uma análise do fluxo de dados com os possíveis valores das variáveis durante a execução daquele código, gerando um grafo de fluxo de dados, onde nos nós do grafo é representado cada um dos possíveis valores daquela variável. Esse critério é suportado pela ferramenta Coverlipse. A última ferramenta, utilizada para a automação dos testes de sistema, foi o 63

64 Figura 8.2: Relatório da ferramenta Cobertura framework Abbot. Dentre as ferramentas que fazem teste de sistema, o Abbot utiliza a abordagem record-and-play, onde se grava as ações de movimento e clique do usuário na tela do sistema, guardando-se essas informações em um arquivo de script, para futuras execuções automáticas daquelas ações feita pelo usuário. A ferramenta é acompanhada por um editor de scritps, encapsulando a necessidade de se conhecer a linguagem destes scripts. Uma vez que o record esteja ligado, as ações capturadas pelo editor são automaticamente convertidas em instruções armazenadas neste script. O Abbot é encontrado em sourceforge.net/. A figura 8.3 é um exemplo do editor Costelo, presente na ferramenta Abbot e que nos auxiliou na gravação de scripts de teste Plano de Teste Elaboramos um Plano de Teste que foi baseado na norma IEEE 829 [2] para padrões de documentação de teste de software. Este contempla algumas seções do template de Plano de Teste sugerido pela norma, como: Objetos de Teste: identificando qual artefato sofrerá processo de teste; Objetivos do Teste: identificando qual objetivo de cada teste que será aplicado; 64

65 Figura 8.3: Exemplo de script gerado pelo editor do Abbot Tipos de Teste: identificando quais os tipos de teste e seus respectivos critétrios de parada; Recursos de Teste: identificando quais as pessoas e máquinas necessárias para a execução dos testes, bem como o cronograma de teste; Ferramentas de Teste e Automação: identificando a linguagem dos scripts e as ferramentas utilizadas; Roteiro de Execução: identificando os passos necessários para a execução de cada tipo de teste; Casos de Uso: referenciando os casos de uso do software; Casos de Teste: referenciando os casos de teste para cada tipo de teste. Por motivos de adequação da ferramenta, escrevemos o Plano de Teste utilizando o Microsoft Word, e ele se encontra no apêndice A. 65

66 8.4 Implementação dos Testes Testes Estrutural de Unidade A primeira atividade que fizemos durante a implementação dos testes de unidade foi a geração dos casos de teste. Uma vez que o objetivo do teste estrutural de unidade é alcançar o critério de cobertura estabelecido, encontramos dificuldade em separar as etapas de projeto, implementação e execução dos testes estruturais. Portanto o que fizemos foi desenvolver o script do JUnit que exercitava o código e, com as ferramentas de monitoramento de código ligada (Coverlipse e Cobertura), íamos executando o código e checando se o critério tinha sido alcançado. Simultaneamente atualizávamos o caso de teste, com as novas funções que acrescentávamos, permitindo que chegássemos cada vez mais perto do critério de parada. Esse processo iterativo era repetido até que os critérios de parada fossem alcançados. Todos os scripts de teste de unidade se encontram no pacote testesprojeto do código-fonte, no CD pertencente ao material do projeto Testes de Verificação de Aderência Para a implementação dos testes de verificação de aderência ao padrão de codificação, a primeira atividade que fizemos foi a instalação do plugin Checkstyle. Ele nos permite uma grande flexibilidade para definir diferentes padrões de codificação e também na edição dos padrões já prontos, tudo sendo feito via interface gráfica, não havendo necessidade de compreensão do formato do arquivo XML que define o padrão de codificação. A figura 8.4 nos fornece uma visão da interface gráfica da ferramenta CheckStyle. No pacote da ferramenta Checkstyle, são fornecidos alguns arquivos XML com padrões de codificação já definidos. Um arquivo contendo o padrão definido pela Sun, que pode ser acessado em e outro com um padrão intermediário entre o da Sun e o padrão de código gerado pela IDE Eclipse. Um exemplo do arquivo XML é exemplificado pela figura 8.5. Em seguida, fizemos uma prévia execução do Checkstyle, com o padrão intermediário, para que pudéssemos ter uma visão de como seria o padrão definido por nós. Em seguida, alteramos algumas configurações através da interface gráfica. Um exemplo de erro acusado pela ferramenta ao ser usado o arquivo sun_checks_eclipse.xml era variável x esconde um campo, onde não era aceito que atributos de método tivessem o mesmo nome de atributos da classe. Esse erro, bastante encontrado pelo CheckStyle,é uma prática comum entre os programadores, porém não apoiada pelo padrão de codificação definido pela Sun, e é exemplificado pela figura

67 Figura 8.4: Interface Gráfica de Configuração do CheckStyle Figura 8.5: Arquivo XML utilizado pelo Checkstyle, definindo o padrão de codificação 67

68 Figura 8.6: Exemplo de erro muito frequente encontrado pelo CheckStyle Testes Funcionais de Sistema Para os testes funcionais de sistema, a primeira atividade feita durante a implementação foi a geração dos casos de uso, pois na disciplina em que se desenvolveu o software testado não foi cobrada a criação de casos de uso para as funcionalidades do software. Fizemos uma busca por templates de casos de uso na internet e entre as leituras feitas e sítios encontrados, usamos um exemplo de seções que deveriam estar presentes no template de caso de uso no sítio developerworks/webservices/library/ws-tip-docusecase.html. Seguimos também algumas dicas de boas práticas que nos auxiliaram na geração de casos de uso consistentes, encontradas em java/library/ws-tip-uml2.html. Neste momento percebemos a importância de uma especificação de requisitos completa e bem estruturada para possibilitar a criação do caso de uso. Para o escopo da disciplina, a especificação fornecida pelo professor foi suficiente, porém para um processo mais formal de geração de casos de uso, esta não estava em um nível de detalhamento satisfatório. A completude na compreensão dos requisitos funcionais somente foi possibilitada pelo fato dos integrantes do projeto final terem cursado a disciplina em que o software foi desenvolvido. Nos casos de uso, mapeamos os cenários de ação para cada caso de uso. Os casos de uso encontramse referenciados no Plano de Teste. A figura 8.7 nos mostra um exemplo de caso de uso, com os cenários mapeados. Com os casos de uso finalizados, começamos a criação dos casos de teste, ma- 68

69 Figura 8.7: Caso de Uso UC01 peando um ou mais casos de teste para cada cenário do caso de uso. Ao todo, foram criados 6 casos de uso, descrevendo as principais funcionalidades dos dois subsistemas, autenticacao e usuario, e 43 casos de teste, todos referenciados no Plano de Teste (Apêndice A). A figura 8.8 nos mostra um exemplo de caso de teste desenvolvido por nós. Com os casos de teste de sistema prontos, começamos a gravar os scripts da ferramenta Abbot. O Abbot é uma ferramenta de instalação bem simples, pois ela se compõe de um pacote.jar, sendo invocado diretamente pela linha de comando, através do comando java -jar lib/abbot.jar. Encontramos alguns pequenos problemas com a ferramenta, que algumas vezes se perdia com as referências de botões e telas que estavam sendo executadas no momento da gravação do script. Por exemplo, toda vez que havia a transição de uma tela para outra do sistema de vendas, o comando para ativação da gravação deveria ser ativado. Algumas vezes também a ferramenta gravava no script ações que não tínhamos feito. Isso nos gerou grande repetição de trabalho na gravação das ações presentes em cada caso de teste, sendo que em alguns casos, onde havia muitos passos, tivemos que repetir várias vezes a gravação para que conseguíssemos um script sem problemas e que refletia realmente os passos descritos no caso de teste. A figura 8.9 nos mostra como é o formato do script que automatiza o caso de teste TC31. Identificamos na prática a presença dos dois perfis de pessoas envolvidas com o teste, mencionados no início do Capítulo 7. O Hugo apresentou mais habilidade na automação dos testes e a Carla teve mais afinidade com a etapa de criação 69

70 Figura 8.8: Caso de Teste TC03 Figura 8.9: Script de Automação do Caso de Teste TC31 70