经典测试设计
- 经典测试设计主要解决如下问题
- 如何有效减少测试用例的数量
- 如何避免测试用例之间的冗余
- 如何满足测试覆盖率的要求
- 静态测试
- 静态分析
- 基于代码的分析
- 基于架构的分析
- 评审
评审通常是通过深入阅读和理解被检查的文档的方式完成。通过直接检查软件产品（软件开发周期中的各种文档）发现缺陷。- 六个阶段
IEEE std 1028-2008- 计划阶段
- 预备会阶段
- 个人准备阶段
- 评审会议阶段
- 返工阶段
- 跟踪结果阶段
- 优点
- 提高质量
- 提高有效性
测试人员提早介入，节省时间和降低成本 - 可预测性
动态测试是整个测试过程中最难预测和最难管理的活动之一。评审可以有效减少进入到动态测试的缺陷数量 - 培训目的
通过分享和讨论促进项目知识的传播 - 缺陷预防
- 遵循的原则
- 尽早开展评审活动
- 控制评审会的时间
- 评审的是软件产品而不是作者
- 每个评审员都必须有机会表达自己的观点，并且评审会议纪要必须完整
- 发现缺陷而不是字符缺陷，即避免讨论具体缺陷的解决方案
- 评审中发现的缺陷和问题应该划分不同的严重程度
- 评审团队必须给出最终评审意见
- 接受
- 有条件接受
- 不接受
- 开展形式
- 审查
- 技术评审
- 走查
- 非正式评审
结对编程，结对测试和代码交换 - 管理评审
- 审计
- 影响评审成功的因素
- 参与评审的人员没有时间保证，或者不具备必须的资格或者技术能力
- 项目计划时间的不准导致评审时间压力较大进而导致结果
- 评审员在准备阶段准备不足
- 没有文档或者文档不完备
- 没有管理层的支持，评审过程无法成功
- 六个阶段
- 静态分析
- 动态测试
- 基于结构的测试
又称白盒测试，基于测试对象的代码，数据或者系统架构，关注的是测试对象的内部结构测试人员需要具备一定的编程技能- 测试步骤
- 分析测试对象的具体实现和内部结构
- 识别测试对象的不同路径（选择合适的代码覆盖标准，如语句覆盖）
- 选择合适的输入数据覆盖测试对象的相关路径并确定期望结果
- 执行测试用例
- 比较测试对象的实际结果和期望结果
- 确定测试对象是否实现了正确的功能
- 存在的缺点
- 控制流路径将非常庞大，几乎不可能遍历
- 根据测试对象的规格说明所设计的代码可能在模块中遗漏了某些路径，而控制流依据测试对象实现的路径展开，所以无法发现遗漏的路径。
- 控制流本身正确，但缺陷仍可能存在于测试对象的语句中。
- 测试对象可能对大部分数据可以正确执行，但是对小部分数据无法正确执行。
- 线性代码序列和转换测试
主要针对LCSAJ覆盖来进行测试用例设计。LCSAJ指的是软件代码路径的片段，由控制流跳转跟着的序列代码构成。 - 判定条件测试
设计若干测试用例执行条件结果和判定结果 - 条件决定测试
对能够独立影响判定结果的单独条件的测试。测试对象的每个必要条件必须产生所有可能的输出结果至少一次，并且每个判定中的每一个条件必须能够独立影响一个判定的输出。即在其他条件不变的前提下仅改变这个条件的值，可以使判定结果发生改变。 - 条件组合测试
指测试用例覆盖每条语句中原子条件所有可能的取值结果组合，即每个判定中的所有可能的原子条件取值组合至少执行一次 - 条件测试
条件测试指的是设计若干测试用例执行不同条件的结果 - 语句测试
语句测试是指设计若干测试用例来执行程序代码中的语句。 - 判定测试
判定测试是一种针对判定结果设计测试用例的技术。尽管判定测试可以发现程序中的逻辑错误，但是并不能保证发现判定中的原子错误。 - 路径测试
设计测试用例来执行不同的路径。Tom McCabe提出了一种通过分析测试对象控制流图的拓扑结构来设计测试用例的方法。- 根据测试对象的源程序得到控制流图
- 计算控制流图的圈复杂度C
- 选择基本路径
- 为每条基本路径创建一个测试用例
- 执行测试用例
- 测试步骤
- 基于规格说明的测试
- 等价类划分
- 边界值分析
- 决策表
- 状态转换
- 结对测试
- 分类树
- 用例/场景测试
- 动态分析
- 基于结构的测试
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
