测某一个功能很容易，但是如果被测的对象是功能的改进（Improvement）呢？例如要提高性能（Performance），提高配额（Quota）准确度，过滤以减少不必要的日志数量。
当我拿到这样的功能需求规格说明书时，我一头雾水。其实我都算是二手，这个被测大模块（多个模块组成的一种服务型模块）的测试任务（算是个子项目）是从他人手中转交给我的，他人也是刚刚接受作为这个领域的测试负责人，上手不到几个月，连这个测试任务都还没有熟悉就转交给我。于是我只能努力地去获取各种可以提供参考的信息，首先我到测试管理工具中去查找以前版本的测试计划、测试用例以及测试报告，从中了解被测对象的情况。我还会去阅读相应的开发方面的文档，包括设计文档、实现文档，甚至代码。
只是看文档远远不够，里面的内容总是可能会存在二义性或是含糊不清的地方，这时候就必须要鼓起勇气去骚扰别人。测试专家、测试架构师、开发团队（好几个人呢）、开发团队小组长、被测大模块的技术专家，我全都骚扰过。如此高频度的造访必须得讲求方式方法，不然人家很可能感到厌烦，而后你就会发现他们经常地很忙没有时间。在问人家问题之前，自己要先做好功课，尽量避免问太简单和基础的问题，更不能重复问同样的问题。而且不管是通过邮件还是当面请教，都要注意说话要有条理性，要能够在较短时间内以较小的篇幅讲清楚问题的背景以及问题本身。
在不断地交流中，我对被测大模块的理解也越来越深，要怎么进行测试的想法也越来越具体。写测试计划其实就是一个动态的过程，我先写出一个大概的样子作为讨论的基础，而后拿着它不断地和大家交流，询问他们的意见，然后再修改。根据测试质量管理的规定，我们的测试计划需要得到批准才可以进入执行阶段。得到批准需要我提前两周邀请相关人员，预约他们的时间参加审核会议；会议一周前要把相关材料发出，并且还要注意催促参会人员都要阅读这些材料；开会的时候基本不用担心，我只需要回答大家提出的疑问，如果有确实需要修改的地方，记录下来会后修改即可，会议的部分有专门的主持人负责主持工作。
测试对象是功能的改进，如何度量其改进，如何选择度量的对象和指标，如何在测试中去收集这些数据，以及如果设计测试结果分析的部分，都很耗费时间和精力，更难得是得到各方都比较认可的共同理解。不仅仅是在写测试计划的过程中，我修改了无数次，在审核会议上也收到太多太多的修改意见，以至于主持人不得不总结说我们还需要召开第二次会议重新审核。一般来说在审核会议上，如果修改意见不多的话，只需要修改好之后邮件发出更新后的版本，大家通过邮件再给反馈即可，只有当修改意见实在太多的时候，才需要按照正式流程再召开一次会议。幸好，第二次审核后，测试计划获得大家的认可通过批复。
由于我们要求在设计的测试用例中除了写明测试步骤，每一个测试步骤都要给出建议执行的操作或者命令，这意味着其实在设计测试用例的时候，我们就必须得实地执行这些命令，或者执行一些命令组合，并从中选择有效果的部分放入测试用例中。而在这个过程中实际上要重复执行相同的命令、命令组合甚至测试用例很多次，绝对具备了将它们进行自动化的需要。我本来就同时担任着测试自动化小组的工作，也将测试自动化的理念运用到自己手头的测试任务上是顺理成章的事情，也正是在这个时候，我开始坚信“任何操作，第二次执行的时候就是将其进行自动化的时候”。我很懒，所以我总想着有没有什么操作是可以拿出来写成一个函数，或者做一个简单脚本，在执行某些操作前执行这个脚本省去我手工操作。当时，测试质量管理部门对于测试自动化是有标准的，只需要将测试用例集合中可以、适合、便于实现自动化的部分实现脚本化即可。而我的测试任务完成后，所有的测试用例全都有相应的测试脚本，就连那种本来是要走到实验室里去亲自把板卡从插槽中拔出来的测试用例，我也将它实现成为了半自动的测试脚本。后来有了远程电源控制的硬件后，可以通过断电来模拟物理隔离，从而实现了脚本全自动执行。当然再后来，测试自动化小组壮大变为测试自动化团队后，他们实现了Tcl/Tk语言连接外部设备，还可以操控AX400这类之前必须靠手工操作的设备，可以进行全自动化的承载性能测试了。
这一次的测试任务帮助我学会了如何在信息模糊的情况下去界定测试边界，以及选择测试方法。饱受信息不完整以及不清晰的折磨，我也特别注重去改善这方面的状况，功能需求规格说明书、设计文档、实现文档等资料的更新改进都有我的贡献。在测试报告中我也写得格外详细，不只是记录当前执行的结果，一些很好用的命令或者测试技巧、注意事项，我也都一一写入测试报告，以及更新到相应的测试用例当中去。藉此我希望能够免去后续测试人员苦寻资料之苦，只要看到之前一个版本的信息既可，用不着再去寻根溯源浪费气力。不过，资料做得再全面也不够，还需要人的手把手协助，后来我把这一块的测试负责工作移交他人时，也费了不少心思去辅导对方，只可惜对方似乎心不在焉没有太注意吸收我的讲述，更可惜之后不久还未曾经历太多实战该测试人员即转战他方，知识的传承纽带再度断裂，后续接受的人有得重新去追根溯源一把。此话绝对不假，在我已经担任敏捷教练职务，也即是离开大模块测试岗位近三年后，还有人根据测试相关文档中的作者信息找到我问问题，只可惜我当时就算记忆力再好也无法保证提供给他的答案绝对准确，更不要说在这三年里，大模块自身也不断地有新功能增加或是缺陷被修复，我的记忆已然不再是第一手信息。
相关链接：
我的软件测试之旅：（1）起点——作为软件开发人员
我的软件测试之旅：（2）转变——作为专职测试人员
我的软件测试之旅：（3）同期——加入测试自动化小组
我的软件测试之旅：（4）并行——自动化回归测试