TOPIC:

Hi All,

Could anyone answer the following questions?

- Do component values (variables) persist between testcases, if not, how can
I pass values from one testcase to another? Eg. my testcase1 runs on the MTC
and modifies variable X (to 100, say) of that MTC component. Should
testcase2 running on the same MTC see X == 100 on entry, if not how do I
pass this value from testcase1 to testcase2? Via an inout parameter in
testcase1, or are there other means?

- What should happen to 'background' messages between testcases? E.g.
supposing I have a background handshaking protocol with the IUT to ensure
that the IUT is alive and the IUT thinks that the ETS is alive. What should
happen if such a message from the IUT comes in just after testcase1 is
exited and before testcase2 is entered?

- In the same vain, do connect and map operations persist through testcases?
Or do they have to be re-connected and re-mapped every time a testcase is
entered?

Many thanks.


Regards<?xml:namespace prefix = o ns =
"urn:schemas-microsoft-com:office:office" />

Ray



Ray Cheung

---

Global Telecom Solutions Sector
Thamesdown Drive
Groundwell
Swindon
Wiltshire
SN25 4XY
Phone: +44 (0)1793 565529
Fax: +44 (0)1793 541228

---

Hello Cheung,



> Do component values (variables) persist between testcases

No, components seize to exist at termination. Specifically, the MTC is
destroyed at test case termination.



> how can I pass values from one testcase to another? ... Via an inout
parameter in testcase1

Yes, that's the way to do it. You can store the value of the inout parameter
in a variable in the control part and pass it on to the next test case.



> What should happen if such a message from the IUT comes in just after
testcase1 is exited and before testcase2 is entered?

That's an adaptation issue. From the TTCN-3 perspective, the component - and
its ports - no longer exists since the test case terminated, so what you do
with "late" messages is up to you.



> In the same vain, do connect and map operations persist through testcases?


No.



> Or do they have to be re-connected and re-mapped every time a testcase is
entered

Yes.



I hope this helps.



/Johan

---

Original Message

---

