FERRAMENTA DE SUPORTE AO PLANEJAMENTO DE TESTE FUNCIONAL DE SOFTWARE A PARTIR DE DIAGRAMAS DE CASOS...

7/26/2019 FERRAMENTA DE SUPORTE AO PLANEJAMENTO DE TESTE FUNCIONAL DE SOFTWARE A PARTIR DE DIAGRAMAS DE CASOS DE USO

1/76

UNIVERSIDADE REGIONAL DE BLUMENAU

CENTRO DE CINCIAS EXATAS E NATURAIS

CURSO DE CINCIAS DA COMPUTAO BACHARELADO

FERRAMENTA DE SUPORTE AO PLANEJAMENTO DE

TESTE FUNCIONAL DE SOFTWARE A PARTIR DE

DIAGRAMAS DE CASOS DE USO

JULIANO BIANCHINI


2/76

JULIANO BIANCHINI




Trabalho de Concluso de Curso submetido Universidade Regional de Blumenau para aobteno dos crditos na disciplina Trabalhode Concluso de Curso II do curso de Cinciada Computao Bacharelado.

Prof. Everaldo Artur Grahl - Orientador


3/76




Por

JULIANO BIANCHINI

Trabalho aprovado para obteno dos crditos

na disciplina de Trabalho de Concluso deCurso II, pela banca examinadora formadapor:

______________________________________________________Presidente: Prof. Everaldo Artur Grahl, FURB

______________________________________________________Membro: Prof. Maurcio Capobianco Lopes, FURB


4/76

Dedico este trabalho a minha querida esposaRosangela e ao meu querido av IngoWengrath (in memorian)


5/76

AGRADECIMENTOS

A Deus, pelo seu imenso amor e graa.

minha famlia por acreditar em mim, principalmente, a minha querida esposa pelo

apoio e compreenso.

A todos os meus amigos que me ajudaram direta ou indiretamente, principalmente ao

Giancarlo Tomazelli e ao Andr Vinicius Castoldi.

Ao meu orientador, Everaldo Artur Grahl, por todo o apoio e por ter acreditado na

concluso deste trabalho.


6/76

RESUMO

Atualmente existem muitas pesquisas sobre a utilizao da UML para a gerao de casos detestes funcionais. Este trabalho analisou algumas alternativas existentes na literatura sobre ouso de diagrama de casos de uso, um dos diagramas mais usados na UML, e a partir desteestudo foi criada uma ferramenta de suporte ao planejamento de testes funcionais.Inicialmente foi modificada a ferramenta CASE ArgoUML para incluir extenses apropriadasa casos de testes. Posteriormente foi desenvolvida uma ferramenta para permitir a leituradestas extenses e documentar os testes seguindo orientaes previstas no padro IEEE 829que trata da documentao de testes de software.

Palavras chaves: teste de software; UML; casos de teste; casos de uso; IEEE 829.


7/76

ABSTRACT

Currently there are many researches on the use of the UML for the generation of functionaltest cases. This work analyzed some existing alternatives in literature on the use of use casediagrams, one of the most used diagrams in the UML, and from this study a tool for supportfunctional test planning was created. Initially, the ArgoUML CASE tool was customized toinclude appropriate extensions for the test case specification. Later, a tool was developed toallow the reading of these extensions and to document the tests cases according with IEEE829 standard that it deals with the documentation of software tests.

Key-Words: software test; UML; test cases; use cases; IEEE 829.


8/76

LISTA DE ILUSTRAES

Figura 1 Vises dos testes por perspectivas diferentes .........................................................16Figura 2 Diferentes nveis de abstrao ao longo do processo de desenvolvimento.............17Figura 3 Relacionamento entre os testes de unidade, integrao e sistema ..........................19Figura 4 Estratgias de integrao entre modelagem de requisitos e testes..........................23Figura 5 Transformando modelos de caso de uso em modelos hierrquico de estados........24Figura 6 Modelo de caso de uso com informao adicional .................................................24Figura 7 Fluxo principal e os fluxos alternativos para um caso de uso.................................26Figura 8 Frmula para calcular a cobertura dos testes dos casos de uso estendidos.............28Figura 9 Relacionamento dos documentos de teste com o processo de teste........................31Figura 10 Interface da ferramenta CASE ArgoUML ............................................................37Figura 11 Principais pacotes do projeto ................................................................................38Figura 12 Casos de uso da ferramenta de suporte ao teste de funcional ...............................43Figura 13 Fluxo de dados entre as ferramentas .....................................................................44Figura 14 Classes de persistncia da ferramenta TestCen.....................................................46

Figura 15 Classes da customizao da ferramenta ArgoUML..............................................47Figura 16 Classes implementados e/ou alteradas no ArgoUML...........................................48Figura 17 Criao de campos com persistncia na forma de tagged values..........................48Figura 18 Guia Caso de Teste, implementada pela classe TabTestCase1.............................49Figura 19 Guia Caso de Teste - Procedimento, implementada pela classe TabTestCase2 ...49Figura 20 Persistncia dos procedimentos de teste em forma de tagged values ...................49Figura 21 Esteretipo de Caso de Teste ................................................................................50Figura 22 Trecho do cdigo que implementa o esteretipo de Caso de Teste......................50

Figura 23 Barra de ferramentas customizada para permitir a incluso de casos de teste......50Figura 24 Imagem da tela principal da ferramenta TestCen .................................................51Figura 25 Estrutura do arquivo XML de um projeto de teste de exemplo ............................52Figura 26 Caso de uso - emprstimo de livros ......................................................................53Figura 27 Testes de cenrio para o caso de usoEmprestar livro ..........................................56Figura 28 Especificao do caso de teste fluxo principal (Testar emprstimo de livros).....56Figura 29 Procedimentos do caso de teste principal (Testar emprstimo de livros).............57

Figura 30 Importao do arquivo XMI do ArgoUML ..........................................................57Figura 31 Parte da especificao dos casos de teste..............................................................58Figura 32 Execuo do caso de teste CT001.........................................................................59Figura 33 Lista de casos de teste por casos de uso................................................................60Figura 34 Grfico de casos de teste por caso de uso .............................................................60Figura 35 Documentos cobertos pelas ferramentas implementadas......................................62


9/76

SUMRIO

1 INTRODUO..................................................................................................................10

1.1 OBJETIVOS DO TRABALHO ........................................................................................12

1.2 ESTRUTURA DO TRABALHO......................................................................................12

2 FUNDAMENTAO TERICA....................................................................................13

2.1 QUALIDADE DE SOFTWARE.......................................................................................13

2.2 O PAPEL DO TESTE NA QUALIDADE DO PRODUTO DE SOFTWARE ................15

2.3 A UML E O TESTE DE SOFTWARE...........................................................................21

2.3.1 Introduo a UML...........................................................................................................21

2.3.2 UML como modelo de teste............................................................................................22

2.3.3 Diagrama de Casos de Uso .............................................................................................23

2.3.3.1 Integrao da modelagem de casos de uso e testes baseados em uso...........................23

2.3.3.2 Gerao de casos de teste a partir dos casos de uso .....................................................25

2.3.3.3 Teste de caso de uso estendido .....................................................................................26

2.4 IEEE STD 829-1998 PADRO PARA DOCUMENTAO DO TESTE DE

SOFTWARE......................................................................................................................30

2.4.1 Especificao do plano de teste.......................................................................................32

2.4.2 Especificao do projeto de teste ....................................................................................33

2.4.3 Especificao do caso de teste ........................................................................................34

2.4.4 Especificao do procedimento de teste .........................................................................34

2.4.5 Relatrio de transio de item de teste............................................................................35

2.4.6Logdos testes (dirio de bordo)......................................................................................35

2.4.7 Relatrio de incidente .....................................................................................................35

2.4.8 Relatrio com resumo dos testes.....................................................................................36

2 5 A FERRAMENTA CASE ARGOUML 37


10/76

3.3.2 Ferramenta de planejamento e execuo de testes (TestCen).........................................50

3.3.3 TCNICAS E FERRAMENTAS UTILIZADAS...........................................................53

3.3.4 OPERACIONALIDADE DA IMPLEMENTAO......................................................53

3.3.4.1 Especificao dos casos de teste na ferramenta TestCen .............................................57

3.4 RESULTADOS E DISCUSSO ......................................................................................61

4 CONCLUSES..................................................................................................................63

4.1 EXTENSES ....................................................................................................................63

REFERNCIAS BIBLIOGRFICAS .................................................................................65

APNDICE A Relatrio de erros por caso de teste ..............................................................67

APNDICE B Cdigo fonte da importao do arquivo XMI ...............................................68

ANEXO A Diagramas da UML e padres de projeto de teste aplicveis a cada diagrama..72


11/76

10

1 INTRODUO

A contnua demanda por sistemas de computao exige que os profissionais da rea de

tecnologia da informao estejam preparados para fornecer produtos de software com

qualidade. Para tanto, a verificao e validao (V&V) so consideradas atividades

fundamentais no desenvolvimento de software. Estas atividades so especialmente valiosas

quando aplicadas desde cedo no processo de desenvolvimento, pois erros encontrados nasfases de especificao e projeto so muito mais baratos para serem corrigidos do que quando

encontrados em fases mais avanadas (RYSER; GLINZ, 2003, p. 1-2). Entre as atividades de

V&V est a atividade de teste de software.

O papel do teste encontrar erros na implementao de um software e validar os

requisitos implementados. Isso significa que o teste tem um papel importantssimo na

verificao e validao de software. Porm, em muitos casos, a preparao e o

