Cross-platform testing method, electronic device, storage medium, and computer program product

Abstract

The present application discloses a cross-platform testing method, electronic device, storage medium and computer program product, which relate to the field of software testing technology. By abstracting the execution logic of test cases in different operating systems into a set of universal testing strategies, the policy execution parameters in the universal testing strategies are adjusted based on the operating system type of the target testing platform, so that the universal testing strategies can adapt to various operating system types, and cross-platform execution of the universal testing strategies in different operating systems is achieved without the need to write different universal testing strategies for different operating systems, thereby improving the overall efficiency and flexibility of the testing method.

Description

Technical Field

[0001] The present application relates to the field of software testing technology, and in particular to a cross-platform testing method, electronic device, storage medium, and computer program product. Background Art

[0002] As computer systems become increasingly complex, various types of software are emerging. For example, host security software has become an essential component in protecting computer systems from external attacks, viruses, and malware threats. Therefore, testing the operational capabilities of various software types, such as host security software, has become a crucial topic.

[0003] Currently, software testing mostly relies on fixed automated testing tools. Because the kernel structure and calling methods vary across operating system platforms, a single testing tool is often only applicable to a specific operating system or hardware platform. Testing software on different operating system platforms typically requires writing different testing tools for each operating system.

[0004] Therefore, existing testing methods cannot meet cross-platform requirements, resulting in low testing efficiency and insufficient flexibility. Summary of the Invention

[0005] The present application provides a cross-platform testing method, electronic device, storage medium and computer program product to at least solve the problems of low efficiency and insufficient flexibility of testing methods in related technologies.

[0006] This application provides a cross-platform testing method, including:

[0007] Obtain the general test strategy corresponding to the test case. The general test strategy is generated based on the execution logic of the test case in different operating systems. The general test strategy uses a scripting language that is common to different operating systems.

[0008] Get the operating system type of the target test platform;

[0009] According to the operating system type, the policy execution parameters in the general test policy are adjusted to obtain the target test policy corresponding to the target test platform;

[0010] Execute the target test strategy on the target test platform.

[0011] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned cross-platform testing methods when executing the computer program.

[0012] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned cross-platform testing methods are implemented.

[0013] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above-mentioned cross-platform testing methods when executed by a processor.

[0014] This application abstracts the execution logic of test cases in different operating systems into a set of universal test strategies, and adjusts the policy execution parameters in the universal test strategies based on the operating system type of the target test platform, so that the universal test strategies can adapt to various operating system types and realize cross-platform execution of the universal test strategies in different operating systems. There is no need to write different universal test strategies for different operating systems, thereby improving the overall efficiency and flexibility of the testing method. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0016] Figure 1 A flow chart of a cross-platform testing method provided by an embodiment of the present disclosure;

[0017] Figure 2 A flow chart of a cross-platform testing method provided by another embodiment of the present disclosure;

[0018] Figure 3 A schematic diagram of the structure of a cross-platform testing device provided in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0019] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0020] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0021] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0022] Figure 1 A flow chart of a cross-platform testing method provided by an embodiment of the present disclosure. This method can be applied to a test tool on a target test platform, where the test tool can be a test script running on the target test platform or an application installed on the target test platform. Optionally, the test tool is written in Lua.

[0023] like Figure 1 As shown, the method includes the following steps:

[0024] S101. Obtain a universal test strategy corresponding to a test case. The universal test strategy is generated according to the execution logic of the test case in different operating systems. The universal test strategy adopts a scripting language that is universal for different operating systems.

[0025] The specific operation paths for implementing related functions of the same test case in different operating systems may vary, but the execution logic of different operating systems is similar.

[0026] For example, adding a file protection rule on a Linux system as . / config mac_file add 100 0 “ / usr / bin / rm” 0 “ / root / test” means that rm cannot delete / root / test. Adding a file protection rule on a Windows system as config.exe mac_file add 100 0 “C:\del.exe” 0 “C:\test” means that del.exe cannot delete C:\test. The specific paths for adding file protection rules differ in these two operating systems, but the execution logic is the same: the "executor" (such as rm or del.exe) uses a configuration tool (such as config or config.exe) to add protection rules for the "execution object" (such as / root / test or C:\test). This means that the same test case has similar execution logic across different operating systems.

[0027] In this step, the core business logic of the test cases in each operating system is analyzed, the parameters that depend on platform differences are extracted, and only the common execution logic is encapsulated into a universal test strategy that is common to multiple platforms so that different operating systems can execute the universal test strategy.

[0028] Optionally, general test strategies can be written in Lua. Lua is lightweight, and general test strategies based on Lua can be run without compilation, shortening the test case development and debugging cycle.

[0029] S102: Obtain the operating system type of the target test platform.

