1. 项目概述：当测试工程师遇上AI

最近和几个测试团队的朋友聊天，大家不约而同地提到了同一个痛点：写测试用例，尤其是那些功能点繁杂、边界条件众多的模块，实在是太耗费时间和精力了。一个需求下来，光是把所有正向、反向、异常场景的测试用例梳理成文档，可能就要花掉一两天。更头疼的是，这种重复性高、逻辑性强的工作，还特别容易因为人的疲劳或疏忽导致遗漏。我自己也深有体会，曾经就因为在设计一个文件上传功能的测试用例时，漏掉了某个特定文件格式与大小组合的边界情况，导致线上出了个小问题。

就在这种背景下，“AI测试用例生成”这个概念开始频繁出现在我们的视野里。简单来说，它就是利用人工智能技术，特别是大语言模型（LLM），来辅助甚至自动化地生成软件测试用例。这听起来有点像让AI来当我们的“测试用例设计助理”。它不再是遥不可及的未来科技，而是随着像GPT、文心一言、通义千问这类模型的成熟和API的开放，变得触手可及。我们不再需要从头训练一个AI，而是可以基于现有的大模型，通过“提示词工程”和脚本封装，打造一个属于自己团队的高效工具。

所以，这个“AI测试用例生成脚本”项目，本质上就是一个桥梁。它的一端连接着强大的、具备通用理解能力的AI大模型，另一端则对准了我们测试工作中最耗时、最需要规范化的环节。这个脚本的核心任务，是接收我们输入的、相对自然的需求描述（比如产品需求文档片段、用户故事、接口定义），然后通过精心设计的提示词与AI交互，输出结构清晰、覆盖度良好的测试用例，格式可能是Excel、思维导图，或者直接是团队在用的测试管理工具（如TestLink、Jira）的导入格式。

它适合谁呢？首先肯定是广大的一线测试工程师和测试开发工程师，能直接将我们从繁重的文档工作中解放出来，把精力更多投入到探索性测试、性能测试等更有创造性的工作中。其次，对于研发团队负责人或项目经理，这意味着测试用例的设计效率和质量可以得到基线保障，加速测试左移的进程。甚至对于产品经理，也可以用它来快速验证需求描述的完整性和可测试性。

2. 脚本核心设计思路与方案选型

当我们决定动手做一个AI测试用例生成脚本时，第一个要回答的问题就是：我们到底要做一个什么样的工具？是把所有东西都包揽的“重型平台”，还是一个轻量、灵活、即插即用的“脚本工具”？我个人的倾向非常明确：先从脚本工具做起。原因很简单，重型平台开发周期长，试错成本高，而且容易与团队现有流程产生排异反应。一个脚本，用Python或Node.js写，几百行代码，能快速验证想法，快速迭代，并且能无缝嵌入到现有的CI/CD流水线或本地工作流中，这才是工程师喜欢的方式。

2.1 核心流程拆解

整个脚本的工作流可以抽象为以下几个核心环节，我把它画成了一个简单的线性流程，方便理解：

1. 输入处理：脚本需要能接收多种格式的输入。最理想的是直接读取产品需求文档（PRD）的某个章节、接口的Swagger/OpenAPI定义文件，或者至少是一段结构清晰的Markdown格式的需求描述。如果输入非常原始，可能还需要一个简单的“需求解析与澄清”模块，但这会增加复杂度，初期可以要求输入相对规范。
2. 提示词工程：这是整个脚本的灵魂所在。我们不能简单地把需求文本扔给AI说“生成测试用例”，那得到的结果会非常随机且不可用。必须构建一个结构化的“提示词模板”。这个模板通常包含：
   • 角色定义：明确告诉AI它现在是一名资深测试专家。
   • 任务指令：清晰说明需要基于给定的需求生成测试用例。
   • 输出格式规范：必须严格要求AI以指定的格式输出，例如：“请以JSON格式输出，包含字段：test_case_id,test_objective,preconditions,test_steps,expected_result,test_type(功能/界面/兼容性/安全等),priority(P0/P1/P2)”。
   • 示例：提供一两个高质量的例子，让AI学会我们想要的风格和细致程度。
   • 约束条件：比如“请重点考虑边界值分析和异常流”，“每个正常流场景，至少配套设计两个异常流场景”。
