项目收尾验收阶段，大家的焦点容易在功能验收上，而对于性能方面容易产生一些验收挑战。

一是性能测试技术门槛高，二是性能测试成本高，三是性能测试中理解和设计容易歧义。

其中有四个细节，需要多关注。

1. 所谈的海量用户和高并发的关系是？

我们在规划业务时，经常关注的是要有多少用户量。希望这个量越大越好。

海量用户对于运营是个挑战，但对于系统建设却不会有太多的难度。

相对于系统容量，同时在线的用户才是高技术难度的挑战。

什么是用户在线呢？是一个个登录的用户吗？

不是！

对于系统而言，是持续在和系统交互的用户，也就是在看视频、在听歌、在发信息、在点餐的用户。是他们的每个点击直接或间接的给系统带来了一个又一个具体的指令和任务。

在性能测试时，要将抽象的海量用户，转为在线用户数，转化为系统的并发数。

这需要对用户使用系统的行为进行建模，包括时间、空间、使用习惯等等。

不同的模型会导致不同的并发数量。

不同的模型也会导致不同的并发类型组合。

2. 一个接一个向系统发请求，是真的吗？

当机器模拟用户不断向系统发出了一个接一个请求，我们看到了系统面临的压力持续增加，我们看到了平均响应时间在逐渐变长，但还都在符合要求的性能指标范围内。

系统达标了吗？

等等！

平均响应时间只反映了每次模拟用户点击应用后，应用响应请求的时间。

如果有十个队列人同时点餐，压力大吗？不一定。

如果每次前面的人点完餐后，下一个人都要想好久才点餐，那我们需要十个服务员吗？
每次请求间的间歇时间，我们称之为思考时间，也就是用户在每一步操作前都需要一定的考虑时间。

这个时间设置越大，系统压力越小。

所以在看到高并发、低时延的测试结论时，要留意一下每次请求间的思考时间的设计。

3. 每次系统访问指的是什么？

用户在使用应用时，都会基于自己的情况，每次访问都或多或少有一些不同。

比如有人愿意在朋友圈里发图片，有人愿意发视频，而有人只想默默地为朋友的精彩点赞。

但测试时，模拟用户发的数据真的和真实情况一致吗？

更多时候是，由于受限于测试数据生成的难度，普遍会采用大量重复使用测试数据。

还会将文字、视频等测试数据用得小一点，这样系统和网络的压力都小一点。

所以在看测试结论时，还要多看看测试数据是什么样的？

4. 被测的系统会有什么不同？

当我们专注于检查测试请求侧的时候，我们还需要关注系统侧。

一个刚跑完马拉松的人和一个刚准备出门上班的人，面对同一个问题的处理能力是不同。

一个背着行李负重前行的人和一个空手遛弯的人，面对你帮忙的请求也是不同的回应的。

从一句话中找出错别字，和从一本书里找出错别字是完全不同的挑战。

所以在看测试报告时，要了解一下测试时，系统的背景数据是什么样的？

包括数量、种类、分散程度等等。

最后的话

以上仅是性能测试设计和审查中需要关注的部分细节，要想做出有价值的性能测试，需要深刻理解目标市场和目标用户，需要重视每个环节的取舍。

这样测试过的系统才能在推向市场时，经受住大流量的考验。