• @Q poium 目前支持selenium 和 appium ,最近将这种模式应用到了 facebook-wda 中,理论上也支持 uiautomator2 ,我想可以使用这种模式来兼容目前主流的测试库。

  • 新增:

    • 用例失败/错误重跑
    • 用例失败/错误自动截图
  • @JonnySen 基于unittest 单元测试框架的基础上,加入了一些功能,还有一些功能待完善,欢迎提建议。

  • 你想法刚好相反,框架是最灵活的,在框架的基础上扩展是容易,如果框架都无法实现,工具和平台就更不能。工具和平台解决的是 不让你写代码做接口测试

  • 如果是把你空降到一个功能测试为主的团队。 你其实可以选择做一个平台去解决他们的问题,也可以选择找出几个懂些代码来培养写框架来结束。

    首先,我不认为接口是适合每个测试的,或者每个测试都必须要参与到接口测试中的,我觉得不懂一些接口实现逻辑的话也 很难设计好接口测试用例

    做平台面临的挑战更多,如果做的没有postman 强大,测试不会用。如果做的特别强大,那么一定很难用!哈哈!

    当然,每个公司的情况是不一样!

  • 我怼过做填“写表格”自动化工具的人,鼓励大家通过代码做自动化,写代码多自由啊!可是,做工具和平台的人一定要假定一批,他们不懂代码,而且还必须要让他们做自动化的测试。然后,把自己放在一个 框架/平台 的制造者。实际情况是:

    • 谁愿意做平台的制造者?

    • 谁只愿意做平台的使用者?

    我想稍微有点追求的测试都会选择前者吧!
    😀 😀

  • @bluesmli 请把链接删除,谢谢!

  • 我不跟你们扯可维护性、灵活性、扩展性,拿一个自动化的技术实现话题你跟讨论 组织愿景 , 来! 你告诉我最广大测试同学的愿景是什么? 还是你们公司、你们团队的愿景?

  • 我帖子的标题 “读表格” 来做参数化简直的毒瘤...

    主要怼的是:

    1、用表格存参数化测试数据。

    2、用表格存元素定位。

    从我来没没说过 读数据库是更好的方案 ,哪里让你产生了理解偏差? 至于我推荐方式在我的文章和这个帖子里都有介绍。

    读表格的者 观点不就是配置简单,不用写代码, 灵活性不也应该考虑一下。难道你们实现的 读表格 只适合一种业务,一个功能?那就不要拿出秀了,别人又不能用。

  • 抱歉! 1 和 2 没看太懂,如果有例子就更好,相信也有和我一样没看懂得。

    3、我没有反对平台化,如果在平台上依然 填表格 ,我反对!也不否认协作,每个公司开发比测试多多了,他们怎么协作的?

    4、UI自动化是从功能测试用例里面提炼而来的,如果你们的功能需要用户输入大量的数据,那么是否做到了满足功能的基础,体验最好? 所以,我说UI自动化所用的数据量不大,就更谈不上要用数据库维护参数化数据? 如果是维护用例本事,那确实很大,所有用例都是数据。

    5、重复的find_elemnt_xxx当然可以通过良好代码设计和封装消除掉,灵活性 也绝对比 填表格 高!