desenvolvimento dos casos de teste so feitos sem muito planejamento. Alm disso,

freqentemente os testes so selecionados de forma aleatria ou ad-hoc (momentnea) e os

casos de teste so desenvolvidos de uma forma no estruturada e no sistemtica. Esta uma

realidade encontrada no desenvolvimento de softwares comerciais, onde h recursos limitados

e tempo escasso para o teste.

Apesar de existirem vrias tcnicas e estratgias aplicadas a teste de software, a prtica

ainda est distante da teoria (RYSER; GLINZ, 2003, p. 1-2). Alguns problemas encontrados

incluem:

a) falta de planejamento dos tempos e custos: na prtica, o planejamento dos

testes feito tardiamente no processo, quando ele est quase no final. Desta

forma h presso para manter menor c sto e tempo e somado ao fato de q e o


12/76

11

fase de testes deveria comear imediatamente aps a especificao ter sido

desenvolvida. Desta forma, muitos erros, omisses e inconsistncias podem ser

encontradas nas fases de anlise e projeto. mais barato corrigir erros nestas

fases iniciais do que aps a implementao ter sido feita;

d) casos de teste no so gerados de forma sistemtica: os testes so escolhidos de

forma aleatria e os casos de teste gerados com base no conhecimento dotestador e sem procedimento definido.

Entre as abordagens de testes de software encontra-se o teste Funcional tambm

conhecido como teste de Caixa-Preta. As tcnicas de teste Funcional derivam os casos de

testes a partir da anlise da funcionalidade (dados de entrada/sada e especificao) do

programa sem levar em considerao a estrutura interna do mesmo.

A Unified Modeling Language(UML) muito usada para modelar sistemas orientados

a objetos e, na verso 1.3, formado por nove diagramas com objetivos e perspectivas

diferentes. A utilizao dela como modelo sistemtico para o desenvolvimento dos casos de

teste tem sido estudada e evoluda durante os ltimos anos. Um diagrama que tem sido

estudado para teste o caso de uso que uma forma de capturar as funcionalidades e

comportamentos de um sistema na perspectiva do usurio. O caso de uso usado para ajudar

na elicitao e documentao dos requisitos dos usurios. Desta forma, o caso de uso uma

fonte de informaes que ajuda no s o desenvolvimento do software, mas tambm, a

atividade de teste de software. Entre as propostas de utilizao da UML para teste encontra-sea apresentada por Heumann (2004) e o teste de caso de uso estendido, proposto por Binder

(2000, p. 722-731).


13/76

12

1.1 OBJETIVOS DO TRABALHO

Este trabalho tem por objetivo principal o desenvolvimento de uma ferramenta de

suporte ao planejamento do teste funcional de software a partir da utilizao de diagramas de

casos de uso da UML.

Os objetivos especficos so:

a) anlise e aplicao das metodologias de teste de software baseada em casos de

uso da UML apresentadas por Heumann (2004) e Binder (2000, p. 722-731);

b) adaptao de uma ferramenta CASE de cdigo aberto para suportar extenses

aplicveis a casos de testes funcionais;

c) incorporao de padres de documentao de teste de software da IEEE 829 na

ferramenta construda.

1.2 ESTRUTURA DO TRABALHO

No segundo captulo feita uma reviso bibliogrfica para o entendimento do trabalhoincluindo temas como qualidade de software, testes de software, UML como modelo para

testes de software, Padro IEEE 829 e a ferramenta CASE ArgoUML.

O terceiro captulo apresenta os requisitos principais do problema tratado neste

trabalho, assim como a especificao do software e a operacionalidade do mesmo

demonstrando o seu uso prtico.

O quarto captulo apresenta as concluses e sugestes de extenso deste trabalho.


14/76

13

2 FUNDAMENTAO TERICA

Neste captulo so apresentados os conceitos, tcnicas, modelos, padres e ferramentas

mais relevantes para o entendimento e desenvolvimento deste trabalho.

2.1 QUALIDADE DE SOFTWARE

Antes de efetivamente falar sobre qualidade de software, convm voltar no tempo eanalisar os fatos que levaram este tema a ser to discutido. Nos ltimos anos tem-se falado

muito em qualidade de software. Isso se intensificou mais depois da to falada globalizao.

A quebra da fronteira de comrcio entre os pases abriu as portas para a exportao de

software. Essa quebra trouxe consigo mais oferta de produtos, maior concorrncia e maiores

exigncias de qualidade. Produzir software apenas pensando em menor custo e prazo deentrega no seria mais o que o mercado queria. A isto, soma-se um fator decisivo: a qualidade

do produto de software.

Isso desencadeou uma srie de novas iniciativas na rea de qualidade e trouxe a tona

aquelas j existentes. Iniciativas estas que visam garantir a qualidade do produto de software

atravs da verificao e validao do produto e da maturidade do processo de

desenvolvimento.

A qualidade de software pode ser definida como um processo sistemtico que focaliza

todas as etapas e artefatos produzidos com o objetivo de garantir a conformidade de processos

e produtos, prevenindo e eliminando defeitos (BARTI, 2002, p. 16). Isto significa que aqualidade no uma fase do ciclo de desenvolvimento de software, mas sim parte de todas as

fases.

N B il lid d d f i i d h i


15/76

14

de 50% das empresas utilizam prticas de Engenharia de Software para avaliar a qualidade do

produto, incluindo diferentes tipos de testes - funcionais, de aceitao, de campo, baseados em

erros, de integrao e do sistema integrado. A Tabela 1 mostra prticas de Engenharia de

Software adotadas na avaliao da qualidade do produto.

Tabela 1 Prticas de Engenharia de Software adotadas na avaliao da qualidadeCategorias N de organizaes %

Auditorias 97 22,6Inspeo formal, Reviso por pares (Peer-review), Walthroughestruturado

70 16,3

Julgamento de especialistas 88 20,5Levantamento de requisitos de qualidade 78 18,1Medies da qualidade (Mtricas) 75 17,4Modelos de confiabilidade de software 21 4,9

Prova formal de programas 82 19,1Segurana do produto final 58 13,5Testes baseados em erros 236 54,9Testes de aceitao 246 57,2Testes de campo 243 56,5Testes de integrao 232 54,0Testes de unidade 149 34,7Testes do sistema integrado 222 51,6Testes estruturais 107 24,9Testes funcionais 255 59,3Testes orientados a objetos 91 21,2Testes para web 135 31,4Outras 3 0,7

No adota tais prticas 50 11,6Base 430 100

Fonte: SEPIN (2004)

Infelizmente este o cenrio de muitas empresas de software no Brasil. Cenrio este

que mostra a imaturidade dos processos de desenvolvimento de software. No basta ter


16/76

15

necessidade de outros esforos no processo de desenvolvimento para se atingir a qualidade

total.

2.2 O PAPEL DO TESTE NA QUALIDADE DO PRODUTO DE SOFTWARE

V&V o processo de verificao e anlise que assegura que o software cumpra com

suas especificaes e atenda s necessidades dos clientes (SOMMERVILLE, 2003, p. 358).

Embora sejam facilmente confundidas, V&V no so a mesma coisa. Pode-se resumir a

diferena atravs de uma pergunta chave:

- Validao: estamos construindo o software certo?

- Verificao: estamos construindo certo o software?

Em outras palavras, validao um conjunto de atividades que garante que o softwareconstrudo corresponde aos requisitos do cliente e verificao o conjunto de atividades que

garante que o software implementa corretamente determinada funo (PRESSMAN, 2002, p.

470).

Dentro da V&V pode-se utilizar duas tcnicas (SOMMERVILLE, 2003, p. 358):

a) inspees de software: analisam e verificam as representaes do sistema,

como o documento de requisitos, os diagramas do projeto e o cdigo-fonte do

programa. As inspees podem ser aplicadas a todas as fases do processo de

desenvolvimento. A inspeo uma tcnica esttica, pois no requer que o

software seja executado.

b) teste de software: envolve a execuo do software com dados de teste e a

anlise das sadas e do comportamento operacional, a fim de verificar se ele


17/76

16

entrada e sada do sistema para descobrir erros de funcionalidade, comportamento e

desempenho (PRESSMAN, 2002, p. 429).

Myers (1979, p. 5), ao afirmar que a funo do teste de software mostrar a presena

de erros (e no a ausncia), contribuiu para que o teste de software tomasse um rumo

diferente. Na prtica, isso significa que mostrar que algo no funciona mais difcil (exige

mais esforo) do que mostrar que funciona. Desenvolvedores de software so, por natureza,pessoas construtivas. O teste de software, ao contrrio, exige pessoas com natureza destrutiva.

A Figura 1 ilustra vises dos testes por perspectivas diferentes. A viso do analista de

sistemas , geralmente, provar que o software funciona, desta forma seus casos de teste sero

limitados a cenrios que provem que o sistema est funcionando. J o analista de teste tem

uma percepo mais ampla, isto , alm de testar as funcionalidades, seus casos de testetentam mostrar falhas no software.

Fonte: Barti (2002, p. 21)

Figura 1 Vises dos testes por perspectivas diferentes

As atividades que envolvem a fase de teste so planejamento, projeto de casos de teste,execuo e avaliao dos resultados. Elas devem ser conduzidas ao longo de todo o processo

de desenvolvimento (ROCHA; MALDONADO; WEBER, 2001, p. 74). Pode-se salientar que

a falta da atividade de planejamento uma das causas dos problemas no desenvolvimento de


18/76

17

