1. 分步拆解 1. /cart/add

1.1.1 界面分析

在电商购物场景中，最常见和典型的就是添加购物车，根据之前选好的界面，我们来看看添加购物车接口POST /cart/add的情况。

从接口文档中我们可以知道，添加购物车需要价格、品牌、品类ID、产品ID、产品SKU等信息，数量比较大

查找添加购物车的实现：

你可以看到，你需要先获取当前的一个，然后通过包含id的对象获取相应的信息，以及可以根据这个自动获取的信息，其实我们不需要填充参数。

那么我们需要填写哪些参数来获取这些信息呢？

再次找到 （） 的实现：

从这里我们可以看到，它需要获取一个认证消息来解密它，然后获取当前信息，这就是我们在开始时需要带入请求的内容：${}：

最后，如果购物车不存在，则添加新的购物车，如果购物车已存在，则更新购物车信息;

1.1.2 接口数据构建

购物车数据构建注意事项：

至此，我们似乎已经知道如何添加购物车，并调用接口传递参数随意插入数据，但需要注意的是：

如果我们随意插入数据，接口可能会通过，数据可以成功插入，但很可能会影响其他相关服务的接口。例如，如果我们插入某个SKU的产品，而该产品已经缺货，那么下一个订单将不可避免地失败。因此，我们需要添加逻辑上真实的购物车数据。

通过梳理参数，我们可以知道购物车的数据来自两个表和：

在表中构建SKU数据时，需要注意的是，在下单时，数字必须具有库存的概念，真实库存+锁定的库存不得大于固定的总库存价值，否则订单将失败，这是构建数据的限制。

=- 也可以从源代码中看出

购物车数据构造：

现在我们开始构造数据，通过join多表查询，我们将找出表中涉及的请求字段且库存数量大于50的项目

select p1.id, p1.product_category_id, p1.product_sn, p1.brand_name, p1.price, p1.name, p1.pic, p1.sub_title, p2.sku_code, p2.id as product_sku_id, p2.sp1, p2.sp2 from mall.pms_product as p1 join mall.pms_sku_stock as p2 on p1.id = p2.product_id where p1.stock >=50 and p2.stock > 50;

保存数据：

1.1.3 脚本

1.1. 脚本调试

经过上述分析和操作后，有必要对实践进行测试，以验证脚本的正确性

好的，它顺利通过了！（其实也没那么顺利，只是我踩到了坑上，试了各种失败后才表现出一个成功~）。

在数据库中看一下，没问题，插入成功：

补充说明：在调试过程中，可以看到结果树中的数据，也可以查看对应容器的.log，进入容器，进入目录 /var/logs/

1.2 获取/购物车/列表

GET /购物车/列表

1.2.1 界面分析

由于我们每天添加购物车时都会刷新购物车信息，也可以通过购物车/列表验证购物车是否已经成功添加，所以测试一下/cart/list接口非常有意义

这个接口比较简单，只是一个get请求来获取当前用户的购物车信息：

1.2.2 脚本编写

1.3GET/购物车/列表/

获取 /cart/list/

1.3.1 界面分析

订单信息是通过购物车生成的，优惠券、积分等信息可能会在订单生成的同时涉及到，因此在生成订单时，您需要查看会员的各种优惠和促销信息。

这个接口也是一个比较简单的get接口：

1.3.2 脚本

1.4 帖子/ /

GET /购物车/列表

1.4.1 界面分析

以上是一个用于确认订单的 POST 请求接口，但从接口文档中可以看到，没有需要传递的请求参数，具体原因在源码中可以看到

找到对应的方法实现：

通过源码可以看出，程序会回到当前用户的购物车信息、地址信息、优惠券信息等，进行计算和生成订单;这也是为什么购物车相关的接口应该在整个链条的前端执行（这种情况下，只涉及购物车，不涉及优惠券积分等信息）。

1.4.2 脚本

1.//

1.5.1 界面分析

有一个接口文档可以看到，这是一个传入购物车信息，然后生成订单的接口，这里是优惠券ID、收货地址、支付类型和积分信息，源代码如下

从源码中可以看出，首先会判断 和 的空值，而 和 在刚才介绍的当前场景中是不涉及的，所以我们在向接口传递参数时不会传入和。

1.5.2 脚本

运行调试脚本时，我们发现以下失败：

我们查看了日志，发现 .该方法的第 189 行报告一个错误，并带有 null 指针异常：

这样，我们找到了源代码的位置，发现它缺少收货地址信息：

所以这里我们需要添加收货地址信息，然后使用相关的接口来构建我们需要的数据。

1.///添加

1.6.1 界面分析

根据请求参数输入请求信息。

1.6.2 脚本

由于只是为了构造数据，所以我们在线程组下单独创建一个线程，其余的都是临时的：

此外，id sum 也是通过认证信息获取的，不需要传递：

用户可以生成地址信息，因此请在 CSV 数据中设置循环以进行身份验证

传递调试验证脚本，可以创建线程结构数据

1.7 获取ID

在确认订单的接口返回值中，我们可以看到 Id

在这种情况下，您可以直接从 JSON 获取它：

订单成功：

1.8 帖子/ /

订单终于完成，最后一步付款了。

1.8.1 界面分析

从接口文档中可以看到，支付接口需要传入订单，其中有一个陷阱需要注意的是，它的参数是以 get 请求的形式传递的，后面跟着带有参数的 URL：

自然是要从确认的订单中返回值，所以还是老办法，可以得到JSON：

1.8.2 脚本

调试验证：

2. 阶段总结

至此，整个电商模型的典型购物订单场景脚本已经基本完成，总体概述如下：

以上就差不多完成了，就是还是有点接近，我们还需要对实际的压力场景做最后的调整，因为当前的线程数是一次性启动的，没有梯度的概念，实际场景是以增量的形式呈现的。

因此，为了测试得更真实，我们需要使用插件来完成需求，具体在下一篇文章中关于插件的应用。

最后：以下完整的软件测试视频教程已经整理上传完毕，有需要的朋友可以自行获取【保证100%免费】。

软件测试面试文件

为了找到一份高薪的工作，我们必须学习，以下面试问题来自阿里巴巴、腾讯、字节等一线互联网厂商的最新面试资料，并且有字节老板给出权威的解答，刷完这套面试资料后，相信大家都能找到一份满意的工作。