三、名称别名问题：大部分系统都会涉及到对象的名称和别名的问题，在UI测试过程中，如果名称作为存储数据库表的主键，那么该名称即不可修改，也不需要修改。别名的存在弥补了这一不足，在名称确定的情况下定义别名是为了提供给客户自定义对象的权利，让用户对自己需要使用的对象提供自定义名称方便使用。在测试过程中我们测试人员要时刻关注被测试的对象显示的情况，这一点，firefox的fidbugs和google浏览器自带的消息返回检测机制做的很好，详细的显示出当前查询、添加等操作返回的结果以及页面上显示的内容。一般情况下用户修改完成别名之后，在所有该对象的地方都应该显示别名而不是名称（在测试的时候多留心），此处还有一个需要注意的地方是名称被“写死”的情况，这种情况主要出现在根节点的情况，因为一个系统只有一个该对象，很容易被UI开发人员写死，心想反正不会改变的。殊不知这个也是对象，也会被修改别名的情况。

　　四、多页面连接相同页面的回退问题：不知道兄弟们有没有这样的场景：C页面是完整的页面，A在调用的需要过程中嵌入C页面，B接口在调用的时候也需要嵌入C页面，这种情况在之前的系统和现在的系统都出现过，每次回退都让我很纠结。按照客户的使用习惯，回退的情况属于使用到一半不想继续下去或者误操作，那我们的回退的情况应该和主流系统一样，从哪个页面来回退到哪儿去。可是我们的系统基本上都会直接复制前端代码，这样的回退操作都是回到一个莫名其妙的起始页面上去了，让人丈二和尚摸不着头脑。果断提单。

　　五、UI和接口的不同步问题（包括相同对象限制不一）：原则上接口和UI上都需要使用相同的限制，如大值限制和字符限制，要求是接口允许的长度和字符数的限制比UI略松或者相等，不能出现UI允许但是接口无法完成添加数据入库的情况。这样出现页面允许添加而接口下不去的情况。还有一点是相同类型的对象的限制一定要统一，例如名称长度，描述允许的字符数，是否允许空格，如果开发人员无法提供，那么你可以招集SE和开发人员，确定了规则，UI测试如果没有规则，这个皮不知道要扯到哪儿去了。

　　六、易用性问题：这一点没什么说的，看使用习惯，你是客户，以你使用舒适为佳，仁者见仁智者见智，不好说什么，觉得不爽可以提，开发不同意提交SE裁决呗。

　　第二篇写的时间相隔有点久，有点狗尾续貂之嫌，不足之处还请兄弟们多见谅，多多交流。