软件测试入门随笔——软件测试基础知识（六）

初步接触性能测试啦！！学习书籍《loadrunner 性能测试巧匠训练营》

• 针对不同系统，性能测试有不同的关注点

     C/S架构的产品更关注系统资源使用情况、数据库性能以及运行的配置要求等等。如：内存、用户连接数、数据库死锁、数据库cache命中率、运行的最低配置等等。

　  B/S架构的产品关注web服务器的相关指标。如：每秒点击率、吞吐量、尝试连接数、事务成功率等等。B/S架构的较为复杂。

• 性能测试的目的（know how fast & how much）

　　1、评估当前系统

　　2、寻找瓶颈，优化系统（分析→定位→调优）

　　3、预测未来性能（要考虑用户数和业务量增加时系统如何及时应对和调整等等）

• 性能测试的术语和指标

　　1、并发数

　　　　首先明确3个概念：系统用户数、在线用户数和并发用户数。

　　　　系统用户数是指该系统的注册用户；在线用户数是指登录了系统的用户；并发用户是指在线并对服务器产生压力的用户。

　　　　并发数可以通过分析服务器日志确定。常用日志分析工具有AWStats、Webalizer、Analog、Deep Log Analyzer等。

　　　　并发的两种理解：①所有用户在同一时刻做同样的操作②多个用户发起多个请求，请求可能不同。

　　2、响应时间

　　　　响应时间=网络传输（请求）时间+服务器处理（一层或多层）时间+网络传输（响应）时间+页面前端解析渲染时间

　　　　一般客户端发起请求后，会先预处理判断是否有缓存。如果有，直接读取cache，再进行数据处理和渲染；如果没有，要先解析DNS域名获得服务器IP，连接服务器发送请求，

　　待服务器响应后返回数据，再进行数据处理和渲染。

　　3、每秒通过事务数

　　　　TPS是指每秒通过事务数，是直接反映系统性能的指标。

　　　　把它与平均事务响应时间进行对比，可以分析事务数量对响应时间的影响。

　　　　当压力加大时，TPS曲线如果变化缓慢，很有可能是服务器开始出现瓶颈了。如果环境没有发生大的变化，对于同一系统会存在一个最大处理事务能力，它并不随并发用户的多少而改变。

　　4、每秒点击数

　　　　代表用户每秒向web服务器提交的HTTP请求数。需要注意，对用户来说是一个请求，对后端来说是多个请求。比如，点击一个网页链接，返回页面上的每张图片每个模块都需要一个HTTP请求。

　　　　每秒点击数从侧面反映了客户端的状况，每秒点击数不正常，一般可能是网络问题或脚本问题所致，需要进一步具体分析。

　　5、吞吐量

　　　　吞吐量是指单位时间内系统处理的请求数量，能直接反映服务器承受的压力，是需要重点关注的指标。

　　　　要与吞吐率区别开来，吞吐率是指用户在给定的一秒内从服务器获得的数据量，就是服务器返回的数据量数据量啊喂。

　　6、思考时间

　　　　两种理解：①用户进行操作时，每个请求或者操作之间的间隔时间②满足业务的特定需求，限制用户的某一请求在一定的时间间隔内不能发送第二次。

　　7、资源利用率

　　　　这部分的内容太杂，主要先了解几个重点指标。

　　　　①CPU

　　　　能反映出系统的繁忙程度，分为系统CPU和用户CPU，其中系统CPU是处理系统本身所占用的资源，而用户CPU则是处理程序所占用的资源，对象不同。

　　　　②Load Average

　　　　指一段时间内CPU正在处理和等待CPU处理的任务，也就是CPU使用队列的程度的统计信息。

　　　　③Memory

　　　　将各种信息收集起来存放。因为数据从内存中读取比从磁盘上读取快，所以内存经常会泄露或溢出，需要重点留意。

　　　　短时间内可用内存越来越少，不代表一定有内存泄露或溢出。（可能是内存损坏、检测软件漏洞、病毒占用程序等等）

