我的系统性能测试方案
性能测试之用例得分评价和 CPU 内存数据监控
对于性能测试，个人看法是：
1、性能测试方案主要目的是引导研发资源投入产出比最高的性能优化点。
2、对于实际项目中的性能测试方案设计，需要根据目的控制测试范围，有所取舍。

对于测试手段：
1、UI 操作偏向用户实际效果的方式，执行测试 case 并录像算帧
2、偏向和研发配合收集性能数据分析则需要埋 log 获取时间，自动化脚本完成执行和数据收集统计形成报告
3、基于显示变化的 case，自动化判定结束状态可以从 SurfaceFlinger 数据变化入手基于变化取性能响应时间尝试
4、CPU，内存，电量监控可以集成到常规测试任务同时进行。包括功能验证，压力测试，专项测试

对于内部标准及推动解决：项目中需要有个能下结论做决策的人（有话语权）推进研发认可标准并跟进解决，制定的标准需要完全站在用户体验角度考虑。

对于竞品对比数据，完全就是为了展示产品和说服研发对性能差的部分进行优化用的。

游戏的 gameplay 测试很大程度上还是拼人力投入的，再有就是公司对游戏质量的态度。正因为人力投入大，Gameloft 在 12 年就把测试放到了越南和马尼拉。Gameloft 对兼容测试的态度还是很值得认可的，保证发售地区使用量 Top100 机型的兼容测试，IOS 还包括多个历史重点系统版本的测试，因为有很多人的 iphone 系列手机到手后都不知道升级。

游戏测试还是需要足够人力保证的，我在 Gameloft 时，标准 gameplay 测试组就是 10 人，还有声音中断组，版本提交前还有其他工作室专门的组负责 double check。
说道具体的测试：
1、首先要过的就是 rules 类检查，规定的标准设计准则，和是否符合用户使用习惯，是否符合应用商店上架标准
2、肯定是要过一遍游戏所有的内容和文本的，这里就需要作弊码做全部内容显示和文本的验证了。测试中发现功能 bug 则需要在不开作弊码情况下再次验证。
3、然后就是需要过音视频的触发，保证触发时刻
4、Gameplay 自由测试就要靠人员手工测试的能力了，再有就是探索测试形式的有针对的引导测试方向
5、兼容类测试就设计分辨率比例显示兼容，适配手机的系统版本兼容的真机测试。
6、压力及性能测试保证稳定性及 cpu，内存，流量开销
如果是网游类，还会涉及后台接口及后台压力测试相关内容

游戏测试除了固定 case 的功能验证，还真不适合做自动化，对于游戏的频繁改动自动化持续维护的方式人力成本代价和时间成本太高

@lihuazhang 本不想把这个工具做成开源项目，也是为了将工具和文章关联在一起，展示的是设计思路。
写这篇文章，起因主要是两点，一个是本身我在 testerhome 群里讨论过两次监控的事了，第一次也展示过我的设计思路和截图效果。第二次又开始讨论就感觉自己需要写一下了，要不每次见到性能测试相关讨论就想吐槽点什么，而结果又是反复说类似的事情，不如一次写清。
本身写出来也是为了从我现在做的事情来讨论框架思路，和设计思路。工具展示出来也是想展示成品效果，及我对数据可视化的设计。
展示出我当前设计的性能测试框架思路，也是希望在更多人的讨论中，可以扩展实际可落实到流程的想法。更多人的想法碰撞，可能会出火花的。

已放出工具，我也是整体设计完逻辑，按逻辑需求直接拼凑代码逻辑完成的。python，html，js，highcharts 和 node-webkit 也是没怎么深入了解直接上手搜实例参考，上手直接写。遇到 bug 和改善意见，可以在这里回复，以便进一步优化下。

@watman 正文中写了所有设计框架和思路。shell 脚本获取数据 +python 处理 csv 为目标 json+highcharts 模板，用 node-webkit 框架展示

Sorry，昨天忙着整理思路，写成了 word。贴过来后，调整了下内容就没排版。今天重新排版了下

建议监控获取数据：cpu，内存，显示的 activity，date 时间。这样分析的时候就可以知道每个获取数据的时刻界面显示状态，时间也可以和 log 的时间对应以便分析

一般都是 Pss 为准，我采用的评估方式都是监控 + 用例（脚本或 monkey），测试整个系统就是 Pss 峰值降序排列，和极值差（最大值 - 最小值）降序排列。对于系统优化思路是：Pss 峰值越高，可优化性越大；极值差越大内存泄露的可能性越大（当然要排除正常逻辑缓存数据，像在线视频类的 app）
对于 app 评估，对比下竞品的 Pss 占用情况，给极值差定个预警值，超过预警值就要分析下原因，以便筛查内存泄露。

5、dumpsys SurfaceFlinger 可以直接判断显示内容的情况，你使用 dumpsys SurfaceFlinger|grep "|....|"取几次数据就能清楚，这部分数据是有用来做判定的价值的

使用 shell 写脚本就是要很清楚信息来源 proc 伪文件系统下的可用信息，dumpsys 可获取到的状态，busybox 可已被利用的命令，uiautomator dump 获取 ui 布局，uiautomator events 获取 ui 事件 log 等；文本操作处理灵活使用 awk，grep，sed；明晰权限对执行命令的影响；控制操作的方式：input，sendevent，am，svc 控制网络开关等。剩下的就是如何组织逻辑，容错异常，设定输入格式将结果信息格式化输出等整体设计的事项。

我自己也已经使用 shell 分析 uiautomator dump 写脚本 1 年多了，几点经验：
1、uiautomator dump 在不同权限下有读写限制，需要保证可以正常写入文件，写文件的位置可以自行调整。
如：uiautomator dump /sdcard/check.xml
2、安卓 5.0 有 dump 出的文本中文乱码问题，需要替换 uiautomator.jar 或更新 uiautomator 相关代码
3、解析 xml，建议使用<node 前加回车换行的方式，一目了然，grep 特征字符锚定行之后 awk 按” 间隔选取很容易判断
注意 echo 变量需要加引号否则会没有换行符导致 grep 特征字符锚定行无效
uiautomator dump /sdcard/check.xml && busybox sed -i 's/<node/\n<node/g' /sdcard/check.xml
4、uiautomator dump 有失败的问题如动态界面抓取，需要容错此问题，每次执行前删除/sdcard/check.xml，判定文件正常生成后继续
5、由于 uiautomator dump 效率问题，在非精确判定布局和文本的情况下，灵活使用 dumpsys SurfaceFlinger，dumpsys window 判定显示状态。
以下命令配合 awk 判断显示界面情况
dumpsys SurfaceFlinger|grep "|....|"
以下命令配合 grep 判断是否存在
dumpsys window p| grep -c "特征字符"
代码实现细节就不写那么多了，思路就是如此。