Extrao de casos de teste a partir de modelos de processos de

negcio

Henrique Prado Sousa1, Andr Luiz de Castro Leal1,2, Arndt von Staa1, Julio Cesar Sampaio do
Prado Leite1
1
Departamento de Informtica
Pontifcia Universidade Catlica do Rio de Janeiro (PUC-Rio)
Rio de Janeiro, RJ, Brasil
2
Departamento de Matemtica
Universidade Federal Rural do Rio de Janeiro (UFRRJ)
BR-465, Km 7, Seropdica, Rio de Janeiro - CEP 23890-000
hps.infotec@gmail.com, andrecastr@gmail.com, arndt@inf.puc-rio.br, www.inf.puc-rio.br/~julio

Resumo. A modelagem de processos de negcio um recurso que vem sendo empregado

com diversas finalidades, entre as quais, planejamento e alinhamento estratgico. Na
engenharia de requisitos, os modelos de processos de negcio tambm so utilizados como
insumos na extrao de requisitos de software, os quais devero ser utilizados com base para
testes posteriores. Neste sentido, propomos um mtodo de extrao de sutes de testes a partir
de modelos de processo de negcio. A identificao dos casos de testes baseada na juno
de heursticas de identificao de requisitos e novas heursticas inspiradas em mtodos de
gerao de casos de testes a partir de casos de uso e diagrama de estados. O produto uma
sute de casos de teste definida ainda nas fases iniciais do desenvolvimento, com base em
informaes de contexto.
Keywords: casos de teste, sute de teste, software, processos de negcio, BPM.

1 Introduo
Nos projetos de desenvolvimento de software, a correta definio dos requisitos ainda um
desafio para a Engenharia de Requisitos (ER). Como fator agravante, o custo da identificao de
problemas inseridos nas fases iniciais da construo de software crescente ao longo do ciclo de
desenvolvimento, muitas vezes de forma exponencial [6] [20]. Mesmo quando bem definidos, os
requisitos podem sofrer problemas de implementao, projeo de arquitetura e tecnologias, e
acarretar prejuzos crescentes ao longo do tempo incorridos nas tentativas de reverter o problema.
O custo relativo para corrigir um defeito nas diferentes fases de construo de um
software se eleva conforme o andamento do projeto. Este custo menor durante as fases iniciais
porque ainda existem poucos artefatos que possam vir a necessitar de correo [18]. Na existncia
de erros, o maior nmero de produtos desenvolvidos provavelmente demandar um efeito cascata
para a correo dos erros encontrados.
Alguns projetos de desenvolvimento de software gastam de trinta a cinquenta por cento
do oramento na realizao de testes, entretanto, a maioria dos usurios identifica que os softwares
no so bem testados antes da entrega [14]. Uma possvel explicao para a ineficincia dos testes
a sua realizao apenas na ltima etapa do processo de desenvolvimento, momento em que
oramento e prazo j se encontram bastante limitados. Somado a isso, alm de ser uma tarefa
complexa, muitas vezes, os testes so realizados sem seguir mtodos bem definidos.
Para auxiliar a tarefa de testes de software, o presente trabalho sugere a projeo de sutes
de testes logo nas fases iniciais do desenvolvimento, com base em informaes do contexto
presentes em modelos de processos de negcio, as quais tambm podero ser utilizadas na
elicitao de requisitos. Os casos de teste so definidos a partir da identificao de
funcionalidades em um modelo de processo, bem como outras caractersticas pesquisadas nas
maiorias dos mtodos de gerao de casos de teste a partir de artefatos de requisitos. Como os
modelos de processos de negcio so elementos fundamentais nesta proposta, ela somente se
aplica aos projetos os quais possuem este artefato disponvel.
Com uma sute de testes projetada praticamente em conjunto com os requisitos, espera-se
que ela oriente a fase de construo do software ao fornecer informaes prvias sobre o fluxo dos
casos de testes que devero ser realizados, produzindo um efeito colateral que pode ser benfico
qualidade dos artefatos a serem produzidos. Isso pode ocorrer porque a formulao de casos de
teste requer a identificao dos cenrios, a valorao dos dados e a definio de orculos ou
resultados esperados, o que reforar a demanda pelo o conhecimento necessrio do domnio para
a definio desses elementos. Os processos que geram esses artefatos so, portanto, benficos,
porque antecedem informaes que podem auxiliar ao engenheiro de requisitos na identificao de
possveis erros, impedindo que sejam propagados para artefatos/produtos posteriores. Reduz-se
assim o custo do projeto atravs da reduo significativa do retrabalho.
Outro benefcio que o uso de modelos de processos de negcio como insumo em um
processo de elicitao beneficia o alinhamento dos requisitos ao negcio, desta forma, os casos de
testes extrados do mesmo modelo, e incorporando o mesmo processo de identificao de
requisitos, alm de garantir uma boa cobertura, tambm incluir nos testes cenrios alinhados ao
negcio.
Diante disso, o objetivo principal deste trabalho apresentar como os modelos de
processos de negcio podem contribuir para a definio de casos de testes de software.
Entendemos que a modelagem de processos possui grande variao de elementos com semntica
rica, e conseguem representar os requisitos de sistema em diferentes nveis de abstrao. A partir
disso, unimos esta capacidade a algumas heursticas de um mtodo de identificao de servios, e
novas heursticas complementares baseadas em outros mtodos de definio de casos de teste
presentes na literatura. Para alcanar este objetivo, iniciamos com o estudo de mtodos para
gerao de casos de teste a partir de artefatos de requisitos. Isso permitiu a identificao dos
elementos necessrios para a definio dos casos de teste e as tcnicas de extrao das informaes
para a composio dos casos de teste a partir de processos de negcio. Por fim, criamos um
pequeno exemplo de aplicao destas heursticas e analisamos os resultados baseado no nvel de
detalhe existente no modelo e nvel de abstrao.
O presente artigo est dividido nas seguintes sees: na seo 2, esto descritas algumas
caractersticas de uso de requisitos na extrao de testes; na seo 3 so analisadas as
caractersticas presentes em um modelo de processo de negcio em relao aos elementos
necessrios para permitir a extrao dos casos de teste, na seo 4, discorre-se a respeito do
mtodo de identificao de requisitos a partir de modelos de processos de negcio; na seo 5
apresentado o mtodo proposto; e por fim, na seo 6, esto as concluses.

2 Uso de artefatos de requisitos na extrao de testes

