Proposta de Utilização Do Diagrama de Sequência Para Definição de Casos de Teste de Unidade

Proposta de Utilizao do Diagrama de Seqncia para Definio de Casos de Teste de Unidade

Antonio Carlos Silva1

Fabiane Barreto Vavassori Benitti1

Resumo: A etapa de teste de software tem se mostrado cada vez mais relevante no processo de desenvolvimento de software, impactando diretamente na qualidade do produto. Dentre os testes aplicados no software, observa-se que o teste de unidade no apresenta um artefato alinhado com o padro adotado para especificao de software (UML). Neste sentido, apresenta-se uma proposta de utilizao do diagrama de seqncia como artefato para definio de casos de teste, especificamente voltado a teste de unidade, tornando o planejamento de testes independente da linguagem de programao, ampliando as possibilidades de utilizao do artefato. A adequao do diagrama proposto demonstrada atravs de uma ferramenta que permite a gerao do cdigo para execuo com framework JUnit. Palavras-chave: Engenharia de software, teste de software, teste de unidade.

Abstract: The step of software testing has been increasingly relevant in the software development process, directly impacting on the quality of the product. Among the tests applied in the software, it appears that the unit test does not present an artifact aligned with the standard adopted for specification of software (UML). In this sense, it presents a proposal for using the sequence diagram of how to define artifact of test cases, specifically geared to unit test, making the planning of tests regardless of programming language, expanding the possibilities for using the artifact. The suitability of the proposed diagram is demonstrated by using a tool that allows the generation of code to run on JUnit framework.

Keyword: Software engineering, software testing, unit test.

1 Introduo

O teste de software uma das etapas no ciclo de desenvolvimento de software que tem como principal objetivo revelar a presena de defeitos em um software. Esta etapa

1 Centro de Educao de Cincias Tecnolgicas da Terra e do Mar, UNIVALI, Itaja, SC - Brasil {antonio.carlos, fabiane.benitti @univali.br}


140 RITA Volume XV Nmero 2 2008

compreendida por sistemticas aplicaes de testes ao longo de todo o processo de desenvolvimento [1]. A etapa de testes definida por Hetzel [2] como: o processo de executar um programa ou sistema com a finalidade de encontrar erros. Teste a medida de qualidade do software.

Um dos testes iniciais aplicados a um software o teste de unidade, que acontece antes mesmo da total codificao do sistema. O teste de unidade, conhecido tambm por teste de componente ou teste de mdulo, definido por Thomas et al [3], como um teste projetado para verificar uma nica unidade de software de forma isolada das demais unidades. Em projetos orientados a objetos, uma unidade de implementao uma classe ou um mtodo de uma classe.

A tcnica de desenvolvimento TDD (Test Driven Development), proposta por Beck [4], apia-se na aplicao de testes de unidade antes da codificao das unidades propriamente ditas. Alguns dos benefcios atribudos ao uso da tcnica referem-se ao fato de que toda unidade de software possuir um conjunto de testes que verifique seu funcionamento, baseado nos requisitos estabelecidos para esta unidade, assim antecipando a deteco de erros presentes na codificao. A etapa inicial envolvida na aplicao da tcnica o planejamento dos casos de teste, momento em que so definidos os detalhes envolvidos na execuo dos testes, como os dados de entrada e os resultados esperados.

Para o teste de unidade a etapa de planejamento comumente confundida com a codificao dos drivers e stubs, resultando em pouca ou nenhuma documentao aos casos de teste, restando apenas o prprio cdigo fonte dos testes como especificao [4]. Esta deficincia na documentao dos casos de teste, identificada tambm por Runeson [5], pode ser explicada pela falta de uma linguagem padro para definio dos casos de teste e uma ferramenta que apie este processo [6]. Neste ponto, Biasi e Becker [6] apresentam alguns problemas na utilizao de ferramentas para automatizao de testes: (i) o esforo necessrio para preparar o cdigo auxiliar; (ii) nem sempre h distino clara entre as atividades de especificao dos casos de teste e de programao do cdigo auxiliar; e (iii) dependncia do caso de teste da linguagem de programao.

Desta forma, este artigo prope a utilizao do diagrama de seqncia, definido na UML (Unified Modeling Language), como artefato para definio de casos de teste (detalhado na seo 3). Tambm apresenta, na seo 4, uma ferramenta que visa auxiliar na definio dos casos de teste, bem como automatizar a gerao do cdigo fonte de execuo dos testes utilizando o framework JUnit. Na seo 2 so apresentados alguns dos pontos fundamentais da tcnica TDD no que se refere a testes de unidade. Por fim, as consideraes finais e direcionamentos para trabalhos futuros so contempladas na seo 5.

