软件测试与维护
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
(1) 是否有不正确或遗漏了的功能。 (2) 在接口上，能否正确地接受输入数据， 能否产生正确的输 出信息。 (3) 访问外部信息是否有错。 (4) 性能上是否满足要求等。
Page 29
5.2.2 知识准备
黑盒测试法与白盒测试法
用黑盒法测试时，必须在所有可能的输入条件和输出条件中 确定测试数据。是否要对每个数据都进行穷举测试呢？例如测 试一个程序，需输入 3 个整数值。微机上，每个整数可能取值 有216个，3个整数值的排列组合数为 216×216×216=248≈3×1014。假设此程序执行一次为一毫秒， 用这些所有的数据去测试要用1万年！但这还不能算穷举测试， 还要输入一切不合法的数据。可见，穷举地输入测试数据进行 黑盒测试是不可能的。
“密码”
“pass10” “pass789” “pass000010” “pass”
“空格”
“pass”
“user”
“userpass”
“user0000011”
“userpass”
…………
…………
“预期结果”
进入系统 进入系统 进入系统 提示输入用户名 不能进入系统 提示无效用户名 不能进入系统 提示用户名太短 不能进入系统 提示用户名太长 不能进入系统
章软件测试与维护
任务5.1
SAGM系统登录测试
Page 2
5.1.1 案例Байду номын сангаас述
教职工津贴系统开发完毕，需要进行功能测试，本 案例要求进行登录功能测试，设计详细的测试用例，完 成黑盒测试。
Page 3
5.1.2 案例分析
任何程序、系统中的问题，和产品设计书的不一致性， 不能满足用户的需求
必须意识到：“软件” ≠ 编程，它有自己的生命周 期 (life cycle)。大型软件系统的开发与其它工程项目 如建造桥梁、制造飞机、轮船等的开发是同理的。
Page 8
缺陷成本
5.1.3 知识准备
Page 9
5.1.3 知识准备
软件测试的基本方法
根据G.J. Myers观点--软件测试的目: 软件测试是为了发现错误而执行程序的过程 一个好的测试能够在第一时间发现程序中存在的错误 一个好的测试是发现了至今尚未发现的错误的测试。
软件测试是质量控制的重要手段，保证客 户拿到或用户使用高质量的软件产品
…………
说明
正确的用户名和密码(6位) 正确的用户名和密码(7-9位) 正确的用户名和密码(10位) 用户名为空
用户名为空格
用户名小于6位
用户名大于10位
………………
Page 26
5.1.5 拓展训练
教职工津贴系统中，完成用户添加、修改、删除的 功能测试，设计详细的测试用例，完成黑盒测试。
Page 27
所以，黑盒法和白盒法都不能使测试达到彻底。为了用有限的测试 发现更多的错误，需精心设计测试用例。黑盒法、 白盒法是设计测试 用例的基本策略，每一种方法对应着多种设计测试用例的技术，每种 技术可达到一定的软件质量标准要求。 下面分别介绍这两类方法对应 的各种测试用例设计技术。
Page 32
5.2.2 知识准备
程水平和习惯有很大的关系
对测试错误结果一定要有一个确认的过程。
Page 14
5.1.3 知识准备
测试方法
黑盒子和白盒子 静态的和动态的 文档、代码审查 数据输入边界条件法 等价划分、数据流程图 状态变换图 逻辑路径法
Page 15
5.1.3 知识准备
黑盒子和白盒子
客户需求
软件测试的原则
应当把“尽早和不断地测试”作为测试人员的座右铭
回归测试的关联性一定要引起充分的注意，修改一个错误
而引起更多错误出现的现象并不少见
测试应从“小规模”开始，逐步转向“大规模”。
不可将测试用例置之度外，排除随意性。
必须彻底检查每一个测试结果。
一定要注意测试中的错误集中发生现象，这和程序员的编
2.
该方法把测试对象看作一个打开的盒子， 测试人员须了解 程序的内部结构和处理过程，以检查处理过程的细节为基础，
Page 31
5.2.2 知识准备
黑盒测试法与白盒测试法
白盒法也不可能进行穷举测试，企图遍历所有的路径， 往往是做 不到的。如测试一个循环20次的嵌套的IF语句， 循环体中有5条路径。 测试这个程序的执行路径为520， 约为1014 如果每毫秒完成一个 路径的测试， 测试此程序需3170年！ 对于白盒测试，即使每条路 径都测试了，程序仍可能有错。 例如要求编写一个升序的程序，错编 成降序程序（功能错）， 就是穷举路径测试也无法发现。再如由于疏 忽漏写了路径， 白盒测试也发现不了。
代码完成文件包,功能详细设计说明书 最终技术文档
系统测试
代码修改后的文件包 完整测试用例,完备的测试计划
确认测试
代码冻结文件包 确认测试用例
版本发布
代码发布文件包 测试计划检查清单
Page 20
输出
市场需求分析会议记要 , 功能设计, 技术设计 测试计划, 测试用例
完整测试用例,完备的测试计划, 缺陷报告, 功能验证测试报告
软件测试分类
测试阶段或层次
验收测试
系统测试
集成测试
单元测试
功能测试 强壮性测试 性能测试
适用性测试 安全性测试 可靠性测试
白盒测试
方法 黑盒测试
目标/特性
Page 19
5.1.3 知识准备
软件测试阶段
阶段
输入
需求分析
需求定义, 市场分析文档, 相关技术文档
设计审查 功能验证
市场需求文档, 技术设计文档
2.
该方法把测试对象看作一个打开的盒子， 测试人员须了解 程序的内部结构和处理过程，以检查处理过程的细节为基础，
Page 30
5.2.2 知识准备
黑盒测试法与白盒测试法
用黑盒法测试时，必须在所有可能的输入条件和输出条件中 确定测试数据。是否要对每个数据都进行穷举测试呢？例如测 试一个程序，需输入 3 个整数值。微机上，每个整数可能取值 有216个，3个整数值的排列组合数为 216×216×216=248≈3×1014。假设此程序执行一次为一毫秒， 用这些所有的数据去测试要用1万年！但这还不能算穷举测试， 还要输入一切不合法的数据。可见，穷举地输入测试数据进行 黑盒测试是不可能的。
如图5.1是一个被测程序的程序流程图。
如果能测试路径124，就保证每个语句至少执行一次，选 择测试数据为
a=2 ， b=0， x=3
输入此组数据， 就能达到语句覆盖标准。
Page 34
2)
判定覆盖指设计足够的测试用例， 使得被测程序中每个判 定表达式至少获得一次“真”值和“假”值，从而使程序的每 一个分支至少都通过一次， 因此判定覆盖也称分支覆盖。
设计测试用例，只要通过路径124, 135或者125, 134， 就达 到判定覆盖标准。
选择两组数据： a=3， b=0， x=1（通过路径125）
a=2， b=1， x=2（通过路径134）
对于多分支（嵌套IF, CASE）的判定，判定覆盖要使得每 一个判定表达式获得每一种可能的值来测试。
Page 35
Page 22
5.1.4 案例实现
简单：能够正确处理用户登录 一般： 输入正确的用户名和密码可以进入系统 输入用户名或密码错误无法进入系统
Page 23
5.1.4 案例实现
详细：用户身份合法性验证
用户名验证
正常用户名的输入
含有特殊字符的用户名
为空或含有空格
字母大小写无关性测试
Page 5
5.1.3 知识准备
软件缺陷的产生
① 技术问题 ② 算法错误，语法错误，计算和精度问题，接口参数传
递不匹配
③ 团队工作 ④ 误解、沟通不充分
⑤ 软件本身 ⑥ 文档错误、用户使用场合(user scenario)， ⑦ 时间上不协调、或不一致性所带来的问题 ⑧ 系统的自我恢复或数据的异地备份、灾难性恢复等问
采用相应的方法去设计测试用例，从而提高测试的效率，更多地发 现错误，提高程序的可靠性。 ⑨ 对发现错误较多的程序段，应进行更深入的测试。一般来说，一段 程序中已发现的错误数越多，其中存在的错误概率也就越大。 ⑩ 重视文档，妥善保存一切测试过程文档（测试计划、测试用例、测 试报告等）
Page 13
5.1.3 知识准备
Page 10
5.1.3 知识准备
软件测试误区 误区一：如果发布出去的软件有质量问题，都是软件测试 人员的错 误区二：软件测试技术要求不高，至少比编程容易多了 误区三：有时间就多测试一些，来不及就少测试一些 误区四：软件测试是测试人员的事，与开发人员无关 误区五：根据软件开发瀑布模型，软件测试是开发后期的 一个阶段
题
Page 6
软件缺陷构成
5.1.3 知识准备
其他, 6% 代码, 15%
设计, 25%
规格说明书, 54%
Page 7
5.1.3 知识准备
在真正的程序测试之前，通过审查、评审会可以发现更多的缺陷。 规格说明书的缺陷会在需求分析审查、设计、编码、测试等过程中会 逐步发现，而不能在需求分析一个阶段发现
非法用户
密码验证
正常密码
含有特殊字符的密码
字母大小写敏感性测试
为空或含有空格
Page 24
5.1.4 案例实现
步骤：
1、输入<<<用户名>>> 2、输入<<<密码>>> 3、点击[OK]按钮
结果：
<<<预期结果>>>
Page 25
5.1.4 案例实现
“用户名”
“user10” “user789” “user000010” “”
由于白盒测试是结构测试，所以被测对象基本上 是源程序， 以程序的内部逻辑结构为基础设计测试 用例。
1. 追求程序内部的逻辑结构覆盖程度，当程序中有 循环时， 覆盖每条路径是不可能的，要设计使覆盖 程度较高的或覆盖最有代表性的路径的测试用例。下
Page 33
1)
为了提高发现错误的可能性，在测试时应该执行到程序 中的每一个语句。 语句覆盖是指设计足够的测试用例，使被 测程序中每个语句至少执行一次。
任务5.2
SAGM系统测试用例设计
Page 28
5.2.2 知识准备
黑盒测试法与白盒测试法
1. 该方法把被测试对象看成一个黑盒子，测试人员完全不考虑程序的内 部结构和处理过程，只在软件的接口处进行测试， 依据需求说明书，检 查程序是否满足功能要求。因此， 黑盒测试又称为功能测试或数据驱动 测试。 通过黑盒测试主要发现以下错误：
输入
输出 事件驱动
结构测试 逻辑驱动测试
功能测试 数据驱动测试
Page 16
5.1.3 知识准备
静态的和动态的
主持人 内审员 作者
技术专业人员
列席人员
不正式 互审
记录员
用户代表
走读
正式 审查会议
Page 17
运行程序
5.1.3 知识准备
自动测试和手工测试
Page 18
手工模拟用户 操作
5.1.3 知识准备
实践证明：对软件进行充分的测试 才能够有效的保证软件质量！
Page 4
5.1.3 知识准备
IEEE (1983) 729 软件缺陷一个标准的定义： 从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错
误、毛病等各种问题； 从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。
软件缺陷的主要类型/现象： 功能、特性没有实现或部分实现 设计不合理，存在缺陷 实际结果和预期结果不一致 运行出错，包括运行中断、系统崩溃、界面混乱 数据结果不正确、精度不够 用户不能接受的其他问题，如存取时间过长、界面不美观
Page 11
5.1.3 知识准备
软件测试的原则
① 所有测试的标准都是建立在用户需求之上。 ② 软件测试必须基于“质量第一”的思想去开展各项工作，当时间和
质量冲突时，时间要服从质量。 ③ 事先定义好产品的质量标准，只有有了质量标准，才能根据测试的
结果，对产品的质量进行分析和评估。 ④ 软件项目一启动，软件测试也就是开始，而不是等程序写完，才开
缺陷报告 缺陷状态报告 项目阶段报告 缺陷状态报告 缺陷报告审查 版本审查
当前版本已知问题的清单 版本发布报告
5.1.3 知识准备
测试阶段（SDLC)
Page 21
5.1.4 案例实现
需求： 用户名长度为6至10位（含6位和10位） 用户名由字符（a-z、A-Z）和数字（0-9）组成 不能为空、空格和特殊字符 密码规则同用户名规则
始进行测试。 ⑤ 穷举测试是不可能的。甚至一个大小适度的程序，其路径排列的数
量也非常大，因此，在测试中不可能运行路径的每一种组合。
Page 12
5.1.3 知识准备
软件测试的原则
⑥ 第三方进行测试会更客观，更有效。 ⑦ 软件测试计划是做好软件测试工作的前提。 ⑧ 测试用例是设计出来的，不是写出来的，所以要根据测试的目的，
Page 29
5.2.2 知识准备
黑盒测试法与白盒测试法
用黑盒法测试时，必须在所有可能的输入条件和输出条件中 确定测试数据。是否要对每个数据都进行穷举测试呢？例如测 试一个程序，需输入 3 个整数值。微机上，每个整数可能取值 有216个，3个整数值的排列组合数为 216×216×216=248≈3×1014。假设此程序执行一次为一毫秒， 用这些所有的数据去测试要用1万年！但这还不能算穷举测试， 还要输入一切不合法的数据。可见，穷举地输入测试数据进行 黑盒测试是不可能的。
“密码”
“pass10” “pass789” “pass000010” “pass”
“空格”
“pass”
“user”
“userpass”
“user0000011”
“userpass”
…………
…………
“预期结果”
进入系统 进入系统 进入系统 提示输入用户名 不能进入系统 提示无效用户名 不能进入系统 提示用户名太短 不能进入系统 提示用户名太长 不能进入系统
章软件测试与维护
任务5.1
SAGM系统登录测试
Page 2
5.1.1 案例Байду номын сангаас述
教职工津贴系统开发完毕，需要进行功能测试，本 案例要求进行登录功能测试，设计详细的测试用例，完 成黑盒测试。
Page 3
5.1.2 案例分析
任何程序、系统中的问题，和产品设计书的不一致性， 不能满足用户的需求
必须意识到：“软件” ≠ 编程，它有自己的生命周 期 (life cycle)。大型软件系统的开发与其它工程项目 如建造桥梁、制造飞机、轮船等的开发是同理的。
Page 8
缺陷成本
5.1.3 知识准备
Page 9
5.1.3 知识准备
软件测试的基本方法
根据G.J. Myers观点--软件测试的目: 软件测试是为了发现错误而执行程序的过程 一个好的测试能够在第一时间发现程序中存在的错误 一个好的测试是发现了至今尚未发现的错误的测试。
软件测试是质量控制的重要手段，保证客 户拿到或用户使用高质量的软件产品
…………
说明
正确的用户名和密码(6位) 正确的用户名和密码(7-9位) 正确的用户名和密码(10位) 用户名为空
用户名为空格
用户名小于6位
用户名大于10位
………………
Page 26
5.1.5 拓展训练
教职工津贴系统中，完成用户添加、修改、删除的 功能测试，设计详细的测试用例，完成黑盒测试。
Page 27
所以，黑盒法和白盒法都不能使测试达到彻底。为了用有限的测试 发现更多的错误，需精心设计测试用例。黑盒法、 白盒法是设计测试 用例的基本策略，每一种方法对应着多种设计测试用例的技术，每种 技术可达到一定的软件质量标准要求。 下面分别介绍这两类方法对应 的各种测试用例设计技术。
Page 32
5.2.2 知识准备
程水平和习惯有很大的关系
对测试错误结果一定要有一个确认的过程。
Page 14
5.1.3 知识准备
测试方法
黑盒子和白盒子 静态的和动态的 文档、代码审查 数据输入边界条件法 等价划分、数据流程图 状态变换图 逻辑路径法
Page 15
5.1.3 知识准备
黑盒子和白盒子
客户需求
软件测试的原则
应当把“尽早和不断地测试”作为测试人员的座右铭
回归测试的关联性一定要引起充分的注意，修改一个错误
而引起更多错误出现的现象并不少见
测试应从“小规模”开始，逐步转向“大规模”。
不可将测试用例置之度外，排除随意性。
必须彻底检查每一个测试结果。
一定要注意测试中的错误集中发生现象，这和程序员的编
2.
该方法把测试对象看作一个打开的盒子， 测试人员须了解 程序的内部结构和处理过程，以检查处理过程的细节为基础，
Page 31
5.2.2 知识准备
黑盒测试法与白盒测试法
白盒法也不可能进行穷举测试，企图遍历所有的路径， 往往是做 不到的。如测试一个循环20次的嵌套的IF语句， 循环体中有5条路径。 测试这个程序的执行路径为520， 约为1014 如果每毫秒完成一个 路径的测试， 测试此程序需3170年！ 对于白盒测试，即使每条路 径都测试了，程序仍可能有错。 例如要求编写一个升序的程序，错编 成降序程序（功能错）， 就是穷举路径测试也无法发现。再如由于疏 忽漏写了路径， 白盒测试也发现不了。
代码完成文件包,功能详细设计说明书 最终技术文档
系统测试
代码修改后的文件包 完整测试用例,完备的测试计划
确认测试
代码冻结文件包 确认测试用例
版本发布
代码发布文件包 测试计划检查清单
Page 20
输出
市场需求分析会议记要 , 功能设计, 技术设计 测试计划, 测试用例
完整测试用例,完备的测试计划, 缺陷报告, 功能验证测试报告
软件测试分类
测试阶段或层次
验收测试
系统测试
集成测试
单元测试
功能测试 强壮性测试 性能测试
适用性测试 安全性测试 可靠性测试
白盒测试
方法 黑盒测试
目标/特性
Page 19
5.1.3 知识准备
软件测试阶段
阶段
输入
需求分析
需求定义, 市场分析文档, 相关技术文档
设计审查 功能验证
市场需求文档, 技术设计文档
2.
该方法把测试对象看作一个打开的盒子， 测试人员须了解 程序的内部结构和处理过程，以检查处理过程的细节为基础，
Page 30
5.2.2 知识准备
黑盒测试法与白盒测试法
用黑盒法测试时，必须在所有可能的输入条件和输出条件中 确定测试数据。是否要对每个数据都进行穷举测试呢？例如测 试一个程序，需输入 3 个整数值。微机上，每个整数可能取值 有216个，3个整数值的排列组合数为 216×216×216=248≈3×1014。假设此程序执行一次为一毫秒， 用这些所有的数据去测试要用1万年！但这还不能算穷举测试， 还要输入一切不合法的数据。可见，穷举地输入测试数据进行 黑盒测试是不可能的。
如图5.1是一个被测程序的程序流程图。
如果能测试路径124，就保证每个语句至少执行一次，选 择测试数据为
a=2 ， b=0， x=3
输入此组数据， 就能达到语句覆盖标准。
Page 34
2)
判定覆盖指设计足够的测试用例， 使得被测程序中每个判 定表达式至少获得一次“真”值和“假”值，从而使程序的每 一个分支至少都通过一次， 因此判定覆盖也称分支覆盖。
设计测试用例，只要通过路径124, 135或者125, 134， 就达 到判定覆盖标准。
选择两组数据： a=3， b=0， x=1（通过路径125）
a=2， b=1， x=2（通过路径134）
对于多分支（嵌套IF, CASE）的判定，判定覆盖要使得每 一个判定表达式获得每一种可能的值来测试。
Page 35
Page 22
5.1.4 案例实现
简单：能够正确处理用户登录 一般： 输入正确的用户名和密码可以进入系统 输入用户名或密码错误无法进入系统
Page 23
5.1.4 案例实现
详细：用户身份合法性验证
用户名验证
正常用户名的输入
含有特殊字符的用户名
为空或含有空格
字母大小写无关性测试
Page 5
5.1.3 知识准备
软件缺陷的产生
① 技术问题 ② 算法错误，语法错误，计算和精度问题，接口参数传
递不匹配
③ 团队工作 ④ 误解、沟通不充分
⑤ 软件本身 ⑥ 文档错误、用户使用场合(user scenario)， ⑦ 时间上不协调、或不一致性所带来的问题 ⑧ 系统的自我恢复或数据的异地备份、灾难性恢复等问
采用相应的方法去设计测试用例，从而提高测试的效率，更多地发 现错误，提高程序的可靠性。 ⑨ 对发现错误较多的程序段，应进行更深入的测试。一般来说，一段 程序中已发现的错误数越多，其中存在的错误概率也就越大。 ⑩ 重视文档，妥善保存一切测试过程文档（测试计划、测试用例、测 试报告等）
Page 13
5.1.3 知识准备
Page 10
5.1.3 知识准备
软件测试误区 误区一：如果发布出去的软件有质量问题，都是软件测试 人员的错 误区二：软件测试技术要求不高，至少比编程容易多了 误区三：有时间就多测试一些，来不及就少测试一些 误区四：软件测试是测试人员的事，与开发人员无关 误区五：根据软件开发瀑布模型，软件测试是开发后期的 一个阶段
题
Page 6
软件缺陷构成
5.1.3 知识准备
其他, 6% 代码, 15%
设计, 25%
规格说明书, 54%
Page 7
5.1.3 知识准备
在真正的程序测试之前，通过审查、评审会可以发现更多的缺陷。 规格说明书的缺陷会在需求分析审查、设计、编码、测试等过程中会 逐步发现，而不能在需求分析一个阶段发现
非法用户
密码验证
正常密码
含有特殊字符的密码
字母大小写敏感性测试
为空或含有空格
Page 24
5.1.4 案例实现
步骤：
1、输入<<<用户名>>> 2、输入<<<密码>>> 3、点击[OK]按钮
结果：
<<<预期结果>>>
Page 25
5.1.4 案例实现
“用户名”
“user10” “user789” “user000010” “”
由于白盒测试是结构测试，所以被测对象基本上 是源程序， 以程序的内部逻辑结构为基础设计测试 用例。
1. 追求程序内部的逻辑结构覆盖程度，当程序中有 循环时， 覆盖每条路径是不可能的，要设计使覆盖 程度较高的或覆盖最有代表性的路径的测试用例。下
Page 33
1)
为了提高发现错误的可能性，在测试时应该执行到程序 中的每一个语句。 语句覆盖是指设计足够的测试用例，使被 测程序中每个语句至少执行一次。
任务5.2
SAGM系统测试用例设计
Page 28
5.2.2 知识准备
黑盒测试法与白盒测试法
1. 该方法把被测试对象看成一个黑盒子，测试人员完全不考虑程序的内 部结构和处理过程，只在软件的接口处进行测试， 依据需求说明书，检 查程序是否满足功能要求。因此， 黑盒测试又称为功能测试或数据驱动 测试。 通过黑盒测试主要发现以下错误：
输入
输出 事件驱动
结构测试 逻辑驱动测试
功能测试 数据驱动测试
Page 16
5.1.3 知识准备
静态的和动态的
主持人 内审员 作者
技术专业人员
列席人员
不正式 互审
记录员
用户代表
走读
正式 审查会议
Page 17
运行程序
5.1.3 知识准备
自动测试和手工测试
Page 18
手工模拟用户 操作
5.1.3 知识准备
实践证明：对软件进行充分的测试 才能够有效的保证软件质量！
Page 4
5.1.3 知识准备
IEEE (1983) 729 软件缺陷一个标准的定义： 从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错
误、毛病等各种问题； 从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。
软件缺陷的主要类型/现象： 功能、特性没有实现或部分实现 设计不合理，存在缺陷 实际结果和预期结果不一致 运行出错，包括运行中断、系统崩溃、界面混乱 数据结果不正确、精度不够 用户不能接受的其他问题，如存取时间过长、界面不美观
Page 11
5.1.3 知识准备
软件测试的原则
① 所有测试的标准都是建立在用户需求之上。 ② 软件测试必须基于“质量第一”的思想去开展各项工作，当时间和
质量冲突时，时间要服从质量。 ③ 事先定义好产品的质量标准，只有有了质量标准，才能根据测试的
结果，对产品的质量进行分析和评估。 ④ 软件项目一启动，软件测试也就是开始，而不是等程序写完，才开
缺陷报告 缺陷状态报告 项目阶段报告 缺陷状态报告 缺陷报告审查 版本审查
当前版本已知问题的清单 版本发布报告
5.1.3 知识准备
测试阶段（SDLC)
Page 21
5.1.4 案例实现
需求： 用户名长度为6至10位（含6位和10位） 用户名由字符（a-z、A-Z）和数字（0-9）组成 不能为空、空格和特殊字符 密码规则同用户名规则
始进行测试。 ⑤ 穷举测试是不可能的。甚至一个大小适度的程序，其路径排列的数
量也非常大，因此，在测试中不可能运行路径的每一种组合。
Page 12
5.1.3 知识准备
软件测试的原则
⑥ 第三方进行测试会更客观，更有效。 ⑦ 软件测试计划是做好软件测试工作的前提。 ⑧ 测试用例是设计出来的，不是写出来的，所以要根据测试的目的，