Nos processos de desenvolvimento de software tradicionais, as atividades de teste costumam ser
uma das ltimas a serem realizadas. Este tipo de abordagem possui falhas, uma vez que so
comuns os erros na definio e/ou interpretao dos requisitos, o que resulta em projeto e
implementao do software de forma equivocada. Os requisitos definem o que o software deve
fazer e como se comportar, sendo obrigatrio satisfaz-los integralmente para que o projeto de
software alcance os seus objetivos. Por isso, importante considerar os requisitos na elaborao de
testes, a fim de verificar se o produto de software corresponde s necessidades esperadas.
Os requisitos so expressos de diversas formas, comumente utilizando documentos
textuais e modelos. Devido ao maior grau de formalidade, os modelos so os artefatos mais
utilizados na elaborao de testes de software. Entre os modelos mais usados, so os que compem
a UML, como o OCL (Object Constraint Language), e diagramas de objetos e especificao do
tipo Z [21]. Cada modelo oferece um conjunto de informaes distintas que, baseado em suas
caractersticas, auxiliam a gerao de testes em diferentes nveis, por exemplo, testes de sistema,
testes de integrao, testes de unidade, testes de regresso, e testes de stress [21]. Entretanto,
importante destacar que a abordagem de testes baseada em requisitos, portanto, demanda
modelos corretamente descritos. Uma forma de verificar isso atravs da aplicao das propostas
de checagem de modelo [19], [12], [21], muitas delas desenvolvidas para se integrarem s
abordagens de gerao de testes a partir de requisitos.
Os modelos de requisitos utilizados como insumo devem oferecer um conjunto de
informaes mnimas que possam ser extradas e disponibilizadas para a construo de casos de
testes. Devem contemplar, se possvel, cada uma das possibilidades de desvios na execuo de
procedimentos que visam satisfao de um requisito. Independente dos artefatos utilizados na
gerao de casos de teste, os seguintes elementos so necessrios: comportamento do sistema [21],
responsvel por definir como ele deve responder aos comandos do usurio e aos estados
alcanados; informaes que so tratadas e geradas no requisito, ou seja, os dados (em seu devido
formato) necessrios para oferecer o insumo correto na execuo dos testes e a verificao do
produto final; momento de inicio de execuo do requisito, caracterizado pelo estado que dispara a
execuo do requisito; produtos gerados na execuo do requisito (se houverem); momento de
finalizao do requisito, caracterizado pelo estado que deve ser alcanado aps a execuo do
teste.
No so todos os artefatos que possuem este conjunto de informaes, por outro lado, os
projetos de desenvolvimento de software no produzem todos os artefatos possveis. Portanto, para
cada projeto, deve-se escolher os artefatos de acordo com suas necessidades [13], uma vez que no
h melhores prticas definidas no contexto de testes de software [15]. Estas informaes sobre os
requisitos constituem os elementos bsicos necessrios para definio de um caso de teste: Estado
inicial - momento que caracteriza o incio do caso de teste. Dados de entrada - informaes
necessrias para execuo do teste. Comportamento - quais tarefas e como devem ser executadas.
Dados de sada - produtos gerados na execuo satisfatria do cenrio. Estado final - momento que
caracteriza o fim do caso de teste (estes elementos so mais detalhados posteriormente).
De forma geral, os mtodos buscam identificar as possibilidades de execuo dos
requisitos no sistema, seus eventos de disparo e eventos finais. A partir deste conjunto de
informaes, so geradas listas de casos de testes, o que muitas vezes resulta em um nmero
extenso. Alguns autores propem mtodos para reduzir o conjunto de casos de testes com critrios
para identificao de casos de teste fora do escopo (ao reduzir o escopo) ou no possveis de
executar no mundo real. Alguns mtodos utilizam diagramas individualmente ou combinados [27],
de acordo com os tipos de testes desejados que possam ser mais ou menos abstratos e abrangentes.
Alm da presena de elementos bsicos nos modelos, ainda devem ser definidos os
critrios de cobertura, que consistem em regras que visam alcanar de forma adequada os cenrios
possveis baseados em suas caractersticas e recursos oferecidos no modelo. Por exemplo, [28]
aplica um conjunto de critrios especficos como mtrica para cobertura dos requisitos a partir de
diagramas de estados. Alguns deles so: Critrio de cobertura dos estados: Todos os estados de um
diagrama de estados devem ser atingidos pelo menos uma vez. Critrio de cobertura das
transies: Todas as transies devem ser exercidas. Critrio de cobertura dos caminhos: Todos os
caminhos criados segundo critrios de seleo devem ser exercidos. Condio de cobertura: Uma
condio considerada coberta se o resultado de sua avaliao for verdadeiro ou falso em algum
momento durante a execuo do teste.
3 Caractersticas dos modelos de processos de negcio
Modelos de processos de negcio podem ser utilizados como material de apoio na gesto da
organizao, bem como em projetos de informatizao dos processos. Para isso so projetados em
momento anterior ao desenvolvimento de software, com informaes que permitem indicar onde,
quando e como as funcionalidades so executadas no processo. Um modelo de processo de
negcio pode ser utilizado tanto para conhecimento do domnio como uma fonte de informao
para a elicitao de requisitos. Em [4] proposto um conjunto de heursticas para extrao de
requisitos a partir de modelos de processo de negcio, de forma automtica.
Os modelos de processos de negcio possuem a capacidade de expressar grande nmero
de elementos de negcio em seus diagramas, como fluxo de atividades, eventos iniciais,
intermedirios e finais, atores, fluxo de informaes, regras e requisitos de negcio, pontos de
controle, artefatos, termos, telas, regras de negcios.
Outra caracterstica importante que um modelo que apresenta o nvel de fluxo de
atividades de um processo de negcio detalha os diversos caminhos que uma instancia de processo
pode seguir baseado em seus possveis estados intermedirios. Estes estados intermedirios podem
ser comparados aos fluxos alternativos de um caso de uso, ou ainda a um diagrama de estados,
portanto, cada possvel caminho pode gerar um caso de teste. Os elementos representativos que
compem modelos de processo de negcio podem representar informaes suficientes para a
gerao de casos de teste devido a sua riqueza de representao. Alm disso, possvel explorar
ainda outros elementos que detalham mais as informaes e procedimentos envolvidos nas
execues das atividades, por exemplo, as regras de negcio e os requisitos de negcio.
A execuo de uma atividade em um processo deve contribuir de alguma forma ao
negcio, ou seja, deve agregar valor para algum elemento envolvido no contexto, uma vez que, se
atividade no traz nenhum benefcio ao processo, ela no deveria existir.
Portanto uma atividade, mesmo que com pequena contribuio, leva o processo de um
estado para outro, ainda que esta mudana de estado no signifique um elemento concreto para a
organizao. Algo sempre processado, mesmo que manualmente, resultando na transformao de
um elemento alvo (ex. informao ou artefato), mesmo que seja, por exemplo, uma alterao do
estado de uma informao, que sai da memria de um computador para um papel impresso.
As transformaes realizadas nos elementos que trafegam pelos processos de negcio
podem ser executadas integralmente por meio computacional, parcialmente com o auxlio de
software operados por pessoas ou completamente manual. Algumas das atividades manuais podem
posteriormente sofrer alteraes em sua execuo caso a organizao implante um sistema para
apoiar os processos, ou ainda, serem substitudas.
Quando tratamos processos que j possuem o mapeamento de sistemas, podemos
considerar que na dada atividade onde o sistema aparece h um ou mais requisitos implementados.
Em uma mesma atividade possvel que o papel executor faa a leitura de um cadastro
(funcionalidade 1), altere as informaes (funcionalidade 2), obedecendo a uma regra de negcio
(funcionalidade 3), e ao final grave a informao (funcionalidade 4). Neste exemplo, identificam-
se quatro funcionalidades de sistema que podem estar mapeadas em uma nica atividade.
Entretanto, essas funcionalidades representam requisitos que possuem caractersticas atmicas e
podem compor requisitos mais abstratos, que abrangem maior nmero de funcionalidades.
Partindo deste pressuposto, o processo tambm pode ser analisado considerando seus fluxos de
atividades. Por exemplo, um ciclo presente em um processo poderia representar um requisito que
executado diversas vezes at alcanar um dado estado que permita prosseguir com o processo. O
ciclo pode ser composto por um conjunto de atividades que possuem diversas funcionalidades e
regras de negcio.
Entre as diversas notaes que esto disponveis para a modelagem de processos, a UCM
(Use Case Map) [31], apresenta caractersticas especiais que demonstram a utilidade dos modelos
de processos de negcio na extrao de casos de teste. Ela foi inicialmente desenvolvida para
modelar cenrios comportamentais durante o projeto de alto nvel em sistemas reativos
distribudos. Posteriormente foi considerado um recurso adequado e til para a modelagem e
anlise de processos de negcio, e que satisfaz os objetivos de uma linguagem BPM [10].
A reutilizao de uma notao inicialmente projetada para a modelagem de cenrios, na
modelagem de processo, evidencia que se uma linguagem para modelagem de cenrios pode ser
abstrada para a modelagem de processos de negcios, ento tambm poderamos utilizar a
notao de processos de negcio para gerar casos de teste, uma vez que possvel gerar testes a
partir de cenrios.
Entretanto, existem outras as notaes com maior capacidade de representao de
elementos do negcio [22], tais como a BPMN [8] e a EPC (Event-driven Process Chain) [29],
que podem ser utilizadas em conjunto ao mtodo proposto neste trabalho [7], [22], [30].

