6， Tie up loose ends：完成收尾工作。
重复前五个步骤直到达到目标。
但当我们完成目标后，依然要注意以下的问题：
·解决的方式是否有边际效应，造成其他的问题 例如：为了某类的查询工作建立了大量的索引，事后原本正常的新建、修改、删除都出现了性能问题。
·是否真正根除了问题，还是仅表象地头痛医头，脚痛医脚建立问题的假设时，很容易将问题特殊化，仅局部地解决该现象。例如：加了某个索引或稍稍改变查询语法，舒缓了当前的瓶颈，但当用户稍微增加，或是采用了不同的查询方式，就老问题复发。
·是否要建立持续跟踪的计划
当你无法确定已经根除问题，那可能就要拟定持续跟踪的计划。决定是否要持续观查某些计数器，跟踪某些现象是否还会发生，若发生了要如何解决等等。如此不但可以让用户安心，更可以让你知道之前的行为到底有多少效益，下次的性能测试才有更完整的解决方式。
性能测试及调校需要有耐心和毅力，能够与用户充分地沟通与协调，每一个步骤都小心翼翼，尽量扩充团队的知识广度与深度。这需要日常培养，并非一触可及。
在进行性能测试和调校的过程中要有步骤，确定每一次的动作都让你更接近目标，妥善搜集各种信息，每一个测试动作都会影响系统本身，导致看到的现象都是系统与你互动的结果，小心不要被自己的盲动所误导。
另：
定义瓶颈
所谓瓶颈，就是整个系统原本可以流畅地执行，但系统中若有一个点无法处理该需求量，导致整个系统执行效率被卡住，该点就是瓶颈。所以定义瓶颈的定义如下：
瓶颈 = 需求到达的处理量 > 实际处理量(Throughput)
以我们现今分布式运算的系统而言，要找出整体流程卡在哪一点上，是蛮复杂的，因为系统的瓶颈点可能相当多，所以我们要重点研究是卡在整体系统处理流程的哪一点上，比如web服务，其中的组成部分包括SQL Server/COM+/IIS/IE,在整体的响应时间中，如果IE花2秒钟(因为PC老旧，而执行动作很复杂)，ASP处理时间0.5秒，COM+4秒钟，SQL Server0.5秒钟，我们可以说这些点各有瓶颈,只是解决的成本效益各有不同。
整体的性能瓶颈寻找与解决流程：先找出系统拥有哪些瓶颈点，再拟定计划，逐项克服。方法：重复寻找不同的瓶颈，先处理执行成本较低但性能影响较大的部分。
文章来源于领测软件测试网 https://www.ltesting.net/
