移动测试基础 JB 的测试之旅-关于线上问题的看法

jb · 2018年11月19日 · 最后由 jb 回复于 2018年12月11日 · 4246 次阅读
本帖已被设为精华帖!

说明

本文以文字为主,会讲解到理论及具体工作思路,因当时没有保存代码,因此代码部分不贴,也懒得写了;
因内容过多,途中会插入部分表情包,阅读时长5-10分钟;

前言

这篇文章修改很多次,各种推倒重写,原因是,一开始只想写自己做过的东西,但是写着写着,觉得太局面,因此想换个大点的角度,能力有限,写的不好或不够,欢迎讨论;

去年8月份,做了线上问题跟进的事情,持续到去年年底,后来因进度问题,以及采用的底层方案有点问题,就让研发负责了,从某种意义上,这是第一个完全自主负责的项目;
image.png-98.6kB

整个项目对于Jb来说是个挑战,同时是一个明显的成长点,后来找工作面试的时候,很多企业对这个感兴趣,问的东西比较细,到现在为止,依然很感恩有这个机会;

一年后的今天,如果要问自己,同样的问题,有没有更好的解决方案?目前来看,没特别的想法,总感觉今年在测试这方面,有点退步了,毕竟今年都在不务正业;

日常骚操作

废话一大堆,来谈主题吧;

相信每一位测试&研发,都会有这日常工作:
跟进线上问题

无论是PC、M端、小程序,只要是面向C端的产品,发布后,肯定会有用户反馈问题;

  • XX功能无法使用;
  • XX功能闪退;
  • XX功能充值不到账

相信很多同学都会遇到这些问题,遇到问题别慌,这类问题一般都会有一套应急流程,因不同公司而异,这里只说知道的;
image.png-121.7kB

一般来说,线上反馈分两类:
紧急&非紧急

紧急问题处理流程

一般的紧急问题处理流程如下:

  • 客服/运营收到线上反馈,且短时间内呈现明显上涨;
  • 通知项目经理/测试/研发,测试尝试重现难问题,研发同步排查代码;
  • 能重现问题/研发知道原因,解决问题;如果重现不了,研发排查差不出问题,尝试联系用户及动员更多的同学一起重现,尝试重现;
  • 确定解决问题方案(回滚代码/紧急线上处理,APP则hotfix或重新提交各商店),内部验收
  • 问题上线后,监控/及时回访用户,观察是否已经解决问题;
  • 分析产生问题的原因,总结;
  • 复盘,后续如何规避;

大致上是说,就是这么一个流程;

非紧急问题处理流程

而对于非紧急的问题,一般如下:

  • 客服/运营收到线上反馈,先确认,标准下不同问题的重现情况;
  • 定时整理,比如一周,反馈到测试&项目处;
  • 测试确认,如果是能重现,报Bug给开发,根据问题严重程度,酌情排期;如果不能重现,也先报Bug,列为观察问题,后面3个版本留意下是否有类似问题或是否能重现,如果一直不重现,关闭观察处理;
  • 问题解决,测试通过,安排版本上线,同时反馈到客服/运营处,安排进行用户回访;
  • 定时关注线上数据,确保问题已解决,并且及时邮件通知最后的结果;

基本上,这两套流程就能用了,很普通的流程,尤其非紧急流程,内部反馈问题也大概是这样,只是内部反馈,可以及时要现场重现;

一般来说,紧急情况,如果实在找不到解决方案,回滚是最后的方案;

而对于非紧急情况,现实往往是测试折腾半天,无法重现,然后放一边,毕竟工作繁忙,而且反馈的问题也比较多,没可能过多投入;

一旦形成习惯,这类情况一般都会说,无法重现,完,然后没下文了,这也是测试日常的骚操作;
image.png-67.2kB

其实从用户角度想想,蛮累的,之前简单统计过,用户主动反馈问题的比例是万分之一,而这万分之一的用户反馈问题过来,测试却说,无法重现就完了,而且也没个交代,犹如石沉大海一般,很打击积极性;

到这里,要知道一点,不能挑战用户,有用户反馈,就说明用户想这个产品越来越好,然而现实很残酷,他明明爱着你,但是你却不知道,舔狗不得house;
image.png-232.8kB

