我走的技术路线是这样的：手工测试-》图形界面自动化-〉接口自动化-》云平台持续集成-〉测试工具开发-》云 +devops+ 测试架构。
现在工作 9 年半，下一步我的方向是是云 +devops+ python 开发/架构。测试的核心是测试效率。你想一下你的职业生涯变迁，正体现了效率的逐渐提升。效率的提升有两方面，一个是测试技术化越来越强，像你说的做工具。另一个是测试人员比例越来越低，开发自测将是未来趋势。而测试人员未来还会活跃在在性能、安全等特殊领域上。对技术路线有兴趣的朋友可以看看我的专栏：https://zhuanlan.zhihu.com/testup

个人觉得不会。用新语言对国内广大测试人员来说太难了，于是现实中会产生的问题就是招不到人。有能力自学的太少了 z

看书之前，先了解下接口测试的基础：http://mp.weixin.qq.com/s/8aZcv4QyogGvyrKRzTv5IQ

我会说技术路线走到底。然后面试官会问你愿不愿意带人的，如果他这个职位真的需要带人的话。还会问你带过人吗？那我就说带过但不是正式的管理职位。

不可能告诉他我的规划就是混日子混下去吧。

现在是知识付费的时代了……

你可以试试去面试几个心仪的公司。至于薪资，不同地区的差距很大，给不了建议。唯一建议就是不管你跳槽不跳槽，都加强一下自学能力。

另外这么多的了解和熟悉 windows 就不用写了。了解别人花两小时就能了解，小学生都很熟悉 windows。想想自己到底核心竞争力是啥...

其实，各种语言都要会。

自己解析 html，参见各种爬虫教程。

看懂官网的例子先

还不如手工 + 半自动化的工具做。

ui 自动化效率实在低。

你说技术含量的话，自己设计开发半自动化的工具不比 ui 自动化调调别人的工具接口技术含量低。

只不过最早一批人带错方向了，所以你现在搞自动化而不是半自动化。

代码能力够了，业务能力不够？没理解，楼主哪方面业务能力不够。

加油吧，不要被困难吓倒。版本控制我帮我们这里的人平台想的办法是让他开放建 case 和改 case 的接口。然后我再以某种形式把 case 描述在 python 文件里甚至 txt 文件，这一大堆文件就能放 git 上了。

呵呵，然而我们这的工具开发不愿意别人插手他们的工具。

问题就在于你是会这些知识的皮毛。这不算会。举例说，我去面一个好单位时人家问我消息中间件懂不懂，然后我就因为没用过被刷掉了。

楼上写网站没用的那位懂吗？

真正最大的缺陷是作者意识不到的缺陷。
测试用例版在 web 上编写就是最大缺陷。

希望你这个平台不要像我这里的一个前人做的平台一样，编辑一个测试用例服务器竟然要发给我 1 万 4 千行的 html。为啥这么多行，因为长年累月往 case 里加东西，本来很简单的网页变成一大坨 s。

我们这还有一个缺陷就是因为用例放在 web 上，没有了版本控制。别人基于文件系统的测试数据放在 git 上各个版本随便切来切去。我们的存在数据库里压根没办法拿到以前某个指定版本。要是不小心把 case 删了就没咯。

我们还有一个缺陷就是没办法调试。就因为 case 放在网页和数据库上，每次改动要调试一下都蛋疼。你敢集成一个 ide 进网页吗，做不到的话如何调试。当然如果你的平台只测最简单的业务逻辑，写 case 不需要调试都能一次成功的话就当我没说吧。

我们这里的这种 web 平台最致命的缺陷就是他的代码原作者跑路了。留下一大堆本身没有单元测试没有接口测试的 web 代码。现在交给一个基本改不了多少东西的组维护着。自己改不了，也不愿意让别人来改造，变成一堆越来越硬的 s。

祝楼主好运吧，别变成我们这里这种垃圾测试平台。另外你说的理念其实很多年前就有很多人实现了。但就我这里看来，还不如纯代码的测试框架。那些还相对来说容易与时俱进一点。

详细说就是想找一个测试主管的工作，有无数人和你争。技术不好的都来争，技术好的也来争。但是岗位寥寥无几。

是啊，还是得手写。

除了定位失败的元素会无效之外，定位成功的元素也可能无效。

就像你的例子上，如果地图搜索和视频搜索如果两个按钮位置交换了。这个工具能发现无效？如果中间增加了一个 a，“xxx 搜索” 呢？

在 xpath 定位里这种事情很常见的吧。特别是工具生成的 xpath，什么 a【1】、 a【2】之类的，页面更新后 a1 仍然存在，但却不是以前的 a1 了。

转产品挺好的。
自动化技术的价值并没有你想象中这么高。
转测试管理竞争极其激烈。

缩减版 robotframework

除了测试自己觉得自己有技术以外，还有谁这么觉得？

看下官方文档关于 package 和 import 的部分。

不知道楼主的 mock 平台怎么解决数据维护问题。
假如我是用户，辛辛苦苦加了几百个接口上去，开发说所有接口都要改几个参数。

此时想死的心都有了。

更想死的事情是过几天之后说弄错了那些参数要改回去。

此时我就想砸了这个图形界面和没有完善的数据版本控制的平台。

以上是我使用类似平台的真实工作体验（不过我们加的不是接口是 case）

这篇不错啊，json 数据如何维护（比如有一天某个字段发生了变化所有 case 都要改），你们直接手写 json 还是做了图形界面？或者有批量修改用的脚本？

依我看，技术不分开发和测试，只分懂和不懂。

我见过测试人员根本不知道怎么测的软件，
却从未见过开发人员测不了，只有测试人员懂怎么测的软件。

因为大多数测试人员不懂待测软件的内部实现。这个就是问题的关键。测试人员走技术路线的真不多，走这个路线的人还有一个问题：为什么要把自己的技术局限在测试？为什么我不干脆转开发？做一个注重自己代码质量的开发人员岂不是很爽，再也不给别人擦屁股，也不用别人擦我的。

至于策略，技术不行用策略补。比如，图形界面的自动化测试是很讲策略的，这个能做那个不能做，这个适合那个不适合。只因为技术发展不够，不然全做就完事了，不用策略。

技术没有深度终究是不给力的，十年后你和他也是一样...