Adaptando o RUP para Análise de Cobertura de Código

ADAPTANDO O RUP PARA ANÁLISE DE COBERTURA DE CÓDIGO Elifrancis Rodrigues Soares Centro de Informática – Universidade Federal de Pernambuco (UFPE) Recife, PE – Brasil [email protected]

Alexandre Marcos Lins Vasconcelos Centro de Informática – Universidade Federal de Pernambuco (UFPE) Recife, PE – Brasil [email protected]

RESUMO Teste é uma atividade muito importante no processo de desenvolvimento de software, entretanto, é uma atividade cara, uma vez que ela consome uma parte considerável dos recursos de um projeto de desenvolvimento de software. Um problema encontrado na maioria dos processos de desenvolvimento de software é a ausência de uma maneira de se avaliar a efetividade dos casos de teste de unidade, que são executados no código desenvolvido. Uma possível solução para este problema é realizar testes de cobertura de código e obter métricas sobre a cobertura do conjunto de testes de unidade executados. O presente artigo descreve um processo de desenvolvimento de código com suporte a análise de cobertura de código. O processo proposto é inspirado do RUP (Rational Unified Process), no qual foram estendidos alguns fluxos para atender aos objetivos da técnica de cobertura de código. PALAVRAS-CHAVE Processo de desenvolvimento de software, Qualidade de software, Teste de software, Cobertura de código.

1. INTRODUÇÃO O desenvolvimento de software envolve varias atividades na sua produção, em que pode haver falhas humanas na realização de suas tarefas. Essas falhas podem ocorrer no inicio do processo, em que os objetivos podem ser elaborados de forma errada ou especificados imperfeitamente. Testar é uma atividade muito importante em um processo de desenvolvimento de software. Ajuda a administrar riscos de projeto e a melhorar a qualidade do software, que é produzido, evitando assim falhas e erros do programa durante o desenvolvimento do software. Mas testar é uma atividade muito cara e pode consumir uma quantia considerável dos recursos de projeto. Assim, o projeto de teste deve ser bem planejado e analisado durante o processo inteiro, tornando-o mais eficiente e com menor custo. Teste de software é um processo, ou umas seqüências de processos, projetado para garantir que o código do computador faça o que foi projetado. Software deve ser previsível e consistente, não oferecendo nenhuma surpresa aos usuários. (MYERS, 2004) Um problema que pode ser encontrado, no processo de desenvolvimento de software, é a ausência de uma medida quantitativa da qualidade dos casos de teste produzidos, porque, embora inspeções e revisões sejam extremamente importantes, não são muito úteis para medir a efetividade de um conjunto de testes que foi produzido, as inspeções têm uma análise pontual no artefato a ser inspecionado, verificando apenas o padrão do código, a lógica e os comentários. Uma aproximação usada, para obter essas medidas quantitativas, é adotar análise de cobertura de código no processo de desenvolvimento de código, para os testes de unidade elaborados da organização. Neste caso, as medidas serão obtidas enquanto os testes de unidade são executados. Apesar do rigor na criação de casos de teste de unidade, não é possível garantir que eles cubram uma parte significativa do código a ser testado. Como uma conseqüência, bugs podem não ser encontrados pelo processo de teste de unidade, sendo localizados apenas em fases posteriores de testes. Pela qualidade de seus produtos algumas organizações têm intensificado o trabalho de pesquisa na área de análise da cobertura de código.

Comunicações

I Simpósio Brasileiro de Testes de Software, Novembro de 2006

19 - 37

Neste trabalho, propomos um processo de desenvolvimento de software, Code Coverage Process, que tem como objetivo definir as atividades, responsáveis e artefatos gerados para implementação do código tendo como suporte a análise de cobertura de código. Além disto, por ser inspirado no RUP, o qual é um processo bastante conhecido e consolidado, será de fácil entendimento. O processo proposto foi desenvolvido no Test Research Project, um projeto de pesquisa fruto de uma parceria entre o Centro de Informática da UFPE e o Motorola Brazil Test Center (BTC), a intenção deste projeto é desenvolver pesquisas junto ao processo de desenvolvimento e aplicações de testes aos produtos da Motorola. Como produto destas pesquisas a parceria pretende identificar possíveis pontos de melhoria ou investimentos no processo. O objetivo geral do BTC é contribuir com todo o processo de testes da Motorola. Além desta seção de introdução, este artigo é composto por outras sete seções, descrito brevemente a seguir: A seção 2 descreve sobre processo e testes de software. A seção 3 descreve definições e alguns tipos de análise de cobertura de código. A seção 4 menciona trabalhos relacionados sobre análise de cobertura de código. A seção 5 descreve sobre o Rational Unified Process (RUP), no qual serviu de inspiração para o processo proposto. A seção 6 descreve o Code Coverage Process, apresentando as atividades, artefatos e responsáveis, bem como o detalhamento dos fluxos adaptados do RUP. A seção 7 descreve o estudo de caso realizado, dificuldades encontradas, lições apreendidas e os resultados obtidos. A seção 8 descreve sobre a análise critica do processo proposto. A seção 9 descreve as considerações finais do trabalho realizado e os trabalhos futuros.

2. PROCESSO E TESTE DE SOFTWARE Processo de software é um conjunto de etapas, formados por atividades, procedimentos e práticas utilizadas para atingir um determinado objetivo. Geralmente este objetivo está associado a um ou mais resultados e ou produtos derivado da execução do processo. Um processo de desenvolvimento define o fluxo das atividades, os artefatos e os envolvidos na realização do trabalho. Segundo Conallen (2000). O processo de desenvolvimento de software possui os seguintes objetivos: • Prover direção sobre a ordem das atividades do time; • Especificar quais artefatos deve ser desenvolvido; • Direcionar as tarefas de desenvolvedores e do time como um todo; • Oferecer critérios para monitorar os produtos do projeto e das atividades. O processo de desenvolvimento de software envolve uma série de atividades nas quais, apesar das técnicas, métodos e ferramentas empregados, erros no produto ainda podem ocorrer. Atividades agregadas sob o nome de Garantia de Qualidade de Software têm sido introduzidas ao longo de todo o processo de desenvolvimento, entre elas atividades de VV&T – Verificação, Validação e Teste, com o objetivo de minimizar a ocorrência de erros e riscos associados. (MALDONADO, 2000) O processo de teste tem como objetivo criar testes para revelar a presença de erros. Ele define como os testes serão planejados e executados através de atividades e passos e quando serão executados. Quando o processo é bem controlado e planejado, exige um menor esforço e tem maior eficácia. Temos dois tipos de abordagem de testes de software: A funcional (“Caixa Preta”) e a Estrutural (“Caixa Branca”). A primeira, os testes são gerados com base nos requisitos coletados com os usuários, em que é feita uma análise entre os dados de entrada e de saída. Na segunda abordagem, os testes são gerados a partir de uma análise dos caminhos lógicos possíveis de serem executados, de modo a conhecer o funcionamento interno dos componentes do software. O processo apresentado neste trabalho utiliza a abordagem estrutural, no qual irá se trabalhar com os testes de unidade e de integração, que tem como ênfase o esforço na verificação da menor unidade do projeto de software, o módulo. Essa abordagem é realizada para melhorar a qualidade do software, reduzindo o custo de defeitos encontrados. O objetivo central é testar a estrutura interna (lógica e fluxo de dados) e comportamento. Podemos utilizar na analise de cobertura de código, com um outro tipo de teste de software, teste de integração, que irá testar a interface entre as unidades integradas, sendo que para o nosso estudo, utilizaremos apenas o primeiro tipo apresentado, pois consideramos como uma etapa fundamental no projeto de software. O teste de unidade concentra esforços na menor unidade do projeto de software, ou seja, procura identificar erros de lógica e de implementação em cada módulo do software, separadamente. (MALDONADO, 2000)

Comunicações

I Simpósio Brasileiro de Testes de Software, Novembro de 2006

20

Segundo Andy Hunt e Dave Thomas (2003), teste de unidade é um código escrito por um desenvolvedor que exercita uma área muito pequena, especifica da funcionalidade do código a ser testado. Por exemplo, você poderia acrescentar um valor grande numa lista ordenada, então confirmaria se este valor aparece realmente no termino da lista. O teste de integração testa a interface entre as unidades integradas. É uma técnica sistemática, para construção da estrutura do programa, realizando, ao mesmo tempo, testes para descobrir erros associados a interfaces. Segundo Elfriede Dustin (2001), teste de unidade e de integração é fundamental para a entrega de um produto de software de qualidade, entretanto são poucos utilizados, ou executados de maneira superficial. Se teste de unidade for realizado corretamente, as fases de testes posteriores serão mais bem sucedidas. Para realizar teste de unidade estruturado e repetível, programa de software de teste de unidade deve ser desenvolvido, antes ou paralelamente com o desenvolvimento do software.