[0030] The target test platform is the platform that needs to be tested, such as a computer with the software to be tested installed, an electronic device responsible for executing the business to be tested, etc.

[0031] The operating system type refers to the system category to which the target test platform belongs, such as Linux, Windows, macOS, etc.

[0032] Through the preset system feature detection mechanism, the operating system feature values ​​of the target operating platform are obtained, such as the operating system environment variables, system command return values ​​and other system feature values, and the operating system type of the target test platform is further determined based on the system feature values.

[0033] S103: Adjust the policy execution parameters in the general test policy according to the operating system type to obtain a target test policy corresponding to the target test platform.

[0034] The policy execution parameters are parameters related to the differences between different operating system types and platforms, that is, the policy execution parameters of different operating system types are different.

[0035] Based on predefined parameter mapping rules, the parameter items in the general test strategy are adjusted to the policy execution parameters corresponding to the operating system type of the target test platform, so as to achieve the adaptation of the general test strategy to the target test platform in terms of specific execution parameters.

[0036] S104: Execute the target test strategy on the target test platform.

[0037] Specifically, based on the execution logic in the target test strategy and the strategy execution parameters adapted to the target test platform, user operations are simulated and data is exchanged with the kernel driver module of the target test platform to realize strategy writing or deletion, operation triggering and result verification, and finally obtain the test results corresponding to the target test strategy.

[0038] The embodiment of the present disclosure obtains a universal test strategy corresponding to a test case, the universal test strategy is generated according to the execution logic of the test case in different operating systems, and the universal test strategy adopts a scripting language common to different operating systems; obtains the operating system type of the target test platform; adjusts the policy execution parameters in the universal test strategy according to the operating system type, and obtains the target test strategy corresponding to the target test platform; executes the target test strategy on the target test platform; abstracts the execution logic of the test case in different operating systems into a set of universal test strategies, and adjusts the policy execution parameters in the universal test strategy based on the operating system type of the target test platform, so that the universal test strategy can adapt to various operating system types, realize cross-platform execution of the universal test strategy in different operating systems, and does not need to write different universal test strategies for different operating systems, thereby improving the overall efficiency and flexibility of the testing method.

[0039] In some embodiments, a general test strategy corresponding to the test case is generated based on the execution logic of the test case in different operating systems, including: obtaining a policy framework of the test case; obtaining policy execution parameters corresponding to the test case in different operating system types; and obtaining a general test strategy corresponding to the test case based on the policy framework and the policy execution parameters.

[0040] Among them, the general test strategy includes policy information items and policy execution parameter items; the policy information items include at least one or more of the policy name, policy operation type, policy execution order, user account, and policy authority; the policy execution parameter items include at least the configuration tools, execution subjects, and executed objects required to execute test cases on platforms of different operating systems.

[0041] The strategy framework refers to the core logical structure of the test case, which is used to abstract the common parts of the same test objectives in different operating systems.

[0042] The policy framework includes policy information items, which are used to configure or describe the static properties of the general test policy.

[0043] The policy name is used to identify the general test policy. For example, based on the user's configuration operation, the policy name is determined to be "file deletion protection test."

[0044] The policy operation type defines the specific operation behavior of the general configuration policy in the platform, including writing or deleting the policy in the platform.

[0045] The strategy execution order refers to the timing label of multi-step testing. For example, during a test process, the executed test case includes multiple test steps, and each test step can be abstracted as a general test strategy. Alternatively, during a test process, multiple test cases need to be executed in sequence, and each test case can be abstracted as one or more general test strategies. Each general test strategy corresponds to a test step or test case. The strategy execution order corresponds to the execution timing of the test cases in the test, and / or the execution timing of the test steps in a single test case.

[0046] The user account specifies the authority subject for executing the test, such as the administrator account or ordinary user in the target test platform; if the login account in the current target test platform does not match the user account of the general test policy, the general test policy will be refused to execute, or the execution of the general test policy will be judged to have failed.

[0047] Policy permissions refer to the access control rules of the general test policy, such as the general test policy's read and write permission control for data in the target test platform.

[0048] Optionally, when the policy permission is defined as the first permission parameter, the general test policy has read data permission; when the policy permission is defined as the second permission parameter, the general test policy has write data permission; when the policy permission is defined as the third permission parameter, the general test policy has both read and write data permissions, where the third permission parameter is the sum of the first permission parameter and the second permission parameter; and when the policy permission is defined as the fourth permission parameter, the general test policy has execute permission. The first permission parameter, the second permission parameter, the third permission parameter, and the fourth permission parameter are all different.

[0049] The above-mentioned policy permission definition method can simply and effectively indicate the access rights of the general test policy. The clear permission definition rules make it easy for developers to maintain it. At the same time, it is easy for the target operating platform to read, identify and verify the policy permissions, avoiding complex calculation processes and saving computing resources of the target operating platform during policy management and execution.

