>>>对于UC浏览器内部的研发和测试流程，可能大部分的用户都不太了解。所以我想到了要找一期专栏，专门对UC内部的一些流程进行讲解，让大家了解一个版本是怎样出来的，一个问题是怎样被跟进的。这样就能减少大家由于相互的不了解而引起的不必要的误会，大家能更有针对性地给我们提出更多更好的建议和问题。
>>>在解答第一个问题之前，我们先来看看目前UC浏览器的开发模式。如下图是一个简化后的功能和代码分支管理，在实际的开发当中，要比这个图要复杂得多。

      >>>图中实线都为功能的开发分支或版本分支，虚线为版本发布分支。可以这么来简单理解：主干（trunk）是所有分支的根分支，所有功能的代码最终都需要回到这个分支上。在每个版本开始之前，比如10.4.0，各个规划在这个版本上实现的功能，都要基于主干开出一个开发分支来进行功能开发。为了保证主干足够的稳定，所有子功能的开发和测试工作都要在开发分支上完成才能合回到主干。

      >>>在某个约定的时间点（图中的两个红圈）之前，所有要在这个版本上实现的功能，都需要完成开发和测试，合回到主干，然后开出版本分支进行后续版本集成测试和发布。

      >>>版本分支开出之后，内部会进行全功能测试。所谓全功能测试就是浏览器所有功能的测试，以验证新版本的代码没有对原有的功能造成不良影响。全功能测试之后，我们会发布内测。内测后会预留一至两天对内测上报的问题进行修复和优化，然后发布公测。一般来说，内测都是在UC论坛内测区进行（申请内测： http://bbs.uc.cn/thread-5142764-1-1.html），发行量是300至500。公测的话，我们会有不同的渠道，比较常用的是程序检查更新后台和UC浏览器右屏的“装机必备”，发行量在1万至5万不等。经过公测验证后，如果我们认为已经达到了发布标准，就会进行正常发布。

      >>>以上是一个版本的演进全过程。对一个功能来说，如果是一个小功能，则在分支上完成开发和测试即可回到主干。如果是一个大功能（如图的10.5.0功能A），则也会经历内测和公测的阶段（我们称之为分支内测和分支公测）。所以问题1的答案就有了：大家看到的这些不同的UC浏览器，主要是不同阶段的UC浏览器版本。那么如何分辨这些版本呢？我们在UC浏览器帮助页面的底下，可以看到UC浏览器带有大版本号和小版本号——大版本号是指10.4.1.576这种，而小版本是build时间前面的那一串英文（如ucrelease）。大版本号一样，子版本号不一样，说明他们的父节点是一样的，只是属于不同的分支。

      >>>大家想知道一个版本是正式版、公测版还是内测版，只要看小版本号就可以了：正式版的小版本号带有release字样，公测版带有trial字样，而内测版则带有alpha字样。另外，如果是主线版本，小版本号后什么都不带，或者只带数字（如trial、release1等）。而分支版本则在小版本号带上一定的差异化标识（如trialvideo、alphanovel等）。

      >>>从上图还可以看出，分支版本都是单独开发的，所以同一个版本的分支之间并无包含关系。比如，15号的一个视频分支的公测，并不会包含10号小说公测的功能。但是在后面的主线版本公测，则会包含所有分支的功能。不过，也有例外，就是我们认为分支的内测和公测效果不理想，达不到上主线的要求，则暂时不会上到主线。而是继续在分支进行优化，直到达到效果后才会回到后面的主线版本中。比如之前有人使用过带有语音搜索功能的公测版，但在10.4.0正式版上却看不到这个功能，就是这个原因。

      上面已经说到UC内测的一些研发和测试过程，其中测试过程是由不同类型的测试组成，包括有分支测试、主线测试、内测和公测等。可能大家还是没有什么概念，我们一起来看看具体是怎样做的吧：

