Mobile terminal automatic test method and device, storage medium and computer device

Abstract

The application relates to the technical field of data processing, and discloses a mobile terminal automatic testing method and device, a storage medium and a computer device. The method comprises the following steps: in response to an automatic testing starting instruction, an external text configuration file is acquired; the file is parsed to obtain a to-be-tested case list; a test case root directory of a to-be-tested mobile terminal is determined, test case folders under the test case root directory are traversed, a case identifier in a folder name is extracted, and it is judged whether the to-be-tested case list contains the identifier; if yes, a test script in the folder is executed, an automatic testing sub-report containing the identifier is generated based on an execution result; otherwise, the folder is skipped; automatic testing reports are generated by summarizing the sub-reports, and a case description information field corresponding to each case identifier field in the external text configuration file is used to replace the original case identifier. The application can be applied to mobile terminal automatic testing scenes in the fields of financial technology and smart medical treatment.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a mobile terminal automated testing method and apparatus, storage medium, and computer equipment. Background Technology

[0002] With the deep integration of smart healthcare and fintech, mobile applications are playing an increasingly important role in scenarios such as medical payments, health insurance claims, remote prescription settlement, and electronic medical insurance vouchers. These applications not only need to handle sensitive medical data and financial transaction information, but also require frequent iterations to adapt to constantly changing regulatory policies, security standards, and user experience needs. Each version update may involve core business processes, therefore rigorous regression testing is essential to ensure functional correctness and data security. Mobile automated testing technology has thus become a key means of ensuring the quality of such applications, achieving efficient and repetitive testing and verification through simulated user operations.

[0003] However, existing technologies still have significant shortcomings in mobile automated testing practices in the fields of smart healthcare and fintech. On the one hand, traditional testing frameworks (such as Appium and Airtest) generally adopt a "full execution" mode, meaning that all test cases are run for each regression test. This results in test time increasing linearly with the number of test cases, severely slowing down continuous integration pipelines and failing to meet the high-frequency iteration and rapid response development pace of healthcare and financial applications. On the other hand, when testers need to perform smoke or regression testing on specific functional modules, they often need to modify test scripts, repackage, or enter complex command-line parameters, which is cumbersome and prone to errors. Summary of the Invention

[0004] In view of this, this application provides a mobile terminal automated testing method and apparatus, storage medium, and computer equipment. By introducing an external text configuration file to drive the selection and execution of test cases, it solves the technical problems of low efficiency caused by full execution in existing mobile terminal automated testing, as well as the cumbersome and error-prone operation caused by modifying code or command line parameters to adjust the test scope.

[0005] According to one aspect of this application, a mobile automated testing method is provided, comprising: In response to the automated test start command, a pre-created external text configuration file is obtained, wherein each record in the external text configuration file contains a test case identifier field and a test case description information field; Parse the external text configuration file to obtain a list of test cases consisting of the test case identifier field of each record; Determine the root directory of the test cases corresponding to the mobile device to be tested, traverse all test case folders under the root directory, extract the test case identifier from the name of each test case folder, and determine whether the test case identifier is contained in the list of test cases to be tested. If the test case identifier is included, the automated testing framework is invoked to execute the test script in the test case folder, and an automated test sub-report containing the test case identifier is generated based on the execution result; otherwise, the test case folder is skipped. After all test case folders have been traversed, the automated test reports are compiled to generate an automated test report. In the automated test report, the test case description information field corresponding to the test case identifier field in the external text configuration file is used to replace the originally displayed test case identifier.

[0006] According to another aspect of this application, a mobile terminal automated testing apparatus is provided, comprising: The file acquisition module is used to acquire a pre-created external text configuration file in response to an automated test start command. Each record in the external text configuration file contains a test case identifier field and a test case description information field. The file parsing module is used to parse the external text configuration file to obtain a list of test cases consisting of the test case identifier field of each record; The judgment module is used to determine the root directory of the test cases corresponding to the mobile terminal to be tested, traverse all test case folders under the root directory of the test cases, extract the test case identifier from the name of each test case folder, and determine whether the test case identifier is contained in the list of test cases to be tested. The test script execution module is used to, if the test case identifier is included, call the automated testing framework to execute the test script in the test case folder and generate an automated test sub-report containing the test case identifier based on the execution result; otherwise, skip the test case folder. The report generation module is used to summarize the automated test sub-reports and generate an automated test report after all test case folders have been traversed. In the automated test report, the test case description information field corresponding to the test case identifier field in the external text configuration file is used to replace the originally displayed test case identifier.

[0007] According to another aspect of this application, a storage medium is provided that stores a computer program thereon, which, when executed by a processor, implements the above-described mobile terminal automated testing method.

[0008] According to another aspect of this application, a computer device is provided, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor executes the program to implement the above-described mobile terminal automated testing method.

[0009] By employing the aforementioned technical solutions, this application provides a mobile terminal automated testing method, apparatus, storage medium, and computer device. By introducing an external text configuration file as the driving core, testers do not need to modify scripts or repackage the application; they only need to edit the test case identifier field in the file to accurately specify the list of test cases to be tested. This completely eliminates the reliance on command-line parameters or hard-coded data, greatly reducing operational complexity and the probability of errors. Upon startup, the external text configuration file is automatically parsed and a list of test cases to be tested is generated. Then, the root directory of test cases is traversed, and only test scripts matching the list of test cases are executed, completely skipping the initialization and execution of irrelevant test cases. This compresses regression testing time from linear growth to being solely dependent on the number of test cases, significantly improving response speed and resource utilization. The final automated test report uses the pre-defined test case description information field in the external text configuration file instead of the original technical test case identifiers for display, making the report content intuitively readable for business personnel without a technical background and enhancing the communication efficiency of test results.

[0010] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0011] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This diagram illustrates an application environment of a mobile terminal automated testing method according to an embodiment of the present invention. Figure 2 A flowchart illustrating a mobile terminal automated testing method provided in an embodiment of this application is shown. Figure 3 This illustration shows a schematic diagram of an automated test report update process provided in an embodiment of this application; Figure 4 This illustration shows a structural schematic diagram of a mobile terminal automated testing device provided in an embodiment of this application; Figure 5 A schematic diagram of the device structure of a computer device provided in an embodiment of this application is shown. Detailed Implementation