[0050] The above-mentioned policy information items are independent of the operating system type of the platform and are used to control the execution process of the general test policy.

[0051] Strategy execution parameters are the differentiated configurations required to implement the same test logic in different operating systems.

[0052] The configuration tool is used to simulate the client application layer of the application software in the target test platform, and to exchange data with the kernel driver module during the test process, such as issuing policies to the kernel driver module, querying policies, or receiving alarm information from the kernel driver module. Different operating systems use different kernel functions for their kernel drivers, as well as different communication methods between the client application layer and the kernel driver layer. For example, in Linux systems, the ioctl command is used to communicate with the kernel driver, while in Windows systems, the FltCreateCommunicationPort communication port is used to communicate with the kernel driver. Therefore, different configuration tools need to be written for different operating systems, and the configuration tools must be configured to be callable by general test strategies. When executing a general test strategy, the configuration tool corresponding to the operating system of the target test platform can be called to perform the tasks required by the general test strategy or to implement the functions required by the general test strategy.

[0053] That is to say, according to the execution logic of the test case in different operating systems, the policy execution parameters corresponding to the test case in different operating system types are obtained, and it also includes obtaining the configuration tools corresponding to different operating systems. The configuration tools are generated according to the kernel functions and communication methods of different operating systems, and are used to simulate the client application layer during the execution of the test case and exchange data with the kernel driver module.

[0054] The execution subject is the party that initiates the operation during the test. This typically refers to the owner of the operation permissions or the application or service that triggers the test behavior. During the test, the execution subject simulates the execution of operations by entities with different permissions to verify whether the kernel module can correctly identify and restrict unauthorized behavior.

[0055] The executed object refers to the target object that is operated during the test process, which usually represents a resource that needs to be protected or a party that is subject to policy constraints.

[0056] Different operating systems have different ways of identifying configuration tools, execution subjects, and executed objects. The configuration tools, execution subjects, and executed objects in the general test strategy need to be dynamically mapped according to the operating system type of the target test platform.

[0057] For example, to add a file protection policy on a Linux system using the config configuration tool, run: . / config mac_file add 100 0 “ / usr / bin / rm” 0 “ / root / test”, indicating that rm cannot delete / root / test. To add a file protection rule on Windows, run: config.exe mac_file add 100 0 "C:\del.exe" 0 "C:\test" , indicating that del.exe cannot delete C:\test. The above test cases are abstracted into a general test policy: exec(CONFIG..MAC_FILE..ADD..RULE_ID..UID..SUBJECT..MODE..OBJECT), where CONFIG is the configuration tool; MAC_FILE is the policy name; ADD is the policy operation type (write in this case, meaning it is used to add a policy); RULE_ID is the policy execution order; UID is the user account; SUBJECT is the execution subject; MODE is the policy permission; and OBJECT is the object being executed. The differences between operating systems lie in the three policy execution parameters: CONFIG, SUBJECT, and OBJECT. For example, in the test case above, for Linux, CONFIG is config, SUBJECT is / usr / bin / rm, and OBJECT is / root / test. For Windows, CONFIG is config.exe, SUBJECT is C:\del.exe, and OBJECT is C:\test. This means that by adapting policy execution parameters based on the operating system, a common test policy can be applied across platforms.

[0058] The disclosed embodiment describes the normative requirements of the test by constructing the policy information items of the policy framework, provides a fixed execution process for the test case, ensures the consistency of the core logic of the same test case on different platforms, and realizes the operating system adaptation of the general test strategy through the dynamic adjustment of the policy execution parameters, avoiding the platform dependence caused by hard coding.

[0059] In addition, the disclosed embodiment generates configuration tools corresponding to different operating systems to simulate various operations of the application client. Even if the application client has not yet been developed, independent testing of the kernel driver module can be achieved, shortening the problem discovery cycle.

[0060] In some embodiments, before obtaining the platform type of the target test platform, kernel driver modules corresponding to different operating system type platforms are obtained. The kernel driver modules are obtained by encapsulating the platform kernel based on the platform communication method of different operating systems. The kernel driver modules are configured with a callable function interface.

[0061] Platform communication refers to the interface protocol and calling mechanism for data exchange between the operating system kernel and the client application layer. The kernel architecture and security mechanisms of different operating systems lead to fundamental differences in the design of communication interfaces. Preliminary reverse engineering or documentation research is conducted on the kernel communication interfaces of various operating systems. The core interaction logic is extracted and encapsulated. Using different encapsulation methods, the kernel communication interfaces of different operating systems are encapsulated into function interfaces that can be called during the execution of a common test strategy, resulting in kernel driver modules corresponding to different operating system platforms.