2 Test Driven Development - TDD

O TDD (Test Driven Development) ou Test First tem como base a definio e aplicao de testes de unidade antes mesmo da codificao das unidades envolvidas.


RITA Volume XV Nmero 2 2008 141

Destaca-se ainda que um cdigo para uma unidade de software s pode ser desenvolvido se houver um conjunto de casos de teste para verific-la [7].

A tcnica de desenvolvimento TDD consiste em trs etapas (Figura 1): (i) definio dos casos de teste; (ii) codificao das classes com o objetivo de atender aos casos de teste; e (iii) refatorao. Cada uma destas etapas aplicada a cada unidade de software [4].

Escreve casosde teste

Executa ostestes

Codifica

Refatora

[Testefalhou]

[Teste passou]

[Necessidade derefatorao]

Figura 1. Diagrama de atividades do TDD

A definio dos casos de teste ganha destaque se comparado a abordagem tradicional de teste de software, uma vez que este guiar a codificao do sistema. Nesta etapa so identificados os drivers e stubs para posterior codificao [7].

So os drivers que determinam a execuo dos casos de teste definindo as mensagens entre os objetos envolvidos e as verificaes estabelecidas a partir dos resultados esperados [8]. Comumente este cdigo desenvolvido para atender a uma ferramenta que automatize a execuo dos testes2, como por exemplo, o JUnit da famlia xUnit [9], responsvel pela automatizao de testes desenvolvidos em linguagem Java.

Os stubs de testes tm por objetivo substituir outras unidades de software envolvidas em um caso de teste, eliminando a dependncia entre as unidades [8]. O uso de stubs permite atender ao princpio de isolamento das unidades, em que cada unidade deve ser testada de forma isolada das demais [3] e [10].

A codificao das classes efetuada com base nos casos de teste estabelecidos, tendo como objetivo o xito na execuo dos testes. Na etapa de refatorao o cdigo desenvolvido para atender aos casos de testes avaliado de forma a verificar questes como flexibilidade, reaproveitamento de cdigo, desempenho, clareza na soluo e duplicidade no cdigo [7].

2 A automatizao dos testes de unidade um dos requisitos no uso da tcnica TDD,

sabendo-se que os testes so executados com grande freqncia na implementao das unidades [4].



3 Definindo casos de teste

Na etapa de planejamento dos casos de teste so especificados os dados de entrada e os resultados esperados, bem como todo o fluxo de execuo do caso de teste como, por exemplo, as mensagens trocadas entre os objetos.

A pouca padronizao na definio de casos de teste destacada por Biasi e Becker [6], Badri, Badri e Bourque-Fortin [11] e Linzhang et al. [12]. Observa-se, ainda, que no padro proposto pela IEEE [10] para testes de unidade tambm no abordada uma linguagem para definio de casos de testes. Dentre as solues j propostas, destaca-se a de Xu, Xu e Nygard (2005 apud [11]), que propem a definio dos casos de teste tendo como base o diagrama de estados. No entanto, uma das limitaes desta proposta refere-se ao fato de que os elementos deste diagrama no esto diretamente relacionados s unidades de software. A fim de contornar este problema Badri, Badri e Bourque-Fortin [11] apresentam novos conceitos e definies ao diagrama de estados. Assim, a proposta de uma representao visual, baseado na UML e utilizando to somente os recursos j especificados na linguagem, favorece a aplicabilidade por parte dos analistas e o suporte por ferramentas j existentes.

O diagrama de seqncia um dos diagramas disponibilizados pela UML para modelagem das interaes na etapa de projeto, no entanto, propem-se a sua utilizao para etapa de teste. A Figura 2 resume a proposta de utilizao do diagrama de seqncia como linguagem visual para definio de casos de teste, destacando os principais elementos envolvidos.



Figura 2. Diagrama de seqncia utilizado para definio dos casos de teste

Durante a elaborao do caso de teste devem ser definidas mensagens entre o driver (gerenciador dos casos de teste) e os objetos envolvidos neste. Para representao do driver utilizou-se a figura do ator, elemento j existente no diagrama de seqncia, denotando o responsvel por invocar os mtodos dos objetos envolvidos nos casos de teste, sendo apresentado esquerda do diagrama, como demonstrado na Figura 2 (A).

