Jacques and all,
Here is an updated set of use case
instances based upon our email discussion. I
hope that this puts us closer to acceptance of a
syntax for testing BPSS scenarios.
I still have not run this model through
SPIN, but will attempt to do so.
Attached is the JPG image of the
schema ( large I know...but necessary to see the "big picture" )
Key points about the scripting
schema:
1) Static
<Thread>s are placed at the beginning of the
<TestSuite>
2)
<Threads> are generally referenced via their "name" attribute from
<ThreadRef>s in <TestCases>
3) A
<TestCase> and <Thread> implicitly "split" their child
<TestStep>s and <Threads>
4)
<TestStep>s and <Thread>s are executed and evaluated sequentially
( unless specified with an "asynchronous" qualifier )
5) All
<TestStep>s and <Thread>s in a parent <Thread> MAY
be <Join>ed ( using its "andjoin" or "orjoin" qualifier attribute
)
6) A
<Join> MAY start a series of <TestStep>s and/or
<Thread>s OR may signal a
<Pass><Fail><Success> or <Exception>
state
7) An
<Else> operator essentially completes the construction of an
<If><Then><ElseIf><Then><Else> logic
structure
8) An
<Else> operatroa MAY start a series of <TestStep>s and/or
<Thread>s OR may signal a
<Pass><Fail><Success> or <Exception>
state
9) At any
point in the branching, one can construct a new <Thread>
tree.. permitting complex nested <Threads> that are
analogous
to
complex processes found in BPSS message transactions.
10) The
<SetParameter> operation is possible within any <Thread> ( and
<TestStep> ) and permits "permutation" of message content
and
response
message evaluation, using a static <Thread> template. ( i.e.
defining a parameter value higher in the <Thread>
hierarchy,
to be
used by <Thread>s or <TestStep>s below it.
12) "stepDuration"
and "stepDelay" are attributes of a <TestStep> that define
a <TestStep> "timeout" for the former, and a "sleep"
period
before
<TestStep> execution ( for the latter ).
13) "matchResult" is an optional
<TestStep> attribute used to set a postive
("true") <TestAssertion> result to "false"... and vice
versa
13)
<TestPrecondition> and <TestAssertion> are "atomic" level
operations in the logic tree. Branching is not possible below this
level. All
control flow happens at the <Thread> level.
14)
<Pass><Fail><Success> and <Exception> are additional
tags added to set <TestCase> state and act as a GOTO to terminate
<TestCase> execution
without necessarily completing logic flow.
I am also adding updated use cases reflecting the
schema change... both in XML and HTML form, along with our running
<Thread> regarding design issues.
Comments welcome,
Mike