3. ANÁLISE DE COBERTURA DE CÓDIGO A análise de cobertura do código é um tipo de técnica usada em teste de caixa-branca, cujo objetivo é verificar como o conjunto de testes exercita partes do código. Portanto, é usada para verificar a qualidade do conjunto de testes e não a qualidade do produto real. Cobertura pode ser usada para medir a perfeição do conjunto de testes (isto é, teste criado) ou dos testes que são executados atualmente. Nós podemos usar cobertura como uma medida de efetividade de teste porque nós subscrevemos à filosofia que um caso de teste é bom se acha um bug ou demonstra que uma função particular trabalha corretamente. (CRAIG, 2002) A cobertura de código é usada principalmente na fase de teste de unidade e integração, no qual requer a cobertura dos caminhos possíveis dentro de cada unidade do programa. As vantagens de se usar cobertura de código dentro do processo de desenvolvimento são: • Ajuda a administrar riscos, pois fornece dados precisos referentes à cobertura do código, mediante a execução dos testes de unidade, fazendo com que as possíveis falhas nas partes em que o código não foi testado, não sejam encontradas em fases posteriores; • fornece informação referente a casos de testes que deveria existir para se ter uma cobertura satisfatoriamente ou casos de testes redundantes; • suporta a garantia do processo resultando na sua melhoria, pois as falhas que deveriam ser encontradas na fase de testes de unidade não serão passadas para as demais fases de testes. Existem diversos tipos de técnicas de cobertura de código, iremos apresentar algumas: Statement Coverage: requer a execução de cada linha do código ao menos uma única vez. É a medida mais simples de cobertura, mas é também a mais fraca, porque é insensível às estruturas de fluxo do controle e operadores lógicos. A statement coverage considera as estruturas do loop ao menos uma vez, como também para loops do-while. “É uma medida simples, no qual registra quais linhas de código foram executadas. Se uma linha nunca foi executada, é uma aposta segura que você não capturou qualquer bugs escondido no local.” (MARICK, 1997) Condition Coverage: os casos de teste são escritos para assegurar que cada condição em uma decisão assume pelo menos uma vez todos os possíveis resultados (LEWIS, 2000). Avalia as sub-expressões independentemente e garante que toda condição dentro de uma decisão está coberta. Function Coverage: verifica se cada função ou procedimento é invocado. É útil durante testes preliminares para assegurar ao menos alguma cobertura em todas as áreas do software. Teste superficial encontra deficiências brutas em um suíte de teste rapidamente. (CORNETT, 2004) Path Coverage: relata se cada um dos trajetos possíveis em cada função foi seguido. Um caminho é uma seqüência original do ramo de entrada da função à saída. (CORNETT, 2004) Segundo Hong Zhu (1997), teste de software é freqüentemente dirigido a descobrimento de falhas no software. Um modo para medir como bem este objetivo foi alcançado é instalar algumas falhas artificiais no programa e conferir se elas são descobertas pelo teste. Um programa com uma falha instalada é chamado de mutante do programa original. Avaliação de Cobertura de Código é o problema de identificar as partes de um programa que não executou em um ou mais execuções de um programa. Desenvolvedores e testadores usam cobertura de código para assegurar que todo ou substancialmente todas as linhas de um programa foram executados pelo menos uma vez durante o processo de teste. Medidas cobertura de código são importantes para testar e validar código durante desenvolvimento e porting de novas plataformas. (TIKIR, 2002) Segundo Rick D. Craig e Stefan P. Jaskiel, no livro Systematic Software Testing (2002), os pontos fracos e fortes de se ter medidas de cobertura de código são os seguintes:

Comunicações

I Simpósio Brasileiro de Testes de Software, Novembro de 2006

21

•

•

Ponto fraco é porque todo o código que foi executado não assegura ao desenvolvedor ou testador que o código faz o que é suposto que faça. Quer dizer, enquanto assegurando que todo o código foi exercitado sobre o teste, não garante que atende ao cliente, requisitos, e necessidades do projeto. Ponto forte é que medidas de cobertura de código forneceram um modo para determinar se e como bem os testes de unidade foram concluídos com sucesso.

4. TRABALHOS RELACIONADOS Alguns estudos foram realizados referentes à aplicação de análise de cobertura de código em projetos de desenvolvimento de software, alguns se referem às dificuldades em utilizar analise de cobertura de código em desenvolvimentos de software em grande escala, como em Kim (2003) que descreve os seguintes pontos: que a analise de grandes sistemas de software industriais é muito cara. A instrumentação do código fonte é necessária, podendo ser feita com alguns módulos, mas em grande escala consome muito tempo; o ciclo de desenvolvimento moderno de software está sendo mais curto para análise de cobertura enquanto as múltiplas entregas estão sendo realizadas devido ao desenvolvimento simultâneo. Um dos grandes problemas que ocorre em não utilizar a análise de cobertura é que maior parte da comunidade a considera como uma prática que adiciona um custo extra que não obtém retorno de investimento. Segundo Gokhale (2005), Teste de software é um processo caro e consome um-terço a um-meio aproximadamente dos custos de desenvolvimento de software. No seu trabalho são mostrados alguns critérios e forma de se avaliar casos de teste. Os critérios baseados em código são frequentemente chamados de baseados em caminho, eles tentam projetar casos de teste que exercitam pelo menos uma vez todos os caminhos ao longo do controle gráfico do fluxo do programa. Em fluxo de dados baseado em testes, o modelo gráfico é escrito com informações sobre como as variáveis do programa são definidas e usadas, e um caso de teste é apontado a exercitar como um valor designado a uma variável usada ao longo de diferentes de controle de fluxos. No trabalho realizado por Elbaum (2001), é investigado o impacto nas informações provenientes da cobertura de código perante a evolução do software, são apresentados dois estudos empíricos. No primeiro é executado um estudo de caso em uma aplicação, que possui varias versões e conjunto de testes existentes. No segundo estudo, é executada uma experiência controlada na qual são realizadas simulações de mudanças no software.

5. RATIONAL UNIFIELD PROCESS (RUP) É um conjunto de atividades a serem realizadas para produzir ou evoluir um software. Baseado em boas práticas de desenvolvimento. É um framework para processos, basta instancia-lo e definir padrões e guias específicos para a realidade de cada projeto. Baseia-se no desenvolvimento iterativo e incremental, guiado por caso (use cases), baseado na arquitetura do sistema e orientado a objetos. O RUP é uma metodologia genérica que pode ser utilizada para desenvolvimento de sistemas em diversas áreas de aplicação. “O Rational Unified Process captura muitas das melhores práticas em desenvolvimento de software e os apresenta em uma forma apropriada que é satisfatória para uma gama extensa de projetos e organizações.” (KRUCHTEN, 2003) O Code Coverage Process é inspirado no Rational Unified Process e usa a modelagem SPEM (Software Process Engineering Metamodel) [OMG, 2005] para representar seus artefatos e atividades. O RUP foi escolhido devido à sua consolidação perante a comunidade de software e por ser bastante utilizado, será de fácil entendimento, podendo ser utilizado por qualquer organização de desenvolvimento de software. O propósito é estender alguns fluxos do RUP, aqueles que irão ser envolvidos com as novas atividades e os artefatos que irão surgir com a realização do processo proposto. O processo proposto tem como objetivo definir as atividades, responsáveis e artefatos gerados para implementação do código tendo como suporte a análise de cobertura de código. Além disto, por ser inspirado em um processo bastante conhecido e consolidado, será de fácil entendimento. Na elaboração do processo, identificamos quais seriam os fluxos do RUP, no qual teríamos que inserir novas atividades ou adaptar as atividades existentes no processo para utilização do Code Coverage Process. Os Fluxos que serão relacionados às atividades de cobertura de código estão na figura 1.

Comunicações

I Simpósio Brasileiro de Testes de Software, Novembro de 2006

22

Figura 1. Fluxos estendido para o Code Coverage Process

