Software migration test method and device, equipment and storage medium

Abstract

The invention discloses a software migration test method and device, equipment and a storage medium, and belongs to the field of software development. The software migration test method comprises the following steps: acquiring a software information graph structure of software; determining operation dependence of the software according to the software information graph structure; generating a to-be-migrated installation package of the software according to the operation dependency; sending the installation package to be migrated to a migration test environment; performing a first operation test on the to-be-migrated installation package in the migration test environment; performing a second operation test on the to-be-migrated installation package passing the first operation test to obtain an operation test result; and generating a software migration test report according to the running test result. According to the method, the migration test can be performed in advance before software migration, so that the feasibility of software migration is determined, and the corresponding test report is generated.

Description

Technical Field

[0001] This application belongs to the field of information technology and software development, and specifically relates to a software migration testing method and apparatus, an electronic device, and a storage medium. Background Technology

[0002] As technology advances and business needs change, software migration becomes necessary when an existing operating environment can no longer permanently meet all software requirements, thus extending the software's lifespan. Software migration is typically a complex, time-consuming, and error-prone process, requiring manual intervention in many stages, including code review, code modification, and functional testing.

[0003] In related technologies, container technology or virtualization technology is commonly used for software migration. However, both of these solutions suffer from low compatibility, low automation, and insufficient code protection. Migration failures can result in a significant waste of human and time resources.

[0004] Therefore, how to determine the feasibility of software migration in advance has become an urgent problem to be solved. Summary of the Invention

[0005] The purpose of this application is to provide a software migration testing method that can solve the problem that a lot of manpower and time costs will be wasted if the software migration fails because the feasibility of the migration cannot be determined in advance.

[0006] Accordingly, embodiments of this application also provide a software migration testing device, an electronic device, and a storage medium to ensure the implementation and application of the above methods.

[0007] To solve the above-mentioned technical problems, this application is implemented as follows: In a first aspect, embodiments of this application provide a software migration testing method, the method comprising: Obtain the software information graph structure of the software; The runtime dependencies of the software are determined based on the software information graph structure; The software's installation package to be migrated is generated based on the runtime dependencies; Send the installation package to be migrated to the migration test environment; The installation package to be migrated is subjected to a first run test in the migration test environment; A second run test is performed on the installation package to be migrated that has passed the first run test, and the run test results are obtained. A software migration test report is generated based on the test results.

[0008] Optionally, before obtaining the software information graph structure of the software, the method includes: Obtain the software information of the software; the software information includes source code and runtime dependency information; The software information graph structure is generated based on the software information.

[0009] Optionally, before sending the installation package to be migrated to the migration test environment, the method includes: The development language of the software is determined based on the software information graph structure; The installation package to be migrated is encrypted according to the software's development language.

[0010] Optionally, encrypting the installation package to be migrated according to the software's development language includes: The bytecode of the installation package to be migrated is obfuscated according to the development language of the software. The encryption algorithm is invoked according to the software's development language to analyze the bytecode files in the installation package to be migrated; The software's development language is used to call a packer tool to encrypt the packaged files in the installation package to be migrated; The software code in the installation package to be migrated is compiled into native machine code according to the software's development language.

[0011] Optionally, the step of performing a second run test on the installation package to be migrated that has passed the first run test to obtain the run test results includes: Install the runtime dependencies from the installation package to be migrated into the migration test environment; the runtime dependencies include at least programming language dependencies, database dependencies, underlying dependencies, and third-party dependencies; The runtime dependencies to be tested are sequentially deleted from the installation package to be migrated, and a test installation package is generated; the runtime dependencies to be tested are any of the runtime dependencies that have been installed in the migration test environment; A second runtime test was performed on the test installation package to obtain the corresponding runtime test results; If the test result is runnable, update the installation package to be migrated to the test installation package, and return to the step of sequentially deleting the test dependencies from the installation package to be migrated and generating the test installation package; If the running test result is that the application is not running, delete any running dependency that is different from the running dependency to be tested from the installation package to be migrated, generate a test installation package, and return to perform a second running test on the test installation package to obtain the corresponding running test result.

[0012] Optionally, generating a software migration test report based on the test results includes: Determine the corresponding factors affecting software operation based on the test results. A software migration test report is generated based on the factors affecting software operation.

[0013] Optionally, after generating the software migration test report based on the test results, the method further includes: Remove the installation package to be migrated from the migration test environment.

[0014] Secondly, embodiments of this application provide a software migration testing apparatus, the apparatus comprising: The acquisition module is used to acquire the software information graph structure of the software; A runtime dependency determination module is used to determine the runtime dependencies of the software based on the software information graph structure. The module for generating installation packages to be migrated is used to generate installation packages to be migrated for the software based on the runtime dependencies. The sending module is used to send the installation package to be migrated to the migration test environment; The first runtime test module is used to perform a first runtime test on the installation package to be migrated in the migration test environment. The second runtime test module is used to perform a second runtime test on the installation package to be migrated that has passed the first runtime test, and obtain the runtime test results; The report generation module is used to generate a software migration test report based on the results of the test run.

[0015] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0016] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.