吹下理论吧

上文得知,一条用户反馈来自不易,那如何有效利用用户反馈,以及把没反馈的用户也利用起来,就是需要思考的问题了;

需要注意,用户不反馈问题并不代表没问题,也许用户想反馈问题直接crash了,无法反馈,或者有问题模块不影响用户日常使用,jb也是用户,看到软件有bug,懒得反馈,反正可替代品那么多,不行就换一个罗;
image.png-21.5kB

上面说到的,这里都不介绍,主要想说说自己对质量保障的看法,可能比较片面,但是想增加对线上质量的关注;

目前整个质量环节大致是这样:

  • 研发阶段,通过研发自测、概要设计评审等手段尽可能提高交付质量;
  • 测试阶段,通过用例评审、丰富测试手段(探索性测试等)来验收产品;
  • 灰度验证,快速验证产品上线是否存在严重问题;
  • 问题修复,线上问题快速定位、修复;

当然,上面说的只是大致环节,还有很多小环节没有暴露,比如上车检查(代码检查)、monkey、核心数据、集体试用等环节;

看到这里,不得不问,如何在敏捷项目中做好质量管理?

质量管理是一个大环节,并不单单是测试找bug,而是贯穿项目立项到结项整个过程,比如产品文档规范等都是一环,比如,产品文档模棱两可,研发测试也没有核实,结果成品跟产品要的效果不一致或者有很多BUG,导致项目延期;

怎么做好质量管理,目前想到两个环节:预防&测试分级

预防

预防,在项目初期就可以有一定的计划,让项目避免出现已知或可能出现的风险。
提前规避,是检验项目经理对整体项目把控程度好坏的重要考量标准。

而定期检查和调整是保证产品质量的关键,定期召开评审会/晨会,及时同步信息,在此显得尤为重要;

那研发侧怎么预防?目前大众的方案就是静态代码检查、lint、代码覆盖率(jacoco较多),从以往经验来说,静态代码、lint的检查,能发现不少编码、性能问题;
image.png-20.9kB

测试分级

一般说的测试,大部分指功能测试,但是靠功能测试,不足以保障质量,因此需要对测试进行分级,拆分出更细的测试维度;

  • 单元测试,不说,白盒测试的一种,即使大公司也不一定会做,小公司简直别想;
  • 接口测试,保障业务逻辑和后台质量,常用是postman,输入输出,看输出是否跟接口文档要求一致,更进一步,去数据库修改数据,来校验后台处理逻辑是否正常;
  • UI测试,保障到C的体验跟交互;
  • 性能测试,保障整体业务性能和稳定性,满足大环境需求;常见的性能监控有稳定性、启动速度、卡顿率、流畅度、内存、耗电、流量,服务器的话,就是CPU、内存、IO、并发用户数、响应时间、事件成功率、超时错误率,可能有遗漏,欢迎提出补充;
  • 安全测试,保障系统安全性;比如涉及到下载,需要考虑到劫持场景,充值功能,需要考虑网络传输是否加密以及是否有破解方式;
  • 自动化测试,主要是用户回归测试和常规验证,比如某些配置项、主路径功能等;

自动化验证和持续交付

互联网的节奏非常快,想在高强度的氛围保障质量,是一件很有挑战性的事情,换个角度,是否有不需要测试就可以直接上线的情况?

如果想达到这种情况,要做什么?

这个话题就更大了,jb也还在学习ing,但上面有提及到,静态代码检查、看研发代码等,除此,代码覆盖率、自动化都是提高质量的一环;

但有一点是肯定的,要做这块,必须要懂代码,记得前前前老大跟jb说过一句,好的测试,编码能力应该要比最差的研发要强;

上面说的都是台前,那我们也要关注幕后,因为质量并不是一环;

那幕后有什么?打包效率、提测质量、上线部署、线上质量监控,这里不像详细说明,直接贴一个图;
image.png-145.6kB

从性价比看,发布部署是性价比最高的,直接弄个jenkins,写点具体发布脚本即可,收益是最高的;

