移动端测试

当前位置:首页 > 移动端测试

大话移动APP测试Android 与iOS应用测试指南(附录C)


附录C博客摘录.

附录C是笔者从自己的博客中摘录了--些相对有价值的文章,希望对大家有所.帮助。

编者注:附录C内容中包含大量专业词汇与网络词汇,为保证博文原汁原味,编辑过程中尽量予以保留,另外,博文中的一些主张与观点,仅代表作者个人思想,请读者自行吸收理解。

C.1我们需要专职的QA吗?

--写 于2012-04-16 11:34:15

原文链接: htp:/log.sina.com.cn/s/blog 7022adbf0100zgqo.html

左耳朵耗子的文章《我们不需要专职的QA吗?》,还是引起了各种风波。就我个人来讲,我非常赞同他的抱怨。注意是抱怨,并非是观点。就观点来讲,其实真的是婆说婆有理,公说公有理。就目前IT行业来讲,还真说不清楚。就他的抱怨来讲,就国内来讲。是的,的确,很多公司都存在他说的这样的情况,甚至更甚。我自己从一-家小公司做起,自己深有体会。在这里,我可以很负责地说,如果之前的一家公司不是因为我的存在,那么左耳朵耗子几乎说的所有现象都会存在。

不过这里我要说一-点的是, 测试们,不要说别人看不起测试。我曾经在Weibo.上面就写到过,中国的测试之所以被别人看不起,根本就是因为测试自己在看不起自己。

由于文章太长,我就不逐个进行评论自己的看法了。

我有一次私自review他们的testase的时候,发现很多的test case这样写到一- "Expected Result: Make sure every thing is fine", WTF,什么叫"Every thing isfine"? !而在testcase design的时候,没有说明test environment/ configuration是什么?没有说明test data 在哪里? Test Case、 Test Data. Test Configuration 都没有版本控制,还有很多Test Case 设计得非常冗余(多个Test Case 只测试了一个功能),不懂得分析Function Point 就做Test Design. 另外,我不知道他们为什么那么热衷于设计一堆各式各样的Negative Test Case, 而有很多Positive 的Test Case没有覆盖到。为什么呢,因为他们不知道开发和设计的细节,所以没有办法设计出Effective 的TestCase,只能从需求和表面上做黑盒。

我:前半段,我不想评论什么。我只能说写这种test case的tester太过肤浅,用我话来讲,根本就还不如那些实习了一个月的tester。当然,在我以前工作过的公司也发生过这类情况。不过这类情况一-般都是发生在第一 -次做测试的人的身 上。至于左耳朵公司怎么会出现这样的人,我个人比较匪夷所思。关于后半段,其实作为-一个测试, 几个case测试-一个point这个在现实生活中没有办法避免的。不知道开发和设计细节,我只.能认为是一种沟通上的不当,测试应当在设计的时候就参与到项目中,并且很好去.design case。就如左耳朵说的,并非只是单纯地看着文档,跑着黑盒。不过这里有一-点我必须要说的是,测试真正需要的是-一个 有好的想法,好的case的设计思路,以及很好地用户体验的这样-一个人。 因为在我看来,黑盒和白盒只不过是方式不同,其主要还在于case本身。

开发人员做测试

我:关于这点,我作为一个测试,不可否认。是的,在很多场景或者很多需求上面开发人员做测试的确相比测试人员更加有效。国内的测试普遍代码基础较差,有很多几乎就没有代码基础。对于这样的局面,比如我们写某个api的功能测试,又或者写一个查看对象生命周期的测试,这类我敢打赌来讲,就一个项目的dev来讲肯定比该项目的.QA写来得心应手。.

但是仅仅限于一些基本功能的保证。dev 无法保证-一个系统性的全面测试,就如我上一"段说了,我不care是dev或者QA去做测试,而是设计case 这样-一个 人是不是真的想法全面,是不是真的设计得好,是否真的会从一个用户的角度去设计。左耳朵所说的,QA要懂代码,这点我不得不说,我很赞同。并非要让QA去品尝自己做出来的产品失败或者有bug是什么滋味。而是只有懂得了,才能够真正地从逻辑.上面去分析测试路径,分析测试方向。这样才不会让别人感觉到只是片面的黑盒测试罢了。我始终不明白,为什么不做开发的QA会比Dev在测试上更专业?这 -点都说不通啊。我:就刚刚进入测试行业的人来讲,肯定会反驳。但是左耳朵说的也并不完全对,不会做开发的QA只不过不能成为优秀的QA,但是和做测试的Dev没有可比性其实。

