• 没事,这个理解。您文中提到的接口测试框架,以及您以前在社区分享过的平台、框架以及在实际项目中的实践,其实都可以分享出来的。

    如同沙龙开始介绍所说,人人都是老师,人人都是学生。我们期望把沙龙打造成一个大家不仅能通过其他人的分享收获启发,也能通过自己做分享收获分享的喜悦及和其他同学交流的机会。只要您的想法有意思,工具/框架在项目中有实践落地、产生价值,都欢迎来进行分享。

  • 从以往的经验来看,能在现场做到系统平台实际演示和甚至开源,这类极为稀少,属于可遇不可求。至今只遇到过一个技术导向型的国外创业企业有这种 topic 。

    原因有几个:
    1、包括唯品会、阿里在内的大公司,topic 分享公司内部都会严格把控。平台演示一般也就只能事先录制视频进行播放,现场演示由于网络、内网平台容易包含敏感信息等原因,至今我都没见到过。
    2、目前国内大部分公司对开源比较谨慎,除了有意打造技术生态或者技术品牌,大多都没怎么开源。

    这个现状暂时不大容易打破。如果您有能做到这方面的 topic,欢迎投递,来沙龙一起分享。

  • 信息量有点少,不好定位。

    建议你单独发帖把完整步骤及相关日志补充下?

  • 感谢对广州沙龙的支持!

    我们也有一直在收集小团队和落地容易的 topic ,但一直没找到合适的。如果您有兴趣,下半年的沙龙来分享一下?

  • 4 月初开始报名的,报名帖置顶半个多月了

    后续可以多留意置顶帖和公众号信息,主要通过这 2 个渠道宣传

  • 正解。目前是这样的

    现在业务同学也有提出一些想法把第一次要人工验证的工作量减少,正在在一起优化。后续有好的落地再分享出来

  • 建议楼主做个 demo 出来分享下,这样讨论起来也更具体?

  • 来来来~

  • 如果对你的测试能力有自信,可以试试投测试工程师。

  • 如果能力突出,学历要求可以适当降低。

  • 可以把整个项目上传 github 后,把 github 地址发下不?

    代码太多了,看起来比较费劲,而且好像不是很全。

    光从图片上看,我估计是由于 TestAdd 这个类重写了 unittest.TestCase 的 init 方法引起的。倒不是说重写这种方式不对,但它的重写里做了 2 个和父类方法不同的修改:
    1、父类原来是一个 method_name 是第一个参数,重写后变成了最后一个参数
    2、父类的 method_name 是可选参数,会有 'runTest' 这个默认值,但子类继承后变成了 4 个必须参数

    因此,用调用父类的初始化方法一样的方式去调用子类,是调不通的。从你堆栈上看,你用的是 pycharm 自带的 runner ,而非你代码里用的 HtmlTestRunner ,自带的 runner 估计按照 unittest.TestCase 的写法,只传了一个参数,不满足子类重写后要求传 4 个参数的要求,所以报错信息里会说少了后面 3 个参数。

    如果要更正让它兼容,可以试试
    1、 TestAdd 里面的 def __init__(self, a, b, expected, MethodName): 换成 def __init__(self, MethodName='runTest', a=None, b=None, expected=None)
    2、执行类中的用例初始化方法从 TestAdd(item[0], item[1], item[2], 'add') 改为 TestAdd(a=item[0], b=item[1], expected=item[2], MethodName='add')

    PS:不知道你学习的是什么课程,但这种继承 unittest.TestCase 后改写 init 方法并且参数数量、位置不一样的写法,还是第一次见,应该是属于一种不大专业的写法,而且参数名用了首字母大写的驼峰命名,也不符合 python 的专业命名方法(全部字母小写且用下划线分隔)。基于 unittest.TestCase 做扩展应该用类似于 https://blog.csdn.net/qq_41963758/article/details/80366507 里面的方法,只增加可选参数,不增加或改变必须参数,这样才能保证对父类的操作对子类也继续适用。

  • 可能比不上北上深,但在广州来说,是比较有竞争力的水平了。

  • 是呀,现在在 ppmoney 。有兴趣过来不?

  • 可以考虑下 了解系统设计 + review 代码 + 抽样测试?

    例如开发用的是 spring security 之类的成熟工具,写很少代码 + 配置就可以完成权限配置,与其遍历,不如直接看配置 + 抽几个不同权限不同的测试。

  • input_data.py 代码 at 2019年04月25日

    所以这是提问贴还是分享贴?

  • 这个要结合业务看。

    1、如果数据不复杂,写死可以满足,可以直接用你说的方法。简单高效。
    2、常说的数据与用例分离,数据指的是用例中的数据 (如接口测试中的 request、response),不是被测系统中的数据。如果用 java 可以了解下 testng 的 dataprovider

  • 有合适的场地欢迎推荐~

  • 大家热情超出预期,下次得找更大的场地了。

  • 人在广州,成都有心无力,还是需要成都的同学组织。

  • 不好意思,场地条件所限,再加人后面就看不清投影了。。。。。

  • 不好意思,场地条件所限,再加人后面就看不清投影了。。。

  • 不好意思,场地条件所限,再加人后面就看不清投影了。

  • 登录、加商品属于用例的前置条件,应该放在 case 的 setup (beforeTest) 里面。这不违反 case 独立原则。
    独立原则是每个 case 可单独被执行,在发贴的 case 里,登录必须是它的一部分,否则发贴的 case 无法独立执行

  • 20 条感觉有点多,不清楚具体情况不好给具体建议,但建议这 20 条要先划一下重点,找到其中 5 条以内的最关键的点。

    有几个点可能觉得不大合适,提下自己的意见:

    • 管理理念个人觉得有点偏,作为管理者管理理念更应该是怎么让团队的成员都持续得到成长。替代性这个词,我更建议改为能力的稳定性,即使人员有少量变动,团队这方面的能力能保持相对问题。这个是分工安排的范畴了,不需要人人相互可替代,关键位置有一主一副相互 backup 就好了。

    • 职业发展,技术序列跟管理序列晋升,管理岗位不多,造成了晋升无望。这个要和公司沟通好,技术序列要有更多的层级,技术发展到最后应该是架构师,而不是总监。

  • 怎么解决可以分享下?方便后人。