1.性能分析的基本原则 确定测试结果有效之后，接下来就要开始对测试数据进行深入地挖掘了。面对经过测试工具产生的纷繁复杂的原始测试数据，如果来进行分析呢？一个普遍遵循的原则是“由外而内，由表及里，层层深入”，如图4-1所示。 对于一个应用系统，性能开始出现下降的最直接表象就是系统的响应时间变长，于是，系统响应时间成为分析性能的起点。性能分析的原则如图4-1所示，首先应该从原始测试数据中查看系统响应时间，判读它是否满足用户对性能的期望。如果不满足，则说明系统的性能出现了问题。发现系统存在问题后，接着就要判断系统在哪个环节出现了瓶颈。 现在的IT系统架构极其复杂，任何一个环节出现瓶颈，都会导致系统出...

在Controller中执行的测试场景结束后，首先要做的是判断采集到的结果数据是否真实有效。多数的性能测试场景都需要迭代地进行测试，因此很多测试结果本身就不能反映问题，深入分析这样的结果纯属浪费时间。 判断测试结果是否有效，通常按下面的步骤进行。 第一步：在整个测试场景的执行过程中，测试环境是否正常。如果在测试过程中发生过异常，这样得出的结果往往不准确，不需要分析。 例如，在测试执行过程中，测试机的CPU利用率经常达到100%、测试环境的网络不稳定、一些系统参数配置不准确等，这样得出的测试结果没有必要分析，应该重新设置测试场景或者调整测试环境，再次执行测试。 第二步：测试场景的设置是否正确、合...

因为性能测试的目的就是为了发现系统的瓶颈，进而通过优化提高系统的性能，所以系统性能瓶颈分析是性能测试工作中最值得总结的一项内容。性能瓶颈分析主要侧重下面几个方面进行总结。 （1）应用系统瓶颈分析经验：大多数情况下性能瓶颈都来自于应用系统，因此总结系统的瓶颈经验十分重要。尤其是对于那些拥有不同目标客户同时需要进行参数配置的产品，很多时候由于配置不正确导致系统性能不高。通过对产品在以往客户产生的性能瓶颈原因进行总结，可以为以后测试时快速解决性能问题提供参考。 （2）数据库瓶颈分析经验：数据库经常由于配置或者设计不合理产生瓶颈，通过在项目中积累经验，可以在以后的测试分析中对数据库问题快速定位。例如，...

性能测试技术一般都会和测试工具联系起来，因此性能测试技术的总结主要是指工具使用方面的总结。测试工具与技术总结主要从下面三个方面入手。 1.测试过程的一些技术方面的总结 每次测试都可能会采用一些新的技术方法，这些都应该认真总结。建议把总结的结果以文档的形式放到测试部门或者公司的知识库中，为执行类似测试任务的人员提供参考。通过把这些技术成果存档备份，可以节省以后项目的性能测试实施成本。例如，某次测试可能开发一些新的测试工具或者类库，而这些工具或者类库很有可能在以后的测试中再次用到。 2.测试工具的使用经验总结 工具的使用在测试中占有很大的比重，很多关键性的工作要依赖工具来完成，因此团队需要认真总结...

性能测试场设计是性能测试核心工作之一，因此应该对性能测试场景设计进行认真地总结。尤其是针对产品的性能测试，以为测试场景可能会在产品升级或实施时重新使用。性能测试场景总结主要侧重一下三个方面。 1.测试场景可用性总结 对于一个比较完善的性能测试项目，经常会有一些测试场景不能够执行，因此测试完成后应该认真分析哪些场景没用执行以及不能执行的原因，这样分析可能为下次测试打好基础。例如，有些场景比较耗费硬件资源，超过了原有压力机规划，下次测试时就应该调整场景或提前准备好压力机资源。 2.场景执行效果分析 通过对场景执行效果进行分析，可以为升级或者开发新的性能测试场景提供有利的参考。不是所有的场景都能发现...

有了前面的性能测试需求分析和整体规划作为基础，那么制订性能测试计划就是一件十分容易的工作。 下面介绍一下如何编写性能测试计划各部分内容。 1.明确性能测试策略和测试范围 性能测试策略贯穿了整个性能测试过程，自始至终都是在指导着性能测试的开展。因此性能测试策略在计划的一开始就要明确。性能测试策略的制定方法可以参考2.2节的内容和第5章案例的相关部分。 性能测试范围也是计划一开始就要明确的内容，通常在第3.2.1节的性能测试需求分析相关工作中，已经确定了性能测试范围，因此只需要在编制计划时明确一下，使测试团队、客户等项目干系人形成共识即可。 需要注意的是，性能测试范围既要明确测试的具体内容，还要明...

人力资源规划主要是针对性能测试团队的规划，包含确定团队角色与落实人员等工作。对于一般应用软件的性能测试，可能一个性能测试工程师就会完成全部性能测试相关工作，因而不会专门探讨人力资源规划，但是对于系统软件或者特殊应用领域的软件，由于对性能要求很高，往往会组建一个专门的性能测试团队。 表3-2是多数性能测试团队涉及的角色与职责介绍 编号 角色名称 主要职责 1 项目经理 确定性能测试策略与目标，制订性能测试计划。负责测试工具的整体协调，与开发、支持等其他团队成员进行协作和沟通，保证性能测试工作的顺利进行 2 系统架构设计师 协助测试设计人员进行系统功能分析，找出系统的压力点...

