-
判定表（Decision Table）驱动
2007-04-16 16:31:52
判定表由四部分组成：
条件桩（Condition Stub）：列出了问题的所有条件，除了某些问题对条件的先后次序有特定 要求外，
通常在这里列出的条件，其先后次序无关紧要。
动作桩（Action Stub）：列出问题规定可能采取的操作。
条件项（Condition Entry）：针对左边条件的取值，在所有可能的情况下，给出真假值。
动作项（Action Entry）：在条件项的各组取值情况下采取的动作。
建立判定表的步骤：
① 确定规则的个数。
② 列出所有条件桩和动作桩。
③ 填入条件项。
④ 填入动作桩和动作项。
⑤ 化简。
适合于使用判定表设计测试用例的条件：
① 规格说明以判定表形式给出，或是很容易转换成判定表。
② 条件的排列顺序不会也不应影响执行那些操作。
③ 规则的排列顺序不会也不应影响执行那些操作。
④ 每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。
⑤ 如果某一规则得到满足要执行多个操作，这些操作的执行顺序无关紧要。
-
正交实验设计法
2007-04-16 16:28:20
概念：
正交实验设计法：从大量实验点中挑选出适量的、有代表性的点，应用依据伽罗瓦理论导出的“正交
表”，合理地安排实验的一种科学的实验设计方法。
实验的指标：在正交实验设计方法中，判断实验结果优劣的标准。
因子：影响实验指标的条件。
因子的水平：影响实验因子的。
步骤：
① 提取功能说明，构造因子状态表。
② 加权筛选，生成因素分析表。
③ 利用正交表构造测试数据集。
优点：
① 节省测试工作工时。
② 可控制生成的测试用例数量。
③ 测试用例具有一定的覆盖度。
-
因果图（Cause-Effect Graphing）
2007-04-16 16:23:19
利用因果图导出测试用例的步骤：
① 分析程序规格说明的描述中，哪些是原因，哪些是结果。原因常常是输入条件或是输入条件的等价
类，而结果是输出条件。
② 分析程序规格说明的描述中语义的内容，并将其表示成连接各个原因与各个结果的“因果图”。
③ 由于语法或环境的限制，有些原因和结果的组合情况是不可能出现的。为表明这些特定的情况，在因
果图上使用若干个特殊的符号标明约束条件。
④ 把因果图转换成判定表。
⑤ 把判定表中每一列表示的情况写成测试用例。
-
边界值分析(Boundary-value Analysis)
2007-04-16 16:18:35
边界值分析
① 如果输入条件规定了取值范围，或是规定了值的个数，则应以该范围的边界内及刚刚超出范围的边界
外的值，或是分别对最大、最小个数及稍小于最小、稍大于最大个数作为测试用例。
② 针对规格说明的每个输出条件使用前面的第①条原则。
③ 如果程序规格说明中提到的输入或输出域是个有序集合（如顺序文件、表格等），就应注意选取有序
集的第一个或最后一个元素作为测试用例。
④ 分析规格说明，找出其它的可能边界条件。
-
等价类划分（equivalence partition）
2007-04-16 16:05:11
1．等价类划分
定义：把程序的输入域划分为成若干部分，然后从每个部分中选取少数代表性数据当作测试用例。
l 有效等价类
对程序的规格说明是有意义的、合理的输入数据所构成的集合。
l 无效等价类
对程序的规格说明是无意义的、不合理的输入数据所构成的集合。
确定等价类的原则：
① 如果输入条件规定了取值范围或值的个数，则可确定一个有效等价类和两个无效等价类。
② 输入条件规定了输入值的集合，或是规定了“必须如何”的条件，则可确定一个有效等价类和一个
无效等价类。
③ 如果我们确知，已划分的等价类中各元素在程序的处理方式是不同的，则应将此等价类进一步划分
成更小的等价类。
输入条件
有效等价类
无效等价类
…
…
…
…
…
…
确定测试用例：
① 为每个等价类规定一个唯一的编号
② 设计一个测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步，最后使得所有有效
等价类均被测试用例所覆盖。
③ 设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步使所有无效等价类均被覆盖。
等价类划分示例(点击有更多惊喜哦:-))
-
人工测试技术
2007-04-16 15:58:21
人工测试技术
软件审查
l 制定计划
l 预审
l 准备
l 审查会
l 返工
l 终审
软件审查取得的数据
系统名 审查日期
被审查单元名 审查会主持人
参加审查人员 审查类别
本阶段审查发现的问题统计
问题类型
遗 漏
错 误
多 余
共 计
接口
数据
逻辑
输入/输出
性能
人为因素
标准
文档
语法
功能
测试环境
测试覆盖
其它
总 计
开发中前阶段发现的问题
所属阶段
问题类型
问题性质
修改次数
估计返工完成日期
返工工作量估计
软件测试步骤—系统测试（System Testing）
2007-04-16 15:57:03
系统测试（System Testing）：
① 恢复测试
② 安全测试
③ 强度测试
④ 性能测试
。。。。。。
软件测试步骤—确认测试(Validation Testing)
2007-04-16 15:55:44
确认测试（Validation Testing）：
检验所开发的软件是否能够按照用户提出的要求运行。
l 确认测试准则
l 配置审查
软件测试步骤—集成测试（Integrated Testing）
2007-04-16 15:52:40
集成测试（Integrated Testing）
l 递增式测试
① 自顶向下增式测试
② 自底向上增式测试
l 非递增式测试
软件测试步骤—单元测试(Unit Testing)
2007-04-16 15:44:27
单元测试（Unit Testing）：
解决的问题：
l 模块接口——对被测试的模块，信息能否正确无误地流入和流出。
l 局部数据结构——在模块工作过程中，其内部的数据能否保持其完整性，包括内部数据的内容、形式以及相互之间不发生错误。
l 边界条件——在为限制数据加工而设置的边界处，模块是否能够正常工作。
l 覆盖条件——模块的运行能否做到满足特定的逻辑覆盖。
l 出错处理——模块工作中发生了错误，其中的出错处理是否有效。
模块接口检查：
l 模块接受的输入参数与模块的变元个数是否一致？
l 参数与变元的属性是否匹配？
l 参数与变元所使用的单位是否一致？
l 传送给另一个被调用模块的变元个数与参数的个数是否相同？
l 传送给另一个被调用模块的变元属性与参数的属性是否匹配？
l 传送给另一个被调用模块的变元其单位是否与与参数的单位一致？
调用内部函数时，变元的个数、属性和次序是否正确？l 在模块有多个入口的情况下，是否有引用与当前入口无关的参数？
l 是否会修改知识作为输入值的变元？
l 出现全程变量时，这些变量是否在所有引用它们的模块中都有相同的定义？
l 有没有把常数当作变量来传送？
当模块执行了外部输入、输出时，还需要考虑：
l 文件属性是否正确？
l OPEN语句是否正确？
l 格式说明与输入、输出语句给出的信息是否一致？
l 缓冲区的大小是否与记录的大小匹配？
l 是否所有的文件在使用前均打开了？
l 对文件结束条件的判断与处理是否正确？
l 对输入、输出错误的处理是否正确？
l 有没有输出错误信息的正文错误？
局部数据结构：
l 不正确的或不相容的说明
l 不正确的初始化或缺省值
l 错误的变量名，如拼写错或缩写错。
l 不相容的数据类型
l 上溢、下溢或是地址错误
典型的计算错误：
l 对运算优先性的错误理解，或是错误的理解。
l 运算方式未加区分，发生了混合运算的情况。
l 初始化错误
l 计算精度不够
l 表达式中符号表示的错误
需要特别注意发现的错误包括：
l 不同数据类型的数据进行比较
l 逻辑运算符或其优先级用错
l 本应相等的数据，由于精度原因而不相等
l 变量本身或是比较有错
l 循环终止不正确，或循环不已
l 在遇到发散的循环时，不能摆脱出来
l 循环控制变量修改有错
出错处理：
l 对运行发生的错误描述难以理解
l 指明的错误并非实际遇到的错误
l 出错后，尚未进行出错处理便引入系统干预
l 意外的处理不当
l 提供的错误信息不足，以致无法找到出错的原因
软件测试策略
2007-04-16 15:38:28
1．静态方法与动态方法
静态方法的主要特征是不利用计算机运行被测试的程序，而是采用其它手段达到检测的目的。
可能发现的缺陷：
① 用错的局部变量和全局变量
② 不匹配的参数
③ 不适当的循环嵌套和分支嵌套
④ 不适当的处理顺序
⑤ 无终止的死循环
⑥ 未定义的变量
⑦ 不允许的递归
⑧ 调用并不存在的子程序
⑨ 遗漏了标号或代码
⑩ 不适当的连接
找到潜伏着问题的根源：
① 未使用过的变量
② 不会执行到的代码
③ 未引用过的标号
④ 可疑的计算
⑤ 潜在的死循环
提供间接涉及程序欠缺的信息
① 每一类型语句出现的次数
② 所用变量和常量的交叉引用表
③ 标识符的使用方式
④ 过程的调用层次
⑤ 违背编码规则
为进一步查错做准备
选择测试用例
进行符号测试
2．黑盒测试与白盒测试
黑盒测试（Black-box Testing）又称为功能测试、数据驱动测试或基于规格说明的测试（Specification-based Testing）。在完全不考虑程序内部结构和内部特性的情况下，测试者只知道该程序输入和输出之间的关系，或是程序的功能。
黑盒测试是从用户观点出发的测试。
白盒测试（White-box Testing）又称结构测试、逻辑驱动测试或基于程序的测试（Program-based Testing）。测试者可以看到被测试的源程序，可用以分析程序的内部构造，并且根据其内部构造设计测试用例。
黑盒测试与白盒测试的比较
黑盒测试
白盒测试
测试依据
根据用户看到的规格说明，即针对命令、信息、报表等用户界面及体现它们的输入数据与输出数据之间的对应关系，特别是针对功能进行测试。
根据程序的内部结构，比如语句的控制结构，模块间的控制结构以及内部数据结构等进行测试。
特
点
优点
能够站在用户立场上进行测试
能够对程序内部的特定部位进行覆盖测试。
缺点
① 不能测试程序内部特定部位
② 如果规格说明有误，则无法发现
① 无法检查程序的外部特性
② 无法对未实现规格说明的程序内部欠缺部分进行测试
方法举例
等价类划分
边界值分析
因果图
语句覆盖
判定覆盖
条件覆盖
判定/条件覆盖
路径覆盖
模块接口测试
排错
2007-04-16 15:34:41
排错方法：
① 内存信息转储（core dumps）
内存信息转储是在执行测试中，出现问题后，设法保留有关的现场信息。把所有寄存器和内存有关部分的内容打印出来，进行分析研究。
② 跟踪
典型事件包括进入、退出或是出现了：
l 特定子程序、语句、宏结构或数据库
l 与终端、打印机、磁盘或是其它外部设备的通信。
l 变量或表达式的值。
l 实时系统中定时启动或随机启动。
注：任何修改都需要重新编译源程序。
③ 打印语句
④ 使用排错程序
排错策略：
① 试错法（Trial and error）
② 回溯法（Backtraacking）或向后跟踪
③ 向前追踪（Forward tracking）
④ 二分法（Binary-Search）逼近法
⑤ 归纳法（Induction）
⑥ 演绎法（Deduction）
首先列举一些可能的原因或假设，然后逐个进行分析，排除那些不能确立的原因和假设，直到仅剩下一个被证实。
软件质量因素
2007-04-16 15:29:15
① 软件的运行特性
l 正确性（Correctness)：该软件是按要求去做的吗？
l 可靠性（Reliability）：该软件能够总是正确的工作吗？
l 效率性（Efficency）
l 完整性（Integrity）
l 可用性（Usability）：此软件容易掌握吗？
② 软件的修正特性
l 可维护性（Maintainability）：很容易理解、纠错、改写或扩充吗？能够维修它吗？
l 灵活性（Flexibility）：容易修改吗？
l 可测试性（Testability）：可以测试它吗》容易测试吗？
③ 软件的转移特性
l 可移植性（Portability）：可以在别的机器上运行这个软件吗？
l 可复用性（Reusability）：它能重复使用吗？
l 共运行性（Interoperability）：这个软件与另外的软件可以对接吗？要做到需要多少工作量？
软件质量保证（SQA——Software Quality Assurance）
包含：
① 采用技术手段
② 组织正式技术评审
③ 软件测试
④ 推行软件工程标准
⑤ 对软件的变更进行控制
⑥ 对软件质量进行度量
⑦ 对软件质量情况及时记录和报告
软件错误类型分析
2007-04-16 15:24:56
软件正确性差异
① 程序编写的无语法错误
② 程序在执行中未发现明显的运行错误
③ 程序中无不适当的语句
④ 程序运行时，能通过典型的有效的测试数据，而得到正确的预期结果。
⑤ 程序运行时，能通过典型的无效的测试数据，而得到正确的结果。
⑥ 程序运行时，能通过任何可能的数据，并给出正确的结果。
软件错误分类：
① 软件需求错误
② 功能和性能错误
③ 软件结构错误
④ 数据错误
⑤ 软件集成错误
⑥ 软件系统结构错误
⑦ 测试定义与测试执行错误
软件错误的后果
① 较小错误：对系统的输出结果有非实质性影响。
② 中等错误：对系统的运行有局部影响。
③ 较严重错误：系统的行为由于错误的干扰而出现明显不合理的现象。
④ 严重错误：系统运行不可跟踪，一时不能掌握其规律，时好时坏。
⑤ 非常严重的错误：系统运行中突然停机，且原因不明，且无法软启动。
⑥ 最严重错误：运行被测试的软件导致环境遭到破坏，或是造成事故，引起生命、财产的损失。
错误的大小与其后果严重程度并不成比例的。
程序中隐藏错误数量估计
1．撒播模型（Seeding Models）
N =(n/n播)*N播
其中：N表示程序中隐藏的错误数
N播表示刚开始往程序中播入的错误数
N表示排错中，发现的非播入的错误数
n播表示播入的错误数
2．回归模型（不是很明白）
① 线形回归分析
② 多项式回归分析
验证与确认
2007-04-16 15:10:58
验证：如何决定软件开发的每个阶段、每个步骤的产品正确无误，并与其前面的开发阶段和开发步骤的
产品相一致。
确认：如何决定最后的软件产品是否正确无误。
关系： 确认要回答的是：我们正在开发一个正确无误的软件产品吗？
验证要回答的是：我们正开发的软件产品是正确无误的吗？
回归测试：重新运行前已经正确无误的测试用例，以便消除由于软件修改而带来的各种错误。
程序测试：是为了发现错误而执行程序的过程。
经典测试名言：
不充分的测试是愚蠢的，过度的测试是罪孽。
测试只能表明错误的存在，而不能表明错误不存在。
能够发现程序错误的数据是好的数据，能够高效率揭露程序错误的测试是成功的测试。
计算机软件测试技术（学习笔记）
2007-04-05 10:01:29
[注]：所用图片均是从《计算机软件测试技术》这本书上截取的，所有权归原作者！
1.计算机软件的生存周期（Life Cyle）:
1.计划(Planning)
2.需求分析(Requirement Analysis)
3.设计(Design)
4.程序编写(Coding)
5.测试(Testing)
6.运行与维护(Run and Maintenance)
标题搜索
我的存档
数据统计
- 访问量: 27838
- 日志数: 30
- 建立时间: 2006-12-05
- 更新时间: 2008-12-12
