为了完整起见，我将提到，非功能性需求不仅必须指定目标和小值，还必须指定测试方法，因为测试方法影响测试结果。举个例子，当度量CPU使用率，取决于我们如何执行度量，结果会变化很大。我们是否测量记录的 大值？一次持续多久？我们算测量的平均值吗？一秒测量几次？我们的测试中还有其它什么并行运行在CPU上吗？
从理论上讲，报告性能测试结果根本不是一个问题。只呈现出结果并且指出通过或者失败。我们不仅想要知道结果；我们想知道结果和目标之间的关系。编写一份不太复杂但仍能提供完整状态图的报告是一项平衡工作。
我们可以使用一个表格：
因为多数产品都有很多性能需求，我们会得到一个很大的表，其中充满了数字。它将难以快速看出哪里出了问题。我们可以使用颜色来提高可读性：
这带来更多问题。帧处理速度和CPU使用率得到相同的颜色代码有意义吗?一个几乎失败，当另一个则在可接受范围内。那么可能是用红色来处理色框？那么我们会使用什么颜色表示失败呢？一个绿色的结果我们考虑要多久才能变成黄色？更不用说由于一些人有色盲而可能出现的困难。
当我的医生派我去做每年一次的血液检查时，我正在考虑这个问题。无论如何，来自实验室的结果包含了一个以这种格式显示的几十个数字的列表:
我不是医生，我也能马上分辨出哪些结果是好的，哪些是次要的，并且哪些是我应该与医生讨论的事。
我脑子里闪过一个念头:为什么不使用这个方法来报告性能测试呢？我拿出一些数据点，并且用幻灯片做了个实验：
请注意，我仍然使用颜色，坐标轴以独立于颜色的方式解释了颜色的选择，并确定了哪个高的更好，哪个低的更好。阅读器可以清楚地看到每个测量在允许范围内的位置;这些颜色主要用于在有麻烦的地方集中注意力。制作这样的报告需要一些时间，但它可以自动化。
我还没有在实际项目看见这个想法的实现——我仍然在研究这个想法——假如你确实使用这个想法，我将会高兴地了解到您的经验和您的组织的反应。
