Bitmap-based test data query method, electronic device and storage medium

Abstract

The application discloses a bitmap-based test data query method, an electronic device and a storage medium, and relates to the technical field of data management. The bitmap-based test data query method comprises the following steps: in response to a timing task instruction, obtaining original test data generated by a business system of each product from a bitmap system, wherein the original test data comprises a bitmap of each product corresponding to a test account, the test account is a customer number or a card number, and the bitmap is used for representing a holding state of the test account for each product; screening valid test data from each original test data and storing the valid test data into a database; and in response to a data query instruction, obtaining target test data matched with the data query instruction from the database. The application solves the technical problems of low test data query efficiency and low data real-time performance based on a bitmap.

Description

Technical Field

[0001] This application relates to the field of data management technology, and in particular to a bitmap-based test data query method, electronic device, and storage medium. Background Technology

[0002] With the advancement of digitalization and networking, more and more enterprises are using online business systems to store business data for test accounts. During development, these systems also require testing, leading to a growing demand for querying existing test data. Currently, bitmap technology can be used to query existing test data, and API requests can be sent to verify data validity. However, this method provides queries to users separately based on the bitmaps stored in each business system. When the same card number or customer number has business data in multiple systems, individual queries are required, resulting in low query efficiency, poor visualization, and low data real-time performance due to the need for manual acquisition of bitmap data from business systems. Summary of the Invention

[0003] The main objective of this application is to provide a bitmap-based test data query method, electronic device, and storage medium, aiming to solve the technical problems of low efficiency and low real-time performance of bitmap-based test data query in the prior art.

[0004] To achieve the above objectives, this application provides a bitmap-based test data query method, which includes:

[0005] In response to a scheduled task instruction, the system obtains the original test data generated by the business system of each product from the bitmap system. The original test data includes the bitmap of each product corresponding to the test account. The test account is a customer number or card number. The bitmap is used to represent the holding status of the test account for each product.

[0006] Valid test data is selected from the original test data and stored in the database;

[0007] In response to a data query command, target test data matching the data query command is retrieved from the database.

[0008] Optionally, the holding status of each product includes holding or not holding, and the step of obtaining the original test data generated by the business system of each product from the bitmap system includes:

[0009] Obtain the bitmaps of each product corresponding to the test account from the bitmap system, and determine whether each bitmap is a household-level bitmap or a customer-level bitmap.

[0010] If the bitmap is a household-level bitmap, then by querying the bitmap database table of household-level products, the holding status of the product is filtered to be the household-level bitmap of the holding and the corresponding card number;

[0011] If the bitmap is a customer-level bitmap, then by querying the customer product bitmap database table, filtering the customer-level bitmaps whose holding status is "holding", and querying the card number corresponding to the customer-level bitmap.

[0012] Optionally, the step of filtering valid test data from the original test data includes:

[0013] Send data query requests to the business systems corresponding to each card number in the original test data respectively, and obtain the message status returned by each business system;

[0014] If the message status is normal, then the test data corresponding to the card number is valid test data;

[0015] If the message status is abnormal, then the test data corresponding to the card number is invalid test data.

[0016] Optionally, the step of filtering valid test data from the original test data includes:

[0017] The test data for each card number in the original test data is transmitted to the corresponding downstream target system to obtain the message status returned by the downstream target system.

[0018] If the message status is normal, then the test data corresponding to the card number is valid test data;

[0019] If the message status is abnormal, then the test data corresponding to the card number is invalid test data.

[0020] Optionally, the step of storing the valid test data in the database includes:

[0021] The valid test data is stored in a whitelist, and the valid test data in the whitelist is used for further screening and querying.

[0022] Following the step of storing the valid test data in the database, the method further includes:

[0023] The invalid test data is stored in a blacklist.

[0024] Optionally, the data query instruction is obtained through an API interface, and the step of retrieving target test data from the database that matches the data query instruction in response to the data query instruction includes:

[0025] Data query instructions are obtained through the API interface. The data query instructions include at least the product name, upper and lower limits of the holding amount, and the number of data records. The product name is a required field.

[0026] The SQL query statement is combined according to the data query instruction, and the corresponding target test data is queried in the database through the SQL query statement.

[0027] Optionally, after the step of querying the corresponding target test data in the database using the SQL query statement, the method further includes:

[0028] The system queries the interface of the downstream target system to obtain the real-time asset information corresponding to the card number in the target test data, and determines whether the target test data is normal based on the real-time asset information.

[0029] If the target test data is normal, then the real-time holding information of the card number in the target test data is returned;

[0030] If the target test data is abnormal, the external interface of the business system corresponding to the card number will be returned.

