测试管理 公司研发要求测试人员提供研发自测用例,合理吗?

tangoliver · 2021年11月17日 · 最后由 不声不响 回复于 2022年11月17日 · 7985 次阅读

公司研发领导,要求测试人员,提供研发需要的自测用例,让测试人员设计编写测试用例,将主要功能区分出来,供研发自测使用;这样做合理吗?

共收到 35 条回复 时间 点赞

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

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

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

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

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

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

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

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

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

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

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

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

常规操作

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

香甜的Q 回复

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

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

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

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册