Re: Revised Test Cases

Hi Tommy

> 1)
> While I am personally OK with the approach, using XKISS messages to
> verify that XKRSS operations have produced the expected results may
> exclude implementors that only intend implementing XKRSS, or portions
> thereof, from executing some tests.
>

I don't see how the tests could exclude implementors from inplementing only
XKRSS. We already have a long list of KRISS tests and it doesn't preclude
people from implementing only part of XKISS or even part of a client to
participate in the test. Remember that the test cases can be exercised
individually, and untested cases can be marked as 4 in the report.

> 2)
> Assuming that XKISS messages are used to verify expected results of XKRSS
> requests, it may be more meaningful to incorporate the XKISS messages in
the
> actual XKRSS test case as opposed to having them separately, using T101 as
> an example:
>
>   - verify that binding-to-be-registered does not exist (Validate/Locate)
>   - attempt registration
>   - verify that binding-to-be-registered does exist (Validate/Locate)
>

Then the case can only be used by ones who implement both XKISS and XKRSS.
The question is, do we allow people to test only registration without
verifying state change?

> 4)
> I am not in favor of using the same shared secret for everyone.  Not only
is
> it not realistic, but it also allows for accidental inteference
> between individual
> testers.
>
Using the same shared secret is to facilitate automated testing where all
the test cases are conducted in sequential order. We can certainly make it a
parameter so that it can be entered before testing.

As for more test cases, we can definitely add when needed.

Regards,

Yunhao

Received on Wednesday, 13 October 2004 13:26:02 UTC