软件测试就是挑Bug?也许你有认知偏差（上篇）

什么是软件测试？”这个看似简单的一个问题，其实也是最难的问题。说它简单，是因为这是一个基本的问题，做软件测试工作多年的小伙伴，自然知道什么是软件测试。说它难，是因为“软件测试”有很多内涵，要了解其全部内涵，并非那么容易。如果我们去问软件研发人员什么是软件测试，得到的答案可能五花八门，人们对软件测试有不同的理解。现在最常见的理解就是:软件测试就是找bug、发现缺陷。

但也有人会认为软件测试就是：

……

有太多的理解，而且都没有错，只是看问题的角度不一样。虽然回答问题时，也容易脱口而出，不会仔细斟酌，只看到软件测试的一面，没有系统地分析“什么是软件测试”。

下面我们就好好讨论“什么是软件测试”，因为有什么理解就有什么行动。有正确的理解，就有正确的操作；相反，有错误的理解，就有错误的操作。所以，先帮助读者对“软件测试”建立正确、全面的认识，构建起一个完整的“软件测试”轮廓，不至于陷入“盲人摸象”的困境，对软件测试有片面的理解。然后，我们再展开流程、方法、技术和实践的讨论。也就是在全面讨论“全程软件测试”之前，咱们需要找到共同语言，即对软件测试的一些基本概念达成共识，为后面的沟通扫除障碍。

软件测试基本认知——正反思维

什么是软件测试？人们常常回答：软件测试就是发现软件产品中的bug（缺陷）。也有人说，不对，软件测试是验证软件产品特性是否满足用户的需求。实际上，上述回答都没错，是对软件测试的正反两个方面的解释。

早期，人们更多的是将“测试”看作是对产品的“检验”，检查软件的每个功能是否运行正常。正如1983年Bill Hetzel将软件测试定义为：“软件测试就是一系列活动，这些活动是为了评估一个程序或软件系统的特性或能力，并确定其是否达到了预期结果。”从这个定义中，至少我们可以看到以下两点。

从这个定义延伸出去，一个成功的测试是发现了软件问题的测试，否则测试就没有价值。这就如同一个病人（因为是病人，假定确实有病），到医院去做相应的检查，结果没有发现问题，那说明这次体检是失败的，浪费了病人的时间和金钱。以逆向思维方式引导人们证明软件是“不工作的”，会促进我们不断思考开发人员对需求理解的误区、不良的习惯、程序代码的边界、无效数据的输入等，找到系统的薄弱环节或识别出系统复杂的区域，目标就是发现系统中各种各样的问题。

人类的活动具有高度的目的性，建立适当的目标具有显著的心理作用。如果测试目的是为了证明程序里面没有错误，潜意识里就可能不自觉地朝这个方向去做。在进行测试的过程中，就不会刻意选择一些尽量使程序出错的测试数据，而选择一些常用的数据，测试容易通过，而不容易发现问题。如果测试的目的是要证明程序中有错，那我们会设法选择一些易于发现程序错误的测试数据，这样，更早、更快地发现缺陷。毕竟开发人员力求构造软件，以正向思维方式为主，所以逆向思维方式可以提升我们的测试效率。

逆向思维也有不利的一面，容易陷于局部的深度测试，缺乏广度。因为觉得某个地方有缺陷，就对这个地方进行测试，然后不断深入下去，这样容易忽视一些区域。虽然那些地方产生的缺陷不多，但如果产生了严重缺陷，也是我们不能承受的。所以正向思维也是有价值的，它会督促针对软件系统的所有功能点，逐个验证其正确性，哪个功能越重要越要进行检验。正向思维会让我们的测试更有广度——良好的测试覆盖面。

为了做好测试，既要有深度，又要有广度；既要有效率，又要有测试工作自身完整的质量。所以，我们应该将正向思维和逆向思维有机地结合起来，做到效率和质量的平衡。换句话说，当我们需要效率时，更多采用逆向思维，当我们需要测试广度来确保完整的测试质量时，则多采用正向思维。这种平衡还体现在不同的应用领域，例如国防、航天、银行等关键性软件系统，承受不了系统的任何一次失效。因为这些失效完全有可能导致灾难性的事件，所以强调验证（verify），以保证非常高的软件质量。而一般的商业应用软件或服务，质量目标设置在“用户可接受水平”，以降低软件开发成本，加快软件发布速度，有利于市场的扩张，则可以强调逆向思维，尽快找出大部分缺陷。

从狭义测试到广义测试

前面提到Glenford J. Myers，他早期给软件测试的简单定义是：“程序测试是为了发现错误而执行程序的过程”，也体现出当时对软件测试的认识非常具有局限性。这也是受软件开发瀑布模型的影响，认为软件测试是编程之后的一个阶段。只有等待代码开发出来之后，通过执行程序，像用户那样操作软件发现问题，这就是“动态测试”。

对于需求阶段产生的缺陷，在不同阶段发现和修复的成本是不一样的。如果在需求阶段发现需求方面的缺陷并进行修复，只要修改需求文档，其成本很低。需求阶段产生的缺陷，如果在需求阶段没有发现，等待设计完成之后才被发现，就需要修改需求和设计，成本增大。需求阶段产生的缺陷，如果在需求和设计阶段都没有发现，等待代码写完之后才被发现，就需要修改需求、设计、代码，成本就更大。设计上的问题，在设计阶段被发现，只要修改设计，如果在后期发现，返工的路径就变长了，其修复的成本自然就增大。缺陷发现得越迟，其修复的成本就越高，如图1-1所示，呈现了不同阶段产生的缺陷在不同阶段修复的成本，所以这要求我们尽早发现缺陷。

图1-1　不同阶段产生的缺陷在不同阶段修复的成本

为了尽早发现缺陷，我们有必要将软件测试延伸到需求、设计阶段，即对软件产品的阶段性成果——需求定义文档、设计技术文档进行评审或验证。这不同于软件质量保证（Quality Assurance，QA），虽然QA侧重评审，但它重点评审流程、评审管理，包括对需求、设计、编码和测试过程规范性的评审。而这里提到的需求和设计的评审依旧是对软件产品的检验或验证，只是需求文档和设计文档只是软件产品的阶段性产品。如果按照“软件=程序+文档+数据结构”这样的定义，需求文档和设计文档等也属于软件的组成部分，软件测试自然也包括需求和设计的验证。

基于上述考虑，将早期的动态测试延伸到静态测试，即从狭义的软件测试发展到广义的软件测试。

静态测试就是在不运行软件系统时对软件或阶段性成果进行评审，包括需求评审、设计评审、代码评审等。引入静态测试，就可以尽早地发现问题，把问题消灭在萌芽之中，将每个阶段产生的缺陷及时清除，极大地提高产品的质量，有效地降低企业的成本。