敏捷测试要求测试能够测试在“短的时间间隔内持续发生”且能够在“短时间内完成”。考虑到纯粹的依赖人工测试基本不可能达到“短的时间间隔内持续发生”和“短时间内完成”这两个目标,而自动化测试在执行效率方面具有天然的优势,在敏捷测试中使用自动化测试技术应该是自然而然的选择。
考察敏捷开发中的一个迭代周期,在迭代周期开始的时候,团队与客户一起定义本迭代周期内需要完成的功能;开发工程师开始实现新功能,使用持续集成尽可能保证每一次代码提交不引入新的缺陷;所有新功能被添加后,回归测试保证原有功能的正确性;针对新功能运行测试保证新功能的正确性。
如果依靠手工测试来进行这些项目,毫无疑问,测试会成为整个敏捷开发的瓶颈。而如果把这些项目中的测试建立在合适的自动化测试基础上的话,测试就可以和开发一起敏捷起来。从这个角度来说,把自动化测试描述成“敏捷测试的基石”毫不夸张。
自动化测试项目为什么会失败?根据调查,“不合适的自动化测试目标”与“从自动化测试中无法获得收益”是项目失败的主要原因。希望把自动化测试定义为“完全替代手工操作”、期望仅仅“在UI层建立自动化测试”都不是合适的自动化测试目标;尤其是“在UI层建立自动化测试”这个目标一定会带来无法从自动化测试中获得收益的后果。
UI自动化测试是自动化测试领域中较早被研究的,其主要出发点是使用工具和脚本驱动应用操作,依靠工具对UI层的元素属性进行验证。现有的大部分商业测试工具,如IBM Functional Tester、HP QTP、Testbird等都属于这一类工具。从好的方面来说,UI自动化测试相对其他自动化测试更接近真实用户;但不得不说的是,UI自动化测试的高昂的投入往往是组织不能持续进行自动化测试原因。
UI自动化测试带来痛苦的主要根源在于UI本身的不稳定性。由于UI是应用与用户的直接交互界面,用户的大量需求都直接对应在UI本身的改变上,这就导致了UI本身的不稳定,建立在UI上的自动化测试也因此不稳定。当然,除了不稳定外,UI自动化测试带来的测试环境的需求也是导致UI自动化测试开销剧增的原因之一;另外,UI自动化测试本身并不能很好的帮助定位缺陷,对开发工程师而言,其在反馈上的价值远不如单元测试。
有疑问加站长微信联系(非本文作者)