4 Identificao de requisitos a partir de processos de negcio

A modelagem de processos geralmente segue a representao dos processos organizacionais em
diferentes nveis (trs nveis) de abstrao: o primeiro nvel formado pelos macroprocessos (nvel
mais abstrato, respectivo cadeia de valor organizacional); o segundo nvel detalha o fluxo de
atividades do processo, composto por um ou mais papis executores, atividades, fluxos,
operadores lgicos e eventos; o terceiro nvel detalha o nvel operacional demonstrando
informaes sobre a execuo de cada atividade e os elementos envolvidos [29]. A partir do
segundo e terceiro nvel possvel identificar requisitos de software, uma vez que esto presentes
elementos operacionais.
O mtodo de identificao de requisitos sugerido nesse trabalho adaptado do mtodo de
identificao de servios a partir de modelos de processos de negcio [2], [3], seguindo uma
anlise top-down dos modelos. Essa anlise identifica os requisitos baseados nos objetos que
compem o modelo, seja por sua definio (por exemplo, regras de negcio, requisitos de negcio
e cluster) ou por caractersticas padronizadas no fluxo de atividades do processo (por exemplo,
ciclo de atividades e sequncia de atividades) [22].
Os requisitos identificados atravs deste mtodo so considerados requisitos
candidatos, uma vez que se torna necessria a verificao posterior de um engenheiro de
requisitos para identificar entre os elementos extrados, quais no so de interesse. Observa-se que
o mtodo baseado em heursticas, e suas identificaes no necessariamente podem estar no
escopo de um dado projeto. O Requisito candidato uma abstrao (no implementada) de um
requisito, que pode vir a ser implementada como um servio fsico (por exemplo, como Web
Service) ou como uma funcionalidade de uma aplicao.
O mtodo de identificao de requisitos candidatos subdividido em trs etapas: A)
Seleo de atividades: so selecionadas atividades automatizadas (executadas por sistema),
apoiadas por sistema (executadas por pessoas, mas utilizando um sistema) e automatizveis
(atividades manuais que se pretende automatizar). Atividades manuais e que no esto sendo
consideradas para automatizao so descartadas, j que no h requisitos envolvidos. B)
Identificao de requisitos candidatos: os modelos de processos de negcio so analisados de
acordo com um conjunto de heursticas definidas por [2], [3]. As heursticas analisam a estrutura e
semntica dos modelos de processos: - Para anlise da estrutura baseiam-se nos padres de
workflow [5], [23] e [26] e cobrem todas as possibilidades de fluxos de atividades que podem ser
representadas por um modelo de processo; Para anlise semntica, so considerados os elementos
dos modelos, tais como os requisitos de negcio, informaes de entrada e sada e regras de
negcio. A semntica destes elementos indica as funcionalidades que podem ser implementadas
em servios de apoio ao processo. O resultado desta etapa a identificao de requisitos
candidatos de dados (executam operaes CRUD (Create, Read, Update, Delete) sobre os dados)
e/ou servios candidatos de lgica (executam regras de negcio e eventualmente podem incluir
operaes CRUD). C) Consolidao de requisitos candidatos: na terceira etapa, os requisitos
candidatos identificados na etapa anterior so analisados e so geradas informaes referentes
granularidade, grau de reuso, dependncia entre servios, associaes dos servios com as
atividades de onde foram identificados, papis que os executam e sistemas que podero invoc-los.
As informaes geradas na etapa de consolidao so apresentadas em tabelas, grficos e
grafos de dependncia, para tornar possvel a manipulao dos resultados pela equipe de
requisitos. Estas informaes so utilizadas nas fases de anlise e projeto de software, a fim de
definir a melhor forma de implementao do conjunto de requisitos candidatos [22]. Assim uma
representao da proposta seria a partir de:
MODELO DE NEGCIO HEURSTICAS REQUISITOS CANDIDATOS
Considerando que apesar da UCM ser utilizada para a modelagem de processos de
negcio e que alguns autores ainda a consideram inadequada [24], [17], [7] por oferecer poucos
recursos, ento podemos esperar que uma notao mais abrangente como a BPMN [8] possua
maior capacidade de oferecer a gerao de casos de teste devido a maior riqueza sinttica e
semntica de seus componentes, uma vez que a UCM, mesmo com suas limitaes, utilizada
com este objetivo [1].

