测试,我误解了你

今天的话题是:对测试的一些误解。我们一些新手,包括很多经验丰富的人,都可能对测试有一些偏见或者误解。大体总结如下:

1) 测试人员不需要了解软件开发的知识:

这个很要命的,我们谈到软件测试人员未来的发展方向大致有:自动化测试,性能测试,测试管理,项目经理。这其中自动化测试和性能测试包括项目管理,都会要求对软件开发有深入的理解,如何能设计一个好的自动化框架,好的性能测试用例,如何管理一个开发团队,这都需要我们在软件开发方面有所掌握。不单要掌握,而且要精通。此其一。
其二:如果不了解开发知识,测试人员很容易被开发人员牵着鼻子走,因为开发人员随便一忽悠,你如果不了解个中奥妙,你一个字也说不上来。(以前我们讨论Cookie和Session,由于GoAhead不支持Session,只能用Cookie来控制,差点别开发人员忽悠了)

2) 测试很简单:

如果你这么想,那么请别去做测试,如果你做了,你也做不长久。以前面试一位小伙子,做了3年测试,问他测试都怎么做的?答不上来,原来他测的都是很简单的小软件,根本就没有系统地去学习过测试,无语。

3) 测试就是为了找到BUG:

很多人最初都是这样的看法,千万要小心。如果你只是为了找到BUG,那么BUG会成天缠着你。

4) 测试人员和开发人员从来都是死对头:

我以前发起过一个倡议:我们讨论的时候不要用他们(开发人员)和我们(测试人员),而是统一用咱们(开发人员和测试人员本来就是一起的)。如果测试人员能与开发人员成为朋友,你会发现,生活是多么美好。

5) 自动化测试太难:

有的人一进公司就想做自动化,觉得它有难度,有挑战。我说你如果做不好手工测试,你同样做不好自动化,手工测试才是基础。而另外还有一部分人一说到自动化便望而生畏,认为这个东西太难了,不想碰(特别是很多女生,就有这个心理)。其实大可不必这样想,自动化测试工具它只是一个工具而已,它跟WORD这样的工具没有任何区别。

6) 手工测试太没挑战:

什么都不说了,能把它做好的人没几个。

7) 大量的重复性的工作很乏味:

于是大家学得测试这份工作不好玩儿,特别一些男生,特别一些开发人员,从来都瞧不起做测试的,觉得这玩意儿太没劲。我想说的是,要掌握方法,要学会创新,任何东西都有它的特点,你如果总觉得成天在做重复性的工作,那么请静下心来想想,怎么能让它不重复(事情本身是死的,人是活的)。

8) 白盒测试是开发人员干的事:

一个合格的测试人员必须掌握白盒测试,理解其中的原理。不管什么样的测试,都必须要有测试人员的思维才能做好。

9) 女生适合做测试:

不管适合不适合吧,反正我以前所在的公司有5个Team Leader,3个Test Manager,其中只有两个是男生(加上我),这是现实。但是做自动化测试的,全是4个男生,这也是现实。不太想加以评论。只想说,女生未必适合做测试,男生同样能把测试做好,且做得更加专业。

10) 测试就是给开发擦屁股的:

如果这样想,那么请每天多准备些手纸。测试人员永远要站在客户的角度来想问题,很显然,客户是从来不会给谁擦屁股的,相反,是客户在驱动着软件的进展与成型。测试人员就应该扮演这样的角色,在大部分时候,要驱动开发人员完成软件的功能,驱动他们做改变。

11) 我做开发可能不行,做测试吧:

这个观点特别适应于应届毕业生,在以前面试的过程中,有一部分人就是觉得我代码写不好,所以入行做测试,还有一部分人稍微明白一点的,是觉得自己在开发方面没什么优势,主动给自己定位做测试工作。其实测试要掌握的技能远比开发多得多,至少面要广得多,要做一个好的测试人员,远比做一个开发人员难得多。

12) 功能性测试掩盖了可用性测试的必要

测试人员甚至我们的设计人员,开发人员都不太注重可用性(usability)方面的设计和测试。
我们往往只在意功能性或者性能方面的测试,而忽略了用户体验,即使谈不上用户体验,哪怕是方便使用也行,这些方面往往从软件需求,设计一开始就没怎么考虑。到后来,用户使用的时候便是边用边骂娘。(我常举的例子是:咱们买手机的时候,手机功能一切正常,但偏偏盖子上有条划痕,我相信大家都会要求重新换一台,就这意思)

有则改之,无则加勉,希望大家在进入软件测试这一行以前,能对测试有一个更深入的认识。时间仓促,随便写写,大家多提观点。

文章作者:蜗牛学院邓强

转载请注明出处

原文链接http://www.woniuxy.com/blog/?p=27

时间: 2024-10-05 04:28:48

测试,我误解了你的相关文章

好好的读两本书, 别再对测试产生误解了

产品的质量始终无法获得保证,其中有一个主要的因素,便是对 "自动化测试" 与 "软件测试" 存在着太多,太多,太多的误解与不切实际的期待. 这二本书将能告诉咱们大家,"自动化测试" 与 "软件测试" 的真相:真实故事为何? "任何事都是需经过深度的学习.深度的思考与细心的验证,才能得出真正符合事实的结论."

