放在以前，如果“前进”按钮没有按下，用户输入不会生效，所以“后退”就是界面改为前一页，没什么大不了的。现在就不一样了，“后退”意味着某些状态发生了变化，如果那些状态要被CEIP记录，那就是一个值得关注的问题。
别忘了添加CEIP的初衷是暴露潜在的Usability缺陷。用户成功的走过各个页面并完成设置，这是需要记录的成功案例；用户感到迷惑不得不中途退出，这也是需要记录的失败案例；用户后退到之前的页面来重试，更是需要记录的失败案例。每个案例都需要记录些什么数据，视情况而定，但不外乎“当时状态”。
请注意，没有CEIP的时候，设置向导关注的是“最终状态”；有CEIP的时候，还需要关注“当时状态”。我要问一个问题，如果当初不考虑CEIP，一个设计设置向导的开发工程师，能一早想到要维护“当时状态”的可能性有多大？
显然，这是一个非常容易引入缺陷的地方、非常需要在把缺陷埋进去之前就采取行动的地方。那么，自动化测试在这里能帮到我们什么？
防范回归缺陷吗？前面说过，太晚了。况且在自动化测试程序写出来第一次运行的时候，缺陷就已经被发现了；等到发现回归缺陷的时候，像前面说的，情况更尴尬了。
进行人工无法执行的测试？跟前面说的一样，在自动化测试程序写出来第一次运行的时候，缺陷就已经被发现了。我们如何才能够在把缺陷埋进去之前就采取行动呢？
其实，这里更需要的是在设计层面或者是代码层面的审核和分析。你可以称之为白箱测试，但我侧重于设计测试用例的过程而不是执行它们的过程。
假设你是开发工程师，你会怎样设计这个功能？也许会维护一个数据结构，或者沿用已有的结构，在向导页面变化或者用户输入变化时更新它们，在恰当的时候调用CEIP的API把它们记录进去。
假设我是软件测试工程师，我会列出引用这些数据结构的地方，观察它们是怎样被修改和读取的，思考用怎样的输入，环境条件和执行顺序／时序打破设计或者代码中蕴含的假设，使得进行CEIP记录时它们不能代表真实情况。例如，倘若设计中没有维护“当时状态”的话，一个包含“后退”的动作序列就可以打破原有的假设了。
我还会找出跟相关状态变化有关的界面消息响应，观察所有这些响应最终能不能正确作用在相关状态上。这是容易被忽略的部分，前面基于引用的方法并不能覆盖这种连引用都没有的情况。
当你找到能打破假设的测试用例时，你并不需要执行它就已经可以知道有没有缺陷了，因为它来自于你对设计或者代码的攻击性思考。在真正执行之前，你已经在脑子里执行过一次了。
甚至，你并不需要覆盖所有的用户动作和输入，因为经过设计和代码审核，你已经知道哪些因素跟CEIP相关，有些测试用例是无关和浪费时间的。
可见，为了在把缺陷埋进去之前就采取行动，自动化测试用处并不大，多从用户的角度思考，多分析设计和代码，取得的效果更好。这里我所采取的决策是：
- 分配较少时间在自动化测试代码编写上
- 利用代码分析工具，结合设计说明，跟踪CEIP所记录的数据的来源，以及与用户场景（User Scenario）的关系
- 根据状态机设计的经验，检查当前设计能在多大程度上满足反映“当前状态”的需要
然而我们还是要坚定不移的把想到的测试用例在自动化测试中实现出来并定期执行，并不因为前面说的就把它丢在一旁。
第一，上述在设计层面或者是代码层面的审核和分析不可能，也不必要每天、每次修改代码的时候都做一次。如果有无需人力的验证方法，它就比需要人力的方法优胜。只有设计变动对CEIP功能有足够大的影响时，才会再次分析那些影响。
第二，修改代码，并不一定都是改动CEIP的功能，也就是说，别人、别的团队也可能去修改，同时你不一定还在测试这个功能。“铁打的营盘流水的兵”，这些自动化测试用例，就是铁打的营盘，保证软件质量不会因为流水的兵而崩溃。
上面说的就是决策做不做自动化测试的一个例子，以及期间所需要考虑的各种问题。在微软，自动化测试只是一个工具，做不做、什么情况／时间做，都是全盘分析的结果。就算绝大多数团队都在做，也只是一个结果，而不是原因。独立自主的思考，深入细致的调研，扎实的系统分析能力，代表用户说话，才是微软赞赏的卓越工程。
文章来源于领测软件测试网 https://www.ltesting.net/
