如今，用户体验测试已经不在是什么新鲜的名词，但是在整个测试都还在探索、发展的路程之上时，用户体验测试显得更为孱弱。

        众所周知，任何测试都会花费成本，用户体验测试也不例外。考虑实际收益，用户体验测试的设计需要慎之又慎，它需要对测试的目的、介入时间、测试的周期、场景、人员的选型都要做出深入的分析和界定。

        有关用户体验测试的目的，我想大的概念应该都是基于用户第一而展开，针对不同软件在细节上的关注点会有所区别，可以说它是介入时间、人员选型等其它设计内容的先决条件，其它内容的设定都将围绕它展开。

        目前我们选择进行用户体验测试的一个很重要目的是为了判定我们的产品是否能让用户快速的接受和使用，或者更直接的说法是验证我们的产品是否会不符合用户的习惯，甚至让用户对产品产生抗拒。显然针对这一目的进行的用户体验测试介入时间一定要尽可能的早，试想如果在系统快要发布前才进行该项测试，很可能因为在用户体验测试时发现页面结构不合用户操作习惯，或者有些功能对于用户而言需要强化，或者操作步骤过繁，在不推迟发布时间的情况下，此时对代码进行修改和优化，谁都知道这样的行为无疑是危险的。因此，较为合理的做法是当页面的demo定稿时我们就需进行用户体验测试，但是由于此时的测试是静态的，所以还不足以保证用户实际的操作感受，我们还需要在系统提交功能测试后，当功能测试人员验证主流程已能正常流转，用户体验测试就可以再次介入进来，此时的用户体验测试不需要像功能测试那样关注细节的实现，更重要的是收集用户的操作习惯和使用感受。假使我们不需要说明使用方法用户就可以流畅的进行操作并且在操作过程中不会对操作习惯进行过多的抱怨，那么我们可以认为系统的交互、设计是合理的，反之，我们就需要考虑作出相应的修改和调整。

        说到用户在使用过程中的抱怨，这里就不得不提到人员的选定，可以从这一点很明显的看出，用户体验测试不宜选取熟悉的人，比如同事等，因为熟悉的同事很有可能因为碍于面子不去直接表达自己的感受，尤其是同一部门的人员，极有可能因为长期的接触，导致习惯同化，这就失去了测试本身的意义。或者可以考虑在测试之前，组织测试的人员鼓励用户提出看法和想法，并对这些意见进行客观的分析。并且进行功能测试和组织用户体验测试的人员最好也不要相同，因为参与了功能测试的人员很有可能被局限在系统现有的设计中，而无法全面的收集意见和作出判断。但同时功能测试人员和组织用户体验测试的人员应该要做到及时的沟通，否则就会出现“脱节”。

        此外，个人还觉得用户体验测试并不应该仅仅拘泥于用计划来限制实际测试。在项目功能验证完成之后正式发布之前，任何一个非项目组人员有机会使用到系统（甚至不需要使用，只是了解了系统的部分功能）所提出的建议，都可以认知为一种用户体验测试。整个项目组成员都应该主动将这类信息进行收集，并及时的商讨判定信息的价值，以便作出修改和完善。