前端数据专项测试

一、 专项背景

随着酷家乐工具设计迭代、服务拆分粒度逐渐细化,一个功能的实现,往往需要多方合作,涉及多个服务间数据传递、多个插件间数据传输,尤其是酷家乐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 (酷家乐质量效能)