HIT软件构造复习：chapter1、2

前言

复习笔记记录一些比较重要的零散的知识点，主要摘自听课时的笔记和PPT

第一章大部分内容是一些概念概述，后续内容会有相应的展开

正文

chapter1：

OOP:面向对象的编程

课程一开始就引导我们要将“软件构造”视作“不同视图之间的转换”

多维视图：

按照阶段划分：可以分为构造时/运行时两种视图

按照动态性划分：可以分为时刻/阶段视图

按照构造对象划分：可以分为代码/构件视图

库的使用很早就有涉及到，库有操作系统提供的/编程语言提供的/第三方公司提供的/自定义的库

**需要告诉IDE/JVM我们引用的库的位置

此后有许多概念分为静态/动态，一般情况下，静态指的是在编译过程中发生的，动态指的是在程序运行时发生的，例如静态/动态链接

SDLC:

即软件开发周期，简单来说分为：规划->分析->设计->实现->测试->维护

版本的概念：软件在特定时间节点，所有文件的共同状态的集合。一般情况下，用 V x.x.x表示，从前到后分别为大版本/小版本/小路径

快照图：描述程序运行时，某时刻内存里变量层面的状态。便于程序员之间交流，刻画各类变量随时间变化情况，解释设计思路。

其中引用以箭头指向以椭圆圈住的对象数据类型/或直接指向基本数据类型，引用为不可变引用时，箭头双线，可变引用为单线箭头；对象为可变时，椭圆为单线，不可变对象对应双线椭圆

值得一提的是引用的可变性与对象可变性无关

 视角之间的切换：

质量标准：

 分为外部、内部质量因素，外部影响用户，内部影响软件本身和开发者，外部质量取决于内部质量

外部质量：

1.正确性：即程序需要按照预先定义的规约执行，是最重要的质量指标，权衡综合效率时要以保证正确性为前提。整个软件系统的分层结构中，上层保证自己的正确性并假设下一层正确。

   方法：

测试/调试，发现不正确并消除

防御式编程，在编程过程就保证正确性

形式化验证发现问题                        

2.健壮性：程序针对异常的处理，是对正确性的补充，即出现规约之外的情况下做出相应的反应。（注意：一定要根据规约区分异常，而不是主观判断）

3.可扩展性：对软件的规约进行修改是否足够容易。一般取决于软件规模，规模越大越不容易。

注：扩展是为了更好适应变化

方法：简约主义/分离主义设计

4.可复用性：一次开发多次使用

方法：发现开发对象中的共性

5.兼容性：不同的软件系统之间相互可容易的集成，难点在于不同软件系统的设定不一样

6.性能：保证正确性的前提下，软件对CPU资源的占用情况

优化时要与其他属性折中，但正确性一定是前提，且过度优化可能导致软件不再适应变化和可复用

7.可移植性：软件可否在不同的技术环境之间移植（硬件、OS）

8.易用性：软件是否足够容易使用、安装、监控

9.功能性：软件的功能是否足够丰富

注：软件的功能过多会导致软件不灵活和其他指标下降

10.及时性：软件的版本更新是否及时，能否适应市场需求

11.可验证性/完整性/可修复性/成本/。。。

内部质量：

代码可读性、整洁性、软件大小，代码功能耦合度等等

 

chapter2：

第二章节围绕软件测试展开。

测试：发现软件中的错误，与其他活动的目标相反。

但即使是再完备的测试也不能完全覆盖所有情况，无法证明系统中无错误

按照测试对象等级划分为

单元测试：对软件中的最小单元进行测试（Java中一般为类），隔离各个模块，便于定位错误

集成测试：类之间、接口之间的测试

系统测试：对整个软件的测试，是否满足规约

验收测试：用户的测试

特殊的：

回归测试：编程中修改了部分错误之后的测试

之前说过静态与动态的基本意思，测试也可以分为静态测试与动态测试

静态测试：不需要运行程序的测试，一般是程序员观察代码纠错

动态测试：通过程序运行结果，或是跟踪运行过程中数据的变化进行纠错‘

黑盒测试：仅对程序外部表现出来的行为的测试，不需要考虑内部实现细节。

常见的有：功能性测试、容量测试、安全性测试、负载测试、恢复性测试、标杆测试、稳定性测试、可靠性测试等。

方法：等价类划分、边界值分析、因果图分析法、错误推断法

白盒测试：对程序内部行为的详细测试，需要知道程序内部结构

常见方法：

语句测试、分支/判定测试、条件测试、数据流测试、基本路径测试

语句测试是将使每条代码都能够并且至少执行一次（多分支的结构中，语句测试只会考虑某一条具体的路径，并不会考虑多条路径的组合）

分支/判定测试是将所有逻辑判断、条件判断的语句的各种情况至少执行一次（比如if条件为真、为假；switch的所有case情况的遍历等）

条件测试是将所有逻辑判断的真、假情况都执行至少一次（看上去是包含在分支/判定测试中的）

数据流测试是在程序执行时跟踪数据（变量）的定义与使用（看上去类似于debug的过程）

基本路径测试是将所有可能组合的路径都至少执行一次
 

不难发现黑盒测试更容易实现，但是因为它不关心程序是如何实现的，因此测试结果可能有误，且要实现更大的覆盖更困难；白盒测试也不完美，程序中依然有部分语句（断言）是无法到达的，所以也无法测试到，而且测试代价高。根据二者的特性来看，黑盒测试适合用户，白盒测试适用于开发者。

测试优先编程：先写spec，再根据spec写测试用例。最后根据测试写相应的代码，然后执行测试，发现问题则修改再测试，直至通过。相比于传统的编程顺序，可以节省调试时间

在Java中，测试一般与源代码文件区分开，但是二者结构要尽量保证一致，便于调用。测试取例要覆盖所有情况，尽可能用最少的案例实现全覆盖。测试语句要以@Test说明，要记录测试策略，测试中常用assertXX（），其中XX是判断结果，可以是equals、same、true等，也可以用assertThat（），括号中填入比较复杂的逻辑语句，如下图

可以在@Test之后加上 expected = IllegalExpectedExceptionclass进行异常情况的测试，但是只能测试出现异常而不能准确测试异常种类

改进：

@Rule

Public ExpectedException EE = ExpectedException.none();

然后在之后的测试体里，可以用EE.expected的方法判断抛出异常种类

这是JUnit4之中的方法，现在最新的JUnit5还支持assertThrows技术来判断异常抛出。

此外还有两个很实用的方法：

@befor：每个测试之前都要执行一遍。一般可以把共有的初始化操作放在这里

@after：每个测试之后都要执行一遍，一般可以把清理内存等结束处理操作放在这里