[0012] The present application will be described in detail below with reference to the accompanying drawings and embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in the embodiments of the present application can be combined with each other.

[0013] The mobile automated testing method provided in this invention can be applied to applications such as... Figure 1 In this application environment, the mobile device communicates with the test machine via a USB cable or local area network. Upon receiving the automated test start command, the test machine retrieves a pre-created external text configuration file. Each record in this file contains a test case identifier field and a test case description field. The test machine parses this external text configuration file to obtain a list of test cases to be tested, composed of the test case identifier fields from each record. Next, the test machine determines the root directory of the test cases corresponding to the mobile device currently under test and then traverses all test case folders within that directory. For each test case folder, the test machine extracts the test case identifier from its name and checks if this identifier exists in the list of test cases to be tested. If it exists, the test machine sends an execution command to the mobile device via USB or local area network, calling the underlying automated testing framework to run the test scripts in that test case folder and generates an automated test sub-report containing the test case identifier locally on the test machine based on the execution results. If it does not exist, the test machine skips that test case folder and does not send any commands to the mobile device. After all test case folders have been traversed, the testing machine summarizes the various automated test sub-reports and generates a unified automated test report. In this report, the test case description information field corresponding to each test case identifier in the external text configuration file replaces the originally displayed technical test case identifiers. Thus, the testing machine, through collaboration with the mobile device via USB or LAN, completes the entire automated testing process from configuration file-driven, on-demand matching, precise execution to readable report generation. The mobile device can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The testing machine can be implemented using, for example, a build node in a continuous integration pipeline or a local development computer. The invention will be described in detail below through specific embodiments.

[0014] This embodiment provides a mobile automated testing method, such as... Figure 2 As shown, the method includes: Step 101: In response to the automated test start command, obtain the pre-created external text configuration file, wherein each record in the external text configuration file contains a test case identifier field and a test case description information field.

[0015] Step 102: Parse the external text configuration file to obtain a list of test cases consisting of the test case identifier field of each record.

[0016] Step 103: Determine the root directory of the test cases corresponding to the mobile device to be tested, traverse all test case folders under the root directory of the test cases, extract the test case identifier from the name of each test case folder, and determine whether the test case identifier is contained in the list of test cases to be tested.

[0017] Step 104: If the test case identifier is included, the automated testing framework is invoked to execute the test script in the test case folder, and an automated test sub-report containing the test case identifier is generated based on the execution result; otherwise, the test case folder is skipped.

[0018] Step 105: After all test case folders have been traversed, summarize the automated test sub-reports to generate an automated test report. In the automated test report, replace the originally displayed test case identifiers with the test case description information fields corresponding to the test case identifier fields in the external text configuration file.

[0019] This application provides a mobile automated testing method. First, when the automated testing system receives an automated test start command, it can immediately obtain a pre-created external text configuration file. Here, the automated test start command can be manually triggered by testers or automatically triggered by the continuous integration pipeline after code submission. In a specific embodiment, the external text configuration file can be named "caselist.txt," a plain text format. Each line contains two fields: a test case identifier field and a test case description field. The test case identifier field can be a short technical number, such as "TC001" or "PAY_003," used to uniquely identify a test case. The test case description field can describe the specific function of the test case in natural language, such as "medical insurance payment process verification" or "online consultation prescription upload test." In smart healthcare applications, the external text configuration file can only list test case identifiers related to "electronic medical record synchronization"; in fintech applications, it can only include test case identifiers for core transaction links such as "credit card repayment" and "account binding," thereby achieving externalized definition of the test scope without modifying any test script code.

[0020] Next, this external text configuration file can be parsed to extract the test case identifier field from each line and combine them into a list of test cases. This list is essentially a collection of strings in memory, such as {"TC001", "TC003", "PAY_005"}, which represents the scope of test cases to be executed in this test task. Using an external text configuration file completely separates the test task from the specific test execution logic, allowing non-technical personnel to directly determine the test scope by editing the external text configuration file without intervening in the code repository or build process. For example, in a fintech scenario, a compliance team can quickly create an external text configuration file containing only test cases related to "anti-money laundering transaction reports" for specific compliance verification before deployment.

[0021] Furthermore, the root directory of the test cases corresponding to the mobile platform currently under test can be determined. In actual projects, Android and iOS test scripts are usually stored in different folders, such as " / testcases / Android / " and " / testcases / iOS / ". Specifically, the correct root directory of test cases can be automatically selected based on pre-set environment variables (such as DEVICE=Android). After selecting the root directory of test cases, all test case folders under that directory can be traversed. These test case folders can be named according to a convention: the first field before the underscore (_) separator is used as the test case identifier, such as "TC001_XXX.air" or "PAY_005_XXX.air". For each test case folder, the part before the first underscore in its name can be extracted as the test case identifier for that test case folder, and then it can be checked whether this test case identifier exists in the previously constructed list of test cases. This naming convention mechanism avoids maintaining an additional mapping table.

[0022] For each test case folder, if its test case identifier exists in the list of test cases to be tested, the underlying automated testing framework (such as Airtest or Appium) can be invoked to execute the test scripts in that folder. Based on the execution results, an automated test sub-report containing the test case identifier is generated, which can record detailed logs, screenshots, assertion results, etc., during the execution process. If its test case identifier is not in the list of test cases to be tested, the folder can be skipped without any initialization or invocation. This "on-demand execution" mechanism can significantly save testing resources. Taking a smart healthcare scenario as an example, if the code change only involves the "appointment registration" module, testers only need to list relevant test case identifiers such as "registration process" and "doctor schedule query" in the external text configuration file. This will automatically skip irrelevant test cases such as "physical examination report interpretation" and "drug delivery query," thus greatly shortening testing time.

