世纪性难题：剪不断、理还乱的开发测试关系

如果说产品经理是开发人员最痛恨、最想群殴的人，那么测试人员无疑是开发最纠结、最想甩锅的人。

开发一方面需要测试人员把控产品质量，帮助他提升产品信心，另一方面又厌恶测试人员质量把控太严，导致他工作量增加，开发进展缓慢。

测试人员需要开发人员讲解系统、修复bug等，同时出于质量保障的需要，又不得不指出开发人员行为和工作上存在问题。

这就形成了开发与测试之间纠结的相互需要关系，即微妙又敏感，堪如当今的婆媳关系，剪不断，理还乱。

开发与测试之间的矛盾

俗话说，十对婆媳九不和，自古以来，婆媳关系都是一种最难协调、最微妙而又最敏感的关系。由于丈夫这个角色的存在，将婆婆和媳妇两个本不相干的角色联系起来。但是，由于双方身份上的差异，对这个共同纽带（丈夫）的有着截然不同的看法和要求。

作为创造者的婆婆天然的认为儿子是自己的一部分，厌恶别人对自己的儿子指手画脚，感性上认为自己的儿子就是好，身上的小毛病在婆婆眼里都可能是与众不同的优秀品质。

然而，作为命运共同体的媳妇本能的希望自己的丈夫更优秀、更有竞争力，主观上就会站在批判者的角度对丈夫敲敲打打、精益求精。

这直接触及到婆婆的禁忌，让婆婆认为这是对自己能力的间接否定，虽然大多数情况下，媳妇只是单纯的说自己老公几句，没有指责婆婆的意思，但是，由于双方视角的差异，使得婆婆总觉得媳妇的这种行为是在指桑骂槐、含沙射影。

日积月累，矛盾越来越深，隔阂越来越大，甚至到了一句话，就能水火不容的地步。更纠结的是，碍于双方同在一个屋檐下，任何掀桌子揭瓦的事情都会对双方造成伤害，这就使得双方处于一种斗而不破的微妙关系中。

在产品研发中，产品就是连接开发和测试的纽带，它如同是开发的儿子，测试的丈夫。产品质量差，根本原因是开发质量不过关，直接原因是测试工作不充分。

由于测试人员肩负系统上线前的最后一道岗，所以系统一出问题，项目干系人往往就会先找测试人员都是怎么测试，为什么还有问题？搞得很多测试人员觉得自己不是在背锅，就是在等待背锅的路上。

所以，明确开发测试关系至关重要。

开发和测试的正确关系

正确的的开发测试关系不应该是婆婆和媳妇那样的关系，而应该是家长和老师这样的关系。产品就是那个小孩，他是家长创造出来的，适龄后交给老师进行培养，同时又需要家长辅助培养，进而培育成材。

确定关系后，就需要明确各自工作的边界在哪里？

• 老师和家长各有各的分工，上学之前家长负责小孩的学前教育类似于开发对产品的自测。
• 入学时，老师对小孩进行入学测评，这类似于冒烟测试。
• 入学后，老师负责小孩一天中大部分的培养职责，家长在放学后辅导培养，这类似于系统测试阶段，测试主导产品质量，开发辅助测试完善产品质量（如修复bug等，这时产品保障的主角是测试人员）。

所以，想要划分开发和测试人员的工作边界，明确责任归属是一件非常有必要的事情，也是困扰过每位测试人员的烦恼。

明确工作边界

工作边界不清晰，容易导致某项工作被开发和测试双方同时忽视掉，也容易导致针对某项工作的开展，开发和测试人员出现相互推诿的现象。这一方面降低了团队的工作效率，另一方也加剧了开发和测试的紧张关系。

明确一个清晰的工作边界，明确双方工作职责所在，有助于双方达成共识。这有助于双方将更多的精力投入到自己份内的工作中，也有助于营造良好的团队协作氛围，从而提高团队效率、增进团队凝聚力。