别少看打包效率这类问题,一人打包10分钟,2人打包20分钟,如果提高到5分钟,那1人就节省5分钟,100人就节省500分钟了,亲身经历,这类问题不能轻视;

其他的提测质量、线上监控,都是很大的点,这里不说;

质量管理优化

不管什么公司,多多少少都会有不同的问题,只是,在大公司里面,往往通过协助平台、流程规范等方式把问题解决或屏蔽,但是在小公司,问题就会暴露出来;

做质量管理不容易,需要强大的内心,而且,公司资源向你倾斜,只有这样才能真正推行,否则如石沉大海;

遇到问题,不要慌,这里介绍三步走:

体系状况,分析梳理

古人云:工欲善其事,必先利其器,想优化,必须得先知道病在哪里,那不妨从以下几个维度去了解问题;

  • 了解公司总体业务现状
  • 了解各业务产品应用架构、技术架构、团队组织架构及分工配合情况
  • 了解业务和产品需求以及未来发布规划
  • 收集核心业务质量现状数据,明确需要优化的方向,优先级,排期处理;
  • - 研发流程现状数据
  • - 产品质量问题数据
  • - 测试质量问题数据
  • - 质量流程问题数据
  • - 团队协助问题收集
  • 诊断分析并找出问题根源(流程、方法、标准、工具、协助、规范等)
  • 根据以上的问题以及具体原因,初步给出一个改善建议的且可行的优先级;

质量流程,优化设计

上面给出了初步改善建议,那接下来就要规定流程,针对具体问题制定规范,明确每个职能部门的分工;

  • 确认目标,即做质量前后有什么变化,要解决什么问题;
  • 根据上一轮诊断信息和优先级顺序,进行优化方案设计
  • - 团队角色及分工定义
  • - 基本流程定义
  • - 流程相关工具平台选择,比如UI用A工具设计,测试报bug用B平台等,确保统一
  • - 初步质量目标和模板定义
  • - 选择试用产品/项目和推广顺序
  • - 实施计划和风险分析
  • 方案讨论,修改,然后跟具体大佬沟通,得到认可后推行
  • 组织团队培训,敏捷思想和方法

质量规范,部署实施

定下规范,就去试试吧;

  • 关键环节控制流程部署和实施
  • - 需求跟踪
  • - 测试设计
  • - 研发编码、提测
  • - 发布验收
  • 全面流程管控和标准化
  • 建立自动化测试平台体系
  • - 接口测试
  • - UI测试
  • - 性能测试
  • - 安全测试
  • 构建持续集成和持续测试
  • 质量保障持续优化机制建立

业界也有个词,叫测试左移,简单说,就是让测试提前介入所有流程:

  • 需求评审,测试必须对业务熟悉;
  • 技术方案评审,测试能读懂和理解技术方案,凭丰富的经验或者嗅觉,挖掘技术方案不足的地方,比如业务场景的可扩展性,业务量大幅增加后的性能问题、可测性;
  • 测试用例和业务编码并行,包括接口测试用例、功能测试用例,准入标准,功能都无问题,回归脚本全部通过;
  • 单元测试质量,除了保障代码覆盖率之外,还要检查UT代码的有效性;
  • 静态代码分析,有能力则协同开发一起保障代码质量,或者引入第三方工具,准入标准,没有严重级别的问题
  • 代码审查,同需要代码能力;
  • 测试用例评审,提测前组织产品、研发、测试一起完成,提测后直接使用;
  • 冒烟测试,提高提测质量,要通过冒烟才能提测,准入标准,比如没有主路径问题;

更详细的,自行上网查询;

大家怎么玩

上面啪啪啪的一大堆废话,本文的重点在于线上质量,那就聊正经事情吧;

问题一般分两类,性能问题、功能问题,体验问题不算在这里;

性能问题能通过一定的规则来抓取,比如获取当前APP的内存,是比较固定的内容:

  • 定时查询统计
  • 有问题直接落地生成log
  • 日志回传到服务器
  • 服务器解析日志,做聚合统计入库
  • 前端查询展示数据

那,在跟进线上反馈的时候,到底遇到什么问题?
image.png-30.7kB

  • 联系上用户,但因各种问题 ,问题没法跟进了或者需要的log拿不回来,怎么办?
  • 压根联系不上用户,怎么办?

