测试是做产品的一个很重要的部分,国内重视测试除了几家硬件和数据库公司就都是外包给外企的测试人员了。
笔者也在外企外包测试了很久,有些话,不吐不快。
笔者认为:
1 测试是一项枯燥的事情,如果不是对技术有很大的信心和爱好,干不长久。
2 测试的种类很多,可以说从高到底。但是国内的普遍都不是技术流所以干不长久。
3 手工测试貌似谁都会,但是有经验的会去找各种边界值和反向值,这个就是编程序的经验的老道与否决定的。
4 开发也普遍看不起测试,因为啥。因为测试的不是和开发平起平坐的。虽然口头上都是说一样。我做了这么久,最大的原因我觉得就是测试的普遍不会写代码。或者对代码抵触。自动化的除外。
再就是领域知识,数据库为中心的产品核心自然是那么些个表盒存储过程。你不比开发的熟悉你咋知道好不好呢?硬件或者固件为中心的比如嵌入式的一些测试,要求的一些平台相关的知识。如果不懂得基本的,那也是玩不转的。
5 但是角色都相反的,开发的是善于编制制造东西,而测试是善于拆东西。把东西拆掉看看内部构造。
所以开发的熟悉的类啊,成员变量啊,静态函数啊,模板类啊。测试的所知有限。
但是做黑盒来讲,你系统慢或者点击就死机这些常见的错误还是一目了然的。
6 对一个成熟的产品而言,测试的作用比开发作用大。为啥,测试就是你养了这么些年的高级用户啊。他们代表着先进产品的需求代表着老用户依然觉得产品好用,代表着新加入的功能还是能被老用户接受。
而新进入的开发人员却不是这样的,一些个之前的开发翻过的错误没写注释的代码,你觉得没用,大笔已删的就是一个回归错误。
我是一个开发人员认可的测试人员吗?
我觉得我是:理由如下。
1 我的开发技术不赖。我测试的是C++ COM的程序,所以我对ATL MFC还是熟悉的。我需要测试的产品的API是基于COM的是早期的微软技术。(童鞋们不要不屑,Citrix AutoCAD等等都是C++的。不想做语言之争。)
我设计了一套框架,自定义了String,加入了XML4C的支持用于解析我的输入的Case,加入了ThreadMemberFunction实现多线程,定义了日志的级别...
然而在实际测试中,为了让开发的能迅速重现我遇到的问题,我不可能把几百M的文件发给开发人员要他用我的这么大一套东西去重现。既然是COM的,我就写COM的C++的程序有时候是VB程序。。(童鞋们不要不屑,Citrix 脚本就是用来做胶水来填补应用程序之间的Gap的,不是是Pathon就一定现金,VB就一定落后...)
然后我把相先出现问题的版本号告诉开发,开发这里就Checking一个缺陷,只能是哪儿出错了。当天3个LocalFix砸过来,第二天就修好了。
久而久之,开发的不服都不行。主要是你每次都有理有据,把他定位的工作也做了。你用你的Code去和人Argue,所谓子之矛卖攻子之盾。不是我的Coding比他好或差的问题。是问题的2个方面他看不到而已。
也不是IBMer就一定比我的Coding强,那BuildTeam的就玩Ant和不到10个Java代码。你去玩2年不比他差。项目决定的,或者说机遇决定的吧...
2 我也遇到过烦躁期,我在网上把所有人的相关的不相关的帖子全部回复一遍。把MSN上面的好友聊的不想和我讲话。后来我自己找东西学习得了。我学习的东西很广,Pathon C++ Oracle DB2 我都喜欢玩一玩。越看越觉得里面的东西很多。至少学习的时候我的心态是平静的。工作的时候就工作,学习的时候就学习。
3 测试是一门很深的学问,我接触到的人大部分都是测试的。有做了5年Java编程累了转型的,有OCM大师,有系统分析员(才Band6),其实都是一样的目的。你接触不到高人所以说测试没含量。我也理解。
做了5年Java编程累了转型的写自动化的框架那是信手拈来,并且他熟悉哪儿Java更容易出错。
OCM写数据库调优的GUIDE HA DR的Guide,对产品设计的不好的位置提出一个职业DBA的建议。
系统分析员对SAN和网络的熟悉程度让我汗颜。
我做的自动化在 做了5年Java编程累了转型看来是小儿科,但是在OCM看来我除了玩Java C++ 还玩VB,在系统分析员看来就更不可思议,你一个OCP把数据库这块测试好就得了还去写啥自动化啊。
我目前的状态是“一个不想写代码的DBA不是一个好的系统测试人员”
我测试数据库为核心的产品,我对DB Instance和表结构不熟悉,对简单调优和备份恢复不熟悉咋干活啊。
不利用IBM STAFF把这些活自动化起来我如何花时间去学些去和坛子里面的各位聊天求教问题呢?
我不喜欢人上来就说啥测试没技术含量,我也不喜欢你们说到武汉看到武汉人素质差一类的话。你们以偏概全,犯了逻辑错误。
今天我就来给你们补第一节课:
逻辑:
showing how various canidates respond:
Interviewer: Imagine you have eight coins, seven of which weigh the same and one that doesn’t (it’s heavier). You need to use a pair of scales to find out what’s the odd one out.
咋看呢?
A 说不知道的是态度问题,遇到事情就退缩,不是做技术的人该做的。
B 一个个的去称,至少是一个解决办法。但是太慢了。
C 4个和4个去称,对折几次到最后的那个,最快4次,最慢8次。(我就是选的这个)
D 取3个来称,最好的2次,最差的3次。
分析:
Interviewer: Yep, that’s the optimal solution, do you know for N coins how long it’ll take ?
Candidate Fred: About Log N
Interviewer: What base ?
Candidate Fred: Base 3
你看看,逻辑的问题确实是比程序更重要的。
不信,我举一个我工作的例子吧。
第一个 是API方面的
virtual HRESULT __stdcall UpdateNotelog (
/*[in]*/ BSTR NotelogText,
/*[in]*/ VARIANT UpdateNotelogCmd = vtMissing,
/*[in]*/ VARIANT InsertTimestamp = vtMissing ) = 0;
/*[in]*/ VARIANT addNervion = vtMissing ) = 0;
这样一个API的入口:
NotelogText: BSTR 标准的String
UpdateNotelogCmd : 1 Update 0 Add vtMissing (Default Add)
InsertTimestamp : 1 insert 0 not insert vtMissing (not add)
addNervion : 1 add 0 not add vtMissing (not add)
这样一套高度Overload的方法,你要全覆盖得多少种呢?
刚开始只考虑0和1 有2X2X2=8
后来vtMissing考虑进去就是27种了....
功能测试就是考验逻辑,设计者的逻辑一定要好。(好到多少情况下看到开发者没看到的。没想到的。)
第二个是 GUI方面的 :
添加喜欢的打印机。在喜欢的打印机为空的时候点击Add,程序会Crash。
C++的老毛病了。
无非就是一个思考的盲点,开发的可以盲,测试的最好别盲。
你看看逻辑对测试人员的要求至少不要低于开发的人员。
本系列将继续,如果大家有兴趣的话,欢迎来我的博客时不时看看,呵呵。