主题：如何制定测试计划
在测试阶段，测试经理要综合考虑以下影响测试的因素并完美地协调其中各个要素的关系，只有这样做才能避免在测试过程中出现种种意外并影响测试的质量：
测试组建立、测试范围的选择、测试组的培训、测试平台的选择和配置、测试技术和工具的选择、测试执行的日程和进度、测试用例的设计、维护和更新、测试环境的设计和搭建、测试文档的格式和提交时间、测试入口/出口的checklist、测试组成员的管理和激励机制、测试过程的流程和定义、测试过程的质量监控。
一、测试团队的建立和组织
测试团队按照职能可分为四类组织：
1）测试设计和执行组，这类组织奖占有大部分的测试人力资源，负责测试的设计和执行。
2）技术支持组，测试中有两种时候会用到特别的技术支持，一是测试工作平台，包括测试用的各类数据库，其维护和支持需要有专门技能的人负责；二是测试环境，测试环境随测试对象的不同而大相近庭。
3）问题管理组，这些人的职责是处理和跟踪测试中发现的问题，以保证所有发现的问题，在正确的时间，由正确的人，在正确的软件基线上做正确的解决，最后由测试人员在正确的版本上做正确的验证。
4）质量监控组，负责监控测试本身的质量，以保证测试能够有效和有序的执行。
二、测试范围的选择
三、测试团队的培训
培训分两类，技术类和流程类。
技术类培训专注于测试中将遇到的技术问题，比如待测产品的技术、设计和方案的培训，测试工具的使用培训等（QA在每次培训前都宣布要针对培训的内容进行考核，有力减少培训中缺席、早退、打瞌睡等现象）；
流程类培训是告诉大家如何按照事先约定的方式去工作（每一个测试活动都有相应的流程指导书，里面会对具体的行为做具体的规定）。
四、测试平台的选择和配置
测试团队不借助任何平台的结果：
1）成千上万的测试用例无法有效管理，测试开始之初无从知道哪些测试用例对此项目是有用的，这将在很大程度上增加测试准备期的工作量。而且对于不同的软件版本进行不同的测试覆盖选择时也会极不方便。
2）测试人员在测试过程中需要为每个测试用例填写测试结果，但通常测试经理的苦恼在于：如果没有工具有效管理这种行为，那么对于测试的进度无法有效地了解，测试当时的状况，如测试用例的通过率，可执行率等数据都很难实时地得到。
3）测试中必然会发现问题，问题管理也是一大繁琐的问题，这涉及一个工作流程的问题。
测试计划阶段需要明确我们即将采用何种测试平台工具来实施测试，在此之后还有一系列的安装、配置、培训和维护等诸多方面的问题需要关注。
测试平台主要包括：测试用例数据库、测试计划数据库、测试报告数据库、问题跟踪数据库。
五、测试技术和工具的选择
测试从技术角度上有多种分类，其实如何分类并不重要，重要的是在某一测试项目中如何筛选适合本项目的技术手段才是最实际的问题。测试中并不是最有技术含量、最有吸引力的手段就一定是最适合的。
测试计划阶段中需要做的是：了解自己的项目需要什么测试。了解每种测试技术适合的范围。之后得出结论：在本测试项目中，哪种测试技术是最有效的，以及针对这种测试技术需要做出哪些资源和人力方面的准备。
六、测试执行的日程和进度
测试经理需要明确清楚地回答这几个问题：什么时间，在什么版本上，出于什么目的，做哪些和测试相关的活动。
通常的经验，对于软件测试项目来讲，测试要进行至少四轮才有意义。
1）第一轮，验证功能，提交发现的问题；
2）第二轮，验证提交的问题是否被修改，同时看是否在修改后引入了新问题；
3）第三轮，验证性能，假定前两轮测试后那些低级的功能性的错误已经被消灭的差不多了，这时需要创造一些恶劣的环境，来验证软件是否足够强壮；
4）第四轮，全面验证软件的全部待测点，并根据本次测试的结果评估产品上市的风险。
并不是所有的问题都是在测试开始第一轮就可以被全部发现，原因有几个方面：
1）测试人员在第一轮可能尚未进入状态，对待测产品的熟悉还有待提高；
2）测试进行中，可能有一些问题阻碍了其他问题的发现；
3）依靠执行测试用例不可能发现100%的错误，软件的功能好比是面，靠孤立的点来覆盖面试完全不可能的。因此测试的主观因素就永远不可避免。测试人员的灵机一动可能会发现很多重要的问题，而这种问题的发现一定要依靠一定的时间和工作量的积累。
M0（软件项目启动，需求定义阶段）—M1（分布式开发阶段）—M2（总体联调阶段）—M3（产品上市）
Mo—M1阶段：测试的人才储备期，主要从人力及其培训方面做准备，保证在将来的测试阶段有足够熟练新技术新功能的测试人员；
M1—M2阶段：测试的技术流程准备期，依据项目明确下来的需求，分别从计划、技术、工具、环境、团队、流程等方面做准备。包括制定测试计划，设计测试用例，搭建测试环境，组建测试团队，明确测试流程等；
M2—M3阶段：测试的全速实施期，整个测试团队按照之前的准备全速执行测试，力求在最短的时间内发现最多的问题；
M3后：对测试仍旧极为重要，测试团队需要根据市场的反馈了解产品在市场上发生了哪些情况，协助开发人员复现这些问题，以使这些问题得到最快的定位和修改，而减少在市场上的负面影响。
测试日程的制定需要根据两个文档，第一是总体的项目时间表，第二是项目的软件版本发布计划。
制定测试日程需遵循以下原则：
1）每个软件版本一定要有一个版本基本测试，目的是在最短的时间里判断软件是否值得一测；
2）在所有功能都集成起来之前不需要进行系统测试，但应该按照集成模块的次序，进行各个子系统的测试；
3）现场测试盒互操作性测试要在系统测试进行至少两轮之后才开始，以保证最基本的功能性问题已经被发现并解决；
4）压力测试发生在上市之前的一两个版本上，主要目的是试图复现那些影响较大但复现概率极低的问题。
七、测试用例的设计、维护和更新
测试用例是所有测试活动的技术基础，实在是非常值得把时间和人力投在它上面。
关于用例问题测试部与开发部之间的沟通：
1）每天开发工程师抽出半小时时间来回答测试人员的疑问
2）开发的任何一点变化都要在需求变更库中存档，数据库的权限要同时开放给相关的测试人员，测试人员每天都需要在需求变更库中检查这些变更，同时同步地更新测试用例。
对于测试用例开发，在第一个软件版本发布之前，基本测试用例集必须完成，针对新模块的测试用例必须在该模块第一次发布之前完成。
测试用例在以下三种情况下必须得到更新：
1）需求变更库中显示需求方出现了变动，相应的测试用例必须修改；
2）测试组内部评审时发现测试用例覆盖不够全面时，需要添加新的测试用例；
3）自由测试中发现了问题，相应的测试用例必须被添加。
八、测试环境的设计和搭建
九、测试文档的格式和提交时间
测试团队对外的输出文档有二：一是问题报告，二是测试报告。测试计划中要清楚地写明对这些报告内容上和时间上的要求。
测试报告是在测试的某一阶段后，对测试过程的总结和待测短剑/版本的成熟度和风险的评估。
十、测试入口/出口的checklist
每一个测试项目的每一个环节都要有清楚的入口和出口的准则，也就是清楚的定义什么情况下测试可以开始和什么情况下测试应该结束。
软件在提交系统测试之前应该按照事先约定的标准（checklist）进行一定的审查，以避免仓促提交测试再被一脚踢回来。
测试循环开始的Checklist：
1）版本的发布是否遵循了《项目软件版本发布计划》？
2）随着版本的发布，是否一起提交了版本发布说明？
3）版本发布说明中是否详细描述了此版本与上一版本的区别？
4）改动部分是否执行了单元测试和集成测试，是否有测试报告？
5）版本发布前是否对简单功能进行了基本验证？
6）版本发布说明中是否包含解决问题的列表和未解决问题的列表？
测试团队自身也要有Checklist，即测试循环结束的Checklist：
1）该版本的测试报告是否已提交？
2）测试报告中是否对软件的状态下出了结论？
3）各子模块测试的报告是否已提交？
4）是否100%完成了更改问题的验证工作，是否有验证结果的汇总？
5）该版本上新发现问题的列表是否已提交？
6）所有遗留问题的列表是否已提交？
7）所有遗留问题中最严重的TOP10是否已提交？
8）以上所有输出物是否都按照标准化文档模板书写的？
十一、测试组成员的管理和激励机制
我们已经充分地了解了测试的特殊性，它要求测试人员随时保持旺盛的斗志，在强调职业道德的同时，一定的物质激励措施绝对是有必要的。
十二、测试过程的流程和定义
测试并不是技术驱动的工作，更多的是管理和流程驱动的活动。
测试计划中要描述两大部分的流程，第一部分是测试管理流程，可以简单的概括为计划、实施和报告三部曲；第二部分是问题管理流程，规定如何管理、维护和跟踪测试中发现的问题。
测试团队方面常见的问题有：
1）有时候问题单输入的质量不高，需要的信息提供不准或者不全，开发人员无法理解问题的全貌，往往需要经过多次沟通才能解决；对于异地开发甚至跨国开发的项目，这种沟通成本是很高而且低效的；
2）多个测试人员在填写问题单时沟通不够，经常同一个问题多个人多次上报，导致问题单的数目大于实际问题的数目，会给开发人员和问题管理员增加很多重复劳动；
3）测试人员对于功能的理解不够深入，往往报告一些实际上不是问题的伪问题，这样会增加其他团队的工作量；
4）验证问题的效率和准确性有待提高，有时候测试人员更喜欢追逐新问题，对旧问题的验证兴趣不高，但是对于项目来说，旧问题的验证却更有价值。
针对四大问题对测试流程进行修正：
1）QA需要抽查问题单的输入质量；
2）测试人员在填写问题单前需要在数据库中按关键字搜索相关问题，只有确信以前没有人提交过时才上报；
3）增强培训，最大限度减少误报；
4）在流程上保证验证问题的优先级，规定在一个版本测试中，最先做的就是旧问题的验证。
十三、测试过程的质量监控
测试过程的监控应该针对六大关键点：
1）测试计划的风险评估；
2）测试文档的质量；
3）计划实施的质量；
4）测试报告的质量
5）问题管理的质量
6）测试范围与覆盖率的完备性。
====================================分割线================================
最新内容请见作者的GitHub页：http://qaseven.github.io/