O Fluxo de Implementação foi estendido porque é onde ocorre a codificação do software, geração e execução de testes de unidade. Devido a isto uma análise de cobertura é necessária, a fim de melhorar a qualidade dos testes e verificação da cobertura do código. O Fluxo de Gerenciamento de Configuração e Mudança foi estendido, devido a novos artefatos que serão incorporados e alguns artefatos, já existentes, terão que ser disponibilizados para o uso do processo. A extensão do Fluxo de Gerenciamento de Projeto foi necessária pelo fato que todo o processo terá que ser monitorado e controlado pelo gerente de projeto, para controle das métricas de cobertura do código serem inseridas durante o desenvolvimento do produto e dos testes elaborados.

5.1 Medição de Cobertura de Código no RUP “A medição da Qualidade, seja do produto ou do processo, requer a coleta e análise de informações, normalmente, especificadas em termos de medições e métricas. As medições são feitas basicamente para obter controle de um projeto e gerenciá-lo.” (KRUCHTEN, 2003) As métricas exigem critérios para identificar e determinar o grau ou o nível em que se atinge qualidade aceitável. O nível de qualidade aceitável é negociável e variável, e precisa ser determinado e estabelecido desde o início do ciclo de vida do desenvolvimento. Por exemplo, nas iterações iniciais, é aceitável um número grande de defeitos no aplicativo, mas não de defeitos na arquitetura. Nas iterações posteriores, apenas defeitos estéticos são aceitáveis no aplicativo. “A qualidade é uma medida de confiabilidade, de estabilidade e de desempenho do objetivo do teste (sistema ou aplicativo em teste). Ela se baseia na avaliação dos resultados do teste e na análise das solicitações de mudança (defeitos) identificadas durante o teste”.(KRUCHTEN, 2003) O RUP define cobertura como a medida da abrangência do teste, expressa pela cobertura dos requisitos e casos de teste ou pela cobertura do código executado. As medidas que o RUP utiliza para medição da qualidade são: cobertura de teste baseada em requisitos e em códigos. A cobertura de teste é qualquer medida de abrangência relacionada a um requisito (baseada em requisitos) ou a um critério de design/implementação do código (baseada em códigos), como a verificação de casos de uso (baseada em requisitos) ou a execução de todas as linhas de código (baseada em códigos). O RUP não especifica em detalhes as atividades ligadas à cobertura de código, bem como não menciona a importância de se ter uma medida que avalia a eficácia dos testes de unidade produzidos no desenvolvimento do código.

6. CODE COVERAGE PROCESS Diante da importância que os testes têm em todo o ciclo de vida de desenvolvimento de software, o processo proposto visa apresentar uma solução de inserir novas atividades dentro de um processo de desenvolvimento de software, sem que aconteça um impacto negativo em relação à execução das atividades existente no processo atual da organização. A maior contribuição do processo é a obtenção de maior qualidade dos casos de testes de unidade produzidos, reduzindo tempo na elaboração de casos de testes, na redução de casos de testes redundantes e na criação de novos casos de testes de unidade. Trata-se de um processo que insere atividades de análise de cobertura de código dentro de um processo desenvolvimento com fases, disciplinas e artefatos, tendo como preocupação a análise de cobertura de código. Resultando numa melhoria na qualidade do software, reduzindo tempo na elaboração de casos de testes de unidade, na redução de casos de testes redundantes e na criação de novos casos de testes de unidade para uma maior cobertura do código. Vale salientar que embora o RUP seja um processo de larga utilização na indústria e adaptável a diferentes tipos de aplicações, estamos instanciando

Comunicações

I Simpósio Brasileiro de Testes de Software, Novembro de 2006

23

apenas alguns fluxos, não é o foco do Code Coverage Process apresentar e descrever todo processo que envolve um projeto de software, desde o levantamento dos requisitos com cliente até a entregar do produto final. Com a execução do processo, buscamos fazer com que ele fosse o mais simples e genérico o suficiente para atender diversos domínios e tipos de aplicações. Desta forma, podemos dizer que a principal contribuição deste processo é fornecer um conjunto coerente de atividades e artefatos direcionados para o desenvolvimento do código e dos testes de unidade, utilizando a técnica de análise de cobertura de código.

6.1 Conceitos Chave A seguir serão apresentados alguns conceitos e terminologia básica necessários para utilização do processo proposto. Instrumentação do código: Antes de poder analisar o código fonte, a ferramenta de cobertura necessita instrumentá-lo. A instrumentação consiste em introduzir pontos de verificação em partes específicas do código (break point, controle de fluxo, labels do código e inicio e fim de procedimentos). Os pontos de verificação fornecerão a informação se o teste está realmente passando (executando) os trechos do código, que foi inserido o ponto de verificação. A instrumentação não irá alterar a execução do fluxo normal do código, ou seja, não irá alterar a seqüência de execução dos comandos e nem o resultado obtido pela computação dos comandos. Código Instrumentado: algumas ferramentas possuem a opção de gerar uma copia do código original, devido a sua estrutura original sofrer modificação quando é instrumentado, sendo que o mesmo não terá perdido as funcionalidades originais, ou seja, ele continuará gerando os mesmos resultados com as mesmas entradas que o arquivo original proporciona. Arquivo de Histórico da Execução: algumas ferramentas de análise de cobertura de código geram um arquivo de histórico da execução do código, em que o mesmo terá as informações da execução do código fonte. O usuário deverá fornecer o endereço onde o arquivo será armazenado, a fim que se possa depois capturá-lo para a geração do relatório com as métricas de cobertura. Outras ferramentas por sua vez geram automaticamente através de scripts o relatório de cobertura, sem a necessidade de ter arquivo de histórico da execução, bastando apenas que o usuário indique o local do repositório de armazenamento, no qual ficará o relatório. Neste caso a utilização da cobertura de código para testes que não sejam de unidade, fica inviável, devido que a maioria das ferramentas gera automaticamente para execuções de testes de unidade. Deve-se estudar e analisar bem as características do projeto e da ferramenta de cobertura que deseja utilizar para que se tenha um melhor proveito das técnicas e dos benefícios gerados pela cobertura de código.

6.2 Responsáveis (Papéis) O Code Coverage Process os responsáveis que irão ter participação nas atividades e nos artefatos gerados pela análise de cobertura de código estão na figura 2. Figura 2. Responsáveis envolvidos no Code Coverage Process

No RUP, a responsabilidade de executar os testes de unidade é do implementador e não de um testador, sendo que em algumas organizações, a tarefa de executar esses testes de unidade pode ser feita por outra pessoa, fazendo o papel de testador. No processo proposto consideramos o implementador como sendo o responsável pela atividade. O implementador terá grande envolvimento no processo de cobertura de código, pois ele será o ponto chave de todo o processo, ele irá configurar a ferramenta no ambiente de desenvolvimento, à medida que for finalizando o conjunto de testes de unidade e submetendo o código para geração do build; terá a responsabilidade de instrumentar o código e coletar as informações da cobertura. Terá também a

Comunicações

I Simpósio Brasileiro de Testes de Software, Novembro de 2006

24

obrigação de analisar os relatórios de cobertura gerados pela ferramenta, para que possa verificar se há necessidade de alteração e ou criação de algum caso de teste de unidade ou alteração do código fonte. As suas atividades serão analisadas pelos resultados coletados pela análise de cobertura de código, logo a definição de métricas e limiares terá grande impacto no seu trabalho. O gerente de projeto tem a responsabilidade de acompanhar, controlar e definir (na medida do possível) as métricas coletadas de cobertura de código, para que se possa ter o acompanhamento da evolução da qualidade dos testes de unidade desenvolvidos, bem como a qualidade do produto gerado. O gerente de configuração terá que prover os recursos para utilização do processo de cobertura de código, como o local e a forma onde serão armazenados os artefatos gerados no processo. Ajudará na criação do guideline de cobertura, referente à utilização do ambiente de trabalho. O integrador irá criar o espaço de integração para receber os componentes testados e criará o build com a integração realizada, para em seguida ser testado novamente. O integrador é responsável por planejar a integração, que ocorre no subsistema e no sistema. O gerente de qualidade acompanhará e monitorará a evolução do projeto e do processo, a partir dos resultados de cobertura. Podendo, caso seja necessário, alterar o processo. O mesmo fará também a análise dos níveis de aceitação obtida, a fim de identificarem falhas no processo e/ou na forma que esta sendo desenvolvido o código e testes. Para um melhor entendimento sobre a interação dos responsáveis, poderemos observar na figura 3, o implementador como sendo o responsável principal e tendo a incumbência de informar ao gerente de projeto o andamento da cobertura do código e dos testes de unidade. O implementador terá o suporte do gerente de configuração e do integrador, em que dará todos os recursos necessários do ambiente para a execução do processo de cobertura de código. O gerente de qualidade fica acompanhando e monitorando a execução do processo, interagindo diretamente com o implementador e o gerente de projeto. Figura 3. Interação entre os envolvidos no Code Coverage Process

