A test method for an application system

Abstract

The application relates to the technical field of testing, and discloses a test method for an application system, which comprises the following steps: acquiring a system configuration file, a local application program package and a corresponding local Java bytecode file of a local application system, and determining a target full-amount corresponding relationship of the local application system; acquiring different Java bytecode files of different versions of application program packages, and determining a program difference list; acquiring an outbound configuration file, and combining the target full-amount corresponding relationship and the program difference list to determine a first full-amount test range of the local application system and a plurality of second full-amount test ranges of a plurality of other application systems, and then testing the application system to obtain a target test result of the application system, which realizes bidirectional accurate analysis of a test range of a local program change on itself and other systems and of other system changes on the local system, comprehensively covers transaction interface and business function test requirements among multiple systems in an enterprise, and guarantees the overall operation stability of the application system.

Description

Technical Field

[0001] This invention relates to the field of testing technology, and more specifically to a testing method for an application system. Background Technology

[0002] Version changes are an inevitable part of software system iteration and upgrades, and are a common task in software lifecycle management. For system development organizers and managers, ensuring the quality of each change's delivery presents a significant challenge. Precise testing has become a popular area of ​​software quality assurance in recent years. It integrates traditional testing with data-driven and intelligent approaches, aiming to discover more and more critical issues with fewer resources.

[0003] However, in related technologies, the focus of accurate testing is on the impact of changes in local program code on the system's business functions and test cases. Because modern enterprise IT application systems have complex call and called relationships, changing even a single line of code in one system can have far-reaching consequences, affecting the normal operation of other systems. A key challenge and a pressing need for enterprise IT managers is how to consider upstream and downstream call relationships during version changes to create a precise test scope that includes transaction interfaces and business scopes of both local and related systems. Summary of the Invention

[0004] This invention provides a testing method for application systems to address the problem of how to accurately test the upstream and downstream call relationships of the system during version changes, thereby forming a precise test scope that includes transaction interfaces and business scope of the local system and related systems.

[0005] In a first aspect, the present invention provides a testing method for an application system, the application system including a local application system and multiple other application systems, the local application system and the multiple other application systems being connected via an enterprise service bus system; the method includes: Obtain the system configuration file, local application package, and corresponding local Java bytecode file of the local application system; obtain the first Java bytecode file of the first version application package, the second Java bytecode file of the second version application package, and the outbound call configuration file of the local application system; based on the system configuration file, local application package, and local Java bytecode file, determine the target full-scale correspondence of the local application system, which is the complete correspondence between all local transaction interfaces and all local Java methods in the local application system. All local Java methods include all interface local methods, multiple entry Java methods, and multiple downstream Java methods; based on the first and second Java bytecode files, determine the program difference list between the first and second version application packages; based on the target full-scale correspondence, program difference list, and outbound call configuration file, determine the first full-scale test scope of the local application system and multiple second full-scale test scopes of multiple other application systems; based on the first full-scale test scope and multiple second full-scale test scopes, test the application system to obtain the target test results of the application system.

[0006] The application system testing method provided by this invention obtains the system configuration file, local application package, and local Java bytecode file of the local application system, providing basic data support for subsequent analysis of the correspondence between local transaction interfaces and Java methods, ensuring the integrity and validity of the data source. Furthermore, by obtaining the first / second version Java bytecode file and outbound call configuration file, core data is provided for version difference analysis and cross-system call relationship analysis, helping to accurately determine the cross-system test scope. Furthermore, by determining the target full correspondence between all local transaction interfaces and Java methods, a complete mapping between local interfaces and methods is established. Furthermore, through the program difference list of the two versions, method-level changes between program versions can be accurately identified, clarifying the change points and providing a basis for subsequent test scope delineation. Furthermore, by determining the first full test scope locally and the second full test scope of other systems, the accurate delineation of local and cross-system test scope is achieved, covering the impact of self-changes and cross-system changes, avoiding test omissions and redundancy. Furthermore, conducting tests based on a precise full test scope improves testing efficiency and coverage, thereby effectively discovering local and cross-system program problems and ensuring the overall operational stability of the application system. Therefore, by implementing this invention, the limitations of traditional precision testing that only focuses on the local system are overcome. By analyzing the relationship between local interfaces and Java methods, version differences, and cross-system call relationships layer by layer, the invention achieves bidirectional precision analysis of the testing scope of local program changes on itself and other systems, and changes in other systems on the local system. This comprehensively covers the testing needs of transaction interfaces and business functions between multiple systems within an enterprise, solves the industry pain point of insufficient precision test coverage in cross-system call scenarios, and provides end-to-end methodological support for quality assurance of enterprise IT system version iteration.

[0007] In one optional implementation, the target full mapping relationship of the local application system is determined based on system configuration files, local application packages, and local Java bytecode files, including: Based on system configuration files and local Java bytecode files, multiple target mapping relationships are determined for the local application system. These multiple target mapping relationships include the mapping relationships between all local transaction interfaces in the local application system and their corresponding entry local Java classes, as well as the entry local methods within those entry local Java classes. Based on the local application package and local Java bytecode files, the first full-scale call relationship between all local Java classes and their corresponding full-scale local methods in the local application system is determined. Based on the multiple target mapping relationships and the first full-scale call relationship, the target full-scale mapping relationship for the local application system is determined.

[0008] The application system testing method provided by this invention first establishes the correspondence between interfaces and directly related classes and methods, then determines the full call relationship between local methods, and finally merges them to form a complete mapping. This achieves full coverage of the local transaction interface and Java methods from direct to indirect association, providing accurate and comprehensive association basis for subsequent precise location of interfaces affected by program changes, and avoiding deviations in test scope determination caused by missing association relationships.

[0009] In one alternative implementation, based on system configuration files and local Java bytecode files, multiple target mappings of the local application system are determined, including: The system configuration file is parsed to determine multiple first correspondences in the local application system. Each first correspondence represents a one-to-one correspondence between each local first transaction interface in the local application system and its corresponding local Java class, and between each local method of the local Java class. The annotation symbols in the local Java bytecode file are analyzed and identified to determine multiple second correspondences in the local application system. Each second correspondence represents a one-to-one correspondence between each local second transaction interface in the local application system and its corresponding local Java class, and between each local method of the local Java class. Based on the multiple first and second correspondences, multiple target correspondences in the local application system are determined.

[0010] The application system testing method provided by this invention analyzes the specific ways in which local transaction interfaces correspond to classes and methods from two dimensions: configuration files and Java bytecode. This covers the configuration and annotation definition scenarios of interfaces under different development frameworks, makes up for the limitations of single data source analysis, and ensures that the obtained interface-class-method correspondence is complete and accurate, laying a solid foundation of data support for the subsequent construction of full correspondence.

[0011] In one optional implementation, based on the local application package and local Java bytecode files, the first full call relationship between all full native Java classes and their corresponding full native methods in the local application system is determined, including: This process involves: using the Java Virtual Machine Specification to read the binary bytecode file corresponding to the native Java bytecode file and obtaining multiple raw bytecode data; traversing the class structure of the raw bytecode data and determining multiple raw call relationships; obtaining all native Java class data and all native interface bytecode data of the native application system based on the native application package; constructing a class hierarchy and determining multiple actual call targets based on the multiple raw call relationships, the full set of native Java class data, and the full set of native interface bytecode data; recursively searching and expanding the multiple raw call relationships and multiple actual call targets to determine the second full call relationship between all native Java classes and their corresponding native methods in the native application system; and deduplicating the second full call relationship to obtain the first full call relationship between all native Java classes and their native methods in the native application system.

[0012] The application system testing method provided by this invention solves the problem of call relationship distortion in scenarios such as polymorphism, lambda, and reflection by standardizing bytecode reading, instruction parsing, call relationship expansion, and deduplication. It generates a complete method-level call relationship consistent with the actual JVM loading, clearly showing the hierarchy and association links between native methods, and providing an accurate call relationship basis for establishing a full correspondence between interfaces and methods.

[0013] In one alternative implementation, class structure traversal is performed on multiple raw bytecode data, and multiple raw call relationships are determined, including: The class structure of multiple raw bytecode data is traversed, and multiple initial call instruction information is identified. Each initial call instruction information includes the class and method signature information of the caller and the callee for each call behavior. The format of multiple initial call instruction information is converted to obtain multiple target call instruction information with a unified description format. Redundancy filtering is performed on multiple target call instruction information, and multiple original call relationships are determined.

[0014] The application system testing method provided by this invention eliminates duplicate calls and interference from JDK internal calls by standardizing the call instruction description format, filtering redundant and invalid calls, and generating a concise and standard original call relationship. This reduces the amount of data for subsequent call relationship expansion and analysis, improves overall analysis efficiency, and ensures the accuracy and usability of the original call relationship.

[0015] In one optional implementation, the target full-scale mapping relationship of the local application system is determined based on multiple target mapping relationships and a first full-scale call relationship, including: Based on multiple target correspondences, multiple direct mapping relationships are obtained from the local application system. These direct mapping relationships include the direct correspondence between all local transaction interfaces in the local application system and their corresponding multiple entry Java methods. Based on the first full call relationship, the direct and indirect call chain information between all local Java classes and all local methods in the local application system is obtained, and the method call tree of the local application system is constructed. Based on the method call tree, each downstream Java method is traced upwards to its corresponding root node entry Java method, and multiple indirect mapping relationships are established between all local transaction interfaces in the local application system and their corresponding multiple entry Java methods and multiple downstream Java methods. Based on the multiple direct and multiple indirect mapping relationships, the target full correspondence relationship of the local application system is determined.

[0016] The application system testing method provided by this invention realizes the tracing of downstream methods to the root node interface by constructing a method call tree. It clarifies for the first time the classification of direct and indirect mapping relationships between interfaces and methods, realizes the seamless association between the local transaction interface and all related Java methods, and thus enables the interfaces affected by program changes to be accurately and comprehensively traced, providing the associated logic for defining the test scope.

[0017] In one optional implementation, a list of program differences between the first version application package and the second version application package is determined based on the first Java bytecode file and the second Java bytecode file, including: Extract multiple first attribute parameters from each first Java method in the first Java bytecode file and multiple second attribute parameters from each second Java method in the second Java bytecode file; calculate the hash value of each first Java method based on the multiple first attribute parameters and construct a first feature variable; calculate the hash value of each second Java method based on the multiple second attribute parameters and construct a second feature variable; compare the first feature variable and the second feature variable to determine the program difference list between the first version application package and the second version application package of the local application system.

[0018] The testing method for application systems provided by this invention extracts method attribute parameters and calculates hash values ​​to form feature variables, achieving precise method-level difference comparison. It can quickly identify the addition, modification, and deletion of methods between versions, thereby forming a clear list of differences. This not only avoids the security risks of accessing source code but also improves the efficiency and accuracy of version difference analysis, providing precise change point basis for change impact analysis.

[0019] In one optional implementation, based on the target full-scale correspondence, the program difference list, and the outbound call configuration file, a first full-scale test scope for the local application system and multiple second full-scale test scopes for multiple other application systems are determined, including: Based on the target full correspondence and the program difference list, the set of local transaction interfaces affected by the program changes in the local application system is determined; based on the set of local transaction interfaces and the first preset correspondence, the test scope of the first transaction interface and the test scope of the first business function affected by the program changes in the local application system are determined, whereby the first preset correspondence is the correspondence between all local transaction interfaces and business functions in the local application system; based on the target full correspondence and the outbound call configuration file, the target call relationship between all local transaction interfaces and multiple outbound call transaction interfaces in the local application system is determined; based on the target call relationship, the set of interface call relationships is determined; based on the set of local transaction interfaces, the set of interface call relationships, and the second preset correspondence, multiple... The test scopes for multiple second transaction interfaces and multiple second business functions of other application systems are defined, and multiple second preset correspondences are the correspondences between transaction interfaces and business functions in multiple other application systems. Based on the first preset correspondence and the set of interface call relationships, the test scopes for the third transaction interface and the third business function of the local application system affected by cross-system program changes are determined. Based on the test scopes for the first transaction interface, the third transaction interface, the first business function, and the third business function, the first full-scale test scope of the local application system is determined. Based on the multiple second transaction interface test scopes and multiple second business function test scopes, multiple second full-scale test scopes of multiple other application systems are determined.

[0020] The application system testing method provided by this invention accurately defines the full testing scope of the local system and other related systems, while covering three core scenarios: local changes affecting itself, local changes affecting others, and changes by others affecting the local system. Furthermore, by associating interfaces with business functions, the technical interface testing scope is transformed into a business-level, implementable functional testing scope. This ensures that the testing scope accurately covers the impact of changes while aligning with actual business testing needs, avoiding test omissions and redundancy, and improving the relevance and effectiveness of cross-system testing.

