Cross-platform test method, electronic equipment, storage medium and computer program product

Abstract

The invention discloses a cross-platform testing method, electronic equipment, a storage medium and a computer program product, and relates to the technical field of software testing. The strategy execution parameters in the general test strategy are adjusted based on the operating system type of the target test platform, so that the general test strategy can adapt to various operating system types, cross-platform execution of the general test strategy in different operating systems is realized, and different general test strategies do not need to be written for different operating systems; and the overall efficiency and flexibility of the test method are improved.

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 equipment, storage medium and computer program product. Background Art

[0002] As computer systems become increasingly complex, various types of software emerge in an endless stream. For example, host security software has become an important part of protecting computer systems from external attacks, viruses, and malware threats. Therefore, testing the business capabilities of various types of software such as host security software has become an important topic.

[0003] At present, software testing mostly relies on fixed automated testing tools. Since the kernel structure and calling methods of each operating system platform are different, a testing tool is often only applicable to a specific operating system or hardware platform. If you need to test software on different operating system platforms, you usually need to write different testing tools for different operating systems.

[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: Obtain a general test strategy corresponding to the test case. The general test strategy is generated according to 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. 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; Execute the target test strategy on the target test platform.

[0007] 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.

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

[0009] 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.

[0010] 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

[0011] 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 paying any creative work.

[0012] Figure 1 A flow chart of a cross-platform testing method provided by an embodiment of the present disclosure; Figure 2 A flow chart of a cross-platform testing method provided by another embodiment of the present disclosure; Figure 3 A schematic diagram of the structure of a cross-platform testing device provided in an embodiment of the present disclosure. DETAILED DESCRIPTION

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

[0014] It should be noted that, in the description of this application, the terms "include", "comprise" or any other variant thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes 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 specific order or sequence.

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

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

[0017] like Figure 1 As shown, the method includes the following steps: S101. Obtain a general test strategy corresponding to a test case. The general test strategy is generated according to the execution logic of the test case in different operating systems. The general test strategy adopts a scripting language that is common to different operating systems.

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

[0019] For example, a file protection rule added on a Linux system is . / config mac_file add 100 0 " / usr / bin / rm" 0 " / root / test", which means that rm cannot delete / root / test; a file protection rule added on a Windows system is config.exe mac_file add 100 0 "C:\del.exe" 0 "C:\test", which means that del.exe cannot delete C:\test. In the above two operating systems, the specific paths for adding file protection rules are different, but their execution logic is that the "executing subject" (such as rm or del.exe) adds protection rules for the "executing object" (such as / root / test or C:\test) through the configuration tool (such as config or config.exe), that is, the same test case has similar execution logic in different operating systems.

[0020] 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.

[0021] Optionally, the general test strategy uses Lua language. Lua language has lightweight characteristics, and the general test strategy based on Lua language can be run without compilation, shortening the test case development and debugging cycle.

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

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

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

[0025] 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.

[0026] S103. According to the operating system type, the policy execution parameters in the general test policy are adjusted to obtain a target test policy corresponding to the target test platform.

[0027] 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.

[0028] 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.

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

[0030] Specifically, based on the execution logic in the target test strategy and the policy execution parameters that are 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 achieve policy writing or deletion, operation triggering and result verification, and finally obtain the test results corresponding to the target test strategy.

[0031] 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 a target test platform; adjusts the policy execution parameters in the universal test strategy according to the operating system type, and obtains a 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, realizes 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.

[0032] 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.

[0033] 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 permissions; 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.

[0034] 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.

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

[0036] 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".

[0037] 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.

[0038] 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.

[0039] The user account specifies the authority subject to execute 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.

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

[0041] Optionally, when the policy permission is defined as the first permission parameter, the general test policy has the permission to read data; when the policy permission is defined as the second permission parameter, the general test policy has the permission to write data; when the policy permission is defined as the third permission parameter, the general test policy has the permission to read and write data, wherein the third permission parameter is the sum of the first permission parameter and the second permission parameter; when the policy permission is defined as the fourth permission parameter, the general test policy has the permission to execute. The first permission parameter, the second permission parameter, the third permission parameter, and the fourth permission parameter are different.

[0042] 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. It also facilitates 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.

[0043] 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.

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

[0045] Among them, the configuration tool is used to simulate the client application layer of the application software in the target test platform, and 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 and different communication methods between the client application layer and the kernel driver layer. For example, in the Linux system, the ioctl command is used to communicate with the kernel driver, while in the Windows system, the FltCreateCommunicationPort communication port is used to drive the kernel driver. Therefore, different configuration tools need to be written for different operating systems, and the configuration tools are set to a form that can be called by the general test strategy. When executing the 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 realize the functions required by the general test strategy.

[0046] 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.

[0047] The execution subject refers to the party that actively initiates the operation during the test process, usually the owner of the operation permission or the application or service that triggers the test behavior. During the test process, the execution subject is used to simulate entities with different permissions to perform operations and verify whether the kernel module can correctly identify and restrict unauthorized behavior.

[0048] 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.

[0049] 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.

[0050] For example, the normal use of the config configuration tool to add a file protection policy on the Linux system is . / config mac_file add 100 0 " / usr / bin / rm" 0 " / root / test", which means that rm cannot delete / root / test; adding a file protection rule on Windows is config.exe mac_file add 100 0 "C:\del.exe" 0 "C:\test", which means 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, which is a write operation here, that 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; OBJECT is the object to be executed. The differences between different operating systems lie in the three policy execution parameters CONFIG, SUBJECT, and OBJECT. For the Linux system, CONFIG is config, SUBJECT is / usr / bin / rm, and OBJECT is / root / test; for the Windows system, CONFIG is config.exe, SUBJECT is C:\del.exe, and OBJECT is C:\test. That is, by adapting the policy execution parameters based on the operating system type, the cross-platform applicability of the general test policy can be achieved.

[0051] The disclosed embodiments describe the normative requirements of the test by constructing the policy information items of the policy framework, provide a fixed execution process of the test case, ensure the consistency of the core logic of the same test case on different platforms, and realize 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.

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

[0053] 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.

[0054] The platform communication mode 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 mechanism of different operating systems lead to essential differences in the design of communication interfaces. Reverse analysis or document research is performed on the kernel communication interfaces of various types of operating systems in advance, and the core interaction logic is extracted and encapsulated. Different encapsulation methods are used to encapsulate the kernel communication interfaces of different operating systems into function interfaces that can be called during the execution of the general test strategy, and the kernel driver modules corresponding to different operating system type platforms are obtained.

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

[0056] The kernel driver module loading command refers to the instructions that need to be executed to load the kernel driver module in a specific operating system. The kernel driver module management mechanisms of different operating systems are different, resulting in essential differences in the syntax and execution methods of the loading command. For example, the command to load the kernel driver module in the Linux system is insmod mydriver.ko, and the command to load the kernel driver module in the Windows system is: sc create MyDriver C:\Windows\System32\drivers\mydriver.sys type= kernel; sc start mydriver. It can be seen that in Linux, the kernel driver module is directly loaded through the insmod command, while in Windows, the driver service of the kernel driver module is created and started through the sc create and sc start commands.

[0057] The differences in loading commands of different operating systems are hidden inside the general loading instruction, and the target test platform of each type of operating system can call it through a unified interface. After the general loading instruction is sent to the target test platform, the general loading instruction is automatically mapped to a specific loading command according to the operation type of the target test platform. For example, sccreate of Windows and insmod of Linux are uniformly encapsulated into the Platform.load_kernel_driver(driver_path) function.

[0058] 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.

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

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

[0061] The generated general 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 general loading instruction.

[0062] 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.

[0063] A possible implementation of a general load instruction is given below: function Platform.load_kernel_driver(driver_path) if is_windows() then -- Windows: Call the sc command os.execute(format('sc create MyDriver binPath= "%s" type= kernel',driver_path)) os.execute('sc start MyDriver') elseif is_linux() then -- Linux: Using insmod os.execute(format('insmod "%s"', driver_path)) end end 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 realize the loading of the kernel driver module.

[0064] Correspondingly, 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.

[0065] 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 the alarm information from the kernel driver, and obtain the execution status returned by the kernel driver module; the kernel driver module is responsible for the reception, storage, matching, alarm feedback, etc. of the test instructions, and automatically realizes the process of driver loading and strategy sending to result verification during the execution of the target test strategy through data exchange with the kernel driver module.

[0066] 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.

[0067] In some embodiments, obtaining the operating system type of the target test platform includes: sequentially executing preset environment variable acquisition commands corresponding to different operating systems on the target test platform; 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.

[0068] The preset environment variable acquisition command refers to the unique environment variables or system commands used to identify their own types in different operating systems. The valid return value means that the execution result of the preset command matches the expected value and can clearly identify the operating system type.

[0069] 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 Windows. 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 Linux. If the return value contains "Darwin", it means that the operating system type of the target test platform is macOS.

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

[0071] 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.

[0072] 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 is executed unsuccessfully.

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

[0074] The trigger policy refers to a set of instructions that simulate potential attacks or illegal operations, and is used to verify the actual interception capabilities of the protection policy. For example, attempting to delete a protected file; starting a restricted process, etc. The trigger policy must correspond to the rules of the protection policy to ensure the pertinence of the test scenario.

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

[0076] The preset storage area refers to an isolated storage space in the target test platform that is specifically used to store protection policies, such as temporary files, memory caches, or security databases. This ensures that the protection policies are persistent during the test and are not accidentally modified, while facilitating fast loading of kernel modules.

[0077] The protection strategy 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 strategy and keep it in effect, thereby establishing an expected protection baseline for the target test platform.

[0078] Optionally, the protection strategy is stored in a preset storage area of ​​the target test platform, and when the kernel driver module is loaded, the protection strategy in the preset storage area is automatically loaded.

[0079] Based on the execution result of the verification strategy, determine whether the protection strategy is effective, and then determine the execution result of the target test strategy. Specifically, when the verification strategy is successfully executed, it means that the protection strategy is effective, and the target test strategy is determined to be executed successfully; when the verification strategy fails to execute, it means that the protection strategy is not effective, and the target test strategy is determined to be executed unsuccessfully.

[0080] 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 are reported for developers to analyze and repair.

[0081] 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 comprises the following steps: S201, obtaining configuration tools corresponding to different operating systems.

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

[0083] S203. Issue general loading instructions and general testing strategies.

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

[0085] 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.

[0086] S206. According to the operating system type, the policy execution parameters in the general test policy are adjusted to obtain a target test policy corresponding to the target test platform.

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

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

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

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

[0091] 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.

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

[0093] The target file protection policy is used to prohibit the deletion operation 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.

[0094] The target file deletion policy refers to an operation instruction that actively attempts to delete the protected target file, which is used to trigger the target file protection policy. For example, use Lua's io.open(file_name, "rb") interface to open the file to be deleted.

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

[0096] 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, then 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, then the target test policy is determined to be executed failed.

[0097] The disclosed embodiments achieve 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, the consistency of defense function testing in different operating systems is ensured, providing quality assurance for the development and maintenance of host security software.

[0098] 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.

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

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

[0101] The first strategy is the target test strategy currently issued, 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 are consistent, and both are used to control the operation of the same execution subject on the same executed object.

[0102] After the first policy is stored in the preset storage area, when the second policy is triggered again, based on the execution policy parameters, it is found that the first policy corresponding to the second policy exists 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 invalid and is no longer executed.

[0103] For example, if a target file protection policy with a write operation type is already stored in the preset storage area, and a target file protection policy with a delete operation type is stored in the target storage area, the target file protection policy will be invalidated. Afterwards, if the target file delete policy is executed, the target file protection policy will be triggered. Since a target file protection policy with a delete operation type is found after the target file protection policy with a write operation type, the previous target file protection policy with a write operation type is invalidated, and the target file can be deleted normally at this time.

[0104] 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 reconstructing the entire test process, further improving the flexibility of cross-platform testing.

[0105] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present disclosure. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some implementations as replacements, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square 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 square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0106] 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 a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method.

