What the Data for This Category Looks Like
This category’s data is generated across the full user acceptance testing workflow. Sources include requirement specification documents, test environment operation data, customer business sample materials, and defect management system records. Daily produced documents include UAT test cases, acceptance issue tickets, acceptance reports, and signed confirmation slips. Data is updated by project phase or version. A single UAT test case includes test scenario, operation steps, and expected result fields. An acceptance issue ticket records failure symptoms, reproduction steps, and impact scope fields. An acceptance report includes issue statistics and conclusion fields. It only records text content and status flags, with no mandatory quantitative unit requirements.
What Constraints These Characteristics Impose on the Database and Operations Link
Data sources are scattered and rely on customer business samples. This requires databases to support mixed storage of multi-source heterogeneous text and structured data. It must support importing UAT test cases and issue tickets in different formats. The feature of updating by phase or version requires databases to support querying data snapshots by phase. This enables retrospective troubleshooting across different test nodes. The requirement to link acceptance issue tickets with defect systems requires configuring cross-system data synchronization links in operations. This ensures real-time alignment between failure records and defect status. Storage of unstructured documents like signed confirmation slips requires databases to support associated storage of large text fields and binary attachments. This avoids data fragmentation.
Configuration Settings
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
MONGODB_URI | mongodb://uat_user:Uat@2024@db-host:27017/uat_db?retryWrites=true | Stores unstructured UAT test cases and acceptance reports. Supports full-text retrieval of fault-related text |
PG_URL | postgresql://uat_admin:Pass123@db-host:5432/uat_acceptance | Stores structured acceptance issue tickets and defect-related fields. Supports filtering data by status and phase |
DB_MAX_LINK | 15–25 connections | Adapts to scenarios with multiple concurrent tester accesses. Prevents exhaustion of database connection resources |
REDIS_URL | redis://:redis-pass@cache-host:6379/0 | Caches frequently accessed acceptance conclusions and test case classification data. Reduces database query load |
| Database Backup Policy | Daily full backup + hourly incremental backup, retain 7 days of historical backups | Matches the data update feature by version. Enables rapid rollback to the dataset for a corresponding test phase after a fault occurs |
Three Common Mistakes
- After deploying the environment, running a database query returns the
text index required for $text queryerror. The cause is that no full-text index was created for the MongoDB fault text field. This prevents keyword retrieval from executing. - After upgrading FastGPT v4.17.0, existing UAT test data is lost. The cause is that the dedicated database instance bound to
MONGODB_URIwas not backed up in advance. Direct overwriting deployment clears the data. - When orchestrating database queries, the number of returned results does not match expectations. The cause is that no reasonable value was configured for
DB_MAX_LINK. Concurrent connections are exhausted. Queries are interrupted and return incomplete results.
How to Confirm Proper Configuration
- Access the database management tool. Verify that the instance corresponding to
MONGODB_URIcontains UAT-related collections. Confirm that acceptance issue ticket documents include complete fields. - Run a database connection test script. Confirm that the connection status for
PG_URLandREDIS_URLis normal. No timeout or permission errors are present. - Import a test UAT test case. Run a query operation. Confirm that the returned results match expectations. Verify that index configuration is active.
- View the operations monitoring panel. Confirm that database connection counts do not exceed the
DB_MAX_LINKsetting. No abnormal error logs are present.
The values provided are common starting points. They should be evaluated against the reader's own samples.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-10-19.