内部测试，按阶段主要可以分为分支测试和主线测试：
一、分支测试
      很好理角，就是指在分支上面的测试，主要为针对单个功能的测试。比如这个分支是专门做字体功能的，那么在这个分支上，就主要针对字体的功能来测试。包括字体的下载、更换、显示等等。所有发现的问题都会被记录在bug管理系统上，研发人员会根据问题的优化级进行修复。理论上在分支功能要回归主线前，所有的bug都需要被修复。但如果有些问题找不到复现路径，或者由于客观原因暂时不能修复，则通过内部评审后，放在后面再来修复或者关闭处理。

二、主线测试
上面已经说过，主线测试是该版本的集成测试，会测试到这个版本所有的新功能，以及集成这些新功能后，旧功能是否受影响。主线测试上发现的问题同样要上报到bug管理系统，在内测、公测和发布前，同样需要经过研发、测试、产品三方评估才能发布。
按类型来分，内部测试可以分为功能测试、性能测试、稳定性测试、兼容性测试等等。
1、功能测试
很好理解，就是从逻辑和体验层面对程序进行测试。验证程序的实现是否与需求规划的一致，在异常情况下是否会产生不可预期的行为等等。

2、性能测试
我们平时说的内存占用、流畅度、耗电量等都是性能测试的一部分，在内部统称为核心数据测试。在每个版本发布之前，我们需要通过对比的方法，测试新版本与旧版本之间的性能差别。经过长期的演进，这部分测试目前已经基本实现自动化，所以得到的数据会更加客观。如果新版本性能比旧版本差，则不允许发布。以下是性能测试报告的一部分。

三、稳定性测试
所谓稳定性测试，是通过长时间运行程序，以及向程序施加极端的测试条件，验证其是否会发生崩溃。来过UC的小伙伴们都知道，我们专门采购了一批（大概有几十部）手机专门用于稳定性测试。以下是我们专门做稳定性测试的实验室，由大神@liuxinlustar提供。

四、兼容性测试
我们知道安卓是一个开源的系统，它本身就有1.x至5.x等多个版本。然后各个厂商也会根据自己需求对ROM进行改造。所以虽然都是安卓系统，但不同手机之间可能会有或大或小的差别。为了保证广大用户能正常用上UC浏览器，我们需要在发布前对同一个功能在不同的手机进行测试。以下是我们目前拥有的测试手机，可以看到已经超过了2500款。注：1、这里是包含全平台的手机，Android系统的手机应该占了五分之一以上。2、这些手机全分布在不同的功能组里面，所以不是说所有的功能都会在全部手机上测试。

五、为了保证质量，我们需要做得更多
1、每日自动化功能测试
每晚12点，我们的自动化测试程序会自动基于最新的代码打一个包出来，按照我们事先设定好的测试用例进行测试。第二天早上上班，我们的第一件事就是查看昨天晚上的自动化测试结果，如果有测试用例不通过，则会马上进行修复处理。以下是一份自动化测试报告的样版。

2、内部有爱版
可能大家都知道，国外很多IT公司都有自己内部使用的每日构建版本——项目内每个人员都使用这个版本，发现问题及时反馈和修复。国外的公司一般把这种版本称为“Dog Food Build”。而在UC里，我们称之为“有爱版”。因为“有爱”是UC的公司企业文化之一。参加过内测的同学都知道，我们的内测版已经集成了“啄虫精灵”，上报问题非常方便。而在有爱版上，我们也集成了“啄虫精灵”，不过有爱版上报的问题直接是进入bug管理系统而不是UC论坛。迄今为止，我们已经推送了超过400个有爱版本，通过“啄虫精灵”上报的问题或建议已经超过1500个。

说到这里，可能会有人问：为什么你们进行了这么多测试，到用户手中还是会有这样或那样的问题呢？
我们先来看两张来自友盟（http://www.umindex.com/）的图片，第一张图片是目前市场上的主流厂商统计，第二张图片是以华为为例，展示其在市场上的top机型统计。

从这两张图片，大家可以看到安卓的碎片化是多么的严重——我们可以看到第一张图的“其它”是很大的一块，可能包含了成百上千个品牌。从第二张图片，我们可以看到同一个版本下面又有N多个机型。
在上面的厂商、机型，然后再加上各种ROM、网络环境和用户数据的不同，得到的组合就是无穷的了。相信看到这里，大家也明白了上面那个问题的答案——因为人力和时间的原因，我们无法穷举所有的场景进行测试，所以不可避免地到达用户手机还是会出现兼容性问题。所以大家碰到问题的时候，建议客观地上报问题的情况就好，没必要加上愤怒、冷漠和吐槽，因为这些对解决问题本身并没有任何的益处。