detalhada (teste de unidade, integrao e sistema) at uma viso mais externa e abstrata (teste

de validao e certificao do sistema).

Fonte: Regnell , Runeson e Wohlin (2003, p. 5)Figura 2 Diferentes nveis de abstrao ao longo do processo de desenvolvimento

Antes dos testes serem efetivamente projetados, alguns princpios deveriam ser levados

em conta (DAVIS apud PRESSMAN, 2002, p. 431-432):

- todos os testes devem ser relacionados aos requisitos do cliente: os defeitos

mais indesejveis de um software so aqueles que deixam de satisfazer osrequisitos do usurio.

- os testes devem ser planejados muito antes do incio do teste: o planejamento

dos testes pode comear to logo o modelo de requisitos esteja definido. A

definio dos casos de teste pode comear assim que o modelo do projeto tenha

sido consolidado. Sendo assim, todos os testes podem ser planejados e projetadosantes do cdigo ter sido gerado.

- o princpio de Pareto se aplica ao teste de software: aplicando o princpio de

Pareto, implica que 80% de todos os erros descobertos durante os testes sero,


19/76

18

combinaes de caminhos durante o teste. possvel, no entanto, cobrir

adequadamente a lgica do programa e garantir que todas as condies no nvel de

componentes tenham sido exercitadas.

- para ser mais efetivo, o teste deveria ser conduzido por terceiros: como dito

anteriormente, a natureza do testador deve ser destrutiva. Por outro lado, pessoas

envolvidas no processo de desenvolvimento (construo) tem natureza

construtiva. Isto , quanto menos a pessoa estiver envolvida no processo de

desenvolvimento, maior a probabilidade dela encontrar erros.

O projeto de casos de teste pode ser feito de duas formas principais (PRESSMAN,

2002, p. 435):

- teste de caixa preta: tambm conhecido como teste funcional, o testeconduzido na interface do software. Apesar de serem projetados para descobrir

erros, so usados para demonstrar que as funes do software esto

implementadas, ou seja, que a entrada adequadamente aceita e a sada

corretamente produzida, e que a integridade das informaes externas mantida.

O teste de caixa preta examina algum aspecto fundamental do sistema sepreocupando pouco com a estrutura lgica interna do software.

- teste de caixa branca: tambm conhecido como teste estrutural, se trata de um

exame rigoroso da estrutura interna do software. Caminhos lgicos, internos ao

software so testados, definindo casos de testes que exercitam conjuntos

especficos de condies e/ou ciclos.

Alm dos casos de teste poderem ser desenvolvidos de duas formas, estes podem ser

aplicados em diferentes escopos ou estgios. O escopo do teste a coleo de componentes de

ft ifi d C t t d t d b i l t


20/76

19

testes de integrao. Por ltimo, a juno dos mdulos forma um sistema completo. Ao

sistema completo so aplicados testes de sistema.

Teste de unidadeClassesFunes

Teste de integraoSub-sistemas

Clusters

Teste de sistemaAplicao (sistema)

Fonte: Adaptado de Binder (2000, p. 46)Figura 3 Relacionamento entre os testes de unidade, integrao e sistema

No teste de unidade (PRESSMAN, 2002, p. 476), testa-se a menor unidade do projeto

de software, isto , o menor componente de software. O teste de unidade orientado para


21/76

20

O objetivo do teste de integrao descobrir erros associados s interfaces entre a

unidades do software (ROCHA; MALDONADO; WEBER, 2001, p. 75). No contexto da OO,

o teste de integrao pode ser feito de duas maneiras (PRESSMAN, 2002, p. 623). Na

primeira, um conjunto de classes integrado para responder a uma entrada ou evento do

sistema. Na segunda, o teste comea com as classes que usam poucas (ou nenhuma) classes

servidoras. Em seguida, estas classes independentes so integradas com outras classes

dependentes e, ento, so testadas. Isto se repete at que todo o sistema seja integrado e

testado.

O escopo do teste de sistema testar todo o sistema, levando em considerao

componentes de software e hardware, ou seja, o software em seu provvel ambiente de

produo. Neste estgio so testadas caractersticas que esto presentes apenas no sistemacomo um todo. Entre os testes que so aplicados neste estgio esto testes funcionais (para

validar requisitos do usurio), testes de performance (tempo de resposta) e teste de carga ou

estresse (desempenho do sistema quando sobrecarregado) (BINDER, 2000, p. 45).

A Tabela 2 mostra a relao entre os estgios de teste e os paradigmas procedimental e

OO.

Tabela 2 Relao entre os estgios de teste e os paradigmas procedimental e OOParadigma

Estgio de Teste Teste Procedimental Teste Orientado a Objetos

Unidade Sub-rotina ou funo Mtodos das classesIntegrao Duas ou mais unidades Classe

Cluster

ComponenteSubclasse

Sistema Toda a aplicao Toda a aplicaoFonte: adaptado de Rocha, Maldonado e Weber (2001, p. 76)


22/76

21

caractersticas comportamentais sejam conseguidas, todos os requisitos funcionais sejam

alcanados, entre outros (PRESSMAN, 2002, p. 487).

Depois que cada caso de teste de validao tenha sido executado, uma de duas

condies pode acontecer: (1) o software est de acordo com os requisitos e aceito ou (2)

um desvio da especificao descoberto e gerada uma lista de deficincias.

2.3 A UML E O TESTE DE SOFTWARE

2.3.1 Introduo a UML

A Unified Modeling Language(UML) uma linguagem para modelagem de estruturas

de software. Atravs da UML possvel visualizar, especificar, construir e documentar

artefatos de software (BOOCH; RUMBAUGH; JACOBSON, 2000, p. 13).

A UML (verso 1.3) composta por nove diagramas: diagrama de casos de uso,

diagrama de objetos, diagrama de classes, diagrama de seqncia, diagrama de colaborao,

diagrama de grficos de estados, diagrama de atividades, diagrama de componentes, diagrama

de implantao. Cada um dos diagramas possui funcionalidades distintas. A seguir tem-seuma breve explicao de cada diagrama. Mais detalhes sobre a construo de cada diagrama

pode ser encontrado em Booch, Rumbaugh e Jacobson (2000):

a) diagrama de casos de uso: representa um conjunto de caso de uso e atores e

seus relacionamentos. Este diagrama abrange a viso esttica de formas de uso

do sistema. importante a utilizao deste diagrama principalmente porque

atravs dele possvel organizar e modelar os comportamentos do sistema.

Alm disso, os casos de uso servem para ajudar a validar a arquitetura e para


23/76

22

d) diagrama de seqncia: mostra a ordenao temporal das mensagens entre

objetos. Ou seja, este diagrama mostra a seqncia das mensagens trocadas

entre os objetos e qual o tempo de vida de cada mensagem;

e) diagrama de colaborao: exibe a organizao dos objetos que participam de

uma interao. Este diagrama mostra o relacionamento entre determinados

objetos e quais as mensagens trocadas entre eles;

f) diagrama de grficos de estados: exibe uma mquina de estados, que

formada por estados, transies, eventos e atividades. Este diagrama apresenta

uma viso dinmica do sistema em questo;

g) diagrama de atividades: apresenta uma viso dinmica de um sistema. Estediagrama um grfico de fluxo, onde mostrado o fluxo de controle de uma

atividade para outra;

h) diagrama de componentes: exibe as organizaes e as dependncias existentes

em um conjunto de componentes. Este diagrama empregado para mostrar

uma viso esttica da implementao de um sistema. Est relacionado

principalmente com o diagrama de classes, pois geralmente os componentes

mapeados so classes, interfaces ou colaboraes;

i) diagrama de implantao: exibe a configurao dos ns de processamento em

tempo de execuo e os componentes que nele existem. Este diagrama utilizado para modelar uma viso esttica da implantao de um sistema.

2.3.2 UML como modelo de teste


24/76

23

que apresenta um guia com padres de teste baseado na UML. O escopo deste trabalho est

em utilizar o diagrama de casos de uso para testes de sistema e para validar requisitos, por

isso, ser dada nfase no diagrama de casos de uso. Mais especificamente, este trabalho

utilizar o padro proposto por Binder (2000, p.722-731) e Heumann (2004), pois estes se

apresentaram mais completos e abrangentes no estudo realizado, alm de serem mais

aplicveis ao contexto de testes funcionais.

Para maiores informaes sobre a utilizao da UML no teste de software, vide o

anexo A. Neste anexo esto relacionados os diagramas da UML e os padres de projeto de

teste relacionados a cada diagrama, conforme proposto por Binder (2000, p. 272-273).

2.3.3 Diagrama de Casos de UsoUm sistema especificado atravs de casos de uso prov muitas das informaes

necessrias para se testar um sistema, pois ele descreve os requisitos funcionais de um

software, isto , pode-se testar e validar os requisitos de software com base nos casos de uso.

Algumas metodologias para se testar um sistema baseando-se em casos de uso sero

apresentadas a seguir:

2.3.3.1 Integrao da modelagem de casos de uso e testes baseados em uso

Regnell , Runeson e Wohlin (2003) prope um modelo de uso como base para as

disciplinas de engenharia de requisitos e teste. Alm disso investigam a possibilidade de

integrar as duas disciplinas. Basicamente, so apresentadas duas estratgias de integraoentre as disciplinas: integrao atravs de transformao de modelos e integrao atravs de

extenso de modelos. A figura 4 ilustra as duas estratgias.


25/76

24

A estratgia de transformao de modelos baseada na observao de que muitos dos

conceitos utilizados na modelagem de casos de uso e teste esttico de utilizao tm

