开始着手全球性IT转型项目对于任何组织来说都是一件即兴奋又富有挑战的事情。当然，降低失败风险是整个项目的主要目标之一。而测试是能明显帮助降低失败几率的活动之一。
\u0026#xD;\u0026#xD;本文介绍了与传统多用户性能测试所不同的测试方法；尽管所使用的工具相同，但该方法结合了现代数据可视化技术，从而早早就能对那些可能存在有“沉睡着的”性能问题的特定位置及应用程序区域有所洞察。
大多数项目会首先专注于功能，然后才是其它。使用类似HP LoadRunner或Neotys Neoload这类测试工具的多用户性能测试往往属于测试循环后期才会发生的活动。很多时候会与UAT并行发生，而这时新系统已经暴露给终端用户了。因此在性能测试时发现性能问题的几率很高，修复的几率却很低。因为这种情况下，通常距离上线时间已所剩无几。
\u0026#xD;\u0026#xD;多用户性能测试通常发生于项目后期的原因有多种，根据项目的不同而不同。以下两个原因最为常见：
\u0026#xD;\u0026#xD;- 多用户性能测试要求工具和自动化。自动化性能测试脚本所需的资源只有在性能测试即将开始时才有望存在，即应用程序达到“稳定”的开发状态时。假如自动化一个性能测试脚本需要2天的话，那么拥有多个测试脚本（比如：10至20个）就要花费大量的时间或人力。为了不破坏当前在性能测试脚本开发上所花费的资源，该阶段不允许修改应用程序。所造成的结果就是：开发阶段的任何延迟或需要对代码进行大量的修改都将进一步延误性能测试，这给执行带来了风险，也不能及时提供相应价值。\u0026#xD;\t
- 多用户性能测试需要一个类产品环境。尤其是处于IT转型的项目，这样的环境不一定在项目初期就存在，需要时间、精力和金钱去构建。但与之竞争的是早期测试周期中所有其它必需的对测试环境的配置和那些“真正办事的”功能。对项目而言，绝对需要类产品环境的最早一刻是测试部署时（即彩排时刻）。而这时要想让性能测试对项目成果产生正面影响已为时过晚。\u0026#xD;
作为降低风险的活动，性能测试