Conforme abordado na seo 2, a utilizao de stubs em casos de teste fundamental para garantir o isolamento da unidade testada, desta forma, um stub no diagrama proposto representado como um objeto acrescido do esteretipo , conforme a Figura 2 (B).

Outro recurso pertinente quando da criao de casos de teste refere-se ao SetUp. Este recurso permite definir objetos compartilhados por todos os casos de teste de uma classe, ou seja, considerados como de uso global. Assim, quando utilizado o SetUp de uma classe no diagrama de seqncia exibida ao fim da linha de vida de cada objeto a mensagem from SetUp, conforme a Figura 2 (C), evidenciando o uso de objetos compartilhados.

Para todo caso de teste definido deve ser includo um objeto Assert, como demonstrado na Figura 2 (D). O elemento Assert representa a classe de mesmo nome do framework xUnit sendo responsvel pela verificao do caso de teste. Ressalta-se que esta classe padronizada nos frameworks da famlia xUnit, ou seja, a sua utilizao independe da linguagem de implementao.



Destaca-se que para definio de um caso de teste utilizando o diagrama de seqncia basta que sejam definidos os objetos envolvidos no teste e as mensagens trocadas entre estes, com isso obtm-se um padro baseado em uma linguagem j estabelecida e de conhecimento de muitos dos analistas e testadores envolvidos no processo de desenvolvimento de software.

Com o objetivo de demonstrar a viabilidade na utilizao deste diagrama como forma de especificao de casos de testes, a seo 4 apresenta a proposta de uma ferramenta que permite a gerao automtica do cdigo de teste de unidade a partir de um caso de teste, definido visualmente atravs do diagrama de seqncia, elaborado conforme descrito nesta seo.

4 Ferramenta para apoio no planejamento dos casos de teste A ferramenta tem como objetivo permitir a criao de um projeto de casos de teste,

focando testes de unidade considerando o contexto de um mtodo (unidade). Para tanto, faz-se necessrio que o modelo de classes do projeto testado esteja definido, pois este compreende a base dos testes. Sendo assim, a ferramenta apia-se nas etapas definidas no diagrama de atividades ilustrado na Figura 3.

Inicio

Importar Modelo de Classes Definir casos de teste

Validar projeto Gerar cdigo fonteCdigo para os casosde teste gerado

Figura 3. Diagrama de atividades para a ferramenta

1. Importar modelo de classes: permite conhecer o modelo de classes a ser testado, devendo ser compatvel com o padro XMI 2.13;

2. Definir casos de teste: nesta etapa, utilizando o formato do diagrama de seqncia proposto, o usurio define os casos de teste para os mtodos do modelo importado;

3. Validar projeto: aps a definio dos casos de teste a ferramenta permite a validao dos casos de teste, fazendo crticas a possveis problemas encontrados nos casos de teste; e

3 Observa-se que as ferramentas efetuam implementaes particulares do padro XMI.

Desta forma, a ferramenta apresentada neste artigo compatvel com a implementao das ferramentas Enterprise Architect 6.5 e 7.0 e Visual Paradigm for UML 6.0.



4. Gerar cdigo fonte: por fim o usurio tem a opo de gerar o cdigo fonte para os casos de teste do modelo, possibilitando sua execuo pelo framework JUnit (inicialmente, para demonstrar a viabilidade do diagrama proposto, optou-se por testar sistemas desenvolvidos na linguagem Java).

Tendo em vista as etapas definidas, a Figura 4 apresenta o diagrama de casos de uso, representando as funcionalidades da ferramenta proposta.

Neste modelo de casos de uso percebe-se comportamentos bsicos para operacionalizar a ferramenta, como abrir, salvar e fechar projeto (UC02, UC03 e UC04). Os demais casos de uso so o foco da ferramenta e, portanto, so detalhados na seqncia abordando sua funcionalidade juntamente com um estudo de caso.

A elaborao do caso de teste (UC05), atravs do diagrama de seqncia, parte da existncia de um modelo de classes com seus respectivos mtodos definidos. Sendo assim, considerando o modelo de classes ilustrado na Figura 5, possvel import-lo na ferramenta (UC01) e iniciar a definio do caso de teste, atravs da interface ilustrada na Figura 6.

Usurio

UC02 - Abrir projeto UC03 - Salvar projeto

UC04 - Fechar projeto

UC01 - Criar projeto

UC05 - Criar caso de teste

UC06 - Definir o SetUp

UC08 - Validar caso de teste

UC07 - Criar Stub

UC09 - Gerar cdigo fonte

