同意
下面的机会测试可以考虑：

1. 转产品。并不是所有的产品都需要懂技术，但是大多数产品岗位是需要了解技术的。测试工作过程中与不懂技术的产品讨论技术需求纯属对牛弹琴。所以懂点技术的测试是可以转技术产品的。
2. 转开发。测试只是职业发展过程中积累技术的一个台阶，转开发的测试通常是对高薪、技术有追求的人。
3. 转项目经理。管人、管事、管进度，项目经理至少需要了解敏捷开发，测试工作过程中采用了敏捷开发，有了经验的积累，完全能够胜任项目经理角色。
4. 第二职业当主业。对测试工作不感兴趣，那就在测试工作的同时，为第二职业做好准备。一旦时机成熟，果断将副业换主业。

同意。
持续学习，持续进步。如果不想持续学习，就给自己留有退路吧，测试工作之余想想其他工作也挺好的

青春很短，没多少时间，可以浪费的

要想提高自己的测试水平，不要将自己仅仅当作一个测试。
开发用到的知识测试需要掌握，不仅仅是了解。

企业招聘岗位收缩 ，从业者普遍能力重合度偏高 ，高级岗位，缺失，初中级岗位，严重供过于求 。

严重供过于求是假象，许多公司招聘找不到合适的测试人员，为什么？

最重要的原因是许多测试工程师没有持续学习能力，常年从事的工作与技术脱节。

举例

1. 某 985/211 计算机相关专业毕业，拥有本科、硕士学位，毕业 10+ 年，在某国企搞数据库相关测试。但是对互联网已经脱节，连接口测试也搞不定；
2. 某研发转测试，年龄 36+，用 Python 编写了一个接口测试框架，花费 3 个月，然而测试框架仅仅是从 Excel 表格中读取用例数据。测试用例断言是什么都不知道。
3. 某日遇到一个老乡，也是 211 毕业的，但是一直从事功能测试。老乡的感情在面试完毕溜走了，直接让他回去了。

虽然大家都不可能周知所有知识，但是对基础知识的欠缺还是需要反思的。无论你是工作 5 年，还是工作 10 年，及时补充基础知识，不要因此闹出笑话。

差不多，使用"id":"(.+?)"可以匹配出来答案，考虑 json 格式的通用性，我给出的正则表达式可以用于匹配{"a":1,"b":true}这样的结果，但是得修改一下正则表达式。

测试的成长不是某次培训带来的飞跃，而是持续学习带来的逐渐提升。

虽然我从来没有这么用过，直接写代码。

但是不排除某天这么用，看了一眼。解决方案如下：

1. 正则表达式是这样的

"id":"([^\,\}]+)"

1. 接口 1 返回结果作为接口 2 的参数
   

2. 效果如下
   
   

配来配去，一点技术成长也没有。几行代码搞定的事情，就用代码搞定。

腾讯不是全靠技术推动的，技术肯定不如阿里。

但是数据驱动还是很厉害的，数据驱动比技术驱动跟重要。

无论转什么，都需要不断学习。
开发转测试需要学习的不必测试转开发的少。

生成的用例加上断言，此外看看是否有需要补充的用例。

代码是开发同学实现的，我只是绿叶，存托一下红花而已。

是的，测试过程中也不是片面追求代码覆盖率，主要是根据代码覆盖率补充异常测试用例。

参数格式与类型都是根据接口文档来的。
当没有接口文档时，可以联系开发确认。

对于其他第三方接口（没有接口文档、也找不到别人家的开发），这时可以根据抓包来猜测接口参数类型与格式。

1. 时间戳字段使用一个生产时间戳的函数生成。
2. uuid 使用字符串拼接函数生成；
3. 至于字段有取值限制（例如字段取值是枚举、散列数组等），可以通过遍历数组生成用例。

感谢大神前来参与。
QTP 不仅仅是因为 license 问题而被取代，个人分析的原因如下（并不全面）：

1. 因为录制工具仅能完成录制工具本身的事情，而代码可以搞定几乎一切问题；
2. QTP 本身不是开源软件；
3. 移动端测试框架与 QTP 没有什么关系；

而 uirecorder 弥补了 QTP 的短板，具备下述特点：

1. 录制的脚本是 node.js 代码，可以任意扩展；
2. uirecorder 是开源的，任何人都可以拿过去进行修改，以满足自己的需求；
3. uirecorder 是 macaca 测试方案的一个简单应用，本身融入了 macaca 生态体系，具备移动端、web 跨平台解决问题能力。macaca 本身还具备多语言支持，uirecorder 是其中的一种用实现，并非仅仅只能用 node.js 实现，还可使用 Java、python 实现。

嗯，跳进坑里面了。

1. 目前已有许多人盲目的跳进 UI 自动化的坑里面了，简历中做过自动化，但是做过的 UI 自动化 case 不及 uirecorder 录制的几个 case 高效；
2. UI 自动化投入产出比是目前许多中小微企业面临的一个问题，大公司可以招聘一帮专门的 UI 自动化的人，但是中小微企业可能测试团队就几个人，uirecorder 是为这些人服务的。当然比不上专门 UI 自动化团队的人，也没有必要比。
3. 我的工作环境确实限制了我的思维，因为我不专职做 UI 自动化。
4. UI 自动化对于培训机构来说可以忽悠住没有做过 UI 自动化、视野狭窄的人，让人花数千、数万 RMB 去培训，培训完编写的 UI 自动化脚本还不如 uirecorder 录制出来的脚本。

UI 录制并不是使用屏幕坐标定位的。

是的，平常工作过程中在多参数接口测试中使用，虽然用例有冗余，但是脚本是机器执行的，成本比手动测试、单接口单场景逐一编写测试用例快很多。

新的知识，需要系统学习。
零碎的知识片段给人造成盲人抹象的错误感知。

不全是针对小项目，UI 录制与 UI 遍历无本质区别。

1. 喜欢折腾的同学可以拿着 UI 录制去学习 UI 录制背后的知识，以便更好的为 UI 自动化后续发展做好准备。老板们喜欢看得见的东东。
2. 拿着 UI 录制的代码，自己动手写 UI 遍历的工具。
3. UI 遍历主要是采集数据，然后使用图像识别 + 规则引擎，实现极少人力参与的兼容性测试；
4. UI 遍历过程中产生的数据（截图、APP 端性能、电量、内存、日志等数据），进行质量评估。

好的，后续再分享录制脚本如何快速优化