对于一个软件来说，总会存在各种各样的软件缺陷。因此我们需要通过软件测试来检查软件中存在的各种问题。

在下面的这篇文章中，将讲解软件测试的基础知识，让我们一起来了解一下吧🙋

一、 软件缺陷的概述

1、什么是软件缺陷

​ 软件缺陷就是软件产品中所存在的问题，最终表现为用户所需要的功能没有完全实现，不能满足或不能全部满足用户的需求。

​ IEEE(电气电子工程师协会)对软件缺陷有一个标准的定义：

​ 从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、误差等各种问题。

​ 从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。

2、软件缺陷的类型

（1）软件未实现产品说明书要求的功能。

（2）软件出现了产品说明书不应该出现的错误。

（3）软件实现了产品说明书未提到的功能。

（4）软件未实现产品说明书虽未明确提及但应该实现的功能。

（5）软件难以理解、不易使用、运行缓慢——从测试员的角度看——最终用户会认为不好。

3、软件缺陷的案例

（1）千年虫问题（产生约1974年）

（2）爱国者导弹防御系统（1991年）

（3）英特尔奔腾浮点除法缺陷（1994年）

（4）“冲击波”病毒（2003年）

（5）诺基亚手机平台缺陷（2008年）

4、软件缺陷的产生原因

• 需求不明确
• 软件结构复杂
• 开发人员水平有限
• 项目期限短
• 使用新技术
• 其他原因

5、软件缺陷的分类

6、软件缺陷的处理流程

每个公司的软件缺陷处理流程不尽相同，但是它们遵循的最基本流程是一样的，都要经过提交、分配、确认、处理、复测、关闭等环节。

• 提交：测试人员发现缺陷之后，将缺陷提交给测试组长。
• 分配：测试组长接收到测试组员提交的缺陷之后，将其移交给开发人员。
• 确认：开发人员接收到移交的缺陷之后，会与团队甚至测试人员一起商议，确定该缺陷是否是一个缺陷。
• 拒绝：如果经过商议之后，缺陷不是一个真正的缺陷则拒绝处理，关闭缺陷。如果经过商议之后，确定其是一个真正的缺陷，则可以根据缺陷的严重程度或优先级等立即处理或延期处理。
• 复测：开发人员修改好缺陷之后，测试人员重新进行测试（复测），检测缺陷是否确实已经修改。如果未被正确修改，则重新提交缺陷。
• 关闭：测试人员重新测试之后，如果缺陷已经被正确修改，则将缺陷关闭，整个缺陷处理完成。

7、多学一招：缺陷报告（由测试人员完成）

测试人员在提交软件测试时都会按照公司规定的模板（Word、Excel、缺陷管理软件等）将缺陷的详细情况记录下来生成缺陷报告，每个公司的缺陷报告模板并不相同，但一般都会包括缺陷的编号、类型、严重程度、优先级、测试环境等，有时还会有测试人员的建议。

8、常见软件缺陷管理工具

（1）Bugzilla

• Bugzilla是Mozilla公司提供的一款免费的软件缺陷管理工具。
• Bugzilla能够建立一个完整的缺陷跟踪体系，包括缺陷跟踪、记录、缺陷报告、处理解决情况等。
• 使用Bugzilla管理软件缺陷时，测试人员可以在Bugzilla上提交缺陷报告，Bugzilla会将缺陷转给相应的开发者，开发者可以使用Bugzilla做一个工作表，标明要做的事情的优先级、时间安排和跟踪记录。

（2）禅道

• 禅道是一款优秀的国产项目管理软件，它集产品管理、项目管理、质量管理、缺陷管理、文档管理、组织管理和事务管理于一体，是一款功能完备的项目管理软件，完美地覆盖了项目管理的核心流程。
• 禅道分为专业和开源两个版本，专业版是收费软件，开源版是免费软件，对于日常的项目管理，开源版本已经足够使用。

（3）JIRA

• JIRA是Atlassian公司开发的项目与实务跟踪工具，被广泛用于缺陷跟踪、客户实务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。JIRA配置灵活、功能全面、部署简单、扩展丰富、易用性好，是目前比较流行的基于Java架构的管理工具。
• JIRA软件有两个认可度很高的特色：第一个是Atlassian公司对该开源项目实行免费提供缺陷跟踪服务；第二个是用户在购买JIRA软件同时将源代码也购置进来，方便做二次开发。

