我们的测试为什么不够敏捷(3)

　　【注】业界常见的测试工具本质上还是针对页面源码来编写(或生成)测试脚本的，即使提供了录制工具，此类脚本的可读性和后期可维护性还是非常差的。

　　3、 断言条件繁琐

　　业界常见的测试工具即使提供录制脚本的功能，但是对于“断言”还是需要人工插入的(工具做不到智能的判断我们想要在哪里设置断言)，于是断言就成了自动化测试人员的“噩梦”。

　　断言对象可能很“多”,页面的信息量往往很大，需要在测试脚本中为每个断言对象(比如，页面某个文本框的值)补充断言语句。

　　预期结果是可能“变”化的，甚至是动态的，因此预期结果的值如果与脚本逻辑耦合在一起，将来极难维护。 断言机制比较“呆”板，对于 未设为断言对象的字段，如果发生错误也是无法感知的，并且难以对于UI样式或UI逻辑(比如，翻页图标应该灰显)进行断言。

　　换个角度可以理解为，如果这样的断言条件“多”的话，整个测试用例集会“变”的非常“呆”板!

　　想要有效的改善这些问题，就必须让自动化测试变得“敏捷”起来!

　　在本系列后续的文章中会就“如何让测试脚本易写、易读、易维护”、“如何让断言不再成为测试的负担”、“如何通过持续集成让测试用例发挥更大的价值”进行详细的介绍，敬请关注!

原文转自：http://www.infoq.com/cn/articles/test-no-agile-enough