Interface test method and device for abnormal test case, equipment and medium

Abstract

The invention provides an interface test method, device and equipment for an abnormal test case and a medium, and the method comprises the steps: receiving an interface request parameter which comprises at least one field; setting each abnormal scene; combining each field in the interface request parameter with each abnormal scene to generate a corresponding abnormal test case; and testing is performed according to the abnormal test case to obtain the test report, so that all abnormal scenes are ensured to be tested, the working efficiency of testers is improved, and the cost of enterprises is reduced.

Description

Technical Field

[0001] The present invention relates to the technical field of interface anomaly testing, and in particular to an interface testing method, device, equipment and medium for an abnormal test case. Background Art

[0002] When performing interface testing, existing interface testing tools need to test whether various abnormal scenarios of the interface meet expectations. The test cases of abnormal scenarios need to combine data by themselves and then make requests one by one. Manually creating abnormal data of request parameters is more troublesome because the request parameters of each interface are different. Some interfaces may have dozens or hundreds of parameters. Each parameter needs to be combined with all abnormal scenarios to create data one by one. The amount of data is very large, and it takes a lot of time to create. It is also relatively complicated and prone to omissions. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide an interface testing method, device, equipment and medium for abnormal test cases, so as to ensure that all abnormal scenarios are tested, improve the work efficiency of testers and reduce the cost of enterprises.

[0004] In a first aspect, the present invention provides an interface testing method for abnormal test cases, comprising the following steps:

[0005] Step 1: Receive interface request parameters, where the interface request parameters include at least one field;

[0006] Step 2: Set up each abnormal scenario;

[0007] Step 3: Combine each field in the interface request parameter with each abnormal scenario to generate a corresponding abnormal test case;

[0008] Step 4: Perform tests based on abnormal test cases and obtain a test report.

[0009] In a second aspect, the present invention provides an interface testing device for abnormal test cases, comprising:

[0010] A parameter receiving module receives an interface request parameter, wherein the interface request parameter includes at least one field;

[0011] Abnormal scenario module, setting various abnormal scenarios;

[0012] Generate an exception test case module, combine each field in the interface request parameter with each exception scenario, and generate a corresponding exception test case;

[0013] The test report module performs tests based on abnormal test cases and obtains test reports.

[0014] In a third aspect, the present invention provides an electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method described in the first aspect when executing the program.

[0015] In a fourth aspect, the present invention provides a computer-readable storage medium having a computer program stored thereon, which implements the method described in the first aspect when the program is executed by a processor.

[0016] One or more technical solutions provided by the present invention have at least the following technical effects or advantages:

[0017] The present invention can automatically perform permutation and combination requests for all abnormal scenarios based on each field of the interface's request parameters. The number of fields is not fixed, and manual modification is unnecessary. It is fully automatic, automatically identifying and performing permutation and combination requests based on the parameters and abnormal scenarios. This significantly saves testing time. Abnormal testing that previously took several days to complete due to data creation can now be completed in an instant, speeding up overall testing progress.

[0018] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are specifically listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0020] Figure 1 This is a flowchart of the method in Example 1 of the present invention;

[0021] Figure 2 This is a schematic diagram of the structure of the device in Example 2 of the present invention. DETAILED DESCRIPTION

[0022] The embodiments of the present application provide an interface testing method, apparatus, device and medium for abnormal test cases, thereby facilitating the testing of abnormal scenarios and ensuring that all abnormal scenarios can be tested, thereby ensuring the operation of subsequent interfaces.

[0023] The technical solutions in the embodiments of this application have the following general ideas:

[0024] 1. Click on the abnormal test case and select the mode (complete, simple);

[0025] 2. Select the type of exception scenario based on the selected mode. The complete option is all exception scenarios (for example, SQL injection, missing key values, special symbols, single quotes, Chinese characters, Chinese content, negative numbers, special boundary values, parameter length, parameter length), etc. The simple option is a few of the more important exception scenarios (for example, SQL injection, missing key values, special symbols, single quotes, etc.).

