软件测试--进阶

Posted 2021-07-05 Kirl z

软件测试--进阶

• 1. 按照开发阶段划分
• • 1.1 单元测试
  • 1.2 集成测试
  • 1.3 系统测试
  • 1.4 回归测试
  • 1.5 冒烟测试
  • 1.6 验收测试
• 2. 按照实施组织划分
• • 2.1 α测试
  • 2.2 β测试
  • 2.3 第三方测试
• 3. 按照是否运行划分 (运行代码)
• • 3.1 静态测试
  • 3.2 动态测试
• 4. 按照是否手工划分
• • 4.1 手动测试
  • 4.2 自动化测试
• 5. 按照是查看代码划分
• • 5.1 黑盒测试
  • 5.2 白盒测试
  • 5.3 灰盒测试
• 6. 按照地域划分
• • 6.1 国际化测试
  • 6.2 本地化测试
• 7. 按照测试对象划分
• • 7.1 业务 (场景法)
  • 7.2 界面 (UI)
  • 7.3 兼容性测试
  • 7.4 文档测试
  • 7.5 兼容性测试
  • 7.6 易用性
  • 7.7 安装测试
  • 7.8 安全测试
  • 7.9 性能测试
  • 7.10 内存泄漏测试

1. 按照开发阶段划分

测试金字塔模型

1. 从下到上三层测试, 投入相同的时间, 人力资源等, 回报率 (产出) 越来越低
2. 从下到上, 测试的效率越来越低
3. 从下到上, 定位问题越来越难

1.1 单元测试

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

Test-Dirven-Develop 测试驱动开发

测试阶段：编码后或者编码前（TDD）
测试对象：最小模块
测试方法：白盒测试
测试内容：模块接口测试 (按照接口设计文档, 参数, 输出)、局部数据结构测试 (局部变量)、路径测试、错误处理测试、边界测试

单元测试框架 Junit

1. 在 pom.xml 文件中加入依赖

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.12</version>
    <scope>test</scope>
</dependency>

2. 在 file - settings - Plugins 搜索 Junit 并安装
3. 开始做单元测试
   选中要进行的单元测试的类的类名, Ctrl + shift + T, 生成单元测试类

1.2 集成测试

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

测试阶段：一般单元测试之后进行
测试对象：模块间的接口
测试方法：黑盒测试与白盒测试相结合
测试内容：模块之间数据传输 (输入, 输出)、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系
统的影响

1.3 系统测试

将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。时间大部分在系统测试执行阶段，包括回归测试和冒烟测试。

测试阶段：集成测试通过之后
测试对象：整个系统（软、硬件）
测试方法：黑盒测试
测试内容：功能、界面、可靠性、易用性、性能、兼容性、可移植性等

1.4 回归测试

回归测试是指修改了旧代码后(引入新代码)，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。

• 出现新功能
• 修改了BUG

大型系统, 不停迭代, 每次都要进行回归 。动化回归

1.5 冒烟测试

在正式测试之前对系统的主要流程和核心功能进行测试

冒烟测试一般在开发人员开发完毕后送给测试人员来进行测试时，测试人员会先进行冒烟测试，保证基本功能正常，不阻碍后续的测试。

准入原则

1.6 验收测试

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

验收测试不仅仅对系统进行全面测试, 验收文档 (开发文档, 软件设计文档, 需求分析文档, 功能使用文档, 用户使用手册)

纯黑盒测试

2. 按照实施组织划分

2.1 α测试

用户或者非测试和开发人员请到开发现场进行测试
时间比较集中, 在开发现场好沟通产品的问题
是比较容易受开发环境的影响

2.2 β测试

用户在实际使用环境下进行测试
用户测试的结果更接近与实际使用情况的反馈

α测试与β测试的区别：

• α测试是指把用户请到开发方的场所来测试,β测试是指在用户的场所进行的测试。
• α测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。β测试的环境是不受开发方控制的, 用户数量相对比较多,时间不集中。
• α测试先于β测试执行。通用的软件产品需要较大规模的β测试,测试周期比较长。

