简介这份资源是面向软件测试人员、质量管理人员及软件开发团队的一份通用型《软件产品测试计划书》PDF文档依照ISO9000质量管理体系认证要求编写以「XXXX分析软件」为样例帮助读者建立起符合规范、可直接套用的测试计划框架。全包共1个文件为127KB的PDF格式体积轻巧便于随项目文档一并归档、传阅与打印。目前已有200人学习下载。文档内容覆盖测试全生命周期从引言中的目的、项目背景、名词定义与参考资料到文档测试与系统测试的任务要求从测试环境搭建Windows XP、JDK6Eclipse、QuickTest Professional、Quality Center到测试组织分工、时间安排与流程规范再延伸至进度跟踪、系统风险与优先级、问题严重度描述以及与测试相关的任务划分。其中对文档完整性、一致性、易理解性与操作实例的检查维度以及功能测试、界面测试、安装部署测试的流程与开始、完成标准均有较细展开可作为编写《测试用例》《测试问题报告》的基础参考适合需要补齐测试文档规范的中初级测试从业者收藏研读。1. 软件产品测试计划书为什么必须先过 ISO9000 这套逻辑审核老师翻到测试计划书那一页问的往往不是你测了多少轮而是这份计划谁编的、谁批的、依据哪一版需求、改过之后旧版本去哪了。很多团队测试执行并不差栽就栽在测试计划书只是一份躺在共享盘里的 Word没有编号、没有版本、没有评审记录在 ISO9000 质量管理体系认证里这属于典型的成文信息失控。ISO9000 认证真正盯的是过程可以自证而软件产品测试计划书恰好是设计开发验证环节最关键的证据载体。它把测试目标、范围、环境、准入准出准则、进度、风险、职责一次性写清楚后面的用例、缺陷、测试报告都挂到它上面形成证据链。这份通用测试计划书适合三类人正在准备初次认证或年度监督审核的研发质量负责人需要向客户交付受控文档的项目经理以及被临时抓来写测试计划的测试工程师。难点从来不在写出来而在写完之后怎么保证它一直有效、一直是最新版本。2. ISO9000 条款到测试计划书章节的映射与通用模板骨架2.1 把成文信息、设计验证、放行三类条款翻译成文档要求写测试计划书之前先做一件事把标准里那几句抽象的话翻译成审核现场能拿出来的东西。常见的做法是拿一张对照表左边写条款关注点右边写我要在计划书的第几节提供什么。审核员不会逐条念标准他只会问这个要求在你文档的哪里体现证据是什么。标准关注点审核员实际要看的测试计划书对应位置客观证据成文信息控制唯一编号、版本、批准人、发放范围封面、文档信息表受控文件清单、发放回收记录设计开发验证验证活动有计划并按计划执行测试策略、测试类型、进度计划批准记录、执行记录外部提供过程第三方测试、商用工具合规测试环境与工具、外包说明供方评价记录、工具授权生产和服务提供未达准则不放行准入准出准则、缺陷等级定义测试报告、放行审批单监视和测量资源环境与工具受控、可追溯环境配置表、工具版本环境搭建与变更记录不合格输出控制缺陷闭环缺陷管理流程与等级缺陷台账、回归记录改进问题有纠正措施风险与改进项不符合项跟踪表注意条款编号以企业受控的标准文本和体系文件为准不要拿网传的iso9000最新版本发布时间当依据以受控清单里标了现行有效的那一版为准。2.2 通用测试计划书的最小章节骨架与必填字段通用模板的价值在于换个项目也能用所以骨架要稳定变量要少而全。我一般把正文固定成 11 节目的与范围、引用文件、术语与缩略语、测试对象与版本基线、测试策略与测试类型、测试环境与工具、准入准出准则、进度与资源、风险与应对、交付物与记录、职责与批准。前十节是内容最后一节是授权。比正文更重要的是封面和文档信息表的字段这些字段决定了这份文档在体系里能不能被检索、被追溯、被作废。字段示例是否必填用途文档编号QMS-TP-PAY-2024007是受控清单的唯一索引版本号V1.2是修订追溯文档状态已批准是防止误用旧版产品/项目名称支付网关 V3是与项目计划对齐需求基线SRS-PAY-V3.0是追溯链起点测试环境SIT-01是结果可复现准入准则冒烟通过率 100%是启动判据准出准则P1/P2 清零是放行判据编制/评审/批准张三/评审组/李四是职责与授权生效日期2024-06-01是版本有效期准入准出这两栏是最容易被写成废话的地方。测试通过后进入下一阶段这种句子在审核时等于没写。合格的写法是带数字的冒烟用例通过率 100%、代码冻结标签 build-3.7.2、P1 与 P2 缺陷清零、P3 遗留不超过 5 个且有规避方案、性能指标 P95 响应时间不超过 800ms。2.3 文档编号、版本号与受控状态的命名规则编号规则要在体系文件里定死不然三份文档三种写法清单就对不上。常见结构是体系前缀-文档类型-产品代号-年份序号-版本例如 QMS-TP-PAY-2024007-V1.2。年份序号保证唯一版本号分两级大版本 V1.0、V2.0 用于基线变更小版本 V1.1、V1.2 用于文字澄清和细节补充。状态机只有四个值草稿、评审中、已批准、已作废。这四个值直接决定文档能不能发出去建议写进文档元数据里用脚本卡住而不是靠人记。--- doc_no: QMS-TP-PAY-2024007 # 唯一编号受控清单以此为主键 title: 支付网关 V3 软件产品测试计划书 version: V1.2 # V1.x 小改V2.0 基线变更 status: 已批准 # 草稿 / 评审中 / 已批准 / 已作废 product: 支付网关 V3 srs_baseline: SRS-PAY-V3.0 # 需求基线追溯链起点 author: 张三 reviewer: 测试评审组 approver: 李四 effect_date: 2024-06-01 supersedes: QMS-TP-PAY-2024007-V1.1 # 被本版替代的旧版本 ---这套元数据的顺序不要随便动后面第 5 章的校验脚本会按 key 逐行匹配顺序乱了脚本照样能跑但人工 diff 会很难受。2.4 需求基线与引用文件的一致性核对最常见的不符合项不是测试计划写得不细而是它引用的需求版本和系统里在跑的需求版本对不上。计划书里写 SRS-PAY-V2.3配置管理库里最新基线已经是 V3.0两份文件各说各话审核时就是文件与记录不一致。核对动作很简单但必须留痕把计划书里的需求基线号与配置管理库中该产品的最新基线号做一次比对结果写进评审记录。如果确实基于旧基线就在计划书里说明原因和影响范围例如本次仅回归 V2.3 遗留缺陷不涉及 V3.0 新增模块。引用文件一节建议只列三类上游输入需求规格说明书、项目计划、体系依据质量手册、测试管理程序、下游输出测试用例集、测试报告模板。列多了容易失效列少了追溯链断裂三类刚好够用。3. 测试计划书参数化生成与受控 PDF 输出3.1 Markdown 模板加变量表的最小可复现流程通用模板最大的浪费是每次复制粘贴再手改改漏一处就出现版本内不一致。我一般把正文写成 Markdown 模板把可变部分抽成变量用一段脚本渲染输出 Markdown 再转 PDF。这样一份计划书的产出时间从两小时压到两分钟而且不会漏字段。# gen_test_plan.py # 渲染通用测试计划书模板输出 Markdown再交给 pandoc 转受控 PDF import datetime from pathlib import Path from string import Template # 模板中变量写成 $doc_no 形式正文骨架固定不变 tpl Path(templates/test_plan.md.tpl).read_text(encodingutf-8) ctx { doc_no: QMS-TP-PAY-2024007, # 唯一编号与受控清单一致 version: V1.2, # 小改递增基线变更升大版本 status: 已批准, # 只有已批准才允许发布 project: 支付网关 V3, srs_baseline: SRS-PAY-V3.0, # 需求基线务必与配置库一致 env: SIT-01 / MySQL 8 / JDK 17, entry: 冒烟用例通过率 100%代码冻结标签 build-3.7.2, exit: P1、P2 缺陷清零P3 遗留不超过 5 个且有规避方案, author: 张三, reviewer: 测试评审组, approver: 李四, effect_date: datetime.date.today().isoformat(), } # safe_substitute 遇到未定义变量不会抛异常方便模板里保留待补占位 out Template(tpl).safe_substitute(ctx) Path(out/test_plan.md).write_text(out, encodingutf-8) print(生成完成:, ctx[doc_no], ctx[version])这段脚本里doc_no、version、status三个参数决定文档在体系里的身份不允许在模板正文里硬编码。entry和exit是字符串但内容必须可量化脚本不做语法校验所以第 5 章的检查脚本里专门加了一条命中规则这两个值里如果出现中文句号后的形容词堆砌而没有数字人工评审时一律打回。effect_date用当天日期最省事但正式发布时应改成批准日期。3.2 必调参数范围、环境、准入准出与缺陷等级模板里的默认值不能直接上线有几个参数必须每个项目重新定。参数默认值调整依据写错的后果测试范围全模块本次变更影响分析范围写大了做不完写小了漏测测试类型功能回归需求中的非功能指标性能安全无证据环境配置单机部署与生产拓扑的差异度缺陷在生产复现不了准入准则冒烟通过率 100%提测质量历史数据带病提测返工率高准出准则P1/P2 清零产品线风险容忍度放行无判据审核开不符合缺陷等级P1~P4与缺陷管理工具对齐等级口径不一致统计失真缺陷等级的口径要和缺陷管理工具里的字段完全一致否则测试计划里写 P1工具里只有严重/一般统计报表对不上审核时解释成本极高。范围那一条建议写包含和不包含两个清单明确排除项比明确包含项更能体现变更影响分析做过。3.3 转受控 PDF 的三条命令与页码字体设置Markdown 定稿后要出受控 PDF归档只放 PDF 只读版本这是体系里最省事的做法源文件留在受控库里可改PDF 用于发放、评审和归档。三条常见路径按场景选。# 方式一pandoc xelatex中文字体必须显式指定否则 PDF 里中文变方框 pandoc out/test_plan.md \ -o out/QMS-TP-PAY-2024007_V1.2.pdf \ --pdf-enginexelatex \ -V CJKmainfontNoto Sans CJK SC \ -V geometry:margin2.2cm \ -V fontsize11pt \ --toc --toc-depth3 \ --metadata title支付网关 V3 软件产品测试计划书 # 方式二已有 Word 模板、要保留页眉页脚和公司封面时走 LibreOffice 无头转换 soffice --headless --convert-to pdf --outdir out out/test_plan.docx # 方式三正文由 web 页面渲染时走无头浏览器的网页 pdf 打印链路 chrome --headless --disable-gpu --print-to-pdfout/plan.pdf out/test_plan.htmlCJKmainfont是最容易踩的坑字体名写错不报错直接输出方框字。geometry:margin建议不小于 2cm留出装订和签章位置。方式三生成的文件默认没有页码需要在页脚模板里用pageNumber和totalPages补上否则打印出来几十页无法引用第几页第几节。3.4 修订后重新出受控版本版本对照与作废处理每次改版都要留一张版本对照表写清改了哪一节、为什么改、影响了哪些下游文档。评审时只对差异部分评审效率高很多审核时这张表就是变更受控的直接证据。版本日期变更章节变更原因影响的下游文档V1.02024-05-08全文首次发布用例集 V1.0V1.12024-05-207.2 准出准则评审意见补充性能指标测试报告模板 V1.1V1.22024-06-016.1 环境配置环境扩容节点数变更环境搭建记录旧版本不要删标记为已作废后归档到独立目录发放记录里注明回收情况。评审阶段如果需要批注把 PDF 转 Word 交给评审人写批注批注处理完只把最终 PDF 入受控库不要用 pdf 编辑器直接在归档件上改字加签章那样归档件的哈希就对不上了。4. 测试过程留痕追溯矩阵、评审签署与变更控制4.1 需求-用例-缺陷追溯矩阵的 SQL 落地方案测试计划书只写了要测什么测到了没有要靠追溯矩阵回答。矩阵不需要专门的工具三张表加两条 SQL 就能跑起来数据源直接来自需求管理库和缺陷库。-- 追溯矩阵三张基础表字段名与既有工具保持一致避免二次清洗 CREATE TABLE req ( req_id VARCHAR(32) PRIMARY KEY, -- 需求编号与 SRS 完全一致 title VARCHAR(200) NOT NULL, baseline VARCHAR(32) NOT NULL, -- 需求基线版本 priority VARCHAR(4) NOT NULL -- P1~P4 ); CREATE TABLE testcase ( case_id VARCHAR(32) PRIMARY KEY, req_id VARCHAR(32) NOT NULL, -- 用例挂在需求上一个需求可多条 plan_no VARCHAR(32) NOT NULL, -- 对应测试计划书编号 type VARCHAR(16), -- 功能/性能/兼容/安全 FOREIGN KEY (req_id) REFERENCES req(req_id) ); CREATE TABLE defect ( bug_id VARCHAR(32) PRIMARY KEY, case_id VARCHAR(32), -- 执行哪条用例发现的 severity VARCHAR(4) NOT NULL, -- P1~P4口径与计划书一致 status VARCHAR(16) NOT NULL, -- 新建/修复中/已关闭/已拒绝 found_at DATE NOT NULL, FOREIGN KEY (case_id) REFERENCES testcase(case_id) );-- 准出前的风险清单无用例覆盖的需求或高等级缺陷未闭环的需求 SELECT r.req_id, r.title, r.priority, COUNT(DISTINCT c.case_id) AS case_cnt, SUM(CASE WHEN d.severity IN (P1,P2) AND d.status 已关闭 THEN 1 ELSE 0 END) AS open_high_bug FROM req r LEFT JOIN testcase c ON c.req_id r.req_id AND c.plan_no QMS-TP-PAY-2024007 LEFT JOIN defect d ON d.case_id c.case_id WHERE r.baseline SRS-PAY-V3.0 GROUP BY r.req_id, r.title, r.priority HAVING COUNT(DISTINCT c.case_id) 0 OR SUM(CASE WHEN d.severity IN (P1,P2) AND d.status 已关闭 THEN 1 ELSE 0 END) 0 ORDER BY r.priority;第二条语句的plan_no是关键过滤条件它把矩阵锁定在这一版测试计划的范围内避免历史用例把覆盖率刷虚。HAVING里两个条件用OR连接输出的是没覆盖和覆盖了但高等级缺陷没关两类需求正好就是准出评审要看的清单。如果这条查询在预期时间返不回结果说明需求编号在需求库和用例库之间没有统一先修数据再谈覆盖率。4.2 评审记录与批准签署怎么写才算客观证据评审记录常见的问题是只写已评审通过。这种记录在审核现场几乎无效因为它回答不了谁评的、评了什么、提出什么、怎么处理。一份能用的评审记录至少包含四块评审对象与版本、参与人及角色、逐条意见与处理结论、结论与签署。检查项合格表现典型缺陷评审对象明确到文档编号与版本只写测试计划参与人列出姓名、角色、所属部门只写测试组意见闭环每条意见有问题描述处理结果只写已修改结论通过/有条件通过/不通过无结论签署手签或电子签带日期打印体姓名无日期有条件通过的场景要特别处理把条件写进记录并约定复评时间点复评记录单独留档。电子签要能追溯到账号和时间戳单纯的打印体姓名不具备签署效力。4.3 变更控制测试计划改版的触发条件与影响分析计划书不是写完就冻结改是正常的不改反而不正常。关键是定义清楚什么情况下必须改版。触发条件我一般列四条需求基线升级、测试范围增减、准出准则调整、测试环境发生拓扑级变化。前三条升大版本第四条升小版本并同步更新环境搭建记录。变更影响分析要回答三个问题哪些章节要改、哪些下游文档要跟着改、已执行的用例和已发现的缺陷还算不算数。第三点最容易被忽略——准出准则收紧以后之前按旧准则判定通过的那些模块是否需要补测这个结论必须写进变更记录否则就是改了文档没改执行。4.4 准入准出判定与测试报告的衔接测试报告是测试计划的执行结果两份文档的章节顺序最好对齐审核员顺着看下来不用来回翻。准入判定留准入检查表准出判定留准出检查表每一条准则后面写实测值而不是打勾。举个具体的准出准则写P1、P2 缺陷清零准出检查表里就要写截至 2024-06-10P1 未关闭 0 个P2 未关闭 0 个P3 未关闭 4 个均已登记规避方案。带日期的快照值是关键它把当时的状态固定下来否则事后无法复现判定依据。5. 内审外审前的自检用脚本扫一遍测试计划书的符合性审前一两天再靠人肉翻文档基本必漏。把可判定的规则写成脚本跑一遍就能把八成低级问题挡在会议室门外。# 扫描受控测试计划书目录检查元数据字段与状态合规性 for f in docs/test-plan/*.md; do echo $f # 必填字段逐项检查缺一个就打印出来 for key in doc_no version status srs_baseline entry exit approver effect_date supersedes; do grep -q ^${key}: $f || echo 缺失字段: $key done # 草稿版不允许出现在受控发布目录这是最常见的一类不符合 grep -q ^status: 草稿 $f echo 警告: 草稿版混入受控目录 # 准入准出准则必须含数字纯形容词视为未量化 grep -E ^(entry|exit): $f | grep -qv [0-9] echo 警告: 准入准出准则未量化 done # 归档 PDF 的可检索性检查审核时要能全文搜索 for p in docs/test-plan/*.pdf; do n$(pdftotext -layout $p - | tr -d [:space:] | wc -c) [ $n -lt 500 ] echo 警告: $p 文本层过薄可能是纯图片扫描件 done脚本里supersedes字段容易被漏它的作用是标出被本版替代的旧版本缺了这个字段受控清单里就会同时出现两个有效版本。第二条循环里的pdftotext检查很有用有些团队扫描签章后回填 PDF输出的是图片页全文检索搜不到任何正文审核时想快速定位第 7.2 节准出准则就得一页页翻体验和效率都会受影响。常见不符合项触发原因快速修法版本与受控清单不一致改版后未更新清单以清单为准回填元数据引用需求基线过期需求升级未同步更新 srs_baseline 并写变更记录审批人无授权代签、越权签对照岗位授权表重签准出准则不可测量写成定性描述改成带数值的判据评审记录无闭环只写已修改补意见条目与处理结果归档件为扫描图片签章后转图保留文本层或补 OCR 文本自检跑完还有一件事把条件为有条件通过的历史评审记录捞出来确认复评已经完成。这类记录在时间线上最容易被遗忘而审核员恰恰喜欢沿着时间线追。把上面这段脚本挂到发布流水线的前置检查里草稿版和未量化准则就再也进不了受控目录剩下的时间可以留给真正需要人来判断的追溯逻辑。本文还有配套的精品资源点击获取