🎉 🎂 🍰 TesterHome 创立 9 周年纪念日 🍰 🎂 🎉

  • 项目配的有文档: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 文件, 项目中两个文件都是存在。

  • @ 文若 感谢,已修复!

  • @WangYuan 这篇分享是在前端开发过程中的实践,所以,当然是自己加的,所以,大部分元素定位都很简单,而且很可靠。

  • @reviewtiger

    1、单接口测试,通过 mock 平台,消除接口之间的依赖,针对每个接口进行测试,当然这需要开发配合对接口的调用做做一些调整。
    2、接口场景测试,就如你上面说的 A 接口-->B 接口 --> C 接口 .... 有时候接口的场景构造更复杂,通过 UI 自动化反倒简单一些,可以通过 UI 自动化覆盖这种场景。

  • seldom 的 assertPath 断言基于 jmespath 库 ,用法也很强大。https://jmespath.org/specification.html

  • 正是我文章开头提到的第一点,测试数据问题,这会直接影响接口自动化测试的稳定性。这个问题选择忽略,接口自动化失败是无法断定是 数据导致的,还是真发现了 bug。
    一般的做法:

    1. 写个 sql 脚本,在跑自动化之前,初始化数据库。
    2. 调用别的接口还原数据,比如,调用删除接口之前,先调用 添加接口。
    3. 数据银行(我面试时一个应聘者的叫法),其实就是建立一个系统来完成一些测试数据的生成。 ....

    seldom 集成了数据操作的目的也会为了解决这个问题,方便的链接数据库去构造一些测试数据。当然,这也仅限于中小规模的系统,以及测试人员对接口涉及到的表接口足够熟悉。