• 我是不是走进了测试误区 at 2018年05月24日

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

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

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

  • 谈一谈你的职业规划 at 2017年10月24日

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

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

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

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

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

  • 测试行业的编程语言之争 at 2017年08月19日

    其实,各种语言都要会。

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

  • 删掉 at 2017年08月04日

    看懂官网的例子先

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

    ui 自动化效率实在低。

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

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

  • 代码能力够了,业务能力不够?没理解,楼主哪方面业务能力不够。

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

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

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

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

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

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

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

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

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

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

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

  • 加快 WEB 自动化定位工具 at 2017年07月20日

    是啊,还是得手写。

  • 加快 WEB 自动化定位工具 at 2017年07月20日

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

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

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

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

  • 缩减版 robotframework

  • 除了测试自己觉得自己有技术以外,还有谁这么觉得?

  • done at 2017年06月23日

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

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

    此时想死的心都有了。

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

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

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

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

  • 历历在目的 2 年 测试生活 at 2017年06月23日

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

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

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

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

  • 历历在目的 2 年 测试生活 at 2017年06月22日

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