预计后续确定场地和议题后，会再放出报名链接，敬请留意。

感谢提醒，已修正。

$ httprunner modifySettingCrossAbroad.yml
INFO     HttpRunner version: 2.2.5
!!!!!!!!!! exception stage: parse tests !!!!!!!!!!
httprunner.exceptions.FunctionNotFound: get_cookies is not found.

方便把你的完整项目放到 github 上吗？估计是内容不全，所以我本地被另一个问题挡住了，重现不了你的问题，无法进行更详细的分析定位。

大公司内部可能有，但开源或者免费的，应该没有。而且说实话到达这种程度，和业务贴合度不会低（比如自动化就区分 UI、接口等），使用的团队为了能落地地更好，其实也必须具备对它二次开发和维护的能力了。

也许可以考虑看看一些商业化的方案，一些云测平台的商业方案可能可以做到。

应该是要转换。

repeater 内部正常只能使用 hessian 序列化的数据，当然你也可以通过二次开发让它使用其它的序列化工具。

额，这个是 15 年的工具了，底层使用的 UIAutomation 在 xcode 9 左右就已经被去掉了，用不了也不奇怪。不确定现在最新版是否有适配新的 XCUITest 。

建议寻找更新一点的 iOS monkey 工具？

这个建议直接和这位 HR 沟通吧，上传过应该不影响面试，没必要搞那么曲线救国。

如果我是面试官，知道简历用化名会有一种明显的身份造假的感觉，进而怀疑简历上其他信息的真实度，甚至考虑直接改为不录取（简历造假这个是一个比较底线的问题了）。所以非常不建议这么做。

是的，用的是 repeater 自带的 hessian 做序列化，具体算法没有去细研究，但从序列化后的文本看应该是做了一些转换的。

序列化后的数据建议还是反序列化后重新序列化成类似 json 之类的格式再加工，避免直接加工出问题导致数据损坏。

没看懂，那现在是有问题还是没问题？

名字是可以改的。

这个顶栏变成两行的，已修复了。原因是所有标题加起来字数太多，被挤成 2 行了。

从技术完整性角度，是个接口最好都做一下性能测试摸个底。

但从实际场景角度，要从几个方面考虑：
1、这个接口日常调用量大吗？不大的话是不是可以改为通过监控预警来观察性能？
2、第三方接口对接的网络链路质量满足性能测试需要吗？如果有性能问题第三方愿意配合吗？第三方给出的测试环境接口性能是否和生产基本没差异？如果这几个问题都是否定回答，那这个测试也没太大做的必要，因为做了意义不大，知道了问题但也解决不了问题。通过监控预警来观察更好。
3、从公司角度，做性能测试中的每次调用如果都得花钱，除非能说服老板性能测试的收益比这个多次调用成本要高很多，值得投入。否则我相信大部分公司领导都不大会接受这样的性能测试，要不让你自己内部模拟代替，要不找商务沟通性能测试期间特殊处理，去掉调用收费。

这个就和为啥有些公司只招本科以上一样，只能说在整个大的行业上看，非外包群体相对于外包群体，整体能力和经验会更强一些（能接触更多东西，公司内部也会更花时间精力培养），更符合大部分公司的能力要求。

所以对于部分招聘要求比较高的公司，为了提高招聘效率，会直接在这方面提出不招外包的要求。这点其实也很正常，也许会因此错过一些外包中优秀的人，但这种挖金子的成本对很多公司来说并不低，不一定能接受。

环境搭建这个，范围很大，通用性不强（不同语言技术栈搭建方式差异很大），如果只是搭建而非调优，深度也不深，所以书和博客没有系统提及也正常。

建议你不如直接把你具体想要了解什么样的环境搭建梳理一下，说不定相比 “环境搭建” 这个关键字更容易找到相关资料？

我主要想指的是，不要用 "low" 这类很明显带有贬低意思的词。

问问题 != 懒/伸手，也可能是方法不对或者没人告知好的问问题方式是什么。我们可以提供思路或者建议便于对方更正，但我个人觉得不适合去说 low 之类的词，对解决问题和提高对方都没啥益处。

想了解下，-allure 和--count 这两个参数，是从什么资料上找到并用来使用的？

从错误信息上看，程序本身并不支持这两个参数。

来参加社区沙龙、MTSC 大会，你就知道了。

简单的说，就是期望你知识水平超越公司里的大部分人，能做到公司内部需要但又做不到或者不知道该怎么做的事情。比如通过线上流量录制回放完成接口回归测试。当然，这个不绝对，也看你这个岗位具体是啥，也有可能这个要求就是个复制粘贴而来的一句话而已，不用太较真。

