Software testing method and software testing device

Abstract

The application discloses a software testing method and a software testing device. The method comprises the following steps: in the case that the testing requirement information of the software to be tested is updated, obtaining the requirement change data corresponding to the software to be tested; updating the testing time sequence diagram corresponding to the software to be tested by using a time sequence diagram updating mode corresponding to the requirement change data, to obtain an updated testing time sequence diagram; generating a target configuration file corresponding to the updated testing time sequence diagram; converting the target configuration file into testing process data used for software testing; and testing the software to be tested based on the testing process data. Thus, the scheme provided by the application can realize automatic testing of the software, and improve the testing efficiency of the software.

Description

Technical Field

[0001] This application belongs to the field of software testing technology, and in particular relates to a software testing method and a software testing apparatus. Background Technology

[0002] In the software development process, in order to ensure the quality of the software product, it is usually necessary to test the software product before it is released to the market.

[0003] In related technologies, software products are typically tested by manually writing test cases. This method is not only time-consuming and labor-intensive but also prone to errors. Therefore, how to efficiently and accurately automate software testing has become a key challenge. Summary of the Invention

[0004] This application provides a software testing method and a software testing apparatus that can realize automatic software testing and improve software testing efficiency.

[0005] In a first aspect, embodiments of this application provide a software testing method, which includes: when the test requirement information of the software under test is updated, obtaining the requirement change data corresponding to the software under test; updating the test timing diagram corresponding to the requirement change data using a timing diagram update method to obtain an updated test timing diagram; generating a target configuration file corresponding to the updated test timing diagram; converting the target configuration file into test process data for software testing; and testing the software under test based on the test process data.

[0006] Secondly, embodiments of this application provide a software testing apparatus, comprising: a data acquisition module, configured to acquire requirement change data corresponding to the software under test when the test requirement information of the software under test is updated; a timing diagram update module, configured to update the test timing diagram corresponding to the software under test using a timing diagram update method corresponding to the requirement change data, to obtain an updated test timing diagram; a configuration generation module, configured to generate a target configuration file corresponding to the updated test timing diagram; a data conversion module, configured to convert the target configuration file into test process data for software testing; and a testing module, configured to test the software under test based on the test process data.

[0007] Thirdly, embodiments of this application provide an electronic device, which includes: a processor and a memory storing computer program instructions; the processor executes the computer program instructions to implement the software testing method as described in the first aspect.

[0008] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions that, when executed by a processor, implement the software testing method as described in the first aspect.

[0009] Fifthly, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform the software testing method as described in the first aspect.

[0010] As described above, in this embodiment, when an update to the test requirement information is detected, test sequence diagrams, configuration files, and test process data can be automatically generated based on the requirement change data. This test process data is then used to test the software under test. This process eliminates the need for manual test case writing, reducing human intervention and improving software testing efficiency. Furthermore, in the above process, the test process data is generated based on the configuration file, which in turn is generated based on the updated test sequence diagram. The test sequence diagram contains the test sequence for the software under test. Therefore, the test process data also includes the sequence and test process required to test the software under test. Based on this test process data, the software under test can be tested directly without generating test cases, simplifying the software testing steps and improving software testing efficiency. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a flowchart illustrating a software testing method provided in one embodiment of this application; Figure 2 This is a test timing diagram provided in one embodiment of this application; Figure 3 This is a schematic diagram of the process for generating a test timing diagram according to an embodiment of this application; Figure 4 This is a schematic diagram of the configuration file update process provided in one embodiment of this application; Figure 5 This is an architecture diagram of a software testing method provided in one embodiment of this application; Figure 6 This is a schematic diagram of the structure of a software testing apparatus provided in another embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in another embodiment of this application. Detailed Implementation

[0013] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0014] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0015] To facilitate understanding, before explaining the solution provided in this application, the background of the solution provided in this application will be explained first.

[0016] In the software development process, testing is essential to ensure software quality. As a core means of quality assurance, the efficiency and accuracy of software testing directly impact the software delivery cycle and the reliability of the final product. However, traditional software testing processes require manual writing of test cases, which is not only time-consuming and labor-intensive but also prone to errors. Therefore, how to efficiently and accurately generate test processes automatically has become a key challenge.

[0017] Currently, software testing processes heavily rely on manual operation, representing a serialized and labor-intensive work model. Specifically, existing technologies typically employ the following fully manual process for software testing: First, testers need to manually read and break down the software requirements specification document. By manually reading and understanding the document, testers identify test elements such as functional requirements, non-functional requirements, input / output conditions, system states and modes, boundary conditions, and exception handling logic. This process is not only time-consuming but also prone to incomplete testing scope due to human misunderstandings or oversights.

[0018] Secondly, based on the decomposed test points, testers need to manually design detailed functional test cases. This step relies entirely on the testers' personal experience and business knowledge, lacking a systematic auxiliary generation mechanism, resulting in low efficiency in test case design and difficulty in ensuring the sufficiency and optimization of the test cases.

[0019] Furthermore, to ensure the traceability and compliance of the testing process, testers also need to manually establish and maintain a two-way traceability link between test cases and original requirement items. This process is usually completed by manually editing documents or using management tools, which is not only tedious and error-prone, but also difficult to update synchronously when requirements change, resulting in high maintenance costs.

[0020] Finally, when converting functional test cases into executable automated test scripts, automation testers need to manually read and understand the designed test cases again, and then manually write the test script code based on their understanding of the test cases. This process requires testers to have strong programming skills and a deep understanding of specific testing tools or frameworks. It is not only inefficient and time-consuming, but also prone to introducing coding errors, resulting in poor stability and maintainability of the automated scripts.

[0021] In summary, the existing software testing process has the following significant drawbacks: Overall testing efficiency is low. Manually identifying test points and designing detailed functional test cases is highly repetitive work, and the conversion of functional test cases into automated scripts is particularly inefficient. Frequent requirement changes lead to a chain of manual updates: requirement change -> test point update and identification -> manual update of functional test case design -> manual update of documented test cases -> manual update of traceability links -> manual modification of corresponding test script code. This process is costly and slow to respond.

[0022] The traceability is weak and maintenance is difficult. The multi-layered traceability chain between test requirements, test points, functional use cases, and automated scripts is highly dependent on manual establishment and updates.

[0023] The risk of errors and omissions is high. The ambiguity of natural language can easily lead to different testers having different understandings of the test requirements. Errors are amplified and passed on at each stage, from test point identification and test case design to script writing.

