如实回答就行了吧
1、为什么打回去，冒烟测试没通过，阻塞核心流程，或者影响面积较大；
2、为什么都要重新测一遍，害怕这个改动会影响到其他功能点，害怕线上出事故；但这样做的成本很高，线上事故该出的还是要出；为什么？因为测试人员对系统没有把握，没有掌握所有的功能，即使你全测一遍，还是会有很多遗漏的点；作为测试人员实际上可以多花时间从业务、代码、数据多个层面去分析各个功能点之间的关联，整理成文档，当有功能点改动时，能直接分析需要测试哪些点，也就是精准测试；开发怀疑你的时候，直接把这些数据扔给他，能节省很多争论的时间；

其他几个问题也是类似的。。

这是个很好的内部沟通机会。问题抛出来了，大家坦诚沟通就好，如果能达成共识，非常棒。

1、对于严重之类的级别，是否有一个大家共识的规范。

2、所有重测不做，你的为难点是什么？风险点是什么？大家是否可以共识

3、测一两下就好了，是否看过测试用例。有没有拉着研发一起做场景分析。

4、不做回归的风险是什么？风险是否可接受

5、换包会怎么样？

。。。。

重点是共识与风险控制。总有改不完的 BUG，共识和风险认知要集体一致，测试工作才会高效且有序顺利进行。

好的。重要是共识与风险控制，学习了，谢谢。

这真的是开发问的问题？
这种问题都想不清楚的开发，要如何教化哟，不如避免与之共事吧

不管怎么说，能弄出这么多问题，好歹说明人家那边是认真思考了。

话说这些问题你是如何回答的呢？看可以先抛砖引玉一下

做过测试做过开发的我来正面回答一下吧。
1.问题严不严重，既不是研发定，也不是测试定，是项目定。
2.测试能力不足的体现。
3.你想想是不是也想过这个功能开发半天就开发完了，位置不一样，换位缺失的话都这么想。
4.一定要做。问题是做的了么？
5.出问题锅谁背？总监定。
6.测试开发都水。
7.简单功能就是单元自测写得水。融合功能，开发测不了。

Q:为什么做了这个功能，其他的功能都要重新测一遍，有这种必要吗？
A:2.测试能力不足的体现。
这个我不认同

这个问题每年问题的反馈都会收到类似的"为什么研发改动了一个小点，测试却要其他功能或者主流程都测试一边"。去年因为知道这个问题是哪个研发团队提的，也理解研发团队注重时间成本，所以回复是 “一方面主流程自动化我们能回归的，提升我们这块回归效率；另外一方面为什么一个小改动影响了其他不相关的模块，是否在我们架构设计的时候，把模块之间的耦合性降低。”

补充解释：
1、代码的复杂关系改动以后 是否对其他模块有影响 项目复杂 开发人员也说不清。
2、如果说不清，那么测试就假定存在问题，需要进行验证，这个回归是验证的过程 。
3、如果说的清，开发是否愿意承担改动不会对其他模块产生影响整个责任背负？如果愿意 那我觉得 只需要测试改动部分的功能；
4、测试不是没有能力去做这个事情，是中国目前现状，大部分测试人员的水平没达到能控制改动代码只测试有影响的部分。

6、为什么测试了没问题，一上线就问题多多？
针对这个点，我们的测试小伙伴就伤心了：请问是哪个项目，上线了出现了什么问题，请给出事实依据。
请使用数据说话，让测试团队看到问题，去改进。（项目的线上事故目前大部分都是测试部门在进行跟进和推动解决的。没有收到这个团队的 2 个项目反馈问题多或者异常事故的。）

外部故障不应该就是测试进行统计和输出么？
数据应该你出，你先分析你的改进计划，然后再来看看能不能驱动开发。

大家都是职业人，又不是小孩子过家家，又不是谈个女朋友，要宠着，哄着。

如果一个研发团队，问出这样的问题，只能说明这个研发团队不职业，不专业。

我天天问你们开发，for 循环是什么意思呀，++i 和 i++ 有什么区别啊，什么是数据结构啊...你看开发会不会炸？

大家都是拿钱来工作的，各自做好各自的边界。质量是整个研发团队的质量，不是 QA 团队的质量，研发的 MindSet 停留在这样的水平，质量保障个棒槌？ 4 楼说得对：这种问题都想不清楚的开发，要如何教化哟，不如避免与之共事吧。

正解。沟通和形成共识是工作良好开展的前提。

谢谢大家给的这么多建议。
1，目前已经做的是针对每个问题进行了归类，并针对这些问题对研发团队先做一个测试流程也可以说是整个项目流程的分享，再针对问题进行沟通。
2，进行测试用例编写的分享。后续测试内部的针对项目有分享的也叫上研发小伙伴。
3，另外后面再做一个《跨部门沟通协作》的分享，通过小组讨论这些形式，一方面培养团队熟悉度和信任感，另外一方面增加大家的沟通协作能力。

说得很好，精准测试。我也是这么想的，不过我没有实现好