[0021] In one optional implementation, based on the target full correspondence and outbound call configuration file, the target call relationship between all local transaction interfaces in the local application system and multiple outbound call transaction interfaces is determined, including: The process involves analyzing outbound call configuration files to determine the initial outbound call transaction interface list for the local application system to call multiple other application systems. Utilizing the service bus interface of the enterprise service bus system, a full list of backend outbound call transaction interfaces is obtained. Based on the initial outbound call transaction interface list and the backend full list, the full list of outbound call transaction interfaces for the local application system is determined. The local application system's local programs are traversed, and multiple third-party correspondences are established between all local Java methods in the local application system and multiple outbound call transaction interfaces in the full list. Based on the target full correspondence and multiple third-party correspondences, the initial call relationship between all local transaction interfaces in the local application system and multiple outbound call transaction interfaces is established. The initial call relationship is deduplicated to obtain the target call relationship for the local application system.

[0022] The application system testing method provided by this invention constructs a precise call relationship between the local transaction interface and the outbound call transaction interface, and ensures the integrity of the outbound call interface list by integrating the outbound call configuration and service bus outbound call interface information. Furthermore, by establishing and deduplicating the association between interfaces using local Java methods as a bridge, a directional and non-redundant cross-system interface call relationship is formed, which helps to achieve precise cross-system testing. This allows for clear identification of the call chain between systems, providing crucial correlation evidence for cross-system change impact analysis.

[0023] In one optional implementation, based on a first preset correspondence and interface call relationship set, the testing scope of the third transaction interface and the testing scope of the third business function of the local application system affected by cross-system program changes are determined, including: Based on the interface call relationship set, determine the target other application systems corresponding to each outbound call transaction interface; obtain the program change information of each target other application system, and based on the program change information, determine the target outbound call transaction interfaces that have undergone program changes during the version change period from the first version application package to the second version application package of the local application system, where there are one or more target outbound call transaction interfaces; based on the interface call relationship set, determine the local transaction interfaces affected by the target outbound call transaction interfaces, and establish the third transaction interface test scope of the local application system affected by cross-system program changes; based on the first preset correspondence and the third transaction interface test scope, determine the third business function test scope of the local application system affected by cross-system program changes.

[0024] The application system testing method provided by this invention can accurately locate local transaction interfaces affected by cross-system changes by filtering valid outbound call interface changes within the version change period, and further transform them into business function testing scope. This fills the gap in traditional precision testing that cannot analyze the impact of upstream system changes on local systems, realizes reverse precision analysis of the impact of cross-system changes, and ensures that the testing scope fully covers cross-system upstream and downstream changes. Attached Figure Description

[0025] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0026] Figure 1 This is a schematic diagram of an application scenario according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating a testing method for an application system according to an embodiment of the present invention; Figure 3 This is a flowchart illustrating a cross-system precision testing method according to an embodiment of the present invention. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0028] It is understood that before using the technical solutions disclosed in the various embodiments of the present invention, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in the present invention and their authorization should be obtained in accordance with relevant laws and regulations through appropriate means.

[0029] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0030] As an optional application scenario of this invention, the specific application environment architecture or specific hardware architecture on which the execution of the testing method of the application system depends is described herein. For example... Figure 1 As shown, the architecture system may include at least one terminal device and at least one server. Figure 1 The system is illustrated in the example, which includes a computer 101, a mobile terminal 102, and a server 103, and the terminal devices such as the computer 101 and the mobile terminal 102 are connected to the server 103 through a network 110.

[0031] Specifically, the terminal device can be a smartphone, tablet, laptop, PDA, desktop computer, game console, smart TV, smart wearable device, in-vehicle terminal, VR (Virtual Reality) device, AR (Augmented Reality) device, etc. Server 103 can be a standalone physical server, a server cluster, a distributed system, or a cloud server providing cloud services. Network 110 can be a wired or wireless network, examples of which include, but are not limited to, the Internet, corporate intranet, local area network, wide area network, mobile communication network, and combinations thereof.

[0032] This invention provides a testing method for an application system. By analyzing the relationship between local interfaces and Java methods, version differences, and cross-system call relationships, and by performing bidirectional and precise analysis on the testing scope of local program changes on itself and other systems, and changes in other systems on the local system, this method aims to comprehensively cover the testing needs of transaction interfaces and business functions across multiple systems within an enterprise, solve the industry pain point of insufficient precise test coverage in cross-system call scenarios, effectively discover local and cross-system program problems, and ensure the overall operational stability of the application system.

[0033] According to an embodiment of the present invention, a testing method embodiment for an application system is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0034] This embodiment provides a testing method for an application system, which can be used in the aforementioned mobile terminals, such as mobile phones and tablet computers. The application system includes a local application system and multiple other application systems, which are connected through an enterprise service bus system.

[0035] Specifically, an application system refers to an IT software system within an enterprise that implements specific business functions, has an independent program package (Java bytecode file), has a dedicated transaction interface, and can collaborate with other similar systems through the transaction interface. It is the core carrier for the enterprise's digital business development.

[0036] Furthermore, a local application system refers to a system that has independent transaction interfaces, Java program packages (bytecode files), system configuration files, and outbound call configuration files, and can independently provide business functions. At the same time, it can call services of other systems through outbound call interfaces and may also be called by other systems.

[0037] Furthermore, multiple other application systems represent related systems that have cross-system transaction interface call relationships with the local application system. They are upstream and downstream collaborative systems of the local application system, and the two achieve interface interoperability through the enterprise service bus system.

[0038] Furthermore, an Enterprise Service Bus (ESB) system represents a service-oriented architectural pattern and middleware technology used to integrate heterogeneous systems within an enterprise or across enterprises, enabling loosely coupled, standardized, and manageable service interactions.

[0039] For example, taking the core IT architecture of digital office in medium and large enterprises as a real-world scenario, a general-purpose enterprise service bus platform (such as Mule ESB) is selected as the unified interface hub for all enterprise office application systems. It is responsible for interface registration, publishing, routing, protocol conversion, and call monitoring, and serves as the only communication bridge between local application systems and other application systems.

[0040] Furthermore, the enterprise collaborative office system (OA system, upgraded from V5.0 to V5.1) was used as the local application system for testing and analysis; the enterprise core office system that has a direct cross-system interface call relationship with the OA system was used as multiple other application systems, which may include: enterprise human resources management system (HRM), enterprise financial management system (FMS), enterprise asset management system (AMS), enterprise document management system, and enterprise attendance management system.

[0041] For example, taking the full-chain IT architecture of medium and large-sized discrete manufacturing enterprises as an example, a customized industrial service bus platform for manufacturing enterprises is selected as the unified interface hub for all core IT systems such as production, procurement, sales, and finance, and is responsible for interface registration, publishing, routing, protocol conversion, encryption of industrial data transmission, and call monitoring.

[0042] Furthermore, the Enterprise Resource Planning (ERP) system (upgraded from V6.2 to V6.3) was used as the local application system for testing and analysis; the core IT systems of manufacturing enterprises that have direct cross-system transaction interface call relationships with the ERP system were used as multiple other application systems, which may include: Manufacturing Execution System (MES), Warehouse Management System (WMS), Procurement Management System (PMS), Sales Management System (SMS), Financial Management System (FMS), Customer Relationship Management System (CRM), and Equipment Management System (EMS).

[0043] Figure 2 This is a flowchart of a testing method for an application system according to an embodiment of the present invention, such as... Figure 2 As shown, the process includes the following steps: Step S201: Obtain the system configuration file of the local application system, the local application package, and the local Java bytecode file corresponding to the local application package.

[0044] In one optional embodiment, the system configuration file represents an XML configuration file in the local application system used to define the mapping relationship between transaction interfaces and Java classes / methods, and may include transaction name, transaction interface code, bean or class name, method name, etc.

[0045] For example, the XML configuration file is as follows: #Configuration file version and encoding format should conform to XML standard specifications. <?xml version="1.0" encoding="UTF-8"?> <services> # Root node: Transaction interface configuration that manages all business services # Inter-bank collection and payment information query: Business function annotation, indicating the actual business corresponding to this interface <!-- Inter-bank collection and payment information query --> <service id="A010011QR" type="spring" bean-id="queryBalance" method="dealqueryBalanceQR"> < / service> < / services> Among them, "A010011QR" corresponds to an entry bean ("queryBalance") and an entry method ("dealqueryBalanceQR"), thereby establishing the correspondence between the transaction interface and the Java method.

[0046] Furthermore, the service id is used to define the configuration of a single transaction interface; id="A010011QR" represents the unique code of the transaction interface, serving as the interface identifier within the system; type="spring" indicates the framework type for the interface implementation, which is the Spring framework here, specifying the method of loading the Bean; bean-id="queryBalance" represents the corresponding Bean instance ID in the Spring container, associated with the backend Java class; method="dealqueryBalanceQR" represents the specific business method in this Bean, implementing the core logic of the interface.

[0047] In one alternative embodiment, a local application package refers to a complete executable code package that can be directly deployed and run after being compiled by a local application system.

[0048] For example, the local application package is mainly in the form of JAR files and WAR files under the Java development system. In some microservice architectures, it may also contain module directories, nested dependency packages, etc. Furthermore, the local application package contains the complete executable code, configuration files, dependency libraries, etc., that implement all business functions of the local application system. It is the smallest unit for independent deployment and version iteration of the system.

[0049] In one alternative embodiment, the local Java bytecode file refers to the binary .class file generated after the local application package is unpacked. It is compiled from Java source code, conforms to the Java Virtual Machine Specification, and may contain structures such as magic number, version number, constant pool, field table, method table, and bytecode instructions.

[0050] For example, in an enterprise application server / containerized deployment environment (such as Docker / Kubernetes), the official deployment path or version package repository path of the local application system can be located. Furthermore, this path is a fixed path in the enterprise IT operations and maintenance specifications, containing the complete program packages and configuration files of the system currently running / to be tested.

[0051] Furthermore, based on the located path, the system configuration file, local application package, and local Java bytecode file can be retrieved separately, ensuring the integrity, consistency, and up-to-dateness of the files, and that they fully match the actual running / tested version of the local application system, without any missing or tampered parts.

[0052] Specifically, it can read all configuration files related to the transaction interface-Java class / method mapping from the dedicated configuration directory, with a focus on obtaining the XML format service configuration file, while simultaneously obtaining auxiliary configuration files in formats such as yml / properties to ensure that the mapping definitions of all interfaces are covered.

[0053] Furthermore, the complete executable code package (JAR / WAR file) of the local application system can be read from the deployment path / version package repository. Additionally, in the case of a microservice architecture, all relevant module packages and nested dependency packages also need to be retrieved synchronously to ensure that the packages contain complete class files and method executable code.

[0054] Furthermore, the obtained local application package is subjected to lossless unpacking. Following the Java Virtual Machine Specification, all directories within the package are recursively scanned to extract all binary .class format Java bytecode files. During unpacking, the original file structure and data are preserved without any modification to ensure consistency between subsequent parsing and the actual JVM loading.

[0055] Furthermore, the three types of files can be validated for format legality and data validity, filtering out invalid, corrupt, and version-mismatched files to ensure that the data source for subsequent analysis is accurate.

[0056] Step S202: Obtain the first Java bytecode file of the first version application package of the local application system, the second Java bytecode file of the second version application package, and the outbound call configuration file.

[0057] In one optional embodiment, the first version application package represents the complete executable package of the historical baseline version of the local application system to be upgraded / compared. It is a JAR / WAR package (including module directory and nested dependency packages) under the Java development system. It is the formal deployment and running package of the local application system before the version iteration, and may include the complete executable code, configuration files, dependency libraries, etc. that implement all business functions under the corresponding version.

[0058] In one optional embodiment, the second version application package represents a complete executable package of a new version of the local application system after code development / iteration is completed. It is a different version of the same local application system as the first version application package, and its format is also a JAR / WAR package (including module directory and nested dependency packages). It is a test version of the local application system that is to be deployed online.

[0059] In one optional embodiment, the outbound call configuration file represents a configuration file in the local application system used to define the transaction interface of the local system to call other application systems, and is used to solidify the interface code / identifier, interface type, calling rules and other information of the local system's outbound calls.

[0060] For example, a dedicated directory for outbound call configuration files can be located within the local application system and deployed separately from the system's general configuration files for easier maintenance. Furthermore, this directory is a fixed path in the enterprise's IT operations and maintenance specifications, ensuring that the latest outbound call interface configuration information is obtained.

[0061] Furthermore, all outbound call configuration files of the local application system are read from the dedicated outbound call configuration directory to ensure that all interface configuration rules for outbound calls of the local system are covered.

[0062] Furthermore, the process of obtaining the first Java bytecode file and the second Java bytecode file can be referred to in step S201 for obtaining the local Java bytecode file, and will not be repeated here.

[0063] For example, the outbound call configuration file is shown below, illustrating that an outbound call service called / interbankTransfer is available: <outbound-services> <!-- Inter-bank transfer transaction --> <service id=" / interbankTransfer" type="020000" seek-type="remote" Among them, id=" / interbankTransfer" represents the unique identifier (interface path) of the outbound call transaction interface; type="020000" represents the outbound call interface business type code, which can adapt to the enterprise service bus classification rules; seek-type="remote" represents the interface call type, which is identified as a remote cross-system call.

[0064] Furthermore, the above configuration corresponds to the core interfaces in the initial outbound call transaction interface list.

[0065] Step S203: Based on the system configuration file, local application package, and local Java bytecode file, determine the target full mapping relationship of the local application system.

