测试（四）

1. 如何根据需求设计测试用例

测试用例是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。

1. 验证需求的正确性，无二义性
2. 分析需求，细化需求，从需求中提取测试项
3. 根据测试项找到测试点
4. 根据测试点设计测试用例

2. 测试用例的两个方面

2.1 功能性测试

1. 界面功能的全面性测试（从左至右，从上到下）
2. 将功能串联为业务或场景，验证功能之间的交互性，一致性
3. 同一个功能输入不同的数据，要有与之对应的输出
4. 异常功能的测试
5. 功能用到的算法的验证

2.2 非功能性测试

1. 性能
2. 兼容性
3. 易用性
4. 安全性
5. 容错性
6. 可移植性
7. 可靠性测
8. 可维护性

3. 具体设计测试用例的方法

3.1 等价类

依据需求将输入（特殊情况下考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，解决了不能穷举测试的问题

1. 有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合
2. 无效等价类：根据需求说明书，不满足需求的集合。

3.2 边界值

对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界

3.3 错误猜测法

根据测试人员的经验、知识积累，猜测某一块功能有问题，有针对性的进行测试用例的编写
探索性测试，比较依赖测试人员的水平

3.4 场景法

软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流

不同的功能点串联起来形成了一个场景，不同的功能点又有不同的输出，不同的输出导致了不同的测试场景

3.5 因果图法

因果图是一种简化的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系。因果图法是借助图形来设计测试用例的一种系统方法，特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况

设计测试用例的步骤：

1. 分析出所有的输入和输出
2. 找出输入、输出之间的组合关系
3. 根据关系图画出因果图
4. 根据因果图画出判定表
5. 根据判定表写出测试用例

3.6正交法

正交法的 目的 是为了减少用例数目。用尽量少的用例覆盖输入的两两组合

正交试验设计是研究多因素多水平的一种设计方法，它是根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合。根据最优数据组合试验的结果来分析整个测试的结果

4. 测试分类

4.1 根据测试对象划分

4.1.1 界面测试

用户是通过界面与软件进行交互的

1. 测试界面元素的完整性、正确性
2. 测试界面的排版布局是否合理
3. 测试界面在不同页面的自适应性（文字无重叠，图片完整，功能完整等）
4. 测试界面控件是否正常
5. 测试界面设计是否合理

界面常见的错误：

1. 文字丢失
2. 文字截断
3. 文字重叠
4. 文字自动换行
5. 控件没有对齐
6. 重复的快捷键
7. 不合适的快捷键

4.1.2 可靠性测试

可靠性指软件正常运行的能力，软件正常运行的时间和总体运行时间的百分比
可靠性 = 软件正常运行的时间 / (软件正常运行时间 + 软件非正常运行时间)

影响可靠性的因素：

1. 网络环境
2. 软件安装环境
3. 硬件环境
4. 软件自身

4.1.3 容错性测试

容错性测试是检查 软件在异常条件下自身是否具有防护性的措施或某种灾难性恢复的手段。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。

常见的容错性处理：

1. 数据容错性（系统异常或错误操作后数据能否恢复）
2. 校验容错性（自动校验空格、大小写字母等）
3. 界面容错性（复杂操作、危险操作的提示等）
4. 环境容错性（软件所在的环境发生故障，软件是否有备用方案）

灾难恢复性测试：通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失，系统和数据是否能尽快恢复。
对于自动恢复需验证重新初始化、检查点、数据恢复和重新启动等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。

4.1.4 文档测试

• 开发文件：可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。
• 用户文件:用户手册、操作手册，用户文档的作用：改善易安装性；改善软件的易学性与易用性；改善软件可靠性；降低技术支持成本。
• 管理文件：项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。

在实际的测试中，最常见的是用户文件的测试

文档测试的关注点：

1. 文档的术语
2. 文档的正确性
3. 文档的完整性
4. 文档的一致性
5. 文档的易用性

4.1.5 兼容性测试

兼容性主要是指软件之间能否很好的运作，会不会有影响、软件和硬件之间能否发挥很好的效率工作，会不会影响导致系统的崩溃

主要有四个方面：

1. 软件自身的兼容性：软件向前向后的兼容性，新开发的功能不能影响就功能，并且不能影响后续功能的开发
2. 软件对于数据的兼容性：设计功能前要考虑用户已有的数据
3. 软件对于平台的兼容性：对不同的软件安装环境、设备硬件环境软件能正常运行
4. 软件对于第三方软件的兼容性

4.1.6 易用性测试

易用性是交互的适应性、功能性和有效性的集中体现
主要表现在：

1. 符合标准和规范
2. 直观性
3. 灵活性
4. 舒适性
5. 实用性

4.1.7 安装卸载

1. 不同的安装卸载途径中，安装卸载软件是否正常
2. 安装或卸载过程中是否暂停，暂停后能否继续正常安装或卸载
3. 安装过程中空间不足，是否有提示
4. 正常卸载软件，如果中途取消卸载，软件能否正常使用，数据能否恢复

4.1.8 安全性测试

软件保护用户的隐私数据，以及数据传输过程中的安全性，防止病毒入侵和黑客攻击

1. 输入域能够检测带病毒的字符或文件
2. 防止输入注入
3. 权限合理分配
4. 防止爬虫
5. 传输文件或数据示防止拦截

4.1.9 性能测试

