测试的艺术_读后感

1. 测试的定义

测试是为发现错误而执行程序的过程。

2. 黑盒测试与白盒测试

2.1 黑盒测试又称数据驱动的测试或输入/输出驱动的测试。这种方法将程序视为一个黑盒子，测试目标与程序的内部机制完全无关，而是将重点集中在发下程序不按其规范运行的情况。这种方法中，测试数据来源于软件规范，判定的标准就是穷举输入测试。

2.2 白盒测试也称为逻辑驱动的测试，允许我们检查程序的内部逻辑结构。这种测试通过检查程序的内部逻辑结构获取测试数据。

3. 软件测试原则

3.1 测试用例中一个必须部分必须是对预期输出或结果的定义。

3.2 程序员应该避免测试自己编写的程序。

3.3 编写软件的组织不应当自己测试自己编写的软件。

3.4 应当彻底检查每个测试的执行结果。

3.5 测试用例的编写不仅应当根据有效的和预期的输入情况，也应当根据无效和未预期的输入情况。

3.6 检查程序是否做了其应该做的只是测试的一般，另一半是检查程序是否做了其不应该做的。

3.7 应当避免测试用例用后即弃，除非软件本身是一个一次性的软件。

3.8 计划测试任务时不能默许假定不会发现错误。

3.9 程序某部分存在位置错误的可能性，与该部分已发现的错误数量成正比。

3.10 测试是一项极富创造性，极富智力挑战性的工作。

4. 代码检查，走差和评审。

4.1 代码检查就是以组为单位阅读代码，它是一系列规程和错误检查技术的集合。执行代码检查之前，负责人应提前准备资料（流程、规范和用于代码检查的错误列表）。做法是由该程序开发人员逐行逐句的讲述程序的逻辑结构。讲述过程中一般是程序编码者本人发现很多错误；此外，检查人员还应该准备一份错误对照表，以便查看是否程序出现了列表中的错误。

4.2 代码走查与代码检查的相似处在于都是以组为单位的检查技术，并且也需要提前准备材料。然而代码走查和检查的会议流程不同。代码检查仅仅是阅读代码，而代码走查使用了计算机。测试人员会使用一些测试用例（程序模块或具有代表性的输入集和预期输出集）和数据沿程序的逻辑走一遍，并将程序的表现和状态记录下来。

 

5. 测试用例的设计方法

等价类划分，边界值分析，因果图分析，错误猜测，语句覆盖，条件覆盖，判定覆盖，判定\条件覆盖，多重条件覆盖等等。

一般的测试策略是：

5.1 推荐先使用黑盒测试方法，再使用白盒测试方法。

5.2 如果需求说明书中包涵输入条件组合的情况，则先使用因果图分析法。

5.3 在任何情况下都需要使用边界值分析法。

5.4 应该为输入和输出确定有效和无效的等价类，必要情况下对测试用例进行补充。

5.5 如果针对上述测试用例集检查程序的逻辑结构，则需根据条件覆盖，判定覆盖，判定\条件覆盖，多重条件覆盖编写测试用例。

 

6. 单元测试

单元测试（也叫模块测试）是对程序中单个子程序（模块）测试的过程。

6.1 测试用例的设计：单元测试倾向于白盒测试。是因为如果对一个大的软件进行测试，白盒测试不容易展开；后续的测试过程着眼于其它类型的错误（例如需求未满足）。因此，单元测试用例的设计过程为：使用一种或多重白盒测试策略分析模块的逻辑结构，然后使用黑盒测试方法针对模块的规格说明进行补充测试。

6.2 增量测试与非增量测试：非增量测试（崩溃测试）指的是先独立测试每个模块，然后将这些模块组装成完整的程序；增量测试（集成）指的是现将模块组装，然后进行测试。在一般情况下，增量测试使用的成本（时间，驱动模块和桩模块）较少，能尽早发现模块间的匹配问题，容易调试，程序测试的也更彻底。因此推荐使用增量测试。

6.3 自顶向下测试和自底向上测试：自顶向下测试指的是从程序的初始模块开始，逐渐增加后续模块的方法；自底向上的测试则是开始于终端模块，并往回测试。

二者的优缺点比较：

 

7. 功能测试与系统测试

7.1 功能测试：功能测试是一个发现软件与其规格说明不一致的过程。一般情况下，功能测试采用黑盒测试。

7.2 系统测试：系统测试与功能测试不同，规格说明不能作为系统测试的用例的基础。系统测试的目的在于：将系统与其初始目标进行比较。例如：能力测试，容量测试，易用性测试，安全性测试，性能测试，可靠性测试，可恢复性测试，兼容性测试等等。

 

8. 软件测试方法论

8.1 基于风险的测试：风险值＝风险概率x风险影响。根据风险值排列测试任务优先权。

8.2 基于案例剧情的测试：通过一系列步骤测试。侧重于系统动力学。

8.3 基于模型的测试：首先对待测系统进行建模，然后通过系统模型生成一组测试用例。用这些测试用例测试待测系统，判断得到的结果是否与模型的预期值是一致的。