[0066] In one optional embodiment, the target full mapping relationship is the complete mapping relationship between all local transaction interfaces and all local Java methods in the local application system. All local Java methods include all interface local methods, multiple entry Java methods, and multiple downstream Java methods.

[0067] The term "local transaction interfaces" refers to the collection of all transaction interfaces deployed in the local application system, independently provided by the system, capable of providing business services externally or carrying business logic internally. These interfaces can include transaction interfaces with unique codes explicitly defined in the configuration file, as well as RESTful interfaces and service interfaces defined in Java bytecode through annotations (@RequestMapping / @Service, etc.).

[0068] Furthermore, the interface native method represents a Java method that is directly bound to the local transaction interface and provides the basic execution logic for the interface. It is the direct implementation of the local transaction interface at the code level and can be directly identified by parsing system configuration files (XML / yml / properties) or annotation symbols (@RequestMapping / @Service, etc.) in Java bytecode.

[0069] Furthermore, multiple entry Java methods represent the core business methods actually executed after the local transaction interface is triggered, and are directly related to the interface's local methods; multiple downstream Java methods represent all Java methods that are directly or indirectly called by the entry Java method during the execution of business logic, with the entry Java method as the root node.

[0070] For example, the local transaction interface first binds to the entry class and the entry Java method. The entry Java method forms a complete call chain of downstream Java methods through multi-level calls. The three together constitute all the local Java methods corresponding to the local transaction interface.

[0071] In one optional embodiment, based on system configuration files, local application packages, and local Java bytecode files, by integrating the direct mapping relationship between local transaction interfaces and Java methods, and the full call relationship between local Java classes / methods, a complete and comprehensive correspondence relationship can be ultimately established between each local transaction interface in the local application system and all corresponding Java methods, i.e., the target full correspondence relationship.

[0072] Step S204: Determine the program difference list between the first version application package and the second version application package based on the first Java bytecode file and the second Java bytecode file.

[0073] In one optional embodiment, the program difference list represents a list of method-level program change results formed after analyzing the Java bytecode files corresponding to the first and second versions of the local application system application package. It is a standardized record carrier for the addition, deletion, and modification of Java methods between the two versions.

[0074] In one optional embodiment, the first and second Java bytecode files are used as the sole data source for analysis. By performing feature extraction and comparison on the two versions of Java methods, the method-level program changes between the two versions of the application package of the local application system can be accurately identified. The change results can then be standardized and organized into a program difference list.

[0075] Step S205: Based on the target full-scale correspondence, program difference list, and outbound call configuration file, determine the first full-scale test scope of the local application system and multiple second full-scale test scopes of multiple other application systems.

[0076] In an optional embodiment, the first full-scale test scope represents the set of local full-scale test objects formed after integrating the impact of local application system's own program changes and the cross-system impact of other application system program changes. It may include the affected local transaction interfaces and corresponding business functions caused by local program version changes, as well as the affected transaction interfaces and corresponding business functions transmitted to the local system through cross-system call links by other application system program changes.

[0077] In one optional embodiment, the second full test scope represents the complete scope of precise testing required for each other application system that has a cross-system call relationship with the local application system. It is triggered by the local application system program version change through the cross-system transaction interface call link and covers both the transaction interface and business functions of each other application system.

[0078] Furthermore, the scope of this second full-scale test only includes the transaction interfaces and corresponding business functions of other application systems affected by the local program changes, which can accurately locate the impact boundaries of the local application system program changes on upstream and downstream related systems.

[0079] In one optional embodiment, based on the target full correspondence, program difference list and outbound call configuration file, by integrating the analysis results of three scenarios—the impact of local program changes on itself, the cross-system impact of local program changes on other systems, and the cross-system impact of changes in other systems on the local system—it is possible to define the first full test scope of the local application system and the second full test scope of each other application system.

[0080] Step S206: Based on the first full test scope and multiple second full test scopes, test the application system to obtain the target test results of the application system.

[0081] In one optional embodiment, the first full-scale test scope of the local application system and multiple second full-scale test scopes of multiple other application systems are used as the unique test boundaries and objects. Adaptive testing methods are employed to conduct precise testing on the overall application system composed of the local application system and multiple other application systems, thereby ultimately outputting target test results covering the entire link between the local and cross-system systems. Furthermore, by conducting targeted testing according to the precisely defined test scope, avoiding indiscriminate full-scale testing, it ensures that the test covers all transaction interfaces and business functions affected by internal and external program changes, while significantly reducing the consumption of test resources.

[0082] For example, based on the transaction interfaces and business functions within the test scope, and combined with the method change types (addition, modification, deletion) in the preceding program difference list, corresponding test cases can be determined. For instance, for the interfaces / functions corresponding to modified / added methods, functional verification, boundary value, and compatibility test cases should be used; for the interfaces / functions corresponding to deleted methods, link connectivity and dependency verification test cases should be used, while ensuring that the test cases cover the correspondence between the interfaces and business functions.

[0083] Furthermore, a cross-system testing environment consistent with the production environment is established, ensuring connectivity between the local application system, multiple other application systems, and the Enterprise Service Bus (ESB) system. Additionally, the versions of each system can be verified to match the testing scope (local system uses version 2, other systems use the corresponding running version), while ensuring traceable interface call logs and method execution logs in the testing environment for easy problem localization.

[0084] Furthermore, for the first full-scale test scope, the designed test cases were executed to verify the correctness of the transaction interfaces and business functions affected by changes to the local program itself and cross-system changes in other systems. The focus was on testing the request and response of the interfaces, parameter validation, and the execution results of business logic, while also recording exception logs during the interface call process.

[0085] Furthermore, for each of the other application systems, corresponding test cases were executed within the second full-scale test scope to verify the correctness of the transaction interfaces and business functions affected by changes in the local application system. The focus was on testing the compatibility of the interfaces being called, the data reception and processing results, and recording any issues encountered during the testing process.

[0086] Furthermore, the independent test results of each system are initially screened, and issues such as functional defects, abnormal interface calls, and data errors are marked. Problems of a single system that are not related to other systems are temporarily stored.

[0087] Furthermore, based on the cross-system interface call relationship of the Enterprise Service Bus (ESB) system, end-to-end cross-system joint debugging tests are carried out on the call link between the local application system and other application systems.

[0088] Furthermore, collect the single-system test results of local application systems and other application systems, as well as the cross-system link integration test results, integrate all the problems found in the tests, form a unified problem list, record the problem's manifestation, occurrence point, related transaction interfaces / business functions, related program change points, and generate corresponding standardized test result reports.

[0089] The application system testing method provided in this embodiment breaks through the limitation of traditional precision testing that only focuses on the local system. By analyzing the relationship between local interfaces and Java methods, version differences, and cross-system call relationships layer by layer, it realizes two-way precision analysis of the testing scope of local program changes on itself and other systems, and changes of other systems on the local system. It comprehensively covers the testing needs of transaction interfaces and business functions between multiple systems within an enterprise, solves the industry pain point of insufficient precision test coverage in cross-system call scenarios, and provides end-to-end methodological support for quality assurance of enterprise IT system version iteration.

[0090] In some optional implementations, step S203 above includes: Step S2031: Based on the system configuration file and the local Java bytecode file, determine the correspondence between multiple targets of the local application system.

[0091] In one optional embodiment, the multiple target correspondences include the correspondence between all local transaction interfaces in the local application system and their corresponding local Java classes, and the correspondence between local methods in the local Java classes.

[0092] Specifically, step S2031 includes: Step a1: Parse the system configuration file and determine multiple first correspondences of the local application system.

[0093] In an optional embodiment, each first correspondence represents a one-to-one correspondence between each local first transaction interface in the local application system and the corresponding local Java class of each first interface, and each local method of each first interface in the local Java class of each first interface.

[0094] In one optional embodiment, the system configuration file defines the association rules between transaction interfaces and Java classes and methods using standardized tags / nodes. Therefore, based on the structured parsing principle of the configuration file, by parsing specific tags (such as service, bean-id, method) in the configuration file, information such as the local first transaction interface code / identifier, the associated Java class Bean ID, and the corresponding Java method stored in the tags can be extracted.

[0095] Furthermore, by using the Bean instantiation rules of enterprise application frameworks (such as Spring), Bean IDs are mapped to specific first interface local Java classes, thereby ultimately establishing a one-to-one correspondence between the local first transaction interface, the first interface local Java class, and the first interface local Java method, i.e., the first correspondence.

[0096] Step a2 involves analyzing and identifying annotation symbols in the local Java bytecode file and determining multiple second correspondences of the local application system.

[0097] In an optional embodiment, each second correspondence represents a one-to-one correspondence between each local second transaction interface in the local application system and the corresponding local Java class of each second interface, and each local method of each second interface in the local Java class of each second interface.

[0098] In one alternative embodiment, based on the principles of bytecode annotation parsing and reflection mapping, modern development frameworks (such as Spring MVC) directly define the association between transaction interfaces and classes / methods in the Java source code through annotation symbols, and the annotation information is retained in the annotation table of the bytecode.

[0099] Furthermore, bytecode parsing tools such as ASM can be used to perform a full traversal of the class structure and methods of local Java bytecode files, parse the annotation table structure in the bytecode, and identify preset transaction interface annotation symbols, such as @RequestMapping, @RestController, and @Service.

[0100] Furthermore, the identified annotation symbols are parsed to extract the local second transaction interface path (e.g., / list) defined in the annotation, and the local Java class (fully qualified class name) and corresponding Java method (method name, parameter list) of the second interface annotated by the annotation are recorded. Further, if the annotation is on a class, it is combined with the method annotations within the class to complete a precise mapping.

[0101] Furthermore, through the above process, a one-to-one correspondence can be finally established between the local second transaction interface, the local Java class of the second interface, and the local Java method of the second interface, i.e., the second correspondence.

[0102] For example, the code for local annotations is as follows. The code defines a transaction interface for ` / list` using `@RequestMapping`, and its corresponding method is `toPage`: @RequestMapping({" / list"}) / / Core annotation for interface mapping: Annotated on a method, defining the access path of the local second transaction interface as / list, serving as the interface entry point for frontend requests. / / Curly braces indicate that multiple paths can be configured; here, only / list is configured as a single interface path. public String toPage(Model model, @RequestParam(value = "type",defaultValue = "1") long type) { / / Method name: toPage, is the local Java method of the second local interface corresponding to this second local transaction interface, which handles the core business logic of the interface. / / Parameter 1: Model model, a Spring framework model object used to pass business data to the front-end page. / / Parameter 2: @RequestParam(...) long type, the request parameter annotation, retrieves the type parameter from the front-end request, the default value is 1, and specifies the parameter rules. model.addAttribute("type", Long.valueOf(type)); / / Add a type parameter to the Model object to pass the parameter data processed by the backend to the frontend view layer, realizing data interaction between the frontend and backend. return "analyze / list"; / / Return front-end view path: Specifies the page path to navigate to after the API request is processed, completing the API's view response logic.} Furthermore, the Java class containing this method is the second interface native Java class, and the above process will also extract the fully qualified class name of this class in the same way.

[0103] Step a3: Determine multiple target correspondences of the local application system based on multiple first correspondences and multiple second correspondences.

[0104] In one optional embodiment, based on the principle of multi-source data integration and standardized mapping, although the first correspondence and the second correspondence have different sources, their core mapping dimensions are the same, both being local transaction interface → interface local Java class → interface local Java method.

[0105] Furthermore, by unifying the identification rules of transaction interfaces and the description rules of Java classes / methods, the two types of correspondences can be fully merged, and duplicate interface mappings can be eliminated. This will ultimately form a standardized target correspondence that covers all local transaction interfaces, ensuring the integrity, uniqueness, and consistency of the mapping relationship.

[0106] For example, the identification rule for a unified transaction interface can be to unify the interface ID / interface path as a unique identifier for the interface; the description rule for Java classes / methods can be to use the form of fully qualified class name plus method name plus parameter list.

[0107] Furthermore, duplicate interface mappings can occur when the same interface is defined repeatedly in configuration files and annotations.

[0108] Step S2032: Based on the local application package and the local Java bytecode file, determine the first full call relationship between all full local Java classes and their corresponding full full local methods in the local application system.

[0109] In one optional embodiment, the full set of local Java classes refers to all Java class files (.class) contained in the application package (JAR / WAR / module directory) of the local application system. It is the code carrier for the local application system to implement all business functions, tool logic, and system interactions. It can include all types of Java classes such as business classes, utility classes, interface classes, abstract classes, control layer classes, service layer classes, and data access layer classes of the local application system. It also includes custom classes belonging to the business implementation of the local application system in the system's nested dependency packages.

[0110] In one optional embodiment, a full native method refers to all methods in a full native Java class that have actual execution logic, that is, the collection of all methods defined in each native Java class that can be called and executed, such as member methods, static methods, constructors, and overridden methods.

[0111] Specifically, step S2032 includes: Step b1: Use the Java Virtual Machine Specification to read the binary bytecode file corresponding to the local Java bytecode file and obtain multiple raw bytecode data.

[0112] In one alternative embodiment, based on the structured file reading principle of the Java Virtual Machine Specification, the binary .class file is a structured file that strictly follows the Java Virtual Machine Specification, and its byte stream stores all the information of the class in a fixed format.

[0113] Furthermore, according to the Java Virtual Machine Specification, each .class file can be read as a byte stream, and the magic number, Java version number, constant pool, access flags, class index / parent class index / interface index set, field table, method table, attribute table and other structures can be parsed and loaded in sequence.

[0114] Furthermore, the read structured data is encapsulated into ClassReader objects that can be recognized by the ASM tool, forming multiple raw bytecode data. This ensures that subsequent analysis is completely consistent with the logic of the JVM actually loading classes, and does not depend on the source code.

[0115] Each piece of raw bytecode data corresponds to the complete bytecode information of a Java class.

[0116] Furthermore, it can also verify the integrity of the original bytecode data (no missing bytes or structural damage), ensure the validity of core identifiers such as magic number and version number, and filter out .class file data that has failed to compile or is invalid.

[0117] Step b2 involves traversing the class structure of multiple raw bytecode data and determining multiple raw call relationships.

[0118] In one optional embodiment, multiple original call relationships represent a set of basic method call relationships extracted directly from the local Java bytecode file after parsing, without expansion or redundancy. These relationships only include call behaviors explicitly defined by the invoke* instruction in the bytecode, and record the class / method signatures and call types of the caller and the callee.

[0119] In one optional embodiment, based on the bytecode traversal and instruction parsing principle of the ASM tool, the calling behavior of Java methods is implemented through the invoke* instruction in the bytecode, and the operand of each instruction points to the corresponding class / method signature in the constant pool.

[0120] The invoke* commands are invokevirtual / invokeinterface / invokestatic / invokespecial.

[0121] Furthermore, by traversing the bytecode instruction stream of the method using the ASM tool, all invoke* instructions are identified, and the class / method signatures of the caller and the callee are extracted. After being converted into a unified description format, internal JDK calls and duplicate instructions are filtered out, and the corresponding original call relationships are obtained.

[0122] In some alternative implementations, step b2 above includes: Step b21 involves traversing the class structure of multiple raw bytecode data and identifying multiple initial call instruction information.

[0123] Step b22: Convert the format of multiple initial call instruction information to obtain multiple target call instruction information with a unified description format.

[0124] Step b23 involves redundant filtering of multiple target call instruction information and determining multiple original call relationships.

[0125] In one optional embodiment, each initial invocation instruction information includes the class and method signature information of the caller and the callee for each invocation behavior.

[0126] In one optional embodiment, the ClassVisitor / MethodVisitor tool of ASM is used to perform a full traversal of the class structure for each raw bytecode data (ClassReader object), and to traverse all methods of the class in sequence, including constructors, member methods, static methods, etc.

[0127] Furthermore, the bytecode instruction stream of each method is parsed line by line to identify all invoke* call instructions, and the caller (current class / method), the fully qualified class name of the callee, the method signature (method name, parameter list and return value), and the call type (virtual method / interface method / static method) are extracted from the constant pool by the operand index of the instruction.

[0128] Furthermore, the call information corresponding to each invoke* instruction is encapsulated into initial call instruction information, forming multiple sets of initial call instruction information. Each set of information fully records the core elements of a single call behavior.

[0129] For example, the call relationship between the method toPage and the method findExtraInfoById is defined using invokevirtual: public String toPage(Model model, @RequestParam(value = "type",defaultValue = "1") long type); / / Method signature: The core method of the caller, corresponding to the caller in the original call relationship. descriptor: (JJ)Lcom / rsea / common / exception / ExecuteResult; / / Method descriptor: identifies parameter types (two Long types) and return type (custom exception result class). flags: ACC_PUBLIC / / Access flag: Public method, allows external calls Code: / / Code segment: The core bytecode instruction stream of the method, which is the core area for parsing invoke* instructions. stack=5, locals=11, args_size=3 / / stack=5: Maximum depth of the operand stack; locals=11: Number of local variable tables; args_size=3: Number of actual method parameters 0: aload_0 / / Instruction: Push the 0th local variable (this object, the current class instance) onto the operand stack. 1: getfield#9 / / Field versionService:Lcom / VersionService; / / Command: Retrieves the member variable `versionService` at index #9 in the constant pool of the `this` object, which is of type `com.VersionService`. 4: lload_3 / / Instruction: Push the third local variable (the Long type parameter) onto the operand stack. 5: invokevirtual #10 / / Method com / VersionService.findExtraInfoById:(J)Lcom / version / VersionInfo; / / Core invoke* instruction: invokevirtual (virtual method call), corresponding to the initial call instruction identified in step b21. / / Constant pool index #10: Points to the signature of the called method — the findExtraInfoById method of the com.VersionService class (parameter Long, returns VersionInfo). / / This instruction is the direct source of the original call relationship toPage->findExtraInfoById.

[0130] Furthermore, a unified calling instruction description format is defined: Caller class fully qualified name. Called method name (parameter list) -> Callee class fully qualified name. Called method name (parameter list) #call type, for example, com.test.Controller.toPage(Long) -> com.test.Service.findExtraInfoById(Long) #invokevirtual.

[0131] Furthermore, all initial call instruction information can be converted into a unified format, standardizing the representation of class names, method names, and parameter lists, thereby obtaining multiple target call instruction information in a unified description format after conversion, ensuring that the description format of all call behaviors is consistent.

[0132] Furthermore, the target call instruction information is deduplicated, and duplicate call instruction records from the same caller to the same callee are removed. Simultaneously, call instructions whose callees are JDK core libraries (java.* / javax.* / sun.*, etc.) are filtered out, retaining only class / method calls from the local application system itself.

[0133] Furthermore, it can also filter invalid instructions that have the access flag set to private and have no actual calling significance.

[0134] Furthermore, the filtered target call instruction information is converted into a raw call relationship in the form of key-value pairs, where the caller is the key and the set of callees is the value, ultimately forming multiple raw call relationships.

[0135] Step b3: Obtain all local Java class data and all local interface bytecode data of the local application system based on the local application package.

[0136] In one optional embodiment, based on the principle of full traversal of the local application package and class / interface identification, the local application package (JAR / WAR) contains the bytecode files of all Java classes (ordinary classes and abstract classes) and interfaces of the local application system. Then, by recursively scanning the package, the fully qualified names, parent class indexes, interface indexes, and access flags of all classes, as well as the fully qualified names and parent interface indexes of all interfaces, are identified and extracted to form structured full Java class data and interface bytecode data.

[0137] For example, a recursive unpacking scan is performed on the local application package, traversing all directories and files within the package, extracting all .class files, and then using the bytecode access flag ACC_INTERFACE to determine and distinguish them into ordinary classes, abstract classes, and interface classes.

[0138] Furthermore, for each ordinary / abstract class, its fully qualified name, parent class fully qualified name, set of fully qualified names of implemented interfaces, and class access flags are extracted and encapsulated into structured Java class data, thereby forming a complete set of native Java class data.

[0139] Furthermore, for each interface class, its fully qualified name, the set of fully qualified names of its parent interfaces, and the method signatures in the interface are extracted and encapsulated into structured interface bytecode data, thereby forming full local interface bytecode data.

[0140] Step b4: Based on multiple original call relationships, full local Java class data, and full local interface bytecode data, construct a class hierarchy and determine multiple actual call targets.

[0141] In one optional embodiment, multiple actual call targets represent the set of all possible actual execution call targets obtained by expanding the interface calls and virtual method calls in the original call relationship after combining the full Java class hierarchy (inheritance / interface implementation) of the local application system. That is, if there is a call to an interface / parent class method in the original call, the actual call targets include all overridden methods of subclasses that implement the interface / inherit the parent class.

[0142] In one alternative embodiment, an inheritance-interface implementation hierarchy of classes is constructed based on full class / interface data, and the interface / virtual method calls in the original call relationship are analyzed, thereby enabling the determination of all possible actual call targets for each call behavior.

[0143] For example, based on the full set of local Java class data and interface bytecode data, a tree-like class inheritance-interface implementation hierarchy is constructed with parent class-child class and interface-implementation class as the association dimensions.

[0144] Furthermore, the CHA / RTA algorithm can be used to perform a full traversal of the multiple original call relationships obtained, and the call relationships with **call types of interface methods (invokeinterface) and virtual methods (invokevirtual)** can be filtered out. In addition, such calls have polymorphic scenarios, and the actual call targets need to be expanded.

[0145] Furthermore, for each selected call relationship, based on the fully qualified name of the callee's interface / parent class, all subclasses that implement the interface, inherit from the parent class, and override the method are recursively searched in the class hierarchy.

[0146] Furthermore, the overridden methods in all retrieved subclasses are extracted and used as the actual call targets for this invocation behavior, thus forming multiple actual call targets. Each original call relationship (interface / virtual method call) corresponds to one or more actual call targets.

[0147] Step b5 involves recursively searching and expanding multiple original call relationships and multiple actual call targets, and determining the second full call relationship between all full native Java classes and their corresponding full native methods in the local application system.

[0148] In one optional embodiment, the original call relationship is combined with the actual call target. Through recursive retrieval and link expansion, the original call of the interface / virtual method is expanded into a call to all actual call targets. At the same time, indirect call links are supplemented, and finally a second full call relationship without deduplication is formed.

[0149] For example, the original call relationship is associated with the actual call target, and for each original call relationship with polymorphism, the call to the interface / parent class method is replaced with a direct call to all actual call target methods, thereby forming a basic extended call relationship.

[0150] Furthermore, taking all the callees in the basic extended call relationship as the new callers, recursively retrieve their subsequent call behaviors in the original call relationship, repeat the actual call target extended logic of step b4, and supplement the links of all indirect calls.

[0151] Furthermore, all call chains after direct calls, indirect calls, and polymorphic extensions are spliced ​​together to form a complete call relationship network. Then, the spliced ​​call relationship network is converted into a second full call relationship in key-value pair form, that is, the caller class / method is the key, and the set of all direct / indirect callee classes / methods is the value.

[0152] Step b6: Deduplication is performed on the second full call relationship to obtain the first full call relationship between full native Java classes and full native methods in the local application system.

[0153] In an optional embodiment, the second full call relationship contains duplicate call relationships from the same caller to the same callee, and duplicate records of the same method node. Therefore, by performing uniqueness verification on the caller-callee tuple of the call relationship, duplicate call edges are eliminated, and duplicate method nodes are merged, thus ultimately obtaining a concise, complete, and unique first full call relationship, which can be displayed as a visual method call tree / graph. Furthermore, each method on the tree can be traced upwards to a root node. For example, in step b2 above, the call relationship of "defining the method toPage by invokevirtual to call the method findExtraInfoById" can be traced upwards from findExtraInfoById to the root node method toPage.

[0154] For example, uniqueness checks are performed on all caller and callee nodes (classes / methods) in the second full call relationship, and they are merged according to the fully qualified class name + method signature, thereby eliminating duplicate node records.

[0155] Furthermore, a uniqueness check is performed on all call edges (caller -> callee) in the second full call relationship, and duplicate call relationships from the same caller to the same callee are eliminated, with only one valid record retained. Further, invalid call relationships such as self-calls and air conditioning conflicts generated during the filtering process are further filtered.

[0156] Furthermore, the deduplicated call nodes and call edges are organized into a structured first full call relationship. This first full call relationship takes the full local Java class as the top-level dimension and associates the direct / indirect callers and callees of all methods under the class, which can fully reflect the full call chain of Java classes and methods in the local application system.

[0157] Furthermore, the initial full call relationship can be stored in a dedicated data structure, while also supporting visual display (such as a method call tree or a call relationship list). The displayed content can include the caller's class name / method name, the callee's class name / method name, and the call type, and provides a query function by class / method name.

[0158] Step S2033: Based on multiple target correspondences and the first full call relationship, determine the target full correspondence of the local application system.

[0159] Specifically, step S2033 includes: Step c1: Based on multiple target correspondences, obtain multiple direct mapping relationships of the local application system.

[0160] In one optional embodiment, the multiple direct mapping relationships include the direct correspondence between all local transaction interfaces in the local application system and the corresponding multiple entry Java methods.

[0161] In one optional embodiment, a one-to-one correspondence between local transaction interfaces and entry-level local Java classes and methods has been determined in multiple target mapping relationships. The core method directly bound to the interface and triggering business logic is the entry-level Java method. Therefore, by filtering the interface-core triggering method mappings in the target mapping relationships, direct mapping relationships can be obtained. The filtering process must ensure that each interface corresponds to a unique set of core entry-level methods.

[0162] For example, the native Java methods of the interface in each target correspondence are filtered, and the core method that triggers the business logic, i.e. the entry Java method, is identified.

[0163] Furthermore, the local transaction interface is bound to the identified entry Java method, forming a one-to-one correspondence between the local transaction interface and the entry Java method, i.e., multiple direct mapping relationships.

[0164] Step c2: Based on the first full call relationship, obtain the direct call chain information and indirect call chain information between all local Java classes and all local methods in the local application system, and construct the method call tree of the local application system.

[0165] In one optional embodiment, by starting with the entry Java method, recursively traversing all its directly called methods downwards, and then using the directly called methods as new nodes to continue traversing its indirectly called methods, a hierarchical method call tree with the entry method as the root can be formed, thereby visually displaying the call chain between the entry method and all downstream methods.

[0166] For example, the first full call relationship is traversed, and the direct call chain information (direct association between the caller and the callee) and indirect call chain information (association between the caller and the final callee through intermediate methods) of each method are extracted according to the association dimension between the caller and the callee, thereby forming a complete call chain list.

[0167] Furthermore, taking each entry Java method as the root node, a hierarchical method call tree is constructed downwards based on the extracted call chain information. The root node is the entry Java method; first-level child nodes are methods directly called by the entry Java method; second-level and lower-level child nodes are downstream methods directly or indirectly called by each level of child node.

[0168] Furthermore, each method call tree can be indexed according to the unique identifier of the entry Java method, and the hierarchical structure of the tree and the node relationships (parent method - child method) can be stored, thereby enabling the quick retrieval of all downstream methods associated with the entry method.

[0169] Step c3: Based on the method call tree, trace each downstream Java method back to its corresponding root entry Java method, and establish multiple indirect mapping relationships between all local transaction interfaces in the local application system and their corresponding multiple entry Java methods and multiple downstream Java methods.

[0170] In one optional embodiment, the method call tree clearly defines the hierarchical association between the root node (entry Java method) and all downstream methods. That is, each downstream method can be traced back to the unique root node entry Java method through the parent node of the call tree. Therefore, combined with the direct mapping relationship (interface → entry method) obtained in step c1, the downstream methods can be associated with the corresponding local transaction interface through the entry method, thereby forming an indirect mapping relationship between the local transaction interface and the downstream Java methods.

[0171] For example, the entire method call tree is traversed, and each downstream Java method in the tree is extracted one by one, that is, all node methods except the root node entry method.

[0172] Furthermore, for each downstream Java method, trace back upwards along the hierarchical structure of the method call tree, locating the unique root node entry Java method corresponding to that downstream method through the path of parent node → grandparent node → ... → root node.

[0173] Furthermore, based on the direct mapping relationship obtained in step c1 (local transaction interface → entry Java method), the root node entry Java method obtained by tracing is associated with the corresponding local transaction interface, thereby establishing a correspondence between the local transaction interface and the downstream Java method, i.e., multiple indirect mapping relationships.

[0174] Furthermore, multiple indirect mapping relationships can be structured and stored in the format of local transaction interface unique identifier - downstream Java class fully qualified name - downstream Java method name - method signature - traceability path, thereby ensuring that the association between each downstream method and interface is traceable.

[0175] Step c4: Determine the target full mapping relationship of the local application system based on multiple direct mapping relationships and multiple indirect mapping relationships.

[0176] In one optional embodiment, by merging multiple direct mapping relationships and multiple indirect mapping relationships according to the interface unique identifier - method unique identifier, and eliminating duplicate mapping records, a complete correspondence between each interface and all associated Java methods can be formed, thereby achieving full coverage of interfaces and methods.

[0177] For example, multiple direct and indirect mapping relationships are standardized, and the core field formats are unified. Specifically, local transaction interfaces are unified into unique interface identifiers (interface IDs or paths); Java methods are unified into fully qualified class names plus method names plus method signatures to ensure consistent mapping dimensions.

[0178] Furthermore, deduplication is performed based on the unique identifiers of the interface and the method, eliminating duplicate association records for the same interface and method, retaining only one valid mapping. Further, the deduplicated direct and indirect mapping relationships are integrated to form a complete correspondence between each local transaction interface and all its corresponding Java methods, i.e., the target full correspondence.

[0179] In some optional implementations, step S204 above includes: Step S2041: Extract multiple first attribute parameters from each first Java method in the first Java bytecode file and multiple second attribute parameters from each second Java method in the second Java bytecode file.

[0180] In an optional embodiment, a first Java bytecode file and a second Java bytecode file are loaded respectively, and the file structure is parsed according to the virtual machine specification using the ClassReader object of the ASM tool, thereby ensuring the integrity of the extracted attribute parameters.

[0181] Furthermore, a full traversal is performed on all methods (including constructors, member methods, and static methods) in each bytecode file, and the corresponding parameters are extracted for each method.

[0182] For example, the extracted parameters may include basic attributes such as method access flag, method name, method descriptor (desc, including parameter type and return value type), generic signature, etc.; extended attributes such as exceptions, method annotations, parameter names, etc.; and auxiliary attribute parameters such as local variable slot number, line number table CRC value, etc.

[0183] Step S2042: Calculate the hash value of each first Java method based on multiple first attribute parameters, and construct the first feature variable.

[0184] In one optional embodiment, the hash value can characterize the attribute features of the method. That is, if the method does not change, its attribute parameters remain unchanged, and the hash value also remains consistent; if the method changes, the hash value will inevitably change.

[0185] For example, for each first Java method, all first attribute parameters are concatenated into a complete UTF-8 encoded string in a fixed order: class fully qualified name, method name, descriptor, generic signature, access flags, exception table, annotations, parameter names, number of local variable slots, and line number table CRC.

[0186] Furthermore, the concatenated string is subjected to SHA-256 hash calculation, and the first 128 bits of the result are extracted. Then, it is mixed with the local variable slot number and the CRC value of the row number table to finally generate a 64-bit long integer hash value.

[0187] Furthermore, the fully qualified class name, method name, and method descriptor of each first Java method are bound to the corresponding hash value, forming the corresponding first characteristic variable.

[0188] Step S2043: Calculate the hash value of each second Java method based on multiple second attribute parameters, and construct the second feature variable.

[0189] For the specific process, please refer to the calculation process in step S2042, which will not be repeated here.

[0190] Step S2044: Compare the first feature variable and the second feature variable, and determine the program difference list between the first version application package and the second version application package of the local application system.

[0191] In one optional embodiment, using the first set of feature variables as a reference, the second set of feature variables is traversed, and feature variables with the same fully qualified class name, method name, and method descriptor are searched for, and then the hash values ​​are compared to see if they are consistent. Simultaneously, in reverse, using the second set of feature variables as a reference, the first set of feature variables is traversed, and feature variables not present in the second set are searched for.

[0192] Further, determine the type of change: (1) Added: Methods with class fully qualified names, method names and method descriptors that are unique to the second set are marked as add; (2) Deletion: Methods with class fully qualified names, method names and method descriptors that are unique to the first set are marked as delete; (3) Modification: Methods with the same identifier but different hash values ​​in two sets are marked as update.

[0193] Furthermore, all change methods are organized according to the field format of system name, version number (first version / second version), fully qualified class name, method name, method descriptor, and change type, forming a structured program difference list.

[0194] In some optional implementations, step S205 above includes: Step S2051: Based on the target full correspondence and the program difference list, determine the set of local transaction interfaces of the local application system affected by its own program changes.

[0195] In one optional embodiment, by changing the method, the target full correspondence, and the traceability link of the local transaction interface, all local interfaces affected by the change can be located, ensuring that no local change-related interfaces are missed.

[0196] In one optional embodiment, all modified methods in the program difference list are traversed, and the fully qualified class name, method name, and method signature of each modified method are extracted. Further, using the modified method as the search condition, the target full correspondence is queried, and all local transaction interfaces associated with that method are located.

[0197] Furthermore, by deduplicating and integrating all the traced local transaction interfaces, a set of local transaction interfaces can be formed. This set can also include all local transaction interfaces affected by changes to the local program.

[0198] Step S2052: Based on the local transaction interface set and the first preset correspondence, determine the test scope of the first transaction interface and the test scope of the first business function affected by the changes in the local application system's own program.

[0199] In one optional embodiment, the first preset correspondence is the correspondence between all local transaction interfaces and business functions in the local application system.

[0200] In an alternative embodiment, by matching the affected local interfaces with the correspondence, the technical interface scope can be transformed into a business function scope that business personnel can understand, which helps with test execution and communication.

[0201] For example, the local transaction interface set is directly used as the first transaction interface test scope. At the same time, using each interface in the first transaction interface test scope as a search condition, a first preset correspondence is queried, and all associated business functions are extracted. Then, after deduplication, the corresponding first business function test scope is formed.

[0202] Step S2053: Based on the target full correspondence and outbound call configuration file, determine the target call relationship between all local transaction interfaces and multiple outbound call transaction interfaces in the local application system.

[0203] In one optional embodiment, by parsing the outbound call configuration file, connecting to the enterprise service bus system, and establishing a mapping between methods and outbound call interfaces, the target call relationship between all local transaction interfaces and multiple outbound call transaction interfaces can ultimately be formed.

[0204] Specifically, step S2053 includes: Step d1 involves analyzing the outbound call configuration file and determining the initial outbound call transaction interface list for the local application system to call multiple other application systems.

[0205] Step d2: Use the service bus interface of the enterprise service bus system to obtain the full list of outbound call transaction interfaces in the background.

[0206] Step d3: Based on the initial outbound call transaction interface list and the backend full outbound call transaction interface list, determine the full outbound call transaction interface list of the local application system.

[0207] Step d4: Traverse the local programs of the local application system and establish multiple third-party correspondences between all local Java methods in the local application system and multiple outbound call transaction interfaces in the full list of outbound call transaction interfaces.

[0208] Step d5: Based on the target full correspondence and multiple third correspondences, establish the initial call relationship between all local transaction interfaces and multiple outbound transaction interfaces in the local application system.

[0209] Step d6: Deduplication is performed on the initial call relationship to obtain the target call relationship of the local application system.

[0210] In one optional embodiment, the outbound call configuration file is parsed, and information such as the outbound call transaction interface identifier (e.g., interface ID, interface path), interface type, and calling rules defined in the configuration file is extracted. Further, the parsed outbound call transaction interfaces are deduplicated and integrated to form a corresponding initial list of outbound call transaction interfaces.

[0211] Furthermore, by invoking the service interface of the Enterprise Service Bus (ESB) system and according to preset permissions and query rules, the system can request information on all backend outbound call transaction interfaces. It then receives a list of backend outbound call transaction interfaces returned by the ESB. This list can include all other system transaction interfaces registered with the ESB and accessible for outbound calls by the local application system.

[0212] Furthermore, the received lists are standardized in format to form a complete list of outbound call transaction interfaces in the backend. Standardization may include fields such as unified interface identifier and system affiliation.

[0213] Furthermore, the initial list of outbound call transaction interfaces and the full list of outbound call transaction interfaces in the backend are merged, and duplicate outbound call transaction interfaces are removed. Then, the legality of each outbound call transaction interface after merging is verified, such as the uniqueness of the interface identifier and the clear system affiliation. Invalid interfaces are filtered out, and finally, a full list of outbound call transaction interfaces covering all other system transaction interfaces that can be called from the local system is formed.

[0214] Furthermore, based on the local Java bytecode file obtained in step S201, the local program of the local application system can be traversed, and all Java methods that call the outbound call transaction interface can be retrieved. Further, for each retrieved method, the outbound call transaction interface it calls is identified, and a mapping relationship is established between the local Java method (fully qualified class name plus method name plus method signature) and the outbound call transaction interface (interface identifier), thereby forming multiple corresponding third-party correspondences. Identification can be achieved by parsing the outbound call instructions in the method and the interface identifier in the parameters.

[0215] Furthermore, by using local Java methods as an intermediary and associating the target full mapping (the mapping between local transaction interfaces and local Java methods) and the third mapping (the mapping between local Java methods and outbound call transaction interfaces), a mapping between local transaction interfaces and outbound call transaction interfaces can be formed. Further, the obtained mappings are integrated to form an initial call relationship that records the call association between each local transaction interface and its corresponding outbound call transaction interface.

[0216] Furthermore, the initial call relationships are traversed, and duplicate calls are removed based on the tuple of local transaction interface identifier and outbound call interface identifier. Simultaneously, invalid relationships without practical call meaning are filtered out, such as mappings between local and outbound interfaces that have no business connection, ultimately forming the target call relationships for the local application system.

[0217] The target call relationship is formatted as local transaction interface@local system → outbound transaction interface@other system, such as / list@OA system → / interbankTransfer@payment system.

[0218] Step S2054: Determine the set of interface call relationships based on the target call relationship.

[0219] In one optional embodiment, the target call relationships are formatted uniformly, and fields such as the caller system name, caller interface identifier, callee system name, and callee interface identifier are determined. Furthermore, all standardized call relationships are integrated to form a corresponding set of interface call relationships.

[0220] Furthermore, this collection can include transaction interface call associations between all systems within an enterprise, thereby enabling the retrieval of call chains by caller and callee.

[0221] Step S2055: Based on the local transaction interface set, the interface call relationship set, and the second preset correspondence, determine the test scope of multiple second transaction interfaces and the test scope of multiple second business functions of multiple other application systems.

[0222] In one optional embodiment, the multiple second preset correspondences are correspondences between transaction interfaces and business functions in multiple other application systems.

[0223] In one optional embodiment, starting with the local transaction interface set, the interface call relationship set is queried, and all other system interfaces called by these local interfaces are located. Then, the downstream interfaces called by these other system interfaces are recursively located, and a corresponding set of interfaces of other systems affected is formed.

[0224] Furthermore, based on the system affiliation of the called party, the aforementioned set of affected interfaces is split into systems, forming a second transaction interface test scope corresponding to each other system.

[0225] Furthermore, for each other system, its second transaction interface test scope is matched with the corresponding second preset correspondence, and the associated business functions are extracted, thereby ultimately forming the second business function test scope for each other system.

[0226] Step S2056: Based on the first preset correspondence and interface call relationship set, determine the testing scope of the third transaction interface and the testing scope of the third business function of the local application system affected by cross-system program changes.

[0227] Specifically, step S2056 above includes: Step e1: Based on the set of interface call relationships, determine the target other application systems corresponding to each outbound call transaction interface.

[0228] Step e2: Obtain program change information for each target application system, and based on the program change information, determine the target outbound transaction interface that has undergone program changes during the version change period from the first version application package to the second version application package of the local application system.

[0229] Step e3: Based on the set of interface call relationships, determine the local transaction interfaces affected by the target outbound call transaction interface, and establish the test scope of the third transaction interface of the local application system affected by cross-system program changes.

[0230] Step e4: Based on the first preset correspondence and the third transaction interface test scope, determine the test scope of the third business function of the local application system affected by cross-system program changes.

[0231] In one alternative embodiment, the target outbound call transaction interface may be one or more.

[0232] In one optional embodiment, all outbound call transaction interfaces are first extracted from the interface call relationship set. Then, the interface call relationship set is queried, and the other application systems to which each outbound call transaction interface belongs, i.e., the target other application systems, are determined.

[0233] Furthermore, obtain program change information for each target application system and determine the version change period of the local application system from version 1 to version 2. Further, filter out other system interfaces that underwent program changes within the version change period and belong to the local outbound call transaction interface from the program change information, and form the corresponding target outbound call transaction interface, i.e., the local outbound call interface affected by changes in other systems.

[0234] Furthermore, using the target outbound call transaction interface as the search condition, the set of interface call relationships is queried, and all local transaction interfaces that call this outbound call interface are located. Then, all the local transaction interfaces obtained from the source are deduplicated and integrated to form the corresponding third transaction interface test scope, that is, the interface-level scope of the local interface affected by cross-system changes.

[0235] Furthermore, using the local interfaces within the third transaction interface test scope as search criteria, the first preset correspondence is queried, and all associated local business functions are extracted. Further, the extracted business functions are deduplicated and integrated to form the corresponding third business function test scope, i.e., the local business-level scope affected by cross-system changes.

[0236] Step S2057: Based on the first transaction interface test scope, the third transaction interface test scope, the first business function test scope, and the third business function test scope, determine the first full-scale test scope of the local application system.

[0237] In one optional embodiment, by integrating and deduplicating the local test scope affected by its own changes (first transaction interface test scope, first business function test scope) and the local test scope affected by cross-system changes (third transaction interface test scope, third business function test scope), the first full test scope of the local application system can be finally formed.

[0238] For example, the test scope of the first transaction interface and the test scope of the third transaction interface are merged, and duplicate interfaces are removed to form the corresponding local full-scale interface test scope. At the same time, the test scope of the first business function and the test scope of the third business function are merged, and duplicate business functions are removed to form the corresponding local full-scale business function test scope.

[0239] Furthermore, the local full-scale interface testing scope and the local full-scale business function testing scope are integrated to form the first full-scale testing scope of the local application system. This first full-scale testing scope can further include all interfaces and business functions affected by internal and external changes locally.

[0240] Step S2058: Based on multiple second transaction interface test scopes and multiple second business function test scopes, determine multiple second full-scale test scopes for multiple other application systems.

[0241] In one optional embodiment, by integrating the second transaction interface test scope and the second business function test scope of each other application system, a second full test scope of each other application system can be formed, thereby ensuring that the test scope of each other system is clear and complete.

[0242] For example, all other application systems that have a calling relationship with the local application system are traversed. Furthermore, for each other application system, its second transaction interface test scope and second business function test scope are integrated to form the second full test scope of the corresponding system.

[0243] In one example, a precise testing method across systems is provided, such as... Figure 3 As shown, the method includes: Step S101: Analyze the correspondence between the local transaction interface and Java classes and methods.

[0244] For a front-end / back-end separated development framework, each transaction interface has an entry bean, a Java class, and corresponding methods. This interface relationship is typically stored in a specific XML configuration file or described in the source code using specific symbols (such as @component, @service, @RequestMapping, etc.). Step S101 obtains and displays the correspondence between all transaction interfaces and Java classes / methods in an IT application system package by parsing the XML configuration file or specific symbols in the bytecode. In precise cross-system testing and analysis, the transaction interfaces here are called local transaction interfaces to distinguish them from transaction interfaces of other systems.

[0245] Further, step S101 above includes: Step S21: Analyze the configuration file to obtain the correspondence between the local transaction interface and Java classes and methods.

[0246] Typically, configuration files are in XML format, and their core content includes the transaction name, transaction interface code, bean or subnet name, and method name. Step S21 reads the configuration file, parses it, and stores the mapping between transaction interfaces and methods in the database. The result of the analysis in step S21 is the direct mapping between transaction interfaces and methods, which is stored in a specific data structure.

[0247] The following is an example of an XML configuration file. In this example, "A010011QR" corresponds to an entry bean ("queryBalance") and an entry method ("dealqueryBalanceQR"), thus establishing the correspondence between the transaction interface and the Java method: <?xml version="1.0" encoding="UTF-8"?> <services> <!-- Inter-bank Receipt and Payment Information Inquiry --> <service id="A010011QR" type="spring" bean-id="queryBalance" method="dealqueryBalanceQR"> < / service> < / services> Step S22: Analyze the Java bytecode to obtain the correspondence between the local transaction interface and Java classes and methods.

[0248] Some software systems use specific symbols (such as @component, @service, @RequestMapping, etc.) to annotate their interface information in the program code. By analyzing the bytecode file, the correspondence between transaction interfaces and classes / methods can be obtained based on these characteristics, and this correspondence can be stored in a specific data structure.

[0249] The code for the local annotation is as follows. The code defines a transaction interface for ` / list` using `@RequestMapping`, and its corresponding method is `toPage`: @RequestMapping({" / list"}) public String toPage(Model model, @RequestParam(value = "type",defaultValue = "1") long type) { model.addAttribute("type", Long.valueOf(type)); return "analyze / list"; } Step S23: Display the interface information within the application package. Show the number of transaction interfaces within the application package, list the names and codes of the transaction interfaces, and provide a query function.

[0250] Step S24: Display the Java class and method information within the application package. Show the number of classes and Java methods within the application package, list their names, and provide a search function.

[0251] Step S25: Display the correspondence between local transaction interfaces and Java classes / methods. Show the number of correspondences between local transaction interfaces and Java classes / methods, and list the transaction interfaces and Java classes / methods in the correspondence, providing a query function.

[0252] Step S102: Analyze the calling relationships between local Java classes and methods.

[0253] The ASM tool is used to read .class files, parse the Method / ClassNode in the bytecode framework, and then traverse each invokevirtual / invokeinterface / invokestatic instruction to record the caller → callee. Finally, distortion points such as polymorphism, lambda, and reflection are resolved as needed to obtain an accurate Java method-method call graph.

[0254] Further, step S102 above includes: Step S31: Read the binary bytecode (.class) file to obtain the raw bytecode data.

[0255] According to the Java Virtual Machine Specification, structures such as the magic number, version number, constant pool, field table, and method table are loaded into memory in byte form to provide lossless input for subsequent parsing, instruction traversal, and call chain construction, ensuring that subsequent analysis does not depend on the source code and can be consistent with the actual JVM loading.

[0256] Step S32: Use the ASM tool to traverse the class structure, parse the method bytecode line by line, identify all invoke* instructions and operands, and extract the target class and method signature.

[0257] During the traversal, line numbers, local variable tables, and stack mapping frames are recorded, providing complete contextual information for subsequent construction of accurate call graphs, backtracking of source code locations, and verification of bytecode validity, thus achieving high fidelity and traceability in static analysis.

[0258] The following bytecode example illustrates the call relationship between the method toPage and the method findExtraInfoById defined using invokevirtual: public String toPage(Model model, @RequestParam(value = "type",defaultValue = "1") long type); descriptor: (JJ)Lcom / rsea / common / exception / ExecuteResult; flags: ACC_PUBLIC Code: stack=5, locals=11, args_size=3 0: aload_0 1: getfield#9 / / Field versionService:Lcom / VersionService; 4: lload_3 5: invokevirtual #10 / / Method com / VersionService.findExtraInfoById:(J)Lcom / version / VersionInfo; Step S33: Convert the parsed call instructions into a unified description, record the caller, callee, and call type, filter out duplicates and internal JDK calls, and form the original call relationship.

[0259] The parsed call instructions are converted into a unified description, recording the caller, callee, and call type. Duplicate calls and JDK internal calls are filtered out to form the original call relationships. Simultaneously, interface implementation classes, lambda dynamic bindings, and reflection targets are added. Visibility is verified by class version and access flags, and a list of call edges without redundancy and containing semantic tags is output for direct use in subsequent dependency analysis, risk propagation, and testing recommendations. In the S32 bytecode example, the caller is `toPage`, and the callee is `findExtraInfoById`, intuitively expressed as `toPage->findExtraInfoById` (Note: Each method has a class; for ease of description, the class name of the method is omitted in this example).

[0260] Step S34: Combining inheritance and interface implementation relationships, extend the method call relationship to all possible actual targets to form a complete set of call relationships.

[0261] By combining inheritance and interface implementation relationships, the interface and method call relationships are recursively extended to all possible actual targets, forming a complete set of call relationships. The CHA / RTA algorithm is used to scan the class hierarchy, collect subclass overridden methods, generate polymorphic edges according to receiver types, and mark context-sensitive indices. The output is a complete call graph including call unrolling, lambda proxy resolution, and reflection backfilling, achieving high coverage prediction of runtime behavior from static analysis. For example, if the call relationships toPage->findExtraInfoById and findExtraInfoById->dealExtraInfo exist, the call relationship toPage->dealExtraInfo is added when organizing the full set of call relationships.

[0262] Step S35: After deduplicating nodes and call relationships, a complete method-level call relationship is generated and displayed for analysis. The displayed content includes the class and method of the caller and the class and method of the callee. Multiple call relationships form a complete method call tree, and each method in the tree can be traced back to a root node. In the previous example, findExtraInfoById can be traced back to the root node method toPage.

[0263] Step S103: Establish the correspondence between the local transaction interface and all related local Java methods.

[0264] Step S101 establishes a direct correspondence between the local transaction interface and Java methods. Step S102 establishes a method call tree. Based on the results of steps S101 and S102, a correspondence between the local transaction interface and all methods on the method call tree is established, forming transaction interface-method relationship pairs. Step S103 also displays all the relationship pairs.

[0265] Furthermore, step S103 above includes: Step S41: Read the direct correspondence between the Java methods of the local transaction interface.

[0266] Read the results of steps S21 and S22 to obtain the direct correspondence between local transactions and the entry Java method. This Java method is located at a node in the method call tree.

[0267] Step S42: Read the full Java method call relationships.

[0268] The full Java method call tree is generated by step S35. For example, there exists a full call relationship: toPage->findExtraInfoById, toPage->dealExtraInfo.

[0269] Step S43: Establish the correspondence between the local transaction interface and all Java methods (including direct and indirect correspondence).

[0270] Based on step S42, each method in the method call tree is traced upwards to the root node, which directly corresponds to a local transaction interface. A correspondence is established between this local transaction interface and each method in the method call tree. This correspondence includes a direct correspondence between transaction interfaces and methods, but more importantly, it includes indirect call relationships generated based on the method call tree. Regardless of the type of relationship, it forms the foundation for subsequent analysis of the impact of accurate testing. Combining steps S21 and S22, the transaction interface / list corresponds to the root node method toPage ( / list->toPage), and the method call relationships are toPage->findExtraInfoById, toPage->dealExtraInfo. Thus, the correspondences between transaction interfaces and methods are established: / list->toPage, / list->findExtraInfoById, and / list->dealExtraInfo.

[0271] Step S44 displays the mapping between the local transaction interface and Java methods. The list displays the transaction interface code, transaction interface name, class name, and method name, and provides a function to search by transaction interface code.

[0272] Step S104: Analyze the program differences between the two versions of the application system.

[0273] Specifically, Git diff is a common tool for comparing differences between applications, and there are other similar tools. However, the biggest problem with these tools is that they require access to the system's source code, which may be an unacceptable risk for security-sensitive enterprises. Step S104 innovatively extracts the attribute parameters of the methods based on the bytecode, and compares the differences of the methods based on the feature variables formed by these attribute parameters, forming a list of methods that differ between the two versions, and showing these methods and the reasons for the changes (such as "add", "update", "delete", etc.).

[0274] Further, step S104 above includes: Step S51: Read the bytecode file of the application package.

[0275] Read the bytecode file of the application package, that is, recursively scan the JAR, WAR, module directories and nested dependencies, unpack them layer by layer in the loading order, and traverse the list of methods of ClassNode through the ASM bytecode tree API.

[0276] Step S52: Extract the attribute parameters of each Java method in the bytecode.

[0277] Each method has several parameters. Key parameter information such as access, name, desc, signature, exception table, annotation, and parameter name are extracted one by one for subsequent calculations.

[0278] Step S53: Calculate the hash value of each Java method based on its attribute parameters to form a feature variable. Concatenate the class name, method name, descriptor, generic signature, modifier, exception table, parameter names, and annotations into a UTF-8 string, extract the SHA-256 hash, truncate it to 128 bits, and then mix it with the local variable slot number and the line number table CRC to generate a 64-bit long integer feature variable for subsequent difference comparison.

[0279] Step S54: Compare the characteristic variables of all Java methods in the two packages. For methods that have been modified, record the specific changes (additions, modifications, and deletions, etc.). For methods that have been added or deleted and exist only in one version, record them directly. For methods that exist in both versions, compare the characteristic variables to determine if the method has changed, and record the changed method.

[0280] Step S55: Generate and display the method-level difference lists for the two application packages. For methods with different change types (add, delete, update), mark them as "add," "delete," and "update," respectively, forming a list of differing methods. Provide display functions for system, version number, compared version number, differing method, and difference type. For example, the method `dealExtraInfo` is marked as "update."

[0281] Step S105: Analyze the scope of the local system's transaction interface test caused by the program change.

[0282] Based on step S103, each local interface corresponds to a large number of methods. Starting from the methods with differences analyzed in step S104, we find the corresponding local transaction interfaces for these methods, forming a set of local transaction interfaces affected by the change. Each transaction interface in the set has one or more corresponding methods that have changed. The result of the analysis in step S105 is all the transaction interfaces affected by changes in the local program, which is the precise test scope at the interface level. Based on the correspondence between business functions and transaction interfaces, we further form a precise test scope for the business function side of this system.

[0283] Further, step S105 above includes: Step S61: Read the mapping relationship between local interfaces and Java methods. Read the results of step S43 and load the mapping relationship information between local interfaces and Java methods (the mapping relationship between / list->toPage, / list->findExtraInfoById, and / list->dealExtraInfo interfaces and methods).

[0284] Step S62: Read the list of Java method differences. The result of step S55: Load information on all methods with differences in the new version after the difference comparison (such as the method `dealExtraInfo`, which is a "update" type difference).

[0285] Step S63: Analyze the local transaction interfaces corresponding to all differing methods. Based on steps S61 and S62, obtain the local interfaces corresponding to all differing methods using the method name as a clue. Form a set of local transaction interfaces affected by local program changes (based on the relationship / list->dealExtraInfo, and since dealExtraInfo belongs to "update", then transaction interface / list is the local transaction interface affected by the change).

[0286] Step S64: Read the mapping relationship between the local transaction interface and the business function. The mapping relationship between the local transaction interface and the business function is imported in advance; this step involves importing these mapping relationships.

[0287] Step S65: Define the test scope for the local system's transaction interface caused by the program change. Based on step S63, consider the situation where multiple methods jointly affect a local interface, and form a precise test scope at the local system interface level. Each included local interface needs to be covered in subsequent tests.

[0288] Step S66 defines the scope of business function testing for the local system resulting from the program change. Based on steps S64 and S65, the business functions that business personnel can understand and that need to be included in the precise testing scope are identified. Each business function included in the precise testing scope must be covered by subsequent testing.

[0289] Step S106: Analyze the correspondence between the local program and the outbound call transaction interface.

[0290] A system's outbound call relationships are typically stored in an XML configuration file or registered and published on a service bus (ESB)-like system. Step S106 obtains all possible outbound transaction interfaces of other systems by parsing the configuration file or calling the ESB's service interface. Step S106 then iterates through all local method contents, recording which method calls which transaction interface of an external system, forming method-outbound transaction interface relationship pairs, and finally compiles all method-outbound transaction interface relationship pairs in the local system to form a relationship list.

[0291] Furthermore, step S106 above includes: Step S71: Analyze the outbound call configuration file and compile a list of all outbound call transaction interfaces for this system to other systems. Some systems' outbound call transaction interfaces are stored in XML format files; parse the XML files to obtain the list of outbound call transaction interfaces.

[0292] Below is an example of an outbound call configuration file that illustrates the availability of an outbound call service called / interbankTransfer.

[0293] <outbound-services> <!-- Inter-bank transfer transaction --> <service id=" / interbankTransfer" type="020000" seek-type="remote" Step S72: Read the service bus interface to obtain a list of all backend transaction interfaces. The service bus system, represented by the ESB system, manages the enterprise's transaction interface information. By calling the ESB's services, the outbound call transaction interfaces of the backend system can be obtained.

[0294] Step S73: Analyze the local program and establish the correspondence between local Java methods and outbound call transaction interfaces. Traverse the local program, retrieve the location of the outbound call interfaces generated in steps S51 and S52, and determine the specific method that calls the outbound call transaction interface. Establish the correspondence between local methods and outbound call transaction interfaces.

[0295] In the following example, if the method dealExtraInfo is found to call the outbound transaction interface / interbankTransfer, then the outbound relationship dealExtraInfo-> / interbankTransfer is established and the relationship is stored in a specific data structure.

[0296] public void dealExtraInfo() { try { obOutVo = invokeOutExecutor(null, " / interbankTransfer"); } catch (CommonException e) { LOG.error("+ e);} } Step S74 displays the correspondence between local Java methods and outbound call transaction interfaces. A list shows the local classes, methods, and their corresponding outbound call interfaces.

[0297] Step S107: Establish the calling relationship between the local transaction interface and the outbound call transaction interface.

[0298] Specifically, Java methods serve as the medium for establishing relationships between local transaction interfaces and outbound call transaction interfaces. For some methods, a relationship with the local interface is established based on step S103, and a corresponding relationship with the outbound call transaction interface is established based on step S106. This allows local interfaces and outbound call transaction interfaces with the same method to establish a correspondence, forming a call relationship such as interface a1 of system A calling transaction interface b1 of external system B (denoted as a1@A->b1@B). This process simplifies and deduplicates the calls, resulting in accurate call relationships between local and outbound transaction interfaces. Step S107 also asynchronously establishes this inter-system transaction interface call relationship, which is the core and foundation for accurate cross-system testing in this example.

[0299] Furthermore, step S107 above includes: Step S81: Read the mapping relationship between local interfaces and local Java methods. Read the results of step S43 and load the relationship information between local interfaces and local Java methods (such as the mapping relationship between interfaces and methods of / list->toPage, / list->findExtraInfoById, and / list->dealExtraInfo).

[0300] Step S82: Read the correspondence between the local Java method and the outbound call transaction interface. Read the results of step S73 and load the relationship information between the local Java method and the outbound call transaction interface (e.g., dealExtraInfo-> / interbankTransfer outbound call relationship).

[0301] Step S83: Establish the correspondence between the local interface and the outbound call transaction interface and remove duplicates. Using the local method as a bridge, and combining the information from steps S81 and S82, establish the correspondence between the local interface and the outbound call transaction interface. For example, a call relationship where system A's interface a1 calls external system B's transaction interface b1 (denoted as a1@A->b1@B). This relationship is directional; the left side of the arrow represents the caller, and the right side represents the callee. Subsequent analysis and precise testing will be conducted based on the different call directions.

[0302] Based on the example above, the transaction interface / list and the outbound call transaction interface / interbankTransfer establish an outbound call relationship, marked as / list-> / interbankTransfer, and stored in a specific data structure.

[0303] Step S84 displays the correspondence between local interfaces and outbound call transaction interfaces. Local interfaces and outbound call transaction interfaces with a calling relationship can be queried based on the transaction interface number.

[0304] Step S108: Analyze the scope of transaction interface testing for other systems affected by the local program changes.

[0305] Specifically, precise testing and analysis are conducted on multiple systems within the enterprise. In step S105, the call relationships between local and outbound transaction interfaces for each system are compiled. The analysis results from all systems are then aggregated to form an enterprise-level set of transaction interface-level call relationships, and the transaction interface call chain is then established. Step S108 focuses on the transaction interface on the called side of the call chain (e.g., transaction interface b1). If a call relationship of a1@A->b1@B exists, and b1 is included in the precise testing scope affected by the change in step S107, then a1 must also be included in the precise testing scope. This process continues, forming a complete precise testing scope for other affected systems' transaction interfaces based on the inter-system transaction interface call relationships. Based on the correspondence between business functions and transaction interfaces, the business functions of other systems requiring precise testing are identified.

[0306] Furthermore, step S108 above includes: Step S91: Read the relationship between all local interfaces and outbound call transaction interfaces under the project.

[0307] Each system analyzed the call relationships between local and outbound interfaces (e.g., transaction interface call relationships like / list-> / interbankTransfer), and aggregated this information to form an enterprise-level set of interface call relationships. While analyzing a single system only reveals which outbound interface the local interface called, and not which interfaces from other systems called the local interface, aggregating the analysis results from all systems allows for the retrieval of instances where the local interface was called.

[0308] Step S92: Read the list of transaction interfaces affected by the local program change.

[0309] Read the results of step S85, namely the transaction interface of the local system caused by the program change. Assume that the transaction interface / interbankTransfer belongs to a certain business system B. When analyzing this system, a method Methodx changed, which affected / interbankTransfer (this analysis process can be referred to in S65, the change of local code affected the local transaction interface).

[0310] Step S93: Analyze the list of transaction interfaces of other systems affected by the local change to form the test scope of transaction interfaces of other systems.

[0311] Based on the information from steps S91 and S92, analyze which other systems have made outbound calls to transaction interfaces affected by local changes. These outbound transaction interfaces need to be included in the precise testing scope. The analysis results of step S903 realize the complex analysis process of local change procedure -> locally affected transaction interfaces -> transaction interfaces of other systems making outbound calls to locally affected interfaces. For cross-system change impact analysis of "he calls me, I change and affect him", a precise testing scope at the interface level is formed across systems. For example, if / interbankTransfer has been called by / list, when / interbankTransfer enters the affected scope list, this step will include / list in the transaction interface testing scope of other systems, forming a precise cross-system testing list.

[0312] Step S94: Read the correspondence between transaction interfaces and business functions of other systems.

[0313] Step S95: Analyze the scope of business function testing for other systems affected by the local change.

[0314] This enables complex analysis and processing, such as local change procedures -> locally affected transaction interfaces -> transaction interfaces in other systems -> business functions in other systems affected. For cross-system change impact analysis of "he calls me, I change and affect him", it forms a precise test scope at the cross-system business function level.

[0315] Step S109: Analyze the scope of the local system's transaction interface test affected by changes in other system programs.

[0316] Specifically, taking the transaction interface on the calling side of the transaction interface call chain as the analysis object (e.g., transaction interface a1), if there is a call relationship of a1@A->b1@B, and given the changes to the program corresponding to transaction interface b1, then a1 should be included in the precise testing scope. This process continues, forming a complete precise testing scope at the transaction interface level for local interfaces affected by changes in other systems, based on the inter-system transaction interface call relationships. Based on the correspondence between business functions and transaction interfaces, the business functions in other systems that require precise testing are identified.

[0317] Furthermore, step S109 above includes: Step S1001: Read the relationship between the local interface and the outbound transaction interface (e.g., the local system / list has made outbound calls to the transaction interface of another system / interbankTransfer).

[0318] Step S1002: Analyze the other systems to which the outbound call transaction interface belongs.

[0319] Each transaction interface belongs to a system. The system retrieves all outbound call transaction interfaces on the local interface and checks if the system has a version package and whether it has undergone precise testing and analysis. Systems that have undergone precise testing and analysis are recorded.

[0320] Step S1003: Read the impact of program changes on all outbound call interfaces and record the reason for the change of each outbound call transaction interface affected by the change.

[0321] For outbound call transaction interfaces that have been changed, determine whether the change time is in the middle of the two version changes in this system. If so, record it to form a "valid" changed transaction interface in other systems (for example, if the transaction interface / interbankTransfer of other systems has been found to have changed and the change time also meets the requirements).

[0322] Step S1004: Analyze the impact of these outbound call transaction interfaces on the local transaction interface to form the test scope of the local transaction interface.

[0323] Combining the "valid" change transaction interfaces of other systems in step S1003, and based on the relationship between the local interface and the outbound call transaction interface read in step S1001, the interfaces affected by the changes in the outbound call transaction interfaces of other systems are filtered out. This achieves a complex analysis process: other system change procedures -> affected transaction interfaces of other systems -> affected transaction interfaces of the local system. For cross-system change impact analysis such as "I call him, he changes and affects me," a precise test range at the cross-system transaction interface level is formed (in the previous example, if the local / list makes an outbound call to / interbankTransfer, and / interbankTransfer undergoes a valid change, then / list enters the precise test range).

[0324] Step S1005: Read the correspondence between the transaction interface and business function of the local system.

[0325] Step S1006: Analyze the scope of business function testing affected by changes in other systems in the local system.

[0326] Combining steps S1004 and S1005, analyze the local business functions affected by changes in other system versions. Implement a complex analysis process: other system change procedures -> affected transaction interfaces in other systems -> affected transaction interfaces locally -> affected business functions locally. For cross-system change impact analysis such as "I call him, he changes and affects me," form a precise test scope at the cross-system business function level.

[0327] This example provides a precise cross-system testing method that performs accurate test scope analysis based on a thorough understanding of the complex upstream and downstream transaction interface call relationships between systems. It establishes cross-system call chains at the transaction interface level using interface outbound call analysis technology. Any change to the program code corresponding to any transaction interface in this call chain will bring the transaction interfaces of other related systems in that chain into the precise test scope. All analysis is based on the application package (executable code) and does not involve accessing the source code.

[0328] In one specific embodiment, the test scenario is as follows: taking the ERP system (local application system) of a medium-to-large discrete manufacturing enterprise as the core, it needs to be upgraded from version V6.2 to version V6.3, and at the same time, there are complex cross-system call relationships with the Manufacturing Execution System (MES), Warehouse Management System (WMS), Financial Accounting System (FMS), and Procurement Management System (PMS).

[0329] The specific testing process includes: 1. Basic Data Acquisition: Obtain the WAR packages of V6.2 (first version) and V6.3 (second version) from the ERP system deployment server, unpack them and extract all Java bytecode files (.class); read the system configuration file (XML format) and outbound call configuration file to obtain the mapping configuration between interfaces and Java classes / methods, and the list of interfaces for outbound calls to other systems; call the Enterprise Service Bus (ESB) interface to obtain the full list of backend outbound call transaction interfaces.

[0330] 2. Construct different core relationships.

[0331] (1) Correspondence between interfaces and Java classes / methods: Parse the XML configuration file to obtain the first correspondence such as “A01001 (purchase order creation interface) → PurchaseController → createPurchase”; analyze the bytecode annotations to obtain the second correspondence such as “ / inventory / query (inventory query interface) → InventoryController → queryStock”, and integrate them into the target correspondence; (2) Method call relationship: The bytecode is parsed by the ASM tool, the invoke* instruction is identified, and the call relationship such as "createPurchase→checkSupplier→validateBudget" is obtained. The polymorphic call is extended by combining the class inheritance relationship, and the first full call relationship is formed after deduplication. (3) Correspondence between interface and full method: Based on the correspondence between the target and the method call tree, the full correspondence between the target and the method is established by tracing the method call tree: “A01001 interface → createPurchase (entry method) → checkSupplier (downstream method) → validateBudget (downstream method)”.

[0332] 3. Version difference analysis: Extract the attribute parameters (name, parameters, annotations, etc.) of Java methods from the bytecode of the two versions, calculate the SHA-256 hash value to form feature variables; compare the feature variables and find that "validateBudget (budget verification method)" is marked as "update" and "syncStockToWMS (inventory synchronization method)" is marked as "add", forming a program difference list.

[0333] 4. Defining the scope of full-scale testing.

[0334] (1) Scope of impact of ERP system: Through the full correspondence of the target, trace the interface corresponding to the difference method (A01001 purchase order creation interface, / inventory / query inventory query interface), and combine the interface with the business function mapping to form the first transaction interface test scope and the first business function test scope of "purchase order creation and inventory query". (2) Construction of cross-system call relationship: Parse the outbound call configuration file and ESB list to establish target call relationships such as " / inventory / query→WMS system / stock / check" and "A01001→PMS system / supplier / verify"; (3) Scope of testing for related systems: The affected interfaces of the ERP system will be transmitted to the related systems to form the second transaction interface testing scope and corresponding business function scope of the MES system “production plan synchronization interface” and the WMS system “inventory verification interface”; (4) Scope of cross-system impact of ERP system: It was found that the “supplier / verify interface” of PMS system was changed during the ERP version change period. Tracing back to the A01001 interface of ERP, the test scope of the third transaction interface and the test scope of the third business function of “purchase order creation” were formed. (5) Full-scale integration: The first full-scale test scope of the ERP system includes interfaces and business functions that are affected by self-influence and cross-system influence; the second full-scale test scope of the associated system is the exclusive scope affected by ERP changes.

[0335] 5. Test Execution and Result Output: First, according to the first and second full-scale test scopes, precise testing was conducted on the ERP system's purchase order creation, inventory query functions, and the related interfaces of MES, WMS, and PMS. Second, the compatibility and data consistency of the cross-system call chain (e.g., ERP purchase order creation → PMS supplier verification → WMS inventory reservation) were verified. Finally, a test result report was output, identifying issues such as the budget verification method modification not affecting business processes and the need to optimize exception handling in the inventory synchronization and addition method. The test was ultimately deemed passed, supporting the deployment of ERP system version V6.3.

[0336] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A testing method for an application system, characterized in that, The application system includes a local application system and multiple other application systems, which are connected via an Enterprise Service Bus system; the method includes: Obtain the system configuration file, local application package, and local Java bytecode file corresponding to the local application system; Obtain the first Java bytecode file of the first version application package of the local application system, the second Java bytecode file of the second version application package, and the outbound call configuration file; Based on the system configuration file, the local application package, and the local Java bytecode file, the target full correspondence of the local application system is determined. The target full correspondence is the complete correspondence between all local transaction interfaces and all local Java methods in the local application system. All local Java methods include all interface local methods, multiple entry Java methods, and multiple downstream Java methods. Based on the first Java bytecode file and the second Java bytecode file, determine a list of program differences between the first version application package and the second version application package; Based on the target full-scale correspondence, the program difference list, and the outbound call configuration file, the first full-scale test scope of the local application system and the multiple second full-scale test scopes of the multiple other application systems are determined; Based on the first full test range and the multiple second full test ranges, the application system is tested to obtain the target test results of the application system.

2. The method according to claim 1, characterized in that, Based on the system configuration file, the local application package, and the local Java bytecode file, the target full mapping relationship of the local application system is determined, including: Based on the system configuration file and the local Java bytecode file, multiple target correspondences of the local application system are determined, wherein the multiple target correspondences include the correspondence between all local transaction interfaces in the local application system and their corresponding entry local Java classes, and the entry local methods in the entry local Java classes; Based on the local application package and the local Java bytecode file, determine the first full call relationship between all local Java classes and their corresponding full local methods in the local application system; Based on the multiple target correspondences and the first full call relationship, the target full call relationship of the local application system is determined.

3. The method according to claim 2, characterized in that, Based on the system configuration file and the local Java bytecode file, multiple target mappings of the local application system are determined, including: The system configuration file is parsed, and multiple first correspondences of the local application system are determined. Each first correspondence represents a one-to-one correspondence between each local first transaction interface in the local application system and the corresponding local Java class of each first interface, and each local method of each first interface in each local Java class of the first interface. The annotation symbols in the local Java bytecode file are analyzed and identified, and multiple second correspondences of the local application system are determined. Each second correspondence represents a one-to-one correspondence between each local second transaction interface in the local application system and the corresponding local Java class of each second interface, and each local method of each second interface in each local Java class of the second interface. Based on the plurality of first correspondences and the plurality of second correspondences, the plurality of target correspondences of the local application system are determined.

4. The method according to claim 2, characterized in that, Based on the local application package and the local Java bytecode file, the first full call relationship between all full native Java classes and their corresponding full native methods in the local application system is determined, including: The binary bytecode file corresponding to the local Java bytecode file is read using the Java Virtual Machine Specification, and multiple raw bytecode data are obtained; The class structure of the multiple raw bytecode data is traversed, and multiple raw call relationships are determined; Based on the local application package, obtain all local Java class data and all local interface bytecode data of the local application system; Based on the multiple original call relationships, the full set of native Java class data, and the full set of native interface bytecode data, a class hierarchy is constructed and multiple actual call targets are determined; Recursively search and expand the multiple original call relationships and the multiple actual call targets, and determine the second full call relationship between all full native Java classes and their corresponding full native methods in the local application system; The second full call relationship is deduplicated to obtain the first full call relationship between the full local Java classes and the full local methods in the local application system.

5. The method according to claim 4, characterized in that, The class structure of the multiple raw bytecode data is traversed, and multiple raw call relationships are determined, including: The class structure of the multiple raw bytecode data is traversed, and multiple initial call instruction information is identified. Each initial call instruction information includes the class and method signature information of the caller and the callee for each call behavior. The multiple initial call instruction information is converted into a format to obtain multiple target call instruction information with a unified description format; Redundancy filtering is performed on the multiple target call instruction information, and the multiple original call relationships are determined.

6. The method according to claim 2, characterized in that, Based on the multiple target correspondences and the first full-scale call relationship, the target full-scale correspondence of the local application system is determined, including: Based on the multiple target correspondences, multiple direct mapping relationships of the local application system are obtained. The multiple direct mapping relationships include the direct correspondence between all local transaction interfaces in the local application system and the corresponding multiple entry Java methods. Based on the first full call relationship, the direct call chain information and indirect call chain information between the full local Java classes and the full local methods in the local application system are obtained, and the method call tree of the local application system is constructed. Based on the method call tree, each downstream Java method is traced back to its corresponding root node entry Java method, and multiple indirect mapping relationships are established between all local transaction interfaces in the local application system and the corresponding multiple entry Java methods and multiple downstream Java methods. Based on the multiple direct mapping relationships and the multiple indirect mapping relationships, the target full correspondence relationship of the local application system is determined.

7. The method according to claim 1, characterized in that, Based on the first Java bytecode file and the second Java bytecode file, determine a list of program differences between the first version application package and the second version application package, including: Extract multiple first attribute parameters from each first Java method in the first Java bytecode file and multiple second attribute parameters from each second Java method in the second Java bytecode file; Based on the plurality of first attribute parameters, calculate the hash value of each first Java method and construct a first feature variable; Based on the plurality of second attribute parameters, calculate the hash value of each second Java method and construct a second feature variable; The first feature variable and the second feature variable are compared to determine the program difference list between the first version application package and the second version application package of the local application system.

8. The method according to claim 1, characterized in that, Based on the target full-scale correspondence, the program difference list, and the outbound call configuration file, a first full-scale test scope for the local application system and multiple second full-scale test scopes for the multiple other application systems are determined, including: Based on the target full correspondence and the program difference list, determine the set of local transaction interfaces of the local application system affected by its own program changes; Based on the local transaction interface set and the first preset correspondence, the test scope of the first transaction interface and the test scope of the first business function affected by the local application system's own program changes are determined. The first preset correspondence is the correspondence between all local transaction interfaces and business functions in the local application system. Based on the target full correspondence and the outbound call configuration file, determine the target call relationship between all local transaction interfaces and multiple outbound call transaction interfaces in the local application system; Based on the target call relationship, determine the set of interface call relationships; Based on the local transaction interface set, the interface call relationship set, and the second preset correspondence, the test scope of multiple second transaction interfaces and the test scope of multiple second business functions of the multiple other application systems are determined. The multiple second preset correspondences are the correspondences between transaction interfaces and business functions in the multiple other application systems. Based on the first preset correspondence and the set of interface call relationships, determine the testing scope of the third transaction interface and the testing scope of the third business function of the local application system affected by cross-system program changes; Based on the first transaction interface test scope, the third transaction interface test scope, the first business function test scope, and the third business function test scope, the first full-scale test scope of the local application system is determined. Based on the test scope of the multiple second transaction interfaces and the test scope of the multiple second business functions, the test scope of the multiple second full-scale tests of the multiple other application systems is determined.

9. The method according to claim 8, characterized in that, Based on the target full correspondence and the outbound call configuration file, the target call relationship between all local transaction interfaces and multiple outbound call transaction interfaces in the local application system is determined, including: The outbound call configuration file is analyzed, and an initial list of outbound call transaction interfaces for the local application system to call the multiple other application systems is determined. Use the service bus interface of the enterprise service bus system to obtain the full list of backend outbound call transaction interfaces; Based on the initial outbound call transaction interface list and the backend full outbound call transaction interface list, determine the full outbound call transaction interface list of the local application system; Traverse the local programs of the local application system and establish multiple third-party correspondences between all local Java methods in the local application system and multiple outbound transaction interfaces in the full list of outbound transaction interfaces; Based on the target full correspondence and the multiple third correspondences, establish the initial call relationship between all local transaction interfaces in the local application system and the multiple outbound call transaction interfaces; The initial call relationship is deduplicated to obtain the target call relationship of the local application system.

10. The method according to claim 8, characterized in that, Based on the first preset correspondence and the set of interface call relationships, the testing scope of the third transaction interface and the testing scope of the third business function of the local application system affected by cross-system program changes are determined, including: Based on the set of interface call relationships, determine the target other application systems corresponding to each outbound call transaction interface; Obtain program change information for each of the target other application systems, and based on the program change information, determine the target outbound call transaction interface that has undergone program change during the version change period from the first version application package to the second version application package of the local application system, wherein the target outbound call transaction interface is one or more. Based on the set of interface call relationships, determine the local transaction interfaces affected by the target outbound call transaction interface, and establish the test scope of the third transaction interface of the local application system affected by cross-system program changes; Based on the first preset correspondence and the third transaction interface test scope, the test scope of the third business function of the local application system affected by cross-system program changes is determined.

Images