Re: 测试好郁闷啊！

  
作为一个在测试岗位上工作了三年的北邮人乱喷几句，姑妄听之。
  
1. 首先明确为什么选这个岗位。我当时是不愿意整天写代码，正好财务软件相关知识又是我愿意学习的，之前全校选修课选过会计也有点底子，所以就来上班了，这一干就是三年。
  
2. 只照用例测试的话确实会导致烦。可是用例都是测试前人在自己的测试经历上总结出来的经验，虽然有时候指导性可能不强，但是能够快速上手一个软件的测试。有经验之后再自己写测试点测试用例又是一次对软件认识的提升。我们这的测试人员一开始都是这么过来的。
  
3. 刚开始如果就让测试人员接触代码的估计这公司不是小的可以一人多职，就是魄力够大。还没有对一个软件完整了解的话，估计看了代码也是白看。如果看了代码就明白是怎么回事的，不是选错了职业就是选错了公司。
  
4. 黑盒测试表面上看起来没什么技术含量，但可从中更全面深刻的了解一个软件的完整形象。我现在能说出我负责测试过软件的整体的数据处理流程，但对于参与其中的任何一个开发都只知道他所负责或相关模块的功能实现细节。具体业务上为什么做成这样或那样，对一个开发人员未必全都明白，但有经验的测试人员必定烂熟于心。即使新接触不知道的东西，通过之前的测试经验也能猜出用户为什么这么需要这种设置。这种情况下，当实施、研发、测试一起讨论问题的时候，还怕测试说出来的话没分量吗？不过测试向来是这三者中最没话语权，两头受气的人，既然选了这个职业也就暂时忍忍吧。
  
5. 想搞代码还怕没机会？拿自己当例子，虽然当时学的不是计算机，好歹北邮混出来也会点C语言，懂点SQL，一点Linux。开始让我看代码我都不想看。Delphi没接触过是一个原因，整个软件实现都完全不怎么了解，看了头都大？我在测的一直是一个平台上构建的各种MIS（管理信息系统），数据库那是必须掌握的。当业务熟悉到完全了解相关模块数据存储的方式，有哪些表，之间的勾稽关系是什么，软件各模块之间的数据处理流程后，即使是不看代码，我也能想出来整个过程的处理方式，虽然具体的算法实现不是我能写的出来的，但如果哪里数据出错了，我能很快的写个SQL或通过其他方式查出是数据记录的问题还是软件实现的问题。另外，看不到代码就与代码完全隔绝吗？我们公司的业务全都是基于Windows平台东西，跟*NIX完全无涉。由于自己有点Linux的底子，对于日常的一些dirty work比较讨厌，就想办法写个脚本什么的，之前可是只把Linux当玩具，shell脚本也是从来都没写过，经过逐步的锻炼，现在只要是“脏活”，“累活”统计个什么数据，做个什么批量生成，批量替换什么的就是手到擒来。别人累死累活搞上1小时还可能弄错，我顶多半个小时写个脚本，不到一分钟结果就出来了。希望这条对LZ有点启发。
  
6. 测试人员基本上都没有会编程的这是说了一句实话。在中国这种对测试普遍认知度不高的大环境下这确认是事实，招的会编程的人都去开发了，谁还来测试。工作轻松些是一回事，工资拿的少点也认了，一大老爷们跟一堆大都刚毕业没多久，学的专业各式各样的MM、哥们儿在一起干活，作为科班儿的不气死也急死。指望他们写代码，开玩笑吧。这就是中国测试行业的大环境，考察不多，大概也就这么一回事。传说我们公司的测试这块在业界还算不错，具体没跳过槽，没问过别家，也不是非常精确，当个笑话看看，如有雷同，不胜荣幸。可如果做性能测试，自动化测试，白盒测试，哪个不需要写代码的能力？再说这些也不是一蹴而就的。我们公司的自动化测试搭上一个兄弟整整一人年的功夫才略有点眉目，之后一步一步的也确实像那么回事了。性能测试用工具也是摸爬滚打N多人，M多个项目前仆后继投入进去才算是有些成效了。白盒测试到现在我公司都没人能拿下，老大一次找我谈心也是期望我能在这方面搞搞，虽然知道有点给我挖坑的意思。但机遇与风险都是并存的，就看抓不抓得住了。
  
东拉西扯的这么多希望对LZ有点用。感谢我也好，说我扯淡也罢，反正对我都无所谓，一人一个看法。
  
如果要指路的话，先买本外国人写的软件测试整体介绍的书，太专于某项反而见树不见林，厚薄随意，英文够好读原版，不好的话翻译版也能看看。别买中国人写的，不留神买本光灌水的就更晕了。全面了解一下软件测试到底怎么一回事。能继续干下去的话，再弄个一年半载看情况，不想继续的话赶紧转行，别在这上面耽误自己的青春了，时间很宝贵的。
--
※ 修改:·youngchance 于 Aug 17 20:20:41 2010 修改本文·[FROM: 124.207.110.*]