2.3 第三方测试

介于开发方和用户方间的组织的测试。

3. 按照是否运行划分 (运行代码)

3.1 静态测试

不运行程序, 根据需求规格说明书, 软件设计文档, 程序设计文档等结合程序 (代码), 查看代码的风格, 语法, 逻辑等是否符合需求

3.2 动态测试

写测试用例, 运行系统 (程序), 执行测试用例

4. 按照是否手工划分

4.1 手动测试

优点: 灵活, 发散性测试 (自动化测试无法替代手工测试)
缺点: 量大容易出错, 执行效率慢

4.2 自动化测试

按照预设的条件去执行测试, 收集测试结果, 设置正常验证和异常验证

UI 界面自动化 , selenium, unitest, ddt, htmlResultRepport
接口自动化 jmeter postman
性能自动化 loaderrunner

自动化的前提: 项目的功能相对稳定
自动化的价值: 脚本的重复使用率 (利用率) 越高, 自动化越有价值

5. 按照是查看代码划分

5.1 黑盒测试

黑河测试不关注程序内部具体的实现, 只关注功能的输入和输出是否满足需求

黑盒测试设计测试用例的方法有哪些?
等价类, 边界值, 因果图法, 错误猜测法, 正交法, 场景法

5.2 白盒测试

测试的时候关注功能内部程序的实现逻辑, 结构, 语法等

白盒测试的方法?
语句覆盖法, 循环覆盖法, 路径覆盖法, 逻辑覆盖法

5.3 灰盒测试

介于白盒和黑盒之间的测试
集成测试

6. 按照地域划分

6.1 国际化测试

软件国际化: 开发软件的时候使用的一种技术, 使得软件可以使用于不同国家的语言, 文化和风俗习惯, 可以不用修改源代码, 这种工程技术叫做软件国际化

6.2 本地化测试

7. 按照测试对象划分

7.1 业务 (场景法)

是测试人员把系统各个模块串接起来运行、模拟真实用户实际的工作流程，满足用户需求定义的功能来进行测试的过程。
业务测试关注需求和用户

7.2 界面 (UI)

完整性, 准确性, 一致性, 易用性
布局, 排版, 字体, 图像
控件: 对话框, 文本框, 按钮, 滚动条, CheckBox

不同页面大小的自适应测试

• 页面从大到小文字, 图片有没有消失重叠
• 页面从大到小功能有没有消失
• 页面从大到小功能是否可以正常使用
• 页面从大到小过程衔接是否丝滑

7.3 兼容性测试

当系统由于外界异常环境或者人为错误引起的系统的错误, 系统可以自我消化掉, 而不把这些错误或者异常直接展示给用户。

数据级别, 校验级别, 环境级别, 界面级别等

7.4 文档测试

完整性, 术语专业, 准确性, 一致性, 易用性

7.5 兼容性测试

• 平台测试
• 浏览器测试
• 软件本身能否向前或者向后兼容
• 测试软件能否与其它相关的软件兼容
• 数据兼容性测试

7.6 易用性

用户体验测试

1. 遵循标准 (行业)
   弹框信息提示
   警告信息提示
   严重错误提示
2. 直观性
3. 灵活性
4. 舒适性
   上传, 下载, 压缩 (进度条)
5. 实用性

7.7 安装测试

测试程序的安装、卸载
典型的是app的安装、卸载

7.8 安全测试

数据泄露, 黑客攻击, SQL 注入, XSS 注入, 病毒等

7.9 性能测试

资源泄露, 资源瓶颈, 线程阻塞, 数据库查询慢效率低等
TPS (吞吐量), 每秒事务处理量, 响应时间, 点击率, 资源利用率 (CPU, 带宽, 硬盘等)

7.10 内存泄漏测试

引起原因:

• 分配的内存没有释放
• 使用 API 函数的时候不正确
• 代码写的有问题, 导致最终无法释放内存