性能测试总结(二)---测试流程篇

本文主要介绍下性能测试的基本流程，性能测试从实际执行层面来看，测试的过程通常分为这么几个阶段，以下图：

　　　　　　　

下面分别介绍下每一个阶段具体须要作什么：

1、性能需求分析：

　　性能需求分析是整个性能测试工做开展的基础，若是连性能的需求都没弄清楚，后面的性能测试执行实际上是没有任何意义的，并且性能需求分析作的好很差直接影响到性能测试的结果。

　　一些性能测试人员常犯的错误就是测试一开始就直接用工具对系统进行加压，没有弄清楚性能测试的目的，稀里糊涂作完了之后也不知道结果是否知足性能需求。市面上的书籍也大都是直接讲性能测试工具如LR，jmeter如何使用，致使不少新手一提到性能测试就直接拿工具来进行录制回放，使得不少人认为会使用性能测试工具就等于会性能测试了，却不知工具其实只是性能测试过程当中很小的一部分。

　在需求分析阶段，测试人员须要与项目相关的人员进行沟通，收集各类项目资料，对系统进行分析，创建性能测试数据模型，并将其转化为可衡量的具体性能指标，确认测试的目标。因此性能测试需求分析过程是繁杂的，须要测试人员有深厚的性能理论知识，除此以外还须要懂一些数学建模的知识来帮助咱们创建性能测试模型。

 

首先，让咱们来看看经过性能需求分析咱们须要得出哪些结论或目标：

• 明确倒底要不要作性能测试？性能测试的目的是什么？
• 明确被测系统是什么？被测试系统的相关技术信息如：架构、平台、协议等
• 明确被测系统的基本业务、关键业务，用户行为
• 明确性能测试点是什么？哪些须要测，为何？哪些不须要测，又是为何？
• 明确被测系统将来的业务拓展规划以及性能需求？
• 明确性能测试策略，即应该怎么测试？
• 明确性能测试的指标，知道测试出来的结果怎么算经过？

 

其次，需求分析阶段咱们能够从如下几个方面入手：

一、系统信息调研：

　　指对被测试系统进行分析，须要对其有全面的了解和认识，这是咱们作好性能测试的前提，并且在后续进行性能分析和调优时将会大有用处，试想若是连系统的架构、协议都不了解，咱们如何进行准确的性能测试？若是进行性能分析与调优？

　　须要分析的系统信息以下（包括但不只限于以下这些）：

 

二、业务信息调研：

　　指对被测试的业务进行分析，经过对业务的分析和了解，方便咱们后续进行性能测试场景的肯定以及性能测试指标的肯定。

　　须要分析的业务信息以下（包括但不只限于以下这些）：

　　

三、性能需求评估：

　　在实施性能测试以前，咱们须要对被测系统作相应的评估，主要目的是明确是否须要作性能测试。若是肯定须要作性能测试，须要进一步确立性能测试点和指标，明确该测什么、性能指标是多少，测试经过or不经过的标准？性能指标也会根据状况评估，要求被测系统能知足未来必定时间段的业务压力。

　　判断是否进行性能测试主要从下面两个方面进行思考：

• 业务角度:

　　 系统是公司内部 or 对外？系统使用的人数的多少？若是一个系统上线后基本没几我的使用，不管系统多大，设计多么复杂，并发性的性能测试都是不必的，前期能够否决。固然，除非在功能测试阶段发现很是明显的性能问题，使得用户体验较差的，此时可进行性能测试来排查问题。

 

• 系统角度：系统又能够从如下3个方面进行分析

　　a）系统架构：

　　　　　若是一个系统采用的框架是老的系统框架（一般大公司都有本身的统一框架），只是在此框架上增长一些应用，实际上是没有必要作性能测试，由于老框架的使用确定是通过了验证的。若是一个系统采用的是一种新的框架，能够考虑作性能测试。

　　b）数据库要求：

　　　　　不少状况下，性能测试是大数据量的并发访问、修改数据库，而瓶颈在于链接数据库池的数量，而非数据库自己的负载、吞吐能力。这时，能够结合DBA的建议，来决定是否来作性能测试。

　　c）系统特殊要求：

　　　　　从实时性角度来分析，某些系统对响应时间要求比较，好比证券系统，系统的快慢直接影响客户的收益，这种状况就有做并发测试的必要，在大并发量的场景下，查看这个功能的响应时间。

　　　　　从大数据量上传下载角度分析，某些系统常常须要进行较大数据量的上传和下载操做，虽然此种操做使用的人数不会太多，可是也有必要进行性能测试，肯定系统能处理的最大容量，若是超过这个容量时系统须要进行相关控制，避免因为不人工误操做致使系统内存溢出或崩溃。

 

四、肯定性能测试点： 

　　在上面第3点中，咱们简单分析了如何肯定一个系统是否须要作性能测试。下面简单总结下若是一个系统肯定要作性能测试，咱们如何肯定被测系统的性能测试点？

　　咱们能够从下面几个方面进行分析：

• 关键业务：

  　　肯定被测项目是否属于关键业务，有哪些主要的业务逻辑点，特别是跟交易相关的功能点。例如转帐，扣款等接口。若是项目（或功能点）不属于关键业务（或关键业务点），则可转入下面。

