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把这些活自动化起来我如何花时间去学些去和坛子里面的各位聊天求教问题呢？
我不喜欢人上来就说啥测试没技术含量，我也不喜欢你们说到武汉看到武汉人素质差一类的话。你们以偏概全，犯了逻辑错误。
今天我就来给你们补第一节课：
逻辑：
http://imranontech.com/2007/01/10/why-logic-puzzles-make-good-interview-questions/
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++的老毛病了。 无非就是一个思考的盲点，开发的可以盲，测试的最好别盲。 你看看逻辑对测试人员的要求至少不要低于开发的人员。 本系列将继续，如果大家有兴趣的话，欢迎来我的博客时不时看看，呵呵。 |
相关链接：
