“什么是软件测试？” 这个看似简单的问题，其实是最难的问题。 说它简单，是因为这是一个基本问题。 做了多年软件测试的朋友自然知道什么是软件测试。 之所以困难，是因为“软件测试”有很多内涵，要理解它的所有内涵并不那么容易。 如果我们问软件开发人员什么是软件测试，我们得到的答案可能五花八门，人们对软件测试的理解也不同。 现在最普遍的理解是软件测试就是发现bug、发现缺陷。
但有些人可能认为软件测试是：
……
理解有太多，没有一个是错的，只是看问题的角度不同而已。 虽然在回答问题的时候，很容易不经过深思熟虑就脱口而出。 我只看到软件测试的一方面，没有系统分析“什么是软件测试”。
接下来我们将讨论“什么是软件测试”，因为有理解，就会有行动。 有正确的认识，才会有正确的操作； 相反，如果理解错误，就会出现错误的操作。 因此，我们首先帮助读者对“软件测试”建立正确、全面的认识，构建完整的“软件测试”纲要，以免陷入“盲人摸象”的困境，产生片面的认识。的软件测试。 然后我们继续讨论流程、方法、技术和实践。 也就是说，在全面讨论“完整的软件测试”之前，我们需要找到一种共同语言，即对软件测试的一些基本概念达成共识，从而为后续的沟通扫除障碍。
软件测试的基本认知——正向思维和负向思维
什么是软件测试？ 人们常常回答：软件测试是为了发现软件产品中的bug（缺陷）。 有人说，不，软件测试是为了验证软件产品功能是否满足用户的需求。 其实，以上答案都是正确的。 它们解释了软件测试的优点和缺点。
早期，人们更多地将“测试”视为对产品的“检查”，检查软件的各项功能是否正常运行。 正如 Bill Hetzel 在 1983 年对软件测试的定义：“软件测试是一系列旨在评估程序或软件系统的特征或功能并确定其是否达到预期结果的活动。” 从这个定义中，至少我们可以看出以下两点。
测试试图验证软件是否“有效”，即它是否正确执行其功能。 测试活动基于人们的“假设”或“预期结果”。 这里的“假设”或“预期结果”是指需求定义和软件设计的结果。
但同时我们知道，软件测试有一个原则：测试不能穷尽。 测试会面临大量的测试数据、测试场景或者代码路径等，测试只是一个样本实验。 不能证明该软件是正确的。 只能说明发现的缺陷确实是缺陷。 但如果没有发现问题，并不意味着问题不存在，而是到目前为止还没有发现软件中潜在的问题。 正如《软件测试的艺术》一书的作者 Glenford J. Myers 所说，测试不应侧重于验证软件是否正常工作。 相反，应该使用逆向思维来发现尽可能多的错误。 他认为，从心理学的角度来看，如果以“验证软件是否工作”作为测试的目的，对于测试人员发现软件错误将非常不利。 因此，1979年他对软件测试给出了不同的定义：“测试是执行程序或系统以发现错误的过程”。 从这个定义可以看出，软件被假定总是有缺陷的（实际上也是如此），如果有错误，测试是为了发现缺陷，而不是证明程序没有错误。
从这个定义延伸，成功的测试就是发现软件问题的测试，否则测试就没有价值。 这就好比一个病人（因为他是病人，假设他确实生病了），去医院做相应的检查，没有发现问题，就说明这次体检是失败的，浪费了病人的时间。时间和金钱。 用逆向思维引导人们证明软件“不行”，会鼓励我们不断思考开发人员对需求的误解、不良习惯、程序代码边界、无效数据输入等，寻找或识别薄弱环节在系统中要走出系统的复杂区域，目标是发现系统中的各种问题。
人类活动具有很强的目的性，建立适当的目标具有显着的心理影响。 如果测试的目的是证明程序没有错误，你可能会下意识地往这个方向走。 在测试的过程中，你不会刻意地尽量选择一些会让程序出错的测试数据，而是选择一些常用的数据。 测试会很容易通过，但很难发现问题。 如果测试的目的是为了证明程序有错误，那么我们会尽量选择一些容易发现程序错误的测试数据，这样可以更早、更快地发现缺陷。 毕竟，开发人员努力以正向思维来构建软件，因此逆向思维可以提高我们的测试效率。
逆向思维也有一个缺点。 很容易陷入部分深入的测试，缺乏广度。 因为你认为某个地方有缺陷，所以你测试这个地方，然后继续深入钻研。 这样，很容易忽略一些区域。 那些地方虽然缺陷不多，但如果出现严重缺陷，我们就承受不起。 因此，积极的思考也是有价值的。 它将督促软件系统的所有功能点一一验证其正确性。 哪个功能更重要，需要更多的测试。 积极的思考将使我们的测试更广泛——良好的测试覆盖率。
要想做好测试工作，既要有深度，又要有广度； 检测工作本身既要高效，又要有完整的质量。 因此，我们要把正向思维和逆向思维有机地结合起来，实现效率和质量的平衡。 换句话说，当我们需要效率时，我们更多地使用逆向思维，当我们需要测试广度以保证完整的测试质量时，我们更多地使用前向思维。 这种平衡也体现在不同的应用领域，比如国防、航天、银行等关键软件系统，都不能承受系统的任何故障。 由于这些故障完全有可能导致灾难性事件，因此强调验证以确保非常高的软件质量。 对于一般的商业应用软件或服务，质量目标设定在“用户可接受的水平”，以降低软件开发成本，加快软件发布速度，便于市场拓展。 可以强调逆向思维，以便尽快发现大部分缺陷。
从狭义测试到广义测试
前面提到，Glenford J. Myers 早期对软件测试的简单定义是：“程序测试是执行程序以发现错误的过程。” 这也反映出当时对软件测试的认识非常有限。 这也受到软件开发的瀑布模型的影响，该模型认为软件测试是编程之后的一个阶段。 只有等待代码开发完成后，像用户一样执行程序、操作软件才能发现问题。 这就是“动态测试”。
对于需求阶段产生的缺陷，不同阶段发现和修复的成本是不同的。 如果在需求阶段发现需求缺陷并修复，只要修改需求文档，成本就很低。 如果需求阶段产生的缺陷在需求阶段没有发现，而在设计完成后才发现，则需要修改需求和设计，这会增加成本。 如果需求阶段产生的缺陷没有在需求和设计阶段发现，而是在代码编写之后才发现，那么需求、设计和代码都需要修改，成本就更大了。 设计问题是在设计阶段发现的。 只要修改了设计，如果到了后期才被发现，返工的路径就会变长，修复的成本自然就会增加。 缺陷发现得越晚，修复的成本就越高。 如图1-1所示，它展示了不同阶段修复不同阶段产生的缺陷的成本，所以这就要求我们尽早发现缺陷。
图1-1 不同阶段修复不同阶段产生的缺陷的成本
为了尽早发现缺陷，我们有必要将软件测试延伸到需求和设计阶段，即对软件产品的阶段性结果——需求定义文档和设计技术文档进行评审或验证。 这与软件质量保证（Quality Assurance，QA）不同。 QA虽然注重评审，但更注重评审过程和评审管理，包括对需求、设计、编码和测试过程的标准评审。 这里所说的需求和设计评审仍然是对软件产品的检查或验证，但需求文档和设计文档只是软件产品的阶段性产品。 如果按照“软件=程序+文档+数据结构”的定义，需求文档和设计文档也是软件的组成部分，软件测试自然就包括了对需求和设计的验证。
基于以上考虑，早期的动态测试扩展到静态测试，即狭义的软件测试发展为广义的软件测试。
静态测试是在软件系统未运行时对软件或阶段性结果进行评审，包括需求评审、设计评审、代码评审等。通过引入静态测试，可以尽早发现问题，消灭在萌芽状态，消除缺陷各阶段产生的物质都能及时消除，大大提高了产品质量，有效降低了企业成本。
基于质量的感知
虽然软件测试不能等同于软件质量保证（SQA），但它是软件质量保证的主要手段之一。 当我们讨论软件测试时，永远离不开“质量”。 软件测试是基于对质量的理解，对软件产品的质量进行评价，改进与软件产品相关的质量信息。 即使我们从1.1节中认为软件测试是为了发现软件产品中的bug（缺陷），那么什么是“缺陷”呢？ 简而言之，缺陷与质量相反。 所有违反质量的问题都可以被视为软件缺陷（尽管如果用专业术语仔细分析，问题会分为“内在错误、外部故障”等）。 所以要了解软件测试，就必须了解软件质量。
说起“质量”这个概念，我们都耳熟能详，都会说“质量不好会怎样，质量好会怎样”，但要给质量下一个正式的定义可能并不容易。 我们还可以查阅国际标准来了解质量是如何定义的。 例如，IEEE Std 829-2008 将质量定义为系统、组件或过程满足特定要求并满足客户/用户需求或期望的程度。 满意度越高，质量越好。 例如，从软件需求定义文档的角度来看，它描述的需求与客户的实际业务需求越一致，未来实施的软件就越有可能满足客户的业务需求，这也意味着更高的需求文档质量。 但这仍然相当广泛并且难以衡量质量。 那么，您究竟如何评估质量呢？ 使用哪些维度来衡量质量？ 这导致了质量模型。 基于质量模型，我们可以知道质量有哪些属性（或维度），然后对这些属性进行一一评价。 无需对软件质量进行全面评估。 它相当于评估并击败质量的各个维度。
过去，软件质量分为内部质量、外部质量和使用质量。 代码标准化、复杂性、耦合性等都可以视为内在质量。 内部质量和外部质量共享一个质量模型。 国际/国家标准现在将内部和外部质量合并到产品质量中。 产品质量可以认为是软件系统本身固有的内部特征和外在表现，而使用质量是从客户或用户的角度感知的质量。 因为质量是相对于客户而存在的。 没有客户就没有质量。 质量就是客户的满意。 过去认为，内在质量影响外在质量，外在质量影响使用质量，而使用质量取决于外在质量，外在质量又取决于内在质量。 今天可以这样理解，产品质量影响使用质量，使用质量又取决于产品质量。
1、产品质量
根据国际标准IEEE 24765-2010，产品质量是指产品在特定使用条件下满足明示和隐含要求的能力的所有固有特性。 根据ISO 25010:2011标准，质量模型由原来的6个特征增加到8个特征，并增加了“安全性和兼容性”。 如图1-2所示，蓝色标记的内容为新增或更改的内容。 这里的安全是指信息安全（Security），原本是放在“功能”之下的，但现在大多数产品都是网络产品，安全性越来越重要，所以需要将其作为单独的维度来衡量。 。 如今，系统互连已经非常普遍。 其次，终端设备越来越多。 除了传统的PC之外，还有很多智能移动设备，比如手机、平板电脑、智能手环、智能手表等，都要求系统具有良好的性能。 兼容性。 这些特性对应于测试类型，如功能测试、性能测试（效率）、兼容性测试、安全测试等。
图1-2ISO 25010 2016产品质量模型
2.使用质量
根据ISO/IEC 25010标准软件测试方法和技术 第三版 朱少民，软件测试还应关注使用质量，如图1-3所示。 使用质量不仅包括基本的功能性和非功能性特征，如功能性（有效性和有用性）、效率（性能）、安全性等，还要求用户在使用软件产品时获得乐趣、对产品的信任、并且该产品还不应给用户带来经济、健康和环境风险，并且能够处理业务上下文并覆盖完整的业务领域。
图1-3 使用质量属性说明
为了便于理解使用质量，这里举三个例子。
[示例1-1] 我个人经历的一个例子。 我在手机上安装了一个英语学习软件，自动下载了该软件使用的多个语音库（如新概念英语、六级英语等）。 我在讲课的时候，它并没有判断出我的手机连接的是哪部手机。 Wi-Fi仍然是3G/4G，导致我的流量大大超出了套餐限制，导致额外收取了300元的流量费。 从功能上来看，自动下载是一个不错的功能，但经济风险很大，使用质量也有明显缺陷。
【例1-2】当我们玩游戏并沉迷于某种游戏时，我们会看产品本身的品质属性。 这是一个好产品，没有任何问题。 但从使用质量来看，会损害玩家的健康，带来健康风险，因此设置防沉迷功能是有必要的。
【例1-3】当我们使用百度地图、滴滴打车等软件时，我们经常在大街上。 如果你站在人行道上或者安全的地方使用是没有问题的，但是如果你在过马路的时候使用的话，就有安全隐患了。 此类软件应给出提示，否则将承担相应的风险责任。
基于风险的认知
由于没有办法证明软件的正确性，软件测试本身总是带有一定的风险，因此软件测试被认为是评估软件系统中各种潜在风险的活动。 从风险的角度来看，软件测试是对软件产品质量风险的持续评估，指导软件开发工作，进而将最终发布的软件的风险降到最低。 基于风险的软件测试意识主要体现在两点：
软件测试不仅仅停留在单个缺陷上，还可以从发现的问题中识别（分析）某些类型的质量风险或存在潜在风险的领域。
软件测试被视为一种动态的质量监控过程，对整个软件开发过程进行测试，随时发现不健康迹象，及时评估新的风险，设定新的监控基准，并持续不断。
基于风险的测试理解将强调测试的连续性和持续测试。 写完几行代码之后，就必须测试一下。 要实现一个功能，必须测试该功能。 开发和测试齐头并进。 这种理解特别适合敏捷开发模式下的测试——敏捷测试。 在敏捷开发中，软件测试可以解释为对软件产品质量的持续评估。 在敏捷方法中，不仅提倡持续集成，而且提倡持续测试。 持续集成实际上是为了持续测试。
基于风险的对测试的认识也不断提醒我们：在尽最大努力做好测试的前提下，工作重点要在风险与开发周期约束之间取得平衡。 首先评估测试的风险。 每个功能出现问题的概率是多少？ 根据帕累托原则（也称为80/20原则），哪些功能是用户最常使用的20%？ 如果某个功能出现问题，会对用户造成多大影响？ 然后根据风险对测试进行优先级排序。 高优先级的功能特性将首先进行测试。 一般来说，用户最常用的20%功能（高优先级）的测试会完整完整地执行，而低优先级功能（用户不常用的另外80%功能）的测试可能会被完全执行。由于时间延迟或资金限制，测试要求降低，测试工作量减少。
基于社会的认知
软件不同于硬件。 软件一般是一个应用系统，往往与人们的娱乐、交易处理、商业活动、社区交流等密切相关，因此软件具有很强的社会性，所以需要将心理学和人类学结合起来。 和社会学被引入到软件测试中。 软件测试不仅是一项技术活动，更是一项社会、心理等综合活动。 软件测试是一项跨学科的活动，以系统为中心软件测试方法和技术 第三版 朱少民，通过不断的调查和讲述故事。 （讲故事）方法来完成软件质量的评价。
通过软件测试的社会认知，强调测试人员的思维能力和探索能力，强调测试的有效性和可靠性。 测试过程中，需要了解用户的行为、人们活动的背景和目的（上下文关系），并不断观察、不断学习、发现与质量相关的信息（差异或疑点），保护产品的价值基于客户兴趣和业务特点的产品。
正是由于软件测试的社会性，需要验证软件产品的易用性、无风险性、上下文覆盖率等。 在可用性测试中，人们经常进行A/B测试，给出不同的解决方案（UI布局、功能设计等），将产品发布给不同的用户群体，以测试哪种解决方案更受用户欢迎。
基于经济的认知
一般来说，一个软件产品在没有经过测试的情况下是不会发布或者部署到产品线上的，或者说是不会发布或者上线的。 因为在目前的开发模式和开发技术下，人们开发出来的软件肯定是大概率会出现严重的缺陷。 如果未经测试就发布，软件可能根本无法使用，可能难以使用，或者在使用时可能出现各种问题，导致用户满意度低，对产品造成负面影响，甚至造成严重的经济损失。顾客。 造成用户生命安全的损失或影响。
从经济学的角度来看，软件缺陷会给企业带来成本，这种成本称为不良质量成本（COPQ）。 基于经济认知，软件测试是为了降低劣质成本，通过投入较低的保障成本帮助企业获得利润。 高品质不仅具有竞争力，还能带来良好的经济效益。 例如，苹果手机因其高品质而比其他品牌手机获得更高的利润率。 据相关媒体统计，苹果智能手机只占高端手机市场的四分之一，但却占据了一半的利润。
测试的经济角度是如何以最低的成本获得更高的利润，这也要求软件测试尽早开始工作。 越早发现缺陷，返工的工作量越小，损失也越小。 因此，从经济角度来看，软件代码写完之后就无法开始测试。 相反，测试人员从项目的第一天就参与其中，尽早发现更多缺陷，并监督和帮助开发人员。 修复错误。
基于标准的意识
软件测试被视为由“验证”和“确认”两类活动组成的一个整体，两者缺一不可。 如果您只执行其中一项，则测试是不完整的。
对于验证和确认有不同的解释。 简单来说，单元测试、集成测试、系统测试都可以理解为“验证”，都是根据需求定义文档和设计规范文档进行验证； 而验收测试是在用户现场进行，有用户的参与，可以理解为“有效性确认”，因为之前的需求定义和设计可能存在错误，研发团队没有正确理解用户的初衷（用户的真实期望），仅根据需求定义文档和设计规范文档完成了测试，并不意味着实现的功能特性是用户真正想要的。 在验收测试中，用户参与确认所实现的功能特性是否是用户真正想要的。
另一种解释是，根据图1-4所示的V模型，验证是架构设计评审、详细设计评审和代码评审/单元测试，分别验证架构设计是否符合需求、详细设计是否符合要求。与架构设计是否一致，代码是否与详细设计一致，用左边带箭头的粗虚线表示。 有效性确认是集成测试、系统测试和验收测试，如中间带箭头的细虚线所示。
图1-4 软件开发V模型
另一种解释是，根据图1-4所示的V模型，验证是架构设计评审、详细设计评审和代码评审/单元测试，分别验证架构设计是否符合需求、详细设计是否符合要求。与架构设计是否一致，代码是否与详细设计一致，用左边带箭头的粗虚线表示。 有效性确认是集成测试、系统测试和验收测试，如中间带箭头的细虚线所示。
《完整的软件测试（第三版）》
《完整的软件测试（第三版）》
【美】朱少民撰
本书系统地总结了近十年来软件测试的变化，凝聚了作者许多宝贵的软件测试经验。 本书首先介绍了对软件测试的不同看法、全量软件测试的思想、软件测试基础设施和TA框架、团队能力建设； 然后逐步进入规划、设计、执行、测试的持续反馈和改进； 然后，讨论了全流程测试的思想，包括全流程静态测试、全流程性能测试、全流程安全、全流程建模、全流程可视化。 本书最后展望了软件测试的未来。
本书适合软件测试人员阅读，也可以作为相关专业人员的参考指南。