5 Mtodo para gerao de casos de teste a partir de processos de negcio

Os modelos de processos de negcio podem expressar grande nmero de elementos do negcio,
podendo representar diversas camadas de abstrao, como tambm diferentes nveis de detalhe.
Portanto, existe um problema de abstrao e detalhamento que afeta o resultado dos casos de teste.
A gerao de casos de testes estar limitada pela complexidade e detalhamento do contedo do
modelo de processo. Por exemplo, um diagrama no precisa conter obrigatoriamente detalhes
sobre regras de negcio relacionadas s atividades as quais se aplicam, ou uma atividade pode ser
abstrata o suficiente de forma a esconder detalhes que definem outras atividades ou ficando
muito densa, com diversos elementos de entrada e sada e muitas tarefas em sua descrio.
Independente desses fatores, o mais importante que a modelagem esteja adequada (tanto
no contexto da notao quanto na qualidade de corretude do mapeamento dos elementos do
negcio para o modelo), j que o produto desta proposta ser uma sute de casos de teste que
dever ser criticada por um engenheiro de software. A necessidade de mais ou menos informao,
incluso de novos casos, excluso de testes similares ou fora de escopo, de sua responsabilidade.
Na identificao de requisitos a partir de processos de negcio, as heursticas geram
requisitos candidatos. A palavra candidato foi includa justamente porque, devido aplicao
das heursticas e natureza automatizada das identificaes, no se pode afirmar que estes
elementos so de fato requisitos de um projeto [2]. O mesmo pensamento aplicado lista de
casos de teste resultante do mtodo. Outro fator importante o da cobertura da identificao de
requisitos que, segundo [25], um problema NP. Portanto, isso justifica o uso de heursticas, j
que definir um mtodo preciso e plenamente correto ainda considerado invivel.
Dividida em passos, o processo de gerao de casos de teste a partir de processos de
negcio pode ser resumidos cmoda seguinte forma: PRIMEIRO PASSO: consiste na modelagem
dos processos de negcio. Recomendamos os cuidados na modelagem das regras de negcio e nas
boas prticas de modelagem. Cada atividade deve agregar valor ao negcio, ou seja, ela deve
alterar o estado de algum elemento do processo, auxiliando em algum nvel o processo a alcanar
seus objetivos. Assim, as atividades representaro tarefas e elementos que os sistemas de software
muito possivelmente devero abordar em suas funcionalidades. SEGUNDO PASSO: consiste na
aplicao do mtodo de identificao de requisitos, apresentado na sesso anterior. A aplicao
deste mtodo importante para que os requisitos sejam identificados ao longo dos elementos de
processo de negcio, j que poderemos agrup-los posteriormente lista de funcionalidades a
serem testadas nos casos de teste. Um caso de teste no verificar uma, e somente uma
funcionalidade do sistema, uma vez que um requisito pode agregar muitas funcionalidades que
devem ser testadas, ou seja, torna-se um requisito denso, principalmente devido ao seu nvel de
abstrao. TERCEIRO PASSO: consiste em delimitar os casos de teste. Neste passo, baseamo-nos
nos mtodos de gerao de casos de testes aplicados em outros modelos, por exemplo, um
diagrama de estados ou caso de uso. Um caso de uso pode possuir diversos caminhos a serem
testados, j que define alm do fluxo principal, os n possveis fluxos alternativos. Isso se
assemelha a um processo de negcio, que atravs dos operadores lgicos e eventos, criam diversos
caminhos possveis para a execuo do processo. QUARTO PASSO: os engenheiros de software
devem criticar a lista final de casos de teste de forma a identificar quais se aplicam s suas
necessidades de teste, que podem, por exemplo, ser reduzida pelo escopo de atuao dos testes que
desejam no dado momento.
No mtodo proposto, dois elementos so variantes: os requisitos candidatos identificados
atravs de elementos explcitos que afetam diretamente os requisitos do sistema; e os requisitos
candidatos identificados atravs de sequncias recorrentes nos processos (padres de workflow)
que podem representar funcionalidades compostas que possuem grande potencial de reuso.
No primeiro caso, o mtodo de identificao de requisitos [2] busca por elementos
especficos que expressam diretamente requisitos bsicos em um sistema: regras de negcio,
informaes de entrada e sada que sofrem operaes CRUD, e requisitos de sistemas explcitos1.
Neste trabalho, utilizamos as seguintes heursticas de requisitos bsicos (HRB) (adaptado de [4],
[22]):
HRB1 (regra de negcio): Um requisito candidato deve ser identificado a partir de uma regra de
negcio.
HRB2 (informao de entrada e sada): Um requisito candidato deve ser identificado para cada
informao de entrada de uma atividade (caracterizado como requisito de leitura), assim como um
requisito candidato de dado deve ser identificado para cada informao de sada de uma atividade
(caracterizado como requisito de escrita) desde que as informaes estejam associados a
portadores de informao (por exemplo, banco de dados, e-mail e documentos eletrnicos).
Adicionamos nova heurstica para abordar as atividades automatizadas, uma vez que
representam uma funcionalidade e devem ser listados como itens para possveis testes isolados.
HRB3 (atividades automatizadas): Um requisito candidato deve ser identificado para cada
atividade automatizada.
No segundo caso, o mtodo de identificao de requisitos [2] busca pelos fluxos de
processo que se enquadram nos padres de workflow. Estes padres identificam fluxos especficos
que evidenciam funcionalidades dentro de um processo devido a sua caracterstica de execuo
sequencial de atividades e repetio. Por exemplo, podemos citar um fluxo de ciclo que pode ser
executado diversas vezes seguidas at um evento ser satisfeito. A repetio caracterstica desse
fluxo remete a uma funcionalidade bem definida que executada repetidamente enquanto um
estado for verdadeiro. Neste trabalho, utilizamos as seguintes heursticas de padro de workflow
(HPW) (adaptado de [4], [22]):
HPW1 (atividades sequenciais): Um requisito candidato deve ser identificado a partir de um
conjunto de atividades sequenciais automatizadas ou apoiadas por sistema (uma atividade
sequencial definida por uma sequncia de no mnimo duas atividades executadas seguidamente,
sem a interferncia de operadores lgicos (OR, XOR ou AND)).
HPW2 (ciclo de atividades - Loop): Um requisito candidato deve ser identificado a partir de uma
estrutura do workflow onde uma ou mais atividades podem ser executadas repetidamente.
Ainda existem as heursticas de padro de workflow OR, AND, XOR, Interface de
processo e atividades de mltiplas instncias que podem ser acessadas em [4] e [22].