[0026] 3. According to the selected exception scenario and each field in the interface request parameter, perform permutations and combinations to make automatic interface requests. For example, if the interface parameter A is {

[0027] "user_id":"16399955242598",

[0028] "company_id":"16399955241011",

[0029] "oauth_string":"Zti0zDTjV4QlcWqraL97",

[0030] "machine_code":"2c38019b02ac3eec19fdd144b5612b06_v1",

[0031] "language":"zh-CN",

[0032] "account_id":"27307955389886"

[0033] }

[0034] It can automatically start from the first field user_id and combine it with abnormal scenarios to make requests, such as not passing key values ​​("user_id":"") or special symbols ("user_id":"@@@!!!"), and after combining the first field, it will turn to the second field company_id and combine it with abnormal scenarios to make requests, and so on, until the end. The number of fields is not fixed and can be dynamically increased or decreased according to the interface parameters;

[0035] 4. After all request parameter fields and abnormal scenario combination requests are completed, a test report is output.

[0036] Specifically:

[0037] Generate exception test cases based on incoming data and patterns.

[0038] Supports recursive processing of dictionary and list type parameters.

[0039] The generated abnormal test cases include normal values, boundary values ​​and abnormal values; random boundary values ​​are generated, including short numeric strings and long character strings.

[0040] Generate abnormal test cases for request headers, including cases where no key value is passed, parameters are empty, and parameters are abnormal.

[0041]

[0042]

[0043]

[0044]

[0045]

[0046]

[0047]

[0048] The above dictionary is:

[0049] "Pass empty value":"",

