任务1.1 性能需求分析.pptx

《任务1.1 性能需求分析.pptx》由会员分享，可在线阅读，更多相关《任务1.1 性能需求分析.pptx（39页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、课程主讲人：任务1.1 性能需求分析模块1 性能测试需求分析任务1.1 性能需求分析知识储备 一些性能测试人员常犯的错误就是测试一开始就直接用工具对系统进行加压，没有弄清楚性能测试的目的，做完以后也不知道结果是否满足性能需求。 市面上的书籍也大都是直接讲性能测试工具，如LoadRunner、JMeter如何使用，导致很多新手一提到性能测试就直接拿工具来进行录制回放，使得很多人认为会使用性能测试工具就等于会性能测试，殊不知工具的使用其实只是性能测试过程中很小的一部分。性能测试需求分析概述首先，通过性能需求分析需要得出以下结论或目标：明确性能测试的必要性和目的。明确被测试系统的架构、平台、协议等相

2、关技术信息。明确被测系统的基本业务、关键业务，用户行为等。明确性能测试点。明确被测系统未来的业务拓展规划以及性能需求。明确性能测试策略。明确性能测试的指标。性能测试需求分析概述其次，需求分析阶段可以从以下几个方面入手：系统信息调研业务信息调研性能需求评估确定性能测试点确定性能指标13452性能测试需求分析概述系统信息调研指对被测试系统进行分析，需要对其有全面的了解和认识，这是做好性能测试的前提，而且在后续进行性能分析和调优时将会大有用处。系统信息调研性能测试需求分析概述业务信息调研指对被测试的业务进行分析，通过对业务的分析和了解，方便后续进行性能测试场景的确定以及性能测试指标的确定。业务信息调

3、研性能测试需求分析概述在实施性能测试之前，需要对被测系统进行相应的评估，主要目的是明确是否需要进行性能测试。如果确定需要做性能测试，需要进一步确定性能测试点和指标，明确该测什么、性能指标是多少，测试是否通过的标准，性能指标也会根据情况评估，要求被测系统能满足将来一定时间段的业务压力。判断是否进行性能测试主要从下面两个方面进行思考u 业务角度u 系统角度性能需求评估性能测试需求分析概述业 务角 度 系统是公司内部使用还是对外使用，系统使用的人数是多少，如果一个系统上线后使用人数很少，无论系统多大，设计多么复杂，并发性的性能测试都是没必要的，前期可以否决。当然，除非在功能测试阶段发现非常明显的性能

4、问题，使得用户体验较差的，此时可进行性能测试来排查问题。性能需求评估性能测试需求分析概述很多情况下，性能测试是大数据量的并发访问、修改数据库，而瓶颈在于连接数据库池的数量，而非数据库本身的负载、吞吐能力。这时可以结合DBA的建议，来决定是否进行性能测试。数据库要求从实时性角度来分析，某些系统对响应时间要求比较高，比如证券系统，系统响应的快慢直接影响客户的收益，这种情况就有必要进行并发测试，在大并发量的场景下，查看这个功能的响应时间。 系统特殊要求如果一个系统采用的框架是老的系统框架（通常大公司都有自己的统一框架），只是在此框架上增加一些应用，其实是没有必要进行性能测试，因为老框架的使用肯定是经

5、过验证的。如果一个系统采用的是一种新的框架，可以考虑进行性能测试。系统架构从大数据量上传下载角度分析，某些系统经常需要进行较大数据量的上传和下载操作，虽然此种操作使用的人数不会太多，但是也有必要进行性能测试，确定系统能处理的最大容量，如果超过这个容量，系统就需要进行相关控制，避免由于人工误操作导致系统内存溢出或崩溃。系 统角 度性能需求评估性能测试需求分析概述确定被测项目是否属于关键业务，有哪些主要的业务逻辑点，特别是跟交易相关的功能点，例如转账、扣款等接口。如果项目（或功能点）不属于关键业务（或关键业务点），则可考虑后续方面。关键业务判定被测项目各功能点的逻辑复杂度，如果一个主要业务的日请求

