年中从某个跨国银行项目上下来之后，稍作休息就开始了某个新项目的整备工作。这个项目据说是我司第一个零售电商项目，从前期得到的信息来看，React构建的前端Web网站，提供标准REST API的CMS平台系统，以及后端的企业级ERP系统，无疑对QA来说都是非常友好的，各种前后端自动化测试应该是可以无缝儿畅玩儿的，我甚至连怎么“忽悠”客户给我资源搭建Micoo的词儿都想好了。然而，接下来几个月发生的事情，着实让我重温了一把什么叫天真。
“两个月捏一个美的官网”
这个项目的客户是一家跨国的家电制造商，自己生产冰箱、吸尘器、烤箱、空调等各种大小家电，类似国内的美的。项目的目标是给客户在T国市场构建新的零售电商网站，用以替换其目前的低效站点，至于老站点怎么个低效法儿，这里就不细说了。我如果没有记错的话，这个项目前期准备从五月份就开始了，直到九月份才正式开始动工写代码，前期的拉扯甚是冗长。而客户挖的第一个坑就是“十一月中上线”！没错，两个月给它捏一个“美的官网”，这里的“捏”可不仅仅是换个肤拉个皮尔的简单替换前端UI，而是要实现整个零售电商的全数据量打通，包括产品、库存、价格、订单、促销等等一切周围系统。客户之所以有这个“底气”要求两个月完成这一切，是因为他们购买了一个商业的电商管理平台VTEX。VTEX以PaaS的方式提供了运营电商网站的近乎所有功能，而客户的期望就是以VTEX为核心，向上打造新的官方购物网站，向下集成各个已有的ERP系统，从而完成对老旧站点的替换。
感兴趣的同学可以去VTEX的官网溜达溜达，它目前为超过3400家网店提供服务，客户包括三星、可口可乐、马自达、尼桑、雀巢、沃尔玛、家乐福、摩托罗拉、索尼、欧莱雅等众多知名企业。作为PaaS，VTEX为其整个电商系统的各项功能提供了非常丰富的REST API接口来帮助客户对接其各自的ERP系统，从而实现生产数据的快速打通。说这么多废话（不好意思，确实是废话），目的不是给VTEX打广告，而是想让大家体会一下为什么客户觉得两个月就能捏出一个购物网站。
那么，按理来说，客户与VTEX的合作应该是郎才配女貌、豺狼配虎豹，这中间又有咋TW啥事儿呢？是的，这个问题是我们所有团队成员刚上项目时都问过的问题，答案是VTEX只希望作为PaaS的提供者给客户开个号就等着数钞票，而客户如果想要自定义某些功能或者本地化某些需求，就得另请高明，哦，对了，要实现和客户已有ERP系统的集成也是需要有人来干活儿的，而这就是TW出现的原因。一句话来说，TW是客户这个项目中的Integrator。
请不要厌烦为什么要讲这么多项目的上下文，因为正是这些上下文以及TW在整个项目中的角色引出了后来的种种问题。
九月秋风似牛刀
还记得上面提到的项目目标吗，顶层实现一个零售购物网站，其下对接VTEX平台，再下面是VTEX平台与客户ERP系统的集成，这里的集成在系统架构上由Integration Layer来实现（也就是几个微服务而已，没什么玄乎的）。还记得上面说的第一个坑吗，十一月上线，Not Movable，为什么，因为客户的底层ERP系统为了适配这个项目，需要有功能修改和部署上线，而那个ERP系统服务于客户的全球市场，有严格的上线时间窗口，最近的一次，就是在十一月，错过了，就得等下一次（什么，你问下一次是什么时候？骚年，你觉得问了有意义吗？你觉得客户会让我们苟到下一次吗？）。于是，围绕这个时间点，从架构到需求，从时间线到人员配置，各种讨论各种计划，最后的结论是：做不完！怎么办呢？带着客户砍需求呗，这不是咱TW的拿手好戏吗。于是，九月秋风似牛刀，咔咔咔几刀下去，直接把顶层的零售网站给端了。是的，你没看错，第一阶段，官方网站不做了，只做VTEX和ERP系统的集成，完成后，ERP系统单独部署上线，而Integration Layer只需要配合ERP系统完成联测验收、不需要上线。整个计划清晰明了，团队又看到了希望。
然而，正是这个“斩首计划”，给后面的开发测试工作铺下了天坑……
为了集成而做的集成
VTEX是一个后台系统，面向网店工作人员，而并不面向顾客，要想实现对下游数据系统的集成验证，就必须要有一个可以模拟顾客操作的入口，也就是能让顾客浏览商品并且下单购买。本来，这就是前端UI的功能，但现在UI不做了，那要怎么测试验证呢？这里再补充一个上下文，VTEX（公司）除了给客户提供一个VTEX后台系统（PaaS)，还在其上部署了一个测试用的购物网站，通过这个测试网站可以模拟购物下单（是的，你不用疑惑，这个测试网站就是那个被斩首的家伙……至少是前生）。
于是乎，日月轮回、星辰交替，转眼间4周过去了，项目进入了SIT阶段。SIT的头三天，连接测试。是的，请不用惊讶，就是测试客户的ERP系统和我们的Integration Layer能否联通！换句话说，在SIT之前，这俩哥们儿就没“hi”过一次，所以，我们的整个Integration Layer是在没有经过调试（就更别说什么测试了）的情况下，裸奔进入SIT的，至于结果嘛，大家就可想而知咯。
好了，如果你能坚持看到这里，恭喜你，无聊的纪实部分已过大半，接下来进入老少皆宜、人见人爱的踩坑环节。
Data Mapping
对于零售电商系统来说，数据要打通各个环节、各个系统，大量的系统集成是毋庸置疑的。数据在各个系统之间流转时，往往存在格式转换，比如最常见的订单号，用户在商城看到的可能是1002123123，它在VTEX里面对应生成的订单号则可能是VT455766768，等传递到ERP系统后，则又可能生成另一个ER9893274823的订单号，所以多系统集成时，解决这种数据转换的常用方法一定是Data Mapping（数据映射）。在这个项目中，VTEX和Integration Layer之间，Integration Layer和ERP系统之间就都存在着大量的Data Mapping。对于QA来说，校验Data Mapping是非常重要的工作，也是我们在SIT期间翻车最多的问题。具体的问（扯）题（皮）我就不一一细说了，只是给出一些可能对大家有益的Check Points：
id，很常见，也很简单，但在系统集成的时候，一定要警惕它在不同系统之间的长度限制，别问我是怎么知道的；datetime, 这货也很常见，在系统集成的时候，要留意两个点，一是有的系统可能只有date，没有time（坑你没商量），二是有的系统可能用UTC，有的系统可能用CET（商量了也照样坑你）；price, 电商系统中，价格可以给你玩儿出花来，举个例子，在我们的系统集成中：100，100.00，”100”, “100.00”, “100.000”, “10000”等价，但不同系统用的却完全不同；address, 一个地址，在不同的系统之间，有的可以给你拆成3段，有的可以给你拆成4段，有的可以给你拆成5段、6段、7段，所以，说实话，我到现在都一直认为应该把第一个想出“拆”地址的那哥们儿拖出去炮绝5分钟；associateId, associateId这个字段可能不是那么的家喻户晓，简单来说，在订单中经常会有礼品，那么礼品是怎么来的？是通过买哪个商品赠送的？就需要通过类似associateId这样的字段来指定。但是，在不同的系统之间，它的指定方式可能完全不同，比如，我可以念张三的身份证号码来指定，也可以念张三的座位号来指定等等，所以，当发现集成中有associateId时，一定当心有坑，还是那句话，别问我是怎么知道的；
集成经验丰富的同学可能会对这些问题不屑一顾：只要前期协商好契约，这些都不是问题。而作为踩坑经验丰富的QA，我想说的是，契约都是给人看的，但现实就有那些个你给了、人不看，等着现场开碰碰车，你能咋的？
踩雷式需求确认
在SIT期间遇到了一个非常郁闷的问题，前期TL、BA与客户澄清的订单流程是：下单 -> 开始配送 -> 开具发票。等到了SIT时，我们发现这个流程只对下单购买商品适用，对于下单购买服务就不适用了，比如下单购买保洁服务，就没有配送这个步骤，下单后后就可以直接开具发票了，这就导致我们的流程控制需要修改。 这是我们测试出来的结果，问客户，客户说：是的，就是那样的。顿时，我们脑海中一片万马奔腾……
之所以会出现这样的问题，原因在于我们和客户ERP系统的集成关注的更多是数据：data mapping怎么做，VTEX能提供什么样的数据，ERP系统需要什么样的数据等等，至于流程，仅仅落地在有一条基本流程能够串通系统就成功了，而缺乏更多的对终端用户发起的不同流程的全面需求确认，为什么？因为终端被砍了呀！
尴尬的UAT
生拉硬拽的SIT还没结束，UAT就开始了，而这个UAT本身就有很大的问题。我们都知道，UAT是业务团队为了验证即将上线的新产品、新功能而进行的测试活动，但这次UAT，面向用户的UI被砍掉，作为后台的VTEX又不会上线，真正要上线的仅仅是ERP系统的部分适配功能，而这部分功能在VTEX正式上线之前，压根儿就不会用到，所以对业务团队来说，这次的UAT没有任何业务价值。但是，基于客户的上线管理流程，ERP系统要上线，必须要拿到业务团队的Sign-off，所以就必须邀请业务团队来做UAT。于是乎，来自财务、运营、供应链等等不同部门的业务方受邀前来参加UAT，但当他们得知即将“验收”的对象只是一个简单的测试网站时，几乎所有人都失去了兴趣，其中一人表示“需要使用真实的支付方式才能验收”，之后就再没出席过后面几天的UAT了。好在我们的客户还是成功的定位了几名业务方成员，帮助完成了后面几天的UAT，要不然真不知道该如何收场。
在此期间，我们也是继续被坑！
长臂依赖
上面说过，VTEX是客户购买的PaaS，是整个系统的核心，TW作为Integrator参与这个项目。然而，我们的开发、测试、验收却着实受到了来自VTEX的影响。比如，经过前期的开发测试、SIT，VTEX中已经留存了不少脏数据，而我们却没有权限删除这些脏数据，能够清理脏数据的VTEX技术人员却又在SIT开始之前就休假去了，修了一个多月的假，而这期间，就因为脏数据的问题，我们第一天的UAT就被客户给毙了。又比如，UAT中盘，VTEX方在没有告知我们和客户的情况下，更新他们的数据库系统，期间出现问题，导致VTEX部分功能不可用，当天的UAT计划直接歇菜。对于这样的问题，别说我们TW，连客户自己有时都很难驾驭得了VTEX。所以，对于核心系统受控于人的项目，在做集成验收时一定要额外当心。
找正确的人做正确的事
这又是另外一个非常有（鬼）趣（扯）的事情，在和客户ERP系统集成的过程中，对方有两个关键人物，一个是S，一个是D。S掌控ERP系统的需求决策，但却并不十分清楚ERP系统的细致操作，D是ERP系统的专业操作人员，整个SIT都由D和我们进行联测，但D却不拍板任何业务问题。
- 在UAT的过程中，我们有好几个测试结果被S发现有问题，要求我们火线修复，但同样的测试结果却通过了SIT测试，这让我十分光火。后来复盘这个问题，发现SIT期间，D在和我们的协同测试中，仅仅验证了订单是否创建成功，而没有验证订单是否创建正确，而貌似只有S才会去验证订单的创建是否正确，但S在整个SIT期间却并没有做正确性的检查，只是把联测工作交给了D去单纯检查是否创单成功；
- 另一方面，S和D身处两个国家有时差，通常每天上午的UAT开始的时候，S会先到，D稍后才到。于是，有一次的UAT测试过程中，S没等D上线，就自己错误的操作ERP系统，导致当天的UAT测试失败。另一次，又是S在UAT之前的Sanity Check中操作ERP系统失误，误导我们以为被测功能出现了问题而临时取消了测试；
所以，即便是客户，也并非人人都是水木皆通。识别正确的人，让他们去做正确的事情，在系统集成的过程中尤为重要。
Lesson & Learn
回顾整个项目的SIT和UAT，各种问题层出不穷，但最核心的，从QA的视角来看，是脱离了价值交付。当项目把UI去掉、仅仅聚焦VTEX和ERP系统之间的集成时，就为测试工作的失焦埋下了伏笔。
任何时候，任何项目，测试工作都需要有明确的目标，通常这个目标就是验证明确的功能。那明确的功能由何而来？明确的功能来自于具体的需求，而具体的需求则来自于对业务的细致分析。对于零售电商系统来说，UI绝对是承载业务的最重要的起始要素。一旦脱离了UI，对整个系统的业务分析就可能是发散而无法收敛的，业务无法收敛，需求就无法收敛，功能也就无法收敛，那么QA就很难判断是否测试充分。比如这个项目，如果有明确的UI，团队就能从UI出发、以用户的视角来分析、实现与测试所有必须的功能。而离开了UI，我们是怎么做的呢？我们是从VTEX出发、以数据集成的视角来分析、实现与测试我们以为的“所有”功能。举个具体的例子，促销是所有电商系统都会涉及的功能，作为电商领域的PasS解决方案，VTEX身实现了31种基础的促销规则，如果再叠加各种过滤条件、以及叠加不同规则之间的竞争规则，单单是下单的价格计算就有上百种方式，作为Integrator，虽然我们不需要去测试验证这上百种计算方式的正确性，但我们仍然需要去获取每一个订单的促销细节信息用于和ERP系统集成，这其中的分析、集成与测试工作量都是非常庞大的，而这些庞大的工作量在客户眼中仅仅做了一件事，那就是对创建订单的数据集成。但如果从UI出发，我们就能从这上百种计价方式中限定出真正会应用到客户业务中的促销方式，从而进行更有针对性的分析与集成，能够节省大量的工作量。即便最后客户说“全都要”，那么我们也能将“全都要”的工作量给可视化出来，从而确保后续的分析、集成与测试工作都能够有的放矢。数据集成可能仅仅是一个API请求带上百种参数，在客户看来这里面没有多少工作量，但当这上百种参数化身成上百种具体的User Journey的时候，客户就能体会到其中的分量了。
所以，对那些功能强大、适用面宽广的行业级解决方案的集成，一定要落实和明确具体的功能，做到业务驱动和价值交付，否则累死三军，板上钉钉。
最后
目前这个项目还在进行当中，上面聊到的问题仅限于第一阶段的过程。当然，严格来说，这个阶段我们什么也没有交付，只是完成了一把集成。基于一些因素，我即将离开这个项目，但这里面的一些经验教训甚为有益，聊以记之。