哈工大软件构造课程知识点总结（一）

系列文章目录

哈工大软件构造课程知识点总结（一）
哈工大软件构造课程知识点总结（二）
哈工大软件构造课程知识点总结（三）
哈工大软件构造课程知识点总结（四）
哈工大软件构造课程知识点总结（五）
哈工大软件构造课程知识点总结（六）

---

---

简介

此文章是2021春哈工大软件构造课程Chapter 1、Chapter 2的知识点总结。

Chapter 1:Views and Quality Objectives of Software Construction

概述

本章首先展示了软件构造过程中的多维度视图，对此图的各部分进行了详细的解读，并简要介绍了各维度视图之间的联系。随后列出了软件系统的内、外部质量因素。最后提出了五个关键质量指标。

软件的多维度视图

多维视图表

	Moment		Period
	Code-level	Component-level	Code-level	Component-level
Build-time	Source code, AST, Interface-Class-Attribute-Method (Class Diagram)	Package, File, Static Linking, Library, Test Case, Build Script (Component Diagram)	Code Churn	Configuration Item, Version
Run-time	Code Snapshot, Memory dump	Package, Library, Dynamic linking, Configuration, Database, Middleware, Network	Execution stack trace, Concurrent multithreads	Event log, Multi-processes, Distributed processes

以下为个人理解：

• Moment维度关注于程序在某一特定时刻的表现，而Period维度关注于程序在某一段特定时间内的表现；
• Build-time维度聚焦于程序被运行前构造阶段的表现，而Run-time维度聚焦于程序运行时的表现；
• Code-level维度注重程序代码本身、逻辑实体在内存中的呈现等细节方面，Component-level维度注重系统模块及整体以及物理实体在内存中的呈现等较大方面。

表格中具体各部分如下：

1. Build-time, Moment, and Code-level: 关注源码的组织情况，可在词汇（源码）、语法（抽象语法树）、语义（类图）三个层面分析；
2. Build-time, Period, and Code-level: 关注代码变化(Code churn)；
3. Build-time, Moment, and Component-level: 关注未运行时的包、库、模块等（静态）；
4. Build-time, Period, and Component-level: 关注文件版本的变化，而不是具体语句的变化；
5. Run-time, Moment, and Code-level: 关注程序在某个时间点的细节情况，如代码快照图(Code Snapshot)、内存信息转储(Memory dump)；
6. Run-time, Period and Code-level: 关注代码阶段执行情况；
7. Run-time, Moment, and Component-level: 关注点与第3点类似，但是在运行时（动态）；
8. Run-time, Period, and Component-level view 关注系统整体运行情况。

视图间关系

如下图：

软件系统的质量

内、外部质量因素

外部质量因素影响用户，内部质量因素影响软件本身和它的开发者，外部质量取决于内部质量。
外部质量因素包括：

1. 正确性：最重要的质量指标
2. 健壮性：针对异常情况的处理
3. 可扩展性：对软件的规约的修改要足够容易
4. 可复用性：一次开发，多次使用
5. 兼容性：不同的软件系统之间相互可容易的集成
6. 性能：性能毫无意义，除非有足够的正确性
7. 可移植性：软件可方便的在不同的技术环境之间移植
8. 易用性、功能性、及时性、可验证性、完整性、可修复性、经济性……

注意：以上质量因素不可能同时完美满足，性能常常要与其他质量因素相折中，但正确性绝不能与其他质量因素折中。
内部质量因素包括：
可读性(Readability)、可理解性(Understandability)、简洁性(Clearness)、大小(Size)等等。

五个关键的质量指标

• 易于理解(Easy to understand)
• 易维护、修改(Ready for change)
• 可复用(Cheap for develop)
• 健壮性(Safe from bugs)
• 高效性(Efficient to run)

Chapter 2:Testing and Test-First Programming

概述

本章主要讲解软件测试与测试优先的编程，要求重点掌握黑盒测试。

软件测试

软件测试是提高软件质量的重要手段。测试跟其他活动的目标相反，测试往往是破坏、证错、“负能量”的。好的测试具有以下几个特点：

• 能发现错误
• 不冗余
• 最佳特性
• 别太复杂也别太简单

软件测试能在一定程度上提高软件的质量，但即使是最好的测试，也无法达到100%的无错误。

测试分为如下四个阶段：

1. 单元测试：针对软件的最小单元模型开展测试，隔离各个模块，容易定位错误和调试(使用JUnit进行单元测试是课程实验的一部分)
2. 集成测试
3. 系统测试
4. 验收测试

一旦程序被修改，重新执行之前的所有测试（回归测试）。

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

黑盒测试

黑盒测试用于检查程序是否符合规约（程序功能正确性），不关心内部实现细节。理想情况是用尽可能少的测试用例，尽快运行，并尽可能大的发现程序的错误。

等价类划分

基于等价类划分的测试：针对每个输入数据需要满足的约束条件划分等价类，从等价类中导出测试用例。

例：设计max: int × int → int的测试用例。
划分为三个等价类: a < b, a = b, a > b。
设计对应的测试用例，可以是：
(a, b) = (1, 2) to cover a < b
(a, b) = (9, 9) to cover a = b
(a, b) = (-5, -6) to cover a > b

边界值分析方法

大量的错误发生在输入域的“边界”而非中央，边界值分析方法是对等价类划分方法的补充。故可在等价类划分时，将边界作为等价类之一加入考虑。

例：重新设计max: int × int → int的测试用例。
考虑a或b取边界值的情况，如0, INT_MAX, INT_MIN等等，添加到等价类中。

等价类覆盖的极限方式

笛卡尔积：全覆盖，多个划分维度上的多个取值，要组合起来，每个组合都要有一个用例。测试完备，但用例数量多，测试代价高。

覆盖每个取值：每个维度的每个取值至少被1个测试用例覆盖一次即可，测试用例少，代价低，但测试覆盖度未必高。

白盒测试

白盒测试要考虑内部实现细节，根据程序执行路径设计测试用例。通常由开发人员完成，一般较早执行。针对功能（实现）进行测试，但测不出未实现的需求。

独立/基本路径测试：对程序所有执行路径进行等价类划分，找出有代表性的最简单的路径(例如循环只需执行1次)，设计测试用例使每一条基本路径被至少覆盖1次。

代码覆盖度

代码覆盖度：已有的测试用例有多大程度覆盖了被测程序。
代码覆盖度越低，测试越不充分；要达到很高的代码覆盖度需要大量的测试用例，测试代价高。

评判代码覆盖度的几个方面：

• 函数覆盖：所有的方法是否都被测试一次
• 语句覆盖：所有的语句都被测试一次
• 分支覆盖：所有的分支都被测试一次
• 条件覆盖：所有的条件的真假组合都被执行一次
• 路径覆盖：所有的路径都被执行一次，这是测试中最强的覆盖标准

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

注意：条件覆盖与分支覆盖无可比性！

测试优先的编程

过程为先写规约，然后写符合规约的测试用例，最后写代码、执行测试、有问题再改、再执行测试用例，直到通过它。