From: Cheung Ray-RCHEUNG1 [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: den 5 november 2003 10:50
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: testcase related questions



Hi All,



Could anyone answer the following questions?



- Do component values (variables) persist between testcases, if not, how can
I pass values from one testcase to another? Eg. my testcase1 runs on the MTC
and modifies variable X (to 100, say) of that MTC component. Should
testcase2 running on the same MTC see X == 100 on entry, if not how do I
pass this value from testcase1 to testcase2? Via an inout parameter in
testcase1, or are there other means?

- What should happen to 'background' messages between testcases? E.g.
supposing I have a background handshaking protocol with the IUT to ensure
that the IUT is alive and the IUT thinks that the ETS is alive. What should
happen if such a message from the IUT comes in just after testcase1 is
exited and before testcase2 is entered?

- In the same vain, do connect and map operations persist through testcases?
Or do they have to be re-connected and re-mapped every time a testcase is
entered?

Many thanks.





Regards

Ray



Ray Cheung

---

Global Telecom Solutions Sector
Thamesdown Drive
Groundwell
Swindon
Wiltshire
SN25 4XY
Phone: +44 (0)1793 565529
Fax: +44 (0)1793 541228

---

Dear Ray,

Cheung Ray-RCHEUNG1 wrote:
> - Do component values (variables) persist between testcases, if not,
> how can I pass values from one testcase to another? Eg. my testcase1
> runs on the MTC and modifies variable X (to 100, say) of that MTC
> component. Should testcase2 running on the same MTC see X == 100 on
> entry, if not how do I pass this value from testcase1 to testcase2?
> Via an inout parameter in testcase1, or are there other means?

In TTCN-3 there are no global or shared variables. Thus, as a test case
is being executed on a test component there is no way to preserve the
value of test component variable between test cases. To solve this
problem you must use inout parameters.

And one point for clarification. Two test cases are *not* executed on
the SAME MTC, but only one the same TYPE of MTC.


> - What should happen to 'background' messages between testcases? E.g.
> supposing I have a background handshaking protocol with the IUT to
> ensure that the IUT is alive and the IUT thinks that the ETS is
> alive. What should happen if such a message from the IUT comes in
> just after testcase1 is exited and before testcase2 is entered?
Well, I can not answer the question what should happened with message
that are received between testcase. From a TTCN-3 point of view this is
undefined, as receiving is bound to ports, and ports are bound to a test
component.

Technically you must take care of this in the System Adapter (SA), which
interfaces with the SUT.

>
> - In the same vain, do connect and map operations persist through
> testcases? Or do they have to be re-connected and re-mapped every
> time a testcase is entered?
No. No test components -> no ports -> no connections, and no maps.

Best regards,

Theo Vassliou

Hi Johan,

Thanks for the answers. They were most helpful. Do you mind if I ask for
your view?

Do you happen to know the philosophy behind the TTCN-3 design? What are the
advantages in destroying components and connections at the end of each test
case - apart from that you alway start in a known (unitialised) state at the
beginning of each test case? This seems to imply that all tests must be
totally independent of each other. But is this really a reflection of the
real testing world? We have lots of tests that have dependencies, e.g. test
1 runs sequence A, test 2 runs B, test 3 runs C, etc, but they need to be
run in sequence. If we were to make them independent, it would mean test 1
runs A, test 2 must now run A & B, test 3 run A, B and C, etc. etc. If A is
rebooting the board, this is obviously exceedingly inefficient. (You're
probably going to ask, why not make a grand test that have A, B & C. It's
because we can branch to other tests along the line, so e.g. we could run
test 1 followed by test 5, or possibly test 1 and 2 followed by test 6,
etc.)

Even using inout parameters to pass persistent data back to the control
block seems somewhat clunky - because testcases/functions/... are
potentially not-single-entry-single-exit, you have to, at minimum, have the
same inout parameter all along the functional call stack if some nested
function modifies this data, so potentially all functions need this inout
parameter.

There must be some overwhelming advantage in the way it's been designed. I
guess I'm bit too blinkered to see it.

Finally, since you work for Telelogic and I'm use Tau G2 Tester; I see
triMap calls on each testcase entry, but I never see any triUmap calls on
exiting testcases. Is this correct?

Many thanks.

Regards

Ray

---

Original Message

---

From: Johan Nordin [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: 05 November 2003 09:57
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: testcase related questions



Hello Cheung,



> Do component values (variables) persist between testcases

No, components seize to exist at termination. Specifically, the MTC is
destroyed at test case termination.



> how can I pass values from one testcase to another? ... Via an inout
parameter in testcase1

Yes, that's the way to do it. You can store the value of the inout parameter
in a variable in the control part and pass it on to the next test case.



> What should happen if such a message from the IUT comes in just after
testcase1 is exited and before testcase2 is entered?

That's an adaptation issue. From the TTCN-3 perspective, the component - and
its ports - no longer exists since the test case terminated, so what you do
with "late" messages is up to you.



> In the same vain, do connect and map operations persist through testcases?


No.



> Or do they have to be re-connected and re-mapped every time a testcase is
entered

Yes.



I hope this helps.



/Johan

---

Original Message

---

From: Cheung Ray-RCHEUNG1 [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: den 5 november 2003 10:50
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: testcase related questions



Hi All,



Could anyone answer the following questions?



- Do component values (variables) persist between testcases, if not, how can
I pass values from one testcase to another? Eg. my testcase1 runs on the MTC
and modifies variable X (to 100, say) of that MTC component. Should
testcase2 running on the same MTC see X == 100 on entry, if not how do I
pass this value from testcase1 to testcase2? Via an inout parameter in
testcase1, or are there other means?

- What should happen to 'background' messages between testcases? E.g.
supposing I have a background handshaking protocol with the IUT to ensure
that the IUT is alive and the IUT thinks that the ETS is alive. What should
happen if such a message from the IUT comes in just after testcase1 is
exited and before testcase2 is entered?

- In the same vain, do connect and map operations persist through testcases?
Or do they have to be re-connected and re-mapped every time a testcase is
entered?

Many thanks.





Regards

Ray



Ray Cheung

---

Global Telecom Solutions Sector
Thamesdown Drive
Groundwell
Swindon
Wiltshire
SN25 4XY
Phone: +44 (0)1793 565529
Fax: +44 (0)1793 541228

---

Hi Cheung,



About the philosophy behind the language design... I'm not the best person
to talk to, even though I indeed were involved quite early on when TTCN-3
was developed. I would suggest that you direct your question to an ETSI PEX
like Mr. Anthony Wiles or someone else in the TTCN-3 team. However, you
should be aware that TTCN-3 was developed with the heritage of TTCN-2 in
mind, where you had a similar approach to separation of test cases. I
believe this is the strongest argument as to why this design was chosen.



About your Tau/Tester question, yes, there are no explicit UnMap calls at
termination of a test case. Those are not needed since the MTC itself - as
mentioned earlier - vanishes along with its ports. I agree that it doesn't
look too pretty, but there you go.



Cheers,

/Johan

---

Original Message

---

From: Cheung Ray-RCHEUNG1 [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: den 5 november 2003 13:42
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: testcase related questions



Hi Johan,



Thanks for the answers. They were most helpful. Do you mind if I ask for
your view?



Do you happen to know the philosophy behind the TTCN-3 design? What are the
advantages in destroying components and connections at the end of each test
case - apart from that you alway start in a known (unitialised) state at the
beginning of each test case? This seems to imply that all tests must be
totally independent of each other. But is this really a reflection of the
real testing world? We have lots of tests that have dependencies, e.g. test
1 runs sequence A, test 2 runs B, test 3 runs C, etc, but they need to be
run in sequence. If we were to make them independent, it would mean test 1
runs A, test 2 must now run A & B, test 3 run A, B and C, etc. etc. If A is
rebooting the board, this is obviously exceedingly inefficient. (You're
probably going to ask, why not make a grand test that have A, B & C. It's
because we can branch to other tests along the line, so e.g. we could run
test 1 followed by test 5, or possibly test 1 and 2 followed by test 6,
etc.)



Even using inout parameters to pass persistent data back to the control
block seems somewhat clunky - because testcases/functions/... are
potentially not-single-entry-single-exit, you have to, at minimum, have the
same inout parameter all along the functional call stack if some nested
function modifies this data, so potentially all functions need this inout
parameter.



There must be some overwhelming advantage in the way it's been designed. I
guess I'm bit too blinkered to see it.



Finally, since you work for Telelogic and I'm use Tau G2 Tester; I see
triMap calls on each testcase entry, but I never see any triUmap calls on
exiting testcases. Is this correct?



Many thanks.



Regards



Ray

---

Original Message

---

From: Johan Nordin [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: 05 November 2003 09:57
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: testcase related questions

Hello Cheung,



> Do component values (variables) persist between testcases

No, components seize to exist at termination. Specifically, the MTC is
destroyed at test case termination.



> how can I pass values from one testcase to another? ... Via an inout
parameter in testcase1

Yes, that's the way to do it. You can store the value of the inout parameter
in a variable in the control part and pass it on to the next test case.



> What should happen if such a message from the IUT comes in just after
testcase1 is exited and before testcase2 is entered?

That's an adaptation issue. From the TTCN-3 perspective, the component - and
its ports - no longer exists since the test case terminated, so what you do
with "late" messages is up to you.



> In the same vain, do connect and map operations persist through testcases?


No.



> Or do they have to be re-connected and re-mapped every time a testcase is
entered

Yes.



I hope this helps.



/Johan

---

Original Message

---

From: Cheung Ray-RCHEUNG1 [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: den 5 november 2003 10:50
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: testcase related questions



Hi All,



Could anyone answer the following questions?



- Do component values (variables) persist between testcases, if not, how can
I pass values from one testcase to another? Eg. my testcase1 runs on the MTC
and modifies variable X (to 100, say) of that MTC component. Should
testcase2 running on the same MTC see X == 100 on entry, if not how do I
pass this value from testcase1 to testcase2? Via an inout parameter in
testcase1, or are there other means?

- What should happen to 'background' messages between testcases? E.g.
supposing I have a background handshaking protocol with the IUT to ensure
that the IUT is alive and the IUT thinks that the ETS is alive. What should
happen if such a message from the IUT comes in just after testcase1 is
exited and before testcase2 is entered?

- In the same vain, do connect and map operations persist through testcases?
Or do they have to be re-connected and re-mapped every time a testcase is
entered?

Many thanks.





Regards

Ray



Ray Cheung

---

Global Telecom Solutions Sector
Thamesdown Drive
Groundwell
Swindon
Wiltshire
SN25 4XY
Phone: +44 (0)1793 565529
Fax: +44 (0)1793 541228

---

Hi Johan,

Many thanks again.

Regards

Ray

---

Original Message

---

From: Johan Nordin [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: 05 November 2003 13:21
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: testcase related questions



Hi Cheung,



About the philosophy behind the language design... I'm not the best person
to talk to, even though I indeed were involved quite early on when TTCN-3
was developed. I would suggest that you direct your question to an ETSI PEX
like Mr. Anthony Wiles or someone else in the TTCN-3 team. However, you
should be aware that TTCN-3 was developed with the heritage of TTCN-2 in
mind, where you had a similar approach to separation of test cases. I
believe this is the strongest argument as to why this design was chosen.



About your Tau/Tester question, yes, there are no explicit UnMap calls at
termination of a test case. Those are not needed since the MTC itself - as
mentioned earlier - vanishes along with its ports. I agree that it doesn't
look too pretty, but there you go.



Cheers,

/Johan

---

Original Message

---

From: Cheung Ray-RCHEUNG1 [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: den 5 november 2003 13:42
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: testcase related questions



Hi Johan,



Thanks for the answers. They were most helpful. Do you mind if I ask for
your view?



Do you happen to know the philosophy behind the TTCN-3 design? What are the
advantages in destroying components and connections at the end of each test
case - apart from that you alway start in a known (unitialised) state at the
beginning of each test case? This seems to imply that all tests must be
totally independent of each other. But is this really a reflection of the
real testing world? We have lots of tests that have dependencies, e.g. test
1 runs sequence A, test 2 runs B, test 3 runs C, etc, but they need to be
run in sequence. If we were to make them independent, it would mean test 1
runs A, test 2 must now run A & B, test 3 run A, B and C, etc. etc. If A is
rebooting the board, this is obviously exceedingly inefficient. (You're
probably going to ask, why not make a grand test that have A, B & C. It's
because we can branch to other tests along the line, so e.g. we could run
test 1 followed by test 5, or possibly test 1 and 2 followed by test 6,
etc.)



Even using inout parameters to pass persistent data back to the control
block seems somewhat clunky - because testcases/functions/... are
potentially not-single-entry-single-exit, you have to, at minimum, have the
same inout parameter all along the functional call stack if some nested
function modifies this data, so potentially all functions need this inout
parameter.



There must be some overwhelming advantage in the way it's been designed. I
guess I'm bit too blinkered to see it.



Finally, since you work for Telelogic and I'm use Tau G2 Tester; I see
triMap calls on each testcase entry, but I never see any triUmap calls on
exiting testcases. Is this correct?



Many thanks.



Regards



Ray

---

Original Message

---

From: Johan Nordin [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: 05 November 2003 09:57
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: testcase related questions

Hello Cheung,



> Do component values (variables) persist between testcases

No, components seize to exist at termination. Specifically, the MTC is
destroyed at test case termination.



> how can I pass values from one testcase to another? ... Via an inout
parameter in testcase1

Yes, that's the way to do it. You can store the value of the inout parameter
in a variable in the control part and pass it on to the next test case.



> What should happen if such a message from the IUT comes in just after
testcase1 is exited and before testcase2 is entered?

That's an adaptation issue. From the TTCN-3 perspective, the component - and
its ports - no longer exists since the test case terminated, so what you do
with "late" messages is up to you.



> In the same vain, do connect and map operations persist through testcases?


No.



> Or do they have to be re-connected and re-mapped every time a testcase is
entered

Yes.



I hope this helps.



/Johan

---

Original Message

---

From: Cheung Ray-RCHEUNG1 [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: den 5 november 2003 10:50
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: testcase related questions



Hi All,



Could anyone answer the following questions?



- Do component values (variables) persist between testcases, if not, how can
I pass values from one testcase to another? Eg. my testcase1 runs on the MTC
and modifies variable X (to 100, say) of that MTC component. Should
testcase2 running on the same MTC see X == 100 on entry, if not how do I
pass this value from testcase1 to testcase2? Via an inout parameter in
testcase1, or are there other means?

- What should happen to 'background' messages between testcases? E.g.
supposing I have a background handshaking protocol with the IUT to ensure
that the IUT is alive and the IUT thinks that the ETS is alive. What should
happen if such a message from the IUT comes in just after testcase1 is
exited and before testcase2 is entered?

- In the same vain, do connect and map operations persist through testcases?
Or do they have to be re-connected and re-mapped every time a testcase is
entered?

Many thanks.





Regards

Ray



Ray Cheung

---

Global Telecom Solutions Sector
Thamesdown Drive
Groundwell
Swindon
Wiltshire
SN25 4XY
Phone: +44 (0)1793 565529
Fax: +44 (0)1793 541228

---

>
>Hi Cheung,
>
Hi Ray,

I hope you don't mind me jumping into the thread...

>
>
>About the philosophy behind the language design... I'm not the best person
>to talk to, even though I indeed were involved quite early on when TTCN-3
>was developed. I would suggest that you direct your question to an ETSI PEX
>like Mr. Anthony Wiles or someone else in the TTCN-3 team. However, you
>should be aware that TTCN-3 was developed with the heritage of TTCN-2 in
>mind, where you had a similar approach to separation of test cases. I
>believe this is the strongest argument as to why this design was chosen.
>
Some of the design objectives of TTCN-3 include, but are not
limited to:

1) Simplifying TTCN, that is, making it easier to read and
write, without the need for special tools.
Thus the core notation which can be written using vi, emacs,
or any favourite text editor. Note that in TTCN-2 you can
do the same with the TTCN.MP format, but who wants to write
all those $keywords???

2) Modernization. TTCN-3 was made to resemble other mainstream
programming languages such as C++ and Java. Note the
OO syntax of TTCN-3. Modernization also includes making
TTCN-3 more readable, eg. removal of the TTCN-2 ! and ?
for sending and receiving. Making TTCN-3 more succinct, shorter. Note that
in send and receive templates, you only
need to reference the template instead of the type and the
constraint in TTCN-2.

3) Another big issue was to move away from OSI-centric nomenclature (e.g. using
ASPs, PDUs, and CMs, and structured
types instead of just using one data structure which is done
in TTCN-3, record. All this extra duplication is done away
with.

4) Removing unnecessary restrictions. In TTCN-2, the BNF
contains many STATIC SEMANTIC rules which are attached to
the BNF productions. Some of them have their "raison d'etre"
however others are not really needed. The TTCN-3 was cleaned
up to eliminate what was thought to be unnecessary.

5) Moving away from the perception that TTCN is only for
conformance testing. One of the reasons for dropping terms
like ASP, PDU and CMs, other than for simplification was
to attempt to get the testing community to drop the idea
that TTCN-2 or TTCN-3 for that matter was only good for
doing conformance testing of protocols. The changes brought
about are meant to get people to start with a clean slate,
and drop their old prejudices, and to see TTCN-3 as the
"new kid on the block", the language that can be
used for anything and everything related to testing.

The onus is really on the testing community, and interested
parties and individuals to demonstrate where TTCN-3 can be
used, other than in Telecom related situations!

6) Better integration of ASN.1 and other notations with TTCN-3

In TTCN-2 ASN.1 is not well integrated. Only X.680:1994 of ASN.1 is supported,
and the ASN.1 language definition had to
be modified to allow constraints to be used. Furthermore,
tagging information of ASN.1 modules gets lost if ASN.1 is used directly in
TTCN-2.
The fact that ASN.1 and TTCN-2 evolved in parallel for several years caused the
languages to diverge more and more, so much so that complete and satisfactory
harmonization of the two become even more difficult.
These, and a series of other problems were resolved in TTCN-3 by
changing the way other notations are interfaced with it. TTCN-3's BNF only
contains information related to TTCN-3, and nothing else. This makes things
cleaner.

7) In TTCN-2, the BNF contains $keywords which are related to
the TTCN.GR (tabular format). The keywords are mandatory.
In TTCN-3, the core notation has no mandatory references
to tabular format information. If one wishes to have
tabular format, one uses the optional 'display' attributes
which allows one to either present information using
ETSI standardized tables, or even to specify, organization
specific tables. The beauty of this is, is that you don't
need to change the BNF of TTCN-3 to do so, as you need to
do in TTCN-2, which makes your test suites "non-standard" and non compliant,
and non portable. OK, some have added new
features into their tools by specifying the proprietary information in comment
fields. That's fine, just that it is not such a nice solution.

>
>About your Tau/Tester question, yes, there are no explicit UnMap calls at
>termination of a test case. Those are not needed since the MTC itself - as
>mentioned earlier - vanishes along with its ports. I agree that it doesn't
>look too pretty, but there you go.
>

Well, it works, but that is not clean programming if you ask me.

>
>
>Cheers,
>
>/Johan
>
>
>
>

---

Original Message

---

>From: Cheung Ray-RCHEUNG1 [This email address is being protected from spambots. You need JavaScript enabled to view it.]
>Sent: den 5 november 2003 13:42
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: testcase related questions
>
>
>
>Hi Johan,
>
>
>
>Thanks for the answers. They were most helpful. Do you mind if I ask for
>your view?
>
>
>
>Do you happen to know the philosophy behind the TTCN-3 design? What are the
>advantages in destroying components and connections at the end of each test
>case - apart from that you alway start in a known (unitialised) state at the
>beginning of each test case? This seems to imply that all tests must be
>totally independent of each other. But is this really a reflection of the
>real testing world? We have lots of tests that have dependencies, e.g. test
>1 runs sequence A, test 2 runs B, test 3 runs C, etc, but they need to be
>run in sequence. If we were to make them independent, it would mean test 1
>runs A, test 2 must now run A & B, test 3 run A, B and C, etc. etc. If A is
>rebooting the board, this is obviously exceedingly inefficient. (You're
>probably going to ask, why not make a grand test that have A, B & C. It's
>because we can branch to other tests along the line, so e.g. we could run
>test 1 followed by test 5, or possibly test 1 and 2 followed by test 6,
>etc.)
>

Test case independence is something which comes from the CTMF
Conformance Testing Methodology and Framework defined in
X.290 through X.296. It still applies to TTCN-3 if one wishes
to do so, but this is not required.

Your analysis of the situation above is quite correct. If all
test cases use the same configurations, surely there is a way
which would allow one to define static test configurations as
is now done in TTCN-2, just that you might need to 'fugdge'
things to do so. Maybe TTCN-3 needs to think about adding
a new reserved word "static" which relates to functions used
to define static configurations as done in TTCN-2. This would
make converting TTCN-2 to TTCN-3 simple in some ways, and remove
the need to constantly reconfigure a test system after every
test case execution.
Maybe you might think about defining
one test case, where you map and connect everything, then
for each ttcn-3 test case you use a normal function, and
these are placed inside that one global test case. I.e.
testcase is replaced by function. Each function returns
a verdict.
( Verdict management might be a problem if you are depending
on the system to calculate the final verdict as it is
currently done in TTCN-3.
If you have different components running in a distributed manner, verdict
management needs to be addressed.)


Then you proceed by executing each function inside
that one test case. In this way, you don't have to disconnect
and reconnect everything. However, you will need to take care
of reinitializing your test system between test cases(that is
functions) to avoid any unwanted dependencies.


Hope this helps,


Cheers,


Claude.

>
Claude Desroches email:CDesroche@aol.com
Conformance Technologies Ltd. phone: +49 30 9606 7986
685 Cedar Point Road fax: +49 30 9606 7987
Penetanguishene Ontario, mobile 0174 701 6792
Canada

ext Claude Desroches wrote:

>>About your Tau/Tester question, yes, there are no explicit UnMap calls at
>>termination of a test case. Those are not needed since the MTC itself - as
>>mentioned earlier - vanishes along with its ports. I agree that it doesn't
>>look too pretty, but there you go.
>>
>>
>>
>
>Well, it works, but that is not clean programming if you ask me.
>
>

I have been stumbeling over exactly this issue not too long ago. The
problem is that the standard does not specify that all mapped ports are
automatically unmapped whenever a component dies or the testcase
finishes. It is the user's responsibility to ensure that all ports are
unmapped.

Together with the fact that the SA does not know when a testcase is
finished (only when the next one starts) and Tau/Tester's habit of
crashing when data is attempted to be sent to a no-longer existing port,
you have a recipe for desaster.

Two CRs would be needed, from my point of view:

a) automatic unmapping of all mapped ports of a component when a
component dies
b) a TRI procedure to inform the SA that a test case has finished.

Any opinions are welcome, but if nothing substantial comes up, I will
write those CRs.

BR

Stephan

--
Stephan Tobies Sr. Research Engineer, Nokia Research Center
Mobile Networks Lab, Protocol Engineering Group
E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
Work Phone: +49-234-9842262
Fax: +49-234-9843491
Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany