敏捷测试-快｜思维发条

小李飞刀，例无虚发。只出一刀，无人能挡，只因天下武功无坚不摧，唯快不破。

相比敏捷开发的火遍地球，敏捷测试就低调太多了，我们所熟知的敏捷宣言又名敏捷软件开发宣言，内容及其遵循的十二条原则没有提到关于敏捷测试的只言片语，作为测试人员出身的我真是感觉莫名的心塞啊。别急，让我们仔细研究研究敏捷宣言，咦，貌似有了新的发现！

“可工作的软件”、“持续不断地及早交付有价值的软件”，都跟测试有着剪不断理还乱的关系。不同于敏捷宣言的含蓄，工程实践就直接的多，“测试驱动开发”、“行为驱动开发”，哪一个能离得开测试？既然敏捷追求“快”，那么“快”当然也是敏捷测试所追求的。

敏捷强调测试与研发并行，强调提前测试，强调及时反馈提交代码质量，强调持续交付可用软件。。。这些强调，无疑增加了测试的工作量，如果依靠传统的手工测试，那结果只有一个，失败！那么如何能做到这些强调呢？答案当然是自动化测试。自动化测试相比手工测试有着不可比拟的优越性，执行效率高，及时反馈，持续验证。。。

自动化测试概念由来已久，笔者十多年前刚工作时候自动化测试就已经很流行，当然那时候流行UI自动化测试，即通过模拟人工操作来实现自动验证。UI测试工具也有太多选择，Rational

Robot、WinRunner、SilkTest、QTP等等，笔者当年做自动化测试的时候选择了非主流工具Testpartner，花了大半年的时间实现了80%的覆盖率，每次版本转测试，虽然可以起到回归的作用，但是面对很多的测试失败也是无能为力，每次都需要手工筛选，然后再花精力进行脚本维护。笔者的经历还算比较好，起码每个版本都还在使用，能够起到回归的作用。比较残酷的是，超过50%的UI自动化测试尝试都以失败告终。UI自动化测试之所以经常以失败告终，大部分原因都是UI变更导致，UI的频繁变更，使得自动化测试脚本的维护成了不可承受之重。

从那张著名的测试金字塔可以看出，UI自动化测试应该占到很小的比例，比例这么小，UI自动化实现的范围就是个学问了。该如何选择呢？大部分人选择的是将冒烟测试的内容实现UI自动化，既然冒烟测试每次都会人工验证，那我们何不实现一些更有价值的内容呢？答案是经常变更的TOP10功能。如何得到呢？试试配置管理工具吧。工具？你可以接着用QTP，当然墙裂建议你了解一下CUCUMBER！

除了UI自动化测试，单元测试和接口测试（业务逻辑测试）应该实现更高的覆盖率，之前我们有一篇文章介绍过接口测试，请回复“测试”查看。至于单元测试，不会期望测试人员实现吧？单元测试和接口测试相比UI自动化来说有很多优势：方便定位问题，运行速度更快，更稳定，代码更容易维护。。。

自动化测试是敏捷测试不可分割的一部分，无自动化不敏捷！