软件测试从来不是测试人员的专利。项目测试从测试内容上可以分为单元测试、集成测试、功能测试、安全测试、性能测试、兼容测试、回归测试、验收测试等。

项目研发的一种重要目标就是提高整体效率，将不同类型的工作分配给适合的角色无疑将极大提高工作的效率。

所以项目实际工作中，通常将单元测试、集成测试交给开发人员做，验收测试交给产品人员开展，功能测试、安全测试、性能测试等交给测试人员负责。通过分工，让不同的角色更加专注自己负责的内容，从而保障工作质量，提高工作效率。

测试的目的是为了保障质量，而不是为了发现bug。由于部分开发人员对测试存在较大的认知错误，主观认为“测试的目的就是为了发现bug，找bug是测试人员应尽的职责，bug越多越能体现测试人员的价值”，从而对自己负责的测试工作不上心，系统交付测试的版本质量低劣，导致后续的测试工作重复返工，项目测试进展缓慢，投产系统质量隐患多。

众所周知，产品的质量是由项目研发的每个环节共同努力保障的。由于“完全测试”客观上无法实现以及bug发现越晚修复代价越高，单纯依靠测试人员来保障产品质量既不现实也增加了项目的研发成本。将产品质量完全压在测试人员身上，即不明智，也不科学。尽早发现修复bug，严格把控各阶段的产品质量才能有效保障产品质量降低研发成本。

冒烟测试

冒烟测试是产品质量保障由开发转移到测试的一个重要分水岭。

明确开发和测试人员质量保障范围，有助于双方界定自己的职责边界，可以有效避免相互推诿指责现象的发生，在冒烟测试阶段设置一个质量门禁。

冒烟测试前，产品质量由开发人员负责，冒烟测试后产品质量由测试人员主导。

• 这样提测质量不合格，交付测试不及时毫无疑问就是开发的责任，由开发负责和解决。
• 测试进度缓慢，上线质量差由测试人员负责，因为测试人员没有站好投产前的最后一道岗，接受了质量差的交付版本或者执行系统测试不充分，让不合格的产品投产上线。

冒烟测试做得好，交付质量有保障。冒烟测试一词源于电路板测试领域，当一块电路板组装完成后，首先要进行通电检查。如果冒烟，则说明电路板存在重大缺陷，质量不合格。如果不冒烟，则开展后续的功能测试、光学检测、飞针测试等。

在软件测试领域，冒烟测试是软件研发过程中的一种针对软件版本包的快速基本功能验证策略，是对软件基本功能进行确认验证的手段，并非对软件版本包的深入测试。

从概念上讲，冒烟测试强调响应快速，对于开发人员的提测申请，测试人员通常需要在半天至一天时间内反馈提测结果。

为什么要做冒烟测试

冒烟测试强调测试范围。 对软件基本功能的确认性验证，要求冒烟测试案例应从基本功能、正向案例出发编写。

冒烟测试强调测试程度。 冒烟测试是对当前版本开展详细测试前的预测试，不对软件版本包进行深入测试，不应将冒烟测试无限扩大到系统测试的程度。

针对每个提测版本，测试人员都应先开展冒烟测试，检测当前版本是否存在致命缺陷、版本质量是否满足测试要求、产品主要功能是否存在实现错误等现象。如果存在，则应停止进一步的系统测试，将版本包打回给开发进行修复和自测。

开展冒烟测试可以快速确认软件是否具备测试准入条件，避免系统测试全面展开后才发现存在阻塞型缺陷或缺陷太多，版本质量不稳定等问题，导致项目返工或测试活动暂停，进而影响项目按计划完工，造成人力物力的浪费。

开展冒烟测试，可以使测试人员快速熟悉系统的基本功能。

一方面有助于测试人员准确估算后续的测试工作量，合理安排工作进度，调配测试资源。

