Claude Code + Skills: A Complete Hands-On Guide to Automatically Generating Test Cases from Requirements Documents

Overview

Writing test cases from requirements documents has always been one of the most time-consuming tasks in software testing. Manually breaking down and writing test cases for a requirements document spanning dozens of pages often takes several days. According to industry statistics, an experienced test engineer can manually produce about 50–100 high-quality test cases per day, while a medium-sized feature module often requires hundreds of cases for adequate coverage. The deeper challenge lies in consistency of test case quality — different test engineers have significantly different interpretations of boundary conditions and exception paths, making it difficult to quantify and guarantee test coverage.

This article introduces an approach based on Claude Code combined with custom Skills to automate the entire pipeline from requirements document input to comprehensive test case output. The core value of AI-generated test cases lies not only in speed improvement but also in ensuring that every requirement point undergoes test design across the same dimensions through standardized extraction logic, thereby improving the predictability of coverage.

The entire process requires just a single command to complete five major steps: document parsing, requirements decomposition, test point extraction, quality review, and test case export.

Overall Architecture: Transforming Claude Code into a Testing Agent

The core idea of this approach is to transform Claude Code from its default role as a "coding agent" into a "test case generation agent." Claude Code is an AI programming agent launched by Anthropic for developers, with its core design philosophy being an extensible Tool Use mechanism that enables the model to execute real-world tasks. The Skills system is essentially an encapsulation and customization of this mechanism — developers can constrain and guide Claude Code's general capabilities toward specific business scenarios by defining prompt templates, command invocation rules, or script logic. This shares the same design philosophy as Chain/Agent concepts in LangChain and the plugin mechanism in AutoGPT — all are engineering practices that combine large models' reasoning capabilities with external tool execution abilities.

Through a carefully designed Skills system and system prompts, the AI follows a standardized process to handle requirements documents and output high-quality test cases.

The entire workflow consists of five key steps:

1. Requirements Normalization — Unify document format to Markdown
2. Requirements Decomposition — Extract feature points by module and associate images
3. Test Point Extraction — Generate test points through multimodal understanding
4. Test Point Review — Quality audit and coverage analysis
5. Test Case Export — Output in Excel/XMind and other formats

Detailed Breakdown of the Five Steps

Step 1: Requirements Normalization

In real projects, requirements documents come in all kinds of formats — PDFs, Word documents, image screenshots, and more. Feeding documents in different formats directly to a large model without a unified standard leads to unstable quality in subsequent steps.

The core approach to normalization is: using document processing tools to convert all formats of requirements documents into a unified Markdown format, while separating and extracting images from the documents (business flow diagrams, prototypes, data charts, etc.) for standalone storage. In engineering practice, this typically relies on a combination of tool chains: PDF parsing can use PyMuPDF or pdfplumber to extract text and image coordinates; Word document processing commonly uses python-docx; and text within images requires OCR engines (such as Tesseract or PaddleOCR).

The choice of Markdown as the target format is no coincidence — its structured heading hierarchy (#, ##, ###) naturally maps to the chapter structure of requirements documents, making it easy to split by module in subsequent steps. At the same time, Markdown is LLM-friendly, with higher token efficiency than rich-format text like HTML. The design of extracting and storing images separately prepares for the multimodal processing stage, preventing image information from being lost during text conversion. This step requires dedicated Skills to ensure the large model can fully understand all content in the document.

Step 2: Decompose Requirements by Module

After normalization, the system splits requirements by chapter and functional module. Each functional module is associated with its relevant text descriptions and image resources.

Taking the e-commerce website project from the demo as an example, the system identified 10 chapters, extracted 118 requirement points, and 8 key images. The Skills design for this step is crucial — clear decomposition rules and output structures must be defined to ensure every feature point is accurately identified and categorized.

Step 3: Multimodal Test Point Extraction

This is the most technically sophisticated part of the entire approach. Unlike simply "reading text to generate test cases," this approach uses multimodal models to simultaneously understand textual requirements and image content (such as flowcharts and prototypes) to comprehensively generate test points.

Multimodal large models (such as the Claude 3 series, GPT-4V) can process both text and image inputs simultaneously, a capability that holds unique value in software testing scenarios. In traditional requirements documents, a large amount of critical information exists in the form of flowcharts (such as BPMN business process diagrams), wireframes, and state machine diagrams. These graphical elements often describe the most complex business logic branches and state transition paths — precisely the areas where test coverage is hardest to guarantee. Pure text parsing approaches systematically miss this information, while multimodal models can identify decision nodes, loop structures, and exception paths in diagrams, converting them into corresponding test scenarios.

This is the key reason why test cases generated by this approach are of significantly higher quality than conventional methods — many test scenarios are hidden in flowcharts and prototypes and simply cannot be covered by pure text analysis. In the demo project, the system generated over 300 test points for the e-commerce website, with each test point including preconditions, test data, and expected results.

Step 4: Automated Test Point Review

After generating test points, the system automatically performs a round of quality review, focusing on:

• Whether test points cover all acceptance criteria
• Whether there are missing boundary scenarios and exception paths
• Whether test case descriptions are clear and executable

Only after passing the review does the process move to the final export stage. This mechanism effectively ensures output quality and avoids the "garbage in, garbage out" problem.