说明

本文以文字为主，会讲解到理论及具体工作思路，因当时没有保存代码，因此代码部分不贴，也懒得写了；

前言

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

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

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

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

日常骚操作

废话一大堆，来谈主题吧；

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

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

XX功能无法使用；
XX功能闪退；
XX功能充值不到账
复制代码

相信很多同学都会遇到这些问题，遇到问题别慌，这类问题一般都会有一套应急流程，因不同公司而异，这里只说知道的；

一般来说，线上反馈分两类： 紧急&非紧急；

紧急问题处理流程

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

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

大致上是说，就是这么一个流程；

非紧急问题处理流程

而对于非紧急的问题，一般如下：

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

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

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

这里做补充，回滚是最后的方案，这里更多的是指APP产品，因为对于APP产品，回滚是有成本的，如果能快速确认并解决问题，那通过热修复方式在线修改的成本远低于回滚成本；

如果是前后端的严重问题，需要考虑的是相关配套是否需要滚动，比如这个页面，其他功能是有依赖的，一旦回滚，那其他产品是不是也要一同回滚，这里需要做评估，如果是单页面\单模块功能，可以进行回滚并且解决完问题后重新上线；

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

一旦形成习惯，这类情况一般都会说，无法重现，完，然后没下文了，这也是测试日常的骚操作；

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

到这里，要知道一点，不能挑战用户，有用户反馈，就说明用户想这个产品越来越好，然而现实很残酷，他明明爱着你，但是你却不知道，舔狗不得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容易出现兼容性问题，厂商有可能做了定制处理，这块要切记；

题外话

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

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

这样，就可以把用户的操作一览无遗，高级玩家高级玩家；

最后，谢谢大家~