Software model testing method and device, storage medium and electronic device

Abstract

The application discloses a software model testing method and device, a storage medium and an electronic device, and relates to the technical field of software testing. The software model testing method comprises the following steps: determining a target test model in a target software system; acquiring a model test case matched with the target test model; calling the target test model according to the model test case, and obtaining target test data output by the target test model; and marking a test result of the model test case according to the target test data. The technical scheme of the embodiment of the application can realize efficient and accurate automatic model testing, and provides reliable guarantee for the stability of a software system.

Description

Technical Field

[0001] This application relates to the field of software testing, and more specifically, to a software model testing method, apparatus, storage medium, and electronic device. Background Technology

[0002] With the rapid development of software technology, the iteration and update speed of models is showing an exponential growth trend, highlighting the importance of model testing in software testing. Existing technologies have many problems in the testing phase after model switching, with the core process still heavily reliant on manual operation: test engineers need to manually select and trigger test cases after model switching, then execute the tests using tools, compare the new model output with the expected results, and subsequently manually annotate the test case status and generate test reports based on templates. This model has significant limitations, not only because manual triggering causes delays due to the inability to respond to model switching in real time, but also because manual annotation is inefficient, subjective, and prone to errors. Therefore, traditional testing methods are no longer suitable for the current high-frequency update pace of models and cannot meet the core requirements of quickly verifying the performance of new models and ensuring system stability. Summary of the Invention

[0003] This application provides a software model testing method, apparatus, storage medium, and electronic device, with the aim of achieving efficient and accurate automated model testing and providing reliable assurance for the stability of software systems.

[0004] According to one aspect of the embodiments of this application, a software model testing method is provided, comprising: Determine the target test model for the target software system; Obtain model test cases that match the target test model; The target test model is invoked based on the model test cases to obtain the target test data output by the target test model; Based on the target test data, the test results of the model test cases are labeled.

[0005] In an optional implementation, determining the target test model in the target software system includes: Monitor the state changes of the test object model in the target software system; When a change in the model state of the test object model is detected, the target test model is obtained from the model change result of the change in the model state.

[0006] In an optional implementation, the step of labeling the test results of the model test cases based on the target test data includes: Obtain comparison data of the results matching the test cases of the model; The target test data and the result comparison data are compared to obtain the data comparison results. Generate use case annotation data based on the data comparison results; The test results are labeled for the model test cases based on the test case labeling data.

[0007] In an optional implementation, obtaining the comparison data matching the model test cases includes: Retrieve the expected output data and historical result data corresponding to the test cases of the model from the test case storage space; The expected output data and the historical result data are respectively determined as the result comparison data.

[0008] In an optional implementation, after labeling the model test cases with the test results based on the test case labeling data, the method further includes: In the use case storage space, the historical result data is updated to the target test data.

[0009] In an optional implementation, generating use case annotation data based on the data comparison results includes: Test result annotation data is generated based on the data comparison results between the target test data and the expected output data. Model difference annotation data is generated based on the data comparison results between the target test data and the historical result data. The test result annotation data and the model difference annotation data are determined as the test case annotation data.

[0010] In an optional implementation, after labeling the model test cases with test results based on the target test data, the method further includes: Based on the model test cases and the target test data, generate test coverage data, pass rate data, failed test case details data, and model difference data; A visual test report is generated based on the test coverage data, the pass rate data, the failed test case details data, and the model difference data.

[0011] According to another aspect of the embodiments of this application, a software model testing apparatus is provided, comprising: The model determination module is used to determine the target test model in the target software system; The test case acquisition module is used to acquire model test cases that match the target test model; The model invocation module is used to invoke the target test model according to the model test cases and obtain the target test data output by the target test model. The result annotation module is used to annotate the test results of the model test cases based on the target test data.

[0012] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored program, wherein the program executes the software model testing method provided in any embodiment of the present invention when it is run.

[0013] According to another aspect of the present application, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the software model testing method provided in any embodiment of the present invention through the computer program.

