可以看下 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 。有兴趣过来不？

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

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

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

这个要结合业务看。

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