软件测试基础理论（一）

---

前言

最后编辑时间为2024-06-03，阅读本文前请注意最后编辑时间，文章内容可能与目前最新的技术发展情况相去甚远。欢迎各位评论与私信，指出错误或是进行交流等。

---

一、软件

1.软件的定义

软件，是一系列按照特定顺序组织的计算机数据和指令的集合。

2.软件生命周期

软件的生命周期（Software Lifecycle）指的是软件从计划、需求分析、设计、编码、测试、部署、维护到最终废弃或替换的完整过程。这个过程可以被视为软件的“生命”，因为它经历了从诞生到消亡的完整循环，其主要的阶段、工作人员、主要任务以及输出内容如下所示。

阶段	主要人员	主要任务	输出内容
计划	项目经理	指定整个项目的计划（目标、人员、预算）	项目计划书
需求分析	产品经理、需求分析人员	进一步确定用户的需求、描述软件的具体功能	需求规格说明书（SRS）、产品需求文档（PRD）
设计	系统架构师、高级开发人员	系统架构师：系统–>子系统–>模块–>函数 高级开发人员：对函数的实现进行详细设计	软件系统概要设计、详细设计
编码	开发人员	根据详细设计完成软件的编码和调试	代码和程序
测试	测试人员	对代码和程序进行测试 检查实际结果和预期结果是否一致 检查需求和设计是否有遗漏	测试报告
运维	运维人员	安装、部署和升级软件，问题排查、技术支持	运维报告

3.软件开发过程

软件开发过程，软件产品从最初构思到公开发行的过程。
开发过程有各种不同的方法，没有所谓最好的模式。
常见的软件开发过程模型有：

3.1.瀑布模型

瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落

优点：
为项目提供了按阶段划分的检查点
当前一阶段完成后，只需要去关注后续阶段

缺点：
不适合需求模糊或需求经常变动的系统
用户可能需要等待较长时间来获得一个可供使用的系统，也许会给用户的信任程度带来影响和打击

3.2.快速原型模型

快速原型模型的第一步是建造一个快速原型，实现用户与系统的交互，用户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足用户的要求。

优点：
克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险。
适合预先不能确切定义需求的软件系统的开发。
允许用户早期看到产品的初步效果，增加用户对产品的信任度

缺点：
快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。

3.3.增量模型

增量模型是把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。运用增量模型的软件开发过程是递增式的过程。相对于瀑布模型而言，采用增量模型进行开发，开发人员不需要一次性地把整个软件产品提交给用户，而是可以分批次进行提交。

优点
将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展
以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统。
开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时，还能及时地对实现顺序进行调整。

缺点
要求待开发的软件能进行增量式的开发

3.4.螺旋模型

螺旋模型是由巴利·玻姆（Barry Boehm）在1988年正式发表的软件系统开发模型。它是一种周期性的系统开发方法，通过多次迭代来逐步推进软件开发过程。每一次迭代都包括需求定义、风险分析、工程实现和评审四个主要阶段。

优点:
设计灵活，可以在项目各个阶段进行变更
风险驱动,每个项目上线前都要进行风险分析

缺点:
螺旋模型强调风险分析,需要相当丰富的风险评估经验和专业知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失；
如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，

二、软件测试

1.软件测试的定义

通过人工或者自动化的手段执行某个程序或者运行某个系统的过程。

2.软件测试的目的

（1）验证软件是否满足软件开发计划、项目开发计划、系统/子系统设计文档、软件需求规格说明、软件产品说明等规定的要求
（2）通过测试，发现软件缺陷
（3）为软件产品的质量度量和评价提供依据

3.软件缺陷定义及分类

软件缺陷，通常也被称为Bug，是指计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。
软件缺陷可以分为多种类型：
遗漏：做少了，指规定或预期的需求未体现在产品中。
错误：做错了，指需求是明确的，但在实现阶段未将需求的功能正确实现。
冗余：做多了，指需求说明文档中未涉及的需求被实现了。
不满意：用户对产品的实现不满意也称为缺陷。

4.软件缺陷的等级

