1.支付类测试注意事项
- 1.1限额
- 1.2整数
- 1.3两位小数
- 1.4单位（分/元）
2.今天遇到一个巨坑，在进行产品验证的时候以后一定注意以下问题：
2.1情况概述
- 在支付时，一笔支付订单，创建时，金额参数=1.99，开发在向第三方发起支付请求时，后端进行浮点型数据处理时，将数据处理成了金额参数=1.98，实际第三方收付款是1.98，1.99元的支付订单却被认为是完成了的，这就造成了用户实际支付1.98元购买了1.99元的商品，造成了公司的损失；
- 金额损失倒还好说，主要是业务账与资金账就对不上了，后续账务处理非常麻烦
2.2详述
- 非两位小数不会出现问题，比如：10.00、10.10
- 两位小数会出现固定缺失一分的问题，比如：用户选择支付10.22，向第三方请求时会出现少一分的情况，实际请求金额=10.21
2.3问题根源
- 浮点型数据的精度问题
- 3419.99转化为二进制=110101011011.111111010111000010100011110101110000101
- 3419.991转化为二进制=110101011011.111111011011001000101101000011100101011
- 3419.992转化为二进制=110101011011.111111011111001110110110010001011010001
- 3419.999转化为二进制=110101011011.11111111101111100111011011001000101101
- 110101011011.111111转化为十进制=3419.984375
- 110101011011.1111110110转化为十进制=3419.990234375
- 341999转化为二进制=1010011011111101111
- 341998转化为二进制=1010011011111101110
- 3419.99转化为二进制=110101011011.111111010111000010100011110101110000101
2.4解决方案
- 浮点型数字存储及运算在进行金额相关的内容时，就是很坑爹，需要转化为big decimal，只要涉及运算，浮点型数据就是很坑爹
- 身为产品，没法解决这个问题，只能等开发处理，但是在验证时需要注意这点，及时发现问题，丢出问题给开发
- 需要了解一些开发实现的基本原理，在支付类需求的处理过程中务必保证每个环节的严谨
- 与测试开会过用例时，需要将金额用例拓展开来，以不同的金额去验证开发实现的准确性，包括整数、一位小数、两位小数、以奇数结尾的小数、以偶数结尾的小数
- 支付金额与到账金额对账
