用户体验，简单的说就是用户使用方便，用户使用方便说起来容易，但作为测试怎么样才能衡量“用户使用方便”，你提出来的用户体验问题如何才能说服开发或者UED去修改呢?很多做过测试的人在测试的过程中多多少少都会遇到一些这样的问题。可能大家平时遇到一个功能就是用的不爽但也说不出个所以然来，像这样公说公有理婆说婆有理，最后问题得不到好的解决。导致上线后出现一系列问题，伤害用户伤害公司伤害自己。

         很多时候我们可能都是通过主观意识来做事情，尤其对待用户这块。大家平时都在说要站在用户的角度去思考问题，去做事情。平时我们提出的所谓用户体验的问题，也都这样说“我是站在用户的角度来考虑的”，但是这些语言总是显得苍白无力。为什么？我一直在思考这个问题。静下心想想，我们真的是站在用户的角度吗？我们真的了解用户吗？我们的依据是什么？其实不光我们测试，任何人都需要思考这些问题。

        单就测试这边而言我觉得我们可以在测试准备阶段加上用户数据和用户行为的收集，采集这一环节。作为测试过程中我们测试工程师用户体验测试一个强有力的依据。让我们真正代表用户去提出问题，解决问题。最终达到用户和公司都满意！
        说归说大家可能在想我们后续如何去收集数据？什么人去收集？收集哪些数据？收集完数据如何利用好这些数据？是否每个项目都适用？用完是否真的对我们的用户体验有所帮助？投入与产出是否成正比？

        针对以上问题我拿一个某功能模块改造项目为例来尝试回答以上问题。项目立项之后由需求人员对该改造的项目的用户类型以及每种用户的行为进行分析，并从数据分析部门（上一个项目发布后会对数据分析部提出这样数据采集的需求，等到下个项目来临就可以轻松获得数据，形成一个循环）收集相应的数据产出一份用户数据报告。测试人员（其他人员可能也会利用到这份报告，我这里单讲测试人员如何利用这样的数据）拿到这份数据报告，在测试准备阶段，根据这份报告产出相应的用户体验测试用例以及用户体验实体数据，这些数据可以自己造，当然必要的情况下也可以找DBA协助。准备工作完毕后 在集成测试执行阶段进行到各功能模块基本稳定就可以执行我们的用户体验测试用例啦。当然根据实际情况用户体验测试也可以提前一点来做。执行完毕并产出用户体验执行报告。等到项目达到发布条件就可以发布啦。

         项目发布后我们就可以对我们的用户体验测试的效果进行评估了。需求人员跟踪用户反馈问题结合我们产出的用户体验执行报告进行综合评估，看看我们测试所做的用户体验测试是否真正对用户有帮助。通过过程中采集相应的用户体验的工作量与我们测试出来的用户体验问题带到线上的代价预估最终得出投入与产出比。还可以对项目之间进行横向的对比，看看哪些项目适合这么做，哪些不适合这么做。