1 A maioria das notaes no oferece o elemento Requisito de sistema.

 Os fluxos de processos tambm definem os diferentes cenrios de um processo. Estes
cenrios so divises que ocorrem a partir dos operadores lgicos, e os caminhos a seguir so
definidos atravs dos diferentes eventos intermedirios. A partir dos padres de workflow, da
representao de possveis cenrios nos processos de negcio e estudo dos critrios de cobertura
presentes em [28], propomos duas novas heursticas de cobertura de cenrios (HCC):
HCC1 (eventos inicial e final): um fluxo de cenrio identificado quando houver uma sequncia
de atividades presentes entre um evento inicial e um evento final. Se houver mais de um fluxo a
ser percorrido, todos devero ser considerados. A partir dessas heursticas, os fluxos dentro de um
processo sero identificados e correspondero a um caso de teste. Unindo o procedimento de
identificao de requisitos ao procedimento de identificao de fluxos, as funcionalidades (em um
baixo nvel) que devem ser testadas nos casos de teste so definidas, podendo ser mais ou menos
granulares, de acordo com o numero de funcionalidades que devero ser abordadas em cada caso.
HCC2 (eventos intermedirios): um fluxo de cenrio identificado quando houver um fluxo de
atividades presentes entre dois eventos intermedirios, evento inicial e intermedirio ou evento
intermedirio e evento final. Esta heurstica permite a identificao de fluxo e subfluxos que
particionam o processo de negcio em seus diferentes ramos. Um fluxo pode possuir subfluxos
quando uma partio maior possui em seu interior outras parties, entretanto, no
necessariamente esses fluxos existiro, podendo apenas ocorrer o fluxo principal, delineado pelo
evento inicial e final, os quais tambm so respectivamente eventos iniciais e finais do processo.
Baseado nas heursticas apresentadas, definimos dois critrios de cobertura (CC):
CriCob1 (cobertura de requisitos): todos os requisitos identificados pelas heursticas devem ser
considerados nos casos de testes pelo menos uma vez, ou seja, os requisitos devem estar presentes
em algum fluxo extrado do processo de negcio.
CriCob2 (cobertura de fluxos): todos os fluxos identificados pelas heursticas devem ser
considerados nos casos de testes pelo menos uma vez.
O produto final da aplicao das heursticas uma lista composta por casos de teste (sute
de testes). Se for desejado utilizar casos especficos, dever ser feita a anlise e seleo dos casos
de testes convenientes. As informaes consolidadas presentes na lista so compostas pelas
informaes oferecidas no modelo atravs de seus elementos. Por exemplo, um objeto
representando um artefato pode disponibilizar informaes sobre o contedo deste artefato. Se este
contedo for relevante, deve estar presente na lista de casos de teste.
Um contedo importante para um artefato de informao que serve como insumo em uma
atividade pode ser o tipo de dado o qual esse elemento representa. Desconsiderando a
possibilidade de informaes extras, definimos os elementos bsicos que devem compor o caso de
teste como: Caso de teste - representa o nome do caso de teste. Normalmente representado apenas
pela enumerao da lista. Condio de cenrio - representa a condio de disparo do caso de teste,
ou seja, o evento inicial ou intermedirio do fluxo que representa o cenrio. Entradas - representa
as informaes necessrias para a realizao do cenrio, ou seja, as informaes que serviro como
insumo das atividades que compem o cenrio. Informaes geradas dentro do cenrio no so
consideradas como entradas. Requisitos - representa os requisitos envolvidos no caso de teste, ou
seja, uma lista de requisitos candidatos que esto relacionados s atividades que compem o
cenrio de teste. Fluxo envolvido - representa o conjunto de atividades que esto envolvidas no
cenrio, incluindo seus eventos que so classificados como informaes de mensagens. Regras
de negcio - representa o conjunto de regras de negcio associadas s atividades que esto
envolvidas no cenrio. Sadas - representam as informaes (ou tipos/objetos) e artefatos gerados
como produto da execuo satisfatria do cenrio. Elementos parciais gerados durante a execuo
do cenrio no so consideradas como produtos de sada. possvel que em alguns casos o cenrio
no gere produtos, mas alcance a satisfao de um estado especfico. Resultado esperado -
representa a condio de finalizao do caso de teste, ou seja, o evento final ou intermedirio-final
do fluxo que representa o cenrio.
 Em um exemplo de aplicao demonstrado como o nvel de abstrao da modelagem
pode afetar o resultado da gerao dos casos de testes. O exemplo proposto trata o registro de um
cliente, que pode ser composto por pequenas tarefas e regras de negcio. Porm, em um modelo de
processo, dependendo da abstrao utilizada estes detalhes podem ser reduzidos, transformando-se
em informaes textuais e no em elementos de modelagem (Fig. 3). Nesta forma a capacidade da
aplicao de heursticas reduzida, porm no impede a identificao do requisito. No entanto,
menos informaes estaro disponveis para extrao e gerao dos casos de testes, j que as
heursticas de aplicao em modelos no atuam na anlise das descries textuais dos elementos.
O registro de cliente apenas um trecho de um processo de negcio, no entanto,
demonstraremos que um pequeno trecho pode ser rico em informaes. Apresentaremos este
exemplo de forma visual, atravs do modelo, como tambm atravs de descrio textual. A Fig. 3
apresenta a atividade Registrar cliente. A descrio da atividade : a atividade recebe como
entrada a senha e o nome do usurio e produz como sada o registro do cliente que armazenado
no banco de dados Clientes. A atividade apoiada pelo Sistema X. Ao final da atividade, o cliente
estar cadastrado na base de dados.

HCC1

HRB2

Fig. 3. Atividade registrar cliente

Ao aplicar a heurstica de requisitos bsicos HRB2 (informao de entrada e sada)
(somente este heurstica aplicvel), obtemos o requisito candidato descrito na Tabela 1.
Tabela 1. Lista preliminar de requisitos
ndice Heurstica Requisitos candidatos Sistemas Papis
1 HRB2 Gravar cliente Sistema X Sistema X; Cliente;
Posteriormente aplicamos a heurstica de cobertura de cenrios HCC1 (eventos inicial e
final) que identifica o caso de teste descrito na Tabela 2 (a coluna Heurstica no acrescentada
nas tabelas 2 e 4 devido ao espao limitado). A Fig. 3 mostra onde as heursticas so aplicadas.
Tabela 2. Exemplo de caso de teste
Caso de Condio Requisitos Regra de Resultado
Entradas Fluxo envolvido Sadas
teste de cenrio (Tabela 3) negcio esperado
Cliente no Nome, Ao: Registrar Evento: Cliente
1 1 --x-- Cliente
cadastrado Senha cliente cadastrado

