这个是 16 年的帖子,里面用到的证书有效期只到 16 年 12 月。不大确定现在还能不能用。
还没,后面一直没有再去投入。。。
这个月抽时间把这个尾结掉。
不大明白 "用代码录制回放" 是什么意思?
Appium desktop、airtest 可以用更简便的方式生成代码,不知道是否符合你的要求?
可以看下 https://segmentfault.com/a/1190000004362731
正常来说浏览器会缓存的,只要手动输一遍,后面一定时间内就不用重复去输入了。
有个疑问,这里只提到了如何让 iOS 设备出现在设备列表中,好像没有提到如何使用 stf 控制 iOS 设备?
这是写到一半?
加精理由: 梳理总结很体系化,点赞
公司政策如此。
如果您觉得能力特别强,也欢迎投递,对于能力很强的我们会考虑适当放松学历上的要求。
持续在招,欢迎投递~
单线程 + 虚拟机,相比点点点还是有价值的吧。
而且 UI 自动化一台手机不是只能一个线程操控么,要多线程,虚拟机是个不错的选择,成本也低。
作为一个路过的同学,表示没看懂 bug 在哪里。(预期怎样,实际怎样)
建议参考其它报 bug 帖子,把内容写更清晰一点?
推动相关工作的进行,通过提升他人的工作效率,达到提升自我工作效率的目的。
为这句话点赞!
没事,这个理解。您文中提到的接口测试框架,以及您以前在社区分享过的平台、框架以及在实际项目中的实践,其实都可以分享出来的。
如同沙龙开始介绍所说,人人都是老师,人人都是学生。我们期望把沙龙打造成一个大家不仅能通过其他人的分享收获启发,也能通过自己做分享收获分享的喜悦及和其他同学交流的机会。只要您的想法有意思,工具/框架在项目中有实践落地、产生价值,都欢迎来进行分享。
从以往的经验来看,能在现场做到系统平台实际演示和甚至开源,这类极为稀少,属于可遇不可求。至今只遇到过一个技术导向型的国外创业企业有这种 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 。有兴趣过来不?