有效报告测试结果是我们专业的关键一环。如果做得正确，它可以提高项目的质量，并帮助我们专注于真正的问题。但如果做得不好，就会增加混乱并拉低测试人员带来的价值。
报告功能测试的结果相对简单，因为这些测试具有明确的通过或失败结果。报告性能测试的结果则要细致入微得多。
让我们从一个定义开始：为了本文的目的，我使用术语“性能测试”来表示执行测量的任何测试，其中一系列数值都被认为是可接受的结果。它可以是功耗的测量，网站并行服务的用户数量，可以从磁盘读取数据的速度等等 - 任何非功能性需求的测量。
性能测试的第一个挑战是决定什么被认为是“通过”。在需求定义阶段经常忽略这一点。我已经看到许多要求，例如“数据库中的数据提取时间应小于10ms”或“处理视频文件的速率至少应为每秒100帧 (fps)。”这些要求是不完整的，因为它们不包括我们想要达到的实际目标。我们只知道我们同意容忍并仍然认可该产品的最糟糕结果。这里有两个问题:
首先，让我们假设我进行了测试，发现视频文件处理速度为101fps（回想一下，要求是“至少100fps”）。看起来不错，对吧？但这是否意味着我们接近边缘（即产品难以满足要求），或者一切都很好？如果要求已经明确定义，它将包括目标和最低要求 - 例如，目标：120 fps；最低：100 fps。有了这样的要求，101 fps的结果清楚地表明产品几乎不符合要求。
其次，当测试失败时（例如，99 fps），产品经理面临着压力情况下“灵活”处理，按原样接受产品。我们经常听到，“事实上，我们已经低于最低限度，但我们差不多过去了，所以我们可以判断它没问题”？如果有完整的要求 (目标: 120 fps)，则很清楚结果离目标有多远，并且产品确实存在问题。
为了完整起见，我将提到，非功能性要求不仅必须指定目标和最小值，还必须指定测试方法，因为测试方法会影响结果。例如，在测量CPU利用率时, 结果将根据我们执行测量的方式而有很大差异。我们是否测量记录了最大值？多久一次？我们的平均测量值是多少？每秒测量多少次？与我们的测试并行的CPU上还运行了什么？
理论上，报告性能测试结果根本不应该是问题。只需显示结果并指明通过或失败。但同样，我们不仅想知道结果，我们还想知道结果与目标的关系。编写一份不太复杂但仍然能完整地反映现状的报告是必要的。
我们可以使用表格：
但是，由于大多数产品都有许多性能要求，我们最终会得到一个满是数字的大表。很难快速查看出出现问题的地方。我们可以使用颜色来提高可读性：
图2 表格显示测试符合要求的位置，使用黄色表示范围内，绿色表示良好
但这带来了更多的问题。帧处理速度和CPU利用率取得相同的颜色代码有意义吗？一个几乎失败了，另一个完全在可接受的范围内。所以可以用红色的彩色帧处理？那么我们会用什么颜色来表明失败？在它变成黄色之前，我们会将结果视为绿色多长时间？更不用说由于某些人有色盲而可能出现的困难。
当我的医生送我进行年度血液检查时，我正在思考这个问题，我每三年都会精心检查一次。无论如何，实验室的结果包括以这种格式显示的数十个数字列表：
图3 血液测试结果用彩色编码的滑动刻度描绘
尽管我不是医生, 但我马上就能判断出哪些结果是好的，哪些是微不足道的，哪些是我应该和医生讨论的问题。
我的脑海里出现了一个点子: 为什么不用这种方法来报告性能测试呢？我拿了几个数据点，并使用PowerPoint进行了实验:
图4 性能测试结果以相同的颜色编码滑动刻度格式显示
请注意，我仍然使用颜色，但轴解释了颜色的选择，并以独立于颜色的方式确定哪个更高更好，哪个更低。读者可以清楚地看到每个测量在允许的范围内的位置；颜色主要用于将注意力集中在有麻烦的地方。创建这样的报告需要一些时间, 但它可以自动化。
我还没有看到这个想法在一个真实的项目中实现 - 我仍在努力 - 但如果你确实使用了这个想法，我很乐意了解你的经验和你组织的反应。