测试关注指标记录点

 

一、主要指标值

 

• 内存：反复切换tab，滑动页面等场景不存在内存泄漏
• 电量：程序放后台或处于飞行模式的情况下，耗电小于10mAh
• 流量：无异常流畅消耗，不存在资源的重复拉取
• CPU：启动时CPU占比<20%,运行时CPU占比峰值<80%
• Crash：网络/网络状态发生变化时，连续运行8小时，无crash
• 流畅度：平均FPS不小于40，FPS大于0
• 弱网络：无crash，体验方面提示用户网络环境差，拉取失败能正常返回
• 打开速度：
  • APP内的H5页面： 
    • 首次启动时间：4G小于xx秒，WiFi/3G小于xx秒，2G下小于xx秒
    • 非首次启动时间（有缓存）：4G小于xx秒，WiFi/3G小于xx秒，2G下小于xx秒
  • 分享后浏览器打开的H5页面：
    • 首次启动时间：4G小于xx秒，WiFi/3G小于xx秒，2G下小于xx秒
    • 非首次启动时间（有缓存）：4G小于xx秒，WiFi/3G小于xx秒，2G下小于xx秒
  • 客户端页面：
    • 首次启动时间：4G小于xx秒，WiFi/3G小于xx秒，2G下小于xx秒
    • 非首次启动时间（有缓存）：4G小于xx秒，WiFi/3G小于xx秒，2G下小于xx秒

 

 

　注：网站性能 行业参考值（来自 听云平台，统计的 网络指数）

 

• 首屏时间（秒）3.1
• 页面打开时间（秒）9.3
• 总下载字节数（KB）3920.9
• 页面元素个数153

 

二、”加载速度“ 的主要关注点如下：

• 网络
  • WIFI/4G/3G/2G
• 启动
  • 白屏时间
  • 首屏时间
  • 可交互时间
• 缓存
  • 有缓存
  • 无缓存
• 缩短响应时间
  • CDN部署
  • 合理分域名
• HTTP请求数
  • 资源合并
• HTTP状态
  • 失败资源处理
• 单个请求优化
  • 缓存机制
  • 压缩内容
• 资源合理组合
  • 预加载
  • 分页加载
  • CSS放顶部
  • js放底部

三、测试关注指标：

• HTTP请求个数【是否有多余的请求，示例：后端可做的请求放在了前段去实现（注：公共的加载项除外）】
  • 一个网页最终到达终端用户有80%的时间都是在js，CSS，图片，mp3，flash等资源的http请求。另一方面，http请求的数量也是有限制的，浏览器对同一个域名有连接数限制，不同浏览器内核、不同版本的请求数不尽相同，大部分的并发请求数是6个。
  • 问题：什么样的请求应该由后端去做？什么样的请求必须由前端来实现？
• 组件是否压缩
  • 压缩方法：在http请求中设置所接受到压缩方式，在Server端对Response资源进行压缩再传给浏览器。一般使用GZIP设置content-Encoding字段。Transfer-Encoding: chunked
  • 压缩对象：从http请求返回资源中的html，js，CSS，xml等都可以设置压缩，值得注意的是我们不需要对图片音乐等资源设置压缩，因为这些资源本身已经压缩过了，再次压缩收益并不高，而且增加CPU负担。
  • 问题：什么情况下才会做压缩？哪些文件支持压缩？压缩的利弊？
• 图片格式和大小是否合适
  • 图片格式：显示效果较好的图片格式中，有webp、jpg和png24/32这几种常见的图片格式，webp的图片最小
  • 图片尺寸：获取图片尺寸时候应该考虑图片具体的展示场景，如当前移动设备中常用个尺寸规格为480×800、600×1024、720×1280，800×1280等，从原图来保证图片能够被呈现，而不是通过代码对图片放大或缩小。
  • 图片压缩：对于jpg，png格式图片来说本身就已经经过了压缩，这对于稀缺的带宽资源是不够的，我们还需要更加优化的压缩算法，通过一系列的图片压缩工具如TinyPNG, Smush.it可以得到更好的压缩且图片质量不变。
  • 问题：jpeg的图片格式跟jpg图片格式的区别？图片的尺寸对加载性能上的影响大不？图片的大小一般建议不超过多少KB？
• css放在顶部（CSS和js代码是否有做分离）：
  • 在浏览器渲染过程中谈到，dom树构建完成后。CSS要放到html代码的开头的head标签结束前。如果网页是动态生成的，那么在head代码完成后可以页面输出，这样浏览器就会更快地解析出来head中的内容，开始下载CSS文件资源。而CSS放在底部则会引起重新绘制，用户侧感受到“闪屏”的不好体验。
  • 问题：CSS和js代码什么情况下适合做分离？什么情况下是不可以做分离的？
• js放在底部
  • JS在下载的时候会引起两个问题：阻止网页内容的展示并阻止其他资源下载。在“减少http数量”部分中，我们谈到各种资源的下载是并行的，根据不同域名不同浏览器内核并行数量有所不同，所以下载js时候，并行下载机制失效。并且在js中可能包括document.write等改变页面布局的操作，所以渲染引擎会等待js下载完成再开始渲染。所以用户侧页面加载时间会因为等待而变得更长。
• js&css压缩
  • 从js&CSS文件的源头进行压缩，缩小了http传输过程数据大小。
• 是否添加缓存
  • 缓存的优点：缓存接口数据，在一些数据新旧敏感性不高的场景下很有用，在非首次加载数据时候优先使用上次请求来的缓存数据，可以让页面更加快速地渲染出来，而不用等待一个新的HTTP请求结束之后再渲染。 
  • 两种方式设置缓存，测试时注意常用资源是否请求资源时否设置缓存Cache-Control：
    • "no-cache"指示请求或响应消息不能缓存（HTTP/1.0用Pragma的no-cache替换）
    • "no-store"用于防止重要的信息被无意的发布。在请求消息中发送将使得请求和响应消息都不使用缓存。根据缓存超时Expires 表示存在时间，允许客户端在这个时间之前不去检查（发请求），等同max-age的效果。
    • 问题：什么样的请求类型才会做缓存？哪些文件适合做缓存？一般的缓存方式有哪些？
• 避免非200返回值
  • 如果有http请求返回为非200的状态码，我们认为这一次请求时无意义的，占用了稀缺的网络资源，所应该避免非200的返回状态码。
• 使用CDN
  • CDN内容分发网络（Content Delivery Network）将源站内容发布到最接近用户的“边缘”节点，使用户可就近取得所需内容，提高用户访问的响应速度和成功率。解决因分布、带宽、服务器能力带来的访问延迟高问题。

  • 问题：哪些内容才会用到cdn的分发？

• 页面的加载方式？（是否有懒加载、预加载）
• 时间
  • 白屏时间：用户首次看到网页有内容的时间，即第一次渲染流程完成时间。
  • 首屏时间：是指用户看到第一屏，即整个网页顶部大小为当前窗口的区域，显示完整的时间。
  • 首资源下载时间：从开始下载到第一个资源均下载完成的时间，不包括页面绘制时间。
  • 总资源下载时间：从开始下载到所有资源均下载完成的时间，不包括页面绘制时间。
  • 用户可操作时间：从页面开始加载到用户操作可响应的时间。