[0023] After all test case folders have been traversed, the various automated test sub-reports can be summarized to generate a unified automated test report. When generating the automated test report, the "Test Case Description Information Field" recorded in the external text configuration file can be used to replace the test case identifier originally displayed in the report. For example, if the external text configuration file records "TC001, Medical Insurance Online Payment Function Verification," then the final automated test report will not display the rigid "TC001," but rather the clear "Medical Insurance Online Payment Function Verification." This replacement greatly improves the readability of the automated test report, allowing project managers, product managers, and even hospital IT personnel without a technical background to understand the test results at a glance.

[0024] By applying the technical solution of this embodiment and introducing an external text configuration file as the driving core, testers do not need to modify scripts or repackage the application. They only need to edit the test case identifier field in the file to accurately specify the list of test cases to be tested, thus completely eliminating the dependence on command line parameters or hard coding, greatly reducing operational complexity and error probability. After startup, the external text configuration file is automatically parsed and a list of test cases to be tested is generated. Then, the root directory of test cases is traversed, and only the test scripts that match the list of test cases to be tested are executed. The initialization and execution process of irrelevant test cases are completely skipped, thereby compressing the regression testing time from linear growth to being only related to the number of test cases to be tested, significantly improving response speed and resource utilization. The final generated automated test report uses the pre-set test case description information field in the external text configuration file to replace the original technical test case identifier for display, making the report content intuitive and readable for business personnel without technical backgrounds, and enhancing the communication efficiency of test results.

[0025] Optionally, before step 101, the method further includes: when a commit operation is detected in the code repository, starting a continuous integration pipeline, obtaining a list of change files associated with the commit operation through a change analysis script configured in the continuous integration pipeline; determining the functional module to which each file belongs based on a preset path-module mapping rule and the storage path of each file in the change file list; determining the use case identifier corresponding to each file based on a preset module-use case mapping rule and the functional module to which each file belongs; merging and deduplicating the use case identifiers corresponding to each file to generate a use case identifier set; and generating the external text configuration file based on the use case identifier set and the use case description information field corresponding to each pre-stored use case identifier field.

[0026] In this embodiment, firstly, when a developer pushes a commit to a code repository (such as GitLab or GitHub), for example, fixing the amount calculation code in the medical insurance settlement module, a pre-configured continuous integration pipeline (such as a CI pipeline) can be automatically triggered. Within this pipeline, a pre-configured change analysis script can be run. This script obtains a list of all changed files involved in the commit by executing version control commands. Taking a smart healthcare scenario as an example, if a developer modifies the code of the "electronic prescription" module, the list of changed files could include src / medical / prescription / Validator.java and src / medical / prescription / Controller.kt, etc.; in a fintech scenario, if a developer modifies the code of the "risk control rules" module, the list of changed files could include risk / aml / TransactionMonitor.java, etc. This automatically captures the scope of the code changes, providing raw data for subsequent accurate selection of test cases, completely eliminating the need for manual analysis.

[0027] Next, based on pre-defined path-module mapping rules, the storage path of each file in the change file list can be mapped to its corresponding functional module. This mapping rule can be implemented using regular expressions or string matching. For example, the rule ". / medical / prescription / ." corresponds to the "electronic prescription module," and ". / risk / aml / ." corresponds to the "anti-money laundering module." The storage path corresponding to each file in the change file list is traversed, and one or more functional modules corresponding to that file are determined based on the regular expression matching results. For example, modifying prescription / Validator.java maps to the electronic prescription module, and modifying risk / aml / TransactionMonitor.java maps to the anti-money laundering module. This elevates changes to underlying code files to the functional modules at the business level, making test case selection more closely aligned with business understanding and laying the foundation for subsequent test case mapping.

[0028] Next, using pre-configured module-test case mapping rules, each functional module is further mapped to specific test case identifiers (such as TC001, PAY005, etc.). These mapping rules can be stored in a simple JSON or YAML configuration file. For each functional module identified in the previous step, all corresponding test case identifiers are identified, and these identifiers are used as the test case identifiers for the files involved in that functional module. It's important to note that a functional module typically corresponds to multiple test cases; for example, the "electronic prescription module" can contain multiple test cases such as "prescription creation," "prescription review," and "prescription cancellation."

[0029] Furthermore, the test case identifiers obtained from all change files in the previous step are merged and deduplicated to generate a set of test case identifiers. Since multiple change files may belong to the same functional module, or multiple files under the same functional module may map to the same test case identifier, merging and deduplication can avoid duplicate test cases in the subsequently generated external text configuration file.

[0030] Based on the set of test case identifiers generated in the previous step, and the pre-stored test case description information field corresponding to each test case identifier, an external text configuration file is automatically generated. Each line of this file contains a test case identifier and its corresponding test case description information, such as "TC001, Electronic Prescription Creation Function Test" and "AML_01, Large Transaction Anti-Money Laundering Trigger Test". This file is written to the path agreed upon by the test executor for subsequent automated test start commands to read.

[0031] This application's embodiments seamlessly connect "code changes" and "test execution" through two layers of mapping rules, completely replacing the traditional manual screening or hard coding methods, and significantly reducing test maintenance costs and the probability of human error.

[0032] In this embodiment of the application, optionally, the step 103 of "determining the test case root directory corresponding to the mobile terminal to be tested" includes: reading preset global environment variables, determining the current mobile terminal operating system type to be tested based on the value of the global environment variables; selecting the test case root directory corresponding to the mobile terminal operating system type from a plurality of pre-configured platform root directories; wherein, for different mobile terminal operating system types, the same scheduling logic code is used to execute the steps of traversing the test case root directory, extracting the test case identifier, determining whether the list of test cases to be tested contains the test case identifier, and calling the automated testing framework.

[0033] In this embodiment, a preset global environment variable, for example named DEVICE, can be read first. This global environment variable can be pre-set in the continuous integration pipeline or test execution script, and its value is used to identify the type of mobile operating system currently being tested, such as DEVICE=Android or DEVICE=iOS. Reading the global environment variable is a lightweight and universal cross-platform identification method that does not rely on any hardware detection or complex system calls. For example, in a smart healthcare scenario, the same test task may need to be executed on an Android tablet used at the nurse's station and an iPhone used by the doctor. By changing the value of the global environment variable, the mobile platform being tested can be switched within the same scheduling logic. In the fintech field, regression testing of mobile payment apps needs to cover both Android and Apple phones, and this global environment variable can also be used to achieve one-click switching.