检查系统是否满足需求规格说明书中规定的性能。
通常表现在以下几个方面：

1. 对资源利用（如内存、处理机周期等）进行的精确度量
2. 执行时间间隔
3. 日志事件（如中断，报错）
4. 响应时间
5. 吞吐量（TPS）
6. CPU和资源利用率

4.1.10 内存泄漏

从用户使用的角度来看，内存泄露本身不会造成什 么危害，一般用户可能根本不会感觉到内存泄露的存在。但是内存泄露是会累积的，只要执行的次数足够多，最终会耗尽所有可用内存，使软件的执行越来越慢，最后停止响应

造成内存泄露的原因有很多，最常见的有以下几种。

• 分配完内存之后忘了回收
• 程序写法有问题，造成没办法回收
• 某些API函数的使用不正确，造成内存泄露
• 没有及时释放

内存泄漏的检测：

1. 人工检查
2. 通过代码扫描分析工具来检查

4.2 根据是否查看代码划分

4.2.1 黑盒测试

不关心代码内部的逻辑结构，不查看代码，只关心软件功能的外部输入和输出是否满足用户的需求

测试方法：等价类、边界值、场景法、因果图、错误猜测法、正交法

特点：

1. 不用关心代码的实现
2. 站在用户的角度设计测试用例
3. 设计测试用例是根据软件的需求来设计的，不容易遗漏需求

4.2.2 白盒测试

分析代码的逻辑结构、对代码进行测试，看代码是否实现了需求

测试方法：语句覆盖、路径覆盖、逻辑覆盖、判定覆盖、条件覆盖、判定组合覆盖、判定和条件覆盖、条件和条件组合覆盖

4.2.3 灰盒测试

介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况

4.3 根据开发阶段划分

4.3.1 单元测试阶段

单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位：模块。又称为模块测试

• 测试阶段：编码后或者编码前（TDD）
• 测试对象：最小模块
• 测试人员：白盒测试工程师或开发工程师
• 测试依据：代码和注释+详细设计文档
• 测试方法：白盒测试
• 测试内容：模块接口测试、局部数据结构测试、路径测试、循环测试、错误处理测试、边界测试

4.3.2 集成测试阶段

将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。集成主要目的是检查软件单位之间的接口是否正确

• 测试阶段：单元测试之后进行
• 测试对象：模块间的接口
• 测试人员：白盒测试工程师或开发工程师
• 测试依据：单元测试的模块+概要设计文档
• 测试方法：黑盒测试与白盒测试相结合
• 测试内容：模块功能的正确性、组成模块的单元之间的接口测试、全局数据结构、单模块缺陷对系统的影响

4.3.3 系统测试阶段

将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试

• 测试阶段：集成测试通过之后
• 测试对象：整个系统（软、硬件）
• 测试人员：黑盒测试工程师
• 测试依据：需求规格说明文档
• 测试方法：黑盒测试
• 测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等

4.3.3.1 回归测试

当系统引入新代码时，测试人员往往需要验证新的代码对旧的功能产生的影响所做的测试 叫做回归测试

回归测试将大幅降低系统测试、维护升级等阶段的成本

4.3.3.2 冒烟测试

在软件开发完成后，对软件的基础功能和核心流程进行测试，测试通过后，才可以进入正式测试环境，如果测试不通过，测试人员有权退回让开发人员重新修改，直至测试通过

4.3.4 验收测试阶段

验收测试是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试。
验收测试的目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买都展示该软件系统满足原始需求。

• 测试阶段：系统测试通过之后
• 测试对象：整个系统（包括软硬件）
• 测试人员：主要是最终用户或者需求方
• 测试依据：用户需求、验收标准
• 测试方法：黑盒测试
• 测试内容：同系统测试(功能…各类文档等)

4.4 依据实施组织测试划分

4.4.1 α测试

α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。

α测试的目的是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)

缺点：测试环境过于单一

4.4.2 β测试

Beta测试是一种验收测试。Beta测试由软件的最终用户们在一个或多个场所进行

α测试 和 β测试 的区别：

1. 测试环境不同
2. 测试时间集中度不同
3. α 测试先于 β 测试

4.4.3 第三方测试

介于开发方和用户方间的组织的测试，通过第三方测评机构按照行业标准规范对软件进行测试

4.5 依据是否手工划分

4.5.1 手工测试

手工测试就是由人去一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一个步骤

优缺点：

• 优点：自动化无法替代探索性测试、发散思维结果的测试
• 缺点：执行效率慢，量大易错

4.5.2 自动化测试

在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。简单说自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程

自动化测试比如功能测试自动化、性能测试自动化、安全测试自动化

通常所说的自动化是指功能测试自动化

4.6 依据代码是否运行划分

4.6.1 静态测试

指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性
对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错

4.6.2 动态测试

动态测试方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能

这种方法由三部分组成：构造测试用例、执行程序、分析程序的输出结果

大多数软件测试工作都属于动态测试

4.7 依据地域划分

软件的国际化和软件的本地化是开发面向全球不同地区用户使用的软件系统的两个过程

4.7.1 国际化测试

1. 外观上：界面是否完整、功能是否正常
2. 是否使用当地人的使用习惯
3. 不同设备上软件能否正常显示和使用
4. 不同分辨率下，软件能否正常显示和使用

4.7.2 本地化测试

以上都可以用作本地化测试