[0024] In related technologies, the overall process is highly dependent on manual labor, time-consuming, labor-intensive, and prone to errors; the various stages are fragmented, and information transmission relies on manual interpretation, resulting in low efficiency and difficulty in ensuring consistency; test case design and automated script writing involve repetitive work, leading to low knowledge reuse; and the traceability between requirements, test cases, and scripts relies on manual maintenance, making real-time synchronization and accurate correlation difficult. Therefore, how to efficiently, accurately, and automatically generate complete, traceable, and executable test processes has become a key technical problem that urgently needs to be solved in this field.

[0025] To address the problems of existing technologies, this application provides a software testing method and a software testing apparatus. In this embodiment, test requirements are analyzed and parsed to automatically generate a timing diagram. Based on this timing diagram, a corresponding configuration file is then generated, allowing for automated updates to the software testing process. This method automatically updates the testing process, reduces manual operation and analysis, minimizes the possibility of human error, and improves the efficiency and accuracy of software testing.

[0026] The software testing method provided in the embodiments of this application will be described first. It should be noted that a software testing tool can serve as the execution subject of the method provided in the embodiments of this application. This software testing tool can run on a terminal device (e.g., a computer), and the software to be tested can run on this terminal device, thus allowing the software testing tool to test the software. Alternatively, the software testing tool can also be located on a server, thereby enabling remote testing of the software.

[0027] In some embodiments, Figure 1 A flowchart illustrating a software testing method provided in one embodiment of this application is shown. Figure 1 As shown, the method includes the following steps S101 to S105: Step S101: If the test requirement information of the software under test is updated, obtain the requirement change data corresponding to the software under test.

[0028] In step S101, the test requirement information of the software to be tested may include, but is not limited to, the attribute information of the software to be tested (e.g., the software identifier, type, and function of the software to be tested), the test duration of the software to be tested, other software or equipment required to test the software to be tested, the interaction logic between the software to be tested and other software or equipment, and the constraint relationships.

[0029] In this embodiment of the application, the test requirement information of the software to be tested can be stored in a test requirement document. The tester inputs the test requirement document into the software testing tool, and the software testing tool can parse the test requirement document to obtain the test requirement information of the software to be tested.

[0030] Furthermore, in this embodiment, the test requirement information has a unique identifier (i.e., a requirement identifier). The software testing tool can store the test requirement information and the requirement identifier corresponding to that test requirement information. When the software testing tool receives the test requirement information, it obtains the requirement identifier corresponding to the test requirement information, retrieves the test requirement information corresponding to that requirement identifier from the local storage area, and then compares the stored test requirement information with the received test requirement information to determine whether the test requirement information of the software under test has been updated. If the test requirement information of the software under test has been updated, the requirement difference between the two sets of test requirement information is taken as the requirement change data corresponding to the software under test.

[0031] Step S102: Using the timing diagram update method corresponding to the requirement change data, update the test timing diagram corresponding to the software to be tested to obtain the updated test timing diagram.

[0032] In step S102, the test timing diagram includes entities, the interaction relationships between entities, and the timing constraints between entities. Entities may include various functional modules in the software under test (e.g., the main control program) and other modules that interact with the software under test, such as a cloud platform or a server responding to data requests (e.g., a Modbus server). The interaction relationships between entities can be connected by horizontal message lines, with different interaction types corresponding to different message line styles. For example, in... Figure 2 In the test timing diagram shown, the cloud platform sends tasks to the main control program using bold solid arrows, while the main control program sends control commands to the server using ordinary solid arrows; timing constraints can be represented by auxiliary elements. Figure 2 (Not shown in the text), for example, the timeout of the interaction between the cloud platform and the main control program is marked with a dashed box, and the interval for the main control program to wait for the server response is marked with a double-arrow line segment.

[0033] In this application embodiment, the timing diagram update method differs for different requirement change data. The timing diagram update method may include, but is not limited to, full update and incremental update. For example, when the requirement change data involves many changes or the changes are significant, a full update can be used to update the test timing diagram to ensure its reliability. If the requirement change data involves few changes or the changes are less significant, an incremental update can be used to update the test timing diagram, reducing the computational resources consumed in updating the test timing diagram and improving its update efficiency.

[0034] Furthermore, in this embodiment, test requirement information is converted into a test sequence diagram, using structured data to display the test requirements of the software under test. This allows testers to verify the correctness of the interaction sequences and state changes corresponding to the test sequence diagram, laying the foundation for accurate testing of the software under test. In addition, testers can update the test sequence diagram in real time according to actual needs, improving the update efficiency.

[0035] Step S103: Generate the target configuration file corresponding to the updated test timing diagram.

[0036] In step S103, the configuration file is a key bridge connecting the test sequence diagram and the test process data used to test the software. It can be a structured test specification document that can convert the interaction logic in the test sequence diagram into machine-understandable and executable instructions, thereby automatically driving the software testing tool to test the software under test and realizing automatic software testing.

[0037] In this embodiment, the configuration file can be obtained by mapping the test sequence diagram to the test framework. When the test sequence diagram is updated, the configuration file can be updated incrementally. For example, the differences between the updated and unupdated test sequence diagrams can be compared, and the configuration file corresponding to the unupdated test sequence diagram can be incrementally updated based on these differences. If the configuration file corresponding to the test sequence diagram does not exist in the local storage of the software testing tool, the configuration file can be generated based on the test sequence diagram.

[0038] Step S104: Convert the target configuration file into test process data for software testing.

[0039] In step S104, the test process data can be in the form of a graph. For example, the process test data can include a test process topology graph, which is a visual model that structurally and graphically maps the test logic defined in the parsed configuration file. This test process topology graph is a directed graph composed of nodes (used to represent test steps, assertions, or conditional judgments) and edges (used to represent execution order, data flow, or dependencies). It can intuitively display the internal logic and execution path of software testing, providing testers with a global perspective and change traceability capabilities, making complex test logic and the scope of impact of updates clear at a glance. At the same time, as a machine-parseable structured blueprint, it can directly drive the test execution engine to schedule tasks and manage dependencies in the correct topology order, thereby ensuring that automated tests can still run accurately, efficiently, and reliably after dynamic updates.

[0040] Step S105: Test the software to be tested based on the test process data.

[0041] In step S105, after generating the test process data, the software testing tool can generate test instructions based on the test process data and send the test instructions to the software under test, while collecting the data fed back by the software under test in real time. After each test instruction is executed, the actual data is compared with the expected value through an assertion function to determine whether the test result corresponding to the test instruction has passed. Failed test instructions are retried or marked according to rules. After the entire process is completed, the test results corresponding to each test instruction are summarized, a test report containing the pass rate, failure details, and data trends is generated, stored in the system database, and a completion signal is pushed. If a serious anomaly occurs during the test, execution is immediately suspended and an alarm is triggered to ensure that the test process is controllable and the results are traceable.

