健壮性和正确性
***健壮性:系统在不正常输入或不正常外部环境下仍能够表现正常的程度
***面向健壮性的编程:
处理未期望的行为和错误终止
即使终止执行,也要准确/无歧义的向用户展示全面的错误信息
错误信息有助于进行debug
***编程原则:总是假定用户恶意、假定自己的代码可能失败
把用户想象成白痴,可能输入任何东西
封闭实现细节,限定用户的恶意行为
考虑极端情况,没有“不可能”
***正确性:程序按照spec加以执行的能力,是最重要的质量指标!
![](/qrcode.jpg)
***正确性VS健壮性:
正确性:永不给用户错误的结果,倾向于直接报错,直接结束
健壮性:尽可能保持软件运行而不是总是退出,倾向于容错,程序内部已有容错机制
***对外的接口,倾向于健壮;对内的实现,倾向于正确
Throwable
一个异常类是从Throwable分离出来的类
Runtime异常、其他异常
Exception可分为两类:运行时异常 + 其他异常
***运行异常:由程序员在代码里处理不当造成
如果在代码中提前进行验证,这些故障就可以避免
e.g:可以通过检查数组的下标是否超过数组的长度以避免ArrayIndexOutOfBoundsException
可以通过检查变量是否为空以避免NullPointerException
***其他异常:由外部原因造成
即使在代码中提前加以验证,也无法完全避免失效发生。
Checked异常、Unchecked异常
***Unchecked exception:Error + RuntimeException
不需要在编译的时候用try…catch等机制处理
可以不处理,编译没问题,但执行时出现就导致程序失败
类似于编程语言中的dynamictype checking
***Checked exception:Throwable除去unchecked exception
必须捕获并指定错误处理器handler,否则编译无法通过
类似于编程语言中的static typechecking
Checked Exception 和 Unchecked Exception的区别
Checked异常的处理机制
用于exception的处理机制的五个关键字:try、catch、finally、throws、throw
throws:声明“本方法可能会发生xxx异常”
throw:抛出xxx异常
try、catch、finally:捕获并处理xxx异常
***方法要在定义和spec中明确声明所抛出的全部checked exception,以便调用该方法的client加以处理
***处理异常时,尽量在自己这里处理,实在不行就往上传
***释放资源:
***清理现场:printStackTrace()
自定义异常类
如果JDK提供的exception类无法充分描述你的程序发生的错误,可以创建自己的异常
自定义异常类的编写:
自定义异常类的使用:
***在抛出异常的时候,将现场信息记入异常
在异常处理时,利用这些信息给用户更有价值的帮助
断言的作用、应用场合
***断言:在开发阶段的代码中嵌入,检验某些“假设”是否成立。若成立,表明程序运行正常,否则表明存在错误。即是对代码中程序员所做假设的文档化,也不会影响运行时性能(在实际使用时,assertion 都会被disabled)
e.g
***两种格式:①assert condition; ②assert condition :message;
***为什么使用断言:
①记录和测试程序员的假设条件(如不变量是否符合条件)
②验证程序员是否理解正确
③快速发现错误
④增加程序的可信度
⑤假设将黑盒测试转换为白盒测试
使用断言的主要目的是为了在开发阶段调试程序、尽快避免错误
***断言用在哪里?
用于验证内部不变量/表示不变量/控制流不变量/方法的前置条件/方法的后置条件
***断言主要用于开发阶段,避免引入和帮助发现bug;实际运行阶段,不再使用断言
避免降低性能
程序之外的事,不受你控制,不要乱断言!!!
调试的基本过程和方法
***过程:
reproduce:找到一种可靠且方便的可以根据需求重现问题的方法
diagnose:构建假设,并通过实验来测试它们,直到已确定错误的根源
fix:设计和实施解决问题的方法,并在此过程中保持软件的整体质量
reflect:通过该错误得到哪些教训?
***方法:假设-检验
***从最小的测试用例开始复现错误
黑盒测试用例的设计
***黑盒测试:对程序外部表现出来的行为的测试,用于检查代码的功能,不关心内部实现细节
***基于等价类划分的测试:将被测函数的输入域划分为等价类,从等价类中导出测试用例。
针对每个输入数据需要满足的约束条件,划分等价类
每个等价类代表着对输入约束加以满足/违反的有效/无效数据的集合
等价类基于的假设:相似的输入,将会展示相似的行为。故可从每个等价类中选一个代表作为测试用例即可
***边界值分析方法是对等价类划分方法的补充,这是由于大量的错误发生在输入域的“边界”而非中央,因此在等价类划分时,将边界作为等价类之一加入考虑,此外还要考虑边界的两侧
以注释的形式撰写测试策略
测试策略(根据什么来选择测试用例)非常重要,需要在程序中显式记录下来
目的:在代码评审过程中,其他人可以理解你的测试,并评判你的测试是否足够充分
e.g:
Junit测试用例写法
使用@Test表明测试一个方法
使用assertEquals()测试方法是否成功实现
Junit中的assertXXX()方法
***需要对每一个编写的方法编写测试用例
测试覆盖度
***笛卡尔积:全覆盖
多个划分维度上的多个取值,要组合起来,每个组合都要有一个用例
***覆盖每个取值:最少1次即可
每个维度的每个取值至少被1个测试用例覆盖一次即可
***笛卡尔积VS覆盖每个取值
前者:测试完备,但用例数量多,测试代价高
后者:测试用例少,代价低,但测试覆盖度未必高
***代码覆盖度:已有的测试用例有多大程度覆盖了被测程序
代码覆盖度越低,测试越不充分但要做到很高的代码覆盖度,需要更多的测试用例,测试代价高
***分类:函数覆盖 + 语句覆盖 +分支覆盖 + 条件覆盖 + 路径覆盖
测试效果:路径覆盖>分支覆盖>语句覆盖
测试难度:路径覆盖>分支覆盖>语句覆盖
路径数量巨大,难以全覆盖
实际当中,根据预先设定的覆盖度标准,逐步增加测试用例的数量,直到覆盖度达到标准(例如语句覆盖100%、路径覆盖90%)。
***工具:EclEmma