　　　　④队列

　　　　队列长，说明处理能力可能达到了极限或者遇到了阻塞。

　　　　⑤IO

　　　　与磁盘的交互，重点关注交换频率和磁盘队列长度。

　　　　⑥网络

　　　　重点关注网络的流量，看是否存在网络带宽的瓶颈。

• 性能测试分类

　　　分类比较多啊，理解特点和概念就可以了，不需要严格区分。

　　　1、基准测试

　　　  应用场景有如下几个：①某系统从来没进行过任何性能测试，需要对系统做一次性能评估，作为后续开发调优的参考。（常见）

　　　　　　　　　　　　   ②可以在制定的标准下通过基准测试建立一个性能基准，这样以后当系统的环境、参数发生变化之后，在进行一次相同标准下的测试，即可看出变化对性能的影响。

　　　　　　　　　　　　　③进行基准测试可以在较早的阶段发现性能问题，减少不必要的测试。

　　   2、并发测试

　　　  很多的用户按照预定的场景并发请求某个业务或功能时是否出现并发问题，例如内存泄露、线程锁、资源争用等。进行并发测试是为了找出并发引起的问题。

　　　  确定需要的并发数的方法：①并发数=PV / PV Time * 页面连接次数 * HTTP响应时间 * 因数 / Web服务器数量

　　     　　　　　　　　　　　　PV（page view）:页面浏览量。PV Time是PV的统计时间，换算成秒，一天是86400s。

　　　　　　　　　　　　　　　  页面连接次数包括外部的JS、CSS、图片等，一般为10。HTTP响应时间一般可为1s或更少。因数一般为5。

　　　　　　　　　　　　　　　  ②经典理论80-20原则（80%的业务量在20%的时间里完成。）

　　　　　　　　　　　　　　　　吞吐量=80%*业务量/(20%*时间)

　　　　　　　　　　　　　　　　注意：二八原则的计算结果是吞吐量而不是并发数。

　　　　　　　　　　　　　　　  ③在段念老师的《软件性能测试过程详解与案例剖析》中提到的估算方法有如下3种：

　　　　　　　　　　　　　　　　1>.     C=nL/T                （1）

　　　　　　　　　　　　　　　　　　　 C’≈C+3√C            （2）

　　　　　　　　　　　　　　　　公式（1）中，C是平均的并发用户数；n是log session的数量；L是log session的平均长度；T指考察的时间段长度。例如，对一个典型的OA应用，考察的时间段长度应该为8小时的工作时间。

　　　　　　　　　　　　　　　　公式（2）给出了并发用户数峰值的计算方法，其中，C’值并发用户数的峰值。该公式是假设用户的logsession产生泊松分布而估算得到的。

　　　　　　　　　　　　　　　　eg：假设有一个OA（办公自动化）系统，该系统有3000个用户，平均每天大约有400个用户要访问该系统，对一个典型用户来说，一天之内用户从登录到退出该系统的平均时间为4小时，在一天的时间内，用户只在8小时内登录该系统。根据公式（1）（2）可得：

　　　　　　　　　　　　　　　　C=400*4/8=200

　　　　　　　　　　　　　　　　C’≈200+3√200=242

　　　　　　　　　　　　　　　　如果能知道平均每个用户发出的请求数（假设为u），则系统的总吞吐量就可估算为u*C。

　　　　　　　　　　　　　　　　但是要估算C和L并不容易，并且考虑到业务操作存在一定的时间集中性，这个方法存在一定的偏差。建议改进两点：

　　　　　　　　　　　　　　　　一是以更细的时间粒度进行考察，如设定1小时为考察时间的粒度，就可以解决时间集中性的问题；

　　　　　　　　　　　　　　　　二是考虑典型的业务模式：不同业务有不同的业务模式，如一个内部系统一般在上班开始后的30分钟至1小时集中出现用户的登录等等，基于这些场景进行估算。

　　　　　　　　　　　　　　　　2>.对于企业内部使用的web系统来说，一个更一般（精度更差）的经验公式是：