[0062] Based on the above embodiment, before obtaining the platform type of the target test platform, a general loading instruction is sent to the target test platform. The general loading instruction is generated based on the kernel driver module loading commands corresponding to different operating system types.

[0063] The kernel driver module load command is the instruction required to load a kernel driver module in a specific operating system. Different operating systems have different kernel driver module management mechanisms, resulting in fundamental differences in the syntax and execution of the load command. For example, the command to load a kernel driver module in Linux is "insmod mydriver.ko," while the command to load a kernel driver module in Windows is: "sc create MyDriver C:\Windows\System32\drivers\mydriver.sys type= kernel; sc start mydriver." This shows that in Linux, kernel driver modules are loaded directly using the "insmod" command, while in Windows, the kernel driver module driver service is created and started using the "sc create" and "sc start" commands.

[0064] The differences in load commands between different operating systems are hidden within a universal load instruction, which is then made available to target test platforms of various operating systems through a unified interface. Once the universal load instruction is delivered to the target test platform, it is automatically mapped to a specific load command based on the target test platform's operation type. For example, Windows' sccreate and Linux's insmod are encapsulated into the Platform.load_kernel_driver(driver_path) function.

[0065] Furthermore, after obtaining the platform type of the target test platform, a general loading instruction is sent to the target test platform; the general loading instruction is executed to call the function interface corresponding to the operating system type, and the kernel driver module corresponding to the function interface is loaded.

[0066] Optionally, a general loading instruction is executed by calling a preset interface.

[0067] The preset interface is a unified interface provided by the general loading instruction, for example, the function Platform.load_kernel_driver(driver_path) defined in Lua code.

[0068] The generated universal loading instruction is transmitted to the target test platform, and the system command corresponding to the target test platform operating system is called through a preset interface to execute the universal loading instruction.

[0069] When executing the general loading instruction, the corresponding function interface is called based on different operating system types to load the kernel driver module corresponding to the operating system type.

[0070] A possible implementation of a general load instruction is given below:

[0071] function Platform.load_kernel_driver(driver_path)

[0072] if is_windows() then

[0073] -- Windows: Call the sc command

[0074] os.execute(format('sc create MyDriver binPath= "%s" type= kernel',driver_path))

[0075] os.execute('sc start MyDriver')

[0076] elseif is_linux() then

[0077] -- Linux: Using insmod

[0078] os.execute(format('insmod "%s"', driver_path))

[0079] end

[0080] end

[0081] Based on the above general loading instructions, after obtaining the operating system type of the target test platform, the sc command is automatically called in the Windows environment, or insmod is automatically used in the Linux environment, both of which can automatically load the kernel driver module.

[0082] Accordingly, based on the target test strategy, the test case is executed on the target test platform, including: calling the configuration tool corresponding to the target test strategy to exchange data with the kernel driver module, so as to execute the target test strategy on the target test platform.

[0083] The target test strategy refers to the specific test instructions after cross-platform adaptation. The test tool calls the specific configuration tool based on the target test strategy, simulates the client application under test to send the test instructions in the strategy to the kernel driver module, query the strategy, receive alarm information from the kernel driver, etc., and obtain the execution status returned by the kernel driver module; the kernel driver module is responsible for receiving, storing, matching, and alarm feedback of test instructions, and automatically realizes the process of driver loading, strategy sending, and result verification during the execution of the target test strategy through data exchange with the kernel driver module.

[0084] The disclosed embodiments achieve cross-platform standardization of the kernel driver module loading process by obtaining kernel driver loading commands of different operating systems and generating universal loading instructions, thereby supporting automatic adaptation of test tools in unknown environments, reducing the complexity of test tool deployment, and further improving the flexibility of cross-platform testing.

[0085] In some embodiments, obtaining the operating system type of the target test platform includes: executing preset environment variable acquisition commands corresponding to different operating systems on the target test platform in sequence; when a valid return value corresponding to any preset environment variable acquisition command is obtained, stopping execution of the next preset environment variable acquisition command; and determining the operating system type of the target test platform based on the valid return value.

[0086] Preset environment variable retrieval commands refer to unique environment variables or system commands used by different operating systems to identify their types. A valid return value means that the execution result of the preset command matches the expected value, clearly identifying the operating system type.

[0087] For example, use os.getenv("OS") to read a specific environment variable. If the value of the environment variable OS is "Windows_NT", it means that the operating system type of the target test platform is a Windows system. Alternatively, use io.popen("uname -s"):read() to read the return value of uname -s. If the return value contains "Linux", it means that the operating system type of the target test platform is a Linux system. If the return value contains "Darwin", it means that the operating system type of the target test platform is macOS.