9、修复软件缺陷的成本

软件开发过程是使用软件工程的方法，在整个过程中，都有可能出现各种各样的软件缺陷。**随着开发时间的推移，软件缺陷修复成本呈倍数的增长。**假如早在进行分析时发现相关功能缺失，立即补上就可以了，可以说付出的代价小得几乎忽略不计。如果在发布时发现缺失某个功能，那么此时加上一个功能，相当于重新开发一样，这时的修补费用可以说高了许多。因此要尽早进行测试。

二、 软件的概述

1、软件生命周期

先来了解软件生命周期的全过程：

下面对软件生命周期各个过程进行逐一解析：

（1）问题定义：由软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。

（2）需求分析：对软件需求进行更深入的分析，划分出软件需要实现的功能模块，并制作成文档。（需求分析说明书）

（3）软件设计：在需求分析结果的基础上，对整个软件系统进行设计，包括系统框架设计、数据库设计等。（概要设计、详细设计）

（4）软件开发：在软件设计的基础上，选择一种编程语言进行开发。

（5）软件测试：软件开发完成后对软件进行测试，以查找软件设计与软件开发过程中存在的问题并加以修正。

（6）软件维护：软件投入使用之后，可能无法满足用户的使用需求，此时就需要对软件进行维护升级以延续软件的使用寿命。软件维护是软件生命周期中持续时间最长的阶段。

2、开发过程中的角色

（1）高级经理：参与项目过程中各个关键环节的活动，关注产品开发的进度，对风险控制、资源提供做出决策。

（2）产品经理（项目经理）：作为客户方和公司内部交流的纽带，对项目过程进行监控，对项目的进度、质量负责。

（3）开发经理：是具体开发过程的领导者，必需由熟悉业务和开发技术的专家担任；职责是界定需求，确定适当的技术架构和体系，保证软件产品按照设计的标准开发。

（4）设计师：软件蓝图设计者，可以分需求分析师、架构设计师、业务设计师三种。基本活动包括：需求分析、架构设计和功能设计，按照规范编写相应的文档。

（5）测试经理：测试活动的领导者，是公司内部认定的产品质量责任人。责任是计划和组织测试人员对目标产品进行测试，发现bug、跟踪bug直到解决bug；计划和组织用户培训工作。

（6）开发人员：根据设计师的设计成果进行具体编码工作，对自己的代码进行基本的单元测试。

（7）测试人员：根据测试经理的计划和测试总体方案对目标产品进行测试，编写测试用例和测试代码，发现和跟踪bug；编写用户手册；进行用户培训和教育。

（8）项目实施人员：针对工程性质的项目必需的人员配置，负责软件系统安装配置、系统割接、运行期间的维护工作。

3、软件开发模型

（1）瀑布模型

• 优点：检查点清晰，分工明确，有利于大型软件软件开发人员的组织管理及工具的使用与研究，可以提高开发的效率。
• 缺点：严格按照线性执行，增加了开发风险；要求必须有产出结果，增加了开发工作量。那么，对于现代软件，各阶段之间的关系很少是线性，瀑布模型已经不适合现代软件开发。

（2）快速原型模型

• 优点：克服了需求不明确带来的风险，适用于不能预先确定需求的软件项目。
• 缺点：原型设计较难；不利于开发人员对产品的扩展。

（3）迭代模型

• 优点：适应客户需求变更；降低了开发成本和风险。
• 缺点：增加了集成失败风险；容易退化为“边做边改”模式，失去对整个项目的控制。

（4）螺旋模型

• 优点：强调了风险分析，有助于将软件质量融入开发中；小分段构建大型软件，易于计算成本；客户参与，保证项目可控性。
• 缺点：构建过程太过繁琐，不适合小型项目。

（5）敏捷模型

• 定义：敏捷模型以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。

• 特点：

  • 项目被拆分成多个子项目，迭代完成，每个迭代都要经过测试。
  • 快速响应需求变更，在修改过程中，软件一直处于可用状态。
  • 不断对产品进行细微、渐进式地改进，每次改进一小部分，如果可行再逐步扩大改进范围。
  • 开发未动，测试先行。
  • 注重“人”的作用。