3. 调用AI模型API：将组装好的提示词，通过HTTP请求发送给选定的AI模型服务（如OpenAI的ChatGPT API、国内的通义千问API、文心一言API等），并获取返回的文本结果。
4. 结果解析与后处理：AI返回的通常是文本，我们需要将其解析成结构化的数据（如Python字典、列表）。这里要处理AI可能的不合规输出，比如格式错误、多余的解释文字等，需要编写健壮的解析逻辑。
5. 输出格式化：将结构化的测试用例数据，转换成最终用户需要的格式。常见的有：
   • Excel (.xlsx)：利用pandas或openpyxl库生成，可以分Sheet组织模块，这是最通用、最易分享的格式。
   • CSV (.csv)：轻量，易于版本管理和diff。
   • Markdown (.md)：便于直接插入项目Wiki或Confluence。
   • 测试管理工具导入格式：如生成Jira的CSV导入模板，或直接调用TestLink的XML-RPC API进行创建。
6. 错误处理与日志：整个流程必须有完善的异常捕获和日志记录。API调用可能失败，网络可能超时，AI可能返回无法解析的内容。好的脚本应该能优雅地处理这些情况，并给出明确的错误信息，方便排查。

2.2 技术栈选型考量

明确了流程，接下来就是技术选型。这里没有绝对的最优解，只有最适合当前团队和场景的选择。

• 编程语言：Python是首选。原因有三：其一，生态丰富，处理HTTP请求有requests，解析JSON轻而易举，操作Excel有pandas/openpyxl，处理Markdown有mistune等，几乎每一步都有成熟的库。其二，在AI和数据科学领域，Python是事实标准，社区支持最好。其三，脚本编写快速，学习成本相对较低。如果团队主力是Node.js，用axios和xlsx库也能实现，但整体生态稍逊。
• AI模型服务选择：
  • GPT系列 (OpenAI API)：能力最强，尤其在理解复杂指令和生成结构化内容方面表现突出。缺点是可能需要处理网络访问问题（注意：此处仅客观陈述技术选型中可能存在的客观障碍，不涉及任何具体方法或工具），且API调用有成本。
  • 国内大模型API (文心一言、通义千问、讯飞星火等)：访问稳定、速度快，符合数据合规要求，中文语境理解可能更接地气。大部分都提供了免费的测试额度，非常适合初期验证和中小规模使用。需要仔细阅读各家的API文档，了解其特有的调用方式和参数。
  • 本地部署模型 (如ChatGLM3、Qwen等)：数据完全私有，安全性最高，适合对数据保密要求极高的场景。但需要一定的GPU资源，且生成速度和效果可能不如云端API，调试和维护成本也更高。对于“脚本”项目而言，初期不建议。
  • 我的选择建议：从快速验证和性价比出发，我建议先用国内大模型的免费额度跑通全流程。比如阿里云的通义千问，注册就有一定免费token，文档清晰，足以支撑我们完成原型开发。
• 配置管理：API Key、模型类型、温度参数等不应该硬编码在脚本里。推荐使用.env文件配合python-dotenv库来管理，或者使用config.yaml文件。这样既能保证安全（避免密钥上传到代码仓库），也方便不同环境切换配置。

注意：关于提示词（Prompt）的稳定性。这是AI应用最大的挑战之一。同样的提示词，AI每次的产出可能有细微差别。为了提升稳定性，除了精心设计提示词，在脚本中可以尝试两种策略：1. 在提示词中明确要求“思考过程”，并让AI先输出思考链，再输出最终答案，有时能提高一致性。2. 对于关键模块，可以设计“评审-修正”循环，即AI生成后，脚本自动对其输出进行基础合规性检查（如字段是否齐全），或提出几个澄清问题让AI自我修正，但这会显著增加复杂度和API调用成本。