[0088] Optionally, the execution order of the preset environment variable acquisition commands corresponding to different operating systems is ranked based on the market share of each operating system. For example, the preset environment variable acquisition command for the Windows operating system is executed first. The preset environment variable acquisition command for the Linux operating system is executed second, and the preset environment variable acquisition command for the macOS operating system is executed last.

[0089] The disclosed embodiment covers mainstream operating systems through a multi-command detection chain, avoiding missed detections caused by relying on a single detection method. At the same time, it terminates the operating system detection process after obtaining a valid return value, reduces unnecessary command execution, saves computing resources of the target test platform, shortens the overall test time, and improves test efficiency.

[0090] In some embodiments, the target test strategy includes a protection strategy, a trigger strategy, and a verification strategy; executing the target test strategy on the target test platform includes: storing the protection strategy in a preset storage area of ​​the target test platform; executing the trigger strategy to trigger the protection strategy; executing the verification strategy to verify whether the protection strategy is effective; if the protection strategy is effective, determining that the target test strategy is executed successfully; or, if the protection strategy is not effective, determining that the target test strategy has failed to execute.

[0091] A protection policy is a set of instructions used to define security rules or defense mechanisms, such as file protection rules, process access control, and network traffic filtering.

[0092] A trigger policy is a set of instructions that simulates potential attacks or illegal operations, used to verify the actual interception capabilities of the protection policy. For example, attempts to delete protected files or start restricted processes must be made. The trigger policy must correspond to the rules of the protection policy to ensure the targeted nature of the test scenario.

[0093] Verification strategy refers to the inspection logic used to detect whether the protection strategy effectively intercepts the triggering operation, which usually includes system status inspection, kernel log analysis or error code capture.

[0094] The preset storage area refers to an isolated storage space in the target test platform specifically used to store protection policies, such as temporary files, memory cache, or secure database. This ensures that the protection policies are persistent and not accidentally modified during the test process, and facilitates the rapid loading of kernel modules.

[0095] The protection policy is stored in the preset storage area of ​​the target test platform, such as a configuration file, memory, or database, so that the kernel driver module can load the protection policy and keep it in effect, thereby establishing an expected protection baseline for the target test platform.

[0096] Optionally, the protection policy is stored in a preset storage area of ​​the target test platform. When the kernel driver module is loaded, the protection policy in the preset storage area is automatically loaded.

[0097] Based on the execution results of the verification policy, the effectiveness of the protection policy is determined, and the execution results of the target test policy are then determined. Specifically, if the verification policy is successfully executed, it means that the protection policy is effective, and the target test policy is determined to have been successfully executed. If the verification policy fails, it means that the protection policy is not effective, and the target test policy is determined to have failed.

[0098] Furthermore, each target test strategy has a unique serial number. If a target test strategy fails to execute, the corresponding serial number and execution information will be reported for developers to analyze and repair.

[0099] Figure 2 This is a flow chart of a cross-platform testing method provided by another embodiment of the present disclosure. Figure 2 As shown, the method includes the following steps:

[0100] S201: Obtain configuration tools corresponding to different operating systems.

[0101] S202: Obtain a general test strategy corresponding to the test case.

[0102] S203: Issue general loading instructions and general test strategies.

[0103] S204: Obtain the operating system type of the target test platform.

[0104] S205: Execute a general loading instruction to call a function interface corresponding to the operating system type, and load a kernel driver module corresponding to the function interface.

[0105] S206: Adjust the policy execution parameters in the general test policy according to the operating system type to obtain a target test policy corresponding to the target test platform.

[0106] Among them, the target test strategy includes protection strategy, trigger strategy, and verification strategy.

[0107] S207: Store the protection strategy in a preset storage area of ​​the target test platform.

[0108] S208: Execute the triggering strategy to trigger the protection strategy.

[0109] S209: Execute the verification strategy to verify whether the protection strategy is effective.

[0110] Optionally, the protection policy is a target file protection policy, the trigger policy is a target file deletion policy, and the verification policy is a target file opening policy.

[0111] Execute the verification policy to verify whether the protection policy is effective, including: if the target file is successfully opened after the target file opening policy is executed, then it is determined that the target file protection policy is effective; or if the target file fails to be opened after the target file opening policy is executed, then it is determined that the target file protection policy is not effective.

[0112] The target file protection policy is used to prohibit the deletion of the specified target file. Under normal circumstances, the kernel driver module should intercept the deletion request for the target file based on the target file protection policy.

[0113] A target file deletion policy is an instruction that actively attempts to delete a protected target file, triggering the target file protection policy. For example, you can use the Lua io.open(file_name, "rb") interface to open the file to be deleted.

[0114] The target file open policy refers to an operation instruction to verify the existence of the target file by attempting to open it.

