摘要：
报告功能测试的结果相对简单，因为这些测试有一个明确的通过或失败的结果。报告性能测试的结果要更加微妙得多，而且显示这些价值的方法有很多，但是迈克尔斯塔尔认为这些方法都不是特别有效。他提出了一种使性能测试结果一目了然的报告方法。
有效的汇报测试结果是我们专业的圣杯之一。如果正确操作，它将提高项目的质量，并帮助我们关注真正的问题。但是如果做得不好，它会增加混乱并降低测试人员带来的价值。
报告功能测试的结果相对简单，因为这些测试有一个明确的通过或失败的结果。报告性能测试的结果要微妙得多。
让我们从一个定义开始:出于这篇文章的目的，我使用“性能测试”这个术语来表示执行度量的任何测试，其一系列数值范围都被认为是可接受的结果。它可以是功耗的测量，网站并行服务的用户数量，可以从硬盘读取数据的速度，等等——任何一个非功能性需求的测量。
性能测试的第一个挑战是确定什么是“通过”。这在需求定义阶段经常被忽略。我看到过很多需求被解读成这样：“从数据库提取数据时间必须少于10毫秒”，或者“处理一个视频文件的速度应该至少为每秒100帧（fps）”。这些需求是不完整的，因为它们没有包含我们想要达到的实际目标。我们只知道我们允许容忍的最坏的结果，但仍然通过产品。这儿有两个问题。
首先，让我们假设我执行一次测试，发现处理视频文件在以101帧每秒的速度完成（回想需求是“至少100帧每秒”）。看起来很好，对吗？但是这是否意味着我们已经接近边缘（也就是说，产品难以满足需求），或者一切都是好的？假如需求定义得很好，它应该包含目标和最小值——例如，目标：120帧每秒；最低：100帧每秒。有这样的需求，101帧每秒的结果很清晰地表明了产品难以满足需求。
其次，当测试稍微失败时(例如，99帧每秒)，产品经理为了“灵活”就会面临压力，并接受产品的现状。我们多少次听到 “确实，我们都低于最小值，但是我们几乎通过了，那么我们可以判定这是好的”？假如完整的需求是可用的（目标：120帧每秒），那么就很清楚了，结果距离目标有多远，而且产品有一个真正的问题。
为了完整起见，我将提到，非功能性需求不仅必须指定目标和最小值，而且还必须指定测试方法，因为测试方法影响测试结果。举个例子，当度量CPU使用率，取决于我们如何执行度量，结果会变化很大。我们是否测量记录的最大值？一次持续多久？我们算测量的平均值吗？一秒测量几次？我们的测试中还有其它什么并行运行在CPU上吗？
从理论上讲，报告性能测试结果根本不是一个问题。只呈现出结果并且指出通过或者失败。但是再者，我们不仅想要知道结果；我们想知道结果和目标之间的关系。编写一份不太复杂但仍能提供完整状态图的报告是一项平衡工作。
我们可以使用一个表格：
但是，因为多数产品都有很多性能需求，所以我们最终会得到一个很大的表，其中充满了数字。它将难以快速看出哪里出了问题。我们可以使用颜色来提高可读性：
但是这带来更多问题。帧处理速度和CPU使用率得到相同的颜色代码有意义吗?一个几乎失败，当另一个则在可接受范围内。那么可能是用红色来处理色框？但是那么我们会使用什么颜色表示失败呢？一个绿色的结果我们考虑要多久才能变成黄色？更不用说由于一些人有色盲而可能出现的困难。
当我的医生派我去做每年一次的血液检查时，我正在考虑这个问题。无论如何，来自实验室的结果包含了一个以这种格式显示的几十个数字的列表:
即使我不是医生，我也能马上分辨出哪些结果是好的，哪些是次要的，并且哪些是我应该与医生讨论的事。
我脑子里闪过一个念头:为什么不使用这个方法来报告性能测试呢？我拿出一些数据点，并且用幻灯片做了个实验：
请注意，我仍然使用颜色，但是坐标轴以独立于颜色的方式解释了颜色的选择，并确定了哪个高的更好，哪个低的更好。阅读器可以清楚地看到每个测量在允许范围内的位置;这些颜色主要用于在有麻烦的地方集中注意力。制作这样的报告需要一些时间，但它可以自动化。
我还没有在实际项目看见这个想法的实现——我仍然在研究这个想法——但是假如你确实使用这个想法，我将会高兴地了解到您的经验和您的组织的反应。
......
查看更多精彩内容，请点击下载：
版权声明：本文出自《51测试天地》第五十二期。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
