软件测试工程师的修炼之道(4)

同样，像数据库、操作系统、网络协议、建模等等都属于基础技能的范畴。可能测试人员在这些技能的掌握程度上没有专业人士强，没关系，因为这些技能最终是为测试专有技能所服务的，如此而已。当然，如果个人有兴趣深入研究那是最好。笔者记得刚接触Linux系统的时候拼命读源码，刚接触网络协议的时候厚厚几本《TCP/IP详解》放在床头，可惜的是都没坚持下来。

为什么说测试工程师转岗容易？现在该明白了吧。

测试模式

瀑布开发、快速开发、迭代开发、敏捷开发等等等等，这么多开发模式听着是不是犯晕？探讨哪种模式更好其实是扯淡，就象探讨是由“开明君主治理的封建制度国家”好，还是由“腐朽无能政府统治的民主制度国家”好一样，均属于哲学问题。同理，测试模式有V模型、X模型、H模型、前置模型，淘宝还提出了SPR模型以及最近正在探索的CCI模型，哪种更好？合适的就是最好的。

尽信书不如无书，这道理很多人都说懂，实际上呢？大多数人依然是照本宣科，死搬硬套。在大多数情况下，工程师应该尽量追求神似而不是形似，特别是奋战在一线的工程师，要明白“将在外君命有所不受”的道理。在当前以结果为导向这种西式管理的氛围下，更多的是要拿出让各方面满意的成绩单。当然，也有部分人以此为借口逃避流程逃避制度，高举敏捷大旗却行偷懒之实。要知道能量守恒，在某方面偷懒在其它方面会付出更多，这样做其实是把自身工作转嫁到他人身上，比方说把自身应该完成的保证产品质量工作转嫁给他人，这样的人要招天谴。“适可而止”这四个字说起来简单，真要做到非常难，需要大量的实践经验，这也是为什么测试工程师职业生命周期较长的原因。

笔者认为，在当下绝大多数项目团队里，V模型足够使用，或者在部分地方进行改良即可适应项目团队工作的需要。要知道，经典是永远不会过时的。那么在行政体系上呢？一个测试部门应该采用怎样的组织结构？目前流行的是一分为二，一部分做技术支撑，另一部分做产品测试，还有极端的是测试人员只做测试技术支撑，产品测试交由开发人员自行完成。至于在产品测试里再细分单元测试、集成测试或功能测试、性能测试等角色，窃以为不需要，因为在广义上，都是功能。测试要做的就是V&V，检验已实现的功能是否正确，检验是否正确实现了功能。

第三页

测试工具

这里所说的工具是广义上的，可以说各种各样只要能辅助测试人员开展测试工作的工具都包含在内。

为什么Mercury（笔者还是习惯称为mercury而不是hp）的产品能得到广大测试工程师的认可？因为它满足了测试工程师工作的需要。工具干嘛用的？辅助测试工作用的。笔者一直觉得Mercury的架构师真是不得了，产品设计的如此漂亮。什么是测试架构师？这就是。

测试工具有很多，这里不一一列举了。每年国际上会评选年度最佳测试工具，有兴趣的朋友可以多了解下，这算是测试工具的风向标。

有人曾经争论什么才能称之为测试工具，例如针对某一特定产品开发的一段测试代码是否算是测试工具。笔者以为，从广义上讲是，但在通常所说的范围下不是，因为它不具备通用性，它只能为特定产品服务。所以笔者常常告诫测试人员，第一不要总吹嘘自己开发了多少测试工具，充其量那只能算是一段测试代码；第二要理解测试工具的本质，开发了一堆工具结果根本不能有效提高测试质量、测试效率，无法帮助测试人员发现更多的缺陷，有意义吗？

当然，有一点肯定没错，多试用不同种类的测试工具并研究其原理，如果能对其进行改进，那么恭喜，离专家又进了一步。

第三章能力修炼

修炼要素

以下列举的十八要素仅供参考，这些要素并没有优先级或前后顺序，但有一点是必需确保的，那就是坚持，至少坚持一个月。如果能把全部要素坚持做一个月，笔者保证测试工程师自身能力会有大幅度提高。如果能坚持一年甚至更长时间直至养成习惯，那么恭喜，离牛人不远了。

1、 每日至少抽出30分钟关注测试行业新闻，包括各种业内动向，技术前沿等。推荐国内网站：51testing、ITPUB、Javaeye、infoq、博客园、Oracle中国用户组……。

2、 每日写一篇博文，200字左右，记录当日工作完成情况及次日需完成工作，流水帐也可。

原文转自：http://www.jianshu.com/p/0cde18be00ed