软件质量保证与测试期末复习

一、软件测试概述

1.软件缺陷：软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好，则是缺陷。

2.软件质量：反映实体满足明确或隐含需要能力的特性总和。

• 客观而言，软件质量是软件具有某种能力的属性，这就是前提条件；
• 主观而言，软件具有的能力对应不同层次的用户需求。

3.广义软件质量和狭义软件质量

•  狭义：软件的内部质量，即软件无“故障”。  
• 广义：产品质量、过程质量和客户满意度。

4.IEEE 关于软件质量的定义

• 软件质量是 系统、部件或者过程满足规定需求的程度。
• 系统、部件或者过程满足顾客或者用户需要或期望的程度。

5.影响软件质量的因素

• 需求模糊 
• 软件开发缺乏规范性文件指导
• 软件开发人员问题
• 缺乏软件质量控制管理

6.软件测试与软件质量

• 软件测试可以验证软件质量
• 软件测试不能提高软件质量
• 提高软件质量依赖于改进软件开发过程质量
• 软件测试是软件质量保证的关键步骤

7.软件质量因素

• 功能性：软件实现的功能达到要求的和隐含的用户需求以及设计规范的程度
• 可靠性：软件在指定条件和特定时间段内维持性能的能力程度
• 易使用性：用户使用该软件所付出的学习精力 
• 效率：在指定条件下，软件功能与所占用资源之间的比值  
• 可维护性：当发现错误、运行环境改变或客户需求改变时，程序能修改的容易程度  
• 可移植性：将软件从一种环境移入另一种环境的容易程度。

二、软件测试基础

1.软件测试的分类（按测试阶段分）

●  单元测试：验证软件单元是否符合软件需求与设计，开发人员自测。

●  冒烟测试：软件构建版本建立后，对系统的基本功能进行简单的测试，这种测试重点验证的是程序的主要功能，而不会对具体功能进行深入测试。

●  集成测试：冒烟测试之后，将已经测试过的软件单元组合在一起测试它们之间的接口，用于验证软件是否满足设计需求。

●  系统测试：将经过测试的软件在实际环境中运行，并与其他系统的成分（如数据库、硬件和操作人员等）组合在一起进行测试。

●  验收测试：主要是对软件产品说明进行验证，逐行逐字的按照说明书的描述对软件产品进行测试，确保其符合客户的各项要求。

2.常见的软件测试模型

V模型

优点：将复杂的测试工作分成了目标明确的小阶段完成，具有阶段性、顺序性和依赖性，它既包含了对于源代码的底层测试也包含了对于软件需求的高层测试。

缺点：只能在编码之后才能开始测试，早期的需求分析等前期工作没有涵盖其中，因此它不能发现需求分析等早期的错误，这为后期的系统测试、验收测试埋下了隐患。

W模型

优点：测试范围不仅包括程序，还包括需求分析、软件设计等前期工作，这样有利于尽早全面的发现问题。

缺点：它将软件开发过程分成需求、设计、编码、集成等一系列的串行活动，无法支持迭代、自发性等需要变更调整的项目。

H模型

• 测试独立
• 并发执行

X模型

优点：对单独程序片段进行的相互分离的编码和测试，保证了测试效果。增加了探索测试，可以帮助测试人员发现计划之外的软件错误。

缺点：频繁的集成会增加测试成本；探索测试对测试人员要求更高。

3.软件测试原则

●  测试应基于客户需求。

●  测试要尽早进行。

●  穷尽测试是不可能的。

●  遵循GoodEnough原则。

●  测试缺陷要符合“二八”定理。

●  避免缺陷免疫。

4.软件测试流程

• 分析需求
• 制定计划
• 设计用例
• 执行测试
• 编写报告

（1）测试用例

👉 包含：

• 测试步骤
• 测试数据
• 预期结果

👉 原则：
👉 少用例，高覆盖率

（2）测试报告（简答题）

包括：

• 测试概要
• 执行情况
• 缺陷分析
• 测试结论

三、黑盒测试

⭐1. 黑盒测试概念

👉 不看代码，只看输入输出

⭐2. 常用方法（重点⭐⭐⭐）

（1）等价类划分 ⭐⭐⭐

👉 核心：

• 把数据分为：
  • 有效等价类
  • 无效等价类

👉 目的：
👉 减少测试用例数量

（2）边界值分析 ⭐⭐⭐

👉 测试：

• 最小值
• 最大值
• 临界点

👉 口诀：
👉 “边界最容易出错”

（3）判定表法

• 多条件组合

（4）因果图法

• 条件→结果关系

（5）场景法（流程测试）

• 业务流程测试

四、白盒测试

 1. 白盒测试定义