Este caso de teste, ao ser executado, envolver o conjunto de requisitos que esto
presentes no fluxo de processo (neste caso, somente um). Cada requisito um elemento distinto,
porm a unio destes elementos definir o grau de granularidade do caso de teste. possvel
identificar que este exemplo de cadastro de cliente simples, principalmente por no considerar
fluxos alternativos. No prximo exemplo ser utilizado o mesmo processo, porm, sendo
expandido para considerar os fluxos alternativos. Ao expandir este cenrio, obtm-se uma viso
mais detalhada, desta forma outros elementos surgem, como regras de negcio e novas atividades.
 Registro de cliente Modelo detalhado
A Fig. 4 apresenta o trecho de processo que tem como objetivo o cadastro do cliente. A
descrio do processo : o processo inicia quando o cliente no est cadastrado. O usurio informa
nome de usurio e senha, o sistema verifica se o nome de usurio j se encontra registrado na base
de dados. Caso o nome de usurio j esteja presente na base de dados, o usurio dever informar
novamente o nome de usurio e senha, porm alterando sua proposta de nome de usurio. Caso o
nome do usurio no esteja presente na base de dados, o sistema registra o cliente. Ao final do
processo, o cliente estar cadastrado.
HRB2

HPW2
HPW1

HRB3 HRB3

HRB1

HRB3 HRB2

Fig. 4. Trecho de processo referente ao cadastro do cliente

Com este novo modelo, as heursticas de identificao de requisitos aplicveis ao modelo
se expandem para as demais, apresentadas anteriormente (HRB1 (regra de negcio); HRB2
(informao de entrada e sada); HRB3 (atividades automatizadas); HPW1 (atividades
sequenciais), HPW2 (ciclo de atividades - Loop)). A Fig. 4 demarca os padres de workflow e
registra as sigas das respectivas heursticas prximas aos objetos nos quais so aplicadas. A Tabela
3 apresenta servios candidatos a partir da aplicao das heursticas.
Tabela 3. Requisitos extrados do modelo expandido
ndice Heurstica Servio candidato Sistemas Papis
1 HRB1 Registrar nome de usurio Sistema X Sistema X
2 HRB2 Consultar nomes de usurios Sistema X Sistema X
3 HRB2 Gravar Cliente Sistema X Sistema X
4 HRB3 Verificar nome de usurio Sistema X Sistema X
5 HRB3 Solicitar nome de usurio diferente Sistema X Sistema X
6 HRB3 Registrar cliente Sistema X Sistema X
Informar nome de usurio e senha_Verificar nome de Sistema X;
7 HPW1 Sistema X
usurio Cliente
Informar nome de usurio e senha_Verificar nome de Sistema X;
8 HPW2 Sistema X
usurio_Solicitar nome de usurio diferente Cliente
Posteriormente so aplicadas as heursticas de cobertura de cenrios HCC1 (eventos
inicial e final) e HCC2 (eventos intermedirios), delimitando os casos de testes. As informaes
so formatadas conforme a tabela proposta (alguns nomes foram abreviados por motivo de
espao):
 Tabela 4. Casos de testes extrados do modelo expandido
Caso Condio Entrad Req. Reg. Resultado
Fluxo envolvido Sadas
teste de cenrio as (Tab 3) Neg. esperado
Ao: Cliente informa nome de usurio e senha;
Sistema verifica nome de usurio; Mensagem: Nome
2, 3, 4, de usurio existente; Ao: Sistema solicita nome e
Evento:
Cliente no Nome, 5, 6, 8 usurio diferente; Mensagem: Nome de usurio
1 1 Cliente Cliente
cadastrado Senha diferente solicitado; Ao: Cliente informa nome de
cadastrado
usurio e senha (inexistentes); Sistema verifica nome
de usurio; Mensagem: Nome de usurio inexistente;
Ao: Sistema registra cliente;
Ao: Cliente informa nome de usurio e senha
Evento:
Cliente no Nome, 2, 3, 4, (inexistentes); Sistema verifica nome de usurio;
2 1 Cliente Cliente
cadastrado Senha 6, 7 Mensagem: Nome de usurio inexistente; Ao:
cadastrado
Sistema registra cliente;
Evento:
Cliente no Nome, Ao: Cliente informa nome de usurio e senha Nome do
3 2, 4, 7 1 --x--
cadastrado Senha (inexistentes); Sistema verifica nome de usurio; usurio
inexistente
Evento:
Cliente no Nome, Ao: Cliente informa nome de usurio e senha Nome do
4 2, 4, 7 1 --x--
cadastrado Senha (existentes); Sistema verifica nome de usurio; usurio
existente
Ao: Cliente informa nome de usurio e senha Evento:
Nome do
Cliente no Nome, 2, 4, 5, (existentes); Sistema verifica nome de usurio;
5 1 --x-- usurio
cadastrado Senha 7 Mensagem: Nome de usurio existente. Ao:
diferente
Sistema solicita nome de usurio diferente; solicitado
Nome de Evento:
Nome,
6 usurio 3, 6 Ao: Registrar cliente; --x-- Cliente Cliente
Senha
inexistente cadastrado
Ao: Sistema solicita nome de usurio diferente; Evento:
Nome de
2, 4, 5, Mensagem: Nome de usurio diferente solicitado. Nome de
7 usurio --x-- 1 --x--
7 Ao: Cliente informa nome de usurio e senha usurio
existente
(inexistentes); Sistema verifica nome de usurio; inexistente
Evento:
Nome de Nome de
8 usurio --x-- 5 Ao: Solicitar nome de usurio diferente; --x-- --x-- usurio
existente diferente
solicitado
Ao: Sistema solicita nome de usurio diferente;
Nome de Evento:
2, 3, 4, Mensagem: Nome de usurio diferente solicitado;
9 usurio --x-- 1 Cliente Cliente
5, 6, 7 Ao: Cliente informa nome de usurio e senha;
existente cadastrado
Sistema verifica nome de usurio;
Nome de Evento:
usurio Nome, Ao: Cliente informa nome de usurio e senha Nome de
10 2, 4, 7 1 --x--
diferente Senha (inexistentes); Sistema verifica nome de usurio; usurio
solicitado inexistente
Nome de Ao: Cliente informa nome de usurio e senha
Evento:
usurio Nome, 2, 3, 4, (inexistentes); Sistema verifica nome de usurio;
11 1 Cliente Cliente
diferente Senha 6, 7 Mensagem: Nome de usurio inexistente; Ao:
cadastrado
solicitado Sistema registra cliente;
Nome de Evento:
usurio Nome, Ao: Cliente informa nome de usurio e senha Nome de
12 2, 4, 7 1 --x--
diferente Senha (existentes); Sistema verifica nome de usurio; usurio
solicitado existente
 Esta tabela construda baseada nos elementos delimitados (trecho do processo) pelas