[0050] "Single quote":""",

[0051] "SQL Injection-1":"1'and'1'='1",

[0052] "SQL Injection-2":"aaa'and'1'='1",

[0053] "SQL Injection-3":"1'and'1'='2",

[0054] "SQL Injection-4":"1'or'1'='1",

[0055] "Chinese symbols":"!#&……￥*%",

[0056] "Chinese content": "Test test123",

[0057] "Floating point string": 1.23456,

[0058] "Negative number": -123,

[0059] "Special Boundary Value 0": 0,

[0060] "Special symbols\"":"\"",

[0061] "Special symbol \\":"\\",

[0062] "Special symbol short string":"~)*&%? / ",

[0063] "Special symbol long string":"!%$#^^$*^%[];',. / **_)(_|' / {}:<>?~'"

[0064] }

[0065] Example 1

[0066] like Figure 1 As shown, this embodiment provides an interface testing method for abnormal test cases, including the following steps:

[0067] Step 1: Receive interface request parameters, where the interface request parameters include at least one field;

[0068] Step 2: Set up each abnormal scenario;

[0069] Step 3: Combine each field in the interface request parameter with each abnormal scenario to generate a corresponding abnormal test case;

[0070] Step 4: Perform tests based on abnormal test cases and obtain a test report.

[0071] In this embodiment, preferably, the step 1 specifically includes: setting a page for the user to fill in the set basic information, converting the basic information into data in JSON format, wherein the basic information includes: request address, request type, and request body; reading the interface request file uploaded by the user, parsing it, and obtaining parsed data; setting the format of the request data according to the type of request, obtaining corresponding data from the parsed data, and constructing interface request parameters if all data exist; if some data exist, obtaining corresponding data from the basic information, and constructing interface request parameters in combination with the data in the parsed data, and receiving the interface request parameters, wherein the interface request parameters include at least one field;

[0072] 1. Use the Excel template to write the interfaces you need to request (any number). When writing, you can miss any one or more of the URL, header, request method, request parameters, etc.

[0073] 2. Read the corresponding data by importing the Excel template. When no data can be read (information is missing), the compatibility logic will be triggered. By default, the corresponding missing data will be obtained from the interface of the requesting application. For example, if only the URL is written and nothing else is written, the matching data will be obtained from the URL matching application interface or the specified place to obtain the header, request method, and request parameters corresponding to the URL.

[0074] Specifically:

[0075] 1. Data in Excel file

[0076] The data in the Excel file is dynamic, and each row of data usually contains the following content (according to the code logic):

[0077] URL: The requested address.

[0078] Method: Request method (i.e. request type, such as GET, POST, etc.).

[0079] RequestBody: The content of the request body (usually form data or data in other formats).

[0080] These data are obtained in the code in the following ways:

[0081] javascript

[0082] const[urlValue,methodValue,requestBody]=row;

[0083] urlValue: The request address read from Excel.

[0084] methodValue: The request method read from Excel.

[0085] requestBody: The request body content read from Excel.

[0086] 2. Data in the page form

[0087] The data in the page form are fixed parameters entered by the user on the page. These parameters will be combined with the data in Excel to form the complete request parameters. The code obtains the form data in the following way:

[0088] javascript

[0089] const formData=newFormData(document.getElementById('apiform'));

[0090] The form may contain the following fields:

[0091] address: The default request address (if no URL is specified from Excel).

[0092] method: The default request method (if no method is specified from Excel).

[0093] request_data: The default request body content (if no request body is specified from Excel).

[0094] Other fields: may also include some additional request headers or other parameters.

[0095] 3. Combination of request parameters

[0096] Before sending the request, the code combines the data in Excel with the data in the form to form the final request parameters. The specific combination logic is as follows:

[0097] 3.1 Constructing new form data

[0098]

[0099] If requestBody is specified in Excel, the value in Excel is used; otherwise, the default value in the form is used.

[0100] If urlValue is specified in Excel, the value in Excel is used; otherwise, the default value in the form is used.

[0101] If methodValue is specified in Excel, the value in Excel is used; otherwise, the default value in the form is used.

[0102] The other fields use the values ​​directly from the form.

[0103] 3.2 Setting Request Options

[0104]

[0105] The request method (method) gives priority to the value in Excel, and if there is no value, it uses the default value in the form.

[0106] The Accept: application / json header is set in the request header, indicating that the response is expected to be in JSON format.

[0107] 3.3 Processing request body and query parameters

[0108]

[0109] If the request method is GET, the form data is appended to the URL as query parameters.

[0110] If it is another method (such as POST), the form data is sent as the request body.

[0111] 4. Summary: Parameters required by the request interface

[0112] According to the above logic, the request interface requires the following parameters:

[0113] Required parameters include:

[0114] URL: The requested address (obtained from Excel or the default value in the form).

[0115] Method: The requested method (obtained from Excel or the default value in the form).

[0116] RequestBody (optional): The content of the request body (obtained from Excel or the default value in the form).

[0117] Optional parameters include:

[0118] Other form fields: Depending on the form design, some additional request headers or other parameters may also be included.

[0119] Query parameters: If the request method is GET, the form data will be appended to the URL as query parameters.

[0120] 5. Examples

[0121] Assume that the Excel file contains the following content:

[0122] URL Method RequestBody https: / / example.com POST {"key":"value"}

[0123] Assume that you have the following fields in your form:

[0124] address: https: / / default.com

[0125] method: GET

[0126] request_data:{"default":"data"}

[0127] Then, the final request parameters are:

[0128] URL: https: / / example.com (from Excel)

[0129] Method: POST (from Excel)

[0130] RequestBody: {"key":"value"} (from Excel)

[0131] If a row of Excel data does not specify a URL or Method, the default value in the form will be used.

[0132] In this embodiment, preferably, the abnormal scenarios include: SQL injection, non-transmitted key values, special symbols, single quotes, Chinese characters, Chinese content, negative numbers, special boundary values, parameters that are too long, and parameters that are too short. By combining each field in the interface request parameters with the corresponding abnormal scenarios, corresponding abnormal test cases are generated.

[0133] In this embodiment, preferably, it also includes step 5, inputting the set keywords into the custom assertion library through the template, and binding the custom assertion library to the user; comparing each result data in the test report with the keywords in the user's custom assertion library one by one; according to the forward use case and the reverse use case, if it is a forward abnormal test case, the result data exists in the custom assertion library, which means it does not meet expectations; if not, it meets expectations; if it is a reverse abnormal test case, the result data exists in the custom assertion library, which means it meets expectations; if not, it does not meet expectations, and the assertion result is obtained; the assertion results and interface data are summarized in an Excel table, and the rows that meet expectations and do not meet expectations are marked with different colors for display.

[0134] Based on the same inventive concept, this application also provides a device corresponding to the method in Example 1, see Example 2 for details.

[0135] Example 2

[0136] like Figure 2 As shown, in this embodiment, an interface testing device for an abnormal test case is provided, including:

[0137] A parameter receiving module receives an interface request parameter, wherein the interface request parameter includes at least one field;

[0138] Abnormal scenario module, setting various abnormal scenarios;

[0139] Generate an exception test case module, combine each field in the interface request parameter with each exception scenario, and generate a corresponding exception test case;

[0140] The test report module performs tests based on abnormal test cases and obtains test reports.

[0141] In this embodiment, preferably, the parameter receiving module specifically: sets up a page for users to fill in the set basic information, converts the basic information into JSON format data, and the basic information includes: request address, request type and request body; reads the interface request file uploaded by the user, and parses it to obtain parsed data; according to the type of request, sets the format of the request data, obtains the corresponding data from the parsed data, and if all exist, constructs the interface request parameters; if some exist, obtains the corresponding data from the basic information, and constructs the interface request parameters in combination with the data in the parsed data, and receives the interface request parameters, and the interface request parameters include at least one field.

[0142] In this embodiment, preferably, the abnormal scenarios include: SQL injection, non-transmitted key values, special symbols, single quotes, Chinese characters, Chinese content, negative numbers, special boundary values, parameters that are too long, and parameters that are too short. By combining each field in the interface request parameters with the corresponding abnormal scenarios, corresponding abnormal test cases are generated.

[0143] In this embodiment, preferably, it also includes a display module, which inputs the set keywords into the custom assertion library through a template, and binds the custom assertion library to the user; compares each result data in the test report with the keywords in the user's custom assertion library one by one; according to the forward use case and the reverse use case, if it is a forward abnormal test case, the result data exists in the custom assertion library, which means it does not meet expectations; if not, it meets expectations; if it is a reverse abnormal test case, the result data exists in the custom assertion library, which means it meets expectations; if not, it does not meet expectations, and the assertion result is obtained; the assertion results and interface data are summarized in an Excel table, and the rows that meet expectations and do not meet expectations are marked with different colors for display;

[0144] The details are as follows:

[0145] 1. updateLogEntries() function is used to update the display of request records.

[0146] Function:

[0147] First, add a button to export request records on the page.

[0148] Get the unexpected keyword list (by calling the / get_unexpected_keywords / interface).

[0149] Use the checkBatchResultMeetsExpectation() function to check whether the response content of each request record contains unexpected keywords.

[0150] Based on the inspection results, the request record is inserted into the page in HTML format and displayed whether it meets expectations (green indicates compliance with expectations, red indicates non-compliance).

[0151] If the acquisition of unexpected keywords fails, the request record will still be displayed, but it will not show whether it meets expectations.

[0152] 2. exportRequestLog() function, used to export request records.

[0153] Function:

[0154] Checks whether there are any request records that can be exported, and prompts the user if not.

[0155] Get the unexpected keyword list (by calling the / get_unexpected_keywords / interface).

[0156] Use the checkBatchResultMeetsExpectation() function to check whether the response content of each request record contains unexpected keywords.

[0157] Encapsulate all request records (including whether they meet the expected results) into a FormData object and send it to the backend / download_request_log / interface through a POST request.

[0158] The backend returns a file (such as an Excel file), and the frontend creates a hidden Tag to trigger the file download.

[0159] 3. updateParameterizationEntries() function is used to update the result display of parameterized test.

[0160] Function:

[0161] Clears the existing display.

[0162] Traverse the history of parameterized tests and set the style based on whether it meets expectations (green means it meets expectations, red means it does not meet expectations).

[0163] Insert each test result into the page in HTML format.

[0164] 4. The checkBatchResultMeetsExpectation() function is used to check whether the response content meets expectations.

[0165] Function:

[0166] Convert the response content to a lowercase string.

[0167] Traverse the unexpected keyword list and return false (indicating that it does not meet expectations) if the response content contains any unexpected keyword.

[0168] If no unexpected keywords are included, it returns true (indicating that it meets expectations).

[0169] 5. File upload processing logic

[0170] When a user uploads an Excel file through the file chooser, the handleAssertFileUpload() function is triggered.

[0171] Function:

[0172] Use FileReader to read the uploaded file content.

[0173] Use the XLSX library to parse Excel files and convert table data into JSON format.

[0174] Traverse each row of data in the table and dynamically generate a new request based on the URL, method and request body in the table.

[0175] Use fetch to send a request and display the result on the page in HTML format.

[0176] The result of each request will display the URL, method, request parameters, status code, response time, response content, and whether it meets expectations.

[0177] 6. fetchUnexpectedKeywords() function is used to obtain a list of unexpected keywords. Function:

[0178] Call the / get_unexpected_keywords / interface to obtain a list of unexpected keywords.

[0179] Returns a Promise that resolves to a list of keywords.

[0180] Contains two Python methods:

[0181]

[0182]

[0183] The present invention is used for:

[0184] 1. Display and process custom assertion functions.

[0185] 2. Update and display request records.

[0186] 3. Export request records to Excel files.

[0187] 4. Process the result display of parameterized test.

[0188] 5. Check whether the response content meets expectations.

[0189] 6. Upload Excel file and generate request dynamically.

[0190] Since the device described in the second embodiment of the present invention is used to implement the method of the first embodiment of the present invention, those skilled in the art will be able to understand the specific structure and variations of the device based on the method described in the first embodiment of the present invention, and therefore will not be described in detail here. All devices used in the method of the first embodiment of the present invention fall within the scope of protection of the present invention.

[0191] Based on the same inventive concept, this application provides an electronic device embodiment corresponding to the first embodiment, see the third embodiment for details.

[0192] Example 3

[0193] This embodiment provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, any implementation method in the first embodiment can be implemented.

[0194] Since the electronic device described in this embodiment is the device used to implement the method in Example 1 of this application, based on the method described in Example 1 of this application, those skilled in the art will be able to understand the specific implementation of the electronic device of this embodiment and its various variations. Therefore, how the electronic device implements the method in the embodiment of this application will not be described in detail here. As long as the device used by those skilled in the art to implement the method in the embodiment of this application falls within the scope of protection to be provided by this application.

[0195] Based on the same inventive concept, this application provides a storage medium corresponding to Example 1, see Example 4 for details.

[0196] Example 4

[0197] This embodiment provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, any implementation method in the first embodiment can be implemented.

[0198] It will be understood by those skilled in the art that embodiments of the present invention may be provided as methods, systems, or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0199] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0200] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0201] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0202] Although the specific embodiments of the present invention are described above, those skilled in the art should understand that the specific embodiments described are merely illustrative and are not intended to limit the scope of the present invention. Equivalent modifications and changes made by those skilled in the art in accordance with the spirit of the present invention should be included within the scope of protection of the claims of the present invention.

Claims

1. An interface testing method for abnormal test cases, characterized by: The steps include: Step 1: Receive interface request parameters, where the interface request parameters include at least one field; Step 2: Set up each abnormal scenario; Step 3: Combine each field in the interface request parameter with each abnormal scenario to generate a corresponding abnormal test case; Step 4: Perform tests based on abnormal test cases and obtain a test report.

2. The interface testing method for abnormal test cases according to claim 1, characterized in that: The step 1 is specifically as follows: a page is set up for the user to fill in the set basic information, and the basic information is converted into data in JSON format, where the basic information includes: request address, request type and request body; the interface request file uploaded by the user is read and parsed to obtain parsed data; according to the type of request, the format of the request data is set, and the corresponding data is obtained from the parsed data. If all data exists, the interface request parameters are constructed; if some data exist, the corresponding data is obtained from the basic information, and the interface request parameters are constructed in combination with the data in the parsed data. The interface request parameters are received, and the interface request parameters include at least one field.

3. The interface testing method for abnormal test cases according to claim 1, characterized in that: The abnormal scenarios include: SQL injection, non-transmitted key values, special symbols, single quotes, Chinese characters, Chinese content, negative numbers, special boundary values, parameters that are too long, and parameters that are too short. By combining each field in the interface request parameters with the corresponding abnormal scenario, the corresponding abnormal test cases are generated.

4. The interface testing method for abnormal test cases according to claim 1, characterized in that: The method further includes step 5, inputting the set keywords into the custom assertion library through the template, and binding the custom assertion library to the user; Compare each result data in the test report with the keywords in the user's custom assertion library one by one; according to the forward use case and the reverse use case, if it is a forward abnormal test case, the result data exists in the custom assertion library, which means it does not meet expectations; if not, it meets expectations; if it is a reverse abnormal test case, the result data exists in the custom assertion library, which means it meets expectations; if not, it does not meet expectations, and obtain the assertion result; summarize the assertion results and interface data into an Excel table, and mark the rows that meet expectations and do not meet expectations with different colors for display.

5. An interface testing device for abnormal test cases, characterized by: include: A parameter receiving module receives an interface request parameter, wherein the interface request parameter includes at least one field; Abnormal scenario module, setting various abnormal scenarios; Generate an exception test case module, combine each field in the interface request parameter with each exception scenario, and generate a corresponding exception test case; The test report module performs tests based on abnormal test cases and obtains test reports.

6. The interface testing device for abnormal test cases according to claim 5, characterized in that: The parameter receiving module specifically: sets up a page for users to fill in the set basic information, converts the basic information into JSON format data, and the basic information includes: request address, request type and request body; reads the interface request file uploaded by the user, and parses it to obtain parsed data; sets the format of the request data according to the type of request, obtains the corresponding data from the parsed data, and if all exists, constructs the interface request parameters; if some exist, obtains the corresponding data from the basic information, and constructs the interface request parameters in combination with the data in the parsed data, and receives the interface request parameters, which include at least one field.

7. The interface testing device for abnormal test cases according to claim 5, characterized in that: The abnormal scenarios include: SQL injection, non-transmitted key values, special symbols, single quotes, Chinese characters, Chinese content, negative numbers, special boundary values, parameters that are too long, and parameters that are too short. By combining each field in the interface request parameters with the corresponding abnormal scenario, the corresponding abnormal test cases are generated.

8. The interface testing device for abnormal test cases according to claim 5, characterized in that: It also includes a display module that inputs the set keywords into the custom assertion library through the template and binds the custom assertion library to the user; Compare each result data in the test report with the keywords in the user's custom assertion library one by one; according to the forward use case and the reverse use case, if it is a forward abnormal test case, the result data exists in the custom assertion library, which means it does not meet expectations; if not, it meets expectations; if it is a reverse abnormal test case, the result data exists in the custom assertion library, which means it meets expectations; if not, it does not meet expectations, and obtain the assertion result; summarize the assertion results and interface data into an Excel table, and mark the rows that meet expectations and do not meet expectations with different colors for display.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the method according to any one of claims 1 to 4 is implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 4 is implemented.

Images