今天我们为大家介绍报告性能测试结果的更好的方法，如何能够使性能测试结果一目了然，如果你目前也在寻找报告性能测试结果的好方法，那么来看看吧：

有效的汇报测试结果是我们专业的圣杯之一。如果正确操作，它将提高项目的质量，并帮助我们关注真正的问题。但是如果做得不好，它会增加混乱并降低测试人员带来的价值。

报告功能测试的结果相对简单，因为这些测试有一个明确的通过或失败的结果。报告性能测试的结果要微妙得多。

让我们从一个定义开始:出于这篇文章的目的，我使用“性能测试”这个术语来表示执行度量的任何测试，其一系列数值范围都被认为是可接受的结果。它可以是功耗的测量，网站并行服务的用户数量，可以从硬盘读取数据的速度，等等——任何一个非功能性需求的测量。

性能测试的第一个挑战是确定什么是“通过”。这在需求定义阶段经常被忽略。我看到过很多需求被解读成这样：“从数据库提取数据时间必须少于10毫秒”，或者“处理一个视频文件的速度应该至少为每秒100帧(fps)”。这些需求是不完整的，因为它们没有包含我们想要达到的实际目标。我们只知道我们允许容忍的最坏的结果，但仍然通过产品。这儿有两个问题。

首先，让我们假设我执行一次测试，发现处理视频文件在以101帧每秒的速度完成(回想需求是“至少100帧每秒”)。看起来很好，对吗?但是这是否意味着我们已经接近边缘(也就是说，产品难以满足需求)，或者一切都是好的?假如需求定义得很好，它应该包含目标和最小值——例如，目标：120帧每秒;最低：100帧每秒。有这样的需求，101帧每秒的结果很清晰地表明了产品难以满足需求。

其次，当测试稍微失败时(例如，99帧每秒)，产品经理为了“灵活”就会面临压力，并接受产品的现状。我们多少次听到 “确实，我们都低于最小值，但是我们几乎通过了，那么我们可以判定这是好的”?假如完整的需求是可用的(目标：120帧每秒)，那么就很清楚了，结果距离目标有多远，而且产品有一个真正的问题。

为了完整起见，我将提到，非功能性需求不仅必须指定目标和最小值，而且还必须指定测试方法，因为测试方法影响测试结果。举个例子，当度量CPU使用率，取决于我们如何执行度量，结果会变化很大。我们是否测量记录的最大值?一次持续多久?我们算测量的平均值吗?一秒测量几次?我们的测试中还有其它什么并行运行在CPU上吗?

从理论上讲，报告性能测试结果根本不是一个问题。只呈现出结果并且指出通过或者失败。但是再者，我们不仅想要知道结果;我们想知道结果和目标之间的关系。编写一份不太复杂但仍能提供完整状态图的报告是一项平衡工作。

我们可以使用一个表格：

但是，因为多数产品都有很多性能需求，所以我们最终会得到一个很大的表，其中充满了数字。它将难以快速看出哪里出了问题。我们可以使用颜色来提高可读性：

但是这带来更多问题。帧处理速度和CPU使用率得到相同的颜色代码有意义吗?一个几乎失败，当另一个则在可接受范围内。那么可能是用红色来处理色框?但是那么我们会使用什么颜色表示失败呢?一个绿色的结果我们考虑要多久才能变成黄色?更不用说由于一些人有色盲而可能出现的困难。

当我的医生派我去做每年一次的血液检查时，我正在考虑这个问题。无论如何，来自实验室的结果包含了一个以这种格式显示的几十个数字的列表:

即使我不是医生，我也能马上分辨出哪些结果是好的，哪些是次要的，并且哪些是我应该与医生讨论的事。

我脑子里闪过一个念头:为什么不使用这个方法来报告性能测试呢?我拿出一些数据点，并且用幻灯片做了个实验：

请注意，我仍然使用颜色，但是坐标轴以独立于颜色的方式解释了颜色的选择，并确定了哪个高的更好，哪个低的更好。阅读器可以清楚地看到每个测量在允许范围内的位置;这些颜色主要用于在有麻烦的地方集中注意力。制作这样的报告需要一些时间，但它可以自动化。

我还没有在实际项目看见这个想法的实现——我仍然在研究这个想法——但是假如你确实使用这个想法，我将会高兴地了解到您的经验和您的组织的反应。

感谢您的阅读，以上就是达内软件测试培训为大家分享的报告性能测试结果的更好的方法，你学会了吗?更多软件测试的相关内容尽在达内软件测试培训机构官网，敬请关注!

免责声明：内容和图片源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。