How to Build an Efficient Public Resource Management System for Testing Teams

Introduction

High‑fidelity user‑behavior simulation requires extensive public testing resources such as devices, feature accounts, and virtual assets. As teams grow, managing these shared resources becomes increasingly complex, leading to scalability and reliability issues.

Why Manage Public Resources?

Public resources exhibit several risky characteristics:

Flowability : Resources move across the team, and their data can change during use (e.g., a live‑simulation account being turned on/off).

Trace‑free movement : Without controls, the flow leaves no audit trail (e.g., a physical device circulating without records).

Asset nature : Some resources hold monetary value, such as virtual currency or paid virtual‑service rights.

Opinion influence : High‑profile accounts can shape public perception.

Commercial risk : Bundled innovative activities may expose business secrets.

Security (密保) attribute : Passwords or keys tied to an account can be abused if not rotated.

Uncontrolled use of such resources can cause data leaks, reputation damage, financial loss, or equipment loss.

Which Resources Should Be Managed?

Any resource that matches the above traits should be governed, including physical test machines, unlimited‑data SIM cards, sandbox IAP accounts, privilege‑exchange codes, etc.

Design and Evolution of the Resource Management System

The author shares the practical evolution of a management platform.

v1.0 – Approval Pipeline Management System

The system classifies virtual and physical resources, stores them in a database, and requires designated administrators to approve and distribute usage. The approval workflow is recorded persistently, solving the “no‑trace” problem.

Asset permission control and sensitive‑data reclamation are handled by limiting asset‑related actions to gray‑environment deployments, isolating real data.

For online simulations, resources are tagged with a “test” attribute; data collection, statistics, and display are governed by whitelist and switch controls, keeping real users untouched.

Problems Discovered After v1.0

Problem 1 – Random Distribution : Administrators assign virtual resources arbitrarily, causing configuration mismatches (e.g., a “carrot” feature configured for account 1 is borrowed by a user who does not need it, forcing another user to re‑configure).

Problem 2 – Password Reuse : A single password grants unlimited access; if not changed promptly after return, subsequent borrowers can cause asset loss without accountability.

v2.0 – More Complete and Autonomous Management System

To address the new issues, v2.0 introduces:

Domain partitioning: Resources are grouped by logical domains (e.g., “rabbit” owns carrots and grassland, “fox” enjoys forest and game).

Automatic safety mechanisms: Expiration‑based auto‑return, background jobs that rotate passwords, and continuous security checks.

Flexible permission model: Designated “rabbit chief” can manage requests, or users can self‑approve within their domain.

Key Takeaways and Remaining Questions

Data changes during resource flow can be avoided by using gray‑environment isolation.

Audit trails are ensured by persisting every approval and usage record.

Asset tagging and switch‑based control keep virtual assets separate from real users, preventing financial loss.

Opinion and commercial risks are mitigated by restricting visibility of privileged accounts.

Security is reinforced through periodic permission checks and real‑time password rotation.

While the system resolves most common resource‑usage problems, the author raises a final practical question: how to simplify the recycling of physical devices, which still requires labor‑intensive periodic inventory?