在敏捷迭代的项目中，通常会将后台服务部署到多套测试环境。那么在进行接口自动化测试时，则需要将服务器的域名进行配置。使用一套接口测试脚本，通过切换域名地址配置，实现多套环境的自动化测试。 实战练习 分别准备两套测试环境，都对其发起get请求，传入参数name，对应值为hogwarts，并断言其响应值。 测试环境1：http://httpbin.org/get1 测试环境2：https://httpbin.ceshiren.com/get Python版本 importrequests 测试环境1测试用例 deftest_org(): res=requests.get(url="http:...

游戏开发公司通过各种检查、评估，确定了自己要开发游戏的范围或者项目，然后就需要对市面上的此类游戏进行测试。测试人员分别去玩和开发项目相同类型的游戏。全面的测试报告包括：可玩性、功能方面、画画、性能、所需配置、社群体系等。 游戏测试用例相对于软件测试用例来说会庞大很多，游戏本身就是一个比软件功能多很多的软件。可以按照以下思路设计测试用例。 1.基本功能的测试思路（如图） 游戏基本功能测试用例设计思路 每个测试项有相应的测试点，比如游戏启动测试项，其测试点根据图标、显示方式、启动时间、按键操作分类后进行测试内容细化，结果如表所示。 其他的测试点的细则不一一列举，根据游戏中的实际情况进行细化。 ...

性能测试往往受到产品发布里程碑的限制，因此需要通过合理的规划，使性能测试在保证进度的前提下，比较低的成本达到了预期的质量目标。性能测试规划的重点是时间、质量、成本等项目管理要素。 本小节主要是站在性能测试管理的角度讲解如何规划性能测试。由于在性能需求分析阶段进度和测试目标（即质量目标）大体已经确定，因此性能测试规划主要是面向成本的规划，具体就是对测试环境、测试工具和人力资源等进行规划。 很多时候，项目团队不会把测试环境和成本联系起来，忽略“测试环境”的规划，实际上两者关系密切。例如，开发的应用系统基于不同数据库均可以运行，性能测试规划时就要明确测试多少种系统支持的数据库，如果系统在一种数据库上...

确定了性能测试策略和目标后，接下来的任务是确定性能测试范围。确定性能测试范围是性能测试策略制订工作的延续。 之所以要确定性能测试范围，是因为全面性能测试需要投入很高的成本。因此在具体的项目中通常不会执行真正意义上的全面性能测试，“全面性能测试”是一个相对的概念，主要是指测试范围、测试种类是否满足测试策略与目标。 确定测试范围常见的方法是对测试项或者测试需求进行打分，根据综合评分确定性能测试工作包含哪些测试内容。评分要素主要包含客户关注度、性能风险、测试的成本等，性能风险主要是指不进行该项性能测试需求，然后投产系统可能潜在的风险。 大多数情况下都会把那些客户关注程度或者性能风险较高的测试需求划分...

性能测试需求分析与功能测试的需求分析没有太大区别，也是主要通过和项目干系人进行沟通以及一些项目文档来确定性能测试范围、性能测试策略等内容，为下一步制订性能测试计划打下良好的基础。 1.需求信息的来源 开发过程相关文档是性能测试需求的主要来源，项目开发计划书、需求规格说明书、设计说明书、测试计划等文档都可能涉及性能测试的要求或者一些性能测试方面的定义。收集这些原始性能需求信息，可以为后面制订性能测试计划、设计性能测试方面提供依据。 和性能测试需求相关的项目干系人主要包括客户代表、项目经理、产品经理、销售经理、需求分析员和架构设计师等。下面介绍各个项目干系人需要采集的主要信息。 （1）客户代表：通...

如果以乐观的态度来看性能测试工作，可以欣慰地说性能测试工作在企业中越来越受重视了，因为至少很多项目的管理人员甚至一些公司领导都知道“性能测试”这一工作。不过分析一下国内多数公司的软件开发环境，不难看出软件测试在开发过程中仍然没有受到足够的重视，作为测试工作一部分的性能测试，很容易被忽略也就不足为奇了，这也是国内很多软件产品处于“亚健康”状态的根本原因之一。 性能测试的地位决定了性能测试工作的管理和实施都会存在一定的困难。 1.性能测试习惯拖到最后阶段进行 导致拖后是很常见的一种现象。国内很多公司系统测试工作都会拖到最后阶段进行，这就导致性能测试很容易遇到下面的情形。 当项目或者产品开发的进度...

