摘要：报告功能测试的结果相对简单，因为这些测试有一个明确的通过或失败的结果。报告性能测试的结果要更加微妙得多，而且显示这些价值的方法有很多，但是迈克尔斯塔尔认为这些方法都不是特别有效。他提出了一种使性能测试结果一目了然的报告方法。
图片
有效的汇报测试结果是我们专业的圣杯之一。如果正确操作，它将提高项目的质量，并帮助我们关注真正的问题。但是如果做得不好，它会增加混乱并降低测试人员带来的价值。
报告功能测试的结果相对简单，因为这些测试有一个明确的通过或失败的结果。报告性能测试的结果要微妙得多。
让我们从一个定义开始:出于这篇文章的目的，我使用“性能测试”这个术语来表示执行度量的任何测试，其一系列数值范围都被认为是可接受的结果。它可以是功耗的测量，网站并行服务的用户数量，可以从硬盘读取数据的速度，等等——任何一个非功能性需求的测量。
性能测试的第一个挑战是确定什么是“通过”。这在需求定义阶段经常被忽略。我看到过很多需求被解读成这样：“从数据库提取数据时间必须少于10毫秒”，或者“处理一个视频文件的速度应该至少为每秒100帧（fps）”。这些需求是不完整的，因为它们没有包含我们想要达到的实际目标。我们只知道我们允许容忍的结果，但仍然通过产品。这儿有两个问题。
首先，让我们假设我执行一次测试，发现处理视频文件在以101帧每秒的速度完成（回想需求是“至少100帧每秒”）。看起来很好，对吗？但是这是否意味着我们已经接近边缘（也就是说，产品难以满足需求），或者一切都是好的？假如需求定义得很好，它应该包含目标和小值——例如，目标：120帧每秒； 低：100帧每秒。有这样的需求，101帧每秒的结果很清晰地表明了产品难以满足需求。
其次，当测试稍微失败时(例如，99帧每秒)，产品经理为了“灵活”就会面临压力，并接受产品的现状。我们多少次听到 “确实，我们都低于小值，但是我们几乎通过了，那么我们可以判定这是好的”？假如完整的需求是可用的（目标：120帧每秒），那么就很清楚了，结果距离目标有多远，而且产品有一个真正的问题。
