日常的研究开发即将告一段落。 对于项目经理和项目团队来说，系统分离是一个重要的里程碑。 生活和工作节奏改变，白天和晚上没有差别。 当系统断开在线后，没有发生大的系统故障，而且越来越稳定时，项目组的痛苦不堪。
但是，如果系统断开联机后，经常发生重大故障，该怎么办？ 前天Web服务器的CPU是100%，不能满足客户的要求； 昨天在数据库锁表上，大量的数据库连接被屏蔽了，无法获取所需的数据今天某个WebService界面因为高合并出现了异常……今天，累了我们解决了这个故障，天一亮就回家了但是明天，明天会发生什么？ 作为项目经理，我们为什么对明天没有信心？
给我们信心的是项目经理对项目成员的充分信任和对软件系统的深刻理解。 信任是建立在长期共同工作、共同解决问题、充分理解的基础上的。 要深入了解项目团队开发的软件系统，需要更多的管理技术手段。 其中最重要的技术手段是压力测试(或性能测试)。
压力测试不仅要孤立测试单个软硬件的性能指标，还要结合软件应用系统尽可能模拟实际业务场景，充分评估系统上线后可能出现的情况。 也就是说，流量达到ljdds时，每台服务器的CPU指标是多少，内存指标是多少，IO、网络有问题吗？ 这些必须事先被测量。
但是，实际系统的应用环境非常复杂，用户使用各系统功能的比例、外部系统的操作等都会影响系统的性能指标。 要准确模拟拆分后业务ljdds时的系统状态，需要根据实际业务指标进行分解，设计压力测试方案。 具体而言，分析系统有几个主要用户(或者相关系统)，各个用户操作系统的主要场景有几种，各自所占的比例等。 最后，将上述指标全部量化，用于制定压力测试方案。 因此，压力测试程序的设计者往往也是项目经理或架构师，而不是测试人员。 只有项目经理和架构师才能充分理解系统，确保在设计项目群时不会有太大的疏漏。
基于实际业务场景设计的压力测试方案还能有效优化代码质量。 例如，业务场景a和业务场景b的业务复杂程度相似，访问者数量也相似，但测试结果表明业务场景a消耗的资源要多得多。 那么，接下来需要重点分析业务场景a的相关代码中是否存在效率低下的SQL语句。 还是使用了成本太高的算法？ 存在某种“软”bug，不表现功能性的缺陷，以消耗了过多的资源为代价。
在详细测试所有业务场景时，潜在的性能障碍已经消除。 我们设计了一套完整的压力测试方案，根据系统的实际压力进行测试，再用两倍的压力、三倍的压力进行测试……我们消除了每一个系统的瓶颈，仔细检查了每一个细节，发现了错误现在，在系统性能方面，我们已经做了所有力所能及的事情，所以不能再做更多了。
系统断开后，我们可以静静地等待业务ljdds的到来，验证压力测试的结果。