semntica similar. A transformao consiste em adicionar informaes de teste aos casos de

uso, gerando um modelo hierrquico de estados. A figura 5 ilustra a estratgia de

transformao.

Modelo de Casosde Uso- Atores- Servios- Casos de uso- Estmulos- Respostas- Aes dosistema

TransformaoModelo Hierrquico deEstados

- Tipos do usurio e subtipos- Servios- Comportamentos- Sub-comportamentos- Transies- Estados do usurio- Perfil de comportamento

- Perfil de hierarquia

Informao adicional- Probabilidades de utilizao deservios- Probabilidades de estmulos dousurio- Nmero de usurios- Estado dos usurios

Fonte: Regnell , Runeson e Wohlin (2003, p. 26)

Figura 5 Transformando modelos de caso de uso em modelos hierrquico de estados

A estratgia de extenso do modelo baseada na idia de complementar o modelo de

casos de uso em qualquer parte em que no haja uma escolha determinstica em

probabilidades de diferentes escolhas. Se for possvel criar semnticas bem definidas de

construo de casos de teste diretamente dos casos de uso, ser possvel economizar esforos

na construo dos casos de teste. A figura 6 ilustra a estratgia de extenso dos casos de uso.

Modelo de Casosde Uso- Atores- Servios- Casos de uso- Episdios

Extenso doModelo

Modelo de Casos deUso complementadocom:

- Nmero de usurios- Probabilidade deinvocao servios


26/76

25

de extenso tem a vantagem de no precisar um segundo modelo. Ao invs disto, estende o

modelo de caso de uso com informaes para gerar casos de teste.

2.3.3.2 Gerao de casos de teste a partir dos casos de uso

Heumann (2004) apresenta uma metodologia para criar casos de teste a partir dos casos

de uso executando trs passos:

a) para cada caso de uso, gerar uma lista de cenrios de casos de uso1;

b) para cada cenrio, identificar, ao menos, um caso de teste e as condies que o

faro ser executado; e

c) para cada caso de teste, identificar os dados que sero utilizados para o teste.

No primeiro passo, deve-se ler a descrio textual do caso de uso e identificar o fluxo

principal e os fluxos alternativos. Por exemplo, um caso de uso para descrever o uso de um

sistema para fazer validao de usurios ter um fluxo principal que : o usurio digita seu

nome e senha corretamente e o sistema vai para a tela principal. Um fluxo alternativo seria: o

usurio digita seu nome corretamente e senha invlida e, ento, o sistema emite um aviso e

permanece na tela de validao. A figura 7 mostra o fluxo principal e os fluxos alternativos

para um caso de uso.


27/76

26

Fonte: Heumann (2004)

Figura 7 Fluxo principal e os fluxos alternativos para um caso de uso

No segundo passo, os casos de teste para cada cenrio devem ser identificados. Para

tanto deve-se analisar os cenrios, revisar a descrio do caso de uso e ento criar o caso de

teste. Criar uma tabela que represente valores de entrada e sada pode ser muito til neste

ponto, ajudando na organizao e montagem dos casos de teste.

No terceiro e ltimo passo, deve-se revisar e validar os casos de teste para assegurar a

meticulosidade e identificar casos de teste redundante ou faltantes. Depois de aprovados, os

dados de teste devem ser identificados. Sem os dados de teste, os casos de teste no podem ser

executados.

Heumann (2004) afirma que com a metodologia apresentada, desenvolvedores podemsimplificar o processo de teste, incrementar a eficincia e ajudar na certeza de se ter uma

cobertura completa dos testes.


28/76

27

b) sadas incorretas;

c) erro de execuo levando o programa a ser terminado;

d) tempo inadequado de resposta do sistema;

e) funes (requisitos funcionais) omitidas;

f) funes extras (apareceram sem ser requisitadas), etc.

Primeiramente, os casos de uso estendidos devem ser desenvolvidos, sendo que estes

devem conter as seguintes informaes:

a) um inventrio completo das variveis operacionais;

b) uma especificao completa do domnio de cada varivel operacional;

c) os relacionamentos operacionais para cada caso de uso;

d) a freqncia relativa para cada caso de uso (opcional).

Para cada caso de uso estendido deve-se executar os seguintes passos:

a) identificar as variveis operacionais: as variveis operacionais so todas as

variveis que so explicitamente parte da interface que suporta o caso de uso.

Entre elas esto entradas e sadas do sistema, condies do ambiente que

resultam em diferentes comportamentos dos atores e estados do sistema;

b) identificar os domnios das variveis operacionais: os domnios so

desenvolvidos definindo quais so os valores vlidos e invlidos para uma


29/76

28

exclusiva, isto , para determinada condio do sistema, apenas uma linha da

tabela de deciso represente esta condio;

d) desenvolver casos de teste: cada variante da tabela verdadeira e falsa pelo

menos uma vez. Este passo requer dois casos de teste para cada variante: um

que represente a variante falsa e outro que represente a variante verdadeira. Os

resultados esperados para cada caso de teste so tipicamente desenvolvidos porinspeo, isto , uma pessoa (provavelmente um analista de testes) observa os

valores de entrada dos casos de teste e desenvolve os resultados esperados.

Preferencialmente, esta pessoa deve ter grande conhecimento do negcio,

principalmente do requisito em teste, e das formas como o sistema em teste

deve ser usado.

O desenvolvimento dos casos de uso estendidos deve ser feito assim que os casos de

uso foram desenvolvidos e validados. J os casos de teste devem ser desenvolvidos assim que

os casos de uso estendidos foram desenvolvidos e validados e o sistema em teste j tenha

passado pelo teste de integrao que demonstre que os componentes necessrios para suportar

o caso de uso estejam operacionais.

Como critrio de aceitao e trmino dos testes, todos os requisitos precisam ser

exercitados, pelo menos uma vez, para que se tenha cobertura mnima do sistema em teste.

Binder (2000, p. 729) prope uma mtrica, chamada de cobertura de variantes (CV), que pode

ajudar a definir a completude do sistema (ver figura 8).


30/76

29

Tabela 3 Matriz de rastreabilidade entre casos de uso e casos de teste

Caso de teste 1 Caso de teste 2 ... Caso de teste 9999Caso de uso 1 Caso de uso 2

...

Caso de uso 9999 Fonte: Binder (2000, p. 729)

Entre as vantagens de utilizar este padro esto (BINDER, 2000, p. 730):

a) casos de uso podem ser desenvolvidos por analistas e testadores que no

possuem experincia no desenvolvimento orientado a objetos;

b) a utilizao dos casos de uso est consolidada nos processos de anlise e

projeto, isso facilita o desenvolvimento dos casos de teste;

c) casos de uso refletem o ponto de vista do usurio (cliente), sendo que o foco

dele est voltado para as funcionalidades que esto implementadas ou no e

isso que determinar se o sistema em teste atende ou no suas necessidades;

d) casos de uso estendidos provem uma forma sistemtica de desenvolvimento

das informaes necessrias para o projeto de teste. A informao dever ser

desenvolvida para testar qualquer caso de uso;

e) se o sistema em teste for desenvolvido a partir de casos de uso ambguos,

inconsistentes ou incompletos, estes logo sero apontados pelos testes.

Por outro lado, entre as desvantagens pode-se apontar (BINDER, 2000, p. 729-730):

a) casos de uso no so usados para especificar, entre outras, performance e


31/76

30

2.4 IEEE STD 829-1998 PADRO PARA DOCUMENTAO DO TESTE DE

SOFTWARE

O objetivo do padro IEEE 829 (INSTITUTE OF ELECTRICAL AND

ELECTRONIC ENGINEERS, 1998) descrever os documentos necessrios para apoiar a

atividade de teste de software. Os documentos descritos neste padro abrangem o

planejamento, especificao e a gerao de relatrios de testes.

Um plano de testes deve descrever o escopo, plano de ao, recursos e cronograma da

atividade de testes. Ele deve identificar os itens a serem testados, as caractersticas a serem

testadas, as tarefas de teste a serem executadas, os responsveis por cada tarefa e os riscos

associados ao plano.

Trs tipos de documentos fazem parte da especificao de teste:

a) o documento de especificao do projeto, que detalha o plano de ao,

identifica as caractersticas que sero testadas e os casos de teste associados.

Tambm identifica os casos e os procedimentos de teste, alm de especificar o

critrio de aceitao e rejeio dos testes.

b) o documento de especificao do caso de teste que especifica os valores de

entrada e as sadas esperadas. Alm disso, identifica restries nos resultados

dos procedimentos de teste.

c) o documento de especificao do procedimento de teste que especifica todos ospassos necessrios para operar o sistema e exercitar os casos de teste.

Quatro tipos de documentos fazem parte do relatrio de testes:


32/76

31

d) o relatrio de resumo dos testes que sumariza as atividades de teste associado a

um ou mais projetos de teste.

A figura 9 mostra o relacionamento dos documentos de teste com o processo de teste.


33/76

32

2.4.1 Especificao do plano de teste

O objetivo do plano prescrever o escopo, o plano de ao, os recursos e o

cronograma das atividades de teste. Um plano de teste dever conter a seguinte estrutura:

a) identificador nico do plano;

b) introduo: sumariza os itens de software e as caractersticas a serem testadas;

c) caractersticas a serem testadas: identifica todas caractersticas e combinaes

de caractersticas que sero testadas;

d) caractersticas que no sero testadas: identifica todas caractersticas e

combinaes de caractersticas que no sero testadas e qual a razo;

e) plano de ao: para cada caracterstica ou conjunto de caractersticas deve ser

