认识达内从这里开始

web前端编程随着互联网的不断发展而被越来越多的人学习和应用，而本文我们就通过案例分析来简单了解一下，web前端编程稳定性如何维持。

一、测试

公司有一个测试团队，当大家研发完成后，后面的流程就会转到他们那边。

1)自行测试

测试团队会出一份测试用例文档，他们会给出部分需要自测的用例。

当自测完成后，再去发一封提测邮件，然后他们再接手。

之所以要自测，是因为在测试验收时经常发生主流程都跑不通的情况。

还需要让研发修改，这样来来回回非常影响效率，所以才会要求自测。

2)单元测试

单元测试是我们组内部一直在推，但收效并不明显。

好处毋庸置疑，之前专门做过分析。

上次升级Node环境版本时，因为一个服务没有连接，导致一个接口报错。

因为影响范围很小，所以也没有在一时间收到反馈。

后面与运维沟通，发现可以在线上发布的时候增加一个单元测试的流程。

在单元测试中，写一些代码验证服务是否连通，若无法连通就断言失败，从而阻止后续的构建和部署。点击测试报告，还有专门的分析页面可以查看。

需要注意的是，在单元测试中不能在数据库中增加数据，以免造成线上数据的混乱。

3)回归测试

测试组会在我们修改完BUG后，会做回归测试，不过目前是依赖人工回归。

测试组近正在研发自动化的回归，有望以后也集成到代码发布流程中。

对于一些有特殊要求的业务，测试组还会做压力和性能测试。

二、工具

有句话叫能依靠工具就不要依赖流程，能建立流程就不要依赖人的主动性。

在我们团队内部已经发布了协作流程、活动配置、Git分支管理等规范。

在制订规范后，解决了很多问题，不过如果有工具加持，那么工作效率可以提升的更高。

1)自研

根据公司业务和技术栈，我们组自研了很多工具。

榜单活动配置直接释放了4个组的人力，从原先的3天开发时间，降低到了1小时，经过时间的沉淀，活动也能更稳定。

通用配置已服务于5个小组，大大降低了开发和测试成本，不用再为一个小需求大动干戈。

BFF平台减少了接口的开发和调试成本，以及冗余的增删改查代码，加速与页面的联调。

依托VSCode开放的API，自研了一个插件，可以选中某个方法，直接从路由层跳转到服务层的声明处，便于查看源码逻辑。

2)三方

有些工具还是需要三方提供，我们或是直接使用，或是做一层封装。

在研发过程中，我们会频繁地将自己分支与测试分支合并，然后再手动发布代码。

后面将合并与发布自动关联，合并后就自动去发布代码，减少了枯燥的手动操作。

要访问公司的管理后台需要进入内网，内网会限制IP，需要先将IP加入到白名单内，才能访问。

原先是运维手动添加，但是有点工作量，后面就根据阿里云提供的接口，我们自行创建了一套管理界面。

后续增加、删除和查询都在此管理界面中操作，权限也开放给了相关人员。

3)CodeReview

CodeReview的好处在有很多人分析过，不再赘述，团队内部已举办十多场。

我们组会对比较重要且复杂的业务做CodeReview，目的是为了发现研发人员没有想到的问题。

当大家在看代码和理解其思路时，可以对写法、逻辑提出自己的看法。

还可以避免在协作时才会发现的问题，尽早解决减少损失。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。