你写绝对路径，不要写相对路径试试？

jenkins 执行 shell 的用户和你直接本地启动 shell 的用户并不是同一个。

解决思路参考：
1、在你跑 newman 前执行 env ，确认下你的环境变量的 PATH 里有没有包含 newman 所在的路径
2、如果没有，确认下你设定 newman 环境变量的配置文件是哪个，手动用 source 对应配置文件 来手动应用，示例：source ~/.bashrc

这个问题背后的原因是 jenkins 使用的 shell 模式，和你直接本地执行的 shell 模式有差异，所以初始化时应用的配置位置也会有差异。从现象上看大概率你的 newman 配置就在有差异的这部分里。

详细可以参考： 登陆 shell,非登陆 shell 以及交互 shell 和非交互 shell

你这个页面有很多 android.view.view ，看起来像是个 h5 ，可以看看是不是确实是 h5 ？

如果是，可以切换到 webview 来控制。

按个人理解尝试回答下：

1、内嵌在 APP 中的 H5 页面如果仅仅只是展示，需要考虑的兼容性因素是什么？为什么？

如果只是展示，无功能。那需要考虑的就只是展示的兼容性了。不同分辨率、不同比例的屏幕下，展示是否都没问题，会不会被挤出去或者出现重叠。不过坦白说，现在前端基本上都不是直接写 html + css 来控制展示的，就算只是展示也离不开 js ，所以也要考虑 js 的兼容。比如某些 js 函数的使用、html5 标签的使用，会不会在某些浏览器上是不支持的。示例：https://developer.mozilla.org/en-US/docs/Web/HTML/Element/video#browser_compatibility

2、内嵌在 APP 中的 H5 页面如果要和 APP 原生页面频繁交互，需要考虑的兼容性因素是否会更多？为什么？

这个不一定，具体要看你的 app 。webview 要和原生 app 交互，需要通过 js bridge 技术进行，即原生 app 暴露特定 js 函数给 h5 调用。如果你的 app 提供的函数一直没变过，那这部分没什么特别的兼容性问题，但如果有改变（比如 1.0 版本和 1.5 版本相同功能的函数进行了重构导致调用方式有差异，或者 app 内部这个函数的实现在不同版本的系统有不同的处理逻辑），那就得按照实际在什么地方有改变进行针对性的兼容性测试。

如果是函数调用方式改变，需要确认这个页面在新老版本 app 上都能正确识别和调用对应的函数，即 h5 需要在新老版本 app 上分别测试

如果是函数内部实现不同版本有差异，这个正常来说改变了实现逻辑后的函数刚出来就要测一遍确保行为一致，所以一般也不需要特意测试。

3、内嵌在 APP 中的 H5 页面若是需要调用手机硬件功能，需要的兼容因素又是什么？为什么？

这个和第 2 个基本一致，硬件功能都是要通过原生 app 提供的 js 函数来完成的。兼容因素就是原生 app 的这个 js 函数实现是否有兼容不同操作系统版本。

4、如果当前没有指定机型，内嵌在 APP 中的 H5 页面如果仅仅只是展示，是否用模拟器模拟分辨率和尺寸就可以验证？

影响展示的要素核心是窗口的大小（即比例和尺寸）和浏览器渲染引擎逻辑，理论上只要这两者一致，那效果就是一致的，所以模拟器是可以验证的。

但要特别留意 浏览器渲染引擎 这个点，不同浏览器内核渲染引擎会有差异，比如 android 原生 webview 和微信 webview 用的 x5 内核就会有差异，苹果 iOS 不同版本对应的 webview 内核也有差异。你需要先确认清楚浏览器内核保持一致这个点。

楼主对自己工作内容说的很简单，没法给特别具体的建议，推荐可以学习下这周刚结束的 MTSC 测试开发大会深圳站议题内容，从这些方向延伸去看背后有什么技术点。

PS：不知道楼主公司是怎么样的分工的，但不做功能测试，只做自动化和测试开发，正常应该是还得自己肩负找到测试痛点、解决测试痛点的任务的吧？毕竟测开的核心工作是提高测试生产力。如果只是实现需求，长期来说会比较危险。容易开发能力不如专业开发（服务几十到几百人的测试平台，和服务几万几十万人的业务系统，锻炼出来的开发能力差异很大），测试能力不如业务测试（特指对业务质量的把控），高不成低不就。

你需要先明确你的工具边界。你前面说的有两个类型的东西混在了一起。

封装的配置和原有的是否一致，这个是你工具类独立完成的，可以做单测来检验。可以看看 Mockito 这个框架，它可以 mock 掉某个指定类型的类对应对象，并校验实际调用时传入的参数等。

多线程处理这个值是否确实起了对应的线程数，不知道你这个实际这个线程启动到底是由工具类启动的，还是由背后实际的外部库调用。如果是工具类启动，单测应该也有办法获取到某个指定类有多少个线程在运行的，你可以找找看。

单测的配套工具并不比我们平时看到的 UI 自动化少，甚至更丰富，你可以先从简单的写起，逐步深入。

没看懂你这个场景，可以详细说明下？

工具类最好的测试方法应该是单元测试，因为足够简单快速。之前做用例平台的增量保存工具类，我写了 22 个单测用例，5 秒内就可以全部跑完，行覆盖达到 93%，非常高效而且放心。基于这个单测我后续还做了一些代码优化和重构，通过单测可以很放心地改，因为出问题单测会立马告诉你。

