先表达一个个人观点：OCR、NLP 个人觉得严格意义上不属于 AI ，我更偏向 AI=机器学习，而非 AI=算法 。

然后，针对你这个维护成本问题，想先问几个点：

1、经常在调研题型里面，会有改动，导致元素定位不准确 ，这个改动是怎样的改动？非自动化的人工用例，对这些改动是怎么适配的？
2、你想核心解决的点，是元素变动后脚本可以做到无需人工维护自适应，还是从人工用例直接转换生成脚本？这两个点技术关注点是不一样的，前者关注的是元素识别的容错性，后者关注的是自然语言的语义识别。我看你前言是第一个，正文变成了第二个，没太看懂你的核心关注点是啥。

个人对于这种基于 NLP 生成脚本的，不是太感冒，核心原因是日常接触中，人工用例会写得非常详细，详细到达到 “是个人都能执行” 的并不多，大部分实际操作步骤都需要自行脑补或者问人。连人都无法准确判断的，NLP 就更难了。而且写得很详细的用例编写成本并不低（参考 BDD 写法的用例，详细到每个具体操作步骤了，但编写成本也高了很多），从投入产出比角度并不划算。

在 ios 系统限制下，除了 appstore 以及企业证书签名包（现在已经很难买到企业证书了），没有包是可以安装到任意手机的，都需要先把手机信息登记到开发者证书，然后用这个证书给安装包进行签名，认证这个包在这个手机上跑，是经过开发者和手机拥有者确认的。

由于这个机制的存在，意味着你就算找到了一个已经编译好的 wda 安装包（网上确实有这样的，有的开源项目自带的单测里有记录这个包，比如这个地方），也必须重签名才能安装到你的手机上，否则会在安装时由于 ios 系统限制直接不允许安装。至于重签名是否有 windows 版工具可用，我暂时没有见到。

另外：
1、windows 安装 ipa 到手机上，tidevice 也支持，tidevice install xx.ipa 就可以。如果不清楚 tidevice 的可以百度一下。
2、wda 不需要每次使用都编译的，使用的时候用 tidevice 启动手机里装好的 wda 就可以了，只有首次安装的时候，如果没有编译过需要编译。如果你手上有已经签名好的 wda ipa 包，也是可以直接不编译直接安装的。

PS：我们现在能享受到的非 mac 可以安装/启动应用的福利，背后其实都是逆向 xcode 相关通讯协议，然后换种能多平台运行的语言重写，让 ios 系统觉得这个就是 xcode 得到的产物。重签名这个涉及到安全（签名本身就是为了保障应用的可靠性，重写后你想加啥料都可以，带来的影响甚至可能比XcodeGhost要大），可能没那么容易被逆向，而且这个很有可能会把开发者带上法庭甚至监狱，所以估计也没人会公开出来吧。

刚试了下，貌似是用不了。之前这个功能基本没用过，一直没发现这个问题。。。

你先 github 记录个 issue ？这周事情比较多，估计得下周才有空研究。

临时用的话，可以找开发帮你装一个，你后面就可以用了。

但如果要深入，还是建议你想办法搞个苹果系统，黑苹果也可以。ios 自动化深入点的话，还是离不开 xcode 。

刚看了下，默认数据的问题。默认数据没有 id，而搜索要求用到节点 id。

刚修复了，你更新下代码重新跑应该就没问题。正式项目里添加节点后，id 是自动生成的，所以也不会有问题。

这个你得通过 logcat 找到这个应用启动失败的具体报错信息，然后再针对性解决。没有通用解决方法。

这个是机器翻译的么？有些文字读起来好怪异，比如

JCov 是一个测试框架不可知代码覆盖工具

以及

它是 JUnit 的 Python 端口

和 android sdk 无关，是一个 appium 自带的应用启动失败。一般和系统兼容性有关。

可以先换台机器试试，还是不行的话，把各个工具的版本号和完整的日志（不要只是报错那一小段，发完整的）发一下吧。

如果是单纯获取网站所有接口列表，简单接入 swagger 就可以获取到。但这个没啥意义，因为不是所有接口都是直接可以成功调用的，必须参数符合内部逻辑要求才行。

一般单个接口测性能测试，除了调用接口，还要提前构造数据、确认参数组合等，不是能调用就能压测的。你这个 “感觉” 有点太理想化了，可以先再仔细分析下吧。

