为什么要做自动化测试?(2)

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

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

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

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

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

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

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

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

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

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

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

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

原文转自：http://www.uml.org.cn/Test/2008061310.asp