如何权衡开发自测与测试?

2021-04-16 08:53:28 +08:00
 monsterlin

如何权衡开发自测与测试?(公司目前测试纯黑盒 手测😶),开发自测应该做到什么程度?😷

10168 次点击
所在节点    Android
22 条回复
Jiangyf
2021-04-16 09:04:26 +08:00
等一个大佬来回答~~~
doyel
2021-04-16 09:07:05 +08:00
我司开发和我说他们是开发,测试不是他们的工作,结果 Function 级别逻辑都跑不通

之所以只能拿个万把块,不是没道理的。。。
shapl
2021-04-16 09:09:09 +08:00
测试过程的 bug 归开发。
生产环境的 bug 归测试。
zhang77555
2021-04-16 09:13:15 +08:00
开发至少单元测试得做吧
wolfie
2021-04-16 09:16:48 +08:00
涵盖大部分情况走一两遍不出问题(部分极端情况先不管)
AoEiuV020
2021-04-16 09:28:41 +08:00
自测只测开发时觉得可能有问题的场景,
wudizaliangbing
2021-04-16 09:32:11 +08:00
自测至少业务流程能走通过一遍
lightjiao
2021-04-16 09:32:44 +08:00
写自动化测试,大概写自动化测试的时间与开发代码的时间占比为 3:7
zhanggg
2021-04-16 09:33:15 +08:00
定好需求,写好冒烟用例和其他用例先,用例也找相关人员评审好
冒烟用例通过率没有 100%一律打会不予测试。
其他用例通过率根据需求和测试点多少来划线,bug 数超过多少一律打回
iceteacover
2021-04-16 09:41:14 +08:00
我理解开发自测起码要将接口逻辑跑通,联调阶段能够减少 block 。

开发测试融洽的话,测试同学应该在开发同学提测前 1-2 天把冒烟测试用例(基础逻辑,涵盖主流程 总数占整体测试用例大概 10%-20%)给到开发,前后端开发同学去执行所有的冒烟用例,冒烟测试用例通过视为正常提测的前提条件。

看起来冒烟用例多,不过实际上许多冒烟用例已经在联调阶段完成。

当然如果开发同学对代码有更高要求的话,可以跑集成测试,有测试框架能够计算代码覆盖率,基本上 80%代码覆盖是一个基础要求。后续提升测试覆盖率非常累,但可以反过来推动代码逻辑优化,很多测试覆盖不到是因为代码逻辑或业务逻辑缺陷,而这种缺陷很难通过测试同学验证出来。
phobal
2021-04-16 09:41:46 +08:00
黑盒测试的话,至少得在提测前由测试同学出一份能跑完整个流程的测试用例,开发用来做冒烟测试,只有冒烟测试通过了测试同学才接受提测要求。
twistedmeadows
2021-04-16 09:47:57 +08:00
盲目追求覆盖率已经是一种落后的开发方式了。
只会产生大量冗余的难以维护的测试代码。

开发自己决定覆盖哪些核心代码和容易出错的逻辑。

至于开发和测试的边界在哪里,就看你们团队的研发方式了。
敏捷开发要求的是全功能团队,开发可以参与测试负责的工作,测试也可以涉足开发的领域(例如把代码重构解耦成方便单元测试的架构)。
如果是传统的瀑布流式研发,那你在什么地方交付给测试就只负责到那里为止。反正测试存在的目的就是帮你 cover 错误
arvinsilm
2021-04-16 09:56:13 +08:00
自测最低要求主流程跑通,不出现大量阻塞性 BUG
ho121
2021-04-16 10:15:39 +08:00
@doyel 什么?万把块的都这样?那我岂不是能拿十万把
Thresh
2021-04-16 14:58:38 +08:00
影响测试大佬写专项的工作 全部开发自测。
Justin13
2021-04-16 15:34:20 +08:00
@twistedmeadows
“例如把代码重构解耦成方便单元测试的架构”
能帮开发擦屁股,这测试可比开发牛逼多了
FATEQiang
2021-04-16 16:41:21 +08:00
@doyel 开发这样说不对,开发自测本身就是必做的,从硬件过来就存在冒烟测试的说法了。。我所经历过的严格的公司,开发需要跑基本用例。这一步完成之后(可能要发邮件的。。。)再由 teamleader 申请下游测试(还没有到解决方案测试),下游测试 bug 密度太大会提到敏捷工具上,kpi 不就鸡儿了?。。。顺便说一句(开发完成之后有一个 cr 和仓库上代码的过程,基本上就是 commiter 的十万个为什么)。。。所以所以他这一万的工作还是太轻松了
doyel
2021-04-16 16:48:07 +08:00
@FATEQiang 我自己也是开发出身转业务和管理的,但是对于现在很多小朋友对待工作的态度和方式实在无力吐槽。只能在这里抱怨抱怨了,哈哈!
christin
2021-04-17 11:57:29 +08:00
自测保证流程以及正常操作没问题
测试要干的就是在酒吧里点炒饭了
对接我的测试总能找出各种稀奇的 bug
xiongxuan
2021-04-18 10:47:50 +08:00
如果测试不靠谱,开发最好全部自测一遍。自己又开发又测试,测试人员做最后兜底。

我司也是测试纯黑盒手测,测试都不是很专业,虽然招的都是计算机专业的人,但我个人测试感觉难度不大,有手就行,当然也出现过生产环境出现重大 bug 的情况。我们的做法就是:

1. 在开发人员面前强调一定要自测,灌输宁愿相信测试不如相信自己的思想
2. 制定分锅方案,生产环境出现重大 bug,由总监来评定,如果是测试失误(必现的问题),测试背大锅,开发背小锅。不是必现但出现频率非常高的问题,两个部门的总监一起评定谁背大锅。当然只要不出现重大 bug,还是不用员工背锅的,及时回退更新就好。
3. 每次出现重大 bug,就反思现有开发流程是否有可以优化的地方,是否可以从流程上避免类似问题再次发生。之前出现过开发人员直接把测试代码更到生产环境的情况(开发人员大锅),后面流程优化成不需要开发人员写测试代码,直接在后台配测试数据,由框架统一管理。并且我们现在已经在着手开发测试工具,从生产环境的日志里抓取数据,生成测试用例,上线之前跑一遍测试用例,避免新的改动影响到老的功能。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/770988

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX