用户体验质量的测试因为涉及到很多人直观感觉的判断，导致了一直以来没有好的测试评判标准。虽然有一种用户体验实验室通过录制用户操作的眼球变化来记录用户行为，推断用户体验效果。但是让我想起了经典的检查空香皂盒的故事：生产线要检查出空香皂盒，有家公司投入多名专家研发了一套激光系统来检查，一家小公司的工人想出用风扇吹飞空香皂盒的方法。对于绝大多数的同行公司更适合风扇方案因为经济实用，实施快。不是所有公司都有条件建立用户体验实验室来录制用户操作眼球变化。那么有无一套“风扇方案”简单有效地发现软件产品用户体验质量的质量问题。类似的问题有：如何发现微软地图中的路线错误问题，如何发现图片搜索中搜索结果图片集质量差的问题。我曾听过一个经典的案例分享：微软一个实习生在不知道微软地图搜索任何实现算法的基础上，建立了一套只有几百行脚本的测试判断系统就能对百分之九十多的地图线路进行用户体验质量的判断和质量保障，这是一种逆向的真正地以用户体验来基准的测试，而不是验证算法实现有无程序错误。自从听了这个案例后，我一直都在思考如何把微软地图测试案例的思想应用到其他软件的测试中。

　　最近终于有所收获，并在产品中进行应用。在此把总结出来的用户体验质量测试的方法论与大家做一个分享，也请大家拍砖给各种意见。

　　第一步：收集10－20款你产品领域的其他产品

　　第二步：安排不同角色的3－4名同事对第一步收集的所有产品进行输出结果质量最严格的评价，每个评估同事至少为每一个用户体验不好的产品输出5－10条不好的“现象”，注意是“现象”不是“原因”

　　第三步：汇总所有不好的“现象”，提炼出高概率有共性的“现象”列表。

　　第四步：共性“现象”列表就是你用户体验质量测试结果的判断标准，这些判断标准是任何一个测试人员都能执行判断的，这就是你的“风扇方案”。

　　对于某些产品甚至可以实现自动化用户体验测试执行。

　　背后的逻辑和方法论：

　　逻辑1、大多数人都能发现严重不好的用户体验现象

　　逻辑2、同领域产品解决同样的用户需求，会表现出大多数相同的用户体验质量问题现象

　　逻辑3、用户体验不好的现象会有多种badcase现象类型，产生问题的设计和实现根因会有多种可能，你无法事先正向知道所有设计组合的badcase效果，但是一旦出现了质量差的用户体验现象，那么一定是产品设计和实现出了问题，具体根因再继续定位分析。

　　虽然不是所有的用户体验质量测试都可以自动化实现，但是有一部分产品是可以实现自动化的挖掘用户体验质量badcase的，其核心思想之一：抓取产品输出的badcase现象，即使不能自动判断出所有badcase现象，只要能自动挖掘到部分badcase现象也能证明产品的设计或实现存在用户体验质量领域的问题。限于工作原因，具体应用案例暂不公开请理解。