性能测试报告基础

目标

• 了解创建一个良好报告的基本原则，并以此来展现你的测试数据。
• 懂得何时去平衡“技术型的测试报告”和“发给利益相关者的性能测试报告”之间的不同。
• 知道各个团队成员对本次性能测试的预期问题是什么，并且在报告中对这些问题做出解答。

 

概况

项目经理和利益相关者需要的不仅仅是从一堆测试中得到的结果——他们需要的是从那堆结果中总结出来的结论，并且能够支持这个结论的数据。技术团队也是一样，但他们需要的更多——结果分析，结果比较，以及获取测试结果的一些细节。性能测试结果需要保持一个较高的分享率，以保证团队中各种角色不同的成员能及时从中获取数据。在本章节中，通过使用和学习各种各样的测试报告，结果分享技术，以及在测试场景（scenario）中被广泛认可的技术点，你将懂得如何去满足所有成员对性能测试结果和数据的需要。
 

如何学习本章节

• 学习本章节，你将会懂得如何用一些基本原则去创建行之有效的性能测试报告，同时，文中还会介绍数据呈现的范例，以供你作为一个参考。
• “高效报告的原则”，带你了解一个牛逼报告背后的关键概念和法则。
• “使用率较高的性能测试数据类型”，带你了解一系列呈现数据的方法，以及这些方法中的哪个方法可以被最有效的应用到测试结果中。
• “报告中可以被回答的问题”，带你了解报告要怎样去设计来满足大众的口味，以及如何向恰当的读者传递恰当的信息，方便他们一眼就能看出报告中的重点。

 

高效报告的原则

• 一个良好报告的关键是以快速，简洁和直观的方式向目标读者展现感兴趣的内容。以下是一个良好报告所应有的基本原则：
• 尽早并经常的发送报告
• 视觉化的呈现报告
• 直观的呈现报告
• 报告中使用合适的统计信息
• 正确的整合报告中的数据
• 有效的总结数据
• 为特定的读者定制报告
• 用简洁的语言概述报告
• 提供测试后的数据

尽早并经常的发送报告
持续不断的为开发团队分享测试信息和测试数据是至关重要的，这甚至关系到整体性能测试项目的成功的与失败。然而，并不是所有的信息和数据的分享都应该采取正式或者半正式的报告。一个有效的途径就是每隔一两天用简明扼要的语言向利益相关者（或其他人）发送一个目前测试状态的汇总。这样，你将会收到他们的反馈以及所提及的问题， 而其中的一些反馈和问题在你下次发送正式或半正式报告的时候是可以用的着的。通过这种方法，你就可以在确定最终报告之前去衡量他们的需求。
向技术团队分享测试信息和数据应该要以一种更加直接的方式去进行。在你分析测试结果前，它可以是简单的告知技术团队我们测试结果存放的地址。然后等测试结果分析完之后，可以在报告中添加具体的连接链到我们分析时用到的各种图表。

视觉化的呈现报告
用图形化的方式展示数据对于大多数人来说是更容易去消化和理解的。这尤其体现在性能测试数据上。因为通常上性能测试数据都是非常庞大的，而且一些重要的结果都需要从一堆监测模型（如HPS）中去发现。当然我们可以通过脚本处理结果数据表，或者使用更复杂的数学方法去得到我们想要的结果。但是我们的眼睛在绝大多数的情况下是能够更快并且更精确的达到这个目的。
一旦一个监测模型或者你所关心的数据点被视觉化的呈现出来后，你很显然的想去把图中一些不需要数据点给去除掉。这些不需要的点，可以称之为“噪点”（chart noise）。噪点可以是用户的活跃度、时间片等所有的数据点，但是有时我们并不关心这些数据。通过清除一些你不需要的噪点，可以使你更加清晰的去评估和分析你的监测模型，并且使你的报告更通俗易懂。

