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 success(如果需要的话，重复之前的步骤)：确认解决方案成功与否。
这一步骤主要任务是：重新收集数据，以验证该计划的成功与否。如果证实假设是对的，则继续搜集相关数据，以确立接下来的步骤；如果到这一步发现执行的结果不如预期，证明我们的假设错误。这会非常让人气tuo,进而放弃这个性能测试的方法，因为无法忍受整个时间的流失。其实，定错性能的目标是常有的事，这个方法论就是要你在错误的当前，停下来好好思考，重新理出头绪，最重要的是要清楚知道这一回是错在哪，如此新的步骤就能更逼近目标。有系统的犯错，是整个计划的一部分，踩着错误走向成功是性能测试的常态。
6， Tie up loose ends：完成收尾工作。
重复前五个步骤直到达到目标。
但当我们完成目标后，依然要注意以下的问题： ·解决的方式是否有边际效应，造成其他的问题 例如：为了某类的查询工作建立了大量的索引，事后原本正常的新建、修改、删除都出现了性能问题。 ·是否真正根除了问题，还是仅表象地头痛医头，脚痛医脚建立问题的假设时，很容易将问题特殊化，仅局部地解决该现象。例如：加了某个索引或稍稍改变查询语法，舒缓了当前的瓶颈，但当用户稍微增加，或是采用了不同的查询方式，就老问题复发。 ·是否要建立持续跟踪的计划
当你无法确定已经根除问题，那可能就要拟定持续跟踪的计划。决定是否要持续观查某些计数器，跟踪某些现象是否还会发生，若发生了要如何解决等等。如此不但可以让用户安心，更可以让你知道之前的行为到底有多少效益，下次的性能测试才有更完整的解决方式。