[0017] Compared with the prior art, the embodiments of this application have the following advantages: In this embodiment, by obtaining the software information graph structure, the software's runtime dependencies can be determined based on the software information graph structure. Then, a software installation package to be migrated can be generated based on the runtime dependencies, and the installation package to be migrated can be sent to a migration test environment. In the migration test environment, a first runtime test is performed on the installation package to be migrated. For the installation package to be migrated that passes the first runtime test, a second runtime test can be performed to obtain the runtime test results. Then, a software migration test report can be generated based on the runtime test results. By sending the corresponding installation package to be migrated to the migration test environment for runtime testing, the feasibility of software migration can be determined in advance based on the obtained software migration test report without performing actual software migration. This prevents the waste of a large amount of manpower and time costs caused by migration failure during the software migration process. Attached Figure Description

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

[0019] Figure 1 This is a flowchart illustrating the steps of an embodiment of a software migration testing method according to this application; Figure 2 This is a schematic diagram of the software information graph structure of an embodiment of the software migration testing method of this application; Figure 3 This is a schematic diagram of the installation package lightweighting process according to an embodiment of the software migration testing method of this application; Figure 4 This is a schematic diagram of the structure of a full software migration method according to an embodiment of the software migration testing method of this application; Figure 5 This is a structural block diagram of an embodiment of a software migration testing device according to this application. Detailed Implementation

[0020] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0022] As technology advances and business needs change, a single operating environment may no longer be able to permanently meet all software requirements. This necessitates software migration to extend the software's lifespan. Software migration refers to the process of moving application software from one adapted operating environment to another. Due to its complexity, migration is typically a lengthy, error-prone process, requiring manual intervention in many stages, including code review, code modification, and functional testing. Two common software migration methods are: container technology and virtualization technology. Container technology typically involves first containerizing the software to create a lightweight, portable image, which is then loaded and run in the target environment to achieve the migration goal. Virtualization technology involves creating a target virtual machine on a virtualization platform, configuring its resources and network, and migrating the operating system, applications, and data from the source environment to the target virtual machine.

[0023] However, not all software can be containerized, and not all migration needs can be met through virtual machines. Container technology and virtualization solutions suffer from low compatibility, easily leading to migration failures. Furthermore, software containerization and virtual machine configuration largely rely on manual processes. If a migration fails at a specific step, engineers cannot identify further risks. Even if the current migration step is overcome, subsequent failures may occur, wasting significant human and time resources. To address, or at least partially address, the problems in these technologies, this application proposes a software migration testing method, apparatus, device, and storage medium.

[0024] The software migration testing method, apparatus, device, and storage medium provided in this application will be described in detail below with reference to the accompanying drawings and through specific embodiments and application scenarios.

[0025] Reference Figure 1 This is a flowchart illustrating the steps of an embodiment of a software migration testing method according to this application, including the following steps: Step 101: Obtain the software information graph structure of the software; Among them, the software information graph structure can be a graph structure mapped from software information, used to store the software information corresponding to the software in the form of a graph data structure.

[0026] Step 102: Determine the runtime dependencies of the software based on the software information graph structure; Software runtime dependencies can refer to external components, libraries, or services required for the software to function properly.

[0027] Step 103: Generate the software installation package to be migrated based on the runtime dependencies; The installation package to be migrated can be a software installation package that contains all the runtime dependencies required for the software to run.

[0028] Step 104: Send the installation package to be migrated to the migration test environment; The migration test environment can be a separate memory space allocated in the target environment to which the software is to be migrated, used for software migration testing.

[0029] Step 105: Perform a first run test on the installation package to be migrated in the migration test environment; Step 106: Perform a second run test on the installation package to be migrated that has passed the first run test, and obtain the run test results; Step 107: Generate a software migration test report based on the test results.

[0030] A software information graph structure mapped from the software's information can be obtained. Based on this graph, the runtime dependencies required for the software's normal operation can be determined. Then, a migration installation package can be generated based on these dependencies and sent to a migration test environment in the target environment. The migration installation package includes all runtime dependencies, enabling the software to run independently to the greatest extent possible. A first runtime test can be performed on the migration installation package in the migration test environment. Packages that pass the first test can undergo a second runtime test to obtain the results. A software migration test report can then be generated based on these results. By generating the corresponding migration installation package and sending it to the migration test environment for testing, the feasibility of software migration can be determined in advance based on the obtained software migration test report without performing actual software migration. Potential problems that may arise during the migration process can be identified early, preventing significant waste of manpower and time due to migration failures. Furthermore, the above software migration testing process can be automated, greatly reducing the manpower required for the initial feasibility assessment.

[0031] In one embodiment of this application, before obtaining the software information graph structure of the software, the method includes: Obtain the software information of the software; the software information includes source code and runtime dependency information; The software information graph structure is generated based on the software information.