直观的呈现报告
不管是正式还是半正式的报告，报告应该始终拥有属于自己的立场。如果一个报告将读者的问题置之度外——为什么在报告中涉及的信息是重要的，那么这个报告是失败的。虽然报告不需要对发现的问题提供有效的解决方案，但是这些问题应该能够快速并直观的在你的报告中体现出来。
一个检测你的报告是否直观的方法是：将报告中所有的标签，标识符和其他说明信息等统统去掉，然后将报告发给对测试项目不熟悉的人。如果这个能够快速并正确的从表格或者图形中指出我们要描述的问题所在，或者指明为什么我们在描述中讨论的问题是如此的重要，那么你的报告就应该很直观明了了。

报告中使用合适的统计信息
尽管我们需要了解许多统计的概念，但实际上许多软件开发人员，测试人员和经理并没有很好的统计学背景或者根本对统计不感兴趣。在这种情况下，他们很会很大程度上的曲解我们的性能测试结果。如果你不是很确定应该如何去使用统计来标注出一个特定的问题，大胆的去寻求帮助吧，孩子！

正确的整合报告中的数据
虽然并不需要严格要求你去整理报告中的数据，但是把十几个图的数据显示在一个或两个图里面，这样会更方便的去论证你模型中的结果。即便如此，在整合数据的时候你应该记住，被整合的数据应该来自于相同的测试场景。（比如在更新代码前，我们跑了10分钟的测试，用户行为是注册。在更新代码之后，如果我们需要比较更新的代码是否具有更好的性能，我们跑的新的一轮的测试应该和上一轮的测试相同：场景执行时间：10分钟，用户行为：注册）

额外需要注意的点
在整合数据前，不同测试之间的测试场景和测试环境必须是相同的才行，并且测试结果在统计学上必须等效。如果测试不是我们自己操作的，但是我们却需要从超过5个测试中找出足够相同的测试结果去整合，除了你可以问相关的测试人员，你还可以通过下面的几个规则去判断。

• 如果某轮测试结果中超过20%的数据不和其他的测试结果符合，那么就是测试环境，被测的应用或者测试本身存在问题。
• 如果一轮测试中有95%的值大于或者小于另外几轮轮测试中的最大或者最小的值，那么他们最终在结果的统计上是不会相同的。
• 如果某轮测试中的每个页面载入时间（page timer）都明显要比另外几轮测试的页面载入时间高或者低，那么这轮测试结果和其他的测试结果在统计后是不会相同的。
• 如果某轮测试中单独的一个页面载入时间都明显要比另外几轮测试的页面载入时间高或者低，但是这轮测试中的其他页面载入时间却和另外几轮测试的页面载入时间相差不大，那么这轮测试结果在统计之后是会和其他的测试结果的统计保持一致的。

有效的总结数据
经常的总结测试结果会使得我们更加容易的在其中发现有意义的地方。而确定出监测模型以及线条的趋势，得益于从不同的结果之中总结出来的图表信息。总的来说，这些图表向团队成员展示我们的测试结果，并且在报告中告知他们测试结果和预期的系统性能指标是如何进行比对的，从而使他们对项目采取一些重要的措施，比如项目系统上线，更新项目系统，或者在某些特定的情况下，彻底的去重新评估这个项目。
额外需要注意的点
当在总结归纳数据时，请注意以下的几个要点：

• 使用图表（图形和表格），以使你发现的结果更加的清晰。
• 使用文字去来补充图表所表示的关键信息。比如我现在有一个HPS的图，你可以对这个图进行一定的描述，不如说最大的HPS是多少，它的趋势是否稳定或者它的平均值是否达到了我们的预期等。
• 如果一个图表在一定程度上会使读者感到困惑，那么请不要使用它们。

为特定的读者定制报告
性能测试报告通常情况下包含三类读者：技术团队的成员，非技术团队成员以及核心团队外的利益相关者。这三类人对性能测试报告关注的侧重点都是不一样的，而且蛋疼的是，他们对报告表示方法的倾向度也不尽相同。所以，在你最终确定出最好的方法去表现你收集的数据之前，确定本次报告是要发给哪类人，以及他们对本次测试的预期是什么。