6、量不高，但是逻辑很复杂，则也需要进行性能测试，原因是在分布式方式的调用中，当某一个环节响应较慢，就会影响到其他环节，造成雪崩效应。运营推广活动确定被测项目各功能点的日请求量（可以统计不同时间粒度下的请求量，如小时、日、周、月），如果日请求量很高，系统压力很大，而且又是关键业务，该项目需要进行性能测试，而且是关键业务点，可以被确定为性能点。日请求量根据运营的推广计划来判定待测系统未来的压力，未雨绸缪、防患于未然、降低运营风险是性能测试的主要目标。被测系统的性能不仅能满足当前压力，更需要满足未来一定时间段内的压力。因此，事先了解运营推广计划，对性能点的制定有很大的作用，例如，运营计划做活动，要求系

7、统每天能支撑多少PV、多少UV，或者一个季度后，需要能支撑多大的访问量等。当新项目（或功能点）属于运营重点推广计划范畴之内，则该项目（或功能点）也需要进行性能测试。逻辑复杂度确定性能测试点性能测试需求分析概述 性能需求分析一个很重要的目标就是需要确定后期性能分析用的性能指标。性能指标有很多，可以根据具体项目选取和设定，而具体的指标值则需要根据业务特点进行设定。确定性能指标 针对整体的需求分析，需要测试人员掌握性能测试的方法、常用指标、应用领域等知识，综合考虑性能测试流程。性能测试方法验收测试验收性能测试方法通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求。这是一种

8、最常见的测试方法。这种测试方法要在特定的运行条件下验证系统的能力状况。该方法具有以下特点：这种方法的主要目的是验证系统是否具有系统宣称具有的能力。验收性能测试方法包括确定用户场景、给出需要关注的性能指标、测试执行、测试分析几个步骤。这是一种完全确定系统运行环境和测试行为的测试方法，其目的只能是依据事先的性能规划，验证系统是否达到其宣称的具有的能力。这种方法需要事先了解被测试系统的典型场景，并具有确定的性能目标。验收性能测试方法需要首先了解被测系统的典型场景。所谓的典型场景，是指具有代表性的用户业务操作。一个典型场景包括操作序列和并发用户数量条件。其次，这种方法需要有确定的性能目标，性能目标的描

9、述方式一般为“要求系统在100个并发用户的条件下进行A业务的操作，响应时间不超过5 s”。这种方法要求在已确定的环境下运行。验收性能测试方法的运行环境必须是确定的，软件系统的性能表现与很多因素相关，无法根据系统在一个环境上的表现去推断其在另一个不同环境中的表现，因此，对这种验收性的测试，必须要求测试时的环境（硬件设备、软件环境、网络条件、基础数据等）都已经确定。性能测试方法负载测试负载测试方法在被测系统上不断增加压力，直到性能指标（如响应时间）超过预定指标或某种资源使用已经达到饱和状态。负载测试方法可以找到系统的处理极限，为系统调优提供数据，有时也称可置性测试。该方法具有以下特点：这种性能测试

10、方法的主要目的是找到系统处理能力的极限。负载测试方法通过“检测加压性能指标超过预期”的手段，找到系统处理能力的极限，该极限一般会用“在给定条件下最多允许120个并发用户访问”或是“在给定条件下最多能够在1小时内处理2 100笔业务”这样的描述来体现。而预期的性能指标一般会被定义为“响应时间不超过10s”“服务器平均CPU利用率低65%”等指标。这种性能测试方法需要在给定的测试环境下进行，通常也需要考虑被测系统的业务压力量和典型场景，使得测试结果具有业务上的意义。负载测试方法由于涉及预定性能指标等需要进行比较的数据，也必须在给定的测试环境下进行。另外，负载测试方法在“加压”的时候，必须选择典型场

