Interface testing method based on Linux cloud desktop platform

Abstract

The invention relates to an interface testing method based on a Linux cloud desktop platform, and relates to the field of software testing, and the method comprises the following steps: S1, obtaining API interface information from the Linux cloud desktop platform in real time, S2, carrying out interface testing on an obtained API interface based on the API interface information in combination with Jmeter, and generating an interface testing script, and S3, carrying out automation on the interface testing script based on a KylinATP automation platform. According to the method and the device, the effect of greatly improving the test efficiency while verifying whether the interface docking is accurate or not is achieved.

Description

Technical Field

[0001] The present application relates to the field of software testing, and in particular to an interface testing method based on a Linux cloud desktop platform. Background Art

[0002] With the continuous development of information technology, cloud desktop virtualization technology and cloud desktop solutions have become very mature. Compared with traditional PC office methods, they have obvious advantages in convenient management, easy delivery and cost savings, and have become a new idea for information construction and management in various industries.

[0003] Cloud desktops can provide the same office experience as traditional PCs, and seamlessly connect to existing office software and surrounding peripherals. Mainstream cloud desktops usually adopt a back-end computing architecture, and the various virtual desktop environments centrally deployed on the back end are isolated from each other and do not affect each other. All data is uniformly stored in background servers or storage devices, management policies are controllable, and data is not easily leaked. At the application level, it provides heterogeneous application push services running in domestic system environments to meet the needs of users in the information and innovation field during the transition period of business system replacement.

[0004] Kylin Security Cloud Desktop keeps up with the latest trends in the development of cloud desktops, adopts key technologies such as virtualization and protocol optimization, and provides many convenient functions such as system management, network management, image management, policy management, user management, terminal management, template management, desktop publishing, desktop management, application management, log management, etc.; and can distribute desktops to different users. Users can log in to the supporting client to achieve the same office experience as traditional PCs. The use of cloud desktops includes convenient operations such as connection, power operation, snapshot, and request for assistance. The various functions of the management end and the interfaces between the management end and the client are numerous and cumbersome, so interface testing is an extremely important and meaningful task for Kylin Security Cloud Desktop. How to verify whether the interface connection is accurate while greatly improving the test efficiency has become a problem. Summary of the invention

[0005] To solve the above problems, the present invention provides an interface testing method based on a Linux cloud desktop platform, which adopts the following technical solutions:

[0006] An interface testing method based on a Linux cloud desktop platform, comprising:

[0007] S1, obtains API interface information from the Linux cloud desktop platform in real time;

[0008] S2, based on the API interface information and combined with Jmeter, the obtained API interface is tested and an interface test script is generated;

[0009] S3, automates interface test scripts based on the KylinATP automation platform.

[0010] In a possible implementation manner, the API interface information includes cloud desktop management platform API interface information and cloud desktop client API interface information.

[0011] In one possible implementation, the API interface is tested based on the API interface information in combination with Jmeter, including:

[0012] Test the cloud desktop management platform API interface based on the cloud desktop management platform API interface information;

[0013] Test the cloud desktop client API interface based on the cloud desktop client API interface information.

[0014] In a possible implementation, the testing of the cloud desktop management platform API interface based on the cloud desktop management platform API interface information includes:

[0015] Sa1, parameterize the request header of the cloud desktop management platform API interface;

[0016] Sa2, parameterize the API interface information of the cloud desktop management platform;

[0017] Sa3, based on the request header parameterized by Sa1 and the cloud desktop management platform API interface information parameterized by Sa2, creates an HTTP request for the functional module corresponding to the desktop management platform API interface, and obtains an HTTP request result to simulate the API interface of the functional module to be tested in the cloud desktop management platform;

[0018] Sa4, adding a response assertion under the HTTP request to determine whether the HTTP request result is consistent with the obtained cloud desktop management platform API interface information, if consistent, determining the test result of the API interface test corresponding to the HTTP request as a test success, if inconsistent, determining the test result as a test failure;

[0019] Sa5, concatenates the created HTTP requests;

[0020] Sa6, add a listener to view the test results of the interface test of the cloud desktop management platform.