另一方面也有助于测试人员提前做好相关设备、数据的准备，为后续的系统测试全面开展做好准备。

开展冒烟测试，有助于测试人员第一时间发现产品功能与需求存在出入的问题，从而尽早暴露实现不正确的问题，减少后续的无效投入、及时止损。冒烟测试做的好，对于保障软件交付质量，提升项目测试效率都有重要意义。

开展冒烟测试的三种方式：倒逼开发、测试力担、相互妥协。

冒烟测试是一道坎，是研发交付测试质量的最后保障。

冒烟测试的目的是确保系统无阻断性缺陷，以免导致大量案例无法执行、确保交付质量达标，避免代码频繁修改导致版本质量不稳定、确保主要功能实现与需求一直，避免后续的返工重做。

所以，开展冒烟测试，重点放在主流程是否畅通、整体质量是否达标、基本功能是否符合需求描述。

如何做冒烟测试

冒烟测试可以通过手工执行和自动化执行两种方式进行，手工执行适合新建系统、重构系统、一次性交付系统的冒烟测试，自动化执行适合于系统功能稳定、优化需求少的场景。

冒烟测试过程简单可以分为4步：

1）开发人员完成单元测试、集成测试后，认为当前版本质量稳定，满足提测条件，发起提测申请。

2）测试人员收到提测申请，根据提测功能项，选定冒烟测试案例，组织冒烟测试。

3）冒烟测试执行完成，根据测试缺陷发现情况、冒烟测试案例通过情况，给出提测结论：通过、不通过、有条件通过。

4）若冒烟结论为通过，开发人员完成测试交付，测试人员按计划组织后续的系统测试等；若冒烟结论为不通过，提测版本包打回，开发人员修复问题，重新自测后再次发起提测申请。

若冒烟结论为有条件通过，则测试人员应该记录风险点由开发人员给出风险管控方案，结合风险管控方案组织后续测试。

这个过程涉及3个关注点需要测试人员注意：提测门槛的设定、冒烟测试案例的选取和冒烟结论的判定标准。

设定提测门槛

设定提测门槛是对开发人员的提测行为进行约束，督促开发人员自测，避免开发人员盲目频频繁提测，影响测试工作。

提测门槛也是测试人员对开发质量的最低要求，单元测试行覆盖率、代码违例数、圈复杂度、代码重复率、源代码安全漏洞、接口测试覆盖率等都可以用于度量开发人员的代码质量。

通过这些指标设置质量门禁，一方面可以督促开发人员编写更高质量的代码，另一方面也可以促使开发人员认真开展单元测试、集成测试等自测工作。

冒烟结论判定标准

有提测门槛，就有准出标准。致命缺陷数、冒烟测试案例通过率、一般缺陷个数等都可以作为冒烟测试准出的判定标准。

通常致命缺陷数要求必须为0，因为致命缺陷的存在势必会导致大量测试案例无法被执行，导致测试人员无法有效开展工作。

冒烟测试案例通过率、一般缺陷个数根据项目实际情况灵活设定，性能、安全等非功能性问题一般是作为风险点进行关注。

设置越高的通过标准无疑更能保障开发的交付质量，但是也极大降低了冒烟测试的通过率，势必会引起开发人员的抗拒，从而导致制度无法落地实施成为一张废纸。

所以，根据实际情况合理设定门禁，有助于双方快速达成有效共识，自觉遵守自身承诺。

冒烟测试案例选取

如何选择冒烟测试执行案例有三种思路：

• 一是随机抽检产品质量，倒逼开发自测；
• 二是梳理全链路场景用例，指导开发自测；
• 三是互相妥协，共同承担。

这三种思路的区别在于是将交付质量的压力放在开发身上还是测试身上，还是开发测试共同承担。

方案一 随机抽验产品质量，倒逼开发自测提质

