【项目管理一点通】（37） 测试管理

上节说了，测试组应该由项目经理直接管辖，或者说测试组与开发组平行，测试管理一般由测试组长去负责，但是项目组比较小的话，建议项目经理应关注测试业务和测试管理。
在上个世纪甚至本世纪初期，我们国家的软件行业开始进入上升期，很多的中小软件公司如雨后春笋一样地出现了，软件业务也逐渐爆发，很多软件公司一度对软件工程认识不够，片面重视开发、轻视设计和测试，尤其是测试岗位不被看重，甚至是今天，很多部门甚至是人力部门都认为测试岗并不重要，可以从其他岗位协调资源参与测试，这种认识是非常错误的。好在大多数软件公司已经认识到测试的重要性，毕竟软件的质量很大程度上依赖于测试，否则无法顺利交付，多出来的费用已经远远大于测试的成本了。
我不打算在这里讲解软件工程和测试业务，而是结合实际情况，让我们的项目经理了解一些必要的测试业务和测试管理的基本知识，这些知识对于项目经理来说是非常必要的，毕竟测试管理也是项目管理的一部分。
1、测试何时介入？很多项目经理都在纠结这个问题。全程介入是不可能的，毕竟一个公司的人力有限，项目的测试组基本上就是公共资源，其他项目组可能也需要共享测试资源，所以需要规划好介入的时间点。一般来说，在概要设计时介入是比较妥当的，让测试人员了解项目的背景和整体业务，从而方便他们制定测试计划，验证整体流程，了解设计目标和原则，对后期的测试工作都是有好处的。
2、测试工作有哪些？测试工作主要包括撰写测试方案、制定测试计划、编写测试用例、运行测试用例、编写测试报告和测试总结等。下面简单描述一下各部分工作的内容：
a. 测试方案。测试方案并不是那么复杂，实际上就是描述测试组打算如何完成测试工作，比如说，测试组组成、测试方法、测试工具、测试流程、测试模板、测试计划、测试用例的管理等。
b. 测试计划。测试计划是项目整体计划的一部分，同时也是测试方案的一部分。测试计划主要交代什么阶段做什么测试工作就行了，比如，在完成概要设计后就开始基于需求编写测试用例、开发阶段就开始准备测试工具、开发工作完成后就开始运行用例进行测试，测试工作结束后形成测试总结等。
3、回归测试需要几轮？这也是测试人员非常闹心的问题。有人说了，这我哪知道要几轮回归，我只能这样说，制定计划和实际执行时需要结合实际情况和以往的经验来调整回归的次数，比如说代码质量较低，需求分析质量不高，需求迭代频繁，估计没有7、8轮下不来。相反如果代码和设计质量水平很高，回归的次数就会少很多，甚至2~3次就可以覆盖。所以结合项目组以往的经验来调整回归的次数和时间。
4、如何让用例覆盖所有的业务？首先要说明的是，用例百分之百覆盖业务的几率几乎为零，换句话说，我们测试人员编写的用例只能是无限接近业务全覆盖，但是很难做到百分之百覆盖。很多项目经理经常责备我们的测试人员，说用例写得不够好，测试遗漏多，这是不科学的，我们可以通过提高测试用例的质量，尽可能多的覆盖业务，但是遗漏是必然的，采用什么办法补全？就是充分的理解业务，追加用例，增加回归的次数。有人疑惑为什么会这样？原因很简单，就像我们的代码写得再完美，也无法百分之百覆盖业务需求一样，这种现象就是代码失真和用例失真，学过离散数学的都知道，离散是对连续的模拟，同理，我们的需求是连续的，我们的代码和用例实际上是离散的，所以，通过提高我们的代码和用例质量可以充分的接近需求，项目经理一定要充分认识到这一点，尤其是要充分估计我们的用例质量，质量差的用例需要的回归次数就多，而且业务覆盖会有很大比例的遗漏。另外，在项目时间不允许的情况下，不要片面追求百分之百的用例覆盖，可以通过其他方法弥补。
5、测试用例模板。网上有很多测试用例的模板，找一个适合自己的就行，没有必要在选择模板上浪费过多的时间。
6、交换测试。单个测试人员进行全系统测试时，有测试疲劳、测试惯性的现象，就是回归测试的时候，会按照上一次的测试轨迹去进行测试，这样很难发现新的问题。所以项目组最好设置两个以上测试人员，进行模块交换测试，避免测试惯性。
7、用例迭代。上面说了，测试用例无法做到百分之百覆盖业务，有时会遗漏很多，所以，需要我们不断的修正测试用例，这就是用例迭代。通过用例迭代可以使我们的用例不断的接近实际需求。
8、用例管理。管理测试文档和测试脚本。
9、测试工具。测试工具有很多，建议大家使用比较高级的测试工具，比如说可以录制和修改脚本，脚本自动运行，断点测试等。好的测试工具能够显著的提高测试效率。
10、自动化测试。如果有条件进行自动化测试的，可以大大降低回归测试的工作量，但是自动化测试需要编写自动化脚本，所以需要综合考虑。另外，不能完全依赖自动化测试，应各种手段综合运用。
由于测试的内容非常复杂，我无法一一详述，大家如果感兴趣，可以参考一些测试的书籍。谢谢大家的阅读。