移动性能测试 你是如何做移动应用的性能测试的?

恒温 · 2014年01月05日 · 最后由 Mingway_Hu 回复于 2014年01月24日 · 2228 次阅读
本帖已被设为精华帖!

这是 @mingway_hu 的总结 (感谢~)

我测,用的网易的 Emmagee+ 安测试 + 腾讯的 GT+adb dump 再取平均值~~看下那些操作或 activity 消耗,然后大致比一下同类产品,然后就消耗大的地方去问问开发能优化么~

之前在模拟器运行 apk,反应速度就不及真机,没法考虑用它来看性能,到后来只有适配 UI 时才偶尔用用模拟器,别的测试绝对不用模拟器了~

那些工具运行起来后,我一般是手动跑测试,主要看的的是热点功能(可由后来数据统计来确定)、主打卖点功能来测试。自动化考虑过,但结合以前的测手机系统时的经验,影响性能的因素太多,自动化察觉不到时还是要手动来过一遍(脚本偶尔也闹情绪),而我这目前手动盯着来测还能顶得住,就没用自动化来跑。

奉上 Emmagee 链接 https://github.com/NetEase/Emmagee

Unlike most other performance test tools that only do system-level monitoring, Emmagee provides the ability to monitor any single App. Other advantages that you should not miss:

  • Open source
  • Easy to use
  • Process-specific monitoring, including CPU, memory, network traffic, battery current and status
  • Floating window that renders real-time process status
  • CSV format report that can be converted into any other format you want
  • User-defined collecting interval
  • Fully support Android 2.2 and above
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 15 条回复 时间 点赞

我看过一部分的代码 发现他们读取进程特定的内存 网络等指标都是读取系统的 proc 下的文件数据 所以读取的数据都应该是一致的 每次的不同只是环境不同导致的

耗电量这种数据 一般也是跟 io 网络紧密相关的 也就是跟业务相关的 相同业务的对比才有意义

另外同样的业务行为在不同的硬件上导致的耗电量也相差很多 比如内存小的手机很容易发生内存 dump 导致存储卡发热 内存大的就好些 网络访问较多时手机的 gsm 芯片也会发热 3g 就好很多

我的看法是评估性能是否靠谱 还需要在各种真机上测试 并把性能数据和硬件关联起来做历史版本的对比分析

对于研发阶段,可以只关注 cpu io mem network 自己 app 自身窗体的响应和渲染时间 以及渲染的成本 耗电量可以统筹分析

我之前是找几个功能稳定的版本,然后就要查看的几个点,拿到各个版本的数据,再问问开发哪个版本更靠谱、那个靠谱的版本的优化空间、优化后能达到什么水平,然后以这个为大概的参考。之后的版本和这个作对比,只要浮动不是太大、或是由于功能改动导致的浮动较大但在合理范围和可接受范围(需要和产品经理确认)内,我都不会去细究其原因。版本出现大改动,之前的参考数据基本上就废了。。。

请 Dev 协助这块,(个人感受)最好是挑一个接触过该项目的但不主做该项目的、能力较强的 Dev,然后再挑该项目的主管,交流时间尽量选在吃饭或下班回家路上等闲暇时间(这时候他们易说真话,本人亲测~~#)来请教或套话(套话的内容和过程多数时候感觉很有意思,信息量一般也比工作期间的沟通多得多,知识面也能稍稍的得到拓展(这点可能对日后再发生类似问题时快速确认问题原因有帮助))~拿到两类 Dev 的话之后,这对确定参考数据的选取和分析判断有巨大的帮助~

(引两句我们 Dev 同事说的题外话:写 code 是个良心活儿;其实哪有坑我都知道,但是不太想承认,也懒得去改。后来在与 Dev 沟通时和测试时能深刻感受到,有时能通过沟通对一个人做事的态度进行大致的判断,再结合套来的信息哪有坑哪没好好写,然后针对他负责的区域进行有针对性的测试,就能有意外收获~~#)

#2 楼 @mingway_hu 我想请你来讲下第三期的公开课 =,来说说性能测试这块怎样?

#3 楼 @lihuazhang 我只是写了点我个人是如何获取所需的数据、为了确认数据准确性而采用的一些笨办法
总的目的就是为了质量,除了找 bug 之外,就是防 bug。通过查看性能上的变化来推测质量的风险。实际上每个人一看这些字就能明白和做到,本身并没有太多实质上的东西,写成文字就足够了~

我感觉还是让 monkey 哥还有 ‘安测试’ 的作者来讲更合适些:)

#5 楼 @mingway_hu @monkey @ 喜力 有什么性能方面的经典 bug 吗.

#6 楼 @seveniruby

1、有次把一半成品给老总装上了,老总后来反应说在家用时启动的有点慢,后来我看了下流量。。。启动后要下载 1MB 多的图片。。。然后就有了内容运营同学上传各种图片尺寸、大小的规则~(图片这个事后又发现了内存泄露的问题。。。)
2、还有就是部分功能反映过慢,查看完内存消耗后发现是复用旧代码时没删干净。。。

我常遇到大都是这类的问题。。。

#7 楼 @mingway_hu 我认识一个中科院的教授, 他们也在带徒弟研究内存泄漏的问题. 到时候可以拿他们的成果试试.

#8 楼 @seveniruby Cool! 思寒大哥你搞定后教教我们 O(∩_∩) O 哈
关于内存泄露那块,下班路上闲聊时我们开发说过他知道,说有时间教我怎么看。

第一种,让开发加入时间戳和业务跟踪线,相信我费不了他们什么时间,如果开发不愿意可以自己做,锻炼一下有好处。
第二种,直接阅读 code 是最有效的,有关内存泄漏基本上都是 a=new a,b=new b,c=new c,c=a,c=b 造成的,gc 不一定能收回 b 和 c 原来分配的内存空间。另外有记忆的是我们以前常说傻开发最喜欢用 string a=“哈哈哈”+“哎哎哎”,而好开发更喜欢用 stringbuffer 和串联 add 函数一样,你看多了自然就知道了。
第三种,对于所有的涉及到 io 和网络 get 任何 xml、html、image 等等,甚至 dom 的 element 都要在 load 的时候进行一次秒读,可以做个工具,这是针对 web 的,原生的 android 控件还是有质量保证的,但是 web 控件臭名昭著的跟当年的 ie web 控件一样,需要多多留意。
暂时就想这么多。

#8 楼 @seveniruby 思寒大哥,这个是我们开发组老大推荐我看的关于 OOM 的两篇文~我道行浅,看的不是很明白,你帮忙看下这个咋样~~?
http://www.blogjava.net/rosen/archive/2010/05/21/321575.html
http://www.blogjava.net/rosen/archive/2010/06/13/323522.html

#11 楼 @mingway_hu monkey 才是性能测试的高手, 我还没涉猎到这一块.

#12 楼 @seveniruby 他说是好文。值得开发和测试一看~

#13 楼 @mingway_hu 写的挺好, MAT 的底层使用的是什么技术, 最好也可以深入分析下. 应该调用的都是 jvm 底层的机制, 性能分析最好是可以深入的了解下 jvm 的机制. 我也是刚转到 java. 也打算年后好好的研究 jvm

#13 楼 @mingway_hu 其实我觉得现在的情况是这样的,性能我们都还在关在门外,内部实现是可以了解的。但是关键是我们找不到场景去进行研究,大部分的情况下都被其他琐事所缠住了。在没有自己写什么工具分析之前我觉得都是门外汉。。= =

需要 登录 後方可回應,如果你還沒有帳號按這裡 注册