自己建个项目去调用也是一种方法，但这种方式单元测试其实也可以覆盖的。开发不愿意写单测，可以你来写呀。

感觉楼主需要转变下思维，服务端的性能测试的思维不是 “模拟用户真实操作，只是数量上增加到原来的几百倍”，而是 “从场景分析得出服务端会承受的负载情况，再使用压测工具进行模拟，查看在这个负载下服务端的性能水平是否可以满足”

然后不知道你这里的 “事务时间” 统计目的是啥，所以不好说。只能说数据是可靠的，因为是按固定公式计算的，只是这个公式是否满足你这里的 “事务时间” 要求，这个不确定。

横向发展不是浅尝辄止的，每种相关的技术都需要花上一些精力去掌握的，当你掌握住后再换其他的

交流一下，个人还是比较认同上面这个观点的。我认为每个方向上的技术都是不断发展的，很难有什么掌握住了这种境界 这个我打个比喻，如果专家级别是 100 分，那掌握应该是 60 分。掌握的核心是掌握典型思路以及原理，这个部分基本都是万变不离其宗的，掌握了之后基本上几年内不会有翻天覆地的变化导致完全过时。比如 UI 自动化领域，核心能力的是 控件识别 + 控件操作 ，这个能力不管是很久以前的客户端软件，还是现在的 web、app，思路上都是一样的，只是具体实现技术上在不断变化（比如 web 的 selenium 变成 app 的 appium/uiautomtor/xcuitest 等）

如果某个技术掌握连 60 分都达不到，那这个技术不管算作是横向发展还是纵向发展，都很容易被赶上甚至超越。个人认为，横向的核心是通过这些多领域的能力，自己总结出一套相对通用有效的思维框架，进而在后面遇到新领域时可以快速上手和进行能力迁移，夺得先机。比如掌握 3 门编程语言的人，学第 4 门会比只会 1 种语言的快，因为前 3 门语言已经让他在各个语言都通用的知识上有了很牢固的基础，需要学的只是这门语言的新理念新方法而已。

感觉正文的论据有点怪怪的。

横向发展
懂得多而不精，用我朋友的话说就是没有在某个领域足够突出是没办法很好的当上管理层

如果只是多而不精，相当于每个方面都只是 “了解” 层级，这不算懂，只能叫听过吧。然后当管理层已经不只是看具体技术层面了，更多是团队组织培养以及各种项目协调管理能力，或者说能把难事干成的能力。个人存在技术短板，招技术大牛来补短板也可以解决。

垂直发展
可能被技术的快速迭代导致被轻易的超越。例如：自动化测试，性能测试都很快的被市面上不断迭代的工具所替代

垂直发展的结果是容易被工具替代的话，那这个垂直的深度也太浅了吧。最为核心的分析部分都是得人工的，暂时没见过有特别有效的工具取代方法。所以不应该会出现垂直发展还被工具取代的情况。

信息太少，帮不了你。。。

只能看出不通过原因可能是某些控件位置变了，导致原有的定位逻辑无法定位到对应的控件。但为何变了，变成了什么，如何修复，这个没相关信息没法给建议，你可以自己 dump 一下控件树对比看看。

前面歪楼了。。。我来回答下楼主留的问题吧。

首先，不要觉得学 java 是从零学另一门语言，编程语言除开各个语言的一些设计理念外，核心逻辑不外乎就是那几个，而且 python 和 java 都是面向对象的，两者很多地方都比较接近，能看懂 python 不至于看不懂 java。

然后，从提高开发的问题解决效率来说，并不见得还得把解决方案都给到才能提高，能找到并给出相关的关键错误日志（如异常堆栈）已经帮助非常大了。进一步的可以拿开发代码本地跑起来后，给错误日志所在代码行加断点，便于看到此时各个变量的信息，排查为何报错。

最后，如果真的是要掌握到知道怎么修 bug 的程度，那得知道怎么写代码。那可以找开发拿到项目代码后，仿照开发的形式基于这个项目自己去加一个对某个库表的增删改查接口，从 controller 写到 service 再到 dao，三层结构都写一遍并调通（过程中你会学到项目用到的框架最常用用法，特别是各个注解的用法和含义，这个对于读懂代码非常重要）。做完后相信你就可以掌握了。

有两个概念建议理清一下：

1、native、webview 属于 context（上下文）领域的概念。主要对应 appium 的底层调用工具切换。如 android 上，native 底层用 uiautomator，webview 底层用 chromedriver 。由于一个 app 是可以有多个 webview 的，所以这个名字后面会有一个不固定的后缀，方便进行唯一标识。

2、基于上面这个概念，我不能针对首页 H5 这个 ‘WEBVIEW_’ 写一个专门的 page 类 这个本身就不大对，page 类应该是针对 webview 里面某个具体 h5 页面（一个 url 对应一个 h5 页面）去编写，而非针对一个 webview 去编写。

我觉得很合理。要保证自测质量，自测用例很重要。一个功能背后一般会拆分好几个模块，开发很清楚自己模块，但不见得清楚完整功能。如果他自己设计，大多都会只是测试自己的模块，而且也比较随意，甚至用例都没有。

提供自测用例，可以让开发减少自测的思考成本，满足开发的诉求，同时也能保障开发自测不跑偏，提高提测通过率，满足测试的诉求，性价比挺高的呀。

可以分享下你们这个系统的开发成本大概多少不？

先表达一个个人观点：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 就可以获取到。但这个没啥意义，因为不是所有接口都是直接可以成功调用的，必须参数符合内部逻辑要求才行。

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