[0014] This application provides a software model testing method, apparatus, storage medium, and electronic device. By determining the target test model in the target software system, obtaining model test cases that match the target test model, and calling the target test model according to the model test cases, the target test data output by the target test model is obtained. The test results of the model test cases are then labeled according to the target test data. This solves the problems of low efficiency and low reliability caused by relying on manual execution of model functional testing after software model updates in the prior art. It realizes efficient and accurate automated model testing, providing a reliable guarantee for the stability of the software system. Attached Figure Description

[0015] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a schematic diagram of the hardware environment for an interaction method of a smart device according to an embodiment of this application; Figure 2 This is a flowchart of a software model testing method provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a software model testing device provided in an embodiment of the present invention; Figure 4This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0018] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0019] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0020] According to one aspect of the embodiments of this application, a software model testing method is provided. This software model testing method is widely applicable to whole-house intelligent digital control application scenarios such as smart homes, smart home ecosystems, and intelligence house ecosystems. Optionally, in this embodiment, the above-mentioned software model testing method can be applied to, for example... Figure 1 The hardware environment shown consists of terminal device 102 and server 104. For example... Figure 1 As shown, server 104 is connected to terminal device 102 via a network and can be used to provide services (such as application services) to the terminal or clients installed on the terminal. A database can be set up on the server or independently of the server to provide data storage services for server 104. Cloud computing and / or edge computing services can be configured on the server or independently of the server to provide data processing services for server 104.

[0021] The aforementioned network may include, but is not limited to, at least one of the following: wired network, wireless network. The aforementioned wired network may include, but is not limited to, at least one of the following: wide area network, metropolitan area network, local area network. The aforementioned wireless network may include, but is not limited to, at least one of the following: Wi-Fi (Wireless Fidelity), Bluetooth. The terminal device 102 may not be limited to PC, mobile phone, tablet computer, smart air conditioner, smart range hood, smart refrigerator, smart oven, smart stove, smart washing machine, smart water heater, smart washing equipment, smart dishwasher, smart projector, smart TV, smart clothes rack, smart curtains, smart audio-visual equipment, smart socket, smart speaker, smart speaker box, smart fresh air equipment, smart kitchen and bathroom equipment, smart bathroom equipment, smart robot vacuum cleaner, smart window cleaning robot, smart mopping robot, smart air purifier, smart steam oven, smart microwave oven, smart water heater, smart air purifier, smart water dispenser, smart door lock, etc.

[0022] This embodiment provides a software model testing method, which is applied to test the model functionality in a software system. Figure 2 A flowchart of a software model testing method provided in an embodiment of the present invention includes the following steps: Step 210: Determine the target test model in the target software system.

[0023] The target software system can refer to any type of software system in the current operating environment that relies on the model to implement core or auxiliary functions and requires model functional testing to ensure stable system operation. Examples include application systems for end users, platform systems for developers, or embedded systems. The target test model can be a model within the target software system that requires functional testing.

[0024] Specifically, the target software system may deploy at least one model, which may include artificial intelligence models and / or algorithm models, etc. These models collectively support the implementation of various functions of the system. Therefore, it is necessary to ensure that the functions of each model can be implemented normally through model functional testing, thereby ensuring the overall stability of the target software system. Depending on the functional type, importance, and whether the models have changed, the target test models may include some or all of the models in the target software system.

[0025] Typically, target test models in a target software system can include newly added models. These models are deployed to the target software system for the first time, and their functionality must be verified through testing to ensure they meet design requirements and are compatible with other modules. Therefore, they can be identified as target test models. Target test models can also include new models that replace existing models. When an existing model in the system is replaced by a new model due to performance optimization, functional upgrades, or business changes, the new model must not only meet its own functional requirements but also ensure its output is compatible with the original model. Therefore, it can be identified as a target test model for testing. Target test models can also include updated models in the target software system. These models typically refer to models whose internal parameters, algorithm logic, etc., have undergone iterative upgrades. These changes may lead to changes in model functionality and / or performance, as well as incompatibility issues with the system. Therefore, they can be identified as target test models for testing. Functional testing of models can usually be performed after the model's initial deployment or update. Therefore, the target test models that currently require functional testing in the target software system can be determined accordingly. This embodiment can accurately identify the target test model that needs to be functionally tested in the target software system based on this triggering logic, ensuring the timeliness and relevance of the testing work.