Uma forma de deixar a interação dos envolvidos no processo mais dinâmica referente aos dados de cobertura alcançados pelos testes de unidade é disponibilizar em um local de fácil acesso para todos, como por exemplo: em um site. O intuito é evitar o acumulo de obrigações do implementador, tornandose automático a disponibilidade destas informações, facilitando com isso a interação dos gerentes de qualidade e de projeto com os demais envolvidos.

6.3 Atividades Para coleta das métricas de cobertura do código fazem-se necessárias algumas atividades para obtenção dos resultados. As atividades incluídas no Code Coverage Process, são as seguintes: “Configuração da Cobertura”; “Instrumentação do Código”; “Geração do Relatório de Cobertura” e “Análise dos Resultados de Cobertura”. Estas atividades são simples de se realizar e dependendo da ferramenta utilizada, algumas podem ser realizadas de forma automática. As novas atividades são ilustradas na figura 4 e descritas a seguir:

Comunicações

I Simpósio Brasileiro de Testes de Software, Novembro de 2006

25

Figura 4. Atividades de cobertura de código

Configuração da ferramenta: a ferramenta de cobertura deve estar configurada no ambiente de desenvolvimento e se possível integrada com outras ferramentas do ambiente. Existem algumas ferramentas que possibilita ao usuário a opção de configuração de métricas, permitindo que o usuário escolha que tipo de métrica de cobertura deseja colher para avaliar um determinado conjunto de teste de unidade, neste caso deve-se definir e configurar os limites de cobertura desejável e os tipos de métricas que deverão ser coletadas. Instrumentação do Código: o código deve ser instrumentado, para que os pontos de verificação sejam inseridos, a fim de verificar se o local onde o ponto foi inserido realmente esta sendo testado. Após ter instrumentado o código original, deve-se realizar a compilação do código instrumentado, para que se possa ter um build instrumentado. Algumas ferramentas oferecem a funcionalidade de compilação do código. Em alguns projetos o tempo de compilação é um fator crítico, pois têm uma duração longa, logo se deve ter o código fonte e os testes de unidade estabilizados para que se possa utilizar o processo de análise de cobertura, para que não ocorra perca de tempo, devido a atividades sendo refeitas. Geração do relatório de cobertura: é a atividade em que serão gerados os relatórios com a análise da cobertura do código. Dependendo da ferramenta de cobertura, podem ser gerados vários tipos de relatórios, com formato textual e ou gráfico. Tendo os casos de testes executados, a atividade agora será gerar as métricas, para isso em alguns casos (dependendo da ferramenta) se faz necessário ter o arquivo histórico da execução correspondente à execução. Análise dos resultados de cobertura: é a atividade em que serão analisados e verificados os resultados das métricas de cobertura. Está atividade serve como suporte para tomada de decisões para o projeto, pois é onde se darão as diretrizes para solução dos problemas encontrados, referentes ao baixo nível de cobertura.

6.4 Artefatos No momento em que as atividades de cobertura de código são realizadas, estas criam, utilizam ou alteram artefatos. Para alguns artefatos produzidos é possível criar modelos que auxiliem a sua criação. Os novos artefatos são ilustrados na figura 5 e descritos a seguir: Figura 5. Artefatos gerados no Code Coverage Process

Guideline de Cobertura: no processo de desenvolvimento com cobertura de código, existe a necessidade da criação de um guideline, em que orientará o uso da ferramenta no processo. Neste guia, deve ter os passos necessários para integração da ferramenta no ambiente de desenvolvimento. Este artefato terá características de manual da ferramenta, sendo que direcionado para realidade da organização e do projeto que está sendo avaliado, ao contrário do manual que acompanha a ferramenta,

Comunicações

I Simpósio Brasileiro de Testes de Software, Novembro de 2006

26

devido que o mesmo é em alguns casos: extenso e muito genérico, ocasionando certa dificuldade para a sua utilização. Código Fonte Instrumentado: é o código alterado com a inserção dos pontos de verificação, para que se possa ser realizado a análise da cobertura do código. Algumas ferramentas geram automaticamente uma cópia do arquivo, devido que o código é alterado na sua estrutura, mas não perdendo a sua funcionalidade. Existe ferramenta que torna esta atividade totalmente transparente para o usuário, fazendo com o que o mesmo não se preocupe com o código instrumentado. Dependendo do tempo da geração do build, se aconselha fazer uma sem instrumentação, a fim de verificar se não tem nenhum problema com o código original e/ou no ambiente de desenvolvimento, para depois gerar o build instrumentado, que no caso é gerada através do código fonte instrumentado. É preciso ter builds paralelas de desenvolvimento, uma oficial proveniente do código original e uma outra para o código instrumentado. A build do código original se tornará build do produto, no qual passará pelo controle de versão, a outra servirá apenas para realizar os casos de testes e realizar a análise de cobertura. Relatório de Cobertura: Apresenta as métricas de cobertura do código que foi executado pelo testes de unidade. Relata a efetividade dos casos de testes de unidade. Faz necessário um banco de dados (repositório) com todos os relatórios de cobertura, para que se possa ter um acompanhamento da evolução dos casos de testes de unidade e do código, tendo um número de relatórios de cobertura, pode-se fazer uma avaliação sobre o nível de cobertura desejável para cada projeto. O relatório de cobertura irá acompanhar o documento de Solicitação de Mudança, a fim que se tenha um controle e monitoramento da qualidade do código e dos testes desenvolvidos. A utilização das técnicas de cobertura de código no fluxo de testes, no qual estaremos executando testes que não são de unidade. O relatório não será tão condizente com a realidade, pois a geração é realizada em base nos testes executados no código e alguns destes testes não conseguiram passar por trechos no qual apenas o teste de unidade poderá verificar. Logo deverá ter uma atenção na definição de limiares e na análise dos resultados, pois a granularidade no relatório é baixa.

6.5 Detalhamento dos fluxos estendido do RUP O processo proposto, Code Coverage Process, aborda os desenvolvimentos iterativos, sendo guiado pela produção de artefatos. Com a execução do processo, buscamos fazer com que ele fosse o mais simples e genérico, o suficiente para atender diversos domínios e tipos de aplicações. Desta forma, podemos dizer que a principal contribuição deste processo é fornecer um conjunto coerente de atividades e artefatos direcionados para o desenvolvimento de testes de unidade, utilizando a técnica de análise de cobertura de código.

6.5.1 Fluxo de Implementação do RUP Estendido É na implementação que se realiza a codificação do produto, e principalmente a elaboração dos testes de unidade que irão exercitar o código que se deseja analisar. Este fluxo é o mais importante no Code Coverage Process, é nele que as principais atividades do processo estão inseridas; os outros fluxos envolvidos servirão de análise de resultados e suporte para a execução do processo. No desenvolvimento do software, a inserção da cobertura de código ocorre quando o código e os testes de unidade estão estabilizados. Para o inicio das atividades, referente à cobertura de código, recomenda-se que o ambiente de desenvolvimento já esteja configurado e funcionando para que não haja problemas no momento da execução das tarefas de cobertura de código. Os subfluxos que serão adaptados para o processo proposto estão apresentados na figura 6 e descritos em seguida. Figura 6. Subfluxos adaptados do fluxo de Implementação

Comunicações

I Simpósio Brasileiro de Testes de Software, Novembro de 2006

27

Implementar Componentes: Os implementadores escrevem o código fonte, adaptam os componentes existentes, compilam, vinculam e realizam os testes de unidade, conforme eles implementam as classes no modelo de design. Se houver defeito no design, o implementador envia o feedback do trabalho refeito sobre o design. Os implementadores também consertam defeitos de código e realizam testes de unidade para verificar as mudanças. Em seguida, o código é revisado para avaliar a qualidade e a compatibilidade com as diretrizes de programação. Podemos ter uma visão mais detalhada do subfluxo de implementar componentes com as atividades de cobertura na figura 7. Figura 7. Subfluxo detalhado de Implementar Componentes

