不合理吧。。研发自测的思路应该和我们不一样吧，怎么写。。

合理的，之前公司有这样做，研发自测用例其实和冒烟用例差不多的，主要作用在于保证提测时迭代主流程质量，不会因为主流程阻塞导致拖延测试进度。
提供研发自测用例对于测试来说是好事，能提升提测质量，也给了测试人员卡提测准入的权利，最怕的反而是有规则却不遵守，开发一直忙于赶进度，不自测，联调敷衍了事，把问题留到测试阶段而且阻塞测试流程和进度。

这个在大小公司都有，有的是开发当着你的面演示自己做的功能，有的是开发执行你给他的冒烟用例。
开发自测可能只调一下 postman，调通了就算自测通过，可能前后端都没联调，然后提测。
他不 show 一下或者跑一下你的冒烟，他都不知道他的功能做的有多烂。通不过，那就不用提测了。省时省力。

合理吧，我觉得这样子能将降低提测时的低级 bug 而且你也会轻松一点

领导的要求都是合理的，因为他觉得你绩效！！！

这个很合理啊，这个就是冒烟用例，研发跑通了之后可以省去测试 1-2 天工作量的，而且测试要支持啊，因为没有那么多主流程不同的情况了，对于测试来说是好事

提测要求之一，研发需要通过自测用例才能提测。这个自测用例就是主流程用例，由测试提供。研发自己需要做的是单元测试。

提供冒烟用例给开发自测也不错吧

这个当然要测试提供啊。。

控制提测质量的手段，这应该是测试提出来的，你认为不合理，可以提出其他控制提测质量的手段说服领导。

合理啊，自测用例本来就是 QA 负责提供给 RD 的

可以给，冒烟测试用例嘛，挺好的，比开发自己写的要好！

常规操作

我觉得很合理。要保证自测质量，自测用例很重要。一个功能背后一般会拆分好几个模块，开发很清楚自己模块，但不见得清楚完整功能。如果他自己设计，大多都会只是测试自己的模块，而且也比较随意，甚至用例都没有。

提供自测用例，可以让开发减少自测的思考成本，满足开发的诉求，同时也能保障开发自测不跑偏，提高提测通过率，满足测试的诉求，性价比挺高的呀。

我们公司会把核心的 P0, P1 的用例让开发去测试，开发要保证自测通过才能提交版本给我们

冒烟用例标注哪些是 p1 级别就行啊，让开发自己去测下

合理

合理，可以根据这个设置准入标准。

常规操作 冒烟用例是测试人员给的准入规则

提供主流程用例即可，不用太细。跑通过之后也给自己省时间了，挺好的

开发自测用例关键是要达成共识，具体谁提供可以协商。就像前面的同学说的，领导安排测试提供，那就提供呗。

这样做虽然看上去是测试为开发提供了工作内容，但其实不管开发要不要自测用例，测试都要写用例，且都要覆盖这一部分内容。

从测试用例中圈出一部分内容，让开发做自检，可以提升测试版本质量，减少测试的工作量，何乐而不为？
测试提供这部分内容，还能掌握主动权，下游掌握主动权的机会并不多呀，要珍惜。

这是「准入标准」之一 ，必须得提供；否则，咋知道开发自测是否合格 ？

我理解研发自测用例=冒烟用例，只是说法不同而已，从主干测试用例抽出冒烟用例就好啦

TDD

换个问法：开发能自测又能自己设计很科学的 case，关键是有问题随手就改好了，Geek……还要测试干吗呢？
显然开发的长处是写 bug 和改 bug，指望开发设计 case 就很容易陷入开发者典型的固定思维套路，造成大面积测试遗漏，你是测试大拿，你这时候还不上去体现自己价值更待何时……还问~

如果是测试提供研发自测用例，大家都是用什么格式提供？Xmind？Excel？还是直接禅道这些用例平台里写好？

自己写用例里面，把 P0 用例筛选出来提供给开发冒烟

这个就是类似冒烟测试用例，你让开发按照你提交的用例测试，能够保证主流程是 ok 的，省的你测试的时候动不动卡住，耽误项目交付，一般来说开发自测，就是随便验证下，提测给你的根本不行，通过冒烟用例能够约束下，保障提测的质量，对测试来说是好事

两个工作思考方式不同，测试写好测试用例，研发写完代码，自己过一遍测试用例，改完再交给测试，可以缩短工期

很合理。比起面对面开发演示，我更喜欢这种方式，高效。

这很正常吧，提测前研发做准入测试，当然需要 QA 提供准入 case 阿，准入通过后 QA 才介入测试。

我们现在要求开发写自测用例 qa review
qa 写测试用例 开发 review
double check

提供给研发的测试用例，为了方便他们执行，我们使用 Excel；测试内部的测试用例，为了跟高效，减少在车上用例耗费的时间，选中 xmind

我的理解，研发站在代码层面考虑问题，所以他们应该有自己的测试用例，可以理解为白盒用例；测试站在业务角度层面看待，提供的测试用例理解为黑盒用例，但两种都是保证代码质量。研发为了追求研发质量，以测试的用例为准绳，是不合理的；如果作为参考，加深自己对业务的熟悉，那才是对整体质量有帮助的。

属于合理，不然研发交付出来的东西测试不满意怎么办，为了解决这个矛盾，提供研发冒烟测试用例，必须测试通过后再交付测试，也是约束研发质量的一种方法