为什么要有软件测试？编程程十八年经验讲师呕血分享

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

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

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

至少我们可以看到以下两点。

测试试图验证软件是“工作的”，也就是验证软件功能执行的正确性。

测试的活动是以人们的“设想”或“预期的结果”为依据。这里的“设想”或“预期的结果”是指需求定义、软件设计的结果。

但同时我们知道，软件测试有一条原则：测试是不能穷尽的。测试会面对大量的测试数据、测试场景或代码路径等，测试也只是一个样本实验，不能证明软件是正确的，只能说明发现的缺陷的确是缺陷。但如果没有发现问题，并不能说明问题就不存在，而是至今未发现软件中所潜在的问题。正如《软件测试的艺术》一书作者 Glenford. Myers所说，测试不应该着眼于验证软件是工作的，相反，应该用逆向思维去发现尽可能多的错误。他认为，从心理学的角度看，如果将“验证软件是工作的”作为测试的目的，非常不利于测试人员发现软件的错误因此，1979年他给出了软件测试的不同的定义：“测试是为了发现错误而执行一个程序或者系统的过程。”从这个定义可以看出，假定软件总是存在缺陷的（事实上也是如此）、有错误的，

测试就是为了发现缺陷，而不是证明程序无错误。

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

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

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

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

二、从狭义测试到广义测试

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

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

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

需求和设计的验证

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

狭义的软件测试：动态测试一一运行程序而进行的测试，测试只是编程之后的阶段

这也是由传统的瀑布模型而决定的

广文的软件测试：动态测试 静态测试，将需求评审、设计评审、代码评审（含代码的静态分析）等也纳入软件测试工作之中。这也使“软件测试”不再停留在编程之后的某个阶段上，而成为贯穿整个软件研发周期的质量保证活动。

下面是我在做自动化对于技术一些归纳和总结，希望能帮助到有心在技术这条道路上一路走到黑的朋友！

这些资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。

关注我的微信公众号：【伤心的辣条】免费获取~

我的学习交流群：902061117 群里有技术大牛一起交流分享~

如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！

好文推荐：

35岁之后软件测试工程师靠什么养家？我能继续做测试！

App公共测试用例梳理

Python简单？先来40道基础面试题测试下

阿里二黑叹息：越来越多的年轻人从职场撤退了？

从一名开发人员转做测试的一些感悟