[0021] In a possible implementation manner, the testing of the cloud desktop client API interface based on the cloud desktop client API interface information includes:

[0022] Sb1, use Jmeter to create a test plan as the cloud desktop client interface test project to be tested, and add a thread group under the test plan, the name of the thread group corresponds to the functional module of the cloud desktop client to be tested;

[0023] Sb2, based on the obtained cloud desktop client API interface information, configures an HTTP information header manager under the thread group to manage the information header of the cloud desktop client API interface request;

[0024] Sb3, configure a controller under the thread group to set the operating conditions of the API interface of the functional module of the cloud desktop client to be tested;

[0025] Sb4, configuring an HTTP request sampler under the controller to complete the creation operation of the HTTP request, which is used to simulate the API interface of the functional module of the cloud desktop client to be tested;

[0026] Sb5, adding a response assertion under the HTTP request to determine whether the API interface of the cloud desktop client corresponding to the HTTP request is tested successfully;

[0027] Sb6, concatenate the created HTTP requests;

[0028] Sb7, add a listener to the test plan created in Sb1 and check the test results of the cloud desktop client interface test.

[0029] In a possible implementation, the interface test script is automated based on the KylinATP automation platform, including:

[0030] S31, create an interface test library in the test project management software, and upload all interface functions corresponding to all HTTP requests created in S2 into test cases to the interface test library, set the automation status to yes, create an automation execution test order and pull all test cases;

[0031] S32, modify the interface test script input method to obtain the modified Jmeter interface test script;

[0032] S33, submit the Jmeter interface test script to the code repository;

[0033] S34, perform testing based on the code repository through the KylinATP automated testing platform.

[0034] In summary, the present application includes the following beneficial technical effects:

[0035] This application obtains the API interface information of the cloud desktop platform in real time, including the API interface of the cloud desktop management platform and the client, and performs interface testing on the corresponding API based on the obtained API interface information in combination with Jmeter, and realizes the connection of the interface test script with the KylinATP automation platform, thereby realizing test case automation, thereby achieving the effect of greatly improving the test efficiency while verifying whether the interface connection is accurate. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Figure 1 It is a flow chart of an interface testing method based on a Linux cloud desktop platform in an embodiment of the present application.

[0037] Figure 2 It is a flowchart of the interface testing method of the cloud desktop management platform in the embodiment of the present application.

[0038] Figure 3 It is a flowchart of the interface testing method of the cloud desktop client in the embodiment of the present application.

[0039] Figure 4 It is a flowchart of a desktop interface test case automation method in an embodiment of the present application. DETAILED DESCRIPTION

[0040] The present application is further described in detail below in conjunction with the accompanying drawings.

[0041] After reading this specification, those skilled in the art may make non-creative modifications to this embodiment as needed, but such modifications are protected by patent law as long as they are within the scope of the claims of this application.

[0042] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0043] In addition, the term "and / or" in this article is only a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article, unless otherwise specified, generally means that the associated objects before and after are in an "or" relationship.

[0044] The embodiments of the present application are further described in detail below in conjunction with the drawings in the specification.

[0045] like Figure 1 As shown, the present application proposes a Linux-based cloud desktop platform interface testing method for testing whether the cumbersome interface of the existing cloud desktop platform is accurate. The method includes:

[0046] S1, obtains API interface information from the Linux cloud desktop platform in real time;

[0047] For the embodiment of the present application, the application becomes an interface, namely an API interface. The Linux cloud desktop platform includes a cloud desktop management platform and a cloud desktop client. The cloud desktop management platform communicates with the back-end server through the cloud desktop management platform API interface. The communication method is implemented using the HTTP protocol, and interaction is performed through the transmission of network data. The cloud desktop client interacts with the cloud desktop management platform through the cloud desktop client API interface. Therefore, the API interface information obtained in S1 includes the cloud desktop management platform API interface information and the cloud desktop client API interface information.

[0048] Specifically, the method for obtaining the cloud desktop management platform API interface information is as follows:

