公号:iammrlaoj,与老J 一起谈质效、聊职场、道管理、说八卦。

质量管理三板斧

上一篇 / 下一篇  2021-02-09 09:34:35 / 个人分类:管理



中国的速度举世瞩目,30 年完成别人 200 年的进程。IT、CT 行业从无到有,再到一流也就区区 20 年;BAT、TMD这些万亿或准万亿互联网公司和老美也能齐头并进。老J 想想就热泪盈眶,无比自豪,毕竟作为大佬背后的男人,刷过抖音、打过滴滴、玩过网购,也在无数个深夜卖过加班体力。


蹭上这趟科技浪潮的老 J 也是摸爬滚打不容易啊!下过瀑布,趟过 V 型,干过 IPD,走上敏捷,最终顺上 Devops。遥想当年坚定地立下 Flag:“30 岁前,在上海买下属于自己的大平层”。如今实现了一半,30多了。


“质量就是生命!” 多么响亮的工业时代口号。放在现在也是如此得正确,市场经济大环境,用户 / 客户用脚投票,默默地离开不稀罕你送不送。用户流失、掉粉因为一个生产事故比比皆是。成熟的反托拉斯注定同类竞争一直会存在。只因这句话过时了,没有那么大的影响力了。


取而代之的是 “好、快、稳” 的三元论,虽然冲突,但可以平衡。励精图治,尝试过各种姿势的老 J 就来聊聊质量管理三板斧,助你打工搬砖既好,又快,而且稳。



质量管理三板斧



1.测试自动化


测试、测试,就是测已知,试未知。已知部分可以结合业务场景,通过测试设计工程方法进行枚举覆盖,可复用的部分逐渐沉淀进入回归集合。常规执行无外乎手工、半自动和自动化三种方式(当下引入 AI 技术辅助测试执行逐渐热门,短期内常规方式仍是主体,AI 作为辅助手段)


其中,回归部分存在完全重复执行;新增覆盖场景难免有前置环境、数据、状态准备需求,存在大量的部分重复执行。人并善于重复性工作,得让机器做。


一来,重复行为会让人随着时间的推移,效率曲线会下降;

再者,既定的工作机器一定比人来的可靠;

最后,更多的探索性测试才是测试工作的高价值部分。


测试人员做“时间的朋友”。经验的累计在于分析业务逻辑、熟悉功能实现,探究应用场景为手段,而非重复性操作。避免陷入勤奋陷阱,1 年的经验重复 做上10 年。

 

测试自动化技术的发展离不开“分层测试”的概念。分层测试是典型的化整为零的思想,把复杂的系统拆解成宽耦合粒度,这样可以尽早介入进行验证的方法。


一般测试分层有:UT、后端(逻辑)测试、前端(交互)测试、集成测试、性能、稳定性、兼容性、安全等专项测试。其中:


  • 接口测试自动化技术源于针对逻辑实现主体的后端的测试;

  • UI 自动化测试技术源于端到端的测试,包括基于浏览器的测试以及移动端 UI 测试;

  • 浏览器兼容性测试、移动端兼容性测试源于系统测试


常见的测试工具 / 框架如下表所示:


测试自动化技术分类
工具 / 框架举例
UT Junit / TestNG
接口试自动化RobotFramework / HttpRuner 
UI 测试自动化
Selenium / WebDriver / Cypress
浏览器兼容性测试
移动端兼容性测试
F2etest / Macca / AirTest / Uiautomator
性能、稳定性测试
Jmeter / LoadRunner

注:工具形态千变万化,不做穷举。


测试自动化技术分门别类不算少,工具/ 框架成百上千也不在话下。如何实施是门学问,老J 给出自动化测试策略


  • 关键路径,核心稳定场景优先实施;

  • 接口组合场景为主,UI 为辅;

  • 兼容性场景必做自动化;

  • 前置条件可做半自动化

  • 自动化测试平台化、服务化


关于左移精准测试、右移流量复制测试,以及 AI 测试技术将单独开一篇讨论。


最后,强调一点执行提效是手段,覆盖全面是目的。重复的操作自动化;更多时间进行探索性测试。




2.流程 & 规范


流程特指研发端到端全流程;规范特指质量相关规范。


流程的产生是为了“协同”高效,规范如“契约”明确流程中关键节点做到什么程度算到位。最终,是为了有质量地快。返工就是最大的浪费,一次把事做对不仅快,而且稳,它不香吗?




无论是哪种研发模式,瀑布、V型还是敏捷,最终都会落地到带有规范的流程至上。流程 & 规范作为研发模式的载体,在每个团队内都有不同的实践。这里着重提两点,也较为通用,分别是设置质量门禁(提测标准)以及准出核对(上线标准)。简单来说,流程靠卡点,卡点有规范