Figura 4. Casos de uso para a ferramenta proposta



O estudo de caso o qual apresentado ao longo desta seo, a fim de demonstrar o funcionamento da ferramenta, possui como base o modelo de classes ilustrado pela Figura 5, onde o mtodo adicionaProduto da classe CarrinhoDeCompras ter um caso de teste definido. Este caso de teste visa verificar se ao adicionar produtos ao CarrinhoDeCompras este responder posteriormente de forma correta o nmero de produtos presentes no carrinho.

CarrinhoDeCompras

- produtos: ArrayList

+ CarrinhoDeCompras()+ getTotal() : double+ adicionaProduto(Produto) : void+ retiraProduto(Produto) : boolean+ getNumeroDeProdutos() : int+ esvaziar() : void

Produto

- preco: double- nome: String

+ Produto(String, double)+ getNome() : String+ getPreco() : double+ equals(Object) : boolean

+produtos

0..*

Figura 5. Diagrama de classes do estudo de caso

Alguns aspectos so importantes de serem destacados. Ao solicitar a criao de um novo caso de teste, a partir de um mtodo presente no modelo e importado pela ferramenta (Figura 6 A), apresentado ao usurio o diagrama de seqncia com alguns elementos pr-definidos, conforme observado em (Figura 6 B):

Gerenciador (CarrinhoDeComprasTest): responsvel por gerenciar o caso de teste e do qual partiro todas as mensagens;

Stubs: a ferramenta identifica com base na assinatura do mtodo ser testado, quais Stubs so necessrios para sua chamada. Caso no exista nenhum Stub j criado do tipo necessrio, um novo Stub adicionado, devendo usurio definir seu comportamento; e

Objeto Assert, que compe o framework JUnit e responsvel pela verificao do casos de teste.

No caso da figura 6, tem-se os elementos propostos para o caso de teste do mtodo AdicionaProduto da classe CarrinhoDeCompras, apresentado na Figura 4. O Stub de nome stubProduto, presente no caso de teste, tem por objetivo permitir que o mtodo adicionaProduto da classe CarrinhoDeCompras possa ser invocado sem a necessidade de que seja instanciado um objeto do tipo Produto, fortalecendo assim o princpio do isolamento destacado por IEEE [10].



Figura 6. Interface para definio e visualizao do caso de teste

O UC06 permite ao usurio a definio do SetUp, conforme exemplo ilustrado na Figura 7, em que criado um objeto com nome de carrinho, como instncia da classe CarrinhoDeCompras, sendo que para sua criao selecionado o construtor padro da classe.

Figura 7. Interface para definio dos objetos do SetUp

Outra funcionalidade necessria a criao de um Stub para uma classe (UC07). Esta funcionalidade obtida a partir da seleo de uma das classes do modelo, quando a ferramenta apresenta a interface para criar um novo Stub, conforme demonstra a Figura 8a e inclu-lo em um caso de teste Figura 7b.



Figura 8a. Interface para criao de um novo Stub

Figura 8b. Interface para adicionar um Stub ao caso de teste

Com os elementos do caso de teste definidos, pode-se ento estabelecer as mensagens entre o gerenciador do caso de teste e os demais objetos (comportamento previsto para o UC05). Para definio de uma mensagem em um caso de teste utilizada a interface apresentada na Figura 9, devendo ser indicado o mtodo que ser invocado e o valor dos parmetros (se necessrio).

Figura 9. Interface para definio da mensagem



Para o caso de teste testAdicionaProduto foram definidas quatro mensagens, apresentadas na Figura 10. A primeira delas adiciona o Stub stubProduto ao objeto carrinho (Figura 10 A), a mensagem seguinte invoca o construtor da classe Produto (Figura 10 B), a fim de construir o objeto produto1 o qual adicionado ao objeto carrinho na mensagem seguinte (Figura 10 C). Por fim, a ltima mensagem do caso de teste verifica se o nmero de produtos do objeto carrinho corresponde ao valor esperado (Figura 10 D).

Figura 10. Caso de teste testAdicionaProduto

Utilizando a opo de validao (UC08), o sistema apresenta crticas quanto aos possveis problemas encontrados nos casos de teste definidos pelo usurio. Estas crticas referem-se, por exemplo, a casos de teste que no possuem chamadas aos mtodos da classe Assert do framework JUnit, ou mtodos que no possuem casos de teste, ou mesmo casos de teste que no possuam pelo menos uma chamada ao mtodo testado, conforme apresentado na Figura 11.



Figura 11. Interface para validao dos casos de teste

