深入了解软件测试：目的、定义与发展

菏泽炫佑科技

深入了解软件测试：目的、定义与发展

1.2 什么是软件测试？

在规定条件下运行程序以发现错误和评估软件质量的过程。

1.3 软件测试的目的

其目标是用*少的人力、物力和时间找出软件中潜在的错误和缺陷，通过纠正各类错误和缺陷来提高软件质量，避免软件发布后由于潜在的软件缺陷和错误而带来的安全隐患和商业风险。

注意：不要与软件测试的定义混淆

1.4 软件测试的定义

使用手动或自动方式运行或测试系统以验证其是否满足指定要求或识别预期结果和实际结果之间的差异的过程。

2.软件开发过程模型

软件开发模型是指整个软件开发过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段，有时还包括维护。软件开发模型可以清晰直观地表达整个软件开发过程，明确定义要完成的主要活动和任务，并作为软件项目工作的依据。对于不同的软件系统，可以采用不同的开发方法，使用不同的编程语言，让具有不同技能的人员参与工作，使用不同的管理方法和手段，允许使用不同的软件工具和不同的软件工程环境。

软件开发过程模型是软件开发人员在公司中工作的流程。

常见的软件开发过程模型

2.1 瀑布模型

1970年，温斯顿·罗伊斯提出了著名的“瀑布模型”，该模型直到20世纪80年代初才被广泛采用的软件开发模型。

瀑布模型将软件生命周期划分为规划、需求分析、系统设计、程序编写、软件测试、运行维护六个基本活动，并规定了从上到下相互衔接的固定顺序，犹如瀑布上的水流一步步流下。

2.1.1 核心思想

瀑布模型的核心思想

瀑布模型中，每个软件开发活动都严格按照线性方式进行，当前活动接受上一个活动的工作结果，并实施所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则将该结果作为下一个活动的输入，继续下一个活动，否则返回进行修改。

2.1.2 状态

瀑布模型是*早的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。

2.1.3 优点和缺点

优势：

 1. 为项目提供了按阶段划分的检查点,软件开发的每个阶段都很清晰明了
 2. 当前阶段完成后,只要去关注后续阶段
 3. 可在迭代模型中每轮迭代很类似于一个小的瀑布模型
 4. 它提供了一个模版,这个模版使得分析、设计、编码、测试可以在改模版下有一个共同的指导

缺点：

各个阶段的划分完全固定，阶段之间会产生大量的文档，大大增加了工作量。由于开发模式是线性的，用户只能在整个过程的*后才能看到开发结果，增加了开发风险。突出的缺点是不能适应用户需求的变化。软件的实际情况只能在项目开发的后期才能被客户看到，这需要客户有足够的耐心。2.1.4 使用范围2.2.快速原型模型

快速原型模型的**步是构建快速原型，使客户或未来用户能够与系统进行交互。用户或客户对原型进行评估，进一步细化所要开发软件的需求。通过逐步调整原型以满足客户的要求，开发人员可以确定客户真正的需求是什么；第二步是在**步的基础上开发出让客户满意的软件产品。

2.2.1 核心思想

快速原型是利用原型辅助软件开发的一种新思路，通过简单快速的分析，快速实现原型。用户与开发人员在试用原型过程中加强沟通与反馈，通过反复评估、改进原型，减少误解、弥补漏洞、适应变化，*终提高软件质量。

2.2.2 优点和缺点

优势：

克服瀑布模型的缺点，适应需求变化，开发出更能满足用户需求的产品

缺点：

2.2.3 使用范围 2.3. 增量模型

2.3.1 简介

增量模型又称递增模型，它将要开发的软件系统模块化，把每个模块看成一个增量组件，这样就可以对这些增量组件进行批量的分析、设计、编码和测试。采用增量模型的软件开发过程是一个增量的过程。与瀑布模型相比，采用增量模型进行开发时，开发人员不需要一次性将整个软件产品提交给用户，而是可以分批提交。

2.3.2 基本思想

增量模式并不是在每个阶段都交付一个完整的可操作产品，而是交付一个满足客户需求子集的可操作产品。整个产品被分解成若干个组件，开发人员逐个组件地交付产品。这样做的好处是软件开发能够更好地适应变化，客户可以持续看到开发出来的软件，从而降低开发风险。

