软件测试就只能挑Bug？绝对远远不止

“什么是软件测试？”这个看似简单的一个问题，其实也是最难的问题。说它简单，是由于这是一个基本的问题，作软件测试工做多年的小伙伴，天然知道什么是软件测试。说它难，是由于“软件测试”有不少内涵，要了解其所有内涵，并不是那么容易。若是咱们去问软件研发人员什么是软件测试，获得的答案可能五花八门，人们对软件测试有不一样的理解。如今最多见的理解就是:软件测试就是找bug、发现缺陷。

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

• 检查软件产品是否符合设计要求；
• 验证软件产品需求、设计和实现的一致性；
• 确认软件产品是否知足用户的实际需求；
• 对软件产品质量的全面评估；
• 提供软件产品质量信息；
• 揭示软件产品的质量风险；
• 投入较低的保障性成本极大地下降劣质成本；
• 验证与确认；
• 调查、分析和比较；
• 不断探索；

……

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

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

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

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

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

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

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

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

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

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

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

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

从狭义测试到广义测试

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

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

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

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

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

• 狭义的软件测试：动态测试——运行程序而进行的测试，测试只是编程以后的阶段，这也是由传统的瀑布模型而决定的。
• 广义的软件测试：动态测试+静态测试，将需求评审、设计评审、代码评审（含代码的静态分析）等也归入软件测试工做之中。这也使“软件测试”再也不停留在编程以后的某个阶段上，而成为贯穿整个软件研发周期的质量保证活动，这也是本书“全程软件测试”的最先立意所在。

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

无论你是刚入门的小白、还没入门的群众、已经入门好久的前辈，不知足如今的工做状况，你想升值加薪，想弯道超车，均可以加个人群：903217991，我们会提供一套专门的测试学习路线规划，带领你实现人生逆袭，财富自由。固然，我们也有免费的资料能够提供给喜欢自学的小伙伴，因此欢迎你们踊跃加群~我会一一为你们经过的。

基于质量的认知

软件测试虽然不能等同于软件质量保证（SQA），但它是软件质量保证的主要手段之一。当咱们讨论软件测试时，绝对离不开“质量”。基于质量的认识，软件测试就是对软件产品的质量评估，提升软件产品有关的质量信息。即便从1.1节中咱们认为软件测试就是发现软件产品中的bug（缺陷），哪什么是“缺陷”呢？简单地说，缺陷就是质量的对立面，一切违背质量的问题均可以看做软件缺陷（虽然从专业术语来仔细辨析的话，会将问题分为“内在错误，外部失效”等）。因此要理解软件测试，就必须理解软件质量。

提及“质量”这个概念，咱们都很熟悉，会说“坏的质量会怎样怎样，好的质量会怎样怎样”，但让咱们给出质量的正式定义，可能不是容易的事情。咱们也能够查国际标准，了解如何给质量下定义。例如IEEE Std 829-2008定义质量就是系统、组件或过程知足特定需求的程度，知足客户/用户需求或指望的程度。知足程度越高，质量就越好。例如，从软件需求定义文档来看，它所描述的需求和客户实际业务需求越吻合，未来实现的软件越有可能知足客户的业务需求，也意味着需求文档的质量越高。但这样说，仍是比较宽泛，很难衡量质量。那究竟如何评估质量？从哪些维度来衡量质量呢？这就引出质量模型。基于质量模型，咱们能够清楚质量有哪些属性（或维度），而后针对这些属性逐个地进行评估，不须要对软件质量进行总体评估，至关于按质量的各个维度来进行评估、各个击破。

