SAAS技术交流系列（二） - 性能测试

一、   性能测试的概念

性能测试是一项综合性的工作，致力于暴露性能问题，评估系统性能趋势。性能测试工作实质上是利用工具去模拟大量用户操作来验证系统能够承受的负载情况，找出潜在的性能问题，分析并解决；找出系统性能变化趋势，为后续的扩展提供参考。

 

二、   性能测试的价值

随着互联网的发展，单机软件的逐渐减少，系统从单机步入“云”时代，软件系统功能和规模也越来越庞大，盗版也越来越难，用户规模也越来越大，企业盈利随之爆发式地增长。随着用户数量的增多，系统稳定就成为企业的首要技术保障，稳定才能带来流量，才能赚钱。

 

三、   软件测试分类

从图可以看到性能测试在整个软件测试环节占了50%的内容，如测试内容中，负载测试、压力测试、性能测试、大数据量测试、恢复测试、内存泄露测试、竞品测试（比较测试）和可靠性测试。一共14个测试内容，性能的测试占领8个，可想而知性能测试在软件测试中的重要程度。

软件业大部分软件开发之初一般考虑的是软件功能的市场需求契合度，是否能被市场认可。这个前提成立之后，才会有较大的用户群体去使用，从而出现性能问题。然而根据金子塔理论，到了后期在进行修改，投入和产出不成比例。一般公司在做出确定可以盈利的产品后，会对产品进行再次开发，来达到这个性能要求。所以第一个产品（试验）的性能要求和真正的推广产品（成熟）的性能要求不是一个量级，企业发展到一定程度就得关注性能，重视性能。性能测试的价值就是保障系统的性能，提供良好的用户体验；尽可能地找出系统性能薄弱环节，帮助进行性能优化。

 

四、   性能测试成功与失败要素

性能测试上手难度比较高，是一门融合测试、开发、运维、需求调研、架构、协调管理等综合技能的学科，掌握一门性能测试工具对于性能测试来说只是万里长征的第一步，没有一定的需求、开发和运维专业能力，往往会吃一些苦头。

性能测试有几大难点：

（1）需求分析；

（2）场景设计；

（3）性能诊断调优。

（4）环境搭建和模拟

往往很多性能测试从业者在需求分析方面没有做到位，不能准确地预估用户行为；在场景上不能复现用户操作，无法把需求体现在脚本和场景设计上，无法模拟真实的系统负载；这种状态下做出的性能测试往往结果良好，上线出问题，导致整个项目团队狼狈不堪，整个公司手忙脚乱。

性能诊断调优是一门有效利用和协调硬件软件的“艺术”，从Oracle Exadata诞生之初在软件层面的优化就可以有200倍至10000倍之多。但是性能诊断和调优是有时间和经济成本的，也是需要全面的IT知识体系的专家或者团队才能比较全面地挖掘出系统的性能问题并给出调优方案。

很多性能测试初学者总觉得性能测试就是写个脚本，弄几台机器应付，出个报告就行了。通常关注并发多少，响应时间多少，能跑通吗等问题认为并发越大，响应时间越快，那性能一定就越好，实际上我们需要对系统进行一系列复杂精密的工作才能开始性能测试执行，经过N次回归，找到瓶颈的具体原因，优化再验证。

下面讲解性能测试重要关注点。

1． 评估系统，需求分析

对于初次上线的系统，我们需要用同行的系统数据，进行用户行为分析和商业数据结构的估算为前提，利用性能估算法推算。得到的负荷和响应时间数据可以被用于验证所计划的模型的能力，并帮助作出决策。

对于已经上线的系统，我们可以通过运维人员获取TPS和时间的比例分布图、用户数和时间的分布图、数据库ER关系图、容量数据等，直接精确得出目前的系统的用户行为和业务数据关系，进而得出我们需要的性能需求。

2． 场景设计、用例设计

充足的需求调研与分析之后，我们要在测试场景中尽可能真实地复原系统负载。通过需要我们要决定哪些功能要参与性能执行，如何参与？这就是用例设计。如何有效地组织测试用例就是场景要做的事，按业务分布、业务量、业务时段、业务角色来综合分配用户数、执行时间、执行比例等。看似简单，实际操作起来还是比较麻烦的。

3． 测试执行、是否通过

模拟不同负载执行测试场景来识别系统弱点：做好各种监控，甄别各种问题；验证系统的稳定性。下面是我们在执行时常见的需要关注的指标，如下图所示。

4． 性能诊断优化

性能诊断知识面要求甚广，系统日益复杂，单打独斗的日子已经远去，依靠团队力量才能够高效完成诊断任务。性能测试从业者要具备良好、敏感的性能意识，能够把遇到的问题初步分类，协助各开发团队完成问题定位、分析调优。所以首先要是一个好的协调者，还是一个技术面广的技术人员，具备跨领域知识，如开发、运维、数据库、缓存等。

 