[0107] Figure 3 The schematic diagram of the structure of a cross-platform testing device provided by the embodiment of the present disclosure is as follows. 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 a 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, and 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.

[0108] 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.

[0109] 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 permissions; 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.

[0110] Optionally, the second acquisition unit 312 is used to obtain configuration tools corresponding to different operating systems, where the configuration tools are generated according to 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.

[0111] 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.

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

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

[0114] Optionally, the test module 34 is used to call a 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.

[0115] 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.

[0116] 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 executed successfully if the protection strategy is effective; or, if the protection strategy is not effective, determine that the target test strategy fails to execute.

[0117] 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; 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.

[0118] Optionally, 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; 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 strategy 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 strategy in the target test platform in response to a trigger command of the second strategy; the fourth execution unit 346 is used to refuse to execute the second strategy if there is a first policy corresponding to the second strategy in the target test platform.

[0119] For the description of the features in the embodiment corresponding to the cross-platform testing device, reference may be made to the relevant description of the embodiment corresponding to the cross-platform testing method, which will not be described in detail here.

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

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

[0122] 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.

[0123] 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 in any of the above cross-platform testing method embodiments are implemented.

[0124] An embodiment of the present application also provides another computer program product, including a non-volatile computer-readable storage medium, the non-volatile computer-readable storage medium storing 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.

