RE: [hyades-dev] Re: [Hyades-team] Test and trace model alignment - cla

[Michael.Norman@xxxxxxxxxxxxx]

I'm glad we're all thinking about this one.  I had a nasty feeling we'd  
lost it somehow. However as Harm says I think it may be a Hyades 2 or 
1.1 issue, not a Hyades 1.0 issue, as long as we're not doing anything 
in 1.0 which is going to break badly when we bring the models together 
later. 
 
Let's not lose sight of it though.  
 
Silvermark's comments are interesting about matching the granularity 
(i.e. the stack-slice level) with the test granularity (or rather the 
objective of the test). I guess we have this interesting possibility of 
the UI being able to drill through a test case into the trace of its 
execution then into the trace of the SUT during test execution, both in 
terms of the layer that was directly being driven, but also internal 
layers and systems parameters.
 
There are another couple of ideas worth bringing up (again for versions 
beyond 1 I think).
 
1) reverse-engineering the behavioural logic into the trace (e.g. 
detecting loops and representing them as such in the trace).
2) reverse-engineering the data logic (i.e. the logic by which the API 
call parameters have been populated) at the point of tracing.  This is 
one of our hobby-horses, but you really do need to do it if you're going 
to do anything sensible in automated test data creation on transactional 
systems.
 
I've got another issue that I think I need closure on in V1, which I'll 
bring up separately.
 
Mike
 
 
 -----Original Message-----
From: sluiman [mailto:sluiman@xxxxxxxxxx]
Sent: Friday, April 25, 2003 1:32 PM
To: hyades-dev
Subject: Re: [hyades-dev] Re: [Hyades-team] Test and trace model 
alignment - clarification needed




This is great that we are now starting to think at this level of 
interop. 

We do have a model workgroup on the sidelines at the moment for this 
topic. You all may recall that the "behavior" model team decided to wait 
until the test and trace models had reached a level of settling and 
would then look at possible common model constructs. 

In the meantime it was decided that a trace model could likely be used 
to "record" some test behavior and if that was the case a transform 
could be done to create a definition. This is not optimal for some 
scenarios but is simply a recognition of the potential linkage. The 
other reason we need to be careful here was also previously discussed. 
That is that this is in effect a behavioral model, and we need to 
consider carefully the relationship to UML meta models. 

I would like to suggest that since the people that will need to be 
involved in this are already busy with several other sub groups we 
continue to sit on this for a while before trying to solve the 
opportunity. In the meantime getting all the structural features in 
place for each of the test and trace models is still key to complete. 

A note regarding how much data goes into the trace model. We actually 
have already done 2 independent collectors for the trace model. One 
which is JVMPI based, and available on Hyades, and being used to create 
more typical detailed performance profiling models, and another which is 
not yet available is for doing distributed interface tracing, which is 
very much like the test recording style of data collection. However we 
have still to get data values and parameters in the model to be complete 
for meaningful "recording". 

Thanks for your time.
------------------------------------------------------------------------
-------------------------
Harm Sluiman, STSM,  
phone:905-413-4032   fax: 4920  
cell: 416-432-9754
mailto:sluiman@xxxxxxxxxx
Admin : Donna Kennedy donnamk@xxxxxxxxxx Tie: 969-2323