抽样检验又称抽样检查，是一种重要的产品质量检验方法，指从一批产品中随机抽取少量产品（样本） 进行检验，据以判断该批产品是否合格的统计方法和理论，分为简单随机抽样、系统抽样和分层抽样三种检测方法。

这种方法同样适用于产品质量检测，通过对提测版本进行功能抽样检验，判断该版本是否满足提测质量要求。

抽样检验也可以通过简单随机抽样、系统抽样和分层抽样三种方法开展：

• 简单随机抽样是指随机抽取若干提测功能，执行相关测试用例，检验版本质量。
• 系统抽样是指根据模块功能项占比，随机抽取相应比例的功能项，执行相关测试用例，检验版本质量。
• 分层抽样是指针对不同模块重要程度，按照比例抽取相应比例的功能项，执行相关测试用例，检验版本质量。

基于抽样检验的方法，查验当前提测版本的质量，满足则通过，不满足则打回开发，重写修改至通过抽样检验。

这种方式下，测试人员相当于质量检查员的角色，开发人员承担了更多比例的项目测试工作。

通过抽样检验，倒逼开发人员想办法通过单元测试、集成测试等提高产品质量。这种方式对开发人员提出更高要求，开发人员不仅要具备实现需求的能力，还要分析到功能可能错在的各种问题。

优点在于开发自己实现的功能，最熟悉的人也是他自己。同时，通过自测也会加深对自己开发功能的了解。对应的就需要更多具备开发、测试能力的人员，所需的纯测试人员就相对较少。

方案二 梳理全链路测试用例，指导开发自测

全链路测试用例描述了系统可能发生的所有操作，全链路测试用例可以确保提测版本的质量基本功能正确、版本质量较好。

全链路测试用例可以分为业务全链路和调用全链路：

• 业务全链路是业务关联步骤组合产生的链路调用集合；
• 调用全链路是数据从请求到返回所流经的路径集合。

比如下单购物场景，登录》搜索》添加购物车》提交订单》支付》订单查看，这一系列业务操作就是一条业务链路。

对应的一条调用全链路是：用户登录》用户信息核验》搜索商品名》添加购物车》选择收货人地址》提交订单》库存比对》订单生成》选择支付方式》支付完成》查看订单进度。

需要注意的是，在微服务架构下，一个单体服务被拆分成N个微服务，这样做各模块之间相互影响较少，单个微服务的代码修改不影响其他微服务。坏处就是服务拆分后，几乎所有功能都会涉及多个服务。

原本单个程序的测试变为服务间调用的测试，频繁复杂的服务调用关系，让测试变得更加复杂。微服务模式如何测试以及测试关注点，有机会下次详细聊聊。

方案三 混合使用，兼顾双方

以上两种方式是将质量压力单方面的放在开发或测试一方，是对开发、测试中的一方提出高标准的要求。这两种方式适合新建系统很多，开发实力很强的公司或维护系统非常多，测试实力很深厚的公司。

大部分公司都介于两者之间，那么在实践中建议采用折中的方式，协调开发和测试共同承担质量压力。比如由测试人员提供业务全链路测试用例给开发人员，开发人员执行相关测试用例，所有测试用例执行通过则冒烟测试通过。

文末总结一下，冒烟测试由于其阶段短，侧重通过，往往导致开发、测试人员忽视其存在，没有利用好冒烟测试发挥作用。

冒烟测试是一个很好的质量转移的边界，通过冒烟测试后，系统质量由测试人员保障，开发人员配合测试人员开展测试工作，顺利达到测试准出标准。

通过冒烟测试前，产品质量由开发人员负责，测试人员提供辅助，开发人员通过代码分析、单元测试、集成测试等保障提测质量。

因此，将冒烟测试作为一道质量边界，开发人员保障提测质量，测试人员保障交付质量，双方项目合作，从而使软件质量在生命周期的每个阶段都有保障。

喜欢软件测试的小伙伴们，如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一 键三连哦！