界面，和用户直接打交道的地方，重要性我想也不需要我多说，能够给客户第一印象你这个系统做的怎么样，通常我们会上一些网站或者系统，然后吐槽这个界面的设计，根本没考虑到客户的使用感受云云，顺便鄙视一下那个公司的测试人员（同行是冤家），根本没有站在用户的角度思考如何测试。那么，UI如此重要，但是漏测现象确是比比皆是，产品一经上网就被客户提一堆问题的现象时有发生，究其原因，首当其冲的当然是测试，我们客户一经使用就发现那么多问题，你测试了那么多版本怎么就没发现？我们测试和开发交流的时候不常常以客户自居么？什么代表客户测试，可是我们的这个“客户”确实应该检视一下自己的工作，是否存在遗漏。下面笔者以最近的测试过程分享下易漏测点，给自己，也给大家，有则改之，无则加勉。

　　一、大数据量的场景：此现象在很多系统中很常见，由于实验室资源的限制，很多测试环境都构造相对较少的测试数据，大数据量要借助工具而且不一定能够在很短时间内搞定。可是我们从测试角度仔细一分析，这样会掩盖很多现象在测试环境中重现。简单的举例：大数据量的分页是否正常，大数据量检索是否正常，搜索的结果中分页是否正常，删除一条数据后下一页的数据是否能够正常跳转至前一页，多少条数据能够分页，排序是否正常，IE测试的时候是否在左下角有JS异常报出？如果某一个页面需要显示目前选择的数据（例如确认信息页面）是否能够显示完全？这些都需要我们在测试设计的时候就应该考虑的，怎么能够以资源不足作为借口搪塞？客户现场的批量的部署可是真真切切的使用场景，你能和客户说我们资源不足？起码你不是一个职业化的测试工程师。其实这种情况解决的方式很简单，设计的时候考虑，调用性能环境测功能，你的提单效率肯定大大提高。

　　二、权限模块：目前的UI测试大部分是附带用户登陆等功能的，说明系统上网之后是要部署面向各式用户的情况的，目前软件系统对安全要求是相当的高的，很多系统就是因为安全漏洞被打回。当然安全本身是一个很大的模块，我们不便讨论，但是对于UI的功能测试来说，基本的不同角色的用户登陆系统能够看哪些不能看哪些这些总要覆盖的嘛。目前常见的系统都是将权限赋予角色，再由用户是哪种角色来决定用户能够查看或者使用哪些功能。其实这块添加用户的测试一般不会漏测太多，你只需将常用的方法用上，如用户名哪些限制，字符和长度边界值，密码长度，是否符合密码策略，是否采用加密的方法呈现在页面上。漏测点主要集中在权限交叉，读写删这些一交叉，就会懵，其实很多时候开发在做时也没有想清楚，我们作为把关人员肯定要比他们仔细，我们可以借助分析，矩阵的方式，交叉点主要集中在哪些地方，重点测试这些地方，没权限的执行系统会予提示，或者根本就不可见？最后提一句跟UI无关的，测试的时候记得看日志，是否有密码明文打印的地方，密码绝对是不允许直接打印在日志中的，有，就是严重的安全泄露问题。

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

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

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

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