3. 从零搭建：一个可运行的Python脚本实现

光说不练假把式，下面我就以一个具体的场景为例，手把手拆解如何用Python实现一个最基础的AI测试用例生成脚本。我们的目标是：输入一段用户登录功能的需求描述，输出一个包含多条测试用例的Excel文件。

3.1 环境准备与依赖安装

首先，确保你的电脑上安装了Python（建议3.8以上版本）。我们创建一个新的项目目录，并初始化虚拟环境，这能有效隔离依赖。

mkdir ai-testcase-generator cd ai-testcase-generator python -m venv venv # 创建虚拟环境 # 激活虚拟环境 # 在Windows上： venv\Scripts\activate # 在Mac/Linux上： source venv/bin/activate

接下来，安装必要的Python包。我们将使用requests调用API，python-dotenv管理配置，pandas和openpyxl输出Excel。

pip install requests python-dotenv pandas openpyxl

然后，我们需要获取AI模型的API访问凭证。以阿里云通义千问为例，你需要：

1. 登录阿里云官网，开通灵积模型服务。
2. 在控制台创建API Key（AccessKey ID和Secret）。
3. 记下你的API Key，我们稍后会用到。

在项目根目录下创建一个.env文件（注意文件名开头的点），用于存放敏感配置。切记要将.env添加到.gitignore中，避免密钥泄露。

# .env 文件内容 DASHSCOPE_API_KEY=你的API_Key MODEL_NAME=qwen-max # 模型名称，如 qwen-max, qwen-plus API_BASE_URL=https://dashscope.aliyuncs.com/compatible-mode/v1 # 通义千问兼容OpenAI的端点

3.2 核心模块一：AI客户端封装

我们创建一个ai_client.py文件，专门负责与AI API的通信。这里我们模仿OpenAI的格式，因为通义千问提供了兼容端点，这样代码有更好的可移植性。

# ai_client.py import os import requests from dotenv import load_dotenv # 加载 .env 文件中的环境变量 load_dotenv() class AIClient: def __init__(self): self.api_key = os.getenv('DASHSCOPE_API_KEY') self.base_url = os.getenv('API_BASE_URL') self.model = os.getenv('MODEL_NAME', 'qwen-max') if not self.api_key: raise ValueError("请在 .env 文件中设置 DASHSCOPE_API_KEY") def generate_test_cases(self, requirement_text): """ 根据需求文本生成测试用例 :param requirement_text: 需求描述字符串 :return: AI返回的原始文本内容 """ # 构建请求头 headers = { 'Authorization': f'Bearer {self.api_key}', 'Content-Type': 'application/json' } # 构建请求体（消息） # 这里是提示词工程的核心！ messages = [ { "role": "system", "content": "你是一位经验丰富的软件测试工程师，擅长根据需求设计全面、细致的测试用例。你的输出必须严格遵循指定的格式。" }, { "role": "user", "content": f"""请根据以下功能需求，设计测试用例。 需求描述： {requirement_text} 请按照以下JSON格式输出测试用例列表，不要输出任何其他解释性文字： ```json [ {{ "test_case_id": "TC_LOGIN_001", "test_objective": "验证使用正确的用户名和密码可以成功登录", "preconditions": ["用户已注册", "用户账号未被锁定"], "test_steps": ["1. 打开登录页面", "2. 输入有效的用户名", "3. 输入有效的密码", "4. 点击登录按钮"], "expected_result": "登录成功，页面跳转到用户主页或显示登录成功提示", "test_type": "功能测试", "priority": "P0" }}, {{ "test_case_id": "TC_LOGIN_002", "test_objective": "验证使用错误的密码登录失败", "preconditions": ["用户已注册"], "test_steps": ["1. 打开登录页面", "2. 输入有效的用户名", "3. 输入错误的密码", "4. 点击登录按钮"], "expected_result": "登录失败，页面提示“用户名或密码错误”", "test_type": "功能测试", "priority": "P1" }} ]