descrito qual o plano de ao que assegura que as mesmas sero

adequadamente testadas. Deve ser especificado as principais atividades,

tcnicas e ferramentas que sero utilizadas para testar as caractersticas;

f) critrio de aceitao e rejeio dos testes: descreve quais os critrios que sero

utilizados para determinar se cada item de teste passou ou falhou;

g) critrio de suspenso e retomada: descreve quais os critrios que sero

utilizados para suspender e reiniciar todos ou parte dos testes;

h) documentos: identifica quais os documentos a serem gerados na atividade de

teste;


34/76

33

l) mo de obra e treinamento: descreve as necessidades de treinamento para

capacitar as pessoas envolvidas no processo;

m) cronograma: descreve o cronograma da atividade de teste;

n) riscos e contingncias: identifica os riscos do plano de testes e o plano de

contingncia;

o) aprovao: identifica os nomes e funes de todas as pessoas que precisam

aprovar o plano.

2.4.2 Especificao do projeto de teste

O objetivo do projeto de teste refinar o que foi definido no plano de teste e identificaras caractersticas que sero testas pelo projeto e seus casos de teste. Um projeto de teste

dever conter a seguinte estrutura:

a) identificador nico do projeto;

b) caractersticas que sero testadas: identifica todas caractersticas e

combinaes de caractersticas que sero testadas pelo projeto. Para cada

caracterstica ou combinao de caractersticas deve haver a referncia para o

requisito associado;

c) detalhamento do plano de ao: descreve detalhe do plano de ao descrito no

plano de teste. Inclui-se aqui a descrio de tcnicas de teste a serem usadas.

Alm disso, deve incluir um resumo dos atributos comuns a todos os casos de

teste;


35/76

34

2.4.3 Especificao do caso de teste

O objetivo do caso de teste definir o caso de teste identificado no projeto de teste.

Um caso de teste dever conter a seguinte estrutura:

a) identificador nico do caso;

b) itens do teste: identifica os itens e caractersticas que sero exercitadas pelo

caso de teste. Para cada item deve-se considerar os seguinte documentos

associados ao item: especificao dos requisitos, especificao do projeto, guia

do usurio, guia de operaes e guia de instalao;

c) especificao das entradas: especifica cada entrada necessria para executar o

caso de teste;

d) especificao das sadas: especifica todas as sadas e caractersticas dos itens

de teste;

e) necessidades de ambiente: especificas as necessidades de ambiente de

software, hardware e outros que so necessrios para a execuo do caso;

f) procedimentos especiais: descreve qualquer restrio especial no procedimento

de execuo do caso de teste.

g) dependncias entre casos: lista os casos que devem ser executados antes deste

caso.

2.4.4 Especificao do procedimento de teste


36/76

35

d) passos para execuo: descreve os passos para execuo do procedimento.

2.4.5 Relatrio de transio de item de teste

O objetivo do relatrio de transio de item de teste identificar os itens que esto

sendo enviados para a equipe de testes. Este documento dever conter a seguinte estrutura:

a) identificador nico do relatrio;

b) itens transmitidos: identifica os itens em transmisso, incluindo a

verso/reviso e o responsvel pela transmisso;

c) localizao: identifica a localizao dos itens em transmisso, devendo ser

descrito a mdia que contm os mesmos;

d) status: descreve o estado dos itens em transmisso;

e) aprovao: descreve os nomes e cargo das pessoas que aprovaram este

documento.

2.4.6 Logdos testes (dirio de bordo)

O objetivo do log prover um histrico cronolgico dos detalhes relevantes da

execuo dos testes. Este documento dever conter a seguinte estrutura:

a) identificador nico;

b) descrio: informaes relativas a todas as entradas devem ser descritas;

c) atividades e eventos de entrada: os eventos e atividades devem ser gravados

36


37/76

36


b) sumrio: resumo do incidente, identificando os itens envolvidos e sua

verso/reviso;

c) descrio do incidente: descreve o incidente ocorrido;

d) impacto: indica qual o impacto do incidente sobre o plano, projeto,procedimento ou caso de teste.

2.4.8 Relatrio com resumo dos testes

O objetivo deste relatrio sumarizar os resultados das atividades de teste projetadas e

prover uma base para avaliao dos resultados. Este documento dever conter a seguinteestrutura:


b) sumrio: apresenta um resumo dos itens testados;

c) divergncias: descreve qualquer diferena dos itens testados em relao ao que

foi planejado;

d) avaliao do plano: apresenta uma avaliao do que foi executado em relao

ao que foi planejado;

e) resumo dos resultados: sumariza os resultados dos testes. Identifica todos

incidentes resolvidos apresentando um resumo das solues. Alm disso,

descreve todos os incidentes no resolvidos;

37


38/76

37

Boa parte deste padro foi adotado na concepo da ferramenta proposta neste trabalho e ser

citada futuramente no texto atravs da indicao da seo especfica para um melhor

entendimento e relao com o texto descrito.

2.5 A FERRAMENTA CASE ARGOUML

O ArgoUML (TOLKE, 2004) uma ferramenta CASE para criao de diagramas da

UML. Esta ferramenta gratuita e seu cdigo-fonte pode ser obtido pela internet (endereo:

http://argouml.tigris.org). A ferramenta simples, prtica e no exige muito esforo para

poder utiliz-la. A partir dos modelos possvel gerar cdigo-fonte em Java. possvel

tambm fazer a engenharia reversa a partir de cdigo-fonte em Java. A Figura 10 mostra a

interface da ferramenta. Uma caracterstica interessante que os dados dos diagramas podem

ser exportados no formato XMI (XML Metadata Interchange), possibilitando assim levar

dados do ArgoUML para outras ferramentas.

38


39/76

38

O projeto ArgoUML, que composto por voluntrios de todo o mundo, possui

atualizaes regulares e est aberto a qualquer pessoa que esteja interessada em contribuir na

melhoria do mesmo. Entre as caractersticas tecnolgicas desta ferramenta pode-se citar que

ela implementada em Java e que utiliza diversos outros projetos de cdigo-fonte aberto. O

projeto possui documentao de usurio e desenvolvedor, apesar da documentao do

desenvolvedor estar defasada em relao ao projeto. Examinando o projeto, pode-se ver na

prtica a utilizao de XML (eXtensible Markup Language), padres de projeto, teste de

unidade (utiliza o JUnit), Java e outros conceitos e tecnologias. A Figura 11 mostra os

principais pacotes que compem o projeto.

Figura 11 Principais pacotes do projeto

Segue uma breve explicao sobre cada pacote:

a) application: contm a classe principal e o ponto de partida do ArgoUML.

Possui a definio das classes que tem abrangncia sobre toda a aplicao;

39


40/76

39

g) util: possui classes de diversas utilidades como, por exemplo, API para logde

execuo, que muito til para depurao;

h) images: todas as imagens utilizadas no projeto so armazenadas neste pacote;

i) ui: contm muitas das classes relacionadas a interface com o usurio;

j) xml: suporta o processamento dos documentos XML;

k) cognitive: define os elementos fundamentais do sistema de suporte cognitivo;e

l) ocl: contm as classes para suporte a Object Constraint Languange (OCL)

linguagem de restrio de objeto.

Fazem parte dos pacotes mencionados, outros projetos de cdigo aberto, tais como:

a) GEF (Graph Editing Framework): prov funes para a edio de grficos em

tempo de execuo como, por exemplo, o desenho dos diagramas da UML e

seus componentes;

b) log4j: prov funes que facilitam a gerao de logs(arquivos de transao);

c) SAX Parser Factory: prov funes para manipulao de arquivos XML;

d) Novosoft UML Library: prov funes para manter e manipulador informao

de meta-dados da UML.

O projeto ArgoUML est passando por uma reengenharia em busca da simplicidade e

legibilidade do cdigo-fonte e da performance da ferramenta. Mais informaes sobre o

40


41/76

40

Santiago (2002), apresenta uma ferramenta de apoio para testes de programas

utilizando teste de validao, cujo objetivo auxiliar os alunos no aprendizado de

programao, utilizando os componentes da biblioteca CLX do Delphi 6.0. Neste trabalho, a

ferramenta aplica testes de caixa preta para efetuar a correo dos exerccios submetidos pelos

alunos em uma disciplina de programao. Desta forma, ao concluir um exerccio proposto

pelo professor, o aluno o submeter correo. A partir de um conjunto de dados de entrada

padro, a ferramenta ir comparar os resultados alcanados pelo programa do aluno com os

resultados esperados, informando ao aluno se o programa atende ou no as especificaes do

professor.

Sander (2002), apresenta uma ferramenta de suporte ao gerenciamento do teste de

software com base nas recomendaes existentes na norma ISO/IEC 12207 para o processo de

gerncia e para as atividades de teste. A ferramenta apresenta um roteiro que orienta o gerente

na elaborao de planos de teste com o propsito de padronizar e melhorar o desempenho da

atividade de teste.

41


42/76

41

3 DESENVOLVIMENTO DO TRABALHO

Neste captulo a ferramenta desenvolvida descrita, desde o levantamento de

requisitos at a descrio de um exemplo de sua utilizao.

O desenvolvimento da ferramenta aconteceu em duas etapas distintas. Na primeira

etapa foram feitas customizaes na ferramenta CASE ArgoUML visando sua adaptao s

tcnicas adotadas. Na segunda etapa foi desenvolvida a ferramenta de suporte aoplanejamento, controle, execuo e documentao de testes (aqui denominada de TestCen)