11、景，在增加压力时保证这种压力具有业务上的意义。这种性能测试方法一般用来了解系统的性能容量，或是配合性能调优来使用。负载测试方法可以用来了解系统的性能容量（系统在保证一定响应时间的情况下能够允许多少并发用户的访问），或是用来配合性能调优，以比较调优前后的性能差异。性能测试方法压力测试压力测试方法测试系统在一定饱和状态下，例如CPU、内存等在饱和使用情况下，系统能够处理的会话能力，以及系统是否会出现错误。该方法具有以下特点：这种性能测试方法的主要目的是检查系统处于压力情况下时应用的性能表现。压力测试方法通过增加访问压力（如增加并发的用户数量等），使应用系统的资源使用保持在一定的水平，这种测试方法的

12、主要目的是检验此时的应用表现，重点在于有无出错信息产生、系统对应用的响应时间等。这种性能测试一般通过模拟负载等方法，使得系统的资源使用达到较高的水平。一般情况下，会把压力设定为“CPU使用率达到75%以上、内存使用率达到70%以上”这样的描述，在这种情况下测试系统的响应时间、系统有无产生错误。除CPU和内存使用率的设定外，JVM的可用内存、数据库的连接数、数据库服务器CPU利用率等都可以作为压力的依据。这种性能测试方法一般用于测试系统的稳定性。用压力测试的方法考察系统的稳定性是出于这样的考虑：“如果一个系统能够在压力环境下稳定运行一段时间，那么这个系统在通常的运行条件下应该可以达到令人满意的稳

13、定程度。”在压力测试中，会考察系统在压力下是否会出现错误，测试中是否有内存等问题。性能测试方法并发测试并发测试方法通过模拟用户的并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题。该方法具有以下特点：这种性能测试方法的主要目的是发现系统中可能隐藏的并发访问时的问题。并发测试方法是通过并发手段发现系统中存在问题的最常用方法。例如，应用在实验室测试时一切正常，但一旦交付给用户，在用户量增大以后，就可能会出现各种莫名其妙的问题。解决这类问题的方法之一是在实验室进行仔细的并发模拟测试。这种性能测试方法主要关注系统可能存在的并发问题，例如系统中的内存泄漏、线程死

14、锁和资源争用方面的问题。并发测试在测试过程中主要关注系统中的内存泄漏、线程死锁等问题。这种性能测试方法可以在开发的各个阶段使用，需要相关的测试工具的配合和支持。并发测试可以针对整个系统进行，也可以仅仅为验证某种架构或是设计的合理性来进行，因此其可以在开发的各个阶段使用。一般来说，并发测试除需要性能测试工具进行并发负载的产生外，还需要一些其他工具进行代码级别的检查和定位。性能测试方法并发测试并发测试主要关注的问题性能测试常用指标并发用户数 在阐述“并发用户数”术语前，先来看看为什么在性能测试中需要关注并发用户数。 首先，如果性能测试的目标是验证当前系统能否支持现有用户的访问，最好的办法就是弄清楚

15、会有多少用户会在同一个时间段内访问被测试的系统，如果使用性能测试工具模拟出与系统的访问用户数相同的用户，并模拟用户的行为，那得到的测试结果就能够真实反映实际用户访问时的系统性能表现，这样一来，就能够通过性能测试了解当系统处于实际用户访问下时，会具有怎样的性能表现。这里提到的在同一个时间段内访问系统的用户数量，也就是并发用户数的一个概念，这种并发的概念通常在性能测试方法中使用，用于从业务的角度模拟真实的用户访问，体现的是业务并发用户数。 如果抛开业务的层面，仅从服务器端承受的压力来考虑，那么，对C/S或B/S结构的应用来说，系统的性能表现毫无疑问地主要由服务端决定。在什么时候服务端会承受最大的压

16、力？或者说，在什么时候服务端表现为最差的性能呢？毫无疑问，肯定是在大量用户同时对这个系统进行访问的时候。越多的用户同时使用系统，系统承受的压力越大，系统的性能表现也就越差，而且，很可能出现由于用户的同时访问导致的资源争用等问题。在这里提到“并发用户数”的另一个概念，该概念不从业务角度出发，而是从服务端承受的压力出发，描述的是同时间从客户端发出请求的客户，该概念一般结合并发测试使用，体现的是服务端承受的最大并发访问数。性能测试常用指标并发用户数 对服务端来说，每个用户和服务端的交互都是离散的。如果仅考虑一个单独的用户对系统的使用，过程为用户每隔一段时间向服务端发送一个请求或命令，服务端按照用户的