[0049] First, obtain the functional modules that need to be tested in the cloud desktop management platform, then access the cloud desktop management platform from the browser, and obtain the API interface information of the corresponding functional module through the F12 developer mode. The API interface information includes: interface URL, request method, request header, request body, response status code, response header, response text and other information.

[0050] The method to obtain the cloud desktop client API interface information is as follows:

[0051] First, install a network packet capture tool on the host machine of the cloud desktop client, and use the network packet capture tool to monitor and capture the API interface information sent by the cloud desktop client to the cloud desktop management platform in real time. When the network packet capture tool is running, it will monitor the network data packets on the host machine's network card, and then filter out the data flow between the cloud desktop client and the cloud desktop management platform through keywords such as IP address and protocol type, and view the API interface information of the data flow, including request URL, request method, request header, request body, response status code, response header, response text and other information.

[0052] S2, based on the API interface information and combined with Jmeter, the obtained API interface is tested and an interface test script is generated;

[0053] For the embodiment of the present application, continuing with the above example, since the cloud desktop platform includes a cloud desktop management platform and a cloud desktop client, the interface test of the present application includes an API interface test of the Sa cloud desktop management platform and an API interface test of the Sb cloud desktop client, and generates a complete cloud desktop interface test script, wherein:

[0054] like Figure 2 As shown in the figure, Sa, the API interface test of the cloud desktop management platform includes:

[0055] Sa1, parameterize the request header of the cloud desktop management platform API interface.

[0056] For the embodiment of the present application, the request header in the API interface is part of the HTTP protocol, which is used to transmit additional information between the cloud desktop management platform and the backend server. Before each thread group in Jmeter runs, the request header of the API interface needs to be loaded. Therefore, the request header of the API interface needs to be defined as a global variable and passed as a parameter to the HTTP information header manager of the thread group to facilitate subsequent unified modification. Specifically, the implementation method is as follows:

[0057] (1) Right-click in the Jmeter test plan to add a configuration element -> User-defined variables -> Add key-value pairs; (2) Fill the request header information obtained in S1 into the user-defined variables in the form of key-value pairs as variable management, including Host, Referer, Accept, Accept-Encoding, Accept-Language, Content-Type, User-Agent, x-auth-token, and X-Requested-With. The x-auth-token will be updated every 24 hours. Before executing the interface test, ensure that the value of the x-auth-token is consistent with the latest token value.

[0058] Sa2, parameterize the cloud desktop management platform API interface information.

[0059] For the embodiment of the present application, some parameters in the API interface information are set as global variables and passed to the HTTP request to be created in the subsequent Sa3. The parameters in the API interface information, such as the server IP address in the interface URL, the username / password in the request body, and other parameters referenced in multiple places can be set as global variables, so that the parameters can be managed uniformly and modified uniformly. The specific implementation method is as follows:

[0060] (1) Right-click in the Jmeter test plan to add a configuration element -> User-defined variables -> Add key-value pairs, where you can define name and value values. For example, if the user name is test, you can add a key-value pair and fill in user_name in the name input box and test in the value input box. (2) After defining the variable, pass it to subsequent HTTP requests and use ${name} as the reference method. If the user name needs to be referenced in the request body, use ${user_name}.

[0061] Sa3, based on the request header parameterized by Sa1 and the cloud desktop management platform API interface information parameterized by Sa2, creates an HTTP request for the functional module corresponding to the desktop management platform API interface, and obtains the HTTP request result to simulate the API interface of the functional module to be tested in the cloud desktop management platform.

[0062] For the embodiment of the present application, after Sa1 and Sa2 are ready, add a thread group under the Jmeter test plan->HTTP Header Manager->Add HTTP Request Sampler, that is, create an HTTP request, which is an access to the functional interface. The specific implementation method is as follows:

[0063] (1) Add Thread Group->HTTP Header Manager in the Jmeter test plan, and fill the request header variable set in step Sa1 into the HTTP Header Manager in the form of key-value pairs for reference;

[0064] (2) Adding an HTTP request sampler, first modify the name of the HTTP request sampler to the name of the function module corresponding to the API interface to be tested, and then fill the API interface information of the corresponding function module obtained in step S1, such as the interface URL, request method, request body, etc., into the HTTP request sampler one by one. For details, see the operation (2.1) below;

