Universidade Estadual de Campinas Faculdade de Engenharia Eltrica e Computao

Critrios de Teste de Software Orientado a Objetos

Autores: Eder Ignatowicz e Liniquer K. Vieira

Professor: Mario Jino

Sumrio
1 Lista de Figuras ................................................................................................................................. 4 Lista de Tabelas ........................................................................................................................................ 5 1. Introduo ......................................................................................................................................... 6 2 Paradigmas de Programao ............................................................................................................. 8 3 Definies e Conceitos Bsicos ...................................................................................................... 10 3.1 Classes ..................................................................................................................................... 10 3.2 Objetos .................................................................................................................................... 10 3.3 Encapsulamento ...................................................................................................................... 11 3.4 Herana ................................................................................................................................... 11 3.5 Polimorfismo ........................................................................................................................... 12 3.6 Clusters (pacote) ..................................................................................................................... 12 4 Tipos de Defeito em O.O ................................................................................................................ 14 4.1 Encapsulamento ...................................................................................................................... 14 4.2 Herana ................................................................................................................................... 14 4.3 Polimorfismo ........................................................................................................................... 15 5 Fases de teste................................................................................................................................... 16 6 Teste Baseado em Especificao .................................................................................................... 18 6.1 Critrios de Teste Baseados na Estrutura do Diagrama de Casos de Uso .............................. 19 6.2 Teste Baseado em Programa ................................................................................................... 24 6.2.1 Teste de Mutao ................................................................................................................ 24 6.2.2 Grupos de operadores de mutao OO ............................................................................... 24 6.2.3 Estudo de caso ..................................................................................................................... 25 7 Ferramentas ..................................................................................................................................... 30 7.1 JUnit ........................................................................................................................................ 30 8 Concluses ...................................................................................................................................... 32 9 Bibliografia ..................................................................................................................................... 33

1 Lista de Figuras
Figura 1 - Clusters ................................................................................................................................... 13 Figura 2 - Componentes de um caso de uso............................................................................................ 18 Figura 3 - Critrio todas as comunicaes [AC03] ................................................................................. 20 Figura 4 - Diagrama de casos de uso genrico [AC03] .......................................................................... 20 Figura 5 - Critrio todos os inclusores[AC03] ....................................................................................... 21 Figura 6 - Critrio todos os includos[AC03] ......................................................................................... 21 Figura 7 - Critrio todas as incluses ...................................................................................................... 21 Figura 8 - Diagrama de casos de uso genrico........................................................................................ 22 Figura 9 - Critrio todos os estendidos ................................................................................................... 22 Figura 10 - Critrio todos os extensores ................................................................................................. 23 Figura 11 - Critrio todas as extenses ................................................................................................... 23 Figura 12 - Comparao dos Critrios .................................................................................................... 23 Figura 13 - Diagrama de estudo de caso ................................................................................................. 26 Figura 14 - Mutao Inherit .................................................................................................................... 27 Figura 15 - Associate .............................................................................................................................. 27 Figura 16 Member ................................................................................................................................ 28 Figura 17 Access .................................................................................................................................. 29 Figura 18 - Exemplo JUnit ...................................................................................................................... 31

Lista de Tabelas

Tabela 1 - Diferenas entre programao OO e procedimental. [Vicenzi] ............................................... 9 Tabela 2 - Relao entre fases de teste de programas procedimentais e OO. ......................................... 17

