测试工程师应该具备的知识体系

它的地位尤为重要。而且随着项目经验的累计，个人能力的慢慢提升，慢慢的悟出原来这些基本的拳脚才是武术的精华，是前辈们走过了无数弯路后总结出来的捷径。看似平淡的一句定义或是一个技巧，若能由行会转为神会，也许在实际项目中你将会深深体会到事半功倍的含义。
基本理论范围：
（1）测试的定义，目标，目的，常识（前面是面试必修，常识乃武功秘籍）
（2）测试技术的划分（技术都是从不同角度划分的，不要简单的把他们理解成西餐的刀叉，大家都是平等的，吃什么就用什么，也许有些是棣属于另外一种测试。此为以后工作的核心，不仅仅要了解它们各自是做什么的,还要知道它们的核心是什么,经常被用在什么类型软件的测试当中）

2. 规范化的测试流程
流程相对简单一些，不外乎设计，执行之类的东东，如:设计测试计划---制定测试用例---执行测试用例---提交缺陷报告---修复软件缺陷---测试总结分析(修复软件缺陷有个箭头指向执行测试用例,这个阶段为修复后的回归测试)

不是简单的么,为何要设计这么多步骤？程序完成了按照客户的使用步骤来执行下不就行了么？（你若存有这种古老的观念就实在跟不上我们这个摩登的新社会了，殊不知现在什么都要做计划？做小偷的都说抢劫的没有技术含量）
该图应该站在软件工程的角度来看，如何有机的将其与软件生命周期牢牢结合起来才是关键所在，不然你始终会认为除开执行其他阶段都是多余的。（很多公司只做 系统测试，那么整个测试生命周期当中只需要制定一套测试计划以及用例；规范化的公司严格按照单元—集成—系统—验收来走，那么每一阶段都需要按照上图执 行）

3. 测试各阶段文档的内容
测试每一阶段需要做些什么？依据是什么？如何评测软件的质量以及测试工作的质量？
这一切取决于测试生命周期中产生的四套文档（通过上图你能推断出来么？）
按照顺序依次为：测试计划（测试经理编写）----测试用例（用例设计工程师编写）----bug报告单（用例执行工程师编写）----测试分析报告（测试经理编写）
每个文档的核心各不相同，对应自己职责的文档一定要弄清应该注意哪些要点，掌握哪些技术。记住，它们也许会成为你晋升或者离职的直接因素。
个人认为此模块是四个模块中最核心也是最为实用的部分，但必须建立在前两个知识模块的掌握之上，还要了解被测程序的行业背景。（不然写出的文档只是个装饰品，并无实际的指导价值；前两个文档必须严格审核，因为它们是测试执行的唯一依据，直接影响到测试的效率及质量）

4. 自动化测试工具的使用及原理
作为测试以后的发展方向,自动化测试成为了很多人盲目追捧的目标。
由于很多公司的招聘信息里面包含必须掌握XXX软件，或者听说懂了XXX软件后会拿到高薪，会在公司举足轻重……很多人基础还没打牢就花费大量的时间在一个呼声很高的测试软件上，但是我要劝你：学武，还是先得从马步扎起。
（1）工具，它是一把利器，但不是必需品，入门和精通并不是一个级别，功力未达到，就算拿到好剑也不知如何去舞。为何这个工具要有这么一个功能，它在什么地方用最恰倒好处？真正的高手才知道，工具使用前，设计的一系列的测试用例才是最重要的。
（2）工具，是根据被测软件所选择，需求及界面长期变更的软件就不适合使用录制回放的功能测试工具，所以，各公司按照自己的产品购买相应的测试软件。也许有一天你发现，你花费大量的时间学到的东西却无法应用在实际工作当中，你会感觉追悔莫及，世界上最痛苦的事莫过于此。
（3）工具，它的思想和测试基础是相通的。基础打牢了，可以使你更快的去学习和领悟每个工具的精髓。理解了测试的规范化流程，TD的使用便是小case。悟得剑道，宝剑在手方能随心所欲。
       所以，希望大家分清主次，四个模块中，它是最专业的，但不是最核心的。建议不要在学习软件测试的前期花费大量的时间在它们上面，除非因为工作需要。（自 动化测试确实重要，不仅能使测试工作方便，快捷，有些工具还能达到现实中很难达到的目的，节省大量人力物力。它必定会成为测试以后的核心发展方向，得到越 来越多公司的肯定。希望大家在能力达到并且有时间的情况下去多学习了解下一些与你行业相关的测试软件，肯定是百利而无一害的）