OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-iic message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ebxml-iic] Use cases for concurrent test cases - Schema and instance examples


Monica,

   Looking at the schema for BPSS -1, it looks like we may be able to model
our
<TestCase>s based on the BPSS schema.  In fact, it appears that we could
define a
transform that could read a BPSS instance document , and generate
<TestCase>s based upon its
content.
   How much of the BPSS syntax we would use in our test scripting , in my
opinion, depends on what we need
to accomplish our testing goal.   While BPSS schema defines a business
process,
its documents, its roles, its preconditions and postconditions...etc.. our
test framework schema defines
a testing process, with <Threads>, <TestSteps>, <TestPrecondition>s and
<TestAssertion>s.
 There will be overlap, but there will also be differences based upon what
we are trying to accomplish
with our schema vs. what the goal of the BPSS schema is.
   What encourages me to believe that we can write a transform from a BPSS
instance document into
a <TestCase> is the fact that all of the information that we need to define
the choreography of <TestStep>s
is in the BPSS instance document.  I ( like Jacques ) do not necessarily
believe that we need to implement a BSI to
choreograph the testing, but we can certainly interpret the meaning of a
BPSS document to choreograph
our "forked" testing threads, construct the messages we send, and evaluate
the content of received messages
in a manner that simulates a business process.
   I think that some BPSS instances documents, with accompanying packages of
business documents
 would help us validate our test scripting schema proposals.  Are there any
"packages" of such documents available?

Thanks,
Mike



----- Original Message ----- 
From: "Monica J. Martin" <Monica.Martin@Sun.COM>
To: "Michael Kass" <michael.kass@nist.gov>
Cc: "Jacques Durand" <JDurand@fsw.fujitsu.com>; "ebXML IIC - main list
(E-mail) (E-mail)" <ebxml-iic@lists.oasis-open.org>
Sent: Sunday, February 01, 2004 8:16 PM
Subject: Re: [ebxml-iic] Use cases for concurrent test cases - Schema and
instance examples


> Michael Kass wrote:
>
> > Jacques,
> >
> >    Here is an updated schema and use case instances, based on your
> > comments.
> > We can use your suggestions ( using only <Split> and <Join>  as
> > operators ) to satisfy these
> > use cases.  As I mentioned in my last post however, generating an
> > "asynchronous" thread requires
> > a lot of "overhead" XML:
> >
> >    A few things that I find worrisome is the inability to create the
> > following logic:
> >
> > <If> ....   <Then> .... </Then> </If>
> > <ElseIf> .....  <Then> ...   </Then>  </ElseIf>
> > <Else>...  </Else>
> >
> > <Split> and <Join> alone do not permit such constructs.   I think that
> > it may be advantageous to
> > use the above elements, rather than <Split> and <Join> so that we
> > won't find ourselves limited
> > by the syntax we choose.  If you can demonstrate how we can achieve
> > the above with <Split> and
> > <Join> I can be convinced otherwise.  Perhaps I am missing something.
> >
> >   I will send a modified schema ( using <If> <Then> <Else>  with use
> > case instances   Monday
> > morning.  But for the three use cases that you presented, it apears
> > that <Split> and <Join> would
> > suffice.
> >
> > Cheers,
> > Mike
>
> mm1: Mike, a very simple question and request. We keep looking back to
> the BPSS for some of the constructs that may be required to show the
> mechanisms to model (in XML) the test paths.  Rather than continuing to
> create new constructs and conditional statements, we model the overall
> process in BPSS. We are almost there anyway.  We have been discussing
> fork, join, sequences, etc.  If you cannot effectively model this
> process in BPSS - 1) We may have new use cases for BPSS or 2) We may
> need to re-evaluate the new semantics under discussion.
>
> I am not asking to use the BPSS semantics but to look at the process we
> are trying to support first.
>
>
>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]