Analysis提供的是整个测试过程中获得的数据的集合，通过这些指标的定义只能找出问题的可能原因和可能的瓶颈的方向，具体的原因取决于测试方法的调整、与开发的沟通和配合和其它相关知识的有机结合。
原则1：把事实与推测分开，要用实际的数据来证明你的推测。
原则2：在没有足够证据之前，先不要说需要对程序进行优化。
原则3：优先验证简单的假设。
原则4：日志中没有错误，不代表真没有错误（严格判断请求事务）。
原则5：先缩小范围，分割成各个小单元，对各个小单元进行测试，确定是由那个单元引起的。
问题的分析与处理思路可按上图的流程进行，只有不断的提出问题、解释现象，并论证现象，调整相关的测试方法才有可能确定问题以及问题产生的可能原因。当然受经验和能力的限制，并不是所有问题的原因都能够靠自己找到，这时就得靠团队的力量了。
缺陷：Summary Report---Transaction Summary中的数据显示与Average Transaction Response Time中显示的不一致！
规避方法：删除Average Transaction Response Time等默认加载的节点信息，然后再添加这些节点的信息，即可使其保持一致。
如下面截图，未规避前Transaction Summary中的平均响应时间为：0.155s，标准差为0.206。
未规避前Average Transaction Response Time中的平均响应时间为：0.152s，标准差为0.08。
规避后Average Transaction Response Time中的平均响应时间为：0.155s，标准差为0.206。