用简洁的语言概述报告
对于在报告中所列出来的一些测试结果，我们至少要用一些总结性的语言对它们进行概括，并且对于一些测试结果，最好或者用最容易的方式将他们分开。在总结中你应该包含哪些内容，这个问题完全取决于你的目标读者。一些读者想要就是一两条能够描述出图中关键点的语句。
比如：“通过观察此图，你们可以看出被测系统能够满足我们所预设的性能目标，但是当用户数上升至每小时150用户时，系统开始迅速的降到一个不可用的状态。”
另外一些读者可能需要从你呈现的图形中获取更详细的信息。
比如：“在此图中，y轴所表示的是事物每秒的平均响应时间，x轴所表示的是每轮测试中每小时的用户总数。图中的交叉点所表示的是…”

提供测试后的数据
现在大家都有一种不安的想法，就是我们不应该把性能测试（或者其他测试）后的原始数据（raw data）共享给其他人，因为他们很可能会用不合适的方法去分析这些数据。虽然这个想法是有点道理，但是我们应该更多的关心是这样一个事实：任何一个人或团队在同一个时间点提取同一组数据显然是不合理的。数据在不同的时间点对不同的人是具有不同的价值的，并且唯一的方法让团队获得大部分的数据是在特定的时间内持续不断的将这些数据提供给他们。此外，将测试后的数据提供给目标读者可以最大化的降低他们这样一个看法：性能测试结果就是测试员用一堆他们不熟悉的工具和流程堆出来的。
 

使用率较高的性能测试数据类型

以下是在性能测试报告中最常用到的测试数据类型。接下来的章节我们将向你阐述什么样的读者喜欢什么样的数据，以及报告中常见的数据类型。

• 终端用户响应时间
• 系统资源占用情况
• 体积，容量和比率
• 事物（transaction）响应时间
• 折线图趋势

终端用户响应时间
目前，在性能测试中，终端用户响应时间是最常用并且最关心的一个指标，并且在报告中也经常看到它的身影。如果你能够有效的抓住性能测试的预期指标和需求，这个指标可以帮助你去分析特定的用户对当前系统或应用的满意度。利益相关者对这个终端用户响应时间很感兴趣，因为他们可以据此去判断哪些用户对这款应用是满意的。技术团队对这个指标也是很感兴趣的，因为他们想知道站在一个用户的立场上，他们是否达到了项目的整体预期目标，如果目标木有达到，那么他们就会去寻找到底是哪里出了问题。
范例1：响应时间

范例2：响应时间分解

额外需要注意的点
尽管终端用户响应时间在报告中是最常用的，但是这里我们还是有那么几点需要澄清的。

• 在发送报告前排除异常值。你要相信，就那么仅仅一个异常值将会戏剧性的毁了你整个报告。
• 确保统计出来的数据能够将信息传达清楚。比如你要弄清楚“平均响应时间”和“90%的响应时间”的区别，技术团队可能会根据它们之间的不同采取不同的措施：要么要这个响应时间“放任自流”，要么就去修好它。
• 在报告中将用户中断操作的响应时间单独列出来。如果你正在统计用户中断操作，收集到的用户中断操作的响应时间并不能代表其他没有中断操作的响应时间。为了安全起见，建议将两者分开统计。
• 单独的汇报每个页面（web页面）或每个事物（transaction）。尽管一些页面代表着一些等价类，但是其中还是会存在你不知道的一些差异。

系统资源占用情况
相比之前的终端用户响应时间，系统资源占用在性能测试中也是不可忽略的一个重点。通常，在报告中，我们都会以口头叙事的方式讲明当前的系统占用。比如：“在测试中，应用服务器的CPU占用一直没有超过45%。而我们设定的CPU占用率是低于70%。”。一般来说当我们需要指出系统资源占用中的一个问题时，用图形去呈现是一个很不错的选择。
范例：CPU Processor Time，给利益相关者看的

范例：CPU Processor Time and Queue，给开发人员看的

额外需要注意的点
当你在汇报系统资源占用情况时，注意以下几点：

