购物车测试和问题总结

因为最近项目都带了购买的需求，所以想着把购物车测试点还有遇到的问题总结一下。这样以后测购买这一块就更加娴熟。

测试环境：购物车有几个商品，

测试操作与实际结果：在查看商品详情直接点击购买后取消支付，该订单就在待付款列表中。再查看购物车，购物车被清空了。（立即购买跟购物车没有啥关系，不应该清空购物车）

测试环境：订单管理中分为：待付款，待发货，待收货，已完结订单4个状态。一个商品要是生成订单，同时出现在购买者和商家的订单管理中。其中待付款和已完结状态的订单中可以进行“删除订单”的操作。

操作步骤和实际结果：购买者在“已完结”状态订单列表中在A订单点击“删除订单”按钮后，该列表中A订单信息删除成功，查看对应A商品的商家端的“已完结”的订单列表。发现该A订单也被删除了。购买者进行删除操作，商家的列表信息也被同步删除了。

也操作过对商家端进行删除订单，相对的购买者的订单管理列表信息也被删除。

期望结果：购买者和商家的分别对订单进行删除操作，不应该同步。逻辑上订单列表中，用户一端的删除操作不能影响另一个用户下信息的删除。即订单实际做了物理删除，应该做逻辑删除，客户进行逻辑删除后，只是在列表中隐藏看不到该信息而已。物理删除是真正的删除或者清零，文件不可恢复。

测试环境：购买者买了一个A商品，订单状态在待发货中。

测试操作与实际结果：商家把A商品删除或者下架状态后，状态在待收货的A商品的订单，不能进行发货等一系列操作。

期望结果：商家把A商品删除或者下架后，还在进行的A商品能够正常走完购买流程，即A商品订单能够达到“已完结”订单列表中。实际的商品删除为物理删除，因为是商品为物理删除，正在进行的订单找不到该商品的ID，订单进行下一步操作会报错。所以删除商品也应该是逻辑删除。并且正在进行的订单点击商品详情，要有友好提示：该商品已经不存在！

后来发现，该系统购买商品付款后都是到了一个被支付账号，即被支付账号是这个做该系统客户的。所以购买商品交易成功后，钱并不是直接打到每个商家的账户。为了能够处理这种现象，我们又增加了商家端账户余额计算，并且能够进行提现的操作的模块。这个都是要产品都要考虑到。

测试都是基于需求上面。之前做过一个系统，整个系统的商品都是一个客户的商品，所以就不用考虑有“缺少商家端余额统计，能够提现”的模块，购物车也不用考虑不同公司、同一公司商品的排列。所以需求的确定还是根据用户使用方式和客户运行模式的影响