白盒测试
单元测试：一般用白盒测试（依据《详细设计说明书》LLD）
集成测试：一般用灰盒测试（依据《概要设计说明书》HLD）
系统测试：一般用黑盒测试（依据《需求规格说明书》SRS）
白盒测试：基于程序结构的逻辑驱动测试。（透明盒）
为什么进行白盒测试？
- 白盒测试在前期，使前期逻辑覆盖率达到一定指标，是软件内部逻辑结构问题能基本得到消除。
- 保证逻辑结构达到一定覆盖程度，给予软件代码质量更大的保证
- 白盒测试发现问题后解决成本较低
白盒测试的常用技术
白盒测试一般会用到静态分析和动态分析两类技术。常用的有:
- 静态分析:控制流分析、数据流分析、信息流分析等
- 动态分析:逻辑覆盖测试(分支测试、路径测试等)、程序插装等
逻辑覆盖测试
根据覆盖的对象不同，存在多种逻辑覆盖测试
语句覆盖 ：有百分之多少的语句被用例跑到
判定覆盖
条件覆盖
判定一条件覆盖
路径覆盖
................
逻辑覆盖率的统计通过程序插装来实现
程序插装
插入一些打印语句
黑盒测试
黑盒测试针对的被测对象可以是一个系统、一个子系统、一个模块，一个子模块、一个函数等
黑盒测试又可以被称为基于规格的测试。
（黑盒测试主要就是测输入数据和输出数据）
- 等价类划分法;
- 边界值分析法;
- 因果图分析法;
- 判定表法;
- 状态迁移法;
不管是什么测试方法，都是为了减少测试时的测试用例数，都是为了用尽量少的测试用例去完成测试，去发现更多的问题。
常见的黑盒测试类型
- 功能性测试，一种是顺序测试每个程序特性或功能，另一种途径是一个模块一个模块的测试，即每个功能在其最先调用的地方被测试;
- 容量测试，检测软件在处理海量数据时的局限性，能发现系统效率方面的问题;
- 负载测试，检测系统在一个很短时间内处理-个巨大的数据量或执行许多功能调用上的能力;
- 恢复性测试，主要保证系统在崩溃后能够恢复外部数据的能力;
灰盒测试
（灰盒测试主要就是测接口数据的）
如果既利用被测对象的整体特性信息，又利用被测对象的内部具体实现信息，采用的就是灰盒测试方法。两种信息占的比例不同，相应的灰度就不同。完全是整体特性信息，就是黑盒测试，完全是内部具体实现信息，就是白盒测试
三个盒测试的评估标准
白盒测试：逻辑覆盖率
黑河测试：需求规格覆盖率
灰盒测试：接口覆盖率
静态分析技术
不用过执行程序来测试
**主要有三种不同的程序测试可能性:*：
- 规则考虑程序是否满足编码，语法上是否具有一-致性和完整性;
- 考虑文档描述是否规范、准确、便于查阅;、
- 考虑程序和文档之间的一致性
动态分析技术
对运行的程序进行分析
常用动态分析工具功能
| 动态分析类型 | 工具的功能 |
|---|---|
| 测试覆盖率分析 | 测试对代码的检测范围 |
| 跟踪 | 跟踪程序执行期间的所有路径，例如所有变量的值等 |
| 调整 | 度量程序执行过程中使用 的资源 |
| 模拟 | 模拟系统的一部分、例如、无法获得的代码和硬件 |
| 断言检查 | 测试在复杂逻辑结构中是否某个条件已经被给出 |
常用黑盒动态测试工具
人工测试和自动化测试
一般来说，需要一些智力的、值执行一次的、控制测试质量的需要人工测试
重复多次、比较机械性的适用于自动化测试
自动化测试的限制
- 不能取代手工测试，自动化测试只能提高测试效率，不能提高测试有效性，即不可能发现跟多缺陷
- 手工测试比自动化测试发现的缺陷更多
- 对测试设计依赖性大，测试设计的不好会遗漏问题
- 自动化测试对软件开发具有很大的依赖性，开发商出现变更可能导致前面的自动化测试完全失效
- 工具本身并不具备想象力，工具不具有智能
自动化常用的因素
- 测试进度：对于测试进度短的，没有必要自动化，因为自动化要大量时间来准备。
- 人力要求：自动化用例设计人员、自动化执行人员、自动化计划方案书写人员需要一定的保障，初期要投入大量的人
- 版本的稳定：测试脚本要根据软件的 版本迭代而更新，所以如果软件版本更新频繁，不适合写脚本
- 版本应用：如果后期软件不进行应用的扩展就不写脚本
- 自动化率：一般用例自动化率 > 20%才写自动化脚本
- 版本规模：测试用例小的时候就不需要考虑自动化
覆盖率
.覆盖率概念
-
白盒覆盖率：语句、判定、条件、路径
-
灰盒覆盖率：接口（函数）
-
黑盒覆盖率：功能
覆盖率 = （至少一次被执行的 item 数）/item 的总数
item（项目数）：指的是前面的语句、判定、接口等等
- 测试用例设计不能一-味追求 覆盖率，因为测试成本随覆盖率的增加而增加。