过去将软件质量分为内部质量、外部质量和使用质量，像代码的规范性、复杂度、耦合性等能够看做是内部质量，内部质量和外部质量共用一个质量模型。如今国际/国家标准将内部质量和外部质量合并为产品质量。产品质量能够认为是软件系统自身固有的内在特征和外部表现，而使用质量是从客户或用户使用的角度去感知到的质量。由于质量是相对客户而存在，没有客户就没有质量，质量是客户的满意度。过去认为，内部质量影响外部质量、外部质量影响使用质量，而使用质量依赖外部质量、外部质量依赖内部质量。今天能够理解为产品质量影响使用质量，而使用质量依赖产品质量。

1．产品质量

根据国际标准IEEE 24765-2010，产品质量是指在特定的使用条件下产品知足明示的和隐含的需求所明确具有能力的所有固有特性。而根据ISO 25010:2011标准，质量模型从原来的6个特性增长到8个特性，新增长了“安全性、兼容性”。如图1-2所示，蓝色标注的内容属于新增长或改动的内容。这里的安全性是指信息安全性（Security），原来放在“功能性”下面，但如今绝大部分产品都是网络产品，安全性愈来愈重要，因此有必要做为单独的一个维度来度量。今天系统互联互通已经很广泛，其次终端设备愈来愈多，除了传统的PC机，还有许多智能移动设备，如手机、平板电脑、智能手环、智能手表等，这些都要求系统具备良好的兼容性。这些特性就对应着测试类型，如功能测试、性能测试（效率）、兼容性测试、安全性测试等。

图1-2　ISO 25010 2016 产品质量模型

• 功能适应性（functional
  suitability）：软件所实现的功能达到其设计规范和知足用户需求的程度，强调正确性、完备性、适合性等。
• 效率（efficiency）：在指定条件下，软件对操做所表现出的时间特性（如响应速度）以及实现某种功能有效利用计算机资源（包括内存大小、CPU占用时间等）的程度，局部资源占用高一般是性能瓶颈存在；系统可承受的并发用户数、链接数量等，须要考虑系统的可伸缩性。
• 兼容性（compatibility），涉及共存和互操做性，共存要求软件能给与系统平台、子系统、第三方软件等兼容，同时针对国际化和本地化进行合适的处理。
  互操做性要求系统功能之间的有效对接，涉及API和文件格式等。
• 易用性（usability）：对于一个软件，用户学习、操做、准备输入和理解输出所作努力的程度，如安装简单方便、容易使用、界面友好，并能适用于不一样特色的用户，包括对残疾人、有缺陷的人能提供产品使用的有效途径或手段（便可达性）。
• 可靠性（reliability）：在规定的时间和条件下，软件所能维持其正常的功能操做、性能水平的程度／几率，如成熟性越高，可靠性就越高；用平均失效前时间（Mean
  Time To Failure，MTTF）或平均故障间隔时间（Mean Time Between
  Failures，MTBF）来衡量可靠性。
• 安全性（security）：要求其数据传输和存储等方面能确保其安全，包括对用户身份的认证、对数据进行加密和完整性校验，全部关键性的操做都有记录（log），可以审查不一样用户角色所作的操做。它涉及保密性、完整性、不可抗抵赖性、可审核性、真实性。
• 可维护性（maintainability）：当一个软件投入运行应用后，需求发生变化、环境改变或软件发生错误时，进行相应修改所作努力的程度。它涉及模块化、可复用性、易分析性、易修改性、易测试性等
• 可移植性（portability）：软件从一个计算机系统或环境移植到另外一个系统或环境的容易程度，或者是一个系统和外部条件共同工做的容易程度。它涉及适应性、可安装性、可替换性。

2．使用质量

从ISO/IEC 25010标准看，软件测试还要关注使用质量，如图1-3所示。在使用质量中，不只包含基本的功能和非功能特性，如功能（有效与有用）、效率（性能）、安全性等，还要求用户在使用软件产品过程当中得到愉悦，对产品信任，产品也不该该给用户带来经济、健康和环境等风险，并能处理好业务的上下文关系，覆盖完整的业务领域。

图1-3　使用质量的属性描述

为了便于理解使用质量，下面举3个例子。