17、要求执行某些操作，然后将结果返回给用户。 从用户的角度来看，在一个相当长的时间段内（如1天），都会有基本固定数量的使用者使用该系统，虽然每个使用者的行为不同，但从业务的角度来说，如果所有用户的操作都没有遇到性能障碍，则可以说该系统能够承受该数量的并发用户访问，这里的“并发”概念就是上面讨论的业务并发用户数。 然而，如果考虑整个系统运行过程中服务器所承受的压力，情况就会不同，在该系统的运行过程中，我们把整个运行过程划分为离散的时间点，在每个点上，都有一个同时向服务端发送请求的客户数，那是服务端承受的最大并发访问数。如果能找到运行过程中可能出现的最大可能的服务端承受的最大并发访问数，则在该用户数下

18、，服务器承受的压力最大，资源承受的压力也最大，在这种状态下，可以考虑通过并发测试发现系统中存在的并发引起的资源争用等问题。性能测试常用指标并发用户数 上面提到的两个不同的“并发”概念之间最根本的不同可以这样理解，假如采用第一种“并发”概念，同样是2 000人规模的并发用户数，如果用户的操作方式不同（场景不同），服务器承受的压力是完全不同的（设想两种极端的情况，在一种情况下，所有用户平均每秒单击一次鼠标，发起一个业务，而在另一种情况下，所有用户平均5 s才单击一次鼠标，发起一个业务，则很明显，两种情况下服务器可能承受的最大压力是不同的）；而在采用后一种“并发”的概念时，如果两种情况下有相同的最大

19、并发用户数，则说明这两种情况下服务器承受的最大压力是相同的。 在实际的性能测试中，经常接触到的与并发用户数相关的概念还包括系统用户数和同时在线用户人数，下面用一个实际的例子来说明它们之间的差别。 假设有一个OA系统，该系统有2 000个用户，这就是说，可能使用该OA系统的用户总数是2 000名，这个概念就是“系统用户数”，该系统有一个“在线统计”功能（系统用一个全局变量计数所有已登录的用户），通过该功能可以得到，最高峰时有500人在线（这个500就是一般所说的“同时在线人数”），那么，系统的并发用户数是多少？性能测试常用指标并发用户数 根据我们对业务并发用户数的定义，500即是整个系统使用时的

20、最大的业务并发用户数。当然，500这个数值只是表明在最高峰时刻有500个用户登录系统，并不表示服务器实际承受的压力。因为服务器承受的压力还与具体的用户访问模式相关。例如，在这500个同时使用系统的用户中，考察某一个时间点，假设其中40%用户在饶有兴致地看系统公告（“看”这个动作是不会对服务端产生任何负担的），20%用户在填写复杂的表格（对用户填写的表格来说，只有在“提交”时才会向服务端发送请求，填写过程是不对服务端构成压力的），20%用户在发呆（也就是什么也没有做），剩下的20%用户在不停地从一个页面跳转到另一个页面，在这种场景下，可以说，只有20%的用户真正对服务器构成压力。因此，服务器实际

21、承受的压力不只取决于业务并发用户数，还取决于用户的业务场景。 那么，该系统的服务端承受的最大并发访问数是多少取决于业务并发用户数和业务场景，一般可以通过对服务器日志的分析得到。性能测试常用指标响应时间 响应时间是“对请求做出响应所需要的时间”，响应时间是用户视角软件性能的主要体现。 响应时间既有客观的成分，也有主观的成分。例如，对一个Web应用来说，如果某页面的主要功能是向用户提供可“阅读”的内容，那么用户很可能会将“页面开始显示可阅读的内容”这个时间作为自己感受到的响应时间；而对一个主要功能是提供给用户“交互”的页面，只有当用户可以开始在页面上进行交互后，才会觉得页面“响应完成”。将用户感受