[0042] Based on the scheme defined in steps S101 to S105 above, it can be understood that in this embodiment, when an update to the test requirement information is detected, test sequence diagrams, configuration files, and test process data can be automatically generated based on the requirement change data. The software under test can then be tested using this test process data. This process eliminates the need for manual test case writing, reducing human intervention and improving software testing efficiency. Furthermore, in the above process, the test process data is generated based on the configuration file, which in turn is generated based on the updated test sequence diagram. The test sequence diagram contains the test sequence for the software under test. Therefore, the test process data also contains the sequence and test process required to test the software under test. Based on this test process data, the software under test can be tested directly without generating test cases, simplifying the software testing steps and improving software testing efficiency.

[0043] The specific implementation process of the method provided in the embodiments of this application is described below.

[0044] In some embodiments, before obtaining the requirement change data corresponding to the software under test, the software testing tool needs to detect whether the test requirements of the software under test have been updated, and then determine whether the test sequence diagram needs to be updated based on the detection results.

[0045] Specifically, the software testing tool acquires the test requirements information of the software under test; performs natural language processing on the test requirements information to obtain the structured data corresponding to the test requirements information; then, it acquires the historical structured data corresponding to the software under test; compares the structured data with the historical structured data, and determines that the test requirements information of the software under test has been updated if there are differences between the structured data and the historical structured data.

[0046] In this embodiment, testers can input the original test requirement document into the software testing tool. This original test requirement document can be in common formats such as Word, PDF, or Markdown. Upon receiving the test requirement document, the software testing tool extracts key information such as the functional description of the software under test, the roles involved in the software testing process, the interaction logic between these roles, and various constraints, organizing this information into structured data and storing it. Simultaneously, the software testing tool continuously monitors the test requirement information. When it detects additions, modifications, or deletions to the test requirement information, it employs intelligent analysis methods to deeply understand the changed requirements and determine the specific changes. Based on the updated structured data, it then updates the test sequence diagram, configuration files, and test process data.

[0047] For example, the software testing tool loads the original test requirements document and uses a text parsing engine to initialize and parse it, extracting key information such as test functions, roles involved in the software testing process, and interaction logic, forming structured data storage. Then, relying on file monitoring tools (e.g., inotify, FileSystemWatcher) and version control hooks (e.g., Git post-receive), the software testing tool continuously monitors for additions, deletions, and modifications to the test requirements document. When an update to the test requirements document is detected, the software testing tool triggers re-parsing, using NLP (Natural Language Processing) to identify entities in the document, extract relationships between entities, and combine this with a knowledge graph of the domain in which the software under test is applied for logical reasoning. This identifies key information and types of changes in the test requirements document, outputting structured data to facilitate subsequent updates to test sequence diagrams, configuration files, and test processes.

[0048] In this way, software testing tools can automatically parse the testing requirements of the software under test, and then generate a test process based on these requirements. This can significantly reduce the time spent manually writing and maintaining test cases, improve testing efficiency, and reduce the error rate caused by human factors.

[0049] Furthermore, after determining that the test requirements information of the software to be tested has been updated, the software testing tool obtains the difference data between the structured data and the historical structured data to obtain the requirement change data.

[0050] Furthermore, after obtaining the requirement change data, the software testing tool uses a timing diagram update method corresponding to the requirement change data to update the test timing diagram corresponding to the software under test, thus obtaining the updated test timing diagram.

[0051] Specifically, the software testing tool determines the target change level corresponding to the requirement change data based on the correlation between the change data and the change level; then, it updates the test sequence diagram using the sequence diagram update method corresponding to the target change level, thus obtaining the updated test sequence diagram.

[0052] For example, after obtaining the requirement change data corresponding to the software to be tested, the software testing tool converts the requirement change data into structured events in a unified format. These structured events include, but are not limited to, fields such as change type (e.g., new feature, description change) and requirement identifier. The target change level corresponding to the requirement change data is determined according to the urgency of the structured events. For example, the target change level corresponding to the structured event of new feature is higher, while the target change level corresponding to the structured event of description change is lower.

[0053] The software testing tool invokes corresponding hook functions based on the target change level to update the software testing process. In this embodiment, when the target change level is high, a full update hook function is invoked to achieve a full update of the test sequence diagram; when the target change level is low, an incremental update hook function is invoked to achieve an incremental update of the test sequence diagram.

[0054] It should be noted that, in this embodiment, after the software testing tool starts, the hook function loads a preset event handling rule configuration file. This configuration file defines different event types (e.g., adding, modifying, or deleting requirements), the mapping relationship between different event types and corresponding processing operations, and the event level classification criteria (e.g., feature change events have higher levels, while non-critical path event changes have lower levels). The hook function establishes a long connection with the requirement change sensing unit, which is used to detect changes in test requirements, through a registered callback interface, to receive standardized event signals pushed by the requirement change sensing unit in real time. These standardized event signals include, but are not limited to, data such as requirement identifier, change type, change level, and change time.

[0055] Hook functions determine the cache queue for requirement change data based on its change severity. For example, high-severity change data is added to the real-time processing queue and processed immediately by the main thread of the software testing tool; low-severity change data is added to the cache queue and processed using a delayed queue mode, processed centrally every 6 hours to reduce the overhead of frequent system calls. When processing low-severity change data, hook functions can match the mapping rules in the configuration file according to the event type of the change event corresponding to the change data, facilitating the subsequent generation of the configuration file. During this process, hook functions generate test tasks containing requirement identifiers, operation instructions, and parameter lists.

[0056] Next, the hook function distributes the generated test tasks to downstream modules of the hook function in the software testing tool via IPC (Inter-Process Communication) mechanism. These downstream modules include, for example, a sequence diagram update module for updating test sequence diagrams and a configuration file update module for updating configuration files. Simultaneously, the hook function initiates timeout monitoring. For test tasks with higher change levels, a shorter timeout threshold is set, such as 30 minutes; while for test tasks with lower change levels, a longer timeout threshold is set, such as 4 hours. If the downstream module of the hook function returns feedback indicating successful task execution within the specified time, the hook function updates the task status to "complete" and writes the execution result (including update time, impact scope, etc.) to the log database. If no feedback is received within the timeout period or a failure is returned, the hook function triggers a retry mechanism. The number of retries for tasks with higher change levels is greater than the number of retries for tasks with lower change levels. For example, a task with a higher change level may be retried twice, while a task with a lower change level may be retried once. If a retry fails, an exception notification is sent to the system alarm module, and the reason for the failure is recorded for subsequent investigation.