[0034] Next, based on the mobile operating system type obtained in the previous step, select the test case root directory corresponding to that mobile operating system type from the pre-configured multiple platform root directories. Pre-configuration refers to defining mapping relationships in a configuration file, for example, Android corresponds to / testcases / Android / , and iOS corresponds to / testcases / iOS / . Test scripts for different mobile platforms under test typically need to be stored separately due to differences in the underlying automation frameworks they rely on (UIAutomator for Android, XCUITest for iOS) and UI control positioning methods. It's important to note that here, the test case root directory only refers to the storage location of the test scripts; the subsequent scheduling logic (i.e., traversing folders, extracting identifiers, matching lists, and calling frameworks) remains completely unaffected. For example, when DEVICE=Android, the test case root directory / testcases / Android / is selected; when DEVICE=iOS, it automatically switches to the test case root directory / testcases / iOS / .

[0035] For different mobile operating system types, this application embodiment uses the exact same scheduling logic code to execute all subsequent steps, including traversing the test case folders under the test case root directory, extracting the test case identifier from the folder name, determining whether the identifier is in the list of test cases to be tested, and calling the automated testing framework to execute the script. That is, the scheduling code does not contain any platform-specific conditional branches (e.g., if Android then ... else...), but instead dynamically switches the test case root directory through global environment variables, and then handles subsequent operations in a unified manner. In actual implementation, the differences in the underlying framework can be encapsulated in the adapter layer through object-oriented polymorphism or dependency injection, but the scheduling control flow logic is singular and reusable. For example, in smart healthcare applications, whether verifying the patient-side APP (Android) or the doctor-side APP (iOS), testers do not need to write two sets of scheduling scripts; they only need to maintain a unified configuration file and a global environment variable switch, which can greatly reduce the maintenance cost of test scripts and avoid human errors caused by inconsistent scheduling logic between the two ends.

[0036] This application avoids the repetitive work and maintenance burden caused by writing separate scheduling scripts for Android and iOS in the traditional approach. At the same time, since the scheduling logic is completely unified, the consistency of cross-platform testing is guaranteed. Any improvement or fix at the scheduling level can benefit both platforms at the same time. Dual-end verification can be completed using the same configuration file, which significantly improves the iteration response speed and reduces resource consumption costs.

[0037] In this embodiment of the application, optionally, each record in the external text configuration file further includes a group identifier field; the step 105 of "summarizing each automated test sub-report to generate an automated test report" includes: parsing the external text configuration file to obtain the group identifier corresponding to each test case identifier; grouping and aggregating each automated test sub-report according to the group identifier, and generating a report display area containing report summary information for each group based on the automated test sub-reports contained in each group; aggregating each report display area to generate the automated test report; Accordingly, each report display area also includes a view switching icon; after "generating the automated test report", the method further includes: in response to a trigger command on the view switching icon of any report display area, switching the current display interface from displaying the automated test report to displaying a detailed list of each automated test sub-report corresponding to any report display area.

[0038] In this embodiment, before generating the automated test report, the external text configuration file can be reread to parse out the group identifier in each record, excluding the test case identifier and test case description information. The group identifier is a label used to categorize multiple related test cases, such as "smoke test," "regression test," "payment core," and "electronic prescription process." In smart healthcare applications, test cases such as "patient registration," "doctor scheduling," and "medical record retrieval" can be grouped under the identifier "registration service"; in the fintech field, test cases such as "transfer," "recharge," and "withdrawal" can be grouped under the identifier "funds transaction." After parsing, it can be determined which group each test sub-report should belong to.

[0039] Subsequently, all generated automated test sub-reports are grouped and aggregated according to their group identifiers. Automated test sub-reports belonging to the same group identifier are grouped into the same set, and then an independent report display area is generated for each group. Within this display area, summary information of each automated test sub-report within the group can be displayed, such as the test case description, execution status, execution time, and a brief description of the failure reason for each test case. For example, in a fintech test, the "Funds Transaction" group may contain three automated test sub-reports: "Transfer Successful," "Transfer Failed - Insufficient Balance," and "Recharge Callback." The report display area can show the pass status and time of these three items in a list format, instead of directly displaying dozens of lines of logs or screenshots, allowing testers to quickly understand the overall situation of the group.

[0040] Furthermore, the report display areas generated by all groups can be aggregated according to rules such as the order in which the group identifier first appears in the external text configuration file, ultimately generating a complete automated test report. The structure of this summary report can be: the top displays overall statistics (total number of test cases, pass rate, and time consumed), with the report display areas for each group arranged sequentially below. Each group's report display area is expanded by default, allowing users to directly view summary information of each test case within that group. This aggregation method makes large test reports clearly hierarchical.

[0041] When generating automated test reports, a visual interactive control—a view toggle icon—can be added to the report display area of ​​each group. This icon can use common symbols such as arrows, lists, or magnifying glasses, and can be distinguished from ordinary text headings using CSS styles. Clicking the icon triggers a front-end JavaScript event, which is bound to the logic of toggling the currently displayed content. The presence of the view toggle icon transforms the automated test report from a static information display into an interactive dashboard, allowing users to actively control the depth of their browsing.

[0042] When a user clicks the view toggle icon in a report display area, the trigger command can be captured, and the current display interface can be dynamically switched from a complete automated test report to a detailed list of only the automated test sub-reports corresponding to that group. Unlike the previous summary information, the detailed list displays all the details of each automated test sub-report, including complete execution logs, screenshots of each operation step, specific assertion values, stack traces for failures, etc. After switching, the current display interface can hide the report display areas of other groups, or present the detailed list of the current group as a pop-up window or a separate page. Users can return to the automated test report at any time. This interaction mode greatly improves the efficiency of troubleshooting.

[0043] This application's embodiments upgrade traditional linear test reports into hierarchical, interactive intelligent reports by introducing group identifier fields and view switching icons. This retains the flexibility of external text configuration file-driven execution while enhancing the readability and traceability of test results.

