本来打字说原因，后来发现写过一篇文章。直接贴给你。https://mp.weixin.qq.com/s/x9r9ryNu4Ha30lJkWWSavA

seldom 官网也有 seldom vs pytest 对比：https://seldomqa.github.io/introduce.html

docker-selenium 提供了 selenium 的运行环境（包含浏览器和驱动）： https://github.com/SeleniumHQ/docker-selenium

至于 selenium 脚本，因为这个脚本时长需要改动，想不到放 docker 的目的； 更应该考虑 集成 CI 吧~！

seldom 应该是非常适合你的！

1. 同样基于 unittest 单元测试框架， 对于你来说几乎无成本。

2. 接口测试非常需要数据驱动，seldom 提供的数据驱动：支持 class_data() 装饰类、data() 装饰用例， file_data() 支持 json\yaml\excel\csv 文件。 api_data() 支持接口数据，甚至数据驱动文件可以做环境区分。

https://seldomqa.github.io/getting-started/data_driver.html

1. 集成 XTestRunner 定时化报告，美观不输 allure（unittest 也可以直接使用 XTestRunner）
   https://github.com/SeldomQA/XTestRunner

2. 楼上提到平台化，seldom-platfrom 可以将 seldom 自动化代码解析映射到 Web 平台上，

https://github.com/SeldomQA/seldom-platform

看不出它的优势在哪里？

结合了框架和平台各自的优势： 用框架写用例，我认为是优势； 用平台 展示用例，执行用例是优势。（相反，尝试用平台写用例，解决复杂的用例更复杂，我不认为是优势。）

省了哪方面的时间？

这套方案，相比其他自动化方案 可能没有什么节省时间上的优势；

谁是你的目标用户？

需要做自动化的测试团队。

懂代码的还是不懂代码的？

必须懂代码啊~！不懂代码咋写用例？

我来简单介绍一下背景：
接口测试平台我们做了三版，文章有介绍过：https://testerhome.com/topics/20084

对于我们公司的业务测试来说都不算好用，虽然第三版比较强大，但编写复杂的场景测试，需要借助辅助功能写很多 py 函数（类似 httprunner 的 debugtalk.py 文件里实现函数）

那既然用平台还不是要写代码，为什么不全部写代码？ 于是，全部业务测试开始使用 seldom 框架编写用例。使用 gitlab 管理 接口自动化项目。 我们公司的业务测试是乐于接受这个方案的，面试的时候就考察了编程能力。 --- 你本地使用 pytest/unittest 写自动化，难道不会 debug 吗？

业务测试人员用 seldom 框架写自己负责模块的用例， 不受制于平台的功能限制（代码可以随意安装扩展库）--- 这对我们来说就是优势。 这也是框架 本来的优势。

你们可能又想，我们写好了代码 集成 jenkins 上面不一样可以 自动/定时触发执行，生成结果。

那 seldom-platform 平台的优势可以自动解析和展示每一条用例。统计历史执行结果； 我们公司基于 seldom-platform 的思路做了 产线拨测 系统； 那用例需要审核， 创建任务的时候可以选择 test_a.py 文件的一条用例 和 test_b.py 文件的一条用例... 这种管理用例的粒度，jenkins 估计做不到吧？ --- 这不是刚好发挥出了 平台 应该的优势吗？

适合自己团队的就是最好的。

另外再说一下：
seldom-platform/seldom 解决的不不单纯是接口自动化问题；可能文章大量提到了接口案例，误以为就是为了解决接口问题的；seldom 支持 web/app UI、接口，写什么用例都可以；多复杂的场景都可以；这个框架的优势； 并不影响 seldom-platform 对用例的解析和展示。 --- 这是一整套 自动化的解决方案。

你只看我抛出的问题，没看看 seldom-platform/seldom 方案？ 你说提到的问题是 seldom 框架中实现的，怎么实现取决于你的业务和方案； seldom-platform 只是用于展示、解析、和执行用例，并不限制你用例如何写。

首先，感谢 @taylortaurus 发帖：

我来补充几点说明：

1. 虽然图中的截图是 接口自动化项目。但理论上通过 seldom 编写的各种类型的测试都是支持的， Web/App UI 自动化测试也可以； 不过 App 测试环境相对复杂，比如 后端需要 启动 appium server 。