[0057] In some embodiments, when the test requirement information of the software under test is updated multiple times, the software testing tool also generates test tasks based on the test process data corresponding to each test requirement information; when there are processing conflicts among multiple test tasks, it obtains the timestamp corresponding to each test task; it selects and executes the test task with the largest timestamp from among multiple test tasks, and discards and terminates other test tasks.

[0058] In this embodiment, in scenarios where multiple test tasks need to be executed simultaneously, the software testing tool can perform concurrent control and resource scheduling for multiple test tasks. For processing conflicts caused by concurrent events with the same requirement identifier, the software testing tool uses a timestamp priority mechanism to handle the conflicts. The software testing tool compares the generation timestamps of all incomplete tasks under the same requirement identifier in real time. Regardless of the current execution progress, the software testing tool automatically terminates and discards tasks with earlier timestamps, retaining and prioritizing the execution of only the most recently executed task. Simultaneously, the software testing tool also uses task preemption markers to avoid interference from residual processes of older tasks, ensuring that the latest requirement changes can be applied to downstream modules as quickly as possible. Furthermore, the software testing tool dynamically monitors the load of downstream modules, such as CPU and memory. When the load of a module exceeds a threshold, tasks destined for that module are temporarily placed in a waiting queue. Once the load decreases, tasks are resumed in timestamp order to prevent the module from crashing due to overload.

[0059] In some embodiments, after determining the target change level, the software testing tool can update the test sequence diagram using a timing diagram update method corresponding to the target change level. Prior to this, to improve the reliability of the test sequence diagram update, the software testing tool needs to perform data validation on the test requirement information.

[0060] For example, in this embodiment of the application, the software testing tool also includes a requirements parsing module and a timing diagram update module. The former is used to parse the test requirements document to obtain test requirements information, and send the obtained test requirements information to the timing diagram update module to transform the structured test requirements information output by the requirements parsing module into a visual test timing diagram. When test requirements change, the latter can accurately identify the changed content and update only the affected parts of the test timing diagram. At the same time, it can detect and mark any logical conflicts that may occur during the update process. Finally, the updated test timing diagram is associated with version information and stored to provide an accurate visual basis for the subsequent configuration file generation.

[0061] In this embodiment, the sequence diagram update module receives test requirement information output by the requirement parsing module through a preset interface, and extracts entity information, interaction relationships, timing constraints, etc. from the test requirement information. After the data is received, the sequence diagram update module starts a format validator to check the completeness of the test requirement information to ensure that no key fields are missing; at the same time, it performs preliminary logical verification, such as checking whether the same entity is assigned contradictory operation instructions at the same time point. If so, the data is temporarily stored and the verification exception is reported back to the requirement parsing module.

[0062] In some embodiments, when the target change level is less than the level threshold, the software testing tool obtains requirement change data from the first cache queue according to the first data acquisition cycle; then, it determines the target element to be updated in the test sequence diagram based on the requirement change data, and updates the target element in the test sequence diagram based on the requirement change data to obtain the updated test sequence diagram.

[0063] In the above embodiments, the first cache queue is a buffer queue, and the first data acquisition period is a relatively long acquisition period, for example, 4 hours. The target element includes at least one of the following: an entity, temporal constraints between entities, and interaction relationships between entities.

[0064] For example, upon receiving an update instruction from a hook function, which includes a requirement identifier and change type, the sequence diagram update module retrieves the historical structured data corresponding to that requirement identifier from the local data storage area of ​​the software testing tool and compares it with the newly received structured data. A graph structure comparison algorithm is used to first compare changes to entity sets, such as adding, deleting, or modifying the attributes of entities; then, changes to the interaction relationships between entities are compared, such as adding or deleting messages, or modifying message content or order; finally, changes to timing constraints are compared, such as adjusting time parameters or adding / removing constraints. During this comparison process, the sequence diagram update module generates a discrepancy list to record the type, location, and specific content of the changes.

[0065] After obtaining the discrepancy list, the sequence diagram update module updates the test sequence diagram accordingly. For example, if the discrepancy list indicates an update of a new entity, the sequence diagram update module adds a new participant box at the corresponding position in the test sequence diagram and draws associated message lines based on its interaction with other entities. If the discrepancy list indicates an update of a change in interaction relationships, the sequence diagram update module only modifies the style, content, or order of the corresponding message lines, without affecting unchanged elements. If the discrepancy list indicates an update of timing constraints, the sequence diagram update module directly updates the time parameters or constraint descriptions in the annotation boxes. For deleted entities or interaction relationships, they are marked for deletion in the sequence diagram, such as temporarily hiding and recording the deletion trajectory, rather than directly clearing the data.

[0066] In some embodiments, when the target change level is greater than or equal to the level threshold, a full update is used to update the test sequence diagram. Specifically, the software testing tool obtains test requirement information from the second cache queue according to the second data acquisition cycle; then, it extracts entities, the temporal constraints between entities, and the interaction relationships between entities from the test requirement information; it calls the drawing rule engine to draw the target test sequence diagram based on the entities, the temporal constraints between entities, and the interaction relationships between entities; finally, it updates the test sequence diagram using the target test sequence diagram to obtain the updated test sequence diagram.

[0067] In the above embodiments, the second data acquisition period is shorter than the first data acquisition period, and the second cache queue is a real-time cache queue.

[0068] It should be noted that for a full update of the test sequence diagram, the sequence diagram update module needs to clear the historical sequence diagram data and regenerate it during the update process. The following example... Figure 3 The generation process of the test timing diagram shown is illustrated using an example.

[0069] like Figure 3 As shown, after receiving the test requirement information, the sequence diagram update module uses intelligent analysis algorithms to intelligently analyze and identify the test requirement information. For example, it uses NLP to identify key entities in the test requirement information; it performs dependency analysis on the test requirement information to identify the interaction relationships between entities; and it calculates time windows for the test requirements to determine the temporal constraints between entities. Then, the sequence diagram update module calls the drawing rule engine, which presets the mapping relationship between data and sequence diagram elements.

[0070] For entity mapping, the drawing rule engine transforms entities such as cloud platform, main control program, and server into vertically arranged rectangular participant boxes. The participant boxes are labeled with entity names and core attributes. The spacing of the participant boxes is automatically adjusted according to the interaction frequency to reduce message line intersections.

[0071] For interactive relationships, the drawing rule engine uses horizontal message lines to represent interactions between entities, with the style of the message lines bound to the interaction type. For example, a bold solid arrow is used when the cloud platform sends a task to the main control program, a regular solid arrow is used when the main control program sends control commands to the server, and a dashed line with a return arrow is used for device response feedback. The start point of the message line is aligned with the sender's timeline, and the end point falls precisely on the corresponding time node of the receiver. Triggering conditions are labeled sequentially next to the line.