记得是在去年2月份,上testerhome发帖子问,幸运得到部分大佬答复,看到的方式有2种:

  • 部分企业有大量log(用户行为日志),通过log分析出用户行为,然后内部排查问题,发现是问题处理,不能发现的,线上增加埋点log;
  • 内部重现,如不能重现,则联系用户,给各种调试包等,联系不上的,放弃;

很不好,当时就是处于第二种,只是觉得,即使是联系不上的用户,也不能浪费;

怀着这份激情,跟老大反馈多次,逐渐的,老大们也开始关注到这块,因此就立了个专项,让jb去负责处理这个事情,因此,这个事情的开端就是:如何跟进线上问题;

这里更多指的是,无法联系,或者联系了重现不了之类的用户;

既然大家都是依赖log来玩,那我们也这么玩吧;

题外话:虽然很不喜欢处理线上反馈,但遇到暖心的用户真的很感动,幸运的是,jb遇到不少,远程各种协助跟进问题,好人还是不少的;
image.png-27.6kB

独乐乐不如众乐乐

既然问题核心是没有log,导致无法跟进问题,那换个角度,有怎样的log才能跟进问题?

因此,有了以下的内容:

  • 当时产品里面有很多收集性能日志功能,比如卡顿、内存、启动速度,只是都不会在release版本开启,因为收集日志本身存在性能问题;
  • 那用户行为日志是不是也可以跟性能日志一样收集?
  • 但是,不在release版本开启,做了也没意义,那,有没有办法做到在release版本开启这些日志功能?
  • 如果支持release版本开启,那怎样的日志内容能满足不同业务进行跟进问题?毕竟不同业务需要的日志内容不一样;
  • 日志什么时候保存?保存在哪里?什么时候回传?回传到哪里?回传到怎么处理?

这就是第一期的目标-发现问题

上面的问题如何解决?

Q:如何在release版本开启收集日志功能?并且支持动态关闭?
Apush,产品本身支持push,有独立push通道,即使用户退出APP也能收到push消息,
因此,针对不同模块(用户行为日志、卡顿、启动速度、内存等)做独立的标记,定好协议,客户端收到push消息后做协议解析,然后修改对应模块的标记,APP重启后做判断,这样就可以达到动态开启\关闭的效果;

Q:怎样的日志内容能满足不同业务进行跟进问题?
A:这是个问题,一开始想着做全家桶,但是后来发现不适合,原因是业务方只会关注自己业务的出错日志,如果弄全家桶,业务方过滤日志需要大量成本;

因此觉得,封装一层提供接口,提供一个写日志的接口,业务方根据协议来传对应的内容即可;

这样,一份日志可能会有多个业务方的内容,没关系,因为格式是固定的,日志回传到服务器后,服务器脚本做解析,最终会把一个日志根据格式内容拆分出N个日志,这样拆分出来的日志就是对应一个业务方的日志;

********************************************
#此处公共模块信息
版本号:XXXX
子版本号:XXXXX
流水号:XXXX
时间:XXX
模块:小说
********************************************
#具体业务日志内容
********************************************

********************************************
#此处公共模块信息
版本号:XXXX
子版本号:XXXXX
流水号:XXXX
时间:XXX
模块:搜索
********************************************
#具体业务日志内容
********************************************

Q:日志什么时候保存?保存在哪里?什么时候回传?回传到哪里?回传到怎么处理?
A:这里面,只有日志什么时候保存是关键;但是这里不细说过程,最终选择的是xlog;

微信开源的一个收集日志库,好处就是,不需要自己处理各种逻辑(比如日志文件限制多少M后拆分等),直接初始化,然后XLog.d就可以用了;

xlog是后面换的,一开始是自己折腾的,浪费不少时间,所以,造轮子之前,想看看有没有好轮子,避免浪费时间;

因为有个业务是联网业务,因此选择软件启动后就异步初始化,只要业务方一调用XLog.d,就会有文件生成;

Q:什么时候回传日志?
A:这里要解释下,一般情况下,日志不会回传,上面都说了,要解决两个场景,

  • 1)用户不反馈;
  • 2)用户反馈但是没日志;

