很多新升为测试管理岗的小伙伴们经常会有的疑问，除了自己去分配其他团队成员任务外，几乎其他的事情与自己以往工作并无区别。特别是团队中没有比自己更有经验的测试人员时，完全不懂测试管理到底要做哪些事情。
简言之，无论是做测试执行还是测试管理，都是一个不断解决问题的岗位 ，只是解决问题的方式与层次不同而已。
而软件测试管理与执行的最大区别就是，后者只需执行前者分配好的任务即可，无论是编写测试设计还是执行用例，或是提炼测试需求点，只需要在规定的时间里完成任务并交付即可。而测试管理并不只是单纯地安排其他人任务就好，需要管理人员对测试团队服务的“客户”以及“客户”需要达到的服务了解地非常清楚（这里的“客户”指服务的对象，比如我们公司测试团队的服务对象即为产品经理，因测试交付后是需要提交给产品经理验收的，验收通过则进入下一环节，否则测试返工，重新执行。这样测试团队对于产品经理给出的验收交付标准、交付功能点清单以及其他要求的质量特性要非常清晰。当然这里测试团队的服务对象会与公司内部的管理有关，不同情况下存在不同的“客户”）同时，要清楚当前的测试资源，如有些团队包括测试人员也是非固定性质的，当成立新的项目组时，会临时借调其他组成员，这样需要提前了解好有多少可以投入的测试人员，以及配备的软硬件等； 接下来就是分析产品及可能存在的风险； 根据以上情况来确定测试任务； 一般可以与技术负责人一起商议，如目前存量的资源以及按照项目计划书描述每个节点应该完成的任务百分比等。同时需要提前准备好测试策略，但测试策略应该是动态的，根据项目进展情况随时调整测试策略。
以上是制订测试计划的基本流程，也是基础信息来源。
一般情况下如果公司有测试管理工具的话建议直接有工具更清晰，也更便于管理维护。如TAPD的自定义测试计划模板，也可以使用在线的思维导图或文档。
以下以一常用的软件测试计划模板为例 ，介绍下如何制订好一份测试计划。
这里主要分为部分：
文档简介
测试资源与工具
测试策略
测试阶段的开始/结束标准
风险与应对计划
质量目标
测试过程管理
测试范围定义
测试排期（进度、人员安排）
测试交付物
附录-测试关注点
-----------------------
文档简介
一般包含测试计划编写目的、限制条件及参考文档
编写目的需要根据文档阅读人群来编写，如果项目属于外包性质的，需要考虑是否会合并在验收文档中。
测试环境
一般包含硬件环境和软件环境，如下图：
测试工具
所有测试过程中使用到的工具，包含用例编写工具、执行测试工具、缺陷管理系统、需求管理系统等等。
测试策略及方法
常见的测试策略如下：
尽量做到在有限的时间里发现尽可能多的缺陷（尤其是严重缺陷）
测试计划与需求阅读同步进行
用例的设计需要高匹配产品需求，在需求的指导下设计出更多更有效的用例
逐步完善测试用例库（测试用例需要根据执行过程中不断修订，动态调整）
保证测试过程受控
常用的用例设计方法：
等价类划分法
是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。
边界值分析法
边界值分析方法是对等价类划分方法的补充。通常输入和输出等价类的边界，就是应侧重测试的边界情况。
错误推测法
基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。错误推测方法的基本思想：列举出程序中所有可能有错误及易发生错误的特殊情况，根据它们来选择Case。
判定表法
判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。
判定表的优点是可以将复杂问题按照各种可能的情况全部列举出来，避免遗漏。在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题。
场景分析法
对于业务功能测试领域，场景分析法是最普遍也是最主要的设计方法了。首先需要充分了解整体业务。结合分析应用场景，从用户角度出发设计Case，是一种面向用户的测试用例设计方法。
缺陷的严重级别定义
此处不作过多说明，通常按照行业标准定义。但业务为主的产品中，需由产品经理及用户代表来确定缺陷的严重程度，主要根据对用户使用的影响程度来计算。
开始/结束标准定义
开始标准与结束标准通常按照公司内部的测试流程来确定，如测试交付产品经理或验收通过，或是达到已经定义好的质量标准。
中断标准
软件开发过程中，难免会出现一些意外导致项目中断，这时测试也应按照提前约定好的暂停，一般存在以下情况时：
软件项目需暂停以进行调整时，测试应随之暂停。
软件项目在开发生命周期内出现重大进度偏差，需暂停或终止时，测试应随之暂停或终止。
若开发任务暂停，则相应测试也暂停。
风险与应对计划
一般包含需求风险、时间风险、资源风险等，需要注意的是，每条风险识别都需要有对应的应对计划措施，至少2条。
质量目标
一般包含产品质量目标与测试质量目标
测试质量目标以下可作为参考：
所有的Case已执行过至少一遍
所有严重级别及以上的Bug已修复且测试人员验证通过
核心功能不允许有中级及以上的Bug
一般功能与终端用户不直接使用的功能不允许有中级以上的Bug
缺陷趋势呈下降并接近为0
在最后的10%时间内没有发现中级以上Bug
测试过程管理
通常包含测试文档的过程管理与缺陷处理的流程、汇报会议、进度日报形式等。
文档的过程管理如管理人员、存储、移交、分享等需要定义好形式，缺陷处理流程可以以缺陷管理系统中定义好的工作流来说明。
测试范围定义
测试范围可以按照项目计划书的里程碑来提前拟定，如哪个阶段需要进行底层框架的性能测试、是否需要完成接口测试、功能测试中包含哪些功能点等等。非测试范围一般说明不在本次范围内的功能点或测试类型，有时因项目进度原因可能临时对某些功能点进行删减，需要同步更新。
测试排期（进度、人员安排）
进度排期可参考以下几个节点进行划分，可以根据特定节点来划分不同的阶段。
人员与任务安排可以根据前期已整理好的可用固定资源与临时资源调配来作好相应调动计划。
测试交付物
一般一个项目结束后需要交付的测试产物有：软件测试方案、测试用例、缺陷报告、项目测试报告、用户操作手册（若由测试团队提供时）
附录-测试关注点
附录中依据需要可以增加多个附录，如相关术语、缩略语的解释、测试需特别关注点等 。
测试关注点一般由技术负责人、所属产品经理及用户代表提供，可以在测试方案中提前明确以提醒测试人员的注意事项。
如增删查改功能点、数据导入、导出及特定输入框功能的测试侧重点
不能破坏数据库数据的关联和完整
检查多次使用back键的情况，在有back的地方，back回到原页面，再back重复多次，检查是否出错
修改正在使用的数据；
多次连续查询正确性
导入数据格式要求不应太苛刻，提示明确
数据的动态监测是否正确无误
对于日期时间型数据，检查格式正确性以及时间日期的合理性。比如开始时间不能晚于结束时间等
重复数据处理，尤其是键值的重复
测试计划制订完成后，需要与项目中核心负责人确认，待审核通过后便可开始进行下一环节。需要注意的是，测试计划是隶属于项目计划书中的一部分，也是项目计划书的延伸，完成制订后仍需要根据实际情况来动态调整，才能达到最理想的指导目的。#软件测试#（更多详情请关注“木蚂蚁”公众号查阅）
网友评论