A atividade de “Corrigir Defeito” será adaptada para o Code Coverage Process, devido o mesmo receber informações da atividade de análise dos resultados de cobertura, a fim que possa corrigir defeitos encontrados no relatório de cobertura. A atividade de “Realizar Teste de Unidade” será também adaptada, pois o componente que será testado está com o código instrumentado e dependendo da ferramenta de cobertura utilizada será gerado um arquivo contendo o histórico da execução do teste de unidade. No Code Coverage Process, deve-se utilizar à ferramenta de cobertura no momento em que se tenha o código fonte e os testes de unidade estáveis, pois não se deve utilizar a instrumentação e ao mesmo tempo ficar alterando o código e ou os testes de unidade, para que não se tenha atividade de instrumentação e de compilação sendo refeita e principalmente gerar métricas de cobertura que não condiz com a realidade ou ficar em dúvida da eficácia do resultado da cobertura, consequentemente do processo. O subfluxo de Implementar Componente irá desenvolver e ou alterar o código, sendo que teremos que configurar a ferramenta de cobertura para ter acesso ao código que esta sendo desenvolvido e para integração dela no ambiente de trabalho. Algumas ferramentas o próprio ambiente de trabalho já estão integrados. As atividades de implementação e instrumentação, juntamente com a tarefa de compilação do código instrumentado, serão realizadas de forma seqüencial podendo ser executada paralelamente com a elaboração dos testes de unidade ou até por implementadores diferentes, sendo que ambas terão que configurar a ferramenta para o acesso ao ambiente de desenvolvimento e também para ajustar os limites de cobertura que foram especificados no projeto. Tendo atingido as métricas de cobertura especificadas no projeto com sucesso. É finalizada a tarefa, atualizando a solicitação de mudança e anexando o relatório de cobertura, a fim de se ter o monitoramento e acompanhamento do projeto. À medida que for sendo seguido o processo, pode-se ser revisto as métricas estabelecidas, a fim de aumentar ou diminuir o limiar de aceitação das métricas de cobertura de código. Tendo sido gerado o relatório de cobertura, começa a atividade de analisar os resultados da cobertura. Dependendo do resultado do relatório com as métricas de cobertura, se faz necessário à correção (alteração) do código e ou dos seus testes de unidade, indo para atividade de corrigir defeito tendo feito o registro no documento de solicitação de mudança e junto anexado o relatório de cobertura. Ao concluir a correção, deverá ser realizada novamente a atividade de instrumentação, caso a correção tenha sido feita

Comunicações

I Simpósio Brasileiro de Testes de Software, Novembro de 2006

28

no código, a fim que se possam gerar novos relatórios para uma reavaliação da cobertura. Se a correção for somente nos testes, logo não tem necessidade de instrumentar o código, precisando apenas de executar os testes de unidade novamente para gerar o relatório. Tendo atingido as métricas de cobertura especificadas no projeto. É finalizada a tarefa, atualizando a solicitação de mudança e anexando o relatório de cobertura, a fim de se ter o monitoramento e acompanhamento do projeto. À medida que for sendo seguido o processo, pode-se ser revisto as métricas estabelecidas, a fim de aumentar ou diminuir o patamar de aceitação da cobertura do código. Integrar cada Subsistema: o objetivo desta atividade é integrar os componentes para formar subsistemas, os quais serão integrados para formar o sistema final. A integração de cada Subsistema, será realizada com um build instrumentado, a fim que se possam realizar os casos de testes e em seguida gerar a métricas de cobertura, para se obter dados com o subsistema integrado e detectar se há necessidade de criar novos testes ou eliminar testes que estão redundantes. Figura 8. Subfluxo de Integrar cada Subsistema

Integrar o Sistema: dependendo do interesse da organização, poderá utilizar o código instrumentado, para o mesmo propósito da atividade anterior, ou seja, ter métricas de cobertura de código com o sistema integrado, no qual teremos a possibilidade de executar os casos de testes baseado na cobertura do código. Figura 9. Subfluxo de Integrar o Sistema

6.5.2 Fluxo de Gerenciamento de Configuração e Mudança do RUP Estendido No “Gerenciamento de Configuração e Mudança”, toda atividade ligada à cobertura de código necessitará de um suporte e um controle dos artefatos gerados para a medição da cobertura. Desde a coleta do código dentro do sistema de controle de versão até o fechamento da solicitação de mudança de implementação ou modificação do código. Para realização do processo com a utilização da técnica de cobertura de código, terá o suporte do fluxo de Gerenciamento de Configuração e Mudança, devido que novos artefatos serão criados e alguns serão adaptados, logo se faz necessário ter um controle de versão destes documentos. Outro ponto também que terá suporte deste fluxo é a questão do ambiente de trabalho, no qual o implementador necessitará configurar o ambiente para a utilização da ferramenta de cobertura. Os subfluxo que serão adaptados estão apresentados na figura 10 e descritos em seguida.

Comunicações

I Simpósio Brasileiro de Testes de Software, Novembro de 2006

29

Figura 10. Subfluxos adaptados do fluxo de Gerenciamento de Configuração e Mudança

No subfluxo de Criar Ambientes para CM do Projeto, controlará o Guideline de Cobertura e o Relatório de Cobertura, pois os dois sofrerão mudança no decorrer do projeto. No subfluxo Monitorar e Relatar Status de Configuração, será adaptado para o processo proposto, no que se refere ao documento de Métricas de Projeto, no qual teremos a inclusão da métrica de cobertura de código. Em todo o processo proposto o fluxo de Gerenciamento de Configuração e Mudança dará suporte no que se refere ao ambiente de desenvolvimento e no controle dos artefatos, bem como o seu acesso.

6.5.3 Fluxo de Gerenciamento de Projeto Neste fluxo teremos a finalidade de analisar as métricas coletadas através dos relatórios gerados pela ferramenta de cobertura, bem como tomar posicionamento e diretrizes para que a qualidade dos testes melhore, ou seja, que as métricas coletadas não fiquem abaixo do nível de cobertura estabelecido pela organização. Uma das vantagens da análise de cobertura de código é que se pode ter a noção dos casos de testes que deverão existir para assegurar a qualidade do código, com isso o gerente tem a facilidade de fazer uma estimação dos recursos e do tempo necessário para a entrega do produto. Os subfluxo que serão adaptados estão apresentados na figura 11 e descritos em seguida. Figura 11. Subfluxos adaptados do fluxo de Gerenciamento de Projeto

Elaborar Plano de Desenvolvimento de Software: as atividades adaptadas para o Code Coverage Process são: Desenvolver Plano de Métricas; Definir Processos de Controle e Monitoramento e Desenvolver Plano de Garantia de Qualidade. Na atividade de Desenvolver Plano de Métricas, definirá as metas do projeto que deverão ser seguidas e alcançadas com êxito. Nesta atividade estaremos realizando o estudo das métricas e limiares de cobertura. Na atividade de Definir Processos de Controle e Monitoramento, que definirá as informações e os processos que serão usados para o monitoramento e controle do andamento, da qualidade e dos riscos do projeto, teremos as tarefas de selecionar e definir as métricas de cobertura de código. A definição de métricas e limiares de cobertura de código é um passo muito relevante na utilização do Code Coverage Process. As métricas são importantes no controle e gerenciamento de projetos de software. A escolha das métricas está intimamente associada às estratégias e objetivos da organização, e vai depender do estágio de maturidade em que a mesma se encontra. A seleção e definição de um conjunto de métricas não são tarefas triviais. Na verdade, é uma tarefa custosa que demanda grande conhecimento para evitar que o seu uso não aumente ainda mais os problemas enfrentados durante o desenvolvimento de software. Escolher incorretamente uma métrica e seus limiares de aceitação pode gerar um aumento desnecessário de esforço e uma visão errada da

Comunicações

I Simpósio Brasileiro de Testes de Software, Novembro de 2006

30

realidade do projeto, resultando em tomada de decisões equivocadas. O correto é a realização de um ou mais projetos piloto, com o intuito de determinar métricas e principalmente atestar a ferramenta selecionada. Na atividade de Desenvolver Plano de Garantia de Qualidade, este documento contará com as informações para o comprometimento das métricas e do processo de cobertura de código. Como foi dito anteriormente o gerente de qualidade terá uma fundamental participação, pois acompanhará e monitorar a evolução do projeto e do processo, levando em consideração os dados obtidos com as métricas de cobertura de código atingidas. A figura 12 mostra quais foram às atividades adaptadas para o processo proposto. Figura 12. Subfluxos de Elaborar Plano de Desenvolvimento de Software

