Self-service assembling and packaging method, device and equipment for software function module and storage medium
By adopting a component-based and dependency analysis model for software engineering, we have enabled the self-service assembly and packaging of software functional modules, which solves the problem of low testing efficiency, simplifies the testing process, and improves efficiency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-16
- Publication Date
- 2026-03-27
AI Technical Summary
Existing technologies require testers to have a deep understanding of the entire software engineering architecture when testing a single software functional module, resulting in low testing efficiency and high difficulty.
By componentizing software engineering, obtaining plugin information and invocation logic information, and using dependency analysis models to determine target plugins and their dependencies, the self-service assembly and packaging of functional modules can be achieved.
It reduces the difficulty of packaging functional modules, improves testing efficiency, and simplifies the testing process.
Smart Images
Figure CN121742850A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of software testing technology, and in particular to a self-assembly and packaging method, apparatus, device and storage medium for software functional modules. Background Technology
[0002] Testing the different functional modules involved in software engineering is an indispensable and crucial step in the software development process. Testing these modules ensures greater software stability and reduces the likelihood of system vulnerabilities.
[0003] Currently, with the increase and upgrading of the number of functions in a single software, when testing any function, the modules involved in that function are usually packaged as plugins. This process requires testers to have a good grasp of the architecture of the entire software project, which makes testers spend a lot of energy to complete the testing of a few or even a single function, resulting in low testing efficiency and high testing difficulty. Summary of the Invention
[0004] This application provides a self-assembly and packaging method, apparatus, device, and storage medium for software functional modules, so as to reduce the difficulty of packaging and testing functional modules and improve testing efficiency.
[0005] In a first aspect, embodiments of this application provide a self-service assembly and packaging method for software functional modules, the method comprising:
[0006] The software project containing the functions to be tested is componentized according to the functional modules to obtain the plugin information and the invocation logic information of each functional module.
[0007] When testing the function to be tested, the plugin information corresponding to each functional module of the software project is displayed on the front end, and the selection interaction information of the front end is obtained.
[0008] The target plugin corresponding to the function to be tested is determined based on the selected interaction information, and the analysis plugin dependency list of the target plugin is determined using a pre-trained dependency analysis model.
[0009] The dependent plugins of the target plugin are determined based on the analysis plugin dependency list, and the target plugin and the dependent plugins are packaged into a functional test package for the function to be tested.
[0010] Secondly, embodiments of this application provide a self-assembly and packaging device for software functional modules, the device comprising:
[0011] The componentization module is used to componentize a software project containing the functions to be tested according to the functional modules, and obtain the plugin information and the plugin invocation logic information corresponding to each functional module.
[0012] An interactive module is used to display the plugin information corresponding to each functional module of the software project on the front end when testing the function to be tested, and to obtain the selection interaction information of the front end.
[0013] The dependency analysis module is used to determine the target plugin corresponding to the function to be tested based on the selected interaction information, and to determine the analysis plugin dependency list of the target plugin using a pre-trained dependency analysis model.
[0014] The packaging module is used to determine the dependent plugins of the target plugin based on the analysis plugin dependency list, and package the target plugin and the dependent plugins into a functional test package for the function to be tested.
[0015] Thirdly, embodiments of this application also provide an electronic device, which includes:
[0016] One or more processors;
[0017] Storage device for storing one or more programs.
[0018] When one or more programs are executed by one or more processors, the one or more processors implement the self-assembly and packaging method for software functional modules as provided in any embodiment of this application.
[0019] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements a self-assembly and packaging method for software functional modules as provided in any embodiment of this application.
[0020] Fifthly, embodiments of this application also provide a computer program product, including a computer program / instruction, which, when executed by a processor, implements a self-assembly and packaging method for software functional modules as provided in any embodiment of this application.
[0021] The technical solution of this application embodiment involves componentizing a software engineering project containing the function to be tested according to functional modules, obtaining plugin information and plugin invocation logic information corresponding to each functional module; when testing the function to be tested, the plugin information corresponding to each functional module of the software engineering project is displayed on the front end, and the selection interaction information of the front end is obtained; the target plugin corresponding to the function to be tested is determined according to the selection interaction information, and the analysis plugin dependency list of the target plugin is determined using a pre-trained dependency analysis model; the dependent plugins of the target plugin are determined according to the analysis plugin dependency list, and the target plugin and the dependent plugins are packaged into a functional test package for the function to be tested. Based on this, by componentizing the software engineering project and analyzing the dependency relationships between functional module plugins using a dependency analysis model, the code of a single functional module can be packaged through the front end component display selection method, reducing the difficulty of packaging and improving testing efficiency. Attached Figure Description
[0022] Figure 1 A flowchart illustrating the self-assembly and packaging method for software functional modules provided in Embodiment 1 of this application;
[0023] Figure 2 This is a schematic diagram of the structure of a self-assembly and packaging device for software functional modules provided in Embodiment 2 of this application;
[0024] Figure 3 This is a schematic diagram of the structure of an electronic device provided in Embodiment 3 of this application. Detailed Implementation
[0025] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the application and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the present application are shown in the drawings, not the entire structure.
[0026] Example 1
[0027] Figure 1 A flowchart illustrating the self-assembly and packaging method for software functional modules provided in Embodiment 1 of this application is shown below. Figure 1 As shown, the self-service assembly and packaging method for software functional modules provided in this embodiment can be applied to a self-service assembly and packaging platform for software functional modules mounted on devices with data processing capabilities, such as computers. It can be used in conjunction with some application software to achieve a better user experience. Specifically, it can include the following steps:
[0028] Step 101: Componentize the software project containing the functions to be tested according to the functional modules to obtain the plugin information and the invocation logic information of each functional module.
[0029] In this step, the software engineering will include multiple functional modules. During development, you can directly develop and load the software according to the functional modules. Of course, for some non-newly developed software, you can modularize it later.
[0030] Specifically, independent functional module repositories can be created, with the main project only retaining the initialization framework and the logic for invoking each module. Java / Android projects can use Maven to depend on sub-repositories, while iOS projects can use the CocoaPods framework to manage versioning and compile dependencies on sub-repositories.
[0031] Each sub-repository can have its own simple shell project for testing. After the functionality is verified, the official plugin package is released to the dependency private repository. The main project can use the source code or binary form to directly depend on it.
[0032] After componentization, we can obtain the plugin information corresponding to each functional module. This plugin information includes the plugin name, plugin version, and the code sub-repository that the plugin depends on.
[0033] The plugin invocation logic information can include other plugins that a plugin depends on and needs to be invoked throughout its entire lifecycle, before, during, and after invocation.
[0034] Step 102: When testing the function to be tested, display the plugin information corresponding to each functional module of the software project on the front end, and obtain the selection interaction information of the front end.
[0035] In this step, the front end can be a rendered display interface. Human-computer interaction devices, such as keyboards, mice, touch screens, and touchpads, can be set up to acquire operation signals from testers.
[0036] When acquiring selection interaction information, the operation signals of the tester on the human-computer interaction device can be acquired, and the selection interaction information can be determined based on the display content of the front end and the operation signals.
[0037] Taking the keyboard and mouse as an example, testers can move the mouse to move the cursor in the display interface. When the cursor reaches the name of the plugin they want to select, they can click a mouse button to input the relevant signal for selecting the plugin, i.e., the operation signal. This operation signal can then be converted into interactive information for selecting the plugin.
[0038] Step 103: Determine the target plugin corresponding to the function to be tested based on the selected interaction information, and use a pre-trained dependency analysis model to determine the analysis plugin dependency list of the target plugin.
[0039] It should be noted that the latest plugin dependency list can be obtained in advance, and after the target plugin is identified, the initial dependent plugins of the target plugin can be determined based on the latest plugin dependency list.
[0040] The current latest plugin dependency list can be determined based on the aforementioned invocation logic information. Since this invocation logic information contains the plugins that need to be invoked during the complete lifecycle of each plugin, other plugins that have dependencies on the target plugin can be determined based on the content contained therein.
[0041] Because software engineering is constantly iterating and updating, functional modules are also constantly being updated, and therefore, dependencies may also change. Therefore, a pre-trained dependency analysis model can be used to determine the list of plugin dependencies for the target plugin.
[0042] Specifically, this dependency analysis model is mainly used to analyze whether its dependent plugins need version updates. Specifically, each application creates a separate session and uses a multi-turn dialogue to input the dependency list of the first-level plugins when packaging into the large model. Through multiple rounds of input, a panoramic dependency topology map of the application is built. In subsequent packaging, each time a node in the topology is selected, the dependency links of the same or lower level can be intelligently analyzed to produce a complete application dependency list, reducing the cost of manual analysis and improving accuracy.
[0043] Specifically, a separate session container can be created for each application to be analyzed, which isolates the dependency data and dialogue context of different applications. This session container incorporates a dependency analysis engine (based on a large language model) and a graph storage module, supporting multi-turn dialogue interactions.
[0044] Then, depending on the multiple rounds of input and topology construction, in a specific example, the first round of input is: submitting basic information about the application to the large model, including the application name, technology stack type (such as Java, Python, Node.js), root directory structure, and a list of first-level direct dependencies (such as dependencies declared in pom.xml and package.json).
[0045] The second round and subsequent inputs: Based on the analysis requests from the large model, submit detailed information about sub-dependencies layer by layer. For example, the model may request version details of a dependency, nested dependencies, system environment variables, or conditional dependency rules; the system responds and provides the corresponding data until the model confirms that it has obtained sufficient information.
[0046] Then, a topology graph is generated: Based on multiple rounds of input, the large model constructs a directed dependency graph with the application as the root node, where: nodes represent dependency packages (including version numbers); edges represent dependency relationships (including direct dependencies, transitive dependencies, and optional dependencies); and circular dependencies, conflicting dependencies, and platform-specific dependencies are marked in the graph.
[0047] Next, the panoramic dependency topology map is stored and updated. The generated dependency map is stored in a graph database (such as Neo4j) format, and each node records: dependency package identifier (Group ID, Artifact ID, Version); source level, license information, security vulnerability identifier (if any); dependency type (production / test / compile / runtime). When application dependencies change, the topology map is updated through incremental dialogue to ensure the timeliness of the map.
[0048] When performing intelligent node selection and dependency chain analysis, the user selects a node in the topology graph (e.g., "log4j-2.17.1") in the visualization interface during packaging. The system then starts the dependency analysis engine and performs the following intelligent analyses: Upstream tracing: Identifies all sibling dependencies of the selected node (i.e., nodes that are jointly depended on by the parent node); Downstream expansion: Recursively extracts all transitive dependency nodes of the selected node; Path filtering: Automatically prunes or retains branches based on the user-selected packaging strategy (e.g., minimal packaging, full packaging); Conflict detection: Checks for version conflicts in the associated paths of the selected node and provides resolution suggestions.
[0049] Finally, based on the analysis results, a structured dependency manifest is generated, which may include: a core dependency chain table (the path from the root node to the leaf node); a deduplicated, flat dependency list (including version and license); a hierarchical tree diagram of dependency packages; and conflict warnings and compatibility descriptions. The manifest can be exported to standardized formats (such as JSON, CSV, or SPDX) for direct use by packaging tools.
[0050] Additionally, during front-end page rendering and loading, the service's query interface is called to retrieve the latest dependency list for the corresponding project. Selecting the corresponding plugin name will display the latest version and update description of that plugin in the private repository. Other options include, but are not limited to, selecting the packaging branch and signing certificate.
[0051] After making your selections, submit the form to the packaging service. The service will process the subsequent logic based on the selected module information, generate a packaging record on the page, and generate a corresponding download QR code after the packaging is complete, and notify the triggering person.
[0052] Step 104: Determine the dependent plugins of the target plugin based on the analysis plugin dependency list, and package the target plugin and the dependent plugins into a functional test package for the function to be tested.
[0053] In this step, all plugins that the currently selected target plugin depends on can be determined based on the analysis plugin dependency list; supplementary dependency plugins that are not present in the initial dependency plugins but exist among the determined plugins can be identified; the initial dependency plugins and the supplementary dependency plugins are then identified as dependencies of the target plugin. The current latest plugin dependency list is updated using the analysis plugin dependency list determined by the dependency analysis model.
[0054] Specifically, the selected plugins (first-level dependencies) and their versions can be passed to the model to analyze whether their second-level dependencies need to be upgraded. For example, the interactively selected list and the original dependency list podfile can be passed to the large model to generate a new version of the podfile and return it.
[0055] In addition, after identifying the dependent plugins of the target plugin, it is determined whether the version of the dependent plugin matches the version of the target plugin; if not, the dependent plugin is upgraded to a version that matches the version of the target plugin.
[0056] As functional modules are upgraded, the other functional modules they depend on also need to be updated. Therefore, the corresponding functional modules need to be upgraded before being packaged to ensure that the functional modules can run normally during subsequent testing.
[0057] During the actual packaging process, the front-end page calls the packaging interface, carrying relevant information such as the application name, the triggerer, and the trigger time. While storing and generating an operation log, the main task is to process and parse the plugin version parameters. Through the interface of the third-party large model, it analyzes whether the selected plugin needs updates from other plugins. Finally, it obtains the full list of changed plugin names and version numbers, then pulls the latest repository code, obtains the dependency list file of the existing shell project, replaces the version number corresponding to the changed plugin name, and then starts the packaging command.
[0058] In this embodiment, the software engineering containing the function to be tested is componentized according to functional modules to obtain plugin information and plugin invocation logic information corresponding to each functional module. When testing the function to be tested, the plugin information corresponding to each functional module of the software engineering is displayed on the front end, and the selection interaction information of the front end is obtained. Based on the selection interaction information, the target plugin corresponding to the function to be tested is determined, and the analysis plugin dependency list of the target plugin is determined using a pre-trained dependency analysis model. Based on the analysis plugin dependency list, the dependent plugins of the target plugin are determined, and the target plugin and the dependent plugins are packaged into a functional test package for the function to be tested. Based on this, by componentizing the software engineering and analyzing the dependency relationships between functional module plugins using a dependency analysis model, the code of a single functional module can be packaged by displaying a selection on the front end, reducing the difficulty of packaging and improving testing efficiency.
[0059] Example 2
[0060] Figure 2 This is a schematic diagram of a self-assembly and packaging device for software functional modules provided in Embodiment 2 of this application. The self-assembly and packaging device for software functional modules provided in this embodiment can execute the self-assembly and packaging method for software functional modules provided in any embodiment of this application, and possesses the corresponding functional modules and beneficial effects of the method. This device can be implemented using software and / or hardware, such as... Figure 2 As shown, the self-service assembly and packaging device for software functional modules specifically includes: a componentization module 201, an interaction module 202, a dependency analysis module 203, and a packaging module 204.
[0061] The componentization module is used to componentize the software project containing the functions to be tested according to the functional modules, and obtain the plugin information and the plugin invocation logic information corresponding to each functional module.
[0062] An interactive module is used to display the plugin information corresponding to each functional module of the software project on the front end when testing the function to be tested, and to obtain the selection interaction information of the front end.
[0063] The dependency analysis module is used to determine the target plugin corresponding to the function to be tested based on the selected interaction information, and to determine the analysis plugin dependency list of the target plugin using a pre-trained dependency analysis model.
[0064] The packaging module is used to determine the dependent plugins of the target plugin based on the analysis plugin dependency list, and package the target plugin and the dependent plugins into a functional test package for the function to be tested.
[0065] Furthermore, the front end is equipped with a human-computer interaction device;
[0066] The interaction module includes:
[0067] The interaction unit is used to acquire the operation signals of the tester on the human-computer interaction device, and determine the selected interaction information based on the display content of the front end and the operation signals.
[0068] Example 3
[0069] Figure 3 This is a schematic diagram of the structure of an electronic device provided in Embodiment 3 of this application, as shown below. Figure 3 As shown, the electronic device includes a processor 310, a memory 320, an input device 330, and an output device 340; the number of processors 310 in the electronic device can be one or more. Figure 3 Taking a processor 310 as an example; the processor 310, memory 320, input device 330, and output device 340 in the electronic device can be connected via a bus or other means. Figure 3 Taking the example of a connection between China and Israel via a bus.
[0070] The memory 320, 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 self-assembly and packaging method for software functional modules in this embodiment of the invention. The processor 310 executes various functional applications and data processing of the electronic device by running the software programs, instructions, and modules stored in the memory 320, thereby implementing the aforementioned self-assembly and packaging method for software functional modules.
[0071] The software project containing the functions to be tested is componentized according to the functional modules to obtain the plugin information and the invocation logic information of each functional module.
[0072] When testing the function to be tested, the plugin information corresponding to each functional module of the software project is displayed on the front end, and the selection interaction information of the front end is obtained.
[0073] The target plugin corresponding to the function to be tested is determined based on the selected interaction information, and the analysis plugin dependency list of the target plugin is determined using a pre-trained dependency analysis model.
[0074] The dependent plugins of the target plugin are determined based on the analysis plugin dependency list, and the target plugin and the dependent plugins are packaged into a functional test package for the function to be tested.
[0075] Furthermore, the front end is equipped with a human-computer interaction device;
[0076] The step of obtaining the selection interaction information from the front end includes:
[0077] The system acquires the operation signals of the tester on the human-computer interaction device, and determines the selected interaction information based on the display content of the front end and the operation signals.
[0078] Furthermore, the method also includes:
[0079] Obtain the latest plugin dependency list, and after identifying the target plugin, determine the initial dependent plugins of the target plugin based on the latest plugin dependency list.
[0080] Furthermore, determining the dependent plugins of the target plugin based on the analysis plugin dependency list includes:
[0081] Based on the analysis of the plugin dependency list, determine all plugins that the currently selected target plugin depends on;
[0082] Determine which of the initial dependent plugins are not present but are present among all the identified plugins;
[0083] The initial dependency plugin and the supplementary dependency plugin are identified as the dependency plugins of the target plugin.
[0084] Furthermore, the method also includes:
[0085] After identifying the dependent plugins of the target plugin, determine whether the version of the dependent plugin is a version that matches the version of the target plugin;
[0086] If not, upgrade the dependent plugin to a version that matches the target plugin version.
[0087] Furthermore, the method also includes:
[0088] The current latest plugin dependency list is updated using the analysis plugin dependency list determined by the dependency analysis model.
[0089] The memory 320 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 320 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 320 may further include memory remotely located relative to the processor 310, 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.
[0090] Example 4
[0091] Embodiment 4 of this application also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform a self-assembly and packaging method for software functional modules. The method includes:
[0092] The software project containing the functions to be tested is componentized according to the functional modules to obtain the plugin information and the invocation logic information of each functional module.
[0093] When testing the function to be tested, the plugin information corresponding to each functional module of the software project is displayed on the front end, and the selection interaction information of the front end is obtained.
[0094] The target plugin corresponding to the function to be tested is determined based on the selected interaction information, and the analysis plugin dependency list of the target plugin is determined using a pre-trained dependency analysis model.
[0095] The dependent plugins of the target plugin are determined based on the analysis plugin dependency list, and the target plugin and the dependent plugins are packaged into a functional test package for the function to be tested.
[0096] Furthermore, the front end is equipped with a human-computer interaction device;
[0097] The step of obtaining the selection interaction information from the front end includes:
[0098] The system acquires the operation signals of the tester on the human-computer interaction device, and determines the selected interaction information based on the display content of the front end and the operation signals.
[0099] Furthermore, the method also includes:
[0100] Obtain the latest plugin dependency list, and after identifying the target plugin, determine the initial dependent plugins of the target plugin based on the latest plugin dependency list.
[0101] Furthermore, determining the dependent plugins of the target plugin based on the analysis plugin dependency list includes:
[0102] Based on the analysis of the plugin dependency list, determine all plugins that the currently selected target plugin depends on;
[0103] Determine which of the initial dependent plugins are not present but are present among all the identified plugins;
[0104] The initial dependency plugin and the supplementary dependency plugin are identified as the dependency plugins of the target plugin.
[0105] Furthermore, the method also includes:
[0106] After identifying the dependent plugins of the target plugin, determine whether the version of the dependent plugin is a version that matches the version of the target plugin;
[0107] If not, upgrade the dependent plugin to a version that matches the target plugin version.
[0108] Furthermore, the method also includes:
[0109] The current latest plugin dependency list is updated using the analysis plugin dependency list determined by the dependency analysis model.
[0110] Of course, the computer-executable instructions provided in the embodiments of this application are not limited to the above-described method operations, but can also execute related operations in the self-assembly and packaging method of software functional modules provided in any embodiment of this application.
[0111] Based on the above description of the implementation methods, those skilled in the art can clearly understand that this application 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 this application, in essence, 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 of the various embodiments of this application.
[0112] It is worth noting that in the embodiments of the above-mentioned device, 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 realized; 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 this application.
[0113] Example 5
[0114] This embodiment provides a computer program product, including a computer program / instructions, which, when executed by a processor, implements a self-assembly and packaging method for software functional modules provided in any embodiment of this application. Specifically, this method may include:
[0115] In response to a user's service queuing request, obtain the service information, user information, and the user's desired service point based on the service queuing request;
[0116] Based on the service information, at least one service point to be assigned is matched from all offline service points to provide the target service corresponding to the service information, and the service point expected by the user is identified as a service point to be assigned.
[0117] Based on service information and user information, a service evaluation is performed on each service point to be assigned, and the current service evaluation value of each service point to be assigned relative to the target service is obtained.
[0118] Based on the service evaluation value of each service point to be assigned, it is the optimal service point configured by the user for the target service.
[0119] Note that the above description is merely a preferred embodiment and the technical principles employed in this application. Those skilled in the art will understand that this application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments. Many other equivalent embodiments may be included without departing from the concept of this application, and the scope of this application is determined by the scope of the appended claims.
Claims
1. A self-assembly and packaging method for software functional modules, characterized in that, The method includes: The software project containing the functions to be tested is componentized according to the functional modules to obtain the plugin information and the invocation logic information of each functional module. When testing the function to be tested, the plugin information corresponding to each functional module of the software project is displayed on the front end, and the selection interaction information of the front end is obtained. The target plugin corresponding to the function to be tested is determined based on the selected interaction information, and the analysis plugin dependency list of the target plugin is determined using a pre-trained dependency analysis model. The dependent plugins of the target plugin are determined based on the analysis plugin dependency list, and the target plugin and the dependent plugins are packaged into a functional test package for the function to be tested.
2. The method according to claim 1, characterized in that, The front end is equipped with a human-computer interaction device; The step of obtaining the selection interaction information from the front end includes: The system acquires the operation signals of the tester on the human-computer interaction device, and determines the selected interaction information based on the display content of the front end and the operation signals.
3. The method according to claim 1, characterized in that, The method further includes: Obtain the latest plugin dependency list, and after identifying the target plugin, determine the initial dependent plugins of the target plugin based on the latest plugin dependency list.
4. The method according to claim 3, characterized in that, The step of determining the dependent plugins of the target plugin based on the analysis plugin dependency list includes: Based on the analysis of the plugin dependency list, determine all plugins that the currently selected target plugin depends on; Determine which of the initial dependent plugins are not present but are present among all the identified plugins; The initial dependency plugin and the supplementary dependency plugin are identified as the dependency plugins of the target plugin.
5. The method according to any one of claims 1-4, characterized in that, The method further includes: After identifying the dependent plugins of the target plugin, determine whether the version of the dependent plugin is a version that matches the version of the target plugin; If not, upgrade the dependent plugin to a version that matches the target plugin version.
6. The method according to claim 3, characterized in that, The method further includes: The current latest plugin dependency list is updated using the analysis plugin dependency list determined by the dependency analysis model.
7. A self-assembly and packaging device for software functional modules, characterized in that, The device includes: The componentization module is used to componentize a software project containing the functions to be tested according to the functional modules, and obtain the plugin information and the plugin invocation logic information corresponding to each functional module. An interactive module is used to display the plugin information corresponding to each functional module of the software project on the front end when testing the function to be tested, and to obtain the selection interaction information of the front end. The dependency analysis module is used to determine the target plugin corresponding to the function to be tested based on the selected interaction information, and to determine the analysis plugin dependency list of the target plugin using a pre-trained dependency analysis model. The packaging module is used to determine the dependent plugins of the target plugin based on the analysis plugin dependency list, and package the target plugin and the dependent plugins into a functional test package for the function to be tested.
8. The apparatus according to claim 7, characterized in that, The front end is equipped with a human-computer interaction device; The interaction module includes: The interaction unit is used to acquire the operation signals of the tester on the human-computer interaction device, and determine the selected interaction information based on the display content of the front end and the operation signals.
9. An electronic device, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the self-assembly and packaging method for software functional modules as described in any one of claims 1-6.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by the processor, the program implements the self-assembly and packaging method for software functional modules as described in any one of claims 1-6.