Working with multiple connected systems is complicated in other tools and therefore often not prioritized, leading to poor interoperability and user complaints. With quflow, interoperability testing is much easier:
1. Start a server for workspaces on one system. In this example the server publishes a phone (‘serverPhone=phone’) and its protocol on all workspaces so that other devices can use it during experiments.
[python]
>>> from quflow import Driver, Workspaces
>>> protocol = dict(
… commands = dict(
… attention="AT",call="ATD%s", answer="H1", hangup="H0"),
… events = dict(
… ok="OK", receiving="INCOMING CALL %s",
… connected="CONNECTED", disconnected="DISCONNECTED"),
… expectEcho = True)
>>> phone = Driver("COM5", number="+17654321", ** protocol)
>>> workspaces = Workspaces(protocol = protocol, serverPhone = phone)
Service spiro://:9091/<workspace> started.
>>>
[/python]
2. Control the experiment from a client system. In this case one that is connected to another phone on COM7. The printouts show communication to and from the COM ports (using their VISA resource name equivalents) when a test scenario is created and tested. Printouts in brackets indicate messages that are pending – these are programmed into the scenario as events on the line after.
[python highlight=”29″]
>>> from quflow import Driver, Workspace, enter, exit
>>> call_test = Workspace(‘localhost/call_1’)
>>> myPhone = Driver("COM7", number = ‘+12345678’, ** call_test.protocol)
>>> enter(call_test) # start a manual experiment
>>> myPhone.call(serverPhone.number)
ASRL7::INSTR> ATD+17654321
ASRL7::INSTR< ATD+17654321
(ASRL5::INSTR< INCOMING CALL +12345678)
>>> serverPhone.receiving(myPhone.number)
ASRL5::INSTR< INCOMING CALL +12345678
>>> serverPhone.answer()
ASRL5::INSTR> H1
ASRL5::INSTR< H1
(ASRL5::INSTR< CONNECTED)
(ASRL7::INSTR< CONNECTED)
>>> serverPhone.connected() and myPhone.connected()
ASRL5::INSTR< CONNECTED
ASRL7::INSTR< CONNECTED
>>> serverPhone.hangup() and myPhone.hangup()
ASRL5::INSTR> H0
ASRL5::INSTR< H0
ASRL7::INSTR> H0
ASRL7::INSTR< H0
(ASRL5::INSTR< DISCONNECTED)
(ASRL7::INSTR< DISCONNECTED)
>>> serverPhone.disconnected() and myPhone.disconnected()
ASRL5::INSTR< DISCONNECTED
ASRL7::INSTR< DISCONNECTED
>>> verdict("OK – myPhone *could* initiate a call with serverPhone")
VERDICT: OK – myPhone *could* initiate a call with serverPhone.
>>> exit(call_test) # finish the experiment
>>>
[/python]
The highlighted verdict line above is automatically converted into a static test purpose (where “OK – (dut) *could* (action)” becomes “Can (dut) (action)?”) and a dynamic test status that depends on the outcome of the latest run (“OK – (dut) *could* (action).” or “FAIL – (dut) *could not* (action).”). To make it re-run after an inconclusive failure, catch the bad situation once:
[python]
>>> call_test() # Re-run the test
TEST: Can myPhone initiate a call with serverPhone?
ASRL7::INSTR> ATD+17654321
ASRL7::INSTR< ATD+17654321
(ASRL7::INSTR< BUSY)
VERDICT: FAIL – myPhone *could not* initiate a call with serverPhone.
REASON: (‘ASRL7::INSTR< BUSY’) when expecting ‘ASRL5::INSTR< CONNECTED’ and ‘ASRL7::INSTR< CONNECTED’.
‘FAIL – myPhone *could not* initiate a call with serverPhone.’
>>> call_test("ServerPhone was buzy – trying again")
STATUS: ServerPhone was buzy – trying again.
TEST: Can myPhone initiate a call with serverPhone?
ASRL3::INSTR> ATD+17654321
ASRL3::INSTR< ATD+17654321
ASRL5::INSTR< INCOMING CALL +12345678
ASRL5::INSTR> H1
ASRL5::INSTR< H1
ASRL5::INSTR< CONNECTED
ASRL3::INSTR< CONNECTED
ASRL5::INSTR> H0
ASRL5::INSTR< H0
ASRL3::INSTR> H0
ASRL3::INSTR< H0
ASRL5::INSTR< DISCONNECTED
ASRL3::INSTR< DISCONNECTED
VERDICT: OK – myPhone *could* initiate a call with serverPhone.
‘OK – myPhone *could* initiate a call with serverPhone.’
>>>
[/python]
3. Run the experiment again, this time on the target system. If the target is a device tested in high volume production this is done in a separate thread within a pre-compiled boot script so that it consumes as little resources as possible and can run other tests in parallel, and with logging enabled so that any error messages can be used to document the reason for repair decisions and corrective actions.
[python]
>>> from quflow import Driver, Workspace
>>> from myplatform import myPhone
>>> call_test = Workspace(‘workspaces.myfactory.net/call_1’)
>>> call_test()
TEST: Can myPhone initiate a call with serverPhone?
ASRL3::INSTR> ATD+17654321
ASRL3::INSTR< ATD+17654321
ASRL5::INSTR< INCOMING CALL +12345678
ASRL5::INSTR> H1
ASRL5::INSTR< H1
ASRL5::INSTR< CONNECTED
ASRL3::INSTR< CONNECTED
ASRL5::INSTR> H0
ASRL5::INSTR< H0
ASRL3::INSTR> H0
ASRL3::INSTR< H0
ASRL5::INSTR< DISCONNECTED
ASRL3::INSTR< DISCONNECTED
VERDICT: OK – myPhone *could* initiate a call with serverPhone.
‘OK – myPhone *could* initiate a call with serverPhone.’
>>>
[/python]
Quflow & Perfeco 