不少介绍微软测试过程的文章都强调大量运用自动化测试，给人一个只要有了自动化测试，整个测试过程就得到保证的印象。不可否认自动化测试的作用，但是对于下面两个问题：

“自动化测试总是任何时间内、任何条件下、任何项目阶段中的最佳选择吗?”

“进行/不进行自动化测试的决策是怎样做出来的?”

答案会是什么?

为了回答这两个问题，我想分享一个真实的微软测试项目的经验。

在这个项目中需要关注两件事情：设置向导和客户体验改进计划。

设置向导，或者安装向导，相信安装过软件的朋友都知道，就是引导用户完成一系列操作的一种界面，具有连续出现的窗口，每个呈现不同的内容，使用户每次只关注特定的项目从而容易完成复杂的全部操作。

客户体验改进计划(Customer Experience Improvement Program，简称CEIP)就不是那么为大众所了解。实际上Windows系统中有这么一个缺省关闭的选项，如果用户打开了，关于用户如何使用微软软件的信息，例如常点击的菜单项有哪些、缺省选项被改动为哪些值等等，会被Windows系统自动记录下来并定期发送到微软的服务器。专业分析师会解读这些数据，从中发现微软软件设计上的潜在缺陷：它们会导致用户迷惑、误解，以致无法正确使用某些功能。

这里要测试的功能，就是为某处设置向导添加CEIP的记录动作。第一次接触这个新事物，不少测试工程师的通常反应是，模拟用户在设置向导中的操作，然后观察CEIP的记录数据对不对，完事。

自动化测试更是小菜一碟：驱动用户界面操作本不是难事，何况测试设置向导本身功能的工程师已经做好了一切，借花献佛就好了;CEIP的记录数据也是拿已经做好的函数读一下记录，然后跟预期数据比较就好了。

表面看是如此，但如果这就是故事的全部，那就没有说的必要了。实际上，这只是冰山浮在水面上的部分。

先考虑一下两个问题：

这个功能没测试好的后果是什么?

CEIP是用于指导下个版本的可用性(Usability)设计的。如果里面的缺陷导致不准确的信息，那么CEIP分析师会被误导从而得出不反映真实情况的结论。例如，本来用户很常用的一个菜单项“打印”，被误记录为“属性”的话，结论会是“打印”没什么人去用，“属性”倒有不少用处。那么开发下个版本的软件时，根据这个“据说从真实的用户统计数据得来”的结论，很可能“属性”被放到显眼处，很常用的“打印”反而被藏起来了。不要争辩哦，这是被大量用户数据所证实的嘛。所以，CEIP是把双刃剑，不准确的数据比没有数据更糟糕。

这个功能没在测试中发现的缺陷，会被谁、什么时候发现?

很多测试中没发现的功能缺陷，发布出去之后用户迟早会发现。唯独这种CEIP的功能，用户除了打开或者关闭之外永远不会去接触：用户为什么要关心CEIP记录得对不对呢?事实上这些功能缺陷用户不知道，微软也不一定知道，只会根据CEIP数据调整设计。除非之后的若干个版本改得实在太过分以致怨声载道，或者跟用户调查的结论相差实在太大，才会惊觉可能是CEIP的问题。所以CEIP数据的缺陷，是一个不定延时引信地雷，埋下去就难以挖出来，而且要挖出来还极为麻烦：怎样回应用户“上几个版本都是这样的，我都习惯了为什么又要改”的质疑?“根据CEIP数据决定这样改，但后来我们发现CEIP数据错了”?(用户一脸茫然：什么是CEIP数据?跟我有什么关系?什么叫做记录我做过的事?你想说这是我自作自受的结果吗?)

综上所述，这个功能不是对着界面点击一通就能看出对不对的，测试人员还需要观察记录下的数据并与做过的操作相对照;测试用例需要持续的在多个版本中执行以防范回归缺陷(Regression Bug);测试这个功能，防止缺陷被埋进去具有更高的价值，因为事后很难挖出来。

表面上看，似乎自动化测试是板上钉钉的事：人工测试很难;还需要反复执行。但请考虑一下最初提到的一个问题：“自动化测试总是任何时间内、任何条件下、任何项目阶段中的最佳选择吗?”

回答这个问题之前，请先看看加入CEIP之后设置向导有什么变化：

设置向导在每一页收集用户的输入，直到“完成”按钮被按下，然后拿着设置的数据往指定的地方一一写入。加入CEIP之后，如果用户按“后退”按钮呢?