[0032] Source code, or the software's source code itself, is an uncompiled text file written in a programming language; it's a series of human-readable computer language instructions. The form of source code may differ depending on the programming language used. When using Java, source code typically exists as a JAR (Java Archive) package or Java class files (bytecode files). Runtime dependency information can include dependencies such as development language dependencies, database dependencies, underlying dependencies, and third-party dependencies required for the software to run. Development language dependencies are the necessary files that support the software code's execution in the environment. For Java, the corresponding development language dependency is the JDK (Java Development Kit), which includes the Java runtime environment and Java development tools. For C, the corresponding development language dependency is the standard library. If the software itself does not contain the corresponding development language dependencies, they must be extracted from the original environment to ensure the software runs correctly. Database dependencies are the databases that the software requires to run. Low-level dependencies refer to all the underlying files that support the software's execution. For example, if the software runs on Linux (the operating system kernel) and uses the screen (terminal multiplexing manager) function, then the screen executable file and its required low-level files, such as libtinfo.so.5, are low-level dependencies of the corresponding software. Third-party dependencies refer to external resources introduced during the software's execution, such as code libraries, frameworks, toolkits, and other components provided by external developers or organizations. For example, for software developed in Java, third-party dependencies might refer to third-party JAR packages required to execute the code; for software developed in C, third-party dependencies might refer to third-party libraries that provide advanced functionality not covered by the standard library.

[0033] The software to be migrated can be analyzed within its source environment to obtain software information. This information is then input into a graph database, and corresponding nodes and relationships are created based on this information, thereby generating a corresponding software information graph structure. For example, Neo4j graph database can be used to generate and maintain the software information graph structure; other graph databases can also be used, and this application does not impose specific limitations. The software information graph structure can consist of nodes, relationships, and attribute labels. Different nodes correspond to different software information and possess different attributes. Through the above implementation process, the software's source code and various runtime dependencies can be mapped into a graph structure. The generated software information graph structure can intuitively demonstrate the modeling of various dependencies corresponding to software operation to technical personnel, facilitating the maintenance and expansion of software information from a global perspective at any time. Furthermore, the graph database has efficient relational query capabilities, which helps in the rapid location of dependencies during software migration testing.

[0034] Reference Figure 2 This is a schematic diagram of the software information graph structure of an embodiment of the software migration testing method of this application. Figure 2 The graph is constructed from the software information of a relatively simple Java application (the software to be migrated) running on a Linux environment. Labels and structures can be defined in the Neo4j graph database using Java code. After defining the labels and structure, the software information can be input into the Neo4j graph database to generate a graph like this. Figure 2The software information diagram structure is shown below. The software information of the software to be migrated includes software code (source code), development language dependencies, underlying dependencies, database dependencies, and third-party dependencies. Specifically, the software code includes multiple .class files; development language dependencies include multiple JDK files; underlying dependencies may include screen, glibc_16 (C runtime library), libpthread library (thread shared library), etc., with screen having its own dependent executable files; the database may be SQL Server (relational database), with SQL Server having its own dependent database files; third-party dependencies may include SpringMVC (Spring Model-View-Controller, the Model-View-Controller pattern in the Spring framework), netty.jar (Java archive file for the Netty framework), log4j.jar (core library file of the Java logging framework), etc., with netty.jar and log4j.jar having their own dependent .so files (shared object files). Furthermore, each type of software information has its corresponding attribute tags. The attribute tags for software code can include information type, a boolean type indicating whether it has been added, compatibility status, error messages, etc.; the attribute tags for development language dependencies can include information type, a boolean type indicating whether it has been added, programming language type, language version, compatibility status, error messages, etc.; the attribute tags for underlying dependencies can include information type, a boolean type indicating whether it has been added, dependency name, dependency version, compatibility status, error messages, etc.; the attribute tags for database dependencies can include information type, a boolean type indicating whether it has been added, file type, compatibility status, error messages, etc.; and the attribute tags for third-party dependencies can include information type, a boolean type indicating whether it has been added, third-party dependency name, dependency file, compatibility status, error messages, etc.

[0035] For example, after obtaining the software information graph structure, the runtime dependencies of the software can be determined based on the software information contained in the structure. Suppose the software migration involves moving the software from the original environment A to the target environment B. The software is developed in Java and requires JDK 11 to run. However, the original software installation package does not contain a JDK, and the software depends on the JDK on the original environment A. Therefore, when generating the installation package to be migrated, the JDK 11 from the original environment A should be included in the package, and the relevant calls should be modified accordingly. This ensures that the software can run normally even without a JDK in the target environment B. Through this process, the original software installation package can be modified so that the newly generated installation package to be migrated includes all the runtime dependencies required for the software migration, maximizing the chances of the software running independently in the target environment.

[0036] In one embodiment of this application, before sending the installation package to be migrated to the migration test environment, the method includes: The development language of the software is determined based on the software information graph structure; The installation package to be migrated is encrypted according to the software's development language.

[0037] After generating the installation package to be migrated, the software's development language can be determined based on the software information graph structure, and the installation package can be encrypted according to the software's development language. If the software itself does not have its code protected, directly migrating the software through containerization or virtualization technology may result in the source code being prematurely exposed to an unsuitable runtime environment, causing risks. The above implementation process can improve the security of software migration testing or the software migration process, preventing code leaks during the process.