不同的企业对软件缺陷等级的划分大同小异，大致可分为5个等级：
1.致命：指造成系统或应用程序死机、崩溃、非法退出等问题，会导致用户数据丢失或被破坏，功能设计与需求严重不符。
2.严重：指功能和特性没有实现，导致模块功能失效或异常退出，还有程序接口错误或者数据流错误等问题。
3.一般：指主要功能丧失，提示信息不太正确，用户界面设计太差以及删除未提示等问题。
4.提示：指对功能几户没有影响，产品及属性仍可使用的问题。
5.建议：测试人员提出的建议、质疑等问题。

5.软件测试的对象

（1）源程序/目标代码
（2）各开发阶段的文档（需求规格说明、概要设计说明、详细设计说明及其它相关文档）
（3）数据

6.软件测试的原则

1）所有测试的都应以软件设计需求规格说明书为标准进行。
2）应尽早地不断地进行软件测试
3）程序员应避免检查自己的程序。
4）充分注意测试中的群集现象。
5）严格执行测试计划，排除测试的随意性。
6）妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便。
7）完全测试是不可能的

7.软件测试的分类

软件测试的分类方式有很多种：按照是否能查看代码分为黑盒测试、白盒测试、灰盒测试。

1.黑盒测试，又叫功能测试、数据驱动测试或基于需求规格说明书的功能测试。该类测试注重于测试软件的功能性需求。

采用这种测试方法，测试工程师把测试对象看作一个黑盒子，完全不考虑程序内部的逻辑结构和内部特性，只依据程序的《需求规格说明书》，检查程序的功能是否符合它的功能说明。测试工程师无需了解程序代码的内部构造，完全模拟软件产品的最终用户使用该软件，检查软件产品是否达到了用户的需求。黑盒测试方法能更好、更真实地从用户角度来考察被测系统的功能性需求实现情况。

2.白盒测试，指的是把盒子打开，测试人员可以查看并了解被测软件内部的逻辑结构、设计、接口、实现以及程序运行的状态。

白盒测试的方法主要包括：

2.1. 代码检查法：
通过对源代码进行逐行检查，寻找并纠正编程错误、不遵守编程规范的地方以及可能存在的逻辑错误。

2.2 静态结构分析法：
无需执行程序，通过分析程序的控制流、数据流等结构信息，检查程序是否满足设计要求，是否存在潜在缺陷。

2.3 静态质量度量法：
使用一定的度量标准，如代码行数、复杂度等，对软件的质量进行评估，从而判断软件是否满足质量要求。

2.4 逻辑覆盖法：
逻辑覆盖是白盒测试的核心方法，它包含以下几种覆盖标准：
2.4.1 语句覆盖：确保每个可执行语句至少被执行一次。
2.4.2 判定覆盖：确保每个判定的每个分支（真和假）至少被执行一次。
2.4.3 条件覆盖：确保每个判定中的每个条件至少取到一次真值和一次假值。
2.4.4 判定/条件覆盖：同时满足判定覆盖和条件覆盖。
2.4.5 条件组合覆盖：确保每个判定中各条件的每一种组合至少出现一次。
2.4.6 修改条件判断覆盖：确保每个判断的所有可能结果都出现过，每个判断中所有条件的所有可能结果都出现过，每个进入点及结束点都执行过，判断中每一个条件都可以独立地影响判断的结果。

2.3 基本路径测试法：
根据程序的控制流图，设计测试用例，确保程序中的每一条独立路径都至少被执行一次。

2.4 域测试：
根据输入参数的取值范围或等价类，设计测试用例，测试程序在不同输入参数下的表现。

2.5 符号测试：
使用符号执行技术，通过为程序中的变量和表达式赋予符号值，模拟程序的执行过程，从而发现可能的错误。

2.6 路径覆盖：
确保程序中的每一条路径都至少被执行一次，这通常与基本路径测试法结合使用。

2.7 程序变异：
通过人为地引入错误（变异）到程序中，然后运行测试用例来检测这些错误是否能被发现，从而评估测试用例的有效性和充分性。

3.灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。