执行测试

根据系统的规模、你从每种测试得到的信息的相对价值、你可用的时间多少以及组织愿意接受的风险大小，最终确定了测试计划后，你就可以进入第四步，即真正执行测试。在这一一步中，你将根据测试计划，在专为测试建立的环境中系统地执行各种测试，并且把各种衡量指标记录下来，如交易时间、响应时间、输出和反应等。所有数据都要被收集起来，在性能测试中，数据是你的朋友，你真正能得到的不过如此。保存每次发布之前的测试数据是很重要的。我们将在下一步中介绍，对比各个发布版本对于理解数据以及判断数据是在正常范围内还是说明出现了问题，至关重要。
分析数据
性能测试流程中的第五步是分析收集到的数据。进行数据分析的方法有很多，取决于分析师的专业知识、整体的期望值、可接受的风险水平以及分配的时间。也许，最简单的分析是对比即将发布的版本和过去发布的版本。例如，在过去发布的版本中，每秒可以执行50次查询，而且没有明显的性能下降，而即将发布的版本每秒却只能执行25次在询，响应时间并没有增加，这就说明可能存在问题。有趣的是下一步，即尝试找出为什么会发生这种变化。
虽然吞吐量下降或者响应时间增加显然都是应该进行进一步调在的情况，不过与之相反的情况也应该加以调在。突然急剧增加也许说明一个特定的代码路径可能已经断掉了，或者某个SQL条件失效了，不过最好是他能够注意到这些异常，并且能够提出问题。况也是需要解释的。我们希望在这些场景中，是由于工程师的确重构了代码，提高了系统的性能，柱状图或饼图中，更易于我们发现异常和差别。虽然这种方法也许有意义，也许没有，但对于判更详细的分析会绘制数据的曲线图，以便能直观地在看它们。有时，把数据绘制为曲线图、斯印将发布的版本来说，这酒常是种快捷的方法。还有各种统计学方法可用，如控制图、检验、因子分析、主效应围、方意分析和交互效应图等。进行分析的报告目的包括确定法成所观察的行为的因素是什么、待发布的版本是否与其他发布存在显著差异，以及待发布的版本能否满足服务协议水平等。
报告给工程师
性能测试流程的第六步是把结果报告给负责该次发布的软件开发团队。通常是以非正式的形式把结果报告给工程师，不过也可以在所有相关方都在场或者分成更小的团队时做这个报告。这种会议的目标是让每个提出的可能异常都得到处理，可能的情况会有如下三种。第一种情况是工程师对这种异常作出了解释。对于这种情况，工程师必须有足够的理由说明为什么测试结果与预期的不同，从而得到网站设计测试者和软件开发团队领导者的认同，可以通过这一测试，而不必采取进一步的行动。第二种情况是向工程师提出一个bug，以便他进一步调查这个问题，然后修复它，或者给出相应的解释。第三种情况是软件开发团队请求额外的测试，以便得到更多的数据，用以帮助缩小找出真正问题的范围。

相关行业资讯

相关视频推荐