减少沟通、扯皮、和推诿

我:其实就这点,所有公司任何一个测试team和dev team都有出现左耳朵说的现象。怎么说呢,其实dev本身不是只为了coding, QA本身不是只为了测试求测试。如大家真心都是为了把产品做好,各种扯皮、抱怨都会减少。其实基本上来说,国内很多测试和dev的素质(不是说做人的素质)就职业的素养来讲还是不够高。这个是-方面,另外一方面来讲,好的流程一种好的沟通方 式也可以大大减少左耳朵说的这类问题。原本我是想建议说可能以后可以有一-种 职位就是开发和测试并存的。但是后来想想,不对。我还是不赞同两者混淆起来。两者除了思维相差太大之外,其花精力以及方向都是不一样的。不可能让同一个人或者同一个team去完成。

吃自己的狗食

我:这点我无条件地完全同意,并且非常同意。

关于SDET.全称是Software Development Engineer on Test.像微软、Google.Amazon都有这样的职位。但我不知道这样的职位在微软和Google的比例是多少,在Amazon是非常少的。那么像这样的懂开发的专职测试可以有吗?我的答案是可以有!但是,我在想,如果一个人懂开发,为什么只让其专职做测试呢?这样的程序员分工合理吗?把程序员分成两等公民有意义吗?试问有多少懂开发的程序员愿意只做测试开发呢?所以,SDET在实际的操作中,更多的还是对开发不熟的测试人员。还是哪句话,不懂开发的人是做不好测试的。

我:我以前认识MS里面的SDET。比例在微软里面还是蛮多的。我同意不懂开发的人成为不了真正意义.上面优秀的测试。但是并非- -定 要让懂开发的测试去做开发。或者说两者兼做。

我不说什么“开发是创造、测试是破坏”这种理论大话了。我来说实际的,实际上面,测试是一种全面性的工作,虽然任何-一个测试不可能让产品没有bug。但是也需要无限接近于这个目标。一个人的精力是有限的,我们需要测试是因为一一个真正意义上面优秀的测试人员肯定比一一个真正意义上面优秀的开发人员想得更多(并非更全)。

我一-直认为测试的思维是第一, 其余所有的只不过是测试实施的手段不同罢了。但是就测试而言,黑盒测试用例的设计,白盒测试框架的搭建、架构,api 的封装。包括各种压力测试、回归测试、性能测试、用户体验测试,更甚的有单元测试、coverage测试等等。这一系列要在-一个项目中做好并非是容易的事情。往往测试会用各种不同的方法去达到一个目的,这个就如同测试会有N条测试用例去覆盖-一个功能点- -样。这个从dev或者旁人的角度来看的确可能是一-件荒唐的事情,但是测试往往是一一种摸索,是一种创新,是一种比较的过程。这样在日积月累之后,case会被精简,方法会被改

进,效率会被改进,bug也会相应的减少,上线之后的问题也会逐步减少。当然-一个真正好的测试应该告诉dev,某些类应该怎么写,某些方法应该怎么写,某些逻辑应该怎.么做保护。dev 和QA相辅相成才能够各取所需,一起提高, 不是么?

以上,所有的观点都是建立在一个有真正测试sense的QA, -个真正知道要做什么的QA的基础上面。其实目前很多的局面的造成就是因为测试自己不知道要做什么,对于产品、对于测试都没有激情所造成的。这类测试根本就不配做测试。说实话,长此以往,第二个抱怨的、第三个抱怨的都会跳出来。到时候就如同狼来的故事一样,谁也不会相信测试。

在此,我向陈皓表示敬意。



相关内容

文章评论

表情

共 0 条评论,查看全部
  • 这篇文章还没有收到评论,赶紧来抢沙发吧~