[0072] For timing constraints, the drawing rule engine uses auxiliary elements to represent timing constraints. For example, the timeout threshold for the interaction between the cloud platform and the main control program is marked with a red dashed box, the interval for the main control program to wait for the server response is marked with a double-arrow line segment, and the preceding operation constraints are marked with a blue annotation box floating above the associated message line.

[0073] After completing the mapping between data and primitives, the drawing rules engine generates a test sequence diagram in PlantUML format. This test sequence diagram can be exported to SVG (Scalable Vector Graphics) with one click. All text and line colors in the diagram are distinguished by entity type. For example, elements related to the cloud platform are dark blue, and those on the device side are green, to ensure readability in complex interactive scenarios.

[0074] In some embodiments, after updating the test timing diagram using a timing diagram update method corresponding to the target change level to obtain the updated test timing diagram, the timing diagram update module also performs conflict detection to improve the reliability of the test timing diagram.

[0075] Specifically, the sequence diagram update module obtains the business scenario corresponding to the software under test, uses the domain knowledge graph corresponding to the business scenario to perform conflict verification on the interaction logic between entities in the updated test sequence diagram, and obtains the conflict verification result; if the conflict verification result indicates that there is a logical conflict in the updated test sequence diagram, it records the entities with logical conflicts and the content of the logical conflicts in the updated test sequence diagram; and based on the content of the logical conflicts and the position of the entities with logical conflicts in the updated test sequence diagram, it performs conflict analysis on the updated test sequence diagram and obtains the analysis result.

[0076] For example, during the update of the test sequence diagram, the sequence diagram update module simultaneously performs logic conflict detection. Specifically, the sequence diagram update module can perform deep validation of the interaction logic in the updated test sequence diagram based on a domain knowledge graph. If a conflict is found, the conflict location is marked with a special color in the test sequence diagram, and a conflict report is generated, detailing the conflict content, the involved requirement data nodes, possible resolution suggestions, and a resolution status marker. This report is then synchronized to downstream modules of the sequence diagram update module, such as the configuration file update module. Simultaneously, the sequence diagram update module pauses its automatic update process, awaiting manual confirmation before resuming. In this embodiment, the sequence diagram update module can also be configured with a conflict resolution callback interface to trigger a retry of the update after manual confirmation.

[0077] like Figure 3As shown, after generating the test sequence diagram and resolving conflicts through conflict detection or manual resolution, the sequence diagram update module associates the newly generated test sequence diagram with the corresponding requirement version number, update time, and updater, and stores it in the sequence diagram version database. The file path storing the test sequence diagram is pushed to the downstream configuration file update module via an interface, triggering the subsequent configuration file generation process. Furthermore, in this embodiment, the sequence diagram version database can also record the differences between the current version and the previous version, supporting quick backtracking of any historical version's sequence diagram via a timeline or version number.

[0078] In some embodiments, the software testing tool also includes a configuration file update module, which is located downstream of the timing diagram update module and is used to update the configuration file based on the updated test timing diagram.

[0079] Specifically, the configuration file update module obtains the first graph metadata corresponding to the test sequence diagram and the historical configuration file generated based on the test sequence diagram, and iterates through the graph elements in the updated test sequence diagram to extract the second graph metadata corresponding to the updated test sequence diagram; then, it compares the first graph metadata and the second graph metadata to obtain the graph element difference data between the first graph metadata and the second graph metadata, and uses the graph element difference data to update the historical configuration file to obtain the target configuration file.

[0080] In the above embodiments, the historical configuration file is a file generated by mapping the graph metadata of the test sequence diagram to the test framework. The first graph metadata is the graph metadata in the test sequence diagram before the update, and the second graph metadata is the graph metadata in the updated test sequence diagram, including but not limited to entities, the interaction relationships between entities, and the timing constraints between entities.

[0081] For example, Figure 4 The configuration file update process is shown, such as... Figure 4 As shown, the process mainly includes steps such as test sequence diagram acquisition, sequence diagram parsing, configuration metadata extraction, configuration file template matching, configuration file generation, version verification and conflict detection, and configuration file output. The following describes each of the above steps.

[0082] The configuration file update module receives the file path pushed by the timing diagram update module through a preset interface and queries whether a test timing diagram exists in that file path. After detecting that a test timing diagram exists in the file path, the configuration file update module calls the timing diagram parsing engine to load the test timing diagram, initializes the parsing environment, and loads the drawing syntax parser and primitive recognition model.

[0083] In the sequence diagram parsing and configuration metadata extraction steps, the configuration file update module calls the sequence diagram parsing engine to traverse the graph elements in the test sequence diagram, identify and extract three types of core information, namely entity information, interaction relationships and sequence constraint relationships.

[0084] For entity information, the sequence graph analysis engine extracts task triggering logic from cloud platform operation data, such as the test start command in the configuration file corresponding to "issue automatic detection task," and records triggering conditions, such as direct triggering without prerequisite dependencies. Then, it sorts out the interaction commands between the main control program and the server, such as "set track width (req_id = 12, carrying QR code coordinates (x,y))," extracting the command type (parameter configuration), parameters (req_id, coordinate values), and execution object (server). In addition, the sequence graph analysis engine can also identify special test stages such as "barcode verification," extracting the execution subject (e.g., the cloud platform executing the verification logic) and the command after verification, such as the barcode verification pass command.

[0085] For interaction relationships, the sequence diagram parsing engine organizes the bidirectional interaction links of "cloud platform → main control program → server" and "cloud platform ← main control program ← server" according to the message passing order in the test sequence diagram, and converts them into the execution order of steps in the configuration file. For example, the track width and Z-axis height settings are executed first, followed by barcode verification and image acquisition parameter settings. In addition, the sequence diagram parsing engine also marks the dependencies of each interaction. For example, "request chip fabrication (req_id = 1)" needs to be triggered after "waiting for product to be in place", and "set image acquisition parameters (req_id = 2)" needs to be executed after "barcode verification passed".

[0086] Regarding timing constraints, the timing diagram parsing engine extracts implicit timing constraints from the test timing diagram. For example, the server-side response timeout threshold can be supplemented based on default values ​​from interactive feedback or business requirements. When the test timing diagram is not explicit, the response timeout threshold can be marked according to conventional response logic as "requires a response within a reasonable time, resp = 1 represents success." The timing diagram parsing engine can also convert status nodes such as "waiting for product to be in place" and "barcode verification in progress" into test phase waiting conditions in the configuration file, clearly defining the execution time limits for each phase.

[0087] Through the identification and extraction of entity information, interaction relationships, and temporal constraints, the time sequence diagram parsing engine outputs structured data, providing clear and directly mappable input for configuration file generation.