- 已知程序内部逻辑结构和执行过程，对内部操作、路径和逻辑进行测试。

2. 逻辑覆盖法

从弱到强记忆：

1. 语句覆盖
2. 判定覆盖
3. 条件覆盖
4. 判定-条件覆盖
5. 条件组合覆盖

1. 语句覆盖

- 每条可执行语句至少执行一次
- 只能保证语句被执行，不能保证分支和逻辑正确
- 覆盖最弱

2. 判定覆盖

- 每个判定结果至少有一次为真、一次为假
- 又叫分支覆盖

3. 条件覆盖

- 每个逻辑条件的真值和假值至少出现一次
- 不一定满足判定覆盖

4. 判定-条件覆盖

- 同时满足：
- 每个条件真/假至少一次
- 每个判定结果真/假至少一次

5. 条件组合覆盖

- 每个条件各种真假组合至少出现一次
- 覆盖最强，但测试用例数量会快速膨胀

 3. 覆盖强弱关系

- 一般记忆为：语句覆盖 < 判定覆盖
- 条件覆盖与判定覆盖彼此不能完全替代
- 判定-条件覆盖强于单独的判定覆盖和条件覆盖
- 条件组合覆盖最强

4. 插桩法

- 在程序中插入测试代码（探针）获取运行信息
- 分为目标代码插桩和源代码插桩

5. 本章高频考点

- 五种逻辑覆盖法定义
- 各覆盖法的区别
- 覆盖强弱排序
- 为什么语句覆盖和判定覆盖仍可能漏错

五、软件测试过程

1. 四个阶段

单元测试

- 最小可测试单元的测试
- 常见最小单元：C语言中常是函数，Java中常是类
- 主要采用白盒测试

单元测试主要任务：

- 模块接口
- 局部数据结构
- 独立路径
- 出错处理
- 边界条件

辅助代码：

- 驱动模块：模拟上级模块，调用被测模块
- 桩模块：模拟被测模块调用的下级模块

集成测试

- 将已通过单元测试的模块组装后测试
- 重点查接口错误、数据传递问题、功能组合问题
- 介于单元测试和系统测试之间

集成策略：

- 非渐增式集成：Big Bang，一次性集成
- 渐增式集成：
- 自顶向下
- 自底向上

对比：

- 自顶向下：少驱动，多桩；早发现上层控制问题
- 自底向上：少桩，多驱动；便于测试底层功能

系统测试

- 在实际运行环境中，对完整软硬件系统进行测试
- 完全采用黑盒测试
- 依据：软件规格说明书

系统测试分类：

- 功能测试
- 性能测试
- 安全测试
- 可靠性/稳定性测试
- 兼容性测试
- 恢复测试
- 用户支持方面测试

验收测试

- 以用户为主
- 在系统测试和配置审查之后进行
- 检查软件是否达到交付标准

验收测试通过准则：

- 所有功能实现
- 性能达标
- 无残余一级、二级、三级错误
- 文档齐全且一致

回归测试

- 软件修改后重新测试
- 检查修改是否正确，是否引入新错误
- 贯穿各阶段，不是最后才做

回归测试分类：

- 纠正型回归测试：修复缺陷后回归
- 增量型回归测试：新增功能后回归

回归测试策略：

- 重点测修改模块
- 重点测耦合模块
- 提高自动化程度
- 维护测试用例库

α测试与β测试

- α测试：开发环境或模拟环境，内部用户/测试员进行，开发者通常在场
- β测试：真实环境，多个外部用户进行，开发者通常不在场

2. 性能测试必须会的指标

- 响应时间
- 吞吐量
- 并发用户数
- TPS
- 点击率
- 资源利用率

3. 性能测试常见类型

- 负载测试：在满足指标前提下找最大负载
- 压力测试：把系统压到极限甚至崩溃边缘
- 疲劳强度测试：长时间高负载运行
- 并发测试：多用户同时访问，查死锁和竞争问题

4. 本章常考简答

- 单元测试的任务
- 驱动模块和桩模块的区别
- 集成测试的策略及优缺点
- 系统测试与验收测试区别
- 回归测试定义与策略
- α测试与β测试区别
- 负载测试与压力测试区别

六、软件质量与软件质量管理

1. 程序中隐藏错误数量估计

撒播模型法

- 人为向程序植入若干错误
- 测试后根据“原有错误”和“植入错误”发现情况估算总错误数
- 局限：
- 人工植错困难
- 不同错误发现难度不同
- 植入错误不一定有代表性

Hyman分别测试法

- 两个测试员独立测试同一程序
- 根据两人分别发现和共同发现的错误，估算原始错误数

回归分析

- 通过回归函数和曲线分析错误变化趋势并预测错误数

2. SQC：软件质量控制