2.2 测试级别

V模型与测试级别[1] 2015-06-24 目录 2.1.1 V模型2.2.1 单元测试2.2.2 集成测试2.2.3 系统测试2.2.4 验收测试 2.1.1 V模型 返回 单元测试:验证软件单元是否按照单元规格说明(详细设计说明)正确执行,即保证每个最小的单元能够正常运行.单元测试一般由开发人员来执行,首先设定最小的测试单元,然后通过设计相应的测试用例来验证各个单元功能的正确性: 集成测试:检查多个单元是否按照系统概要设计描述的方式协同工作.集成测试的主要关注点是系统能够成功编译,实现了主

第二次作业+105032014028

一:链接 测试帖链接:http://www.cnblogs.com/wangjiao0-0/p/6590944.html 第一次开发源代码链接:http://www.cnblogs.com/sky-tian/p/6531367.html 二:测试人员提出的问题.发现的缺陷 建议: (1)导入时代码格式问题. (2)new RuntimeException(e);这句话在此没有用处. (3)变量tt命名不够直观. 三:修正后的代码清单 1 package test; 2 import java.u

敏捷脑图用例实践之路

原文在infoq已经发布,可以直接阅读:http://www.infoq.com/cn/articles/road-of-agile-mind-map-practice/ 传统的黑盒测试用例比较繁杂,在实施敏捷的项目中会显得水土不服,让测试人员过度关注用例步骤的编写.修改,甚至同一条用例经过多人执行得到相同结果,让人想到一个呼之欲出的广告词:一次编写,多人运行相同结果,没有思考的过程.在经历过这些痛楚之后,对用例进行改革,以便快速响应开发的交付节奏,同时形成用例评审规范,让开发.测试知己知彼,也

最大子数组求和并进行条件组合覆盖测试

简介 算法导论第四章介绍过使用分治法求最大子数组问题,其基本思想就是把一个数组分成三部分,a[0:n/2],a[n/2+1:n],a[j:k] (其中0<=j<=n/2,n/2+1<=k<=n),通过递归分别求出他们的最大子数组和,然后再从中挑出最大的一个值,即为该数组的最大子数组值,该算法的时间复杂度为O(nlogn) 白盒测试有语句覆盖.判定覆盖.条件覆盖.判定/条件覆盖.条件组合覆盖这五个覆盖标准 环境:Ubuntu 16.04 语言:C++ 测试工具:GTest(Gtest

关于测试的一些&quot;误解&quot;

1)Testing & QA(Quality Assurance) 在我刚开始接触测试的时候,就一直没有分清楚Testing和QA的区别,一直认为QA的工作包括了测试的内容.直到有次去download一个测试工具的试用版,忽然发现填写个人信息的职务选择中就有Testing Manager,也有QA Manager,心里已经感觉这两者不能混为一谈. 它们到底有什么不同呢? 首先让我们来了解什么是QA,软件质量保证负责在软件开发全过程中,监控,保证和改善实施的过程,确保所有经过协商同意的约定和流程被

对可用性测试的8种误解,你中枪了吗

用户测试是理解用户行为和动机的过程. 好的设计能让用户轻松找到想看的, 轻松做到想做的. 然而很多时候, 由于时间和预算的限制, 用户测试被边缘化. 甚至直接被略过了. 究其根本, 还是在于用户测试的价值被误解和低估了. 蜜汁误解1 "穷,预算不够,无法做用户测试"   事实上,明明有很多种用户测试的办法! 预算少不是你放弃了解用户的理由.从正经的实验室测试到你公司旁边的咖啡馆,有很多方法可以进行用户测试. 而且即使从经济层面考虑,用户测试本身就是在省钱.如果产品团队直到最后测试阶段或

一些典型的测试方面的误解

在我们每天的工作中,我们可能时时都在面对着对测试的批评和指责中.开发人员或管理人员试着用这种或那种的理由要求我们在测试过程中更负责,更仔细些.但是你认为他们对你的要求或指责都是正确抑或合理的吗?作为一个测试人员,你是否在工作中固执己见?作为一个管理者,你是否一味地追求高深的技术或测试自动化呢?本文参照了国外一些资深的测试专家的观点,并结合本人多年的经验而成.希望我们能够更理性的把测试工作做的更好.  测试的角色 认为测试小组应负责保证产品的质量 -这是经常被开发人员和管理人员滥用的一句话.经常出

投资银行的IT部门——不同之处与常见误解

投资银行的IT部门——不同之处与常见误解 说了这么多投资银行,投行里面的IT部门究竟是做什么的呢?在过去,投资银行仅靠纸.笔.计算器就能做生意了.但是在今天,所有的部门都要依靠IT技术.交易部门甚至是严重依赖IT技术. 我们可以从两个方面来看IT部门. 从工作的内容上,可以分为系统支持(System Analyst)和开发员(Application Developer).前者和其他公司的IT基本相同,需要维护公司内部的局域网.设备等等.与开发员相比,系统支持的数量要少很多.开发员的职责是开发公司