[0026] In one optional implementation, determining the target test model in the target software system may include: monitoring the state changes of the test object model in the target software system; and, when a state change of the test object model is detected, obtaining the target test model from the model change results of the state change.

[0027] The test object model can include models within the target software system that may be replaced, added, and / or updated, or locations where models can be deployed. State change monitoring can be the real-time detection of whether the test object model has undergone replacement, addition, or update. Model state changes can include model replacement, addition, or update. Model change results can be the outcome of model replacement, addition, or update.

[0028] Specifically, the test object model can include all or part of the models in the target software system, or locations where models can be deployed. Its definition can be based on a comprehensive assessment of factors such as the model's functional importance within the system, update frequency, and scope of business impact, to ensure the targeted nature and efficiency of status monitoring. For example, optionally, the target software system may include models used to implement core system functions. Changes to these models directly affect system stability, and functional abnormalities could trigger serious system problems. Therefore, functional testing needs to be performed immediately after any addition, replacement, or update. In this case, these models can be identified as test object models for real-time monitoring. The target software system may also include models for non-core functions. Changes to these models have a smaller impact on system stability and overall functionality, and the testing cost is higher. In this case, functional testing can be performed only when the model is needed, and these models may not be included in the test object model.

[0029] Furthermore, monitoring state changes across all test object models allows for timely detection of any model state changes, identifying the target test model with functional testing requirements. Specifically, state change monitoring can be performed on test object models across dimensions such as model version, deployment information, parameter configuration, functional description, and dependencies to accurately determine whether a substantial change has occurred. The model change result refers to the final state of the model after additions, replacements, or updates. Once a model completes its addition, replacement, or configuration update, a model change result is generated. At this point, the model that has been added, replaced, or updated within the model change result can be automatically identified as the target test model, initiating the subsequent testing process.

[0030] The above implementation method enables real-time response in the testing process. No manual intervention is required after model changes; the system can promptly detect changes, identify the target test model, and automatically trigger the testing process. This solves the latency problem of traditional manual testing, ensuring timely verification of new models before deployment. Furthermore, it eliminates the need for test engineers to manually select and determine test models, reducing repetitive manual operations and avoiding errors in target test model identification due to human judgment, thus improving the reliability of the testing process. It is particularly suitable for AI-driven systems containing a large number of deep learning and machine learning models with high model iteration frequencies, requiring rapid verification of the functional effectiveness after model changes to ensure the stability of the system's intelligent decision-making capabilities. It is also suitable for machine learning platforms that support simultaneous deployment and updating of models by multiple users, with diverse model types and a large number of models, where manual tracking of all model changes is difficult and inefficient; automated target test model identification significantly improves the platform's test management efficiency. Finally, it is suitable for natural language processing systems, where models frequently iterate due to corpus updates and algorithm optimizations, requiring real-time monitoring of model changes and initiation of tests to ensure the accuracy and fluency of language processing.

[0031] Step 220: Obtain model test cases that match the target test model.

[0032] Among them, model test cases can be executable verification schemes that include the required input data and expected results, designed to verify whether the function of the model can be implemented normally.

[0033] Specifically, model test cases can be pre-designed based on the expected model functions in the target software system. This involves transforming the functional requirements of the model into quantifiable and executable test scenarios. By inputting specific data and comparing the output results with the expected results, it can be determined whether the model functions as expected. Once the target test model is determined, one or more model test cases matching the functions required by the target test model can be automatically obtained.

[0034] In one optional implementation, model test cases can be pre-designed and stored in a preset test case management module; further optionally, the stored model test cases may include test case content such as input data and expected results required for testing, and may also include test results of functional testing using the model test cases after each model change, which are stored as annotation information for the model test cases.

