前言

    我们做过很多关于产品质量保证的工作和研究，产品质量保证简单地说就是我们接触最多的产品测试，大概包括从需求评审，设计评审，各阶段测试（单元，接口，功能、性能，安全等），到最后上线等一些软件工程上的环节，其实做好了上述部分，产品的质量或者软件系统本身的质量应该不会差，但我们往往会遇到，自己、团队成员或公司同事使用没什么问题，但客户使用的时候就总是这样那样的问题，包括下载更新失败，想用的某些功能失效等，以前写文章的时候提到过，一个优秀的业务或产品，只有在产品质量保证，交付质量保证，运营质量保证 3 方面做到位之后，才能使业务达到卓越运营高体现业务价值的效果，那今天就来简单聊聊第 2 个环节 - 交付质量保证

     小弟所参与的业务测试工作中一直都有ToB（面向企业用户）相关的业务，工作上经常有交付对接工作，交付到客户现场时时常出现不兼容，不支持的情况，这带来影响不仅仅是损失一个企业客户，分分钟导致同类行业的客户流失，所以做 ToB 业务的企业当中经常说到他们有精准的，优秀的 XX 行业的定制化解决方案，项目或方案依靠质量保证体系的来驱动项目或方案稳定的在客户环境中落地

    应该有小伙伴会问产品交付不是交付工程师做的吗，和测试工程师有什么关系，一般情况下交付工程师是去到客户现场来进行交付落地工作，但有些项目需要在提供服务方和客户现场方进行双方同步对接，一般情况下很多产品研发团队，尤其是创业或新团队，很少会有专门的交付工程师去做这件事，那这个重任就落在既要懂产品，又要懂技术的测（bei）试（guo）同学身上了，接下来就聊聊小弟在这方面工作的一些质量保证上的经验总结，可能有些地方是愚见，希望大家可以提点一下我，如果对的话也希望下面的一些总结会对大家有帮助

开篇

    首先还是说明一下产品交付对接工作，简单解释就是将测试通过的产品或项目在客户环境落地，并且能够正常运行同时达到客户所预期的价值，但之前在整个对接过程中总是遇到各种各样的坑

• 坑 1：客户突然间要用你的产品和项目，而且要求在很短时间内搞定，但团队没有任何准备，甚至连安排对接的资源都没有

• 坑 2：对接一些老客户，用了平常对接的方法去进行，结果对接完成之后这个功能不能用，那个功能也不能用，后来发现客户环境是一些设备较旧或相关较老的系统或版本，客户发毛了，被喷都不爱惜老客户了

• 坑 3：在对接之前客户说他们企业会有 100W+ 人用我们的产品，结果对接完之后发现我们的产品根本支撑不了客户的人多势众，客户又发毛了，被喷没能力对接大企业

• 坑 4：客户 A 喜欢用方法 A 去对接，我们开发了接口 A 来对接，客户 B 喜欢用方法 B 来对接，我们开发接口 B 来对接.............，结果对接同一个功能用了 N 多接口，开发哥哥发毛了

• 坑 5:对接的产品有功能 abcde 等，客户 A 对接完之后发现经常用 a 功能，后来重点测试 a 功能，客户 B 对接完之后经常用 b 功能，后来重点测试 b 功能.........，结果产品的所有功能都是核心功能

• 坑 N：我已经说不出话了

    不知道有同类经历的同学对于上面的坑有没有一些同感，我们来梳理一下有什么原因导致了上面的坑

主题

    上述对接过程明显是没有一个较好的规范或流程，这样是不会有质量优秀的交付对接过程，大大降低产品在客户的使用场景中的价值，所以至关重要的就是建立好一套交付质量保证体系

一、对接说明文档的建立

    说明文档的建立是整个对接交付过程的开端，说明文档包括对产品功能的说明，也包括一些对接过程的说明，一是面向客户，让客户了解我们的产品具备什么功能，对于这些功能，需要怎么的条件才能接入使用，一来提供客户对我们产品的一个熟悉程度，二来不会贸贸然一来就说所有功能都对接上，不是全部功能或接口都适合各种客户的，客户就可以结合自己的实际情况来进行对接，标准化好接口和对接方式，让客户可以在遵守对接规范的前提下进行对接，那交付对接的质量也会相对提高，说明文档在功能说明的部分可以如下面设计

说明文档比较理想化的情况就是建立开放平台，如微信公众号的开放平台

    当然对接说明文档除了给客户看，也是给自己看，除了让客户知道我们能做什么，也明确自己能做什么，不能做什么，对于团队内的协作也起到指导性的作用，毕竟不是每次都是由 A 来进行对接，也毕竟不是每个测试工程师或交付工程师都了解要对接产品，文档就是最好的协作工具

二、对接流程的建立

    有了文档之后，我们就需要有一套完成的流程明确每个阶段要做什么，比如：

    1、售前等相关负责人员发起工单

    2、产品项目组接收工单并安排工作任务

    3、建立相关对接任务沟通渠道（钉钉，QQ 等）

    4、测试工程师在提供服务方准备好交付对接的前置数据和配置

    5、交付工程师在客户现场准备好交付对接的前置数据和配置

    6、测试工程师和交付工程师进行联调部署对接

    7、测试工程师和交付工程师同时进行验收测试

    8、验收通过后交付给客户，交付完成

    9、工单确认结束，总结交付情况并记录

这是一个比较基本的交付对接过程，明确过程的每一步做什么，有谁来做，责任到位，落实到每一个负责人，每一步都是有依据的，交付过程不乱套，质量保证才可靠，同时我们可以依据流程建立一些策略和载体保证流程的执行畅通无阻