• 优点：及时响应客户需求变更，不断适应新的趋势。

• 缺点：管理相对混乱，不适合大型项目。

PS 以上内容是对软件开发模型的简要概括，如需了解软件开发模型的详细内容，请前往软件工程和过程模型

4、软件质量概述

（1）定义：软件质量是指软件产品满足基本需求及隐式需求的程度。软件产品满足基本需求是指其能满足软件开发时所规定需求的特性；其次是软件产品满足隐式需求的程度。

（2）软件质量模型：ISO/IEC 9126:1991质量模型是最通用的一个评价软件质量的国际标准，建立在MCCall和Boehm模型基础之上，主要描述了内部质量、外部质量和使用质量。由6个特性和27个子特性组成。

软件质量模型图如下：

对内部质量、外部质量和使用质量进行逐一解析：

①内部质量：针对内部质量需求被测量和评价的质量，可维护性、灵活性、可移植性、可重用性、可读性、可测试性、可理解性。

②外部质量：使用外部度量在模拟环境中，用模拟数据测试时，所被测量和评价的质量，即在预定的系统环境中运行时可能达到的质量水平。正确性、可用性、效率、可靠性、完整性、适应性、精确性、坚固性。

③使用质量：在规定的使用环境下，软件产品使特定用户在达到规定目标方面的能力。有效性、生产率、安全性、满意程度等。

三、 软件测试的概述

1、软件测试的发展

软件测试的发展也经历了一个漫长的过程，其发展过程可用下图表示：

2、软件测试的定义

（1）1983年，IEEE给软件测试的定义：

使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。

（2）1990年，IEEE再次给出软件测试的定义：

①在特定的条件下运行系统或构件，观察或记录结果，对系统的某个方面做出评价；

②分析某个软件项以发现现存的和要求的条件之差别并评价此软件项的特性。

总结：

• 以上的定义都有一定的片面性。不能只对系统程序进行测试，找出系统程序中的错误，而对分析、设计等过程发生的错误视而不见。
• 软件产品由文档、数据和程序组成，那么软件测试就是对软件开发过程中形成的文档、数据以及程序进行相关的测试。

3、软件测试的目的

• 对于软件开发来说，软件测试通过找到的问题缺陷帮助开发人员找到开发过程中存在的问题，包括软件开发的模式、工具、技术等方面存在的问题与不足，预防下次缺陷的产生。
• 对于软件测试来说，使用最少的人力、物力、时间等找到软件中隐藏的缺陷，保证软件的质量，也为以后软件测试积累丰富的经验。
• 对于客户需求来说，软件测试能够检验软件是否符合客户需求，对软件质量进行评估和度量，为客户评审软件提供有力的依据。

4、软件测试的分类

（1）按照测试阶段分类

• 单元测试：验证软件单元是否符合软件需求与设计，开发人员自测。
• 集成测试：将已经测试过的软件单元组合在一起测试它们之间的接口，用于验证软件是否满足设计需求。
• 系统测试：将经过测试的软件在实际环境中运行，并与其他系统的成分（如数据库、硬件和操作人员等）组合在一起进行测试。
• 验收测试：主要是对软件产品说明进行验证，逐行逐字的按照说明书的描述对软件产品进行测试，确保其符合客户的各项要求。

（2）按照测试技术分类

• 黑盒测试：把软件（程序）当作一个有输入与输出的黑匣子，它把程序当作一个输入域到输出域的映射，只要输入的数据能输出预期的结果即可，不必关心程序内部是怎么样实现的。

• 白盒测试：测试人员了解软件程序的逻辑结构、路径与运行过程，在测试时，按照程序的执行路径得出结果。白盒测试就是把软件（程序）当作一个透明的盒子，测试人员清楚的知道从输入到输出的每一步过程。

总结：

相对于黑盒测试来说，白盒测试对测试人员的要求会更高一点，它要求测试人员具有一定的编程能力，而且要熟悉各种脚本语言。但是在软件公司里，黑盒测试与白盒测试并不是界限分明的，在测试一款软件时往往是黑盒测试与白盒测试相结合对软件进行完整全面的测试。

（3）按照软件质量特性分类