[0035] Step 230: Call the target test model according to the model test cases to obtain the target test data output by the target test model.

[0036] The target test data can be the actual output data of the target test model after it executes the corresponding function according to the model test cases.

[0037] Calling the target test model based on the model test cases is a crucial step in achieving test automation, ensuring that the model accurately receives input data and outputs target test data. Specifically, based on the model test cases, pre-defined input data can be fed into the target test model, causing it to output target test data based on its own functionality. This target test data can then be compared with the expected output results in the model test cases, reflecting the current functional implementation status of the target test model. Calling the target test model based on the model test cases may also include configuration processes such as API calls and environment settings.

[0038] Optionally, the target test model can be invoked based on the model test cases to obtain the target test data output by the target test model. This may include deleting the model output data left by the historical tests in the acceptance environment and invoking the new target test model to regenerate the target test data.

[0039] Step 240: Based on the target test data, label the test results for the model test cases.

[0040] Among them, test result labeling can be based on the obtained target test data to determine the result of functional testing of the target test model using model test cases, and then label the result in the operation of the model test case.

[0041] Specifically, based on the current functional implementation status of the target test model as reflected in the target test data, the test result can be determined. For example, if the target test data shows that the target test model's functionality can be implemented as expected, then the model test cases can be labeled with test success results; conversely, test cases can be labeled with test failure results. Alternatively, the specific functional status of the target test model as reflected in the target test data can be labeled on the corresponding model test cases. Through test result labeling, the execution status of test cases can be clearly and accurately recorded, providing a basis for test result analysis, model quality assessment, and defect localization.

[0042] In one optional implementation, labeling the model test cases with test results based on the target test data may include: obtaining result comparison data that matches the model test cases; comparing the target test data with the result comparison data to obtain the data comparison results; generating test case annotation data based on the data comparison results; and labeling the model test cases with test results based on the test case annotation data.

[0043] The result comparison data can be the output when a model responds to input data in a model test case based on a pre-defined specific model function. Result data comparison can be an operation that compares the target test data with the model output described by the result comparison data. The resulting data comparison results can describe the consistency and / or differences between the target test data and the model output described by the result comparison data. Test case annotation data can be data annotated on the model test cases to describe the test results corresponding to the data comparison results.

[0044] Specifically, target test data is the result of the target test model responding to the input data in the model test cases based on its actual functions and outputting the results. By comparing the target test data with the result comparison data, the test results reflected by the target test data can be determined using the obtained data comparison results, thereby generating corresponding test case annotation data for test result annotation.

[0045] In one optional implementation, obtaining the result comparison data that matches the model test cases may include: obtaining the expected output data and historical result data stored in the test case storage space that correspond to the model test cases; and determining the expected output data and historical result data as result comparison data respectively.

[0046] The test case storage space can be used to store each model test case and its related data. The expected output data can be the result of responding to the input data in the model test cases based on the expected model functionality. The historical result data can be the result of responding to the input data in the model test cases based on the model functionality before changes to the target test model.

[0047] Specifically, the comparison data can include expected output data and historical result data stored in the test case storage space corresponding to the model test cases. By comparing the result data between the target test data and the expected output data, it can be determined whether the actual functionality of the target test model meets the expected requirements. Similarly, by comparing the result data between the target test data and the historical result data, it can be determined whether the actual functionality of the target test model differs from its functionality before the model change.

[0048] Optionally, historical result data can be the result of responding to and outputting the input data in the model test cases based on the functionality of the model before the change. The functionality of the model before the change can include functions that meet the expected requirements or functions that do not meet the expected requirements. The specific situation can be marked with corresponding test results in the test case annotation data of the model test cases. Thus, the test results corresponding to the target test data can be judged by combining historical result data and its corresponding test result annotations.