• 日请求量：

  　　肯定被测项目各功能点的日请求量（能够统计不一样时间粒度下的请求量如：小时，日，周，月）。若是日请求量很高，系统压力很大，并且又是关键业务，该项目须要作性能测试，并且关键业务点，能够被肯定为性能点。

• 逻辑复杂度：

  　　断定被测项目各功能点的逻辑复杂度。若是一个主要业务的日请求量不高，可是逻辑很复杂，则也须要经过性能测试。缘由是，在分布式方式的调用中，当某一个环节响应较慢，就会影响到其它环节，形成雪崩效应。

• 运营推广活动：

  　　根据运营的推广计划来断定待测系统将来的压力。未雨绸缪、防患于未然、下降运营风险是性能测试的主要目标。被测系统的性能不只能知足当前压力，更须要知足将来必定时间段内的压力。所以，事先了解运营推广计划，对性能点的制定有很大的做用。例如，运营计划作活动，要求系统天天能支撑多少 PV、多少 UV，或者一个季度后，须要能支撑多大的访问量等等数据。当新项目（或功能点）属于运营重点推广计划范畴以内，则该项目（或功能点）也须要作性能测试。

　　以上 4 点，是相辅相成、环环相扣的。在实际工做中应该具体问题具体分析。例如，当一个功能点不知足以上 4 点，但又属于资源高消耗（内存、CPU），也可列入性能测试点行列。

 

五、肯定性能指标： 

　　性能需求分析一个很重要的目标就是须要肯定后期性能分析用的性能指标，性能指标有不少，能够根据具体项目选取和设定，而具体的指标值则须要根据业务特色进行设定，本文不详细进行阐述，后续可考虑就此单独写一篇。

 

2、性能测试准备

一、测试环境准备：

　　a）系统运行环境：这个一般就是咱们的测试环境，有些时候需求比较多，作性能测试担忧把环境搞跨了影响其它的功能测试，可能须要从新搭建一套专门用来作性能测试的环境。

　　b）执行机环境：这个就是用来生成负载的执行机，一般须要在物理机上运行，而物理机又是稀缺资源，因此咱们每次作性能测试都须要提早准备好执行机环境。

二、测试场景设计：根据性能需求分析来设计符合用户使用习惯的场景，场景设计的好很差直接影响到性能测试的效果。

三、性能工具准备：

　　a）负载工具：根据需求分析和系统特色选择合适的负载工具，好比LR、Jmeter或galting等

　　b）监控工具：准备性能测试时的服务器资源、JVM、数据库监控工具，以便进行后续的性能测试分析与调优。

四、测试脚本准备：若是性能测试工具不能知足被测系统的要求或只能知足部分要求时，须要咱们本身开发脚本配合工具进行性能测试。

五、测试数据准备：

　　a）负载测试数据：并发测试时须要多少数据？好比登陆场景？

　　b）DB数据量大小：为了尽可能符合生产场景，须要模拟线上大量数据状况，那么要往数据库里提早插入必定的数据量。这可能须要花费一些时间，特色是关联系统较多，逻辑复杂的业务可能同时涉及多张表。

六、其它：若是须要其它其它关联系统或专业人士如DBA配合的，也须要提早进行沟通。

 

3、性能测试执行

 一、人工边执行边分析

　　一般咱们作性能测试都是人工执行并随时观察系统运行的状况、资源的使用率等指标。性能测试的吸引力之一就在于它的不可预知性。当咱们在作性能测试的时候遇到跟预期不符的状况很正常，这个时候须要冷静的分析。但这个过程可能会很慢长，须要不断的调整系统配置或程序代码来定位问题，耗时耗人力。特别是在当前敏捷开发模式比较流行的大环境下，版本发布很是频繁且版本周期短（一般1~2周一个版本），没有那么长的时间来作性能测试。

二、无人值守执行性能测试

　　无人值守是最理想化的目标，目前咱们也朝着这个方向努力。无人值守不是说没有人力介入，而是把人为的分析和执行过程分离，执行过程只是机器服从指令的运行而已。一般测试环境在白天比较繁忙，出现性能问题及定位难度较大且会影响功能测试。因此通常性能测试最好在晚上或周末进行，在相对较安静的条件有利于测试结果的稳定性。这种方法也相对比较适合敏捷的模式，不须要人工一直守着。只须要在拿到结果后进行分析就行了。同进，这种方式对测试人员能力的要求比较高，须要咱们能进行自动化的收集各类监控数据、生成报表便于后续分析。

 

4、结果分析与调优

 

关于性能分析与调优这是一个比较大的话题，后续会单独进行总结和分析。

 

5、测试报告与总结

 　　性能测试报告是性能测试的里程碑，经过报告能展现出性能测试的最终成果，展现系统性能是否符合需求，是否有性能隐患。性能测试报告中须要阐明性能测试目标、性能测试环境、性能测试数据构造规则、性能测试策略、性能测试结果、性能测试调优说明、性能测试过程当中遇到的问题和解决办法等。

　　性能测试工程师完成该次性能测试后，须要将测试结果进行备案，并作为下次性能测试的基线标准，具体包括性能测试结果数据、性能测试瓶颈和调优方案等。同时须要将测试过程当中遇到的问题，包括代码瓶颈、配置项问题、数据问题和沟通问题，以及解决办法或解决方案，进行知识沉淀。