[0038] In one embodiment of this application, encrypting the installation package to be migrated according to the software's development language includes: The bytecode of the installation package to be migrated is obfuscated according to the development language of the software. The encryption algorithm is invoked according to the software's development language to analyze the bytecode files in the installation package to be migrated; The software's development language is used to call a packer tool to encrypt the packaged files in the installation package to be migrated; The software code in the installation package to be migrated is compiled into native machine code according to the software's development language.

[0039] Bytecode obfuscation can be performed on the installation package to be migrated based on the software's development language. Bytecode obfuscation refers to the technique of increasing the difficulty of reverse engineering by modifying the mutated bytecode files. Different bytecode obfuscation methods can be applied based on the software's development language. For Java, name obfuscation can be performed by renaming classes, methods, and fields to meaningless characters, removing debugging information and inserting redundant instructions, or encrypting sensitive strings to increase the difficulty of decompilation. For C, control flow obfuscation can be indirectly achieved through code optimization using a compiler. For Python, .py files can be compiled and then packaged and obfuscated using PyInstaller, or name obfuscation can be performed by renaming function and variable names. There are also various obfuscation methods for other development languages, which this application does not specifically limit. Commonly used bytecode obfuscation tools include ProGuard and Allatori.

[0040] The encryption algorithm can be invoked based on the software's development language to access the bytecode files in the installation package to be migrated. For example, AES (Advanced Encryption Standard) or RSA algorithms can be used to encrypt class files, which can then be decrypted and loaded at runtime using a custom ClassLoader. Furthermore, different development languages ​​have varying levels of support for computation and key management, resulting in different performance levels. The specific design can be tailored to the specific needs of the application, and this application does not impose any particular limitations in this regard.

[0041] The packer tool can be invoked to encrypt the packaged files in the installation package to be migrated, depending on the software's development language. For example, existing packers such as Virbox Protector and XJar can be used. For statically typed languages ​​like C / C++ and Delphi, the packer tool can directly encrypt the files in the installation package to be migrated. For dynamic languages ​​like Python and Java, the files in the installation package to be migrated can first be packaged into an executable file, and then the packer tool can be used to encrypt the packaged file, generating a standalone executable file that requires a specific environment or license to run.

[0042] Furthermore, based on the software's development language, the corresponding compiler or interpreter can be used to compile the software code in the installation package to be migrated into native machine code. For example, tools such as GraalVM (High-Performance General-Purpose Virtual Machine) can be used to pre-compile Java code into native machine code, eliminating bytecode characteristics. Through the above implementation process, various encryption methods can be applied to the installation package to be migrated based on the software's development language. Compared to container technology and virtualization technology commonly used in related technologies that do not process the software code, this application can protect the source code from being prematurely exposed to an unsuitable runtime environment for migration, improving the security of software migration testing or the software migration process, and preventing code leakage during the process.

[0043] For example, the migration test environment can be a separate memory space allocated within the target environment to be migrated to, using virtualization or container technology, specifically for migration testing. If container technology is used, a separate container can be created using Docker (an application container engine) to serve as the migration test environment, for example, by executing the command "docker run -it --memory=512m your-image". If virtualization technology is used, a virtual machine can be used to directly allocate a dedicated memory segment as the migration test environment. Performing migration tests in a dedicated test environment within the target environment eliminates the need for a third-party test environment, thus improving the security and accuracy of software migration tests.

[0044] For example, after sending the installation package to be migrated to the migration test environment, a first run test can be performed on the installation package in the migration test environment. This first run test is used to evaluate the quality of the generated installation package containing all runtime dependencies. In the migration test environment, the corresponding software can be run based on the installation package to be migrated, and then relevant functional tests can be performed to determine whether the database required by the software can be installed and used normally in the target environment; whether the software development language dependencies can be installed correctly in the target environment; whether the target environment is compatible with the underlying dependencies required by the software; whether the target environment is compatible with the third-party dependencies required by the software; and whether each function of the software can be used normally. Through the above implementation process, performing a first run test on the installation package to be migrated in the migration test environment can verify whether the generated installation package to be migrated can support the normal operation of the software in the target environment.

[0045] In one embodiment of this application, the step of performing a second run test on the installation package to be migrated that has passed the first run test to obtain the run test results includes: Install the runtime dependencies from the installation package to be migrated into the migration test environment; the runtime dependencies include at least programming language dependencies, database dependencies, underlying dependencies, and third-party dependencies; The runtime dependencies to be tested are sequentially deleted from the installation package to be migrated, and a test installation package is generated; the runtime dependencies to be tested are any of the runtime dependencies that have been installed in the migration test environment; A second runtime test was performed on the test installation package to obtain the corresponding runtime test results; If the test result is runnable, update the installation package to be migrated to the test installation package, and return to the step of sequentially deleting the test dependencies from the installation package to be migrated and generating the test installation package; If the running test result is that the application is not running, delete any running dependency that is different from the running dependency to be tested from the installation package to be migrated, generate a test installation package, and return to perform a second running test on the test installation package to obtain the corresponding running test result.

