• #22 楼 @quqing 我理解在持续集成环境中要求保存数据当作证据给开发人员的。都是不管三七二十一只要脚本失败了就扔给开发的工作模式

  • #25 楼 @quqing 我的观点是不需要保留数据的。因为这世界上有种东西叫 debug。首先如果测试脚本失败了。作为测试人员肯定要去分析一下原因。为什么失败了,环境错误?网络问题?case 之间互相影响了?还是脚本本身的 bug?起码要 debug 一下看看到底怎么回事对吧?如果这件事无法达成共识那么也不用聊了。如果最后排出这些原因。怀疑是开发的问题,那么分析是哪部分代码出的问题。UI 自动化失败的话那就看一下对应的接口测试报告。确认是前端的 bug 还是 server 的 bug。去代码库看看相应路径,是不是有代码变化。什么变化引起的 bug。自己分析下原因后发现是自己搞不定的才提交给开发。bug 管理工具中提出完整的重现步骤。这是一个测试开发起码要做的。这个可以达成共识对吧。
    那么再说开发追踪 bug 的问题。如果你们是异步合作模式,开发去 bug 管理工具上获得详细的重现步骤。如果根据步骤不能重现问题,有可能是测试没写好。也有可能是双方环境不一致。如果开发一定要在测试环境中看一下测试结果。根据之前测试人员 debug 的结果。会没有数据保留么?debug 的时候在数据清除之前就打断很难么?就算测试人员忘了保留数据。我们都是自动化的,跑一边脚本几秒钟的事很难么。所以我们需要在框架里特意的保存数据么?

  • #22 楼 @quqing 测试失败了。不尝试找原因直接扔给开发的我也是醉了

  • #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 见过?