大家好，感谢邀请，今天来为大家分享一下webhook网站源码分享的问题，以及和网站官网源码的一些困惑，大家要是还不太明白的话，也没有关系，因为接下来将为大家分享，希望可以帮助到大家，解决大家的问题，下面就开始吧！
前言
最近一年多一直在做前端的一些测试，从小程序到店铺装修，基本都是纯前端的工作，刚开始从后端测试转为前端测试的时候，对前端东西茫然无感，而且团队内没有人做过纯前端的测试工作，只能一边踩坑一边总结经验，然后将容易出现问题的点形成体系、不断总结摸索，最终形成了目前的一套前端测试解决方案。在此，将有赞的前端质量保障体系进行总结，希望和大家一起交流。
先来全局看下有赞前端的技术架构和针对每个不同的层次，主要做了哪些保障质量的事情：
有赞的Node技术架构分为业务层、基础框架层、通用组件和基础服务层，我们日常比较关注的是基础框架、通用组件和业务层代码。Node业务层做了两件事情，一是提供页面渲染的client层，用于和C端用户交互，包括样式、行为js等；二是提供数据服务的server层，用于组装后台提供的各种接口，完成面向C端的接口封装。
对于每个不同的层，我们都做了一些事情来保障质量，包括：
针对整个业务层的UI自动化、核心接口|页面拨测；针对client层的sentry报警；针对server层的接口测试、业务报警；针对基础框架和通用组件的单元测试；针对通用组件变更的版本变更报警；针对线上发布的流程规范、用例维护等。
下面就来分别讲一下这几个维度的质量保障工作。
一、UI自动化
很多人会认为，UI自动化维护成本高、性价比低，但是为什么在有赞的前端质量保证体系中放在了最前面呢？
前端重用户交互，单纯的接口测试、单元测试不能真实反映用户的操作路径，并且从以往的经验中总结得出，因为各种不可控因素导致的发布A功能而B功能无法使用，特别是核心简单场景的不可用时有出现，所以每次发布一个应用前，都会将此应用提供的核心功能执行一遍，那随着业务的不断积累，需要回归的测试场景也越来越多，导致回归的工作量巨大。为了降低人力成本，我们亟需通过自动化手段释放劳动力，所以将核心流程回归的UI自动化提到了最核心地位。
当然，UI自动化的最大痛点确实是维护成本，为降低维护成本，我们将页面分为组件维度、页面维度，并提供统一的包来处理公用组件、特殊页面的通用逻辑，封装通用方法等，例如初始化浏览器信息、环境选择、登录、多网点切换、点击、输入、获取元素内容等等，业务回归用例只需要关注自己的用例操作步骤即可。
1.框架选择
–puppeteer[1]，它是由Chrome维护的Node库，基于DevTools协议来驱动chrome或者chromium浏览器运行，支持headless和non-headless两种方式。官网提供了非常丰富的文档，简单易学。
UI自动化框架有很多种，包括selenium、phantom；对比后发现puppeteer比较轻量，只需要增加一个npm包即可使用；它是基于事件驱动的方式，比selenium的等待轮询更稳当、性能更佳；另外，它是chrome原生支持，能提供所有chrome支持的api，同时我们的业务场景只需要覆盖chrome，所以它是最好的选择。
–mocha[2]+mochawesome[3]，mocha是比较主流的测试框架，支持beforeEach、before、afterEach、after等钩子函数，assert断言，测试套件，用例编排等。
mochawesome是mocha测试框架的第三方插件，支持生成漂亮的html/css报告。
js测试框架同样有很多可以选择，mocha、ava、Jtest等等，选择mocha是因为它更灵活，很多配置可以结合第三方库，比如report就是结合了mochawesome来生成好看的html报告；断言可以用powser-assert替代。
2.脚本编写
封装基础库封装pc端、h5端浏览器的初始化过程封装pc端、h5端登录统一处理封装页面模型和组件模型封装上传组件、日期组件、select组件等的统一操作方法封装input、click、hover、tap、scrollTo、hover、isElementShow、isElementExist、getElementVariable等方法提供根据“html标签>>页面文字”形式获取页面元素及操作方法的统一支持封装baseTest，增加用例开始、结束后的统一操作封装assert，增加断言日志记录业务用例安装基础库编排业务用例
3.执行逻辑
分环境执行增加预上线环境代码变更触发、线上环境自动执行监控源码变更增加gitlabwebhook，监控开发源码合并master时自动在预上线环境执行增加gitlabwebhook，监控测试用例变更时自动在生产环境执行每日定时执行增加crontab，每日定时执行线上环境
二、接口测试
接口测试主要针对于Node的server层，根据我们的开发规范，Node不做复杂的业务逻辑，但是需要将服务化应用提供dubbo接口进行一次转换，或将多个dubbo接口组合起来，提供一个可供h5/小程序渲染数据的http接口，转化过程就带来了各种数据的获取、组合、转换，形成了新的端到端接口。这个时候单单靠服务化接口的自动化已经不能保障对上层接口的全覆盖，所以我们针对Node接口也进行自动化测试。为了使用测试内部统一的测试框架，我们通过java去请求Node提供的http接口，那么当用例都写好之后，该如何评判接口测试的质量？是否完全覆盖了全部业务逻辑呢？此时就需要一个行之有效的方法来获取到测试的覆盖情况，以检查有哪些场景是接口测试中未覆盖的，做到更好的查漏补缺。
istanbul[4]是业界比较易用的js覆盖率工具，它利用模块加载的钩子计算语句、行、方法和分支覆盖率，以便在执行测试用例时透明的增加覆盖率。它支持所有类型的js覆盖率，包括单元测试、服务端功能测试以及浏览器测试。
但是，我们的接口用例写在Java代码中，通过Http请求的方式到达Node服务器，非js单测，也非浏览器功能测试，如何才能获取到Node接口的覆盖率呢？
解决办法是增加cover参数：–handle-sigint，通过增加–handle-sigint参数启动服务，当服务接收到一个SIGINT信号（linux中SIGINT关联了Ctrl+C），会通知istanbul生成覆盖率。这个命令非常适合我们，并且因此形成了我们接口覆盖率的一个模型：
1.istanbule–handle-sigint启动服务\n2.执行测试用例\n3.发送SIGINT结束istanbule，得到覆盖率\n复制代码\n
最终，解决了我们的Node接口覆盖率问题，并通过jenkins持续集成来自动构建
当然，在获取覆盖率的时候有需求文件是不需要统计的，可以通过在根路径下增加.istanbule.yml文件的方式，来排除或者指定需要统计覆盖率的文件
verbose:false\ninstrumentation:\nroot:.\nextensions:\n-.js\ndefault-excludes:true\nexcludes:[‘**/common/**’,’**/app/constants/**’,’**/lib/**’]\nembed-source:false\nvariable:__coverage__\ncompact:true\npreserve-comments:false\ncomplete-copy:false\nsave-baseline:false\nbaseline-file:./coverage/coverage-baseline.json\ninclude-all-sources:false\ninclude-pid:false\nes-modules:false\nreporting:\nprint:summary\nreports:\n-lcov\ndir:./coverage\nwatermarks:\nstatements:[50,80]\nlines:[50,80]\nfunctions:[50,80]\nbranches:[50,80]\nreport-config:\nclover:{file:clover.xml}\ncobertura:{file:cobertura-coverage.xml}\njson:{file:coverage-final.json}\njson-summary:{file:coverage-summary.json}\nlcovonly:{file:lcov.info}\nteamcity:{file:null,blockName:CodeCoverageSummary}\ntext:{file:null,maxCols:0}\ntext-lcov:{file:lcov.info}\ntext-summary:{file:null}\nhooks:\nhook-run-in-context:false\npost-require-hook:null\nhandle-sigint:false\ncheck:\nglobal:\nstatements:0\nlines:0\nbranches:0\nfunctions:0\nexcludes:[]\neach:\nstatements:0\nlines:0\nbranches:0\nfunctions:0\nexcludes:[]\n复制代码\n
三、单元测试
单元测试在测试分层中处于金字塔最底层的位置，单元测试做的比较到位的情况下，能过滤掉大部分的问题，并且提早发现bug，也可以降低bug成本。推行一段时间的单测后发现，在有赞的Node框架中，业务层的server端只做接口组装，client端面向浏览器，都不太适合做单元测试，所以我们只针对基础框架和通用组件进行单测，保障基础服务可以通过单测排除大部分的问题。比如基础框架中店铺通用信息服务，单测检查店铺信息获取；比如页面级商品组件，单测检查商品组件渲染的html是否和原来一致。
单测方案试行了两个框架：
Jest[5]ava[6]
比较推荐的是Jest方案，它支持Matchers方式断言；支持SnapshotTesting，可测试组件类代码渲染的html是否正确；支持多种mock，包括mock方法实现、mock定时器、mock依赖的module等；支持istanbule，可以方便的获取覆盖率。
总之，前端的单测方案也越来越成熟，需要前端开发人员更加关注js单测，将bug扼杀在摇篮中。
四、基础库变更报警
上面我们已经对基础服务和基础组件进行了单元测试，但是单测也不能完全保证基础库的变更完全没有问题，伴随着业务层引入新版本的基础库，bug会进一步带入到业务层，最终影响C端用户的正常使用。那如何保障每次业务层引入新版本的基础库之后能做到全面的回归？如何让业务测试同学对基础库变更更加敏感呢？针对这种情况，我们着手做了一个基础库版本变更的小工具。实现思路如下：
1.对比一次master代码的提交或merge请求，判断package.json中是否有特定基础库版本变更\n2.将对应基础库的前后两个版本的代码对比发送到测试负责人\n3.根据changelog判断此次回归的用例范围\n4.增加gitlabwebhook，只有合并到合并发布分支或者master分支的代码才触发检查\n复制代码\n
这个小工具的引入能及时通知测试人员针对什么需求改动了基础组件，以及这次基础组件的升级主要影响了哪些方面，这样能避免相对黑盒的测试。
第一版实现了最简功能，后续再深挖需求，可以做到前端代码变更的精准测试。
五、sentry报警
在刚接触前端测试的时候，js的报错没有任何追踪，对于排查问题和定位问题有很大困扰。因此我们着手引入了sentry报警监控，用于监控线上环境js的运行情况。
sentry[7]是一款开源的错误追踪工具，它可以帮助开发者实时监控和修复崩溃。
开始我们接入的方式比较简单粗暴，直接全局接入，带来的问题是报警信息非常庞大，全局上报后info、warn信息都会打出来。
更改后，使用sentry的姿势是：
sentry的全局信息上报，并进行筛选错误类型:TypeError或者ReferenceError错误出现用户>1k错误出现在js文件中出现错误的店铺>2家增加核心业务异常流程的主动上报
最终将筛选后的错误信息通过邮件的形式发送给告警接收人，在固定的时间集中修复。
六、业务报警
除了sentry监控报警，Node接口层的业务报警同样是必不可少的一部分，它能及时发现Node提供的接口中存在的业务异常。这部分是开发和运维同学做的，包括在Node框架底层接入日志系统；在业务层正确的上报错误级别、错误内容、错误堆栈信息；在日志系统增加合理的告警策略，超过阈值之后短信、电话告警，以便于及时发现问题、排查问题。
业务告警是最能快速反应生产环境问题的一环，如果某次发布之后发生告警，我们第一时间选择回滚，以保证线上的稳定性。
七、约定规范
除了上述的一些测试和告警手段之外，我们也做了一些流程规范、用例维护等基础建设，包括：
发布规范多个日常分支合并发布限制发布时间规范发布流程整理自测核心检查要点基线用例库不同业务P0核心用例定期更新项目用例定期更新到业务回归用例库线上问题场景及时更新到回归用例库
目前有赞的前端测试套路基本就是这样，当然有些平时的努力没有完全展开，例如接口测试中增加返回值结构体对比；增加线上接口或页面的拨测[8]；给开发进行自测用例设计培训等等。也还有很多新功能探索中，如接入流量对比引擎，将线上流量导到预上线环境，在代码上线前进行对比测试；增加UI自动化的截图对比；探索小程序的UI自动化等等。
关于webhook网站源码分享的内容到此结束，希望对大家有所帮助。