que utiliza os diagramas estendidos gerados na ferramenta CASE ArgoUML.

3.1 REQUISITOS PRINCIPAIS DO PROBLEMA

Conforme j dito anteriormente, a baixa qualidade de software pode ter como fonte

algumas das prticas:

a) os testes no so devidamente preparados, no h um plano de teste e os testes

no so documentados;

b) o desenvolvimento dos casos de teste feito depois que o sistema foi

desenvolvido. Porm, os casos de teste podem (e deveriam) ser desenvolvidos

assim que a especificao foi desenvolvida;

c) os casos de teste no so gerados de forma sistemtica, isto , estes so

escolhidos de forma aleatria, com base no conhecimento do testador e semprocedimento definido.

Para gerar um produto de software com qualidade, um processo de qualidade (e teste)

42


43/76

suporte o planejamento, execuo e documentao do teste funcional de software com base no

padro IEEE 829.

Os principais requisitos funcionais a serem atendidos pela ferramenta incluem:

a) integrao com ferramenta CASE: a ferramenta deve permitir a leitura dos

casos de testes criados na ferramenta CASE ArgoUML;

b) planejamento de testes: a ferramenta deve permitir a manuteno dos cadastros

necessrios ao planejamento de testes incluindo os projetos de testes, casos de

testes e respectivos procedimentos de testes;

c) execuo dos casos de teste: a ferramenta deve permitir o registro de

informaes sobre a execuo dos casos de testes criados e armazenar o

histrico destas execues;

d) relatrio de erros: a ferramenta deve emitir um relatrio com os erros

encontrados na execuo de um caso de teste junto com um resumo do projeto

de teste;

e) gerao de grficos: a ferramenta deve gerar grficos sobre a cobertura de

testes realizados e testes executados.

Como principal requisito no-funcional pode-se destacar a aderncia ao padro IEEE 829 que

apresenta diversas recomendaes sobre a documentao de testes de software.

3.2 ESPECIFICAO

A i t d di d d d i

43


44/76

Fi 12 C d d f t d t t t d f i l

44


45/76

devem ser baseados no padro IEEE 829 para especificao do caso de teste

(2.4.3) e especificao do procedimento de teste (2.4.4). Este caso de uso

representa a relao com a ferramenta CASE ArgoUML;

Figura 13 Fluxo de dados entre as ferramentas

b) criar projeto e caso de teste: o analista de testes cria um projeto de teste e os

casos de teste que compe o projeto. Cada caso de teste pode estar associado a

um caso de uso. Os atributos devem ser baseados no padro IEEE 829 para

especificao do projeto de teste (2.4.2), especificao do caso de teste (2.4.3) e

especificao do procedimento de teste (2.4.4);

c) executar casos de teste: a partir dos casos de teste planejados, o testador pode

escolher um caso, de cada vez, para ser executado. Para cada execuo do caso

criado um histrico, com os dados utilizados nos testes e os resultados

obtidos, para posterior consulta;

d) gerar relatrio de erros encontrados: O testador seleciona um caso de uso e

poder gerar um relatrio dos erros encontrados. Os atributos do relatrio

devem ser baseados no padro IEEE 829 para relatrios de incidentes (2 4 7);

45


46/76

g) gerar resumo da execuo do projeto de teste: O testador poder selecionar e

gerar um relatrio com sumrio do projeto de teste. Os atributos do relatriodevem ser baseados no padro IEEE 829 para relatrios de resumo dos testes

(2.4.8).

3.2.2 Diagrama de classes

O diagrama de classe, apresentado na figura 14, representa as classes de negcio da

ferramenta TestCen. Os atributos das classes esto baseados no padro IEEE 829 e os

mtodos das classes dizem respeito a consulta e manuteno dos valores dos atributos.

A classeprojeto_testemantm as informaes que dizem respeito a todos os casos de

teste, alm da lista de casos de teste associados ao projeto. Esta classe representa aespecificao do projeto de teste descrito pelo padro IEEE 829 (ver 2.4.2).

A classe caso_teste mantm informaes relativas a configurao dos casos de teste e,

tambm a lista de procedimentos de teste. A especificao do caso de teste do padro IEEE

829 (2.4.3) representada por esta classe.

A classe procedimento_testeguarda informaes para a efetiva execuo dos testes.

Representa a especificao do procedimento de teste do padro IEEE 829 (2.4.4).

As classes histrico_execuo e resultados guardam dados do histrico de execuo

dos casos de teste e os resultados obtidos. Estes dados so usados nos relatrios e grficos

definidos nos requisitos. Os relatrios representam o relatrio de incidentes (2.4.7) e relatrio

de resumo dos testes (2.4.8)

46


47/76

47


48/76

Figura 15 Classes da customizao da ferramenta ArgoUML

3.3 IMPLEMENTAO

3.3.1 Alteraes na ferramenta ArgoUML

As classes criadas para representar os casos de teste foram implementadas no pacote

uml, conforme mostra a figura 16.

48


49/76

Figura 16 Classes implementados e/ou alteradas no ArgoUML

A classe org.argouml.uml.ui.TabTestCase1mantm as informaes do autor, reviso,

data, ambiente necessrio e procedimentos especiais do caso de teste compatveis com padro

IEEE 829 visto na seo (2.4.3). Estas informaes so persistidas como tagged values

(mecanismo de extenso da UML, ver BOOCH, RUMBAUGH e JACOBSON 2000, p.74-88)

do diagrama de casos de uso. Para criar tagged values foi utilizada a classe

UMLModelElementTaggedValueDocumentdo ArgoUML, conforme mostra a figura 17.

49


50/76

Figura 18 Guia Caso de Teste, implementada pela classe TabTestCase1

A classe org.argouml.uml.ui.TabTestCase2 implementa a guia que est representada

na figura 19.

Figura 19 Guia Caso de Teste - Procedimento, implementada pela classe TabTestCase2

Nesta classe so mantidos os dados dos procedimentos de teste (entradas e sadas).

Estas informaes tambm so persistidas como tagged valuesdo diagrama de casos de uso.

A classe TableModelTestCase2 implementa uma tabela que recebe os dados digitados e

transforma em tagged values, conforme mostra a figura 20. As tags so formadas pelos

prefixos procedimento_ e verificao_ mais o nmero da linha em que se encontram os dados

e cada valuerecebe o valor digitado na tabela.

50


51/76

Mais informaes sobre mecanismos de extenso da UML podem ser encontradas em

Booch, Rumbaugh e Jacobson (2000, p.74-88).

A classe org.argouml.uml.diagram.use_case.ui.FigTestCaseimplementa o esteretipo2

que representa o caso de teste (ver figura 21). Este esteretipo tem como base o elemento caso

de uso. Esta classe herdeira da classe FigUseCase(classe que representa o caso de uso) e a

ela foi dado o nome de esteretipo Caso de Teste. A figura 22 mostra parte do cdigo que

implementa a classeFigTestCasee o esteretipo Caso de Teste.

Figura 21 Esteretipo de Caso de Teste

Figura 22 Trecho do cdigo que implementa o esteretipo de Caso de Teste

A classe org.argouml.uml.diagram.use_case.ui.UMLUseCaseDiagram do projeto

original. Ela foi customizada, para possibilitar a insero de casos de teste no diagrama de

casos de uso (ver figura 23).

Figura 23 Barra de ferramentas customizada para permitir a incluso de casos de teste

3.3.2 Ferramenta de planejamento e execuo de testes (TestCen)

51


52/76

de teste e no segundo nvel esto os casos de teste associados ao projeto de teste. A rvore

montada em tempo de execuo a partir das instncias das classes projeto_teste e caso_teste.

Do lado direito da figura 24 utilizado o componente TPageControl, que possui trs

guias. A primeira guia (Informaes do Projeto) mostra as informaes do projeto de teste.

Esta guia aparece apenas se, no componente TTreeView, selecionado o objeto projeto_teste.

A segunda e terceira (Informaes do Caso de Teste e Casos de Teste Procedimentos)

mostram os dados de um caso de teste. Ao selecionar um caso de teste no TTreeView, os

dados do objeto correspondente so mostrados nestas guias. Para mostrar os dados foram

utilizados os componentes TEdit, TMemo e TStringGrid.

Na parte superior da figura 24 est o menu de opes e, abaixo deste, est a barra de

ferramentas com atalhos para itens do menu de opes.

52


53/76

de teste. Alm disso, pode-se visualizar o histrico de execues de um caso de teste e exibir,

em forma de rvore, os casos de teste por caso de uso.

J no menu Grficos, existem as opes de grfico de casos de teste por caso de uso,

que mostra a quantidade de casos de teste por caso de uso, e grfico de cobertura de casos de

teste, que mostra o nmero de casos de teste testados e no testados em relao ao total de

casos de teste.

No ltimo menu, Relatrios, existem as opes para imprimir os dados de um caso de

teste onde aconteceram erros na execuo e imprimir o resumo do projeto de teste.

A camada de persistncia formada por instncias das classes apresentadas na figura

14. Os dados mantidos nos campos da interface com o usurio so gravados nos objetos da

camada de persistncia. Os dados dos objetos so persistidos em disco no formato XML

atravs da opo salvar do menu Projeto de Teste ou no boto salvar da barra de ferramentas.

A figura 25 mostra um exemplo da estrutura do arquivo XML de um projeto de teste.

53


54/76

Na classe TfrmTestCen (herdeira da classe TForm), foram criados mtodos para

implementar as regras de negcio da ferramenta. Destaca-se, entre os mtodos, o mtodoimporta_XMIque faz a importao dos dados, exportados do ArgoUML, para a ferramenta. O

