前端数据专项测试
一、 专项背景
随着酷家乐工具设计迭代、服务拆分粒度逐渐细化，一个功能的实现，往往需要多方合作，涉及多个服务间数据传递、多个插件间数据传输，尤其是酷家乐4.0与5.0这类多插件集成的复杂前端应用，如何获取服务间、插件间的数据，对问题排查尤为重要，这也是对单应用进行精准测试的前提。
二、 前端问题定位困难
酷家乐云设计工具，diy页面有30+个插件共同集成，不同的插件处理其特定的数据模块，功能实现必然依赖插件间互相传递数据，如
当需要排查插件间数据传递正确性问题时，如之前的线上故障：调整户型里的门窗位置后，吊顶设计里的模型位置出现变动。
需要检查家具插件传递给硬装的数据，再检查硬装传给家具插件的数据，以判定是哪方数据出现了问题。
2.1 常用定位方法
一般由前端开发本地起服务，进行debug，常用的前端方式有：
- 直接在代码里console.log()，将对象值直接打印在控制台
缺点：生产环境不允许，如果bug比较复杂，直接打log并不能定位到问题
- 本地起服务，在chrome扩展程序中的source进行Debug
优点：定位准确
缺点：门槛高，需要熟悉代码；费事费时间
2.2 小结
第二种定位方式，是前端开发最常用的，但是对测试来说门槛较高，导致测试缺乏有效的数据验证手段，遇到bug，基本只能求助于开发，逐渐沦为bug的搬运工。本地起服务成本比较大，对于跨组问题，谁先定位问题，就成日常甩锅现场，这并不利于快速处理问题，解决用户需求。日常测试中过分依赖环境，无法做单插件的功能测试，单纯页面功能上的校验，粒度比较粗。
所以我们需要寻找有力的方式，加强对前端数据层校验，同时提高测试定位问题的能力。
三、 借鉴后端，寻找思路
3.1 当服务端遭遇多服务数据传递问题排查时怎么办？
举个例子，一个常见的渲染异常问题，在coohom版商家后台上传的一石多面，在地面上铺贴，预览效果正常，但是渲染出来的效果都是单面瓷砖的效果。
渲染是中间数据的处理方，数据来源于硬装、材质、商品、定制等，要确定渲染异常的原因，必须一级一级往上排查，核对链路上每个应用提供数据的准确性。
排查链路：渲染 → mesh中台 → 硬装 → 材质，最终确认材质有问题，数据库中的材质数据缺少一张图。需要进一步判定，该数据丢失是存储时出错，还是上传时丢失。
通过商品brandGoodId在日志中查询到上传商品时的taskId和traceId，最终获得商品上传的请求体，最终确定是商家后台上传时，前端传的数据少了个数据。
3.2 后端常用的获取应用间数据的方式
后端获取应用间传递数据方式较多，也很普遍，这些方式并不会对应用性能、实现造成影响，且不涉及用户个人信息。
3.2.1 在chrome的开发者模式中直接获取
3.2.2 通过公司内部封装的二方包——bodyRecorder
记录request和response并上传至oss，然后通过traceId获取记录结果
3.2.3 打印日志
3.2.4 重新发起请求
对于较简单的GET请求参数，通过构造请求参数，重新请求后端，获取后端返回
小结：服务端获取数据间传递数据的方式，大概可以分为记录数据、重新获取数据两种方式，由此出发，探索前端最合适的实现方式。
四、调研前端插件的调用方式
4.1 选取合适的调研对象
想要获取插件间数据传递，必须先了解插件间的调用方式，找到关键突破口。施工图3.0中户型、硬装、软装、定制等数据的获取，均依赖前端插件数据传递，最终由施工图插件进行数据汇总和最终处理，故我们选取了施工图3.0，调研其插件调用流程，寻找突破口，获取插件间传递数据。
4.2 施工图3.0插件调用流程
打开方案时，decoration-drawing-plugin的index.ts会先加载，如果有存在drawingPlugin，会开始初始化，调用setupViewPlugin，将faceDesign和对应的key绑定，比如：
faceDesign: Symbol('deco-face-design'),planarModelingDesign: Symbol('deco-planar-modeling-design'),进一步调用createFaceDesignElement(decoration: Decoration, info: FaceDesignInfo)，
获得一个element，这个elementType为Symbol(faceDesign)，id为faceId-fd，faceDesign信息。调用createUnionBorderElement获得一个element，这个elementType为Symbol('unionBorder')，id为faceId和列举-ub，比如w_13_r, w_10_r-ub，合并的建筑面结构；点击图纸，进入模型即图纸时，drawing-view-kaf-plugin的view.ts会加载，获取getBufferedGRep2d，调用drawing-sdk，每一个iElement获取其GRep2d，此时一个iElement是一个面，id为"r_22_f-fd"；调用decoration-drawing-plugin的createFaceDesignElement里的element.getGRep2d，入参是config，根据element的id，然后调用getFaceDesignGeometries，对于3D下的铺贴，会进一步调用createLoftPavingElement下的createTilePavingElement()方法。
4.3 总结
由此可见，施工图3.0中，施工图插件与硬装图纸插件的数据传递，都是通过createFaceDesignElement这个方法。
是否可以将每次调用的数据存储起来，通过某种方式进行获取？
答：存储成本较大，且要考虑数据更新问题，代码改造成本大，且会对业务造成影响。
重新获取数据是否可行？
答：createFaceDesignElement这个方法的入参较简单，可以通过插件暴露API，再手动构造出DVConfig，再次生成硬装数据，就能获得硬装图纸插件和施工图插件间传的数据了。
五、实现重新获取数据
5.1 代码实现
步骤：
- 开发在代码中，将API暴露出来，在Hades的kaf-injection中，增加一个方法：
- 在云图/BIM环境中，就能在console里直接调用pyBellInjection.getDecorationDrawData( faceId )获取硬装数据.
- 返回数据为element.getGRep2d(config)，和施工图插件获取数据完全一致。
5.2 实现效果
Console接口里返回的geometries里有两个element，分别对应方案里的水刀和墙面图案
水刀这个element下面，会有27个geometries，分别对应水刀里的27个区域
每个区域下有对应的deepValue，用于标识层级关系，还有612个子geometries，用于描述彩图模式和线框模式下需要使用的数据，比如区域的curve形状、区域材质数据、材质偏移旋转的数据，通过这些数据，若水刀没显示，就可以判定是否硬装传递数据有问题。
5.3 单插件前端自动化
将数据保存起来，每次迭代运行API测试，保证数据的准确性
推荐阅读
公众号：酷家乐技术质量 知乎：酷家乐技术质量
TesterHome：kujiale-qa (酷家乐质量效能)