因为我们已经知道内部测试无法穷举所有的用户场景，所以我们非常重视来自于用户的反馈。为此，我们也付出了巨大的努力：
1、首先，我们有强大的客服团队，在意见反馈平台、微信、微博、电话热线等渠道收集和解答大家的问题。一经发现有大批量反馈的问题，会马上通知技术人员进行处理。同时，对于常规的反馈，客服同学也会有专门的日报和周报，把用户的重点反馈整理出来，知会到各方人员；

2、我们自己对用户反馈也有强大的自动化监控，一旦设定的条件成立，马上会有告警邮件和短信发出来，第一时间去处理；

3、我们认为新版本发布后的第一周是一个重要的阶段，我们会严密监控这段时间内的问题反馈，一旦发现多用户反馈的问题，马上会采取行动。比如之前愚人节的小丑头像，我们就提前将其下线了。另外，对这一周内的问题，我们也会整理成报告，和上个版本进行对比，以便观察用户对这个版本的接受程度。

写在最后的话：
本来不想多说了，但是为免部分相熟的老用户不爽，就最近部分用户在论坛发的牢骚，我这里再统一表明下我个人的立场，之后不再单独解释（而是希望聚焦在问题和建议本身）：
      1、从反馈量来看，论坛的反馈只是占了问题和建议反馈很小的一部分。但我们知道论坛上的都是资深用户和重度活跃用户。所以我们非常重视论坛用户的反馈，为此也在论坛的建设投了不少人时间和精力；
      2、我们认真对待每一个用户的每一个反馈，并不能代表每一个用户的反馈都能在产品上直接体现出来。我们每个月收到的用户反馈有数万个，无论是时间还是人力，都无法做到全部在产品上体现出来。而且还有另一个重要原因是，因为每个人的产品观不同，操作习惯不一样，导致这些用户需求本身就是有相互冲突的。比如“保存网页”这个功能，一部分人认为这个不是常用的功能，不应该内置。而另一部分人认为这个是非常重要的功能，且属于浏览器的基本功能，不应该做成插件。UC是一个拥有4亿用户的app，任何一个小小的改动，影响到的用户基数都不会小。所以产品经理作出的每个决定都是不容易的。我们相信大家提的建议都是自己内心的真实诉求。但是否要在产品上实现，是要经过深思熟虑的。我自己也是一个对产品有“洁癖”的人，对任何一个app，增加了我不喜欢的功能，我就是一直不会升级。比如有某个计帐的app，非常好用。我认为记帐是个人的私事，做个云端备份就差不多了。但它们一个新版本把在线讨论和在线理财也加了上去，个人非常难以接受。但我理解，一个产品要做大，要继续生存下去，必须要有自己的商业模式。所以我把我的意见反馈给他们，然后就再也没有升级过了。我说这点，并不是希望大家效仿我，而恰恰地强调后面一点，希望多点换位思考。再说回到内部，我不是产品经理，我提过的很多我自己认为有价值的产品建议也被产品经理无情地拒绝。但我还是支持他们的决定的，因为他们是第一决策者。其它大家都想把产品做好，只是大家的想法不太一致而已。所以没有人故意作死的，产品作失败了，对我们有什么好处呢？
      3、有一些问题，可能反馈有些时日了，仍然没有修复。主要有三种情况：A、问题本身不属于UC的bug，无法从UC侧修复。比如有些网站排版异常，是因为他们的写法不合理所致（或者是适配IE所致）；B、有部分问题，虽然存在不合理性，但路径较偏，影响的用户不多，而且修复成本较大（修复这个问题可能会导致更多的未知问题），所以暂时不去修改；C、由于项目时间有限，有新功能需要开发或有其它更严重的bug要修复，部分低优化级的问题会被安排至后面的版本中去解决。