| 软件开发 |
| --- |
| 
核心行动 |
| * 过程
* 需求
* 设计
* 工程
* 构造（英语：）
* 测试
* 偵錯
* 部署
* 維護
 |
| 
范式与模式 |
| * 原型设计（英语：）
* 净室（英语：）
* 增量建模（英语：）
* 瀑布模型
* 敏捷软件开发
* 螺旋模型
 |
| 方法论与框架 |
| * 快速應用程式開發
* DevOps
* 极限编程
* 团队软件流程（英语：）
* 個人軟體程序
* 动态系统开发方法（英语：）
* MSF（英语：）
* Scrum
* 看板
* V模型
* FDD（英语：）
* MDD
* 迭代式开发
* 精實开发
* 统一流程（英语：）
 |
| 
支持行为 |
| * 配置管理
* 文档
* 质量保证
* 项目管理
* 用户体验
 |
| 
实践 |
| * ATDD（英语：）
* 行为驱动开发
* 持續整合
* 持續交付
* 領域驅動設計
* 结对编程
* 站会
* 测试驱动开发
 |
| 工具 |
| * 編譯器
* 偵錯器
* 性能分析
* GUI设计器（英语：）
* 建模（英语：）
* 集成开发环境
* 組建自動化
* 发布自动化（英语：）
* 测试
 |
| 
标准与知识体系 |
| * 能力成熟度模型集成
* IEEE标准
* ISO 9001
* ISO/IEC标准（英语：）
* SWEBOK（英语：）
* 项目管理知识体系
* BABOK（英语：）
 |
| * 
* 论
* 编
 |

在计算机科学中，**程序分析**是指自动分析一个程序的包括正确性、健壮性、安全性和活跃性等特征的过程。
程序分析主要研究两大领域：程序的优化（英语：）和程序的正确性。前者研究如何提升程序性能并且降低程序的资源占用，后者研究如何确保程序完成预期的任务。

程序分析可以在不执行程序的情况下进行（静态程序分析），也可在执行时进行（动态程序分析（英语：）），或结合二者。

静态程序分析
------

条目：静态程序分析
在程序正确性里，静态分析可以在程序的开发阶段就发现漏洞。这些漏洞通常比测试阶段发现的漏洞更容易修复，因为静态分析可以直接发现漏洞的根源。

由于很多静态分析其实无法确切地判定，因此实现静态分析的机制不总返回正确的结果——要么是返回了一个假阴性（返回"没有发现问题"然而程序其实存在问题）或者是返回了一个假阳性，要么它们不返回错误的结果但是有时候不会终止。尽管它们或多或少地存在种种不足，然而前者可能帮助降低漏洞的数量，而后者则在一些时候可以明确确定程序不受某类漏洞的威胁。

不正确的优化是谁都不希望的，所以在程序优化里，有两类策略来处理无法判定的分析情况：

1. 设计一个优化器时，如果认为它应该很快完成它的任务（例如编译器里的优化器），那么可以用一个削减过的分析算法来保证可以在一个有限的时间内完成，并且保证只做正确的优化。
2. 一个第三方的优化器可能会被设计为永远不会输出一个错误的优化，但是有时候可能在找到正确的优化前永远都不会停下来（可能永远也找不到）。这种时候，开发者可能需要关掉这一工具并且避免它再次在要优化的代码上运行（或者也可以修改代码来避免触发这个工具）。

然而，还有第三种策略有时可以用于一些规范不够完整的语言（比如C语言）。一个做优化的编译器在遇到未定义行为时，可以自主选择如何生成这部分代码。生成的代码可以在运行时做任何事情，甚至可以崩溃。

### 控制流

条目：控制流分析
控制流分析的目的是获取在程序执行时一些特定位置可能调用的函数的信息。这些信息由控制流圖（英语：control flow graph，简称CFG）来表示，其中节点表示程序的指令，边表示控制流。
通过识别代码块和循环，CFG常常被编译器当作优化的起始点。

### 数据流分析