HCC1 e HCC2. Os itens bsicos para a construo dos casos de testes so extrados do trecho de
processo, tais como, Condio do cenrio (representada pelo evento que inicia o caso de teste),
Entradas (representadas pelos insumos da primeira atividade), Sadas (representadas pelos
produtos da ltima atividade), Fluxo envolvido (representado pelas atividades e eventos
intermedirios que expressam o comportamento de uma funcionalidade composta) e Resultado
esperado (representado pelo evento que finaliza o caso de teste). Alm disso, so listados os
Requisitos identificados pelas heursticas de identificao de requisitos (neste caso HRB1-3,
HPW1-2) conforme nmero de identificao na respectiva tabela (Tabela 3). Da mesma forma so
destacadas as Regras de negcio envolvidas no trecho do processo delimitado (identificadas
pela HRB1). A nomenclatura usada nos requisitos candidatos (Tabela 3) baseada em [2]. A
descrio da coluna Fluxo envolvido, na Tabela 4, foi organizada para descrever o fluxo
representando as atividades como Aes e eventos como Mensagens.
Em especial, a coluna Requisitos importante porque descreve os requisitos envolvidos
no caso de teste. Entretanto, pode haver redundncia neste campo porque alguns requisitos podem
ser identificados por diferentes heursticas e apresentar nveis de abstrao distintos. Por exemplo,
no caso de teste 1 h um ciclo representado pelo ndice 8, que uma composio dos requisitos de
ndices 2, 4 e 5. O caso de teste deve ser projetado de acordo com a soluo de implementao
adotada e projeo de testes dos requisitos. Ou seja, o teste poder verificar o ciclo como uma
funcionalidade, ou considerar separadamente cada um dos requisitos atmicos identificados.
Em relao aos critrios de cobertura CriCob1 (cobertura de requisitos) e CriCob2
(cobertura de fluxos) propostos neste trabalho, verifica-se que o primeiro se relaciona com as
heursticas de identificao de requisitos, enquanto o segundo, com as heursticas de cobertura de
cenrios. Desta forma, o cumprimento destes critrios depende da relao entre os requisitos
presentes na Tabela 3 e os casos de testes da Tabela 4, que j expressam todos os fluxos
identificados. Desta forma verifica-se que todos os requisitos (1 a 8) esto presentes em alguma
das linhas que compem a Tabela 4, satisfazendo ambas as heursticas. No exemplo, os casos de
testes 1 e 2 foram identificados pela HCC1 e os casos de teste 3, 4, 5, 6, 7, 8, 9, 10, 11 e 12, pela
HCC2. A apresentao de todos os resultados destas heursticas buscam satisfazer o CriCob2.
Entretanto, para satisfazer o critrio de cobertura de fluxos (CriCob2) muitos subfluxos
so repetidos em fluxos maiores na lista de casos de teste. Isso evidencia a necessidade da fase de
consolidao das informaes, que consiste em identificar tanto possveis duplicidades como
especificar os casos de testes mais adequados para as necessidades momentneas do projeto. Por
outro lado, uma lista abrangente permite maior possibilidade de seleo de trechos especficos do
processo para teste das funcionalidades de software presentes. A escolha de realizar um caso de
teste mais especfico ou mais abrangente fica a cargo do engenheiro de software.

6 Concluses
O presente trabalho apresentou uma proposta para extrao de casos de testes a partir de modelos
de processos de negcio. O mtodo faz uso de heursticas definidas em [2], o que inclui padres de
workflow presentes em [5], alm de heursticas complementares, proposta neste trabalho. Algumas
heursticas so influenciadas por propostas que utilizam outros artefatos de requisitos como
insumo para extrao de casos de teste, tais como [9], [11], [14], [16], [25], [28].
Observamos que os modelos de processos de negcio oferecem grande potencial como
insumo para gerao dos casos de testes, principalmente porque possuem maior capacidade em
representar detalhes do negcio. Estes detalhes so traduzidos em requisitos de sistema e devem
ser includos nos casos de teste. Identificamos que quanto maior a abstrao do modelo de
processo, maior o impacto nos casos de teste. importante que o processo seja modelado de
forma detalhada, principalmente em relao aos fluxos que podem ser considerados como
alternativos. Por exemplo, os fluxos caracterizados por desvios em regras de negcio ou
situaes que demandam decises que levem a um fluxo executado por diferentes atividades.
Apesar destes cuidados beneficiarem o mtodo de identificao de requisitos e de
extrao de casos de teste, os modelos de processos no abordam todos os requisitos de um
sistema, mas expressam os de natureza operacional, assim como so os elementos que o compem.
Requisitos no funcionais so ainda mais difceis de serem representados em modelos e
identificados por heursticas. Isso demonstra que a aplicao dessas propostas no deve ser
considerada como nico recurso para elicitao de requisitos e construo de casos de teste.
Entre os benefcios do mtodo proposto, temos a aplicao direta nos modelos, sem a
necessidade de transformaes ou construo de modelos intermedirios que auxiliem no processo
de definio de casos de teste, como ocorrem em algumas propostas [9], [28], [32]. O mtodo
proposto baseado em heursticas que analisam diretamente os modelos e extraem as informaes
a partir dos objetos e fluxos presentes. A identificao dos requisitos [2] auxilia a construo de
casos de testes, mas ainda demanda a delimitao dos cenrios e tratamento das informaes
coletadas. Outro fator importante a possibilidade de alinhar a estratgia de uso dos modelos de
processos de negcio na engenharia de requisitos, com a gerao de casos de teste, ampliando o
potencial dos processos de negcio na construo de software. Alm disso, o mtodo de
identificao de requisitos utilizado j se encontra automatizado para a ferramenta ARIS [4] e
BPMN [30]. Desta forma, a automatizao da gerao de casos de teste facilitaria o acesso aos
artefatos com significativa reduo de custos. Em organizaes que utilizam processos de negcio
como auxlio na gesto, as alteraes nos modelos poderiam ser replicadas nos artefatos de
software de forma imediata, reduzindo o seu custo de manuteno.
Em trabalhos futuros, alm da automao da proposta, devemos aplicar o mtodo em um
exemplo real para identificar com mais preciso o impacto do uso dos casos de testes candidatos.
Tambm devemos investigar como classificar e consolidar a lista de casos de testes, gerando novas
informaes que possam auxiliar engenheiro de software durante a aplicao da sute de testes.
Outra questo qual o impacto dos casos de teste no alinhamento do software com os objetivos
organizacionais. Ou seja, deseja-se saber se os testes projetados a partir dos modelos de processo
de negcio podem contribuir positivamente ao alinhamento entre a TI e o negcio. A relao com
TMM (Testing Maturity Model) e TMMI (Testing Maturity Model Integration) tambm
desejada, com o objetivo de integrar as boas prticas registradas nestes modelos.

