HIT软件构造第六章三到五节知识点总结

  本篇继续总结第六章的知识点

三. 断言与防御式编程

1.断言

  断言主要是开发阶段使用，用于假设某些假设是否成立，一旦不成立则会抛出AssertionError
  有以下两种形式：
  (1).assert 表达式; 相当于一个if判断，只是失败了就抛出异常。
  (2).assert 表达式:信息; 额外在抛出异常的时候显示出对应的信息。
  断言一般用在各种不变量，以及前置条件和后置条件的检查等等；但不要胡乱使用断言，断言中也不要有与正常操作有关的代码。
  断言很影响运行效率，在开发结束后应该关闭断言来使用。只有在运行时加上-ea参数才会开启断言。

2.断言vs异常

  断言用于保证程序的正确性，如果断言失败那就是严重的错误，一般针对于自己写的代码；而异常用于保证程序的健壮性，有异常不代表一定是严重的错误，一般针对于外部的情况，比如用户输入不合法，读入文件失败等等与自己代码无关的错误。

3.防御式编程

  对于类的public方法接收到的参数都应该被认为是dirty的，如果要是其中调用了private方法，我们就可以建立一个“隔离舱”来进行隔离；从而隔离前可以用异常处理，隔离后用assert语句来处理(因为此时再出问题就是内部逻辑代码的问题了)。

四.代码调试

  当各种防御式编程手段和测试手段还不能完全找出问题后，出现bug就要进行最后一步了：代码调试(debug)。这是一个很浪费时间的步骤，尤其是耦合度高的代码。

1.调试过程

  总的来说可以分为四个阶段：重现、诊断、修复、反思。常用方法：假设-检验法。
  重现很多时候是非常难的，因为可能有各种因素：多线程，与时间有关，与版本有关，bug导致崩溃而不知为何等等。
  高效诊断的方式：测量(加入插桩代码)，分治(逐渐缩小错误出现的可能范围)，切片(如果某变量的计算有bug，那就只去找对应的与这个变量有关的计算的语句)，寻找差异(利用版本控制系统，还有软硬件差异等等)

2.调试工具

  (1).内存转储：把某一时刻软硬件的信息、出问题的部分的内存的情况以及进程线程的有关信息保存在文件中。是最原始，难以理解的方式。
  (2).栈轨迹：可以很轻松的定位到问题所在的方法的某一行
  (3).日志：比较流行的是log4j，可以灵活的使用日志。
  (4).警告信息：尽量把编译器的警告级别调到最高级，尽量消除一切Warning.

五.软件测试与测试优先的编程

  测试的目的是尽量找到错误，而对错误的改正是前面调试的过程。

1.测试的类别

  按照级别/层面，可以分为单元测试，集成测试，系统测试，最后用户还会进行验收测试。
  按照测试中是否运行程序，可以分为静态测试与动态测试。静态测试的过程不进行测试，例如评审，审查等等。
  按照是否关注内部代码，可分为白盒测试和黑盒测试。白盒测试中是知道了内部代码，跟着内部代码的结构进行测试；而黑盒测试中只知道这块的功能，只知道输入对应的输出而不知道内部结构，然后进行测试。

2.测试优先的编程

  测试优先的编程：在写代码前，先写测试样例，确定对于某个输入，期望的输出结果。这样就把测试放在了第一步，使得测试的思考方式不被代码的逻辑所约束，最具有合理性。当然，测试样例的结果是根据规约来决定的。

3.JUnit测试框架

  具体的语法可见：我是传送门。这里主要说一些使用JUnit测试的心得吧。
  1.很多时候使用assertEquals就足够了，配上fail(),assert(true)等语句，至少几次实验都足够用了。
  2.对于浮点数的测试，要使用assertEquals(double,double,double)这个方法，第三个参数是允许误差 ，比如0.001。
  3.对于测试中期望发生的异常，可以使用try catch进行处理，在catch中让测试成功，try语句块最后直接让程序失败。
  4.对于测试在控制台输出的内容是否正确 ，可进行输出的重定位，从而可在assertEquals语句中进行内容的比较。

  5.GUI等客户端不适合使用JUnit测试，总之客户端的代码尽量简单，监听器等等里面的逻辑最好都是调用下层的代码，否则如果在监听器内实现各种逻辑，就只能出错后手动调试了，深坑。

4.设计好的测试用例

  等价类划分方法是目前最好的方法：将被测函数的输入域划分为等价类，每个等价类代表着对输入约束加以满足/违反的有效/无效数据的集合。这样可以尽量的用最少的测试样例去找出更多的错误。
  其实在我们以前的采用实际运行看结果的测试方式中，我们每次使用的隐含的指导思想其实也是如此：每次选一个有代表性的即可，即可代表一类情况。
  另外可以加入边界值分析法作为补充：多关注边界情况，例如空字符串空数组，0或者-1等等情况。