重新做人

静态类型检查是关于“类型”的检查，不考虑值；动态检查是关于“值”的检查。Java 是一种静态类型语言，它同时具有静态类型检查和动态类型检查。改变变量和值的区别改变一个变量：将该变量指向另一个值的存储空间改变一个变量的值：将该变量当前指向的值的存储空间中写入一个新的值不变性不变数据类型（immutable type）：一旦被创建，其值不能改变引用不变：一旦确定其指向的对象，不能再被改变（但其值是可能变化的）Java 中的 final 关键字 final 类无法派生子类 fin

两种基本类型：线性过程、迭代过程选择合适的过程模型的依据：用户参与程度、开发效率/管理复杂度、开发出的软件的质量瀑布过程特点：线性推进、整体推进、非迭代优点：管理简单缺点：无法适应需求增加/变化增量过程特点：线性推进、增量式（多个瀑布的串行）、非迭代优点：比较容易适应需求的增加V-ModelV 模型可以看作瀑布模型的优化，它仍然是线性推进的，瀑布模型存在的问题大多在 V-model 中也存在。每个开发阶段都有相应的测试对齐进行验证，但是测试与开发是串行而非并行进行的，也就是测试需要等开发完成后再开始。

从范围上看 从静态/动态上看从结构上看白盒测试：对程序内部代码结构的测试黑盒测试：对程序外部表现出来的行为的测试（例如输入输出）测试用例：输入 + 执行条件 + 期望结果测试的动机：让代码出错，出错越快越好编写测试的过程 先写规约，再写符合规约的测试用例 写代码、执行测试、有问题再改、再执行测试用例，直到通过它 测试驱动开发（TDD）：将需求转化为具体的测试用例，然后软件经过改进，通过新的测试规约本身也可能是错误的 - 不正确，不完整，模棱两可缺失

总览:按阶段划分：构造时/运行时视图按动态性划分：时刻/阶段视图按构造对象的层次划分：代码/构件视图软件多维视图:源码组织在文件中，进而组织在目录中文件存档在包中，并逻辑上归属于组件和子系统可重用的模块以库的形式存在，库存储在磁盘文件中静态链接：库被拷贝进代码形成整体，执行的时候无需提供库文件,发生在构造阶段AST:彻底结构化,对树的各种操作==对源代码的修改版本控制是给计算机软件不同状态分配唯一的名字或编号的过程动态链接：库文件不会在构建阶段被加入可执行软件，仅仅做出标记；程序运行时，根据标记装载库至内存

检查抛出的异常有三种方式，它们各自都有优缺点：1.@Test(expected…)@Test注解有一个可选的参数，"expected"允许你设置一个Throwable的子类。在测试的方法前加入类似下面的句子即可验证方法抛出预期的异常:简单明了，这个测试有一点误差，因为异常会在方法的某个位置被抛出，但不一定在特定的某行。2.ExpectedException如果要使用JUnit框架中的ExpectedException类，需要声明ExpectedException异常。然后你可以使用更加简单的方式验证预期的异

在做软件构造的lab1时,编写P3的测试用例时我遇到了这么一个问题,即在检测加边是否正常工作时,图中并没有我在检测加点的程序中添加的人.addVertex正常工作,addEdge报错错误信息不存在此人我以为是不同方法之间的数据不共享,于是我便在addEdge中重复了一遍加点操作,发现这次addEdge正常通过,但addVertex却开始报错:图中出现重复人名.这下知道了,同一个测试类中的私有数据还是共通的,那么便是顺序问题了,说明它并不是起初我预想的按顺序执行,而是有着自己的规则.查阅资..