What data for this category looks like
Data sources include code repositories, test framework reports, requirement specifications, and interface definitions. Update frequency is daily or per code commit. Daily documentation includes test cases, coverage reports, Mock instructions, and defect tickets. Test cases contain case identifiers, preconditions, execution steps, and expected results. Mock instructions include interface paths, request parameters, and return formats. Coverage reports contain module names and coverage metrics. Defect tickets contain problem descriptions and reproduction steps.
What constraints these characteristics impose on the "document parsing and chunking" link
Because the data update frequency is daily or per code commit, document parsing must adapt to frequently changing test documentation, and avoid repeated full parsing. Test cases, Mock instructions, and other documents contain structurally associated content. When chunking, context binding between case steps and preconditions, interface paths and request parameters must be retained. Do not split across units. Coverage reports bind modules and coverage metrics. Chunking must retain this corresponding relationship, to ensure accurate matching of test scope during retrieval. Documentation from code repositories contains code snippets. Chunking must retain the integrity of code blocks, and avoid splitting logical units. Problem descriptions and reproduction steps in defect tickets must be bound together. Do not split associated content during chunking.
The following configuration items are based on FastGPT v4.17.0.
How to set the configurations
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
chunkSize | 800–1200 characters | Adapts to the text length of test cases and Mock instructions, retains the integrity of a single case or interface description |
chunkSplitter | Split by semantic segments | Based on the structured characteristics of test documentation, split by case steps and interface modules, avoid splitting associated content |
customPdfParse | Enable digital signature compatibility mode | Adapts to test report PDFs with digital signatures, ensures normal recognition of content outside encrypted signature areas |
UPLOAD_FILE_MAX_SIZE | 1000 MB | Covers upload requirements for batch test reports and code repository export documents, calibrated based on actual testing |
PARSE_FILE_TIMEOUT_SECONDS | 600 seconds | Adapts to the parsing duration of large-volume coverage reports, avoids timeout interruptions of parsing tasks |
chunkSettingMode | Custom mode | Supports adjusting chunking rules based on test documentation types, adapts to test materials in different formats |
Three common mistakes
- After uploading a signed PDF test report, document content cannot be recognized. The cause is that the digital signature compatibility mode of
customPdfParseis not enabled. The parsing engine does not skip the signature area to extract the main content directly. - After calling the knowledge base interface to return a reading link, accessing the page reports an error indicating that only .txt and .m formats are supported. The cause is that the file format of the uploaded coverage report or Mock instructions is not supported by the basic parsing engine, and no corresponding
customPdfParseadaptation rule is configured. - After uploading a normally parsed test document, the large model output does not include associated images. The cause is that the chunking configuration does not enable binding extraction of images and text, and images are not embedded into the context of the corresponding chunk.
How to confirm configurations are correctly set
- Upload a signed test report PDF, check if the parsed text includes the test steps and metrics from the original document, to confirm that the
customPdfParseconfiguration is effective. - Upload a test report file with an unusually large volume, check that the parsing process does not experience timeout interruptions, to confirm that the
PARSE_FILE_TIMEOUT_SECONDSvalue is reasonable. - Import a single test case document, check that the chunking result does not split the preconditions and execution steps of the case, to confirm that the
chunkSizeandchunkSplitterconfigurations adapt to the document structure. - Call the knowledge base interface to obtain a reading link, confirm that the corresponding test document content loads normally after access, to confirm that the file format adaptation rules are effective.
The values provided here are common starting points, and should be evaluated against relevant 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.