看了下日志，没见到啥非常有效的线索，只知道在 AndroidUiautomator2Driver.findElOrEls 抛了异常。但它具体转换成了什么 uiautomator 之类的原生框架操作语句不大清楚，不好定位。再深究得周末抽时间看源码了。

用 inspector 可以查看到 webview 里面的元素，但是操作不了

这句话有点好奇，inspector 操作不了这个可以具体说下是什么情况吗？你是做了什么动作，所以产生操作不了这个结论？

初学者有这样的问题也是正常的，不一定就是很 low 。
每个人都是从初学者一路踩坑过来的，大家还是多点换位思考把。

试下看是不是开启了系统的缩放？这个缩放有可能引起字体比控件大导致部分被截掉。

图里显示的内容不全，无法判定你用的是什么命令和报什么错，不好说根本原因是什么。把你图里面的文字都复制粘贴上来吧。

permission denied 只是表象，表明没权权限，但很可能核心是其它原因（如使用姿势不对）。建议贴图里面内容的时候，加个注释说明下你跑这段命令是想要达成什么目的，便于确认你的命令使用有没有错。

有没有 appium 的日志，能不能以代码块形式贴上来？

当项目内容/业务流/功能点很多时，效果和效率是如何权衡的

核心点和自动化回归一样，这个事情不管谁做，是不是你在上线前必须做的。如果是，那做这个事情本身就不会降低效率，最多持平。而效果肯定比不做要好。

但要留意做好宣贯，让整个团队都认为这个事情是必需要做的，工作量纳入时间排期和提测标准。很多时候开发不做自测很大的原因也是给排期时没有考虑这块的时间，所以没时间做。

另外，如果项目自测的内容确实非常多，光测试执行可能就要超过 1 天，那真的得好好想想是不是需求划分出了问题，一个需求太过庞大了。

个人意见：业务测试发展不一定要往测开或者测试架构，也可以走管理路线甚至转型产品等。

但从当前行业整体情况看，业务测试也需要有一定的技术能力。一些重复性的工作可以通过使用工具平台甚至自己写脚本提效，了解开发写的代码代表的是怎样的逻辑并有自己的判别能力，避免被开发的 “影响范围” 说得不准导致遗漏或多测。这些能业务测试测得更快更准，符合大部分公司对测试的期望，所以如果不具备就会被具备的人淘汰。

这部分能力和测开的技能部分重合，但不是说就得做测开。

就我司的实践，分享下个人经验见解：

1. 开发做更多什么类型的测试？
   ——正向的基本功能流程，或者说相当于冒烟测试类型的测试

2. 测试如何帮忙开发自测，测试需要提供什么等？
   ——冒烟测试，或者说开发自测的用例（内容写明确一点，别只是要点，免得认知有偏差后面撕逼）；造数据的脚本或者平台（特别是对于后端比较复杂的，前端不懂造数据会导致自测效率很低）；走通整体流程的一些手把手教程或培训（有时候开发只知道自己负责的一小块子模块，不知道整体流程怎么回事，我们既然很熟悉这个，可以分享下）。严格说不是帮忙自测，而是让开发更方便、更高效地去做自测，这样他们才更愿意做。毕竟开发最能产生价值的还是写代码完成功能，都想在写代码之外的事情尽可能不要花太多时间。

3. 如何去校验开发自测与否，以及自测的质量如何？
   ——用例精简到顺利的话半小时内可以全部完成，然后提测前让开发组织做一次半小时到一小时的演示（我们内部称为 showcase ），开发自己亲自执行这些自测用例，测试和产品一起看。一个是确认功能确实已经可用，测试自己也不用再花时间重复执行一遍；另一个是产品确认实现效果和他期望一致（有时候产品需求会有些没提及的模糊地带，开发可能不沟通直接自己脑补做功能，和产品期望不一样）。如果老是走不通，开发自己也会不好意思的，所以能借此促进他们自己先做好自测再演示，免得出溴。

   很多时候开发自己对质量没要求，是因为自己开发的东西自己都不用，所以对里面的问题都没感觉，磕磕碰碰能过一次就交差了。让他们自己实际用起来，自然就会发现自己开发的东西有啥问题或者哪里不好用，产生改进的自驱力。用流行点的话说就是 eat your own dog food ，各个大公司内部最新版本要求研发全员自己日常就得使用也是这个道理。

4. 第三个问题也引申一个问题，提测的标准可以有哪些？
   ——核心还是要能证明自己的代码能用，至少能走通正向核心功能，所以最低要求是上一步说的演示必须进行并且测试、产品都认为可以通过。更严格的提测标准可以在这个基础加上一些代码质量要求（如 sonar 标准、单测标准等）

不知道你这个具体是啥场景，能说下不？

很少见有这样的需要，既然都用 adb 了，基本都是在做专业调试了，没啥必要还要走公网。