3、使用场景的一致性
● 基础数据的一致性
包括预测的业务数据量，以及数据类型的分配。很简单的一个列子，一个系统的数据库只有10条数据和一条数据库里几千万条数据，我们在对其进行性能测试时，得到的性能指标可能会有非常大的差别。
为了保证每次测试环境的更加一致性，磁盘的使用情况以及磁盘的碎片情况也会或多或少的影响的性能。
● 使用模式的一致性
尽量模拟真实场景下用户的使用情况，其实，我们在做性能测试前期的需求分析，其主要目的也就是为了更真实的模拟用户的使用情况。
性能测试环境的实施策略
上面讲测试环境与生产环境保持一致所需要注意的内容。其实在实际的测试中，我们很难搭建出与生产环境完全一致的一个测试环境，除非我们暂停生产环境用户于进行性能测试，这往往是不可能。一方面某些生产环境是不允许被暂停的，另一方面也为生产环境的安全性考虑。
性能测试环境并不像功能测试环境，为了节省资源可以一台服务器上运行多个系统。由于性能测试的特殊性，整个测试环境需要在严格的独立监控下管理，在很多情况下，我们很难申请到足够的且一致的资源（说白了就是老板是否愿意出钱给你买服务器搭建系统）。对于一个并未上线的项目，其生产环境的配置也属于暂定状态，性能测试的目的就是为了确定具体生产环境的硬件配置。这个时候更不可能用过高的配置来搭建性能环境（除非现成的环境放着不用）。
我们一般通过两种策略来搭建性能测试环境（预估方式均有误差）
1、通过建模的方式实现低端硬件对高端硬件的模拟
通过配置测试来计算不同配置下的硬件性能和系统处理能力的关系，从而推导出满足系统性能的真实配置情况，这种模拟需要精确的建模，模型的采样点越多，那么得到的结果越精确，从而将在低端配置下的性能指标通过该模型转化为高端配置下的最终预计性能指标。
例如：搭建一个低端环境，首先需要对这个环境的CPU和内存进行单独的性能基准测试，同过在不同的配置的性能测试，得到一个基准信息列表，当然，在进行这个性能测试的过程中，我们要确定硬件是系统的瓶颈。如果只用一个CUP，在性能测试过程中，其使用率很低，但得到的性能数据都非常底，这起码说明CUP不是系统的平静，这种情况下就无法得到想要的基准值。
如上图，在一颗CPU情况下，运行100个用户且CUP使用率接近饱和（100%）。在增加至两颗CUP的情况下，可以运行190个用户且UPU使用率接近饱和（100%），以此做记录，那么我们就可以推算出运行800个用户需要多少颗CUP。
如果你在实际应用中使用的CUP型号及其频率并非完全一样，这个时候可以使用EVEREST工具计算每种CUP的得分，对其性能进行评估。
内存也可以使用此方法进行测试推导，这里需要我们多进行试验，对硬件的性能以及对整个项目的结构都要做深入的了解，以便尽量减少误差。