放在以前，如果“前进”按钮没有按下，用户输入不会生效，所以“后退”就是界面改为前一页，没什么大不了的。现在就不一样了，“后退”意味着某些状态发生了变化，如果那些状态要被CEIP记录，那就是一个值得关注的问题。

别忘了添加CEIP的初衷是暴露潜在的Usability缺陷。用户成功的走过各个页面并完成设置，这是需要记录的成功案例;用户感到迷惑不得不中途退出，这也是需要记录的失败案例;用户后退到之前的页面来重试，更是需要记录的失败案例。每个案例都需要记录些什么数据，视情况而定，但不外乎“当时状态”。

请注意，没有CEIP的时候，设置向导关注的是“最终状态”;有CEIP的时候，还需要关注“当时状态”。我要问一个问题，如果当初不考虑CEIP，一个设计设置向导的开发工程师，能一早想到要维护“当时状态”的可能性有多大?

显然，这是一个非常容易引入缺陷的地方、非常需要在把缺陷埋进去之前就采取行动的地方。那么，自动化测试在这里能帮到我们什么?

防范回归缺陷吗?前面说过，太晚了。况且在自动化测试程序写出来第一次运行的时候，缺陷就已经被发现了;等到发现回归缺陷的时候，像前面说的，情况更尴尬了。

进行人工无法执行的测试?跟前面说的一样，在自动化测试程序写出来第一次运行的时候，缺陷就已经被发现了。我们如何才能够在把缺陷埋进去之前就采取行动呢?

其实，这里更需要的是在设计层面或者是代码层面的审核和分析。你可以称之为白箱测试，但我侧重于设计测试用例的过程而不是执行它们的过程。

假设你是开发工程师，你会怎样设计这个功能?也许会维护一个数据结构，或者沿用已有的结构，在向导页面变化或者用户输入变化时更新它们，在恰当的时候调用CEIP的API把它们记录进去。

假设我是测试工程师，我会列出引用这些数据结构的地方，观察它们是怎样被修改和读取的，思考用怎样的输入，环境条件和执行顺序/时序打破设计或者代码中蕴含的假设，使得进行CEIP记录时它们不能代表真实情况。例如，倘若设计中没有维护“当时状态”的话，一个包含“后退”的动作序列就可以打破原有的假设了。

我还会找出跟相关状态变化有关的界面消息响应，观察所有这些响应最终能不能正确作用在相关状态上。这是容易被忽略的部分，前面基于引用的方法并不能覆盖这种连引用都没有的情况。

当你找到能打破假设的测试用例时，你并不需要执行它就已经可以知道有没有缺陷了，因为它来自于你对设计或者代码的攻击性思考。在真正执行之前，你已经在脑子里执行过一次了。

甚至，你并不需要覆盖所有的用户动作和输入，因为经过设计和代码审核，你已经知道哪些因素跟CEIP相关，有些测试用例是无关和浪费时间的。

可见，为了在把缺陷埋进去之前就采取行动，自动化测试用处并不大，多从用户的角度思考，多分析设计和代码，取得的效果更好。这里我所采取的决策是：

- 分配较少时间在自动化测试代码编写上

- 利用代码分析工具，结合设计说明，跟踪CEIP所记录的数据的来源，以及与用户场景(User Scenario)的关系

- 根据状态机设计的经验，检查当前设计能在多大程度上满足反映“当前状态”的需要

然而我们还是要坚定不移的把想到的测试用例在自动化测试中实现出来并定期执行，并不因为前面说的就把它丢在一旁。

第一，上述在设计层面或者是代码层面的审核和分析不可能，也不必要每天、每次修改代码的时候都做一次。如果有无需人力的验证方法，它就比需要人力的方法优胜。只有设计变动对CEIP功能有足够大的影响时，才会再次分析那些影响。

第二，修改代码，并不一定都是改动CEIP的功能，也就是说，别人、别的团队也可能去修改，同时你不一定还在测试这个功能。“铁打的营盘流水的兵”，这些自动化测试用例，就是铁打的营盘，保证软件质量不会因为流水的兵而崩溃。

上面说的就是决策做不做自动化测试的一个例子，以及期间所需要考虑的各种问题。在微软，自动化测试只是一个工具，做不做、什么情况/时间做，都是全盘分析的结果。就算绝大多数团队都在做，也只是一个结果，而不是原因。独立自主的思考，深入细致的调研，扎实的系统分析能力，代表用户说话，才是微软赞赏的卓越工程。