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

权衡

手测

测试

黑盒

22 条回复 • 2021-05-12 10:13:40 +08:00

1

Jiangyf

2021-04-16 09:04:26 +08:00

等一个大佬来回答~~~

2

doyel

2021-04-16 09:07:05 +08:00

我司开发和我说他们是开发，测试不是他们的工作，结果 Function 级别逻辑都跑不通

之所以只能拿个万把块，不是没道理的。。。

3

shapl

2021-04-16 09:09:09 +08:00

4

测试过程的 bug 归开发。
生产环境的 bug 归测试。

4

zhang77555

2021-04-16 09:13:15 +08:00

开发至少单元测试得做吧

5

wolfie

2021-04-16 09:16:48 +08:00

涵盖大部分情况走一两遍不出问题（部分极端情况先不管）

6

AoEiuV020

2021-04-16 09:28:41 +08:00

自测只测开发时觉得可能有问题的场景，

7

wudizaliangbing

2021-04-16 09:32:11 +08:00

自测至少业务流程能走通过一遍

8

lightjiao

2021-04-16 09:32:44 +08:00

写自动化测试，大概写自动化测试的时间与开发代码的时间占比为 3:7

9

zhanggg

2021-04-16 09:33:15 +08:00

定好需求，写好冒烟用例和其他用例先，用例也找相关人员评审好
冒烟用例通过率没有 100%一律打会不予测试。
其他用例通过率根据需求和测试点多少来划线，bug 数超过多少一律打回

10

iceteacover

2021-04-16 09:41:14 +08:00

我理解开发自测起码要将接口逻辑跑通，联调阶段能够减少 block 。

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

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

当然如果开发同学对代码有更高要求的话，可以跑集成测试，有测试框架能够计算代码覆盖率，基本上 80%代码覆盖是一个基础要求。后续提升测试覆盖率非常累，但可以反过来推动代码逻辑优化，很多测试覆盖不到是因为代码逻辑或业务逻辑缺陷，而这种缺陷很难通过测试同学验证出来。

11

phobal

2021-04-16 09:41:46 +08:00

黑盒测试的话，至少得在提测前由测试同学出一份能跑完整个流程的测试用例，开发用来做冒烟测试，只有冒烟测试通过了测试同学才接受提测要求。

12

twistedmeadows

2021-04-16 09:47:57 +08:00 via iPhone

盲目追求覆盖率已经是一种落后的开发方式了。
只会产生大量冗余的难以维护的测试代码。

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

至于开发和测试的边界在哪里，就看你们团队的研发方式了。
敏捷开发要求的是全功能团队，开发可以参与测试负责的工作，测试也可以涉足开发的领域（例如把代码重构解耦成方便单元测试的架构）。
如果是传统的瀑布流式研发，那你在什么地方交付给测试就只负责到那里为止。反正测试存在的目的就是帮你 cover 错误

13

arvinsilm

2021-04-16 09:56:13 +08:00

自测最低要求主流程跑通，不出现大量阻塞性 BUG

14

ho121

2021-04-16 10:15:39 +08:00

@doyel 什么？万把块的都这样？那我岂不是能拿十万把

15

Thresh

2021-04-16 14:58:38 +08:00

影响测试大佬写专项的工作全部开发自测。

16

Justin13

2021-04-16 15:34:20 +08:00 via Android

@twistedmeadows
“例如把代码重构解耦成方便单元测试的架构”
能帮开发擦屁股，这测试可比开发牛逼多了

17

FATEQiang

2021-04-16 16:41:21 +08:00

@doyel 开发这样说不对，开发自测本身就是必做的，从硬件过来就存在冒烟测试的说法了。。我所经历过的严格的公司，开发需要跑基本用例。这一步完成之后（可能要发邮件的。。。）再由 teamleader 申请下游测试（还没有到解决方案测试），下游测试 bug 密度太大会提到敏捷工具上，kpi 不就鸡儿了？。。。顺便说一句（开发完成之后有一个 cr 和仓库上代码的过程，基本上就是 commiter 的十万个为什么）。。。所以所以他这一万的工作还是太轻松了

18

doyel

2021-04-16 16:48:07 +08:00

@FATEQiang 我自己也是开发出身转业务和管理的，但是对于现在很多小朋友对待工作的态度和方式实在无力吐槽。只能在这里抱怨抱怨了，哈哈！

19

christin

2021-04-17 11:57:29 +08:00 via iPhone

自测保证流程以及正常操作没问题
测试要干的就是在酒吧里点炒饭了
对接我的测试总能找出各种稀奇的 bug

20

xiongxuan

2021-04-18 10:47:50 +08:00

如果测试不靠谱，开发最好全部自测一遍。自己又开发又测试，测试人员做最后兜底。

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

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

21

CY4suncheng

2021-04-19 10:40:07 +08:00

我们是测试给开发提供自测用例，基本就是主要功能点和流程验证，至少保证提测的是可测试状态，没有 block 的 bug

22

zhanlanhuizhang

2021-05-12 10:13:40 +08:00

主要是领导给的时间，不够写单元测试，集成测试，和自测