大多数性能测试项目会按照图3-1的流程来进行，即使在项目验收阶段启动性能测试也不例外。不过根据项目的实际情况可能会省略一些步骤，例如有一些“轻量级”的性能测试就可以不必单独去编写测试计划，因为在整个项目的测试计划中已经安排了性能测试。 下面介绍一下各个步骤的主要工作内容。 1.测试需求分析 测试需求分析是整个性能测试的基础，在这一阶段测试负责人要和项目干系人进行沟通，同时收集各种项目资料，尤其要搞清楚用户对待性能测试的核心需求。 测试需求分析阶段的主要任务是确定测试策略和测试范围。对于多数系统，性能测试策略主要根据软件类型等自身特点，以及用户对性能测试的核心需求等来确定，测试范围则根据测试策...

在性能测试工作中经常会提到“性能调优”或者“系统调优”等概念，实际上“性能调优“或者”系统调优”都属于性能调整的范畴。性能调整是比性能调优更准确的说法，例如可能为了让某些部分“更优”而把某些部分调得“不优”。 所谓性能调整是为了改变系统特性而对系统软件或者硬件进行的修改，性能调整不是测试人员的职责，性能测试工程师的主要任务是主要任务是发现定位性能问题。对于性能测试中发现的问题，通常由性能测试工程师、DBA、系统管理员、开发人员共同来解决，但是对于测试人员，了解调整的相关知识则是十分必要的。 1）确定问题 通常情况下，首先确定系统是否存在问题，并对问题进行正确的定位，重点是发现系统瓶颈。通常，确...

误区5：在开发环境下进行一下性能测试就可以了 很多时候，在系统开发完成后会进行性能测试，在开发环境“看一看”软件的性能。而实际上大多数的开发环境因为硬件条件比较差，所以反映不了系统的真正性能。这是因为系统的性能表现通常依赖于硬件，一些系统在资源不足的情况下可能运行缓慢，这类问题往往提高一下硬件配置就可以解决问题。一些系统在资源不足条件下发现的性能问题，主要通过优化程序来解决，则可能需要花费非常高的人力成本。当然，对于一些算法方面的缺陷、内存泄漏、低效SQL等问题，则无论任何环境下都应该修正程序来解决。 性能测试的最终目的是为了发现系统的软件和硬件瓶颈，因此性能测试尽量在软件和硬件尽可能接近用户...

性能测试以其独特的地位和重要性越来越为软件测试人员、开发人员和用户所重视，但是在实施性能测试方面，不管是测试人员还是开发人员，仍然存在一些认识上的不足，存在这样或者那样的问题。 误区1：提高硬件配置就可以提高性能了，因此性能测试不重要。 这是以前系统规模较小时期留下来的认识。早期的DOS时代以及后来管理信息系统刚刚流行的时期，软件规模一般较小，而硬件的更新确实日新月异，软件的性能一般不是突出问题，因为只要升级硬件，性能问题很容易得到解决。 现在随着软件规模的扩大，提高硬件配置只是解决性能问题的一个基本手段。因为如果软件自身存在性能问题，再多的资源可能也不能够用，例如内存泄漏问题，随着时间的增加...

系统性能测试包含很多内容、种类，例如峰值测试、负载测试、压力测试、强度测试都属于性能测试的范畴。 在通常的系统性能测试工作中，可能涉及的性能测试种类主要有峰值测试、压力测试、负载测试、强度测试、容量测试、并发测试、可靠性测试、配置测试，以及狭义范围的性能测试等。多数团队中，这些种类的性能测试很少单独一一实施，一般会结合起来实施或选择其中几种来实施。对于初学者很多时候这些名词会误导初学者，搞不清这些测试种类的区别和关系，又不知道如何开展工作。实际上，上面提到的性能测试基本属于联机交易的性能测试范畴，而这些性能测试种类的本质都是并发用户的性能测试：或者调整加压方式、或者调整加压时间、或者调整压力大...

请求响应时间：请求响应时间指的是客户端发出请求得到响应的整个过程的时间。这个过程是从客户端发起的一个请求开始时，到客户端接收到从服务区端返回的响应结果为止时结束。在某些工具中，请求响应时间通常会被称为TTLB，即TimetoLastByte,意思是从发起一个请求开始，到客户端收到最后一个字节的响应所耗费的时间。请求响应时间的单位一般为“秒(s)”或者“毫秒（ms）”。请求响应时间的分解如图1-1所示。 从图1-1可以看出，请求响应时间为“网络响应时间”和“应用程序与系统响应时间”之和，具体由七个部分组成，即（N1+N2+N3+N4）+(A1+A2+A3)。 事务响应时间：事务可能由一系列请求...

以下都是性能测试中出现频率比较高的词汇。掌握了这些基础的性能测试知识、可以更好地开展测试工作。典型的术语主要有并发用户、并发用户数量、请求响应时间、事物响应时间、吞吐量、TPS、点击率、资源利用率等。 并发用户： 并发一般分两种情况。一种是严格意义上的并发，即所有的用户在同一时刻做同一件事或者操作，这种操作一般是指做同一类型的业务，例如，在贷款审批业务中，一定数目的用户在同一时刻对已经完成的审批业务进行提交（操作的不是同一记录）；还有一种是特例，即所有用户进行完全一样的操作。例如，在三方存管业务中，所有的用户可能会在一起进行银行转账业务，测试操作同一个券商账户时的性能，模拟这类并发用...