求答复

给出冒烟测试用例，让开发自测过后再提测

这不应该是开发组长的事么。自测流程都能省了。

1.跟上面 ALEX 说的一样，给冒烟用例
2.如果没有区分用例类别，可以把测试设计思维导图发给开发，让他们对照导图来自测基本功能

面试官都喜欢问这些无聊的问题：
1、开除开发，你没权利
2、什么冒烟测试，自测通过后在提测，SQA 的事，就算有这流程，SQA 也拿开发没办法。
所以最后的结果：还是靠自己，有多少 bug 测多少 bug，改不完是开发的事，否则项目延期就是测试的事了。

如果是我的话，会分两种场景看：

场景一：连冒烟都跑不过的
沟通方式：调整下提测方式，改为提测的时候直接到开发座位，开发操作演示冒烟流程（控制在 30-60 分钟内可以操作完，服务端要部署到测试环境中）是 OK 的才算正式提测。如果现场都演示不过的那现场打回，开发修到演示过了再算作提测。

场景二：冒烟能跑过，后续修复 bug 中出问题
沟通方式：提醒开发做好自测，记录缺陷的时候也标记下哪些是修复 bug 引起的。同时也和开发沟通下，看是不是有什么困难导致没法做好自测（比如多项目并行、此场景不知道怎么自测）。直接沟通无效的话就向上级组长汇报，带上修复 bug 引起新增缺陷的数量数据增强说服力。

大公司一般不会出现这样的情况,出现这样的情况的一般是中小型公司,中小型公司大部分在着重开发的"创造",所以沟通基本不管用,开发该不自测还是不会自测,除非能用自测通过率来考核开

不自测或自测很粗糙 ，出现堵塞的问题，直接拒绝测试，需求的流程走通畅了再提单。不会一上来就进行测试，一般随手玩玩 P0 用例先，边玩边跟开发聊聊天
不过遇到真的堵塞问题，一般都会再玩一会 ，一个早上或一个下午，再提出。谢谢您写的 bug 给我摸鱼的机会

1. 设置准入标准，引导开发自测
2. 与开发结对编程，或者引入 TDD
3. 找下根本原因，技术太差 or 态度敷衍，再针对性的来
4. KPI、绩效引导下

你应该反问他：开发人员还能写出来高级 Bug 吗？？？
当出现大量低级或阻塞性问题时，也侧面反映了所在项目中转测入口的管控力度小或者根本没有，另一方面就是开发人员的自测没啥效果或者根本没有。你能做的就两方面：
1.如果有强有力的推动，你可以选择加强并制定转测规则，反向推动开发自测工作的进行和保证。
2.如果没有推动力而且还是孤军奋战，那你可以通过提交问题单，以问题单来逼近来督促来获取管理人员的推动

这个公司不值得去。经常犯低级错误，这是人性不是你流程就能解决问题的）。如果你都能决定流程了，你早就不会需要操心这种问题了

场景二里面有其他情况，我以前合作的开发经常出现。
1、开发主要精力在处置较为麻烦的问题，比如缓存、性能等，解决之后对业务基本逻辑出现主观偏差，觉得 “哎呀真爽啊，完事”，造成低级问题产生。
2、不屈从于垃圾代码，为兼容当前的业务逻辑，花了额外的功夫做优秀的设计或者对遗留代码做了重构，这种情况也很容易出现低级问题。

除了大家说的流程上的处理手段，我觉得还是要试着去理解一下深层次的原因，逻辑简单，CRUD 不犯低级错误的开发也不见得就是多么出色的开发，因为这些人坑一般挖的比较深；经常犯低级错误的人反而也可能是技术比较好、比较上进的人，只是方法未必到位而已。这样跟开发合作，相互知根知底，了解对方容易出错的习惯，效率一定不会差的——测试和开发的合作也是一个相互培养的过程，俗称磨合。

嗯嗯，认同磨合这个点，每个开发都有自己的特点，只要能做到互补并不一定就是坏事。

不过有一个点可能还是想讨论下，我接触到技术比较好且比较上进的，会以出低级 bug 为耻，所以自测一般会做得更完善，确保不会出低级错误，避免影响优化带来的好印象。优化后容易出错的容易是炫技型的，这种埋得坑可能更深。。。

上进也分档次，我说的仅限于把代码搞漂亮点，也并不是炫技，至少不通过加 if else 来实现新的业务逻辑也是一种上进的表现，至于觉悟能不能更进一步，自测通过再提测，这就要再提点提点或者通过流程来帮着提升了……我本人还停留在前一种，虽不耻于堆代码屎山，但是自测这一点上的确不值得骄傲……经常被测试妹子耳提面命

如果有绩效考核，那么请加入开发提测不通过率
如果没有，需要测试组长和他们组长在流程上沟通，加入冒烟测试