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

　　敏锐的开发/测试人员从上面的示例脚本中，可以马上嗅出一些“坏味道(Bad Smell)”: 代码相似度非常高、可能变化的数据被硬编码在测试代码里、代码可读性差、测试代码与页面源码耦合度大，等等。这些坏味道的出现，通常意味着需要进行重构，否则会愈演愈烈，最终变得尾大不掉。

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

　　3、 断言条件繁琐

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

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

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

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

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

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

　　作者简介

　　殷坤，东软集团资深测试经理、技术讲师，10年软件研发、实施、测试及项目管理工作经验。 目前专注于敏捷项目管理及质量控制、过程改善、自动化测试、持续集成、用户体验提升等方面。

　　感谢侯伯薇对本文的审校。

　　给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们，并与我们的编辑和其他读者朋友交流。

原文转自：http://www.infoq.com/cn/articles/test-no-agile-enough?utm_source=infoq&utm_medium=related_content_link&utm_campaign=relatedContent_articles_clk