正式的可用性测试，整个筹备、执行、反馈周期，至少在5天。这也许不长，但绝对不短。尤其在企业环境中，凡事求快，5天已足以使问题变成“下期优化”、 “以后再考虑”的旧账。另外一重时间上的矛盾源于开发流程。原型阶段执行可用性测试，可修改的机会往往更高，但原型低保真，与真实使用场景较为脱节，测试结果发生偏差的风险高。开发阶段执行可用性测试，尽管仿真度高，但发现问题后可修改的机会非常有限。

　　基于这种矛盾，需要一种折中的方 案，既保证充分发现问题，又保证及时解决。微软游戏团队的RITE(Rapid Iterative Testing and Evaluation)，是一种值得推广但似乎没被广泛讨论的方法。

　　RITE全称是快速迭代测试与评估，它的目标是尽 可能解决更多问题，在最短时间内验证解决方案的有效性。它的两个特征是：

　　1. 快速修正设计方案。

　　传统正式的可用性测试，会在测试完所有用户后总结分析问题。RITE则是在头几轮（甚至第一轮） 测试后，对发现的问题进行分析，然后马上修正设计，将修正后的方案用于后续测试。

　　2. 快速评估修正方案的效果。

　　由 于几乎测一轮修正一轮，在后一轮测试就可以检验根据前一轮结果修正的效果。

　　那么，如何对一个问题进行分析呢？为此，他们提出了4种问题分 类以及对策。

　　类型一：问题有明确原因和明确的解决 方案，并可以快速实施该解决方案；

　　类型二：问题有明确原因和明确的解决方案，无法快速实施该解决方案；

　　类型三：问题没有明确原因，因此没 有明确解决方案；

　　类型四：问题是由其他原因引起的（测试脚本不当、指导语不当等）

　　对于类型一的问题，马上对界面进行修正，并用于 下一轮测试。对于类型二的问题，着手开始修正，一旦修正完毕，马上用于测试。对于类型三和四的问题，继续收集数据，看是否能上升为类型一或二的问题。图1 是微软的测试记录文档，其中：

　　- X代表该用户遇到这个问题

　　- 黄色高亮代表对该用户实施了修正方案1

　　- 蓝色高亮代表对该用户实施了修正方案2

　　- 加粗黑线代表有修正发生

　　- 黑色高亮代表用户没有做可能遇到问题的任务

　　图1 微软RITE测试记录