[0046] If the installation package to be migrated passes the first runtime test, the runtime dependencies contained in the installation package can be installed into the migration test environment based on the graph information in the software information graph structure, and the files added to the installation package can be converted to support the target environment. Runtime dependencies include at least programming language dependencies, database dependencies, underlying dependencies, and third-party dependencies. Then, the runtime dependencies to be tested can be deleted sequentially from the installation package to be migrated, generating a test installation package. The runtime dependencies to be tested are any runtime dependencies already installed in the migration test environment. For example, assuming the software requires JDK 11 for runtime support, JDK 11 can be installed in the migration test environment and related calls modified. Afterwards, the temporarily added JDK file in the installation package to be migrated can be deleted, and other runtime dependencies can be deleted sequentially. Then, a second runtime test can be performed on the generated test installation package to determine whether the test installation package can support the software to run normally in the target environment, obtaining the corresponding runtime test results. The runtime test results can include whether the software is runnable or not.

[0047] If the run test result is "runnable," it means that after installing the runtime dependencies included in the installation package to be migrated to the migration test environment, the runtime dependencies to be tested removed from the installation package will not affect the normal operation of the software in the migration test environment. Correspondingly, the installation package to be migrated can be updated to a test installation package, achieving a lightweight approach. The process of sequentially deleting the runtime dependencies to be tested from the installation package to be migrated and generating the test installation package is then returned. If the run test result is "not runnable," it means that after installing the runtime dependencies included in the installation package to the migration test environment, the runtime dependencies to be tested removed from the installation package will still affect the normal operation of the software in the migration test environment. This runtime dependency to be tested is incompatible with the target environment. Correspondingly, this runtime dependency to be tested can be retained, and any other runtime dependency different from the runtime dependency to be tested can be deleted from the installation package to be migrated, generating a new test installation package. The process of performing a second run test on the test installation package is then returned, and the corresponding run test results are obtained. The second run test for the installation package to be migrated can be completed after all runtime dependencies in the installation package to be migrated have undergone a deletion operation and the corresponding second run test has been completed. If all runtime dependencies are packaged into the software installation package during software migration, the package size will increase significantly, impacting migration efficiency and making maintenance difficult. Internal errors in runtime dependencies may also be attributed to errors in the main program, increasing debugging complexity. Through the above implementation process, after all second-run tests are completed, a single installation package capable of supporting software operation in the migration test environment can be obtained. This package allows for the identification of the minimum set of runtime dependencies necessary to ensure successful migration, resulting in a lighter installation package while maintaining software compatibility. Furthermore, second-run tests targeting each runtime dependency can quickly pinpoint incompatibilities during the migration process.

[0048] For example, the second runtime test may include, but is not limited to, environment compatibility checks, resource requirement assessments, runtime behavior verification, and migration impact quantification. Environment compatibility checks may include dependency library verification, file system permission verification, and system call interception analysis; resource requirement assessments may include storage I / O performance testing, memory usage analysis and testing, and CPU instruction set compatibility testing; runtime behavior verification may include network testing, communication testing, security testing, and functional testing; migration impact quantification may include performance testing and functional integrity testing. The second runtime test for different types of software can be set according to the software's migration and runtime requirements, and this application does not impose specific limitations on this. The first and second runtime tests can be performed by directly running the software to test its functionality and analyze errors, or by using independent test cases to perform targeted testing on a portion of the software, determining the corresponding runtime test results based on the test case execution results; this application does not impose specific limitations on this either.

[0049] For example, after performing a second run test on the test installation package and obtaining the corresponding run test results, the process can return to the step of sequentially deleting the runtime dependencies to be tested from the installation package to be migrated, and generating a test installation package, regardless of whether the run test result is runnable or not. Each time, only the test installation package generated after deleting one of the runtime dependencies to be tested is run a second time, and finally, the minimum set of runtime dependencies that can ensure the normal migration of the software is determined based on the corresponding run test results.

[0050] For example, suppose we want to migrate software from its original environment 1 to a target environment 2. The software requires dependencies A, B, C, and D to function correctly in the original environment 1. These dependencies A, B, C, and D are present in the original environment 1 but not in the software installation package. Now, we want to migrate the software to the target environment 2, where A, B, and C are present but D is absent. In this case, we can first package the software itself along with its dependencies A, B, C, and D into a migration installation package, and then migrate it together to the target environment 2. Then, through a second runtime test, we can gradually try removing A, B, C, and D. Ultimately, we can find that the software itself, with dependency D added, can function correctly in the target environment 2. Therefore, the minimum set of runtime dependencies that guarantees successful software migration is runtime dependency D. The suggested migration solution is to generate a migration installation package by adding runtime dependency D to the software itself, and then migrate it to the target environment 2.

[0051] In one embodiment of this application, generating a software migration test report based on the test results includes: Determine the corresponding factors affecting software operation based on the test results. A software migration test report is generated based on the factors affecting software operation.

[0052] Among them, software operation influencing factors refer to factors that prevent software from running in a certain environment. There are many factors that affect software operation, including but not limited to: restricted system calls, such as the absence of some low-level commands or required low-level files in certain special environments; missing environment variables; missing binary files; inappropriate addresses / IPs in configuration files; lack of permissions; incompatible kernel versions; conflicting dependency libraries (GLIBC versions, etc.); insufficient resources; security policy constraints that limit functionality; and unsupported network.