- 通过检查、测试、审查、评估识别并纠正缺陷
- 目标：以较低代价获得满足客户要求的软件产品，并持续改进过程

常用方法：

- 目标-问题-度量法
- 风险管理法
- PDCA法

PDCA：

- Plan 计划
- Do 执行
- Check 检查
- Action 处理/改进

风险控制方法：

- 风险避免
- 风险弱化
- 风险承担
- 风险转移

3. SQA：软件质量保证

- 通过计划、标准、审计、评审和监督，保证开发过程符合要求
- 是一种独立审查活动
- 重点是“过程是否按标准执行”

SQA主要工作：

- 识别质量需求
- 参与项目计划
- 制定SQA计划
- 评审工作产品
- 审核过程
- 处理不合格项
- 报告质量情况

4. SQC与SQA区别

- SQC重“产品和输出”的检查纠错
- SQA重“过程和标准”的保证监督
- SQC偏发现缺陷
- SQA偏防止缺陷、保证过程合规

5. 软件质量模型

McCall模型

常见质量因子：

- 正确性
- 可靠性
- 效率
- 完整性：对未授权人员访问软件或数据的可控制程度
- 可用性
- 可维护性
- 灵活性
- 可测试性
- 可移植性
- 可复用性
- 互连性

ISO 9126

六大特性：

- 功能性
- 可靠性
- 可用性
- 效率
- 可维护性
- 可移植性

6. 软件度量

- 本质：对软件属性进行量化表示
- 目的：
- 理解软件
- 管理项目
- 评估和预测
- 改进过程
 

七、习题

1.某登录系统要求：用户名不能为空，密码长度必须为6—12位，验证码必须正确。请分析该功能适合采用哪些黑盒测试方法进行测试，并说明理由。

1. 等价类划分法
最适合这题的基础方法。

理由：

• 用户名可分为“为空”和“非空”两类。
• 密码长度可分为“小于6位”“6到12位”“大于12位”三类。
• 验证码可分为“正确”和“错误”两类。
• 这些输入条件都很明确，特别适合先划分有效等价类和无效等价类，再从每类中选代表数据设计测试用例。

2. 边界值分析法
尤其适合密码长度这一条件。

理由：

• 密码长度限制是 6—12位，明显存在边界。
• 应重点测试 5、6、7、11、12、13 这些边界附近的值。
• 因为程序在边界处最容易出错，所以边界值分析法非常适合。

3. 错误推测法
可以作为补充方法。

理由：

• 登录功能是高频功能，容易出现一些经验性问题。
• 例如：
• 用户名输入空格是否算空
• 密码输入空格、特殊字符是否允许
• 验证码大小写是否敏感
• 验证码正确但已过期是否能通过
• 这些情况不一定完全由等价类和边界值覆盖，适合用错误推测法补充。

结论
该登录功能最适合采用：

• 等价类划分法
• 边界值分析法
• 错误推测法

其中：

• 等价类划分法用于划分用户名、密码、验证码的有效和无效输入
• 边界值分析法重点测试密码长度边界
• 错误推测法用于补充一些常见异常场景

2.有一段程序逻辑如下：如果（A>1 且 B=0）则执行X操作；如果（A=2 或 C>1）则执行Y操作。请为该逻辑设计一组测试用例，仅满足“判定-条件覆盖”标准，并说明该用例覆盖了哪些判定和条件。

设：

• 判定1：D1 = (A > 1 且 B = 0)
• 判定2：D2 = (A = 2 或 C > 1)

对应条件：

• C1: A > 1
• C2: B = 0
• C3: A = 2
• C4: C > 1

测试用例

覆盖说明

TC1：

• C1 真，C2 真，所以 D1 真
• C3 真，C4 真，所以 D2 真

TC2：

• C1 真，C2 假，所以 D1 假
• C3 真，C4 假，所以 D2 真

TC3：

• C1 假，C2 真，所以 D1 假
• C3 假，C4 假，所以 D2 假

最终覆盖结果

• 判定覆盖：

• D1 取到 真、假

• D2 取到 真、假

• 条件覆盖：

• C1: A>1 取到 真、假

• C2: B=0 取到 真、假

• C3: A=2 取到 真、假

• C4: C>1 取到 真、假

3.某个程序的处理逻辑如下：

1.如果用户是教师且借书数量超过5本，则借阅期限为60天；

2.如果用户是教师但借书数量不超过5本，则借阅期限为30天；

3.如果用户不是教师且借书数量超过3本，则借阅期限为15天；

4.如果用户不是教师且借书数量不超过3本，则借阅期限为7天。

请使用决策表的形式，列出所有条件桩、动作桩及其可能的组合？

条件桩