三、工单的建立

     从坑 1 那里提到，对于客户的对接任务完全无概念，不知道如何应对，也就是说不知道怎么去部署落地，所以通过工单就能很好的作为对接任务整个过程的跟进载体，所以要梳理出整个对接过程的一些环节，明确客户环境的相关系统版本，要对接使用的功能或接口，交付的时间点，跟进人，联系人以及一些备注项等，于是可以这样设计工单：

     从工单可以明显出客户的一些特征，从客户的体量和行业特征，明确一些对接时的注意事项，比如由于客户的某些数据要特殊处理，那就要避免我们某些功能导致这些数据暴露，即时你的功能在行业 A 看起来没 bug，但在行业 B 都有可能引起漏洞，所以客户的一些特征就必须得分析到位，做好相关风险评估和处理方案，这个也是高质量落地的重要环节，就像我们在产品测试中的需求评审一样，明确好相关对接方案

    明确好相关的时间点，对项目进度进行相关风险把控和安排，避免非常突然的对接任务，客户是要接入，但也要量力而行，工作量安排肯定也要合理，贸贸然地加班对接，必然会降低交付对接的质量，2 来交付对接耗时过长，肯定也会影响整体的对接效率，所以需要有明确的时间点和风险把控

    明确好要对接的功能或接口，合理的安排工作量，同时也是明确客户需求的过程，同时也要清楚客户环境的相关情况，不然又会一堆环境不兼容的问题出来

    同时明确好相关负责人，有问题或工作调整时能够精准地找到相关负责人来跟进，责任到位

    最后是对接完成后的相关记录，对接情况，以及相关问题反馈到客户和项目组

四、对接测试策略的建立

    一般在客户相关对接完之后，交付工程师或者测试人员还会进行验收测试来验证是否部署成功，同时在一些验收测试之前，测试工程师也会根据工单的说明备注进行事先的预交付测试，也就是说我们可以将交付测试工作分为交付前和交付后两部进行

交付前：

1、线性镜像测试 - 模拟客户环境进行部署并测试

    最理想的情况下，就是 1 比 1 的部署一套和客户环境一样的测试环境进行交付测试，但一样的情况下是做不到的，尤其是客户是大集群环境的机器，测试环境根本模拟不了，所以我们可以通过了解客户的环境情况，通过线性对比模拟搭建一套镜像测试环境进行交付测试，这样的测试方法是比较有保证的，同时通过测试后得到的数据预估是否能够支撑客户环境的部署

2、建立产品适用范围边界并测试

    我们无法穷举所有客户环境的情况，但我们可以指定一个范围，适当地让客户去适配，比如通过测试得到一些适用性边界：

    a、支持的最大用户数

    b、兼容的操作系统版本

    c、需要的硬件配置

    d、网络协议支持或可用性等

     通过大家熟悉的测试手段得到上面或者更多的数据，让客户和项目组了解到自己产品的一些接入条件以及支持范围，是保证有效的交付对接工作的重要手段，不然不支持的对接，严重浪费工作成本，那交付质量肯定是不高的，这些都是事前准备好的，知己知彼百战百胜

交付后：

    交付之后我们需要使用客户提供的账号或数据进行相关的验收测试，所以我们需要有一套标准的验收测试用例，针对对接的功能，执行对应的验收测试用例并得到测试结果进而判断是否对接成功，记录相关对接验收过程中的问题和情况，必要时，可以将相关固定的测试用例转变成自动化测试用例，通过执行自动化测试用例进行验收测试，降低人力手工投入和时间的成本，验收通过后再交付到给客户，客户使用的时候问题也会减少，落地成功的同时也提高了项目和团队在客户中的口碑

五、对接总结整理

     在交付对接以及交付验收测试的过程中记录的相关问题，我们需要总结分析归纳，要研究交付中是否有一些小坑是会影响到交付质量的，设计方法和策略避免问题的发生，同时有有些交付或验收测试的方法虽然能够保证交付质量，但是就需要相当高的成本，是否可以通过技术手段或策略手段来提升整体交付对接过程的效率以及质量

     同时，我们通过交付对接中记录的一些坑，作出相关的避免方法或解决方案，在下次进行同类对接的时候就可以安心躺过，提高交付质量的同时也提高交付对接的效率

     这里就是一个数据驱动的模型，通过前期积累的交付对接经验，总结出有行业特征的交付对接方案，再对接同类行业的客户时，就迎刃有余了，所以这就回到了前文提到了对某某行业有优秀的精准的解决方案，交付对接的方案也是满足客户需求的解决方案的一部分，要让每次交付对接都有意义，每次都归纳总结好，利用数据让自己优秀起来

总结

    上面的一些方法是小弟在平时的工作中所使用到的，通过上述方法或策略的建立，对项目落地到客户时候起到强大的保证作用，客户满意，我们收益，双赢

    其实作为测试人员更多地可能会在产品质量保证那一块进行测试工作，作为一名测试是可以的，但如果作为一名质量负责人那就不合格了，测试工程师最终还是会发展成质量负责人的，也就是说产品质量，交付质量，运营质量 3 方面都要牢牢把握，这里也提一个小概念：业务质量保证，业务质量不仅是说你测的 app 没 bug，或者 bug 修复的很好，而是你要知道当产品经理提出业务需求之后需求的价值体现在哪里，作为测试，作为质量保证人员，你要做的就是用什么办法或策略给业务保驾护航从而使你负责的业务体现的价值最大化，这就是业务质量保证要求的事，也就是涵盖了上述 3 个保证，所以测试这个角色是很重要的

    以上是小弟的一些愚见，欢迎大家一起讨论，一起进步，谢谢