• 懂得什么时候汇报所有的数据，什么时候对相关的数据做出一个总结。通常情况下，汇报测试中一个监控资源的峰值是足够的。除非你发现一个问题，报告中你需要做的就是你使用了正确的指标证明了问题的存在。
• 将资源占用率和其他的负载和响应数据进行叠加。资源占用率与负载和响应数据叠加在同一个图中后，其强大之后就体现了出来。如果系统存在一个性能问题，这个叠加图能够快速的帮助你从一堆的指标中找出他们之间的联系。
• 如果你决定在报告中想呈现的不只是一个数据点，亲！你干脆将他们都呈现出来算了。资源占用率经常会戏剧性的从一个值变到另一个毫无预期的值。测试中，变化的每个值都是很重要的。平均值和线条趋势的改变都会使我们的分析模糊化。如果处理不当的话我们会得到不正确的假设和令人遗憾的决定。

体积，容量和比率
体积，容量和比率这些指标同样是受利益相关者的关心的，尽管这些指标让我们解释起来很具挑战性。所以说，当我们的报告中涉及到这些指标时，最好将其和特定的性能测试表准或特定性能问题联系起来。下面就是一些涉及到体积，容量和比率的常用指标：

• 带宽消耗（Bandwidth consumed）
• 吞吐量（Throughput）
• 每秒事物响应数（Transactions per second）
• 每秒服务器点击数（Hits per second）
• 可支持的最大注册用户数
• 数据库中最多允许多少条记录

范例：吞吐量

额外需要注意的点
当在报告中涉及体积，容量和比率时，注意一下几点：

• 注意上下文关联性。体积，容量和比率一般不具有独立性。
• 在测试之前，确定我们具备完整的测试条件并且相关的外部数据已经准备好了。这是一个好的测试习惯，尤其对体积，容量和比率来说 尤为重要。
• 用叙事的方式对数据进行总结。这也是一个好的测试习惯，对体积，容量和比率来说是至关重要的。

事物响应时间
尽管事物响应时间不像终端用户响应时间或系统资源占用情况那样需要汇报给利益相关者，但是他们经常被收集起来，并且把相关的数据分享给技术团队。这些响应时间可以帮助开发者，架构师和数据库管理员等去分析系统的哪个子部分或者哪个部分的响应时间
最终影响到了终端用户响应时间。
范例：Sequential Consecutive Database Updates

额外需要注意的点
当在报告响应时间的时候应该注意以下几点：

• 涉及组件响应时间的终端用户操作。因为我们不能很明显的看出终端用户操作队组件响应时间产生什么样的影响，所以最好的方法就是在报告中提及他们两者之间的关系。
• 解释哪个组件响应时间受关注的程度更深。有时我们关注的是一个组件可能会成为瓶颈，因为它在测试的过程中反应相当的慢；有时，我们关注的是某个组件很大程度上影响了终端用户响应时间。合理的运用刚才所说的会使我们在项目测试时做出一个积极有效的决定。

折线图趋势
折线图的趋势是一个很强的性能测试指标，但是在基于数据的性能测试报告中却很少用到。当项目从一个版本升级到另一个版本时，趋势能够很好的向我们展示项目的性能是在增长还是在下降。趋势还能帮助技术团队的成员很快的知道最近他们对项目中某个部分的改变是否达到了预期的性能目标。
范例：Response Time Trends For Key Pages

额外需要注意点
当你在写报告的时候，需要注意到的有以下几点：

• 至少要有3个以上的点指标趋势才能显现出来。在写正式报告的时候，如果需要谈到指标的趋势，这个指标一定要有足够多的数据才行。
• 在发正式报告之前，将指标的趋势情况分享给技术团队。这又是另外一条很好的建议。因为开发者，架构师，管理员和数据库分析师等很有可能在我们进行测试之前就对项目做了些许改动，而且没有来得及告知我们，他们的这些改动可能会造成一个不合理的指标趋势走向。所以 为了保证起见，你可以在报告中不谈论趋势这个问题，或者直接向开发人员询问这个问题是什么原因造成的，然后在报告中简单的描述这个问题和解决情况等。

 

