开篇前述：

四月底换的工作，交接前两周做了下历史经验总结和公司内分享，还受邀去东舟做了下分享。现在晒下主要内容，背景知识自己补齐吧，不详细介绍了。内部分享时展开详细讲时讲了三个多小时，累。。。本篇还是介绍思路为主。

正篇开叙

性能测试阶段

如何理解这张图？
第一阶段：想办法聚焦优化范围并推进优化点合入用户版本。（落实优化）

1、相关部门出接口人参与虚拟团队，由虚拟团队进行优化决策和各自团队内的信息传递。
2、虚拟团队拍定第一版优化范围、用户体验标准线、项目 bug 标准线。
3、持续例会跟进优化进展、测试范围调整及标准迭代
4、优化成果合入用户版本后进入第二阶段

第二阶段：监控衰减及扩大优化

1、主线版本建立重点关注项的持续自动化测试进行防衰退跟踪
2、用户版本拉线后性能专项测试（根据合入需求的性能风险，可动态调整复测范围），之后对性能 bug 持续跟进，发版前提供数据报告用于上线评审
3、扩充性能专项测试覆盖的范围及维度，在主线上推进优化；虚拟团队例会跟踪并推进落实优化后进入监控衰减阶段

第三阶段：性能数据进入稳定期后，根据研发力量投入情况，设定更高目标推进优化，由虚拟团队主导（评测对比推进 KPI 迭代）

性能测试优化进程

优化思想主旨：

筛查问题场景推进性能优化 ———— 聚焦优化范围、设定目标、推进研发投入优化点分析和解决方案决策
用户反馈性能问题优化 ———— 各反馈渠道信息统计分析，依据反馈量排行逐步收敛性能问题
CPU/内存 IO 优化策略落地 ———— 管控硬件资源分配，控制后台，保障前台
评测对比推进 KPI 迭代 ———— 探索优化能力上限，提高产品在竞品中的性能体验优势

设计脚本方案的思路（我历史经验中的思考点总结）

主要设计思想：
1、设备各端按需独立执行脚本（降低长连接产生的执行效率损失，规避连接不稳定对执行过程产生的未完整执行风险）
2、设备端使用 shell 脚本摆脱安卓层的管控
3、数据采集尽可能的靠近原始数据，使用文本流处理思想提高采集效率，保存结果为 csv 格式。（部分命令行工具在采集数据上有时间和关键内容项优势时，使用该工具输出为数据源）
4、数据监控进程可按需定制，外部进程可控制运行和停止
5、用例操作场景灵活，可动态配置顺序和循环
6、统计报告设计要适应不同角色需求，并且展示效果要有 “高大上” 感觉：
（1）管理者：总结概述，整体了解测试结论
（2）SPM/SQA：bug list 细节，了解重点跟进的 bug
（3）测试：总结报告的关键信息及 bug 提交的完整信息
（4）研发：数据细节及对应 log


↙↙↙阅读原文可查看相关链接，并与作者交流