我们前端的 bug 一直是居高不下的

好难啊，感觉只能把测试用例，在业务复杂度上，完善到极致

快速版本迭代后果

1.追溯代码提交记录，合并主分支时候，少了一行代码。
这个可以用 git 比对的。和开发商量写个自动化脚本吧。

这就是设计耦合的问题。前端应该只涉及展示逻辑。
中台和前端之间应该有一个接口层，来进行交互。
PS：这只是展示不对，最多小投诉一下。看开看开。。。

前端 bug 很影响用户体验啊，影响很大

我这个是核心业务，客户投诉，大老板，cto 都能看见，影响很大，而且很明显，这种问题，上来就是，测试没测出来的锅啊

3 周 1 个版本，版本里很多新功能。。每次发版本后，几乎都有 hotfix 版本

这个不现实啊，前端测试的人少，公司大部分投入在后端测试上

1. 这各版本没有这个公式改动，所以只跑了主流程
   回归测试不能只跑主流程，要全量跑所有的回归用例。但可以根据项目情况，对小版本只跑主流程，对主要版本进行全量回归。换句话，几个版本跑完主流程后，就必须跑一次全量，如此循环。

2. 这个 avbl 场景和前端切换币对没有一毛钱关系，他是依赖于后端的
   接口测试可以验证后端，但要保证前端也是正确的，就需要把前后端或说是整个产品看做个黑盒，从 GUI 的角度，从真实用户的角度，去使用和验证产品。

3. 回归测试切换币对时，一般来说，就切换那 2，3 个币对，测试切换功能是否正常，这个时候，如果这 2 个币对杠杆倍数一致，avbl 也是对的。
   这是用例设计的问题，只设计两三组测试数据是不够的，多设计几组测试数据（不需要多设计测试用例）就能避免这种 “巧合漏网” 的现象。

4. 求助大家，像这种 bug，后续怎么测试才能保证测试到，业务上没有关联的 2 个点，因为开发原因影响到了，该怎么办
   这个案例很好地说明了基于 UI 的功能测试的重要性和必要性。测试用例设计要全面，保证覆盖度，相比接口测试，UI 测试应适当加大比重。每个版本都必须或尽可能全量执行回归。考虑自动化测试。

分享下有赞的几篇文章：

1. https://testerhome.com/topics/18751 有赞前端质量保障体系
2. https://www.cnblogs.com/finer/p/11895063.html

之前测试期货交易的时候会把前端和接口返回的参数分别遍历组合一次执行下单（我们有 2 套前端逻辑、以及公用的 1 套接口逻辑），每个单子开仓、平仓、强平、部分平仓过程的前、中、后都会校验一次系统资金状态、正确性。

多谢🙏，学习下别人是怎么做的

人多了都好做，主要就是人力不足。下单，2 种交易产品 6 个模式，5 种下单方式，2 个方向（买/卖），3 种条件，2 个触发方式，我算了下，下单有 200 多种情况，这个已经用脚本解决了。然后类似于 avbl 这种，纯前端计算，公式极其复杂，如果仅仅是针对这个公式测试，就要准备 20 多条 case，更别说还考虑上其他交互上的。然后类似于 avbl 这种，全靠 app 前端自己计算的点还有 4 个点。这些公式复杂到什么程度尼，就是这个本可以放到后端计算的，但是因为考虑计算复杂及实时性，比较占用服务端性能，所以放到前端。

下单已经做了自动化了，下完单去查数据库校验前端传参数是否正确。但是像可用余额这种，纯前端计算的，没有接口提供值做对比，自动化从界面拿到值方便，但是怎么断言这个值是否正确？自己去写一套公式不现实的，相当复杂，依赖好几个接口，ws 的推送计算得来

[但是因为考虑计算复杂及实时性，比较占用服务端性能，所以放到前端]---这个应该不复杂也不占性能。。。【应该是后端怕麻烦为了省事把这些烦人的业务甩了出去】
我比较赞同 5L 的观点，整套系统的架构确实有问题，至于避免这类问题的发生，要么加人，或者单元测试写详细点，而且单元测试你得参与（用例设计和编码）

如果是我，我会问。
算法逻辑为什么不能放后端？CPU 占用率多少？
并行计算，HPC 了解一下，如果吃得是 CPU 资源，不能用 GPU 么？
公式有大量的条件表达式么？实时性要求需要多高？各流程耗时多少？
拿数据出来说话，不要开发说啥就是啥。。。
锅来了就接着呗。除非你用户体量极大，给人力，给资源，否则你改变不了。

不是，这个确实是占性能的，因为后端已经已经计算好了某个瞬时值，前端显示需要动态的，这个要求 1s 计算好几次，而且每次上百万用户。所以理论上 1s 有 500w 次计算，其次就是 500w 次的推送，还是比较耗性能的。单元测试的事情，确实想到了，还是要看代码

我们这用户体量是比较大，android 端日活 60w，ios，30w 左右。。leader 层次都知道的，人力问题暂时解决不了