请至少生成5个测试用例，需覆盖：1. 正常登录流程 2. 用户名错误 3. 密码错误 4. 用户名密码为空 5. 密码是否密文显示 6. 登录失败次数过多是否锁定账号。请确保test_case_id具有唯一性和可读性。 """ } ]

data = { "model": self.model, "messages": messages, "temperature": 0.2, # 温度参数调低，使输出更稳定、更确定 "max_tokens": 2000 } try: response = requests.post(f"{self.base_url}/chat/completions", headers=headers, json=data, timeout=30) response.raise_for_status() # 如果状态码不是200，抛出异常 result = response.json() # 提取AI返回的消息内容 content = result['choices'][0]['message']['content'] return content except requests.exceptions.RequestException as e: print(f"API请求失败: {e}") return None except KeyError as e: print(f"解析API响应失败，响应结构异常: {e}") print(f"原始响应: {result}") return None

**代码解读与心得**： 1. **提示词是核心**：我把详细的指令、格式示例、覆盖点要求都放在了`user`角色的`content`里。`system`角色设定了AI的“人设”。这种分角色的方式能让AI更好地理解任务。 2. **温度参数**：`temperature`设置为0.2，这是一个较低的值，目的是让AI的输出更加聚焦和确定，减少“天马行空”的随机性，对于生成需要严格格式的测试用例非常重要。 3. **错误处理**：网络请求和API调用可能失败，用`try-except`包裹并打印明确错误信息，是脚本健壮性的基础。 4. **格式约束**：我要求AI输出一个JSON数组，并给出了两个非常具体的例子。这极大地提高了AI返回结构化数据的成功率。直接要求“输出JSON”比让AI自由发挥后再用正则表达式去解析要可靠得多。 ### 3.3 核心模块二：结果解析与Excel导出 AI返回的是一个包含JSON的文本块（可能被Markdown代码块包裹）。我们需要将其中的JSON解析出来，并转换成Excel。创建`output_handler.py`。 ```python # output_handler.py import json import pandas as pd import re class OutputHandler: @staticmethod def parse_ai_response(ai_response_text): """ 解析AI返回的文本，提取JSON部分 :param ai_response_text: AI返回的完整文本 :return: 解析后的Python列表（字典的列表），解析失败返回None """ if not ai_response_text: return None # 尝试1：直接查找JSON字符串（可能被```json ... ```包裹） json_pattern = r'```json\s*([\s\S]*?)\s*```' match = re.search(json_pattern, ai_response_text) if match: json_str = match.group(1) else: # 尝试2：如果没有代码块，尝试直接查找第一个`[`和最后一个`]`之间的内容 start = ai_response_text.find('[') end = ai_response_text.rfind(']') if start != -1 and end != -1 and end > start: json_str = ai_response_text[start:end+1] else: print("无法从AI响应中提取有效的JSON字符串。") print("响应内容预览：", ai_response_text[:500]) return None try: test_cases = json.loads(json_str) # 确保返回的是列表 if isinstance(test_cases, list): return test_cases else: print(f"解析出的JSON不是列表类型: {type(test_cases)}") return None except json.JSONDecodeError as e: print(f"JSON解析失败: {e}") print(f"尝试解析的字符串: {json_str[:200]}...") return None @staticmethod def save_to_excel(test_cases_list, filename='generated_test_cases.xlsx'): """ 将测试用例列表保存为Excel文件 :param test_cases_list: 测试用例字典列表 :param filename: 输出的Excel文件名 """ if not test_cases_list: print("测试用例列表为空，不生成文件。") return False # 使用pandas的DataFrame直接转换 df = pd.DataFrame(test_cases_list) # 调整列的顺序，让ID和优先级在前面 preferred_order = ['test_case_id', 'priority', 'test_objective', 'test_type', 'preconditions', 'test_steps', 'expected_result'] # 只保留数据中存在的列 existing_columns = [col for col in preferred_order if col in df.columns] # 加上其他可能存在的列 other_columns = [col for col in df.columns if col not in existing_columns] final_order = existing_columns + other_columns df = df[final_order] try: # 使用openpyxl引擎写入Excel with pd.ExcelWriter(filename, engine='openpyxl') as writer: df.to_excel(writer, index=False, sheet_name='测试用例') # 获取workbook和worksheet对象以进行格式调整 workbook = writer.book worksheet = writer.sheets['测试用例'] # 自动调整列宽（近似） for column in worksheet.columns: max_length = 0 column_letter = column[0].column_letter for cell in column: try: cell_value_len = len(str(cell.value)) except: cell_value_len = 0 if cell_value_len > max_length: max_length = cell_value_len adjusted_width = min(max_length + 2, 50) # 设置最大宽度 worksheet.column_dimensions[column_letter].width = adjusted_width print(f"测试用例已成功保存至: {filename}") return True except Exception as e: print(f"保存Excel文件失败: {e}") return False

代码解读与心得：

1. 健壮的解析：AI的输出可能不会100%听话，有时会在JSON外面包裹Markdown代码块标记，有时会多几句解释。这里用了正则表达式和字符串查找两种方式尝试提取JSON，提高了容错率。
2. 数据处理：使用pandas.DataFrame是处理表格数据的利器。我们可以轻松地调整列顺序、过滤数据。
3. 用户体验：自动调整Excel列宽是一个小细节，但能让生成的文档看起来更专业，无需手动调整。这里设置了一个最大宽度（50），防止某个单元格内容过长导致列宽失控。

3.4 主程序入口

最后，我们创建一个main.py来串联整个流程。

# main.py from ai_client import AIClient from output_handler import OutputHandler def main(): # 1. 示例需求描述 - 这里可以替换为从文件读取或命令行参数传入 login_requirement = """ 用户登录功能需求： 1. 登录页面包含用户名输入框、密码输入框、登录按钮。 2. 用户名支持邮箱或手机号格式。 3. 密码输入时需隐藏显示（显示为圆点或星号）。 4. 点击登录按钮后，系统验证用户凭证。 4.1 验证成功：跳转至用户个人中心首页，并记录登录状态。 4.2 验证失败：在登录页面下方显示红色错误提示信息“用户名或密码错误”。 5. 连续5次登录失败后，该账号将被锁定30分钟，期间无法登录。 6. 提供“记住我”复选框，勾选后下次访问登录页自动填充用户名。 """ print("开始生成测试用例...") print("需求描述：") print(login_requirement) print("-" * 50) # 2. 初始化AI客户端并生成 client = AIClient() raw_response = client.generate_test_cases(login_requirement) if not raw_response: print("AI生成失败，程序退出。") return print("AI原始响应接收成功。") # 可以打印出来看看，调试用 # print(raw_response) # 3. 解析响应 handler = OutputHandler() test_cases = handler.parse_ai_response(raw_response) if not test_cases: print("解析AI响应失败，请检查提示词或AI返回内容。") return print(f"成功解析出 {len(test_cases)} 条测试用例。") # 4. 保存为Excel output_filename = '登录功能测试用例.xlsx' if handler.save_to_excel(test_cases, output_filename): print("流程执行完毕。") else: print("流程执行失败。") if __name__ == "__main__": main()

现在，在项目根目录下运行python main.py，如果一切配置正确，你应该能在当前目录下看到一个名为登录功能测试用例.xlsx的文件，里面包含了AI生成的、格式规范的测试用例。

4. 进阶优化与实战经验分享

一个能跑通的脚本只是起点。要让这个工具真正在团队中发挥作用，产生价值，还需要考虑很多工程化和实用性的问题。下面分享我在实际尝试和与同行交流中总结的一些进阶思路和踩过的坑。

4.1 提升生成质量与可控性

AI生成的内容质量波动是最大的挑战。除了优化基础提示词，还有以下方法可以尝试：

• 分步骤生成：不要指望一个提示词解决所有问题。可以设计两阶段甚至三阶段生成。
  1. 第一阶段：生成测试点。提示AI：“请根据以下需求，列出所有需要测试的功能点、输入域和边界条件。” 得到一个结构化的测试点大纲。
  2. 第二阶段：基于测试点生成用例。将测试点大纲作为新的输入，提示AI：“请针对以下每一个测试点，设计至少一条具体的测试用例，包含步骤和预期结果。” 这样做的好处是，你可以先人工审核或调整测试点大纲，确保覆盖度，然后再让AI填充细节，可控性更强。
• 提供领域知识：如果你测试的是一个特定领域（如金融支付、物联网设备），可以在system提示词或user提示词的开头，加入一些领域规则和测试常识。例如：“你是一名金融系统测试专家，熟知支付交易中的状态机、幂等性、对账等测试要点。在设计测试用例时，请特别关注...”
• 利用Few-Shot Learning：在提示词中提供更多、更高质量的示例。示例是最好的老师。如果你有历史积累的优秀测试用例，挑选几个最具代表性的，格式化后放入提示词，能极大地引导AI模仿其风格和细致程度。
• 后处理与规则校验：脚本不应只是被动接收AI的输出。可以加入简单的规则校验逻辑。例如，检查生成的测试用例中是否包含“密码”字段但expected_result里出现了明文密码（这违反了安全测试原则）；或者检查priority字段的值是否在约定的[‘P0‘， ’P1‘， ’P2‘]范围内，如果不在则自动修正或标记。

4.2 工程化与集成实践

脚本要融入团队工作流，才能发挥最大价值。

• 输入来源多样化：
  • 文件读取：支持从.md、.txt、.docx甚至Confluence页面（通过API）直接读取需求文本。
  • 接口集成：解析Swagger/OpenAPI的YAML/JSON文件，自动为每个API接口生成正向、反向、参数校验、安全相关的测试用例。这是API测试自动化的绝佳起点。
  • UI元素识别：结合Selenium或Playwright等UI自动化工具，录制或解析页面元素，生成针对性的UI交互测试用例（如“点击XX按钮后，YYY元素应该出现”）。
• 输出集成：
  • 直接导入测试管理工具：与其生成中间文件，不如让脚本直接调用TestLink、Jira（通过Zephyr Scale等插件）、TestRail的API，创建测试用例并关联到对应的需求或用户故事。这实现了从需求到测试用例的无缝衔接。
  • 生成自动化测试脚本骨架：更进一步，可以让AI在生成test_steps的同时，生成对应的Selenium（Python）或Cypress（JavaScript）的代码片段。虽然不能直接用于生产，但能为自动化测试工程师提供极有价值的参考和起点。
• 配置化与模板化：
  • 将提示词模板、输出格式模板、领域规则等都抽离成配置文件（如config.yaml）。这样，测试不同项目（如Web前端、移动端、后端API）时，只需切换配置文件，而无需修改代码。
  • 为不同的测试类型（功能、性能、安全、兼容性）设计不同的提示词模板。

4.3 常见问题与排查技巧实录

在实际操作中，你肯定会遇到各种各样的问题。下面是我遇到的一些典型情况及其解决方法：

一个关键的实操心得：不要追求一次性生成完美无缺的测试用例集。AI目前最适合的角色是“高级助手”或“灵感加速器”。它的价值在于快速产出初稿，覆盖你可能忽略的角落，提供新的测试视角。生成的用例必须经过测试工程师的评审、补充和修正后才能投入使用。将这个脚本看作是“测试用例脑暴会议”的催化剂，而不是替代测试工程师思考的“自动流水线”。抱着这个心态去使用和迭代它，你会收获更多，团队也更容易接受。