标签：专题 错误 路径 程序 软件工程 测试 测试用例 软件测试
！！！注：文章内容均来自NUAA软件工程SGH老师的课件！！！撰写文章仅用作复习总结和记录
文章目录
1 软件测试概述
1.1 基本概念
-
软件错误：软件系统的功能和性能与预期不一致
-
目标：
- 发现软件中的错误，提高软件质量（不能证明程序无错）
- 好的测试方案是尽可能发现迄今为止尚未发现的错误的测试方案;
- 成功的测试是发现至今为止尚未发现的错误的测试
-
软件测试
- 为发现错误而执行程序的过程
- 根据软件开发各阶段的规格说明和程序的内部结构而精心设计的一批测试用例，并利用这些测试用例运行程序以及发现错误的过程
-
测试用例：
- 为测试设计的数据
- 测试用例 ::= 测试输入数据 + 预期输出数据
1.2 软件测试原则
原则
- 尽早地、不断地进行软件测试
- 程序员应避免检查自己的程序
- 在设计测试用例时应包括合理的输入条件和不合理的输入条件
- 充分注意测试中的群集现象（80-20原则：发现错误越多，说明残存错误越多）
- 严格执行测试计划，注意排除测试中的随意性
- 应当对测试结果做全面检查
- 妥善保管测试计划、测试用例、出错统计、和最终分析报告，为维护提供充分的资料
正确认识软件测试
- 完全测试程序是不可能的
- 软件测试是有风险的行为(没有测试到的功能被用户使用并发现了软件缺陷)
- 测试无法显示潜伏的软件缺
- 找到的软件缺陷越多，就说明软件缺陷越多（集群）
- 并非所有软件缺陷都能修复
- 没有足够的时间
- 修复的风险太大
- 不值得修复(用户可以预防)
- 难以说清的软件缺陷
- 产品说明书不断变化
1.3 软件测试方法
- 按照是否执行软件：分静态测试和动态测试。
- 按照测试用例的设计方法：分白盒测试法和黑盒测试法。
- 按照软件测试的策略和过程：可分为单元测试、集成测试、系统测试、验证测试和确认测试。
- 传统测试方法和面向对象测试的方法
–
2 软件测试方法（白盒/黑盒）
2.1 白盒测试
- 思想：已知程序内部工作程序，通过测试检验程序内部动作是否按规格说明书的规定正常运作
- 依据：针对程序的内部逻辑结构设计测试用例
- 特点：必须了解程序的内部工作流程
2.2 黑盒测试
- 思想：根据已知程序的功能和性能(而不是内部细节)，通过测试检验每个功能和性能是否正常
- 依据：程序的功能和性能描述
- 特点：知道程序的功能和性能，不必了解程序的内部结构和处理细节
软件开发和测试间的关系
测试信息流
- 软件配置 包括软件需求规格说明、软件设计规格说明、源代码等。
- 测试配置 包括测试计划、测试用例、测试驱动程序等。
- 测试工具 测试工具为测试的实施提供某种服务。例如，测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序以及驱动测试的工作等。
- 软件测试的信息流程
错误分类
- 按错误的影响和后果分类：较小错误；中等错误；较严重错误；严重错误；非常严重的错误；最严重的错误
- 按错误的性质和范围分类：功能错误；系统错误；加工错误；数据错误；代码错误
- 按软件生存期阶段分类：需求分析错误；规格说明错误；设计错误；编码错误
3 软件测试活动及策略
软件测试：从低层次抽象向高层次抽象过渡
软件测试的层次
-
单元测试：测试程序中每个模块是否有错（白盒）
- 定义：针对程序模块，进行正确性检验的测试
- 目的：发现各模块内部可能存在的各种差错
- 内容：模块接口测试；局部数据结构测试；路径测试；错误处理测试；边界测试
- 步骤（略）
-
集成测试：测试软件总体结构是否有错误（黑盒+部分白盒）
- 定义：组装软件的系统技术，即在单元测试的基础上，需要将所有模块按照设计要求组装成为系统
- 考虑因素：
- 各个模块连接的时候，接口的数据是否会丢失。（模块间接口）
- 一个模块的功能是否会对另一个模块的功能产生不利的影响。（模块间功能负面影响）
- 各个子功能组合起来，能否达到预期要求的父功能。（功能组合）
- 全局数据结构是否有问题。
- 单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。（误差积累、放大）
- 单个模块的错误是否会导致数据库错误
- 方法：一次性集成方式；增殖性集成方式（自顶向下；自底向上）
- 采用 混合增殖式测试
-
确认测试：测试软件是否满足用户需求（黑盒）
- 验证软件的功能、性能及其他特性是否与用户的要求一致。
- 由软件方、用户方共同参与。
- 有效性测试：效性测试是在模拟的环境(可能就是开发的环境)下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。
- 软件配置复查：软件配置复查的目的是保证软件配置的所有成分都齐全，各方面的质量都符合要求，具有维护阶段所必需的细节，而且已经编排好分类的目录。
- α测试：由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。
- β测试：多个用户在一个或多个用户的实际使用环境下进行的测试
-
系统测试：将软件系统与其他部分（数据库、硬件）集成后测试
- 目的是充分运行系统，验证系统各部件是否能正常工作并完成赋予的任务。
- 常见的系统测试：
- 恢复测试：检查系统容错能力（出错后多久能恢复）
- 安全测试：检查系统不受到非法侵入（面向security）
- 强度测试：检查系统对异常情况（最差工作环境）的抵抗能力
- 性能测试：检查实时性等性能要求
- 安装/卸载测试
4 设计软件测试方案
- 测试方案包括预定要测试的功能，应该输入的测试数据和预期的结果。
- 测试方案的目标：确定一组最可能发现某个错误或某类错误的测试数据。
4.1 白盒测试
-
如何设计测试用例？
-
逻辑覆盖准则：对一系列测试过程的总称，这组测试过程逐渐进行越来越完整的通路测试。
-
语句覆盖
- 选择足够多的测试数据，使被测程序中每个语句至少执行一 次
-
分支覆盖（判定）
- 每个语句必须至少执行一次,且每个判定的每种可能的结果都应该至少执行一次
- 比语句覆盖强
-
路径覆盖
- 不仅每个语句都至少执行一次,而且使判定表达式中的每个条件都取到各种可能的值
-
判定/条件覆盖
- 同时满足判定和条件的覆盖
-
条件组合覆盖
- 要求选取足够多的测试数据，使得每个判定表达式中条件的各种可能组合都至少出现一次
-
点覆盖
- 要求选取足够多的测试数据，使得程序执行路径至少经过程序图中每个节点一次。
- 和语句覆盖一致
-
边覆盖
- 选取足够多测试数据，使得程序执行路径至少经过程序图中每条边一次。
- 和判定覆盖一致.
-
路径覆盖
- 选取足够多测试数据，使程序的每条可能路径都至少执行一次(如果程序图中有环，则要求每个环至少经过一次)
- 特点：保证程序中每条可能的路径都至少执行一次；没有考虑程序的条件的各种可能组合情况；路径覆盖和条件组合覆盖结合起来，可以设计出检错能力更强的测试数据
-
4.2 基本路径（!）
基本路径测试的思想
- 基本路径：至少引入一个新语句or新判断的程序执行通道
- 测试用例的设计方法：流程图 —> 流图 —> 基本路径 —> 测试用例
- 流程图 —> 流图的示意图：
void Func(int nPosX, int nPosY) {
while (nPosX > 0) {
int nSum = nPosX + nPosY;
if (nSum > 1) {
nPosX--;
nPosY--;
}
else {
if (nSum < -1) nPosX -= 2;
else nPosX -= 4;
}
} // end of while
}
- 步骤
-
Step 1：根据程序的逻辑结构画出流程图
- 程序结构：如上。
- 示例： 如上。
-
Step 2：根据流程图画出流图
- 流图：刻画了程序的控制结构,但不涉及程序的过程性细节
- 节点：过程块，结合点，判定点
- 有向边
- 判定点不含复合条件，否则应按照下列方式增加判定点
- 示例：如上。
- 流图：刻画了程序的控制结构,但不涉及程序的过程性细节
-
Step 3：确定基本路径的集合
-
基本路径：流图的 复杂度（环路/圈复杂度） 正好是基本路径的数目
-
V(G) = E – N + 2
- V(G) = 11 - 9 + 2 = 4
-
V(G) = P + 1
- V(G) = 3 + 1 = 4
-
路径集合
- 1 - 11
- 1 - 2, 3 - 4, 5 - 10 - 1 - 11
- 1 - 2, 3 - 6 - 7 - 9 - 10 - 1 - 11
- 1 - 2, 3 - 6 - 8 - 9 - 10 - 1 - 11
-
示例：
-
-
Step 4：对每条基本路径设计测试用例
* 对于路径1 – 11
* nPosX 取-1, nPosY取任意值
* 1 - 2, 3 - 4, 5 - 10 - 1 - 11
* nPosX 取1, nPosY取1
* 对于路径1 - 2, 3 - 6 - 7 - 9 - 10 - 1 – 11
* nPosX 取1, nPosY取-1
* 1 - 2, 3 - 6 - 8 - 9 - 10 - 1 - 11
* nPosX 取1, nPosY取-3
-
4.3 黑盒测试（略）
- 等价分类法
- 边界分类法
- 排错法
- 原始法
- 回溯法
- 排除法
- 基于归纳和演绎的方法
软件测试 vx 调试
- 目的不同
- 软件测试的目的：发现错误
- 调试的目的：定位和纠正错误
- 独立性不同
- 软件测试由独立的测试小组进行
- 调试由原开发人员完成
基于case的软件测试和排错
- 静态分析器：通过静态的扫描源程序，找出可能导致程序出错的异常情况
- 代码审查器：检查源程序代码是否满足最基本的代码标准
- 断言处理器：检查程序员关于程序行为的断言在程序执行过程中是否成立
- 测试用例生成器
OO软件测试
- 类的测试（单元测试）
- 需要开发驱动程序
- 驱动程序的编写方式
- Main（）
- 调用被测类的成员函数
- 单独实现测试类，每个成员函数都需要测试
- 交互测试（集成测试）
- 需要开发驱动程序
- 对象对接收消息的顺序
- 继承的测试
- 先测父类，再测子类
- 相对于父类，子类的主要变化：新增方法；新增变量和属性；重写父类的方法，实现了父类的接口（虚函数）
思考：只要设计足够多的测试用例，软件测试是否完全可以发现软件中的所有错误？（×）
标签：专题,错误,路径,程序,软件工程,测试,测试用例,软件测试 来源： https://blog.csdn.net/weixin_46391486/article/details/121807639
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。