内容简介:本文以文字为主,会讲解到理论及具体工作思路,因当时没有保存代码,因此代码部分不贴,也懒得写了;这篇文章修改很多次,各种推倒重写,原因是,一开始只想写自己做过的东西,但是写着写着,觉得太局面,因此想换个大点的角度,能力有限,写的不好或不够,欢迎讨论;去年8月份,做了线上问题跟进的事情,持续到去年年底,后来因进度问题,以及采用的底层方案有点问题,就让研发负责了,从某种意义上,这是第一个完全自主负责的项目;
本文以文字为主,会讲解到理论及具体工作思路,因当时没有保存代码,因此代码部分不贴,也懒得写了;
前言
这篇文章修改很多次,各种推倒重写,原因是,一开始只想写自己做过的东西,但是写着写着,觉得太局面,因此想换个大点的角度,能力有限,写的不好或不够,欢迎讨论;
去年8月份,做了线上问题跟进的事情,持续到去年年底,后来因进度问题,以及采用的底层方案有点问题,就让研发负责了,从某种意义上,这是第一个完全自主负责的项目;
整个项目对于Jb来说是个挑战,同时是一个明显的成长点,后来找工作面试的时候,很多企业对这个感兴趣,问的东西比较细,到现在为止,依然很感恩有这个机会;
一年后的今天,如果要问自己,同样的问题,有没有更好的解决方案?目前来看,没特别的想法,总感觉今年在测试这方面,有点退步了,毕竟今年都在不务正业;
日常骚操作
废话一大堆,来谈主题吧;
相信每一位测试&研发,都会有这日常工作: 跟进线上问题 ;
无论是PC、M端、小程序,只要是面向C端的产品,发布后,肯定会有用户反馈问题;
XX功能无法使用; XX功能闪退; XX功能充值不到账 复制代码
相信很多同学都会遇到这些问题,遇到问题别慌,这类问题一般都会有一套应急流程,因不同公司而异,这里只说知道的;
一般来说,线上反馈分两类: 紧急&非紧急 ;
紧急问题处理流程
一般的 紧急问题 处理流程如下:
- 客服/运营收到线上反馈,且短时间内呈现明显上涨;
- 通知项目经理/测试/研发,测试尝试重现难问题,研发同步排查代码;
- 能重现问题/研发知道原因,解决问题;如果重现不了,研发排查差不出问题,尝试联系用户及动员更多的同学一起重现,尝试重现;
- 确定解决问题方案(回滚代码/紧急线上处理,APP则hotfix或重新提交各商店),内部验收
- 问题上线后,监控/及时回访用户,观察是否已经解决问题;
- 分析产生问题的原因,总结;
- 复盘,后续如何规避;
大致上是说,就是这么一个流程;
非紧急问题处理流程
而对于 非紧急 的问题,一般如下:
- 客服/运营收到线上反馈,先确认,标准下不同问题的重现情况;
- 定时整理,比如一周,反馈到测试&项目处;
- 测试确认,如果是能重现,报Bug给开发,根据问题严重程度,酌情排期;如果不能重现,也先报Bug,列为观察问题,后面3个版本留意下是否有类似问题或是否能重现,如果一直不重现,关闭观察处理;
- 问题解决,测试通过,安排版本上线,同时反馈到客服/运营处,安排进行用户回访;
- 定时关注线上数据,确保问题已解决,并且及时邮件通知最后的结果;
基本上,这两套流程就能用了,很普通的流程,尤其非紧急流程,内部反馈问题也大概是这样,只是内部反馈,可以及时要现场重现;
一般来说, 紧急情况,如果实在找不到解决方案,回滚是最后的方案;
而对于非紧急情况,现实往往是测试折腾半天,无法重现,然后放一边,毕竟工作繁忙,而且反馈的问题也比较多,没可能过多投入;
一旦形成习惯,这类情况一般都会说, 无法重现 ,完,然后没下文了,这也是测试日常的骚操作;
其实从用户角度想想,蛮累的,之前简单统计过,用户主动反馈问题的比例是万分之一,而这万分之一的用户反馈问题过来,测试却说,无法重现就完了,而且也没个交代,犹如石沉大海一般,很打击积极性;
到这里,要知道一点,不能挑战用户,有用户反馈,就说明用户想这个产品越来越好,然而现实很残酷,他明明爱着你,但是你却不知道,舔狗不得house;
吹下理论吧
上文得知,一条用户反馈来自不易,那如何有效利用用户反馈,以及把没反馈的用户也利用起来,就是需要思考的问题了;
需要注意, 用户不反馈问题并不代表没问题 ,也许用户想反馈问题直接crash了,无法反馈,或者有问题模块不影响用户日常使用,jb也是用户,看到软件有bug,懒得反馈,反正可替代品那么多,不行就换一个罗;
上面说到的,这里都不介绍,主要想说说自己对质量保障的看法,可能比较片面,但是想增加对线上质量的关注;
目前整个质量环节大致是这样:
- 研发阶段,通过研发自测、概要设计评审等手段尽可能提高交付质量;
- 测试阶段,通过用例评审、丰富测试手段(探索性测试等)来验收产品;
- 灰度验证,快速验证产品上线是否存在严重问题;
- 问题修复,线上问题快速定位、修复;
当然,上面说的只是大致环节,还有很多小环节没有暴露,比如上车检查(代码检查)、monkey、核心数据、集体试用等环节;
看到这里,不得不问,如何在敏捷项目中做好质量管理?
质量管理是一个大环节,并不单单是测试找bug,而是贯穿项目立项到结项整个过程,比如产品文档规范等都是一环,比如,产品文档模棱两可,研发测试也没有核实,结果成品跟产品要的效果不一致或者有很多BUG,导致项目延期;
怎么做好质量管理,目前想到两个环节: 预防 & 测试分级 ;
预防
预防,在项目初期就可以有一定的计划,让项目避免出现已知或可能出现的风险。 提前规避,是检验项目经理对整体项目把控程度好坏的重要考量标准。
而定期检查和调整是保证产品质量的关键,定期召开评审会/晨会,及时同步信息,在此显得尤为重要;
那研发侧怎么预防?目前大众的方案就是静态代码检查、lint、代码覆盖率(jacoco较多),从以往经验来说,静态代码、lint的检查,能发现不少编码、性能问题;
测试分级
一般说的测试,大部分指功能测试,但是靠功能测试,不足以保障质量,因此需要对测试进行分级,拆分出更细的测试维度;
- 单元测试,不说,白盒测试的一种,即使大公司也不一定会做,小公司简直别想;
- 接口测试,保障业务逻辑和后台质量,常用是postman,输入输出,看输出是否跟接口文档要求一致,更进一步,去数据库修改数据,来校验后台处理逻辑是否正常;
- UI测试,保障到C的体验跟交互;
- 性能测试,保障整体业务性能和稳定性,满足大环境需求;**常见的性能监控有稳定性、启动速度、卡顿率、流畅度、内存、耗电、流量,服务器的话,就是CPU、内存、IO、并发用户数、响应时间、事件成功率、超时错误率,**可能有遗漏,欢迎提出补充;
- 安全测试,保障系统安全性;比如涉及到下载,需要考虑到劫持场景,充值功能,需要考虑网络传输是否加密以及是否有破解方式;
- 自动化测试,主要是用户回归测试和常规验证,比如某些配置项、主路径功能等;
自动化验证和持续交付
互联网的节奏非常快,想在高强度的氛围保障质量,是一件很有挑战性的事情,换个角度,是否有不需要测试就可以直接上线的情况?
如果想达到这种情况,要做什么?
这个话题就更大了,jb也还在学习ing,但上面有提及到,静态代码检查、看研发代码等,除此,代码覆盖率、自动化都是提高质量的一环;
但有一点是肯定的,要做这块,必须要懂代码,记得前前前老大跟jb说过一句, 好的测试,编码能力应该要比最差的研发要强;
上面说的都是台前,那我们也要关注幕后,因为质量并不是一环;
那幕后有什么?打包效率、提测质量、上线部署、线上质量监控,这里不像详细说明,直接贴一个图;
从性价比看,发布部署是性价比最高的,直接弄个jenkins,写点具体发布脚本即可,收益是最高的;
别少看 打包效率 这类问题,一人打包10分钟,2人打包20分钟,如果提高到5分钟,那1人就节省5分钟,100人就节省500分钟了,亲身经历,这类问题不能轻视;
其他的提测质量、线上监控,都是很大的点,这里不说;
质量管理优化
不管什么公司,多多少少都会有不同的问题,只是,在大公司里面,往往通过协助平台、流程规范等方式把问题解决或屏蔽,但是在小公司,问题就会暴露出来;
做质量管理不容易,需要强大的内心,而且,公司资源向你倾斜,只有这样才能真正推行,否则如石沉大海;
遇到问题,不要慌,这里介绍三步走:
体系状况,分析梳理
古人云:工欲善其事,必先利其器,想优化,必须得先知道病在哪里,那不妨从以下几个维度去了解问题;
- 了解公司总体业务现状
- 了解各业务产品应用架构、技术架构、团队组织架构及分工配合情况
- 了解业务和产品需求以及未来发布规划
- 收集核心业务质量现状数据,明确需要优化的方向,优先级,排期处理;
-
- 研发流程现状数据
-
- 产品质量问题数据
-
- 测试质量问题数据
-
- 质量流程问题数据
-
- 团队协助问题收集
- 诊断分析并找出问题根源(流程、方法、标准、 工具 、协助、规范等)
- 根据以上的问题以及具体原因,初步给出一个改善建议的且可行的优先级;
质量流程,优化设计
上面给出了初步改善建议,那接下来就要规定流程,针对具体问题制定规范,明确每个职能部门的分工;
- 确认目标,即做质量前后有什么变化,要解决什么问题;
- 根据上一轮诊断信息和优先级顺序,进行优化方案设计
-
- 团队角色及分工定义
-
- 基本流程定义
-
- 流程相关工具平台选择,比如UI用A工具设计,测试报bug用B平台等,确保统一
-
- 初步质量目标和模板定义
-
- 选择试用产品/项目和推广顺序
-
- 实施计划和风险分析
- 方案讨论,修改,然后跟具体大佬沟通,得到认可后推行
- 组织团队培训,敏捷思想和方法
质量规范,部署实施
定下规范,就去试试吧;
- 关键环节控制流程部署和实施
-
- 需求跟踪
-
- 测试设计
-
- 研发编码、提测
-
- 发布验收
- 全面流程管控和标准化
- 建立自动化测试平台体系
-
- 接口测试
-
- UI测试
-
- 性能测试
-
- 安全测试
- 构建持续集成和持续测试
- 质量保障持续优化机制建立
业界也有个词,叫 测试左移 ,简单说,就是让测试提前介入所有流程:
- 需求评审,测试必须对业务熟悉;
- 技术方案评审,测试能读懂和理解技术方案,凭丰富的经验或者嗅觉,挖掘技术方案不足的地方,比如业务场景的可扩展性,业务量大幅增加后的性能问题、可测性;
- 测试用例和业务编码并行,包括接口测试用例、功能测试用例,准入标准,功能都无问题,回归脚本全部通过;
- 单元测试质量,除了保障代码覆盖率之外,还要检查UT代码的有效性;
- 静态代码分析,有能力则协同开发一起保障代码质量,或者引入第三方工具,准入标准,没有严重级别的问题
- 代码审查,同需要代码能力;
- 测试用例评审,提测前组织产品、研发、测试一起完成,提测后直接使用;
- 冒烟测试,提高提测质量,要通过冒烟才能提测,准入标准,比如没有主路径问题;
更详细的,自行上网查询;
大家怎么玩
上面啪啪啪的一大堆废话,本文的重点在于线上质量,那就聊正经事情吧;
问题一般分两类, 性能问题、功能问题 ,体验问题不算在这里;
性能问题能通过一定的规则来抓取,比如获取当前APP的内存,是比较固定的内容:
- 定时查询统计
- 有问题直接落地生成log
- 日志回传到服务器
- 服务器解析日志,做聚合统计入库
- 前端查询展示数据
那,在跟进线上反馈的时候,到底遇到什么问题?
- 联系上用户,但因各种问题 ,问题没法跟进了或者需要的log拿不回来,怎么办?
- 压根联系不上用户,怎么办?
记得是在去年2月份,上testerhome发帖子问,幸运得到部分大佬答复,看到的方式有2种:
- 部分企业有大量log(用户行为日志),通过log分析出用户行为,然后内部排查问题,发现是问题处理,不能发现的,线上增加埋点log;
- 内部重现,如不能重现,则联系用户,给各种调试包等,联系不上的,放弃;
很不好,当时就是处于第二种,只是觉得,即使是联系不上的用户,也不能浪费;
怀着这份激情,跟老大反馈多次,逐渐的,老大们也开始关注到这块,因此就立了个专项,让jb去负责处理这个事情,因此,这个事情的开端就是: 如何跟进线上问题;
这里更多指的是,无法联系,或者联系了重现不了之类的用户;
既然大家都是 依赖log 来玩,那我们也这么玩吧;
题外话:虽然很不喜欢处理线上反馈,但遇到暖心的用户真的很感动,幸运的是,jb遇到不少,远程各种协助跟进问题,好人还是不少的;
独乐乐不如众乐乐
既然问题核心是没有log,导致无法跟进问题,那换个角度,有怎样的log才能跟进问题?
因此,有了以下的内容:
- 当时产品里面有很多收集性能日志功能,比如卡顿、内存、启动速度,只是都不会在release版本开启,因为收集日志本身存在性能问题;
- 那用户行为日志是不是也可以跟性能日志一样收集?
- 但是,不在release版本开启,做了也没意义,那,有没有办法做到在release版本开启这些日志功能?
- 如果支持release版本开启,那怎样的日志内容能满足不同业务进行跟进问题?毕竟不同业务需要的日志内容不一样;
- 日志什么时候保存?保存在哪里?什么时候回传?回传到哪里?回传到怎么处理?
这就是第一期的目标- 发现问题 ;
上面的问题如何解决?
Q:如何在release版本开启收集日志功能?并且支持动态关闭?
A: push ,产品本身支持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拉取日志;
至此,第一阶段,发现问题,到此结束;
看看干了啥
既然有日志了,那对于测试同学来说,比较方便了,如果没记录,问题解决率在30%左右,看上去觉得很低,但实际是因为,很多功能研发还没埋点,算是一个不错的效果;
点对点的问题解决了,那点对面了?从项目的角度,想知道线上什么情况,怎么搞?
因此专项第二阶段就是 监控问题 ;
其实,监控问题,没有太多的内容可以说,无非就是把日志如何解析,聚合,数据处理再显示而已,最终的效果就是,点击某一个版本,选择某一个模块,就可以知道这个模块收集到的日志排名,研发根据这个排名依序解决问题就好了;
换种方式踩坑
做完上面2个阶段,时间到了10月初,期间从立项,方案,调研,编码,灰度,推行都花了不少时间,尤其在推行这一环节,要有具体数据来吸引业务方来使用,不然做出来没人用是很尴尬的事情;
这时候,既然产品有这样的功能,想让用户有意识使用,说白就是想增加曝光,有如下的想法:
- 新手引导用户
- 产品首页增加悬浮框告诉用户
- 简化用户反馈的路径(原有路径有3级,比较麻烦,业界大部分产品也类似)
但是1、2被产品经理打回,原因是,用户反馈这个功能不是每个用户都必须的,为了那点人而浪费一个新手引导位,不合适;
当时听到很不舒服,但是事后回去站在场景的时候思考,有点道理,打脸了吧~
那就想办法简化用户进行反馈的路径吧,经过思维的碰撞,内部觉得,在产品上三指长按一定时间弹出反馈界面,是一个不错的场景;
跟产品沟通后,产品觉得可以,那需求就为: 用户三指同时长按屏幕2S,弹出意见反馈页面;
从此,跌入深渊,自己给自己挖了一个大坑;
跌入深渊
需求很简单: 用户在app内使用三指长按屏幕2s,APP执行某操作;
挖坑
需求关键字: 三指,长按,2s,执行 (这不是需求原话么)
当时的处理逻辑是这样的:
- 判断用户手指个数
- 如果是3个,设置一个runnable 2S后执行
- 执行时再判断用户手指个数
- 如果还是3个,执行操作A,over
(懂的大神已经笑了~)
当时信心满满的上线后, 发现使用的uv\pv都非常高 ,非常不合理,因为app上没有功能引导,用户也没有三指的行为习惯,所以 肯定是出bug 了;
跟进这问题2个步骤,
- 看用户反馈,结果上千条反馈,都没有一条相关反馈,那是否可能是打点问题?
- 查看统计代码,也没发现异常;
问题到底在哪里? 新增了用户的场景统计,发现部分用户 在色情网站会连续出现打点 ,本地尝试没发现问题,就让其他同学帮忙用用,结果发现问题了!!(一个人的力量是有限的,理解也是有限的~)
原来用户是 有多指(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,其实还有区别,但是被系统强奸了。。)
处理方案讨论了好久,也好了好多大神沟通,纷纷表示没办法,毕竟是操作系统返回的,你能怎么办?话虽这么说,但是后来还是针 对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的,用户的也得忍受,而工具类产品不一样,比如新闻资讯类,有问题,换一个,很现实;
这也不代表用理财这类产品不需要管线上反馈,只是不需要做到那么细的地步,遇到线上问题,还是要处理的哦;
撒花
写了将近1天的时候,本来三指那块是重点,但是想着既然都要写了,就从一个大的角度去说说吧,对自己来说,算是巩固了这块的知识了,算一个知识回顾吧;
看到这里,感谢您的坚持,纯文字的文档,居然能坚持看到这里,兄弟,不容易吧;
小结
常规流程,来个小结;
- 线上质量要重视,很容易造成用户流失;
- 想做好质量管理,有两个环节:预防&测试分级;
- 预防是依赖流程、工具进行约束;
- 测试分级大致为:单元、接口、UI、性能、安全、自动化测试;
- 了解持续交付,包括部署流程,线上监控等;
而质量管理优化,有以下三步:
- 体系状况,分析梳理
- 质量流程,优化设计
- 质量规范,部署实施
剩下的,就是收集log的工作,大概思路如下:
- 客户端具备生成日志且储存日志功能;
- 客户端具备上传日志功能;
- 客户端具备关闭上传日志功能;
- 后台系统具备将上传日志进行问题 排序 且提供日志下载功能
接着就是安卓三指遇到的坑,总结下:
- 研发的概要设计文档流程还是需要的,别以为只是一句话需求就不做了;容易陷入想当然;
- event容易出现兼容性问题,厂商有可能做了定制处理,这块要切记;
题外话
以前见识到手淘的黑科技,具体链接忘记的,大致流程如下:
- 用户遇到问题
- 程序上传日志
- 解析日志,转化成用户行为信息
- 通过视频回放的方式观察到用户的操作场景
这样,就可以把用户的操作一览无遗,高级玩家高级玩家;
最后,谢谢大家~
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。