[0031] Optionally, the data query instruction is obtained through a chatbot tool, and the step of retrieving target test data from the database that matches the data query instruction in response to the data query instruction includes:

[0032] The user inputs a data query command through the chat interface of the chatbot tool, wherein the data query command includes at least the product name;

[0033] The system pushes candidate input parameters to the user in the chat interface and obtains the input parameters entered by the user.

[0034] The SQL query statement is combined based on the product name and the input parameters, and the corresponding target test data is retrieved from the database using the SQL query statement.

[0035] This application also provides a bitmap-based test data query device, which is applied to a bitmap-based test data query equipment. The bitmap-based test data query device includes:

[0036] The bitmap acquisition module is used to respond to a scheduled task instruction to acquire the original test data generated by the business system of each product from the bitmap system. The original test data includes the bitmap of each product corresponding to the test account. The test account is a customer number or card number. The bitmap is used to represent the holding status of the test account for each product.

[0037] The data cleaning module is used to filter out valid test data from the original test data and store the valid test data in the database;

[0038] The data query module is used to retrieve target test data from the database that matches the data query command in response to the data query command.

[0039] This application also provides an electronic device, which is a physical device, comprising: a memory, a processor, and a program for the bitmap-based test data query method stored in the memory and executable on the processor. When the program for the bitmap-based test data query method is executed by the processor, it can implement the steps of the bitmap-based test data query method as described above.

[0040] This application also provides a computer-readable storage medium storing a program implementing a bitmap-based test data query method, wherein when the program is executed by a processor, it implements the steps of the bitmap-based test data query method as described above.

[0041] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the bitmap-based test data query method described above.

[0042] This application provides a bitmap-based test data query method, electronic device, and storage medium. First, in response to a scheduled task instruction, it retrieves raw test data generated by the business systems of each product from a bitmap system. The raw test data includes bitmaps of each product corresponding to a test account, where the test account is a customer number or card number. The bitmaps represent the holding status of the test account for each product. This technical solution achieves automatic retrieval of test data, eliminating the need for manual acquisition and ensuring data real-time performance. Furthermore, the raw test data includes the holding status of the test account for each product, enabling rapid retrieval of data for the same card number or customer number across multiple business systems, improving test data query efficiency. Then, valid test data is filtered from the raw test data and stored in a database. In response to a data query instruction, the target test data matching the data query instruction is retrieved from the database. This technical solution effectively achieves the beneficial effect of quickly matching business data from multiple business systems corresponding to a specific customer number or card number based on personalized query conditions, linking the independent business data of various business systems for unified querying, thereby solving the technical problems of low query efficiency and low data real-time performance in bitmap-based test data. Attached Figure Description

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

[0044] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0045] Figure 1 This is a flowchart illustrating the first embodiment of the bitmap-based test data query method of this application;

[0046] Figure 2 This is a schematic diagram illustrating the program implementation principle of the bitmap-based test data query method in this application;

[0047] Figure 3 This is a schematic diagram of the overall inventive concept framework of the bitmap-based test data query method of this application;

[0048] Figure 4 This is a schematic diagram of the composition structure of the bitmap-based test data query device in the embodiments of this application;

[0049] Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the bitmap-based test data query method in this application embodiment.

[0050] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0051] To make the above-mentioned objectives, features, and advantages of this application more apparent and understandable, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0052] Example 1

[0053] Current publicly available technologies, such as querying existing test data using bitmap technology and verifying data validity by sending interface requests, lack a data preservation mechanism, making it difficult to quickly query test data for shared accounts across multiple business systems. Furthermore, they suffer from inconvenient access to data generation functions. The technical solution in this application addresses this issue by periodically executing scheduled tasks to preserve data freshness. By converting bitmap relationships into corresponding product names, it enables combined queries based on product name parameters, resolving the need for quickly finding data when the same card number or customer number exists in multiple business systems.

[0054] This application provides a bitmap-based test data query method. In the first embodiment of this bitmap-based test data query method, refer to... Figure 1 The bitmap-based test data query method includes:

[0055] Step S10: In response to the scheduled task instruction, obtain the original test data generated by the business system of each product from the bitmap system. The original test data includes the bitmap of each product corresponding to the test account. The test account is a customer number or card number. The bitmap is used to represent the holding status of the test account for each product.

[0056] Step S20: Select valid test data from each of the original test data and store the valid test data in the database;

[0057] Step S30: In response to a data query instruction, target test data matching the data query instruction is retrieved from the database.