在报告中可以被回答的问题

当团队成员从性能测试报告中获得数据和结果时，几乎他们每一个人都有着自己特定的需求和期望。尽管这会造成我们在性能测试报告中分享信息变得很具挑战性，但是当你知道不同的团队成员期待的是什么，以及提前准备为合适的人，在正确的时间提有价值的信息，我相信你在写报告的时候也会变得得心应手了。

他们的共同问题
几乎收到性能测试的每个团队成员都有如下相同的问题：

• 项目的性能是变好了，还是变差了？
• 这次性能测试是否达到了我们的预期要求或者服务品质保障协议（SLA）？
• 本次测试报告能够提供什么内容？
• 我每隔多就能够收到报告？
• 我能够得到更详细/更简洁明了的报告吗？

利益相关者的问题
利益相关者对性能测试报告通常有着非常独特的需求和期望，以至于和其他团队成员的需求和期望是截然不同的。他们倾向于性能测试报告能够言简意赅，方便他们能够快速的从报告中找出重点。除此之外，视觉化的呈现指标更受利益相关者的喜欢，因为他们撇一眼指标图形就能看出个大概，同时对这些视觉化呈现的数据配以简要的解释也是很好的。最终，他们间歇的会对这些信息进行整合和总结。以下的就是利益相关者期待性能测试报告中能够回答的问题：

• 这个项目可以上线了吗？
• 这些测试结果和被测项目有着怎样的联系？
• 我对这个测试结果应该有多少信心？
• 为了项目能够正式的上线，我们还需要准备些什么？
• 该性能测试达到了我们的预期期望吗？
• 性能测试能否对该项目有着价值的提升？

项目级的管理人员
项目级的管理人员包括项目经理，开发部门的Lead或经理和测试Lead或经理。他们除了和利益相关者有同样的问题之外，这些人还希望我们能够经常并且能够更详细的去分析性能测试报告中涉及的点。总之，他们一般还期待下面几个问题能够被回答：

• 性能测试能否有效的发现项目中存在的性能问题？
• 被发现的性能问题是不是能够很好的被我们解决？
• 我们还需要为性能测试做些什么？
• 我们目前做的哪些是对性能测试没有什么实际意义的？
• 有一些困难阻碍着性能测试的进行吗？如果有，他们是什么？

技术团队的成员
尽管技术团队的成员对利益相关者和项目级管理人员的问题有着一定程度的兴趣，但是他们更在意的是从测试结果，监测数据和观测数据的有关信息中去分析和提升他们的代码。技术团队的成员倾向于要知道以下几点问题：

• 这些结果对我所负责项目的那一块有着什么意义？
• 我能够去哪里看到最近的测试结果？
• 我在哪里能够得到测试结果的原始数据？
• 当在测试正在进行的时候，我能够去实时的去观察某个值的变动吗？

 

性能测试报告的类型

在最基本的意义上来说，性能测试报告有着3中截然不同的类型：原始数据展示，技术报告和针对利益相关者的报告。尽管所有的性能测试报告都是基于对测试结果，观测数据，测试侧重点和测试建议等最及时，准确以及沟通的结果，但是每个不同类型报告的目标读者是不同的，并且我们测试员和他们之间最有效的去沟通报告中相关数据的方法也是有着很大的不同的。
原始数据型的测试报告
尽管原始数据型的测试报告并不是一个很标准的报告类型，但是把测试所得的原始数据分享出来是去更好更有效提升合作为目的的。这种报告也包含着性能测试报告中一些数据呈现的基本原则。
通常来说，大多数人宁愿去看图形化的原始数据和统计，而不是去看不是很直观的表格。然而，在大多数情况下，表格却是一种最有效的方式去展现你对数据计算的结果。表格化的原始数据可以被用来创建图形化的结果，然后将他们作为附件放在报告的邮件中，这样的话你就可以在报告中少用些表格啦，感兴趣的利益相关者自然会去附件中查看更多信息的。
以下类型的测试结果可以被很好的以表格的形式展现出来：