22、到的响应时间定义为“用户响应时间”，毫无疑问，“用户响应时间”是最直观地反映应用是否满足客户需求的指标，但由于该响应时间中包含主观性，很难被准确度量，因此，对响应时间的讨论主要基于呈现时间与服务端响应时间两方面。 用户所感受到的软件性能（响应时间）分为呈现时间和服务端响应时间两部分。其中，呈现时间取决于数据在被客户端收到后呈现给用户所消耗的时间，例如，对于一个Web应用，呈现时间就是浏览器接收到响应数据后呈现和执行页面上的脚本所消耗的时间；而服务端响应时间指应用系统从请求发出开始到客户端接收到数据所消耗的时间。性能测试常用指标响应时间 呈现时间的主要构成是前端响应时间，这部分时间主要取决于客户

23、端而非服务端。性能测试是否需要关注前端性能，主要取决于应用本身的特点和期望的运行环境。例如，一台内存不足的客户端机器在处理复杂页面的时候，其呈现时间可能就很长，而这并不能说明整个系统的性能。对于Web应用来说，即使使用同样配置的计算机，合理地使用前端技术也能极大地减少前端响应时间，因此有必要对前端响应时间进行深入的研究。 响应时间可以被进一步分解。图5-1-1-5描述了一个Web应用的页面响应时间的构成。从图中可以看到，页面的服务端响应时间可被分解为网络传输时间（N1+N2+N3+N4）和应用延迟时间（A1+A2+A3），而应用延迟时间又可以分解为数据库延迟时间（A2）和应用服务器延迟时间（A

24、1+A3）。之所以要对响应时间进行这些分解，主要目的是能够更容易地定位性能瓶颈。性能测试常用指标响应时间 图 5-1-1-5性能测试常用指标响应时间 关于响应时间，要特别说明的一点是，对客户来说，该值是否能够被接受带有一定的主观色彩，也就是说，响应时间的“长”和“短”没有绝对的区别。 例如，对一个电子商务网站来说，一个普遍被接受的响应时间标准为2/5/10 s，也就是说，在2 s之内给客户响应被用户认为是“非常有吸引力的”，在5 s之内响应客户被认为是“比较不错的”，而10 s是客户能接受的响应的上限。 但考虑一个税务报账系统，用户每月使用一次该系统，一次花费2小时以上进行数据的录入，当用户单

25、击“提交”按钮后，即使系统在20分钟后才给出“处理成功”的消息，用户仍然不会认为该系统的响应时间不能接受，毕竟，相对于一个月才进行一次的操作来说，20分钟确实是一个可以接受的等待时间。 因此，在进行性能测试时，合理的响应时间取决于实际的用户需求，而不能依据测试人员的设想来决定。性能测试常用指标吞吐量 吞吐量指单位时间内系统处理用户的请求数。 从业务角度看，吞吐量可以用请求数/秒、页数/秒、人数/天、处理业务数/小时等单位来衡量。 从网络角度看，吞吐量可以用字节/秒来衡量。 对于交互式应用来说，吞吐量指标反映的是服务器承受的压力。在容量规划的测试中，吞吐量是一个重点关注的指标，它能够说明系统的负

26、载能力。 以不同方式表达的吞吐量可以说明不同层次的问题。例如，以字节数/秒方式可以表示数据要受网络基础设施、服务器架构、应用服务器制约等方面的瓶颈；以请求数/秒的方式表示主要是受应用服务器和应用代码的制约体现出的瓶颈。 当没有遇到性能瓶颈的时候，吞吐量与虚拟用户数之间存在一定的联系，可以采用以下公式计算：F=VUR/T。其中F为吞吐量，VU表示虚拟用户个数，R表示每个虚拟用户发出的请求数，T表示性能测试所用的时间。性能测试常用指标TPS 事务是用户某一步或几步操作的集合。不过，通常要保证它有一个完整意义。比如，用户对某一个页面的一次请求，用户对某系统的一次登录，淘宝用户对商品的一次确认支付过程

