现在主要在知乎,地址:https://www.zhihu.com/people/qqrrm 老的文章在:http://blog.csdn.net/pyp
☆ 参与调查问卷,抢限量实战课程!!☆

发布新日志

  • 如果你负责系统测试如何跟踪需求?

    2020-08-02 21:01:25


    按照CMMI的操作,实际有需求跟踪矩阵,原始需求、需求规格、设计、测试等等都在需求跟踪矩阵中一一对应。

    此文档虽然没有基线,但是基线文档变更的时候,需要同步更新此文档,保证此文档是最新的。

    而基线文档变更在cmmi中是挺麻烦的事情,实际没有人会没事就去变更基线。

    当然了,cmmi是最理想的情况,现实中很难做到,但是一定要了解理想下的情况应该如何做,这样才可以参考现实,努力往理想的方向去做。

    现实中,大部分情况下,文档要不缺失,要不和最终的实际软件不一致,这些都是很常见的情况。

    所以很多时候,测试人员只能努力的跟上开发的进度,有周例会之类的能参加就参加,了解项目组最新的情况。

    或者和需求人员处理好关系,有什么风吹草动的就知会一声。

    更多情况下,还是以实际软件为准,记录和需求不一致的问题,询问需求和开发人员。

  • 为什么大家都觉得做软件测试工程师很容易?

    2020-08-02 20:57:40


    这两天在看《乐队的夏天2》,在知乎看了不少的讨论,有一个知乎网友

    @大红 的回答有点意思,
    如何评价《乐队的夏天》第二季第一期(上、下)? - 大红的回答

    引用里面的一些内容:

    重点是我们怎么来看音乐及做音乐的人 这个矛盾就很像乐评人和普通乐迷之间的矛盾问题是,乐评人你他娘的也不是精神食粮的生产者啊,你BB这些,有啥用? 丁太升,我一直觉得他很像许知远,窦文涛,之类的人,但是他有个问题,本身的知识储备没法支撑起他的人设,所以说话特别蠢,没啥文化,既浅薄,又刻薄,好像菜市场霸市的老娘们。 丁太升就是乐评人的代表每一个乐评人,都没讲到重点,还没丁太升讲得好。

    之所以觉得有意思,乐评人实际和测试人有类似的地方啊。

    无论上一季还是这一季的乐评人,在大众看来,都是愚蠢的代名词,但是乐评人是否有存在的必要呢,这是一个问题。

    乐评人和测试人有些相似的地方在于:

    1.两者都没有实质产出

    2.两者都依附于别人存在

    3.两者都是报忧多于报喜

    4.两者的门槛都低于产品生产者

    5.两者在业界的口碑都不怎么好

    6. ┉┉

    当然了,实际两者也有很大的区别,比如测试有需求等参考文档,有自己的测试体系和工作方法,这些都是乐评人没有的。

    所以说道乐评人,主要是希望能从另外的角度来看看测试。

    为什么乐评人被人诟病的那么多,就是因为他们很多不专业啊,满口跑火车,很多时候从自身的感觉而不是客观的事实来评价。

    乐队可以专门的设置一个方向研究,我只要面向同一个风格的乐曲,吸取养分,顶多在涉及相关的领域即可,没有必要方方面面都考虑到。

    乐评人不同,乐评人面对的是各种风格的歌曲,总不能说我只评价摇滚->朋克->后朋克->joy division,他们我爆熟,听2小节就知道哪支歌曲。但是现在流行核啊,你评价不,你还想恰饭不,核的东西全听真的很难很难,任何的细分流派其实能搞明白就很不容易了。

    黑刀丁太升算是乐评人的顶流吧,包含在知乎的自称最好乐评人的梁源等等,他们自己感觉良好,实质上也比普通的歌迷确实水平高太多太多,但是如果他们的观点符合大家想的,众口一词的称赞;他们的乐评和我听到的感觉不一样,恐怕大部分的人感觉,要不收钱了,要不就是这样的水平也能当乐评人??

    说回软件测试,在IT也内部,恐怕测试也就比运维、美工地位好点,和开发人员的地位比低的很;在外面人的看法更是测试是谁啊。遇到软件问题,第一口大锅毫不犹豫的就扣到测试人员身上了。

    而测试人员内部,其实大部分水平确实不足,开发能力比程序员弱很多,测试理论和实践其实花费的时间并不太多,但是软件测试能成为一个独立的职业,实际仍然需要掌握很多的工作知识,只是这些工作内容和工作价值,很多情况下并不为人所理解和知道。

    既然选择了这样的职业,那么只能继续,或者换一个更好的跑道,人无论是否愿意,总是需要前进。

  • 测试人员不会判断问题是前后端怎么办

    2020-08-02 20:51:16



    从根本讲是公司流程方面的问题,和测试人员关系不算太大。

    测试人员的主要工作内容是发现缺陷,只要测试人员根据需求写全测试用例,测试过程中执行了全部测试用例,提交的缺陷记录清晰明了没有问题,也很少遗漏缺陷,那么就可以说是一个基本合格的测试人员。

    缺陷记录的一个属性项就是发现缺陷的模块,测试人员有义务和责任,表明此条缺陷记录发现在哪个模块,如何发生,但是提交的内容是否正确,测试人员本身其实很多时候是很难确定的。

    比如题目中说的一个缺陷是前端问题还是后端问题,在知乎我看到很多开发人员吐槽这件事情了,但是这件事情真的和测试人员关系不算太大,你们是开发人员,一眼能看出来一个缺陷大概发生在哪里,因为什么原因发生的,是否应该由自己还是别人负责,但是测试人员不知道啊。

    对于测试人员来说,仅仅是根据测试用例执行,软件预期结果和实际结果不一致,所以发现了一个缺陷,我按照职责记录了下来,至于问题发生真实原因是什么,谁负责处理,who care。当然了,优秀的负责的测试人员会关心相关的问题,会去看源码定位问题,把应该改哪个文件哪行代码都给开发人员标识出来,开发人员只要按照测试人员的记录,直接就把缺陷处理掉了。但是,第一,测试人员的工作也是很繁忙的,不一定有时间帮你们定位问题;第二很多测试人员就是混口饭吃,没有必要把工作做得那么精细;第三很多测试人员的能力也不行,不会定位问题;第四大部分和开发人员的关系也没有到这份上;第五等等等等等。

    总之,大部分的测试人员还是只做自己工作责任内的内容,当然了,如果一个公司规定说,测试人员发现的问题测试人员自己处理,我也有自己的开发项目,其实也是自己测试自己维护的。

    话题稍微有点远了,我们拉回来看看这件事情应该如何处理。

    我开始就说了,这个就是简单的研发流程问题,其实每一个测试人员提交的缺陷,本来就是不应该直接到最终处理问题的人手里面,中间最好有一个确认的过程,这个确认缺陷记录的人,可以是测试Leader,可以是项目经理指定的开发人员,或者由测试人员和指定开发人员协同处理。

    缺陷确认需要做以下的内容:

    第一:此条缺陷是否是真正的缺陷。比如测试人员理解错误,或者需求变更了等等等,不是缺陷由提交缺陷的测试人员确认后关闭。

    第二:此条缺陷是否内容明确。很多测试人员提交的问题,别人看不懂。无法理解的,打回让测试人员补充内容。

    第三:此条缺陷是否需要修改。有些问题虽然是缺陷,但是可以不修改,那么经过开发人员和测试人员协商,打上标签,不需要提交給开发人员处理。

    第四:此条缺陷处理人员。其实这条就对应了问题,确定缺陷发生的真实模块和处理人员,比如可能一个缺陷表面发生在A模块,但是实际可能B模块的原因,那么把此条缺陷让B模块的开发人员处理。也就顺便确定了前端还是后端等等。

    第五:此条缺陷的严重性。严重性从职责讲是由测试人员确定的,但是很多时候严重性可能会和其他的一些什么有的没的东西挂钩,可能会有争议,就需要由更高层次的人协商确认。

    第六:此条缺陷的优先级。此条就是由开发人员决定的,就是缺陷的处理顺序。可以由开发leader或者修改缺陷的人决定。

    第七:此条缺陷的的类型。这个可以在测试过程完毕后处理,也可以提前处理,就是缺陷真正发生的原因是什么,引入阶段在哪里,就是缺陷类型,缺陷起源,缺陷来源等等。比如是开发人员的需求理解错误,还是就是代码写错了,或者干脆需求就是错误的。在缺陷确认处理的好处是可以查看缺陷聚集情况,查看其他类似地方是否存在类似的问题。

    其实大家可以看看我在知乎关于测试方面的回复,基本都归结于各种开发流程而不是具体的人,我个人还是愿意相信大家的职业操守,只要在一个好的合适的适合本单位的开发流程里面,可以尽量的避免个人的因素影响。

    大概就是这些。

Open Toolbar