移动性能测试 [个人总结分享] 安卓端性能测试 (思路及方案设计篇)

浮云 · 2018年05月28日 · 最后由 Test44 回复于 2019年09月12日 · 4095 次阅读

开篇前述:

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

正篇开叙

性能测试阶段

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

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

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 5 条回复 时间 点赞
浮云 [个人总结分享] 安卓端性能测试 (数据篇) 中提及了此贴 05月28日 20:03

可以做成 TK 可视化

回复

不做成图形化交互,其实我是有自己的考虑的,对内是开放脚本源码的,引导测试执行了解执行步骤细节,并进一步看看有没有手工人员主动看源码,问问题,有这类积极度高的人可看基础情况培养下,毕竟测试开发不好招。

测试开发主要的两大类,其一是研发路子转的,另一类是我这样从功能测试转自动化后又转负责性能专项设计到现在负责非功能测试。各有各的优缺点,从功能测试转的对业务熟,了解测试执行的痛点,设计方案时会倾向解决问题和使用的易用性。而研发路子代码基础强一些,但缺乏做事做方案的设计思路,听安排实现自动化需求,更适合测试工具开发而非自动化测试方案设计。作为团队来说是希望两类人都有的,优势互补。

再有现在更倾向于 CI 线上交互,线上维护代码避免通知和线下使用的测试工具版本参差不齐。

楼主你好,我想问下关于 android 性能这块的问题,如果想实现脱离手机和电脑的数据线连接这块有什么好的方案吗,例如 wetest 类,把一个 sdk 嵌入到 apk 里,因为现在的 android 系统限制越来越大,adb shell 的命令很多都需要 root 才能实现,想找一套 apm 类似的开源的工具,例如把 sdk 嵌入 apk 中,开启监控后,数据上传到 web 端,成图形化显示出来,楼主对这方面有研究吗,如果有的话,希望可以帮助推荐一下

enumerate 回复

这要区分内部测试还是外部数据抓取,外部数据收集走埋点上报,内部测试就简单了,设备端后台挂个监控持续跑数据就是了。脱机方案最简单就是 shell 后台脚本,权限是 shell 或 root 权限,设备端 adbd 不重启进程就在。

比如我自己设计的 shell 设备端监控 (https://testerhome.com/topics/20187) ,shell 脚本加个后台执行(&)就完事了,还可以配合自动化测试分 case 场景分别监控。

性能测试这事一定要 “聚焦”,目的是为了解决问题,最怕无目的的取数据监控,占了开销又没落地到优化。这个又分两个维度:
1、监控:建议在指定位置加埋点,样本量分析,结合具体的 case,在特定行为触发时上报数据,这块重点是采样点和采样频率控制。
2、筛出问题推动解决:找个合适的方案配合自动化 case 或手工测试做数据抓取和分析

对于 android 上的 app,后台查杀是常事,不是 rom 整体测试,监控时长配合进程存活时间做埋点应该是比较合适的监控方式,至于各家的埋点上报和后台数据统计报告都是各做各的,原理一致,方案和形式不一样。

Android 的 APP 性能好累,但楼主这篇文章给了我很多学习的引导,谢谢

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册