6.7.3 老功能分析
很多时候，我们的被测对象并不是全新开发的功能，而是在之前版本上已经测试过的老功能。对一个新开发的版本来说，老功能和新功能的质量要求可能是相同的。如果我们需要基于质量要求来制定测试策略，那么在测试的时候，老功能和新功能的测试投入就应该是一样的。
但是，事实上老功能已经被测试过，老功能和新功能的质量起点是不同的。执行10个新功能的测试用例和执行10个老功能的测试用例相比，前者更容易发现问题，失效的风险更大。
此外，老功能的测试用例，如果在之前测试的时候没有发现问题，想在新版本上发现问题的可能性并不高（注意，是“不高”，不是“绝对没有”）。
可见，更明智的做法是对老功能进行风险分析，以此来确定老功能在新版本中的测试深度和测试广度，制定“刚刚好”的测试策略。
对老功能进行风险分析就是老功能分析。我们可以从差异性分析和历史测试情况分析两方面来进行分析，如图6-29所示。
1.差异性分析
差异性分析是指找出老功能在新版本和老版本上的差异。这些差异包括需求、设计、平台、实现等各种差异。“找差异”也是在新版本中做好老功能测试的金钥匙。
老功能在新版本和老版本上的差异举例
老功能在老版本上的性能要求是需要支持每秒新建5个用例，在新版本上要求支持每秒新建10个用例。
老功能在老版本上只支持Windows 7、Windows 8，在新版本上要支持ISO和安卓系统。
老功能在新版本上重新进行了设计，做了重构。
老功能改由平台提供相关功能。
很多测试团队会要求开发提供产品的老功能的改动说明和测试建议，这是获得老功能在新版本上差异的好办法，但它却不怎么有效——根据我的访谈来看，大多数测试团队对开发提供的改动说明和测试建议不满意，它们不是描述笼统，就是细到几乎罗列出所有修改了的函数名，无法起到很好的测试指导作用。
有的测试团队会从设计文档中来收集差异，这也是个获得差异的不错途径，但是它也不是那么有效——很多开发团队不会再对老功能写设计文档，而且文档也存在更新的问题。
如果你遇到的窘况和上面描述的一样，我建议你可以试着和开发人员面对面地沟通——面对面沟通的效率和效果可能会超乎你的想象。
当然，为了让沟通更有针对性、更有效，事先准备一个沟通提纲是绝对有必要的。下面是一个“差异性分析沟通提纲”的示例，供大家参考（表6-20）。
这样的沟通活动持续一段时间后，我们还会发现它还会带来一些意想不到的“正作用”：开发提供的“修改说明”和“测试建议”逐渐变得有用，开发人员和测试人员之间变得更有默契。
2.历史测试情况分析
历史测试情况分析是对老功能在老版本中的测试情况（包括测试策略、测试用例、缺陷）进行分析，以此来确定老功能在新版本中需要采用怎样的测试策略。
我们可以按照如图6-30所示的思路来对老功能的历史测试情况进行分析。
1）确认老功能在新版本和老版本中的质量要求是否一致
需要我们特别注意的情况是，老功能在老版本中的质量要求比较低，例如就是给用户演示的功能，但是在新版本中，我们对它的质量要求提高了，提高到要完全满足用户的商用。
此时虽然老功能在之前的版本中就测试过，但是相对较低的质量要求使得老功能测试场景、测试深度等都还远远不够。这时我们需要对老功能旧的测试用例进行分析，确定在新版本测试时哪些地方还需要增加测试用例（至少可以确定大致的工作量，降低在工作时估计遗漏此部分工作量时的风险）。
2）进行测试方法分析
可以从表6-21中的这些角度对老功能进行测试方法分析。
3）进行缺陷分析
我们可以使用6.6节中提供的缺陷分析方法，围绕表6-22中的分析点，来对老功能的历史缺陷进行分析。
4）对“组织和人”进行分析
如果老功能是其他测试团队测试的，对这个测试团队的情况进行分析也是非常有必要的（表6-23）。
本文选自《测试架构师修炼之道:从测试工程师到测试架构师》第六章，本站经机械工业出版社和作者的授权。
版权声明：51Testing软件测试网获机械工业出版社和作者授权连载本书部分章节。任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