[0044] In the embodiments of this application, optionally, as shown... Figure 3 As shown, after step 105, the method further includes: Step 106: When there is a failed test script in the automated test report, parse the execution log of the failed test script and extract exception stack information and error keywords from the execution log.

[0045] Step 107: Parse the corresponding source code file path and line number from the exception stack information, and obtain the submitter information and submission time of the source code file through version control commands.

[0046] Step 108: Based on the error keywords, match similar historical faults and corresponding fault solutions from a pre-built knowledge base.

[0047] Step 109: Generate a root cause analysis report for the failed test script based on the source code file path, the line number, the submitter information, the submission time, the similar historical failures, and the failure solutions, and add the root cause analysis report to the automated test report.

[0048] In this embodiment, firstly, after completing automated testing and generating an automated test report containing test case descriptions, it can be checked whether there are test scripts with a "failed" status in the report. If a failed script exists, its corresponding execution log can be automatically located. Then, the execution log is structured and parsed to extract key exception stack traces and error keywords (such as NullPointerException, ConnectionTimeout, and a 500 error returned by the medical insurance interface). The exception stack trace can be a text record of a series of method call chains, showing which line of code the program was executing when the error occurred; the error keywords are brief descriptions of the error type or business error codes. In a smart healthcare scenario, if the "electronic prescription upload" test case fails, the execution log can extract the exception stack trace and the keyword "invalid drug code".

[0049] Next, the corresponding source code file path and line number are further parsed from the extracted exception stack trace. Since exception stack traces in modern programming languages ​​(such as Java, Kotlin, and Swift) typically contain precise filename and line number information (e.g., "PrescriptionService.java:147"), these fragments can be extracted using regular expressions. After obtaining the source code file path and line number, version control commands can be invoked to query the last modification details of that line of code, including the committer's name (e.g., "Zhang San") and the commit time (e.g., "2025-03-15 14:23:05"). This allows test failures to be directly anchored to specific code changes and responsible parties, eliminating the need for manual review of version history. In the fintech field, if a "large-amount risk control verification" test case fails, it can quickly pinpoint a risk control rule configuration line modified by a developer two days prior, thereby accelerating the process of identifying and fixing the issue.

[0050] Furthermore, the extracted error keywords are used for matching and retrieval in a pre-built knowledge base. This knowledge base can be a database or text index that stores various past test failures and their corresponding solutions. Each record includes failure characteristics (error keywords, stack fingerprint) and solutions (e.g., "Invalid drug code: Call the basic data interface to refresh the cache" or "SWIFT timeout: Check the IP whitelist of the cross-border gateway sandbox environment"). Historical failures most similar to the current error keywords are found through fuzzy or exact matching, and successful solutions for those records are returned. If the failure is not yet included in the knowledge base, general suggestions (such as "Check network configuration") can be provided based on rules.

[0051] Finally, the information from these multiple dimensions is integrated to generate a separate root cause analysis report, which is then added to the existing automated test report. The root cause analysis report may include: the name and description of the failed test case, the path and line number of the located source code file, the name and submission time of the submitter for that line of code, descriptions of similar historical failures found in the knowledge base, and suggested solutions. The root cause analysis report can be displayed in the automated test report as a collapsed section, a pop-up window, or a sidebar.

[0052] This application embodiment deeply integrates test failure analysis with code repositories and historical knowledge bases, automatically completing the entire chain of root cause tracing from "discovering failures" to "locating code lines" and then to "recommending solutions." It automates all the tedious work that originally required manually reviewing logs, searching for commit records, and recalling similar issues, significantly shortening the time developers spend troubleshooting failed test cases.

[0053] Optionally, in this embodiment, the external text configuration file further includes a priority field and an execution weight field corresponding to each test case identifier; before step 104, the method further includes: reading the historical test database to obtain historical execution data corresponding to each test case to be executed indicated by the test case identifier in the list of test cases to be tested, wherein the historical execution data includes at least one of the average execution time, failure rate, and most recent execution status of the test case to be executed in the past preset number of executions; parsing the external text configuration file to obtain the priority field and execution weight field corresponding to each test case identifier, dynamically calculating the scheduling score of each test case to be executed based on the priority field, the execution weight field, and the historical execution data; sorting the test case identifiers of each test case to be executed in descending order of the scheduling score to generate a first scheduling queue, and sequentially calling the automated testing framework to execute the test script corresponding to the test case identifier based on the order of each test case identifier in the first scheduling queue.

[0054] In this embodiment, before executing specific test scripts using the automated testing framework, the historical test database is first read. This database persistently stores metadata generated by each test execution, such as the execution time of the last N executions of each test case, pass / fail status, and a summary of the failure reason. The list of test cases is read, and then, for each test case identifier in the list, historical execution data for that test case in the past preset number of executions (e.g., the last 10) is queried from the historical test database. The historical execution data includes at least the average execution time (the total execution time of the test case divided by the number of executions), the failure rate (the proportion of failures to the total number of executions), and the most recent execution status (pass or failure). In the smart healthcare scenario, for the "electronic prescription signature" test case, the historical execution data might show an average execution time of 12 seconds, a failure rate of 15%, and a most recent execution failure; in the fintech field, the historical execution data for the "large-amount transfer facial recognition" test case might show an average execution time of 8 seconds, a failure rate of 2%, and a most recent successful execution. This historical execution data reflects the behavioral characteristics of each test case, providing a quantitative basis for subsequent intelligent scheduling.

[0055] Next, the external text configuration file is parsed to obtain two additional fields corresponding to each test case identifier: a priority field and an execution weight field. The priority field can be preset by the test designer based on business importance, such as P0 (highest), P1, P2; the execution weight field can be a numerical value used to represent the importance of the test case in the current test task, and can be dynamically adjusted in combination with priority and temporary strategies. Then, based on the priority field, execution weight field, and historical execution data obtained in the previous step, the scheduling score of each test case to be executed is dynamically calculated according to a preset algorithm.