[0065] (2.1) HTTP request sampler configuration: (2.1.1) Protocol: The protocol used when sending HTTP requests to the backend server corresponding to the cloud desktop management platform. It can be HTTP or HTTPS. In this test, the protocol is https; (2.1.2) Server name or IP: The name or IP address of the target server to which the HTTP request is sent. This test has set the value as a global variable. You only need to reference it. The reference method is ${server_ip}; (2.1.3) Port number: The port number of the target server. The default value is 80. This test uses the default value and does not need to be filled in; (2.1.4) Request method: The method of sending HTTP requests. The specific method depends on the actual interface request method. Fill in, commonly used ones are get, post, head, put, delete and patch; (2.1.5) Path: target URL path; (2.1.6) Message body: There are three message body value methods. The first is the request data in JSON format. You can directly copy the json source code under the payload of the network request (that is, HTTP request) viewed by F12; the second is form data. Fill in the form data under the payload of the network request viewed by F12 in sequence; the third is file value. Select the file upload method, fill in the relative path of the file such as . / test_file.zip file, fill in the parameter name, and fill in the file type, that is, Content-Type;

[0066] (2.2) After the configuration is completed, you can click Run to test. If you want to determine whether the test results are accurate, you need to add "Response Assertion" under the HTTP Request Sampler to determine. For specific operations, see Sa4.

[0067] Sa4, add a response assertion under the HTTP request to determine whether the HTTP request result is consistent with the acquired cloud desktop management platform API interface information. If consistent, the test result of the API interface test corresponding to the HTTP request is determined to be a successful test. If inconsistent, the test result is determined to be a test failure.

[0068] For the embodiment of the present application, a "response assertion" is added under the HTTP request to determine whether the HTTP request result meets expectations, thereby determining whether the cloud desktop management platform functional interface test succeeds or fails. Specifically, the HTTP request result is matched with the response status code and response text in the API interface information of the cloud desktop management platform obtained by S1. If the match is consistent, it means that the test is successful, otherwise it means that the test fails. More specifically, the matching of the response status code and the matching of the response text are as follows:

[0069] (1) Response status code: Match the response status code obtained in S1, that is, set the interface response status code to the interface response status code obtained in S1. If the actual test result is inconsistent, it means that the match fails and the test result will be displayed in red. If the returned response status code needs to be ignored, you can check the "Ignore Status" checkbox. After ignoring, the response status code will not be matched.

[0070] (2) Response text: Match the response text, that is, set the response text to the response text obtained by S1. If the actual test result is inconsistent, it means that the match has failed, and the test result will be displayed in red. The response text matching rules can be: include, match, equal, and string; generally, the "include" matching rule is selected, and the wildcard (.*) is used to ignore the strings that do not need to be matched, thereby simplifying the matching text. For example, .*"display_name":"test" means that the execution passes when the response text includes the "display_name":"test" string.

[0071] Sa5, concatenate the created HTTP requests.

[0072] For the embodiments of the present application, it is necessary to create different thread groups to represent different functional modules, create different HTTP requests under the same thread group to represent the API interfaces under each functional module, and then cover the business process based on the dependency relationship between the various functional modules of the cloud desktop management platform.

[0073] Here we take the "Template Management" function module in the cloud desktop management platform as an example. The "Template Management" function module mainly includes "Creating Templates" and "Template Power Operations":

[0074] (1) Create a template: The HTTP request for this function requires three parameters: network, image, and configuration. Therefore, before creating the HTTP request for the template, you need to obtain the values ​​of these three parameters from other HTTP requests. Specifically, you can obtain them through a regular expression extractor or a JSON extractor. Use a regular expression to extract the desired data from the response text returned by the corresponding HTTP request and assign it to the variable xxx_id. Subsequent HTTP requests can directly reference the variable ${xxx_id}. If you need to set the local variable extracted by the JSON extractor as a global variable, you can add a BeanShell sampler. The setting method is: ${__setProperty(xxx_id,${xxx_id})}. The way to reference the global variable is ${__property(xxx_id)};