【例1-1】我本身亲身经历的例子。我在手机上安装了一个英语学习软件，自动下载该款软件用到的多个语音库（如新概念英语、六级英语等），它在我讲课时，但并无判断我手机链接的是Wi-Fi仍是3G/4G，形成个人流量大大超过套餐额度，产生了额外的300元流量费。从功能上看，自动下载是一个不错的功能，但有很大的经济风险，在使用质量上有明显缺陷。

【例1-2】当咱们玩游戏，沉醉于某款游戏，从产品自己质量属性看。是一个好产品，没有问题。但从使用质量看，会有损于玩家的健康，有健康风险，因此须要设置防沉迷功能。

【例1-3】当咱们使用百度地图、滴滴打车等软件时，每每是在大街上。若是站在人行道或安全地方使用没问题，可是若是一面横穿马路一面还在使用，就有安全风险。这类软件应该给予提示，不然它们要承担相应的风险责任。

基于风险的认知

由于没有办法证实软件是正确的，软件测试自己老是具备必定的风险性，因此软件测试被认为是对软件系统中潜在的各类风险进行评估的活动。从风险的观点看，软件测试就是对软件产品质量风险的不断评估，引导软件开发工做，进而将最终发布的软件所存在的风险降到最低。基于风险的软件测试认知主要体如今两点上：

软件测试不只仅停留在单个缺陷上，要从所发现的问题看到（分析出）某类质量风险或某个具备潜在风险的区域。

软件测试被看做是一个动态的质量监控过程，对软件开发全过程进行检测，随时发现不健康的征兆，及时评估新的风险，设置新的监控基准，不断地持续下去。

基于风险对测试的认知，会强调测试的持续性，持续地进行测试，写几行代码就要作测试、实现一个功能就要对这个功能进行测试，开发和测试相伴而行。这种认知特别适合敏捷开发模式下的测试——敏捷测试。在敏捷开发中，软件测试就能被解释为对软件产品质量的持续评估。在敏捷方法中，不只提倡持续集成，并且提倡持续测试，持续集成实际上也是为了持续测试。

基于风险对测试的认知还不断提醒咱们：在尽力作好测试工做的前提下，工做有所侧重，在风险和开发周期限制上得到平衡。首先评估测试的风险，每一个功能出问题的几率有多大？根据Pareto原则（也叫80/20原则），哪些功能是用户最经常使用的20％功能？若是某个功能有问题，其对用户的影响又有多大？而后根据风险大小肯定测试的优先级。优先级高的功能特性，测试优先获得执行。通常来说，针对用户最经常使用的20％功能（优先级高）的测试会获得彻底地、充分地执行，而低优先级功能的测试（另外用户不经常使用的80％功能）就可能因为时间或经费的限制，测试的要求下降、减小测试工做量。

基于社会的认知

软件不一样于硬件，软件通常都是应用系统，经常和人们的娱乐、事务处理、商业活动、社区交流等紧密联系在一块儿，因此软件具备很强的社会性，因此有必要把心理学、人类学和社会学等引入到软件测试中。软件测试不只仅是技术活动，并且是社会、心理等综合性活动，软件测试是跨学科的（inter-disciplinary）活动，以系统为焦点（systems-focused），经过不断调查（investigative）和讲故事（storytelling）的方式完成软件质量的评估。

经过软件测试的社会性认知，强调测试人员的思惟能力和探索能力，强调测试的有效性和可靠性，在测试中要理解用户的行为、人们活动的背景和目的（上下文关系），不断观察，不断学习，发现和质量相关的信息（差别或质疑），从客户利益、业务特性出发来守护产品的价值。

也正是因为软件测试的社会性，须要对软件产品的易用性、免于风险的程度、上下文覆盖等进行验证。在易用性测试中，人们经常进行A/B测试，给出不一样的解决方案（UI布局、功能设计等），向不一样的用户群发布产品，来检测哪一个解决方案更受用户喜欢。