[0056] Finally, based on the scheduling score calculated for each test case to be executed, they are sorted from highest to lowest to generate the first scheduling queue. This queue determines the actual execution order of the test scripts: the test cases with the highest scores are executed first, and the test cases with the lowest scores are executed last. Subsequently, test case identifiers are retrieved from the first scheduling queue in sequence, and the corresponding test scripts are executed by calling the automated testing framework. In some scenarios, if the continuous integration pipeline has a strict time budget (e.g., requiring all tests to be completed within 30 minutes), the first scheduling queue can be truncated based on the scheduling score, executing only the top K test cases by score, and recording the unexecuted test cases for manual review. This dynamic sorting and intelligent scheduling mechanism allows limited testing resources to be prioritized for the most important, most prone to failure, and most in need of rapid feedback testing tasks.

[0057] This application integrates static configuration (priority, execution weight) and dynamic historical data (average execution time, failure rate) to intelligently determine the execution order of test cases, breaking through the traditional fixed-order scheduling mode. It can adaptively prioritize the execution of high-value, high-risk, and high-failure-probability test cases, thereby maximizing the possibility of discovering problems and feedback efficiency within a limited time window, while reducing the risk of key defects being discovered late due to unreasonable test order.

[0058] Optionally, before step 101, the method further includes: constructing a test case dependency graph, wherein the nodes in the test case dependency graph are test case identifiers, and the directed edges represent the test case dependency relationship between two connected test cases, and the test case dependency relationship includes the dependency relationship that the second test case is executed before the first test case is executed; Accordingly, after step 103, the method further includes: if the test case identifier is included, adding the test case identifier to the set of test case identifiers to be tested; after all test case folders have been traversed, determining whether the set of test case identifiers to be tested contains downstream nodes in the dependency graph based on the test case dependency graph; if downstream nodes in the dependency graph are included, adding the test case identifiers indicated by all upstream nodes directly or indirectly dependent on the downstream nodes to the set of test case identifiers to be tested, thus obtaining an expanded set of test case identifiers to be tested; sorting the test case identifiers in the expanded set of test case identifiers to be tested according to the topological order of the dependency relationship to generate a second scheduling queue; and sequentially calling the automated testing framework to execute the test scripts corresponding to each test case identifier in the second scheduling queue.

[0059] In this embodiment, firstly, a use case dependency graph can be pre-constructed before executing any test task. This graph is a directed graph, where each node represents a use case identifier (such as TC001, PAY_003) for a test case, and the directed edges in the graph represent the dependencies between two test cases. Specifically, if use case B must be executed before use case A, a directed edge is added to the graph from B to A (or from A to B, which can be uniformly agreed upon), defining "the first use case depends on the second use case" as an edge pointing from the second use case to the first use case. For example, in smart healthcare applications, the "complete online consultation process" use case depends on two prerequisite use cases: "patient login" and "doctor scheduling query"; in the fintech field, the "cross-border remittance" use case depends on two basic use cases: "sufficient account balance" and "currency exchange rate acquisition". The dependency graph can be constructed by manually writing configuration files or automatically generated through static code analysis.

[0060] When traversing the root directory of test cases and determining whether the test case identifier of each test case folder belongs to the list of test cases to be tested, once a test case identifier is found to exist in the list of test cases to be tested, that test case identifier can be immediately added to the set of test case identifiers to be tested. The set of test case identifiers to be tested is initially empty, and as the traversal process progresses, all test case identifiers explicitly selected by the user (or change analysis script) are gradually collected.

[0061] After traversing all test case folders, a set of unexpanded test case identifiers is obtained. Next, this set is expanded using a closure model based on a pre-built test case dependency graph. Specifically, each test case identifier in the set is traversed, and it is determined whether that identifier has other test cases it depends on in the dependency graph (i.e., whether there are incoming edges pointing to it, or whether it, as a downstream node, depends on an upstream node). If a test case identifier is included in the set and that identifier depends on another test case identifier in the graph, then the dependent upstream node is also added to the set; otherwise, directly executing the former will fail due to a lack of preconditions. This process is recursively executed until no more test case identifiers are added, ultimately resulting in the expanded set of test case identifiers.

[0062] After obtaining the expanded set of test case identifiers, the execution order of these test cases is further determined. Due to dependencies (e.g., "login" must be executed before "transfer"), the test case identifiers can be sorted according to the topological order of dependencies, generating a second scheduling queue. Topological sorting is a sorting algorithm for directed acyclic graphs (DAGs) that guarantees that for each directed edge U→V (meaning U depends on V, or V depends on U), U appears before (or after) V in the sorting result. Generally, the dependent test case (upstream) is listed first, and the dependent test cases (downstream) are listed later. This second scheduling queue ensures that when executed sequentially, the preconditions required for each test case have been prepared by the previously executed test cases.

[0063] Finally, following the order of the test case identifiers in the second scheduling queue, the automated testing framework executes the test scripts corresponding to each test case sequentially. Since the second scheduling queue already satisfies all dependencies, execution will not fail due to missing prerequisites or improper ordering. Compared to traditional "manual user sorting" or "random execution," this approach significantly improves the success rate and reliability of testing.

[0064] This application embodiment achieves automatic completion and intelligent sorting of test cases through an explicit dependency graph, which completely solves the problem of execution failure caused by missing preceding test cases in traditional on-demand execution. This method automatically fills in path dependencies, significantly reducing the complexity of writing and maintaining test scripts.

[0065] Furthermore, as Figure 2 To specifically implement the method, this application provides a mobile terminal automated testing device, such as... Figure 4 As shown, the device includes: The file acquisition module is used to acquire a pre-created external text configuration file in response to an automated test start command. Each record in the external text configuration file contains a test case identifier field and a test case description information field. The file parsing module is used to parse the external text configuration file to obtain a list of test cases consisting of the test case identifier field of each record; The judgment module is used to determine the root directory of the test cases corresponding to the mobile terminal to be tested, traverse all test case folders under the root directory of the test cases, extract the test case identifier from the name of each test case folder, and determine whether the test case identifier is contained in the list of test cases to be tested. The test script execution module is used to, if the test case identifier is included, call the automated testing framework to execute the test script in the test case folder and generate an automated test sub-report containing the test case identifier based on the execution result; otherwise, skip the test case folder. The report generation module is used to summarize the automated test sub-reports and generate an automated test report after all test case folders have been traversed. In the automated test report, the test case description information field corresponding to the test case identifier field in the external text configuration file is used to replace the originally displayed test case identifier.