[0075] (2) Template power operation: The power operation interface has three options: power on, power off, and restart. To simplify the program, you need to traverse in the order of restart -> shutdown -> power on. The implementation method is as follows:

[0076] a. The prerequisite is to ensure that the template is in the running state: the IF controller is used to judge the template status field. If it is running, the IF judgment program will be jumped out. If it is not running and is in the shutdown state, the IF controller program will be entered to execute the interface request for the template startup, and the template will be kept in operation;

[0077] b. If it is running, then first execute the interface of the restart function: The complete process is as follows: the first step is to use the IF controller to determine whether the template task status and power status meet the requirements of the restart operation. If the task status is null and the power status is running, the restart operation can be performed. If not, the restart operation under the IF controller will be skipped and the next HTTP request will be executed. The second step is to determine whether the restart process is completed through the combination of While controller + fixed timer, that is, to obtain the task status of the template module through a request. If the task status is rebooting, continue to determine until the task status is not rebooting, indicating that the restart operation is completed. The third step is to use the IF controller to determine whether the restart is successful, that is, first determine whether the task status is rebooting. If not, the restart fails. If yes, execute to obtain the template interface information, and determine whether the power status of the template is running through the response assertion to determine whether the restart is successful.

[0078] c. After the restart function is executed, the shutdown function interface is executed again. The same judgment method as the restart operation is used to determine whether the shutdown is successful. After determining that the shutdown is successful, the startup function interface is executed again, and finally the startup is determined to be successful.

[0079] The above methods are also applied to HTTP requests of other process types. I will not go into details here.

[0080] Sa6, add a listener to view the test results of the interface test of the cloud desktop management platform.

[0081] For the embodiment of the present application, the interface test results can be viewed by right-clicking on the cloud desktop management interface test plan or thread group to add a listener -> View result tree; View result tree displays the HTTP request operation results in a tree diagram, including execution time, thread group name, HTTP request name, HTTP request and response data. If there is a failed execution result, it can be judged whether there is a problem with the interface or a problem with the interface test code written by the tester through the displayed HTTP request sampler failure code and type, request and response display error content, response assertion record error assertion, etc.

[0082] like Figure 3 As shown in Sb, the API interface test of the cloud desktop client includes:

[0083] Sb1, use Jmeter to create a test plan as the cloud desktop client interface test project to be tested, and add a thread group under the test plan, the name of the thread group corresponds to the functional module of the cloud desktop client to be tested.

[0084] For the embodiment of the present application, Jmeter is used to create a test plan as the cloud desktop client interface test project to be tested, and user-defined variables are filled in the test plan as global variables. A thread group is added under the test plan, and the name of the thread group corresponds to the functional module of the cloud desktop client interface test, and the number of threads required for the operation, the ramp-up time, and the number of loops are set.

[0085] Sb2, based on the obtained cloud desktop client API interface information, configures an HTTP information header manager under the thread group to manage the information header of the cloud desktop client API interface request.

[0086] For the embodiment of the present application, when operating in the cloud desktop client interface, the interface of the cloud desktop client will exchange data with the cloud desktop management platform to send data packets, that is, send HTTP / HTTPS requests, and the verification information defined in the request header enables the cloud desktop client and the cloud desktop management platform to connect. In S1, the request header of the cloud desktop client API interface has been obtained, and the data in the request header is placed in the HTTP information header manager in the form of a key-value pair, so that when sending a request to the cloud desktop management platform, it can simulate carrying the header information.

[0087] Sb3, configure a controller under the thread group to set the operating conditions of the API interface of the functional module of the cloud desktop client to be tested.

[0088] For the embodiments of the present application, an IF controller or a WHILE controller is configured under the thread group. The IF controller is used to control the process of executing the script. The HTTP request sampler under the controller can only be run when the IF condition is true. In the present application, the IF controller is used to determine whether the preconditions meet the expectations for executing the next step. For example: in the preconditions, the HTTP request extractor has been used to extract the status of the cloud desktop template and assign it to the variable template_status; in the IF controller, it is necessary to determine whether template_status is running. If so, enter the IF controller to execute the cloud desktop template shutdown operation; the controller condition is written as "${template_status}" == "running".