[0115] If the target file still exists, the target file opening policy is executed successfully, which means that the protection policy is effective and the target file deletion action is successfully intercepted, and the target test policy is determined to be executed successfully; if the target file does not exist, the target file opening policy fails to execute, which means that the protection policy is not effective and the target file deletion action is not successfully intercepted, and the target test policy is determined to be executed failed.

[0116] The disclosed embodiment achieves comprehensive verification of the kernel driver module's defense mechanism through persistent storage of protection strategies, simulation of real attacks that trigger strategies, and automated closed-loop detection of verification strategies. Combined with cross-platform adaptation of strategies, it ensures consistency in defense function testing across different operating systems, providing quality assurance for the development and maintenance of host security software.

[0117] In some embodiments, the target test strategy includes a first strategy, and the policy operation type of the first strategy is a delete operation; a second strategy corresponding to the first strategy is stored in a preset storage area of ​​the target test platform, and the policy operation type of the second strategy is a write operation, and the policy execution parameters of the first strategy and the second strategy are consistent.

[0118] Executing the target test strategy on the target test platform includes: storing the first strategy in a preset storage area of ​​the target test platform; in response to a trigger command of the second strategy, searching whether the first strategy corresponding to the second strategy exists in the target test platform; if the first strategy corresponding to the second strategy exists in the target test platform, refusing to execute the second strategy.

[0119] The target test policy whose operation type is a delete operation represents invalidating a policy in a preset storage area.

[0120] The first strategy is the currently issued target test strategy, and the second strategy is the target test strategy that already exists in the preset storage space at a historical moment. The execution strategy parameters of the two strategies are consistent, and both are used to control the operation of the same execution subject on the same executed object.

[0121] After the first policy is stored in the preset storage area, when the second policy is triggered again, based on the execution policy parameters, the first policy corresponding to the second policy is found in the target storage area, and the policy operation type of the first policy is a deletion operation. The corresponding second policy is equivalent to being invalid and will no longer be executed.

[0122] For example, if a target file protection policy for a write operation is already stored in the preset storage area, and a target file protection policy for a delete operation is stored in the target storage area, the target file protection policy will be invalidated. Subsequently, if the target file delete policy is executed, triggering the target file protection policy, since a target file protection policy for a delete operation is found after the target file protection policy for a write operation, the previous target file protection policy for a write operation will be invalidated, and the target file can now be deleted normally.

[0123] The disclosed embodiment uses a consistency policy framework of general test policies and target test policies to facilitate conflict detection when a certain policy is triggered, thereby avoiding confusion in the test process due to misoperation or concurrency problems; at the same time, based on the target test policies issued with different policy operation types, the policy execution logic based on the kernel driver module can be changed without the need to reconstruct the entire test process, further improving the flexibility of cross-platform testing.

[0124] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the module, program segment, or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of the boxes in the block diagram and / or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0125] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0126] Figure 3 This is a schematic diagram of the structure of a cross-platform testing device provided by an embodiment of the present disclosure. Figure 3 As shown, the cross-platform testing device 30 includes: a first acquisition module 31, a second acquisition module 32, an adjustment module 33, and a testing module 34; the first acquisition module 31 is used to obtain a general test strategy corresponding to the test case, and the general test strategy is generated according to the execution logic of the test case in different operating systems, and the general test strategy adopts a scripting language common to different operating systems; the second acquisition module 32 is used to obtain the operating system type of the target test platform; the adjustment module 33 is used to adjust the policy execution parameters in the general test strategy according to the operating system type to obtain the target test strategy corresponding to the target test platform; the testing module 34 is used to execute the target test strategy on the target test platform.

[0127] Optionally, the first acquisition module 31 includes a first acquisition unit 311, a second acquisition unit 312, and a third acquisition unit 313; the first acquisition unit 311 is used to obtain the policy framework of the test case; the second acquisition unit 312 is used to obtain the policy execution parameters corresponding to the test case in different operating system types; the third acquisition unit 313 is used to obtain the general test strategy corresponding to the test case based on the policy framework and the policy execution parameters.

[0128] Optionally, the general test strategy includes policy information items and policy execution parameter items; the policy information items include at least one or more of the policy name, policy operation type, policy execution order, user account, and policy authority; the policy execution parameter items include at least the configuration tools, execution subjects, and executed objects required to execute test cases on platforms of different operating systems.

[0129] Optionally, the second acquisition unit 312 is used to obtain configuration tools corresponding to different operating systems. The configuration tools are generated according to the kernel functions and communication methods of different operating systems, and are used to simulate the client application layer during the execution of the test case and exchange data with the kernel driver module.

[0130] Optionally, the cross-platform testing device 30 also includes a third acquisition module 35, which is used to obtain kernel driver modules corresponding to different operating system type platforms. The kernel driver module is obtained by encapsulating the platform kernel based on the platform communication method of different operating systems. The kernel driver module is configured with a callable function interface.