[0058] In this embodiment, it should be noted that the bitmap-based test data query method can be applied to a system located between the upstream business system and the downstream target system. This system is used to acquire and store bitmaps generated by the upstream business system and the bitmap system, and to perform periodic updates and filtering for the downstream target system to call and query, as well as to provide users with convenient test data query services. The bitmap system records the correctness data retained by the upstream business system during daily testing. The correspondence between test accounts and bitmaps recorded in the bitmap is converted into a correspondence between test accounts and business systems. The bitmap is typically used to represent the holding status of a test account in various business systems (i.e., various products). For example, if a user's card number (account) has purchased funds, but not wealth management products or deposits, and has also purchased insurance, then its bitmap for "funds-wealth management products-deposits-insurance" can be represented as "1001". The bitmap clearly indicates which products the user holds, while products without holdings can be ignored when filtering test data to reduce computational and storage requirements. Alternatively, the bitmap can also be used to... Figure 1 This provides a clear overview of the holding status of a card number, enabling the association of business data for a single card number across multiple business systems and enhancing the visualization of test data. Furthermore, since technicians may add manually constructed data during business system testing, and the actual business systems do not have corresponding transactions, it is necessary to clean the original test data to filter out invalid data and avoid consuming system storage and computing resources. Finally, the technical solution of this application embodiment can also provide an API interface to users and downstream target systems to receive data query commands with certain filtering conditions, allowing testers to access the required data at any time. The data query command is used to query the database for test data that meets the filtering conditions and return it to the user, lowering the barrier to entry for data creation applications and making it easier for users to obtain test data.

[0059] In one feasible embodiment, the bitmap-based test data query in this application can be completed using Fast API (a high-performance web framework) and Python language, and valid test data can be stored in a MySQL (relational database management system) database. The high-performance asynchronous characteristics of Fast API are utilized, and the test data acquisition, filtering, and updating are periodically automated through a scheduled task framework.

[0060] As an example, steps S10 to S30 include: obtaining pre-set raw test data generated by each business system from the bitmap system connected to the Fast API framework through a timed update instruction issued by a timed task built into the Fast API framework. The raw test data includes bitmaps of each product corresponding to a test account shared by all business test systems. Specifically, each business system can correspond to one product, such as funds, wealth management, deposits, and insurance products. In the bitmap of each test account, different bitmap states represent whether the user holds a position in that product; for example, 0 indicates no position, and 1 indicates a position. The returned message status is obtained by sending requests or incoming data to the upstream business system or downstream target system. Based on the message status, it is determined whether each piece of raw test data is valid test data. Valid test data is stored in a whitelist for downstream target systems and users to access and query, while invalid test data is stored in a blacklist to avoid duplicate screening and save computing resources. The process then responds to user requests from the Fast API framework. The API framework provides web service API interfaces that take in data query commands with various input parameters. It then matches target test data from the whitelist that matches each of the input parameters and returns the results to downstream target systems or users.

[0061] Furthermore, the step of obtaining the raw test data generated by the business systems of each product from the bitmap system includes:

[0062] Step S11: Obtain the bitmaps of each product corresponding to the test account from the bitmap system, and determine whether each bitmap is a household-level bitmap or a customer-level bitmap.

[0063] Step S12: If the bitmap is a household-level bitmap, then by querying the bitmap database table of household products, filter the holding status of the product to the household-level bitmap and the corresponding card number.

[0064] Step S13: If the bitmap is a customer-level bitmap, then by querying the customer product bitmap database table, filter the customer-level bitmaps whose holding status is "holding", and query the card number corresponding to the customer-level bitmap.

[0065] In this embodiment, it should be noted that since the test account may be a customer number or a card number (account number), the corresponding bitmap also exists in two forms: account-level bitmap and customer-level bitmap. This is because in some business systems, the business data of each product may be associated not only with the card number but also with the customer number, and a single customer number may include multiple card numbers from different systems. Therefore, it is necessary to first distinguish the type of bitmap before determining the corresponding bitmap and card number. It should also be noted that in this embodiment, bitmaps with a "held" status are filtered out, thereby maximizing the saving of system computing resources and avoiding the need to filter, calculate, and update a large number of bitmaps and test data with no "held" status, thus maximizing the efficiency of test data query. Furthermore, in various business systems, the card number is usually used as the query input parameter, so the card number for each bitmap is determined separately for subsequent validity verification of various test data by card number to filter out invalid test data. It should be noted that the bitmap database table consists of bitmaps for multiple test accounts corresponding to each product, including bitmap database tables corresponding to account products and bitmap database tables corresponding to customer products. It is mainly used to filter out products with a holding status corresponding to each test account, so as to filter out the corresponding card number and the corresponding test data.