[0089] The WHILE controller is used to control the flow and number of script executions. The HTTP request sampler under the controller can only be run when the WHILE controller is true. In this application, the WHILE controller is used to determine whether the preconditions meet the expectation of executing the next step. When the conditions are met, the HTTP request sampler under the WHILE controller will be executed in a loop until the conditions are not met. For example: the cloud desktop template shutdown operation has been executed in the preconditions, and the status of the cloud desktop template is the intermediate state of shutdown; in the WHILE controller, it is necessary to determine whether template_status is powered off. If the status of the cloud desktop template is shutdown, the sampler under the WHILE controller is repeatedly run until the status of the cloud desktop template changes to shutdown, then the loop ends and the next step is entered; the controller condition is written as "${template_status}"! = "poweroff". The WHILE controller can also be used with a counter, so that the number of executions can be controlled by both the parameter value and the number of loops. For example: the counter setting name is loop_count, and the controller condition is written as "${template_status}"! ="poweroff"&&${loop_count}>10.

[0090] Sb4, configure an HTTP request sampler under the controller to complete the creation operation of the HTTP request, which is used to simulate the API interface of the functional module of the cloud desktop client to be tested.

[0091] For the embodiments of the present application, in the related art, since there is no clear definition of the command specification of the HTTP request, the test result display cannot distinguish which test environment the result is from, and the interface test fails and the specific location of the code module cannot be accurately located. In the present application, the HTTP request sampler is used to simulate the functional interface to be tested, so the HTTP request sampler is renamed to the cloud desktop client functional interface name to make it one-to-one corresponding to solve the problem that the result cannot accurately locate the specific location of the code module. The naming format is: test environment-functional module-functional name; for example, client-template-template startup.

[0092] Furthermore, in this application, HTTP request is used to simulate the add, delete, modify and query interface test of the cloud desktop client. The specific implementation method is: modify the name of the HTTP request to the name of the functional interface; fill in the correct basic information, the basic information includes the protocol, server name or IP, port number, request method, path and content encoding, and its value comes from the request header captured by the network packet capture tool; and the content sent with the HTTP request exists in three forms, namely parameters, message body data and file upload, and its content comes from the request body captured by the network packet capture tool in S1.

[0093] Sb5, adding a response assertion under the HTTP request to determine whether the API interface of the cloud desktop client corresponding to the HTTP request is tested successfully.

[0094] For the embodiment of the present application, the response assertion is used to determine whether the HTTP request meets expectations, thereby determining whether the corresponding cloud desktop client function interface test succeeds or fails. The specific implementation method is: add a response assertion under the HTTP request, and select the response status code and response text for judgment. If the test field selects the response status code, its pattern matching rule is "equal", and the matching object is the HTTP response status code captured by the network packet capture tool; if the test field selects the response text, its pattern matching rule is "include", and the matching object is the key field in the HTTP response text captured by the network packet capture tool.

[0095] Sb6, concatenate the created HTTP requests.

[0096] For the embodiment of the present application, the thread group simulates the functional module, and the HTTP request simulates the API interface corresponding to the functional module. According to the business operation process of the cloud desktop client, multiple HTTP requests are created under the same thread group to cover the API interface contained in the functional module. The specific implementation method is: create a module thread group, such as creating a cloud desktop operation thread group, which is used to test the cloud desktop operation functional module of the client, and create multiple HTTP requests in sequence under this thread group. For example, the interface functions correspond to the application cloud desktop-connect cloud desktop-disconnect cloud desktop operation process in sequence, simulating the actual operation process of the cloud desktop client to achieve the purpose of covering the business process.

[0097] Sb7, add a listener to the test plan created in Sb1 and check the test results of the cloud desktop client interface test.

[0098] For the embodiment of the present application, select View Results in Table and View Result Tree as the result monitoring tool. View Results in Table displays the running results in a table, including execution time, thread group name, HTTP request name, and execution status. The execution results of each test case can be quickly viewed through the table results; View Result Tree displays the running results in a tree list, including sampler results, request and response data. When the operation fails, the response assertion details will also be displayed. If the results of all response assertions are successful, the interface test case is executed successfully; if an assertion fails, the test case fails to execute and the exception information is reported.