Referncias bibliogrficas
1. Amyot, D., Mussbacher, G., URN: Towards a New Standard for the Visual Description of
Requirements. In Proceedings of SAM2002. pp.21-37, (2002)
2. Azevedo, L., Baio, F., Santoro, F., Souza, J., Revoredo, K., Pereira, V., Herlain, I., Identificao de
servios a partir da modelagem de processos de negcio, Simpsio Brasileiro de Sistemas de
Informao (SBSI09), Braslia, (2009)
3. Azevedo, L., Santoro, F., Baio, F., Souza, J., Revoredo, K., Pereira, V., Herlain, I., A Method for
Service Identification from Business Process Models in a SOA Approach, 10th International
Workshop on Business Process Modeling, Development, and Support (BPMDS), Enterprise,
Business-Process, and Information Systems Modelling. V. 29, Amsterdam, (2009)
4. Azevedo, L., Sousa, H. P., Souza, J. F., Santoro, F. Baio, F., Identificao automtica de servios
candidatos a partir de modelos de processos de negcio. Conferncia IADIS Ibero Americana
WWW/INTERNET 2009 (CIAWI09), Outubro, 21-23, Madrid, Espanha, (2009)
5. van der Aalst, W., Ter Hofstede, A., Kiepuzewski, B., Barros, A., Workflow patterns, In
Distributed and Parallel Databases 14(1), p.551, (2003)
6. Westland, J. C., The cost of errors in software development: evidence from industry, Journal of
Systems and Software, Volume 62, Issue 1, Pages 1-9, ISSN 0164-1212, (2002)
7. Sousa, H. P., Integrando modelagem intencional modelagem de processos, dissertao de
 mestrado, PUC-Rio, Rio de Janeiro, (2012)
8. OMG, Business Process Model and Notation, http://www.bpmn.org
9. Swain, S.K., Mohapatra, D.P., Mall, R., Test Case Generation Based on Use case and Sequence
Diagram, International Journal of Software Engineering & Applications (IJSEA), Vol.3, (2010)
10. Weiss, M., Amyot, D., Business process Modeling with URN, International Journal of E-Business
Research, Vol. 1, No. 3, (2005)
11. Fraikin F., Leonhardt, T., SeDiTeC Testing Based on Sequence Diagrams, Automated Software
Engineering, 2002. 17th IEEE International Conference on, ISSN: 1938-4300, 23-27, (2002)
12. Gargantini, A.; Heitmeyer, C., Using model checking to generate tests from requirements
specifications, In: ESEC/FSE- 7, ACM Press, (1999)
13. Hartman, A., Katara, M., Olvovsky, S., Choosing a test modeling language: a survey. Proceedings
of the 2nd international Haifa verification conference on Hardware and software, verification and
testing, Haifa, Israel, (2006)
14. Heumann, J., Generating Test Cases From Use Cases, The Rational Edge: e-zine for the rational
community, (2001)
15. Kaner, C., Bach, J., Pettichord, B., Lessons Learned in Software Testing, Wiley (2001).
16. Wang, Y., Zheng, M., Test Case Generation from UML Models, Midwest Instruction and
Computing Symposium 2012, (2012)
17. Sikandar-gani, S. B., User Requirement Notation (URN), Graduate Student, Department of
Electrical and Computer Engineering, Mississippi State University, MS, USA, 2003.
18. Mogyorodi, G., Requirements-based testing: an overview, Process engineering for systems,
software and people, 2003.
19. Mingsong. C., Xiaokang. Q., Xuandong, L., Automatic test case generation for UML activity
diagrams, In: AST 06, ACM Press, 2006.
20. Myers, G. J.; Sandler, C.; Badgett, T., The Art of Software Testing, 240 pages, Wiley; 3 edition,
ISBN-10: 1118031962, ISBN-13: 978-1118031964, (2011)
21. Neto, A.C., Subramanyan, R. Vieira, M. Travassos, G.H., A Survey on Model-based Testing
Approaches: A Systematic Review, WEASELTech07, Atlanta Georgia, USA, (2007)
22. Sousa, H. P., Azevedo, L.G., Santoro, F.M., Identificao Automtica de Servios em Uma
Abordagem SOA. Relatrios Tcnicos do Dep. de Informtica Aplicada da UNIRIO, n 0002, (2011)
23. van der Aalst, W., ter Hofstede, A, Kiepuzewski, B., Barros, A., Advanced workflow patterns, 7th
International Conference on Cooperative Information Systems, LNCS 1901, pp. 1829, (2000)
24. Pourshahid, A., Amyot, D., Peyton, L., Ghanavati, S., Chen, P.; Weiss, M.; Forster, A. J., Business
process management with the user requirements notation, International MCETECH Conference on
e-Technologies, pp.3-15, (2009)
25. Rosenberg, D., Use Case Thread Generation for Acceptance Testing From Theory to Practice,
ICONIX, http://iconixsw.com/
26. Russell, N., Ter Hofstede. A., Edmond, D., van der Aalst, W., Workflow Data Patterns, QUT
Technical report, FIT-TR-2004-01, Queensland University of Technology, Brisbane, (2004)
27. Srivastava, P.R., Combining UML Interaction Diagrams and State-Charts for Testing of Object
Oriented Software Systems, Journal of Information and Computing Science, Vol. 4, No. 1, pp. 056-
064, ISSN 1746-7659, England, UK, (2009)
28. Swain, R.K., Behera, P.K., Mohapatra, D.P., Minimal Test Case Generation for Object-Oriented
Software with State Charts, International Journal of Software Engineering & Applications (IJSEA),
Vol.3, No.4, (2012)
29. Scheer, A.G., Methods ARIS 7.0, (2005)
30. Brando, B. C. P.; J. C., Silva, Identificao automtica de servios a partir de processos de negcio
em BPMN, TCC, Departamento de Informtica, UNIRIO, (2013)
31. R.J.A. Buhr, R.S. Casselman, Use Case Maps for Object-Oriented Systems, Prentice Hall, (1996)
32. D. Buchs, L. Lucio, A. Chen, Model checking techniques for test generation from business process
models, Reliable Software Technologie-Ada-Europe, LNCS, Vol 5570, pp59-75, Springer, (2009)