【HIT软件构造第二章复习】

确保程序正确性/健壮性的最普遍的手段：测试
1． 设计测试用例
2． 用Junit写测试程序
3． 自动化测试过程

一． 软件测试

提高软件质量的最好手段
确认是否达到用户需求
关注系统的某一面的质量特性
即使是最好的测试，也无法达到百分之百的无错误

残留缺陷率

1-10 kloc/defects: 典型的行业软件
0.1-1 kloc/defects: 高质量验证。Java库可能会达到这种级别的正确性。
0.01-0.1 kloc/defects: 最好的，安全关键的验证。NASA和像Praxis这样的公司可以达到这个水平。
测试的目标就是找到错误（与其他活动相反）
再好的测试也无法证明系统里不存在错误
What is a good test?
能发现错误、不冗余、最佳特性、别太复杂也别太简单

测试类型：单元测试、集成测试、系统测试、回归测试**

静态测试：在执行时没有实际执行程序 -检查、演练或检查被称为静态测试
动态测试：描述代码动态行为的测试
动态测试可以在程序100%完成之前就开始了，以测试代码的特定部分，并应用于离散的函数或模块。–典型的技术是使用存根/驱动程序或从调试器环境中执行。
静态测试vs动态测试：靠眼睛看vs撸起袖子使劲干

Testing vs debugging
测试：发现是否有错误
调试：识别错误根源，消除错误

白盒测试vs黑盒测试
白盒测试：对程序内部代码结构的测试
黑盒测试：对程序外部表现出来的行为的测试

为什么软件测试很困难
穷举+暴力=不可能
靠偶然测试没意义
基于样本的统计数据对软件测试意义不大—软件与产品的巨大差异

软件行为在离散输入空间中差距巨大：

1. 该系统似乎在广泛的输入范围中工作良好，然后在单个边界点上突然失效（大多数正确，少数点出错）
2. Bug出现往往不符合概率分布
   无统计分布规律可循

二． 测试用例

测试用例：输入+执行条件+期望结果
良好测试用例的优点：
最可能发现的错误
不重复、不冗余
最有效
既不简单与不复杂

三． 测试优先的编程/测试驱动开发

在写代码之前先写测试

过程：
先写spec，再写符合spec的测试用例
写代码、执行测试、有问题再改、、再执行测试用例、直到通过它
Spec描述了该函数的输入和输出行为
（写测试用例，就是理解、修正、完善你的spec设计的过程）

先写测试会节省大量的调试时间

TDD

测试驱动开发(TDD)是一个依赖于非常短的开发周期重复的开发过程：将需求转换为非常具体的测试用例，然后对软件进行改进，只通过新的测试。

四． 单元测试

针对软件的最小单元模型展开测试，隔离各个模块，容易定位错误和调试

五． 使用Junit进行自动化单元测试

六． 黑盒测试

用于检查代码功能，不关心内部实现细节
黑盒测试一般用于检测下列错误

1. 功能不正确或缺失
2. 接口错误
3. 数据结构或外部数据库访问中的错误
4. 行为或性能错误
5. 初始化和终止错误
   检查程序是否符合规约

等价类划分

基于等价类划分的测试：将被测函数的输入域划分为等价类，从等价类中导出测试用例
针对每个输入数据需要满足的约束条件，划分等价类（对称、传递、自反）
基于的假设：相似的输入，将会展示相似的行为。故可从每个等价类中选一个代表作为测试用例即可。从而可以降低测试用例数量

从正负的角度对二维空间进行等价类划分（正正，反反，正反，反正）

需要考虑数据的输入情况（所有）

边界值分析

大量的错误发生在输入域的“边界”而非中央
边界值分析方法是对等价类划分方法的补充
程序的行为可能在边界上发生突变
在等价类划分时，将边界作为等价类之一加入考虑

覆盖分区的两个极端
笛卡尔积：全覆盖（测试完备，但用例数量多，测试代价高）
覆盖每个取值：最少一次即可（测试用例少，代价低，但测试覆盖度未必高）

七． 白盒测试

黑盒测试完全从函数spec导出测试用例，不考虑函数内部实现，但是白盒测试要考虑内部实现细节
根据程序执行路径设计测试用例
白盒测试一般比较早执行
独立路径测试：对程序所有执行路径进行等价划分，找出有代表性的最简单的路径（例如循环只需进行一次），设计测试用例使每一条基本路径被至少覆盖1次

八． 覆盖度测试

代码覆盖度：已有的测试用例有多大程度覆盖了被测程序（通常用百分比衡量覆盖率）
代码覆盖度高（测试代价高）
函数覆盖、语句覆盖、分支覆盖、条件覆盖、路径覆盖
测试效果：路径覆盖>分支覆盖>语句覆盖
测试难度：路径覆盖>分支覆盖>语句覆盖
最彻底的白盒方法是覆盖程序中的每条路径，但路径数量巨大，难以全覆盖
实际当中，根据预先设定的覆盖度标准，逐步增加测试用例的数量，直到覆盖度达到标准

九． 集成测试

手工测试的代价太高，最好达到完全的自动化（自动调用被测函数、自动判定测试结果、自动计算覆盖度）

十． 回归测试

一旦程序被修改，重新执行之前的所有测试
A test is good if it elicits(显现) a bug记住这一点，每一个回归测试都是在代码的一个版本中完成的

十一． 在程序中文档化测试策略

测试策略（根据什么来选择测试用例）非常重要，需要在程序中显式记录下来
目的：在代码评审的过程中，其他人可以理解你的测试，并评判你的测试是否足够充分

总结

测试优先编程。在编写代码之前，请先编写测试。
为系统地选择测试用例的划分和边界。
白盒测试和声明覆盖范围，以填写一个测试套件。
单元-尽可能地测试每个模块，进行隔离。
自动回归测试，以防止bug返回。