简介面向新成立测试部门的规划文档旨在解决测试流程不规范、文档不健全、测试文档缺乏管控、人员多为新人等常见问题。内容从团队建设切入详细说明测试经理、配置管理员、测试组负责人、性能测试工程师、功能测试工程师的岗位职责与技能要求并针对团队规模给出配置管理与性能测试工作的过渡安排。同时系统梳理了项目整体测试流程、各阶段测试分工单元、集成、确认、回归、验收、测试环境搭建、文档输出模板、缺陷追踪机制以及基于TestDirector、LoadRunner、SVN等工具的配套使用方法还覆盖了技能与业务培训计划、部门考评机制并附有测试现状诊断与改进建议可作为测试部门建立初期的完整操作指南与后续优化蓝本。资源包为单个doc文档大小149KB内容可直接用于内部培训或制度修订参考。该文档已有2078人学习适合新任测试主管、质量负责人以及需要从零搭建测试团队的管理者能够帮助快速构建规范化测试管理体系也有助于测试人员快速理解岗位职责与协作方式。1. 测试部门规划新团队想清楚这五件事再动手新成立测试部最常见的开局领导催着出活成员全是行业新人测试流程根本没有。文档无模板、用例无评审、提测无版本号几轮救火之后才意识到问题不在测试人员不够拼而在测试部门规划没做好。本文要拆的是一份来自某公司测试组从无到有的梳理文档它把岗位职能、测试流程、文档规范、日常项目、部门考核五件事拆成了可抄作业的条目连“配置管理员暂时不设、性能测试全员打底”这种过渡方案也写清楚了。适合刚接手测试团队的负责人搭框架也适合老团队拿来做制度盘点。先立结构再谈工具是这份文档最值得借鉴的地方。2. 团队岗位与技能矩阵五岗位设计怎么落到三岗位起步新测试部门最容易犯的错是岗位设计照搬大厂结果招不来人、养不起人、没人带。这份规划的处理顺序很值得学先按质量管理流程拆出完整岗位再按现状压缩最后用技能分级把空缺补上。2.1 五类岗位职能拆解每个岗位对应什么输出规划文档把测试部分成五类岗位测试部门经理、配置管理员、测试组负责人、性能测试工程师、功能测试工程师。我的判断标准很简单一个岗位如果说不清楚输出什么文档这个岗位就是虚的。岗位核心职责输出文档测试部门经理部门发展规划、资源协调、组织技能与业务培训、指导职业发展部门发展计划、培训计划配置管理员代码版本与文档版本控制、变更控制配置管理计划、配置审计报告测试组负责人测试环境搭建、bug 管理库维护、任务分派、跨部门沟通测试计划、测试报告、部分测试用例性能测试工程师性能测试设计与执行、系统瓶颈分析性能测试计划、性能测试用例、性能测试报告功能测试工程师功能与流程测试、提交缺陷到 bug 库功能测试用例、功能测试报告注意配置管理员管的不只是代码版本还包括文档版本和相关变更控制。很多新团队只让测试组在 SVN 里开几个文件夹没有明确的变更流程配置管理计划也没人写后面文档被覆盖、误改、丢失全都变成扯皮。配置审计报告尤其容易被忽略它回答的问题是当前这个版本到底能不能发布文档和代码是否一致。2.2 新部门初始定位三岗位起步配置与性能工作怎么分摊规划给出的过渡方案很务实目前只设测试部门经理、测试组负责人、功能测试工程师三个岗位。配置管理员不单设工作方式是“与项目人员沟通配备专人参与要求测试人员从中学习”性能测试工作由测试团队人员共同来做必要时测试经理参与。这个折中的逻辑是配置管理日常量少但关键时刻重要独立岗位容易变成“闲着”不如借项目团队力量跑通流程同时培养内部骨干。性能测试需要专项能力但项目频次不固定先全员打底再从中长出专项人员。从零起步的测试部最怕的不是缺人而是每个岗位都配了人每个岗位都产出不了可用的东西。我一般会在项目分工表里写明“配置对接人”和“性能责任人”哪怕暂时由功能测试兼任。做不到专人专岗至少要专人负责否则“全员参与”最后就是全员不参与。2.3 技能要求分级哪些必须熟练、哪些了解即可规划把技能分成三档必须熟练、灵活运用、具备认识。分档的意义在于把培训成本花在刀刃上。新团队三个月内能把主干工具练熟就不错了不可能全都要。技能域必须熟练灵活运用具备认识缺陷管理TestDirector 从需求到 bug 列表、测试报告汇总组负责人掌握系统管理员常用功能Bugzilla、Bugfree、QC、Mantis性能测试性能人员熟练 LoadRunner能参数化、关联、定位瓶颈团队成员理解原理能做简单结果分析自动化测试工具配置管理全员会用 SVN 做 update、commit 等基本操作配置管理员熟练使用 SVN 全部功能VSS、CVS、JIRA数据库SQL Server 2005、Oracle 常用语句查询、插入、修改、删除、简单表关联组负责人掌握更复杂的联表查询性能人员了解数据库监控操作系统Windows Server 常用命令组负责人、性能人员能独立安装系统并搭建测试环境Linux、Unix 基本命令中间件Tomcat、Weblogic 能理解配置含义组负责人能用它们搭建测试环境团队成员了解用途文档工具Visio、Project、Excel 函数能看懂数据模型了解系统架构和开发语言按兴趣深入网络协议了解 HTTP、Tuxedo、SNMP 等常用协议性能人员熟悉主协议工作原理按兴趣学习这套分级的落点是一句话前三个月所有成员至少把缺陷管理、SVN、SQL 查询、环境搭建这四件事跑通性能测试和自动化先让有潜力的人深耕其他人了解原理即可。培训节奏上规划建议技能和工具培训每月 1-2 次内容按员工意愿汇总业务流程培训则请需求和设计人员来讲。我会把每月的第一次培训固定成“复盘会加工具技巧”第二次才安排新工具避免培训流于形式。3. 测试流程与文档规范六类输出文档和它们的输入依据有了岗位和技能下一步是把测试流程立起来。这一章最核心的经验是用文档来定义流程而不是用箭头图。3.1 先看现状哪些是流程问题哪些是文档问题规划文档开头列了六条现状测试流程不规范、测试文档不健全、测试文档不受控、测试人员不参与需求分析、被测软件没有版本控制、测试人员多为新人。这六条看着都是问题按属性分其实是两类流程问题和文档问题。流程问题包括流程不规范、不参与需求、版本没控制文档问题包括文档不健全、不受控。我的处理习惯是先抓文档再抓流程。文档是流程的载体没有文档模板流程就是空话。先让文档从无到有再把流程节点一个个嫁接到文档上。版本控制比较特殊它同时是流程和技术问题测试部要管的不只是被测软件还包括自己输出的测试文档两份内容都放进版本控制体系才能说得上受控。3.2 整体测试流程从测试需求到总结报告的七个节点规划没有把测试流程画成一大堆箭头而是用输出定义节点每个节点都写明了参考依据测试需求参考需求规格说明书和业务流程说明文档现阶段可暂不输出。测试计划参考项目整体计划、开发计划以及测试需求。测试用例参考需求规格说明书、demo、系统详细设计文档。执行测试依据已评审通过的测试用例执行记录实际结果。提交缺陷单使用 TestDirector 管理定期统计 bug 列表。回归测试验证已修复缺陷检查是否引入新问题。测试总结报告根据各个阶段测试总结和 bug 管理工具数据输出。好处是每个节点都有明确的输入依据不会出现“用例拍脑袋写”的情况。测试需求文档在现状下暂不输出原因很实在新团队还没能力把需求规格抽象成测试需求强行输出只会多一叠没人看的文档。如果项目经理有特殊要求就按项目组模板输出部门模板在日常工作中持续改进。3.3 各阶段测试分工开发、测试、用户各自的责任边界测试阶段责任主体单元测试开发人员完成集成测试开发人员与测试人员共同完成确认测试测试人员完成回归测试测试人员完成验收测试测试人员、用户、开发人员完成这里最容易出问题的是集成测试。如果把集成测试全接过来开发会默认“只要自测过就行”留给测试的环境问题、模块接口问题全要测试自己排查。正确做法是开发负责模块联调测试负责验证联调结果是否满足系统整体要求。确认测试是测试人员第一次独立行使质量判断权的节点前置条件是测试环境搭建完成、版本基线固定、用例评审通过。3.4 输出文档清单每份文档的输入依据与模板要求文档参考输入是否必须测试需求需求规格说明书、业务流程说明现状可暂不输出测试计划项目整体计划、开发计划、测试需求必须测试用例需求规格说明书、demo、详细设计必须缺陷单测试执行结果必须测试总结报告各阶段测试总结、bug 管理工具数据必须文档统一按部门模板编写项目如有特殊要求按项目组模板输出。我建议每个测试组维护一份文档索引把项目名、文档版本号、负责人、存放路径列出来。这样不管人怎么流动都能快速找到上一轮测试的依据。没有索引的文档库三个月后就变成没人敢动的“黑匣子”里面可能有价值的信息也被埋了。3.5 测试环境与配置管理SVN 让文档和版本都受控测试环境要求测试部门独立搭建并维护搭建时向开发或实施要三样东西安装部署手册、版本代码、数据库脚本必要时可要求开发配合。这意味着测试组负责人要能独立安装操作系统和中间件这也是上一章技能分级里组负责人必须达到的水平。项目测试文档用 SVN 管理最常见的落地动作是这套# 以 SVN 为例测试文档从“不受控”到“受控”的最小动作集 svn mkdir https://svn.example.com/repo/项目X/{trunk,tags,branches} -m 初始化项目结构 svn checkout https://svn.example.com/repo/项目X/trunk 项目X_工作副本 cd 项目X_工作副本 svn update # 开始当天工作前先更新避免基于旧文档修改 svn commit -m 提交测试计划 v1.2补充回归测试策略svn mkdir 一次性建出 trunk、tags、branches 三个目录trunk 里放当前正在开发的版本tags 放里程碑版本branches 放分支。测试人员日常只需要 checkout 和 updatecommit 时写清楚版本号和变更点后面回溯“这份计划是什么时候、为什么改的”就有据可查。注意提交信息不要写“修改一下”“更新”这种空话至少要写到能让三个月后的自己看明白。注意SVN 切分支不是测试人员日常要做的事但需要会看日志和合入记录否则开发说改了你连改动在哪都查不到。4. 日常项目与跨部门接口bug 追踪、人员备份、需求参与流程和文档立住之后测试部的日常工作才能谈得上规范。这一章讲的是怎么把流程转起来以及怎么不让测试组变成孤岛。4.1 Bug 追踪机制TestDirector 流程与统计习惯Bug 管理流程是测试部运行的主干。规划明确使用 TestDirector 作为 bug 管理工具流程可以按项目组需求调整但状态变更必须完整留痕。常用流这样走测试人员提交缺陷单填写标题、复现步骤、预期结果、实际结果、严重程度和优先级。测试组负责人审核缺陷确认有效的指派给对应开发无效的直接退回并写明原因。开发修复后修改缺陷状态并在备注里写明修改内容和影响范围。测试人员用最新版本验证通过则关闭不通过则重新打开。每周从 bug 管理工具导出数据按模块、等级统计纳入测试总结报告。我的经验是开发关闭 bug 时必须写明修复方式和验证建议否则测试得重新猜一遍。凡是“重新打开”超过两次的 bug测试负责人要单独拉出来过一遍这往往意味着需求理解有偏差或者修复策略本身有问题不是测试人员较真。4.2 项目人员安排与备份1-2 人配置下的最小可用组织规划要求每个项目至少配置 1-2 名测试人员同时建议做备份。原因是测试组长任务繁重一旦因个人原因无法到岗项目测试可能整个停摆。备份的意义有两层一是有人请假不误事二是新人能在备份过程中获得独立负责模块的机会。实际操作里我会把备份人员固定到一条具体用例集上比如“备份负责支付模块的用例设计和执行”。直接上手做的备份才是有效备份站在旁边看三个月跟没备份一样。测试小组还要阶段性地组织技术和心得交流让碰过不同模块的人互相知道彼此的坑这对后续轮换帮助很大。4.3 测试组与开发组的接口需求研讨、业务培训、沟通边界规划里提到几个关键点与开发人员交朋友采用恰当的方法沟通不要总责怪开发的能力和经验要主动协助开发排除阻碍。两个部门负责人之间的沟通协作是工作成败的关键。测试人员必须熟悉业务流程和技术才能对系统 bug 有更多发言权有时还能给开发提出建议。具体建议是测试组负责人参与开发人员的项目需求分析研讨会然后给测试组其他成员讲解项目需求和业务流程。这个机制比我见过的大多数“测试自己看需求文档”要有效得多因为转训会逼着负责人先把业务吃透组内其他人也能在同一认知基线上去设计用例。沟通技巧有一条血泪经验提 bug 时永远先附复现步骤和截图再写结论。开发最烦的就是一句“这个页面错了”他复现不了剩下的全是争吵。能稳定复现的 bug是测试给开发最好的礼物。4.4 与其他部门的接口验收测试与用户操作手册验收测试由开发、需求业务部门着重考虑软件是否满足规定功能、性能文档资料是否完整准确人机界面和可移植性、兼容性、错误恢复能力、可维护性是否令用户满意。测试人员在适当时候要参与验收站在技术角度帮用户把关。用户操作手册和帮助文件的撰写建议由测试人员配合实施部人员完成。理由很直接测试人员对系统的边界条件和异常路径最熟知道用户会在哪里走偏写出来的帮助文档才能真正避免用户走到死路。开发写文档容易默认用户什么都知道测试写文档默认用户什么都不知道后者更适合做用户手册。5. 测试部门避坑与常见问题五个最容易翻车的场景制度写出来是一回事落地是另一回事。这一章把新测试部门最容易翻车的五个场景列出来每条都是现象、原因、解决。5.1 现象一文档写了一堆发布后没人看现象测试计划、测试报告全放进了 SVN开发找你要结论只看邮件里的截图新入组的测试人员不知道文档在哪甚至不知道有这些文档。原因文档写完没有评审没有统一目录文档和决策没有绑定。没人会把一份静态文件当作工作依据尤其是这个文件存在哪里都还得问一圈。解决先定统一模板和目录结构测试计划必须开评审会当众过让开发、项目经理在会上确认测试策略。文档索引放在项目信息统一入口每次例会同步“文档状态”。关键决策写进邮件并附上文档链接让文档是活的而不是写完就归档的资料。5.2 现象二测试人员不参与需求分析用例全靠“猜”现象开发自测完提测测试人员第一次接触需求当场问出一堆基础问题。用例评审时需求已经冻结一改就要改一整片。原因流程上没定义测试人员的介入点项目经理默认测试只负责最后环节。测试人员不是不愿意参与需求讨论是根本没人通知他们参加。解决测试组长在项目启动阶段就进需求会把转训机制写进部门流程需求会后三天内由测试组长给组内讲一遍业务背景。实在进不了需求会就用 demo 和详细设计文档补先画业务流程再写用例能逼出很多需求理解问题。5.3 现象三被测软件没有版本控制测了半天测的是旧包现象测试环境里的系统行为和代码对不上。开发说这个 bug 已修复测试说这里确实没变最后核对才发现部署的包根本不是同一个版本。原因没有版本基线开发只在本地修复但没提交主干或者测试环境没有按最新版本重新部署。小项目里这种问题最常见大家觉得没必要管版本结果填坑的时间比省下的时间还多。解决SVN 建立 trunk、tags、branches 结构提测必须带版本号。测试人员部署前先 svn update 并记录版本号回归前核对部署包版本号和提测邮件一致。没有版本号页面的系统查构建产物的版本信息三十秒就能验证别嫌麻烦。5.4 现象四性能测试“全员参与”结果只会录脚本不会分析现象把 LoadRunner 发给所有人一场培训下来大家都能录脚本、跑场景但报告堆了一堆响应时间没人能说清瓶颈在哪。原因性能测试是垂直技能需要并发模型、关联参数、资源监控和瓶颈定位全员摊薄了反而谁都学不精。新人最容易卡在脚本关联上一旦 session 处理不对录出来的脚本回放全是失败。解决先定 1-2 名性能专项人员测试经理兜底其余成员只要求理解原理和参数化。专项人员先拿一个内部模拟项目跑通“脚本-场景-监控-数据库-瓶颈定位”闭环再上真实项目。LoadRunner 这类工具会用脚本只是入门能定位系统瓶颈才算合格。5.5 现象五考核只考工作量能力成长没进考核留不住人现象月度考评表全是任务完成率技能学习和流程改进不占分。勤恳的人得分高但团队整体技术长期停滞优秀的人开始外流。原因考评权重只围绕“今天干了什么”没有回答“三个月后能干好什么”。测试人员如果看不到自己的成长路径很容易觉得自己是个点鼠标的机器。解决用规划的 80% 加 20% 公式任务完成情况占 80%个人行为及能力表现占 20%。后 20% 要具体量化是否输出了新的测试用例模板是否完成指定专项学习是否带过新人bug 有效率是否稳定而不是负责人凭印象打分。考核标准要公开让被考核者知道怎么做能拿高分制度才有引导力。注意避坑章节的三条主线是文档、版本、能力。新团队如果只抓一件事先抓版本控制版本不受控前面所有流程都是建立在流沙上。6. 进阶落地把考核机制变成一张可执行的评分表6.1 考评总分构成任务占比 80%行为与能力占比 20%规划里的考评总分为 100 分等级分五个层次计算公式很明确总分 工作任务及完成情况 × 80% 个人行为及能力表现 × 20%为什么任务只占八成单纯考核任务量会逼着测试人员只挑好做的用例执行、只提交安全性高的缺陷。划出 20% 给行为和能力是在明确告诉团队学习、改进流程、帮助同事这些事和完成项目同样重要。具体分数档位可以由各部门按项目强度自定义我习惯把等级定为“优秀、良好、称职、待改进、不称职”五档并在月度考评表里把 20% 拆成三个可勾选项技能学习完成度、文档改进贡献、团队协作表现。6.2 月度考评与年度总结联动调薪、转岗的依据月度考评积累的是过程数据年度总结报告看的是全年变化。规划要求测试人员年底提交年度总结部门据此做职位级别调整、岗位调换和薪资调整申请。这个设计把短期执行和长期发展接上了月度评分是“过程检查”年度总结是“阶段验收”避免年底评优全靠负责人回忆。我自己的习惯是把每月数据汇总成一张趋势表到年底直接看曲线哪个成员从三个月前开始明显成长哪个成员连续六个月任务达标但能力项没变化一目了然。岗位调换和调薪建议都拿这张表说事不靠印象分。带过新测试团队之后我才真正明白规划文档写得再全落不到月度动作上就是空转。从那以后我每次接手新测试部门都会强制走一套验证流程先出部门规划草案再对照岗位、流程、文档、接口、考核五件事逐项检查岗位有没有漏、文档有没有人认、考核有没有数据支撑。希望帮到你。本文还有配套的精品资源点击获取