2. 图中解析用例 不是单纯的 把目录下的文件/类/方法 解析出来，一个项目中 有各种.py 文件，比如 common/utils 放的公共模块， 甚至在测试类中也有 普通的 不以 test 开头的方法， seldom 可以做到只解析测试用例。

3. 用例解析不依赖 seldom-platform ，这是 seldom 框架的能力； 比如，我们公司 后端用 go 调用 seldom 命令来解析和执行用例。

4. seldom-platform 是开源项目，有些人参与了走了，有些人贡献了想法，有些人贡献了代码，非常希望更多人参与贡献想法和代码； 你看不上 UI 可以自己 fork 分支，重写 前端/ 后端都是可以的。

好的轮子是需要时间打磨的。引用前两天在知乎看到的观点；
你想造一个满足 特定 项目 的特定场景轮子很简单；
你想造一个满足所有项目的特定场景的轮子有点难。
你想造一个满足所有项目的所有场景的轮子就很难了。
拿我自己维护的 seldom 框架为例：框架封装了 MySQL 数据库的调用，本来我们公司只用 MySQL，甚至我待过的公司都用的 MySQL, 但是，有人 就要 用 Mongdb，还有人要用 SQL Server...
随便造个轮子自己用用无所谓；如果想开源，想给所有人用，那么就要做好长期投入的准备。
社区里大部分项目都是开源三分钟热度的那种！seldom 敢说不是，虽然 不完美，有一些天生缺陷；但一直在迭代；已经满足了自动化测试的大部分需求；
与其自己造轮子，不如参与到一个轮子的开发中。
SeldomQA 包括框架和平台，是自动化测试的一整套解决方案（今年已经在我们公司落地）。
https://github.com/SeldomQA
希望更多人参与进来~！我会毫无保留的和你们交流 经验 和 设计思想。

第 1 个问题可以参考这篇文章：https://www.cnblogs.com/fnng/p/15554203.html

你在用 pytest 框架 写 自己的 业务测试用例，并且 对 selenium 的 API 做了简单的封装，并使用了 PO 设计模式。

框架设计 被用烂了，作为公开框架，应该具备：

1. 框架提供独立的安装，pip 安装 或 exe 安装程序，或别的独立的安装程序。至少应该和业务代码剥离吧！

2. 框架的版本号，有版本号才能更好的迭代和维护。

3. 框架的 API 和 文档，如果是给别人用的话。

-- 无意冒犯，只是更正一下业务代码的设计 和 框架设计 的区别。

@ 不声不响 这里不讨论 quick 平台的功能，他仅用于学习，很多功能没有，也不稳定，可以社区的其他接口测试平台。

备注：关于测试平台，我们有一些新的想法，可以留意这个项目：https://github.com/SeldomQA/seldom-platform

我们测试平台做了三版，我之前有文章做过介绍，第三版类似于 httprunner 的 web 版，http://testerhome.com/topics/20084

今年重新用回框架，我们公司的接口自动化流程比较长也挺复杂的，例如 获取一些 token 信息（不仅仅登录），用到一些数据加密，需要通过秘钥链接查询数据库。UI（web 界面的功能）不能完全满足需求，为此用 python 写了大量的函数（类似 httprunner 中的 debugtalk.py 文件作用），在用例执行的过程中调用。当然，这些东西都可以 web 设计到系统了。但总之，开发平台的人力不足，业务测试团队又觉得难用，所以，使用率一直不高。

另一个很重要的诉求，测试人员自己需要成长空间。他们更愿意通过框架更加灵活的编写测试用例，也更能从编程中得到技术提升，从而带来一些成就感。改用框架之后，积极性都高了很多。

seldom 有强大的参数化（@data()/@data_file()）功能，其实可以很大限度降低编写重复的代码。所以，对于熟悉编程的同学，编写接口自动化的效率是高于通过平台去创建用例的。

当然，我们也并未完全抛弃平台，平台的主要作用是拉取项目代码 在远端执行，并解析报告在平台上展示。也可以通过平台执行测试。

总之，这是一个目前双方都接受的方案

1. 测试人员可以开心的写自动化用例。
2. 测试 leader 可以通过平台看到他想要的数据。

这肯定不适用于所有公司、所有团队。

1. seldom 2.10.0 发布，同步用法更新到了 https://github.com/defnngj/seldom-api-testing 新项目