[0131] Optionally, the cross-platform testing device 30 further includes a loading module 36, which includes an instruction issuing unit 361 for issuing a general loading instruction to the target testing platform. The general loading instruction is generated based on the kernel driver module loading command corresponding to different operating system types.

[0132] Optionally, the loading module 36 further includes a calling unit 362, configured to execute the general loading instruction to call a function interface corresponding to the operating system type, and load a kernel driver module corresponding to the function interface.

[0133] Optionally, the testing module 34 is configured to call a configuration tool corresponding to the target testing strategy to exchange data with the kernel driver module, so as to execute the target testing strategy on the target testing platform.

[0134] Optionally, the second acquisition module 32 includes a first execution unit 321, a stop unit 322, and a first determination unit 323; the first execution unit 321 is used to execute preset environment variable acquisition commands corresponding to different operating systems on the target test platform in sequence; the stop unit 322 is used to stop executing the next preset environment variable acquisition command when a valid return value corresponding to any preset environment variable acquisition command is obtained; the first determination unit 323 is used to determine the operating system type of the target test platform based on the valid return value.

[0135] Optionally, the target test strategy includes a protection strategy, a trigger strategy, and a verification strategy. The test module 34 includes a storage unit 341, a second execution unit 342, a third execution unit 343, and a second determination unit 344; the storage unit 341 is used to store the protection strategy in a preset storage area of ​​the target test platform; the second execution unit 342 is used to execute the trigger strategy to trigger the protection strategy; the third execution unit 343 is used to execute the verification strategy to verify whether the protection strategy is effective; the second determination unit 344 is used to determine that the target test strategy is successfully executed if the protection strategy is effective; or, if the protection strategy is not effective, determine that the target test strategy fails to execute.

[0136] Optionally, the protection policy is the target file protection policy, the trigger policy is the target file deletion policy, and the verification policy is the target file opening policy; the third execution unit 343 is used to determine that the target file protection policy is effective if the target file is successfully opened after the target file opening policy is executed; or, if the target file fails to open after the target file opening policy is executed, determine that the target file protection policy is not effective.

[0137] Optionally, the target test policy includes a first policy, and the policy operation type of the first policy is a delete operation; a second policy corresponding to the first policy is stored in the preset storage area of ​​the target test platform, and the policy operation type of the second policy is a write operation, and the policy execution parameters of the first policy and the second policy are consistent; the test module 34 includes a storage unit 341, a search unit 345, and a fourth execution unit 346; the storage unit 341 is used to store the first policy in the preset storage area of ​​the target test platform; the search unit 345 is used to search whether there is a first policy corresponding to the second policy in the target test platform in response to the trigger command of the second policy; the fourth execution unit 346 is used to refuse to execute the second policy if there is a first policy corresponding to the second policy in the target test platform.

[0138] For the description of the features in the embodiment corresponding to the cross-platform testing device, please refer to the relevant description of the embodiment corresponding to the cross-platform testing method, which will not be repeated here.

[0139] An embodiment of the present application further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any of the above-mentioned cross-platform testing method embodiments.

[0140] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps of any of the above-mentioned cross-platform testing method embodiments when running.

[0141] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0142] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of any of the above-mentioned cross-platform testing method embodiments are implemented.

[0143] An embodiment of the present application also provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above-mentioned cross-platform testing method embodiments are implemented.

[0144] The above description is merely a preferred embodiment of the present disclosure and an illustration of the technical principles employed. Those skilled in the art should understand that the scope of the present disclosure is not limited to technical solutions formed by specific combinations of the aforementioned technical features. It also encompasses other technical solutions formed by any combination of the aforementioned technical features or their equivalents, without departing from the scope of the above disclosure. For example, a technical solution formed by replacing the aforementioned features with (but not limited to) technical features with similar functions disclosed in this disclosure.

[0145] In addition, although each operation is described in a specific order, this should not be understood as requiring these operations to be performed in the specific order shown or in a sequential order. Under certain circumstances, multitasking and parallel processing may be advantageous. Similarly, although some specific implementation details have been included in the above discussion, these should not be interpreted as limiting the scope of the present disclosure. Some features described in the context of a separate embodiment can also be implemented in a single embodiment in combination. On the contrary, the various features described in the context of a single embodiment can also be implemented in multiple embodiments individually or in any suitable sub-combination mode.

[0146] Although the subject matter has been described in language specific to structural features and / or methodological logical acts, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are merely example forms of implementing the claims.

