软件测试最全执行测试_单元测试，熬夜整理2024最新软件测试高级笔试题

2401_84140707

于 2024-05-13 08:36:01 发布

阅读量286

点赞数 3

分类专栏：程序员文章标签：单元测试功能测试学习

本文链接：https://blog.csdn.net/2401_84140707/article/details/138783463

版权

程序员专栏收录该内容

189 篇文章 1 订阅

订阅专栏

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取

独立执行路径

检查每一条独立执行路径的测试。保证每条语句被至少执行一次。

Checklist:

误解或不正确使用算术优先级
混合类型运算
变量初值错
运算精度不够
算法错误
表达式符号错

针对判定和条件覆盖。Checklist:

不同数据类型对象之间进行比较
错误的使用逻辑操作和优先级
由于计算机表示的局限性，期望理论上相等而实际上不相等
不正确的判定或不正确的变量
不正常或不存在的循环终止
错误的修改了循环控制变量

使用以基本路径测试为基础的动态白盒测试

错误处理

预见、预设的各种出错处理是否正确有效。
Checklist:

输出的出错信息难以理解
报告的错误与实际不相符
程序定义的出错处理前系统已介入
异常处理不当
未提供足够的定位出错的信息
也就是能够用自然语言清楚的告诉用户错在哪，怎么改。

动态黑盒测试

边界条件

检查临界数据处理的正确性。Checklist:
普通合法数据的处理。
普通非法数据的处理。
边界值内合法边界数据的处理。
边界值外非法边界数据的处理

动态黑盒测试

单元测试环境的建立

单元测试环境=被测模块 + 驱动模块 + 桩模块

驱动模块(drive)： 对底层或子层模块进行测试所编写的调用这些模块的程序
接收测试数据，把相关的数据传送给被测模块，启动被测模块，并打印出相应的结果
桩模块(stub)： 对顶层或上层模块进行测试时所编写的替代下层模块的程序
进行很少的数据处理，如打印入口和返回

注：

自动和手工测试都要搭建驱动模块 + 桩模块
驱动模块 + 桩模块的设计越简单越好，消耗的资源越少越好
驱动模块好写，桩模块难写

单元测试主要技术

主要采用白盒测试技术，辅之以黑盒测试技术

单元测试主要技术：

人工静态测试
动态执行测试(白盒+黑盒)
状态转换测试

1. 静态测试

不运行程序，单独检查单元代码并进行代码的评审和检查
外部接口和程序代码的关键部分要进行桌面检查和代码审查
目的：保证代码算法的逻辑正确性、清晰性、规范性、一致性、算法高效性

静态测试
适用于新开发和重用的代码
通常在代码完成并无错误的通过编译或汇编后，采用自动化工具扫描分析、代码评审等方法
由软件开发人员及开发小组成员共同完成
常用方法：
桌面检查(Desk Checking)
代码走查(Walk Through)
代码审查(Program Inspection)

2. 动态执行测试

动态白盒测试：逻辑覆盖和基本路径测试
测试基本原则：
保证单元中每一个独立路径至少执行一次
保证所有判断的每一分支至少执行一次
保证每一循环在边界条件和一般条件下至少执行一次
验证所有单元内部数据结构的有效性
2. 动态执行测试
动态白盒测试：逻辑覆盖和基本路径测试
测试基本原则：
保证单元中每一个独立路径至少执行一次
保证所有判断的每一分支至少执行一次
保证每一循环在边界条件和一般条件下至少执行一次
验证所有单元内部数据结构的有效性

3. 状态转换测试

当单元可能处于不同状态转换时，应根据单元可能进入的状态、这些状态之间的转换、引起转换可能导致的状态等进行测试

单元测试的评估

通过单元测试的一般准则：

软件单元功能与设计需求一致
软件单元接口与设计需求一致
能够正确处理输入和运行中的错误
在单元测试中发现的错误已经得到修改并且通过了测试
达到了相关的覆盖率的要求
完成软件单元测试报告

4.7 单元测试的管理

单元测试过程
在详细设计阶段完成单元测试计划。
建立单元测试环境，完成测试设计和开发。
执行单元测试用例，并且详细记录测试结果。
评估测试用例是否通过。
提交《单元测试报告》。
单元测试文档
《软件需求规格说明书》、《软件详细设计说明书》  《单元测试计划》
《单元测试计划》、《软件详细设计说明书》 《单元测试用例》
《单元测试用例》文档及《软件需求规格说明书》、《软件详细设计说明书》  《缺陷跟踪报告》/《缺陷检查表》
《单元测试用例》、《缺陷跟踪报告》/《缺陷检查表》 《单元测试检查表》
评估 《单元测试报告》

单元测试工具

单元测试工具简介
自动化单元测试工具的工作原理是借助于驱动模块与桩模块工作的，运行被测软件单元以检查输入的测试用例是否按软件详细设计规格说明的规定执行相关操作。

常见分类：静态分析工具；代码规范审核工具；内存和资源检查工具；测试数据生成工具；测试框架工具；测试结果比较工具；测试度量工具；测试文档生成和管理工具

JUnit⭐

JUnit是一个开放源代码的Java测试框架，用于编写和运行可重复的测试。

它是单元测试框架体系xUnit的一个实例
（xUnit系列框架，常用的根据语言不同分为JUnit(java)，CppUnit(C++)，DUnit (Delphi)，NUnit(.net)，PhpUnit(Php)等）

⭐JUnit特性

可以使测试代码与产品代码分开
针对某一个类的测试代码通过较少的改动便可以应用于另一个类的测试
易于集成到测试人员的构建过程中，JUnit和Ant的结合可以实施增量开发
JUnit是公开源代码的，可以进行二次开发
可以方便地对JUnit进行扩展

JUnit框架组成

对测试目标进行测试的方法与过程集合，可称为测试用例(TestCase)。
测试用例的集合，可容纳多个测试用例(TestCase)，将其称作测试包(TestSuite)。
测试结果的描述与记录(TestResult) 。
测试过程中的事件监听者(TestListener)。
每一个测试方法所发生的与预期不一致状况的描述，称其测试失败元素(TestFailure)
JUnit Framework中的出错异常(AssertionFailedError)

JUnit注解(Annotation)

@Test：测试方法，表明这是一个测试方法。在Junit中将会自动被执行
@Before：初始化方法，在任何一个测试执行之前必须执行的代码
@After：释放资源，在任何测试执行之后需要进行的收尾工作
@Ignore：忽略的测试方法，该方法尚未完成，暂不参与此次测试
@BeforeClass：针对所有测试，只执行一次
@AfterClass：针对所有测试，将会在所有测试方法执行结束后执行一次


	`@BeforeClass –> @Before –> @Test –> @After –> @AfterClass`

JUnit断言

assertTrue|False(boolean condition)：判定结果是否为真|假
如果断言成立，继续运行后续测试；
如果不成立，抛出AssertionFailedError异常
assertEquals([String message, ] expected,actual[,tolerance])：判定表达式是否相等