今天专门谈谈软件测试以及我对软件测试的一些理解，也希望这些理解对做软件测试的人有所帮助。

　　首先对于软件测试和软件开发的关系问题，首先要说明的是测试需要懂一些软件开发方面的知识，而这些软件开发知识里面最重要的又是数据库和SQL，结构化编程和脚本语言，这些是测试人员上升到一个新高度的重要内容。可以是软件开发转入测试，这个时候强的是软件开发方面的知识，但是若的是对业务和需求本身的理解，同时也容易卷入程序员的固有思维而不能从客户的角度来看待问题；也可以是先从测试和业务熟悉做起，后面逐渐需求一些开发方面的知识，包括数据库SQL 和脚本语言，但是往往没有真正做过开发又很难理解结构化编程的一些基本规则。这里面都存在一个转换问题，都需要自己在这个转换的环节多去思考，转变思维，多多总结。

　　其次测试最核心的内容是什么？做软件测试需要时刻的提醒自己来思考这个最重要的问题。软件工程书里面我们学过来，测试最重要的就是找出至今为止别人没有发现的Bug，找出尽可能多的有价值的问题，以最大限度的降低的缺陷泄露和现场故障。这个回答本身没有问题，不过我们还需要做一些更加深测试的思考，特别是做了测试一两年后更需要不断思考，测试的核心和关键点究竟在哪里？在这里我想谈两个比较重要的核心内容，一个就是拿到一个大的系统或复杂的业务功能后，这个时候第一个核心就是根据需求规格说明书进行测试分析，而不是一下切入到了测试用例和测试设计，测试分析的目的是让测试人员真正的理解需求和业务场景本身，测试有个重要的概念是测试场景，而测试场景则来源于需求场景。做测试分析的目的就是根据需求和业务流程梳理清楚我对整个测试流程的总体规划，搞清楚对于复杂的功能如何按一定的方法系统性的开展测试，如何更加有效的设计测试用例，如果加强测试用例和测试数据的复用，测试用例对需求和业务场景的覆盖等诸多问题。如果你还不能去考试测试分析，说明还在测试的一种初级阶段，完全照搬着需求规格说明书的测试用例是无法带来很好的测试效果和效率的。第二个重要内容要谈的是测试用例的设计问题，一条测试用例涉及到编号，名称，对应的需求点和业务规则，前置条件，测试步骤和预期输出和优先级等诸多内容，那带来的一个重要问题就是测试用例本身的核心是什么？其实这里我想指出的则是通过前期的测试需求分析后所规划的测试数据的准备问题，而测试数据准备的方法则来源于我们常说的黑盒测试场景方法，如等价类划分，边界值设定，因果分析等，这些都是为测试数据准备服务的，没有准备的测试数据预期的测试输出往往是一句空话，有了预先准备的测试数据测试的过程才是有计划和有目的的，真正准备了测试数据的人才谈得上在真正系统的使用各种黑盒测试方法。系统的规划和准备测试数据是系统化的进行测试用例的灵魂，你考虑了这点才会发现到，需求里面啰嗦了半天的内容往往仅仅需要1-2条测试用例概括即可，而需求里面只有一句话的业务规则往往则需要准备上十条甚至更多的测试用例来进行测试。如果在测试用例的设计上考虑到了这些问题，基本表示对业务深入理解和对测试方法已经灵活应用了。

　　最后谈下成为一个优秀的测试工程师，首先你要转变思维，你代表的是用户，你是整个软件产品或系统版本发布的最后一关，对你的评价只有一个就是从你手出去的产品到了用户现场的缺陷情况，这是唯一的一个有价值的目标。如果连对自己的工作绩效如何衡量都还不清楚，更谈不上如何做好测试，因此对于测试我们会谈到一个重要的外延就是质量管理方面知识的学习，质量管理基础理论，质量管理七工具，6Sigma等都可能是测试中需要时常用到的方法和工具，需要去拓展这个外延知识，加深对测试工作本身意义的理解。同时优秀的测试工作师不仅仅是测试方法和各种测试工具的熟悉，更重要的一点需要意识到的是对某个业务领域业务的深入理解，没有理解无法做好测试，理解一些可以做单个功能模块的测试，全面理解才可能做集成测试和系统测试，你对业务理解的越深，就越容易测试出各种业务规则方面和数据方面的问题，到了这种层次后SQL和后台数据的查询就必不可少的，基于业务规则的数据校验测试是测试人员上一个新台阶的重要内容。