vue 前端,java+spring 后端
大页面嵌套了收款人页面,vue 实现
收款人页面和外层大页面有三个数据,a ,b 和 c , a = b+ c
a 和 b 可以手动输入和 从大页面点击计算带入。
c 只读,会根据带入或输出的 a-b 得出 c
大页面提交会校验大页面上的 a 和收款人里面的 a 是否相等,大页面上的 b 和收款人页面的 b 是否相等
当大页面 a 和收款人 a 不一样会提示,然后点击计算会把大页面的 a 重新赋值给收款人的 a
收款人页面,小数点精度
大页面提交按钮校验 a 和收款人 a 相等,b 和收款人 b 相等。
由于收款人页面 c 为只读,就没有做大页面提交按钮的 a=b+c 测试覆盖,并且提交会校验大页面 a 和收款人 a 相等,大页面 b 和收款人 b 相等
由于大页面 a 和收款人 a 不等时,必须重新点击计算按钮,让两个 a 相等,但是 收款人页面没有监控到鼠标移动,所以没有做 a-b=c 的操作。
提交按钮,也没有做 a-b=c 的校验,所以,当 a 第一次带入或修改 数据为:2000, b 的数据为 300 时计算出的 c = 1700,由于大页面做了改动,a 的数据从 2000 变为 1000, 提交按钮校验了:你的 a 和收款人里面的 a 不一样,你需要计算一下。 好,点击计算, a=1000,收款人页面的 a 被自动赋值为 1000 了,但是,收款人页面没有收到鼠标移动的操作,所以他没有做 a-b=c,对于 c 的重新赋值,提交也没做这个校验,所以提交之后的数据为:a = 1000,b = 300,c = 1700。
一次,不该漏测的问题,一次经验。这种组件化模块化的操作,需要在总提交按钮做一切必要的校验。
涉费逻辑一律后端校验,不能依赖前端计算和检查,不用太过考虑性能问题
另外,如果 c 是最终提交金额,也需要测试一下这个只读域的前端篡改提交(F12,删除 disabled 属性或者 http post)问题,业务逻辑写在前端都是找死行为
是的,所有涉费应该一律放到后台校验,这次真的是一个马虎造成的问题,潜意识里,校验了 a 和 b 那么 c 也应该会跟着做变动,经验不足的原因吧。吃一堑长一智,回头在给 vue 好好研究研究,这东西还是有一系列会漏测的问题的。
居然在前端进行计算。。。服气。。。
涉及金额的,我们前端都只做试算,真正入账的金额都是在后端算。因为前端或者接口,都是很容易被伪造的。
PS:你的步骤里,没有收到鼠标移动的操作,所以他没有做 a-b=c
这个没太懂。鼠标移动操作这个没太看懂。
onchange=calc(data) 或者 onblur 甚至 onmouseover 这些事件,可能后面的提交按钮绑定的事件没等这些前面的触发直接触发了……看起来用 onblur 和 onmouseover 的可能性比较大,onchange 速度快的多
涉及到金额的一定要小心且多方面验证哇
系统为内部系统,不是对外使用。所以在前端计算和校验,但是实际上应该是前端计算校验,后端也要校验金额的。这里是设计错误了,导致的问题。至于鼠标移动的问题,我没有描述清楚。vue 监控输入框失焦,页面自动计算,页面是大页面里面套了收款人页面,收款人页面需要点击才能弹出收款人的页面,vue 自动加载的那种,具体我也没太研究前端技术.....所以可能描述的不太清楚技术层面的问题。
系统为内部系统,不是对外使用。所以在前端计算和校验,但是实际上应该是前端计算校验,后端也要校验金额的。这里是设计错误了,导致的问题。至于鼠标移动的问题,我没有描述清楚。vue 监控输入框失焦,页面自动计算,页面是大页面里面套了收款人页面,收款人页面需要点击才能弹出收款人的页面,vue 自动加载的那种,具体我也没太研究前端技术.....所以可能描述的不太清楚技术层面的问题。。
我就喜欢这种前端校验的系统,轻松越过验证,可以搞一堆问题出来。
涉及到钱计算的一律交给后端,这种依靠前端计算的设计评审时候怎么过的,测试还是要知道研发的设计 实现方案,要不然背锅是少不了的
倒不是要你描述清楚技术层面的问题,但操作交互还是需要说清楚的。你这个答复还是没看懂,具体的操作步骤是什么,先点哪里,后操作哪里,这些操作效果的预期和实际有啥不同。
推动不起来,整个公司的技术部门比较败。没有需求评审,没有设计评审,用例评审都是拉群艾特人看,人看不看都不知道。边测边写用例。
OK,理解。
其实只要这些计算由服务端做,会简单很多。前端交互基本都是各种相互关联事件流,组合方式多,容易遗漏。服务端基本就一个请求一个返回,会简单很多。
只能说,收款人页面的 a 和 b 有失焦监控,失焦自动计算 a-b 得出 c 赋值。 但是因为大页面的计算按钮并不会让收款人页面的失焦监控监控到,所以当大页面计算按钮重新计算之后,收款人页面 a 变了,但是不会重新计算 a-b=c。
金额计算要在前端计算,然后后端需要做校验就行了。之前所有设计金额问题都会在后端有校验,但是这次没有做后端校验,所以导致了这个问题的发生。我理解这个应该也是测试常识,但是我没有注意到,所以我记录一下这个问题。
不至于养成不良习惯,只不过是他们的做事方式和做事准则有点不太正确,我可以在这个公司按照他们的规则来,在其他公司按照其他公司的规则来,也不至于养成不良习惯。
至于提升的话,现在有一些时间可以用来研究技术吧,业务方面已经差不多了。技术的话,这家公司测试技术太落后了,自动化一系列都没有,纯黑盒,最多使用一个 jmeter 做常规的接口测试。
这里感觉有点问题。
vue 或者 react 这些现在流行的前端框架,基本都是带有数据双向绑定的特性,即界面的数据一更新,js 里面对应的值和基于这个值计算的所有值都会立即自动更新(有个 computed 计算属性,里面固定写 c=a-b ,那 a 或者 b 有变化,c 就会自动变)。
一般用这种框架,应该不需要监控失焦这类事件来触发值变化,除非是数据没有绑定到 js 里的 data 值,导致 vue 监控不到数据变化。
金融系统的设计应该都需要考虑安全性的。后端做校验,做粗了就只是恒等式校验(比如你这个场景的 a-b=c ),没啥用。做细了基本就是再算一遍,确认和前端一样,这样又变成了重复劳动,维护成本增加。
所以大部分情况,都是前端不做计算,要计算就请求后端,后端返回计算结果。最多会做试算,但不会以此为准确值。
这个系统不是金融系统,就是普通的理赔系统,公司内部理赔业务人员使用的,所以这个金额一般都是前端实时计算(因为要给客户看或者告知客户),后端做一个金额校验的问题。偶尔还需要理赔业务人员手动计算机计算一下。
这里还真的不太清楚,vue 的情况。最近在学 js,等 js 学完了会进阶到 vue 上学一学,到时候应该就能知道这个是什么情况了。我怀疑是组件的问题。
总结一句话,涉及到金额的,以后端计算为准的,前端只是试算。
这种图快的方式,让前端做一堆计算逻辑的,对测试而言是巨坑,对整个系统而言就是存在非常大的数据安全问题,计算结果依赖前端计算是非常大的错误;