• 单元测试的 cheat sheet at June 30, 2019

    单测一定是开发做。开发不做就没戏。
    推动它得有契机,大环境,或者小环境支撑,不然坡爬不过去。

  • 单元测试的 cheat sheet at June 30, 2019

    你是对的。已改。哈哈哈。

  • 我也跳到网联啦。 诚邀小伙伴一起来搞事情。能做的事情多多多。 简历快点投过来啊。

  • 聊一聊职业发展 at May 09, 2019

    结合你工作中的感悟和思考回答会好一些。没有标准答案。
    通用的来说:最大的成本其实是编写成本和维护成本。最大的难度就是遇到困难,觉得没收益,然后就废了。自动化的实施跟被测物技术架构,开发模型,测试、开发人员能力,项目的类型都有很大关系。所以不结合上下文,没有标准答案。建议多看或者多经历一些实施案例,特别是成功了的实施案例。

  • 好赞。

  • 黄老师越来越赞了。缺少的就是这些基本功。

  • 我是楼上。原来默认是匿名。

  • 聊一聊职业发展 at December 03, 2018

    如果我年轻的时候就悟到这些,有多好。😄

  • 聊一聊职业发展 at December 03, 2018

    试着答一下啊。
    1.都要依托。如果没有复杂的环境和复杂的问题需要解决,时间长了人就会蹉跎,面试的时候遇到了很多这样的同学,被自己一成不变的工作耽误了,在职业生涯的中早期,平台的好坏其实更取决于它能不能制造一大堆问题让你解决,成为你成长的养料,而不是普通意义上的高大上就是好公司,举个例子,前两年有一段时间总接到一个著名外企的工程师应聘,但是存在一个通病:公司平台把什么都封装了,应聘者也没有去研究怎么封装的,为什么要这么做,做了多年的"点点点"同学,虽然有准一线大厂的背景,但是能力上几乎丧失了竞争力。 但是,如果平台不错,你自己蹉跎了自己(看不到问题,不愿意解决问题),那也不行,面试时候也遇到了很多这样的同学,很多问题视而不见,这样工作多年可能和工作一年没啥区别。 还是努力能力增长-》换更有挑战,也回报更高的工作。这种正向循环最重要。

    2.小公司更重视结果。小公司问题也往往十分多,你能把这些问题清晰的定义出来,给出改进指标,把收益说明白,然后做到了,很容易得到认可。实际上小公司是更容易争得话语权的,因为里边能人不多,稍微优秀一些就能体现出来。举个例子:在上家公司的时候,有个测试小伙伴就做到了一点:比产品懂业务细节,所有开发的代码做CR,懂的所有的代码细节。慢慢的,他变成了团队中话语权最强的人,因为他总能指出别人的错误,说的特别在点子上。所以每次考核总在前边,所有团队成员都很佩服,重大产品方面决定很多都会咨询他,是否能上线基本上也是他说了算。工资自然是涨了很多。 另外一个建议是别给自己设限,别把自己只定位成测试,例如,如果自己是最懂产品的人,小公司很容易转变成产品,甚至产品总监。 有准备并抓住机会的话,小公司很容易胜出,见过很多这样的例子。

    3.我觉得其实还是问题驱动,努力解决好你眼前的问题,被认可,其实就全面发展啦。一个我非常佩服的同事的一篇文章供参考:http://www.qkey.top/ce-shi-kai-fa-gong-cheng-shi-de-career-path/ (上边也贴过) 我十分认同
    另外从市场角度看,其实:安全测试工程师、性能测试工程师这种工种的岗位需求是很少的。原因两点:1.小公司需要人是万金油,啥都做。2.大公司全部平台化服务化了,实施没有啥技术难度,很多人依托平台很快上手。大厂,很多性能测试是开发自己完成的,调优也是开发完成的,不需要什么专职的性能测试工程师。

    4.职级越高,需要懂的东西越多,因为懂得足够多才能正确决策。其实在我心中质量是所有人的事儿,“测试开发”的定位是用自己的开发能力更好的保证系统质量。比较认同google团队中的职责划分,具体可以参考: https://testing.googleblog.com/2016/03/from-qa-to-engineering-productivity.html

    5.不是大神,共同学习。

  • 聊一聊职业发展 at November 19, 2018

    又被面试啦,简要答一下:
    通用的思路:
    基于风险的测试。测试的本质是抽样,时间资源总是有限的。要把资源用在刀刃上。先看看那个模块是干嘛的,是不是重要,如果出问题,影响面有多大?然后具体问题具体分析。如果是核心模块,会造成重大损失,那质量一定是不能丢的,抽调别的力量加强这块儿投入,把风险明确的传递给主要干系人,必要时延期项目。如果是非关键模块,识别出问题,可以做:设定一个最小实现目标,砍feature,用运营/客服的手段补足。长效方法:自动化防护网建立,让回归的时间成本、人力投入成本低下来;在项目的初期就能够一定程度的识别这种风险,早加资源,别让这种事儿变成到了最后:一坨毛病,deadline不变。 QA最大的一个价值就是:像探照灯一样很早的预期到风险,并同步给主要干系人。

    其实这类问题,主要是看看你以前在项目里怎么做的。实战经验非常重要,能积累很多“土方法”。

lxg0618@163.com 其实很少用gmail了。。。