...
As the system evolves and goes through interoperabilty testing, we would like to ensure that scenarios that have already worked. One way of doing this is to run tests manually against actual equipment. However it is exceedingly difficult to do this because it requires a lot of configuration. Further, due to the dynamic nature of the protocol, different message interleaving may result in the test case than in the scenario that was debugged and hence the developer is never sure that exactly the same scenario has been re-run.
Running the regression tool
In your BUILD directory under sipXbridge/regression, edit the tester.properties file to specify your IP address.
run
| Code Block |
|---|
make regression |
Principle Of Operation
Signaling services such as sipXbridge are message driven finite state automata. i.e. from an external perspective they are driven by SIP signaling messages that appear at a port and they generate messages as a result of such messages. The important thing with testing such components is to send requests to and expects requests and responses from the SUT in the same order as a working test case does. The regression is a stimulus response tester which tries to maintain the same message ordering as was observed in a trace. The diagram below shows the setup :
...
The regression test tool (RT) is meant to test a single component in isolation by emulating actual call flows that interact with that component. Emulation in this case consists of presenting the SUT with a sequence of SIP requests which are suitably re-written. It is not meant to be a system tester i.e. it does not test signaling through multiple hops. inferred by reading a captured trace. RT reads a trace of a successful interoperability test that is presented as a suitably filtered "merged.xml" file (i.e. the output of sipx-trace with appropriate flags to isolate the call Id's of interest. It then consults a second configuration file (monitored-interfaces.xml) that indicates which IP addresses and ports in the captured merged.xml are of interest. A third configuration file (testmaps.xml) specifies an address mapping between a given trace message and an emulated trace message. As each message is presented to the SUT, addresses contained in the signaling such as the Via header address, Contact address, Route header address etc. are re-written to correspond to the corresponding address of the tester by consulting this mapping file. Finally, the tester address and base port are configured in tester config.xml
...