测试务必注意的场景（临时修改后台数据造成的bug）：用户下单 待支付-》 运营人员去修改了 后台参数 -》用户再支付

业务需求场景   举例如下：

客户小王 作为购物平台的CP级会员店主账号，小王自己下单购买商品 会 获得CP销售利润，CD销售利润、CD拓客利润 。小王跟运营人员沟通好，300的价格  下单200个，

第一步：运营小张 在 2021-05-25 17:14:19 设定了 商品价格 为300，渠道毛利比例为0

第二步： 2021-05-25 17:14:49  客户小王 下单了这个订单商品

第三步： 2021-05-25 17:15:15  再去修改  这个 售价与 渠道毛利比例

第4步：2021-05-25 17:17:42  用户对刚才 产生的订单 去完成支付操作。

按照正常的逻辑： 小王下单 后未支付 ，小张 修改了后台的 参数，小王再去支付，这时 小王支付还是拿下单时的 售价价格 和  当时下单时的 渠道毛利比例 去参加计算  销售利润。

但是现在 创建订单的接口 返回的 实际支付金额 会传给 支付接口，这块 支付接口的数据是正确的。

我们再来看 销售利润，因为销售利润 由于按照正常的逻辑来说，你的销售利润计算 会拿 后台 价格维护管理列表中 商品渠道毛利比例 这个参数来计算，由于这个参数是存在数据库中 的字段，当你修改后 这个数据是会发生变化的。刚好你支付时这个价格已经变了。

所以  小王支付时 就拿到了 最新的 渠道毛利比例 参数，而不是他下单时的参数，这时就会造成了  销售利润结果错误的情况。

正常逻辑我们 计算销售利润 是取 这个 商品价格管理列表中的 这个“渠道毛利比例”，但是这种 特殊情况下，就需要对当前的数据 做一些判断与 特殊处理，必须拿到它的历史 数据来计算。

这种特殊场景 是产品需求 在设计阶段 忽略了的，本身这也是一种小概率的事件，但是偏偏就 存在了这种场景。

因此站在开发设计的角度，对于这种特殊场景下，需要拿 创建订单时的 当时所有参数 来参与计算。这种关于数据修改的场景 我们都需要注意这种bug问题，很常见，但是影响范围和后续处理的话 肯定非常麻烦。

如果是在生产环境中出现的话，那将会存在以下的影响：

1、有多少订单数据 存在这种问题，那需要排查，排查的过程会非常复杂与麻烦

2、对 用户的展示数据、用户提现金额的 累计会错误、后台展示数据 会出现错误的数据

3、修改这些数据 需要评估 对 其他统计的数据 是否会造成影响，这需要考虑到 sql表中的逻辑关系 ，这种评估过程也会比较麻烦，尤其是 多个项目组成员 一起参与的项目，后面接手的人不熟悉的情况下，对于接手的人会非常痛苦

4、核对错误的账号与订单数据，通过数据库中修改 这些数据，并且修改后 需要去核对，这个过程也会耗时，不排除修改数据有遗漏的地方

5、可能运营人员 会 对系统中出现类似问题 会感到担忧，对系统的信心与信任度下降

通过这个 业务场景故事 告诉我们，对于 下单后未支付，后台数据被修改后，再去支付 可能出现的bug，务必要引起注意，在产品需求评审阶段 就需要考虑到。

我们务必注意 临时修改后台数据 的各种 测试业务场景。

标签：场景,小王,用户,修改,下单,支付,后台,数据
来源： https://www.cnblogs.com/xiezhifei-testingtechnology/p/14846421.html