27、。这些都可以看作一个事务。那么如何衡量服务器对事务的处理能力，又引出一个概念TPS（Transactions Per Second，每秒钟系统能够处理事务或交易的数量），它是衡量系统处理能力的重要指标。性能测试常用指标点击率 点击率指每秒用户向Web服务器提交的HTTP请求数。这个指标是Web应用特有的一个指标。Web应用是“请求响应”模式，用户发出一次申请，服务器就要处理一次，所以点击是Web应用能够处理的交易的最小单位。如果把每次点击定义为一个交易，点击率和TPS就是一个概念。容易看出，点击率越大，对服务器的压力越大。点击率只是一个性能参考指标，重要的是分析点击时产生的影响。需要注意的是，

28、这里的点击并非指鼠标的一次单击操作，因为在一次单击操作中，客户端可能向服务器发出多个HTTP请求。性能测试应用领域能力验证 能力验证是性能测试中最简单也是最常用的一个应用领域。一个典型的能力验证的问题会采用“某系统能否在A条件下具有B能力”的描述方式。例如，为客户进行系统上线后的验收测试，或是作为第三方对一个已部署系统的性能进行验证，都属于这种性能测试应用领域内的测试。能力验证领域的特点与性能测试的特点非常接近。要求在已确定的环境下运行。能力验证要求运行环境必须是确定的。只有在确定的运行环境下，软件性能的承诺和规划才是有意义的。因为无法或很难根据系统在一个环境中的表现去推断其在另一个不同环境中

29、的表现，因此这种应用领域内的测试必须要求测试时的环境（如硬件设备、软件环境、网络条件、基础数据等）已确定。需要根据典型场景设计测试方案和用例。能力验证需要了解被测系统的典型场景，并根据典型场景设计测试方案和用例。一个典型场景包括操作序列和并发用户数量条件。在设计用例时，需要确定相应的性能目标。性能测试应用领域规划能力 规划能力应用领域与能力验证应用领域有些不同，能力验证应用领域关心的是“在给定条件下，系统能否具有预期的能力表现”，而规划能力应用领域关心的是“应该如何使系统具有要求的性能能力”或是“在某种可能发生的条件下，系统具有如何的性能能力”。规划能力应用领域内的问题常常会被描述为“某系统能

30、否支持未来一段时间内的用户增长”，或是“应该如何调整系统配置，使系统能够满足增长的用户数的需要”。规划能力领域具有以下特点：它是一种探索性的测试。规划能力领域侧重的是规划。也就是说，该领域内的测试不依赖于预先设定的用于比较的目标，而是要求在测试过程中了解系统本身的能力。这种测试与能力验证领域内测试的最大区别就在其探索性。所谓非探索性测试，是指测试过程中已建立明确的测试预期，得到测试结论的方法是用实际的结果与预期的结果进行比较，一致则说明“通过”，否则说明“不通过”。而探索性测试则没有在测试中建立明确的测试预期，测试要求得到的结论是非确定的，对性能测试来说，即是“这种条件下，系统的性能表现如何”

31、这类问题的答案。它可被用于了解系统的性能以及获得扩展性能的方法。规划能力领域的问题是期望了解系统的能力，或是获得扩展系统性能的方法。该领域在测试过程中，除要通过负载测试等方法获知系统性能表现外，还需要通过更换设备、调整参数等方法获知系统性能可扩展的元素。性能测试应用领域性能调优 性能调优应用领域主要对应于对系统性能进行调优。一般来说，性能调优活动会和其他性能测试应用领域的活动交杂在一起。由于性能调优可以调整的对象众多，而且并不要求在系统全部完成后才能进行调优（在开发阶段也可针对某个设计或是某种实现方法进行调优），因此可以在多种不同的测试阶段和场合下使用。 对已经部署在实际生产环境中的应用系统来