2.3.3 优点和缺点

优势

缺点

2.3.4 使用场景* 2.4. 螺旋模型

1988年，巴里·伯姆（Barry Boehm）正式发表了软件系统开发的“螺旋模型”，该模型融合了瀑布模型与快速原型模型，强调了其他模型所忽视的风险分析，特别适用于大型复杂系统。

如图所示，螺旋模型沿着螺旋线经过多次迭代，图中四个象限代表以下活动：

（1）制定计划：确定软件目标，选择实施方案，明确项目开发的约束条件；

（2）风险分析：对所选定的方案进行分析和评估，考虑如何识别和消除风险；

（3）实施工程：实施软件开发与验证；

（4）客户评估：评估开发工作，提出修正建议，制定下一步措施。

螺旋模型以风险为驱动，强调支持软件重用的选项和约束，并有助于将软件质量作为特殊目标纳入产品开发中。

2.4.1 优点和缺点

优势：

缺点：

2.4.2 使用场景

适用于大型软件项目

3. 测试模型

软件测试与软件开发一样，遵循软件工程和管理的原则深入了解软件测试：目的、定义与发展，因此了解软件开发模型将有助于理解测试模型。

软件测试的一般流程：

我们发现一般的软件测试流程和软件开发流程是一样的，但是这样的流程测试介入比较晚自动化软件开发，前期修复重大的Bug比较困难，因此对测试流程进行了总结，归纳出以下几种常用的测试模型：

3.1 V 模型

3.1.1 简介

V模型和瀑布模型有一些共同的特点，V模型中的流程从左到右，描述了基本的开发流程和测试行为。

单元测试：是模块测试，验证软件基本组件的正确性，属于白盒测试。

集成测试：是模块之间的测试，测试接口（软件模块之间的接口、软件与硬件之间的接口）是否正确，是灰盒测试（白盒和黑盒的结合）

系统测试：系统测试包括：冒烟测试系统测试回归测试

验收测试：是为了确保软件实施能够满足用户的需求或合同要求

3.1.2 优点和缺点

优势：

缺点：

3.2. W 模型 3.2.1 简介

V模型的局限性在于没有明确阐述早期测试，不能体现“早期、持续”的软件测试原则。在V模型的基础上添加了软件开发各个阶段应同时进行的测试，就演化为W模型（如下图）。在模型中不难看出，开发是“V”，测试是并行的“V”。

W模型是V模型的发展，强调测试伴随整个软件开发周期，测试对象不仅仅是程序，还有需求、功能和设计。测试与开发同时进行，有利于尽早发现问题。

3.2.2 优点和缺点

优势

缺点

3.3. H模型 3.3.1 简介

在H模型中，软件测试过程活动完全独立，并贯穿整个产品周期，与其他过程同时进行。当一个测试点准备好后，就可以从测试准备阶段进入测试执行阶段。软件测试可以尽早进行，并可根据测试对象的不同，分层次进行。

3.3.2 优点和缺点

优势：

缺点：

3.4 总结

在实际工作中，应灵活运用各种模型的优点。

V模型：强调了整个软件项目开发过程中需要经历的几个测试层次，并与各个开发级别相对应；忽略了测试对象不应该只包括程序，没有明确指出需求和设计的测试。

W模型：补充了V模型省略的内容，强调测试规划、系统需求和系统设计的测试等前期工作；与V模型一样，它没有说明软件测试的过程

H模型：强调测试是独立的，只要测试准备完成就可以执行。

4.软件测试分类

从上图中我们可以看出，软件测试根据不同的分类条件会有不同的结果。

4.1. 按阶段划分 4.1.1 单元测试（Unit）

单元测试是对软件组件的测试，其目的是验证软件基本组件的正确性，测试的对象是软件设计的*小单元：模块。

4.1.2 集成测试

集成测试又称联合测试或装配测试，采用适当的集成策略组装程序模块，测试系统接口和集成功能的正确性，主要目的是检查软件单元之间的接口是否正确。

补充说明：单元测试是在模块内进行测试，而集成测试是在模块之间进行测试（至少两个）

