如果不影响测试，就别管它了

我想知道我执行的接口测试用例中，接口发送的请求是否正确

1. 直接查看脚本
2. debug 跟踪下

这种情况不适合自动化测试

如果不影响测试，就别管它了

var rstAct = apiX();
Assert.AreEqual(rstExp, rstAct);

我现在的需求是 ……看 locust 好像并不支持这样 请问我应该怎么做？

是的，locust 的确不支持这样做。
这是你的做法，而不是你的需求。
所以，你的需求是什么？

若方向不对，后面的道路将会满是泥泞。

标题给力，末尾总结到位

小伙伴基于 HttpRunner v3.1.6 进行二次开发

这个需要多少工作量？前期如何预估？后期如何评估？

今日用例评审，开发提出问题，我的用例没有形成闭环

不具备专业测试技能者难免会提出些古怪问题。

可以有两种回应。

1. 用专业的知识悉心教导，让其明白自身的不足；
2. 要求提出者打个样，看评审能否通过；

如果方向不对，后面的道路将会满是泥泞。

辛苦

眼前的黑不是黑，
你说的白是什么白

团队使用过各种各样的工具，比如 Postman、JMeter、Python Requests、Pytest、自研脚本工具等等，但总有一些不如意的地方。
主要问题是：
有些工具上手简单，但是效率不高，如 Postman、JMeter 等；
有些工具效率很高，但是有一定门槛，无法让所有成员快速上手，如 Python Requests、Pytest、自研脚本工具；

做技术的人都明白此处缺乏数据支撑，技术经理更不该有此失误。

目前实现了互联网医院项目的主要业务流程相关的业务接口集成自动化脚本维护，项目接口维护总量共计 600+ ，其中使用 HttpRunner 维护起来的自动化接口有 100+，用例 200+。定时执行，基本上能保障主流业务接口被回归遍历到，采用定时执行 + 根据需要临时手工调度的方式，每天定时分析执行结果，主要业务流程接口的覆盖让版本更新时对新版本的质量有了些许底气。

数字是最好的证明

UI 自动化，57600+ 用例，196 台执行机，10 个小时 (22:00--08:00)

从 0 到 1 是个突破的过程，有困难在所难免，俗话说 “万事开头难” 嘛
敢于尝试、勇于突破，后面会迎来自身全新的蜕变。
well done, man!

末段解释说明了这种做法并非完全可靠。
总体还是不错的，持续改进吧，加油！

历史的车轮滚滚向前

造起来！

能解决基本的接口测试，但是无法解决接口链路上的所有问题，一个工具难以支持整个过程。

5.我的测试场景是不是有缺失？
“都需要测试哪些场景呢？”
开发回答：“增删改查”

呵呵，开发靠得住吗？

Pytest 中装饰器@pytest.mark.parametrize 使用示例：
https://blog.csdn.net/sjx1111111/article/details/115519713