我相信认真看过社区内帖子和回帖的测试行家心里知道,目前还存在很多同行,对业务测试也好,自动化测试也好,都可能存在一些认知上的误区,而且这种误区会像病毒一样传播,我觉得作为一名热爱测试的人,有责任站出来普及一些常识性误区。
现实情况有很多人会把 QC 也理解成 QA,我人微言轻就直接引用网上的定义:Quality Assurance vs. Quality Control。可能接触过 CMMI 的同行对两者的区别有更深的体会。我的理解是:QA 是整个软件生产过程的执法者,对整个过程的质量体系负责,偏管理但又必须懂技术;QC 是为检验产品而实施的具体的产品测试活动,包括业务测试、自动化测试等。
为了更容易理解,举个例子:一家生产精密仪器的制造商,制定了一套确保生产质量的流程规范,各个生产、装配环节必须严格遵守,确保这个流程规范按既定执行的角色就是 QA。还是以这个例子为例,流水线最后精密仪器制造出来了,要有人去检验其是否能按设计标准正常工作,这个角色就是 QC。
我看到一些回帖在解答提问者疑惑时竟然多次提到 “自动化测试的目的不是为了发现 Bug”,他们可能也是受到了一些加精文章的影响。其实,仔细想想,这个概念是不值得推敲的,自动化测试是执行测试的一种手段,那测试的目的是什么?也许我的理解还不够到位,但至少包括以下几点:
我在一篇文章中看到,把测试用例设计定为初级阶段,这绝对是技术至上的一种偏见和对测试用例的一种无知。敏捷可能对测试用例有弱化,但这和测试用例设计属于何种阶段是两码事,在传统企业,测试用例的设计好坏会直接关系到产品质量。即便是敏捷也会有简化的测试用例,其设计好坏也直接影响到测试盲区。所以说,测试用例设计的质量好坏,直接能反映出设计者的测试功底、技术功底、测试经验。
测试用例是测试工作的基石。好的测试用例,会让整个项目组都松一口气。
#1 楼 @Lihuazhang 对于腾讯 WeTest 发文的严谨性表示怀疑,这是要坑害多少人
我认为对于公司来说不一定要严格区分 QA 和 QC ,但用例 确实是测试的关键,不过现在用例的尴尬在于到底是写出指导思想 还是精细到 可以移交给第三方执行。
@quqing 为啥要喷 WeTest 呢?我倒是觉得 wetest 还有些深度。。。
个人觉得测试用例设计完全看人,但技术门槛确实不高,大部分互联网公司也没那么多精力养那么多人去死抠质量,简单问题线上修复。。。
#6 楼 @yangchengtest 你也说了是大部分互联网公司,能代表全部互联网公司吗,能代表整个行业吗?我表达方式比较直接,请包涵。
#3 楼 @Lihuazhang http://wetest.qq.com/lab/view/169.html,表面上看是给社区做软广,长远来看,可能会起到相反的效果。
我比较认同最后的观点,不管是何种研发流程,测试用例设计的好与坏,不仅仅体现了测试团队的可靠度,专业性,以及测试结果的可信度。不论是传统企业也好,互联网企业也罢,测试用例是最基本的保障,虽然互联网野蛮式的奔跑让测试在各个环节变得越来越被动,但是每个测试同行都应该保留和坚持自己的底线,用例设计要用心、严谨、可靠,该 review 的要 review,该弄清楚的必须弄清楚,这不仅仅是基本功,还是一份职业操守和对质量的坚守。
我的理解是随着企业对效率的要求. 负责质量的部门不会太多. 可以 QA QC 或者测试都会逐渐合并为一个部门. 加强沟通.
自动化测试不是用来发现 bug, 这个是行业一直以来的误区, 你提出来很好. 自动化测试的价值被低估. 大多是因为行业里面的人没有用好而已. 举个极端的例子. 有的产品是无法手工操作的, 必须写自动化用例. 所以 bug 也全是自动化发现的. 对于用户端的产品, 技术也会逐渐突破到能发挥更大的价值.
测试用例和自动化不冲突. 写自动化本身也是测试用例. 区分下就是用例设计是基础, 在此之上, 可以人工可以自动化.也可以大数据对比分析.
#13 楼 @Lihuazhang 有些东西我不想明说,但既然你都艾特我了,我觉得我还是来给你讲讲我跟这位仁兄的恩怨。要说我俩的恩怨可以追溯到我刚来 tester home 的时候了,那是我测试开发之路的第一篇帖子,那时候这位仁兄就因为我的帖子上来引战。然后前几天我们在一个技术贴的讨论上他又开始了嘲讽模式,那一次我没忍住,跟他吵了起来,现在他是专门来再一次开贴引战了。 别的不多说,我上几个截图。
还有很多的记录我不发了,这位仁兄最近专门挑我写过的帖子找事。 你可以看到留言根本没说我为什么错了。只是没有任何营养的来那么很装逼的一句:你丫的错了。每一次我都懒得理他,只是他不停在找事而已。自动上次我俩吵完以后,我便本着老死不相往来的态度来对待这个人,你发你的贴,我更我的文章。井水不犯河水。 所以在我俩有这么大仇怨的前提下,又是这么带有个人针对性帖子,我真的是懒得理。如果大家真把这篇帖子当成纯粹的技术讨论那我也没办法。你也看到我第一张截图上的聊天记录了,不只我一个人觉得他卖弄文字游戏。上一次我俩吵是因为他强调修改和劫持的问题,指责我不严谨。 呵呵,所以这篇文章一出来你可以看到,又是一个文字游戏大战。说起 QA 和 QC 的区别来了, 随便找了个国外大牛的文章来佐证他的观点。这个东西怎么说吧,我给你举个例子,在瑞典加班是犯法的,我如果引用瑞典人的说法是不是咱们中国所有公司都在犯法?我心里是呵呵的。 在国外的某些软件公司环境下 QA 和 QC 是这么定义的,所以不理中国国情把他生搬硬套到国内来,我心里更是呵呵的。大家可以扪心自问一下你们见过几家公司是这么区分 QA 和 QC 的,甚至会真正区分 QA 和 QC 的。如果你的老板让你做一件事,你说那是 QC 干的,我不干,你说你是不是疯了。随便在书里网上看一些理论知识,根本没怎么实践过就强行拿出来分享并让他人按你的理念实行的做法我是真醉了。
此仁兄的文字游戏功底之强悍我叹为观止。引用我文章中自动化的目的不是为了发现 bug 这半句话,决然不提后半句。 我后半句写的明明白白,为了节省人力,节省资源,节省成本。可这位仁兄半字不提,断章取义。然后又引入到自己的节奏去了,我心里是呵呵呵呵呵呵呵的。我觉得大家还是看看我原来文章比较好,不要被人误导了
这明显又是一个断章取义。我只在文章开头的第一句提过一嘴。之后我列举了当前行情下 QA 应该有的 7 大能力。跟这 7 大能力相比,设计用例明显就是个初级阶段。而且这位仁兄又开始玩文字游戏了,他开始偷换概念了,他把我说测试用例是初级阶段偷换概念为我不尊重测试用例,事实上我文章中没有提过哪怕一嘴这样的话,我只说了设计测试用例的能力是 QA 的基础而已。这文字游戏玩的。。我继续呵呵。 退一万步讲,抛开我的文章来说, 设计用例不是 QA 的基础能力? 初级 QA 可以不用设计好用例? 难道这个世界已经疯狂到把设计测试用例当成高级 QA 才有的本事了? 如果是,我道歉是我对 QA 的要求太高了。
所以这篇文章,我理解只是这位仁兄来报仇来了。 各位当笑话看看就好。对于只是因为转发了我文章就喷 WeTest 的状况,我表示我们大家都很懵逼。对于这位仁兄,我说一句话:你有你的逼格,我有我的原则,三十六重天天,一重一境界。前路走好不送。
#14 楼 @seveniruby 思寒看一下我的回复
#17 楼 @Lihuazhang 我本就是这个理念。只是这位仁兄专门在我的帖子下放狠话也就罢了。我也没理他,现在又开贴几乎指名道姓的引战,而且你还艾特我了。我就来澄清一些事情而已。 他在泄他的私愤,我不能就这么背黑锅。
可是现在好多公司都把 qa、qc 混一起用。
有些人明明做 qc 还可以的,非要拿 qa 的角度去评定。
我觉得怎么让这些人可以分清楚一下 qc/qa 的区别会更好一点。
QC 其实也是把控者,还有本书叫 QC 手法运用实务,执行者是 tester.国内这种定义都比较混淆,有些是 hr 给定义的。
我想提的误区是杀虫剂悖论(用交叉测试规避是其中一种),很多都是怎么简单怎么好培训怎么来,其实大量重复工作充斥(不光是手工测试)
早年,我在一个台资的软件企业里面,05 年的时候就通过了 CMMI3,有 CCB 小组,流程很是规范,有专门的 QA 的角色,负责项目中的各种流程的合规性,检查这种文档等。
那个时候 QC 还是工厂里的说法。
talk is cheap,show me the code。go on!~
三年测试,不知 QA 与 QC,只知测试。
#34 楼 @yangchengtest 可以简单翻译为,不会写代码不要逼逼么
我觉得测试做 qa,就是给项目经理擦屁股的。
@erick 你可以去 google 下这是谁说的,我觉得这才是做技术撕 x 的最高境界。
别因为争论影响了工作心情啊,很少能看到这种盛况→测试技术人在 TesterHome 争论的面红耳赤,可能对于二位不太好把,但是对于大部分人来说,学到了很多,总之我是学到挺多的!最简单的方法→列个条目 1、2、3 一次只回答一条,1 条没结束讨论,就不开始下一条。
#39 楼 @yangchengtest 厉害了,word 哥
@quqing @ycwdaaaa
感谢两位社区大 V 的交流. 让我们这吃瓜群众能通过挑战来看到更多的技术细节
江湖高手, 社区大 V 之间因为观点不同导致的不合, 在各个社区甚至是普通的社会中都非常的多见. 以我们雪球上的炒股高手为例, 有的大 V 之间已经水火不容, 扬言退出雪球平台去对手平台的人也有好几位了. 他们这些大 V 在雪球有较大的商业利益考虑. 并不是纯技术和纯社区的理念. 我想我们这些技术人还不至于和那些商人一样.
首先争论会是一直存在的, 就如美国的两党制一样. 我们要理性的去看待这个事情. 正是因为观点的碰撞才有了思维的创新. 才让一个社区充满了无尽的活力和创新源泉. 所以不要对别人的挑战保持敌意
大多数的矛盾, 并不是诞生于真正的技术流派之争, 而是诞生于对人格的攻击. 成功来自于细节, 恩怨也来自于细节.
评价一篇文章, 需要用公正客观负责的态度. 鼓励大家充分的使用赞扬和批评. 但是并不鼓励人格攻击和不负责任的嘲讽.
二位的不合也大多是起因于对方简单轻浮的总结或者嘲讽.
我建议两位大拿以后按照这样的标准要求自己.
金庸小说里面提到, 华山派有气宗和剑宗之争, 纠缠数百年, 最后打的你死我活导致门派高手陨落殆尽, 最后只有令狐冲得到两派真传从而笑傲江湖.
也许你们两个的争论最后没有绝对的胜负, 但是会影响无数看帖的新人. 进而促进他们的成长.
我代表社区下一代的无数"令狐冲"们感谢你们两个
#42 楼 @seveniruby 今天是我又一些激动,这里我道歉了。 毕竟被人无理取闹了这么久。一时没忍住。
@seveniruby 赞思寒的风范,更赞同这句『当彼此无法达成共识的时候, 请最后注明你赞同哪部分反对哪部分. 这是为了负责任的去表明自己的立场, 不至于以偏概全. 也是为了让时间和实践去证明.』
#45 楼 @seveniruby 本来是在冷静的,对于他在我的帖子里喷我的话我也没有反击,这些事就当这么过去了,但是他今天已经发帖子几乎指名道姓的喷我了,我觉得不能再继续沉默下去,才会激动的反击了一下。你说的对,我们都认为对方在无理取闹。我们都该冷静一下。我本不欲相争,毕竟影响工作影响心情,能想息事宁人是最好了,只要这位仁兄别再公然发帖子,黏上我的文章,说我在坑害别人就好。
这两位见面就打,我怀疑他们其实是同一个人,只是患有精神分裂
测试领域有些定义已经很明确了,就如白盒和黑盒,黑白岂能颠倒。只有敢于面对自己的不足,才有勇气更上一个台阶。
把测试用例设计定为初级阶段,这绝对是技术至上的一种偏见和对测试用例的一种无知 。点赞!
那为啥我面试的时候说测试用例设计得好,人家 piapia 滴把我赶走了。。
@woshizh 给多少钱干多少活,价格是你的可替代性决定的,无论技术,管理其实都是有 level 的。
现在测试其实是有溢价的,自己要有清醒的认识,知道很多理论没实践,鸟用没有,哎。
#59 楼 @yangchengtest 是的,有理论不实践,有技术不懂测试都是不全面的。唯理论、唯技术论都是极端的。
@quqing 楼主你最牛,楼主测试大法,一统江湖,威震武林。佛挡杀佛,人乱说删帖,是吧?