1. 软件的组成
软件由程序，数据，文档三部分组成，由此也指引出软件测试的方向，即为以上三部分。
2. bug的定义
bug一词由来已久。它的起源可追溯到计算机的上古时代，起因是Grace Hopper在解决计算机故障时，发现一只虫子因触电死在了继电器上，导致运行失败。于是她将这样的计算机缺陷称之为 bug ，找缺陷为 debug。
作为软件测试人员，我们主要的工作也是与bug打交道，预防bug，寻找bug等等。那我们应该如何定义一个bug呢。我们这里参考一下Ron Patton在《软件测试》一书中的定义：
软件未实现产品说明书中要求的功能
软件出现了产品说明书中指明不应该出现的功能
软件实现了产品说明书中未提到的功能
软件未实现产品说明书中虽未明确提及但应该实现的功能
软件难以理解，不易使用，运行缓慢，或（从测试的角度）最终用户会认为不好
我们首先明晰一个概念：产品说明书，这与我们可以将它理解为需求/需求文档。
分析以上五点，软件的缺陷从两个层面进行定义：一是客观层面（1~4），二是主观层面（5）。
客观层面前两点比较好理解，软件与需求不符即为bug，这点与我们的认知相符。但后两点开始模棱两可了，软件实现了需求之外的功能，与没实现隐性需求，均与需求文档不符。但我们不能轻易判断这是否是一个缺陷。需求之外的功能可能是行业标准，隐性需求可能不是刚需，那这样就不算是一个bug。反之这就是一个应该被提交的问题。这就要求我们测试必须足够灵活，来做好这个判断。这也提醒我们提交一个软件缺陷一定要有理有据，才令人信服。由上我们可以认识到，缺陷在客观层面与需求紧密相连，一个好的需求文档应该满足两点原则：明确 和 合理 。这也是我们测试需求文档的重要思想。
主观层面可以说非常考验测试人员了，什么叫难以理解，不易使用，运行缓慢，这些都没有统一的标准。最终用户会觉得不好还是你不喜欢？要想做好最后这一点，对测试人员的经验、能力、处事多方面都提出了高要求，这也是测试难做的点，没有统一客观标准。所以我们必须再次提出，作为测试人员，一定要灵活。这样的灵活能力来自于我们积累的经验，我们的专业判断，和对产品深入的理解。
所有不满足需求或超出需求的都是缺陷
没有不存在缺陷的软件，只有迄今为止尚未发现的缺陷
3. 软件测试的定义
虽然bug早在计算机诞生后不久就提出了，但软件测试的概念直到70年代中期才开始被提出来。这与计算机软件越来越庞大，而软件质量越来越难以保证有很大关系。1975年《测试数据选择的原理》文章发表，软件测试被确定为一中研究的方向。软件质量保证的号角也开始渐渐吹响，其中不乏一些优秀和经典的作品，比如《软件测试的艺术》。
对于软件测试，有多个角度的定义方式，这里我们一个一个来看：
-
正向思维定义：顺着软件运行逻辑，以确信其最终能够正常运行为目标/导向而展开的任何行为，是软件测试。
-
反向思维定义：抱着怀疑主义的精神，相信软件一定存在缺陷的想法作为出发点。逆着软件运行的内生逻辑，以证明其存在的缺陷为目标/导向而开展的任何行为，是软件测试。
一个好的测试用例在于它能发现以前未发现的错误
一个成功的测试是发现了以前未发现的错误的测试
关于这里的双向思维定义，感触颇多。正向和方向的思维方式不光在测试里有用，推而广之，这也是我们解决任何问题的原则之一：多角度看问题。通过这样的思考方式，既有助于我们解决问题，也变相帮我们验证了问题本身。而当我们运用这样的思维方式进行反推会发现，其实这也是“条条大路通罗马”的一个应用实践。这条鸡汤也再一次提醒我们：be flexible，要灵活!
- IEEE定义：
在规定的条件下运行系统或构件的过程：观察和记录结果，并对系统或构建的某些方面给出评价
分析软件项目的过程：检测现有状况与所需状况之间的不同，并评估软件项目的特性
前面双向思维式的定义是从软件测试的方法出发，给出软件测试的定义。而审视IEEE对软件测试的定义，从更加宏观的角度，回答了软件测试是什么。
第一条，我们注意两点，一是在规定条件下运行系统或构建，这个过程就是软件测试。规定条件可以是我们运用上面正反向思维框定的测试用例，也可以是其他测试方法下的用例。二是作为测试人员，我们的工作内容是什么？是三部分：设计测试用例（为软件规定条件），运行用例，观察和记录运行的结果，最后对被测试的软件进行评价。这里引入评价这一点很精髓，既展示出测试工作的成果，又有助于我们确定软件改进的方向。
第二条，在明晰了测试和测试人员的主要工作后，进一步将测试的范围扩大，从对软件本身的测试，推广到对整个软件项目过程（生命周期）的测试，在这一层，我们测试人员需要做做三点：对软件生命周期各个阶段进行分析，检测/觉察出现实状况与我们所需要的状况之间的差异，最后做出我们对整个软件项目的评估/评价/总结。这一条无疑是非常难以做到的，需要我们的日积月累，厚积薄发。
- 广义定义：软件测试是对软件形成过程中的所有工作产品（包括程序及相关文档）进行测试，而不仅仅是对程序的运行进行测试
这是一个单纯的对软件测试的定义，了解IEEE的定义，我们不难看出广义的定义其实也是它的一个子集。不过它很好的提示了我们，不要只看到狭义的软件测试（对程序本身的测试），还要扩展到对软件开发整个过程的质量保证。
这里我们提出两个重要的软件测试的术语：
-
确认（validation）：通过检查和提供客观证据来证实特定目的的功能或应用是否已经实现。
-
验证（verification）：通过检查和提供客观证据来证实指定的需求是否满足。
这两个词是递进的关系，验证包含了确认。确认用来检查功能有没有实现，而验证更进一步，看实现的功能满不满足需求（实现了功能不代表会满足需求）。
学习完以上四点定义，我们对软件测试是什么，和软件测试做些什么有了一定的了解，那软件测试的目的什么呢？我们来谈谈。
借用Ron Patton的话来说，软件测试的目的就是一点：
尽早地发现软件缺陷，并确保其得以修复。
这也是作为软件测试人员来说，我们最重要的使命。这里我们需要注意几个关键词，“尽早”是指我们应该在项目早期就介入，以期从根源减少缺陷的出现。另一个是“修复”，注意修复不是单纯指改bug，因为我们知道，有些bug是我们无法解决的或者解决成本过大的。所以我们在进行修复时，可以不单单选择修改代码，还可以选择在用户手册中进行提示等方式，来解决问题。方法多样，灵活选择。
除了以上一点最重要的目的，我们还引申出两点有意义的：
-
利用测试过程中得到的测试结果和信息，作为未来测试的参考，减少类似错误的发生
-
不断地提高测试的效率和产品的质量
最后提一下，测试和调试的区别。它们一个是软件测试概念，一个是开发概念，注意区别即可。