[0088] It should be noted that the structured data output by the timing graph parsing engine includes a list of test steps and timing constraint rules. The list of test steps includes the execution entity, instructions, parameters, dependencies, etc., while the timing preset rules include timeouts, dependency order, etc.

[0089] After extracting the configuration metadata, the configuration file update module matches and generates the configuration file template. In this embodiment, the configuration file update module can generate the configuration file based on structured test information and in conjunction with an adapted test framework (e.g., an automated test framework, Modbus communication test tools, etc.).

[0090] The configuration file update module loads a template file containing "test procedure arrangement," "parameter configuration syntax," and "result verification rules" based on the test framework type. This template file contains placeholders corresponding to the interactions with the test sequence diagram, used to populate the extracted structured information.

[0091] For example, the configuration file update module maps "Set track width (req_id=12, parameters (x,y))" to the template file, replacing "{{REQ_ID}}" with 12 and "{{PARAMS}}" with "Track width parameters: (x,y), source cloud platform task". It arranges the execution order of the configuration files according to the identified dependencies. For example, it first configures the server-side device parameters (e.g., track width, Z-axis height), then executes barcode verification and image acquisition parameter settings, marking step dependencies using template syntax, such as "depends_on: Step 1 completed (track width set successfully)". The configuration file update module can also perform logical validation on supplementary results. For example, based on "req=0, resp=1 represents successful execution", it adds assertion rules to the corresponding positions in the configuration file. The configuration file update module can also generate a JSON format configuration file conforming to the framework syntax, and mark the configuration file version for future traceability. If the test framework requires special format conversion, the configuration file update module can automatically call a conversion tool to complete the adaptation, ensuring that the configuration file can be directly loaded and run by the test execution module.

[0092] The above steps generate the configuration file using template matching. When the test sequence diagram is updated, the configuration file update module can also use incremental updates. For example, it obtains the difference data from the sequence diagram and locates the corresponding line or block in the configuration file based on the difference data, modifying only the changed parts. For new steps, the corresponding configuration code block is inserted; for modified rules, the assertion condition fields are updated; for deleted elements, the corresponding configuration item is commented out. If a conflict is detected, the configuration file update module can also mark the conflict location, generate a comparison report, and pause the update until manual confirmation. After manual repair, if the file parsing error is fixed, a "file repair ready signal" is generated; if the node dependency conflict is resolved, a "conflict resolution ready signal" is generated.

[0093] After completing version verification and conflict detection, the configuration file update module assigns a version number to the generated configuration file, associating it with the generation time and update type, and stores it in the version repository. Simultaneously, it embeds a "traceability identifier" in the configuration file and records the "configuration item mapping" in the sequence graph database, enabling bidirectional navigation. The configuration file update module saves the final generated configuration file to a specified directory and pushes a version ready signal, including the file path, version number, and file hash value, to its downstream module, the test process update module, via an interface, triggering the test process to load and update. An update log is also generated and written to the system log repository.

[0094] In some embodiments, after generating the target configuration file, the software testing tool converts the target configuration file into test process data for software testing.

[0095] Specifically, when an update to the configuration file corresponding to the test sequence diagram is detected, the software testing tool performs an integrity check on the target configuration file and obtains the check result. If the check result indicates that the target configuration file has passed the check, the software testing tool obtains the configuration file difference data between the historical configuration file and the target configuration file. Then, the software testing tool obtains the historical test process data generated based on the historical configuration file and updates the historical test process data according to the configuration file difference data to obtain the test process data.

[0096] In the above embodiments, the historical test process data is a topology graph generated based on the structured data corresponding to the historical configuration file.

[0097] In this embodiment, the software testing tool monitors changes to the configuration file storage directory through a file listening mechanism. Upon detecting a new configuration file version, it performs an integrity check on the configuration file. After the configuration file passes the integrity check, it is automatically loaded and parsed to determine test process nodes, step sequences, dependencies, and assertion conditions. Subsequently, the differences between the old and new configuration files are compared to locate test process nodes that need to be added, modified, or deleted, and the relationships between entities are adjusted according to the parsed logic. During the test process update, the software testing tool records the execution results of each test instruction in real time and generates alarm information. After the update is complete, it outputs the updated test process topology diagram and detailed logs to support the smooth operation of the test execution phase.

[0098] For example, the software testing tool starts a directory monitoring service to continuously monitor file creation and modification events in the configuration file storage directory. When a new configuration file is detected, it calls the file loading interface to read the configuration file content and temporarily stores it in a memory buffer. Next, the software testing tool calls a parser adapted to the testing framework to transform the configuration file content into structured data recognizable by the system. Specifically, for test process nodes, it extracts the node identifier, name, and type from the "test case block"; for step sequences, it parses the specific operations contained in each test process node according to the "keyword definition" and records the operation parameters; for dependencies, it extracts the triggering logic between nodes from the "precondition" field; for assertion conditions, it parses the "verification rule" field and transforms it into an executable assertion function. After parsing, a data structure of a "test process topology diagram" is generated, visually displaying the relationships between nodes.

[0099] Next, the software testing tool retrieves the structured data of the currently running test process from the cache and compares it with the newly parsed data to obtain the comparison results. If the comparison results indicate the addition of a new node, the tool marks the test node and its associated steps in the test process topology diagram that exist in the new configuration file but not in the old configuration file. If the comparison results indicate the modification of a test node, the tool locates the test node whose step parameters, dependencies, or assertion conditions have changed. If the comparison results indicate the deletion of a test node, the tool identifies the test node that existed in the old configuration file but has been removed from the new configuration file, along with its associated dependency links. Based on the above comparison results, a discrepancy list is generated, and the differences in the comparison results are categorized according to their scope of impact.

[0100] Next, the software testing tool performs process update operations based on the discrepancy list. For new nodes, the new node is inserted into the test process topology diagram, and its predecessor node (e.g., "Node C's predecessor node is Node A") and successor node (e.g., "Node C triggers Node D after execution") are configured according to the resolved dependencies. The execution parameters of the node (e.g., timeout, number of retries) are initialized. For modified nodes, the node's step sequence (e.g., replacing the parameter value of "send signal"), dependencies (e.g., changing Node B's predecessor node from A to C), or assertion conditions (e.g., relaxing the response time threshold) are updated. For deleted nodes, the target node is removed from the test process topology diagram, and the dependency links of related nodes are adjusted. For example, the successor node that originally pointed to the deleted node is reassigned to the predecessor node of the deleted node.

[0101] During the aforementioned adjustments, the software testing tool verifies the legality of node dependencies using a test process topology graph traversal algorithm (e.g., depth-first search), ensuring there are no circular dependencies and no isolated nodes.