apndice B mostra o cdigo de implementao da importao. Para auxiliar na leitura do

arquivo XMI, foi utilizado assistente XML Data Bindingdo prprio Delphi. Baseado em um

arquivo XMI, criado com o ArgoUML, o assistente criou classes e interfaces para ler e

processar os dados do arquivo. O mtodo importa_XMIimplementa as regras de quais dadosdevem ser importados e onde devem ser gravados dentro da ferramenta TestCen.

Para implementao dos grficos, foi utilizada a classe TChart e para gerar os

relatrios foi utilizada a classe TQuickRep.

3.3.3 TCNICAS E FERRAMENTAS UTILIZADAS

Para a modelagem foi utilizada a UML com a ferramenta CASE ArgoUML. Para a

customizao da ferramenta ArgoUML foi utilizada a IDE (Integrated Development

Environment ambiente integrado de desenvolvimento) NetBeans juntamente com o pacote

de desenvolvimento JavaTM 2 SDK Standard Edition verso 1.4.2. Para a ferramenta de

planejamento e execuo de testes foi utilizada a IDE Delphi 7.

Para o desenvolvimento de todo o trabalho foram usadas tcnicas de anlise e projeto

de software orientado a objetos com UML (BEZZERA, 2002) e tcnicas de teste funcional de

software, alm de conceitos de arquitetura de software e XML.

3.3.4 OPERACIONALIDADE DA IMPLEMENTAO

Para facilitar o entendimento da ferramenta desenvolvida, foi realizado um conjunto de

54


55/76

Inicialmente o Analista precisa criar os casos de uso na ferramenta CASE ArgoUML.

Aplicando as metodologias de teste baseado em caso de uso, apresentadas por Binder (2000) eHeumann (2004), foram desenvolvidos manualmente os casos (cenrios) de teste apresentados

na figura 27. Estes casos (identificados pelo esteretipo ) foram

especificados, no diagrama de casos de uso, utilizando a modificao aplicada na ferramenta

CASE ArgoUML.

Tabela 4 Descrio do caso de uso de emprstimo de livros

Caso de uso emprestar livro

Identificador CU001

Ator primrio Aluno

Ator secundrio Bibliotecrio

Pr-condiesO aluno deve estar cadastrado no sistema de acadmicos e ter umcadastro e senha na biblioteca.

Fluxo Principal

O aluno informa os livros a serem emprestados. A bibliotecria faza leitura do cdigo de barras de cada livro e o sistema registra adata e hora do emprstimo, o cdigo do livro e qual a data dedevoluo do mesmo.

Fluxo Alternativo 1O aluno tenta emprestar um livro, porm existem livrosemprestados cuja data de entrega j venceu. O sistema no deve

permitir o emprstimo.

Fluxo Alternativo 2O aluno tenta emprestar um livro, mas existem multas no pagasde atraso na entrega de livros. O sistema no deve permitir oemprstimo.

Fluxo Alternativo 3O aluno tenta emprestar um livro, mas o nmero mximo deemprstimos j excedeu. O sistema no deve permitir oemprstimo.

Para o fluxo principal, o sistema dever ter registrado com sucesso

55


56/76

operacionais e seus valores para teste. A tabela 5 mostra as variveis operacionais para o caso

de teste do fluxo principal (Testar emprstimo de livros).Tabela 5 Variveis operacionais e valores para teste

Cdigo do aluno Cdigo do livro Data e hora do emprstimo Data da devoluo001 005 Data e hora do momento do

emprstimoData do momento deemprstimo + 7 dias

Por ltimo, foram desenvolvidos os casos de teste, incluindo os procedimentos para

execuo dos testes. Estes foram desenvolvidos com base nas descries dos casos de uso e

nas variveis operacionais identificadas. A tabela 6 apresenta a descrio do caso de teste do

fluxo principal (Testar emprstimo de livros).

Tabela 6 Procedimento de teste para fluxo principal -Testar emprstimo de livrosProcedimentos Verificaes

Na tela de validao do aluno, digitar comocdigo do aluno 001e senha abc123(j

previamente cadastrados).

O sistema dever ir para a tela de emprstimode livros.

Informar como cdigo do livro a seremprestado 005.

O sistema dever trazer as informaes dolivro: nome autor, descrio, editora e n daedio.

Confirmar a emprstimo do livro para o aluno

001.

O sistema dever mostrar uma mensagem de

confirmao do emprstimo, seguido de umalista de livros emprestados pelo aluno, ondepara o livro 005 a data e hora do emprstimodeve ser a data e hora do momento deemprstimo e a data de devoluo deve ser adata do momento de emprstimo + 7 dias.

56


57/76

Figura 27 Testes de cenrio para o caso de usoEmprestar livro

As figuras 28 e 29 mostram as especificaes do caso de teste fluxo principal (Testar

emprstimo de livros) na customizao feita no ArgoUML. A figura 29 descreve os

procedimentos para execuo do teste. Na tabela 6 foram descritos os procedimentos, desta

forma, bastou apenas copiar os procedimentos do caso de teste para o ArgoUML.

57


58/76

Figura 29 Procedimentos do caso de teste principal (Testar emprstimo de livros)

3.3.4.1 Especificao dos casos de teste na ferramenta TestCen

Aps os casos de teste terem sido especificados no ArgoUML, as informaes podemser exportadas para um arquivo XMI (XML Metadata Interchange), atravs do menu Tools,

opoExport as XMI. Este arquivo pode ser importado pela ferramenta TestCen, atravs do

menu Casos de Teste opo Importar XMI (ArgoUML) (ver figura 30). Vale lembrar que

antes de importar os casos de teste, necessrio criar um projeto de teste.

58


59/76

O prximo passo complementar as especificaes dos casos de teste, caso as

informaes importadas estejam incompletas. Neste exemplo as informaes de teste foram

importadas, mas elas poderiam ser digitadas, pois a ferramenta permite a digitao ou

importao das especificaes de teste. A figura 31 ilustra a especificao dos casos de teste.

Figura 31 Parte da especificao dos casos de teste

59


60/76

Figura 32 Execuo do caso de teste CT001

Ainda no menu Casos de Teste, existe a opoExibir Casos de Teste por Caso de Uso

que mostra a lista de casos de teste para cada caso de uso, conforme mostra a figura 33. Esta

opo facilita no rastreamento dos casos de teste por caso de uso.

60


61/76

Figura 33 Lista de casos de teste por casos de uso

No menu Grficos pode-se visualizar grficos da quantidade de casos de teste por

casos de uso e a cobertura de casos de teste. A figura 34 mostra um grfico com a quantidade

de casos de teste associada a cada caso de uso. Neste grfico os casos de teste so agrupados

por caso de uso, possibilitando uma visualizao dos casos de uso que possuem casos de teste

implementados.

61


62/76

relatrio, so mostrados os logs de execuo onde houve algum erro, para o caso de teste

selecionado. Isto , dado um caso de teste que j foi executado, pelo menos uma vez, orelatrio mostra apenas as execues onde foi encontrado algum erro.

3.4 RESULTADOS E DISCUSSO

A utilizao das metodologias apresentadas por Binder (2000, p. 722-731) e Heumann

(2004) proporcionaram uma criao mais fcil e gil dos casos de teste. A utilizao dasferramentas facilitou e organizou todo o processo de teste. Alm disso, contribuiu para a re-

execuo dos testes, isto , no momento em que o software foi alterado todos os testes

executados anteriormente foram executados da mesma forma que foram executados nas vezes

anteriores.

A utilizao dos casos de uso no teste facilitada a medida que a especificao de

requisitos e a especificao dos casos de uso feita de forma detalhada. Isto , a elicitao de

requisitos e a anlise esto intimamente ligadas ao teste e validao de requisitos.

A figura 35 mostra a cobertura das ferramentas implementadas em relao aos

documentos descritos no padro IEEE 829. Dentre os documentos especificados por estepadro apenas a especificao do plano de teste (2.4.1) e o relatrio de transio de item de

teste no foram implementados. O primeiro no foi coberto por ser um documento de

planejamento global dos testes, onde so descritas as atividades, ferramentas e estratgias que

sero utilizadas na fase de teste de um software. Este documento criado juntamente com

planejamento de um projeto de software e neste ponto no se tem uma viso detalhada dosrequisitos. O segundo no foi coberto por ser um documento de comunicao entre a rea de

desenvolvimento e a rea de testes.

62


63/76

FerramentaTestCen

Ferramentas TestCen eArgoUML

Ferramenta TestCen

63


64/76

4 CONCLUSES

A utilizao das metodologias e ferramentas apresentadas neste trabalho podem

auxiliar as equipes de teste a verificar e validar os requisitos de software de forma simples e

organizada.

Os objetivos definidos foram alcanados. Uma ferramenta de suporte ao planejamento

do teste funcional de software a partir dos diagramas de casos de uso foi desenvolvida. Asmetodologias de teste baseada em casos de uso da UML, apresentadas por Heumann (2004) e

Binder (2000, p. 722-731), foram aplicadas e facilitaram a criao de casos de teste. A

ferramenta CASE ArgoUML foi adaptada para incorporar extenses a casos de testes. Isto foi

possvel com a utilizao do mecanismo de criao de novos esteretipos disponvel na

ferramenta CASE. Alm disso a ferramenta desenvolvida utilizou boa parte dos padresexistentes na IEEE 829 e que facilitaram e organizaram o processo de planejamento e

execuo dos testes.

