当开发做了需求之外的事情时...

   在软件测试阶段，可能我们对软件的需求变更的事情已经很熟悉了，这个的影响，更多的影响到你的测试计划，对软件缺陷的漏测影响还不算很大。但当开发人员，在需求的背后，悄悄地“捅”你一刀－－根据他的想法，修改了计划外的东西！那这就很要命了，测试对需求不可控！很容易就造成了漏测。这在一些走敏捷开发、敏捷测试流程的企业里，算是司空见惯的事情。那么，面对这种现状下，我们该怎么去控制，怎么使漏测的可能性降低呢？

    首页，这个当然得从软件开发流程上去把握了。在流程上，我们可以操作的，一方面是将这个问题暴露给整个流程上的相关人员（可以通过群组邮件或在质量会议上），陈述这种“暗箱”操作的危险性，让PM强调开发流程，同时让开发人员增强这种缺陷的意识。另一方面，我们可以提高版本转测试的门槛。在转测试时，对开发的交付件进行严格审查，特别是对单元测试报告，对版本变更汇总，还可以更强硬地要求开发人员提供修改说明，描述具体修改了哪个模块、修改了哪一行的代码，这样，也可以在一定程度上，让测试人员对版本的修改更有把握，测试的针对性方面也会做得更有效。

    除了在流程上的掌控外，我们还需要从测试技术上来实现真正的自控。为何说是"真正的自控”呢？ 开发流程的东西，要所有人员很正直、很严格地遵守才行，如果开发转测试的交付件里，也很“无私地”不体现他的"额外工作"时，那也只能在我们测试这边来把握了。所以测试要建立在完全不信任开发的情况下（好像这个也应该是测试的本质）。对转测试版本，我们首先可以使用代码比较工具（如beyond compare），对前后版本进行比较，然后我们再根据需求来分析一下代码的修改，这样，我们对修改的合理性，对意外的修改也可以一目了然了，这样在做测试时，更可以有针对性地执行。笔者，曾经就在一个版本中发现开发人员无端去掉了一个加锁的操作（他以为这个线程锁，而我们这个进程现在只支持单线程），然后笔者使用多进程方式，发送交叉请求，问题就出现了。这个就是比较分析代码的功劳（因为这次需求根本就不涉及到多进程，与压力有关）。 还有一种工作就是进行压力的测试，笔者一贯都比较提倡，不管这个版本需求有无涉及到压力的影响。通过压力，我们可以测试一下交叉的请求，也可以关注一下内存泄漏方面的问题。这个笔者也有多次经历。它对于发现并发冲突、内存泄漏方面、性能下降等问题都很有帮助。再一个工作，如果可能的话，可以使用一些内存泄漏工具对软件进行内存泄漏方面的分析（如valgrind，purify等）。在一个版本修改少时，很多开发人员都会忽略对内存泄漏的检查。

    当然，以上这些方法需要具备一定的条件。如需要有质量管理这概念、测试可以接触源代码等。

    以上内容，纯属笔者亲身体验，有感而发。望各方朋友，多加指点。