Appearance
测试原则
软件测试是使用，其目的在于检验它是否。
软件测试的目的就是，所以软件测试工作主要是发现软件的错误、有效定义和实现软件成分由低层到高层的组装过程、验证软件是否满足任务书和系统定义文档所规定的技术要求、为软件质量模型的建立提供依据。
测试是为了发现错误而执行程序的过程，成功的测试是发现了至今尚未发现的错误的测试。
核心原则：
- 应尽早并不断进行测试
- 测试工作应避免由原开发软件的人或小组承担
- 设计测试方案时，要确定输入数据和预期的输出结果
- 既包含有效合理的用例，也包含不合理失效的用例
- 检验程序是否做了该做的事，且是否做了不该做的事
- 严格按照测试计划进行，妥善保存测试计划和测试用例
- 测试用例可以重复使用或追加测试
测试方法分类 ⭐️
测试方法的分类
- 测试过程中程序执行状态：。
- 具体实现算法细节和系统内部结构的相关情况为根据可分。
- 程序执行方式：（自动化执行测试脚本）。
静态测试
(1)静态测试：静态测试是被测程序不运行，。即通过对软件的需求规格说明书、设计说明书以及源程序做结构分析和流程图分析，从而来找出错误。例如不匹配的参数，未定义的变量等，其方法包括：
- 桌前检查：，在程序编译后，单元测试前。
- 代码审查：，通过召开程序评审会来进行审查。
- 代码走查：也是采用开会来对代码进行审查，但并非简单的检查代码，而是，手动运行测试用例，检查代码逻辑。
动态测试
（2)动态测试：通过运行被测试程序，对得到的等。这种方法可简单分为3步骤构造测试实例、执行程序以及分析结果。
动态测试是通过运行程序发现错误，包括与白盒测试（各种类型的覆盖测试）。
静态测试是人工测试方式，包括桌前检查（桌面检查）、代码走查、代码审查。
软件测试方法的分类有很多种，以测试过程中程序执行状态为依据可分为静态测试(Static Testing,ST)和动态测试(Dynamic Testing,DT); 从程序执行的方式来分类，可分为人工测试(Manual Testing,MT)和自动化测试(Automatic Testing,AT)。
黑盒测试
(3)黑盒测试法：黑盒测试将，根据需求规格说明书设计测试实例，并检查程序的功能是否能够按照规范说明准确无误的运行。其主要是对软件界面和软件功能进行测试。对于黑盒测试行为必须加以量化才能够有效的保证软件的质量。
白盒测试
(4)白盒测试法：白盒测试主要是。白盒测试是从程序结构方面出发对测试用例进行设计。主要用于检查各个逻辑结构是否合理，对应的模块独立路径是否正常以及内部结构是否有效。常用的白盒测试法有 根据测试用例的覆盖程度，分为等。
灰盒测试
(5)灰盒测试法：灰盒。灰盒测试除了性，也看重其内部的程序逻辑。但是，它不可能像白盒测试那样详细和完整。它只是简单地靠一些象征性的现象或标志来判断其内部的运行情况，因此在内部结果出现错误，但输出结果正确的情况下可以采取灰盒测试方法。因为在此情况下灰盒比白盒高效，比黑盒适用性广的优势就凸显出来了。
自动化测试
(6)自动化测试。自动化测试就是，即在预先设定的条件下自动运行被测程序，井分析运行结果。总的来说，这种测试方法就是将以人驱动的测试行为转化为机器执行的一种过程。
单元测试
(1)单元测试：也称为，测试的对象是可独立编译或汇编的程序模块、软件构件或OO软件中的类（统称为模块），测试依据是软件详细设计说明书。主要是对该软件的模块进行测试，通过测试以发现该模块的功能不符合/不满足期望的情况和编码错误。
- 由于模块的规模不大，功能单一，结构较简单，且测试人员可通过阅读源程序清楚知道其逻辑结构，，比如静态分析、代码审查等，对该模块的源程序进行分析，按照模块的程序设计的控制流程图，以满足软件覆盖率要求的逻辑测试要求。另外，也可采用黑盒测试方法提出一组基本的测试用例，再用白盒测试方法进行验证。若用黑盒测试方法所产生的测试用例满足不了软件的覆盖要求，可采用白盒法增补出新的测试用例，以满足所需的覆盖标准。其所需的覆盖标准应视模块的实际具体情况而定。对一些质量要求和可靠性要求较高的模块，一般要满足所需条件的组合覆盖或者路径覆盖标准。
集成测试
(2)集成测试：目的是，并验证已集成的软件是否符合设计要求。，集成测试通常要对已经严格按照程序设计要求和标准组装起来的模块同时进行测试，明确该程序结构组装的正确性，发现和接口有关的问题。在这一阶段，一般采用白盒测试和黑盒测试结合的方法进行测试，验证这一阶段设计的合理性以及需求功能的实现性。
集成测试可以分为，增量式组装测试效果更好。集成测试计划一般在概要设计阶段完成。
系统测试
(3)系统测试：一般情况下，系统测试采用黑盒测试，以此来检查该系统是否符合软件需求。本阶段的主要测试内容包括试、用户界面测试、压力测试、可靠性及安全性测试等。测试人员必须进行多轮回归测试。系统测试的结束标志是测试工作己满足测试目标所规定的需求覆盖率，并且测试所发现的缺陷都已全部归零。
性能测试
(4)性能测试：是通过。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。
验收测试
(5)验收测试，是最后一个阶段的测试，是软件产品投入正式交付前的测试工作。是要满足用户需求或者与用户签订的合同的各项要求，是由用户对要交付软件开展的一种测试工作。主要目标是为用户展示所开发出来的软件符合预定的要求和有关标准，并验证软件实际工作的有效性和可靠性，确保用户能用该软件顺利完成既定的任务和功能。
通过了验收测试，该产品就可进行发布。从用户的角度出发，测试人员还应进行Alpha测试或Beta测试。Alpha测试是在软件开发环境下由用户进行的测试。而Beta测试是在实际环境中由多个用户对其进行测试。
回归测试
(6)回归测试：测试目的是。
其他测试
(1)AB测试是为Web或App界面或流程制作两个或多个版本，在同一时间维度，分别让组成成分相同（相似)的访客群组（目标人群)随机的访问这些版本，收集各群组的用户体验数据和 业务数据，最后分析、评估出最好版本，正式采用。
(2)Web测试是软件测试的一部分，是针对Web应用的一类测试。由于Web应用与用户直接相关，又通常需要承受长时间的大量操作，因此Wb项目的功能和性能都必须经过可靠的验证。
(3)链接测试。链接是Wb应用系统的一个主要特征，它是在页面之间切换和指导用户去一些未知地址页面的主要手段。链接测试可分为3个方面。首先，测试所有链接是否按指示那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证b应用系统上没有孤立的页面。
(4)表单测试。当用户通过表单提交信息的时候，都希望表单能正常工作。如果使用表单来进行在线注册，要确保，当注册完成后应返回注册成功的消息。如果使用表单收集配送信息，应确保程序能够正确处理这些数据，最后能让用户收到信息。
| 对比维度 | 静态测试 | 动态测试 |
|---|---|---|
| 方式 | 被测程序不在机器上运行 | 实际运行程序 |
| 手段 | 人工检测 + 计算机辅助静态分析 | 白盒测试 + 黑盒测试 |
| 文档测试 | 以检查单形式进行 | — |
| 代码测试 | 桌前检查、代码审查、代码走查 | — |
| 效果 | 有效发现 30%-70% 逻辑设计和编码错误 | — |
- 测试方法的分类
黑盒测试 vs 白盒测试：
| 对比 | 黑盒测试 | 白盒测试 |
|---|---|---|
| 别名 | 功能性测试 | 结构性测试 |
| 特点 | 不了解代码结构 | 明确代码流程 |
| 依据 | 根据功能设计用例 | 根据代码逻辑设计用例 |
| 目标 | 测试软件功能 | 进行用例覆盖 |
测试阶段
| 阶段 | 测试对象 | 测试依据 | 目的 |
|---|---|---|---|
| 单元测试 | 可独立编译的模块/类 | 软件详细设计说明书 | 模块功能正确性 |
| 集成测试 | 模块间接口 | 软件概要设计文档 | 检查模块间接口关系 |
| 确认测试 | 完整软件 | SRS | 验证功能/性能与用户需求一致 |
| 系统测试 | 完整的集成计算机系统 | 用户需求/开发合同 | 验证与系统正确连接，满足设计要求 |
| 配置项测试 | 软件配置项 | SRS | 检验与 SRS 一致性 |
| 回归测试 | 变更后的软件 | — | 验证变更正确性+不影响原有功能 |
确认测试按用户参与程度：
软件确认测试一种针对需求的测试，是用户参与的测试。它主要验证软件功能、性能及其它特性是否与用户需求一致。
软件确认测试包括：。
| 类型 | 说明 |
|---|---|
| 内部确认测试 | 开发组织内部按 SRS 测试 |
| Alpha 测试 | 用户在开发环境下测试 |
| Beta 测试 | 用户在实际使用环境下测试，通过后交付 |
| 验收测试 | 交付前以用户为主的测试，依据 SRS/合同 |
系统测试最重要的工作是功能测试与性能测试。功能测试主要用黑盒测试，性能测试指标：响应时间、吞吐量、并发用户数、资源利用率。
其他测试
略
练习题
单元测试的依据是()
- A.概要设计
- B.需求分析
- C.详细设计
- D.用户需求
答案与解析
答案：C
以下( )不属于白盒测试
- A.控制流分析
- B.数据流分析
- C.程序变异测试
- D.功能测试
答案与解析
答案：D
解析：
- 白盒测试（又称结构测试）基于程序的内部逻辑结构，主要方法包括：控制流分析、数据流分析、程序变异测试（变异测试）、语句覆盖、分支覆盖、路径覆盖等。
- 控制流分析：分析程序的控制流图，属于白盒测试。
- 数据流分析：跟踪变量的定义和使用，属于白盒测试。
- 程序变异测试：通过修改程序产生变异体，检查测试用例能否发现差异，属于白盒测试。
- 功能测试（黑盒测试）基于需求规格，不考虑内部结构，因此不属于白盒测试。
要测试复杂程序逻辑应该选择()方法，()既考虑了功能需求，又考虑了内部结构
A.性能测试
B.黑盒测试
C.静态测试
D.压力测试
A.黑盒测试
B.白盒测试
C.灰盒测试
D静态测试
答案与解析
答案：C C
( )是为Web或App界面或流程制作两个或多个版本，在同一时间维度，分别让组成成分相同(相似)的访客群组（目标人群)随机的访问这些版本，收集各群组的用户体验数据和业务数据，最后分析、评估出最好版本，正式采用。
- A.web测试
- B.链接测试
- C.表单测试
- D.AB测试
答案与解析
答案：D
测试模型
W模型：W模型是对V模型的一个重要改进，充分体现了尽早开展测试的原则，并将 V模型中以发现缺陷为目标上升为保证软件质量为目标。W模型如图所示。
W模型实际上是两个 V 的叠加，一个V描述开发过程，另外一个V描述测试过程。但测试的起始时机不再是编码结束之后，而是从需求分析时开始，且与开发的每一个阶段活动同步进行。
H模型：改进了W和V模型高度依赖于开发的瀑布模型的缺陷，其特征如图所示：
- “模型把测试活动从软件开发过程中独立出来，在软件过程的任何一个时间点上，只要测试条件满足即开展测试。测试的流程与其他流程是并行的。H模型比W模型更好的地方是能够兼顾测试的效率和灵活性，适合于各种规模及类型的软件项目。
敏捷测试模型：敏捷测试源于敏捷开发。敏捷测试是敏捷开发的组成部分，需要与开发流程良好融合，其特征如图所示。
- 敏捷测试在整个敏捷开发过程中，需要与项目的其他人员甚至用户保持紧密协作，时刻关注需求变化并实施测试，以体现测试的时效性和适应性，这对测试人员有比较高的能力要求。
测试用例设计 ⭐️
黑盒测试用例
| 方法 | 说明 |
|---|---|
| 等价类划分 | 按特性归类，每类选取一个代表。有效等价类：尽可能多覆盖；无效等价类：每次仅覆盖一个 |
| 边界值划分 | 取范围两端值及范围外相邻值（如 0-150 → 0, 150, -1, 151） |
| 错误推测 | 凭经验推测可能出问题的地方 |
| 因果图 | 由结果反推原因 |
白盒测试用例（覆盖级别从低→高） TODO
| 级别 | 说明 |
|---|---|
| 语句覆盖 SC | 所有语句至少执行一遍，覆盖层级最低 |
| 判定覆盖 DC | 所有判断的真假分支都覆盖一次 |
| 条件覆盖 CC | 每个判断条件内的每个独立条件都执行一遍真和假 |
| 判定条件组合覆盖 CDC | 同时满足判定覆盖和条件覆盖 |
| 路径覆盖 | 所有可行路径都覆盖，覆盖层级最高 |
覆盖层级口诀：语句<判定<条件<判定条件组合<路径。
语句覆盖
语句覆盖是，使得运行这些测试用例时，被测程序的每个语句至少执行一次
我理解是这个节点都执行了一次，但是不是所有分支都执行到。
sacbed 节点。 
判定覆盖
至少分支都走了一下（但不是所有条件都走了）
判定覆盖也称为分支覆盖，它是指。
条件覆盖是指不仅每个语句至少执行一次，而且
条件/判定覆盖。盖。它的含义是，选取足够的测试用例，使得判定表达式中每个条件的所有可能结果至少出现一次，而且每个判定本身的所有可能结果也至少出现一次。 
路径覆盖。路径覆盖是指选取足够的测试用例，（
在白盒测试用例中，其中语句覆盖是最弱的覆盖准则，路径覆盖则最强
- (1)语句覆盖。语句覆盖是，使得运行这些测试用例时，被测程序的每个语句至少执行一次。很显然，语句覆盖是一种很弱的覆盖标准。
- (2)判定覆盖。判定覆盖也称为分支覆盖，它是指。判定覆盖比语句覆盖强，但对程序逻辑的覆盖程度仍然不高。
- (3)条件覆盖。条件覆盖是指不仅每个语句至少执行一次，而且。条件覆盖不一定包含判定覆盖，判定覆盖也不一定包含条件聚盖。
- (4)条件/判定覆盖。盖。它的含义是，选取足够的测试用例，使得判定表达式中每个条件的所有可能结果至少出现一次，而且每个判定本身的所有可能结果也至少出现一次。
- (⑤)路径覆盖。路径覆盖是指选取足够的测试用例，（如果程序中有环路，则要求每条环路路径至少经过一次）。路径覆盖实际上考虑了程序中各种判定结果的所有可能组合，因此是一种较强的覆盖标准。但路径覆盖并未考虑判定中的条件结果的组合，并不能代替条件覆盖和条件组合覆盖。
练习题
招聘系统要求求职的人年龄在20岁到60岁之间（含)，学历为本科、硕士或者博士，专业为计算机科学与技术、通信工程或者电子工程。其中（ )不是好的测试用例。
- A.(20,本科，电子工程)
- B.（18,本科，通信工程)
- C.(18,大专，电子工程)
- D.（25,硕士，生物学)
答案与解析
答案：C
正确答案是 C。
好的测试用例应尽量只包含一个无效条件，以便快速定位缺陷。
- A：所有条件均有效（边界值20岁），是有效测试用例。
- B：仅年龄无效（18<20），可测试年龄下限。
- C：年龄无效（18<20）且学历无效（大专不在本科/硕士/博士），多个无效条件叠加，不利于问题定位，因此不是好的测试用例。
- D：仅专业无效（生物学），可测试专业约束。
答案与解析
答案：AD
解析：
可根据问题将测试用例代入执行，①②会执行语句A和语句B, 但只覆盖第一个条件，因此是语句覆盖；
①②覆盖了第一个条件的真假，执行了第一个条件的Y和N以及第二个条件的N,而③或者④又执行到了第二个条件的Y,因此流程中所有分支都走到了，是路径覆盖。
McCabe 环路复杂度
环路复杂度 = m - n + 2，其中 m = 有向边数（分支连线），n = 节点数（语句框）。
McCabe度量法：又称为环路复杂度，假设有向图中有向边数为m,节点数为n,则此有向图的环路复杂度为m-n+2.
注意m和n代表的含义不能混淆，可以用一个最简单的环路来做特殊值记忆此公式，另外，针对一个程序流程图，每一个分支边（连线）就是一条有向边，每一条语句（语句框）就是一个顶点。
此外，推荐使用另一种简单的计算公式：环路复杂度=判定节点个数+1.
解析：
这两个空在这类题里，通常答案是一样的，因为：
- 环路复杂度 = 独立路径数
- 白盒测试时，通常要求的是 基本路径（独立路径） 的条数，不是把循环重复无数次后的所有执行路径都算进去。
图中有 3 个判定节点，
V(G)=判定节点个数+1=3+1=4 （环路复杂度）
方式二：顶点 11 边 13， 13 - 11 + 2 = 4
白盒测试这里默认问的是 独立路径数（基本路径数），它恰好等于环路复杂度。
因此：独立路径数=V(G)=4独立路径数=V(G)=4
所以第一个空也是：B
把流程大致看成这样：
- 开始 →→ 语句1 →→ 判断1
- 判断1：
- 否 →→ 结束
- 是 →→ 语句2 →→ 判断2
- 判断2：
- 否 →→ 语句3
- 是 →→ 判断3
- 判断3：
- 是 →→ 语句5
- 否 →→ 语句4 →→ 语句5
- 然后到语句6，再回到判断1
可以取 4 条基本独立路径：
- 判断1为否
- 开始 →→ 语句1 →→ 判断1(N) →→ 结束
- 判断1为是，判断2为否
- 开始 →→ 语句1 →→ 判断1(Y) →→ 语句2 →→ 判断2(N) →→ 语句3 →→ 语句6 →→ 判断1...
- 判断1为是，判断2为是，判断3为是
- 开始 →→ 语句1 →→ 判断1(Y) →→ 语句2 →→ 判断2(Y) →→ 判断3(Y) →→ 语句5 →→ 语句6 →→ 判断1...
- 判断1为是，判断2为是，判断3为否
- 开始 →→ 语句1 →→ 判断1(Y) →→ 语句2 →→ 判断2(Y) →→ 判断3(N) →→ 语句4 →→ 语句5 →→ 语句6 →→ 判断1...
这 4 条就覆盖了所有判定分支的“新情况”，所以独立路径数是 4
练习题
调试
测试是发现错误，调试是找出错误的代码和原因。
调试方法：
| 方法 | 说明 |
|---|---|
| 蛮力法 | 全面排查 |
| 回溯法 | 从出错位置往回找 |
| 原因排除法 | 找出所有可能原因逐一排除，含演绎法、归纳法、二分法 |
调试后需要进行回归测试。
软件度量
| 属性类型 | 说明 | 特点 |
|---|---|---|
| 外部属性 | 面向管理者和用户，如性能指标 | 可直接测量 |
| 内部属性 | 软件产品本身的属性，如可靠性 | 只能间接测量 |
软件的两种属性：外部属性指面向管理者和用户的属性，可直接测量，一般为性能指标。内部属性指软件产品本身的的属性，如可靠性等，只能间接测量。
补充考点
灰盒测试
🎯 一句话结论：灰盒测试既关注内部程序逻辑又考虑外部功能，但不像白盒测试那样详细和完整。
判定表测试
🎯 一句话结论：判定表最适合描述在多个逻辑条件取值组合构成的复杂情况下分别执行哪些不同动作。
自动化测试脚本类型
| 脚本类型 | 特点 |
|---|---|
| 线性脚本 | 录制手工测试时得到的脚本，无判断和循环 |
| 结构化脚本 | 包含控制结构（判断、循环） |
| 数据驱动脚本 | 测试输入存储在独立的数据文件中，不在脚本中 |
| 共享脚本 | 可被多个测试用例复用的脚本 |
静态分析类型
| 分析类型 | 检测内容 |
|---|---|
| 控制流分析 | 程序执行路径，如死代码、无限循环 |
| 数据流分析 | 引用未定义的变量、未使用的变量赋值等 |
| 接口分析 | 模块接口一致性，参数类型/个数匹配 |
| 表达式分析 | 表达式正确性、优先级等 |
⚠️ 易错：引用未定义变量属于数据流分析，不是控制流分析。
系统测试特点
系统测试主要采用黑盒测试方法，检查系统是否符合软件需求（不是白盒也不是内部逻辑验证）。
测试标准流程
单元测试 → 集成测试 → 系统测试（不可颠倒）
Web 专项测试
- 链接测试：验证所有超链接是否有效、指向正确页面
- 压力测试前应先进行基准测试验证正常负载下的资源占用