性能测试的一些概念和技巧剖析.doc

一些性能测试概念 不同概念的用户 系统用户：可以连接并使用系统的用户。比如一个单位使用某系统办公，每个人都用，这个单位有500人，那么这个系统的总用户数就是500。 同时在线用户：当前已经连接系统的用户；但他们不一定对服务器构成压力，比如正在浏览信息的用户，正在填写表单的用户，这部分用户不会对服务器造成压力；只有并发用户才会对服务器造成压力。 并发用户：当前正在与服务器进行交互的用户，他们会对系统造成压力，比如正在向服务器提交查询数据的用户，正在提交保存表格的用户。 并发用户数的统计方法目前并没有准确的公式，因为不同的系统会有不同的并发特点。例如OA系统统计并发用户数量的经验公式数5%~20%。对于这个公式是没有必要拘泥于计算的结果，因为为了保证系统的扩展空间，测试时的并发用户数量要稍微大一些，除非是要测试系统能承载的最大并发用户数量。 而什么原因造成了这个性能拐点的出现？我们发现CPU记录图出现了如下的情况： 很明显，CPU占用率与事务的响应时间呈现出负相关的联系，且超过60用户后，CPU占用率长时间超过90%，甚至达到100%，这说明性能拐点是由于CPU瓶颈造成的。 然而一般在平时的性能测试中，见得最多的性能拐点成因则是带宽瓶颈，如下面的图（来源为珲春政府网性能测试，场景设定为从10虚拟用户开始，每2分钟增加10虚拟用户，最大到100虚拟用户）： 很明显，系统的性能拐点为30用户，查看CPU、内存的记录，并无异常；而再看一下吞吐量的记录，呈现出下面的现象： 很明显，在超过30用户后，系统的吞吐量就不再有明显的增加，而测试环境中使用的是100Mbps的网络环境，理论上即约为1200多万字节每秒，这恰好与图中的数值相合，所以带宽瓶颈是导致性能拐点出现的原因。 由于压力机端的带宽和服务器端的带宽可能是不对称的，比如压力机端只能使用100Mbps，而服务器端则可以使用1Gbps，这就会使压力机端产生带宽瓶颈，对测试结果造成影响；因此在进行性能测试的时候，压力机端的带宽要尽可能大，尽量降低压力机端带宽瓶颈对测试结果的影响。 常见系统类别 信息发布系统（如各种网站）： （1）用户范围不确定，用户数难以统计 （2）系统的主要操作集中在页面访问、信息查询、信息发布（如留言、评论等） （2）图片等资源请求较多，所以网络带宽对测试结果通常影响较大 信息管理系统（OA系统）： （1）用户范围是比较确定的，用户数较容易统计 （2）通常系统的业务功能会很多，但是只有其中一部分业务功能是最常用的，其他功能的使用相比起来会少很多 （3）很多情况下，主要业务功能的执行在时间上会有一定的特点 （4）图片等资源请求较少，所以网络带宽通常来讲对测试结果影响不大 测试角度 客户端角度：模拟同时在线用户 特点：直接体现现实中的操作场景，测试结果在用户层面上非常直观，但是需要详细了解用户的操作习惯，并在编辑测试脚本时体现出来，否则测试结果的说服力不强 服务端角度：模拟并发用户 特点：不需要了解用户的操作习惯，但不能体现现实中的操作场景，测试结果能反映服务器处理能力，但在用户层面上不够直观 测试需求分析 常见的测试需求有： （1）测试事务，脚本录制的基础，必须有 （2）并发用户数，场景设置的基础，必须有（可以是直接给出来的，也可以是计算出来的） （3）平均响应时间，最基本性能指标，必须有 （4）业务量，一些系统需要验证能否支持；另外当没有给出并发用户数时，可以使用业务量和平均响应时间计算并发用户数 （5）事务通过率，必须有，因为事务出错过多对系统而言是不可接受的 （6）用户使的用网络带宽 （7）服务器资源占用，建议给出 示例1：某个网站，在页面访问的平均响应时间不超过8秒的情况下，测试服务端最大能够支持的并发请求数；测试中并发请求上限设定为200（性能探索，服务端角度） 示例2：某个业务系统，300用户同时在线执行XX操作，平均响应时间不超过8秒（性能验证，客户端角度） 示例3：某个业务系统中，在平均响应时间不超过5秒的情况下，测试系统可以支持的同时在线执行XX操作的最大用户数；预计在项目周期内，同时在线用户数不会超过600（性能探索，客户端角度） 示例4：在某个业务系统中，业务A的处理时间集中在每月最后4个工作日，每个工作日以8小时计，每月执行的业务A数量可以达到36万笔，业务A完成的平均响应时间不能超过8秒（性能验证，服务端角度） 测试场景中能够控制的是并发用户数，而在示例1、2、3中都包含了并发用户数的信息，但是示例4中却没有并发用户数的信息，为了测试需要我们需要自己计算并发用户数 依据80-20原则进行计算，系统对业务A的处理能力，即每秒业务数M需要达到： 360000*0.8/(