Monitorar e Controlar o Projeto: que acompanha o trabalho do gerente de projeto, as atividades “Monitorar Status do Projeto”; “Relatar Status” e “Resolver Exceções e Problemas” foram adaptadas para o Code Coverage Process. Podemos observar a figura 13, no qual essas atividades foram adaptadas. Figura 13. Subfluxos de Monitorar e Controlar o Projeto

Comunicações

I Simpósio Brasileiro de Testes de Software, Novembro de 2006

31

Na atividade de Monitorar Status do Projeto, o gerente irá agora, através das informações do Relatório de Cobertura, avaliar a qualidade do código e dos testes desenvolvidos. Na atividade de Relatar Status serão informados, para as autoridades competentes do projeto, os dados provenientes das métricas de cobertura atingidos no projeto, com intuito de comprovar a qualidade dos testes e conseqüentemente do produto como um todo. Na atividade de Resolver Exceções e Problemas será feita às ações e medidas corretivas no aspecto dos problemas encontrados do não comprometimento com as métricas estabelecidas no projeto. O gerente de projeto irá analisar e tomará decisões cabíveis para a correção deste problema. O gerente de qualidade deverá acompanhar e monitorar a evolução do projeto. Gerenciar Iterações: teremos a atividade de Avaliar Iteração adaptada para o Code Coverage Process, pois o Relatório de Cobertura dará informações a respeito da qualidade dos testes desenvolvidos, mediante essas informações se tomará ações e medidas apropriadas para as próximas iterações. No momento que for selecionar e definir a ferramenta de cobertura que será utilizada no projeto da organização, deve-se levar em consideração a forma que o relatório se apresenta, informando os trechos que foram ou não executados pelo testes de unidade. A figura 14 mostra a atividade que foi adaptada. Figura 14. Subfluxo de Gerenciar Iteração

7. ESTUDO DE CASO Esta seção apresenta o estudo de caso desenvolvido para a elaboração do Code Coverage Process, no qual incorporamos a técnica de cobertura de código no processo de desenvolvimento de software em durante a sua execução. O estudo de caso foi desenvolvido na Motorola Brazil Test Center (BTC), no domínio de desenvolvimento de aplicações para telefones móveis, no qual interagimos com uma equipe de desenvolvimento do projeto da Motorola. “Sistemas embarcados têm tido enorme crescimento e desenvolvimento, especialmente com a disponibilidade de número crescente de dispositivos inteligentes e complexos com capacidades diversas” (MUPPALA, 2005). Mediante essa constatação tivemos que, inicialmente, realizar estudos e analises para vemos a melhor forma de inserimos as atividades dentro do fluxo da equipe de desenvolvimento de código para sistemas embarcados, a fim de não ocasionar impactos negativos e prejudicar o andamento do desenvolvimento atual. A equipe de desenvolvimento, no qual estávamos trabalhando no estudo de caso, tinha as seguintes características: realizava-se um procedimento de criação dos testes de unidade para código, mas em contrapartida não tinham um procedimento de analisar a efetividade dos testes de unidade gerados. A única métrica de qualidade de código era quantidade de testes de unidade que passaram e falharam, apesar

Comunicações

I Simpósio Brasileiro de Testes de Software, Novembro de 2006

32

de não haver nenhuma garantia que os testes de unidade passados cobriam realmente o código ou que alguns deles pudessem ser redundantes. Análise de cobertura de código é o processo de encontrar código exercitado por um conjunto particular de entradas de teste, é um importante componente de desenvolvimento e verificação de software. A maioria dos métodos tradicionais de implementar ferramentas de análise de cobertura de código é baseada em instrumentação de programa. Este método ocasiona tipicamente um overhead, devido à inserção e a execução do código da instrumentação, e não são deployable em muitos ambientes de software. (SHYE, 2005) No momento que estávamos estudando e analisando como as técnicas de cobertura de código poderiam ser inseridas dentro do projeto do nosso estudo de caso, realizamos uma pesquisa de possíveis ferramentas que combinaria com o ambiente de desenvolvimento do projeto e principalmente, se elas poderiam gerar dados detalhados a respeito da cobertura do código em base dos testes de unidade realizados. Essa pesquisa foi necessária devido a enorme quantidade de ferramentas existente no mercado, logo teríamos que selecionar uma que atendesse aos requisitos que foram levantados para na nossa análise, a fim de termos no resultado final um maior número de métricas de cobertura e outras funcionalidades além da cobertura de código, bem como uma ferramenta que pudesse gerar um relatório de cobertura detalhado. Terminado o processo da seleção da ferramenta, o próximo passo foi aplicá-la no ambiente real de desenvolvimento, onde poderiam ser coletadas métricas. Foi montada toda uma estrutura dentro do ambiente da equipe de desenvolvimento da Motorola. Foi necessário conhecer todo o ambiente de desenvolvimento e interagir diretamente com desenvolvedores durante o processo. Em seguida iniciamos um projeto piloto, no qual selecionamos dois componentes de desenvolvimento do projeto, para a realização de experimentos, com objetivo de verificar a eficácia da ferramenta de cobertura escolhida e principalmente colher informações referente à inserção e adaptações de atividades para o uso da cobertura de código, relacionado com o impacto que seria no processo de desenvolvimento utilizado no projeto. A partir do piloto foi possível analisar e registrar os benefícios da técnica de cobertura no processo, como: • Melhoria na codificação; • identificação de casos de teste redundantes; • análise da cobertura do código; • sugestão de criação de casos de teste.

7.1 Dificuldades Encontradas e Lições Apreendidas Alguns problemas foram encontrados no decorrer da realização do estudo de caso, no qual tivemos que ir em busca de soluções adequadas para estas atividades. A seguir iremos descrever quais dificuldades foram encontradas e as soluções adotadas. Problemas com arquivos que eram instrumentados, mas não deveriam ser, devido à instrumentação recursiva, fizeram com que o tamanho do componente, cujo código foi instrumentado, aumentasse em comparação ao componente original, fazendo com que, conseqüentemente, o tempo de compilação fosse prejudicado. Esse problema ocorreu devido a uma forma de errada da utilização da ferramenta de cobertura. Inicialmente tivemos problemas na compreensão a respeito do ambiente de desenvolvimento, em relação à estrutura de armazenamento e a criação de builds. Foi preciso realizar treinamentos, bem como ter um suporte de alguns desenvolvedores. Devido a esse problema, tivemos certa dependência da equipe de desenvolvimento no começo dos nossos trabalhos. Tivemos alguns trabalhos que foram refeitos, devido ao processo de desenvolvimento de software, em que se realizava a criação de testes de unidade paralelamente com o desenvolvimento do código, pois como o código mudava frequentemente havia a necessidade de se alterar os testes e consequentemente fazer uma nova análise de cobertura. A solução encontrada para este problema foi realizar a análise de cobertura após a estabilização do código e dos testes de unidade. Como a ferramenta, que selecionamos nas primeiras fases do nosso trabalho, produz uma quantidade enorme de relatórios de cobertura e outros tipos de relatórios, tivemos que nos dedicar exclusivamente a atividade de estudo dos relatórios e realizar um número maior de experimentos e testes, com intuito de entender os relatórios de cobertura gerados pela ferramenta, bem como escolher quais tipos de relatórios serviria para o projeto que estávamos analisando.

Comunicações

I Simpósio Brasileiro de Testes de Software, Novembro de 2006

33