[0066] Optionally, the apparatus further includes a file generation module; the file generation module is used for: Before obtaining the pre-created external text configuration file in response to the automated test start command, when a commit operation is detected in the code repository, the continuous integration pipeline is started, and the list of change files associated with this commit operation is obtained through the change analysis script configured in the continuous integration pipeline. Based on the preset path-module mapping rules and the storage path of each file in the changed file list, the functional module to which each file belongs is determined. Based on the preset module-use case mapping rules and the functional module to which each file belongs, determine the use case identifier corresponding to each file; Merge and deduplicate the test case identifiers corresponding to each file to generate a set of test case identifiers; The external text configuration file is generated based on the set of use case identifiers and the use case description information field corresponding to each pre-stored use case identifier field.

[0067] Optionally, the determination module is used to: Read the preset global environment variables, and determine the current mobile operating system type to be tested based on the values ​​of the global environment variables; Select the test case root directory corresponding to the mobile operating system type from the pre-configured multiple platform root directories; For different mobile operating system types, the same scheduling logic code is used to execute the steps of traversing the root directory of test cases, extracting test case identifiers, determining whether the list of test cases to be tested contains the test case identifiers, and calling the automated testing framework.

[0068] Optionally, each record in the external text configuration file further includes a group identifier field; the report generation module is used to: Parse the external text configuration file to obtain the group identifier corresponding to each use case identifier; The automated test sub-reports are grouped and aggregated according to the group identifier, and a report display area containing report summary information is generated for each group based on the automated test sub-reports contained in each group. The various report display areas are aggregated to generate the automated test report; Accordingly, each report display area also includes a view switching icon; the device also includes a view switching module; the view switching module is used for: After the automated test report is generated, in response to the trigger command of the view switching icon of any report display area, the current display interface is switched from displaying the automated test report to displaying a detailed list of each automated test sub-report corresponding to any report display area.

[0069] Optionally, the apparatus further includes a root cause report generation module; the root cause report generation module is configured to: After replacing the originally displayed test case identifier, when there is a failed test script in the automated test report, the execution log of the failed test script is parsed, and exception stack information and error keywords are extracted from the execution log; The corresponding source code file path and line number are parsed from the exception stack information, and the submitter information and submission time of the source code file are obtained through version control commands; Based on the error keywords, similar historical faults and corresponding fault solutions are matched from a pre-built knowledge base; Based on the source code file path, the line number, the submitter information, the submission time, the similar historical failures, and the failure solutions, a root cause analysis report is generated for the failed test script, and the root cause analysis report is added to the automated test report.

[0070] Optionally, the external text configuration file further includes a priority field and an execution weight field corresponding to each use case identifier; the device further includes a sorting module; the sorting module is used for: Before the automated testing framework is invoked to execute the test scripts in the test case folder, the historical test database is read to obtain the historical execution data corresponding to each test case to be executed indicated by the test case identifier in the list of test cases to be tested. The historical execution data includes at least one of the following: the average execution time, failure rate, and most recent execution status of the test case to be executed in the past preset number of executions. The external text configuration file is parsed to obtain the priority field and execution weight field corresponding to each test case identifier. Based on the priority field, the execution weight field and the historical execution data, the scheduling score of each test case to be executed is dynamically calculated. According to the scheduling scores from high to low, the test case identifiers of each test case to be executed are sorted to generate a first scheduling queue. Based on the order of the test case identifiers in the first scheduling queue, the automated testing framework is called sequentially to execute the test scripts corresponding to the test case identifiers.

[0071] Optionally, the apparatus further includes a relationship graph construction module; the relationship graph construction module is used for: Before obtaining the pre-created external text configuration file, a test case dependency graph is constructed. In the test case dependency graph, the nodes are test case identifiers, and the directed edges represent the test case dependency relationships between two connected test cases. The test case dependency relationships include the dependency relationship that the second test case is executed before the first test case is executed. Accordingly, the test script execution module is further configured to: After determining whether the test case identifier is included in the list of test cases to be tested, if the test case identifier is included, the test case identifier is added to the set of test case identifiers. After all test case folders have been traversed, based on the test case dependency graph, it is determined whether the test case identifier set contains downstream nodes in the dependency graph. If it contains downstream nodes in the dependency graph, the test case identifiers indicated by all upstream nodes that the downstream nodes directly or indirectly depend on are added to the test case identifier set to obtain the expanded test case identifier set. The test case identifiers in the expanded set of test case identifiers are sorted according to the topological order of the dependencies to generate a second scheduling queue; The automated testing framework is invoked sequentially to execute the test scripts corresponding to each test case identifier in the second scheduling queue.

[0072] It should be noted that other corresponding descriptions of the functional units involved in the mobile terminal automated testing device provided in this application embodiment can be found by referring to... Figures 2 to 3 The corresponding descriptions in the method will not be repeated here.

[0073] This application also provides a computer device, which may specifically be a personal computer, a server, a network device, etc. Figure 5 As shown, the computer device includes a bus, a processor, memory, and a communication interface, and may also include an input / output interface and a display device. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores location information. The network interface allows communication with external terminals via a network connection. When the computer program is executed by the processor, it implements the steps in the various method embodiments.

[0074] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0075] In one embodiment, a computer-readable storage medium is provided, which may be non-volatile or volatile, having stored thereon a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0076] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0077] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0078] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0079] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0080] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0081] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A mobile terminal automated testing method, characterized in that, include: In response to the automated test start command, a pre-created external text configuration file is obtained, wherein each record in the external text configuration file contains a test case identifier field and a test case description information field; Parse the external text configuration file to obtain a list of test cases consisting of the test case identifier field of each record; Determine the root directory of the test cases corresponding to the mobile device to be tested, traverse all test case folders under the root directory, extract the test case identifier from the name of each test case folder, and determine whether the test case identifier is contained in the list of test cases to be tested. If the test case identifier is included, the automated testing framework is invoked to execute the test script in the test case folder, and an automated test sub-report containing the test case identifier is generated based on the execution result; otherwise, the test case folder is skipped. After all test case folders have been traversed, the automated test reports are compiled to generate an automated test report. In the automated test report, the test case description information field corresponding to the test case identifier field in the external text configuration file is used to replace the originally displayed test case identifier.