[0147] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0148] The above is a detailed introduction to a cross-platform testing method, electronic device, storage medium and computer program product provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and core ideas of the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A cross-platform testing method, characterized in that: include: Obtain a universal test policy corresponding to the test case, the universal test policy being generated based on the execution logic of the test case in different operating systems, the universal test policy including policy execution parameter items, the policy execution parameters including at least a configuration tool, an execution subject, and an executed object required to execute the test case in the platforms of different operating systems; the configuration tool being generated based on the kernel functions and communication methods of different operating systems, and being used to simulate the client application layer during the execution of the test case and to exchange data with the kernel driver module; the execution subject being the party that actively initiates an operation during the test process, and being used to simulate the execution of operations by entities with different permissions, and to verify whether the kernel driver module can correctly identify and restrict unauthorized behavior; Get the operating system type of the target test platform; According to the operating system type, the policy execution parameters in the general test policy are adjusted to obtain the target test policy corresponding to the target test platform; The target test strategy is executed on the target test platform.

2. The cross-platform testing method according to claim 1, characterized in that: The obtaining of the general test strategy corresponding to the test case includes: Obtaining a policy framework for the test case; Obtaining policy execution parameters corresponding to the test case in different operating system types; According to the policy framework and the policy execution parameters, a general test policy corresponding to the test case is obtained.

3. The cross-platform testing method according to claim 2, characterized in that: The general test strategy includes strategy information items; The policy information items include at least one or more of a policy name, a policy operation type, a policy execution order, a user account, and a policy authority.

4. The cross-platform testing method according to claim 3, characterized in that: The obtaining of the policy execution parameters corresponding to the test case in different operating system types includes: Obtain configuration tools corresponding to different operating systems.

5. The cross-platform testing method according to claim 1, characterized in that: Before obtaining the platform type of the target test platform, the method further includes: The kernel driver modules corresponding to different operating system type platforms are obtained. The kernel driver modules are obtained by encapsulating the platform kernel based on the platform communication mode of different operating systems. The kernel driver modules are configured with a callable function interface.

6. The cross-platform testing method according to claim 5, characterized in that: Before obtaining the platform type of the target test platform, the method further includes: A general loading instruction is issued to the target test platform, wherein the general loading instruction is generated based on kernel driver module loading commands corresponding to different operating system types.

7. The cross-platform testing method according to claim 6, characterized in that: After obtaining the platform type of the target test platform, the method further includes: The general loading instruction is executed to call the function interface corresponding to the operating system type, and the kernel driver module corresponding to the function interface is loaded.

8. The cross-platform testing method according to claim 7, characterized in that: Executing the target test strategy on the target test platform includes: The configuration tool corresponding to the target test strategy is called to exchange data with the kernel driver module, so as to execute the target test strategy on the target test platform.

9. The cross-platform testing method according to claim 1, characterized in that: The obtaining of the operating system type of the target test platform includes: Executing preset environment variable acquisition commands corresponding to different operating systems on the target test platform in sequence; When a valid return value corresponding to any preset environment variable acquisition command is obtained, the execution of the next preset environment variable acquisition command is stopped; The operating system type of the target test platform is determined according to the valid return value.

10. The cross-platform testing method according to claim 1, characterized in that: The target test strategy includes a protection strategy, a trigger strategy, and a verification strategy; Executing the target test strategy on the target test platform includes: Storing the protection strategy in a preset storage area of ​​the target test platform; Executing the triggering strategy to trigger the protection strategy; Execute the verification strategy to verify whether the protection strategy is effective; If the protection strategy is effective, it is determined that the target test strategy is executed successfully; or, If the protection strategy is not effective, it is determined that the target test strategy has failed to execute.

11. The cross-platform testing method according to claim 10, characterized in that: The protection policy is a target file protection policy, the trigger policy is a target file deletion policy, and the verification policy is a target file opening policy; The executing the verification strategy to verify whether the protection strategy is effective includes: If the target file is successfully opened after the target file opening policy is executed, it is determined that the target file protection policy is effective; or If the target file fails to be opened after the target file opening policy is executed, it is determined that the target file protection policy is not effective.

12. The cross-platform testing method according to claim 1, characterized in that: The target test policy includes a first policy, wherein the policy operation type of the first policy is a delete operation; a second policy corresponding to the first policy is stored in a preset storage area of ​​the target test platform, wherein the policy operation type of the second policy is a write operation, and the policy execution parameters of the first policy and the second policy are consistent; Executing the target test strategy on the target test platform includes: Storing the first strategy in a preset storage area of ​​the target test platform; In response to a trigger command of the second policy, searching the target test platform for a first policy corresponding to the second policy; If the first policy corresponding to the second policy exists in the target test platform, the second policy is refused to be executed.

13. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the cross-platform testing method according to any one of claims 1 to 12 when executing the computer program.

14. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the cross-platform testing method according to any one of claims 1 to 12.

15. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the cross-platform testing method according to any one of claims 1 to 12 are implemented.

Images