背景
团队现状
- 规定时间内无法随心所欲的设计大量测试用例
- 后期大段的系统测试时间和集成测试时间无法保证
- 无法有效地进行回归测试，回归测试占总测试量的比重太高。
- 开发人员提供的测试建议没时间采纳 用例有分层-P1级别是什么级别
团队目标
终极目标：保质提效 子目标：提升回归测试效率
- 缩减回归测试的范围
- 依靠自动化测试
自动化的收益 = 迭代次数X全手工执行成本-首次自动化成本-维护次数X维护成本 假设每次迭代均需要维护的话，上式简化为 自动化的收益 = 迭代次数X（全手动执行成本-维护成本）-首次自动化成本
自动化测试可能的价值：
- 帮助回归、节省人力
- 构建人工测试无法构建的场景、数据准备，或执行一些人工测试做不到的测试用例，有效提升测试覆盖率
- 前置测试，让测试和开发有可能并行，提升项目敏捷度，降低测试独占周期
测试独占周期：从交付测试开始到版本达到待发版状态的时间长度。
测试覆盖率：测试执行的用例总数/需要真正被执行的测试用例总数。 PS：分母中并不包含因为“担心影响到”、“害怕有问题”从而执行的大量低价值回归测试用例。
具体实践
- 关注开发实现。 测试从代码层面了解改动范围，参考开发的测试建议来独立的得出测试策略。
- 回归测试分析，深入理解测试分析。通过测试分析得出测试范围。
- 基于需求的测试分析
- 基于开发实现的测试分析 - 功能测试详细分析 - 性能测试详细分析 - 接口测试分析 - 稳定性测试分析 - 兼容性测试分析
- 找准测试对象。从最小对象入手
最佳实践
通过对二进制文件进行差异分析，建立函数体内部基本块的跳转流程图矩阵，通过新老两个版本的矩阵差异分析影响范围
遇到难题
强耦合会导致分析范围过大，使得回归测试的用例数并没有减少。
针对耦合的处理
对耦合进行分类
- 内容耦合
- 公共耦合
- 外部耦合
- 控制耦合
- 标记耦合
- 数据耦合
- 非直接耦合