1)质量门禁--门禁不把容易尴尬


越早发现 Bug 并修复成本越低,风险越低。想必大家都有共识,如下图 Bug 缺陷成本趋势图所清晰展示。越往后风险越高,形象的类比“蝴蝶效应”就很好理解。想想:


修改一行代码,影响功能能逻辑不说,还可能牵连到业务逻辑;


后期验证范围被主观锁定而产生遗漏,纵使有全量回归兜底,在临近上线前发现 Bug 修复引入的新 Bug 也是让整个项目很崩溃的消息;


最终,导致上线交付 Delay。

。。。你说是不是很尴尬?




与质量门禁相配套的提测标准包含哪些内容?


  • 自测通过

  • UT 覆盖率达到 xx%

  • Code Review 意见全部回复

  • 文档类,如设计文档、接口文档、配置、SQL等完备

  • 跑冒烟用例集合(关键路径、影响模块抽样) 



2)准出核对--上线前最后一次的“清单革命”


临门一脚,功亏一篑,谁都不愿接受。核对是上线前夕的兜底措施,更是团队所有成员的心理建设过程。褪去其保险功效,满槽蓝血就等运维小哥鼠标一点, 进度条 100 % 那刻的 Give Five!




与准出相配套的上线标准包含哪些内容?


  • 依照测试策略,用例执行完成  

  • 需求覆盖率 100 %

  • 无严重级别 Bug,缺陷趋势收敛

  • 版本信息、配置、SQL信息正确 

  • 有回滚方案,且验证通过 


另外,测试是个长周期活动,测试规范得过硬。除了上述提测标准、上线标准,还包括有:用例分层、用例管理、缺陷定级、测试报告、生产故障定级、RCA等等。详见:那些年要是知道这些 该有多好!




3.数据度量


管理学大师彼得-德鲁克说过:“无度量难管理”。


质量有没有变好?测试执行有没有变高效?测试是否是研发瓶颈?哪里需要改善?认知、沟通最低的方式就是通过数据说话。


当下,“数字化”是个时髦词,比如金融数字化、政务数字化、社交数字化等等。沉淀研发过程数据就是软件工程数字化。


当然,这里主要聚焦于质量数据方面,更广泛的研发数据与工程效能息息相关,比如 Devops ,老 J 另开一篇聊聊。


那么,如何做数据度量?可以分两步走


  • 第一步,沉淀端到端数据,甚至是过量沉淀,以备后用;(解决有没有的问题)

  • 第二步,挑选当期关键指标进行重点提升 or 降低。(聚焦如何用的问题)


指标大致分为三类,外加排行榜,罗列了一些常用的指标,见下表。


分类
图表形式
指标项
结果质量生产故障排名

生产故障数及定级

过程质量

提测通过率

缺陷密度(缺陷数 / 需求数 )

缺陷分布图

缺陷Reopen 率

过程缺陷趋势图

缺陷数

需求数

缺陷密度 = bug 数 / 需求数 

缺陷 Reopen 率

缺陷分布 

人效

开发、测试耗时及其比例

开发、测试历史耗时对比及趋势

自动化测试提效数据表格

流程各阶段耗时

自动化用例数、总用例数

冒烟、功能回归、迭代提效百分比 

排行榜

生产故障排名

过程缺陷数量排名

需求交付数量排名

缺陷数

需求数

生产故障数

说明:质排行透明、可视化,有利于同级竞争。


相信,好的过程数据能促成好的结果。完备的数据度量能让每天上班感觉在玩“足球经理”(EA 早期出款的一部沙盘游戏)人生如戏,游戏人生啊。



文末总结


1、质量管理三板斧。测试自动化、流程&规范以及数据度量。


2、设置质量门禁,卡好准入标准,能让质量较早受控,避免项目运作的后续风险累计;上线前准出核对不但是最后一道兜底措施,同时能让团队积聚成功上线后的成就感,提升团队凝聚力。见 那些年要是知道这些 该有多好!


3、“无数据,无管理;先度量,后决策”。对质量数据的度量能用相对客观的“语言”描述质量状况,最重要的是驱动改进,实现质量提升。而这种趋势是实打实看得见的。


-END-




TAG:

 

评分:0

我来说两句

显示全部

:loveliness: :handshake :victory: :funk: :time: :kiss: :call: :hug: :lol :'( :Q :L ;P :$ :P :o :@ :D :( :)

我的栏目

日历

« 2021-02-27  
 123456
78910111213
14151617181920
21222324252627
28      

我的存档

数据统计

  • 访问量: 237
  • 日志数: 1
  • 建立时间: 2021-02-09
  • 更新时间: 2021-02-09

RSS订阅

Open Toolbar