性能测试(1) - 性能测试的需求确定

当问到性能测试的需求，我们的客户有的时候可能会回答，“我们要支持20000个用户同时在线”，或者“每天有10000个用户同时访问这个网站”，更有甚者“我们也不知道，越多越好吧”。

遇到类似的情况，我们应该怎样去确认性能的具体需求呢？

看似很明确的需求

就拿刚才提到的，当用户说“我们与10000个用户同时访问这个网站”。 这个时候看似我们的需求已经很“明确”了。真的很明确了嘛？

其实不然，10000个用户同时访问这个网站，那他们都在干什么呢？ 有可能有5000个用户仅仅是在浏览静态页面，2000个在创建表单，1000个在做查询，还有... 真正产生压力的用户是谁呢？这恐怕不能单单从10000个用户同时访问这个网站得到结果。

之前做过一个项目，客户为某机场，他们为用户提供免费的wifi服务，但是提供wifi的同时，会在不同的页面播放广告。后台有一个广告管理系统，可以做一些配置，根据优先级来投放广告。这其中涉及到一些复杂的算法，主要是投放广告的比例。当然机场还有很多物料服务器，主要是用来存放广告的图片等等。当时用户给的性能需求也就一句话，我们每天大概有xxxxxx个用户连接我们的wifi。那怎样来做性能测试呢？

多少个用户连接wifi其实只是一个最表面的现象，在连接wifi的同时，其实系统做了很多事情，首先连接wifi的时候会去访问分发服务器，确定要播放哪几个广告，其次会根据分发的广告，去物料服务器上找相应的资源，然后打点把广告的访问的历史数据记录到数据库中去。这是能联想到的一些最基本的后台操作，每一个行为都有可能成为一个瓶颈，都需要去考虑。

所以在考虑性能需求的时候，一定要清楚背后的逻辑是什么，同时需要分析用户活动，从而确认系统的性能测试目标。

分析历史数据

对于性能测试来说，如果有很详细的历史数据，这将是是一个非常珍贵的数据源。我们可以从中分析出很详细用户行为。之前我们有做过一个项目，性能测试的需求就基本上是从历史数据中得到的。我们对数据库进行了很详细的分析，从而来设计性能测试用例。这其中主要包含，系统的哪些service承受了压力，压力是多大，用户量是多大等等。

需要特别注意的是，如果对于业务的了解不够深，很容易导致场景的设计缺失，从而产生测试的场景和实际的场景有所偏差。 比如分析某张表，分析出系统有10000个插卡的拔卡的记录，有的人可能直接就开始写脚本了，模拟一个用户每天做10000次插卡拔卡的操作。 殊不知，这10000次插卡和拔卡的操作是4000个用户完成的...而性能的瓶颈很有可能就在用户的管理，而不是插卡拔卡产生的压力。

所以建议大家做历史数据分析的时候，在了解真正业务的同时，可以很多人去协作完成，这样可以分析出更全面的场景。

我们也不知道需求是什么，你们看着办吧

这种情况通常出现在一个新的项目，客户对上线后的用户体量并没有很好的认知。我们应该怎么做呢？真的看着办吗？

通常我们会对系统进行负载测试，就是在被测系统上不断增加压力，直到性能指标（如响应时间）超过预期或者某种资源已经快达到饱和状态，那么这个时候我们基本就可以确定系统的瓶颈是什么，支持多大的吞度量。再通过一段时间的稳定性测试，让系统在一定的时间内（比如一周）维持一定的压力，去查看相应的性能指标。

这样，我们就可以告诉我们的用户，我们的系统现在支持多大的用户访问量，吞度量是多少。

当然，现在提到的这些都是广义的需求，对于性能测试本身来说，我们也有一些明确的需求，也就是我们通常提到的index，这个我在接下来的文章中会继续去深入讨论这个问题。