日复一日的研发工作即将告一段落。对于项目经理和项目团队来说，系统割接上线是一个重要的里程碑。生活和工作的节奏改变，白天和黑夜没有差别。如果系统割接上线后，没有出现大的系统故障，而是日趋稳定，那么项目团队的苦日子就算是熬到头了。
可是，如果系统割接上线后，重大故障频发，怎么办？前天是Web服务器CPU 100%，导致无法响应客户请求；昨天是数据库锁表，大量数据库连接阻塞，无法获取需要的数据；今天是某个WebService接口在高并发下出现异常……今天，疲惫的我们解决了这个故障，天蒙蒙亮的时候回到了家。可是明天呢，明天会发生什么事？作为项目经理，我们怎么能对明天毫无信心？？
给予我们信心的，是项目经理对于项目成员的充分信任，以及对于软件系统的深刻理解。信任，是建立在长期共同工作、共同解决问题，彼此充分了解基础上的。而对于项目组所开发的软件系统的深刻理解，则需要更多管理技术手段来保证。其中最为重要的技术手段，就是压力测试(或性能测试)。
压力测试不仅是孤立测试各个软硬件的性能指标，而是要与软件应用系统结合，尽可能模拟真实的业务场景，从而充分评估系统上线后可能发生的情况。也就是，当业务量达到高峰时，各个服务器CPU指标大概是多少，内存指标大概是多少，IO、网络是否有问题？这些都应当事先被测量。
然而，真实系统的应用环境非常复杂，用户在使用各个系统功能时的比例，外部系统操作等等都会对系统性能指标构成影响。要准确模拟割接后的业务高峰时的系统状态，就必须根据实际业务指标进行分解和设计压力测试方案。具体的说，分析系统有几类主要用户(或相关系统)，每类用户对系统的操作主要有哪几种场景，每种所占的比例等等。最后将上述指标全部定量化，用于编制压力测试脚本。因此，压力测试方案的设计者，也常常不是测试人员，而是项目经理或架构师。只有项目经理和架构师对系统才能有非常全面的理解，确保在设计方案时不会有大的疏忽。
根据实际业务场景设计的压力测试方案还能有效优化代码质量。例如，业务场景A与业务场景B的业务复杂度相似，访问人数也相似，测试结果却发现业务场景A消耗的资源多得多。那么，接下来就应当着重分析一下，是不是业务场景A的相关代码中，存在低效的SQL语句？或者使用了代价过高的算法？甚至存在某些 “软”BUG，没有表现了功能缺陷，而以消耗了过多资源为代价。
当我们详细测试了每一个业务场景，消除了其中隐含的性能故障；当我们设计了完整压力测试方案，按照系统实际压力进行测试，再用2倍的压力、3倍的压力测试……我们消除了一个又一个系统瓶颈，仔细检查每一个细节，找不到错误的理由。现在，在系统性能方面，我们已经无法做的更好，因为我们已经做了所有应该做的事，和所有能做的事。
系统割接后，我们可以静静等待业务高峰的到来，并验证我们的压力测试结果。