如果是用户主动反馈,则在点击反馈的时候,先把日志上传,得到一个地址,然后再把地址传给客服系统的接口,

这样就能在具体反馈里面看到具体日志,当然这个是原始日志,需要解密处理,因此会再传一个解密后的地址,跟解密服务器约定好的格式;

如果用户没反馈问题,那就在业务出错时把日志上传,业务出错的时机交给业务方自行判断;

部分业务是没办法识别到出错的,比如联网业务,因此这类业务采用日志先落地不上传的策略,需要时通过push拉取日志;

至此,第一阶段,发现问题,到此结束;
image.png-11.3kB

看看干了啥

既然有日志了,那对于测试同学来说,比较方便了,如果没记错,问题解决率在30%左右,看上去觉得很低,但实际是因为,很多功能研发还没埋点,算是一个不错的效果;

点对点的问题解决了,那点对面了?从项目的角度,想知道线上什么情况,怎么搞?

因此专项第二阶段就是监控问题

其实,监控问题,没有太多的内容可以说,无非就是把日志如何解析,聚合,数据处理再显示而已,最终的效果就是,点击某一个版本,选择某一个模块,就可以知道这个模块收集到的日志排名,研发根据这个排名依序解决问题就好了;

换种方式踩坑

做完上面2个阶段,时间到了10月初,期间从立项,方案,调研,编码,灰度,推行都花了不少时间,尤其在推行这一环节,要有具体数据来吸引业务方来使用,不然做出来没人用是很尴尬的事情;

这时候,既然产品有这样的功能,想让用户有意识使用,说白就是想增加曝光,有如下的想法:

  • 新手引导用户
  • 产品首页增加悬浮框告诉用户
  • 简化用户反馈的路径(原有路径有3级,比较麻烦,业界大部分产品也类似)

但是1、2被产品经理打回,原因是,用户反馈这个功能不是每个用户都必须的,为了那点人而浪费一个新手引导位,不合适;

当时听到很不舒服,但是事后回去站在场景的时候思考,有点道理,打脸了吧~
image.png-42.9kB

那就想办法简化用户进行反馈的路径吧,经过思维的碰撞,内部觉得,在产品上三指长按一定时间弹出反馈界面,是一个不错的场景;

跟产品沟通后,产品觉得可以,那需求就为:用户三指同时长按屏幕2S,弹出意见反馈页面;

从此,跌入深渊,自己给自己挖了一个大坑;

跌入深渊

需求很简单:用户在app内使用三指长按屏幕2s,APP执行某操作;

挖坑

需求关键字:三指,长按,2s,执行(这不是需求原话么)
image.png-29.1kB

当时的处理逻辑是这样的:

  • 判断用户手指个数
  • 如果是3个,设置一个runnable 2S后执行
  • 执行时再判断用户手指个数
  • 如果还是3个,执行操作A,over

(懂的大神已经笑了~)

当时信心满满的上线后,发现使用的uv\pv都非常高,非常不合理,因为app上没有功能引导,用户也没有三指的行为习惯,所以肯定是出bug了;
image.png-30.3kB

跟进这问题2个步骤,

  • 看用户反馈,结果上千条反馈,都没有一条相关反馈,那是否可能是打点问题?
  • 查看统计代码,也没发现异常; image.png-38.8kB

问题到底在哪里?
新增了用户的场景统计,发现部分用户在色情网站会连续出现打点,本地尝试没发现问题,就让其他同学帮忙用用,结果发现问题了!!(一个人的力量是有限的,理解也是有限的~)
image.png-1.1kB

原来用户是有多指(3指及以上)进行缩放的习惯,如果用户是使用三指进行缩放,而且还是一直在屏幕不停缩放(即没有手指离开屏幕),就会出现问题了;

因为代码只判断触发前后的手指个数,中招了!(事后跟产品沟通,这种用户可能是平时有用iPad的习惯。。而色情网站是用户在看图片或者漫画,为了看得更清晰,所以需要缩放,就出现问题了,但是还是没想懂如此明显问题,居然没用户反馈?)