32、说，对其进行的性能调优可能会首先关注应用系统部署环境的调整，例如，对服务器的调整、对数据库参数的调整及对应用服务器的参数调整，此时的性能调优需要在生产环境这个确定的环境下进行；但对正在开发中的应用来说，性能调优会更多地关注应用逻辑的实现方法、应用中涉及的算法、数据库访问层的设计等因素，此时并不要求测试环境是实际的生产环境，只要整个调优过程中具有一个可用于比较的测试基准测试环境即可。性能测试应用领域性能调优 性能调优是一种在开发和测试阶段都可能会涉及的性能测试应用领域。要注意的是，在这里讨论的性能调优并不是一种自发的无意识的行为，它本身必须遵循一定的原则和过程。可能读者已经使用一些测试的方法对应

33、用性能进行过调整，但如果不是按照以下性能调优的过程描述来进行，则不能视为真正意义上的性能调优过程，一个标准的性能调优过程的描述如下：性能测试应用领域性能调优确定基准环境、基准负载和基准性能指标 基准负载是指一种可以被用来衡量和比较性能调优测试结果的标准的应用运行环境、测试操作脚本和可被用来衡量调优效果的性能指标。请特别注意描述中的“标准的应用运行环境”，所谓的“标准”是指每次执行性能测试时的环境要严格保持一致。调整系统运行环境和实现方法，执行测试 这是性能调优过程中的核心步骤。性能调优的目的是通过调整，提高应用系统的性能表现。对于一个应用系统来说，这种调整包括硬件、系统、应用程序三方面，She

34、ll层基本不存在调优，如图5-1-1-6所示。性能测试应用领域性能调优 图 5-1-1-6性能测试应用领域性能调优 硬件环境的调整 主要是对系统运行的硬件环境进行调整，包括改变系统运行的服务器、主机设备环境（改用具有更高性能的机器，或是调整某些服务器的物理内存总量、CPU数量等）、调整网络环境（更换快速的网络设备，或是采用更高带宽的组网技术）等。系统设置的调整 主要是对系统运行的基础平台设置进行调整，例如，根据应用需要调整UNIX系统的核心参数，调整数据库的内存池大小，调整应用服务器使用的内存大小，或是采用更高版本JVM环境等。应用级别的调整 主要是对应用实现本身进行调整，包括选用新的架构、采

35、用新的数据访问方式或修改业务逻辑的实现方式等。性能测试应用领域性能调优 在实际的性能调优过程中，具体调整哪部分的内容要视具体情况而定。如果调优的对象是一个已经在实际生产环境上部署完成的系统，则调优的重点可能会放在硬件环境和系统设置上，以达到较高的投入/产出比；但对于一个正在开发中的应用，或是一个通过对硬件环境和系统设置调整仍然不能达到用户要求的已部署系统，还需要在应用级别上进行调整。 对应用系统进行调整之后，必须存在一个可用于衡量调优是否取得效果的标准。在确定基准负载、基准环境和基准性能指标之后，需要根据已经确定的这些内容执行测试，以提供对性能调优有效性评估的原始数据。 最后需要说明的是，不要

36、一次调整过多的参数或是应用实现方法，否则，很难判断具体哪个调整对系统性能产生较为有利的影响。性能测试应用领域性能调优记录测试结果，进行分析 本步骤和第（2）步构成性能调优过程中的循环，循环的出口是“达到预期的性能调优目标”。对测试结果的分析需要了解每次调整是否确实提高系统的性能。性能测试应用领域缺陷发现 缺陷发现性能测试应用领域的主要目的是通过性能测试的手段来发现系统中存在的缺陷。当然，系统在测试环境中运行良好，但在用户现场却问题不断的原因并不完全由并发或性能问题引致，但如果应用在实验室测试过程中运行良好，但在用户现场却经常出现应用挂死、多人访问时速度时快时慢、多人访问时应用崩溃的概率明显增大等问题，则很可能是由于并发时的线程锁、资源竞争或内存问题引起的。 缺陷发现性能测试应用领域一般可以作为系统测试阶段的一种补充测试手段，在测试过程中发现并发时的应用问题，或是作为在系统维护阶段的问题定位手段，对系统运行过程中已经出现的问题进行重现和定位。感谢观看