中国的速度举世瞩目，30 年完成别人 200 年的进程。IT、CT 行业从无到有，再到一流也就区区 20 年；BAT、TMD这些万亿或准万亿互联网公司和老美也能齐头并进。老J 想想就热泪盈眶，无比自豪，毕竟作为大佬背后的男人，刷过抖音、打过滴滴、玩过网购，也在无数个深夜卖过加班体力。
蹭上这趟科技浪潮的老 J 也是摸爬滚打不容易啊！下过瀑布，趟过 V 型，干过 IPD，走上敏捷，最终顺上 Devops。遥想当年坚定地立下 Flag：“30 岁前，在上海买下属于自己的大平层”。如今实现了一半，30多了。
“质量就是生命！” 多么响亮的工业时代口号。放在现在也是如此得正确，市场经济大环境，用户 / 客户用脚投票，默默地离开不稀罕你送不送。用户流失、掉粉因为一个生产事故比比皆是。成熟的反托拉斯注定同类竞争一直会存在。只因这句话过时了，没有那么大的影响力了。
取而代之的是 “好、快、稳” 的三元论，虽然冲突，但可以平衡。励精图治，尝试过各种姿势的老 J 就来聊聊质量管理三板斧，助你打工搬砖既好，又快，而且稳。
1.测试自动化
测试、测试，就是测已知，试未知。已知部分可以结合业务场景，通过测试设计工程方法进行枚举覆盖，可复用的部分逐渐沉淀进入回归集合。常规执行无外乎手工、半自动和自动化三种方式（当下引入 AI 技术辅助测试执行逐渐热门，短期内常规方式仍是主体，AI 作为辅助手段）
其中，回归部分存在完全重复执行；新增覆盖场景难免有前置环境、数据、状态准备需求，存在大量的部分重复执行。人并善于重复性工作，得让机器做。
一来，重复行为会让人随着时间的推移，效率曲线会下降；
再者，既定的工作机器一定比人来的可靠；
最后，更多的探索性测试才是测试工作的高价值部分。
测试人员做“时间的朋友”。经验的累计在于分析业务逻辑、熟悉功能实现，探究应用场景为手段，而非重复性操作。避免陷入勤奋陷阱，1 年的经验重复 做上10 年。
测试自动化技术的发展离不开“分层测试”的概念。分层测试是典型的化整为零的思想，把复杂的系统拆解成宽耦合粒度，这样可以尽早介入进行验证的方法。
一般测试分层有：UT、后端（逻辑）测试、前端（交互）测试、集成测试、性能、稳定性、兼容性、安全等专项测试。其中：
- 接口测试自动化技术源于针对逻辑实现主体的后端的测试；
- UI 自动化测试技术源于端到端的测试，包括基于浏览器的测试以及移动端 UI 测试；
- 浏览器兼容性测试、移动端兼容性测试源于系统测试；
常见的测试工具 / 框架如下表所示：
测试自动化技术分门别类不算少，工具/ 框架成百上千也不在话下。如何实施是门学问，老J 给出自动化测试策略
- 关键路径，核心稳定场景优先实施；
- 接口组合场景为主，UI 为辅；
- 兼容性场景必做自动化；
- 前置条件可做半自动化
- 自动化测试平台化、服务化
关于左移精准测试、右移流量复制测试，以及 AI 测试技术将单独开一篇讨论。
最后，强调一点执行提效是手段，覆盖全面是目的。重复的操作自动化；更多时间进行探索性测试。
2.流程 & 规范
流程特指研发端到端全流程；规范特指质量相关规范。
流程的产生是为了“协同”高效，规范如“契约”明确流程中关键节点做到什么程度算到位。最终，是为了有质量地快。返工就是最大的浪费，一次把事做对不仅快，而且稳，它不香吗？
无论是哪种研发模式，瀑布、V型还是敏捷，最终都会落地到带有规范的流程至上。流程 & 规范作为研发模式的载体，在每个团队内都有不同的实践。这里着重提两点，也较为通用，分别是设置质量门禁（提测标准）以及准出核对（上线标准）。简单来说，流程靠卡点，卡点有规范。
1）质量门禁--门禁不把容易尴尬
越早发现 Bug 并修复成本越低，风险越低。想必大家都有共识，如下图 Bug 缺陷成本趋势图所清晰展示。越往后风险越高，形象的类比“蝴蝶效应”就很好理解。想想：
修改一行代码，影响功能能逻辑不说，还可能牵连到业务逻辑；
后期验证范围被主观锁定而产生遗漏，纵使有全量回归兜底，在临近上线前发现 Bug 修复引入的新 Bug 也是让整个项目很崩溃的消息；
最终，导致上线交付 Delay。
。。。你说是不是很尴尬？
缺陷成本曲线
与质量门禁相配套的提测标准包含哪些内容？
- 自测通过
- UT 覆盖率达到 xx%
- Code Review 意见全部回复
- 文档类，如设计文档、接口文档、配置、SQL等完备
- 跑冒烟用例集合（关键路径、影响模块抽样）
2）准出核对--上线前最后一次的“清单革命”
临门一脚，功亏一篑，谁都不愿接受。准出核对是上线前夕的兜底措施，更是团队所有成员的心理建设过程。褪去其保险功效，满槽蓝血就等运维小哥鼠标一点， 进度条 100 % 那刻的 Give Five！
[图片上传失败...(image-2b76b8-1611994813889)]
走你
与准出相配套的上线标准包含哪些内容？
- 依照测试策略，用例执行完成
- 需求覆盖率 100 %
- 无严重级别 Bug，缺陷趋势收敛
- 版本信息、配置、SQL信息正确
- 有回滚方案，且验证通过
另外，测试是个长周期活动，测试规范得过硬。除了上述提测标准、上线标准，还包括有：用例分层、用例管理、缺陷定级、测试报告、生产故障定级、RCA等等。详见：那些年要是知道这些 该有多好！
3.数据度量
管理学大师彼得-德鲁克说过：“无度量难管理”。
质量有没有变好？测试执行有没有变高效？测试是否是研发瓶颈？哪里需要改善？认知、沟通最低的方式就是通过数据说话。
当下，“数字化”是个时髦词，比如金融数字化、政务数字化、社交数字化等等。沉淀研发过程数据就是软件工程数字化。
当然，这里主要聚焦于质量数据方面，更广泛的研发数据与工程效能息息相关，比如 Devops ，老 J 另开一篇聊聊。
那么，如何做数据度量？可以分两步走：
- 第一步，沉淀端到端数据，甚至是过量沉淀，以备后用；（解决有没有的问题）
- 第二步，挑选当期关键指标进行重点提升 or 降低。（聚焦如何用的问题）
指标大致分为三类，外加排行榜，罗列了一些常用的指标，见下表。
相信，好的过程数据能促成好的结果。完备的数据度量能让每天上班感觉在玩“足球经理”（EA 早期出款的一部沙盘游戏）人生如戏，游戏人生啊。
文末总结
1、质量管理三板斧。测试自动化、流程&规范以及数据度量。
2、设置质量门禁，卡好准入标准，能让质量较早受控，避免项目运作的后续风险累计；上线前准出核对不但是最后一道兜底措施，同时能让团队积聚成功上线后的成就感，提升团队凝聚力。测试规范参见 那些年要是知道这些 该有多好！
3、“无数据，无管理；先度量，后决策”。对质量数据的度量能用相对客观的“语言”描述质量状况，最重要的是驱动改进，实现质量提升。而这种趋势是实打实看得见的。
-END-