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