importante salientar que o trabalho apresentado apenas supre parte do que a

atividade de teste deve contemplar. Isso significa que o teste no se limita apenas a testar e

validar os requisitos funcionais. Outros testes, como teste de performance, de carga, de

unidade e integrao, devem ser executados durante a atividade de testes e estes tambm

devem ser feitos de forma sistemtica e organizada .

Outro aspecto a ser considerado o conjunto de testes elaborados para a validao das

ferramentas. Os testes ficaram restritos ao orientando e seu orientador.

Futuramente pretende-se disponibilizar a ferramenta nas disciplinas de engenharia de

software da FURB visando facilitar o entendimento de conceitos sobre testes de software a

64

li d O i d d t i t d i d l d


65/76

aplicados. O mecanismo de reproduo teria como entrada o arquivo gerado pelo gravador e

ento reproduziria a interao que o usurio teve. Alm disso, o arquivo (chamado de script)poderia ser alterado manualmente e a este poderiam ser acrescentados comandos de interao

e controle de fluxo. Desta forma a mesma interao com a interface poderia ser feita com

dados diferentes.

Outra sugesto seria o estudo de tcnicas de inteligncia artificial como, por exemplo,

processamento de linguagem natural aplicada a automatizao do processo de testes baseados

em casos de uso.

65

REFERNCIAS BIBLIOGRFICAS


66/76

REFERNCIAS BIBLIOGRFICAS

BARTI, Alexandre. Garantia da qualidade de software: adquirindo maturidadeorganizacional. Rio de Janeiro: Elsevier, 2002.

BEZERRA, Eduardo. Princpios de anlise e projeto de sistemas com UML. Rio deJaneiro: Campus, 2002.

BINDER, Robert V. Testing object-oriented systems: models, patterns and tools. Addison-Wesley, 2000.

BOOCH, Grady; RUMBAUGH, James. JACOBSON, Ivar. UML, guia do usurio. Rio deJaneiro: Campus, 2000.

CAVARRA, Alessandra et al. Using UML for automatic test generation. Disponvel em:. Acesso em:08 set. 2003.

HEUMANN, Jim. Generating test cases from use cases. Disponvel em:. Acesso em: 20 jan. 2004.

INSTITUTE OF ELECTRICAL AND ELECTRONIC ENGINEERS. IEEE Std 829-1998:IEEE standard for software test documentation. Nova York, 1998.

OFFUTT, Jeff; ABDURAZIK, Aynur. Using UML collaboration diagrams for staticchecking and test generation. Disponvel em:. Acesso em: 08 set. 2003a.

OFFUTT, Jeff; ABDURAZIK, Aynur. Generating tests from UML specifications.Disponvel em: . Acesso em:08 set. 2003b.

l f d k il

66

REGNELL Bjrn; RUNESON Per; WOHLIN Claes Towards integration of use case


67/76

REGNELL, Bjrn; RUNESON, Per; WOHLIN, Claes. Towards integration of use casemodelling and usage-based testing. Disponvel em:

. Acesso em: 20 out. 2003.

ROCHA, Ana R. Cavalcanti da; MALDONADO, Jos C; WEBER, Kival C. Qualidade desoftware: teoria e prtica. So Paulo: Prentice Hall, 2001.

ROSA, Edson. Software de apoio a etapa de testes, utilizando tcnicas de caixa preta.1997. 67 f. Trabalho de Concluso de Curso (Bacharelado em Cincias da Computao) -Centro de Cincias Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.

RYSER, Johannes; GLINZ, Martin. A practical approach to validating and testingsoftware systems using scenarios. Disponvel em:. Acessoem: 01 set. 2003.

SANDER, Izabela. Sistema de gerenciamento do teste de software baseado na normaISSO/IEC 12207. 2002. 64 f. Trabalho de Concluso de Curso (Bacharelado em Cincias daComputao) - Centro de Cincias Exatas e Naturais, Universidade Regional de Blumenau,Blumenau.

SANTIAGO, Denise. Ferramenta para teste de programas utilizando componentes da

biblioteca CLX. 2002. 57 f. Trabalho de Concluso de Curso (Bacharelado em Cincias daComputao) - Centro de Cincias Exatas e Naturais, Universidade Regional de Blumenau,Blumenau.

SEPIN. Qualidade dos produtos de software. Disponvel em:. Acesso em:15 abr. 2004.

SOMMERVILLE, Ian. Engenharia de software.6. ed. So Paulo: Addison Wesley, 2003.

TOLKE, Linus. ArgoUML Project. Disponvel em: . Acesso em:

67

APNDICE A Relatrio de erros por caso de teste


68/76

APNDICE A Relatrio de erros por caso de teste

68

APNDICE B Cdigo fonte da importao do arquivo XMI


69/76

APNDICE B Cdigo fonte da importao do arquivo XMI

//Importa arquivo XMIprocedure TfrmTestCen.importa_XMI;var

i, i1, i2, i3, i4, i5 : integer;docXMI: IXMLXMIType;contentType: IXMLXMIcontentType;modelo: IXMLModel_ManagementModelType;ownedElement: IXMLFoundationCoreNamespaceownedElementType;listaEstereotipo: IXMLFoundationExtension_MechanismsStereotypeTypeList;estereotipo: IXMLFoundationExtension_MechanismsStereotypeType;LUseCase: IXMLBehavioral_ElementsUse_CasesUseCaseTypeList;UseCase: IXMLBehavioral_ElementsUse_CasesUseCaseType;useCaseEstereotipo:

IXMLFoundationExtension_MechanismsStereotypeextendedElementType;listaTaggedValue: IXMLFoundationCoreModelElementtaggedValueType;listaAssociacoes: IXMLFoundationCoreAssociationTypeList;associacao: IXMLFoundationCoreAssociationType;conexao: IXMLFoundationCoreAssociationconnectionType;

tempCasoTeste: caso_teste;tempProcedimento: procedimento_teste;

begin

//Abre arquivo XMI para importaodocXMI:= LoadXMI(odImportaXMI.FileName);contentType:= docXMI.XMIcontent;modelo:= contentType.Model_ManagementModel;

ownedElement:= modelo.FoundationCoreNamespaceownedElement;ListaEstereotipo:= ownedElement.FoundationExtension_MechanismsStereotype;

//Busca esteretipos de caso de testefor i:= 0 to ListaEstereotipo.Count - 1 dobeginestereotipo := ListaEstereotipo.Items[i];if estereotipo.FoundationCoreModelElementname = 'Caso de Teste' thenbegin

useCaseEstereotipo:=

estereotipo.FoundationExtension_MechanismsStereotypeextendedElement;break;endelse

estereotipo:= nil; //endifend; //endfor

69

if estereotipo nil theni


70/76

begin//Inicializa treeview

tvTestCen.Items.item[0].Selected := true;// busca lista de casos de usoLUseCase:= ownedElement.Behavioral_ElementsUse_CasesUseCase;

for i:=0 to LUseCase.Count -1 dobegin//Pega caso de uso da vezUseCase:= LUseCase.Items[i];

//Verifica se um caso de teste - se o caso de uso possui o esteretipode caso de teste

for i1:=0 to useCaseEstereotipo.Count - 1 dobegin

if UseCase.Xmiid =useCaseEstereotipo.FoundationCoreModelElement[i1].Xmiidref then

begin//Importa caso de testetempCasoTeste := caso_teste.Create;

tempCasoTeste.Set_id(UseCase.FoundationCoreModelElementname);

//Busca Associaes com os casos de usolistaAssociacoes:= ownedElement.FoundationCoreAssociation;for i4:= 0 to (listaAssociacoes.Count - 1) dobegin

associacao:= listaAssociacoes.Items[i4];conexao:= associacao.FoundationCoreAssociationconnection;for i5:=0 to (LUseCase.Count - 1) dobegin

//Verifica se existe conexoif ((LUseCase.Items[i5].Xmiid =conexao.FoundationCoreAssociationEnd[0].FoundationCoreAssociationEndtype.FoundationCoreClassifier.Xmiidref) or

(LUseCase.Items[i5].Xmiid =conexao.FoundationCoreAssociationEnd[1].FoundationCoreAssociationEndtype.FoundationCoreClassifier.Xmiidref)) and

((conexao.FoundationCoreAssociationEnd[1].FoundationCoreAssociationEndtype.FoundationCoreClassifier.Xmiidref = UseCase.Xmiid) or

(conexao.FoundationCoreAssociationEnd[0].FoundationCoreAssociationEndtype.FoundationCoreClassifier.Xmiidref = UseCase.Xmiid)) then

begin

tempCasoTeste.Set_use_case(LUseCase.Items[i5].FoundationCoreModelElementname);break;

70

if(listaTaggedValue FoundationExtension MechanismsTaggedValue[i2] FoundationExte


71/76

(listaTaggedValue.FoundationExtension_MechanismsTaggedValue[i2].FoundationExtension_MechanismsTaggedValuetag = 'autor') then

tempCasoTeste.Set_autor(listaTaggedValue.FoundationExtension_MechanismsTaggedValue[i2].FoundationExtension_MechanismsTaggedValuevalue);

if(listaTaggedValue.FoundationExtension_Mechan

FERRAMENTA DE SUPORTE AO PLANEJAMENTO DE TESTE FUNCIONAL DE SOFTWARE A PARTIR DE DIAGRAMAS DE CASOS...

Documents

Transcript of FERRAMENTA DE SUPORTE AO PLANEJAMENTO DE TESTE FUNCIONAL DE SOFTWARE A PARTIR DE DIAGRAMAS DE CASOS...