• 测试转开发后的一点感想 at 2018年07月27日

    话说我转过来依然还是干着开发的活

  • 测试转开发后的一点感想 at 2018年07月27日

    所以,不仅仅是工作中,生活中与人交往也是一样,多换位思考,设身处地的考虑对方的感受~

  • 测试转开发后的一点感想 at 2018年07月27日

    能把问题简单说清楚的,都很欢迎啊,实际是减少出问题的情况啊。
    碰到半天说不清楚问题,还吐槽你不理他的,浪费彼此时间,可以跟你领导吐槽一下。。。

  • 测试转开发后的一点感想 at 2018年07月27日

    提 BUG 的基本要素,这是最最基础的岗位技能啊~

  • 测试转开发后的一点感想 at 2018年07月27日

    哈哈,现在理解开发们的感受了吧

  • 测试转开发后的一点感想 at 2018年07月27日

    😂 相煎何太急

  • 鸡肋是不存在的,只能说是成本和收益的对比,成本>收益那就是鸡肋了,收益>成本 那就是测试过程中的必不可少的助力了。

  • 说白了,我还没看懂这个问题

  • 其实最讨厌这种自以为是的笔试题,有些题目写的可能连作者自己都不知道答案,也不知道想要测试应聘者哪方面的能力,反正就是搞一个虎头蛇尾的题目摆在那。...

  • 等你先搞清楚自动化测试的概念再来发牢骚吧!

  • 你是中专到研究生吧

  • 我连谁在提问都没搞明白,"anonymous" 这个人怎么说了这么多

  • 好复杂 name 自定义?返回 userid?
    redis 自增加规则就好了。然后先把信息放到 redis 异步同步数据库 15k 并发 眼睛都不眨 并发再多就奇读偶写交替 优化序列化方式 速度起飞

  • 大致看了下没很明白,一般自动化接口测试,不都是要考虑数据初始化,然后查表比较返回么(比较这边加上特有的业务逻辑),然后再来个数据清理么。。。;楼主是要考察这点么?纯探讨,说错见谅

  • 楼主回:只要答案中有提到用函数和在数据库中查找,其实就可以了。至于函数怎么写,那都是可以优化的或者根据实际情况写法也会不同。有了思路一切都容易解决。
    至少你的答案和我的想法差不多一致 。

  • 存储 user 的表中,利用代码执行 LAST_INSERT_ID() 函数,获取最新的 userId。然后和接口返回值比较,您看这样回答合适嘛

  • 楼主回:其实我在回答中也说一个在我心目中一个我觉得现在对于我比较满意的解决方案。我一直觉得最有效的方案和最能在实际工作中解决问题的方案才是最好的。这少在这个帖子中,有几位还是愿意给出解决方案的,也的确是切实可行的。比如,在面试的时候也有人给出先去数据库查询是否存在某个 username,然后去删除,在跑脚本,这也也是种可以解决问题的办法,对于这位在这个题目上我觉得他有自己的设计,是很不错的。
    的确是我把题目写的简单了,以后我考虑面试的时候尽量把细节和逻辑写的太清楚点,在面试的时候,我还会引导一下,这里就不说了。
    至于你提到别人学到手了会跑这个观点,我本人就支持学到了就跑这种观点,如果你的能力提高了,公司不能给到你相对于的薪资,那就换家公司。现在的公司又不是以前的大锅饭,一吃一辈子的事情。员工和公司都是互相选择的,缘分尽了就散了呗。我比较喜欢有上进心的,尤其是那种在完成工作任务的时候,会主动来进行学习的。
    另外说一句,我们来 testerhome,不就是大家来分享自己的经验,让别人少走弯路。

  • 看了半天都搞不清楚楼主想表达的是些什么,而且你还我最怕的那类同事类型,就是说话没什么逻辑的那种(对于这句话,其实我想匿名,但是初来乍到,一时没有找到匿名回复的开关在哪。。。BUG)。。。

    这种感觉通常发生在开发需求串讲的时候,一两句话带过。。。实际工作中,我会从系统整体涉及(分布式还是单点等等)、数据库结构设计(向上面说的,分表、字段结构、是否冗余等等)、参数校验、结果检验、操作权限、各种上限限制等等方面去理清规格。。。规格不讲清楚,就让其他人去测试,完全是耍流氓

    当然,面试官就是真理。。。

  • 3 楼,既然楼主这么客气,我说点我觉得可能是实话的话,可能不太容易让人接受,楼主可以慢慢思考,不接受也没问题。~
    我个人是开发,为了避免有人针对我,我就不实名了。。。
    我以前做通讯测试的时候接口也就做做全流程测试,很多细节也不清楚。
    我想说的是逻辑思维是程序的基础,逻辑思维强的,沟通做事的成本都会很低,至于经验,接口测试门槛也不高。
    如果你有机会面更大的公司,你会发现考察的基础能力和实际经历,实际经历最好明确化,逻辑细节都非常重要。你问问题的方式,我个人觉得有待提高。你这么问问题,你自己以后面试可能也会有问题。
    不要鄙视经验稍微欠缺的人,有些人有可能只是缺个环境。只要努力基础好,做自动化测试绝对不会有问题,当然你要做好人家学会了跑路的思想准备~
    很多做测试的同事,包括我自己都有个很不好的习惯,第一时刻总觉得自己是对的,不对的话,我怎么和开发撕啊,怎么区分责任,久而久之,就算自己觉得不对,也会潜意识第一时间圆自己是对的,没问题的。我最近也在思考这个问题,拿出来跟楼主分享一下。

  • 楼主回:
    如果我们两现在在面试,你提出这类问题,作为面试官的我肯定会给你加分的,至少你思考了这个问题,也说明在工作中或多或少的经历过。有的面试者,应为没有经历过这种问题,随便写了接口自动化测试,或者说做的太浅,很多问题没有自己思考过,那就不能给出解决方案,跟不要说和面试官 题问题了。

  • 楼主回:
    因为这个本来就是一个面试时候的一个问题而已,没有必要带那么多逻辑上去。
    至于为什么查询天气要返回星期几,可以参考这个接口(这个接口是我做测试用的)
    https://www.sojson.com/open/api/weather/json.shtml?city=%E4%B8%8A%E6%B5%B7
    如果工作中有这样的接口,的确和你说的一样要去思考这类问题。但是这是这个面试题,希望得到的只是设计思路。

  • 我是 3 楼,返回值是开发逻辑,不是测试逻辑。
    可以通过设计不同的入参,返回不同的出参。
    但这个是有逻辑的,不是随机的。。。
    你举得例子都没有逻辑,为什么查询天气要返回星期几?难道不是查询的时候入参带日期、时间,返回为毛要有星期?
    我觉得楼主需要多想想,接口为什么这样设计,冗余参数的危害性。。。

  • 楼主回:自动化的脚本就是需要可以不断的反复执行,虽然每执行一次脚本会多一个注册的用户。但这个概念绝对不是你说如何实现批量用户注册。

  • 楼主回:根据 username 去查询 userid,只不过是为了解面试的人是否能对动态返回的值进行设计处理。希望面试的人有自己的思路去解决类似这种问题。好像一个查询天气的结果,返回值中有今天是星期几,如果不会动态的去设计这个期待值的,怎么能做成自动化。
    何必在业务逻辑上这样纠结?

  • 同 3 楼:
    根据 username 就能期待出 userid?
    开发设计注册的猿类可以去财务那结账了.

    莫不是 username+ 时间戳或者 md5 什么的吧,
    这种几十年前的敷衍设计,多骗几行代码?

    注册这块的测试,4 楼讲的很清楚.

    28 楼,真相```