简介一份面向软件研发团队的质量保证计划QA计划文档适用于需要规范SQA流程的校园招聘系统或同类管理类项目。内容以CMMI Level 3和MLP 1.0为审核标准系统梳理了目的范围、方案维护、人员角色、审核标准、活动安排、度量方案等模块特别细化了QA代表在参与工程活动、评审测试活动、审核工作产品时的优先级与执行时机为质量管理人员提供了可落地的操作框架。资源整体为1个doc文件大小87KB属于可直接编辑的Word文档。已有563人学习浏览适合软件质量保证人员、项目经理及过程改进相关岗位参考。文档从原始数据、采集方法和采集方案三个层面给出了SQA度量方案覆盖SQA活动次数、问题跟踪、工作量及里程碑完成情况等关键指标同时明确各角色职责分工有助于团队快速建立符合CMMI要求的质量保证机制减少质量活动缺漏。1. 质量保证计划QA计划.doc从流程校准到评审投票一份文档的边界打开项目共享盘找到命名为“质量保证计划QA计划.doc”的文件多数人的第一反应是翻到最后一章确认有没有测试用例清单。对这个词的误读导致不少QA计划变成了一份躺在共享盘里没人翻的检查表。质量保证QA管的是过程质量控制的重点才是产品QA计划要回答的不是“测多少条”而是“凭什么能相信每个阶段的交付物可以继续往前走”。如果这份.doc通篇是流程名称和模板条款却没有定义质量目标、门禁和退出准则到评审会上它就撑不起任何一个结论。下面这条路径来自一线团队的习惯做法把这份文档当作一份受控文件来设计和维护从范围和角色写起用验证活动和度量指标去支撑门禁。适合正在起草质量保证计划的新人也适合想把手头那份几千字的QA计划改成评审依据的负责人。2. 拆模型一份可用的QA计划至少要有五块内容为什么不能只写测试用例2.1 QA与QC的边界决定了你的.doc该写什么质量保证计划最容易被写错的地方是以测试计划为主体。可以这样理解QAQuality Assurance的目标是建立过程标准并保证过程被遵守它偏“预防”QCQuality Control的目标是验证交付物是否达标它偏向“检测”。这二者的边界直接影响文档结构。如果一份QA计划里只写了测试范围、测试用例、缺陷等级那么评审时遇到“为什么这轮迭代严重缺陷率上升”这类问题文档给不出任何过程证据。因为测试用例不是用来佐证开发阶段是否做了自测和评审的。把QA和QC分开整份文档的推导关系就清楚了这份计划定义过程过程定义活动活动输出证据证据支持评审。测试只是其中的一类验证活动不是整份计划的骨架。2.2 QA计划的核心五块内容一份能直接用于评审的QA计划核心是五块内容范围与质量目标适用哪些项目、哪些阶段、每个阶段的质量目标是什么。角色与职责谁制定标准谁执行审计谁批准门禁。过程标准开发流程、代码评审规则、变更管理规则、发布规则。验证与审计活动评审、走查、测试、审计的活动类型和频率。度量与交付准则用哪些指标、什么阈值来判断可以进入下一阶段。这五块内容就是一份.doc的一级目录。如果新建的QA计划文档缺少其中一项评审时就会有一个环节悬空。下面这张表格把每块内容和文档中应出现的具体对象对应起来模块文档中应有的内容常见坑范围与目标项目名、版本号、阶段范围、可量化目标把范围写成整个部门评审时无法聚焦角色与职责责任人、审计人、批准人只写角色名没有实际人门禁无法追溯过程标准何时评审、哪些提交必须走检查照搬流程模板没有结合团队现状验证活动测试类型、审计频率、证据要求只列测试类型没有审计节奏度量与交付准则可量化的准出条件和计算公式使用“尽量”“及时”这类无法判定真假的词这五块不是并列填充的关系而是推导关系范围约束质量目标的取值质量目标决定验证活动的设计验证活动反过来支撑门禁的定义。写的时候按这个顺序填整份文档才有一条贯穿的主线。2.3 用一份文档骨架模板把结构固化常见做法是把QA计划做成可复用的文档骨架每开一个新项目只改参数而不是重写一遍。下面这份Markdown模板可以直接当作.doc的一级大纲来用也比在Word里反复复制整段文字容易维护# 质量保证计划QA计划 ## 1. 范围与质量目标 - 项目名称: - 适用阶段: (如迭代1~3或试点项目) - 质量目标: (按优先级列1~3条写可量化数值) ## 2. 角色与职责 | 角色 | 负责人 | 审计权限 | 批准权限 | |---|---|---|---| | 项目经理 | | | 门禁审批 | | QA | | 启动审计 | 审计报告 | ## 3. 过程标准 - 开发流程: 需求-设计-编码-测试-发布 - 代码评审: 至少一名非作者评审 (是否使用静态检查工具) - 变更管理: 变更必须关联缺陷单 ## 4. 验证与审计活动 - 审计点: 需求评审通过现场首轮功能测试前发布会前 - 测试类型: 单元测试/集成测试/系统测试/回归测试 - 频率: 每周功能审计里程碑走查 ## 5. 度量与交付准则 - 指标: 需求追溯率、缺陷逃逸率、回归通过率 - 准出条件: (待填量化)这段骨架里的每一项都不是装饰。项目名称和适用阶段直接决定质量目标该怎么取值“审计权限”和“批准权限”两列分开是为了保证门禁不是由执行人自己一个人签字。“测试类型”只写类型不写用例清单因为QA计划不应该详细到单个用例那是测试计划的事。如果后续评审人员对某一条产生分歧争论的就是表格里那个具体数值而不是“我觉得质量还行”这类观点。3. 从空白文档到评审通过编写QA计划的步骤、参数与批准流程3.1 先定范围再设置质量参数编写时最容易犯的顺序错误是一上来就写“缺陷密度不超过多少”。没有范围数值就没有语义。先对照项目章程、合同或SLA明确这份QA计划管辖的是什么。常见的写法是“仅覆盖迭代13”“仅覆盖交易链路相关模块”。范围不明确后面的指标口径也会跟着模糊。范围定完再逐项设置质量参数。我一般会把质量参数做成一张表在评审前和项目负责人逐行对齐避免评审现场再改。参数常见建议值设置理由需求追溯率核心需求100%保证每个需求都有对应的测试验证和结果记录严重缺陷逃逸率不高于5%超出该值说明测试阶段的拦截能力不足单元测试覆盖率核心组件不低于80%给重构和回归提供基础保护代码评审闭环率100%的PR必须评审防止“走过场式”的评审占满过程记录评审准备时间材料提前24小时发出当天发材料当天开会评不出有价值的内容这些值不能盲目抄。老系统和新建模块应该用不同的覆盖率要求新团队和成熟团队应有不同的缺陷密度基线。另外要特别提醒严重缺陷逃逸率算的是一个比例如果这个迭代总缺陷数只有20条一条线上缺陷就占了5%比例波动没有统计意义这时候要用“线上严重缺陷数不超过1条”这种绝对数值来替代。3.2 定义阶段门禁与进入/退出准则QA计划里最容易引起争议的就是“准入/准出”。要明确一点阶段门禁是一个判定集合集合内所有条件同时满足才算通过。实际项目中我一般按下面四个门禁来卡需求评审通过缺陷跟踪工具中需求相关问题清零。设计评审通过接口文档和安全设计说明已完成。测试准入开发自测通过静态检查阻断问题清零CI构建可用。发布门禁已知严重缺陷有明确规避方案关键路径回归全部通过遗留缺陷列表获得干系人认可。每个门禁项一定要指定证据来源。“自测通过”来自CI报告而不是开发在群里的口头答复“评审通过”来自评审记录中明确写出的结论和签字人。没有证据的门禁项审计时等于没有。3.3 用一段校验脚本避免带着空文档上评审会评审前最尴尬的事是文档缺了“度量准则”或“门禁”章节。下面这段Python脚本可以检查QA计划导出后的txt或Markdown文本是否包含关键模块适合在提交评审前跑一遍。#!/usr/bin/env python3 # 检查QA计划文本是否包含关键模块 # 用法python3 check_qap.py 质量保证计划.md import re import sys def main(path): with open(path, encodingutf-8) as f: text f.read() required [ 范围, 角色, 职责, 过程标准, 验证, 审计, 度量, 准出, 门禁 ] missing [kw for kw in required if kw not in text] if missing: print([失败] 缺失关键词, , .join(missing)) sys.exit(1) # 找到文档中的量化参数例如 100%、24小时、5% numbers re.findall(r\d\s*[%小时个项], text) if len(numbers) 3: print([警告] 可量化参数较少可能缺少度量标准) print([通过] 关键结构完整检测到, len(numbers), 个量化参数) if __name__ __main__: main(sys.argv[1])这段脚本的思路是两层校验第一层检查章节关键词是否存在确保文档结构没有缺项第二层用正则寻找文档里的量化描述例如“5%”“24小时”“3个”用来判断计划是不是只写了定性描述。要注意脚本只能校验“存在性”不能判断内容是否合理。如果有人把“门禁”写成了“门槛”脚本会漏判所以它只是一个评审前的提醒工具不能替代人工评审。3.4 评审、批准与归档文档骨架和参数都填完后最后一步是走评审和批准流程。建议按下面的顺序做提前两天把QA计划发给项目经理、测试负责人和交付负责人要求直接在文档上批注会前不评论默认没有异议。评审会上只过三个问题质量目标是否和合同或SLA一致门禁条件是否过松或过严度量指标和团队实际投入是否匹配。修改完成后由项目经理邮件确认或签字QA计划正式进入基线。提示门禁过严可以调整后重新评审但不要为了赶进度在评审当场打折放行。基线建立后每一次修改都要留变更记录否则这份.doc很快会和实际过程脱节。4. 让QA计划在团队里真正落地审计、度量报表和文档版本维护4.1 每一条QA计划条款都要能派生出可检查的任务QA计划如果只是被抄进一份.doc通常会变成“挂墙文件”和实际开发脱节。落地的方法是把计划里的条款拆成可执行、可核实的任务让人知道做完之后要留下什么证据。用表格来对照QA计划条款落地做法验收时看的证据代码评审闭环每个PR必须有至少一个非作者审批PR页面审批记录静态检查阻断清零CI管道中静态检查失败则阻止合并CI报告截图或链接缺陷严重度填写提交缺陷时必须选择严重度和优先级缺陷管理工具中字段填写率抽查表格里核心的逻辑是每条规则必须对应一个“客观可查的证据”。例如“闭环”不是靠自觉而是在合并前检查是否真的有一次批准。QA抽查的时候不看团队汇报直接看系统和CI记录证据链完整才算这条执行有效。4.2 阶段审计按迭代节奏触发做审计不一定要等里程碑按迭代节奏安排三个时点比较合适迭代启动时QA做过程理解度审计确认每个角色对自己涉及的那几条规则理解一致。迭代中期QA抽检交付物证据比如抽查10个PR、10个缺陷单、5份评审记录确认流程真实发生。迭代结束时QA用计划偏差记录做简短复盘把新增偏差列入下一迭代改进项。审计时不要抓着一次缺失就定性。抽样比例要写清楚结论里明确“抽查10个中发现2个不合规”这样团队会把精力放在改进流程上而不是想办法规避检查。4.3 用SQL统计缺陷逃逸率给审计一个硬指标审计要基于数据。下面这段SQL可以从缺陷管理表中统计当前迭代的缺陷逃逸率Defect Escape RateDRE用于衡量测试阶段的拦截能力。-- DRE统计线上缺陷数 / 已发现缺陷总数 -- 分母包含线上逃逸的缺陷才是真正的逃逸率 SELECT SUM(CASE WHEN found_stage production THEN 1 ELSE 0 END) AS escaped_num, SUM(CASE WHEN found_stage IN (test, smoke, review) THEN 1 ELSE 0 END) AS caught_num, ROUND( 100.0 * SUM(CASE WHEN found_stage production THEN 1 ELSE 0 END) / NULLIF(SUM(1), 0), 2 ) AS escape_rate FROM defect WHERE iteration_id 2025-3 AND defect_status duplicate;这段SQL的要点有两个分子是发现阶段为production的缺陷分母是迭代内所有有效缺陷而不是只统计测试发现的缺陷。这样计算出的逃逸率才反映“测试漏掉了多少”而不是“占了多少”。NULLIF(SUM(1), 0)用来防止迭代刚开始时没有缺陷导致的除零错误。如果只把一个迭代的逃逸率作为结论偶然性很大应该按周滚动观察趋势当连续两周上升时再拉响预警。4.4 受控文件版本维护与变更记录QA计划进入基线后要按受控文件来维护。每次修订都要保留历史版本并在变更记录中写明变更原因和影响模块。下面是一个简化版的变更记录表版本变更时间变更内容影响模块批准人V1.03月1日首次发布全部项目经理V1.13月15日新增静态检查阻断门禁第3章/第4章项目经理产生变更的原因一般是过程证据暴露了某个门禁不合理而不是文档模板本身要调整。只改版本号不写变更原因是版本管理里最没价值的行为。QA计划真正发生变化时应该触发一次通知让所有关联角色知道规则变了。4.5 常见误用把QA计划写成测试计划团队最容易犯的问题就是QA计划里塞满了测试用例却在过程审计上是空白。这三个文档的职责不同用一张表区分文档要解决的问题维护频率主要读者QA计划流程是否有有效证据里程碑/季度项目组、QA、管理层测试计划这次测什么、怎么测每个迭代测试团队、开发测试用例具体的输入输出和预期持续更新测试执行者如果一份.doc里全是测试用例先把用例剪出来放到测试计划或用例库。QA计划里只需要保留对测试活动“何时做、由谁做、如何评价”的描述不需要写具体的测试步骤和预期结果。这样文档的篇幅会大幅缩短评审时反而更容易被读完。5. 一个进阶技巧用“计划偏离率”量化QA计划本身的质量5.1 把偏离率拆到过程门禁上QA计划经常定义大量规则但很少有团队反过头来量化“规则本身有没有被遵守”。与其在迭代总结时用一句“过程基本正常”带过不如先算一个计划偏离率计划偏离率 (计划审计项总数 - 按标准按时完成的审计项数) / 计划审计项总数 × 100%公式里的“计划审计项”不是随便挑的可以从QA计划第4章的审计频率和门禁项中统计。比如这个迭代定义了20个检查项实际18项按标准按时完成1项延期1项完成但没有满足参与人要求后两项都算未按标准完成。偏离率就是(20-18)/2010%。计算时要注意延后和有瑕疵的执行都要算作未按标准完成否则大家都会把“做了”当成“做合规了”偏离率就失去了意义。这张表是把后续的检查数据收集起来的示例按周维护月底汇总检查项计划时点实际情况是否按标准完成需求评审第1周周三周四完成评审人齐否测试准入自测检查第2周周一按时自测报告缺失否静态检查阻断清零第2周周四按时CI报告0阻断是比单一偏离率更有用的做法是把检查项按过程门禁分类分别统计“评审类偏离率”“测试类偏离率”“变更类偏离率”。如果连续两个迭代评审类偏离率都在20%以上而测试类只有5%问题大概率出在评审排期或材料准备时间上而不是团队不配合。按这个维度拆开之后QA计划下一次修订就有了数据支撑是减轻评审频率还是把评审材料提前到48小时发出决策不再靠感觉。我一般会设定一个阈值当总偏离率连续两个迭代超过15%时下一迭代不增加新条款而是先删掉那些无法执行或相互冲突的规则。执行率低往往说明规则本身和当前团队节奏不匹配而不是团队态度有问题。把偏离率放进QA月报的第一张图它会比覆盖率这类指标更早暴露流程健康度。当计划本身能被度量时那份质量保证计划QA计划.doc才真正从静态文档变成了项目过程的校准器。本文还有配套的精品资源点击获取