三、名称别名问题：大部分系统都会涉及到对象的名称和别名的问题，在UI测试过程中，如果名称作为存储数据库表的主键，那么该名称即不可修改，也不需要修改。别名的存在弥补了这一不足，在名称确定的情况下定义别名就是为了提供给客户自定义对象的权利，让用户对自己需要使用的对象提供自定义名称方便使用。在测试过程中我们测试人员要时刻关注被测试的对象显示的情况，这一点，firefox的fidbugs和google浏览器自带的消息返回检测机制做的很好，详细的显示出当前查询、添加等操作返回的结果以及页面上显示的内容。一般情况下用户修改完成别名之后，在所有该对象的地方都应该显示别名而不是名称（在测试的时候多留心），此处还有一个需要注意的地方就是名称被“写死”的情况，这种情况主要出现在根节点的情况，因为一个系统只有一个该对象，很容易被UI开发人员写死，心想反正不会改变的。殊不知这个也是对象，也会被修改别名的情况。
四、多页面连接相同页面的回退问题：不知道兄弟们有没有这样的场景：C页面是完整的页面，A在调用的需要过程中嵌入C页面，B接口在调用的时候也需要嵌入C页面，这种情况在之前的系统和现在的系统都出现过，每次回退都让我很纠结。按照客户的使用习惯，回退的情况属于使用到一半不想继续下去或者误操作，那我们的回退的情况就应该和主流系统一样，从哪个页面来就回退到哪儿去。可是我们的系统基本上都会直接复制前端代码，这样的回退操作都是回到一个莫名其妙的起始页面上去了，让人丈二和尚摸不着头脑。果断提单。
五、UI和接口的不同步问题（包括相同对象限制不一）：原则上接口和UI上都需要使用相同的限制，如最大值限制和字符限制，要求是接口允许的长度和字符数的限制比UI略松或者相等，不能出现UI允许但是接口无法完成添加数据入库的情况。这样就出现页面允许添加而接口下不去的情况。还有一点就是相同类型的对象的限制一定要统一，例如名称长度，描述允许的字符数，是否允许空格，如果开发人员无法提供，那么你可以招集SE和开发人员，确定了规则，UI测试如果没有规则，这个皮不知道要扯到哪儿去了。
六、易用性问题：这一点没什么说的，看使用习惯，你就是客户，以你使用舒适为佳，仁者见仁智者见智，不好说什么，觉得不爽就可以提，开发不同意就提交SE裁决呗。
第二篇写的时间相隔有点久，有点狗尾续貂之嫌，不足之处还请兄弟们多见谅，多多交流。
向顺利哥学习