4.1.3 系统测试（）

将软件系统视为系统测试。这包括测试软件的功能、性能以及运行的硬件和软件环境。大部分时间都花在系统测试执行阶段，包括回归测试和冒烟测试。

补充说明：（1）系统测试是从整体的角度看待问题，而不仅仅是模块本身。（2）系统测试虽然包括冒烟测试和回归测试，但是三者之间有严格的顺序，即：先冒烟测试，再系统测试，*后回归测试。

4.2. 按是否覆盖源代码分类 4.2.1 黑盒测试

黑盒测试又叫功能测试，在测试中把被测软件当做一个黑盒子，盒子内部结构并不重要，只关心软件的输入输出数据。黑盒测试又分为功能测试和性能测试。

4.2.2 白盒测试

白盒测试又称为结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒是指打开盒子来研究里面的源代码和程序结果。

白盒测试也是一种接口测试

4.2.3 灰盒测试

灰盒测试是介于白盒测试和黑盒测试之间的一种测试类型，灰盒测试多用于集成测试阶段，它不仅关注输出和输入的正确性，还关注程序内部的情况。

灰盒测试：功能+接口

4.3. 按程序是否执行分类 4.3.1 静态测试（ ）

静态方法是指在不运行程序本身的情况下，通过分析或检查源程序的语法、结构、流程、接口等来检查程序的正确性。对需求规范、软件设计规范和源程序进行结构分析、流程图分析和符号执行，以查找错误。Awang 的分析如下

静态测试：代码静态分析和文档测试都属于静态测试

4.3.2 动态试验（ ）

动态测试是运行被测程序，检查运行结果与预期结果的差异，分析运行效率、正确性和健壮性等性能。该方法由构造测试用例、执行程序、分析程序输出结果三部分组成。

(1)动态测试由构造测试用例、执行程序、分析程序的输出结果三部分组成。 (2)大多数软件测试都是动态测试。

4.4. 根据是否自动化 4.4.1 手动测试（ ）

手工测试是一个比较原始但必要的步骤，由人逐个输入测试用例，然后观察结果，与机器测试相对应。Awang 总结了机器测试的优点和缺点：

4.4.2 自动化测试（）

就是在预先设定的条件下运行系统或应用程序，并评估运行结果。预先设定的条件应该包括正常情况和异常情况。简单来说，自动化测试就是将人驱动的测试行为转化为机器执行的过程。

自动化实施步骤：

（1）功能测试完成，版本基本稳定

（2）选择适合项目的自动化工具，根据项目特点搭建环境

（3）从手工测试中提取测试用例，转化为自动化测试的测试用例

（4）利用工具和代码实现输入构造的自动化，并自动检测输出结果是否符合预期

（5）生成自动测试报告

（6）持续改进和脚本优化

4.5. 其他 4.5.1 烟雾测试

该术语来自硬件，指对一个或一组硬件进行更改或维修后，直接通电启动设备的过程。如果没有烟雾，则表示该部件通过了测试，也可以理解为一个简短的测试，只需要一包香烟就可以了。

冒烟测试的目的是确认软件基本功能正常，可以进行后续的正式测试。冒烟测试的执行者是版本编译者。冒烟测试通常是在开发人员完成开发并交给测试人员测试后进行的。测试人员会先进行冒烟测试，确保基本功能正常，不会妨碍后续的测试。

4.5.2 回归测试

回归测试是指修改旧代码后重新进行测试，确认修改没有引入新的错误或者导致其他代码出错。自动化的回归测试将大大降低系统测试、维护和升级的成本。

回归测试在整个软件测试过程中占有很大比重，软件开发的每个阶段都要进行多次回归测试。随着系统越来越大，回归测试的成本也越来越大。通过正确的回归测试策略来提高回归测试的效率和效果是非常有意义的。

4.5.3 随机测试

随机测试主要根据测试人员的经验抽查软件的功能和性能。

它是按照测试规范进行用例测试的重要补充手段，是保证测试覆盖完整性的有效方法和过程。

随机测试主要对被测软件的一些重要功能进行重新测试，同时也包括测试当前测试用例没有覆盖到的部分。