[0099] S3, automates interface test scripts based on the KylinATP automation platform.

[0100] For the embodiment of the present application, after S1 and S2 implement the interface test of the cloud desktop platform, an interface test script is also generated. The interface test script needs to be automated and run in the background without occupying local resources. Specifically, Figure 4 As shown, the steps to achieve automation are as follows:

[0101] S31, create an interface test library in the test project management software, and upload all interface functions corresponding to all HTTP requests created in S2 into test cases to the interface test library, set the automation status to yes, create an automated execution test order and pull all test cases.

[0102] For the embodiment of the present application, the test project management software refers to ZenTao management software. The specific implementation method is: the interface functions corresponding to the HTTP request are formed into test cases and uploaded to the ZenTao management software, and the automation status is set to "yes", an automated execution test order is created and all test cases are pulled, thereby opening the channel for docking with the KylinATP automated testing platform.

[0103] S32, modify the interface test script input method to obtain the modified Jmeter interface test script.

[0104] For the embodiment of the present application, a complete interface test script has been formed according to S1 and S2, that is, the interface test script only relies on Jmeter software to run; in order to combine with the KylinATP automation platform to uniformly manage variables, it is necessary to extract the user-defined variables in the interface test script and the variables of the HTTP header manager, reserve a parameter passing entry, and perform variable parameter configuration through the KylinATP automation platform interface during execution. The specific implementation method is as follows: (1) unified management through user-defined variables: for example, there is a parameter Host in the HTTP information header manager under the thread group, and its value is the URL of the cloud desktop, then add a parameter key pair value in the user-defined variable of the test plan: the name is server_ip, the value is server_ip_value, and the value of Host in the HTTP information header manager under the thread group is modified to ${server_ip}, that is, the value of server_ip in the user-defined variable is taken; (2) create a front-end configuration script, and use sed to replace the variable value in the interface test script file, for example, replace the server_ip_value in (1): sed-i"s / server_ip_value / ${server_ip_value} / g"xxx.jmx, and obtain the modified Jmeter interface test script.

[0105] S33, submit the Jmeter interface test script to the code repository.

[0106] For the embodiment of the present application, the code repository refers to the Gerrit repository. The Gerrit repository is an open source code review software. Software developers in the same project team can review each other's code and decide whether to submit, roll back or continue to modify; it uses the version control system Git as the underlying layer and can also be used for code repository management. The specific implementation method is: (1) Create a code repository for cloud desktop interface testing on Gerrit; (2) Enter the code repository, copy the SSH url to the local and execute the git clone url; (3) Enter the local code library directory to configure the user name and email address; (4) Put the Jmeter interface test script in the test script directory, execute git add to submit the update; (5) Execute git push to push the update to the code repository and merge the code.

[0107] S34, perform testing based on the code repository through the KylinATP automated testing platform.

[0108] For the embodiment of the present application, KylinATP is an important testing platform for quality assurance of the KylinOS system. It matches multiple business lines with corresponding automated test cases in the order of the R&D time cycle, connects iterative processes such as R&D and testing through the testing platform, and ultimately realizes automation of the entire product R&D process. The KylinATP automation platform connects the Gerrit warehouse and ZenTao management software, allowing testers to complete automated testing online, generate automated test reports, and realize performance data statistics and analysis. The specific implementation method is as follows: (1) Log in to the KylinATP platform, select the branch where the code repository of the Jmeter interface test script is located, and select the ZenTao automated test order in step S31 to create a KylinATP test plan; (2) Configure the test parameters. The parameter list is the uniformly managed variables extracted from S32. The configuration method is {"server_ip_value":"10.10.10.10"}, so that the Host in the Jmeter interface test script can successfully take the value of 10.10.10.10 when the program is running; (3) Execute the automated test; (4) Wait for the test to complete, view the execution results, and view the logs for analysis of failed items; (5) Synchronize the results to the ZenTao management software. This completes the cloud desktop interface test of the KylinATP automated platform.

