测试管理 [质量提升之道]-测试左移动&提测质量管控

扫地僧 · 2018年03月31日 · 4937 次阅读

文章系列
[质量提升之道]-Code Review
[质量提升之道]-UT&Coverage

前言

上一篇介绍了 UT&Coverage,本篇将介绍测试左移动和提测质量管控。
所谓测试左移,以版本提测为界限,界限以左的测试工作。测试左移,能帮助到提测质量,提测质量的好坏直接反映出一个团队的管理水平、技术能力。
目前大部分公司,测试在左移阶段还比较薄弱,一般只参与需求评审,测试用例等工作,其余的要么不带测试玩,要么没有能力参与。
其实,能发现更多质量问题的还是在左移阶段,这是提升测试人员核心竞争力的舞台,也是测试人员为提升测试行业影响力的星星之火。

左移清单

1.需求评审,测试人员必须对业务熟悉,甚至成为领域内的专家,敢于合理的挑战产品经理;
2.技术方案评审,测试人员能读懂和理解技术方案,凭丰富的经验的敏锐的嗅觉,挖掘技术方案的不足之处。例如:方案中的补偿场景是否合理充分、业务场景不断增加后的可扩展性、业务量大幅增加后的性能问题、可测试性等;
3.测试用例和业务编码并行,包括接口测试用例、功能测试用例的编写;
a.提供接口服务的,要求开发人员在编写业务代码之前,先给出接口设计文档;
b.引入 Swagger 等自动生成工具的,先定义好接口(request 和 response 的参数、参数类型、必填项、取值范围、其他约束等),编写业务代码前,先编译生成文档;
4.单元测试的质量,除了保障代码覆盖率等硬性指标,还要从测试角度检查 UT 代码的有效性;
5.代码静态分析,测试也可以拉取代码进行检测,协同开发一起保障代码质量;
6.代码审查,有问题的代码不能轻易带病入库,测试协同开发一起把好代码入库前的最后一道关;
7.测试用例评审,版本提测前组织产品、研发、测试一起完成,提测后可直接使用。

提测质量管控

相信大多数同行切身体验过随意发版的各种负面影响:
1.提测版本问题一大堆,测试大多数时间耗费在基本功能的验证,而极端场景、复杂场景基本没时间测试;
2.养成开发不自测的陋习,皮球踢给测试,发版质量越来越差;
3.缺陷收敛期拉的比较长,造成迭代次数不可控,测试疲于应对,不得不靠堆人力、堆时间完成。

所以,提测质量管控,势在必行:
a.代码静态扫描通过提测标准,例如:没有严重级别的问题;
b.单元测试的覆盖率达到要求的指标,例如:method 覆盖率不低于 90%,line 覆盖率不低于 70%;
c.接口测试快速回归脚本全部通过;
d.冒烟测试通过提测标准,例如:危险 P0=0、 严重 p1<=1。

后话

这几年,IT 行业对懂技术的测试人才需求量越来越大,测试技术领域的人才也越来越多。目前大多数的讨论都集中在了 UI 自动化、接口自动化、工具开发等领域,有不少是重复造轮子。希望有更多的能理解测试工作的本质,契合工作痛点应用技术,说白了,我们测试学技术最终是为质量服务的。

下一次,会介绍代码审核工具-Phabricator 的安装和使用。

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 20 条回复 时间 点赞

好文,几次实践下来,其他还好,让开发做单元测试并达到一定覆盖率,目前还是最困难的。

蒋刚毅 回复

确实有这种情况,自上而下推行,纳入考核最好,实在不行测试也可以深度介入。

大佬 我是你的迷粉了 期待你的后续连载

确实应该要有一个比较硬的提测标准,这一项纳入考核确实确实很必要。目前大多数公司不会有这项。养成了开发,产品不自测的陋习,测试人员又不多,造成了测试人员不会往专业性方面发展,而是持续呆在奇怪的圈子,不断恶性循环。

现在的测试,大多数实际意义是产品助理

@quqing 我看你说话的方式有点像我现在领导啊,咱俩不会是一个公司吧?

Ambers 回复

不可能,我只是一个藏经阁扫地僧

FelixKang 回复

肯定的

锅锅的锅 回复

说到点子上了

现在的测试,大多数实际意义是半个产品助理 +1/2 开发 +1/2 客服

daivd 回复

如果能达到半个开发,半个产品助理,也算可以了

我现在主要负责电商系统的后台 web 端测试,商品,订单,供应链,仓储等等,觉得业务逻辑好多,传统功能测试有时觉得很慢,且测试时间短,很多地方覆盖不全,有点迷茫,想搞自动化,但不知道怎样的自动化才适合目前的工作状况。

真的很长知识了,不少内容在我的工作中都没有涉及到。学习学习。感谢分享

扫地僧 回复

庆哥这扫地僧的境界,可不是一般人能企及的啊

说的挺好的,提测质量管控,小公司有点难度,开发自测没时间,单元测试没时间

自上而下的贯彻执行,确实是个不错的思路。
我们公司 CTO 也明确要求每个项目团队都要保证 UT 平均行覆盖率>80%,核心模块甚至要达到 100%,最后出现两个怪圈:
项目上线后再拼命的补单测、动歪脑筋去钻行覆盖率的空子从而满足覆盖率。大家不是发自内心的想提升产品质量,打心里认为 UT 是浪费时间,多此一举,反正后面有测试。
研究过代码覆盖率的同学都知道,行覆盖率不是很准的,而应该用路径覆盖来进行衡量

好文,我们也可以从项目流程上进行辅助把控;例如测试部门提供准入测试用例,增加开发进行提测前的准入测试流程。目前我们公司实行下来推动开发自测还是有一定的效果!

测试极客 回复

其实写过 UT 的内行知道,老老实实写 UT 和动歪脑筋达到覆盖率的投入差不了多少,方法覆盖和路径覆盖确实更重要,所以有条件可以让懂行的测试介入监督,确保 UT 工作的有效性。流于形式除了开发心里抵触,还有是觉得测试不懂可以忽悠过去。

苹果 回复

效果肯定是有的

匿名 #20 · 2018年04月07日

写得很赞,加个 QQ505160467 深度交流一下

扫地僧 [质量提升之道]-Phabricator 的安装 中提及了此贴 04月09日 15:14
扫地僧 [质量提升之道]-接口测试 中提及了此贴 12月06日 00:30
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册