A gerao do cdigo fonte dos casos de teste definidos pelo usurio (UC09) realiza a partir da interface demonstrada na Figura 12a. No exemplo apresentado, o cdigo gerado pela ferramenta para o caso de teste AdicionaProduto pode ser visualizado na Figura 12b.

package EcommerceTest.ecommerce; import public class CarrinhoDeComprasTest { ecommerce.CarrinhoDeCompras carrinho; @Before public void setUp() throws Exception { carrinho = new ecommerce.CarrinhoDeCompras( ); } @Test public void testAdicionaProduto() { ecommerce.Produto stubProduto = EasyMock.createMock(ecommerce.Produto.class); this.carrinho.adicionaProduto( stubProduto ); Produto produto1 = new Produto("Padres de Projeto", 48.90); this.carrinho.adicionaProduto( produto1 ); Assert.assertEquals( 2, carrinho.getNumeroDeProdutos() ); } }

Figura 12a. Interface para gerao de cdigo fonte

Figura 12b. Cdigo fonte gerado pela ferramenta



Com o objetivo de apresentar a estrutura utilizada para implementao da ferramenta so exibidos os diagramas de classes de domnio, sendo que cada diagrama representa um dos pacotes da ferramenta: modelo e casoDeTeste.

O diagrama de classes do pacote modelo, apresentado na Figura 13, tem por objetivo manter as informaes necessrias sobre o modelo de classes do projeto ao qual esto sendo criados os casos de teste.

ObservableItemEmpacotavel

- pacote: Pacote- id: String- nome: String

Pacote

- i tens: ArrayList

ObservableMetodo

- id: String- nome: String- tipoDeRetorno: String- visibil idade: Visibil idade- abstrato: boolean- estatico: boolean- casosDeTeste: ArrayList- parametros: ArrayList- classe: Classe- construtor: boolean

Classe

- classes: ArrayList- tipo: String- visibil idade: Visibil idade- metodos: ArrayList- classesExtendidas: ArrayList- stubs: ArrayList- atributos: ArrayList- setUp: SetUp- gerenciador: Gerenciador

Atributo

- visibil idade: Visibilidade

ObservablecasoDeTeste::Stub

- nome: String- metodos: ArrayList

TestecasoDeTeste::CasoDeTeste

- metodoTestado: Metodo- setUp: SetUp

Parametro

TestecasoDeTeste::

SetUp

- classe: Classe

interfaceClassificador

ObservablecasoDeTeste::MetodoStub

- comportamento: Comportamento- metodo: Metodo

enumerationVisibilidade

enum PACOTE PUBLICO PRIVADO PROTEGIDO

ObservableElementoTipado

- id: String- nome: String- tipo: String

Projeto- instance: Projeto- autor: String- dataDeCriacao: Date- descricao: String

interfaceProjetoVisitor

ObservablecasoDeTeste::Objeto

- objetos: ArrayList- id: String- nome: String- classe: Classificador- fromSetUp: boolean- fromStub: boolean

+metodos *

+classe 1

+parametros

*

+metodos *

0

+setUp

1

0

+metodo

1

+itens

0..*

-pacote

0..1

+casosDeTeste

* +metodoTestado 1

+atributos *

+setUp 0..1

+classe

+classe

1

+classesExtendidas 0..*

+stubs

*

+classe

1

Figura 13. Diagrama de classes para o pacote modelo da ferramenta

J o diagrama apresentado na Figura 14, contm as classes do pacote casoDeTeste, o qual responsvel por manter as informaes sobre os casos de teste criados pelo usurio, o qual criado com base na instncia de objetos para as classes do projeto, permitindo ento a troca de mensagens entre estes objetos.



CasoDeTeste

- metodoTestado: Metodo- setUp: SetUp

ObservableObjeto

- objetos: ArrayList- id: String- nome: String- classe: Classificador- fromSetUp: boolean- fromStub: boolean

SetUp

- classe: Classe

ObservableMensagem

- id: String- valoresDosParametros: ArrayList- destino: Objeto- origem: Gerenciador- atribuirPara: Atributo- metodo: Metodo- contruirObjeto: boolean

ElementoTipadomodelo::Atributo

- visibil idade: Visibil idade

ObservableObserver

Teste

- id: String- nome: String- gerenciador: Gerenciador- objetos: ArrayList- mensagens: ArrayList

Observablemodelo::Metodo