条目：数据流分析
数据流分析收集程序运行到不同位置时各个值的信息和它们随时间变化的信息。这一技巧也常被编译器用来优化代码。
一个有名的数据流分析的例子叫做污点检验，它考虑所有的可能被使用者修改的变量（也就是有"污点"、不安全的变量），并阻止这些变量在被"消毒"前被使用。这一技巧常被用来避免SQL注入攻击。污点检验既可以静态完成也可以动态完成。

### 抽象释义

条目：抽象释义
抽象释义允许在不执行程序时提取出某个可能的执行的信息。
这个信息可以让编译器寻找某条可行的优化路径，也可以证明一个程序不会存在某些问题。

### 类型系统

条目：类型系统
类型系统给程序关联上满足特定条件的类型。类型系统的目的是选出一个编程语言编写的程序的一个子集，使这个子集满足特定的性质。

* 类型检查——验证一个程序是否被类型系统接受

类型检查被用来限制程序中一个对象如何被使用以及一个对象能做什么。类型检查是由编译器或解释器完成的。类型检查也可以帮助避免如将有符号变量赋值给无符号变量所带来的漏洞。
类型检查可以静态完成（在编译期间），也可以动态完成（在运行时），或者结合二者。

静态类型信息（可以通过类型推论，或者由代码明确给出）也可以被用来做优化，例如把封包的数组替换为未封包的数组。

### 作用系统

作用系统（英语：）是一类用来给出函数或方法的作用的形式化系统。一个作用（英文：effect）规定了做了什么以及对谁做了——通常称之为作用类型（英文：effect kind）以及作用范围（英文：region）。

### 模型检查

模型检查（英语：）指一类严格、形式化并且自动的检查一个*模型*（在这里指一段代码的形式化模型，但在其他语境下也可以指一个硬件的模型）是否符合给定规范的方法。基于代码内在状态有限这一特点，且规范和代码都可以被转换为逻辑公式，我们有能力用算法来检查一个系统是否违反规范。

动态程序分析
------

动态程序分析（英语：）可以用程序运行时的信息来提高分析的精度并且提供运行时保护，然而它只能分析单次运行的情况，并且可能因为进行运行时检查而降低运行性能。

### 测试

条目：软件测试
每个软件都应当被测试来确保其质量，保证其按照期望稳定运行，并且确保其不会与其他软件冲突。测试一般通过运行程序并给定一组输入然后来评估程序给出的输出。
即使软件没有指定好的安全性要求，也应当对其进行额外的安全性测试（英语：）从而保证攻击者无法随意修改软件并盗取数据、妨碍软件的正常工作或者用它当作攻击其他用户的跳板。

### 监控

程序监控会记录程序的诸多信息（例如资源占用、事件、交互等），使之可以在之后被用来寻找或定位异常行为的原因。此外，它还可以被用来做安全审查。程序的自动监控有时也被称为运行时检查（英语：）。

### 程序切片

对于一个给定的程序的行为的子集，程序切片（英语：）将程序削减到保持给定行为的最小形式。被削减后的程序被称之为一个"切片"，是原程序在给定行为子集上的一个正确表示。
通常而言，找到切片是一个无法解决的问题。但是通过给定一组变量的值的行为的子集，有可能通过数据流算法来找到大约符合条件的切片。这些切片通常被开发者用来调试从而找到错误的原因。

参考文献
----

1. ↑  Nielson, F. Nielson, H. R. & Hankin, C. (2015). Principles of program analysis. Springer.
2. ↑  Jovanovic, N. Kruegel, C. & Kirda, E. (2006, May). Pixy: A static analysis tool for detecting web application vulnerabilities. In Security and Privacy, 2006 IEEE Symposium on (pp. 6-pp). IEEE.

延伸阅读
----

* Agrawal, Hiralal; Horgan, Joseph R. .
* Chunlei, Wang; Gang, Zhao; Yiqi, Dai. .
* Nielson, Flemming; Nielson, Hanne Riis; Hankin, Chris.. Springer Science+Business Media. 2005.

参见
--

* 自动代码审查
* 基于语言的安全性（英语：）
* 性能分析
* 形式验证

外部链接
----

* 维基共享资源上的相關多媒體資源：程序分析