[0102] It should be noted that during the process adjustment, the software testing tool also starts an exception monitoring thread. For example, if a configuration file parsing error occurs, the software testing tool immediately stops the update, outputs the error location, and pushes a file error report to the configuration file update module. This error report contains information such as the file path and error location. The software testing tool waits for the "file repair ready signal" from the configuration file update module, and reloads the file upon receiving the signal. If a node dependency conflict is detected, a node conflict location report is pushed to the configuration file update module, and the current process is paused, awaiting manual repair. During this waiting period, the tool continuously listens for the "conflict resolution ready signal" from the configuration file update module, and reloads the repaired configuration file upon receiving the signal.

[0103] During the above anomaly monitoring process, a maximum number of retries can be set, for example, 3 times. If the number of retries exceeds the maximum number of retries, the process is frozen and an alarm is triggered.

[0104] After the test process data is updated, the software testing tool serializes the newly generated test process data and stores it in the process database, generating an update log containing basic information, detailed changes, and execution results. The basic information may include, but is not limited to, update time, old and new version numbers, and the number of affected nodes; detailed changes include, but are not limited to, the identifiers and specific content of added, modified, or deleted nodes; and execution results include the time taken for each step and whether any warnings were triggered.

[0105] This concludes the introduction of the methods provided in the embodiments of this application.

[0106] In some embodiments, Figure 5An architecture diagram of the method provided in the embodiments of this application is shown. Figure 5 As shown, after obtaining the original test requirement document, the requirement parsing module parses the test requirement document to obtain the test requirement information. Then, the requirement change detection module detects whether the test requirement information has changed. If a change in the test requirement information is detected, a hook function is triggered to drive the timing diagram update module to update the test timing diagram and automatically generate a configuration file. Then, the configuration file update module updates the configuration file and dynamically loads the updated configuration file to generate test process data for automated testing of the software under test.

[0107] As can be seen from the above, the solution provided in this application embodiment can significantly reduce the time spent manually writing and maintaining test cases, improve software testing efficiency, and reduce the error rate caused by human factors, making it suitable for testing stages of various software projects. The solution provided in this application embodiment, from requirement detection and analysis to the final test process update, requires almost no manual intervention throughout the entire process. Through its built-in requirement change awareness module and hook functions, the solution provided in this application embodiment can quickly respond to any requirement changes and update relevant resources in a timely manner. Furthermore, the hook function design allows users to add more customized event handling logic according to their needs, greatly improving the system's flexibility and adaptability.

[0108] This application also provides a software testing device, such as... Figure 6 As shown, the device 600 includes: a data acquisition module 601, a timing diagram update module 602, a configuration generation module 603, a data conversion module 604, and a testing module 605.

[0109] The data acquisition module 601 is used to acquire the requirement change data corresponding to the software under test when the test requirement information of the software under test is updated. The timing diagram update module 602 is used to update the test timing diagram corresponding to the software to be tested by adopting the timing diagram update method corresponding to the requirement change data, so as to obtain the updated test timing diagram. Configuration generation module 603 is used to generate a target configuration file corresponding to the updated test timing diagram; Data conversion module 604 is used to convert the target configuration file into test process data for software testing; Test module 605 is used to test the software under test based on test process data.

[0110] In some embodiments, the software testing apparatus further includes: a requirement parsing module, configured to acquire test requirement information of the software under test before acquiring requirement change data corresponding to the software under test; perform natural language processing on the test requirement information to obtain structured data corresponding to the test requirement information; acquire historical structured data corresponding to the software under test; and determine that the test requirement information of the software under test has been updated if there is a difference between the structured data and the historical structured data.

[0111] In some embodiments, the timing diagram update module includes a level determination module and a first update module. The level determination module is used to determine the target change level corresponding to the requirement change data based on the correlation between the change data and the change level; the first update module is used to update the test timing diagram using a timing diagram update method corresponding to the target change level, thereby obtaining the updated test timing diagram.

[0112] In some embodiments, the first update module is specifically used to obtain requirement change data from the first cache queue according to the first data collection cycle when the target change level is less than the level threshold; determine the target element to be updated in the test sequence diagram according to the requirement change data, wherein the target element includes at least one of entity, temporal constraint relationship between entities and interaction relationship between entities; update the target element in the test sequence diagram according to the requirement change data to obtain the updated test sequence diagram.

[0113] In some embodiments, the first update module is specifically used to obtain test requirement information from the second cache queue according to the second data collection cycle when the target change level is greater than or equal to the level threshold; extract entities, the temporal constraint relationship between entities, and the interaction relationship between entities from the test requirement information; call the drawing rule engine to draw the target test timing diagram based on the entities, the temporal constraint relationship between entities, and the interaction relationship between entities; and update the test timing diagram using the target test timing diagram to obtain the updated test timing diagram.

[0114] In some embodiments, the software testing apparatus further includes: a conflict analysis module, configured to: update the test sequence diagram using a sequence diagram update method corresponding to the target change level to obtain the updated test sequence diagram; obtain the business scenario corresponding to the software under test; use a domain knowledge graph corresponding to the business scenario to perform conflict verification on the interaction logic between entities in the updated test sequence diagram to obtain a conflict verification result; if the conflict verification result indicates that there is a logical conflict in the updated test sequence diagram, record the entities and content of the logical conflict in the updated test sequence diagram; and perform conflict analysis on the updated test sequence diagram based on the content of the logical conflict and the position of the entities with logical conflicts in the updated test sequence diagram to obtain an analysis result.

[0115] In some embodiments, the configuration generation module is specifically used to obtain the first graph metadata corresponding to the test sequence diagram and the historical configuration file generated based on the test sequence diagram, wherein the historical configuration file is a file generated by mapping the graph metadata of the test sequence diagram to the test framework; traverse the graph elements in the updated test sequence diagram to extract the second graph metadata corresponding to the updated test sequence diagram; compare the first graph metadata and the second graph metadata to obtain the graph difference data between the first graph metadata and the second graph metadata; and update the historical configuration file using the graph difference data to obtain the target configuration file.

[0116] In some embodiments, the data conversion module is specifically used to perform integrity verification on the target configuration file when an update is detected in the configuration file corresponding to the test sequence diagram, and obtain the verification result; if the verification result indicates that the target configuration file has passed the verification, obtain configuration file difference data between the historical configuration file and the target configuration file; obtain historical test process data generated based on the historical configuration file, wherein the historical test process data is a topology diagram generated based on the structured data corresponding to the historical configuration file; and update the historical test process data according to the configuration file difference data to obtain test process data.

[0117] In some embodiments, the software testing apparatus further includes: a task processing module, configured to generate test tasks based on test process data corresponding to each test requirement information when the test requirement information of the software under test is updated multiple times; obtain the timestamp corresponding to each test task when there is a processing conflict among multiple test tasks; obtain and execute the test task with the largest timestamp from among multiple test tasks, and discard and terminate other test tasks.