• C1：用户是否为教师
• C2：借书数量是否超过5本
• C3：借书数量是否超过3本

注意：

• 对教师来说，真正起作用的是“是否超过5本”
• 对非教师来说，真正起作用的是“是否超过3本”
• 所以有些条件在某些规则下是“不关心”的，用 - 表示

动作桩

• A1：借阅期限为60天
• A2：借阅期限为30天
• A3：借阅期限为15天
• A4：借阅期限为7天

决策表

各规则含义

• 规则1：教师，且借书数量大于5本，借阅期限60天
• 规则2：教师，且借书数量不大于5本，借阅期限30天
• 规则3：非教师，且借书数量大于3本，借阅期限15天
• 规则4：非教师，且借书数量不大于3本，借阅期限7天

4.分析跨站脚本攻击与跨站伪造请求之间的区别？

相同点

• 都属于常见 Web 安全漏洞
• 都可能利用用户当前登录状态发起攻击
• 都会危害用户数据和系统安全

不同点

• 攻击本质不同：

• XSS 是“向页面注入恶意脚本”

• CSRF 是“冒充用户发起恶意请求”

• 利用方式不同：

• XSS 利用的是网站对用户输入过滤不严，恶意脚本被浏览器执行

• CSRF 利用的是网站对请求来源校验不足，诱导用户在已登录状态下执行操作

• 攻击目标不同：

• XSS 重点是窃取信息、执行脚本、控制页面

• CSRF 重点是借用户身份完成转账、修改资料、发帖等操作

• 是否依赖脚本注入：

• XSS 需要恶意脚本注入页面

• CSRF 不一定需要脚本注入，关键是伪造请求

• 防御方式不同：

• XSS：输入过滤、输出编码、HttpOnly、CSP

• CSRF：Token 校验、Referer/Origin 校验、重要操作二次验证

一句话记忆：

• XSS 是“偷你的身份去干坏事”
• CSRF 是“骗你自己去干坏事”

5.集成测试与系统测试的区别？

集成测试

• 对象：已通过单元测试的模块及其接口
• 目的：发现模块之间接口、调用、数据传递、组合逻辑的问题
• 依据：概要设计、模块接口设计
• 方法：黑盒和白盒结合
• 阶段：单元测试之后，系统测试之前
• 重点：接口错误、数据丢失、功能组合问题、全局数据问题

系统测试

• 对象：完整的软件系统及其运行环境
• 目的：验证系统是否满足功能、性能、安全等整体需求
• 依据：需求规格说明书
• 方法：主要采用黑盒测试
• 阶段：集成测试之后
• 重点：完整业务功能、性能、安全性、兼容性、稳定性、恢复能力

一句话记忆：

• 集成测试看“模块之间连得对不对”
• 系统测试看“整个系统好不好用、达不达标”

6.解释CMM5中已定义级和已管理级之间的区别是什么？

已定义级（第3级）

• 组织已经建立了标准化、文档化的软件过程。
• 各项目有统一的开发和管理规范可遵循。
• 重点是“过程已经被定义并制度化”。

已管理级（第4级）

• 在第3级基础上，进一步对过程和产品进行定量管理。
• 能用数据对软件过程和质量进行测量、分析和控制。
• 重点是“过程不仅被定义，而且能被度量和统计管理”。

两者核心区别

• 第3级强调：有统一标准过程。
• 第4级强调：用量化数据管理过程和质量。

一句话记忆：

• 已定义级：过程标准化。
• 已管理级：过程定量化。

7.简述Loadrunner和JMeter两者的相同和不同点

相同点

• 都可用于性能测试和压力测试
• 都可模拟多用户并发访问
• 都能采集响应时间、吞吐量等指标
• 都可用于发现性能瓶颈

不同点

1. 性质不同

• LoadRunner：商业软件
• JMeter：开源软件

2. 成本不同

• LoadRunner：授权费用高
• JMeter：免费

3. 易用性不同

• LoadRunner：界面完整，功能集成度高，企业级支持较强
• JMeter：上手相对灵活，但部分高级场景需要更多配置经验

4. 协议支持与企业能力

• LoadRunner：对企业级复杂协议支持通常更强，更适合大型商业项目
• JMeter：对常见 Web 接口、HTTP、数据库等支持很好，适合多数常规性能测试场景

5. 扩展性不同

• JMeter：插件生态丰富，便于二次扩展
• LoadRunner：功能成熟，但扩展通常依赖其平台体系

6. 适用场景不同

• LoadRunner：适合预算充足、规模大、规范要求高的企业项目
• JMeter：适合教学、练习、中小项目、接口和 Web 性能测试

一句话记忆：

• LoadRunner：商业化、企业级、功能成熟
• JMeter：开源、免费、灵活常用