docs: impl 'Static Testing'

Author: chiichen

src/notes/Software-Testing-and-Maintenance/Chapter2-Software-Testing-Technology.md

@@ -394,15 +394,15 @@ void  Sort(int iRecordNum,int iType)
 - 利用图形矩阵可以实现自动地确定一个基本路径集。
 - 一个图形矩阵是一个方阵，其行/列数控制流图中的结点数，每行和每列依次对应到一个被标识的结点，矩阵元素对应到结点间的连接（即边）。
 - 在图中，控制流图的每一个结点都用数字加以标识，每一条边都用字母加以标识。
-- 如果在控制流图中第i个结点到第j个结点有一个名为x的边相连接，则在对应的图形矩阵中第i行/第j列有一个非空的元素x。 
+- 如果在控制流图中第i个结点到第j个结点有一个名为x的边相连接，则在对应的图形矩阵中第i行/第j列有一个非空的元素x。
 - 对每个矩阵项加入连接权值，图矩阵就可以用于在测试中评估程序的控制结构，连接权值为控制流提供了另外的信息。最简单情况下，连接权值是 1(存在连接)或0(不存在连接)，但是，连接权值可以赋予更有趣的属性：
   - 执行连接(边)的概率。
   - 穿越连接的处理时间。
   - 穿越连接时所需的内存。
   - 穿越连接时所需的资源。
 - 对例4画出图形矩阵如下
 ![Case 4's Graphic Matrix](images/Chapter2-Software-Testing-Technology/image-18.png)
--  连接权为“1”表示存在一个连接，在图中如果一行有两个或更多的元素“1”，则这行所代表的结点一定是一个判定结点，通过连接矩阵中有两个以上（包括两个）元素为“1”的个数，就可以得到确定该图圈复杂度的另一种算法。 
+- 连接权为“1”表示存在一个连接，在图中如果一行有两个或更多的元素“1”，则这行所代表的结点一定是一个判定结点，通过连接矩阵中有两个以上（包括两个）元素为“1”的个数，就可以得到确定该图圈复杂度的另一种算法。
 
 ### 数据流测试(Data-Flow Testing)
 
@@ -416,7 +416,7 @@ void  Sort(int iRecordNum,int iType)
 
 - Defined, Created, Initialized
 - Killed, Undefined, Released
-- Used: 
+- Used:
   - Used in a calculation(计算使用)
   - Used in a predicate(谓词使用)
 
@@ -455,4 +455,90 @@ $$
 \end{array}
 $$
 
-- 定义-清除路径(Define-Clear Path)：一条路径 $(i, n_1, ..., n_m, j)$ 如果在节点 $(n_1, ..., n_m, j)$中不包含变量 $x$ 的定义，则称这条从节点 $i$ 到节点 $j$ 的路径对于变量 $x$ 来说是定义-清除路径。
+- 定义-清除路径(Define-Clear Path)：一条路径 $(i, n_1, ..., n_m, j)$ 如果在节点 $(n_1, ..., n_m, j)$中不包含变量 $x$ 的定义，则称这条从节点 $i$ 到节点 $j$ 的路径对于变量 $x$ 来说是定义-清除路径。
+
+## 静态测试(Static Testing)
+
+- 静态测试，通过检查和评审软件而不是运行软件来测试软件的方法。
+- 静态测试对象，待测试的软件相关产品，各种文档、源代码等
+- 识别错误的成本，需求阶段识别重要Bug平均需要2-3小时，在设计阶段识别一个重要的bug平均需要3-4个小时，代码评审阶段识别重要bug 3-5小时，动态测试平均需要 15-25 小时才能识别重要错误
+- 静态分析主要由软件工具自动执行，广义上讲，它还包括设计阶段的软件需求分析和技术审查，一群程序员和测试人员组成一个小组，集体阅读和讨论一个程序，或者用“大脑”来执行和检查程序的过程
+
+### 代码审查(Code Review)
+
+- 由一组程序和错误检查技术组成
+- 以代码审查组方式进行
+- 四个步骤
+  - 准备
+  - 程序阅读
+  - 审查会
+  - 跟踪及报告
+
+### 代码走查(Code Walkthrough)
+
+- 它也是由一组程序和错误检查技术组成，只是程序和错误检查技术不完全相同
+- 与代码审查不同，不是读程序和使用代码审查单，而是由被指定的作为测试员的小组成员提供若干测试用例（程序的输入数据和期望的输出结果），让参加会的成员当计算机，在会议上对每个测试用例用头脑来执行程序，也就是用测试用例沿程序逻辑走一遍，并由测试人员讲述程序执行过程，在纸上或黑板上监视程序状态（变量的值）
+- 代码走查中，测试用例并不是关键，也并不是仅想验证这几个测试用例运行是否正确，人脑毕竟比计算机慢太多
+- 这里测试用例是作为怀疑程序逻辑与计算错误的启发点，在随测试实例遍历程序逻辑时，在怀疑程序的过程中发现错误，这比几个测试用例本身直接发现的错误要多得多
+
+#### 代码走查的缺点
+
+- 代码走查使用测试用例启发检测错误，人们注意力会相对集中在随测试用例遍历的程序逻辑路径上，不如代码审查检查的范围广，错误覆盖面全
+
+### 静态测试的分类
+
+- 需求定义的静态测试
+- 设计文档的静态测试
+- 源代码的静态测试
+
+#### 需求定义的静态测试
+
+- 高级审查：测试需求定义的第一步是站在一个高度上进行审查，找出根本性的问题、疏忽或遗漏之处。例如符不符合政策规定，法务要求，功能需求是否都包含在了规格说明书中
+- 低层测试：高级审查之后可以很好地了解产品以及影响其设计的外部因素，然后就可以在更低的层次测试需求定义了。一些词语往往会带来缺陷，例如`如果...那么...`，没有`否则`，`如果`没有发生时就会带来缺陷。除此之外还包括这些对照条例：
+  - 完备性，例如是否对所有功能与时间有关的方面都作了考虑？
+  - 一致性，例如需求是否与其软硬件操作环境相容？
+  - 正确性，例如对设计和实现的限制是否都有论证？
+  - 可行性：例如需求定义是否使软件的设计、实现、操作和维护都可行？
+  - 易修改性
+  - 健壮性
+  - 易追溯性
+  - 易理解性
+  - 易测试性和可验证性
+  - 兼容性
+
+#### 设计文档的静态测试
+
+- 对设计文档的静态测试着重于:
+  - 分析设计是否与需求定义一致
+  - 所采用的数值方法和算法是否适用于待解问题
+  - 程序的设计中对程序的划分是否与待解问题相适应
+  - 需求是否都被满足了
+- 同样的，对照条例包括：
+  - 完备性：是否有充分的数据（如逻辑结构图、算法、存储分配图等）来保证设计的完整性？
+  - 一致性：在设计文档中，是否始终使用标准的术语和定义？文档的风格和详细程度是否前后始终一致？
+  - 正确性：设计文档是否满足有关标准的要求？
+  - 可行性：设计能否在所规定的限制条件下和开发代价下实现？
+  - 易修改性：设计是否做到了高内聚低耦合
+  - 模块性：是否采用了模块化的机制，使得程序由若干个子程序组成
+  - 可预测性：设计是否包含了子程序来提供在已经标识出的出错情况下所需的反应？
+  - 健壮性：设计是否覆盖了需求定义中所要求的容错和故障弱化的需求？
+  - 结构化：设计是否使用了层次式的逻辑控制结构？
+  - 易追溯性：设计文档中是否包含设计与需求定义中的需求、设计限制等内容的对应关系？
+  - 易理解性：设计是否避免了不必要的成分和表达形式？
+  - 可验证性/易测试性
+
+#### 源代码的静态测试
+
+- 对源代码的静态测试着重于分析实现是否正确、完备
+- 对照条例包括：
+  - 完备性：代码是否完全、准确地实现了设计规约中所规定的内容？
+  - 一致性：是否自始至终使用了相同的格式、调用约定、结构等等？
+  - 正确性：变量的定义和使用都正确吗？
+  - 易修改性：代码中对常数的使用是否都通过符号来进行，使其便于修改？
+  - 可预测性：是否避免了依赖于程序设计语言中的缺省值的代码？
+  - 健壮性：代码是否防止可以发现的运行时刻的错误？如下标变量越界，除数为零，变量值越界，栈溢出等等
+  - 结构性：程序的每一个功能是否都可以作为一块代码而识别出？
+  - 易追溯性：是否有修改历史记录，它记录对代码的所有修改历史和修改原因？
+  - 易理解性：注释是否使用简洁明了的语言对每一个子程序都作了充分的描述？
+  - 可验证性：实现是否避免了使用测试难度大的技术和方法？
+