[0066] As an example, steps S11 to S13 include: after issuing a scheduled task instruction in the scheduled task framework, obtaining bitmaps for each product corresponding to multiple test accounts from the bitmap system; determining whether each bitmap is an account-level bitmap or a customer-level bitmap; if the bitmap is an account-level bitmap, querying the account-level bitmaps with a product holding status of "holding" and the corresponding card number of each account-level bitmap according to the bitmap database table of account products; if the bitmap is a customer-level bitmap, querying the customer-level bitmaps with a product holding status of "holding" according to the bitmap database table of customer products, and further querying the corresponding card number according to the customer number of the customer-level bitmap, obtaining the card numbers with a holding status of "holding", and each card number can be used to filter valid test data.

[0067] Additionally, the step of filtering valid test data from the original test data may include:

[0068] Step S21: Send data query requests to the business systems corresponding to each card number in the original test data to obtain the message status returned by each business system;

[0069] Step S22: If the message status is normal, then the test data corresponding to the card number is valid test data;

[0070] Step S23: If the message status is abnormal, then the test data corresponding to the card number is invalid test data.

[0071] This application provides a method for filtering valid test data. Since the original test data originates from upstream business systems, during the testing process of these systems, data may be constructed by testers themselves. This data may not have corresponding real data in the corresponding business system and is therefore invalid, requiring filtering to ensure the validity of the test data. Therefore, this application initiates a data query request to each business system based on the card number to query the test data corresponding to that card number. If a normal message is received from the upstream business system, the test data corresponding to that card number is valid; if the returned message is abnormal (i.e., cannot return test data normally), the test data corresponding to that card number is invalid.

[0072] As an example, steps S21 to S23 include: based on the card numbers of each held position, using multi-threading to traverse each piece of test data and initiate data query requests to the business systems corresponding to the card numbers of each piece of test data for the business systems to respond; receiving the data query messages about each card number returned by each business system, and determining whether the corresponding test data is valid based on the message status corresponding to each card number; specifically, if the message status is normal, the test data corresponding to the card number is valid test data; if the message status is abnormal, the test data corresponding to the card number is invalid test data.

[0073] On the other hand, the step of filtering valid test data from the original test data may further include:

[0074] Step S24: Transmit the test data of each card number in the original test data to the corresponding downstream target system to obtain the message status returned by the downstream target system;

[0075] Step S25: If the message status is normal, then the test data corresponding to the card number is valid test data;

[0076] Step S26: If the message status is abnormal, then the test data corresponding to the card number is invalid test data.

[0077] In this application embodiment, an alternative method for filtering valid test data, besides the methods described above, is provided. Its purpose and beneficial effects are the same as the methods described above, and will not be repeated here. Since this application embodiment utilizes the raw test data from the upstream testing system, data validity screening can be performed through the business system of the data source. The downstream connection is to the downstream target system, i.e., systems that require the target test data obtained in this application embodiment to perform other operational steps. Therefore, the downstream system also contains test data corresponding to each test account, which can also be used to verify the validity of the test data. It should be noted that this method for filtering valid test data and the previous method for filtering valid test data can be executed sequentially, thereby further ensuring the validity of the test data.

[0078] As an example, steps S24 to S26 include: based on the card number for each determined position status, calling the interface of the downstream target system corresponding to each card number to initiate a data transmission request to each downstream target system for response; receiving the data transmission message returned by each downstream target system regarding each card number, and determining whether the corresponding test data is valid based on the message status corresponding to each card number; specifically, if the message status is normal, the test data corresponding to the card number is valid test data; if the message status is abnormal, the test data corresponding to the card number is invalid test data.

[0079] In addition, in the first embodiment of this application, the step of storing the valid test data in the database may further include:

[0080] Step S27: Store the valid test data in a whitelist, whereby the valid test data in the whitelist is used for further screening and querying;

[0081] Following the step of storing the valid test data in the database, the method further includes:

[0082] Step S28: Store the invalid test data in the blacklist.

[0083] In this embodiment, it should be noted that, in order to reduce repeated screening of invalid test data and decrease requests to upstream systems for invalid data, a blacklist and whitelist are established. The whitelist stores the sources of test data for the target system and downstream systems, while the blacklist stores invalid test data. Thus, test data in the whitelist can be continuously added and repeatedly screened based on each data acquisition and update, while data in the blacklist, once determined to be invalid, will not be screened again, saving a significant amount of computation.

[0084] Based on the bitmap-based test data query method described in the first embodiment of this application, a method for obtaining data query instructions can also be proposed, namely, different methods for accessing test data in the Fast API framework. The data query instructions are obtained through an API interface. The step of retrieving target test data from the database that matches the data query instructions in response to the data query instructions includes:

[0085] Step S31: Obtain a data query instruction through the API interface. The data query instruction includes at least the product name, upper and lower limits of the holding amount, and the number of data entries. The product name is a required option.

