【软件构造HIT】Chapter 1 & 2 知识整理

HIT_Champ

已于 2022-06-09 19:44:47 修改

阅读量171

点赞数 4

文章标签： java

于 2022-05-26 13:11:33 首次发布

本文链接：https://blog.csdn.net/qq_51364889/article/details/124982683

版权

文章目录

Software Construction of HIT
Chapter 1 Views and Quality Objectives of Software Construction
Chapter 2 Testing and Test-First Programming

Software Construction of HIT

Chapter 1 Views and Quality Objectives of Software Construction

1 Multi-dimensional software views

在这里插入图片描述

1.1 Build-time Views

Code-level：代码的逻辑组织，例如类、方法、接口等
Component-level：代码的物理组织，例如文件、包、库等

Moment view：特定时刻软件（source code和component）的形态
Period view：软件形态随时间的变化

Build-time Moment Code-level：
- 词汇层面：Source Code
- 语法层面：Abstract Syntax Tree
- 语义层面：Class Diagram
Build-time Period Code-level：
- 代码变化：Code Churn——added, deleted, modified
Build-time Moment Component-level：
- File, Package, Library
- Static linking：静态链接发生在构造阶段
- Test Case
Build-time Period Component-level：
- Software Configuration Item 配置项
- Version

1.2 Run-time Views

Code-level：代码层面：逻辑实体在内存中如何呈现？
Component-level：构件层面：物理实体在物理硬件环境中如何呈现？

Moment view：逻辑/物理实体在内存/硬件环境中特定时刻的形态如何？
Period view：逻辑/物理实体在内存/ 硬件环境中的形态随时间如何变化？

Run-time Moment Code-level：
- Code Snapshot：
- Memory Dump
Run-time Period Code-level：
- Execution tracing：用日志方式记录程序执行的调用次序
Run-time Moment Component-level：
- Deployment Diagram
Run-time Period Component-level：
- Event Log：系统层面的事件日志

1.3 Focus

在这里插入图片描述

2 Transformation between views

在这里插入图片描述

∅→Code
- Programming / Coding (ADT/OOP)
- Review, static analysis/checking
Code→Component
- Design (ADT/OOP;Reusability;Maintainability)
- Build: compile, static link, package, install, etc
Build-time→Run-time
- Install / deploy
- Debug, unit/integration testing (Robustness and Correctness)
Moment→Period
- Version control
- Loading, dynamic linking, execution (dumping, profiling, logging)
- Concurrent threads

3 Quality properties of software system

外部质量因素影响用户
内部质量因素影响软件本身和它的开发者
In the end, only external factors matter.
外部质量取决于内部质量

3.1 External quality factors

Correctness：严格按照规约执行
Robustness：针对异常的处理，对规约外的情况恰当反应（Chapter 12）
Extendibility：ADT和OOP
Reusability：
Compatibility：
Efficiency：
Portability：
Easy of use：
Functionality：
Timeliness：
Verifiability, Integrity, Repairability, Economy

3.2 Internal quality factors

Internal quality factors are usually used as partial measurement of external quality factors.

Lines of Code (LOC), Cyclomatic Complexity圈复杂度
Architecture-related factors such as coupling耦合, cohesion, etc
Readability
Understandability
Clearness
Size

3.3 Tradeoff between quality properties

在这里插入图片描述

encapsulation：封装
decentralization：分散，去中心化

3.4 Five key quality objectives of software construction

Specification→Easy to understand： elegant and beautiful code / understandability
Maintainability→Ready for change： maintainability and adaptability
Reusability→Cheap for develop： design for/with reuse

在这里插入图片描述

Correctness/Robustness→Safe from bugs： robustness

在这里插入图片描述

Efficient to run： performance

Chapter 2 Testing and Test-First Programming

1 Software Testing

1.1 What is testing

测试是提高软件质量的重要手段，不是唯一手段。
测试的目的是发现错误。不能证明系统不存在错误。

1.2 Test level

Unit testing 单元测试：针对function level
Intrgration testing 集成测试：针对classes、packages、components
System testing 系统测试：针对一个完全集成的系统
Regression testing回归测试：

1.3 Testing types

静态测试和动态测试：
- Static testing：不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误的过程。
- Dynamic testing：实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。
白盒测试和黑盒测试：
- White-box testing：也称为结构测试，知道程序内部的代码结构，主要用于检测软件编码过程中的错误。
- Black-box testing：也称为功能测试，主要关注被测软件的功能实现，而不是内部逻辑。在黑盒测试中，被测对象的内部结构，运作情况对测试人员是不可见的，主要是根据其规约，验证其与规约的一致性。
As a tester, not only “make it fail”, but also “fail fast”.

2 Test Case

2.1 Characteristics of good test case

最可能发现错误（不能证明程序是正确的）
不重复，不冗余
最有效
既不简单，也不复杂

3 Test-First Programming

Write the tests before you write the code. 😮

3.1 Test-driven development(TDD)

”测试代码“比写代码更有成就感！
Process：

先写spec
再写符合spec的测试用例
写代码、执行测试、有问题再改、再执行测试用例，直到通过它

在这里插入图片描述

4 Unit Testing

针对软件的最小单元模型开展测试，隔离各个模块，容易定位错误和调试。

5 Automated Unit Testing with JUnit

5.1 JUnit test case

@Before和 @After
- @Before： Prepare for the test, complete the initialization
- @After： Clean up the test environment
@test assertXXX in JUnit，查看实际值是否满足指定的条件，条件使用Hamcrest Matchers匹配符进行匹配。

assertArrayEquals("failure - byte arrays not same", expected, actual);
assertEquals("failure - strings are not equal", "text", "text");
assertFalse("failure - should be false", false);
assertNotNull("should not be null", new Object());
assertNotSame("should not be same Object", new Object(), new Object());
assertNull("should be null", null);
assertSame("should be same", aNumber, aNumber);
assertTrue("failure - should be true", true);
assertThat("albumen", both(containsString("a")).and(containsString("b")));
assertThat(Arrays.asList("one", "two", "three"), hasItems("one", "three"));
assertThat("good", allOf(equalTo("good"), startsWith("good")));

Complete list can be found in here.

6 Black-box Testing

黑盒测试用于检查代码的功能，不关心内部实现细节。可能出题方向：概念解释题和设计测试。
测试应该检查程序是否符合规约，用尽可能少的测试用例，尽快运行，并尽可能大的发现程序的错误。

6.1 Choosing Test Cases by Partitioning

Equivalence Partitioning基于等价类划分的测试：将被测函数的输入域划分为等价类，从等价类中导出测试用例。针对每个输入数据需要满足的约束条件，划分等价类（对称、传递、自反）。
Guidelines for Equivalence Partitioning

输入数据限定了数值范围，则…
输入数据指明了特定的值，则…
输入数据确定了一组数值，则…
输入数据是Y/N，则…

在BigInteger.multiply()例子中，得到了49的partitions，考虑了：
- 正负
- 特殊值0，-1，1
- 输入的上限（Boundary Value Analysis——BVA）

6.2 Include Boundaries in the Partition

大量的错误发生在输入域的“边界 ”而非中央。例如： 0、Maximum and minimum values of numeric types, like int and double、Emptiness (the empty string, empty list, empty array) for collection types、 The first and last element of a collection。 边界值分析方法是对等价类划分方法的补充。
在max()例子中，除了分： a < b 、a = b、a > b；还要考虑a，b的边界值如：a = 0、a < 0、a > 0、a = minimum integer、a = maximum integer。