从决定开始写博客这一刻起，意味着我以后的日子将更加笃定地走在IT这条不归路上。现在的我，只是一个IT菜鸟，对IT行业的各个领域都充满了无限的好奇，在自己不断学习的过程中，希望通过博客与大家分享自己的一点心得，发表一些自己的拙见。
我是从软件测试开始进入IT这一行的，那就从软件测试开始吧。。。
如果你想了解一个从未了解的新事物，有一个很好的方法，我们把它称之为5W1H法则，也就是What, When, Who, Why, Where, How。
What----什么是软件测试？
如果你问我什么是软件测试，我会先告诉你什么是软件，就像你想要用手机打电话给别人，你先要知道手机是什么。软件测试的主体对象是软件，而软件并不仅仅是我们日常生活中所说的某某应用，某某程序。相信了解研发的朋友肯定知道，IT类的研发主要包括硬件研发和软件研发，那么这里所说的软件就八九不离十了，因为软件是指计算机系统中与硬件相互依存的另一部分，它是程序、数据、文档的完整集合。
主要两点：1、与硬件相互依存，没有脱离硬件而存在的软件，就比如一个操作系统也是一个软件，但是它是需要在我们的计算机硬件上的才能运行发挥它的功能的。
2、软件=程序+数据+文档。
这么看来，软件测试就不是简单只是针对某个应用或某个程序来说了，而是对整个软件系统而言的，其中数据可以理解为数据库，文档可以理解为需求文档，设计文档，这些都是做软件测试需要考虑的范围，甚至于软件系统和硬件之间能否很好的结合，正常地发挥其该有的功能，也是软件测试要考虑的，我想这也是对一个软件测试工程师的要求吧。
Why---为什么要做软件测试？
我相信有很多人，甚至也有很多不是很了解软件测试的开发人员会认为软件测试就是在找BUG。你可以这么说，但事实并非如此，相信通过前面的介绍，你大概已经感觉到软件测试的目的不单纯在于程序本身的BUG了，那么还有数据、文档呢。的确，找BUG并不是软件测试的唯一目的，如果把一个软件系统当做一个产品来看的话，那么软件测试的目的就是确保最终交给用户的产品符合用户的需求，在产品交给用户之前尽早尽可能的多发现问题，并协助开发改正问题，共同保证产品的质量。
这里所说的问题，可以是程序的BUG，也可以是需求分析、设计过程中存在的问题，往往这些问题在软件开发过程中如果没有及早发现解决，后期来修复的成本是巨大的且不划算的。因为你不能保证用户提供的原始需求一定是合理并且正确的，或者是将用户原始需求转化为软件需求规格说明书的过程中一定没有歧义，软件概要设计过程一定没有逻辑问题。所以对于这些文档性质的内容也是需要进行测试的，或者说是评审。而这些也是一个项目中软件测试工程师的首要工作，通过这些工作来保障项目正常开始，是在软件开发项目的初期就着手的去做的。举个例子，如果软件的某个功能点在需求规格说明书中的解释存在问题而未经发现，后期经过测试发现达不到客户要求重新修改，那么重新对这个功能模块进行修改，无疑又要耗费额外的人力物力，但是这个问题要是最初阶段发现并解决了，岂不是很好地提高了项目的效率！
再者说了，软件是人为的产物，当开发一个软件的前提条件全部准备充分了，良好的工作环境、高性能的硬件条件以及优秀的程序员。然而最后最容易导致程序运行过程中出BUG的因素不是内存不够用了、网络不好等等，而是程序本身的问题。毕竟程序员是人不是机器，人的不同心理或生理状态，工作的效率和质量也会不同，心情好的时候和心情不好的时候，舒服和生病的时候写出来的代码当然是后者更容易出现问题，这是不可避免，也使得软件测试有存在的必要。当然软件测试工程师也是人，所以说再优秀的软件测试工程师也不能保证测试后的程序会没有一个BUG，但是却可以说经过系统全面测试并使已发现的缺陷得以解决的软件是合格的、是满足用户需求的，是拿得出手的产品！
Who,When,Where---什么人在什么时候针对软件的哪方面做测试？
总的来说，软件测试的主体还是软件测试工程师，因为软件测试工程师会通过专业的测试思路以及一些专业的测试方法对软件开展测试工作。如果将测试的范围扩大化，那么执行测试的人员可以是项目经理、开发人员、客户以及软件产品发布后的用户群体。比如说某些白盒的测试会让更熟悉代码结构的开发人员进行，测试后期的验收测试中β测试则是用户在实际环境中进行的测试，就完全脱离了开发人员和测试人员进行测试。
要说软件测试的时间，通过前面的介绍，我想大家应该能想到，软件测试是在项目启动的时候就已经开始了的，而结束的时间一般来说就是别指望。为啥这么说呢？除非这个软件没人用了，或者这个软件项目已经停止更新了，否则软件测试就会要不断的进行，每一次的软件版本迭代更新伴随而来的是一次又一次的回归测试，来确保新版本的质量。所以说测试工作不要做结束的指望。但是在软件项目开发的过程中，测试工作的时序还是有着一定的规律性：
一般来说，可以分为以下几个阶段（时序按先后顺序排列）：
1、需求阶段
这个阶段主要是进行需求分析与评审，参与对客户或用户关于软件产品原始需求的分析，或者指导客户提需求，保证需求的合理性。这个阶段的输入是用户或客户的原始需 求，输出则是《产品需求规格说明书》，同时测试工作包括对《产品需求规格说明书》的评审（包括后续各阶段的文档都是需要经过评审通过的）。
2、计划阶段
这个阶段则是针对需求对整个测试工作的一个宏观计划，我认为应该至少包括以下两点，
1、资源计划，包括时间资源：人员资源的利用，什么人在什么时间点做什么工作，时限多少。
2、策略计划：测试在什么阶段针对什么需求使用什么方法，执行方案。
这两点需结合起来才算式比较完整的计划，这个阶段的输入是《产品需求规格说明书》，输出是《项目测试计划》。
3、设计阶段
这个阶段主要就是设计测试用例啦，计划做好了，为了执行测试的规范，高覆盖率和高效率。就要根据计划对各功能点，各个需求设计测试用例，开发自动化测试脚本等
这个阶段的输入是《项目测试计划》、《概要设计文档》、《详细设计文档》，输出是《测试用例》。
4、执行阶段
前面几个阶段都如期完成后，这个阶段的主要工作就可以根据《测试用例》来执行测试啦，通过测试发现的BUG提交给程序员修复，修复完成后返测。
这个阶段又可以按照时序分为：单元测试、集成测试、系统测试（包括确认测试）、验收测试。直到验收测试结束，第一阶段的测试工作也快接近尾声了，后续版本更新的 时候又会有大量的回归测试工作要做。这个时候之前设计阶段的成果《测试用例》就体现出优势了，通过第一轮测试后测试用例会不断完善，之前做过的测试工作在回归测试的 时候就会更加顺手，甚至可以通过自动化测试工具代替我们完成测试执行工作。
5、总结阶段
最后也是最重要的阶段，通过对测试工作的总结，能发现许多工作中存在的问题，分析之后，对以后的工作效率，工作准确度的提高有很大的帮助。这个阶段的输出是《测 试总结文档》。
在软件测试工作不断积累提高下，于是就衍生出了许多与软件测试相关的模型，以‘W’模型为例：
就强调了软件开发与测试是同步进行的，测试的对象不仅仅是程序，需求、设计等同样要测试的观点。
How---如何进行软件测试？
其实这个问题比较大，就软件测试的分类就不下20种，每种分类又有着不同的含义和操作方式。而设计测试用例的方法也多种多样各有优劣。对于如此庞大的一个知识体系，难以一篇文章介绍详尽，我们不妨换一个角度来看这个问题，找一个切入点来聊聊这个话题。
比方说，软件测试的工作内容是什么，通过前面的介绍，我想大家或许最软件测试工程师的工作内容有个基本的概念了，总的来说可以简单归纳为以下几点：
1、参与分析需求评审测试需求
2、参与测试计划的制定和执行
3、评审开发设计并参与测试设计和开发
4、测试环境的搭建
5、测试的执行
6、缺陷的发现和提交并协助定位、解决缺陷
7、测试的分析和总结
这也是作为一个软件测试工程师需要具备的能力，至于什么样的测试如：性能测试、自动化测试等，怎么具体去开展，以后我会通过博客把我所学的知识和锻炼出来的技能和大家分享，目前的我， 仍然只是一个小菜鸟。当然不同企业的要求也不同，测试工作开展的方式也会不同。努力去学习知识并转化为自己的技能自然是极好的。
直到现在我还并没有将软件测试的官方定义贴出来，不过我相信现在大家再去看这个软件测试的定义，想必是十分容易理解的了吧，贴出来给大家参考一下吧。
软件测试的定义：
使用人工或自动手段，来运行或测定某个系统的过程。其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
最后再说一点，软件测试并不能提高软件的质量，而通过软件测试能验证软件的质量，并与开发共同解决出现的问题才能达到保证软件质量的目的。我想也正因如此，软件测试才是软件工程中不可或缺的一部分吧！
第一次写博客，旨在分享心得体会，欢迎大家分享转载，不足之处，还望大家指正。
短暂的温柔
2016-12-16