- id: String- nome: String- tipoDeRetorno: String- visibil idade: Visibil idade- abstrato: boolean- estatico: boolean- casosDeTeste: ArrayList- parametros: ArrayList- classe: Classe- construtor: boolean

interfacemodelo::Classificador

ObservableGerenciador

- id: String- nome: String- atributos: ArrayList- classe: Classe

ObservableMetodoStub

- comportamento: Comportamento- metodo: Metodo

ObservableComportamento

- valoresDosParametros: ArrayList- valorDoRetorno: String

ObservableStub

- nome: String- metodos: ArrayList

-gerenciador

-origem

0-atribuirPara 0..1

+comportamento

1

+classe 10

+destino 1

0

+origem 1

0

+metodo

1

0

+metodo

1

+mensagens*

+objetos*

0

+setUp

1

+casosDeTeste *

+metodoTestado 1

+metodos *

Figura 14. Diagrama de classe para o pacote casoDeTeste para a ferramenta

5 Consideraes finais

A principal contribuio deste artigo apresentar uma proposta para utilizao do diagrama de seqncia como artefato de definio de casos de teste visando auxiliar, por exemplo, a aplicao da tcnica TDD.

O uso do diagrama de seqncia na definio dos casos de teste, ganha destaque medida que este no foi concebido para este fim. Apesar disso, sua adequao se deu de forma natural, no exigindo a criao de qualquer elemento ou comportamento em especial, apenas utilizando de recursos j existentes na UML, como o esteretipo, utilizado para identificao do stub.

Observa-se ainda que o diagrama de seqncia como proposta para definio de casos de teste juntamente com a ferramenta desenvolvida se configuram como soluo para os problemas citados em [6], dado que o cdigo auxiliar gerado automaticamente pela ferramenta. Os casos de testes podem ser definidos de forma visual sem qualquer contato com a linguagem de implementao, tendo como base apenas o modelo de classes do projeto.



O uso do diagrama de seqncia para definio dos casos de teste se demonstrou compatvel com os recursos necessrios para tal aplicao, dado que a ferramenta desenvolvida com base nesta definio pode gerar o cdigo fonte para os casos de teste, tendo como base to somente o diagrama de seqncia definido pelo usurio na prpria ferramenta.

Por fim, acredita-se que o uso de uma linguagem visual para definio de casos de teste linguagem esta que j de domnio de parte dos analistas - permite uma melhor comunicao e interao entre os envolvidos no processo de desenvolvimento.

Referncias

[1] Macgregor, J.; Sykes, D. (2001). A Practical guide to testing object-oriented software. Addison-Wesley.

[2] Hetzel, W. (1987). Guia completo do teste de software. Rio de Janeiro: Campus. [3] Thomas, J.; Young, M.; Brown, K.; Glover, A. (2004). Java testing patterns. Indianpolis: John Wiley.

[4] Beck, K. (2002). Test driven development: by example. Boston: Addison-Wesley. [5] RUNESON, P. (2006). A survey of unit testing practices. In IEEE Software, v 23, Issue 4, p. 22 29, July-Aug.

[6] Biasi, L.; Becker, K. (2006). Gerao automatizada de drivers e stubs de teste para JUnit a partir de especificaes U2TP. In Proceedings of Brazilian Symposium of Software Engineering (SBES), Florianpolis Santa Catarina. [7] Astels, D. (2003). Test Driven development: a practical guide. Prentice Hall. [8] Maldonado, J. C.; Fabbri, S. C. P. F.. (2001). Teste de software. In: Rocha, A. R. C. da; Maldonado, J. C.; Weber, K. C. (Coord.). Qualidade de software: teoria e prtica. So Paulo: Prentice Hall, p. 73-84.

[9] JUNIT (2007). JUnit FAQ. Disponvel em: http://junit.sourceforge.net/doc/faq/faq.htm. Acesso em: 25 fev. 2007.

[10] IEEE (1986). IEEE standard for software unit testing. [11] Badri, M.; Badri, L.; Bourque-Fortin, M.;. (2005) Generating unit test sequences for aspect-oriented programs: towards a formal approach using UML state diagrams. In 3rd International Conference on Information and Communications Technology. p. 237 253. Coimbatore, India.

[12] Linzhang, W.; Jiesong Y.; Xiaofeng Y.; Jun H.; Xuandong L.; Guoliang Z. (2004). Generating test cases from UML activity diagram based on Gray-box method. In 11th Software Engineering Conference. p. 284 291. Asia-Pacific.

Documents

Proposta de Utilização Do Diagrama de Sequência Para Definição de Casos de Teste de Unidade