基于经济的认知

通常来讲，一个软件产品没有通过测试是不会发布（release）、不会部署(deploy)到产品线上，或者说，不敢发布、不敢上线。由于在当前的开发模式和开发技术状况下，人们开发的软件存在严重的缺陷绝对是大几率事件。若是没有通过测试，就发布出去，可能软件根本不能用、很差用，或者用起来出现各类各样的问题，用户满意度很低，给产品形成负面影响，甚至给客户带来严重的经济损失或影响到用户的生命安全。

从经济观点看，软件缺陷会给企业带来成本，这个成本就叫劣质成本（Cost of Poor Quality，COPQ）。基于经济的认知，软件测试就是经过投入较低的保障性成原本下降劣质成本，帮助企业得到利润。高质量不只是有竞争力，并且是带来良好的经济收益的。例如苹果手机就是以其高质量得到比其余品牌手机更高的利润率。据相关媒体统计数据看，苹果智能手机在高端手机市场只占四分之一，但利润占到一半。

测试的经济观点就是如何以最小的代价得到更高的收益，这也要求软件测试尽早开展工做，发现缺陷越早，返工的工做量就越小，所形成的损失就越小。因此，从经济观点出发，测试不能在软件代码写完以后才开始，而是从项目启动的第一天起，测试人员就参与进去，尽快尽早地发现更多的缺陷，并督促和帮助开发人员修正缺陷。

基于标准的认知

软件测试被视为“验证（Verification）”和“有效性确认（Validation）”这两类活动构成的总体，缺一不可。若是只作到其中一项，测试是不完整的。

• “验证”是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性。验证过程提供证据代表软件相关产品与全部生命周期活动的要求相一致，即验证软件实现（即交付给客户的产品）是否达到了软件需求定义和设计目标。
• “有效性确认”是确认所开发的软件是否知足用户实际需求的活动。由于软件需求定义和设计可能就不对，上述一致性不能保证软件产品符合客户的实际需求，并且客户的需求也是在变化的，当需求定义是半年前肯定的，这种变化的可能性就比较大。

对验证和确认有不一样的解释。简单地说，单元测试、集成测试和系统测试均可以理解为“验证”，都是基于需求定义文档和设计规格说明书文档来进行验证；而验收测试则在用户现场、由用户共同参与进行，能够理解为“有效性确认”，由于以前的需求定义和设计均可能存在错误，研发团队没有正确理解用户的原意（用户的真实指望），仅仅根据需求定义文档和设计规格说明书文档来完成测试，并不能表明所实现的功能特性是用户真正想要的。而在验收测试中，用户参与进来，是能够确认所实现的功能特性是不是用户真正想要的。

另外一种解释是根据图1-4所示的V模型，验证是架构设计评审、详细设计评审和代码评审/单元测试，分别验证架构设计是否和需求一致、详细设计是否和架构设计一致、代码是否和详细设计一致，用左边带箭头的粗虚线表示。而有效性确认则是集成测试、系统测试、验收测试，如中间带箭头的细虚线表示。

图1-4　软件研发的V模型

另外一种解释是根据图1-4所示的V模型，验证是架构设计评审、详细设计评审和代码评审/单元测试，分别验证架构设计是否和需求一致、详细设计是否和架构设计一致、代码是否和详细设计一致，用左边带箭头的粗虚线表示。而有效性确认则是集成测试、系统测试、验收测试，如中间带箭头的细虚线表示。

结语

无论你是刚入门的小白、还没入门的群众、已经入门好久的前辈，不知足如今的工做状况，你想升值加薪，想弯道超车，均可以加个人群：903217991，我们会提供一套专门的测试学习路线规划，带领你实现人生逆袭，财富自由。固然，我们也有免费的资料能够提供给喜欢自学的小伙伴，因此欢迎你们踊跃加群~我会一一为你们经过的。