Android Test Tool threadingtest Open API Interface Description

Threadingtest (TT) The first phase is an Android white box test tool, using offline detection method, based on the protection of User source code, the use of plug-in, fifth-generation coverage and other technologies, for development engineers and test engineers to provide a set of efficient quantifiable, visual communication tools. In contrast to other test tools, TT automatically generates the relationship between test cases and code and function coverage in automated tests, and is presented in a bi-directional traceability graph with TT, which, during the entire automated testing process, The TT also visualizes the test data obtained at every moment of the automated test with the Oscilloscope interface.

Based on the testing of other testing tools, TT also opened API interface to integrate, so that the original automation operation without any changes, through the TT API interface connection, TT oscilloscope to obtain the test data of other test tools, and generate the relationship between the test case and the code that will automatically generate the test case and the function coverage. The currently open Java language API directly uses the Java language as a unit test tool for script prediction, and automated test tools can be integrated with TT through this interface. This enables you to record the Code execution logic information corresponding to the use case in TT while running the test case.

Demo: Test Scenario Description:

When using other test tools for automated testing, if there is an inability to intervene in the test process or the automated test process is in progress, the test process needs to be a test case to differentiate, such as login and exit, run an automated test at the same time, both test cases are executed, you can in the program, Add the start and end points of the two test cases to differentiate between the two test cases. This enables the automatic creation of the relationship between the test case and the source code via TT, for example, the code that corresponds to the login operation and the exit action for this example will be created.

Test steps:

Take log-out as an example, if the following code structure exists:

... Classhomepage { public void Login () { ...//Login related actions } public void logout () { ...//exit related actions } }

1, the Javaparser-android.jar package is introduced into the project;

2, import com.zoa.writeToMQ.UnitTest;

3. Add start end ID.

Add the sign that the login test case starts at the beginning of the login function, add the identity of the login test case end before the function ends, and also add the corresponding identity at the beginning and end of the logout function. The following code is added:

... Import Com.zoa.writeToMQ.UnitTest; Classhomepage { public void Login () { UnitTest testlogin = new UnitTest ("Homepage/login"); ...//Login related actions Testlogin.close (); } public void logout () { UnitTest testlogout = new UnitTest ("Homepage/logout"); ...//exit related actions Testlogout.close (); } }

4, using the TT program to insert piles and test, see: Http://www.threadingtest.com/xwiki/bin/view/ZOA%7C4. Demo/android+ Program Test Configuration

Manual use of TT Test fundamentals:

In order for the reader to understand the TT interface call, we explain here how TT is recording the code execution logic and coverage information for the use case in manual mode.

In TT, the difference test cases are divided by using different test case IDs. At the beginning of the test add the test start identity and at the end of the add end identity, the purpose of which is to start the identity through a network connection or a USB connection, a string from the TT to get a test case ID, and then through the previous TT to the source code of the pile, the test program will continue to send data to the TT oscilloscope, The test case ID obtained from TT is used in the message to differentiate the test case.

When the send end identity is called, the sent message will be received using the default test case Id,tt, and the received data will be stored in the default checked test case, thus not mixing with the previous test case.

For example, when conducting a unit test, each unit test corresponds to a test case, resulting in multiple test cases, as follows:

1, open the TT real-time monitoring oscilloscope interface, tick a test case.

650) this.width=650; "Src=" http://img.blog.csdn.net/20140817191725430?watermark/2/text/ ahr0cdovl2jsb2cuy3nkbi5uzxqvdghyzwfkaw5ndgvzddiwmtq=/font/5a6l5l2t/fontsize/400/fill/i0jbqkfcma==/dissolve/70/ Gravity/southeast "/>

2. Click Start, then run the test.

650) this.width=650; "Src=" http://img.blog.csdn.net/20140817191549671?watermark/2/text/ ahr0cdovl2jsb2cuy3nkbi5uzxqvdghyzwfkaw5ndgvzddiwmtq=/font/5a6l5l2t/fontsize/400/fill/i0jbqkfcma==/dissolve/70/ Gravity/southeast "/>

At run time, the data waveform graph shows the data sent by the received program.

3, after the test is finished, click Stop, refresh the test case tree, you can see the divided test cases.

650) this.width=650; "Src=" http://img.blog.csdn.net/20140817191612656?watermark/2/text/ ahr0cdovl2jsb2cuy3nkbi5uzxqvdghyzwfkaw5ndgvzddiwmtq=/font/5a6l5l2t/fontsize/400/fill/i0jbqkfcma==/dissolve/70/ Gravity/southeast "/>

650) this.width=650; "Src=" http://img.blog.csdn.net/20140817191819999?watermark/2/text/ ahr0cdovl2jsb2cuy3nkbi5uzxqvdghyzwfkaw5ndgvzddiwmtq=/font/5a6l5l2t/fontsize/400/fill/i0jbqkfcma==/dissolve/70/ Gravity/southeast "/>

1. Unit Test start tag

Com.zoa.writeToMQ.UnitTest.UnitTest (String unitname)

Publicunittest (String unitname)

When this constructor is called, it marks the beginning of a unit test. Create a test case for a new unit test.

This function sends a unitname to TT, which is created by TT according to the name of a test case and test type. The communication process is a blocking process, and the function returns only if the communication ends or a serious error occurs.

When you do a unit test, you must select a test case on the TT side, and the resulting unit test case group will first generate a test type with the same name as the selected test case, and then build to that test type based on the test case and test type generated by Unitname.

Parameters:

unitname– the test case name, the name is split with "/", the last part is the test case name, and the previous part is the test type path, such as "Threadingtest/android/unittest" whose resulting test case structure is:

-threadingtest Test Type

|-android Test Type

|-unittest Test Cases

2. Unit Test END tag

Voidcom.zoa.writeToMQ.UnitTest.close () throws IOException

public void Close () throws IOException

To end a unit test, a unit test can call the function only once.

Parameters:

return value:

Threadingtest Official website: www.threadingtest.com

Interested in mobile white box test technology or performance testing, join the group symbol execution 339834199

Threadingtest Official website: www.threadingtest.com

Interested in mobile white box test technology or performance testing, join the group symbol execution 339834199