现在主要在知乎,地址: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或者修改缺陷的人决定。

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

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

    大概就是这些。

  • 做软件测试需要强势吗?

    2020-04-13 12:54:30


    作者:鹿鸣
    链接:https://www.zhihu.com/question/303675694/answer/1143576945
    来源:知乎
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

    测试仅仅是一个工作,和性格关系不大,更关键的是所在公司的流程。

    需求评审,测试本来就应该提出自己的看法和意见,你无法提出意见更多应该是你的水平不到,无法看到文档里面更深入的问题,这个更需要的是多多学习和思考,和性格无关。

    迭代排期也一样,关注进度,主要还是项目经理和质量保证方面的责任,当然了,很多公司的测试会兼顾一些QA的职责,但是看你的描述无法确认是否测试有QA的职责权限。

    公司的流程如果正常,本来就应该有周例会或周报之类的,各个角色说明当前的项目进度,并不需要测试人员去督促进度,测试人员本身的职责和范围,通常也并没有进度监控这项内容。

    而且你们没有项目计划和测试计划的吗?为什么需要测试人员去询问什么时间测试,测试人员只需要按照测试计划,在需要测试的时候,去配置库提取测试版本。

    感觉你们没有项目经理去管理项目,或者开发人员认为并不需要测试就可以发布。

    至少从你描述,我看不出来工作和性格有什么关系,只是表明你的公司的流程有问题,所以需要员工自己去调整工作,应该是没有项目经理,只有开发人员和测试人员,所以需要大家商量着来,结果开发人员更强势,控制了话语权,测试人员被逼随着开发人员的节奏步调进行工作。

    所以你需要做的,建议公司设立开发标准流程,建立项目经理负责制,找真正可以做主的人员,不要有事没事和开发人员说进度之类的事情,这个本来就不是开发人员管的。测试工作上,坚持专业技能,只做应该自己做的,时刻提醒自己,我仅仅是测试人员,测试才是我的工作范围,测试以外的事情,我只有建议权,没有决策权,所以该是哪里的问题,找相应的负责人解决。

    坚信自己是技术人员,一切以技术说话,尽量避免性格因素对于工作的影响。

    大概就是这样。

  • 测试工程师的核心竞争力是什么?

    2020-04-13 12:51:19


    这几天在知乎总能看到一个问题给我推送:

    假如我是一名能100%修复所有bug的程序员,我能在编程领域混成什么地位?

    其实测试人员也可以提出类似的问题:假设我是一名能100%发现所有缺陷的测试工程师,我能在测试领域混成什么地位?

    企业为什么需要测试,本质上是为了保证产品的质量,所以如果企业对产品质量没有任何的要求,那么完全没有必要设置质量相关岗位。当然了,实际因为现实的种种原因,即使企业真的不重视质量,除非是小作坊,企业规模到了一定的程度,只要存在需要提供产品,那么一定需要有质量人员存在,这个人员也许是质检,也许是品质,也许是QA,也许是测试,也有可能是其他角色人员。

    企业的根本目的是生存发展,这些离不开金钱,所以需要计算投入产出,只有一个角色企业认为产出超出了投入,才可能有相关的角色人员存在。

    测试在产品生产甚至是质量链条上,并不一定是必要的存在,所以需要考虑的是自身存在的价值和意义。

    测试总体来说,是质量的度量,实际是提供一个阈值,衡量产品是否低限满足客户需求。

    那么就很容易得出结论,其实测试的能力和企业的要求并无太多的关联性,企业招募人员一定希望最低的成本完成最有价值的事情,测试的价值就是提供质量情况,谁能越多的满足此种企业需要,谁和企业的匹配度越高。

    其实吧,可以认为我上面的内容都是废话,企业很多时候面试的时候考的造火箭,进去大部分时候还是在敲钉子。

  • 如何看到软件测试技术带来的价值?

    2020-03-28 10:59:34

    知乎问题回答

    测试不是创造价值,而是提升价值。

    创造价值的一定是开发人员,但是开发人员做出来的产品质量未知。

    谁能判断一个产品的质量是否优异,除了客户,就是质量人员。

    质量人员的范围很大,比如技术专家、比如QA、比如开发、比如测试等等质量相关或者项目干系人都可以说是狭义或者广义上的质量人员。

    测试的目的是发现产品中存在的问题,以此定义产品的质量。

    质量的好坏和产品的价格非正相关,以客户的判断为最终标准。

    所以如果客户觉得一个产品的质量不优异也可以接受,那么质量相关的投入可以减少。

    测试过程仅仅是质量环节的一个部分,身为测试人员,保持自己的立场即可。

  • 去哪里找系统来进行测试

    2020-03-28 10:56:06


    有一个误区,虽然说软件测试的工作产品之一是通过测试过程发现的缺陷,但是此工作产品的产出并不是单单直接测试获得的。

    一个产品需要测试,拿过来直接测试通常并不能获得一个好的结果,通常需要了解很多的内容才能更好的完成此测试过程。

    比如此产品的需求是什么,需要进行哪些方面的测试,哪些内容是要重点测试的,测试的工作时间是多久,需要安排多少的工作量。

    在软件开发中,也并不是拿过来一个点子就开始写代码吧,需要进行需求调研,整理客户需求,写需求规格说明书,评审,项目计划,概要设计说明书,界面设计,数据库设计,详细设计等等等等,这些都做好了,才开始正式的写代码。即使是敏捷过程,同样有story,站立会议等等,也并不是拿过来都直接做的。

    测试过程类似,参与需求评审,写测试计划,参与项目例会,写测试方案,写测试用例 ,根据计划做接口测试、功能测试、性能测试、安全测试、回归测试等等等等。

    所以说,测试不仅仅是发现缺陷,而是通过软件测试的过程,让项目相关人员了解当前软件的质量情况,最终给发布的软件以信心支持。

    回到问题,你想通过一个具体的软件了解测试,那么建议通过以下的途径进行:

    1.软件确认。随便找一个软件,比如你常去的论坛,比如知乎,比如豆瓣等等等等,软件是什么不重要,重要的是测试的思路。

    2.测试内容。通常功能比较多,可以拆分一些简单的功能模块进行测试,比如登录,比如发帖,比如查询等等。

    3.测试范围。这个其实如果有需求应该是对于需求的分析,但是既然没有需求,那么就参考具体的程序,把上面的功能拆分出来,比如登录就可以列出功能分解:创建新账号,老用户的登录,使用QQ、手机、微信第三方登录等等。这里需要对测试的范围进行确定,具体测试哪些功能。

    4.测试类型。接口测试,功能测试,性能测试等等。

    5.测试计划。简要写一个就可以,主要说明测试的范围,测试的类型,测试用例的编写等等,具体看测试计划相关内容,确认需要做的工作。

    6.测试用例。具体内容应该都学习过的吧,等价类、边界值、场景法等等,能用上的都用上,多分析多写,尽量考虑更多种类的正常和异常的情况,这个才是测试人员最基本最基本的基本功。真正工作中,即使不写测试用例,但是头脑中一定也要有一个测试用例列表,我现在应该做什么,接着做什么,实际按照此列表进行。软件测试绝对不是随便点点的胡乱测试,是有理论和实践支持的科学工作方法。

    7.执行测试。按照测试用例去测试。在测试的过程中,可能需要随时补充调整测试用例,这个是正常现象,发现缺陷就记录下来。

    8.缺陷分析。发现的缺陷进行整理分析,比如是否可以重复出现,测试步骤是否可以简化,是否其他地方存在类似的问题等等。测试缺陷通常有群集的现象,一个地方发现的问题多,那么说明这个地方一定会有更多的问题等待发现。

    按照上面的流程,至少你可以对别人有信心的说,这个软件我成功的进行了测试,即使没有发现任何的缺陷,至少在测试用例的范围之内,我已经尽力了。

    --------------------------

    补充内容:

    测试人员的基本技能是发现缺陷,这个是正确的,但是这个并不是全部。

    任何的工程,都需要考虑成本、进度、质量,测试过程同样不例外。

    确实很多人可以发现别人无法发现的问题,而且测试人员作为专业人士,发现的缺陷本来就应该比开发或者客户等外行多且正规,这个是测试人员的工作。

    但是发现缺陷,同样需要考虑很多的时间和成本问题,而最好的控制手段就是进行规划,也就是计划和用例,保证测试的投入产出比。

    当然了,作为学习阶段,并不需要考虑这些,就像是开发面试,一定会考一大堆的堆栈算法等问题,但是实际真正工作用到的,大部分人还是CRUD居多。

    书上和培训的知识内容,更多是理论的框架,实际工作要复杂很多,在一个不断进化的行业,人员也是需要不停学习的,理论的扎实是很重要的部分,还是一切的基础。

    努力学习和工作吧。

  • 未来方向软件测试,有什么可以指点提醒的?

    2020-03-28 10:53:51

    不清楚你大专学习的什么专业,是否IT相关。个人更建议学习编程,当程序员比测试人员要好很多,而且现在对于测试人员的要求也逐步在提升,没有开发背景的测试人员,上限未必会太高。

    工作用的电脑不是应该工作单位给配置的么。总体来说,测试人员的电脑没有太高的配置要求,因为顶多用个loadrunner,基本对于电脑没有要求。测试人员不比开发人员,开发人员需要使用Visual Studio或者IDEA、Eclipse这样的开发工具,同时搭配类似Oracle数据库才需要高配置的电脑,测试人员也许更需要Android模拟器或者VMware这样的虚拟机。当然还是电脑配置越高越好用。其实测试人员更需要的是多样的测试环境,比如各种分辨率显示器,各种操作系统的机器,各类常用的Android手机等等,但是没有也可以虚拟代替使用。具体还是在工作过程中看你测试的软件,还有公司对于测试方面的资源倾向。

    测试工作总体来说是大杂烩,什么都要求会一点,但是很多没有必要精通。个人觉得比较根本的有两点,第一是测试方法测试思路,落实到测试用例的编写上,测试人员是否水平足够,看测试用例编写即可。第二就是业务的熟悉。测试人员的工作目的还是为了发现缺陷,要发现缺陷就要对业务和软件熟悉,才能更广泛更深层次的发现问题。业务需要在具体工作中了解,所以如果想成为一个优秀的测试人员,努力练好基本功,多分析软件,多写写使用各种测试方法的测试用例。

    从我个人的角度,分析一下你手打的内容,觉得有些违和的地方,意见仅供参考,不需要完全相信。

    1.原文:全面的深入进行数据库、代码、接口非功能等方面的测试。

    这句过于的杂揉。测试人员分很多种,常见的功能测试人员,接口测试人员,自动化测试人员,性能测试人员,测试开发等等。我这里默认角色是人数最多的黑盒功能测试人员。数据库不需要测试,数据库通常不在测试人员的测试范围内。代码不需要测试,代码基本都是单元测试、TDD、接口测试等等,这个是开发人员的责任,基本代码是不需要测试人员管的,测试人员通常只需要测试编译打包后的可执行程序。接口和非功能是两个东西。非功能指的的是性能、安全、界面等内容,接口应该归于功能测试。

    2.原文:可以协助需求、设计以及开发人员做很多补充和完善的测试。

    需要记住一点,你是测试人员,测试方面你才是专业的,你才是专家。所以测试相关的内容,不是协助其他人做测试,而是其他角色人员协助测试人员做专业测试。测试人员需要做的工作是对需求文档、设计文档、开发文档等做测试方向的评审,比如需求文档中是否存在矛盾冲突、无法测试的地方,设计文档是否和需求文档功能一致,或者指导开发人员,除了正常的路径,还需要考虑各种异常情况,这才是测试人员的工作。测试人员在整个项目开发过程中处于辅助地位,但是在测试方面,一定是测试人员做主导。

    3.原文:数据库,增删改查,迁移存储优化(mysql)

    还是身份定位的问题,你是测试人员,不是DBA,迁移存储有DBA、运维,优化有DBA、程序员,哪家公司会叫测试人员做这些工作。测试人员的独立得益于社会化大生产分工,其实没有测试人员,程序员也可以当全栈从头干到尾,为什么还需要需求人员、设计人员、项目经理、DBA、运维等等等等,因为每个专业既然分出来,一定是有其专业化和时间成本分配原则。测试人员只需要做好自己份内的工作。当然了,如果想转行做别的,当然是学的越多越好,但是实际上,任何一个可以独立分工的职业,想学习明白都是要花费很多时间精力的,看你个人的选择如何。

    别的就没有什么了,证书个人觉得ISTQB是坑,看你的公司是否需要,否则看看教程即可,测试人员的理论知识并不算太多。最好的证书一定是信息系统项目管理师,建议优先考这个证。



  • 33岁学软件测试来得及吗?

    2018-06-09 11:12:34

    内容为:之前一直在工厂上班,看不到希望。已经33岁了,想转学软件测试来得及吗?

    我给出了下面的回复,大家可以去给出不同的回复。

    ------回复正文-------

    我看题主的个人资料,你在12个月前关注了测试话题,但是在知乎一直没有进行过操作,今天提出这样的问题,因为对你的信息没有太多的了解,所以只说些自己能分析判断出来的,可能和题主的实际情况不一致,如果看到能补充更多信息更好。


    看题主问题有几点:

    1.工厂上班

    2.没有希望

    3.33岁

    4.希望学软件测试。

    不清楚12个月前为什么你关注了测试的话题,是否你周围的人有在从事相关的工作,可能和你沟通的时候,表达了测试入门门槛低,待遇不错的信息。而你在工厂的工作不是很顺利,33岁不清楚是否有家庭的压力,所以想换一个更有前途的工作。

    因为工厂的职业有很多,所以不清楚你现在的工作是什么,也不清楚你的学历以及是否做过学过做过IT相关的工作,只是从一个测试人员的角度给你一些看法和建议。

    1.测试的入门门槛

    其实不是测试的入门门槛,而是很多公司本来就对员工有入门要求。比如学历,比如相关工作经验。除非你是应届毕业生,公司认为你有培养的价值,所以会降低相关的要求,否则进入公司的那一关就很难。

    2.测试的发展前途

    测试现在的发展趋势都是程序员化,就是一是质量方面要求程序员负担起更大的责任,同时测试人员的技能要求在向程序员发展。所以对于想入测试的人,通常建议先去做程序员,实在对测试感兴趣再从程序员转成测试人员。

    3.年龄限制

    现在的IT行业,整体还是在拼人力。996了解一下,虽然不是全部公司都这样,但是大部分的IT公司加班出差等都是常态。33岁在IT行业真的很大了,很多公司初级人员都是要年轻的,最好吃住都在公司,30岁以后基本都是资深开发或领导一个小组了。33岁真的大部分公司不会需要的。

    4.测试技能。

    软件测试还是需要基础的,测试即使相对开发简单,想入门也需要花费一定量时间和大量的金钱,建议你去咨询一下相关的培训公司。


    所以从你的情况,个人建议不要转职测试,除非你有对口的单位可能会需要测试人员,职位给你保留。

  • 开发对于测试的误解问题回复

    2018-05-27 15:25:01

    原文在https://zhuanlan.zhihu.com/p/37288095,格式更清晰些,紫色部分为原文引用。

    今天看到一篇文章《关于质量保障部(测试)人员的测试管理及KPI工作的思考与讨论》,感觉里面对于测试方面的看法基本都是错误的,但是其中的一些观点很有代表性,就详细回复解答了一下,在这里重新做一下整理和记录。


    因为研发管理不可避免的和测试打交道,会深入到测试管理的种种利弊中,所以今天因为一个问题和测试争论很久。

    故事是这样的:今天团队的一名新人截图告诉我说,测试提的bug,他标记外部原因后给测试,测试又打回来,并回复“请修改状态为已解决”。

    新人就表示了不理解,因为bug的本身是因为研发中需求变更导致产生的历史错误数据干扰,上线后不会有这个情况,严格的说也确实不应该是研发的开发bug。

    但是测试缺认为,虽然你是历史数据,但是我确实发现了问题,你标注外部原因,是对我工作的否定。

    经过沟通,确认了问题的核心是,测试对BUG数量,BUG等级,BUG有效率进行了绩效管理和考核,而《外部原因》这个状态的bug不会算在有效BUG统计中。

    也就是说,开发和测试对这个BUG的状态共识并不一致。

    测试角度释疑:

    个人一直不建议测试人员和开发人员对于缺陷是否需要修改直接进行交流,因为太容易产生文中的矛盾。个人觉得比较理想的状态是缺陷提交后有一个确认过程,比如通常每天测试完成,个人习惯找项目经理确认当天发现的缺陷,确认哪些是缺陷哪些不是缺陷,或者确认是缺陷但是项目经理认为可以暂时不修改,因为不涉及具体的修改缺陷的开发人员,所以即使开发人员有意见认为不需要修改,请先去找项目经理沟通,项目经理确认后再和测试负责人重新对缺陷进行确认。这样通过中间人不易产生矛盾。

    开发人员可以说测试人员提交的缺陷不是bug,这是很正常的行为。但是对于一个问题是否是缺陷测试人员有自己的标准,此标准不会以开发人员的看法改变。当缺陷出现争议的时候应以测试人员为准,因为缺陷为测试人员提交,需要测试人员确认验证后才能关闭,开发人员责任仅限于缺陷修改。

    对于文中的历史遗留问题,开发方既然知道是问题,那么在测试的角度就是缺陷。测试通常没有必要理会缺陷发生的原因,缺陷存在就是存在,开发人员的职责是把缺陷处理掉,至于开发人员说上线等非技术手段就能处理的问题,在测试这边是不存在的。因为太多情况下开发人员都是在应付,即使到线上环境,此问题也未必会解决。测试人员遇到过太多类似的事情,所以很多时候不会信任开发人员的解答,只有修改并经过测试人员验证过的缺陷才能关闭。


    定义
    探讨这个问题,我觉得首先要定义清楚两个个事情:
    1、BUG其实是要分两种类型的。
    即 生产BUG 和 测试BUG。
    这两个问题应该单独管理并分开讨论。很多公司对于这两种问题从工具到认知都是分开处理的。
    2、定义一个名词《真实bug》,也就是开发完成交付后,测试拿到的研发成功他客观真实存在的真实bug数目。
    这个不等于测试提交的bug数目。
    生产bug越少,测试bug越接近真实bug。
    测试bug完全等于真实bug时,生产无bug。

    测试角度释疑:

    测试人员的工作是发现缺陷,无论什么样的缺陷,和缺陷数量无关,和缺陷质量无关,缺陷就是缺陷。

    对于测试人员来说,并没有区分什么生产BUG、测试BUG、真实BUG的必要性。测试人员都了解缺陷具有无尽性,只要有时间,总能发现新的缺陷。

    项目需要考虑进度、成本、质量,测试过程同样需要考虑这些内容,需要在有限的时间内发现尽可能多的缺陷和影响比较大的缺陷,这才是一个测试人员体现价值的地方,所以才会有需求评审、测试计划、测试用例等等。

    总之,生产BUG、测试BUG、真实BUG在测试人员这里没有必要区分,因为定义本身就是有问题的。


    什么是质量保障工程师
    我们再来明确下一名质量保障工程师的定义,测试人员都喜欢叫自己质量保障工程师,部门叫质量保障部,那么顾名思义,测试 就是进行质量保障的。而保障的质量,当然是上线的质量,而不是开发后,那是开发的事,测试能决定吗?
    所以一名合格的测试,首先要保障上线后的bug数目小于预期。上线后能够尽可能的没有bug。
    也就是说,测试工作的究极目标,就是要上线后没有bug,至于需求分析、用例编写、测试、回归,沟通,管理,这些过程,都是为了实现最终目标的手段和方法,那么这个过程中产生的bug数目,即测试bug,还有意义吗?什么才是有意义的呢?

    测试角度释疑:

    没有质量保障这个叫法,通常说的是质量保证。质量保证是QA(Quality Assurance),QA主要工作是检查流程是否符合预定目标,比如项目计划说要有需求,那么QA人员会在计划时间检查是否需求人员完成了需求文档,需求文档是否进行了评审。测试主要工作针对产品,发现产品中的缺陷。

    虽然很多非测试人员都认为质量保证和测试两者是一样的工作,但实际是不同种类的工作。一个测试人员通常不会叫自己质量保证工程师的,我们只会叫自己测试工程师。

    现在在很多公司,确实不区分QA和Test,工作内容也同时包含两者,但是两者实质确实不同的工作内容。

    质量是产品的内附属性,可以认为无论是QA还是Test主要是为产品的质量目标服务。产品开发出来,质量上限实际就已经决定了,Test可以通过工作使产品努力达到质量上限目标;但是开发和QA可以提升这个质量上限,比如QA可以要求开发做单元测试和集成测试,而测试通常是没有这样的权利的。

    测试的工作内容是尽可能的发现产品的缺陷,对产品上线后的问题通常并不关心。这里有一个测试清除率的概念,就是测试的缺陷没有在当前期间发现,遗留到了下一个阶段,这个可以对测试做一个考核目标,但是并不是测试人员关心的问题。测试人员只会关心当前阶段如何尽可能多的发现缺陷。

    测试可以认为是对质量属性的一种度量,通过测试发现的缺陷,可以了解当前产品的质量情况。比如测试发现的缺陷较多,可以认为产品的质量较差,并不是缺陷全部处理了,就认为产品质量好了。因为发现的缺陷越多,可以认为没有发现的问题更多,产品本身质量就有问题。还是那句话,提升质量更多靠的是开发人员和QA,到测试这里,一切都已经太晚了。


    传统kpi的参数分析
    1、bug的数量和bug的级别
    我认为,测试过程中的bug数目,bug等级,统统没有任何意义。因为各个需求复杂度不同,各个需求开发人员不同,开发周期不同,开发质量不同,这些会决定真是存在的BUG总数就不同。
    比如需求A ,到交付时,真实BUG数目是100个,测试测了60个,其他40个上线了,这算成功吗?
    比如需求B,到交付时,真实BUG数目是10个,测试测了10个,其他0个上线,这算失败吗?
    结论:比较两个分别负责需求A和B的人员 产生的bug数量和bug级别,没有任何意义。因为你也不清楚真实bug数目,并且无法预估。

    测试角度释疑:

    只要在测试用例的覆盖范围内,测试发现了多少缺陷就是多少缺陷,即使测试阶段测试人员发现了10个问题,到客户那边发现了1000个问题,也无法说测试人员是失败的,因为测试人员可能已经在他的工作范围内尽力了,测试人员都清楚并不能用缺陷数来度量测试成功或失败。

    在通常情况下是可以对缺陷进行预估的,比如CMMI到4级后,度量数据都应该限定在一个比较确定的区间范围内,缺陷数据也不例外。无论是测试缺陷还是现场用户缺陷,都是可以在计划阶段就预估的,只是需要很**的开发流程和一定量的成本。


    2、bug的有效率
    有效率的定义应该是 bug是否是有效的,所谓有效,那其实就是 bug是否是bug,这个当然是有意义的。但是其实对于中高级以上的测试,既然提出了bug,很少是使用方式,或者执行流程造成的不是bug的无效bug,所以这儿数值,能力达到一定程度,变化并不会特别大。
    另外这个值其实从统计学上,仍然具有缺陷,即数据量样本越大,也就是越大的需求,越复杂的需求,出现无效bug的概率越高,有效率月低,所以并不能完全说明什么。
    结论:bug有效率,有一定程度的意义,kpi占比可以较低。

    测试角度释疑:

    这段我从头到尾都没有看懂什么意思。缺陷就是缺陷,没有是否有效的区别,每一条缺陷都是有意义的。

    感觉答主对中高级测试有误解,中高级测试是可以用更好的手段发现更多的缺陷。举个例子大概说明一下,比如初级测试人员的工作可能只是执行测试用例,中级测试人员负责编写测试用例,高级测试人员可以通过开发测试工具、优化测试流程、通过对业务的熟悉编写较少的测试用例发现更多的问题等等。无论初中高级测试,绝对没有什么高级测试发现的缺陷就一定比中级的好。还是那句话,高级测试可能发现初级测试发现不了的缺陷,但是就缺陷本身没有高低贵贱之分,缺陷本身没有有效无效之分。

    对于缺陷,测试人员通常使用严重性来区分,比如一个缺陷,可能对于产品质量影响比较大,不修改此功能就无法继续使用,那么可能就是一个严重缺陷;比如仅仅是一个文字问题,开发人员连续使用5个叹号做强调,我可能就会提一个轻微缺陷,告诉开发人员最好一个叹号都不要用,也不要用红色之类的提示,所有的提示要统一风格,避免引起客户的不适感。

    开发人员对缺陷的区分主要是优先级,就是修改的顺序。比如一个缺陷,对于测试人员来说可能严重性很高,但是开发人员认为其他缺陷更紧急,测试人员发现的缺陷虽然引发的后果很严重,但是客户很难触发这个缺陷,那么可能就放在最后修改,开发人员会优先修改客户容易发现的缺陷。


    应该怎么做?
    大家发现,所以一个质量保障工程师(测试),最重大的产出都不具备考核价值,那么我们应该如何考核测试的KPI呢?
    根据上文的例子,我们很容易发现,其实关键的问题是需求A开发完成后,他的真实BUG数目是不可预估的,高质量的开发和设计过后,充裕 的时间过后,他的真实存在的bug可能很少,甚至不存在。
    相反,低级工程师、不了解业务的人员开发,时间过渡紧迫加班赶工,等诸多因素可能让真实bug较多。
    在这种情况下,我们要保障的是 尽可能的发现真实bug,尽可能的让自己发现的bug数目接近或者等于 真实bug数目。
    所以,我们为此付出的努力,工作方式,流程,才是我们考核的更重要的部分。

    测试角度释疑:

    缺陷度量数据是可以预估的。

    每个公司进行大量的项目后,只要有一定的测试数据收集和分析,新的项目根据规模、类型等至少可以在数量级范围内对相关数据进行预估。测试工作也都是在一定时间和成本下进行的,所以测试一定也会考虑投入产出比。


    1生产bug预期达成比
    回到最初关于 “质量保障的定义”,很简单,我们首先要衡量的是一名合格的工程师有没有达到保障质量的目标,即如果上文提到的《生产bug》超出预期,那么工作其实是不合格的。
    但是bug预期是一个较为抽象难以量化的东西,只能根据用例复杂度和需求复杂度等具体的需求表述,根据以往经验和团队能力配比,以及时间投入相关,由产品、研发、测试共同制定一个尽可能客观的预期bug数目标准。
    比如一个10人/日的需求 ,bug预期是3 ,计算预期达成比。
    所以在KPI考核中,生产bug的数目可以占到绩效占比的很大程度.

    测试角度释疑:

    生产BUG超出预期,可能是因为需求没有做好,产品和客户要的不一样;生产BUG低,可能是因为客户忍耐性高或者水平不足或者你们的产品客户买来根本就没有用。所以生产BUG不建议作为度量目标,因为你无法预期客户的行为。

    度量目标通常是在可控的范围内制定,无法受控的度量目标就是在给自己挖坑,有过实际经验的兄弟姐妹都应该懂。


    2、用例编写
    详细的用例会覆盖客户的各种实用场景,保证在测试过程中尽可能的发现所有的真实bug,而优秀的用例编写又能让测试用最少的时间,完成测试。所以符合规范的、考虑全面的,有逻辑条例的用例编写,是kpi考核的关键参数。
    这条其实会和很多人认为的bug级别有关联,有些管理者认为能够发现高级、严重bug的工程师是优秀的,实际上,如果程序真实bug没有严重bug,你又何谈发现呢?但是不管有没有,你的用例应该覆盖的到严重bug,也能考虑到各种复杂场景,这个才是更重要的。

    测试角度释疑:

    测试过程也是有时间和成本制约的。

    测试人员写用例,也需要考虑花费的时间。而且前期的需求、设计文档是否真的和实际产品一致,在测试用例上的投入是否值得。这个话题太大,我也很难细说。

    从我的实际经验来看,开发人员写的文档很多都是用处不大的。根据开发文档写测试用例很多时候很难做到,而照着软件写用例,同样的实际我可以发现更多的缺陷。所以测试用例的编写在实际工作中很多还是在测试人员的揣度思考下进行,既要符合KPI的要求,又不要太费时间,还要对得起自己的职业道德,总之不是实际遇到此情况的人员,很难具体的评论说明。


    3、bug描述与定义
    发现了BUG如何第一时间周知相应开发,如何清晰的表达清楚bug内容,如果简介的描述出bug复现的场景。
    如何总结出导致bug的真实操作原因和背景。这些是一个测试人员能力高低的重要标准。
    优秀的工程师对于非必现问题的定位高效,排除无效操作,去除掉障眼法,找出真正必现的使用流程,问题的本质,大大提高了bug的解决周期。
    举个例子 初级工程师“点击下单报错”高级工程师“在选择多规格产品,有优惠的情况下,选择下单报错”

    测试角度释疑:

    测试人员发现缺陷通常会第一时间提交到缺陷库中,具体的分析处理是事后的事情。测试很多时候一天发现几十个的缺陷,不可能每一个都和开发人员沟通确认,通常只有在缺陷过于严重,无法继续测试的情况下,才会联系开发人员。

    我通常不会去理会缺陷发生的原因和背景。因为我主要做的黑盒手工测试,产品对于我来说就是一个无法探知内部细节的黑匣子,我只能通过一些操作,感知发生的回馈,此回馈如果和测试用例的预期不符,那么就是缺陷。至于为什么发生,那应该是开发人员关心的事情。

    测试人员更关心的是发生了这个缺陷,是否其他模块同样会发生,是否进行不同的操作会发生同样的缺陷,是否此缺陷会引发其他的缺陷发生等等。测试人员更关心如何通过发生的缺陷找到更多的问题,而不是去关心缺陷为什么发生和如何修复。

    初级测试和高级测试,对于同一个问题的提交应该是一致的,这个是测试人员的基本能力。不要认为一个问题不同的测试工程师会有不同的提交,缺陷本质都应该一样,缺陷发生的模块,操作过程,严重性,截图等等。

    我个人不建议测试人员对缺陷提出处理意见,比如打印有问题,测试人员应该提出的是无法打印,可以说打印控件无法加载。如果更进一步的提出使用A打印控件更好个人就认为有些过了,因为测试人员的关注点一定是缺陷本身,说多错多,只能给开发人员留下测试人员开发能力不行的借口。


    4、BUG生命周期跟踪与推进
    对每一个BUG的产生、经过、结果都有良好的沟通,并了解问题的真正原因,记录归纳并协助其他团队总结分析。

    测试角度释疑:

    测试有操作不明白的地方可以询问开发人员,开发人员对于发现的缺陷有不明白的地方可以问测试人员。了解问题的真正原因个人认为应该是开发人员而不是测试人员的责任,因为通常测试人员并不会负责处理缺陷,所以真实原因只有开发人员知道。通常一次系统测试过程,会发现百级甚至千级数量的缺陷,分析过程实际是一个很大的工作量。


    5、需求审核
    作为整个研发中心的一员,在需求评审阶段给出合理性建议,提出需求遗漏的问题或者逻辑错误或者质量风险,都是一名高级工程师必备的能力。也是有效降低后期真实bug数目。
    6、测试报告
    定期整理需求测试报告,分类、总结,风险预估。有效的保障整个需求能够持续,安全顺利的进行是高级工程师重要的考核方向,给开发团队和产品团队做kpi数据支撑以及需求总结。
    7、工作效率管理
    如何有设立自己工作的时间计划、优先级安排,以及排期后准时达成,时间预期排期的准确性等情况。

    测试角度释疑:

    至少在我的经验里面,需求大部分并不能提供太有效的信息,顶多知道有什么功能,大概内容是什么。我主要做系统测试,系统测试的参考就是需求规格说明书,但实际对我来说,绝大部分项目需求并不能给测试人员一个很好的参考,需求评审只能发现一些比如性能指标不合理啊,功能说明在各个地方不一致,数据库设计有问题等等,对于最后的测试过程并不能起到决定性的作用。当然了,可能其他的公司会有需求写的很好的,可以对测试人员的测试过程起到很大的指导作用。


    总结:
    上文有些东西是不好量化的,但是不能因为不好量化,就去量化没有意义的量化,用bug数目考核。
    上文只是从有没有好处的角度分析bug数目。并没有说统计坏处,这个大家可能都有经验。不提也罢。
    反是保障测试中发现的bug尽可能接近 真实bug的有效手段和方式 ,是值得考核和提升的。
    最后:
    经过这个事,详细的思考总结了下测试工作内容及绩效管理,对自己是一个记录和成长,也希望对大家有帮助,引起讨论,更希望大家给些意见。

    测试角度释疑:

    测试的KPI是很多测试人一直的考虑的问题。测试出数据的地方通常只有测试用例和缺陷,所以从度量角度只能从这两者考虑,里面还划分很多的属性,比如严重性等,不是测试人员通常没有必要了解这些内容。

    在测试的角度,从来不存在真实bug。我想也不会有哪个公司用真实BUG去考核测试人员。


    其他的就不多说什么了。

    其实写这么多,主要是太多的开发人员对于测试人员的工作不理解,此文就是,所以希望看到此文的无论开发人员还是测试人员还是其他过客,能了解测试人员多一些就多一些吧。

    另外,很多的回复内容仅以自己的工作经验为准,个人并不保证全部正确,每个人对于同一个事件有自己的角度和看法是很正常的,工作不同,具体工作内容不同,对事物的看法不同也很应当,本人只是说明了自己的工作实践和自己对于测试工作的一些思考。

    就是这样。

    over。

  • 别人对我的测试评价

    2018-05-27 15:23:36

    很久没有更新了,现在主要在知乎,链接 https://www.zhihu.com/people/qqrrm ,欢迎大家去访问。

    正文:

    大前年的时候,公司离职的同事,给我推荐了他所在的公司,说要招测试管理,问我是否有兴趣,我就去面试了。当时还是比较急的,当天下午给他们发了我的电子简历,接着我打车就去面试了,没有怎么准备,而且当天有点感冒,状态算不上太好。
    那是一家小公司,开发不到10个人吧,做什么忘记了,但是待遇相当不错,我的同事去那里工资翻了一倍,就是会很辛苦。
    到那里有两个人面试我,一个应该是老总之类的,一个应该是开发主管。当时聊了两个小时左右吧,反正最后我出来的时候渴的不行,在他们的写字楼下买了一瓶水。

    大概的过程有些忘记了,我应该说了一些自己的测试理念,他们两个人感觉对于测试都不是很懂,总要往自动化测试上说,认为自动化测试才是测试,可以解决大部分问题,而我的观念是应该给开发更多灌输测试观念,测试只能保证保底的质量,开发或QA才能真正的提高质量。测试过程要一步一步来,不要一开始就想着做自动化测试,从黑盒测试开始,慢慢提升,一下子到自动化测试效果未必好。当时的自我感觉作为十年加的测试人员,当时聊的都是干货和自身体悟,没有什么忽悠的成分。

    第二天的时候,老同事告诉我面试没有过,我询问原因,给出了下面的答复。


    ------------
    XX说你这10多年没有属于自己真正的知识体系,没有系统的研究过测试方面的技术,还停留在对工作的应付上,不积极主动。
    ------------


    当然了,也许我是实话说多了,比如我承认在当前公司测试工作不多,测试处于辅助位置质量的主力是开发,出现问题应该职责分摊,这些内容也许在开发那边的看法都是减分项吧。自认体系之类的个人还算不错,2007年软件评测师刚出来就考了,市面上的测试书籍也是看到基本就买了,软件项目管理师也考下来,公司本身CMMI3、ISO9000之类的也都熟悉,javaeye,51testing,infoQ也是基本每天都看,但是在别人那里还是评价这么差,这就是自我感知和他人看法的区别吧。

    最后仍然给了他们公司一些建议,不知道是否他们找到了合适的测试人员。


    ------------
    不积极主动的锅我可以背一半。但是测试体系和技术,自认还是够测试人员的行业标准的。

    昨天感觉X老师他们更多的关注于自动化测试等方面,但是在没有体系和公司积累的情况下,自动化测试是不可能开展的。外人觉得自动化测试等很高大上,但是昨天就和他们说了很多了,小公司还是从头来,建立研发体系,加强质量控制,最后才是开展更高级的内容,测试是需要成本的。有时间可以和X老师他们建议一下,首先建立开发规程,先找几个测试人员,把现有程序稳定后,再涉及更多方面的测试内容。

    了解测试的开发人员不多,昨天的X老师他们也未必知道测试是应该如何进行的,等以后有你们公司有开展相关测试工作了,慢慢我想他们会了解测试方面的内容的。测试和开发还是有很多不同的地方的。
    ----------


    算是一个记录吧,本文结束。

  • 发红包怎么测试?

    2016-09-20 10:17:40

    在论坛看到有人问“发红包怎么测试”,就随便写了写,仅供参考。

    下面是原文回复:

    很麻烦的啊。
    参考微信红包随便说说,只能是一个大概的思路,而且我基本不怎么用微信,所以更具体的,还是应该参照开发人员的需求设计文档。

    一、向单人发红包
    发的人:
    1.单红包。就是等价类了,比如限定数字,0,随机数值,最大值,小数点后几位等。
    2.留言。不录入,最大录入,超长录入,特殊字符等等。
    3.出钱相关。比如超过零钱怎么办,领取后是否扣钱等等。
    4.发送的信息的保留,接收后的显示处理
    5.一些异常处理,比如网络断了
    6.安全
    收的人:
    1.是否及时能看到。看到的内容是否和发的信息一致
    2.放置不动,最后超时处理
    3.接收后的效果等等
    4.收的钱是否进入了钱包等等。

    二、群红包
    更多的内容,比如最多多少人,平均分配还是随机分配,随机分配是否是真随机,随机后是否确实把全部的钱都正确的分割了。等等等等。

    我说的比较简略,但是慢慢写,写个千级的测试用例应该不算太难。

    其实没有需求文档照产品测试总会遗漏的,我想红包这样的需求,不会在需求文档中只有一条“需要有红包功能”就完事了吧。

    PS:真的有这样的需求。我在测试一个移动版软件,标书里面真的就一句“软件应该有离线采集功能”,但是离线采集应该采集哪些东西,采集的数据如何整合到产品里面去,都木有了。现在开发在做离线采集功能,我这边写测试用例和测试一下移动框架,顺便来这里灌点水。答案仅供参考。
  • 缺陷就是缺陷,不是其他

    2015-11-13 23:08:30

    http://bbs.51testing.com/thread-1047880-1-1.html

    看到过很多的观点,认为缺陷有分类,比如从严重性分类,比如从优先级分类,比如从阶段分类,比如从属性分类等等.
    但是,实际在我看来,缺陷就是缺陷,缺陷的属性很单一,就是到客户那里,认为这里有问题,就是缺陷,其他都是开发/测试等附加上去的含义,从客户角度并没有太多的意义.
    比如很多人问过,无法重新的问题怎么处理,其实在我看来,并无太多的处理意义,还是看是否可能对客户有重大影响,测试人员可以发现这样的问题,客户也可以 发现,但是很好解释,让客户重现一次,无法重新就应付过去;等客户再次发现的时候,再处理也不迟,如果客户发现了不再提出,说明他不重视,所以从成本角度 看,可以不处理;如果用户反复提出,那么说明客户重视,自然要花时间和精力去处理.其实本身来说,,无法重现的问题,很多时候即使测试人员发现了,开发说 修改了,也无法确认是吧.想想微软的蓝屏,大家心里就应该清楚应该怎么办了.
    还有人说发现了别人没有发现的问题,所以这个测试人员的水平很高.其实呢,这个是两说的问题,第一就是测试人员经验到了,可能发现一些新手没有发现的问 题;或者就是测试人员灵机一动,或者就是随机测试发现了而已,这样的问题,测试人员都很难发现,除非有大量的用户在用,否则我想客户发现的几率比专业的测 试人员会更小.当然了,这样的问题会让测试人员自己心里很爽的,<测试之美>第一篇就说的这个问题,真的很符合啊.
    当然了,我说这么多,并不是否定大家对缺陷管理的意义,产品的质量还是需要测试人员尽可能的保证的.只是给大家提供另外一个客户考虑的视角,缺陷的严重性/优先级等等都是承建单位确定的,甲方真的未必会在乎这些东西.

    一个缺陷,对于测试和客户的意义不同 .比如发现一个严重的问题,但是也许步骤很复杂,发生几率很小,客户几乎不会触发缺陷,那么对客户的意义也许不大;测试人员一个建议,到客户那里也许就是 需求;一个文字上的轻微缺陷,客户可能就认为是你对他的极其不尊重,软件都直接给你废掉.
    优先级也一样,开发人员的优先级和客户的优先级是两个东西.
    缺陷其他的附属也有同样的问题存在.
    测试、开发视角不同,所以会有严重性、优先级的区别,但是客户的视角没有一个统一的定义.客户提交的缺陷,也许经过测试/开发一分析就没有掉了.
    当然了,大部分的情况下,测试发现的问题未必会到用户那里,而且现在beta版横行,也解决了很多的类似问题.
    这个仅仅给大家一个思考,每个角色,对自己的工作都是有观点、有阶级的,一些事情未必较真.

    近期公司刚完成CMMI,其实有很多想写的,也写了一个框架,但是没有心情整理,有时间再说吧.


  • 测试回复集(一)

    2015-11-13 23:06:51

    其实一直发现自己挺阴暗的,喜欢吐槽,回黑暗向帖子,收集一下自己的回复吧.


    <如何让别人看懂自己的测试用例>
    让看的人先写一个他自己看得懂的,你再按照他写的模式扩展.


    <怎么给公司搭建缺陷管理平台>
    随便找一个搭上就可以了,麻烦的是让开发人员用。

    <项目多大才适合做自动化测试>
    主要看成本和收益,比如你的软件只需要测试一次,那么就没有必要测试自动化;如果软件变更不多,需要进行多次测试,从成本收益比看,自动化测试可能就更合适.
    自动化测试个人感觉主要不是为了发现问题,而是保证在软件变更后,不会影响原有功能.

    <软件测试与售后>
    售后很麻烦的,就是客户的出气筒,而且要经常出差,发展前景也不好,其实觉得售前比售后好,但是也要出差.

    <独立去客户测试需要测试哪些内容>
    谁让你干活的,向谁要需求,没有需要至少要操作手册,再没有去问开发人员业务流程.
    了解需求后,根据需求写测试用例.实际测试过程中对用例进行补充.
    测试那些方面的内容,请去和项目经理确认,比如功能/安全/性能等.
    具体的测试用例内容,论坛里面很多,多找找多看看就可以.
    业务方面除非开发过或测试过的人,否则没有人可以帮你的.

    <验收用例怎么写>
    我自己写验收用例的时候,不考虑异常,只考虑常用场景和正常的操作,分支也根据需要不用全部走到,但是需求规格和合同要求要全部覆盖到.
    用例粒度可以粗一些,最好详细说明操作步骤和录入数据,因为操作的人可能不是乙方而是甲方人员.
    总之,一切以安全简单高效为主,只要客户通过验收即可.
    验收用例这种东西吧,还是看客户的,有的要求的多些就多写,少的就随便写点对付过去.
    其实,验收用例本来就应该是甲方或第三方提供的吧.

    <测试用例执行结果和编写不一致怎么办>
    简单的就是提交缺陷,复杂的参考下面的内容,仅仅作为参考.
    1.判断是否预期结果是错误的
    2.再次进行验证,包括各种环境,条件,试出各种错误出现的方式,并了解引发错误最简洁方式.
    3.如果原先的用例没有问题,提交缺陷.
    4.再次进行思考,是否可能会有其他的地方出现问题,探索性测试,需要的时候补充用例.
    5.打开编译器,把bug改了
    6.缺陷自己验证关闭
    7.告诉程序员,you can't,i do.

    <如何确保测试用例已覆盖全面>
    用例评审,找各个方面的人去审核用例,大家都说没有问题了,签字盖章打基线.
    谁敢说不全,没有覆盖到,喏,你的签名在上面呢.
    是否覆盖到,很多时候不是一个技术问题,需求全/设计全/单元测试什么都全,到自己这里,想不全都很难的吧.

    <缺陷单是否需要给质量部门>
    你不给质量部数据,质量怎么能改进啊.
    对一个程序来说,QA对质量的把握更宏观全面些.

    <面试题:A+B写测试用例>
    需要确定a和b是什么,那个+符号代表什么,接着就是不同的玩法了.
    比如a,b有nil或等价的东西.a,b超长,a,b非对应类型,不同的客户端同时发a,b,a,b发送后断掉,发a后隔很久发b等等等等.
    主要从几个方面
    1.正常
    2.数据异常
    3.客户端异常
    4.服务器异常
    5.网络相关
    6.多用户相关
    等等等等,慢慢想,能想出很多东西的.

    <面试题:进行资料收集整理>
    应该是让你google或百度出来xenu和loadrunner的资料给他们发过去.
    是否他们想用这两个工具,所以干脆让招聘的人做整理.





  • 关于《××社保系统》测试的一些想法和建议(2003年1月)

    2014-12-23 17:53:58

    2003年初,到了现在的公司,那个时候公司还没有测试人员,所以就下到了项目组中做测试,不到2周后,根据项目组的项目,写了这份总结文档。
    现在看来,那个时候我的一些想法和现在几乎一样,10多年过去了,其实感觉测试并没有太多的发展,至少在我的角度,看不到测试有进一步的可能,也许测试人员终将消亡,全栈工程师取代一切。

    直接copy会出错,感兴趣下载看吧。

    测试总结.doc(80.5 KB)社保系统。
  • 测试别被敏捷忽悠

    2014-06-20 18:54:44

    这篇帖子原先发表我在博客园的blog里,还有一些讨论,想想还是在这里也发一份吧。这个应该是几个月前的事情了。

           个人对敏捷一直很关注,其实很正常的啦,作为一个资料的深度收集爱好者,在满眼都是敏捷的今天,想不关注都不可能啊。

            腾讯无线研发部副总监张鼎(dylan)写了一篇《反思:别被敏捷忽悠》,里面的观点我个人很喜欢。这个应该是对dylan的访谈整理,也许会和dylan的意思有偏差,但假设不是记者太无良,dylan的思想应该是反敏捷的,至少对敏捷思想有很多的质疑。

          提炼一下dylan的观点:

    1. 敏捷方法会拉低质量标准。
    2. 传统瀑布和敏捷方法没有本质差别。
    3. 互联网软件和传统应用型软件开发没有本质差别
    4. 在一些情况下,文档优于沟通。

          上面的观点是我总结的,具体内容大家可以看原文,有误读的地方请原文作者谅解。

          其实对于敏捷,我的观点一直很矛盾,对开发人员这应该是好的,但是对于测试则未必。

          敏捷从根本讲应该是开发方法,不是方法论,所以很多人可以把敏捷嵌入到CMMI、RUP等开发流程框架内。换句话说,敏捷说了开发人员应该怎么做,但是没有说比如测试人员做什么,也就是说,无论XP还是Scrum等,基本都没有考虑测试人员在其中应该做什么。当然了,有些开发人员会说,还要测试人员做什么,有TDD、BDD等,测试人员滚一边去玩吧。但是测试人员真的可以缺席吗?

          测试人员其实一直努力的在希望嵌入到敏捷开发过程中,比如段念的《什么是敏捷软件测试》,朱少民的《究竟什么是敏捷测试》等,甚至有专门的书籍说敏捷过程中的测试,但都像是CMM的效颦TMM一样,没有太多的信服力。感觉就是在敏捷过程中,强加了一个测试角色,做和传统测试差不多的活儿,看上去很美,但是总觉得相当的不协调。

          测试是什么,测试是质量的控制和度量。就和帖子最开始的dylan说的一样,敏捷实际在降低质量基线。敏捷的说法是从根源上,通过TDD、BDD、用户现场确认等方法,解决质量确认问题。认为通过用户认证了,就是好的。但是用户不是专业的测试人员,对质量等的认知,其实是有一定偏差的,敏捷方法貌似总在有意无意的忽视这种质量偏差。

          在软件工程中,有一个基本的观点,不要让开发人员测试自己的程序,但是在敏捷过程中,测试角色是大部分由开发人员直接兼任,当然带包装的--测试驱动开发,但实质还是开发自己负责自己部分的质量问题。产品的生产者是开发,质量的提供者是开发,难道质量的确认者仍然是开发?或者再加上用户?这样做是否会出问题?

          从根本说,敏捷方法的研发者都是开发出身,对测试我想未必有深入的了解,敏捷方法其实规定的都是开发人员的行为,但是问题就在于没有留出测试验证的位置, 测试人员即使挤进去,也有很多的力气无法使用上。比如敏捷测试过快,是否有必要重复的做开发人员做过的测试;敏捷变更太多,测试人员能否跟上变更的节奏等等。

          我这里仅仅是提出问题,并没有解决问题。敏捷开发我还是仅从大家的资料中了解分析,测试也更多从理论和别人的文章中获取敏捷测试相关内容,也许我的整篇文章观点都是错误的,但是至少希望能给测试人员以思考,至少能提出一个让我认为合理的、可以容易确认执行的敏捷中的测试过程,也就不枉我打这么多的字了。


  • 近期我所遇到的一些测试情况

    2014-01-29 10:26:40

    我在的公司,可以说是一个作坊,10年前,我来的时候,还没有专职测试人员,那个时候公司就过了cmm2,我现在都不清楚没有测试人员怎么过的。
    我来公司后,测试部就组建了,有的时候人多,有的时候人少,多的时候7、8个人,少的时候快2年时间,就我一个测试人员。
    当然了,从上面情况也能看出,公司也不重视测试,我个人懒的换地方,我所在的城市,专职测试可以去的地方也不多,也就这么对付着过来了。
    公司还是有一定规模的,大概70多开发人员,cmmi3、iso9000等等也都有,看上去比较正规,当然了,在我内部人的看法就是作坊。
    去年11月的时候,我最后一个手下离职了,又变成了光杆司令,当然了,我个人都习惯了,就和主管领导说,给我人啊,虽然没有活儿,但是真的要测试,总不能我一个人做吧。
    嗯,测试工作一直是不饱和的,去年我的实际工作量时间,不超过6、7个月吧,全年很多时候都空闲着,我个人平时喜欢看小说,这也是我不舍得走的原因之一吧,很清闲,可以做自己喜欢的事情。
    其实我去年一年,做的最多的事情不是测试,是给各个项目写测试文档,平时的时候,各个项目组,都不喜欢做测试,只有在项目验收的时候,我测试需要出具测试用例和测试报告,才会找我。或者做测试,但是测试到一半,1、2轮的时候,开发人员就以种种理由闪人了,比如其他项目组要用人,或者去现场开发等等,所以我去年只测试了一个完整的项目,大概1个月的时间,其他都是扔了一大堆的缺陷在哪里,没有理会了。
    当然了,这和公司的情况也有关系,第一,我们主要做行业软件,大部分的时候,开发人员都是在现场开发,边开发边上线,那边就直接用了,很多时候可能不希望测试人员插手,至少测试提出的一大堆问题需要改不是;第二就是很恶心的任务单制度。我们公司在建立项目的时候,就给出了项目的费用和人力计划,要报销等,必须在额度内,但是有一个问题,大家也都知道,开发人员几乎不可能在进度的设定内完成,所以进度一定是不够的,这种情况下,谁还会考虑测试人员?我一直和项目管理部的人说,测试要独立出来,不要走项目内经费,要不测试根本不可能有活儿干,那边一直在推搪。我去年干的活,还有一些费用没有报销,因为超过额度了,研发经理说等下次再做2期的时候,给我转过去,但是2期什么时候,天知道。
    上面的介绍一下背景,下面就是近期遇到的一些情况。

    公司有一个大项目,实际这两年,公司都指望这个项目,所以人力什么的很充足,还是老规矩,现场开发,去年要结项,去写测试用例,需求文档之类的是不用指望了,就是按照软件写吧,反正他们的说法,有就行,看都不看。当然了,写文档的过程中,测试人员一定会发现一些问题,实际软件已经在使用快1年了,个人觉得还是比较稳定的,问题算不上太多。写好后给他们了,至于改不改,和我无关了。

    2014年,这个软件在其他的地方销售成功,根据客户的要求,要做些改动,所以相当于原版本的一个升级。在2014年项目管理部出台了一个决议,说全部项目的计划、需求都需要评审,既然按规矩来,那就做吧,评审计划。既然有计划评审,当然在评审过程中,我作为测试要争取自己的利益和资源,其实当时开了一个下午,项目经理、我、项目管理部、QA,内容不多,大部分时间都在抢资源。虽然测试现在只有我1个人,但是还是说要3个人、1个半月(计划是2个人,1个月)。中间的细节就不说了,其实这个软件是一个很大的项目,160多个模块,业务流程也很复杂,他们开发了快2年,我对原有的版本比较熟悉,新的版本也就是写测试用例的1个月,勉强算了解。

    计划定下来了,人没有啊,找人。在我最后一个手下离开的时候,我就和主管领导说要招人,他的意思是,你测试现在也没有工作,即使招到人,也许过两天就跑了,所以等有工作的时候再说,你看开发组谁没有工作,到时候就支援你。嗯,这次有工作了,就从项目组暂时找了一个人,计划充当测试人员。还少人员啊,就和做软件的项目组说,测试没有人,到时候能否支援,项目经理也答应了。一切看起来挺好的吧。

    正好,有一个其他部门的人,强烈要求做研发,我们的研发副总看,不好推脱(小老板招的人),就扔给我了。嗯,现在有两个测试小白等着我浇灌了。

    既然这样,写ppt,做培训资料,后来看到有项目经理对我的工作比较感兴趣,那更好啊,开大培训,就介绍我们系统测试的工作。

    其实我写的ppt很少内容,只有13、4也,我的ppt原则是简略版的,只要说的内容,就不写,ppt只是一个引导。我第一次讲培训,效果不知道怎么样,反正很多人,20多吧,各个部门都来捧场了,我还以为讲2、30分钟就可以了呢,结果讲了1个半小时,我自己都怀疑自己怎么那么能说的。
    ppt主要内容就是:质量是用户的要求;测试是质量控制和度量,终极目的是验证需求和确认质量;,测试的工作是发现问题;一个软件开发出来后,有一个质量上限,测试的工作是接近上限,但是无法到达,提供质量的方法是开发和质量保证,测试做的工作主要是验证和修补,对质量的提高没有决定性作用;质量成本是有数量级的差别的,越到后期,处理成本越高;任何问题,等到系统测试发现和处理,全部都晚了。

    反正说了很多,效果如何不清楚,培训后,我问了很多人,都说挺好,我想可能还是客气话居多。

    当然了,这个是科普性质的培训,后来我还专门花了一天的时候,给两个新人,做具体测试内容应该如果做的培训,效果如何现在还没有开始测试,不清楚。

    原先说了,我和软件的项目组说要借调一个人,现在人齐了,本来我想测试人员越多越好,就去和研发经理L确认人员,你知道他怎么说吗?一周时间够不够,我当时就思密达了(他们在外面开发,没有听我的培训)。我说,你们的软件开发了两年,不说别的,你培训客户需要多久。L说,客户都知道业务啊,培训怎么用就行了。我说,老大,除了我,另外两个都是新人,业务都不熟悉,1周时间恐怕你的软件做什么他们都未必清楚。反正最后说了很多,他的人我也就不指望了。还有,本来我的计划是在年前,让他们去现场熟悉一下原版软件,这样年后测试其他地方的升级版,大概业务也能熟悉,但是万恶的任务单,他们就是不下,我也无法派工。

    未完待续。回家喽....................
  • 测试过程3步走

    2012-07-27 22:41:42

    在我们公司,还是作坊式的开发,需求、设计基本没有,都是客户说几点要做的,其他都看开发人员的想象力。
    这样在很少的需求文档,并且没有设计等内容的情况下,测试如何进行测试?
    下面就以我近期测试的一个项目为例,说明在这种情况下,我如何处理这种情况。

    我接手测试的是我们公司内部开发的一个项目管理系统,需求都是由项目管理部的经理提出,现有流程都是走的纸质单子,想把各个项目组的流程电子化。
    我们测试并没有介入前期,所以直到交给我们,才看到具体的软件样子。
    同期给我们的,只有数据库结构设计,其他莫有了。

    开始第一轮测试。
    第一轮测试,我主要是确认软件功能都是正确的。
    项目管理软件,主要由3个部分组成,一是立项管理,就是销售或项目经理建立项目,指定项目经理,项目类型,预计人员,里程碑,项目回款等等。立项管理这里还有项目管理部等的审批,以及修改等内容。二是任务单,主要是确定做项目的人员,每个活动都对应到具体的人上面,根据人员计算项目花销。三是借款报销,主要就是在项目的框架内,进行直接借款或通过任务单借款和相应的报销。
    功能算不上太复杂,大概6个大模块70个左右功能。
    第一轮,主要是了解系统由哪些功能组成,而且确保每个功能的正确性。比如每次操作,我都会去查数据库,看是否数据进行了相应的变更,通过数据库的设计,可以更好的了解程序员是如何想的,程序是如何运作的。
    每一个功能都需要进行了解和确认,比如立项的时候,有间接费用、直接费用、管理费、利润等等数据,每个数据都需要了解从哪里来的,以及如何计算,确保计算结果的正确性。
    另外,收集需求的时候,他们既然把大部分的东西都写在自己的笔记本上,而不是整理出来,所以很多时候,都需要开发人员具体的解释。
    总之,第一轮过后,我保证对数据库的每个表,每个数据都心里有数,知道每个操作会影响到哪里。

    第一轮提出问题后,经过开发人员的修改,进入第二轮。
    第二轮我不很关注功能,因为第一轮基本确认了所有的功能,保证其有效性,第二轮我主要从业务逻辑着手,发现其中可能存在的漏洞。
    比如很多办理业务的过程中,需要先查询再办理,但是很多时候,查询结果只有入口,没有出口,这样随着项目的更新,查询就几乎失去了意义,因为很多都不是办理需要的。
    还有像是任务单借款报销,这里并没有和任务单很好的结合,实际借款和任务单并没有太多关联。
    这样的业务漏洞,在第2轮提出了很多。第二轮我所做的就是深入业务,了解各个业务是如何运作的,从整体上把握整个的项目。
    在第2轮,终于从开发人员那里弄来了需求列表,上面都是项目管理部提出的对软件的要求,发现了很多不符合要求的地方,看文档日期,半年前的需求,一些确实是问题,一些后来在他们的笔记本上又变更了,其实后面第3轮,还要来了补充的需求,挤牙膏一样,很多东西他们自己都忘记有了。

    第三轮我关注接口。
    经过第二轮理顺业务,对整个系统应该熟悉了,就需要考虑一个地方变动,会对其他地方有什么影响。比如项目里面有客户,那么我把客户删除了,对项目有什么影响。
    或者我提交了1个任务单,但是对此任务单多次借款和报销,是否会有问题。
    另外就是磨一些比较细的地方,比如立项有4种类型,不同的类型对借款报销等的影响等等。第一轮也做过相应的测试,但是第3轮的时候,随着系统的熟悉,实际补充了很多的用例对可能有问题的地方做更细致的测试调整。

    这样经过三轮测试,功能、业务、接口都没有问题了,剩下的就是慢慢的和开发磨了,很多时候一个问题经过多轮没有修改,或者原先一些问题没有发现,但实际都不影响大局。这个可能再经过3~5轮,项目就大概能收尾了。

    测试用例我是第2轮才开始写的,因为刚接触软件的时候比较兴奋,还是第2轮沉淀和熟悉的时候,写用例更适宜,而且经过第2轮,软件很多地方有很大的调整,第一轮即使写了,也都需要变更。

    还有就是一定要从业务的角度思考系统,功能是死的,但是为什么有这个功能,每个测试人员都需要了解。数据的流向也需要切实的把握,我是很喜欢用截图软件截图的,因为随时进行比对,看哪些内容有了变化。

    大概就是这些了,只是自己的一点经验,可能大家有更好的测试方法,不妨也都说出来进行参考。
  • Mantis解析(四)

    2011-08-19 19:39:54

    (四)core.php到底做了什么

    下面的分析,我没有解释全部代码,只是挑选主要的说明Mantis都在后面做了哪些魔法,感兴趣的可以直接去看完整的代码。

     

    1.      constant_inc.php

    45行:require_once( dirname( __FILE__ ).DIRECTORY_SEPARATOR.'core'.DIRECTORY_SEPARATOR.'constant_inc.php' );

    这个是Mantis中定义的常量,在各种函数中,调用的很多不是硬编码,而是对应的常量数值。

    50,51行的

    if ( file_exists( dirname( __FILE__ ).DIRECTORY_SEPARATOR.'custom_constants_inc.php' ) ) {

           require_once( dirname( __FILE__ ).DIRECTORY_SEPARATOR.'custom_constants_inc.php' );}

    这个是如果你需要定义自己的常量,请在根目录下面新建custom_constants_inc.php文件,把自己定义的常量定义到此文件中。按照基本的原则,没有绝对必要,不要修改Mantis中原有的文件,Mantis本身已经给你留下了自定义的接口文件,此custom_constants_inc.php文件就是。

    下面还有很多类似的情况,有一个缺省的Mantis配置文件,就有一个对应的用户自定义文件

    2. config_defaults_inc.php

    62行:require_once( dirname( __FILE__ ).DIRECTORY_SEPARATOR.'config_defaults_inc.php' );

    config_defaults_inc.phpMantis系统默认的各种参数。此文件和下面config_inc.php是同样作用的文件,但是config_defaults_inc.php是系统预设的,config_inc.php是用户自己定义的。

    3. config_inc.php

    64-67

    # config_inc may not be present if this is a new install

    if ( file_exists( dirname( __FILE__ ).DIRECTORY_SEPARATOR.'config_inc.php' ) ) {

           require_once( dirname( __FILE__ ).DIRECTORY_SEPARATOR.'config_inc.php' );

           $t_config_inc_found = true;}

    安装或升级Mantis的时候,自动把数据库等信息写到此constant_inc.php文件中。如果需要自己定义一些参数,也都是在此文件中写入,可以写入的参数参考doc目录内administration_guide.pdfChapter 5. Configuration章节。在根目录的config_inc.php.sample文件内也有一些相关的示例。总之,自己需要定义的参数,就在config_inc.php中实现。

    如果config_inc.phpconfig_defaults_inc.php参数有重复的情况,以config_inc.php中定义的为准。

    4. custom_function_api.php

    244行:

    require_once( 'custom_function_api.php' );

    用户自定义的函数,请加入到此文件中,缺省没有此文件,需要的时候自己建立。

    5.其他

    Core.php里面还定义了很多内容,比如载入core目录下面的各种api文件,定义时区,出否加载wiki等,但是主要的,还是上面的几个文件。

     

    总结,core.php主要加载Mantis使用的资源和库文件,不妨当成缺省的命名空间,而且预留了用户的接口,主要就是变量config_inc.php、常量custom_constants_inc.php、函数custom_function_api.php,后两个文件缺省没有,需要的时候由用户手工建立。在自己定义或开发的过程中,不要修改Mantis的原文件,都使用此三个文件即可。

    具体的示例,参考doc目录内administration_guide.pdfChapter 7. Customizing MantisBT

  • Mantis解析(三)

    2011-08-19 19:39:17

    (三)Mantis的结构分析

    其实这个应该放到最后的,因为修改后,才发现很多的东西,Mantis都已经想到了,东西都在代码中,而不是在页面配置里面,所以很多时候,想要的功能,直接修改源码参数即可。等到(四)的时候,大家就可以具体的了解其中的内容了,此节仅仅对Mantis的结构进行说明。

    我本人不是开发出身,原先也不了解php,都是此次因为需要使用,才现看的php内容,好在不是需要开发一个没有的系统,而是在一个现有的体系下找到其中的节点和关键,这个就方便多了,所以下面的内容,仅仅代表本人的一些看法,可能有不对的地方,大家可以随时指出,谢谢。

    Mantis的目录很多,但是关键的目录目录只有一个,就是core目录,当然了,因为汉化的缘故,lang目录的strings_chinese_simplified.txt,也是我们关心的内容。还有就是根目录下面的各个php文件。

    其实感觉Mantis的结构安排不尽合理,php目录下面的大部分内容,都应该放置到一个专门的目录,因为都是一些功能页面文件。而用户定义的内容,比如config_inc.php,应该放置在根目录或者专门的配置目录中,现在的安排显得很混乱,主次不清。

    如果看过Mantis的源码,会发现很多php中都首先引入require_once( 'core.php' );core.php是我们第一个需要分析的文件,把此文件分析完,Mantis什么样子,我们也就知道了。

271/212>
Open Toolbar