UI 测试的苦恼

看了一下web UI的测试方法,工具,也在项目中使用了一段时间,
UI测试方法的原理都是模仿IE的行为,录制一系列的页面操作(登陆,提交,查询等),
然后对结果页面的关键数据解析出来后和期望的数据进行比较,
也就是assertion,可实践中发现,页面逻辑经常会发生变化,
所以完成的automation test script在页面变化后经常就
fail了, 造成测试脚本的不稳定性,不停要跟随页面修改而修改,
不知道大家有没有遇到过这种情况,如何改善呢?

if the Ui has been changed, you must update the test codes, but how to abstract the ui, that is key point for ui automation test.

办法是不要变UI
呵呵 这是废话
其实脚本工具可以很大程度上帮助你做到达测试了，但是超出到达测试的范畴用脚本就吃力了。
如果只做到达测试脚本录制和维护应该不会太复杂。
如果你在脚本中包含了一些业务逻辑的判断，那么当界面逻辑发生变化时你的测试脚本的变化将很笨重。这就需要考虑将这些业务逻辑的测试分离到单元测试里去。使得测试脚本可以轻快一些。

到达测试是什么概念?

UI的到达测试 指覆盖你所有的用户可以进行的操作
说UI相对固定的产品可以用脚本工具测试是为了避免你每发布一个版本都需要你的测试人员把所有按钮都点一遍 一定程度上降低成本

可是要想在UI上跑一遍所有用户可能的操作,必然会以业务流程为case,
而判断这个流程跑的正确与否,就需要对页面中的东西进行验证,
比如新建一个货单,提交,入库,每一个返回页面都有一些关键词,
比如insert successful/insert failed,脚本中需要找到并验证这些词,
以判断流程的正确性,但页面变化时,脚本就很难维护了,可能改一个
脚本比重新写都废时

所以脚本测试工具是否适用和你的业务实现方式很有关系。如果你的UI都是用户自定义的，那么想要用脚本测试工具来测试自然会有很大的困难，至于你说以业务流程为case就是我之前说的将业务判断放到了脚本测试工具中，脚本测试最适合判断的是有没有在该弹出窗体的地方弹出窗体，有没有在不该弹窗的地方抛了错误等等，但是如果你想要用一个脚本测试这个业务单流转到另一个人时的状态，本身就高估了脚本测试工具的能力了。
使用脚本工具是为了减少一些你的测试人员的重复工作，测试一个界面上的所有功能，例如：预览和打印等一般很少修改的功能，你不好要求你的测试人员每拿到一个版本都去点一遍吧。这些工作应该交给脚本工具来做，至于上面讨论的流程是否正确的问题应该要人来测试。具体什么工作应该脚本工具来做，什么工作应该人来做？我认为唯一的衡量标准就是成本，如果你出得起测试的人力成本，全部都用人力测也没有什么关系。但如果你本来就人手不足，脚本工具应该在某些条件下可以提供一些帮助。

我看楼主的情况就是不太适合自动化测试。