This document is written based on FastGPT v4.17.0.
What the data for this category looks like
Typical data for this category comes from code repositories, test framework reports, requirement descriptions, and interface definitions. Update frequency is daily or per code commit. Commonly processed documents include standardized test cases, coverage statistics reports, Mock interface descriptions, defect tracking tickets, and more. Test cases include fixed fields such as case ID, preconditions, execution steps, and expected results. Mock descriptions include structured content such as interface paths, request parameters, and return formats. Defect tickets include reproduction steps, log snippets, and screenshot attachments.
What constraints these characteristics impose on document parsing and chunking
Structured test documents require chunking to preserve field integrity, and prevent splitting the preconditions and expected results of a single test case. High-frequency, small-batch updated data requires the chunking workflow to adapt to fast iterative submission cycles, avoiding excessive parsing delays that disrupt development pipelines. Defect tickets with screenshots and coverage reports require the parsing step to support extracting text embedded in images. Critical test information will be lost otherwise. Large test framework reports require chunking configurations to align with single-file processing limits, stopping parsing timeouts or interruptions.
How to set the configurations
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
chunkSize | 800–1200 characters | Aligns with the information density per chunk for test cases and Mock descriptions, avoids overly long chunks that cause redundant retrieval, and ensures a single chunk contains a complete test logic unit |
chunkSplitter | Split by semantic paragraphs | Matches the structured paragraph structure of test documents, preserving the integrity of preconditions, execution steps, and expected results for a single test case |
customPdfParse | Enable OCR mode | Adapts to PDF defect tickets and coverage reports containing screenshots, extracting reproduction steps and statistical text embedded in images |
PARSE_FILE_TIMEOUT_SECONDS | 120 seconds | Covers the parsing time of large test framework reports, preventing task failures caused by timeout interruptions |
chunkSettingMode | Manual configuration | Adapts to chunking requirements for different types of test documents, avoiding automatic chunking that breaks the association between structured fields |
Three common errors
- Symptom: After parsing a test report PDF containing screenshots, the text embedded in the images is not extracted. Cause: The OCR mode of
customPdfParseis not enabled, and only the plain text surface content of the PDF is extracted. - Symptom: After chunking, the preconditions and expected results of a single test case are split into different chunks. Cause:
chunkSplitteris configured to split by fixed characters, and does not identify the structured units of test documents via semantic paragraphs. - Symptom: When uploading a test framework report larger than 100 MB, the parsing task times out and fails directly. Cause: The value of
PARSE_FILE_TIMEOUT_SECONDSis lower than the actual parsing time of this type of document, and the processing rhythm for large-volume test data is not adapted.
How to confirm the configuration is correct
- Upload a PDF defect ticket containing screenshots, and check if the reproduction step text from the screenshots is included in the parsing results.
- Upload a standardized test case document, and verify that the chunking results retain the complete preconditions and expected results for a single test case.
- Upload a test framework report larger than 50 MB, and confirm that the parsing task does not display timeout errors.
- View the chunk length statistics panel, and confirm that the character count per chunk falls within the preset 800–1200 character range.
The values provided are common starting points, and 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.