噗,多明显的设计问题啊~!

二遇坑

重现后问题就好办了,逻辑重写,处理event事件,触发逻辑不变:

1)当用户手指个数为3个且每只手指按下时间差不大于50ms(防止用户是一只手指点击后再放第二只手指,这种场景是无效的,因此设定个两个手指的时间差),就会设置一个runnable 2S后执行;

2)其他情况,长按后,产生up事件(有手指抬起)、move事件大于一定距离(认为用户在滑动)、大于3只手指,这些场景都会把执行removeRunnable操作,则把runnable取消,避免触发操作a逻辑;

这样算是把门槛调高了,上线后,误触发的占比大幅下降,但是,仍然有百分之一的用户误触发,虽然人均pv大部分为1!!

对比原来动不动误触发,的确是有优化效果的,但是,百分之一的uv也是很困扰~

经过好几轮灰度,最终发现一个问题,问题用户的event常规统计数对不上,那说明有其他没有统计到事件在一直执行,最终发现是cancel事件!!!

再次懵逼,cancel事件理论上是不会触发,至少自己本地用几台机器都没出现。

android文档的说明很简短,想看明白很难。国外一网页说的还比较详细,写在这里分享给大家:

原文是这样的:

You receive this when a parent takes possession of the motion, for example when the user has dragged enough across a list view or scroll view that it will start scrolling instead of letting you press the buttons inside of it.

意思是这样的:

当你的手指(或者其它)移动屏幕的时候会触发这个事件,比如当你的手指在屏幕上拖动一个listView或者一个ScrollView而不是去按上面的按钮时会触发这个事件。”

当时懵逼,我们的场景没有这种行为,为什么还会有cancel事件,肯定有其他原因,最终终于找到了:

“当控件收到前驱事件(什么叫前驱事件?一个从DOWN一直到UP的所有事件组合称为完整的手势,中间的任意一次事件对于下一个事件而言就是它的前驱事件)之后,后面的事件如果被父控件拦截,那么当前控件就会收到一个CANCEL事件,并且把这个事件会传递给它的子事件”;

划重点:被父控件拦截!!

最后经过多次验证,的确是被拦截了,但是,是被rom拦截了!

通过统计数据,发现oppo r9及以上机器很容易出现该问题,人均pv高达几十次,后来找来机器验证,发现问题了:

原来这些手机系统上自带了一个三指上/下滑动进行手机截屏的功能,而原理就是监听event事件,如果发现手指个数等于3,操作系统层直接返回cancel事件;

而客户端没有针对cancel事件做处理,因此导致逻辑继续跑,意味着用户执行系统三指截图功能时,顺带把app的这个三指功能也触发了~

这个问题已经跟oppo的研发沟通,的确如此,而且一加、小米、魅族等新机器都有此功能,如果手动在系统设置把系统的三指功能关闭,则app的三指功能恢复正常,再次验证这个假设;

虽然发现了问题,但是开心不起来,因为后来发现不同厂商虽然都有这功能,但是实现的方案不一样,这里不细聊,后面权衡后,决定对oppo的手机做兼容处理;

(系统逻辑是三指长按后滑动,我们的逻辑是三指长按2s,其实还有区别,但是被系统强奸了。。)
image.png-31.6kB

处理方案讨论了好久,也好了好多大神沟通,纷纷表示没办法,毕竟是操作系统返回的,你能怎么办?话虽这么说,但是后来还是针对cancel事件做了特殊的处理

通过调试发现,一旦触发这种cancel事件,oppo系统会一直返回cancel事件(原理是触发move,系统把所有事件触发都返回cancel,对于系统而言,move是很高频的且很短,而如果真的触发了系统的截屏,每次截屏耗时基本在200ms以上,针对这一特性做手脚)

1)在收到cancel事件时,判断之前触发的runnable是否已经存在;如果存在,则手动把runnable取消;

2)如果每次cancel事件大于200ms,则认为触发了系统的截屏,则把这个事件相加保存起来,原因是排除move事件的影响;并且执行次数+1;