[0053] The software migration test report can be a summary of all test results, and may include migration feasibility, the main reasons for migration failure, environmental difference analysis, security compliance check results, whether there are incompatible syntaxes, whether there are unusable dependency libraries, encryption algorithms, certificate protocol compatibility test results, performance test results, resource consumption test results, and whether manual adjustments are needed if migration is attempted. Migration feasibility may include assessments such as full support, partial support, and incompatibility. The software migration test report can be presented in text, diagrammatic structure, or a combination of both; this application does not impose specific limitations in this regard.

[0054] If the run test result is "unworkable," it means that the runtime dependencies deleted during the second run test will affect the software's operation in the migration test environment, i.e., the target environment. The run test results can be used to identify the corresponding factors affecting software operation. Then, the influencing factors and the corresponding second run test process are analyzed separately, ultimately generating a software migration test report. During the migration of software to a new environment, failures may occur due to various reasons, including missing third-party dependencies, missing underlying file support, and code incompatibility. Through the above implementation process, before the formal migration, software migration testing can identify the factors affecting software operation and generate a software migration test report recording all specific error information during the testing process. This provides users with comprehensive and powerful reference information for software migration, enabling them to determine the feasibility of the migration in advance, discover potential problems during the migration process, and avoid wasting manpower and time due to direct and failed migration. Simultaneously, the software migration test report can also provide a reference for the formulation and modification of the migration plan for the formal software migration.

[0055] For example, while generating the software migration test report, error information and compatibility data obtained from analyzing the second run test process can be used to update the software information graph structure. The node attribute labels in the graph can then be used to maintain the compatibility of each part of the software with the target environment, error information, etc. The software information graph structure constructs the complete composition structure and runtime dependency information of the software to be migrated. Updating the software information graph allows users to more intuitively obtain the test results corresponding to various types of information in the software.

[0056] In one embodiment of this application, after generating a software migration test report based on the run test results, the method further includes: Remove the installation package to be migrated from the migration test environment.

[0057] Software migration is typically a complex process, requiring feasibility verification through various methods and confirmation of detailed migration steps before actually commencing. After generating a software migration test report, the feasibility of the migration has been tested. At this point, the entire migration process can be rolled back, including: removing the installation package to be migrated from the migration test environment; uninstalling runtime dependencies installed to adapt the software from the migration test environment; deleting runtime dependency files downloaded to adapt the software from the migration test environment; and clearing related processes and runtime files for software migration testing. Through this process, even if the software is completely incompatible with the target environment, the migration test environment can be completely reverted to its pre-migration state, reducing the risk of code leakage.

[0058] Reference Figure 3 This is a schematic diagram of the lightweighting process of the installation package in an embodiment of the software migration testing method of this application.

[0059] Step 301: The installation package lightweighting module can perform lightweighting on software installation packages containing all runtime dependencies, i.e., the installation packages to be migrated. Each lightweighting process can remove one of the various types of runtime dependencies in the software installation package at once, such as third-party dependencies, underlying dependencies, and database dependencies. Step 302: The lightweight installation package can be submitted to the runtime evaluation module for a second runtime test; Step 303: Determine whether the evaluation is passed based on the evaluation results output by the operation evaluation module; Step 3031: If the evaluation is passed, proceed to step 304; Step 3032: If the evaluation fails, proceed to step 301, where the lightweight installation package module will continue to delete the next runtime dependency in the software installation package. Step 304: Determine whether the evaluation of the software installation package is complete. The condition for determining the completion of the evaluation is that each runtime dependency in the software installation package has undergone a deletion operation. Step 3041: Upon completion of the evaluation, generate a migration report (i.e., a software migration test report) and completely revert the migration test environment to its state before the migration. If the evaluation is not yet complete, step 3042 jumps to step 301, where the lightweight installation package module continues to delete the next runtime dependency in the software installation package.

[0060] Reference Figure 4 This is a schematic diagram of the structure of a full software migration method according to an embodiment of the software migration testing method of this application.

[0061] In one embodiment of this application, the software migration testing method is applied simultaneously to the original environment where the software is currently located and the target environment to which the software is to be migrated. The original environment includes an information collection module, an installation package modification module, and a migration module, while the target environment includes a migration module, a runtime evaluation module, and an installation package lightweighting module. In addition, a rollback module and a Neo4j database are also provided for migration testing of the application software from the original environment to the target environment.

