What This Category’s Data Entails
Data for this category originates from defect management systems, test reports, code commit records, and online user feedback. Update frequency follows daily or per-version release cycles. Core documents include:
- Defect tickets, which contain unique identifiers, priority levels, reproduction steps, fixed version numbers, and verification results
- Regression checklists, which contain test case IDs, associated defects, and execution statuses
- Repair verification records, which contain submitters, operation times, and verification conclusions
- Defect statistical reports, which summarize defect distribution and repair progress by cycle
The data has both semi-structured and strict schema characteristics, and covers tracking and retrospective needs across the full defect lifecycle.
Constraints Imposed on Database and Operations Workflows
Multi-source data synchronization requires compatibility with varied format write requests. High-frequency daily or version-level updates demand databases support high-concurrency read and write operations. Mixed storage of strict schema and semi-structured data requires databases to support both flexible queries and transaction consistency guarantees. High-time-consuming steps such as defect reproduction, priority determination, and regression verification require databases to support complex associated queries and fast data loading. Severe error consequences require databases to have high availability, to avoid data loss or query interruptions that disrupt fault troubleshooting and retrospective processes. This category focuses on functional defect lifecycles, and its data model differs significantly from performance testing categories. Mixed storage logic must be avoided.
Configuration Recommendations
These configurations are validated for FastGPT v4.17.0.
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
MONGODB_URI | mongodb://username:password@mongo-host:27017/fastgpt-defect?authSource=admin | Stores semi-structured data such as defect tickets and repair verification records, supports flexible queries across the defect lifecycle |
PG_URL | postgresql://username:password@pg-host:5432/fastgpt-regression | Stores strictly schemaed structured data such as regression checklists and defect statistical reports, ensures consistency for data writes and queries |
DB_MAX_LINK | 20–30 | Matches high-frequency read/write demands from daily or version-level updates, prevents database connection pool exhaustion from causing query timeouts |
REDIS_URL | redis://:redis-password@redis-host:6379/0 | Caches popular regression test cases and defect priority determination rules, reduces query pressure on primary databases |
| Data Retention Period | Retain 12 months per version | Meets historical data query needs for fault retrospectives, while controlling long-term storage costs |
Three Common Configuration Mistakes
- Symptom: A locally Docker-deployed database cannot write defect data, with errors indicating authentication failure or connection timeout. Cause:
MONGODB_URIorREDIS_URLis not configured with the correct Docker internal network address and authentication information, and does not match the service port and account password inside the container. - Symptom: After the execution status of a regression test case is updated, the statistical report is not synchronized. Cause:
MONGODB_URIis used to store strictly schemaed statistical data, instead of binding the dedicated structured database viaPG_URL, leading to write conflicts and data inconsistency. - Symptom: Queries for defect priority determination have excessive latency, affecting fault retrospective efficiency. Cause:
REDIS_URLis not configured to cache popular determination rules, so every query directly accesses the primary database, causing latency under high concurrency.
How to Verify Successful Configuration
- Perform batch creation and query operations for defect tickets, check that database connection logs show no connection timeout or authentication failure errors.
- Check the database bound to
PG_URL, confirm that no strict schema fields are missing or abnormal for regression checklists and statistical reports. - View the cache monitoring dashboard, confirm that requests for popular regression test cases are correctly cached, with no frequent primary database query records.
- Verify that after data is updated, statistical reports complete synchronization according to the business's preset cycle, with no data lag.
The values provided are common starting points, and should be measured 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.