[0109] This application obtains the API interface information of the cloud desktop platform in real time, including the API interface of the cloud desktop management platform and the client, and performs interface testing on the corresponding API based on the obtained API interface information in combination with Jmeter, and realizes the connection between the interface test script and the KylinATP automation platform, thereby realizing test case automation and improving the testing efficiency of API interface testing.

[0110] It should be understood that, although the steps in the flowchart of the accompanying drawings are displayed in sequence as indicated by the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least a part of the steps in the flowchart of the accompanying drawings may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be executed in turn or alternately with other steps or at least a part of the sub-steps or stages of other steps.

[0111] The above are only some implementation methods of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. An interface testing method based on a Linux cloud desktop platform, characterized in that: include: S1, obtains API interface information from the Linux cloud desktop platform in real time; S2, based on the API interface information and combined with Jmeter, the obtained API interface is tested and an interface test script is generated; S3, automates interface test scripts based on the KylinATP automation platform.

2. According to claim 1, an interface testing method based on a Linux cloud desktop platform is characterized in that: The API interface information includes cloud desktop management platform API interface information and cloud desktop client API interface information.

3. According to claim 2, an interface testing method based on a Linux cloud desktop platform is characterized in that: Based on the API interface information and Jmeter, the obtained API interface is tested, including: Test the cloud desktop management platform API interface based on the cloud desktop management platform API interface information; Test the cloud desktop client API interface based on the cloud desktop client API interface information.

4. According to claim 3, an interface testing method based on a Linux cloud desktop platform is characterized in that: The testing of the cloud desktop management platform API interface based on the cloud desktop management platform API interface information includes: Sa1, parameterize the request header of the cloud desktop management platform API interface; Sa2, parameterize the API interface information of the cloud desktop management platform; Sa3, based on the request header parameterized by Sa1 and the cloud desktop management platform API interface information parameterized by Sa2, creates an HTTP request for the functional module corresponding to the desktop management platform API interface, and obtains an HTTP request result to simulate the API interface of the functional module to be tested in the cloud desktop management platform; Sa4, adding a response assertion under the HTTP request to determine whether the HTTP request result is consistent with the obtained cloud desktop management platform API interface information, if consistent, determining the test result of the API interface test corresponding to the HTTP request as a test success, if inconsistent, determining the test result as a test failure; Sa5, concatenates the created HTTP requests; Sa6, add a listener to view the test results of the interface test of the cloud desktop management platform.

5. According to claim 3, an interface testing method based on a Linux cloud desktop platform is characterized in that: The testing of the cloud desktop client API interface based on the cloud desktop client API interface information includes: Sb1, use Jmeter to create a test plan as the cloud desktop client interface test project to be tested, and add a thread group under the test plan, the name of the thread group corresponds to the functional module of the cloud desktop client to be tested; Sb2, based on the obtained cloud desktop client API interface information, configures an HTTP information header manager under the thread group to manage the information header of the cloud desktop client API interface request; Sb3, configuring a controller under the thread group to set the operating conditions of the API interface of the functional module of the cloud desktop client to be tested; Sb4, configuring an HTTP request sampler under the controller to complete the creation operation of the HTTP request, which is used to simulate the API interface of the functional module of the cloud desktop client to be tested; Sb5, adding a response assertion under the HTTP request to determine whether the API interface of the cloud desktop client corresponding to the HTTP request is tested successfully; Sb6, concatenate the created HTTP requests; Sb7, add a listener to the test plan created in Sb1 and check the test results of the cloud desktop client interface test.

6. The interface testing method based on the Linux cloud desktop platform according to claim 1, characterized in that: The interface test script is automated based on the KylinATP automation platform, including: S31, create an interface test library in the test project management software, and upload all interface functions corresponding to all HTTP requests created in S2 into test cases to the interface test library, set the automation status to yes, create an automation execution test order and pull all test cases; S32, modify the interface test script input method to obtain the modified Jmeter interface test script; S33, submit the Jmeter interface test script to the code repository; S34, perform testing based on the code repository through the KylinATP automated testing platform.

Images