最近部门的一个项目在做性能测试，在测试设计及测试结果上有过一些讨论。同一个系统，不同的测试设计及测试过程会导致不同的结果，也会有不同的解读。合理的规划设计是至关重要的。

　　性能测试有许多种，项目性能测试的目的可以也各有不同。常见的是通过性能测试来了解系统的性能特性及指标，基于测试结果来做系统的容量规划，也通过性能测试了解系统在压力上的可靠性，伸缩性及可能的资源瓶颈，帮助进一步的系统优化。

　　最开始的测试设计很重要。一方面是测试场景及用例的设计。合理的设计不可能是凭空想象，而是要基于系统的业务及用户使用行为模型。要基于统计数据或者行业专家来首先确定一个大家都认可的业务及行为模型。包括系统的业务种类，每个种类的典型业务量及比例关系，用户的角色及使用方式，也包括典型的业务操作时间，业务高峰的特征等等。测试场景及用例的设计应与业务行为模型一致，特别是各种操作的比例关系。与业务行为模型不一致的测试设计会导致结果的不可信及各种争议。另外，如果业务模型过于复杂，可以通过抽象来简化，可以是业务层次的简化，合并一些业务类型。测试设计也可以从IT层面做抽象简化，把一个类似复杂度的IT操作合并来建模，比如简单业务查询，复杂的业务查询，简单的业务新建/修改，复杂业务交易，登录等等。设计的另一方面是测试环境及执行方式，也要基于模型及保持每次运行测试时条件一致。比如系统的测试系统的数据，数据量及数据关系复杂度应与典型的实际情况一致。比如如果是多用户的系统，多用户的访问方式模拟也要和典型情况一致。比如如果测试中的多用户都是都用同一个用户或者少量几个用户来访问的系统，结果就可以与实际情况有很大不同，会有可能由于少量用户的数据有容易被系统缓存而显得结果过于乐观。缓存在测试中的命中率应于实际情况中一致。

　　测试的过程也是重要的，它要保证测试结果的可信，今天先不谈。只说一下有了测试结果，如何做容量规划。比如业务预半年内用户量会达到十万，我们要需要什么样的硬件及系统支持。虽然测试模型与实际情况难免总会有出入。但规划还是要基于测试的数据及业务行为模型，基于模型和数据做推算。一个推算的过程会有更大的说服力。举个简单的例子，测试结果会让我们知道一个基准系统的正常处理能力，比如平均每秒可正常处理多少笔业务。我们可以预模型计算出十万用户的业务需求，进一步推算出每秒的业务需求，根据分布模型再推算出高带的每秒上业务需求，再对比基准系统的能力，就可以规划实际的系统需求了。

　　当然，实际的系统需要考虑的角度都是多方面也是复杂的，不会象我们举的例子那么简单。重要还是一种基于模型的分析方法，基于数据的推导过程。另外，当我们对业务有新的理解或都数据统计结果时，我们需要及时修正我们的模型以得到更加准确的结果。（以上言论仅代表作者的个人观点，不代表51Testing观点）