通用标准： 百度app安装数达到10万以上
1.安装时长： 安装时长大于6秒，且同款手机智慧社区APP安装时长大于百度app 30%以上
2.启动时长： 启动时长大于2秒，且同款手机智慧社区APP启动时长大于百度app 30%以上
3.CPU占用： CPU均值占用大于50%，且同款手机智慧社区APP CPU占用大于百度app 30%以上
4.内存占用： 内存占用大于140M，且同款手机智慧社区APP内存占用大于百度app 30%以上
6.FPS： FPS小于50，且同款手机百度app高于50FPS
APP性能测试(1):FPS测试
工具/原料
apk文件
APP加密网站
方法/步骤
安装、卸载测试：安装测试、卸载测试。测试软件在不同操作系统（Palm OS、Symbian、Linux、Android、iOS、Black Berry OS 6.0、Windows Phone 7）下安装是否正常。软件安装后的是否能够正常运行，安装后的文件夹及文件是否写到了指定的目录里。
UI测试：导航测试、图形测试和内容测试。测试用户界面(如菜单、对话框、窗口和其它可规控件)布局、风格是否满足客户要求、文字是否正确、页面是否美观、文字、图片组合是否完美、操作是否友好等。
UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏觅功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。
功能测试：运行、应用的前后台切换、免登录、数据更新、离线浏览、App更新，定位、照相机服务，时间测试、PUSH测试。根据软件说明或用户需求验证App的各个功能实现，实现并评估功能测试。
安全测试 ：软件权限、安装与卸载安全性、数据安全性、通讯安全性、人机接口安全性。
如何看国内首个应用性能管理标准的发布
adb 计算帧率： https://zhuanlan.zhihu.com/p/67056913
adb 计算帧率： https://www.huaweicloud.com/articles/12566219.html
帧率：FPS是图像领域中的定义，是指画面每秒传输帧数，通俗来讲就是指动画或视频的画面数。30FPS是一般录像的常用帧数，30FPS在快速动作的时候会感觉不流畅。60FPS是一般游戏的常用帧数。
绝大部分时间两者(Android和IOS)都能保持60FPS左右的满帧率。但都会有偶尔的掉帧。并且Android上要比IOS上严重很多。掉帧导致卡顿，用户必然会感觉到掉帧那一刻的不流畅。
FPS是图像领域中的定义，是指画面每秒传输帧数，通俗来讲就是指动画或视频的画面数。FPS是测量用于保存、显示动态视频的信息数量。每秒钟帧数愈多，所显示的动作就会愈流畅一般来说，Android设备的屏幕刷新率为 60帧/s ，要保持画面流畅不卡顿，要求每一帧的时间不超过 1000/60=16.6ms ，这就是16ms的黄金准则，如果中间的某些帧的渲染时间超过16ms，就会导致这段时间的画面发生了跳帧，因此原本流畅的画面变发生了卡顿。
FPS 通常作为衡量应用是否流畅的标准。
FPS 即 frames per Second（每秒显示的帧数），用于测量显示帧数的度量。帧数为 0 说明页面处于静止，只要页面动起来，这个帧数就会有变化，然后再趋于静止，页面滚动起来帧数整体呈现 “非对称” 抛物线走势。接下来看一张图直观感受一下：
通过上图我们能看出 FPS 值的大小对画面流畅度的影响，每一帧都是静止的图像，快速连续地显示帧便形成了运动的假象，因此高帧率可以得到更流畅、更逼真的动画。
帧延迟的高低可以通过帧时间（frame Time）来判定。我们参考显示器的 60Hz 刷新率进行计算，它意味着每秒刷新 60 帧，每帧大约用时 16.7 毫秒。画面中每帧生成时间如果与 16.7 毫秒很接近，那么全程画面的帧数就很稳定，更接近理想的 60 帧每秒。
如果每帧生成时间高于 16.7 毫秒，也就意味着渲染这一场景所花费的时间比其他帧更多，造成画面跟不上，进而带来显示卡顿。
手机的 CPU 处理速率、屏幕尺寸、内存及显存的大小都影响着 APP 帧率的大小，这些因素在一定程度上约束着准备数据和数据传到屏幕的时间。再者，GUI 软件架构在一定程度上也影响着应用帧率的大小。
在同等机器环境下，除去 CPU、屏幕尺寸及系统 GUI 等固有数据传输耗时，要提升应用 FPS 就要减少视图渲染的时间。
1、尽量不要在刷新时做耗时操作，例如准备数据，创建图片，图片变换等，数据和图片都应该在之前就加载到内存中，图片变换用 canvas 的变换来实现。
2、同一个界面中多个动画重叠出现时，尽量将动画的刷新过程统一刷新，避免频繁的 invalidate，尤其是多个动画有时序上的关系时更应该统一。
3、尽量使用带有参数的 invalidate 来刷新，这样可以减少很多运算量。
APP也需要关注FPS、Jank及卡顿率。只是需要区分使用场景，如：
只需关注FPS，理论FPS应该为0，否则，说明有冗余刷新，容易引起手机发热及耗电。
只需关注FPS，FPS处于合适值即可，无需高频刷新。
需要关注FPS、Jank及卡顿率。手机交互灵敏度就是来源于此，Android系统才出黄油计划Jank。一般滑动状态下，帧率越高越好，Jank越小越好。
需要关注FPS、Jank及卡顿率，视频卡顿直接影响用户。视频一般帧率18-24帧，Jank=0。比如微信播放视频、视频播放器等。
注：
引用来源
APP性能测试-流量
在商业规则中，标准这个词提及得最多。任何一个市场都需要一套标准，没有标准也就没有了靶子，没有了规则，也就无法建立最优的秩序效果。特别是在一些新兴的行业和领域，一开始处于混沌状态，但市场一旦逐步成熟，就必须在标准化上推进，否则市场上会有不同的声音，没有了好坏之分，市场也会停滞不前。移动应用性能管理就是走在标准化过程中的一个行当。
最近，一份移动APP的生存状况报告披露，我国主要应用商店的应用规模已超过400万个，App的生命周期平均只有十个月，85%的用户会在1个月内从手机中删除，5个月后应用程序的留存率仅有5%。在AppStore中，中国僵尸应用占比高达81.3%，为全球最高。这也表明，APP竞争正进入深水区，首个应用性能管理标准的发布，又能在多大程度上改善APP恶劣的生存环境？
没标准市场就是伪命题
这两天，国内移动应用性能管理的领导品牌听云也发布了一份《2014年中国移动应用性能管理白皮书》，专门就应用性能管理给出了一些标准层面的建议。报告从应用崩溃率、错误、请求响应时间、交互性能及运营商网络响应时间五个维度，给出了优秀、标准、轻微隐患、严重隐患四档数据区间。整个白皮书基于听云App监测覆盖的3.5亿台终端，日启动量2.4亿次，每日超过100亿次的真实用户请求的监测。
从数据样本上来看足够大，也就更具代表性和参考价值。可以说，谈到移动应用性能管理，在中国还是一个远没有普及的概念。很多应用开发者，辛辛苦苦开发出来的APP，从互联网思维到极致、体验、单点突破，一套关乎用户体验的葵花宝典，还花费大价钱去抢应用商店的入口，结果却在性能管理的“阴沟”里翻了船，就像漏斗一样，因为性能不“达标”，相当一部分用户流失掉了。
只不过，由于缺乏标准，危害很难量化。所以说，这就是一个典型的“误区”，就像雷军说的，“如果不能在性能上过关，谈用户体验都是耍流氓的行为”。而根本原因有两点：一是移动应用的开发者们对应用性能的定位和数据、危害认识不足，也将性能问题归结为自然现象，无知者无畏二是移动应用性能领域缺乏统一的标准，比如说崩溃几率多高、响应时间多长、发生错误几率等指标，没有一个参照系。
标准是怎么设定的？
其实就是需要建立一个参照的体系，而建立这个体系显然不能拍脑门，而具备探索这一标准能力的企业就更寥寥无几了。难度主要体现在两方面：一是应用性能问题出现的频率和错误种类太多，涉及到主流的手机机型有5079个，1172种操作系统、18家运营商网络，就如排列组合一样，应用性能问题组合起来1亿零700万种二是国内移动应用面临的环境过于复杂，特别是云服务、CDN、物联网、互联网+的后时代，让应用所处的IT环境和网络传输链条不断扩展，多维度分析、诊断的难度越来越大。
说白了，移动APP火爆起来也没几年，如果对性能数据指标进行定义的话，只有有数据积累和终端、用户广泛覆盖后，才具备了条件，否则无从谈起。所以作为新兴事物，本身就是摸着石头过河的事，距离普遍认可并遵从行事更远。从听云发布的《2014中国移动应用性能管理白皮书》来看，对基础指标进行了定义和区间定性，分别从崩溃、错误、网络请求响应时间、交互性能、网络响应时间，五个维度进行判定。
而标准是否合理取决于实际环境所产生的数据，比如按照系统不同，iOS崩溃率在3-8‰间属标准，安卓2-4‰间，如果超过这一指标，iOS在8-15‰间就是轻微隐患了，如果达到15‰以上属于严重隐患。试想，如果应用在运行过程中出现崩溃、关闭现象，带来的直接影响就是用户留存度下降，关键业务中断，ARPU值降低，长期看DAU和MAU会持续走低，这对于任何一款应用来说都是致命的。而目前的现状又如何呢？报告表明大多数移动应用处在轻微隐患的档位上，是不健康的。
同样，在错误、响应时间、交互性能指标上也大体类似。
在没有统一标准前，判定一款移动应用到底在性能上是不是健康，完全没有全行业认可的指标。就像一个人的身体健康指标，每个参数都有一个区间值，超出的话就说明存在异常，需要进一步发现病因，并采取治疗措施。应用性能管理也是这个道理。但如果没标准来认定，到底健不健康就存在争议，谈性能管理就成了伪命题。
应用性能管理任重道远
有人会说，为什么不沿用国际上的标准呢？就如同国外出现的成熟的商业模式，复制到中国来本土化一下，难道不是中国互联网十几年来一直走的路吗？道理对，但是行不通的。就应用性能来讲，确实比中国要成熟的多，市场接受度、认可度和使用率也高，早在1998年就出现了商用的应用性能管理产品，但十多年发展处于滞涨期，原因就在于缺乏标准。而后Gartner提出5个维度模型来解决性能需求，才催生了New Relic和AppDynamics这样的应用性能管理企业。
相比，中国移动应用性能管理的市场比海外要大得多，由于应用所处的环境又有很大区别，导致国外的和尚即使进入中国，也念不好经。拿移动互联网发展特征和空间来说，中国在餐饮、旅游、网购、电影票、教育、医疗等领域上演的O2O商业形态，在美国远没有这么热闹。另外还有一点是企业级移动应用处于爆发前夜，相比个人应用市场，企业级更强调业务的连续性、稳定性，一旦发生中断，业务直接停摆，所以对应用性能的管理“痛点”更强，这都决定了移动应用性能管理会是一个大的business，且具明显的本地化特征。
目前来看，市场上即便是大佬们的移动APP，微信、大众点评、导航、支付宝等，都难免会出现性能问题，连接超时、闪退、卡顿、崩溃、交互性能及联网性能问题，尤其是联网与IT、网络环境动态相关，这决定了性能监测和管理是一个长期、持久的工作。虽然像听云这样的专门做应用性能管理的企业，并没有去定义和推行标准的权力，但市场会最终会做出选择。
转载
获取流量数据的方法：
1、先获取进程ID：adb shell ps | grep com.android.browser
2、获取流量命令：adb shell cat /proc/5715/net/dev
Receive：接收数据流量；
Transmit：发送数据流量；
lo：本地流量，不用统计，因为它没有使用网络；
eth0：网卡0的流量；
eth1：网卡1的流量；
app总的流量=Receive+Transmit，即当前app流量消耗的总值；
1、第一次获取流量数据之后，在APP上经过一些列操作，时间5s，然后再去获取一次APP流量数据，差值就是本次APP的流量消耗；
2、持续执行10次，获取10次流量差值；
衡量流量消耗的标准：
1、竞品对比；
2、版本对比；
V1.2，消耗20M流量；
V1.3，消耗30M流量；
需要找到流量消耗原因。
以上就是关于APP性能测试的标准全部的内容，如果了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！