[0049] In an optional implementation, after annotating the model test cases with test results based on the test case annotation data, the method may further include: updating the historical result data to the target test data in the test case storage space. Specifically, after the current model functional test generates the corresponding test case annotation data and completes the test result annotation, the template test data can be identified as historical result data, so that the test result can be judged in the next test by referring to the judgment of the current test result.

[0050] In one optional implementation, generating test case annotation data based on the data comparison results may include: generating test result annotation data based on the data comparison results between the target test data and the expected output data; generating model difference annotation data based on the data comparison results between the target test data and historical result data; and determining the test result annotation data and the model difference annotation data as test case annotation data.

[0051] Specifically, the test result annotation data can be labeled data used to describe whether the actual function of the target test model meets the expected requirements. The model difference annotation data can be labeled data used to describe the differences between the actual function of the target test model and the function of the model before the change.

[0052] Specifically, test case annotation data can include both test result annotation data and model difference annotation data. This allows for the evaluation and annotation of the target test model's capabilities based on both the expected functional requirements of the model and the actual functional requirements that occurred during historical periods.

[0053] Specifically, optional data may include test result annotations indicating whether the test passed or failed, and model difference annotations may include differences from historical result data.

[0054] In an optional implementation, after annotating the test results of the model test cases based on the target test data, the method may further include: generating test coverage data, pass rate data, failed test case details data, and model difference data based on the model test cases and the target test data; and generating a visual test report based on the test coverage data, pass rate data, failed test case details data, and model difference data.

[0055] Specifically, test coverage data describes the extent to which test cases cover the model's functionality, logic, and / or usage scenarios. Pass rate data represents the percentage of target test data where the actual model functionality meets expectations. Failure test case details describe specific instances where the actual model functionality corresponding to the target test data does not meet expectations. Model discrepancy data reflects the differences between the actual model functionality corresponding to the target test data and historical results data.

[0056] Specifically, based on the model test cases labeled with the test results and the specific target test data, test coverage data, pass rate data, failure case details data, and model difference data can be obtained, and all of these can be reflected in the generated visual test report. This allows users to understand the comprehensive and detailed test situation through the visual test report. The specific structure of the visual test report can be determined by pre-set rules or templates.

[0057] In an optional implementation, the implementation architecture of the software model testing method provided in this embodiment may include a test case management module, a model switch detection module, an automated regression testing module, an intelligent annotation module, and a report generation module. Specifically, based on the above implementation architecture, the software model testing method may include: a test case preparation stage, where the execution entity may be the test case management module, and the data flow may include test cases, including inputs, expected outputs, and annotation information, including test results after each model update, stored in the test case management module, and its timing may be during system initialization or test case update; a model switch detection stage, where the execution entity may be the model switch detection module, and the data flow may include the model in the monitoring system, triggering the regression testing process after detecting a model switch, and its timing may be real-time monitoring, executing immediately after detecting a switch; and an automated regression testing stage, where the execution entity may be the automated regression testing module, and the data flow may include the switching of the last model in the acceptance environment. The generated answer is deleted, and a new model is called to regenerate the answer. The result is compared with the expected output and the previous version's answer to generate test results. This process can be executed after the model switch detection module is triggered. In the intelligent annotation stage, the execution entity can be the intelligent annotation module, and the data flow can include automatically annotating test cases based on the test results. The annotation content includes test pass, test failure, and model differences generated by comparing with the previous model switch results. This process can be executed after the automated regression testing module generates test results. In the report generation stage, the execution entity can be the report generation module, and the data flow can include generating a regression test report, including test coverage, pass rate, details of failed test cases, model differences, etc. This process can be executed after the intelligent annotation module completes the annotation.

[0058] In one exemplary implementation, the software model testing method provided in this embodiment can be applied to AI model update scenarios. Specifically, in AI-driven systems, models are frequently updated, and regression testing is required after each update, such as in scenarios where users are provided with recommendations based on GPT, or recipe generation. The software model testing method provided in this embodiment monitors model changes in real time through a model switching detection module, automatically triggering the regression testing process to ensure system stability.