• 基线测试（Baseline）
• 基准测试（Benchmark）
• 可伸缩性测试（Scalability）
• 其他基于用户体验的测试

表格能够以整洁有序的方式去完美的呈现数据，并且可以用来支持测试员最终发现的结果。然后，请注意不要在报告中过多的使用表格。因为大多数人在阅读的时候是非常快速的跳过表格的内容，只是阅读表格附近的文字或者图形。当你在报告中用表格去阐述一个问题的时候，需要确保的一点就是，这些表格能够突出信息的重点。数据量非常大的表包含的的数据可能会吸引一些感兴趣的读者，但是大多数读者却不以为然。所以建议将这中表格放在报告的附录里是最佳的选择。原始数据最常见的呈现方式有以下几种：

• 电子表格（Spreadsheets）
• 文本文件（或正则表达式的搜索结果）
• 数据搜集工具所形成的数据

技术型的测试报告
技术型的测试报告要比单纯的原始数据型的测试报告显得更加的正式，但这并不说这种报告写起来就很蛋疼。技术型的测试报告应该坚持站在自己的立场上，但是因为这种报告主要是给负责该测试项目的技术团队成员阅读，所以他们并不需要像发给利益相关者的报告（下面会介绍）那样在报告中体现所有的测试细节。简而言之，技术型的测试报告由以下内容组成：

• 测试描述，包括测试模型和测试环境简洁易消化，并且预处理较小的数据
• 能让读者获取完整的数据集和测试条件
• 对观察点，关注点，问题和合作要求等进行简短的描述

技术型的测试报告包含的数据通常有以下几种格式：

• 散点图（Scatter plots）
• 柏拉图（Pareto charts）
• 趋势图（Trend charts）
• 数据摘要表（Summary spreadsheets）

发给利益相关者的测试报告
发给利益相关者的测试报告是所有测试报告中最正式的。这种报告必须使那些不是在技术岗位上工作的人能够一眼就能够看出个大概。也就是说，这些报告关系着项目验收标准和验收风险。为了使报告能够更加有效，这类的测试报告应该包含以下内容：

• 测试结果和验收标准之间的关联
• 直观并视觉化的呈现数据
• 对图或表进行简明扼要的描述
• 直观并视觉化的呈现测试模型和测试环境
• 能让读者获取技术型的测试报告，完整的数据集和测试条件
• 总结测试中涉及到的观察点，关注点和建议点

当你在准备这类测试报告时，应该想到绝大数的利益相关者看完你的报告之后会做出以下三个反应。对于他们来说，这些反应时积极的正常的，但是对我们测试人员来说就不那么见得了。

• “恩，这个测试很不错，但是我要从哪获得你们的数据？”这个是利益相关者们最常见的反应。很多读者和机构相关获取所有测试相关的数据，以便他们能够对这些数据进行分析，得出自己的测试结果。幸运的是，这个简单的问题很好解决：把这些数据以电子表格的形式作为一个附件添加到报告中。
• “不错，但是这轮测试结果到底意味着什么？”这里就需要我们为他们去解释了。不熟悉性能测试或者不知道怎样去阅读性能测试结果的读者通常需要性能测试员为他们描述出有意义的结果。请记住，超过90%的几率，性能测试员都要承受一些利益相关者不愿看到的性能测试结果。测试员应当有责任让利益相关者对我们的发现有信心，并且用一种建设性的方式去呈现我们发现的问题。
• “太棒了！这正是我想要的！不要担心最终的测试报告，这些已经做得很棒了。”这个让我们测试员赶脚超酷，但是不要高兴的太早。迟早，会有一些人去分析报告中的图和表，并且会问你上面提到的两个或者一些更蛋疼的问题，比如这些数据时怎样获取的。如果至少没有一个最终报告，告诉读者在哪里找到其余的数据，他们就会质疑测试结果，因为你目前并没有来得及去回答他们所关心的问题。

 

