分析数据

性能测试流程中的第五步是分析收集到的数据。进行数据分析的方式有许多，取决于分析师的专业知识、团体的期望值、可接受的风险水平以及分配的时间。大概，最简单的分析是对比即将发布的版本和曩昔发布的版本。例如，在曩昔发布的版本中，每秒可以实行50次查询，而且没有显明的性能降落，而即将发布的版本每秒却只能实行25次在询，自适应时间并没有增长，这就说明可能存在问题。风趣的是下一步，即尝试找出为什么会发生这种转变。
 
虽然吞吐量降落或者自适应时间增长显然都是应该进行进一步调在的情况， 不过与之相反的情况也应该加以调在。忽然急剧增长大概说明一个特定的代码路径可能已经断掉了，或者某个SQL条件失效了， 不过最好是他能够注重到这些非常，并且能够提出问题。况也是必须要诠释的。我们盼望在这些场景中，是因为工程师的确重构了代码，提升了体系的性能，柱状图或饼图中，更易于我们发现非常和差别。虽然这种方式大概故意义，大概没有，但对于判 更细致的分析会绘制数据的曲线图，以便能直观地在看它们。偶然，把数据绘制为曲线图、斯印将发布的版原本说，这酒常是种快捷的方式。还有各种统计学方式可用，如控制图、检验、因子分析、主效应围、方意分析和交互效应图等。进行分析的报告目的包括确定法成所观察的举动的因素是什么、待发布的版本是否与其他发布存在明显差异，以及待发布的版本能否知足服务协议水平等。

报告给工程师

性能测试流程的第六步是把效果报告给负责该次发布的软件开发团队。通常是以非正式的情势把效果报告给工程师，不过也可以在所有相干方都在场或者分成更小的团队时做这个报告。这种会议的目标是让每个提出的可能非常都得到处理，可能的情况会有如下三种。第一种情况是工程师对这种非常作出了诠释。对于这种情况，工程师必须有充足的理由说明为什么测试效果与预期的不同，从而得到网站设计测试者和软件开发团队向导者的认同，可以通过这一测试，而不必采取进一步的举措。第二种情况是向工程师提出一个bug，以便他进一步调查这个问题，然后修复它，或者给出相应的诠释。第三种情况是软件开发团队请求额外的测试，以便得到更多的数据，用以帮助缩小找出真正问题的范围。