[0062] The information collection module can collect software structure information (software information) of the software in the original environment where the software to be migrated is installed, including the software code, development language dependencies, database, underlying dependencies and third-party dependencies; The information collection module can inject the collected software structure information into a predefined Neo4j database. The Neo4j database generates and maintains the corresponding topology (i.e., software information graph structure). The topology will include the following factors: the software's own code, the software's third-party dependencies, the underlying files, executable binary files, library files, the JDK required by the software, the database required by the software, the permissions required by the software, the memory resources required by the software, etc. The installation package modification module can receive software information sent by the information collection module and topology structure sent by the Neo4j database, and modify the original software installation package according to the received content. It adds all the runtime dependencies required for the software to run into the software installation package, and then submits the modified software installation package (i.e. the installation package to be migrated) to the migration module. The migration module is responsible for sending the modified software installation package from the original environment to the target environment. It is usually sent to a memory space in the target environment that is separately allocated for migration testing. The evaluation module will refer to the topology provided by the Neo4j database to evaluate whether the software can run stably in the target environment. This evaluation is carried out through multiple running tests. The first evaluation is of the full software installation package modified by the installation package modification module, corresponding to the first running test mentioned above. If the first evaluation passes, the lightweighting module of the installation package will refer to the topology provided by the Neo4j database to perform lightweighting operations on the software installation package. The lightweighting operation refers to deleting the runtime dependencies contained in the software installation package one by one in each lightweighting operation. Each lightweighting operation will be re-evaluated, corresponding to the second runtime test mentioned above, until all the later added dependencies in the software installation package have been tested in the second runtime test. Then the lightweighting operation of the software installation package can be stopped and the error information collected during the test will be sent to the runtime evaluation module. After receiving error messages from the lightweight installation package module, the runtime evaluation module can summarize and analyze the error messages and generate a migration report (software migration test report). The rollback module is responsible for rolling back the entire migration process. After completing the software migration test, it completely rolls back the target environment to its pre-migration state.

[0063] Through the above implementation process, based on the information such as software code, third-party dependencies, databases and underlying dependencies maintained by the graph structure, operations such as installation, evaluation and lightweighting can be automatically performed in the target environment, thereby outputting a detailed migration report, allowing users to determine the feasibility of migration before the formal software migration.

[0064] It should be noted that the software migration testing method provided in this application embodiment can be executed by a software migration testing device, or a control module within the software migration testing device for executing the method of loading software migration testing. This application embodiment uses the execution of the method of loading software migration testing by a software migration testing device as an example to illustrate the software migration testing method provided in this application embodiment.

[0065] Based on the above embodiments, this embodiment also provides a software migration testing device, which can be applied to electronic devices such as terminal devices and servers.

[0066] Reference Figure 5 The diagram shows a structural block diagram of an embodiment of a software migration testing apparatus according to this application, which may specifically include the following modules: The acquisition module is used to acquire the software information graph structure of the software; A runtime dependency determination module is used to determine the runtime dependencies of the software based on the software information graph structure. The module for generating installation packages to be migrated is used to generate installation packages to be migrated for the software based on the runtime dependencies. The sending module is used to send the installation package to be migrated to the migration test environment; The first runtime test module is used to perform a first runtime test on the installation package to be migrated in the migration test environment. The second runtime test module is used to perform a second runtime test on the installation package to be migrated that has passed the first runtime test, and obtain the runtime test results; The report generation module is used to generate a software migration test report based on the results of the test run.

[0067] The software migration testing device also includes: The software information acquisition module is used to acquire the software information of the software; the software information includes source code and runtime dependency information. A software information graph structure generation module is used to generate the software information graph structure based on the software information.

[0068] The software migration testing device also includes: A development language determination module is used to determine the development language of the software based on the software information graph structure; An encryption module is used to encrypt the installation package to be migrated according to the development language of the software.

[0069] The encryption module is further used for: The bytecode of the installation package to be migrated is obfuscated according to the development language of the software. The encryption algorithm is invoked according to the software's development language to analyze the bytecode files in the installation package to be migrated; The software's development language is used to call a packer tool to encrypt the packaged files in the installation package to be migrated; The software code in the installation package to be migrated is compiled into native machine code according to the software's development language.

[0070] The second test module includes: The installation submodule is used to install the runtime dependencies in the installation package to be migrated into the migration test environment; the runtime dependencies include at least the development language dependencies, database dependencies, underlying dependencies, and third-party dependencies; The test installation package generation submodule is used to sequentially delete the runtime dependencies to be tested from the installation package to be migrated and generate the test installation package; the runtime dependencies to be tested are any of the runtime dependencies already installed in the migration test environment; The second runtime test submodule is used to perform a second runtime test on the test installation package and obtain the corresponding runtime test results. The test installation package update submodule is used to update the installation package to be migrated to the test installation package when the run test result is runnable, and return to the step of sequentially deleting the runtime dependencies to be tested from the installation package to be migrated to generate the test installation package; when the run test result is not runnable, it deletes any runtime dependency different from the runtime dependencies to be tested from the installation package to be migrated to generate the test installation package, and returns to the step of performing a second run test on the test installation package to obtain the corresponding run test result.

[0071] The report generation module includes: The software operation influencing factor determination submodule is used to determine the corresponding software operation influencing factors based on the operation test results; The software migration test report generation submodule is used to generate a software migration test report based on the factors affecting software operation.

[0072] The software migration testing device also includes: The rollback module is used to remove the installation package to be migrated from the migration test environment.

[0073] The software migration testing device in this application embodiment can be a device. This device can be a mobile electronic device or a non-mobile electronic device. For example, a mobile electronic device can be a mobile phone, tablet computer, laptop computer, PDA, in-vehicle electronic device, wearable device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc. A non-mobile electronic device can be a server, network attached storage (NAS), personal computer (PC), television (TV), ATM, or self-service machine, etc. This application embodiment does not specifically limit the device.

[0074] The software migration testing device in this application embodiment can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit the specific operating system used.

