• #29 楼 @monkey 我其实有点能理解他们不懂测试。。。他们起家那些年。。确实没啥测试技术。。偏见已然形成 l。现在他们的级别已经使得他们不想去关注这些问题了。挺可怕的。外行领导内行

  • #25 楼 @monkey 咱们这个行业么。。忽悠者居多。我曾经强烈建议我门老板把测试架构师这职位取消了

  • #21 楼 @jamesparagon 可以啊。怎么加?我不太方便公布个人微信号。testerhome 上有私信么?我刚活跃起来。好多东西不知道在哪呢

  • #18 楼 @monkey 我也碰见过。能从 1 做到 10 但是做不到从 0 到 1

  • #13 楼 @lihuazhang 不用都会。谁也不可能是全栈工程师。我是看着简历问的。他简历写了。正好我也会。所以我就问了

  • #15 楼 @buddy931102 这个么。挺难得。刚毕业那会挺看运气的。我也没法告诉你怎么办

  • #14 楼 @monkey 不会很正常。。。我问的基本都不是你擅长的东西。 你问我移动测试的东西。我也完犊子

  • #20 楼 @quqing 不知道你怎么看出来我实战经验不足的。不过看你问的测试结束后销毁数据就是销毁证据。我就能看出你的水平了

  • #10 楼 @buddy931102 找个靠谱的公司走出第一步很重要

  • #17 楼 @sanlengjingvv 数据隔离指的是?我遇到的有些场景。不删除数据是不行的。例如有的接口是列出所有的 data。另一个接口是创建一个 data。创建接口生成的数据就会影响到列出 data 的接口。所以我不太知道怎么给这种情况做数据隔离。我只能删掉它

  • #15 楼 @sanlengjingvv 好思路。docker 起容器很快的。就是我没试过有多快。不知道每运行一条脚本就恢复一下数据库是不是成本太高了。要用多长时间?我回去可以试一下。目前我们数据库没有单独运行在一个容器里。多谢你的思路

  • 要不就多台施压机器搞吧。或者别用 lr 了。lr 本身就挺消耗资源的。你写的 java 代码放倒 jmeter 里也一样

  • #4 楼 @niweyzhuce 我大部分是个 Google 选手哈哈。书的话认真看过的也就是 thinking in java 和研磨设计模式了。测试的书,比较推荐的就是 xunit test partten 和 Google 测试之道了。

  • #5 楼 @quqing 其实有的时候我们可能用的语言不同,项目类型不同。想考察一个人代码能力到底怎么样我也就只能考设计模式和数据结构了。我也没有太好的办法。总不能现场把他写的框架写出来给我看吧。如果他用的框架和我用的一样还好说。我可以问一点框架的东西。我觉得说自己不懂设计模式但设计出的软件特好的人,我实在没法相信他。如果对面是个资深开发我还能相信。测试开发里么,我是没见过。开发人员除了写代码很少关心其他的。他大部分时间都用来设计代码了。所以真的可能出线不用设计模式但仍然写出厉害的代码。但我认为这种人大多数也都是搞了 n 多年的开发了,一开始也以设计模式入门的。然后慢慢融会贯通无招胜有招了。你要说他从一开始就不知道设计模式为何物,我也是不太信的。这么多年工作经验。光听同事说也该知道有设计模式这么个东西了。而且设计模式是面试常考的题目,既然出来面试开发类职位,我觉得专门去学习一下也是有必要的。

  • #8 楼 @quqing 基本是一套。但是两种形式。一个写代码一个不写代码。在领导那看。就跟两套一样

  • #13 楼 @quqing 是我笔误了么?我应该一直说测试结束后销毁

  • 测试开发之路----概要 at 2016年05月02日

    #13 楼 @doctorq 恩,有机会给我讲讲你们那的测试怎么做的哈。我是闭门造车选手。没去过一线公司。不知道一线公司测试什么样子的

  • #11 楼 @sigma 恩,差不多是这样的。不过我上个东家的老大提出过质疑,例如测试人员必须对数据库很了解,增加了学习成本。不过我个人觉得,不了解数据库你怎么验证接口呢。光靠验证返回值明显不靠谱。

  • 测试开发之路----概要 at 2016年05月02日

    #11 楼 @doctorq 额。我想起来了。这个确实失误了。。。不过其实我现在也不在 58 了。我看了你的心向百度的帖子。希望你在百度一切顺利。我在上地。跟你着实挺近的哈

  • #9 楼 @sigma 第三个问题。其实用产品接口生产一个订单,生成一个随机订单 ID。你下一个接口需要这个 ID,我理解的对么?如果是这样的话。其实用 SQL 创建数据的时候就可以把 ID 写死了。你脚本里 hard code 这个 ID。虽然 hard code 的方式总感觉不太好。但是 ID 这个东西除了唯一标示以外没什么用。修改他的机率太小了。相反,产品接口 bug 的机率倒是挺大的。我个人的想法,

  • 测试开发之路----概要 at 2016年05月02日

    #8 楼 @doctorq 你是?我应该没提过我在 58 工作的事?咱俩在 58 见过?

  • 测试开发之路----概要 at 2016年05月02日

    #7 楼 @zzhh7890 多谢支持

  • #6 楼 @sigma 关于删除被测功能产生的数据。你也可以尝试我的这种做法:在读取 excel 的程序里做点手脚。凡是以 delete 开头的 sheet,不会生成 insert 语句,只生成 delete 语句。也就是说在 case 运行前不会创造这部分数据,但是 case 运行结束后会删除这部分 case。你可以专门做一个删除数据的 excel 了

  • #6 楼 @sigma 注册式的缺点确实是无法删除被测功能产生的数据。所以接口测试我们都是注册式加上 inline 结合着搞。最好还是不要依赖产品的接口造数据,尤其是共享数据。这么做确实会产生很多的 excel 文件。不过你可以考虑一下把 excel 文件也重复利用。例如造订单的 excel 文件做一个通用的。造用户的 excel 造一个通用的。商家的 excel 造一个通用的。很多 case 都可以使用这些 excel 文件。但是这些文件你仍然做成隔离数据。就是虽然很多 case 都用这几个文件。但是这几个文件的作用域仍然是 method。一个 case 运行前创建。运行后销毁。好处就是这些数据原则上都是隔离数据。我们也不用创建那么多的 excel 了。问题就是这些数据的内容是一样的。所有的 case 都引用这个数据。所以要求这部分数据必须稳定。不能经常变化。