性能测试过程的六个阶段

性能测试过程的六个阶段

作者: 未知

　　性能测试的工作千头万绪，最怕的就是像无头苍蝇般盲目地测试，不但旷日费时，还累积不到经验，团队与个人都难以成长，（下次再

进行性能测试时，还是乱测一通）。

　　我们需要拟定步骤分阶段执行，如此才能循序渐进，一步步向目标前进。根据微软公司的研究显示，性能测试的过程应该为六个阶段，

分别是发现、探究、提案、执行、复查、收尾。原文如下：

　　1， Discover the problem： 发现问题。

　　这个步骤最重要的就是发现(Discover)问题，详述(Discribe)问题,并且正确而详细地记录(Document)下来。在进入下一步骤前，我们测

试人员应该问问自已以下这些问题：

　　对于问题是否已经有简明的描述
　　用户的基线与期待在哪

　　2， Explore the conditions： 探究原因，为问题提供明确的定义与定位。

　　这个步骤的主要任务：是广泛搜集相关数据，尽量了解系统的每一个方面，避免深入分析时，漏了某个关键的现象而误入歧途； 重点：

是探索(Explore)，寻找证据(Evidence),建立(Establish)整个问题的来龙去脉的假设。

　　有的时候在这个阶段就可以发现重大问题，一眼就看出关键点，例如硬件毁损，某个硬盘区块或内存块不稳，或某个其他程序吃掉所有

的内存，让SQL Server无内存可用，或是该程序常常死当，拖垮CPU等等。

　　3， Track down possible approaches：提供可能的解决方案。

　　这个步骤的主要任务：深入分析数据间的关联性，并对整个问题的前因后果提出假设，最后拟定出相应的策略(计划)。如果前一个步骤

做得不够详实，在这个步骤我们可能就会误判，导致努力了半天，但就是找不到瓶颈点。

　　这个步骤最重要的动作是：拟定计划。一个好的计划，你才能知道方向与步骤。

　　4， Execute the most likely approach：执行最有可能的解决方案。

　　这是DETECT方法中最简单的一步，因为只要执行上一步中所拟定的计划就行了。但是在执行计划时，仍然要注意系统的反应（随时都可

能会要放弃当前的计划，因为新的证据可能证明你先前的判断错误，因而要修正计划，甚至是退回到上一步以重新拟定计划。这时切勿躁，

因为整个性能测试的过程就是在考验团队的细心与耐力、知识的广度与深度！），同时还要小心观察会不会有新的问题出现并严重影响当前

系统的执行，不要原来系统迟缓，而你的测试却成为压垮骆驼的最后一根稻草。

　　5， Check for suclearcase/" target="_blank" >ccess(如果需要的话，重复之前的步骤)：确认解决方案成功与否。

　　这一步骤主要任务是：重新收集数据，以验证该计划的成功与否。如果证实假设是对的，则继续搜集相关数据，以确立接下来的步骤；

如果到这一步发现执行的结果不如预期，证明我们的假设错误。这会非常让人气馁,进而放弃这个性能测试的方法，因为无法忍受整个时间的

流失。其实，定错性能的目标是常有的事，这个方法论就是要你在错误的当前，停下来好好思考，重新理出头绪，最重要的是要清楚知道这

一回是错在哪，如此新的步骤就能更逼近目标。有系统的犯错，是整个计划的一部分，踩着错误走向成功是性能测试的常态。

　　6， Tie up loose ends：完成收尾工作。

　　重复前五个步骤直到达到目标。

　　但当我们完成目标后，依然要注意以下的问题：

　　解决的方式是否有边际效应，造成其他的问题 例如：为了某类的查询工作建立了大量的索引，事后原本正常的新建、修改、删除都出现

了性能问题。
　　是否真正根除了问题，还是仅表象地头痛医头，脚痛医脚建立问题的假设时，很容易将问题特殊化，仅局部地解决该现象。例如：加了

某个索引或稍稍改变查询语法，舒缓了当前的瓶颈，但当用户稍微增加，或是采用了不同的查询方式，就老问题复发。
　　是否要建立持续跟踪的计划
　　当你无法确定已经根除问题，那可能就要拟定持续跟踪的计划。决定是否要持续观查某些计数器，跟踪某些现象是否还会发生，若发生

了要如何解决等等。如此不但可以让用户安心，更可以让你知道之前的行为到底有多少效益，下次的性能测试才有更完整的解决方式。

　　性能测试及调校需要有耐心和毅力，能够与用户充分地沟通与协调，每一个步骤都小心翼翼，尽量扩充团队的知识广度与深度。这需要

日常培养，并非一触可及。

　　在进行性能测试和调校的过程中要有步骤，确定每一次的动作都让你更接近目标，妥善搜集各种信息，每一个测试动作都会影响系统本

身，导致看到的现象都是系统与你互动的结果，小心不要被自己的盲动所误导。

　　另外：

　　定义瓶颈，所谓瓶颈：就是整个系统原本可以流畅地执行，但系统中若有一个点无法处理该需求量，导致整个系统执行效率被卡住，该

点就是瓶颈。所以定义瓶颈的定义如下：

　　瓶颈 = 需求到达的处理量 > 实际处理量(Throughput) 

　　以我们现今分布式运算的系统而言，要找出整体流程卡在哪一点上，是蛮复杂的，因为系统的瓶颈点可能相当多，所以我们要重点研究

是卡在整体系统处理流程的哪一点上，比如web服务，其中的组成部分包括SQL Server/COM+/IIS/IE,在整体的响应时间中，如果IE花2秒钟(

因为PC老旧，而执行动作很复杂)，ASP处理时间0.5秒，COM+4秒钟，SQL Server0.5秒钟，我们可以说这些点各有瓶颈,只是解决的成本效益

各有不同。

　　整体的性能瓶颈寻找与解决流程：先找出系统拥有哪些瓶颈点，再拟定计划，逐项克服。方法：重复寻找不同的瓶颈，先处理执行成本

较低但性能影响较大的部分。

原文转自：http://www.ltesting.net