[0075] The software migration testing apparatus provided in this application embodiment can achieve… Figures 1 to 4 The various processes implemented by the software migration testing device in the method embodiment will not be described again here to avoid repetition.

[0076] This application provides a software migration testing apparatus that can acquire a software information graph structure mapped from the software information of the software. Based on this graph, it determines the runtime dependencies required for the software's normal operation. Then, it generates a software installation package to be migrated based on these dependencies and sends it to a migration testing environment established in the target environment. The installation package includes all runtime dependencies required for the software to run, enabling the software to operate independently to the greatest extent possible. A first runtime test can be performed on the installation package in the migration testing environment. Packages that pass the first test can undergo a second runtime test to obtain the test results. A software migration test report can then be generated based on these results. By sending the corresponding installation package to the migration testing environment for runtime testing, the feasibility of software migration can be determined in advance based on the obtained software migration test report without actual software migration. This allows for the early detection of potential problems during the migration process, preventing significant waste of manpower and time due to migration failures. Furthermore, the software migration testing process can be automated, greatly reducing the manpower required for preliminary feasibility assessments.

[0077] Optionally, embodiments of this application also provide an electronic device, including a processor, a memory, and a program or instructions stored in the memory and executable on the processor. When the program or instructions are executed by the processor, they implement the various processes of the above-described software migration testing method embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0078] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.

[0079] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described software migration testing method embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0080] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0081] It should be noted that, in this document, 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 one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0082] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by 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 is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0083] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A software migration testing method, characterized by, The method comprises: acquiring a software information graph structure of the software; determining a running dependency of the software according to the software information graph structure; generating a to-be-migrated installation package of the software according to the running dependency; sending the to-be-migrated installation package to a migration test environment; performing a first running test on the to-be-migrated installation package in the migration test environment; performing a second running test on the to-be-migrated installation package that passes the first running test to obtain a running test result; generating a software migration test report according to the running test result.

2. The method of claim 1, wherein, Before the acquiring of the software information graph structure of the software, the method comprises: acquiring software information of the software; the software information comprises source code and running dependency information; generating the software information graph structure according to the software information.

3. The method of claim 1, wherein, Before the sending of the to-be-migrated installation package to the migration test environment, the method comprises: determining a development language of the software according to the software information graph structure; encrypting the to-be-migrated installation package according to the development language of the software.

4. The method of claim 3, wherein, The encrypting of the to-be-migrated installation package according to the development language of the software comprises: performing bytecode obfuscation on the to-be-migrated installation package according to the development language of the software; calling an encryption algorithm to encrypt bytecode files in the to-be-migrated installation package according to the development language of the software; calling a shell tool to encrypt packaged files in the to-be-migrated installation package according to the development language of the software; compiling software code in the to-be-migrated installation package into local machine code according to the development language of the software.

5. The method of claim 1, wherein, The performing of the second running test on the to-be-migrated installation package that passes the first running test to obtain a running test result comprises: installing running dependencies in the to-be-migrated installation package into the migration test environment; the running dependencies at least comprise development language dependencies, database dependencies, underlying dependencies and third-party dependencies; sequentially deleting to-be-tested running dependencies from the to-be-migrated installation package to generate a test installation package; the to-be-tested running dependencies are any of the running dependencies that have been installed into the migration test environment; performing a second running test on the test installation package to obtain a corresponding running test result; in a case where the running test result is runnable, updating the to-be-migrated installation package to the test installation package, and returning to the sequentially deleting of the to-be-tested running dependencies from the to-be-migrated installation package to generate the test installation package; in a case where the running test result is not runnable, deleting any of the running dependencies that is different from the to-be-tested running dependencies from the to-be-migrated installation package to generate a test installation package, and returning to the performing of the second running test on the test installation package to obtain a corresponding running test result.

6. The method of claim 1, wherein, The generating of the software migration test report according to the running test result comprises: determining corresponding software running influence factors according to the running test result; generating a software migration test report according to the software running influence factors.

7. The method of claim 1, wherein, After the generating of the software migration test report according to the running test result, the method further comprises: deleting the to-be-migrated installation package from the migration test environment.

8. A software migration testing apparatus, characterized by comprising: The device comprises: An acquisition module is configured to acquire a software information graph structure of the software; A running dependency determination module is configured to determine a running dependency of the software according to the software information graph structure; A to-be-migrated installation package generation module is configured to generate a to-be-migrated installation package of the software according to the running dependency; A sending module is configured to send the to-be-migrated installation package to a migration test environment; A first running test module is configured to perform a first running test on the to-be-migrated installation package in the migration test environment; A second running test module is configured to perform a second running test on the to-be-migrated installation package that passes the first running test, to obtain a running test result; A report generation module is configured to generate a software migration test report according to the running test result.

9. An electronic device, comprising: A processor, a memory, and a program or instructions stored on the memory and executable on the processor are included, and the program or instructions are executed by the processor to implement the steps of the software migration test method according to claims 1-7.

10. A readable storage medium, characterized by, A readable storage medium stores a program or instructions, and the program or instructions are executed by a processor to implement the steps of the software migration test method according to claims 1-7.

Images