• 功能测试：测试软件的功能是否满足客户的需求，包括准确性、易用性、适合性、互操作性等。
• 性能测试：测试软件的性能是否满足客户的需求，性能测试包括负载测试、压力测试、兼容性测试、可移植性测试和健壮性测试等。

（4）按照自动化程度分类

• 手工测试：测试人员一条一条的执行代码完成测试工作。费时费力且很难保证测试效果。
• 自动化测试：借助脚本、自动化测试工具等完成相应的测试工作，它也需要人工的参与，但是它可以将要执行的测试代码或流程写成脚本，执行脚本完成整个测试工作。

（5）按照测试项目分类

• 界面类测试：验证软件界面是否符合客户需求。
• 安全性测试：软件遭受到没有授权的内部或外部用户的攻击或恶意破坏时如何进行处理，是否能保证软件与数据的安全。
• 文档测试：以需求分析、软件设计、用户手册、安装手册为主，主要验证文档说明与实际软件之间是否存在差异。

（6）其他分类

• α测试：软件上线之前进行的版本测试。由开发人员和测试人员或者用户协助进行测试。测试人员记录使用过程中出现的错误与问题，整个测试过程是可控的。
• β测试：软件上线之后进行的版本测试。由用户在使用过程中发现错误与问题并进行记录，然后反馈给开发人员进行修复。
• 回归测试：对修改后的程序重新进行测试，确认原有的缺陷已经消除并且没有引入新的缺陷，这个重新测试的过程就叫作回归测试。
• 随机测试：没有测试用例、检查列表、脚本或指令的测试，它主要是根据测试人员的经验对软件进行功能和性能抽查。

四、 软件测试与软件开发的关系

软件测试在软件开发过程中占有重要的地位，在传统的瀑布模型中，软件测试只成为其阶段性的一段工作——进行代码的测试。而现代软件工程思想将软件测试认为是贯穿整个软件生命周期，并且是保证软件质量的重要手段之一。

有些研究数据显示，在国外软件开发的工作量中，软件测试的工作量占有总工作量的40%左右；软件开发的总费用中软件测试占有30%-50%。对于一些高科技开发系统，软件测试占有的时间和费用可能更多更高。

1、软件测试与软件开发

软件测试在项目各个阶段的作用如下：

• 项目规划阶段：负责从单元测试到系统测试的整个测试阶段的监控。
• 需求分析阶段：确定测试需求分析，即确定在项目中需要测试什么，同时制定系统测试计划。
• 概要设计与详细设计阶段：制定单元测试计划和集成测试计划。
• 编码阶段：编写相应的测试代码和测试脚本。
• 测试阶段：执行测试并提交相应的测试报告。

软件测试与软件开发的关系如下图所示：

2、常见软件测试模型

（1）V模型

• 优点：将复杂的测试工作分成了目标明确的小阶段完成，具有阶段性、顺序性和依赖性，它既包含了对于源代码的底层测试也包含了对于软件需求的高层测试。
• 缺点：只能在编码之后才能开始测试，早期的需求分析等前期工作没有涵盖其中，因此它不能发现需求分析等早期的错误，这为后期的系统测试、验收测试埋下了隐患。

V模型流程图如下：

（2）W模型

• 优点：测试范围不仅包括程序，还包括需求分析、软件设计等前期工作，这样有利于尽早全面的发现问题。
• 缺点：它将软件开发过程分成需求、设计、编码、集成等一系列的串行活动，无法支持迭代、自发性等需要变更调整的项目。

W模型流程图如下：

（3）H模型

• 设计原理：H模型的设计原理是将测试活动完全独立了出来，形成一个完全独立的流程，这个流程将测试准备活动和测试执行活动清晰的体现出来。测试流程和其他工作流程是并发执行的，只要某一个工作流程的条件成熟就可以开始进行测试。

• 优点：

  • 开发的H模型揭示了软件测试除测试执行外，还有很多工作；
  • 软件测试完全独立，贯穿整个生命周期，且与其他流程并发进行；
  • 软件测试活动可以尽早准备、尽早执行，具有很强的灵活性；
  • 软件测试可以根据被测物的不同而分层次、分阶段、分次序的执行，同时也是可以被迭代的。