创建一个技术型的测试报告

尽管我们在下面列出了一个技术型测试报告应当包含的6个关键点，但是这些关键点并不是适应每个技术型的测试报告。同样的，根据你在报告中想覆盖的测试内容，也会有一些额外的信息点会被加进报告中。尽管这6点内容在大多数的情况下可以帮你完成一个成功的技术型的测试报告，但是请记住有些时候我们需要的是一点点小小的创新，以便使报告中的内容更清楚和直观。
以下就是刚才谈到的6个关键点：

• 某些指标的测试结果图
• 单一指标的测试结果表格（列如：测试中达到最大的吞吐量）
• 测试场景模型（以图形的方式呈现）
• 对观察点，关注点，问题点和合作要求等进行简明扼要的概述
• 参考内容

例子：某些指标的测试结果图（服务器CPU使用状态和页面响应时间的合并图）

例子：单一指标的测试结果表格（列如：达到最大的吞吐量）

例子：用户模型

例子：测试环境

例子：测试总结
从第一幅测试结果图中可以看出，其由服务器CPU使用状态和页面响应时间组成。仔细检查，我们会发现应用服务器的CPU占用率和队列和响应时间的急剧降低同时发生。这表明应用服务器的CPU占用影响着响应时间的降低，但我们还需时间确认这个问题。为了方便参考，剩下的图形和表格作为补充信息列了出来。

例子：参考内容
测试的原始数据和额外的支持信息已经被收录到版本控制系统中，您可以通过以下格式进行查找：PerfTest-{date}-{issue number}。
 

创建一个发给利益相关者的测试报告

同样的，尽管下面列出了此类测试报告应具备的8个关键点，但是并不是所有的点都符合利益相关者的测试报告。同时，你可以根据自己的需要，在报告中添加一些额外的信息和创意点，使报告更加的清晰和易于理解。
以下就是上面说的8点内容：

• 测试结果和验收标准之间的关联
• 某些指标的测试结果图
• 单一指标的测试结果表格（列如：测试中达到最大的吞吐量）
• 对图或表进行简明扼要的描述
• 测试场景模型（以图形的方式呈现）
• 总结测试中涉及到的观察点，关注点和建议点
• 参考内容

例子：验收标准声明
这个报告涉及到终端用户响应时间的遵从性。为了验证这个遵从性，我们根据需求管理系统中的Perf### through Perf???谈到的那样：在预期负载峰值的一半的情形下，测试场景使用的是最常见的预期场景。

例子：测试结果图

例子：单一指标的测试结果表格

例子：建立在验收标准之上的测试总结
除了Page8和Page10的响应时间外，其他所有的监测指标都达到了预期的要求。

• Page10的响应时间没有达到预期值的2%
• Page8的响应时间没有达到预期值的38%

例子：用户户模型

例子：测试环境

例子：观察点和建议点的概括
基于我们的测试条件和测试结果，我们对接下的性能测试和性能调优有如下的建议：

• 在更复杂的测试场景下执行负载更高的性能测试。
• 找出影响Page10和Page8响应时间的根本原因，并提升这个问题的优先级，接着对他们进行必要的调优。
• 如果在接下来的时间，其他一些页面的响应时间没有达到预期的值，造成这些问题的根本原因的查找和接下来的调优工作应该需要着手进行展开。

例子：参考内容
创建此报告的所有数据和执行测试所产生的数据都被作为只读文件收录到版本控制系统中，
您可以通过以下格式进行查找：PerfTest-{date}-{issue number}。
如果您没有权限登录版本控制系统，您可以访问\\shared-resource\location来获取这些数据的一个副本。
 

总结

性能测试报告在呈现测试结果的过程中可以对关键的技术和商业决定进行必要的支持。在决定如何最好的去展现测试结果之前，应当考虑到读者究竟想要的是哪些数据，这就是创建一个行之有效的性能测试报告的关键点所在。最高效的性能测试结果包含着对数据的分析，比较，以及数据的来源信息，并能影响关键业务的决策。