Overview - Test suggestions from TBots

[TOC] Test-Dragon gets and executes test-actions by repetitively calling the getTestInput() method of TBots. The test suggestions from a TBot is via return statements of the following form. <center>return testAction [, testArgs]</center> The **testArgs** is a list of parameters. Depending on the role of Test-Dragon played in this test suggestion, the testAction can be in one of the following. 1. **{An integer}**: This is an index of an element of the legal action list shown in the Test-Dragon GUI. In this case, the TBot expects Test-Dragon to play the role of test action executive. 2. **{Name of a platform action}**: In this case, the TBot treats Test-Dragon as a device or platform controller. 3. **crawl**: When receiving this test action from a TBot, Test-Dragon acts as a one-step crawler and can execute an action for the executing TBot. The test arguments constitute a list of elements in the following form. 1. *action topic [...]*: In the bracket is a list of action topics (as the **_NLP@topic** properties of all action dicts). The crawler can fulfill this test action by triggering an action in the screen with an **_NLP@topic** value in the list. 2. *action op [submitForm]*: In the bracket is a list of action opcodes (as the **op** properties of all action dicts). The crawler can fulfill this test action by triggering an action in the screen with such an **op** value. 3. *action coverage*: The crawler can fulfill this test action by triggering an action that has not been triggered before in the state. The ordering of elements represents the priority of checking the satisfaction of the elements. When there is no test arguments, a random action is triggered by Test-Dragon. In this role, the TBots can be relieved of the burden of crawling the states of the app screenshots for some coverage. 4. **reach**: When receiving this test action from a TBot, Test-Dragon acts as a long-range crawler and selects a sequence of test actions for the TBot to reach a coverage state according to the test arguments in the return value. 1. action topic XXX: The goal is to reach a state with an action whose **_NLP@topic** value is XXX. 2. action op YYY: The goal is to reach a state with an action whose **op** value is YYY. 3. state topic ZZZ: The goal is to reach a state whose **_FM@topic** value is ZZZ. 4. coverage state index NNN: The goal is to reach coverage state with index NNN in the coverage automata. 5. **submitForm** or **fillForm**: Test-Dragon supports intelligent automatic form recognition and filling. When a TBot returns <center>submitForm, D</center> Test-Dragon automatically fills in all text data items with form fields specified in the python dict D and then click the submit button of this form. We can also use API.testExec.getFormFill() to obtain a form fill suggestion from the AI capability of Test-Dragon that best matches the form in the screen with the test data cards and then modify the text data items for, e.g., SQl-injection, XXS, etc. If we only want to fill in the text data from python dict D, then TBot can return the following. <center>fillForm, D</center> We can also switch on the options for form filling automation in the project cards so that Test-Dragon can automatically serve to find the best-matching data card and fill in each form. 6. **callAlgorithm** or **exitAlgorithm**: A TBot can call one another when the the TBot requests Test-Dragon to play as a calling stack maintainer. When a TBot XXX returns <center>callAlgorithm, YYY</center> in its getTestInput(), then Test-Dragon will push YYY into the calling stack of TBots and XXX is a caller and YYY becomes a callee. When TBot YYY returns <center>exitAlgorithm</center> in its getTestInput, Test-Dragon will pop YYY out of the calling stack of TBots and TBot XXX resumes execution by Test-Dragon.