How ICBC Solved Banking Test Data Pain with One‑Click Full‑Link Generation

1. Characteristics and Data Pain Points of Current Banking Systems

A single customer transaction must traverse multiple systems—from channel to core banking—to complete fund transfers and account updates, resulting in long transaction chains and strong inter‑system dependencies. The "three‑many" nature of banking (many transaction types, many customers, many regulatory rules) makes the architecture complex and tightly coupled.

Generating test data therefore requires a lengthy chain of steps; for example, creating a debit card involves establishing customer information, opening a checking account, depositing funds, and signing an e‑banking agreement across four front‑office transactions and three systems. This complexity demands high business knowledge from testers and consumes significant time.

Moreover, a usable test record must exist in the databases of all related systems, leading to data collision when multiple test cases share the same record, and version‑migration issues where upgraded system databases render existing test data obsolete, forcing testers to recreate data.

2. ICBC's Approach to Solving Test Data Challenges

1. Establishing Data Service Development Standards for One‑Click Full‑Link Generation

ICBC adopted an interface‑driven data creation method, encapsulating API calls into reusable data services. By defining a uniform data‑service communication format and enabling service chaining, the output of one service can feed the input of the next, allowing both single‑assistant and batch automatic data generation. Users can trigger an entire data‑generation chain with a single click from the test data center UI.

2. Supporting a Data Refresh Occupancy Mechanism for Freshness

To avoid data‑collision problems—e.g., two testers using the same debit‑card record simultaneously—the data center introduced a refresh‑occupancy mechanism. Data is modeled into three parts: base information (static, e.g., customer ID, card number), supplemental information (dynamic, e.g., balance), and features (state descriptors such as "card_status_normal"). A scheduled SQL process updates supplemental info and features, storing them back into the center.

The refresh process provides near‑real‑time data, while the occupancy rule ensures that once a user claims a record, it is locked from others until released, effectively eliminating data‑collision errors.

3. Feature‑Based Data Retrieval to Eliminate Solidified‑Data False Positives

Traditional automated tests often rely on hard‑coded data, which becomes invalid when the underlying record changes, causing script failures. ICBC's data center allows testers to request data by specifying required features; the system then supplies a fresh record matching those criteria at execution time. This approach removes the need for manual data replacement and significantly reduces false‑positive rates.

3. Achievements and Outlook

By June 2022, the test data center covered over 100 systems with more than 2,200 data services, refreshing data for 20 core banking modules. It served over 1,000 users, generating roughly 100,000 data records and 250,000 feature‑based queries per month. Feature validity reached 98%, and test‑related false positives dropped by over 60%.

The platform has repeatedly supported urgent joint testing with the People’s Bank of China, demonstrating its capability for large‑scale, one‑click full‑link data generation. Looking forward, ICBC plans to integrate additional core systems, enhance intelligent data generation, and further boost development efficiency as its core architecture continues to evolve.