[0086] Step S32: Combine the SQL query statement according to the data query instruction, and query the corresponding target test data in the database through the SQL query statement.

[0087] In this embodiment of the application, it should be noted that the Fast API framework provides a unified data query API interface to the outside world for downstream target systems to call and access. The downstream target systems can directly access the Fast API framework through Web services to quickly query test data when the same card number or customer number has business data in multiple business systems.

[0088] In one feasible embodiment, the data query instruction includes a mandatory field, which includes the name of the product for which test data needs to be obtained; this field is an enumerated value. It also includes multiple optional fields, including the upper and lower limits of the holding amount corresponding to the product name. Additionally, if multiple products need to be held by the same card, multiple of the above fields can be entered to form a product holding filter list. The instruction may also include the number of data records to be obtained; if this is not entered, the default number of data records is 1. This embodiment of the application satisfies personalized needs through the above method, supporting functions such as combined queries, upper and lower limits of amount, and record count queries.

[0089] As an example, steps S31 to S32 include: obtaining a data query instruction through a request entry point, wherein the data query instruction includes various input parameters, including the product name, and may also include upper and lower limits of the holding amount and the number of data entries; parsing the input parameter message corresponding to the data query instruction, converting the product name in the input parameters into a bitmap, and concatenating the bitmap, the upper and lower limits of the amount, and the number of data entries to obtain an SQL (Structured Query Language) query statement; matching the various filtering conditions in the SQL query statement in the database to obtain target test data that matches each of the filtering conditions.

[0090] Furthermore, since the bitmap-based test data query method in this embodiment is a scheduled task, the final queried target test data may differ somewhat from the real-time assets. Therefore, after the step of querying the corresponding target test data in the database using the SQL query statement, the method further includes:

[0091] Step A10: Query the real-time asset information corresponding to the card number in the target test data according to the interface of the downstream target system, and determine whether the target test data is normal based on the real-time asset information;

[0092] Step A20: If the target test data is normal, return the real-time holding information of the card number in the target test data;

[0093] Step A30: If the target test data is abnormal, return to the external interface of the business system corresponding to the card number.

[0094] In this embodiment, it should be noted that, in order to determine whether the matched target test data is current real-time data, this embodiment verifies the real-time asset information of each card number involved in the target test data by calling the interface of the downstream target system, thereby determining whether the target test data returned by the API interface is the latest real-time asset data. Specifically, this embodiment queries the real-time asset platform interface in the downstream system and returns real-time holding information. In addition, to shorten the downstream usage path, customer information related to the card number is queried and returned in the interface as well, so that users can use it as needed.

[0095] In a feasible embodiment, considering the detailed execution steps of the bitmap-based test data query method described above in the embodiments of this application, the overall program implementation idea of ​​this bitmap-based test data query method can be as follows: Figure 2As shown, the process begins by controlling and triggering a scheduled task through the scheduled task framework in the Fast API framework, and then obtaining the bitmap corresponding to each product from the bitmap system. It then determines whether the bitmap is a customer-level bitmap. If so, it queries the customer product bitmap chart, filters all customer numbers with bitmap Y (holding status is holding), and further obtains the card number based on the customer number. If not, it queries the account product bitmap chart, filters all card numbers with bitmap Y. Next, it queries the card number verification interface to filter invalid card numbers (i.e., filter invalid test data), where the card number verification interface is the data interface of the upstream business system. Further, it queries the real-time asset interface of the asset middle platform, views the returned fields by product, and filters card numbers whose holding field is not null (invalid) and whose card assets are greater than 0 (this step corresponds to steps S24 to S26). After obtaining each... After obtaining valid test data, the corresponding card number and product holding information are stored in the database. On the other hand, when the downstream target system needs to access the test data, it requests the data retrieval interface and parses the message in the input parameters, converting the product name in the input parameters into a bitmap. It then further concatenates the product bitmap, amount, and data volume as filtering conditions to query the database and obtain the matching target test data. It then queries the real-time asset platform and customer information interface based on the card number of the target test data to determine whether the interface returns normally based on the obtained real-time asset information. If it returns normally, it returns the filtered card number, real-time asset holding information, and customer information. If it returns abnormally, it returns the filtered card number and the external interface information indicating that the request was successful, so that users can query the original test data from the upstream business system, ensuring the real-time nature of the data.

[0096] On the other hand, based on the bitmap-based test data query method described in the first embodiment of this application, a method for obtaining a data query instruction can also be proposed, namely, receiving a data query instruction by connecting to a chatbot tool. The step of retrieving target test data from the database that matches the data query instruction in response to the data query instruction includes:

