由于最近项目都带了购买的需求，因此想着把购物车测试点还有遇到的问题总结一下。这样之后测购买这一块就更加娴熟。工具
测试环境：购物车有几个商品，测试
测试操做与实际结果：在查看商品详情直接点击购买后取消支付，该订单就在待付款列表中。再查看购物车，购物车被清空了。（当即购买跟购物车没有啥关系，不该该清空购物车）操作系统
测试环境：订单管理中分为：待付款，待发货，待收货，已完结订单4个状态。一个商品要是生成订单，同时出如今购买者和商家的订单管理中。其中待付款和已完结状态的订单中能够进行“删除订单”的操做。code
操做步骤和实际结果：购买者在“已完结”状态订单列表中在A订单点击“删除订单”按钮后，该列表中A订单信息删除成功，查看对应A商品的商家端的“已完结”的订单列表。发现该A订单也被删除了。购买者进行删除操做，商家的列表信息也被同步删除了。排序
也操做过对商家端进行删除订单，相对的购买者的订单管理列表信息也被删除。同步
指望结果：购买者和商家的分别对订单进行删除操做，不该该同步。逻辑上订单列表中，用户一端的删除操做不能影响另外一个用户下信息的删除。即订单实际作了物理删除，应该作逻辑删除，客户进行逻辑删除后，只是在列表中隐藏看不到该信息而已。物理删除是真正的删除或者清零，文件不可恢复。产品
逻辑删除顾名思义，文件没有被真正的删除，只不过是文件名的第一个字节被改为操做系统没法识别的字符，一般这种删除操做是可逆的，就是说用适当的工具或软件能够把删除的文件恢复出来。 物理删除是指文件存储所用到的磁存储区域被真正的擦除或清零，这样删除的文件是不能够恢复的。
测试环境：购买者买了一个A商品，订单状态在待发货中。class
测试操做与实际结果：商家把A商品删除或者下架状态后，状态在待收货的A商品的订单，不能进行发货等一系列操做。登录
指望结果：商家把A商品删除或者下架后，还在进行的A商品可以正常走完购买流程，即A商品订单可以达到“已完结”订单列表中。实际的商品删除为物理删除，由于是商品为物理删除，正在进行的订单找不到该商品的ID，订单进行下一步操做会报错。因此删除商品也应该是逻辑删除。而且正在进行的订单点击商品详情，要有友好提示：该商品已经不存在！软件
后来发现，该系统购买商品付款后都是到了一个被支付帐号，即被支付帐号是这个作该系统客户的。因此购买商品交易成功后，钱并非直接打到每一个商家的帐户。为了可以处理这种现象，咱们又增长了商家端帐户余额计算，而且可以进行提现的操做的模块。这个都是要产品都要考虑到。
测试都是基于需求上面。以前作过一个系统，整个系统的商品都是一个客户的商品，因此就不用考虑有“缺乏商家端余额统计，可以提现”的模块，购物车也不用考虑不一样公司、同一公司商品的排列。因此需求的肯定仍是根据用户使用方式和客户运行模式的影响