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

这次笔记我们学习一下软件测试与测试优先的编程。

一、软件测试与测试优先的编程

1.1 软件测试

1.1.1 概念

测试是提高软件质量的重要手段，发现bugs, 确认是否达到可用级别(用户需求)，进而关注系统的某一侧面的质量特性。
一个好的测试具有这些特征：能发现错误、不冗余、最佳组合、不能太过复杂也不能太过简单。
测试与调试的区别如下：
测试：发现是否存在错误
调试：识别错误根源，消除错误

1.1.2 测试的分类

在范围方面，可以将测试分为如下种类：
单元测试：是指验证特定代码部分功能的测试，通常在功能级别。
集成测试：由多个程序员或编程团队创建的两个或多个类、包、组件、子系统的组合执行。
系统测试：测试一个完全集成的系统，以验证系统是否满足其要求，并在其最终配置中执行软件。
回归测试：如果程序被修改，则重新执行先前的所有测试，如图所示：

图1.1 回归测试

验收测试：程序发布前的最后一道测试，要求完成用户所有需求，如图所示：

图1.2 验收测试

测试的静态和动态还有区别。
静态测试指在代码编辑时用代码编辑器进行检查
动态测试就是我们常用的测试样例去测试程序。我们平时采用的junit就属于此类内容。
测试还可以分为黑盒测试和白盒测试。
白盒测试：对程序内部代码结构的测试
黑盒测试：对程序外部表现出来的行为的测试

1.1.3 测试用例

测试用例：输入+执行条件+期望结果
对测试用例的要求：
最可能发现错误，不重复、不冗余，最有效，既不简单也不复杂等。

1.2 测试优先的编程

测试优先的编程过程如下:
先写spec（函数规约）；
再写符合spec的测试用例；
写代码、执行测试、有问题再改、再执行测试用例，直到通过它。
测试优先可以尽早发现设计问题，避免浪费时间做错误的事情。
函数规约包含如下内容：

• 参数类型；
• 返回值类型；
• 它们之间的约束和关系。

单元测试中我们常用的软件是Junit，我们三次实验中均有所涉及；
测试中常用的代码如下图所示：

图1.3 junit测试代码

1.3 黑盒测试和白盒测试

1.3.1 黑盒测试

黑盒测试：用于检查代码的功能，不关心内部实现细节
检查程序是否符合规约。用尽可能少的测试用例，尽快运行，并尽可能大的发现程序的错误。

图1.4 黑盒测试

1.3.2 白盒测试

相对于黑盒测试，白盒测试要考虑内部实现细节，根据程序执行路径设计测试用例，其在程序内一般较早执行。

图1.5 白盒测试

1.4 代码覆盖度（Code coverage）

代码覆盖度需要借助一个名为Eclemma的软件完成，这个软件一般内置在eclipse的安装包中，也可以手动安装。它代表的是已有的测试用例有多大程度覆盖了被测程序。
代码覆盖度越低，测试越不充分。但要做到很高的代码覆盖度，需要更多的测试用例，测试代价高。

1.5 测试策略

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

1.6 总结

测试优先编程。 在编写代码之前编写测试。
系统地选择测试用例的分区和边界。
用于填写测试套件的白盒测试和语句覆盖。
尽可能独立地对每个模块进行单元测试。
自动回归测试以防止错误再次出现。

二 过程与配置管理

2.1 传统开发模型

在软件开发的过程中，应当根据用户的参与程度、开发效率以及管理复杂度等等指标来选择合适的过程模型。现存的模型有瀑布过程、增量过程、V字模型、原型过程、螺旋模型等，接下来具体介绍这些模型。

2.1.1 瀑布过程

瀑布模型通过概念、启动、分析、设计、构建、测试、实施和维护阶段稳步向下推进一个软件的发展进程，像一座瀑布一样稳步向下流动。
特点：线性推进、整体推进、非迭代
优点：管理简单
缺点：无法适应需求增加/变化

图2.1 瀑布模型

2.1.2 增量过程

增量模型可以看做是多个瀑布模型的集合体。在每一个小的构件中，可以看作是一个一个瀑布分别进行管理；而整体上当所有的构件都完成之后在统一交付给客户。它的优点是在瀑布模型的基础上，能够提升对客户的要求适应性。
特点：线性推进、增量式（多个瀑布的串行）、非迭代
优点：比较容易适应需求的增加。

图2.2 增量过程

2.1.3 V字模型

V字模型可以看作瀑布模型的优化，它仍然是线性推进的，瀑布模型存在的问题大多在V字模型中也存在。
每个开发阶段都有相应的测试对齐进行验证，但是测试与开发是串行而非并行进行的，也就是测试需要等开发完成后再开始。

图2.3 V字模型

2.1.4 原型过程

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

图2.4 原型过程

2.1.5 螺旋模型

螺旋过程含有多轮迭代，基本遵循瀑布模式。每轮迭代有明确的目标 ，遵循“原型”过程。一轮迭代完成后，进行严格的风险分析， 方可进入下一轮迭代。

图2.5 螺旋模型

2.2 敏捷开发

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

图2.6 敏捷开发

敏捷宣言四个维度：
个体和互动高于流程和工具
工作的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划

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

2.3.1 软件配置管理

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

图2.7 软件配置管理

2.3.2 版本控制

版本控制可分为以下几类：
本地版本控制系统：仓库存储于开发者本地机器，无法共享和协作。
集中式版本控制系统：仓库存储于独立的服务器， 支持多开发者之间的协作。
分布式版本控制系统：仓库存储于独立的服务器 + 每个开发者的本地机器。

2.3.3 Git仓库

Git仓库就是一个分布式版本控制系统。
一个 Git 仓库分为三个部分：
.git 目录：本地的 CMDB
工作目录：本地文件系统
暂存区：.git 目录中的一个文件，隔离工作目录和 Git 仓库

图2.8 Git仓库文件状态

关于git中的指令我们会在实验总结篇中叙述，此处之讲述重要内容：

$ git branch [branch]					#创建分支
$ git checkout [branch]					#切换分支
$ git merge [name]						#合并分支
$ git branch -d [name]					#删除分支

这就是git的几条重要指令。执行过程如图所示:

图2.9 指令描述1

图2.10 指令描述2

2.4 软件构造的一般过程

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

2.5 总结

▪ 传统的软件过程模型
– 瀑布式、增量式、原型式、迭代式
▪ 敏捷开发
▪ 协作软件开发
▪ 软件配置管理 (SCM)
▪ Git 作为 SCM 工具