7.1 Resultados Obtidos Durante o período do projeto piloto, várias pessoas foram envolvidas na melhoria da qualidade do software do projeto da Motorola, procurando melhores resultados em relação à cobertura do código desenvolvido e produtos no mercado, que oferecesse uma ferramenta capaz de garantir um bom comportamento e conformidade com os requisitos de sistemas embarcados. Algumas dificuldades foram encontradas e algumas soluções foram apresentadas no processo de seleção da ferramenta de cobertura e de desenvolvimento do código. Inicialmente, nós seguimos as métricas de aceitação de cobertura proposta pela ferramenta, porque não tínhamos um histórico das execuções, que nos permitisse criar um perfil das métricas de cobertura para os projetos que fossem ser analisados. Com a ferramenta de cobertura selecionada foi possível alcançar um código bem coberto, que agregasse mais qualidade, menos depuração de tempo ou criação de cenários de falha ou sucesso, e mais produtividade para a codificação e processo de teste. Pelos próprios relatos dos desenvolvedores podemos mencionar e destacar o seguinte resultado: • Com a verificação e análise dos relatórios de cobertura, poderemos saber antes de implementar novos casos de testes para se obter uma cobertura de 100% do código testado, testes poderá ser caixa branca ou caixa preta; • com os relatórios de cobertura, podem-se descobrir os possíveis cenários para a criação dos casos de testes de unidade, bem como saber se existem casos de testes redundantes; • na identificação de um determinado trecho de código que não está sendo coberto, verificar se a razão desta falta é devido ao teste não estar passando pelo ponto de verificação ou se não existem testes; • quando existem vários módulos a serem testados, tendo os módulos da camada superior testado, pode se reduzir à quantidade de testes da camada inferior, resultando na redução dos esforços sem perder a cobertura dos casos de testes, evitando a redundância. No projeto surgiu a necessidade da criação de um guideline, em que orientaria o desenvolvedor no uso da ferramenta de cobertura no processo. Este guia, é inserido os passos para integração da ferramenta no ambiente de desenvolvimento. Com as informações colhidas no projeto piloto, realizado no estudo de caso, pudemos elaborar uma proposta de um processo de desenvolvimento de software, com atividades, responsáveis e artefatos gerados para implementação do código, tendo como suporte a análise de cobertura de código, no qual estaríamos utilizando o RUP como base e fonte inspiradora, consequentemente utilizando-se um processo genérico, o RUP, no qual é um processo bastante conhecido e consolidado, o processo proposto será de fácil entendimento para outras organizações de desenvolvimento de software.

8. ANÁLISE CRITICA DO PROCESSO PROPOSTO Ao propor um processo de desenvolvimento de código, é necessário verificar se o mesmo é realmente viável, do ponto de vista de quem irá utilizar na prática, as equipes de desenvolvimento de software, para avaliar sua utilidade e seus benefícios. Em Shad Pfleeger, são descritas técnicas de validação de processos, métodos e ferramentas de engenharia de software. Dentre estas técnicas, as mais utilizadas são experimentos, estudos de caso, questionários e entrevistas. Questionários e entrevistas são boas técnicas para o levantamento de dados qualitativos e para saber a opinião de pessoas envolvidas em um determinado projeto. Para que obtivéssemos uma maior legitimidade e imparcialidade na avaliação do Code Coverage Process, um questionário foi enviado a um grupo de profissionais da área de desenvolvimento de software. Tal questionário serviu para verificar a satisfação dos objetivos almejados pelo processo proposto e a possibilidade de sua utilização em metodologias tradicionais, bem como em metodologias ágeis, mesmo tendo o processo sido inspirado no RUP, uma metodologia tradicional, procuramos saber se o processo poderia ser utilizado também em processos ágeis. O questionário foi divido em duas partes. A primeira parte é utilizada para identificação do perfil dos avaliadores e a segunda parte faz uma análise do processo mediante aos objetivos descritos referente a processo, teste e medição da qualidade do software. Além do questionário, disponibilizamos uma primeira versão do processo proposto para que o avaliador fosse capaz de responder as perguntas claramente. Para compor esta avaliação, onze (11) questionários foram enviados, e destes, apenas cincos (5) foram devolvidos, no qual podemos constatar como uma grande dificuldade desta análise, foi

Comunicações

I Simpósio Brasileiro de Testes de Software, Novembro de 2006

34

exatamente a indisponibilidade das pessoas em se ceder um pouco do seu tempo para análise do processo e preenchimento do questionário. O perfil dos profissionais selecionados para compor o grupo de avaliadores foi escolhido de acordo com o papel desempenhado atualmente e de acordo com o conhecimento em processo de testes de software. Procuramos principalmente escolher pessoas que exercessem papeis relacionados com o que foi adaptado no RUP para o processo proposto. As perguntas referentes à análise critica do processo, foram elaboradas relacionadas ao processo, teste e métricas de qualidade de software, no qual perguntávamos se o processo proposto contribuía aos objetivos apontados nos questionários e se poderia ou não ser aplicado a metodologias tradicionais e ou ágeis. Por ultimo foi perguntado ao entrevistado se o processo como todo contribuía aos objetivos apontados (processo, teste e métricas de qualidade de software) no questionário e se era aplicável a metodologias tradicionais e ou ágeis. No final tinha um espaço para os entrevistados descreverem os benefícios e ou problemas do processo proposto. A seguir podemos observar nos gráficos o resultado da primeira analise critica do Code Coverage Process referente à sua utilização como um todo. Gráfico 1. Em relação à sua aplicabilidade aos tipos de metodologias de desenvolvimento de software Aspectos Gerais - Code Coverage Process 0% 0% 20%

Metodologias ágeis Metodologias tradicionais Ambos os tipos Nenhuma deles

80%

Gráfico 2. Em relação à contribuição ao comprimento do conjunto de objetivos (processo, teste e medição de qualidade de software) Aspectos Gerais - Code Coverage Process 0% 0%

40%

Contribui fortemente Contribui em partes Contribui fracamente

60%

Não contribui

Como resultado da aplicação do questionário, tivemos um excelente feedback dos entrevistados que analisaram o processo e responderam o questionário, no qual deram sugestões e considerações a respeito do processo, com isso realizamos um refinamento do processo para numa fase posterior podermos aplicar novamente o questionário, a fim de melhorar o processo e valida-lo. Nos gráficos podemos observar que mesmo o processo sendo inspirado no RUP, no qual é um processo tradicional, o Code Coverage Process pode ser aplicável também para processos ágeis; outro ponto que nos deixou contentes foi que o processo, mediante a resposta dos entrevistados, contribui em partes ou fortemente ao comprimento do conjunto de objetivos relacionado a processo, teste e medição de qualidade de software. O maior ponto negativo da análise foi o número da amostra ter sido pequena, em virtude de ter tido 6 entrevistados não ter entregue os questionários preenchidos.

9. CONCLUSÃO O Code Coverage Process, é de fácil entendimento, pois as atividades que foram inseridas são simples de execução, e principalmente que o processo proposto foi inspirado no processo bastante consolidado e

Comunicações

I Simpósio Brasileiro de Testes de Software, Novembro de 2006

35

conhecido nas organizações de software. Pudemos realizar um estudo de caso, no qual analisamos e estudamos como deveria ser a colocação destas novas atividades e quais atividades seriam adaptadas. Com a realização do estudo de caso podemos constatar que com a técnica de cobertura de código para realizar teste que validam a efetividade dos casos de testes, faz com que o código gerado tenha uma melhoria significativa na sua qualidade, bem como no processo de desenvolvimento. Resultando um ganho na produtividade do desenvolvimento e num melhor gerenciamento do projeto referente ao controle de estimativas dos testes de unidade. Outro fator é que as falhas que deveriam serem encontrados nesta fase não iram passar para fases posteriores de testes. As atividades e artefatos sugeridos no processo, são de forma simples de execução, pois procuramos deixa o mesmo genérico o suficiente e de fácil entendimento para que não seja difícil a utilização do code Coverage Process em outros processos e projetos, mesmo que o estudo de caso tenha sido realizado no ambiente de desenvolvimento de software para sistemas embarcados, pois o processo de desenvolvimento de código que acompanhamos é semelhante para outros tipos de sistemas. Estamos atualmente realizando uma segunda analise critica do processo, pois inserimos no processo o fluxo de teste, pois realizamos um segundo estudo de caso e um experimento para utilizar a técnica de cobertura de código na fase de testes funcionais e de sistemas, para a validação da build do software. Neste trabalho criamos builds instrumentadas para a execução de testes funcionais e de sistemas. Um outro motivo da realização de uma nova avaliação crítica se deve ao fato que a primeira avaliação foi com um numero pequeno de amostra, e logo necessitamos ter um número maior de entrevistados. Este trabalho foi aplicado (estudo de caso) em apenas projetos que utilizam metodologia tradicional, ficando para trabalho futuro a aplicação do mesmo para projetos de desenvolvimento de software que utilizam metodologias ágeis, a fim de saber o impacto e as interações entre as atividades proposta e a existente no processo ágil. Apesar de que pela análise qualitativa, realizada pela aplicação de questionários, pudemos questionar se o processo proposto poderia ser utilizado em processos ágeis, mas gostaríamos de realizar um estudo de caso para este tipo de metodologia. A partir do trabalho realizado ficam os seguintes registros para trabalhos futuros, a fim de melhorar e validar o processo proposto: • Realização de experimentos para definição de critérios referente aos limiares aceitáveis de cobertura de código, utilizando o processo de métricas proposto neste trabalho. Este tem o intuito de propor um limiar de cobertura no qual a organização, em que está sendo aplicado o projeto, possa validar seus casos de testes de unidade; • coleta de informações sobre o impacto da análise de cobertura de código no processo de desenvolvimento de software; • implantação deste processo de cobertura de código inserido no desenvolvimento de código nas organizações, a fim que se possa verificar, analisar e validar o seu ganho na implantação do processo existente.