1. Introduo
O teste de software pode ser visto como uma atividade de Verificao, Validao e Teste, e tem como objetivo encontrar o maior nmero possvel de erros com uma quantidade de esforo gerencivel aplicada durante um intervalo de tempo realstico [Pre06]. Tambm objetivo dos testes a construo de casos de teste capazes de cobrir diferentes classes de defeitos com o mnimo de tempo e esforo. vlido lembrar que o teste no mostra a ausncia de defeitos em um software, apenas pode mostrar que defeitos esto presentes [Pre06]. Mesmo com a evoluo constante dos mtodos, tcnicas e ferramentas de desenvolvimento de software, defeitos podem ser introduzidos, e somente uma atividade especfica de teste pode descobrir a ocorrncia de determinados defeitos no software. O teste pode ser realizado em diversas etapas de um projeto de software e consiste em ser adequado para cada uma dessas etapas [Pre06]. A cada tcnica esto associados critrios de teste. Um critrio um predicado a ser satisfeito pelos casos de teste e pode ser utilizado para avaliar um conjunto de casos de teste. O critrio fornece uma medida de cobertura dada pelo nmero de elementos requeridos que foram satisfeitos pelos casos de teste que pode ser utilizada para decidir se o programa foi devidamente testado e encerrar a atividade de teste. Atravs das diferentes formas de desenvolver um software so aplicadas determinadas tcnicas de teste. Segundo Pressman [Pre06], o teste em orientao a objetos utiliza diferentes estratgias e tticas para atingir o objetivo quanto ao teste. Esse trabalho tem por objetivo principal apresentar as diversas tcnicas e estratgicas utilizadas para realizar um teste de software em orientao a objetos (OO). Essa monografia segue organizada da seguinte forma: a Seo 2 descreve os conceitos de paradigmas de programao e as diferenas entre programao procedimental e orientada a obetos; a Seo 3 apresenta as principais definies e conceitos bsicos da OO; a Seo 4 mostra os provveis tipos de defeitos que podem ocorrer em funo das novas caractersticas da OO; a Seo 5 descreve as diversas fases de teste e seus objetivos; a Seo 6 apresenta os principais critrios para a realizao de testes baseando-se na especificao de um

programa OO; a Seo 7 mostra as ferramentas disponveis para realizao de testes em OO; finalmente, a Seo 8 faz as consideraes finais deste trabalho.

2 Paradigmas de Programao
Paradigma de programao a forma com que o programador enxerga a soluo de um problema, ou seja, a maneira com que o mesmo desenvolve uma aplicao ou um programa. Novos paradigmas de programao so desenvolvidos com o objetivo de suprir as deficincias dos paradigmas j existentes. No paradigma procedimental, a nfase dada ao desenvolvimento de procedimentos e a comunicao realizada por passagem de dados, seu objetivo estruturar um problema na forma de um conjunto de dados e procedimentos que manipulam esses dados. Esse paradigma possui uma grande desvantagem, pois quando grandes problemas precisam ser solucionados, a dependncia entre os procedimentos e os dados torna-se muito grande, fazendo com que pequenas alteraes em como os dados esto organizados podem levar a alteraes na forma com que os procedimentos acessam esses dados. [VDDM07]. A fim de fornecer um mecanismo que isole os dados da forma como so manipulados surgiu o paradigma de orientao a objetos. A orientao a objetos agrupa os atributos e mtodos em uma entidade esttica denominada classe. Desse modo, em vez de estruturar o problema em termos de dados e procedimentos/funes, na orientao a objetos o desenvolvedor incentivado a pensar em termos de classes e objetos que podem ser encarados como uma abstrao de mais alto nvel [VDDM07]. Pressman [Pre06] descreve que utilizando o paradigma OO o domnio do problema caracterizado como um conjunto de objetos que possuem propriedades e comportamentos especficos e se comunicam por meio de mensagens. No entanto, Vincenzi et al. [VDDM07] alertam que o uso da orientao a objetos no garante a correo de um programa por si prprio, pois no impede que os desenvolvedores cometem enganos durante o desenvolvimento de um produto de software. Alm disso, novos conceitos que surgiram com o paradigma OO apresentam-se como novos desafios no que diz respeito a teste de software, pois novos tipos de defeitos precisam ser considerados. [Pre06] Na tabela 1 podemos verificar as diferenas entre programao OO e procedimental e a evoluo entre esses paradigmas.

Programao Orientada a Objetos Mtodos Variveis de Instncias Mensagens Classes Heranas Polimorfismo

Programao Estruturada Procedimentos e funes Variveis Chamadas a procedimentos e funes Tipos de dados definidos pelo usurio -

Tabela 1 - Diferenas entre programao OO e procedimental. [Vicenzi]