2. seldom 不是一个开源之后不管的项目。近三年发布的版本：
   https://pypi.org/project/seldom/#history

3. 越来越多公司的测试在用，问题和 bug 的处理速度很及时。也有其他其他开发参与到了项目中，当然希望更多人加入。

谢谢关注和使用这个框架的同学。

@kingTester 先跑到我的 poium 下面评论 这不是 page object ，搞笑（欢迎给我科普一下什么才是 page objects ）。 然后，又跑到这里 恶意 评论。 seldomQA 相关项目都是开源的，哪里得出的结论 需要报培训班才能用一说？

你想太多了， 压根不需要考虑异常捕捉，不然干嘛用 unittest 单元测试框架。自己直接写代码做测试不就好了。

之所以用测试框架，说明这些事情都框架都给我们做了。当用例错误/失败，框架自动抛出异常，并且不影响下一条用例的执行。 并且最终帮你统计成功/失败/错误的用例数。 自己写异常捕捉没啥意义。

如果是想在用例失败的时候截图，那么需要 和 测试报告结合，不然截图放某个目录下面也好找和用例的对应关系。

推荐 XTestRunner，自动截图：https://github.com/SeldomQA/XTestRunner/blob/master/docs/test_type.md

@ 李健彬 首先，确保 seldom 大于 2.4.2 版本，否则，不支持列表嵌套 字典。

• json

{
"release": [
    {
        "pageId":18,
        "pageVersion":4
    }
 ]
}

• seldom

@file_data('data.json',key='release')
def test_aab(pageId, pageVersion)：
    pass

备注： 参数中的 pageId 、pageVersion 并不需要和 json 中的名字对应，但参数顺序有严格要求。

你也可以写成下面这样：

@file_data('data.json',key='release')
def test_aab(pId, pVersion)：
    pass

@A_延林 seldom 2.4.0 支持了打标签功能， 参考文档： https://github.com/SeldomQA/seldom/blob/master/docs/advanced.md#%E7%94%A8%E4%BE%8B%E5%88%86%E7%B1%BB%E6%A0%87%E7%AD%BE

@wiggins 去项目下面提问哈！ 给出详细的例子和错误描述：https://github.com/SeldomQA/seldom/issues

接口测试用例代码 非常模板化，我的意思是只要了解接口（HTTP）的规则，手写 和 生成其实没有区别。1. 手写就是复制、粘贴改。 2、用工具生成，抓包或 浏览器工具 复制 curl 转代码。 难度上：都没有难度，效率上：都差不多。

当然，如果你说的是自动录制回放的，那是另外一条玩法了。

项目配的有文档：https://github.com/SeldomQA/seldom/tree/master/docs ， 打标机制是什么？可能不支持。

打包上传 pypi 漏掉了，.whl 文件， 已经在2.2.4 版本修复。

有问题去项目下面提问，更及时得到反馈。
https://github.com/SeldomQA/seldom/issues

中秋节快乐！

@Thirty-Thirty 我之前的那篇文章以及下面的讨论，已经比较充分的说明了我的观点，个人更倾向于 每层做每层的事情。 如果不按照自动化分层的思想来，我可以在跑 UI 自动化的时候去验证数据库。 或者跑 UI 的时候，启动一个服务监听抓包，顺便也把接口给测试了，行不行？当然可以！这只是手段，目的是保证质量，发现 bug。

我之前的场景是接口用例后置，就是接口提测之后，边写接口自动化用例边测试，这个过程中会读接口代码逻辑 + 验证数据库，但是自动化用例里面没有操作验证数据库的逻辑。 后续就可以愉快的跑接口自动化了，每次迭代新增接口自动化用例。从经验来来，接口自动化失败一般是接口删除、修改导致。几乎没有遇到过，接口告诉我成功了，但是压根就没有更新数据这种低级错误。 如果我遇到这种问题，我会把他扼杀在我编写接口用例阶段。

最后，我认为单元测试更适合验证数据库。已 django 框架为例：
https://docs.djangoproject.com/en/3.2/topics/testing/overview/

最后，上面引用微信接口的例子确实不当。

支持标准的 pip 安装：

pip install seldom

setup.py 有引用 description.rst 文件， 项目中两个文件都是存在。

@ 文若 感谢，已修复！