五、   不同角色看性能

下图是当前典型的系统性能涉及的方面，需要多个工种（有架构师、开发、系统管理员、DBA、测试等）一起协调才能完成工作，每个环节都可能是瓶颈，造成阻塞。相对于目前国内的IT软件部门环境，因为需要协调多部门，所以性能测试工作人员必须是一个复合型人才，对于各工作的知识有所了解也要求有一定的项目协调能力，来引导大家同心协力地完成此项复合任务，靠单人是不太可能完成如此具有挑战的工作。

技术部门一般有以下几种常见的角色，开发、测试、架构师、运维人员-（系统管理员、DBA）等。下面我们看看不同角度对于系统的要求。

1． 黑盒测试的角度　

黑盒测试操作应用界面——数据请求经过网络发送——服务器前端接收处理——在DB server获取相关数据——前端处理后返回数据——应用界面收到数据响应下一步。

黑盒测试只关心应用程序的单步响应时间，性能好坏就看应用时间多少，也就是数据流经过服务器/服务器集群经过网络传输后往返的时间总和。

2．开发角度

（1）架构合理性（2）数据库设计合理性（3）代码（4）系统里内存的使用方式（5）系统里线程使用方式（6）系统资源是否有恶性，不合理竞争（7）作为一个开发人员，只关注功能的代码实现，很少有精力去关注数据库的设计，框架的设计是否合理，系统里内存的使用方式是否合理、系统里线程使用方式是否合理、系统资源会不会有可能存在不合理竞争。他们通常认为这些是架构师去考虑的问题，但是在我国普遍的中小软件公司，很少有去考虑这些事情。

3．系统管理员角度

（1）硬件资源利用率（2）JVM（3）DB（4）换哪些硬件能提高系统性能（5）系统能否支持7*24的服务（6）扩展性，兼容性，最大容量，可能的瓶颈（7）作为运维人员通常关注这套系统所有服务器是否正常运行，一般关注这些服务器（数据库、中间件等服务器）的硬件资源利用率情况，如内存是否有可用空间，CPU是否超过70%，网络是否通畅、I/O是否存在瓶颈。这些服务器和配置是否能支撑几个月甚至几年稳定无问题地运行这套系统。除此之外还考虑，随着公司业务的增大，吞吐量需求加大，是否增加服务器就可以等比例地提高系统的综合吞吐量。

4．性能测试的角度

（1）服务器硬件性能（2）根据需求和历史数据制定性能目标（3）建立性能通过模型（4）对开发代码框架和硬件框架进行性能分析（5）针对开发发布版本的基准测试（6）执行软件性能验收及稳定性测试（7）生产环境的配置和优化（8）制定性能测试的测试用例（9）制定性能测试的场景设计（10）协调各部门配合（11）特定的性能分析

 

六、   性能测试工具选择

工欲善其事必先利其器，性能测试时模拟大量负载需要工具帮忙，市面上可供使用的负载工具繁多，如何选择呢？

首先我们要明白负载工具是帮助我们来模拟负载的，对于性能测试来说，工具并不是核心，分析、评估、找出性能问题才是核心，这些是主观因素；工具是客户因素，自然要降低其对结果的影响，所以工具选择时我们有几个方面要考虑。

（1）专业、稳定、高效，比如Loadrunner，工业级性能负载工具。

（2）简单易上手，在测试脚本上不用花太多时间。

（3）有技术支持，文档完善，不用在疑难问题上花费时间，集中精力在性能分析上。

（4）要考虑投入产出比，比如我们可以选择免费开源的JMeter。当然有时候自研或者使用开源不一定比商业工具更省钱，因为要做技术上的投资，时间上的投资。

常见性能工具：

（1）HP公司的LoadRunner；

（2）Apache JMeter（开源）；

（3）Grinder（开源）；

（4）CompuWare 公司的QALoad；

（5）Microsoft公司的WAS ；

（6）RadView公司的WebLoad ；

（7）IBM公司的RPT ；

（8）OPENSTA等。

 

七、   性能测试通过标准

性能测试从需求、设计、准备、执行到分析，最后需要判断性能测试是否通过，性能测试工程师最终需要考虑很多因素，判断的标准相应也会有多个维度。

性能测试通过标准包括服务端性能、前端性能和用户体验性能，常规通过标准如表所示。

八、参考文献

全栈性能测试修炼宝典-Jmeter实战

https://yq.aliyun.com/articles/92267?spm=5176.100239.blogcont92259.18.9tNTGQ云栖社区