[0059] In one exemplary implementation, the software model testing method provided in this embodiment can be applied to natural language processing (NLP) systems. Specifically, in NLP systems, model switching may lead to output differences, requiring rapid verification, such as in intelligent interactive knowledge services for home appliances. The software model testing method provided in this embodiment uses an automated regression testing module to call the new model to generate answers and compare them with the expected output to quickly generate test results.

[0060] In one exemplary implementation, the software model testing method provided in this embodiment can be applied to machine learning platform scenarios. Specifically, in machine learning platforms, comprehensive testing is required after model switching to ensure model performance. The software model testing method provided in this embodiment automatically annotates test cases through an intelligent annotation module, providing detailed test reports to help test engineers quickly locate problems.

[0061] The above implementation method determines the target test model in the target software system, obtains model test cases that match the target test model, calls the target test model according to the model test cases, obtains the target test data output by the target test model, and then annotates the test results of the model test cases according to the target test data. This solves the problems of low efficiency and low reliability caused by relying on manual execution of model functional tests after software model updates in the prior art, and realizes efficient and accurate automated model testing, providing a reliable guarantee for the stability of the software system.

[0062] According to another aspect of the embodiments of the present invention, Figure 3 This is a schematic diagram of the structure of a software model testing device provided in an embodiment of the present invention, as shown below. Figure 3 As shown, the device includes a model determination module 310, a use case acquisition module 320, a model invocation module 330, and a result annotation module 340, wherein: Model determination module 310 is used to determine the target test model in the target software system; The test case acquisition module 320 is used to acquire model test cases that match the target test model; The model invocation module 330 is used to invoke the target test model according to the model test cases to obtain the target test data output by the target test model; The result annotation module 340 is used to annotate the test results of the model test cases based on the target test data.

[0063] In an optional implementation, the model determination module 310 may include: a model monitoring unit for monitoring state changes of the test object model in the target software system; and a state change unit for obtaining the target test model from the model change results of the state change when a model state change is detected in the test object model.

[0064] In an optional implementation, the result annotation module 340 may include: a comparison acquisition unit for acquiring result comparison data that matches the model test cases; a data comparison unit for comparing the target test data with the result comparison data to obtain a data comparison result; an annotation generation unit for generating test case annotation data based on the data comparison result; and a test case annotation unit for annotating the model test cases with the test results based on the test case annotation data.

[0065] In an optional implementation, the comparison acquisition unit may be specifically used to: acquire the expected output data and historical result data stored in the test case storage space corresponding to the model test case; and determine the expected output data and the historical result data as the result comparison data respectively.

[0066] In an optional implementation, the result annotation module 340 may further include: a history update unit, used to update the historical result data to the target test data in the use case storage space.

[0067] In an optional implementation, the annotation generation unit may be specifically used to: generate test result annotation data based on the data comparison results between the target test data and the expected output data; generate model difference annotation data based on the data comparison results between the target test data and the historical result data; and determine the test result annotation data and the model difference annotation data as the use case annotation data.

[0068] In an optional implementation, the software model testing apparatus may further include: a report generation module, configured to generate test coverage data, pass rate data, failed test case details data, and model difference data based on the model test cases and the target test data; and to generate a visual test report based on the test coverage data, the pass rate data, the failed test case details data, and the model difference data.

[0069] According to another aspect of the embodiments of the present invention, Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of the present invention, such as... Figure 4 As shown, the electronic device includes a processor 510, a memory 520, an input device 530, and an output device 540; the number of processors 510 in the electronic device can be one or more. Figure 4 Taking a processor 510 as an example; the processor 510, memory 520, input device 530, and output device 540 in the electronic device can be connected via a bus or other means. Figure 4 Taking the example of a connection between China and Israel via a bus.

[0070] The memory 520, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and modules, such as the program instructions / modules corresponding to the software model testing method in this embodiment of the invention (e.g., the model determination module 310, test case acquisition module 320, model invocation module 330, and result annotation module 340 in the software model testing device). The processor 510 executes various functional applications and data processing of the electronic device by running the software programs, instructions, and modules stored in the memory 520, thereby implementing the aforementioned software model testing method.

