软件性能测试的规范化

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

　　我们需要拟定步骤分阶段执行，如此才能循序渐进，一步步向目标前进。根据微软公司的研究显示，性能测试的过程应该为六个阶段，分别是发现、探究、提案、执行、复查、收尾。原文如下：

　　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