• 缺点：

  • 管理型要求高：由于模型很灵活，必须要定义清晰的规则和管理制度，否则测试过程将非常难以管理和控制；
  • 技能要求高：H模型要求能够很好的定义每个迭代的规模，不能太大也不能太小；
  • 测试就绪点分析困难：测试很多的时候，你并不知道测试准备到什么时候是合适的，就绪点在哪里，就绪点的标准是什么，这就对后续的测试执行的启动带来很大困难；
  • 对于整个项目组的人员要求非常高：在很好的规范制度下，大家都能高效的工作，否则容易混乱。例如：你分了一个小的迭代，但是因为人员技能不足，使得无法有效完成，那么整个项目就会受到很大的干扰。

H模型流程图如下：

（4）X模型

• 设计原理：X模型的设计原理是将程序分成多个片段反复迭代测试，然后将多个片段集成再进行迭代测试。
• 优点：对单独程序片段进行的相互分离的编码和测试，保证了测试效果。增加了探索测试，可以帮助测试人员发现计划之外的软件错误。
• 缺点：频繁的集成会增加测试成本；探索测试对测试人员要求更高。

X模型流程图如下：

经验小结：

• v模型适用于中小企业，w模型适用于中大型企业（因为人员要求高），h模型人员要求非常高，很少有公司使用；
• 结合W模型与H模型进行工作，软件各方面的测试内容是以W模型为准，而测试周期、测试计划和进度是以H模型为指导。X模型更多是作为最终测试、熟练性测试的模板，例如，对一个业务的测试已经有2年时间，则可以使用X模型进行模块化的、探索性的方向测试。

五、 软件测试的原则

1、软件测试的原则

（1）测试应基于客户需求

所有的测试工作都应该建立在满足客户需求的基础上，从客户角度来看，最严重的错误就是软件无法满足要求。有时候，软件产品的测试结果非常完美，但却不是客户最终想要的产品，那么软件产品的开发就是失败的，而测试工作也是没有任何意义的。因此测试应依照客户的需求配置环境并且按照客户的使用习惯进行测试并评价结果。

（2）测试要尽早进行和不断进行

软件的错误存在于软件生命周期的各个阶段，因此应该尽早开展测试工作，把软件测试贯穿到软件生命周期的各个阶段中，这样测试人员能够尽早地发现和预防错误，降低错误修复的成本。尽早的开展测试工作有利于帮助测试人员了解软件产品的需求和设计，从而预测测试的难度和风险，制定出完善的计划和方案，提高测试的效率。

（3）穷举测试是不可能的

由于时间和资源的限制，进行完全（各种输入和输出的全部组合）的测试是不可能的，测试人员可以根据测试的风险和优先级等确定测试的关注点，从而控制测试的工作量，在测试成本、风险和收益之间求得平衡。

（4）遵循GoodEnough原则

GoodEnough原则是指测试的投入与产出要适当权衡，形成充分的质量评估过程，这个过程建立在测试花费的代价之上。测试不充分无法保证软件产品的质量，但测试投入过多会造成资源的浪费。随着测试资源投入的增加，测试的产出也是增加的，但当投入达到一定的比例后，测试的效果就不会明显增强了。因此在测试时要根据实际要求和产品质量考虑测试的投入，最好使测试投入与产出达到一个GoodEnough状态。

（5）测试缺陷要符合“二八”定理

一般情况下，软件80%的缺陷会集中在20%的模块中，缺陷并不是平均分布的。因此在测试时，要抓住主要矛盾，如果发现某些模块比其他模块具有更多的缺陷，则要投入更多的人力、精力重点测试这些模块以提高测试效率。

（6）避免缺陷免疫

测试用例被反复使用，发现缺陷的能力就会越来越差；测试人员对软件越熟悉越会忽略一些看起来比较小的问题，发现缺陷的能力也越差，这种现象被称为软件测试的“杀虫剂”现象。它主要是由于测试人员没有及时更新测试用例或者是对测试用例和测试对象过于熟悉，形成了思维定势。

六、 软件测试的流程

1、软件测试的基本流程

不同类型的软件产品测试的方式和重点不一样，测试流程也会不一样。同样类型的软件产品，不同的公司所制定的测试流程也会不一样。虽然不同软件的详细测试步骤不同，但它们所遵循的最基本的测试流程是一样的。

（1）分析测试需求

