让测试也敏捷起来

　　第一个是要让测试人员及早参与， 至少不能晚于开发人员。 当有了"fix the bug before the fact"的意识的时候， 无论测试人员多么早参与都是有事情可以做的。

　　第二是要做"psychical test" (我根据psychical debug发明的词， 可反以为思维测试)。 通俗一点， 是要从一开始对spec和design进行测试， 而不是等到代码出来后。 让测试人员及早参与是实现这一点的基础。 比如当详细需求出来后， 仔细阅读需求文档， 根据我的经验， 往往能找到很多互相冲突矛盾的地方。 当设计文档出来后， 思维测试更为重要， 而其中的关键是要抓住细节。 我发现大多数团队在做spec review的时候， 都不会太深入细节。 一个设计， 整体看起来没问题， 模块分工没问题， 那基本上算过了。 所谓深入细节， 是要求把所有能想到的可能性， 案例， 数据流动， 性能， 可扩展性等等， 无论优先级高低， 都尽可能地拿到这个设计中用思维走一次。 有问题的地方立刻写下来和开发人员确认清楚。 如果思维测试走过去比较困难， 可以立刻写一个prototype来证明。 相比代码出来后， 在这一个阶段消灭掉bug只需要1/10不到的开销。 所以千万不要浪费spec/design review的时间。

　　第三是深入代码实现。 通俗点说， 是要test做到和dev一样熟悉产品代码。 我承认这一点有很有争议性， 可能更多的只能代表我的个人习惯。 深入代码实现不同于白盒测试。 深入代码的目的， 在于了解具体实现所付出的风险， 以此作为依据安排测试。 比如抓取关键字的功能来说， 使用正则和使用自己的parser都可以做到。 如果使用了前者， 那对性能方面往往需要测试的更多关注。

　　另外， 我认为作者对于UI自动化的认识有些极端。 作者觉得UI自动化不应该超过20%。 UI自动化不稳定， 前端的UI变化导致UI自动化维护成本很高。 我虽然说只做了3年的测试， 但其实测的都是UI， 而且是WinForm和WPF， 不是HTML。 作者提到的原因都是正确的， 我深有体会， 但并不等于说没有解决办法。

　　首先， UI自动化已经有相当成熟和稳定的Windows API了。 相比几年前通过Windows Message和屏幕位置的实现来说， 现在通过UIA来实现UI自动化非常稳定， 而且都是C#的实现。 项目中我们可以使用录制工具， 但是我们发现其实直接写代码来的效率更高， 只是偶尔借助工具自动生成代码。 UI自动化的性能， 稳定性， 主要还是取决于实现的质量。 实现的开销， 其实现在和API Automation相比， 我认为UI多多20%而已。 如果是测试HTML的UI， 那更加简单和稳定了。

　　其次， UI自动化的维护其实是取决于测试代码的质量。 当UI发生变化的时候， 我相信都是渐进的。 只要UI自动化代码设计合理， 这种渐进的维护其实很容易。 举个例子， 假设login。html发生变化了， 理想的情况是之需要更新自动化代码的资源文件。 如果逻辑也要变化， 那可能需要修改login UI proxy的代码， 但是接口是稳定的。 再不行， 那login这一步现不走UI了， 简单修改config替换成非UI的provider实现走http post好了。 所以， UI自动化并不难， 开销并不大。

　　UI自动化提供的价值并不能被其它自动化替代。 因为UI才是客户真实使用的。 而且很多简单的UI操作其实可以覆盖底层多个API， 完全是简单实现达到大覆盖率。 和API自动化更不同的是， 很多bug只在UI自动化下面才容易暴露出来， 这主要是UI操作对timing非常敏感。 在我做的几个UI相关的产品中， 几乎都出现了当主界面刚出现， 立刻操作导致崩溃的问题， 而且这样的问题都是UI自动测试中暴露出来的。

　　所以对UI自动化， 不应该简单地边缘化， 而是找到正确的解决方法。