这个地址打不开呀。。。

大家还是分享学习成果吧，我理解楼主初衷也是想大家分享知识，不是分享网址。。。

从方式上，可能线上流量录制回放比较接近你的需要，里面参数基本都是真实有效的，而且只要日活不低，覆盖率也不会太差。实际上大会上也有见过讲流量回放的时候，提到其中一个扩展使用场景是压测的。

但没明白做个性能测试，为啥要遍历全部接口？

理解。
提个小建议，这么简短的文字估计没法让这类不合适的候选人有产生要改变的感受，而且也容易引起歧义（比如走向另一个极端，不去听任何分享）。建议写个详细点的文章来说吧。

好奇为啥会突然有这样的感慨呢？

你现在看的是商城类的，业务和测试领域差异比较大，你比较需要补的应该是业务领域知识，直白点说就是测试工具的设计思路。

可以想想现在测试工作有什么需要帮助的，比如哪些地方效率低，是否需要做一些测试工具平台辅助。典型的像接口测试平台这种。

PS：如果你出发点是帮助测试工作，建议先想有什么需要帮助的，大概要用到什么技术，再去学习技术。先学习技术，容易陷入手里有个锤子，什么问题都想用锤子解决的倾向。

开发不适合我。。。以前在学校有做过开发类的活，明确了自己兴趣不在这块。

楼上说的非常清晰了，我只补充一个小点：文档积累也会有过时的问题，可以推荐每一个新人在看完文档实践完后，多吐槽甚至直接可以动手去优化文档（担心会改乱的可以弄一些简单的审核机制，改完后导师确认下改动点没问题再发布）。

新人才最知道新人需要什么，所以新人文档，新人参与会很好避免文档发挥不了作用的问题。

哈哈，不错。

保持自己习惯就好，个人喜欢辩证地看东西多一点，所以不大喜欢太绝对的东西。不过观点无对错，期待你后面对楼上说的基于 k8s 支持做流量回放的成功案例分享。

前辈客气了，我还有很多需要学习的，称不上大佬。

这。。。那就转给硬件测试工程师好了。

可以找你 leader 反馈下这个问题，也一起探讨下有什么方法可以优化。

可以先问下给你任务的人他对任务的期望，以及说明你缺少这方面经验，需要一些指导协助？能给你这个任务，这个人应该不至于完全对这个任务一窍不通。

虽然从描述看应该是你本质工作之外，但也不妨看做是一个公司提供的带薪学习硬件测试的机会？

不错的分享，点赞。社区里阿里的同学好像越来越多了呀。

代码怎么快速上手这个，我自己以前也总结过，确认目的->找到对应功能的出入口（比如 controller 层）->从入口开始阅读，期间同时记录 uml 时序图。过程中持续了解用到的框架功能（java 工程有挺多功能是某些框架自带，所以直接看代码体现不出来的，而且框架姿势使用不对也非常容易出 bug ），大体差不多。

点个赞，能在比较大的年纪且测开已经有一定成就的情况下，转开发并坚持下来，Respect！

业务维度，测试站在最底层，对于架构设计的理解是欠缺的。很多好的工具和平台，是在开发过程中造出来的，不参与其中，不知创新的点。现在也在提倡研发效能，如何提升？

对于这个点，个人也有同感，我们常看到的研发效能提升，我个人理解更多其实只是做质量赋能和测试阶段的提效，对于研发流程里面实际耗时最长的开发阶段，提效可能不是那么明显。想问下楼主目前接触开发后，对这个点有什么新的想法可以供测试同学参考不？

这个有点绝对了吧。

流量回放无法解决未上线新功能测试的需要（没有流量可录制），对于接口调用频率不高、数据安全性要求高的 ToB 类业务也不见得适用（流量不足以覆盖大部分场景），还是有自身的局限性的。只是他相比手工写自动化脚本，自动化成本降低很明显，所以比较受欢迎，应用领域也更多是有大量流量的 ToC 类业务。

至于说 k8s 支持后这两个都很简单，没太理解这个点。k8s 貌似本身并没有自带接口回归、压力测试的能力。你想说的和 k8s 组合的 istio 这种服务网格机制，可以更方便控制服务间流量吧？

？