测试人员在制定测试计划之前需要先对软件需求进行分析，以便对要开发的软件产品有一个清晰的认识，从而明确测试对象及测试工作的范围和测试重点。在分析需求时还可以获取一些测试数据，作为测试计划的基本依据，为后续的测试打好基础。

此外，分析测试需求也是对软件需求进行测试，以发现软件需求中不合理的地方。

序号	检查项	检查结果	说明
1	是否覆盖了客户提出的所有需求项	是【】否【】NA【】
2	用词是否清晰、语义是否存在歧义	是【】否【】NA【】
3	是否清楚地描述了软件需要做什么以及不做什么	是【】否【】NA【】
4	是否描述了软件的目标环境，包括软硬件环境	是【】否【】NA【】
5	是否对需求项进行了合理的编号	是【】否【】NA【】
6	需求项是否前后一致、彼此不冲突	是【】否【】NA【】
7	是否清楚地说明了软件的每个输入、输出格式，以及输入与输出之间的对应关系	是【】否【】NA【】
8	是否清晰地描述了软件系统的性能要求	是【】否【】NA【】
9	需求的优先级是否合理分配	是【】否【】NA【】
10	是否描述了各种约束条件	是【】否【】NA【】

被确定的测试需求必须是可核实的，测试需求必须有一个可观察、可评测的结果。无法核实的需求就不是测试需求。测试需求分析还要与客户进行交流，以澄清某些混淆，确保测试人员与客户尽早地对项目达成共识。

（2）制定测试计划

测试计划一般要做好以下工作安排。

• 确定测试范围：明确哪些对象是需要测试的，哪些对象不是需要测试的。
• 制定测试策略：测试策略是测试计划中最重要的部分，它将要测试的内容划分出不同的优先级，并确定测试重点。根据测试模块的特点和测试类型（如功能测试、性能测试）选定测试环境和测试方法（如人工测试、自动化测试）。
• 安排测试资源：通过对测试难度、时间、工作量等因素对测试资源合理安排，包括人员分配、工具配置等。
• 安排测试进度：根据软件开发计划、产品的整体计划来安排测试工作的进度，同时还要考虑各部分工作的变化。在安排工作进度时，最好在各项测试工作之间预留一个缓冲时间以应对计划变更。
• 预估测试风险：罗列出测试工作过程中可能会出现的不确定因素，并制定应对策略。

（3）设计测试用例

• 测试用例（Test Case）指的是一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。不同的公司会有不同的测试用例模板，虽然它们在风格和样式上有所不同，但本质上是一样的，都包括了测试用例的基本要素。
• 测试用例编写的原则是尽量以最少的测试用例达到最大测试覆盖率。

（4）执行测试

• 测试执行就是按照测试用例执行测试的过程，这是测试人员最主要的活动阶段。
• 在执行测试时要根据测试用例的优先级进行。
• 在执行测试过程中，测试人员要密切跟踪测试过程，记录缺陷、形成报告等，这一阶段是测试人员最重要的工作阶段。

（5）编写测试报告

一份完整的测试报告必须要包含以下几个要点。

• 引言：测试报告编写目的、报告中出现的专业术语解释及参考资料等。
• 测试概要：介绍项目背景、测试时间、测试地点及测试人员等信息。
• 测试内容及执行情况：描述本次测试模块的版本、测试类型，使用的测试用例设计方法及测试通过覆盖率，依据测试的通过情况提供对测试执行过程的评估结论，并给出测试执行活动的改进建议，以供后续测试执行活动借鉴参考。
• 缺陷统计与分析：统计本次测试所发现的缺陷数目、类型等，分析缺陷产生的原因给出规避措施等建议，同时还要记录残留缺陷与未解决问题。
• 测试结论与建议：从需求符合度、功能正确性、性能指标等多个维度对版本质量进行总体评价，给出具体明确的结论。

总结：测试报告的数据是真实的，每一条结论的得出都要有评价依据，不能是主观臆断的。

七、结束语

下一篇文章讲解黑盒测试和测试用例的基础知识。

关于软件测试的基础知识就讲到这里啦！如有不明白或有误的地方欢迎评论区评论或私信我交流~

• 关注公众号 星期一研究室 ，不定期分享学习干货，学习路上不迷路~
• 如果这篇文章对你有用，记得点个赞加个关注再走哦~