个人理解：
1、beanshell 应该属于解释型语言，实时编译 + 执行，执行效率相对并不那么高。而且它目的更多是功能的扩展，性能本身并不是它所关注的，也不是它擅长的。
2、jar 虽然只是变成了字节码，但已经是有一定的预编译和编译器优化，所以性能会高不少。

挺完整的分享，受益良多。

目前移动端 app 都是基于 rubychina 的移动端 app 做的，用户量也比较少（从 bugly 看日活在几十左右），暂时也确实没有专人开发维护。

目前在全力维护的主要是网页版，推荐直接用网页访问，功能也是齐全的，网页也做了移动端布局的适配，排版不比 app 差。

从团队角度来理解，除了看自动化本身的目标和性价比，是否也可以补充考虑一下对团队人员能力、对技术文化方面的一些影响？

不用纠结这些名词，理解代表的含义和归类就好。比如 TPS 有些地方也会叫 QPS ，但都属于描述服务端处理速度的指标，这一点明确就好。

因为实际上压测软件里每个虚拟用户，实际都是 发送请求 - 等待返回 - 发送下一个请求 - 等待返回 这样的方式运行的。

当你从 200 增加到 300 时，虽然虚拟用户数量增加了 100 个，但因为服务器 TPS 已经达到瓶颈，所以这增加的用户数实际都在服务端的请求处理队列里等着，变成了响应时间。

举个例子，商场购物，结账只有 5 个通道（类比服务端的 TPS 是一个相对固定的值），就算你多一倍的人排队（增加压测工具的并发用户数），也只是增加了排队时间（表现出来就是响应时间增加），并不会让这 5 个通道的处理速度上升（TPS 不会上升），也不会让能结账完出商场的人流量增加（网卡流量上升）。

当你继续增大压力，压力达到服务端队列也撑满，新请求不是进队列而是直接被拒绝的时候，才会出现你提到的 “系统错误不断增加” 这种情况。

这个队列在 Java 常见的服务端架构里，是由 tomcat 负责的，有兴趣可以看看这篇文章：https://segmentfault.com/a/1190000023657729 里面关于线程池的说明

点解决应该是改代码那一方来点就好。

根本原因是写文档的人没写清楚，直接原因是前端实现的时候发现没讲特别清楚后，也没有找后端二次确认就直接自行脑补了。

看了完整代码，大概能猜到原因了：

你的 url 实际上是在 test1_login 这个测试方法里赋值的，而 unittest 是不会保证所有测试方法都是在这个方法后执行的，所以如果刚好有别的测试方法在 test1_login 前执行的，那它拿到的就是初始值 None ，而非赋值后的正确值。

另外，不知道你这段代码怎么来的，MyTestCase.url = url 这种赋值方式看，MyTestCase 像是个静态类，但你实际调用又用了 self.url 这种动态类获取属性值的方法，有点乱。

把你这个文件的完整代码贴上来吧？

只有一个个截图片段没法评估问题。现在线索已经明确了 self.url 是 none 了，你需要做的是获取尽可能多的线索去定位为何值是 none ，包括断点调试等手段。而不是一直盯着一样写法别的地方没问题这个事情，并持续截图去证明写法是可以跑通的。

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

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 去编写。

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

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

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