　　　　　　　　　　　　　　　　　　　　　　C=n/10      （3）

　　　　　　　　　　　　　　　　　　　　　　C’≈ r*C      （4）

　　　　　　　　　　　　　　　　用每天访问系统用户数的10%作为平均的并发用户数，并发用户数的最大值有并发用户数乘上一个调整因子r得到，r的取值一般为2~3。

　　　　　　　　　　　　　　　　这种方法可以在要求不太严格的性能测试，或是只有少数数据支持分析的性能测试中使用。

　　　　　　　　　　　　　　　　3>.“日志分析”方法

　　　　　　　　　　　　　　　　“日志分析”方法是指通过对应用服务器的日志进行分析，从而了解系统用户的使用状况，从日志中计算出“服务器承受的最大并发用户访问数”数据。

　　　　　　　　　　　　　　　　这种方法得到的数据准确度和可信度都比较高。对于Internet应用等无法估计用户数量和用户行为模式的应用，这种方式最为可信。

　　   3、负载测试

　　　　主要目的是验证业务或系统在给定的负载条件下的处理性能，此外，还要关注响应时间、每秒通过事务数和其它相关指标。负载测试是为了发现性能问题，性能测试是为了获取性能指标。在性能测试中，也可以不调整负载，而是在负载相同的情况下通过改变系统的结构、算法、硬件配置等来得到性能指标。

　　　4、压力测试

　　　　没有预期的性能指标，不断地加压，看系统什么时候崩溃，以此来确定系统的瓶颈或者不能接受的性能拐点，以获得系统的最佳并发数、最大并发数。通过压力测试，可以更快地发现内存泄露问题，还可以更快地发现影响系统稳定性的原因。

　　  5、稳定性测试

　　　　要想知道系统稳定的情况，就需要长时间运行，在这段时间内观察系统的出错几率、性能变化趋势等，进而大大减少系统上线后的崩溃等现象。一般都会进行所谓的7*24小时的稳定性测试。

　　　　注意：①一般稳定性测试需要在系统成型后进行，并且没有严重的bug存在。

　　　　　　   ②场景的设计以模拟真实用户的实际操作为佳。

　　  6、失效恢复测试

　　　　失效恢复测试重在关注系统出现问题后能否根据预定制定的策略恢复，且恢复后能否正常运行。不过失效恢复测试一般是对具有负载均衡的系统进行的，主要是为了测试当系统局部发生故障时，是否会对全局产生大的影响，产生的影响是否在可以接受的范围内，以及用户能否继续使用系统。

　　　　在实际应用过程中，可以模拟一台或几台负载均衡机器出现故障来进行失效恢复测试，但需要注意的是，不仅要关心失效后，用户是否可以正常访问或者恢复后系统是否可以正常工作，也要关注失效后，系统还能支持多少并发用户，以及采用哪些备选方案来快速响应。

　　7、现网性能测试

　　　　就是在实际网络、实际环境中进行测试，完全和真实用户一样，有一定的风险，需要注意：

　　　　①时间段的选择：现网性能测试可能会影响正常用户，要尽量避开高峰期，选择半夜或凌晨来进行。

　　　　②垃圾数据处理：如果现网性能测试涉及了写数据的操作，这些数据后期一定要处理，为了方便处理，前期数据的设计要有规律可循。

　　　　③网络限制：现网测试如果突然间产生大的数据量，可能会被网络带宽限制，甚至路由会认为是非法数据请求而产生拦截等。所以进行现网测试时，压力机需要和被测服务器部署在同一网段机房内，这样可以避免网络限制，最后远程收集数据即可。

           如果没有特殊情况，尽量不要进行内网的性能测试，风险比较大，如果非要进行，一定要事先充分评估风险以及应对的解决方案，以便快速响应，把影响控制到最小。所以人还是偶尔要怂一点的，别逞强。

 

 

 

 　　　　　　　　　　　　　　　　

 

转载于:https://www.cnblogs.com/gajendra/p/6185349.html