[0097] Step S33: Obtain the data query instruction input by the user through the chat interface of the chatbot tool, wherein the data query instruction includes at least the product name;

[0098] Step S34: Push the candidate input parameters to the user in the chat interface and obtain the input parameters input by the user.

[0099] Step S35: Combine the product name and the input parameters into an SQL query statement, and use the SQL query statement to query the corresponding target test data in the database.

[0100] In this embodiment, it should be noted that the data generation request can be received by connecting to a chatbot, and the data generation result can be returned to the chatbot. This shortens the usage path and reduces the barrier to entry for data generation applications, improves the convenience of triggering access to the data generation function, and allows testers to quickly obtain the test data they want through a question-and-answer process. It should also be noted that the process of querying target test data using a chatbot in this embodiment also requires the use of the API interface provided by the Fast API framework, and its underlying logic is consistent with steps S31 to S32 above.

[0101] In one feasible embodiment, steps S33 to S35 include: the user asking the chatbot for keywords related to "asset middle platform data creation" in a dialog box; the chatbot automatically triggers question and answer content, wherein the question and answer content is the input parameter conditions when querying data through the API interface, including various input parameter conditions, which must include the product name, and may also include the upper and lower limits of the holding amount and the number of data entries; the user inputs the input parameter command (data query instruction) as required according to the question and answer content answered by the chatbot, and assembles the corresponding SQL query statement according to the input parameter command to query the matching target test data in the database; finally, the result corresponding to the target test data is returned through the chatbot's answer.

[0102] In one feasible embodiment, it should be noted that the overall inventive concept framework diagram of the embodiments of this application can be as follows: Figure 3 As shown, the system primarily uses a timed framework to trigger scheduled tasks, periodically retrieving data from the bitmap system to ensure data freshness. It also performs data cleaning and information processing to avoid repeatedly filtering and processing invalid test data, thereby improving the system's computational efficiency. Valid and invalid test data are stored in blacklists and whitelists respectively to complete data storage. Data query interfaces are then provided to users through API calls and chatbot access, allowing testers to access the entry point at any time and lowering the barrier to entry.

[0103] This application provides a bitmap-based test data query method. First, in response to a scheduled task instruction, raw test data generated by the business systems of each product is retrieved from the bitmap system. The raw test data includes bitmaps of each product corresponding to a test account. The test account is a customer number or card number. The bitmap represents the holding status of the test account for each product. Thus, the technical solution of this application realizes automatic retrieval of bitmap data, eliminating the need for manual acquisition and ensuring data real-time performance. Furthermore, the raw test data includes the holding status of the test account for each product, enabling rapid retrieval of data for the same card number or customer number across multiple business systems, improving test data query efficiency. Then, valid test data is filtered from the raw test data and stored in a database. In response to a data query instruction, target test data matching the data query instruction is retrieved from the database. This application's technical solution effectively achieves the beneficial effect of quickly matching business data from multiple business systems corresponding to a specific customer number or card number based on the user's personalized query conditions. It connects the independent business data of various business systems for unified querying, solving the technical problems of low query efficiency and low data real-time performance in bitmap-based test data.

[0104] Example 2

[0105] This application also provides a bitmap-based test data query device, which is applied to a bitmap-based test data query equipment, as described above. Figure 4 The bitmap-based test data query device includes:

[0106] Bitmap acquisition module 101 is used to respond to a scheduled task instruction to acquire the original test data generated by the business system of each product from the bitmap system. The original test data includes bitmaps of each product corresponding to the test account. The test account is a customer number or card number. The bitmap is used to represent the holding status of the test account for each product.

[0107] The data cleaning module 102 is used to filter out valid test data from each of the original test data and store the valid test data in the database;

[0108] The data query module 103 is used to retrieve target test data that matches the data query instruction from the database in response to the data query instruction.

[0109] Optionally, the holding status of each product includes holding or not holding, and the data acquisition module 101 is further used for:

[0110] Obtain the bitmaps of each product corresponding to the test account from the bitmap system, and determine whether each bitmap is a household-level bitmap or a customer-level bitmap.

[0111] If the bitmap is a household-level bitmap, then by querying the bitmap database table of household-level products, the holding status of the product is filtered to be the household-level bitmap of the holding and the corresponding card number;

[0112] If the bitmap is a customer-level bitmap, then by querying the customer product bitmap database table, filtering the customer-level bitmaps whose holding status is "holding", and querying the card number corresponding to the customer-level bitmap.

[0113] Optionally, the data cleaning module 102 is further configured to:

[0114] Send data query requests to the business systems corresponding to each card number in the original test data respectively, and obtain the message status returned by each business system;

