前言
春节前在北京出差，和同事聊到了一个关于流量网关如何进行性能验证的需求，当时写了一篇文章《聊了简单的话题：如何分析性能需求》。
结果节后上班同事找到我，希望我帮他们写一份给到业务团队的性能测试报告，原因是业务觉得他们之前提供的报告不够充分。
这篇文章，来聊聊我对这个需求的分析和理解，以及如写出让业务满意的性能测试报告。
需求背景
需求背景实际上在前面的文章《聊了简单的话题：如何分析性能需求》中已经提到了，写性能测试报告的初衷，是目前的组织架构和业务形态决定的。
我目前在Application Infrastructure团队，负责测试开发和性能及稳定性相关工作，由于公司是纵向的独立BU式的组织架构，基础架构团队更多的是作为一个乙方的角色，
为各个事业部提供底层的通用技术组件和解决方案。这就是为什么这篇文章标题会题为‘让业务满意’的寓意了。
大多数独立BU式架构的企业，业务方往往都处在一个很强势的角色，而做底层基础建设的团队，本身的绩效和评价往往来自于业务团队影响因素较多。
聊完背景，接下来聊聊本文的重点——性能测试报告。我会尝试从报告的作用、业务团队关注的点以及报告背后的思考逻辑来阐述我的一些观点和想法。
测试报告的作用是什么？
聊到报告的作用，可以尝试从以下几个方面来理解它的作用：
流程闭环
现在企业大都讲究流程，我在前面的文章《测试工程师的职场发展二三谈》里面也谈到了流程的重要性。
在技术领域，报告一般都意味着阶段性的结束总结，如果是偏数据计算或调研方面，报告更是很好的素材和样本。
因此测试报告的作用，在流程管理方面，是很重要的一个环节和必不可少的产出。
结果量化
上面聊了流程，这里聊结果。互联网领域有个黑话叫做拿结果，结果是什么？
结果不是你写了多少代码提了多少bug，而是你在某个阶段做某件事的可量化的产出物。
报告是对这个阶段的高度总结，是对目标和结果的拉齐，更是向上向下的一个交代！
原谅我用了一些互联网黑话，因为这些黑话属于一说就透大家都懂的意思。总结一下，报告的作用如下：
保证流程的完整性；
工作的阶段性总结；
可量化的产出结果；
对业务合作方的交代；
达成OKR的重要手段；
老板向上向下管理的抓手；
个人绩效和年终的影响因素；
业务团队更关注哪些内容？
聊到这里，就要提到需求最核心的部分：流量网关。
一般来说，流量网关是大部分业务流量的入口，它的特点在于一方面需要承载比较高的访问流量；
另一方面要起到入口的一些特性作用，比如：限流/鉴权/防爬等。考虑到容灾可可用性等指标，一般在服务部署的时候，还需要跨可用区甚至跨机房。
因为基础架构团队负责流量网关等基础组件的研发，需要推动在不同的业务团队协助他们接入服务。
业务团队对服务的时延比较敏感，且之前部分团队已经有了类似的技术组件，这个背景下要说服业务团队接入，阻力还是不小的。
所以就有了文章开头所提到的事情。那么，类似流量网关这种基础的技术组件，业务团队会比较关注哪些内容呢？
低时延；
可用性；
接入成本；
流控和鉴权；
精准的可量化指标；
明确便捷的接入方案；
丰富的使用培训和答疑服务；
输出让业务满意的性能测试报告
写测试报告是很多测试同学比较头疼的问题，但很多时候报告的作用远超形式主义的为老板汇报的作用。下面是我总结的一个性能测试报告的模版，供大家参考：
PS：以流量网关接入业务为例！
标题
XXX性能测试报告
结论
经过x轮测试验证，涉及x个场景，目前的结果已满足x业务的线上实际场景。相比于接入/优化前，接入后整体提升xxx，对x业务的优势是xxx。
背景目标
为了统一流量入口，做到安全防爬/统一鉴权等目的，我们选用了APISIX作为流量网关组件。 我们的目标是xxx。，业务接入后，可以解决xxx问题，带来xxx提升，避免xxx。
环境信息
网关配置：8C16G
集群数量：三个可用区，每可用区6个节点；
网络类型：跨可用区单独VPC调用；
预期指标
同可用区时延<1ms，跨可用区时延<2ms
验证结果
这里用表格或者图表将不同场景和条件下的详细数据列出来
建议方案
针对不同的业务类型和技术栈，我们准备了x种方案：
a业务建议x方案，原因为xxx，优势为xxx；
b技术栈建议y方案，原因为yyy，优势为yyy；
相关文档
a业务接入文档
b技术栈接入文档
接入常见问题及解决方法
总结
报告要重点突出结论，直截了当的给业务方明确的结果；
说明验证环境信息，尽可能贴近或者匹配业务方的实际情况；
阐述项目的背景/目标和如此做的价值，价值最好切中业务实际痛点；
提供更多可选的方案，傻瓜式的接入方案比各种改造更能让业务方接受；
文章来源
发表评论