这是一个创建于 1304 天前的主题，其中的信息可能已经有所发展或是发生改变。
如何权衡开发自测与测试？（公司目前测试纯黑盒 手测😶），开发自测应该做到什么程度？😷
 |
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
|
 |
15
Thresh 2021-04-16 14:58:38 +08:00
影响测试大佬写专项的工作 全部开发自测。
|
 |
16
Justin13 2021-04-16 15:34:20 +08:00 via Android
|
 |
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
主要是领导给的时间，不够写单元测试，集成测试，和自测
|
Select Language