3)当执行次数少于15次且时长大于2s,则认为满足条件,此时判断是否为3只手指且没明显滑动操作,如果是,则立即触发执行操作a;(设置次数是为了提高门槛,不然随着次数的增加,肯定会有达到2s的情况,这样就没意义了)

代码上线了,虽然不是百分百杜绝误触发,但是占比再次下降,基本达到万分之一,这事后来就不折腾了~

如果有更好的解决办法,欢迎一起讨论,这个方案并非合理方案,只是简单处理,而整个功能虽然一句话,但是从编码到最后发现,用了一个月多点,而不停灰度收集统计是时间的大头~

小小结:

  • 研发的概要设计文档流程还是需要的,别以为只是一句话需求就不做了;容易陷入想当然;
  • event容易出现兼容性问题,厂商有可能做了定制处理,这块要切记;

爱理不理

既然用户反馈这么重要,是不是每条都需要跟进?

答案也是否定的,给自动化一样,自动化很重要,那是不是所有项目都要做自动化?同理而已;

有一类产品,不需要做过多的线上闭环这么一个流程,是跟钱相关的,比如P2P,理财类;

为什么?因为用户的钱在你那里,再大的bug的,用户的也得忍受,而工具类产品不一样,比如新闻资讯类,有问题,换一个,很现实;

这也不代表用理财这类产品不需要管线上反馈,只是不需要做到那么细的地步,遇到线上问题,还是要处理的哦;
image.png-113.5kB

吧唧下线上跟进流程

谁没有过跟进线上问题的经历,下面就介绍下跟进线上问题的流程吧:
image.png-19.4kB

影响范围评估

QQ截图20181108135838.jpg-44kB
拿到问题,肯定是先要评估影响面,根据影响面的不同以及影响时间,采取不同的修复策略;

问题定位

QQ截图20181108140504.jpg-64.2kB

修复方案

QQ截图20181108140943.jpg-48.3kB

复盘

关于复盘,不想多说,可以来这看,之前写过一篇关于复盘的总结;

1629b91cb8d982d5-40kB

撒花

写了将近1天的时候,本来三指那块是重点,但是想着既然都要写了,就从一个大的角度去说说吧,对自己来说,算是巩固了这块的知识了,算一个知识回顾吧;

看到这里,感谢您的坚持,纯文字的文档,居然能坚持看到这里,兄弟,不容易吧;
image.png-32.7kB

小结

常规流程,来个小结;

  • 线上质量要重视,很容易造成用户流失;
  • 想做好质量管理,有两个环节:预防&测试分级;
  • 预防是依赖流程、工具进行约束;
  • 测试分级大致为:单元、接口、UI、性能、安全、自动化测试;
  • 了解持续交付,包括部署流程,线上监控等;

而质量管理优化,有以下三步:

  • 体系状况,分析梳理
  • 质量流程,优化设计
  • 质量规范,部署实施

剩下的,就是收集log的工作,大概思路如下:

  • 客户端具备生成日志且储存日志功能;
  • 客户端具备上传日志功能;
  • 客户端具备关闭上传日志功能;
  • 后台系统具备将上传日志进行问题排序且提供日志下载功能

接着就是安卓三指遇到的坑,总结下:

  • 研发的概要设计文档流程还是需要的,别以为只是一句话需求就不做了;容易陷入想当然;
  • event容易出现兼容性问题,厂商有可能做了定制处理,这块要切记;

题外话

以前见识到手淘的黑科技,具体链接忘记的,大致流程如下:

  • 用户遇到问题
  • 程序上传日志
  • 解析日志,转化成用户行为信息
  • 通过视频回放的方式观察到用户的操作场景

这样,就可以把用户的操作一览无遗,高级玩家高级玩家;
image.png-36.4kB

最后,欢迎大家一起探讨,毕竟一个人的力量是有限的,jb只是在无知的世界里漫游而已;

最后的最后,谢谢大家~
1-140R3154U8.jpg-9kB

共收到 26 条回复 时间 点赞

好长的文,部分内容好像在哪看过

xinxjxjxj 回复

质量管理优化那段,是在几年前原百度分享的质量管理文章里面加工生成的,所以看过的同学会有点印象😁

666,写的不错
不过听麻麻说,表情多的人,没对象……new也new不出来😏

槽神 回复

看楼主头像好像有小孩了😂

陈恒捷 将本帖设为了精华贴 11月19日 23:33

加精理由: 讲得很全面,而且语言幽默,挺吸引人

jb #7 · 2018年11月20日 作者
槽神 回复

哈哈哈哈,可惜早早已婚了,再也不用考虑new 对象这个问题了😏

jb #8 · 2018年11月20日 作者
踏雪之歌 回复

居然被发现了,低调低调😼

jb #9 · 2018年11月20日 作者
陈恒捷 回复

感动,人生第一个精华帖,看到测试相关还是要放testerhome才行,谢谢大佬

文章写的赞👍

但是这点完全不能同意啊 紧急情况优先考虑回滚啊,特别是在没有apm工具帮助你快速定位的情况,等你复现、定位、修复、测试、上线,黄花菜都凉了,时间就是金钱~
线上质量监控有待加强,APM能帮助你快速定位和主动发现问题,持续发布应该支持你快速发布和回滚

jb #11 · 2018年11月20日 作者
workhard 回复

上面写的,大部分是基于app产品考虑的,可能没说明,抱歉~!😂
对于APP来说,就没办法说回滚就回滚了,毕竟回滚是有成本的,对比回滚的成本,如果能马上解决处理上线,这成本比回滚要低;

一般来说,如果真出现严重线上问题,马上下架所有渠道包,马上止损,然后紧急安排处理,比如30分钟,研发搞不定,就主管上,尽快解决发patch处理;

当然,对于前端后端的话,马上回滚是最优的,解决后再重新上线,毕竟是灵活的嘛~

我居然完整的看完了。。挺有趣的。真实😂

jb #13 · 2018年11月21日 作者
回复

谢谢支持,写网文多了😂
看来以后测试的文章还是放这里好😢

有料、有趣 。

我大JB 要执笔出山了?

jb #16 · 2018年11月24日 作者
IDO老徐 回复

谢谢支持

jb #17 · 2018年11月24日 作者
lucios 回复

别闹,这里是随便发的而已

总结的很到位。

仅楼主可见
jb #20 · 2018年11月27日 作者

谢谢支持😁

jb #21 · 2018年11月27日 作者
白肥美 回复

以前在一家大公司,上面说的,基本都有,但并不是所有都是自己做;

关于质量管理体系框架,jb最近在做,只不过只是做乞丐版,就是定一下项目流程,后续会发出来,在大公司,这块也不会让测试来做,但是了解之后,总没坏处,说不定哪天转项目了,就需要了;

而日志埋点这块,有点争议,产品只关心打点日志,比如,点击搜索,PV+1,但线上问题的埋点日志,更多的需求方应该是测试,虽然能通过产品的打点来分析出用户行为,但需要N个表报的数据做整合,这样太麻烦了,如果项目各方都支持,直接把用户行为日志搞出来,是最好的~

写的很不错,涉及面挺广的,赞一个。

jb #23 · 2018年11月29日 作者
jeky2017 回复

谢谢大佬支持~

太长了,看了一部分,对于用户反馈的方法,就是release包进行埋点日志性能收集,跟友盟一样,只是外面收集的数据不一样。这样就可以监控发布版本问题及性能~我们目前就是采用这种平台来监控~

jb #25 · 2018年12月11日 作者
chenyouan 回复

好奇咨询下,release包进行埋点日志性能收集,本身这个操作会存在性能问题吗?是很轻量的?
如果很轻量,那是不是点击一个功能时就收集当时的内存等信息?

jb 回复

这个应该不会,很小的,是进行日志插桩记录反馈的,对APP的性能影响很小。如果很大的话,估计友盟会被干掉把~原理类似的~我们也是一直在学习改进中

jb #27 · 2018年12月11日 作者
chenyouan 回复

嗯嗯,谢谢反馈,学习了,原来的公司是自己做的,对于普通公司来说,友盟的确是一个不错的方向,省时省力

ivy520 [该话题已被删除] 中提及了此贴 12月16日 22:55
ivy520 定向班第一期_shell 课程实战_20181216 中提及了此贴 12月16日 23:53
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册