AGRADECIMENTOS Gostaria de agradecer a: João dos Prazeres, Rafael Marques, Angelo Ribeiro, Lucas Loreiro e Marcos Carita. Agradecimento em especial à Motorola, Centro de Informática e o C.E.S.A.R pela oportunidade de aplicar esse trabalho, mas especificamente aos professores Augusto Sampaio e Paulo Borba, e ao Gerente de Qualidade da Motorola José Lima, por todo apoio dado neste trabalho. A todos os colegas do programa CIn-Motorola pelo apoio incondicional sempre que solicitei.

REFERÊNCIAS Conallen, J., 2002. Building Web Applications with UML. Addison Wesley Longman Publishing Co., Inc., Boston, USA. Myers, G., 2004. The Art of Software Testing. John Wiley & Sons, Inc., New Jersey, USA. Maldonado, J. C. et al, 2000. Introdução ao Teste de Software. In: XIV Simpósio Brasileiro de Engenharia de Software. Minicurso. João Pessoa, Brasil. Hunt, A. and Thomas, D., 2003. Pragmatic Unit Testing in Java with JUnit. The Pragmatic Bookshelf. Raleigh, North Carolina Dallas, Texas, EUA.

Comunicações

I Simpósio Brasileiro de Testes de Software, Novembro de 2006

36

Lewis, W. E., 2000. Software Testing and Continuous Quality Improvement. Boca Raton: CRC Press, Florida, EUA. Cornett,

S.,

2005.

Code

Coverage

Analysis.

Bullseye

Testing

Technology.

Disponível

em:

http://www.bullseye.com/coverage.html. Acesso em: 21 Outubro. Kim, Y. W., 2003. Efficient Use of Code Coverage in Large-Scale Software Development. Proceedings of the 2003 conference of the Centre for Advanced Studies on Collaborative research. Ontario, Canada, pp. 145–155. Gokhale, S.S.; Mullen, R.E., 2005. Dynamic Code Coverage Metrics: A Lognormal Perspective. Software Metrics. 11th IEEE International Symposium. pp. 33-33. Elbaum, S.; Gable, D.; Rothermel, G., 2001. The impact of software evolution on code coverage information. Software Maintenance, 2001. Proceedings. IEEE International Conference on. pp. 170-179 Kruchten, P., 2003. Rational Unified Process, The: An Introduction. Addison Wesley Longman Publishing Co., Inc., Boston, USA. OMG, 2005. Software Process Engineering Metamodel Specification - SPEM, Version 1.1. Object Management Group, Inc. (OMG) Muppala, J. K., 2005. Experience with an Embedded Systems Software Course. Senior Member IEEE. ACM SIGBED. ACM Press New York, NY, USA. pp. 29-33. Shye, A. Iyer, M. Reddi, V. J. Connors, D. A., 2005. Code Coverage Testing Using Hardware Performance Monitoring Support. Proceedings of the sixth international symposium on Automated analysis-driven debugging AADEBUG'05. ACM Press. Monterey, California, USA. pp. 159-163. Tikir, M. M. and Hollingsworth, J. K., 2002. Efficient Instrumentation for Code Coverage Testing. ACM SIGSOFT Software Engineering. Roma, Italy. pp. 86-96. Zhu, H.; Hall, V. A. P.; May, R. H. J., 1997. Software Unit Test Coverage and Adequacy. ACM Computing Surveys. ACM Press. The Open University, Milton Keynes, UK. pp. 1-62. Marick, B., 1997. How to Misuse Code Coverage. Reliable Software Technologies. Craig, R. D. and Jaskiel, S. P., 2002. Systematic Software Testing. Artech House Publishers. London, UK. Pfleeger, S. L., 1995. Experimental Design and Analysis in Software Engineering – Part2: How to Set Up an Experiment, Software Engineering Notes, vol 20, no 1. pp. 22-26.

Comunicações

I Simpósio Brasileiro de Testes de Software, Novembro de 2006

37

ANÁLISE DA ADERÊNCIA DE UM PROCESSO DE TESTE AO TMM ALLAN REFFSON1, CARLA ILANE MOREIRA BEZERRA2, EMANUEL FERREIRA COUTINHO1, FRANDBERTO FAÇANHA1 1 Serviço Federal de Processamento de Dados (SERPRO) Av. Pontes Vieira, 832, São João do Tauape CEP - 60130-240 – Fortaleza – CE Brasil 2

Universidade Estadual do Ceará (UECE) [email protected]

{allan.lima, frandberto.facanha, emanuel.coutinho}@serpro.gov.br

RESUMO Quando um produto é lançado no mercado com alto grau de defeitos, afetando a usabilidade, funcionalidade, performance e segurança do mesmo, o impacto pode ser muito grande para a imagem da organização, trazendo possíveis prejuízos. Por esse motivo, as empresas de desenvolvimento de software estão cada vez mais preocupadas com a qualidade de seu produto, sendo necessário realizar uma melhoria de seu processo de desenvolvimento de software, através da garantia de adequação dos requisitos impostos pelo cliente. Uma forma de conseguir verificar e validar esses requisitos é através dos testes de software realizados ao longo do ciclo de desenvolvimento do produto. Para que isto seja possível, as empresas elaboram um Processo de Teste de software onde estão documentados os procedimentos que cada membro da equipe deve executar para seguir o processo. Para adequar o processo às boas práticas do teste é necessário adotar um modelo de melhoria que atenda a área de teste de software. Neste contexto, este trabalho propõe apresentar uma análise de aderência de um Processo de Testes de uma empresa de grande porte aos níveis 2 e 3 do modelo de melhoria de testes TMM (Test Maturity Model). PALAVRAS-CHAVE Qualidade de Software, Processo de Teste, TMM.

1. INTRODUÇÃO Atualmente, percebe-se a necessidade de dispor de processos que auxiliem uma organização no desenvolvimento de software. Um processo consiste de uma série de passos a serem seguidos para resolver um problema. Esses passos devem ser definidos de tal forma, que não sejam ambíguos e possam ser seguidos por qualquer pessoa utilizando-se do processo. Dessa forma, a organização diminuirá o retrabalho e aumentará a qualidade de seus produtos desenvolvidos, assim como de seus processos de desenvolvimento. Logo, deve-se focar no processo e ter como apoio treinamentos, recursos, pessoas capacitadas, ferramentas apropriadas e gerência comprometida [Paula, 2005]. Para conseguir o nível de qualidade adequado para seus produtos, o mercado de software vem investindo em pesquisas de processos de desenvolvimento de software e vários modelos de melhoria. O TMM é um bom exemplo de modelo de melhoria de testes de software que auxilia as empresas a alcançar o nível de qualidade adequado para aplicar em seus processos de teste. O modelo de maturidade TMM é utilizado apenas para melhoria de processos de testes. A existência de um Processo de Testes é muito importante para a empresa, pois através de procedimentos eficientes de testes de software durante todo o desenvolvimento do produto, é garantida a redução do número de defeitos, atendimento aos requisitos, diminuição de prazo de entrega e custo do software e maior eficiência do produto. Neste contexto, o trabalho apresenta um Processo de Testes de uma grande empresa e o analisa sob a perspectiva das boas práticas de testes do modelo TMM. É realizado um mapeamento do Processo de Testes com o modelo para observar o cumprimento dos objetivos, e em seguida é proposta uma melhoria do processo baseando-se no mapeamento. Esse trabalho tem como principais contribuições:

Comunicações

I Simpósio Brasileiro de Testes de Software, Novembro de 2006

38 - 53