Tenant data permission test method, electronic equipment, storage medium and program product
By selecting test data based on the data isolation method of the business modules in the tenant system, executing the target test script, and performing consistency comparison, the problem of low efficiency in tenant data permission testing was solved, and efficient and accurate test results were achieved.
Patent Information
- Application Number
- CN202410865708.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-06-28
- Publication Date
- 2026-01-13
AI Technical Summary
In existing technologies, tenant data permission testing methods rely on black-box testing, which results in a huge workload, wasted time and manpower costs, and is prone to test omissions, reducing the accuracy and efficiency of test results.
By obtaining the authentication information and data name of the tenant to be tested, selecting test data according to the data isolation method of the business module, executing the target test script, performing consistency comparison, generating target test data, and obtaining test results.
It improves the flexibility, speed, and convenience of the testing process, reduces workload, saves time and costs, avoids test omissions, ensures the accuracy and reliability of test results, and improves the efficiency of tenant data permission testing.
Smart Images
Figure CN121326718A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data processing, and in particular to a tenant data access control testing method, electronic device, storage medium, and program product. Background Technology
[0002] With the development of modern science and technology and the popularization of the Internet, more and more tenants are starting to use various software on the Internet due to their own usage needs. In order to meet the needs of sharing the same system or program components in a multi-tenant environment, multi-tenant technology has emerged. In the application of multi-tenant architecture, it is necessary to ensure that the business data between each tenant is isolated from each other. The business data permissions between tenants are the key points of testing in multi-tenant applications, and tenant data permission testing has become a promising direction.
[0003] In existing technologies, tenant data permission testing methods mainly rely on black-box testing, which involves multiple tenant accounts logging into the system and performing data addition, modification, deletion, and querying to check whether the business data between tenants is isolated.
[0004] Because existing black-box testing involves a huge workload, it wastes time and manpower. Furthermore, excessive workload can easily lead to test omissions during the testing process, thereby reducing the accuracy of test results. This results in a technical problem of low efficiency in data access control testing. Summary of the Invention
[0005] This application provides a tenant data permission testing method, electronic device, storage medium, and program product to improve the efficiency of data permission testing.
[0006] Firstly, this application provides a method for testing tenant data permissions, including:
[0007] Obtain the authentication information and test data name of the tenant to be tested. The authentication information includes the identity identifier of the tenant to be tested and at least one business module to which the tenant to be tested belongs. Each business module stores test data and data isolation configuration for multiple tenants. The data isolation configuration is physical isolation or logical isolation.
[0008] For each business module, if the business module is a physically isolated module, then within the business module, obtain the test data with the same name as the data to be tested but a different identity identifier; wherein, the data names corresponding to tenants with different identities within the business module are the same;
[0009] For each business module, if the business module to which the tenant under test belongs is a logically isolated module, then in the business module, obtain the test data with a different name than the data under test; wherein, the data name in the business module is the same as the corresponding tenant name;
[0010] Obtain at least one target test script corresponding to a business module, execute the target test script on the data to be tested in each business module, and obtain the target test data generated by the target test script. The target test data is used to indicate the actual test data generated after the data to be tested is executed.
[0011] The target test data and the data to be tested are compared for consistency, and the corresponding test results are obtained based on the comparison results.
[0012] Optionally, obtain at least one target test script corresponding to a business module, and execute the target test script on the data to be tested in each business module, including:
[0013] Based on the basic functional scenarios of each business module, obtain the first test script corresponding to the basic functional scenarios, and execute the first test script for each business module. The basic functional scenarios are scenarios in which each business module works independently.
[0014] Optionally, if there are at least two business modules, the method further includes:
[0015] Based on a business process scenario with at least two business modules, obtain the second test script corresponding to the business process scenario. The business process scenario is a scenario in which multiple business modules work in sequence according to the process. The second test script is a script to test the business process.
[0016] According to the sequence of the process, at least two business modules are tested sequentially using the second test script.
[0017] Optionally, before obtaining the target test script corresponding to at least one business module, the method further includes:
[0018] Based on the tenant's first operation information on the business module in the basic functional scenario, the first test script is recorded and generated.
[0019] Based on the tenant's second operation information on multiple business modules in the business process scenario, a second test script is recorded and generated.
[0020] Redundancy removal is performed on the first and second test scripts to generate the target test scripts corresponding to the business modules.
[0021] Optionally, before obtaining the authentication information of the tenant to be tested and the name of the data to be tested, the method further includes:
[0022] If the business module is a physically isolated module, then obtain the module name of the business module and change the test data name of each tenant in the business module to the module name;
[0023] If the business module is a logically isolated module, then obtain the tenant name of each tenant in the business module, and change the test data name of each tenant in the business module to the corresponding tenant name.
[0024] Optionally, a consistency comparison is performed between the target test data and the data to be tested, and the corresponding test results are obtained based on the comparison results, including:
[0025] Compare the target test data with the data to be tested to determine whether the target test data is consistent with the data to be tested;
[0026] If so, it is determined that the tenant under test has not modified the data to be tested, and there is no data unauthorization behavior between the tenant under test and other tenants. The test result is marked as successful.
[0027] If not, it is determined that the tenant under test has modified the data to be tested, and that there is a data privilege violation between the tenant under test and other tenants. The test result is marked as a failure.
[0028] Secondly, this application provides an apparatus for testing tenant data permissions, comprising:
[0029] The first acquisition module is used to acquire the authentication information and the name of the data to be tested of the tenant under test. The authentication information includes the identity identifier of the tenant under test and at least one business module to which the tenant under test belongs. Each business module stores test data and data isolation configuration of multiple tenants. The data isolation configuration is physical isolation or logical isolation.
[0030] The second acquisition module is used to acquire test data with the same name but different identity identifier as the test data for each business module. If the business module is a physically isolated module, the module will acquire test data with the same name but different identity identifier. Among them, the data names of tenants with different identity identifiers in the business module are the same.
[0031] The third acquisition module is used to acquire test data with a different name from the test data in each business module if the business module to which the tenant to be tested belongs is a logically isolated module; wherein, the data name in the business module is the same as the corresponding tenant name;
[0032] The processing module is used to obtain the target test script corresponding to at least one business module, execute the target test script on the data to be tested in each business module, and obtain the target test data generated by the target test script. The target test data is used to indicate the actual test data generated after the data to be tested is executed.
[0033] The testing module is used to compare the target test data and the data to be tested for consistency, and obtain the corresponding test results based on the comparison results.
[0034] Optionally, the first acquisition module is also used for:
[0035] Based on the basic functional scenarios of each business module, obtain the first test script corresponding to the basic functional scenarios, and execute the first test script for each business module. The basic functional scenarios are scenarios in which each business module works independently.
[0036] Optionally, the first acquisition module is also used for:
[0037] Based on a business process scenario with at least two business modules, obtain the second test script corresponding to the business process scenario. The business process scenario is a scenario in which multiple business modules work in sequence according to the process. The second test script is a script to test the business process.
[0038] According to the sequence of the process, at least two business modules are tested sequentially using the second test script.
[0039] Optionally, the processing module is also used for:
[0040] Based on the tenant's first operation information on the business module in the basic functional scenario, the first test script is recorded and generated.
[0041] Based on the tenant's second operation information on multiple business modules in the business process scenario, a second test script is recorded and generated.
[0042] Redundancy removal is performed on the first and second test scripts to generate the target test scripts corresponding to the business modules.
[0043] Optionally, the processing module is also used for:
[0044] If the business module is a physically isolated module, then obtain the module name of the business module and change the test data name of each tenant in the business module to the module name;
[0045] If the business module is a logically isolated module, then obtain the tenant name of each tenant in the business module, and change the test data name of each tenant in the business module to the corresponding tenant name.
[0046] Optionally, the test module is also used for:
[0047] Compare the target test data with the data to be tested to determine whether the target test data is consistent with the data to be tested;
[0048] If so, it is determined that the tenant under test has not modified the data under test, and there is no data unauthorization behavior between the tenant under test and other tenants. The test result is marked as successful.
[0049] If not, it is determined that the tenant under test has modified the data to be tested, and there is a data privilege violation between the tenant under test and other tenants. The test result is marked as a failure.
[0050] Thirdly, this application provides a device for testing tenant data rights, comprising:
[0051] Processor and memory;
[0052] The memory stores the instructions that the computer executes;
[0053] The processor executes computer execution instructions stored in memory, causing the processor to perform the various possible implementations described in the first aspect above.
[0054] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, are used to implement various possible implementations as described in the first aspect.
[0055] Fifthly, this application provides a computer program product, which, when executed by a processor, is used to implement various possible implementations as described in the first aspect.
[0056] This application provides a tenant data permission testing method, electronic device, storage medium, and program product. The method involves: obtaining the authentication information and test data name of the tenant under test; for each business module, if the business module is physically isolated, obtaining test data with the same name but different identity identifier; for each business module, if the business module to which the tenant under test belongs is logically isolated, obtaining test data with a different name; obtaining at least one target test script corresponding to a business module, executing the target test script on the test data in each business module, and obtaining the target test data generated by the target test script; and then... The test data and the data to be tested are compared for consistency. Based on the comparison results, the corresponding test results are obtained. By obtaining the data isolation method of the business modules in the tenant system, the corresponding test data construction scheme is selected, ensuring the stability of the test environment and the security of the test data. The generated test script is used to perform permission tests on the test data of the tenant under test, which improves the flexibility, speed and convenience of the overall testing process, reduces the workload of testing, saves time costs, avoids the problem of data omission during testing, ensures the accuracy and reliability of test results, solves the technical problem of low efficiency in tenant data permission testing, and achieves the technical effect of improving the efficiency of tenant data permission testing. Attached Figure Description
[0057] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.
[0058] Figure 1 A schematic diagram of the architecture of the tenant data permission testing method provided in the embodiments of this application;
[0059] Figure 2 The flowchart of the tenant data permission testing method provided in the embodiments of this application Figure 1 ;
[0060] Figure 3 The flowchart of the tenant data permission testing method provided in the embodiments of this application Figure 2 ;
[0061] Figure 4 The flowchart of the tenant data permission testing method provided in the embodiments of this application Figure 3 ;
[0062] Figure 5 A schematic diagram of the test results for the tenant data permission testing method provided in this application embodiment. Figure 1 ;
[0063] Figure 6 A schematic diagram of the target test data and the data to be tested for the tenant data permission testing method provided in the embodiments of this application;
[0064] Figure 7 A schematic diagram of the test results for the tenant data permission testing method provided in this application embodiment. Figure 2 ;
[0065] Figure 8 This is a schematic diagram of the tenant data permission testing device provided in the embodiments of this application;
[0066] Figure 9 The hardware structure diagram of the tenant data permission testing device provided in the embodiments of this application is shown.
[0067] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation
[0068] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.
[0069] Because existing black-box testing involves a huge workload, it wastes time and manpower. Furthermore, the excessive workload can easily lead to omissions during the testing process, thereby reducing the accuracy of the test results. This results in a technical problem of low efficiency in data access control testing.
[0070] This application provides a tenant data permission testing method, electronic device, storage medium, and program product. By obtaining the data isolation method of the business modules in the tenant system and selecting the corresponding test data construction scheme, the stability of the test environment and the security of the test data are ensured. Permission testing is performed on the test data of the tenant under test according to the generated test script. This improves the flexibility, speed, and convenience of the overall testing process, reduces the workload of testing, saves time costs, avoids the problem of data omission during testing, ensures the accuracy and reliability of test results, solves the technical problem of low efficiency in tenant data permission testing, and achieves the technical effect of improving the efficiency of tenant data permission testing.
[0071] The technical solution of this application and how it solves the above-mentioned technical problems will be described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.
[0072] Figure 1 A schematic diagram of the architecture of the tenant data permission testing method provided in the embodiments of this application is shown below. Figure 1As shown in the figure, the overall architecture of the tenant data permission test provided in this application embodiment includes: a test scenario design module, a test data configuration module, a test script recording module, a test script configuration module, a test execution module, and a test result analysis module. The test scenario design module designs test scenarios, including basic functional scenarios and business process scenarios; the test data configuration module selects the corresponding test data construction scheme according to the tenant system's data isolation scheme, constructing the test data required for basic functional scenarios and business process scenarios; the test script recording module records test scripts for basic functional and complex business process scenarios; the test script configuration module configures test scenarios and authentication information; the test execution module enables and runs the corresponding test scripts according to different test scenarios, and the test result analysis module collects test results.
[0073] Figure 2 The flowchart of the tenant data permission testing method provided in the embodiments of this application Figure 1 .like Figure 2 As shown in the embodiments of this application, the tenant data permission testing method includes:
[0074] S201. Obtain the authentication information and test data name of the tenant to be tested;
[0075] In this embodiment, the authentication information includes the identity identifier of the tenant under test and at least one business module to which the tenant under test belongs. Each business module stores test data and data isolation configurations for multiple tenants. The data isolation configuration is physical isolation or logical isolation.
[0076] When conducting data access control tests, it is necessary to determine the identity of the tenant under test and the specific data to be tested. In order to accurately identify and execute the tests, it is necessary to obtain the authentication information of the tenant under test and the name of the data to be tested.
[0077] S202. For each business module, if the business module is a physically isolated module, then in the business module, obtain the test data with the same name as the data to be tested but a different identity identifier.
[0078] In this embodiment, the data names corresponding to tenants with different identities in the physically isolated business modules are the same; physical isolation refers to data isolation achieved by placing the test data of different tenants into different data tables contained in the business module.
[0079] For each business module, if it adopts physical isolation, during the test, the system will accurately locate within that business module and select only the test data whose name matches the data to be tested but whose identity identifier is different.
[0080] S203. For each business module, if the business module to which the tenant under test belongs is a logically isolated module, then in the business module, obtain the test data with a different name than the test data.
[0081] In this embodiment, the data names in the logically isolated business modules are the same as the corresponding tenant names; logical isolation means that the data of different tenants are stored in the same data table of the same business module, and data isolation is achieved by adding the corresponding tenant name to each test data name.
[0082] For each business module, if logical isolation is adopted, during test execution, the test will be precisely located within that business module, and the test data whose name does not match the name of the tenant under test will be selected.
[0083] S204. Obtain at least one target test script corresponding to a business module, execute the target test script on the data to be tested in each business module, and obtain the target test data generated by the target test script.
[0084] In this embodiment, the target test data is used to indicate the actual test data generated after the target test script is executed.
[0085] Select at least one business module, obtain its corresponding target test script, and precisely execute the corresponding target test script for the test data in each business module; after execution, obtain the actual test data generated by the execution of the target test script.
[0086] S205. Compare the target test data and the test data for consistency, and obtain the corresponding test results based on the comparison results.
[0087] The target test data after executing the target test script and the test data before executing the target test script are compared for content consistency. Based on the comparison results, the corresponding test results are obtained.
[0088] This application provides a tenant data permission testing method, which involves: obtaining the authentication information and test data name of the tenant under test; for each business module, if the business module is physically isolated, obtaining test data with the same name but different identity identifier as the test data within the business module; for each business module, if the business module to which the tenant under test belongs is logically isolated, obtaining test data with a different name than the test data within the business module; obtaining at least one target test script corresponding to a business module, executing the target test script on the test data in each business module, and obtaining the target test data generated by the target test script; and then combining the target test data and the test data... By performing consistency comparisons and obtaining corresponding test results based on the comparison results, and then selecting the appropriate test data construction scheme by obtaining the data isolation method of the business modules in the tenant system, the stability of the test environment and the security of the test data are ensured. Furthermore, permission tests are performed on the test data of the tenant under test based on the generated test scripts. This improves the flexibility, speed, and convenience of the overall testing process, reduces the workload of testing, saves time costs, and avoids data omissions during testing, ensuring the accuracy and reliability of the test results. It solves the technical problem of low efficiency in tenant data permission testing and achieves the technical effect of improving the efficiency of tenant data permission testing.
[0089] Figure 3 The flowchart of the tenant data permission testing method provided in the embodiments of this application Figure 2 .like Figure 3 As shown, this embodiment, based on the above embodiment, provides supplementary explanations of the configuration process before tenant data permission testing, including:
[0090] S301. Obtain the data isolation configuration of the business module. If the business module is a physically isolated module, obtain the module name of the business module and change the test data name of each tenant in the business module to the module name.
[0091] Before testing begins, the data isolation configuration of the business module is first obtained to determine its isolation type. If the business module is a physically isolated module, the module name of the business module is further obtained. Since the test data of each tenant in the physically isolated module is stored independently, the test data name of each tenant is associated with the module name for easy management and identification.
[0092] S302. Obtain the data isolation configuration of the business module. If the business module is a logically isolated module, obtain the tenant name of each tenant in the business module and change the test data name of each tenant in the business module to the corresponding tenant name.
[0093] If the business module is a logically isolated module, then the names of all tenants in that business module are further obtained. Since the test data of each tenant in the logically isolated module is stored together, for the convenience of management and identification, the test data name of each tenant is associated with its corresponding tenant name.
[0094] S303. Based on the tenant's first operation information on the business module in the basic functional scenario, record and generate the first test script;
[0095] In this embodiment, the basic function scenario is a scenario in which each business module works independently; the first operation information is used to indicate the operation information of the tenant in the basic function scenario, and the first test script is a script for testing the basic functions.
[0096] By using the tenant system's script recording tool, all operations performed by the tenant on the business modules in the basic functional scenario are recorded and saved as test scripts applied to that basic functional scenario.
[0097] S304. Based on the tenant's second operation information on multiple business modules in the business process scenario, record and generate a second test script;
[0098] In this embodiment, the business process scenario is a scenario in which multiple business modules work in sequence according to the process. The second operation information is used to indicate the operation information of the tenant in the business process scenario, and the second test script is a script for testing the business process.
[0099] Continue using the script recording tool to record all operations performed by the tenant on multiple business modules in the business process scenario and save them as test scripts applied to that business process scenario.
[0100] S305. Perform redundancy removal on the first and second test scripts to generate the target test script corresponding to the business module.
[0101] In this embodiment, the redundancy removal operation refers to removing duplicate operation information in the first test script and the second test script.
[0102] After generating the first and second test scripts, a redundancy removal operation is performed on the duplicate operation information in these two test scripts to obtain the target test script corresponding to the business module after redundancy removal.
[0103] This application provides a tenant data permission testing method. Before data testing, it constructs test data for multiple tenants within a business module through data isolation configuration. Based on the test scenario, it uses a recording tool to generate corresponding test scripts to facilitate subsequent testing. By obtaining the data isolation scheme of the business module in the tenant system and selecting the corresponding data test scheme, it ensures the stability of the test environment and the security of the test data. The use of a script recording tool to obtain the operation information of the business module under test and generate corresponding test scripts reduces the waste of manual resources and time costs, avoids data omissions during testing, ensures the accuracy and reliability of subsequent test results, solves the technical problem of low efficiency in tenant data permission testing, and achieves the technical effect of improving the efficiency of tenant data permission testing.
[0104] Figure 4 The flowchart of the tenant data permission testing method provided in the embodiments of this application Figure 3 .like Figure 4 As shown, this embodiment, based on the above embodiment, provides supplementary explanations of the tenant data permission testing process, including:
[0105] S401. Based on the basic functional scenarios of each business module, obtain the first test script corresponding to the basic functional scenarios, and execute the first test script for each business module.
[0106] In this embodiment, the basic functional scenario and the first test script are the same as those described in S303, and will not be repeated here.
[0107] For each business module, obtain the first test script applied to the basic functional scenario, and execute the test script for each business module.
[0108] S402. If there are at least two business modules, obtain the second test script corresponding to the business process scenario based on the business process scenario of at least two business modules.
[0109] In this embodiment, the business process scenario and the second test script are the same as those described in S304, and will not be repeated here.
[0110] If there are at least two business modules that need to be tested, then for the business process scenarios corresponding to at least two business modules, obtain the second test script applied to that business process scenario.
[0111] S403. According to the process sequence, test at least two business modules sequentially using the second test script;
[0112] For each business process scenario, the second test script is executed sequentially for at least two business modules within that scenario.
[0113] S404. Obtain the target test data generated by the target test script;
[0114] In this embodiment, the target test data is consistent with the target test data described in S204, and will not be repeated here.
[0115] After the first and second test scripts in the target test script have been executed, obtain the actual test data generated after the target test script has been executed.
[0116] S405. Compare the target test data and the test data to determine whether the target test data is consistent with the test data.
[0117] The target test data after executing the target test script is compared with the test data before executing the target test script to determine whether the target test data is consistent with the test data.
[0118] S406. If yes, then it is determined that the tenant under test has not modified the data under test, and there is no data overreach behavior between the tenant under test and other tenants. The test result is marked as successful.
[0119] In this embodiment, data overreach refers to abnormal operations such as modification or control of test data of other tenants who do not belong to the tenant being tested.
[0120] If the content of the target test data and the content of the data to be tested are consistent, it is determined that the tenant under test has not modified the content of the data to be tested, and there is no data overreach behavior between the tenant under test and other tenants. The result of this test is determined to be successful.
[0121] Specifically, the business module contains tenant A to be tested and other tenant B. If the content of the target test data and the content of the data to be tested are consistent, a result will be generated in the system as follows: Figure 5 The test results shown in the figure indicate that “records: [ ] ” means that the difference between the target test data and the test data is null. The test tenant A did not affect the test data. It is determined that the test tenant A did not have any data overreach behavior with other tenants B. The test result is determined to be successful.
[0122] S407. If not, it is determined that the tenant under test has modified the data to be tested, and there is a data privilege violation between the tenant under test and other tenants. The test result is marked as failure.
[0123] Under normal circumstances, the tenant under test can only control the test data belonging to that tenant and has no right to operate on test data that does not belong to that tenant. If the content of the target test data is inconsistent with the content of the test data, it is determined that the tenant under test has modified the content of the test data, and there is a data privilege violation between the tenant under test and other tenants. The result of this test is determined to be a failure.
[0124] Specifically, the business module contains tenant A to be tested and other tenant B. If the content of the target test data and the content of the data to be tested are as follows: Figure 6 As shown, if the content of the target test data and the content of the data to be tested are inconsistent, an error will be generated in the system as follows. Figure 7 The comparison results shown in the figure indicate that "Assertion failure: true" and "0, tenant A / " indicate that there is a data privilege violation between the tested tenant A and other tenant B, and the test result is determined to be a failure.
[0125] This application provides a tenant data permission testing method. By configuring test scenarios into basic functional scenarios and business process scenarios, corresponding target test scripts are executed according to the different test scenarios. The method compares the target test data generated by the target test script with the data to be tested before executing the target test script. Based on the comparison, it obtains information on data privilege violations between the tenant under test and other tenants during script execution, thus determining the corresponding test results. This refined configuration of test scenarios improves the comprehensiveness and accuracy of the test. The use of script-based hierarchical testing enhances the flexibility, speed, and convenience of the overall testing process, reduces the workload of data testing, saves testing time, and improves the accuracy and reliability of test results. Furthermore, by comparing the target test data with the data to be tested to obtain information on corresponding data privilege violations, it ensures the security of tenant data and solves the technical problem of low efficiency in tenant data permission testing, achieving the technical effect of improving the efficiency of tenant data permission testing.
[0126] Figure 8 This is a schematic diagram of the tenant data access control testing device provided in an embodiment of this application. The device in this embodiment can be in the form of software and / or hardware. For example... Figure 8 As shown in the embodiment of this application, the tenant data permission testing apparatus 800 includes: a first acquisition module 801, a second acquisition module 802, a third acquisition module 803, a processing module 804, and a testing module 805.
[0127] The first acquisition module 801 is used to acquire the authentication information and the name of the data to be tested of the tenant under test. The authentication information includes the identity identifier of the tenant under test and at least one business module to which the tenant under test belongs. Each business module stores test data and data isolation configuration of multiple tenants. The data isolation configuration is physical isolation or logical isolation.
[0128] The second acquisition module 802 is used to acquire, for each business module, if the business module is a physically isolated module, the test data with the same name as the test data but different identity identifier in the business module; wherein, the data names corresponding to tenants with different identity identifiers in the business module are the same;
[0129] The third acquisition module 803 is used to acquire test data with a different name from the test data in each business module if the business module to which the tenant to be tested belongs is a logically isolated module; wherein, the data name in the business module is the same as the corresponding tenant name;
[0130] The processing module 804 is used to obtain a target test script corresponding to at least one business module, execute the target test script on the data to be tested in each business module, and obtain the target test data generated by the target test script. The target test data is used to indicate the actual test data generated after the data to be tested is executed.
[0131] Test module 805 is used to compare the target test data and the data to be tested for consistency, and obtain the corresponding test results based on the comparison results.
[0132] In one possible implementation, the first acquisition module 801 is further configured to:
[0133] Based on the basic functional scenarios of each business module, obtain the first test script corresponding to the basic functional scenarios, and execute the first test script for each business module. The basic functional scenarios are scenarios in which each business module works independently.
[0134] In one possible implementation, the first acquisition module 801 is further configured to:
[0135] Based on a business process scenario with at least two business modules, obtain the second test script corresponding to the business process scenario. The business process scenario is a scenario in which multiple business modules work in sequence according to the process. The second test script is a script to test the business process.
[0136] According to the sequence of the process, at least two business modules are tested sequentially using the second test script.
[0137] In one possible implementation, the processing module 804 is further configured to:
[0138] Based on the tenant's first operation information on the business module in the basic functional scenario, the first test script is recorded and generated.
[0139] Based on the tenant's second operation information on multiple business modules in the business process scenario, a second test script is recorded and generated.
[0140] Redundancy removal is performed on the first and second test scripts to generate the target test scripts corresponding to the business modules.
[0141] In one possible implementation, the processing module 804 is further configured to:
[0142] If the business module is a physically isolated module, then obtain the module name of the business module and change the test data name of each tenant in the business module to the module name;
[0143] If the business module is a logically isolated module, then obtain the tenant name of each tenant in the business module, and change the test data name of each tenant in the business module to the corresponding tenant name.
[0144] In one possible implementation, test module 805 is also used for:
[0145] Compare the target test data with the data to be tested to determine whether the target test data is consistent with the data to be tested;
[0146] If so, it is determined that the tenant under test has not modified the data under test, and there is no data unauthorization behavior between the tenant under test and other tenants. The test result is marked as successful.
[0147] If not, it is determined that the tenant under test has modified the data to be tested, and there is a data privilege violation between the tenant under test and other tenants. The test result is marked as a failure.
[0148] The tenant data permission testing device provided in this application can implement the above method embodiment. Its implementation principle and technical effect are similar, and will not be described again here.
[0149] Figure 9 This is a hardware structure diagram of the tenant data permission testing device provided in an embodiment of this application. Figure 9 As shown, the tenant data access control test device 900 includes:
[0150] Processor 901 and memory 902;
[0151] The memory stores the instructions that the computer executes;
[0152] The processor executes computer execution instructions stored in memory 902, causing the device for tenant data rights testing to perform the tenant data rights testing method described above.
[0153] It should be understood that the processor 901 described above can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.
[0154] The memory 902 may include high-speed random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device, and may also be a USB flash drive, external hard drive, read-only memory, disk or optical disc, etc.
[0155] This application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the tenant data permission testing method described above.
[0156] This application also provides a computer program product, which, when executed by a processor, is used to implement the tenant data permission testing method described above.
[0157] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.
[0158] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.
[0159] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.
[0160] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.
[0161] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.
[0162] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.
[0163] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.
[0164] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.
[0165] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.
Claims
1. A method for testing tenant data permissions, characterized in that, The method comprises the following steps: obtaining authentication information of a to-be-tested tenant and a to-be-tested data name, wherein the authentication information comprises an identity of the to-be-tested tenant and at least one business module to which the to-be-tested tenant belongs, each of the business modules stores test data and data isolation configurations of a plurality of tenants, and the data isolation configurations are physical isolation or logical isolation; for each business module, if the business module is a physically isolated module, obtaining test data in the business module that is the same as the to-be-tested data name and different from the identity; wherein the test data of different tenants in the business module correspond to the same data name; for each business module, if the business module to which the to-be-tested tenant belongs is a logically isolated module, obtaining test data in the business module that is different from the to-be-tested data name; wherein the data name in the business module is the same as the corresponding tenant name; obtaining a target test script corresponding to the at least one business module, executing the target test script on the test data in each business module, and obtaining target test data generated by the target test script, wherein the target test data is used to indicate actual test data generated by the test data after execution of the target test script; comparing the target test data and the test data for consistency, and obtaining a corresponding test result according to the comparison result.
2. The method of claim 1, wherein, The method further comprises the following steps before the step of obtaining the target test script corresponding to the at least one business module: based on a basic function scenario of each business module, obtaining a first test script corresponding to the basic function scenario, and executing the first test script on each business module, wherein the basic function scenario is a scenario in which each business module works independently.
3. The method of claim 2, wherein, If the business modules are at least two, the method further comprises the following steps: based on a business process scenario of the at least two business modules, obtaining a second test script corresponding to the business process scenario, wherein the business process scenario is a scenario in which a plurality of business modules work in a process sequence, and the second test script is a script for testing a business process; according to the process sequence, testing the at least two business modules in sequence through the second test script.
4. The method of claim 3, wherein, The method further comprises the following steps before the step of obtaining the target test script corresponding to the at least one business module: based on first operation information of a tenant on the business module in a basic function scenario, recording and generating a first test script; based on second operation information of a tenant on a plurality of business modules in a business process scenario, recording and generating a second test script; performing a de-redundancy operation on the first test script and the second test script to generate a target test script corresponding to the business module.
5. The method of claim 1, wherein, The method further comprises the following steps before the step of obtaining the authentication information of the to-be-tested tenant and the to-be-tested data name: if the business module is a physically isolated module, obtaining a module name of the business module, and changing the test data name of each tenant in the business module to the module name; If the business module is a logically isolated module, a tenant name of each tenant in the business module is acquired, and a test data name of each tenant in the business module is changed to the corresponding tenant name.
6. The method of claim 1, wherein, The consistency comparison between the target test data and the to-be-tested data comprises: comparing the target test data with the to-be-tested data to determine whether the target test data is consistent with the to-be-tested data; if yes, it is determined that the to-be-tested tenant has not modified the to-be-tested data, and there is no data overreach behavior between the to-be-tested tenant and other tenants, and the test result is marked as successful; if no, it is determined that the to-be-tested tenant has modified the to-be-tested data, and there is data overreach behavior between the to-be-tested tenant and other tenants, and the test result is marked as failed.
7. A tenant data authority testing apparatus, comprising: comprise: a first acquisition module configured to acquire authentication information of a to-be-tested tenant and a to-be-tested data name, wherein the authentication information comprises an identity of the to-be-tested tenant and at least one business module to which the to-be-tested tenant belongs, and each business module stores test data of multiple tenants and data isolation configurations, wherein the data isolation configurations are physical isolation or logical isolation; a second acquisition module configured to, for each business module, if the business module is a physically isolated module, acquire, in the business module, to-be-tested data that is the same as the to-be-tested data name and different from the identity; wherein the data names corresponding to tenants with different identities in the business module are the same; a third acquisition module configured to, for each business module, if the business module to which the to-be-tested tenant belongs is a logically isolated module, acquire, in the business module, to-be-tested data that is different from the to-be-tested data name; wherein the data names in the business module are the same as corresponding tenant names; a processing module configured to acquire a target test script corresponding to the at least one business module, execute the target test script on the to-be-tested data in each business module, and acquire target test data generated by the target test script, wherein the target test data is used to indicate actual test data generated after the to-be-tested data is executed by the target test script; a test module configured to compare the target test data with the to-be-tested data for consistency, and acquire a corresponding test result according to a comparison result.
8. A tenant data authority testing device, comprising: comprise: a memory and a processor; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory, so that the processor executes the method of any one of claims 1-6.
9. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer execution instructions, and the computer execution instructions are executed by the processor to implement the method of any one of claims 1-6.
10. A computer program product, characterised in that, The computer program is executed by the processor to implement the method of any one of claims 1-6.