HIT软件构造学习笔记【二】（第2，3章）

目录

1 软件测试与测试优先的编程... 2

1.1 软件测试... 2

1.1.1 测试的分类... 2

1.1.2 测试用例... 3

1.2 代码覆盖度... 4

1.3 测试策略... 4

1.4 分析工具... 4

2 软件构造过程与配置管理... 5

2.1 传统开发模型... 5

2.1.1 瀑布过程... 5

2.1.2 增量过程... 5

2.1.3 V模型... 6

2.1.4 原型过程... 6

2.1.5 螺旋过程... 7

2.2 敏捷开发... 7

2.3 软件配置管理（SCM）和版本控制（VCS）... 8

2.3.1 软件配置管理（SCM）... 8

2.3.2 版本控制（VCS）... 8

2.3.3 Git. 9

2.4 软件构造的一般过程... 10

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

测试是提高软件质量的重要手段，确认软件是否达到可用级别（用户需求），它关注系统的某一侧面的质量特性。测试跟其他活动的目标相反，它的目的是发现错误，即便是再好的测试也无法证明系统里不存在错误。

一个好的测试具有这些特征：能发现错误、不冗余、最佳组合、不能太过复杂也不能太过简单。

测试和调试的区别

测试：发现是否存在错误

调试：识别错误根源，消除错误

1. 1. 1. 测试的分类

从范围上看

·单元测试：针对软件的最小单元模型开展测试（一般来说是在单个方法/类的级别），隔离各个模块，容易定位错误和调试

·集成测试：将多个程序员/团队编写的类/包/组件/子系统联合起来测试

·系统测试：对整个系统进行测试，将硬件、软件、配置信息等看作一个整体

·验收测试：产品发布之前所进行的软件测试活动，是技术测试最后一个阶段，目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务

·回归测试：一旦程序被修改，重新执行之前的所有测试以确认修改没有引入新的错误或导致其他代码产生错误

从静态/动态上看

·静态测试：在编写代码的阶段由程序员或是代码编辑器、编译器等工具进行检查（如语法检查、代码评审）

·动态测试：通过测试用例实际执行了编写的代码，动态测试可能在程序完全编写完成前就用于测试代码的特定节

从结构上看

·白盒测试：对程序内部代码结构的测试。考虑内部实现细节，根据程序执行路径设计测试用例，其在程序内一般较早执行。

·黑盒测试：对程序外部表现出来的行为的测试（例如输入输出）。检查程序是否符合规约，用尽可能少的测试用例，尽快运行，并尽可能大的发现程序的错误。

1. 1. 1. 测试用例

测试用例：输入 + 执行条件 + 期望结果

测试的动机：让代码出错，出错越快越好

编写过程：

·先写规约，再写符合规约的测试用例。

·写代码、执行测试、有问题再改、再执行测试用例，直到通过它。
·测试驱动开发（TDD: Test Driven Development）：将需求转化为具体的测试用例，然后软件经过改进，通过新的测试。

在单元测试中我们常用到Junit，通常通过注释@Test声明这是一个测试。在Junit测试中，我们常用到断言方法（assertion methods）有：assertEquals，assertTrue，assertFalse等。

1. 1. 代码覆盖度

代码覆盖度指已有的测试用例有多大程度覆盖了被测程序，通常用百分比衡量，代码覆盖度越低，测试越不充分。但若要做到很高的代码覆盖度，需要更多的测试用例，测试代价高。

语句覆盖：每⼀条语句至少执行一次

分支覆盖：判定中每个条件的所有可能结果至少出现一次，并且每个判定本身的所有可能结果也至少出现一次
路径覆盖：每条可能执行到的路径至少执行一次

测试效果：路径覆盖 > 分支覆盖 > 语句覆盖
测试难度：路径覆盖 > 分支覆盖 > 语句覆盖

测试覆盖度通常通过Eclemma插件完成。

1. 1. 测试策略

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

1. 1. 分析工具

Junit、EclEmma、VisualVM、AppPerfect：动态检查，需要执行代码

CheckStyle、SpotBugs、PMD：静态检查，无需执行代码

1. 软件构造过程与配置管理
   1. 传统开发模型

软件开发过程中，选择合适的过程模型的依据：用户参与程度、开发效率/管理复杂度、开发出的软件的质量。

两种基本类型：线性过程、迭代过程

1. 1. 1. 瀑布过程

构思、启动、分析、设计、构建、测试、实施和维护阶段稳步向下推进一个软件的发展进程，如瀑布一般。

特点：线性推进、整体推进、非迭代
优点：管理简单
缺点：无法适应需求增加/变化

1. 1. 1. 增量过程

增量过程可以看做是多个瀑布过程的集合体。在每一个小的构件中，可以看作是一个一个瀑布分别进行管理；而整体上当所有的构件都完成之后在统一交付给客户。它的优点是在瀑布模型的基础上，能够提升对客户的要求适应性。

特点：线性推进、增量式（多个瀑布的串行）、非迭代

优点：比较容易适应需求的增加。

1. 1. 1. V模型

V模型可以看作瀑布模型的优化，它仍然是线性推进的，瀑布模型存在的问题大多在V-model中也存在。

每个开发阶段都有相应的测试对齐进行验证，但是测试与开发是串行而非并行进行的，也就是测试需要等开发完成后再开始。

1. 1. 1. 原型过程

开发出来之后由用户试用/评审，发现问题反馈给开发者，开发者修改原有的实现，继续交给用户评审，循环往复这个过程，直到用户满意为止。重点在于在原型上持续不断地迭代发现用户变化的需求。

特点：迭代推进
优点：开发质量高
缺点：时间代价高

1. 1. 1. 螺旋过程

多轮迭代，基本遵循瀑布模式。每轮迭代有明确的目标，遵循“原型”过程

进行严格的风险分析，方可进入下一轮迭代。

1. 1. 敏捷开发

敏捷开发，即通过快速迭代和小规模的持续改进，以快速适应变化。

敏捷宣言四个维度：

个体和互动高于流程和工具

工作的软件高于详尽的文档

客户合作高于合同谈判

响应变化高于遵循计划

1. 1. 软件配置管理（SCM）和版本控制（VCS）
      1. 软件配置管理（SCM）

指追踪和控制软件的变化，包括版本控制和软件配置项。
软件配置项（SCI）：软件中发生变化的基本单元（例如：文件）。

1. 1. 1. 版本控制（VCS）

版本控制分类：

本地版本控制系统：仓库存储于开发者本地机器，无法共享和协作。

集中式版本控制系统：仓库存储于独立的服务器， 支持多开发者之间的协作。

分布式版本控制系统：仓库存储于独立的服务器 + 每个开发者的本地机器。

1. 1. 1. Git

Git是一个分布式版本控制系统。

一个Git仓库分为三个部分：

.git目录：本地的CMDB

工作目录：本地文件系统

暂存区：.git目录中的一个文件，隔离工作目录和Git仓库

 

传统 VCS 和 Git 对比：

传统 VCS：存储版本之间的变化（行）。

Git：存储发生变化的文件（而非代码行）， 不变化的文件不重复存储。

1. 1. 软件构造的一般过程

软件构造的一般过程包括编码、重构、调试、测试、性能分析、代码评审、构建。