4.5.4 验收测试

验收测试是软件部署前的*后一个测试操作，又称交付测试。验收测试的目的是确保软件已经准备就绪，并向软件购买者表明软件系统符合双方商定的项目合同、任务书和验收依据文件规定的原要求。

验收测试根据实施组织不同，分为 alpha 测试和 beta 测试。

Alpha 测试

Beta 测试

alpha测试和beta测试的区别：

5. 基本原则和程序 5.1 基本原则

由于软件测试的目的是发现软件的错误和缺陷，从而评估和改进软件质量，因此，在测试软件时必须遵循一定的原则：

5.1.1. 所有测试都应追溯到用户需求

众所周知，软件测试的目标是验证产品的一致性，确认产品是否满足客户需求。因此，测试人员必须始终站在用户的角度看待问题，判断软件缺陷的影响。系统中*严重的错误是那些导致程序无法满足用户需求的错误。

5.1.2. 测试人员应以“尽早测试，经常测试”为座右铭

需求模型完成后就要开始制定测试计划，需求模型确定后也可以马上开始进行详细的测试用例定义，因此在代码生成之前就应该做好测试的计划和设计。

5.1.3. 原则（80/20 规则）：80% 的错误发生在 20% 的模块中

当某个功能出现问题时，评估其对用户的影响程度，然后根据影响大小确定测试的优先级，优先级高的测试优先进行测试。

一般来说，用户*常使用的20%功能（*高优先级）的测试会被充分执行，而低优先级的测试（另外80%用户很少使用的功能）则不需要。如果没有足够的时间和金钱，它们就不会做或会少做。

5.1.4. 无法进行详尽的测试

测试无法揭示软件中的潜在缺陷。测试只能证明存在错误或缺陷，但不能证明软件没有错误。由于中等规模的程序的路径排列数也非常大，因此不可能在测试中运行每种路径组合。但是，可以完全覆盖程序逻辑并确保满足程序使用的所有条件。

5.1.5. 第三方测试更客观

程序员应避免自己测试自己的程序，为了达到*佳效果，*好交由第三方测试。测试是一种“挑剔”的行为，心理状态是测试自己程序的障碍。同时，对需求规范理解上的错误在程序员自我测试时很难被发现。我们要做“经得起考验、经得起考验的产品”。

5.1.6. 测试用例是设计的，不是写出来的

测试用例是根据测试的目的而设计的，采用相应的方法，以提高测试的效率，发现更多的错误，提高程序的可靠性。除了检查程序是否做了应该做的事情，还要检查程序是否做了不该做的事情；不仅要选择合理的输入数据，还要针对非法输入设计测试用例。要知道，好的测试用例才是真正有效的，事半功倍。

5.1.7. 不要忽视测试用例，消除随意性

特别是在对修改后的程序进行重新测试时，如果不严格按照测试用例进行，可能会忽略大量由修改后的错误而产生的新错误。因此，回归测试的相关性也应得到充分重视，因为相当一部分*后发现的错误在早期的测试结果中被遗漏了。其他所有工作都应避免随意性。

5.1.8. 整个生命周期的测试

由于软件的复杂性和抽象性，在软件生命周期的各个阶段都可能出现错误。测试的准备和设计必须在编码之前开始。同时，为了保证*终的质量，在开发过程的每个阶段都必须保证过程产品的质量。因此，软件测试不应该被看作仅仅是软件开发完成后的一个独立的工作阶段。测试应该贯穿整个生命周期。软件项目一上线就应该参与软件测试，而不是等到软件开发完成后才开始。项目上线后，测试人员应该参与到每个阶段相应的活动中。换句话说，在每个开发阶段，测试都应该检查和验证该阶段的输出。例如，在需求阶段，测试人员需要参与需求文档的评审。

5.1.9. 对于错误较多的程序片段，应进行更深入的测试。

一般来说，程序中发现的错误越多，说明程序中存在错误的概率越大，需要进行更深入、更重复的测试。

5.1.10. 所有文件应妥善保存，以备日后重复使用 5.2 基本流程

需求分析阶段：

测试计划阶段：

测试设计阶段：

测试执行阶段：

评估阶段：

炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等