[0118] The software testing apparatus provided in this application embodiment can implement all the processes implemented in the foregoing method embodiments, and will not be described again here to avoid repetition.

[0119] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0120] Figure 7 A schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application is shown.

[0121] The electronic device may include a processor 701 and a memory 702 storing computer program instructions.

[0122] Specifically, the processor 701 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0123] Memory 702 may include mass storage for data or instructions. For example, and not limitingly, memory 702 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 702 may include removable or non-removable (or fixed) media. Where appropriate, memory 702 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 702 is non-volatile solid-state memory.

[0124] Memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the methods according to one aspect of this disclosure.

[0125] The processor 701 implements any of the software testing methods described in the above embodiments by reading and executing computer program instructions stored in the memory 702.

[0126] In one example, the electronic device may also include a communication interface 703 and a bus 710. For example, Figure 7 As shown, the processor 701, memory 702, and communication interface 703 are connected through bus 710 and complete communication with each other.

[0127] The communication interface 703 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0128] Bus 710 includes hardware, software, or both, that couples components of an electronic device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 710 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0129] Furthermore, in conjunction with the software testing methods in the above embodiments, this application embodiment can provide a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the software testing methods in the above embodiments.

[0130] Furthermore, in conjunction with the software testing methods described in the above embodiments, this application embodiment can provide a computer program product for implementation. When the instructions in this computer program product are executed by the processor of an electronic device, the electronic device performs any of the software testing methods described in the above embodiments.

[0131] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0132] The functional modules shown in the above-described block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0133] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0134] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0135] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A software testing method, characterized in that, include: If the test requirements information of the software under test is updated, obtain the requirement change data corresponding to the software under test; The test timing diagram corresponding to the required change data is updated using the timing diagram update method to obtain the updated test timing diagram. Generate a target configuration file corresponding to the updated test timing diagram; The target configuration file is converted into test process data for software testing; The software to be tested is tested based on the test process data.

2. The method according to claim 1, characterized in that, Before obtaining the requirement change data corresponding to the software under test, the method further includes: Obtain the test requirements information of the software to be tested; Natural language processing is performed on the test requirement information to obtain the structured data corresponding to the test requirement information; Obtain the historical structured data corresponding to the software under test; If there is a difference between the structured data and the historical structured data, it is determined that the test requirements information of the software under test has been updated.

3. The method according to claim 1, characterized in that, The step of updating the test timing diagram corresponding to the requirement change data using the timing diagram update method to obtain the updated test timing diagram includes: Based on the correlation between the changed data and the changed level, determine the target changed level corresponding to the changed data. The test timing diagram is updated using a timing diagram update method corresponding to the target change level to obtain the updated test timing diagram.

4. The method according to claim 3, characterized in that, The step of updating the test timing diagram using a timing diagram update method corresponding to the target change level to obtain the updated test timing diagram includes: If the target change level is less than the level threshold, the demand change data is obtained from the first cache queue according to the first data collection cycle; Based on the requirement change data, the target elements that need to be updated in the test sequence diagram are determined, wherein the target elements include at least one of entities, temporal constraint relationships between entities, and interaction relationships between entities; The target elements in the test sequence diagram are updated based on the required change data to obtain the updated test sequence diagram.

5. The method according to claim 3, characterized in that, The step of updating the test timing diagram using a timing diagram update method corresponding to the target change level to obtain the updated test timing diagram includes: If the target change level is greater than or equal to the level threshold, the test requirement information is obtained from the second cache queue according to the second data collection cycle; Extract entities, temporal constraints between entities, and interaction relationships between entities from the test requirement information; Call the drawing rule engine to draw the target test timing diagram based on the entity, the temporal constraint relationship between the entity, and the interaction relationship between the entity; The target test timing diagram is used to update the test timing diagram to obtain the updated test timing diagram.

6. The method according to any one of claims 3 to 5, characterized in that, After updating the test timing diagram using a timing diagram update method corresponding to the target change level to obtain the updated test timing diagram, the method further includes: Obtain the business scenario corresponding to the software to be tested; Using a domain knowledge graph corresponding to the business scenario, conflict verification is performed on the interaction logic between entities in the updated test sequence graph to obtain the conflict verification result. If the conflict verification result indicates that there is a logical conflict in the updated test sequence diagram, record the entities and contents of the logical conflict in the updated test sequence diagram. Based on the content of the logical conflict and the position of the entities with logical conflicts in the updated test timing diagram, a conflict analysis is performed on the updated test timing diagram to obtain the analysis results.

7. The method according to claim 1, characterized in that, The generation of the target configuration file corresponding to the updated test timing diagram includes: Obtain the first graph data corresponding to the test sequence diagram and the historical configuration file generated based on the test sequence diagram, wherein the historical configuration file is a file generated by mapping the graph data of the test sequence diagram to the test framework; The primitive elements in the updated test timing diagram are traversed to extract the second primitive data corresponding to the updated test timing diagram; The first and second map data elements are compared to obtain the map element difference data between the first and second map data elements. The historical configuration file is updated using the primitive difference data to obtain the target configuration file.

8. The method according to claim 7, characterized in that, The step of converting the target configuration file into test process data for software testing includes: If an update is detected in the configuration file corresponding to the test timing diagram, the integrity of the target configuration file is checked to obtain the check result. If the verification result indicates that the target configuration file has passed verification, obtain the configuration file difference data between the historical configuration file and the target configuration file; Obtain historical test process data generated based on the historical configuration file, wherein the historical test process data is a topology map generated based on the structured data corresponding to the historical configuration file; The historical test process data is updated based on the differences in the configuration file to obtain the test process data.

9. The method according to claim 1, characterized in that, The method further includes: If the test requirement information of the software under test is updated multiple times, a test task is generated based on the test process data corresponding to each test requirement information. In the event of processing conflicts among multiple test tasks, obtain the timestamp corresponding to each test task; From the multiple test tasks, select and execute the test task with the largest timestamp, discard and terminate the other test tasks.

10. A software testing apparatus, characterized in that, include: The data acquisition module is used to acquire the requirement change data corresponding to the software under test when the test requirement information of the software under test is updated. The timing diagram update module is used to update the test timing diagram corresponding to the software under test by adopting the timing diagram update method corresponding to the requirement change data, so as to obtain the updated test timing diagram. A configuration generation module is used to generate a target configuration file corresponding to the updated test timing diagram; The data conversion module is used to convert the target configuration file into test process data for software testing; The testing module is used to test the software under test based on the test process data.

Images