如何写好性能测试结果报告？

lsekfe

前言
　　报告功能测试的结果相对简单，因为这些测试有明确的通过或失败结果。
　　报告性能测试的结果就要微妙得多，而且显示这些值的方法有很多——但是作者认为这些方法都没有特别有效。他提出了一种报告方法，使性能测试结果更易于阅读和理解。
　　有效地报告测试结果
　　有效地报告测试结果是我们职业的圣杯之一。如果做的好，它能提高项目的质量，并帮助我们专注于真正的问题；但如果做得不好，就会增加混乱，降低测试人员带来的价值。
　　报告功能测试的结果相对简单，因为这些测试有明确的通过或失败结果，报告性能测试的结果就要微妙得多。
　　让我们从一个定义开始：为了本文的目的，我使用了一个术语——性能试验，指任何执行度量的测试，其数值范围都被认为是可接受的结果。
　　它可以是电能消耗的测量、网站并行服务的用户数、从磁盘读取数据的速度等等，可以是对非功能需求的任何测量。
　　性能测试需求
　　性能测试的第一个挑战是决定什么是“通过”。在需求定义阶段，这常常被忽略。
　　我看过许多需求，比如“从数据库中提取数据的时间应该小于10毫秒”，或者“视频文件的处理速度至少应该是每秒钟100帧(Fps)”。
　　这些要求是不完整的，因为它们不包括我们想要达到的实际目标。我们批准该产品，就意味着我们同意容忍最坏的结果。这里有两个问题：
　　首先，假设我运行了一个测试，并发现视频文件处理的速度为101 fps（回想一下需求是“至少100 fps”）。看起来不错对吧？但这是否意味着我们已经接近边缘（也就是说，产品很难满足要求），还是一切都很好？
　　如果需求被很好地定义，它将同时包含目标和最小值——例如，目标：120 fps；最低目标：100 fps。有了这样的要求，101 fps的结果清楚地表明该产品很难满足要求。
　　第二，当测试轻微失败（例如99 fps）时，产品经理面临着“灵活”和接受现有产品的压力。
　　我们多久听到一次，“确实，我们在最低限度以下，但我们几乎通过，所以我们可以决定它是好的”？如果有完整的需求（目标：120 fps），那么就可以清楚地知道结果离目标有多远，并且产品有一个真正的问题。
　　性能测试报告方法
　　为了完整起见，我要提到的是，非功能需求不仅必须指定目标和最小值，还必须指定测试方法，因为测试方法会影响结果。
　　例如，在测量CPU利用率时，结果将因我们执行测量的方式而有很大差异。我们测量记录的最大值吗？间隔多久测一次？我们记录测量的平均值了吗？每秒测量多少次？在CPU上与我们的测试并行运行的还有什么？
　　性能测试报告结果
　　理论上，报告性能测试结果不应该是一个问题，只需显示结果并指出通过或失败。但是，我们不仅想知道结果，我们还想知道结果与目标之间的关系。所以编制一份不太复杂但仍能提供完整状态图的报告是一种平衡之举。
　　我们可以用一个表举例：

但是，由于大多数产品都有许多性能要求，我们最终会得到一个满是数字的大表。很难快速看出哪里有问题。我们可以用不同的背景颜色来提高可读性：

但这带来了更多的问题。帧处理速度和CPU利用率得到相同的颜色码有意义吗？其中一个几乎失败，而另一个则在可接受的范围内。那么也许是红色的彩色帧处理呢？但是，对于失败，我们会用什么颜色呢？在结果变成黄色之前，我们要考虑多长时间绿色呢？更别提有些人色盲可能造成的困难了。
　　当我的医生让我做年度血液检查时，我正在考虑上面提到的这个问题，我每三年都会仔细体检一次。而且，实验室的结果包括一个以下面这种格式显示的带几十个数字的列表：

即使我不是医生，我也能马上判断出哪些结果是好的，哪些是边际的，哪些是我应该和我的医生讨论的。
　　我突然有一个想法：为什么不用这种方法来报告性能测试呢？我选取了一些数据点，并用PowerPoint进行了试验：

请注意，我不仅使用颜色标注，还用轴线解释了颜色的代表的意义，并以独立于颜色的方式标注了哪个颜色越高越好，哪里越低越好，读者可以清楚地看到每个测量在允许的范围内的位置。
　　颜色主要用来提示比较麻烦的地方，创建这样的报告需要一些时间，但可以自动完成。
　　我还没有看到这个想法在一个真正的项目中得到实现——我还在研究这个问题，但如果你真的使用这个想法，我很乐意了解你的经验和贵组织的反馈。