3 Definies e Conceitos Bsicos

Neste captulo so apresentados os conceitos bsicos das principais caractersticas da orientao a objetos, sempre utilizando a linguagem Java como motivador.

3.1 Classes
Uma classe uma entidade esttica que engloba atributos (ou dados) e mtodos (ou funes-membro) que representam operaes que podem ser realizadas sobre os dados. [VDDM07] No prximo exemplo, construmos uma classe chamada Carro, que mantm os dados relativos de um carro, a qual possui uma declarao de uma varivel cor que da classe Cor, uma varivel List denominada pneus da classe Pneu e finalmente uma varivel List denominada Roda da classe Roda.

public class Carro { Cor cor; List<Pneu> pneus; List<Roda> rodas; } Para uma classe ser compilada, no necessrio a definio de atributos ou mtodos. A declarao abaixo tambm vlida e compilada corretamente, mesmo que sem nenhum mtodo ou atributo. public class Carro {

3.2 Objetos
Um objeto uma instncia de uma classe criada em tempo de execuo. Cada objeto tem uma cpia dos dados existentes na classe e encapsula estado e comportamento. [VDDM07] 10

A instruo abaixo instancia um objeto da classe Carro, a qual possui todas as caractersticas da mesma. Carro astra = new Carro();

3.3 Encapsulamento
O encapsulamento uma forte caracterstica da programao orientada a objetos. a capacidade que um objeto tem de impedir que outros objetos tenham acesso aos seus dados, garante a ocultao de informaes na qual a interface e implementao de uma classe so separadas sintaticamente.[MTW] No exemplo abaixo podemos verificar a existncia de uma classe pblica Carro, a qual possui declaraes de variveis privadas, ou seja, essas variveis s podero ser acessadas por mtodos contidos dentro da classe, o que garante o encapsulamento. public class Carro { private Cor cor; private List<Pneu> pneus; private List<Roda> rodas; }

3.4 Herana
Atravs da herana novas classes podem ser criadas a partir de outras j existentes. Utilizando a herana, as classes so inseridas em uma hierarquia de especializao, de modo que uma classe mais especializada herda todas as propriedades das classes mais genricas. A classe mais genrica d-se o nome de superclasse (classe-pai), e a mais especializada d-se o nome de subclasse (classe-filha). Atravs da herana, uma subclasse pode estender ou restringir as caractersticas herdadas da superclasse. [MTW] No prximo exemplo apresenta-se uma classe pblica Carro que estende uma classe Automvel. Logo a classe carro uma subclasse da classe Automvel (superclasse), e herda todas as caractersticas da mesma. public class Carro extends Automovel { }

11

3.5 Polimorfismo
O termo polimorfismo representa a qualidade ou estado de um objeto ser capaz de assumir diferentes formas [VDDM07]. No exemplo abaixo inicialmente instanciado um objeto Carro. Considerando que a classe Carro estende a classe Automvel e toda classe do Java estende uma classe Object, logo podemos instanciar um objeto da classe Automovel recebendo um objeto do tipo Carro e um objeto do tipo Object recebendo um objeto do tipo Automvel que nenhum problema ocorrer. Carro carro = new Carro; Automovel auto = (Automovel) carro; Object obj = (Object) auto;

3.6 Clusters (pacote)

Um conjunto de classes que cooperam entre si na implementao de determinadas funcionalidades [VDDM07]. As classes que constituem um cluster podem estar fortemente acopladas e trabalhar juntas para fornecer um comportamento unificado, ou ser independentes e fornecer diversos tipos de funes similares. [MTW] Em Java, uma classe Carro que pertence a um pacote br.testeorientacao possui o nome completo br.testeorientacao.Carro. Na figura 1 podemos verificar os pacotes conforme os diretrios de uma aplicao organizados conforme o seu relacionamento.

12

Figura 1 - Clusters

13

4 Tipos de Defeito em O.O

Binder [Bin99] descreve que os tipos de defeitos que um desenvolvedor pode cometer so limitados pelas formas similares utilizadas de se expressar o que se tem na mente, bem como o que se utiliza para desenvolver. A programao orientada a objetos pode reduzir a ocorrncia de alguns tipos de defeitos encontrados na programao procedimental, mas a partir da aplicao de suas novas caractersticas e conceitos, acaba por introduzir outros tipos. Segundo Pressman [Pre06], apesar de se ter o mesmo objetivo fundamental quanto ao teste, o teste em OO utiliza diferentes estratgias e tticas. Novos conceitos que surgiram com o paradigma OO apresentam-se como novos desafios no que diz respeito a teste de software, pois novos tipos de defeitos precisam ser considerados. So apresentados nessa seo, alguns dos defeitos mais provveis de ocorrer dadas as novas caractersticas citadas na seo acima. Esse contedo foi extrado de Vincenzi et al. [VDDM07].

4.1 Encapsulamento
Atravs do encapsulamento, possvel controlar o acesso indesejvel de atributos e mtodos dentro de uma classe, pois se refere ao tratamento de visibilidade dos mesmos. O encapsulamento no contribui diretamente para a ocorrncia de defeitos, mas apresenta-se como um obstculo para as atividades de teste por no se ter conhecimento do estado de determinados atributos de um objeto em determinados momentos, atributos esses com visibilidade privada. Como soluo pode ser aplicada a implementao de todos os mtodos get e set a todos os atributos da classe [Har00], ou a utilizao de recursos de reflexo computacional [RM98].

4.2 Herana

14

Atravs da herana possvel compartilhar atributos e mtodos de uma classe a uma nova classe gerada a partir dela. Permite a reusabilidade compartilhando caractersticas presentes em classes ancestrais. Contudo, Binder [Bin99] destaca que a herana enfraquece o encapsulamento e pode ser responsvel pela criao de um risco de defeito similar ao uso de variveis globais em programas procedimentais. Grandes hierarquias de herana podem tambm ser responsveis por provocar enganos frequentes de desenvolvedores, gerando defeitos causadores de falhas. Portanto, necessrio ter a compreenso dos detalhes de implementao das classes ancestrais.

4.3 Polimorfismo
O polimorfismo caracteriza a possibilidade de um mesmo nome ser utilizado para representar instncias de vrias classes. A aplicao do polimorfismo muito comum em conjuntos hierrquicos formados. Porm o polimorfismo propicia riscos de possveis defeitos no software como indecibilidade no acoplamento dinmico, extensibilidade de hierarquias, containers heterogneas e type casting [VDDM07].

Barbey e Strohmeier [BS94] descrevem alguns riscos de possveis defeitos no software ocasionados pelo uso do polimorfismo:
Indecidibilidade no Acoplamento Dinmico Extensibilidade de Hierarquias Containers Heterogneos e Type Casting

15

5 Fases de teste
A atividade de teste dividida em vrias fases com diferentes objetivos. Na literatura encontram-se diferentes variaes quanto diviso das fases de teste. Pressman [Pre06] define as seguintes fases: Teste de unidade: Visa identificar os erros de lgica e de implementao, corresponde a verificao da menor unidade do software. A tcnica de teste estrutural e o teste de mutao so freqentemente utilizados nessa fase. Teste de integrao: Inicia-se aps a fase de teste de unidade. Verifica a integrao entre os mdulos do software e busca os erros de interface entre os mesmos. A tcnica de teste funcional a mais utilizada durante essa fase. Teste de validao: Verifica se o produto est de acordo com a especificao dos requisitos do software. Idealizado a partir de uma serie de testes funcionais cujos resultados demonstram a conformidade aos requisitos. Teste de sistema: Exercita o software por completo. composto por diferentes testes especficos os quais verificam se todos os elementos do software esto integrados e executam suas respectivas funes. Duas abordagens diferentes sobre as fases de teste de software OO so apresentadas a seguir. Harrold e Rothermel [HR94] definem o mtodo como a menor unidade a ser testada. O teste de unidade corresponde ao teste intramtodo. O teste de integrao representado por testes intermtodos, Intraclasses e intraclasses. J para Pressman [Pre06], apesar de considerar que as operaes (mtodos) de uma classe so a menor unidade testvel, devido a essas operaes poderem fazer parte de certo nmero de classes diferentes, a ttica aplicada ao teste de unidade precisa modificarse, no podendo ser a operao a base do teste unitrio. O teste de sistema tem o mesmo significado e a mesma forma de aplicao para ambas as abordagens. A tabela 2 apresenta os tipos de teste que podem ser aplicados em cada uma das fases em programas orientados a objetos ou procedimentais, considerando o mtodo ou a classe como menor unidade a ser testada.

16

Menor Unidade: Mtodo Fase Unidade Integrao Sistema Teste Procedimental Intraprocedimenta l Interprocedimenta l Toda Aplicao Teste Orientado a Objetos Intramtodo Intermtodo, Intraclasse e Interclasse Toda Aplicao

Menor Unidade: Classe Fase Unidade Integrao Sistema Teste Procedimental Intraprocedimental Interprocedimental Toda Aplicao Teste Orientado a Objetos Intramtodo, intermtodo e Intraclasse Interclasse Toda Aplicao

Tabela 2 - Relao entre fases de teste de programas procedimentais e OO.

17

6 Teste Baseado em Especificao

Esta seo apresenta o conjunto de critrios proposto por Chaim[AC03] para realizao de testes baseando-se na especificao de um programa orientado a objetos. A especificao de um software geralmente feita atravs da notao UML. A UML uma linguagem visual, que tem como objetivo fornecer uma maneira comum de capturar e expressar relaes, comportamentos e idias de um nvel mais alto na forma de notaes. A UML visa expressar a modelagem de um software da maneira mais simples e eficiente possvel [DP05]. Na linguagem UML os diagramas de caso de uso so utilizados para capturar as funcionalidades e requisitos do sistema. Estes diagramas descrevem a interao entre um usurio e um sistema. Um diagrama de caso de uso apresenta o relacionamento entre um ator e um caso de uso. Os dois principais componentes de um diagrama de caso de uso so os casos de uso e os atores (Figura 2) [DP05]. Um ator uma representao de um usurio ou outro sistema que ir interagir com o sistema que est sendo modelado. Um caso de uso uma viso externa do sistema que representa uma ao que o usurio possa executar, a fim de completar uma tarefa [DP05]. De acordo com Fowler [DP05], diagramas de caso de uso devem ser usados na maior parte dos projetos de software, pois so teis na obteno de requisitos e planejamento do projeto.

Figura 2 - Componentes de um caso de uso

Chaim [AC03] define em seu trabalho uma srie de critrios de teste para a gerao de testes de cobertura em diagramas de casos de uso. Segundo [livro do jino] estes critrios almejam assegurar que casos de testes garantam a cobertura dos casos de uso utilizados 18

para modelar sistemas orientados a objetos. A idia bsica dos critrios assegurar que interaes entre casos de uso e entre atores sejam exercitadas de forma a exercitar todas as comunicaes, incluses e extenses presentes no diagrama. Desta forma alguns elementos estruturais foram escolhidos por Chaim[AC03] na criao dos critrios: os relacionamentos de comunicao entre atores e casos de uso e relacionamentos de incluso e extenso entre casos de uso. A definio de critrios til pois estabelece um critrio de quantificao e parada da atividade de testes.

6.1 Critrios de Teste Baseados na Estrutura do Diagrama de Casos de

Uso
Esta seo detalha cada critrio estabelecido por Chaime detalhado em Carniello[AC03]. O primeiro tipo de critrios a ser definido neste trabalho o critrio baseado em relacionamentos de comunicao. Um relacionamento de comunicao definido quando um caso de uso iniciado diretamente por um ator. Desta forma os critrios baseados em relacionamento de comunicao so listados a seguir.
1. Critrio todas as comunicaes: Um conjunto de dados de teste T satisfaz o critrio todas as comunicaes se cada relacionamento de comunicao que inicia um caso de uso do diagrama D estiver sido exercitado pelo menos uma vez. Como a linguagem UML no apresenta uma notao especial para identificar qual ator inicia o caso de uso, apresentada uma tarja especial sobre a relao de comunicao e esta identificada atravs da leitura da especificao do caso de uso (Figura 3).

19

Figura 3 - Critrio todas as comunicaes [AC03]

A segunda categoria de critrios so os critrios baseados no relacionamento de incluso. Estes so aplicados aos casos de uso de um diagrama que mantm relacionamentos de incluso entre si. Em um relacionamento de incluso, o caso de uso includo e passa a fazer parte de outro caso de uso. Os critrios apresentados por Carniello[AC03] utilizam o diagrama genrico apresentado na Figura 4. Desta forma os critrios baseados em relacionamento de incluso so listados a seguir.

Figura 4 - Diagrama de casos de uso genrico [AC03]

1. Critrio todos os inclusores: Um conjunto de dados de teste T satisfaz o critrio todos os inclusores se cada caso de uso inclusor do diagrama D tiver exercitado pelo menos um caso de uso includo (Figura 5). Este critrio assegura que cada caso de uso inclusor tenha pelo menos exercitado um caso de uso includo exercitando desta forma todos os casos de uso inclusores do diagrama.

20

Figura 5 - Critrio todos os inclusores[AC03]

2. Critrio todos os includos: Um conjunto de dados de teste T satisfaz o critrio todos os includos se cada caso de uso includo do diagrama D tiver sido exercitado pelo menos uma vez. A aplicao deste critrio certifica o exerccio de todos os casos de uso includos do diagrama (Figura 6).

Figura 6 - Critrio todos os includos[AC03]

3. Critrio todas as incluses: Um conjunto de dados de teste T satisfaz o critrio todos as incluses se cada relacionamento de incluso entre dois casos de uso de D tiver sido exercitado pelo menos uma vez (Figura 7).

Figura 7 - Critrio todas as incluses

A terceira categoria de critrios so os critrios baseados no relacionamento de extenso e so aplicados aos casos de uso que mantm relacionamentos de extenso com outros casos de uso. 21

Os critrios apresentados por Carniello[AC03] utilizam o diagrama genrico apresentado na Figura 8. Desta forma os critrios baseados em relacionamento de extenso so listados a seguir.

Figura 8 - Diagrama de casos de uso genrico

1. Critrio todos os estendidos: Um conjunto de dados de teste T satisfaz o critrio todos os estendidos se, para cada caso de uso estendido do diagrama D tiver exercitado pelo menos um caso de uso extensor (Figura 5). Este critrio assegura que cada caso de uso extensor tenha pelo menos exercitado um caso de uso estendido exercitando desta forma todos os casos de uso extensores do diagrama.

Figura 9 - Critrio todos os estendidos

2. Critrio todos os extensores: Um conjunto de dados de teste T satisfaz o critrio todos os extensores se cada caso de uso extensor do diagrama D tiver sido exercitado pelo menos uma vez. A aplicao deste critrio certifica o exerccio de todos os casos de uso extensores do diagrama (Figura 10).

22

Figura 10 - Critrio todos os extensores

3. Critrio todas as extenses: Um conjunto de dados de teste T satisfaz o critrio todos as extenses se cada relacionamento de extenso entre dois casos de uso de D tiver sido exercitado pelo menos uma vez (Figura 11).

Figura 11 - Critrio todas as extenses

A Figura 12 apresenta uma comparao dos critrios apresentados. Vale salientar que alguns critrios no apresentados nesta monografia so combinaes dos critrios anteriores.

Figura 12 - Comparao dos Critrios

23

6.2 Teste Baseado em Programa

De acordo com Jino[JIMADE] um problema do teste baseado em especificao que este est sujeito s inconsistncias decorrentes de uma especificao de m qualidade devido a esta ser a base da criao dos casos de teste. Esta m qualidade justifica-se pela forma descritiva e informal da linguagem UML e desta forma os requisitos derivados da especificao tambm so, de certa forma, descritivos e informais. Desta forma utilizam-se alguns critrios estruturais de fluxo de controle e de dados e critrios baseados na especificao. A prxima seo detalhar o teste de mutao em programas OO.

6.2.1

Teste de Mutao

Teste de mutao uma tcnica popular para aferir qualidade de uma sute de teste. Pequenas modificaes sintticas so introduzidas em um programa de forma a criar

verses modificadas de um, conhecidas como mutantes, que servem como simuladores de erro. Tipicamente os mutantes contm um pequeno defeito, consistente com a prtica de desenvolvimento de uma equipe. Mutantes sobreviventes ao teste (isto , para o qual no h teste na sute que observe sua diferena de comportamento) indicam necessidade de novos casos de teste na sute. A aplicao de teste de mutantes a softwares orientado a objetos tem como objetivo investigar resultados de operadores de mutao OO aplicados a uma especificao UML e ao cdigo fonte. O grupo de operadores de mutao apresentados nesta seo e o estudo de caso so baseados no artigo de Anna Derezinska Object-Oriented Mutation to Asses the Quality of Tests. [AD]

6.2.2 Grupos de operadores de mutao OO

No seu trabalho, Derezinska[AD]define alguns operadores de mutao OO que so listados a seguir:

24

1. Inherit (Inh) Muda a classe base ou omite a relao de herana; 2. Associate (Ass) Muda a associao entre classes; 3. Object (Obj) Acessa um membro em outro objeto da mesma classe ou membro em outra classe da mesma hierarquia de herana; 4. Member (Mem) Acessa dado ou funo diferente do objeto; 5. Access (Acc) Muda o especificador de acesso relacionados ao dado, s funes, ou s classes em um relacionamento de herana.

O estudo de caso a seguir apresentar um estudo de caso aplicando cada um destes operadores.

6.2.3 Estudo de caso

O diagrama da Figura 13 apresenta um exemplo de diagrama UML para um modelo de carro. Baseado neste modelo sero gerados mutantes para cada operador de mutao proposto no trabalho de Derezinska [AD].

25

Figura 13 - Diagrama de estudo de caso

Como visto, o operador Inherit adiciona, omite ou muda a direo de um relacionamento de herana. Desta forma pode ser criado um mutante baseado no diagrama modificado abaixo;

26

Figura 14 - Mutao Inherit

Com o operador Associate possvel modificar a direo de uma associao, modificar o relacionamento de agregao para associao como no diagrama da figura abaixo:

Figura 15 - Associate

27

Atravs do operador Member, podemos chamar a funo herdada da classe base, criar funes da mesma classe e acessar dados diferentes.

Figura 16 Member

Com o operador de mutao Access podemos modificar uma funo de public para protected ou uma herana de public para private por exemplo.

28

Figura 17 Access

De acordo com o artigo de Derezinska, os operadores Inherit, Associate e Access foram aplicados para especificaes UML. J os grupos Object e Member foram aplicados diretamente no cdigo fonte. Contudo alguns mutantes foram invalidados diretamente pelo compilador. Com os mutantes equivalentes foram selecionados casos de teste baseado nos testes tradicionais. Atendendo o critrio de seleo por mutantes o artigo obteve uma cobertura de 83% das funes e 85% das linhas de cdigo.

29

7 Ferramentas
Como a atividade de testes propensa a erros e improdutiva, a eficaz aplicao de um critrio de testes est condicionada a sua automatizao. A utilizao de ferramentas de testes propicia uma maior qualidade e produtividade de uma equipe de testes. A prxima seo apresentar uma viso geral do framework para automatizao de testes Junit.

7.1 JUnit
De acordo com Neto [AVPN], O JUnit um framework open-source, criado por Eric Gamma e Kent Beck, com suporte criao de testes automatizados na linguagem de programao Java. O framework foi criado com o objetivo de facilitar a criao de cdigo para a automao de testes unitrios. Com ele, pode ser verificado se cada mtodo de uma classe funciona da forma esperada, exibindo possveis erros ou falhas podendo ser utilizado tanto para a execuo de baterias de testes como para extenso. A IBM[IBM] apresenta alguma das vantagens da utilizao do JUnit:

Permite a criao rpida de cdigo de teste possibilitando um aumento na qualidade do desenvolvimento e teste;

Amplamente utilizado pelos desenvolvedores da comunidade cdigo-aberto, possuindo um grande nmero de exemplos;

Uma vez escritos, os testes so executados rapidamente sem que, para isso, seja interrompido o processo de desenvolvimento;

JUnit checa os resultados dos testes e fornece uma resposta imediata; JUnit livre e orientado a objetos.

A figura apresenta um pequeno exemplo da utilizao do JUnit sobre uma classe exemplo valor.

30

Figura 18 - Exemplo JUnit

31

8 Concluses
Foram apresentadas nesse trabalho as diferenas entre os paradigmas de programao procedimental e programao orientada a objetos, assim como os principais conceitos e definies bsicas sobre OO. As fases de teste e as questes relativas s estratgias e tcnicas de testes orientados a objetos foram descritas. Apresentou-se tambm a ferramenta de teste JUnit, tendo em vista a importncia da automatizao da atividade de teste. Como j visto, apesar da programao orientada a objetos trazer alguns benefcios tambm implica em ocasionar novas dificuldades para atividade de teste, pois suas novas caractersticas acabam por introduzir novos erros. Portanto, cada vez mais novos critrios de teste esto sendo desenvolvidos a partir daqueles j existentes para o teste de programas procedimentais.

32

9 Bibliografia
[Pre06] R. S. Pressman. Engenharia de Software. McGraw-Hill, 2006. [Har00] M. J. Harrold. Testing: A roadmap. In In The Future of Software Engineering, pages 61_72. ACM Press, 2000. [RM98] A. C. A. Rosa and E. Martins. Using a Re_ective Architeture to Validade Object-Oriented Applications by Fault Injection. pages 76_80. Proc. of the Workshop on Re_ective Programming in C++ and Java, October 1998. [VDDM07] A. M. R. Vincenzi, A. L. S. Domingues, M. E. Delamaro, and J. C. Maldonado. Teste Orientado a Objetos e de Componentes. In M. C. Delamaro, J. C. Maldonado e M. Jino, Introduo ao Teste de Software, pages 119_174. Ed. Campus-Elsevier, Setembro 2007. [RdSSMM05] A. D. Rocha, A. da S. Simo, J. C. Maldonado, and P. C. Masiero. Uma ferramenta baseada em aspectos para o teste funcional de programas Java - ICMC/USP. XIX Simpsio Brasileiro de Engenharia de Software (SBES2005) - Universidade Federal de Uberlndia, 2005. [Bin99] R. V. Binder. Testing Object-Oriented Systems: Models, Patterns, and Tools, volume 1. Addison-Wesley LongMan, Inc., 1999. [HR94] M. J. Harrold and G. Rothermel. Performing data_ow testing on classes. In Proceedings of the SIGSOFT'94 Symposium on the Foundations of Software Engineering, pages 154_163, New Orleans, NO, USA, 1994. ACM Press. [BS94] The Problematics of Testing Object-Oriented Software. Stphane Barbey, Alfred Strohmeier [Vicenzi] Auri Marcelo Rizzo Vicenzi Orientao a Objeto: Definio, Implementao e Anlise de Recursos de Teste e Validao [MTW] G. C. Murphy, P. Townsend e P.S. Wong. Experiences with cluster and class testing. Communications of the ACM, 37(9):39-47, set. 1994. [AC03] A. Carniello, M. Jino, M. L. Chaim Teste Baseado na Estrutura de caso de Uso [DP05] Dan Pilone and Neil Pitman. UML 2.0 in a nutshell. OReilly Media, Inc., 1 edition, 6 2005.

33

[JIMADE] Mrio Eduardo Delamaro, Jos Carlos Maldonado, Mrio Jino, Introduo ao Teste de Software

[AD] Anna Derezinska Object-Oriented Mutation to Asses the Quality of Tests

[AVPN] Aristides Vicente de Paula Neto Criando testes com JUnit (UFPE)

[IBM] Elliotte Rusty Harold, An early look at JUnit 4, Polytechnic University

34