性能报告&测试汇报
性能报告表达的是业务系统的性能结论
性能报告是一个性能项目的总结,是性能价值的最终体现
“三分干活七分报告”,也就是说干活的辛苦都是留给自己体会的,报告如果做得不好,你再累、再辛苦,所有的付出都会付诸东流。
给老板做汇报,简明扼要即可,不用写那么花哨。
我们的报告不是用来展现自己做得有多么辛苦,也请你务必牢记这一点。
1. 先确定受众,再写性能报告【要先考虑清楚,报告是给谁看,这一点至关重要。给领导看,不用过于细节;给技术人员看,不要过于笼统。】
汇报的场合里,专业技术内容可能并不是受欢迎的话题,
总之,做性能汇报时,控场很重要,我们要引导现场,而不是被现场引导。
2. 性能报告先尽量写全,然后删减
性能报告应该有两种表现形式:
尽量详细的技术型报告:这种报告通常是 Word、PDF、HTML 形式,
报告内容包括项目背景、测试范围、需求指标、工具环境、数据量级、业务模型、场景执行策略、场景结果整理、场景结果分析、结论、问题汇总、后续性能工作建议、运维建议。
【注意】在汇报的场合,切忌与提出异议的人争论。即便有人提出的问题很尖锐,你也一定要磨圆了再回答,在这一过程中要不退不让、不卑不亢。
不退不让,是因为你是汇报人,你是专业的,你要控制全场;
不卑不亢,则是一种沟通的能力和技巧,不要让听汇报的人觉得你骄傲自负,接受不了别人的意见。
尽量简单的汇报型报告:这种报告通常是 PPT、Keynote 形式,
报告内容包括结论、基本信息描述(用几个简单的页面概括一下即可)、问题汇总、后续性能工作建议、运维建议。
第一种报告是给技术人看的,第二种报告显然是在汇报场合中用的。
性能报告
不建议使用报告模板编写性能报告,容易限制住思维,建议最好自己一个字一个字去写报告。
一个完整的性能报告基本上可以分为两大部分:
第一部分是执行场景之前的信息
包括方案中所列的部分,比如项目背景、测试范围、业务模型、性能指标、系统架构图、软硬件环境、压力工具及监控工具、数据、场景设计及报告策略、监控设计。
第二部分是执行场景之后的信息
包括场景结果整理、场景结果分析、结论、问题汇总、后续性能工作建议、运维建议。
场景结果整理、场景结果分析:截图+描述
场景结论:
基准场景:优化前后TPS对比:所有业务的基准场景都可以达标目标TPS
容量场景:优化前后TPS对比:容量场景可满足线上业务的性能指标【技术层面】
业务级结论:
用户级结论:
通过容量场景的结论可知,系统最大TPS为1700
系统可支撑最大918并发用户,系统可支撑最大38250在线用户
稳定性场景:最重要的结论就是所有的业务积累量和持续时间
稳定性场景可持续时间超过 16 个小时,所有业务积累量可达到 7700 万以上,系统资源使用率稳定保持在 80% 左右。
异常场景
应用异常、操作系统异常、容器异常、虚拟机异常等。
对后续性能工作的建议
1. 定时任务必须和实时业务分离。
2. 制定符合业务的定时定量归档计划和分库分表策略;
3. 返回用户友好提示。
生产配置建议
1. 做好项目级的全局监控设计和实现策略,并实现实时预警功能;
2. 做好限流、降级熔断策略,并实现自动容量扩展功能;
3. 结合项目级性能参数配置列表,在生产环境中做好相应的性能参数配置,以符合业务容量的要求;
4. 实现生产环境的定时定量归档和分库分表策略。
对于更具体的建议,我们可以形成相应的文档,直接放在报告的附录中。
【注意】
1. 尽量使用图来表达结论,不要用表格,因为表格无法呈现比较直观的趋势。
2. 性能报告作为性能项目中最重要、最能体现性能价值的一个输出文档,我们做性能的人必须要学会编写。
在编写的过程中,我们一定要先考虑清楚受众是谁,然后从受众的角度考虑报告内容的表现形式。
3. 在做汇报时,我们一定要做到简明扼要,不过分表达,但也不能遗漏。
性能工程实战课-031-怎么写出有价值的性能报告?
本文详述了性能报告的重要性和撰写要点,强调了理解受众、内容精炼以及控场能力在汇报中的关键作用。性能报告应包含项目背景、测试范围、场景执行与分析、结论、问题汇总和建议等,同时提供技术型和汇报型两种形式。在汇报时,应避免过于技术性的内容,用图表清晰展示结论,并保持专业而不失谦逊的态度。
摘要由CSDN通过智能技术生成