[0115] If the message status is normal, then the test data corresponding to the card number is valid test data;

[0116] If the message status is abnormal, then the test data corresponding to the card number is invalid test data.

[0117] Optionally, the data cleaning module 102 is further configured to:

[0118] The test data for each card number in the original test data is transmitted to the corresponding downstream target system to obtain the message status returned by the downstream target system.

[0119] If the message status is normal, then the test data corresponding to the card number is valid test data;

[0120] If the message status is abnormal, then the test data corresponding to the card number is invalid test data.

[0121] Optionally, the data cleaning module 102 is further configured to:

[0122] The valid test data is stored in a whitelist, and the valid test data in the whitelist is used for further screening and querying; and

[0123] The invalid test data is stored in a blacklist.

[0124] Optionally, the data query instruction is obtained through an API interface, and the data query module 103 is further used for:

[0125] Data query instructions are obtained through the API interface. The data query instructions include at least the product name, upper and lower limits of the holding amount, and the number of data records. The product name is a required field.

[0126] The SQL query statement is combined according to the data query instruction, and the corresponding target test data is queried in the database through the SQL query statement.

[0127] Optionally, the data query module 103 is further configured to:

[0128] The system queries the interface of the downstream target system to obtain the real-time asset information corresponding to the card number in the target test data, and determines whether the target test data is normal based on the real-time asset information.

[0129] If the target test data is normal, then the real-time holding information of the card number in the target test data is returned;

[0130] If the target test data is abnormal, the external interface of the business system corresponding to the card number will be returned.

[0131] Optionally, the data query instruction is obtained through a chatbot tool, and the data query module 103 is further used for:

[0132] The user inputs a data query command through the chat interface of the chatbot tool, wherein the data query command includes at least the product name;

[0133] The system pushes candidate input parameters to the user in the chat interface and obtains the input parameters entered by the user.

[0134] The SQL query statement is combined based on the product name and the input parameters, and the corresponding target test data is retrieved from the database using the SQL query statement.

[0135] The bitmap-based test data query device provided in this application, employing the bitmap-based test data query method described in the above embodiments, solves the technical problems of low efficiency and low real-time performance in bitmap-based test data query. Compared with the prior art, the beneficial effects of the bitmap-based test data query device provided in this application are the same as those of the bitmap-based test data query method described in the above embodiments, and other technical features in this bitmap-based test data query device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0136] Example 3

[0137] This application provides an electronic device, which includes: at least one processor; and a memory communicatively linked to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the bitmap-based test data query method described in Embodiment 1 above.

[0138] The following is for reference. Figure 5 The diagram illustrates a structural schematic of an electronic device suitable for implementing embodiments of the present disclosure. The electronic devices in the embodiments of the present disclosure may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable media players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0139] like Figure 5 As shown, the electronic device may include a processing unit 1001 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 (ROM) or a program loaded from a storage device 1003 into a random access memory 1004 (RAM). The RAM 1004 also stores various programs and data required for the operation of the electronic device. The processing unit 1004, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also linked to the bus 1005.

[0140] Typically, the following systems can be linked to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the electronic device to communicate wirelessly or wiredly with other devices to exchange data. Although electronic devices with various systems are shown in the figures, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems may be implemented alternatively.

[0141] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device, or installed from a ROM. When the computer program is executed by a processing device, it performs the functions defined above in the methods of embodiments of this disclosure.

[0142] The electronic device provided in this application employs the bitmap-based test data query method described in the above embodiments, solving the technical problems of low efficiency and low real-time performance in bitmap-based test data query. Compared with the prior art, the beneficial effects of the electronic device provided in this application are the same as those of the bitmap-based test data query method provided in Embodiment 1 above, and other technical features of this electronic device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0143] It should be understood that various parts of this disclosure can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics may be combined in any suitable manner in one or more embodiments or examples.

[0144] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0145] Example 4

[0146] This embodiment provides a computer-readable storage medium having computer-readable program instructions stored thereon, which are used to execute the bitmap-based test data query method in Embodiment 1 above.

[0147] The computer-readable storage medium provided in this application embodiment may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical links having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM, or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination thereof.

[0148] The aforementioned computer-readable storage medium may be included in an electronic device or may exist independently without being assembled into an electronic device.

[0149] The aforementioned computer-readable storage medium carries one or more programs that, when executed by an electronic device, cause the electronic device to: in response to a scheduled task instruction, acquire raw test data generated by the business systems of each product from a bitmap system, wherein the raw test data includes bitmaps of each product corresponding to a test account, the test account being a customer number or card number, and the bitmaps representing the holding status of the test account for each product; filter out valid test data from each of the raw test data and store the valid test data in a database; and in response to a data query instruction, retrieve target test data from the database that matches the data query instruction.

