摘要：
汇报功能测试结果相对简单，因为这些结果有一个清晰的通过或者失败的输出。汇报性能测试的结果更加细致入微些，而且有很多展示这些值的方法——但是迈克尔斯塔尔感到这些方法没有特别有效。他建议一种使性能测试结果一眼易读的汇报方法。
有效的汇报测试结果是我们专业的圣杯之一。如果正确操作，它能改进项目的质量并且帮助我们关注实际的事情。但是如果错误操作，它增加了误解并减少测试带来的价值。
汇报功能测试结果相对简单，因为这些测试有一个个清晰的通过或失败的输出。汇报性能测试更有细微差别。
让我们以一个定义开始：这篇文章的目的，我使用术语“性能测试”意味着任何测试会执行一个度量，它以一系列数值型的值都被考虑到可接受的结果。它可能是耗电量的测量，网站并行服务的用户数量，可以从硬盘读取的数据速度，等等。——任何一个非功能需求的测量。
第一个性能测试的挑战是决定什么被认为是“通过”。这在需求定义阶段经常地被忽略。我看到过很多需求解读成这样：“从数据库提取数据时间必须少于10毫秒”，或者“处理一个视频文件的速度必须是小于每秒100帧”。这些需求是不完整的，因为它们没有包含我们想要达到的实际目标。我们只知道我们允许忍受的而且仍然通过产品的最坏的结果。这儿有两个问题。
首先，让我们假设我执行一次测试并且发现处理视频文件在以101帧的速度完成（回想需求是“至少100帧每秒”）。看起来很好，对吗？但是它是否意味着我们接近边缘（那是产品难以满足需求）或者一切都是好的？假如需求被定义很好，它将包含目标和最小值——例如，目标：120帧每秒；最少：100帧每秒。有这样的需求，101帧每秒的结果很清晰地暗示了产品难以满足需求。
第二，当测试最低限度地失败（比如99帧每秒），产品经理会处于“灵活”且接受产品的压力中。我们有多经常听到 “事实上，我们都在最小值以下，但是我们经常通过，所以我们决定它是好的”？假如完整的需求可以被获取到（目标：120帧每秒），将会更清晰地看到结果离目标有多远，并且产品会有一个真正的发行。
为了完整性的好处，我将提起一个非功能性需求不仅需要特定目标和最小值，而且需要测试方法，因为测试方法影响测试结果。举个例子，当测量CPU使用率，取决于我们如何执行测量，结果会变化很大。我们是否测量记录的最大值？一次持续多久？我们算测量的平均值吗？一秒有多少测量值？我们的测试中还有其它什么并行运行在CPU上吗？
从理论上讲，汇报性能测试结果根本不应该是一个问题。只呈现出结果并且指出一个通过或者失败。但是再者，我们不仅想要知道结果；我们想要得到结果如何关联目标的一个概念。制作一份报告不会过度复杂，但是仍然要发送一个完整的状态图片是一个平衡的做法。
我们可以使用一个表格：
|
需求 |
目标 |
最小值 |
结果 |
|
视频处理速度（帧每秒） |
120 |
100 |
101 |
无论如何，因为多数产品有很多性能需求，我们将以一个充满数字的大表格结束。它将难以快速看出哪里是一个问题。我们可以使用颜色去提高可读性：
|
需求 |
目标 |
最小值 |
结果 |
|
帧处理速度（帧每秒） |
120 |
100 |
101 |
|
CPU占用率（%） |
7 |
10 |
8.55 |
|
性能消耗 |
1.5 |
1.9 |
1.34 |
但是这带来更多问题。它意味着帧处理速度和CPU使用率使用相同的颜色代码吗?一个几乎失败，当另一个很好地在可接受范围内。所以可能帧处理速度标成红色？但是然后我们使用什么颜色表示失败呢？而且多久我们考虑一个结果在它应该变成黄色前而为绿色呢？更不要提到会发生的困难，因为一些人有色盲。
当我的医生每三年把我的每年血液检查（我一丝不苟地做这个事）发送给我时，我正在考虑这个事情。无论如何，从实验室来的结果包括几十个数的列表显示了这个表格：
即使虽然我不是物理学家，我可以区分良好结果的合适的方法，哪个是边界，并且哪个是我应该与医生讨论的一些事。
在我的脑海里一个电灯泡继续前进：为什么不使用这个方法来报告性能测试呢？我指出一些数据点并且用幻灯片演示：
|
特性 |
分数 |
|
能量消耗 |
|
|
传输/米每秒 |
|
|
CPU占用率 |
|
|
内存使用 |
注意那些我仍然使用颜色，但是轴线解释了颜色的选择并且暗示哪里高亮会更好并且哪儿颜色上更暗会更好些——单独的方法。读者能清晰地看到在允许范围内的每个测量的位置；颜色主要服务于关注在有问题的地方。制作这样一份报告花费一些时间，但是它可以被自动化。
我还没有在实际项目看见这个想法的实现——我仍然在研究这个想法——但是假如你确实使用这个想法，我将会高兴地了解到你的经验和你的组织的反应。