1. 项目概述当测试工程师遇上AI最近和几个测试团队的朋友聊天大家不约而同地提到了同一个痛点写测试用例尤其是那些功能点繁杂、边界条件众多的模块实在是太耗费时间和精力了。一个需求下来光是把所有正向、反向、异常场景的测试用例梳理成文档可能就要花掉一两天。更头疼的是这种重复性高、逻辑性强的工作还特别容易因为人的疲劳或疏忽导致遗漏。我自己也深有体会曾经就因为在设计一个文件上传功能的测试用例时漏掉了某个特定文件格式与大小组合的边界情况导致线上出了个小问题。就在这种背景下“AI测试用例生成”这个概念开始频繁出现在我们的视野里。简单来说它就是利用人工智能技术特别是大语言模型LLM来辅助甚至自动化地生成软件测试用例。这听起来有点像让AI来当我们的“测试用例设计助理”。它不再是遥不可及的未来科技而是随着像GPT、文心一言、通义千问这类模型的成熟和API的开放变得触手可及。我们不再需要从头训练一个AI而是可以基于现有的大模型通过“提示词工程”和脚本封装打造一个属于自己团队的高效工具。所以这个“AI测试用例生成脚本”项目本质上就是一个桥梁。它的一端连接着强大的、具备通用理解能力的AI大模型另一端则对准了我们测试工作中最耗时、最需要规范化的环节。这个脚本的核心任务是接收我们输入的、相对自然的需求描述比如产品需求文档片段、用户故事、接口定义然后通过精心设计的提示词与AI交互输出结构清晰、覆盖度良好的测试用例格式可能是Excel、思维导图或者直接是团队在用的测试管理工具如TestLink、Jira的导入格式。它适合谁呢首先肯定是广大的一线测试工程师和测试开发工程师能直接将我们从繁重的文档工作中解放出来把精力更多投入到探索性测试、性能测试等更有创造性的工作中。其次对于研发团队负责人或项目经理这意味着测试用例的设计效率和质量可以得到基线保障加速测试左移的进程。甚至对于产品经理也可以用它来快速验证需求描述的完整性和可测试性。2. 脚本核心设计思路与方案选型当我们决定动手做一个AI测试用例生成脚本时第一个要回答的问题就是我们到底要做一个什么样的工具是把所有东西都包揽的“重型平台”还是一个轻量、灵活、即插即用的“脚本工具”我个人的倾向非常明确先从脚本工具做起。原因很简单重型平台开发周期长试错成本高而且容易与团队现有流程产生排异反应。一个脚本用Python或Node.js写几百行代码能快速验证想法快速迭代并且能无缝嵌入到现有的CI/CD流水线或本地工作流中这才是工程师喜欢的方式。2.1 核心流程拆解整个脚本的工作流可以抽象为以下几个核心环节我把它画成了一个简单的线性流程方便理解输入处理脚本需要能接收多种格式的输入。最理想的是直接读取产品需求文档PRD的某个章节、接口的Swagger/OpenAPI定义文件或者至少是一段结构清晰的Markdown格式的需求描述。如果输入非常原始可能还需要一个简单的“需求解析与澄清”模块但这会增加复杂度初期可以要求输入相对规范。提示词工程这是整个脚本的灵魂所在。我们不能简单地把需求文本扔给AI说“生成测试用例”那得到的结果会非常随机且不可用。必须构建一个结构化的“提示词模板”。这个模板通常包含角色定义明确告诉AI它现在是一名资深测试专家。任务指令清晰说明需要基于给定的需求生成测试用例。输出格式规范必须严格要求AI以指定的格式输出例如“请以JSON格式输出包含字段test_case_id,test_objective,preconditions,test_steps,expected_result,test_type(功能/界面/兼容性/安全等),priority(P0/P1/P2)”。示例提供一两个高质量的例子让AI学会我们想要的风格和细致程度。约束条件比如“请重点考虑边界值分析和异常流”“每个正常流场景至少配套设计两个异常流场景”。调用AI模型API将组装好的提示词通过HTTP请求发送给选定的AI模型服务如OpenAI的ChatGPT API、国内的通义千问API、文心一言API等并获取返回的文本结果。结果解析与后处理AI返回的通常是文本我们需要将其解析成结构化的数据如Python字典、列表。这里要处理AI可能的不合规输出比如格式错误、多余的解释文字等需要编写健壮的解析逻辑。输出格式化将结构化的测试用例数据转换成最终用户需要的格式。常见的有Excel (.xlsx)利用pandas或openpyxl库生成可以分Sheet组织模块这是最通用、最易分享的格式。CSV (.csv)轻量易于版本管理和diff。Markdown (.md)便于直接插入项目Wiki或Confluence。测试管理工具导入格式如生成Jira的CSV导入模板或直接调用TestLink的XML-RPC API进行创建。错误处理与日志整个流程必须有完善的异常捕获和日志记录。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调用APIpython-dotenv管理配置pandas和openpyxl输出Excel。pip install requests python-dotenv pandas openpyxl然后我们需要获取AI模型的API访问凭证。以阿里云通义千问为例你需要登录阿里云官网开通灵积模型服务。在控制台创建API KeyAccessKey ID和Secret。记下你的API Key我们稍后会用到。在项目根目录下创建一个.env文件注意文件名开头的点用于存放敏感配置。切记要将.env添加到.gitignore中避免密钥泄露。# .env 文件内容 DASHSCOPE_API_KEY你的API_Key MODEL_NAMEqwen-max # 模型名称如 qwen-max, qwen-plus API_BASE_URLhttps://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: fBearer {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, headersheaders, jsondata, timeout30) response.raise_for_status() # 如果状态码不是200抛出异常 result response.json() # 提取AI返回的消息内容 content result[choices][0][message][content] return content except requests.exceptions.RequestException as e: print(fAPI请求失败: {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 rjson\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:end1] 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(fJSON解析失败: {e}) print(f尝试解析的字符串: {json_str[:200]}...) return None staticmethod def save_to_excel(test_cases_list, filenamegenerated_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, engineopenpyxl) as writer: df.to_excel(writer, indexFalse, 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代码解读与心得健壮的解析AI的输出可能不会100%听话有时会在JSON外面包裹Markdown代码块标记有时会多几句解释。这里用了正则表达式和字符串查找两种方式尝试提取JSON提高了容错率。数据处理使用pandas.DataFrame是处理表格数据的利器。我们可以轻松地调整列顺序、过滤数据。用户体验自动调整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生成的内容质量波动是最大的挑战。除了优化基础提示词还有以下方法可以尝试分步骤生成不要指望一个提示词解决所有问题。可以设计两阶段甚至三阶段生成。第一阶段生成测试点。提示AI“请根据以下需求列出所有需要测试的功能点、输入域和边界条件。” 得到一个结构化的测试点大纲。第二阶段基于测试点生成用例。将测试点大纲作为新的输入提示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的同时生成对应的SeleniumPython或CypressJavaScript的代码片段。虽然不能直接用于生产但能为自动化测试工程师提供极有价值的参考和起点。配置化与模板化将提示词模板、输出格式模板、领域规则等都抽离成配置文件如config.yaml。这样测试不同项目如Web前端、移动端、后端API时只需切换配置文件而无需修改代码。为不同的测试类型功能、性能、安全、兼容性设计不同的提示词模板。4.3 常见问题与排查技巧实录在实际操作中你肯定会遇到各种各样的问题。下面是我遇到的一些典型情况及其解决方法问题现象可能原因排查与解决思路AI返回内容为空或超时1. API Key无效或过期。2. 网络连接问题。3. 请求内容过长或模型负载高。1. 检查.env文件中的Key是否正确并在对应平台验证其状态和余额。2. 使用curl或postman直接测试API端点排除脚本问题。3. 简化提示词减少max_tokens参数重试。返回内容不是合法的JSON1. 提示词中对输出格式的约束不够强。2. AI“自由发挥”添加了额外解释。3.temperature参数过高导致输出随机性大。1.强化格式指令使用“必须”、“严格遵循”、“只输出JSON不要有任何其他文字”等强约束词。用json代码块包裹示例。2. 在解析逻辑中加强文本清洗如上述代码中的正则匹配。3.降低temperature尝试设置为0.1或0.2。生成的测试用例肤浅缺乏边界和异常场景提示词过于笼统没有明确要求覆盖边界和异常。在提示词中明确列出要求“请务必使用等价类划分和边界值分析方法为每个输入字段设计有效等价类、无效等价类和边界值的测试用例。” “请为每个正常流程设计至少两个异常流程测试用例。”用例步骤描述过于笼统如“输入数据”AI缺乏对具体界面的认知。在需求描述中提供更具体的界面信息或在提示词中要求“测试步骤应具体到UI元素例如‘在标有‘用户名’的文本输入框中输入xxx’”。脚本运行一次后再次运行生成内容雷同AI模型具有记忆性或提示词/输入完全一致。1. 这是正常现象在temperature较低时相同输入产生相似输出的概率很高。2. 如果需要多样性可以稍微提高temperature(如0.5)或在提示词中要求“从不同测试角度思考”。3. 更有效的方法是改变输入让人工先对需求描述进行微调或补充再生成。一个关键的实操心得不要追求一次性生成完美无缺的测试用例集。AI目前最适合的角色是“高级助手”或“灵感加速器”。它的价值在于快速产出初稿覆盖你可能忽略的角落提供新的测试视角。生成的用例必须经过测试工程师的评审、补充和修正后才能投入使用。将这个脚本看作是“测试用例脑暴会议”的催化剂而不是替代测试工程师思考的“自动流水线”。抱着这个心态去使用和迭代它你会收获更多团队也更容易接受。