本节书摘来自异步社区《精通软件性能测试与LoadRunner最佳实战》一书中的第2章2.7节 测试场景运行，作者于涌 , 王磊 , 曹向志 , 高楼 , 于跃，更多章节内容可以访问云栖社区“异步社区”公众号查看。
2.7 测试场景运行精通软件性能测试与LoadRunner最佳实战测试场景运行是关系到测试结果是否准确的一个重要过程。经常有很多做测试的人员花费了大量的时间和精力去做性能测试，可是做出来的测试结果不理想。原因是什么呢？关于测试场景的设计在这里着重强调以下几点。
（1）性能测试工具都是用进程或者线程来模拟多个虚拟用户，每个进程或者线程都是需要占用一定内存的，所以要保证负载的测试机足够跑设定的虚拟用户数，如果内存不够，请用多台负载机分担进行负载。
（2）在进行性能测试之前，需要先将应用服务器“预热”，即先运行一下应用服务器的功能。这是为什么呢？语言翻译成机器语言，计算机才能执行高级语言编写的程序。翻译的方式有两种，一个是编译，一个是解释。两种方式只是翻译的时间不同。编译型语言写的程序执行之前，需要一个专门的编译过程，把程序编译成为机器语言的文件，比如可执行文件，以后要运行的话就不用重新翻译了，直接使用编译的结果文件执行（EXE）就行了，因为翻译只做了一次，运行时不需要翻译，所以编译型语言的程序执行效率高。解释则不同，解释性语言的程序不需要编译，省了道工序，解释性语言在运行程序的时候才翻译，如解释性语言JSP、ASP、Python等，专门有一个解释器能够直接执行程序，每个语句都是执行的时候才翻译。这样解释性语言每执行一次就要翻译一次，效率比较低。这也就是有很多测试系统的响应时间为什么很长的一个原因，就是没有实现运行测试系统，导致第一次执行编译需要较长时间，从而影响了性能测试结果。
（3）在有条件的情况下，尽量模拟用户的真实环境。经常收到一些测试同行的来信说：“老师，为什么我们性能测试的结果每次都不一样啊？”，经过询问得知，性能测试环境竟与开发环境为同一环境，且同时被应用。有很多软件公司，为了节约成本，开发与测试应用同一环境，进行测试，这种模式有很多弊端。做性能测试时，若研发和测试共用系统，因性能测试周期通常少则几小时，多则几天，这不仅给研发和测试人员使用系统资源带来一定的麻烦，而且容易导致测试与研发的数据相互影响，所以尽管经过多次测试，但每次测试结果各不相同。随着软件行业的蓬勃发展，市场竞争也日益激励，希望软件企业能够从长远角度出发，为测试部门购置一些与客户群基本相符的硬件设备，如果买不起服务器，可以买一些配置较高的PC代替，但是环境的部署一定要类似。如果条件允许也可以在客户实际环境做性能测试。总之，请大家一定要注意测试环境的独立性，以及网络、软、硬件测试环境与用户的实际环境一致性，这样测试的结果才会更贴近真实情况，性能测试才会有意义。
（4）测试工作并不是一个单一的工作，作为测试人员应该和各个部门保持良好的沟通。例如，在遇到需求不明确的时候，就需要和需求人员、客户以及设计人员进行沟通，把需求搞清楚。在测试过程中，碰到问题以后，如果自己以前没有遇到过也可以跟同组的测试人员、开发人员进行沟通，及时明确问题产生的原因、解决问题，点滴的工作经验积累对一个测试人员很有帮助，这些经验也是日后问题推测的重要依据。在测试过程中，也需要部门之间相互配合，在这里就需要开发人员和数据库管理人员同测试人员相互配合完成1年业务数据的初始化工作。所以，测试工作并不是孤立的，需要和各部门进行及时沟通，在需要帮助的时候，一定要及时提出，否则可能会影响项目工期，甚至导致项目的失败，在测试中我一直提倡“让最擅长的人做最擅长的事”，在项目开发周期短，人员不是很充足的情况下这点表现更为突出，不要浪费大量的时间在自己不擅长的东西上。
（5）性能测试的执行，在时间充裕的情况下，最好同样一个性能测试用例执行3次，然后分析结果，如果结果相接近才可以证明此次测试是成功的。
本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。
相关资源：精通软件性能测试与loadrunner实战