2. The method according to claim 1, characterized in that, Before retrieving the pre-created external text configuration file in response to the automated test start command, the method further includes: When a commit operation is detected in the code repository, the continuous integration pipeline is started, and the list of change files associated with this commit operation is obtained through the change analysis script configured in the continuous integration pipeline. Based on the preset path-module mapping rules and the storage path of each file in the changed file list, the functional module to which each file belongs is determined. Based on the preset module-use case mapping rules and the functional module to which each file belongs, determine the use case identifier corresponding to each file; Merge and deduplicate the test case identifiers corresponding to each file to generate a set of test case identifiers; The external text configuration file is generated based on the set of use case identifiers and the use case description information field corresponding to each pre-stored use case identifier field.

3. The method according to claim 1 or 2, characterized in that, The step of determining the root directory of the test cases corresponding to the mobile device to be tested includes: Read the preset global environment variables, and determine the current mobile operating system type to be tested based on the values ​​of the global environment variables; Select the test case root directory corresponding to the mobile operating system type from the pre-configured multiple platform root directories; For different mobile operating system types, the same scheduling logic code is used to execute the steps of traversing the root directory of test cases, extracting test case identifiers, determining whether the list of test cases to be tested contains the test case identifiers, and calling the automated testing framework.

4. The method according to claim 1, characterized in that, Each record in the external text configuration file also includes a group identifier field; the process of summarizing the various automated test sub-reports to generate an automated test report includes: Parse the external text configuration file to obtain the group identifier corresponding to each use case identifier; The automated test sub-reports are grouped and aggregated according to the group identifier, and a report display area containing report summary information is generated for each group based on the automated test sub-reports contained in each group. The various report display areas are aggregated to generate the automated test report; Accordingly, each report display area also includes a view switching icon; after generating the automated test report, the method further includes: In response to a trigger command on the view switching icon of any report display area, the current display interface is switched from displaying the automated test report to displaying a detailed list of each automated test sub-report corresponding to any report display area.

5. The method according to claim 1, characterized in that, After replacing the originally displayed use case identifier, the method further includes: When a failed test script is found in the automated test report, the execution log of the failed test script is parsed, and exception stack information and error keywords are extracted from the execution log. The corresponding source code file path and line number are parsed from the exception stack information, and the submitter information and submission time of the source code file are obtained through version control commands; Based on the error keywords, similar historical faults and corresponding fault solutions are matched from a pre-built knowledge base; Based on the source code file path, line number, submitter information, submission time, similar historical failures, and failure solutions, a root cause analysis report is generated for the failed test script, and the root cause analysis report is added to the automated test report.

6. The method according to claim 1, characterized in that, The external text configuration file also includes a priority field and an execution weight field corresponding to each test case identifier; before calling the automated testing framework to execute the test scripts in the test case folder, the method further includes: Read the historical test database and obtain the historical execution data corresponding to each test case to be executed indicated by the test case identifier in the list of test cases to be tested. The historical execution data includes at least one of the following: the average execution time, failure rate, and most recent execution status of the test case to be executed in the past preset number of executions. The external text configuration file is parsed to obtain the priority field and execution weight field corresponding to each test case identifier. Based on the priority field, the execution weight field and the historical execution data, the scheduling score of each test case to be executed is dynamically calculated. According to the scheduling scores from high to low, the test case identifiers of each test case to be executed are sorted to generate a first scheduling queue. Based on the order of the test case identifiers in the first scheduling queue, the automated testing framework is called sequentially to execute the test scripts corresponding to the test case identifiers.

7. The method according to claim 1, characterized in that, Before obtaining the pre-created external text configuration file, the method further includes: Construct a test case dependency graph, wherein the nodes in the test case dependency graph are test case identifiers, and the directed edges represent the test case dependency relationship between two connected test cases. The test case dependency relationship includes the dependency relationship that the second test case is executed before the first test case is executed. Accordingly, after determining whether the test case identifier is included in the list of test cases to be tested, the method further includes: If the test case identifier is included, then the test case identifier is added to the set of test case identifiers; After all test case folders have been traversed, based on the test case dependency graph, it is determined whether the test case identifier set contains downstream nodes in the dependency graph. If it contains downstream nodes in the dependency graph, the test case identifiers indicated by all upstream nodes that the downstream nodes directly or indirectly depend on are added to the test case identifier set to obtain the expanded test case identifier set. The test case identifiers in the expanded set of test case identifiers are sorted according to the topological order of the dependencies to generate a second scheduling queue; The automated testing framework is invoked sequentially to execute the test scripts corresponding to each test case identifier in the second scheduling queue.

8. A mobile terminal automated testing device, characterized in that, include: The file acquisition module is used to acquire a pre-created external text configuration file in response to an automated test start command. Each record in the external text configuration file contains a test case identifier field and a test case description information field. The file parsing module is used to parse the external text configuration file to obtain a list of test cases consisting of the test case identifier field of each record; The judgment module is used to determine the root directory of the test cases corresponding to the mobile terminal to be tested, traverse all test case folders under the root directory of the test cases, extract the test case identifier from the name of each test case folder, and determine whether the test case identifier is contained in the list of test cases to be tested. The test script execution module is used to, if the test case identifier is included, call the automated testing framework to execute the test script in the test case folder and generate an automated test sub-report containing the test case identifier based on the execution result; otherwise, skip the test case folder. The report generation module is used to summarize the automated test sub-reports and generate an automated test report after all test case folders have been traversed. In the automated test report, the test case description information field corresponding to the test case identifier field in the external text configuration file is used to replace the originally displayed test case identifier.

9. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

10. A computer device, comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 7.

Images