年轻的时候去面过一个相对于当时我的比较高端的管理岗位，当时的我情况是，开发经验相对丰富， 但管理经验还欠缺。对方当时面临一个具体的问题。
“我们最近生产上，出现了一个比较严重的事故，复盘的时候，开发喷测试，测试喷开发，都觉得是对方的问题。对于类似情况你有没有什么解决和处理的经验。如何提高软件质量”
我当时对这个问题回答的比较单薄，无非就说，大家要团结合作，开发要加强自测，测试要考虑全面，有责任心。这么说虽然没错，但是只有战略没有战术，也没实例经验。最终，显然对方也不是很满意， 无缘了这个岗位。
如今的我已不再是曾经的那个少年，虽然错过的人已经错过， 但问题长存， 都说人在不同的阶段，对相同的问题，会有不同的答案，于是锅叔在这里重新回答一次……
具体这件事情，建议从三个层面来处理。
一、就事论事
这一层比较简单，具体问题要具体分析， 要了解下这个问题的出现的原因， 归属的类型，然后才能明确责任。一刀切的让所有的生产Bug都由测试背锅是不科学的。
- 如果需求明确，正向用例就应该覆盖到，没有被测出，那显然属于测试全责。进一步需要追查，这个部分的用例是谁编写的，是否遗漏，执行了没有，为什么没有测出。
- 如果属于一些特殊数据，特殊流程下触发的bug，不能认为全是测试的问题，开发也需要承担部分。 可以具体分析下代码，是否属于那种开发人员容易意识到而“有意忽略”的问题。实际开发经验丰富的同学肯定容易理解，有些bug是，开发容易而且应该想到，而测试难以测出的。例如“并发减库存”这类问题，仅通过功能测试很难测出，在开发设计时，就应该进行考虑。
- 也有可能存在开发，测试都很无辜，需求背锅的情况，做出来的东西就不符合用户的实际需要。或者需求，测试一起背锅的情况， 需求调整需要连带修改的需求，没有做出调整，测试也没有回归到。例如只考虑了新增输入校验，没有考虑编辑已有数据的校验等。
二、举一反三
复盘的目的，主要应该不是为了追责。而是为了优化流程。弄清事情的发生原因后，应该建立对应的流程，机制，避免类似的事情重复发生。例如，用例的执行应该能追溯，测试开发能力不足的，要培训，要编写对应操作规范等，缺少评审的流程加入评审。
三、统筹安排
如果公司觉得此事暴露了软件质量的不足，期望改进开发质量，那么就要理解，软件的质量控制和软件测试，其实是不同范围的事情。质量改进包含的范围远大于软件测试，对这一点要在团队中进行宣贯，统一认识。
提高软件质量不等于提高测试质量，质量控制是一个贯穿开发流程始终的活动，需要团队的所有角色共同参与，为交付质量共同负责。
1、产品，需求人员的质量责任
非常容易想到的一个职责是——不能理解错用户的原始需求，否则就将带着整个团队南辕北辙了，但这其实只是一个最基本的要求。
除此之外另一个重要的职责是——传达清楚，即把需求全面，准确的传达给用户。
“准确”可以理解为要把你的需求描述清楚，条理清楚，避免歧义。实践中很多bug的产生，是因为开发人员遗漏一些细节需求导致的。这类bug的情况，通常功能较为细节，例如一些细节的校验，提示的文字，与同类功能的细小差异等。这类问题可以通过在需求编写形式上上，使用逐一列出，重点强调的方式会比把所有需求无差别写成一坨文字，降低发生的比率。歧义情况的出现，多是由于语言描述不严谨，不具体导致的，可以有意识多使用逻辑性描述，实践所占比例不高，适当注意即可。
“全面”实际是一个非常难以达成的要求，需要需求人员有较高的素质。这类问题造成的bug在运行维护多年，持续迭代的系统上暴露的非常多。抽象来说就是修改了某功能，要对应修改系统中对于此功能为有依赖的其他功能。对于陈年老系统，要考虑周全非常困难。简单的例子如，为了增强账号安全，增加了注册用户名的长度，也允许加入特殊符号。需求人员应该想到，此处修改除了影响用户注册页面的用户名输入框校验规则外，也同时需要修改，用户登录页面的用户名输入规则，如果有其他客户端如移动端，也需要同步修改，如果后台有用户管理，搜索，用户名搜索框允许输入内容可能也要同步修改。甚至要求高的UI界面， 因为长度变化，可能会导致显示异常，也要一并考虑到。
而产品架构，则是更高层次的要求， 要求需求人员对产品的功能，实体，概念，做恰当的抽象，并有一定前瞻性。 产品架构其实是技术架构的基础，如果产品没有一个需求上的框架，那技术架构也是无法恰当提出的，随机应变会成为日常，修改成本会升高，稳定性会变差。
2、开发人员
· 开发人员主要是要强调自测，对自己的交付物负责。实践中，开发人员常反怼说，我们又不是测试， 我们都测了要测试干啥。 因此也确实涉及到一个度的问题。实践中一个最基本的要求是， 对于需求对应的正向用例应该自测到，通俗说就是需求明确提到的功能开发自测应该覆盖。例如“新增的用户，点击用户名称，能够显示用户详情”，开发人员至少要保证自测下， 新增一个用户，点击其用户名，显示详情这个流程。如果没有问题算通过。而测试人员则要考虑的更多。例如编辑的用户，导入的用户能不能正常显示？有特殊边界输入的，选填项不填的，显示是不是正常。
情况往往也不会这么简单， 现代系统通常分工比较细，一个功能通常由几个开发人员合作完成，他们之前通常通过接口定义来衔接，也就是各自按约定的接口协议，实现功能即可。这种情况下，除了要求按照接口自测外，还要要求，这几个人中指定一个人负责串联的测试，保证功能正确。因为实践中接口难以定义的事无巨细。 这里的接口可能是前后台间的http接口，也可能是基于数据库表的接口（一个存，一个取）。如一个负责用户存的开发只验证了用户信息有没有写入数据库表。 另外一个负责展示的开发人员只验证了，自己在数据库手动填写的数据，能不能正常的被读取显示到页面上。 如果没人负责串联验证下这个过程，那接口对接环节的bug就无法发现，例如，存取的字段不对应，空值的表示不一致null与””等。
开发人员自测确实可以更早的发现bug，降低bug修改的成本，不需要经过 ，“测试提”，”开发查”，”开发改”,”测试验”的过程。但锅叔觉得这只是开发自测收益中较小的一面，更大的收益在于，提高开发人员的质量意识，不是功能写完就算是开发完。通过结合其他追溯机制，可以推动开发人员，使用更合理的设计，主动进行重构优化。
3、测试人员
测试人员在很多人的观念里，是天然的负责软件交付质量的人员，其质量责任主要就是做“好测试”。做好测试，无非依赖于，扎实的软件测试理论基础，和对系统业务的充分理解。 测试理论属于通用技能，只能通过学习思考，积累提高。而对系统业务的充分理解，对测试人员的稳定性是有一定要求的。 如果你们公司的测试人员是共享资源性质的，那应该尽量让他们稳定服务于，1个或几个项目。尤其对于长期迭代，周期较长的项目，人员稳定性非常重要，切换成本高昂。
质量控制是测试工作的超集，因此提高软件质量，也要求测试人员额外承担一部分质量分析统计工作。因为Bug直接由测试人员记录产生， 由其来进行这类工作更为直接。常见的统计指标如，
用例通过率，重激活Bug数，需求问题Bug数，未自测Bug数，遗漏需求Bug数，生产发现Bug数。
都是开发质量的评价依据，是复盘优化的基础数据。测试人员在测试工作中，或者生产环境支持过程中，在bug管理管理工具中，应对bug类型，进行识别归类， 用于日后统计分析。
这也要求，测试人员要客观公正，真实反应质量数据。这里也提下，个人不赞成Bug与绩效明确的挂钩，否则容易造成开发测试对立，内耗严重，非常糟心。-_-||。
4、管理人员
管理人员，首先明白，研发有其自身遵循的客观规律。所谓给技术以时间，凡事总有个测试，优化的过程，如果总是随意拍脑袋，削减研发评估的研发周期，那么，因为功能是显而易见，一定要交付的，所以首先被压缩的一定就是质量。例如一个系统计划开发一个月，测试一个月， 领导一拍脑袋，开发测试压缩成一个月， 那实际上，可能就开发3三个周，测试一个周，中间的各类评审也都被扔的七七八八，开发设计怎么方便怎么来， 测试就走走主要功能能用就行。这样质量就不要苛责了，相当于把测试交给最终用户，对于长期迭代的项目，也会累积不菲的重构债务。
建立评审，复盘机制，是高级管理人员的职责。 重要的评审公司多小也应该具备，如需求评审，开发设计评审，测试方案/用例评审。同样复盘，如结项复盘，或以时间为周期的月复盘，季度复盘。
基层管理人员，参与组织评审时，应保证评审不流于形式。如需求评审， 就是降低需求BUG的重要环节， 系统大了，需求人员自身的能力，也很难考虑的面面俱到，需要开发，测试共同，帮忙考虑，新需求对已有系统各处的影响。评审过程也是一个传达质量价值观的好机会， 在“好改，工作量小”和“规范，长远可维护”中尽量选择，规范的需求设计， 开发设计方案。要倡导细心和减少Bug是有非常有技术含量和挑战的事情，而不是一件麻烦的事情， 让开发多花精力在一次作对上。
复盘是一个重要的回溯机制，质量问题应该都能追溯到个人，谁提的需求，谁写的，谁测的。 到不一定要跟绩效挂钩，但责任到人的方式，确实可以推动大家，建立质量意识，遵守质量规范。用例通过率低的模块的原因？需求Bug的数量较多，提示我们要重视需求编写，评审，提高需求编写人员能力，未自测bug多，提示开发人员责任心不强，生产的Bug数多，要分析，是否为常见问题，测试是否应该覆盖，如果是用户的日常操作，而回归流程却没有纳入，要考虑测试与用户多沟通，了解用户使用习惯。
OK先到这里，上面的回答，你给几分 :-)。
曾经有一份真挚的爱情摆在我面前,但我没有珍惜,等到失去了我才后悔莫及,尘世间最痛苦的事莫过于此……o(*￣︶￣*)o