[0071] The memory 520 may primarily include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a given function; the data storage area may store data created based on terminal usage. Furthermore, the memory 520 may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some instances, the memory 520 may further include memory remotely located relative to the processor 510, which can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0072] Input device 530 can be used to receive input digital or character information, and generate key signal inputs related to user settings and function control of the electronic device. It can also be a camera for acquiring images and a sound pickup device for acquiring audio data. Output device 540 may include display devices such as a screen, and audio devices such as a speaker. It should be noted that the specific composition of input device 530 and output device 540 can be set according to actual conditions. Processor 510 executes various functional applications and data processing of the electronic device by running software programs, instructions, and modules stored in memory 520.

[0073] According to another aspect of the present invention, the present invention also provides a computer-readable storage medium comprising a stored program, wherein the program, when executed, performs the following software model testing method: Determine the target test model for the target software system; Obtain model test cases that match the target test model; The target test model is invoked based on the model test cases to obtain the target test data output by the target test model; Based on the target test data, the test results of the model test cases are labeled.

[0074] Of course, the computer-executable instructions provided in the embodiments of the present invention are not limited to the method operations described above, but can also perform related operations in the software model testing method provided in any embodiment of the present invention.

[0075] Based on the above description of the implementation methods, those skilled in the art can clearly understand that the present invention can be implemented using software and necessary general-purpose hardware, and of course, it can also be implemented using hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as a computer floppy disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk, or optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0076] It is worth noting that in the embodiments of the software model testing device described above, the various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy differentiation and are not used to limit the scope of protection of the present invention.

[0077] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A software model testing method, characterized in that, include: Determine the target test model for the target software system; Obtain model test cases that match the target test model; The target test model is invoked based on the model test cases to obtain the target test data output by the target test model; Based on the target test data, the test results of the model test cases are labeled.

2. The method according to claim 1, characterized in that, The determination of the target test model in the target software system includes: Monitor the state changes of the test object model in the target software system; When a change in the model state of the test object model is detected, the target test model is obtained from the model change result of the change in the model state.

3. The method according to claim 1, characterized in that, The step of labeling test results for the model test cases based on the target test data includes: Obtain comparison data of the results matching the test cases of the model; The target test data and the result comparison data are compared to obtain the data comparison results. Generate use case annotation data based on the data comparison results; The test results are labeled for the model test cases based on the test case labeling data.

4. The method according to claim 3, characterized in that, The acquisition of comparison data for matching the model test cases includes: Retrieve the expected output data and historical result data corresponding to the test cases of the model from the test case storage space; The expected output data and the historical result data are respectively determined as the result comparison data.

5. The method according to claim 4, characterized in that, After labeling the model test cases with the test results based on the test case labeling data, the method further includes: In the test case storage space, the historical result data is updated to the target test data.

6. The method according to claim 4, characterized in that, The step of generating test case annotation data based on the data comparison results includes: Test result annotation data is generated based on the data comparison results between the target test data and the expected output data. Model difference annotation data is generated based on the data comparison results between the target test data and the historical result data. The test result annotation data and the model difference annotation data are determined as the test case annotation data.

7. The method according to claim 1, characterized in that, After labeling the test results of the model test cases based on the target test data, the method further includes: Based on the model test cases and the target test data, generate test coverage data, pass rate data, failed test case details data, and model difference data; A visual test report is generated based on the test coverage data, the pass rate data, the details of failed test cases, and the model difference data.

8. A software model testing device, characterized in that, include: The model determination module is used to determine the target test model in the target software system; The test case acquisition module is used to acquire model test cases that match the target test model; The model invocation module is used to invoke the target test model according to the model test cases and obtain the target test data output by the target test model. The result annotation module is used to annotate the test results of the model test cases based on the target test data.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein the program, when executed, performs the software model testing method according to any one of claims 1 to 7.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to execute the software model testing method according to any one of claims 1 to 7 through the computer program.

Images