[0125] The above description is only a preferred embodiment of the present disclosure and an explanation of the technical principles used. Those skilled in the art should understand that the scope of disclosure involved in the present disclosure is not limited to the technical solutions formed by a specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above disclosed concept. For example, the above features are replaced with the technical features with similar functions disclosed in the present disclosure (but not limited to) by each other to form a technical solution.

[0126] 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 are 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.

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

[0128] 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 composition and steps of each example have been generally described in the above description according to function. 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 to be beyond the scope of this application.

[0129] 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, and the description of the above embodiments is only used to help understand the method and core idea 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: Obtaining a general test strategy corresponding to the test case, wherein the general test strategy is generated according to the execution logic of the test case in different operating systems; 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 a strategy information item and a strategy execution parameter item; 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 at least include the configuration tools, execution subjects, and executed objects required to execute the test cases on platforms of different operating systems.

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: Configuration tools corresponding to different operating systems are obtained. 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.

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 the platforms of different operating system types 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 step of 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, 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 trigger 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 strategy is a target file protection strategy, the trigger strategy is a target file deletion strategy, and the verification strategy is a target file opening strategy; The executing the verification strategy to verify whether the protection strategy is effective includes: If the target file is opened successfully after executing the target file opening policy, 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 strategy includes a first strategy, the strategy 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, the strategy operation type of the second strategy is a write operation, and the strategy execution parameters of the first strategy and the second strategy 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 strategy, searching the target test platform for a first strategy corresponding to the second strategy; 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