[0150] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be linked to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be linked to an external computer (e.g., via the Internet using an Internet service provider).

[0151] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0152] The modules described in the embodiments of this disclosure can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0153] The computer-readable storage medium provided in this application stores computer-readable program instructions for executing the bitmap-based test data query method described above, thus solving the technical problems of low efficiency and low real-time performance in bitmap-based test data query. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the bitmap-based test data query method provided in the above embodiments, and will not be repeated here.

[0154] Example 5

[0155] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the bitmap-based test data query method described above.

[0156] The computer program product provided in this application solves the technical problems of low efficiency and low real-time performance in bitmap-based test data querying. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the bitmap-based test data querying method provided in the above embodiments, and will not be repeated here.

[0157] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent scope of this application.

Claims

1. A bitmap-based test data query method, characterized in that, The bitmap-based test data query method includes: In response to a scheduled task instruction, the system obtains the original test data generated by the business system of each product from the bitmap system. The original test data includes the bitmap of each product corresponding to the test account. The test account is a customer number or card number. The bitmap is used to represent the holding status of the test account for each product. Valid test data is selected from the original test data and stored in the database, while invalid test data is stored in the blacklist. In response to a data query command, target test data matching the data query command is retrieved from the database; The step of storing the valid test data in the database includes: The valid test data is stored in a whitelist, and the valid test data in the whitelist is used for further screening and querying.

2. The bitmap-based test data query method as described in claim 1, characterized in that, The holding status of each product includes whether it is held or not held. The step of obtaining the raw test data generated by the business system of each product from the bitmap system includes: Obtain the bitmaps of each product corresponding to the test account from the bitmap system, and determine whether each bitmap is a household-level bitmap or a customer-level bitmap. If the bitmap is a household-level bitmap, then by querying the bitmap database table of household-level products, the holding status of the product is filtered to be the household-level bitmap of the holding and the corresponding card number; If the bitmap is a customer-level bitmap, then by querying the customer product bitmap database table, filtering the customer-level bitmaps whose holding status is "holding", and querying the card number corresponding to the customer-level bitmap.

3. The bitmap-based test data query method as described in claim 1, characterized in that, The step of filtering valid test data from the original test data includes: Send data query requests to the business systems corresponding to each card number in the original test data respectively, and obtain the message status returned by each business system; If the message status is normal, then the test data corresponding to the card number is valid test data; If the message status is abnormal, then the test data corresponding to the card number is invalid test data.

4. The bitmap-based test data query method as described in claim 1, characterized in that, The step of filtering valid test data from the original test data includes: The test data for each card number in the original test data is transmitted to the corresponding downstream target system to obtain the message status returned by the downstream target system. If the message status is normal, then the test data corresponding to the card number is valid test data; If the message status is abnormal, then the test data corresponding to the card number is invalid test data.

5. The bitmap-based test data query method as described in any one of claims 1-4, characterized in that, The data query instruction is obtained through an API interface. The step of retrieving target test data from the database that matches the data query instruction in response to the data query instruction includes: Data query instructions are obtained through the API interface. The data query instructions include at least the product name, upper and lower limits of the holding amount, and the number of data records. The product name is a required field. The SQL query statement is combined according to the data query instruction, and the corresponding target test data is queried in the database through the SQL query statement.

6. The bitmap-based test data query method as described in claim 5, characterized in that, After the step of retrieving the corresponding target test data from the database using the SQL query statement, the method further includes: The system queries the interface of the downstream target system to obtain the real-time asset information corresponding to the card number in the target test data, and determines whether the target test data is normal based on the real-time asset information. If the target test data is normal, then the real-time holding information of the card number in the target test data is returned; If the target test data is abnormal, the external interface of the business system corresponding to the card number will be returned.

7. The bitmap-based test data query method as described in any one of claims 1-4, characterized in that, The data query instruction is obtained through a chatbot tool. The step of retrieving target test data from the database that matches the data query instruction in response to the data query instruction includes: The user inputs a data query command through the chat interface of the chatbot tool, wherein the data query command includes at least the product name; The system pushes candidate input parameters to the user in the chat interface and obtains the input parameters entered by the user. The SQL query statement is combined based on the product name and the input parameters, and the corresponding target test data is retrieved from the database using the SQL query statement.

8. An electronic device, characterized in that, The electronic device includes: At least one processor; and, A memory that is communicatively linked to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the steps of the bitmap-based test data query method according to any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program implementing a bitmap-based test data query method, the program implementing the bitmap-based test data query method being executed by a processor to implement the steps of the bitmap-based test data query method as described in any one of claims 1 to 7.

Images