下载掌阅APP，畅读海量书库
立即打开
品质管理分为两大类，即研发品质和线上品质。
研发品质： 包括品质体系（性能指标+用户评测）、测试过程数据（Bug、通过率）。
线上品质： 包括线上数据、用户反馈、漏测率。
品质体系，除产品本身的特性功能外，还包含流畅度、内存、耗电量、启动速度、弱网络等功能，是用户体验能感知或者影响用户口碑的。同时需要思考各个指标的比重（主要考虑对用户的影响程度），这样可以更好地优化核心指标。
线上品质，研发品质的指标都可以通过预设在被测App里的埋点上报上来，这样就有了线上数据。用户反馈主要是通过各反馈渠道收集用户的反馈信息。通过对用户反馈信息的分析，可以得知哪些问题是应当提前发现而漏出去的。漏出去的问题有些可能是因为测试工程师测试设计覆盖不全导致的，有些可能是因为开发直接修改没经过测试引起的，有些可能是运营活动引起的。
上面提到了品质体系，那么具体的产品品质如何衡量？很多公司都以Bug来衡量，除Bug外，还有一些指标大家会用到，例如代码质量、代码覆盖率、测试过程数据。性能指标、用户评测、用户反馈和线上数据。具体解释参考如下。
· 代码质量： 指静态代码扫描、架构评审、代码规范、代码评审。
· 代码覆盖率： 指行覆盖、类覆盖、条件覆盖、分支覆盖。
· 测试过程数据： 指测试通过率、回归通过率。
· 性能指标： 指启动时间、响应时间、内存、流畅度（FPS）、CPU、耗电量。
· 用户评测： 指产品进行用户调研、用户体验、用户问卷调查等。
· 用户反馈： 指用户反馈的问题或者建议。
· 线上数据： 指上线后的产品数据，如启动时间、用户行为数据。
·Bug：指Bug模块分类（FT分布）、Bug各研发阶段数据、Bug分析。
对于产品度量，腾讯各产品的度量方式也各有特色，图1-4所示是浏览器品质体系的一小部分，仅供参考。
图1-4 浏览器品质体系（部分）
关于产品品质的衡量，不少公司还是以Bug来衡量的，下面先重点介绍Bug维度。
引用Elisabeth Hendrickson在文章《BETTER TESTING-WORSE QUALITY？》中的图来说明“质量”的相关概念，如图1-5所示。
图1-5 Bug分析模型
图1-5中左边的三部分是跟Bug相关的，分别是“已知Bug”“未知Bug”和“预防Bug”，右边两部分分别是开发质量工作和测试质量工作。
· 开发质量工作： 涉及架构评审、代码规范、代码评审、单元测试、开发自测等。
· 测试质量工作： 需求评审、用例设计（利用测试建模、测试分析等方法来提升测试设计覆盖度）、自动化测试（BVT或者接口测试等）、性能测试、精准测试、探索式测试、基于风险测试（RBT）、Bug大扫除、Bug分析、Bug统计、众测等。测试质量工作涉及的内容很多，可以考虑再抽练几个分类，如图1-6所示。
而这些测试质量工作的开展还需要借助一些平台和工具才可以更高效地完成，如图1-7所示。
测试质量工作除品质体系外，还包含工程效率。对于工程效率，测试团队一般围绕两个主题来开展：测试效率提升和可测性扩展。
· 测试效率提升： 可以通过项目流程的规范、测试方法论应用、自动化测试的应用等工作，从而更高效地达到工作预期。
图1-6 测试质量工作分类
图1-7 测试平台和工具
· 可测性扩展： 可以联合开发做一些可测性提升的工作，例如接口暴露、代码解耦等。当然，也可以尝试覆盖更多没有覆盖的内容，例如有些项目终端类测试开展不错，就可以考虑加强后台接口的覆盖；还有黑盒类测试，可以考虑白盒类测试或者灰盒类测试等。
总的来说，测试质量工作一方面是做得更快，另一方面是做得更多。
通过上面对各个模块的分析，我们再把上面提到质量保证的各项工作映射到Elisabeth Hendrickson的图上，如图1-8所示。
团队成员在测试过程中发现的Bug（包括但不局限于Code review、show case、dogfood、测试发现的Bug等）。这些Bug一般都会记录到Bug系统中（例如腾讯的TAPD），这样就可以方便进行分析，例如Bug分布模块（浏览模块、支付模块、个人中心等）、各FT的分布（有可能跟模块有关联）、各研发阶段（迭代、集成、上线前等）、严重级别等。通过对Bug系统性分析来评估待发布产品的质量风险，这样可以给予决策者更好的数据支持。当然，有些Bug是可以挂起的，不一定所有都需要修复。
图1-8 Bug分析及测试工作模型
产品发布之前未发现的Bug，发布后通过海量用户反馈的问题或者通过统计埋点上报的问题。因为用户的机型网络以及数据环境等因素可能触发潜在Bug（而这些Bug是整个团队研发过程中很难出现或者偶尔出现漏过的），借助海量用户可以放大出现的概率，然后用户主动反馈或者被动埋点上报可以收集到这类潜在Bug。
一般产品里都有用户反馈意见的入口，通过这个入口可以收集用户使用过程中的问题或者意见。同时有些产品会对某些关键逻辑路径进行埋点，这样，只要用户使用过程中触发这个埋点，就会自动上报到后台。主动上报的数据就可以进行统计分析，这类数据统计可能区别于用户行为的统计，更多的是某个逻辑或者路径的上报。针对这些上报的数据进行数据挖掘，可以帮助发现某些问题最有可能出现的场景，进而可以再结合众测用户进行重现，最后解决这些问题。
主要通过一些流程或者机制充分体验产品，提前发现一些潜在Bug，例如通过需求评审、Showcase、DogFood等手段，全员积极参与各阶段产品的体验，就可能提前发现一些需求问题或者设计问题等。
· 需求评审： 需要各方角色（产品、开发、测试、PM、设计等）都能投入精力讨论PK，这样可以提前把不合理的需求扼杀在摇篮中。
·Showcase：各个迭代完成后，PM可以组织各个角色参与体验，尽早发现潜在问题，例如某些设计问题或者体验上的问题，快速返工，避免后期返工带来更大的人力消耗。
·DogFood：通过持续集成编译出版本后（有重点需求说明），发送给团队各成员体验，及时快速发现问题。这里更强调产品质量需要全员的参与。
质量工作涉及方方面面以及各个角色，同时必须考虑人力、时间等因素，还得考虑项目的市场竞争状况，这样才能平衡好以上各项措施的选择。