哈尔滨工业大学计算机学院
唐好选
Email:tanghx@
净室软件工程(CSE)
“净室”（Cleanroom）一词源自半导体工业中硬件生产车间，
通过严格、洁净的生产过程预防了缺陷的产生，而不是在事后
再去排除故障。借用这个词，充分显示了净室技术“防患于未然”
的主导思想
净室基本概念
净室软件工程（CSE）是一种应用数学和统计学理论生产
软件的工程技术。力图通过严格的工程化的软件过程达到开发
中的零缺陷或接近零缺陷
通过在第一次正确的书写代码增量，并在测试前验证其正
确性来避免成本过高的缺陷消除过程。它的过程模型是在代码
增量集成到系统的同时，进行代码增量的统计质量验证。
净室方法的观点
强调规格说明和设计上严格性，使用基于数学的正确性证
明对结果设计模型的每个元素进行形式化验证，在规格说明和
设计中消除错误，以“干净”的方式进行制造。
20世纪70年代末80年代初，资深数学家和IBM客座科学家
Harlan Mills阐述了将数学、统计学及工程学上的基本概念应
用到软件的设想
净室软件工程的发展
Mills的观点：程序中出现错误的唯一方式是作者将错误引
入进去的。没有其他的方式……正确实践的目标是：设法避免
引入错误，通过测试或其它任何运行程序的方式来消除错误。
净室软件工程的发展
两大基本观点促进了Mills的工作：首先，程序是
数学函数规则，其次，潜在的程序执行是无穷的，
质量认证必须进行统计采样
第一个观点使所有函数理论向软件开发敞开大门，导
致以下技术的产生：盒式结构规范及设计、函数理论
正确性检验及增量开发
第二个观点使所有统计理论在软件测试方面得到应用，
导致了统计使用测试和质量认证
致力于通过防止软件缺陷来提高软件质量
立足于严格的科学理论基础
强调净室小组：制定系统规范、开发和认证；
基本目标是：开发过程的可管理性和使用时的无
失效性
净室软件工程的基本特点
函数理论和抽样理论
函数理论
一个函数定义了从定义域到值域的映射。一个特定的程
序好似定义了一个从定义域（所有可能的输入序列的集
合）到值域（所有对应于输入的输出集合）的映射。这
样，一个程序的规范就是一个函数的规范
抽样理论
不可能对软件的所有可能应用都进行测试。把软件的所
有可能的使用情况看作总体，通过统计学手段对其进行
抽样，并对样本进行测试，根据测试结果分析软件的性
能和可靠性
净室软件工程的理论基础
统计过程控制下的增量式开发（Incremental
Development）：增量是最终软件产品的功能子集，系统
功能随时间增加
基于函数的规范、设计：盒子结构方法按照函数理论定义
了三种抽象层次：行为视图、有限状态机视图和过程视图。
规范从一个外部行为视图（称为黑盒）开始
然后被转化为一个状态机视图（称为状态盒）
最后由一个过程视图（明盒）来实现
盒子结构是基于对象的
净室软件工程的技术手段
正确性验证：是CSE的核心，正是由于采用了这一技术，
净室项目的软件质量才有了极大的提高
统计测试（Statistically Based Testing）和软件认证：净
室测试方法采用统计学的基本原理，即当总体太大时必须
采取抽样的方法。首先确定一个使用模型（usage model）
来代表系统所有可能使用的（一般是无限的）总体。然后
由使用模型产生测试用例。因为测试用例是总体的一个随
机样本，所以可得到系统预期操作性能的有效统计推导
净室软件工程的技术手段
净室软件
工程的基
本模型
净室的组成
项目规划、项目管理、性能改善、工程变化
结构规范( 概念、模块、执行)
功能规范
需求分析
使用规范
增量设计、正确性验证
统计测试、认证
使用模型、测试规划
增量
规划
用
户
用户评价的
累计规范
用户评价的
累计认证增量
系
统
工
程
需求
收集
盒结构
规格
形式化
设计
正确性
验证
代码
检查
测试计划
统计性
使用
测试
认证
需求
收集
盒结构
规格
形式化
设计
正确性
验证
代码
检查
测试计划
统计性
使用
测试
认证
净室技术-增量开发技术
…
增量开发的理论基础
引用透明性原理:
一个表达式可用与其等值的任意子表达式代替,一个给
定函数(规范)f能改进为如下任何一种形式
do f1,f2 enddo
if p then f1 else f2 endif
while p do f1 enddo
函数的合并对原函数f在数值影响上必须等价
软件增量开发的基础在于为程序制定数学函数规则
因此程序开发作为一种自顶向下的控制结构或子函数
(子规范)的函数改进(规范)过程,将导致对象或函数的分解
或结合
功能规范
...
增量规划
增量设计/验证
增量1设计/验证
使用规范 增量测试与认证
增量2设计/验证
增量n设计/验证
产品评估与过程改进
增量1统计 增量1-2统计 增量1-n统计
增量开发的进度分配
增量1:定义顶层结构及桩组件
增量2:根据用户反馈,用新的可重用
桩组件代替桩组件
增量3:用新的可重用桩组件部件代替
桩组件
净室技术-基于函数规范的设计和验证
规范：
• 从一个外部视图(黑盒)开始转化为一个状态视图(状态盒),
由一个过程视图(明盒)来实现
• 三个盒形式不同,但行为等价，称为盒结构
• 将数学函数逐步扩展为逻辑连接词（如if-then-else）和子
函数构成的结构，这种扩展一直进行下去，直到所有标识
出来的子函数可以用程序设计语言直接表达
设计求精和验证
每个明盒规格说明代表了一个完成状态盒转换所需的过程
（子函数）的设计，使用结构化程序设计结构和逐步求精
在每个求精层次上，净室团队执行一次形式化正确性验证。
为此，将一类正确性条件集合附加到结构化程序设计结构上
如果函数f被扩展为序列g和h，则f所有输入的正确性条件
是：执行g之后再执行h能完成f的功能吗？
如果一个函数p被精化为if<c>then q else r的条件形式，
则对p的所有输入的正确性条件是（1）只要条件c为真，
q能完成p的功能吗？（2）只要条件c为假，r能完成p的功
能吗？
如果……
状 态
变换
状态盒
输入S 输出R
精
化
过
程
验
证
过
程
状态
BB1 BB2
明盒
S R
盒结构
精化和
验证
F=s* R
RSH
黑盒(所需行为)
历史激励
响应
黑盒规范的原则
对系统拥有者和用户:黑盒定义了他们分析和协
商所需的行为
对系统开发者:黑盒定义待设计和实现所需的行
为
对系统测试者:黑盒定义了在测试过程中待确认
所需的行为
黑盒的组成(例)
基于12个月平均销售额的预测部分情况
规则号
1
激励历史条件
<产品>历史记录
包含小于11个
月的<销售额>
<产品>历史记
录至少有11个
月的<销售额>
响应
接收<产品>
的<销售额>
不求平均
当前激励
2 <销售额>
<产品>
<销售额>
<产品>
<产品>的最近
<销售额>加上
当前的<销售额
>后求平均
状态盒
对系统或其组件进行初步细化;定义状态空间
状态信息来自黑盒中需要保存的激励元素
变换
当前的激励S (Stimulus) 映射响应R (Response)
旧状态OS (old State )映射到新状态NS (new State)
即 (OS,S) (NS,R)
状态盒组成（例）
销售额情况表
规则号 旧状态 激励 新状态 响应 黑盒规则号
<销售文件>
不含<产品>
记录
<销售额>
<产品>1
在<销售文件>中
为<产品>增加记
录出现最新<销售
额值>
收到<产品>的
<销售额值>但
不能求平均值
1
2 1
<销售文件>中
<产品>包含的
<销售额值>记
录少于11个月
<销售额>
<产品>
<产品>记录己
在<销售文件>
中,把<销售额
>作为最新<销
售额值>
收到<产品>
的<销售额值
>但不能求平
均值
明盒(清晰盒)
是一个计算机程序或程序集
将 (OS,S) (NS,R),借助过程实现
明盒的过程可以重用己有的黑盒或在求精过程中引入新
的黑盒
明盒的正确性验证是基于数学方法，证实一个过程与其
规范相符
盒子的层次结构
黑盒
状态盒
白盒
黑盒
状态盒
明盒
黑盒
状态盒
明盒
黑盒
状态盒
明盒
……
盒子结构原则
引用透明性(Referential Transparency)
明确组件所有需求，在逻辑上不需进一步规范
事务闭包(Transaction Closure)
事务是充分、足够的、可获得及保留所有状态数据
状态迁移(State Migration)
系统数据应该迁移和封装到最小的系统部分，不必复制更新
共享服务(Common Services)
对于多次用到的系统部分可定义共享服务，创建重用机会
净室技术-统计测试和软件认证
当测试的规模太大时,要采取抽样方法，选择一个模型(马尔
可夫模型、形式化语言等)代替使用的规模,然后用模型产生
测试用例(测试用例是规模的一个随机样本),可以得到系统预
期操作性能的有效统计推导
统计使用测试等同于“以用户试图使用软件的方式来测试软
件”。为了完成测试工作，净室测试团队必须确定软件的使
用概率分布，按照使用概率为每个触发集合生成测试用例
盒子结构开发过程
(1) 定义系统需求
(2) 确定和确认黑盒 (激励) (响应)
(3) 确定和验证状态盒
(状态,激励) (新状态,响应)
(4) 设计和验证明盒
(5) 对新黑盒重复上述过程
净室实例
设计并验证一个小的程序，该程序对某给定的整数
x，找出其平方根的整数部分y
净室实例-设计求精与验证
定义入口和出口条件。为了证明设计的正确性，需要证明图中
表示的条件init、loop、cont、yes和exit在所有情形下都是正
确的
净室实例-设计求精与验证
条件init：假定入口条件是正确的，因此，init条件的第一部分
x≥0 是满足的，在流程图中，init条件前的语句设置为y=0，因
此，init条件的第二部分也是满足的，因此，init为真
条件loop可能以两种方式之一出现（1）直接从init（满足）或
（2）通过穿过cont的控制流，因为条件cont与loop相同。无
论从哪条路径到达，条件loop都为真
条件cont：如果（y+1）2 ≤x，则y2 ≤x，条件成立
条件yes在条件逻辑中被测试，一定为真
x为被赋值或修改，保持不变，测试条件（y+1）2 ≤x不成立时
才能到达exit，因此（y+1）2 >x,loop条件必须为真，因此exit
满足
y递增而x不变，循环一定终止
CMM是软件组织进行软件过程改进以及评估和评
价软件能力的基准。但在具体的过程改进实施中，
需要有效的软件工程方法支持
净室软件工程正是为过程改进提供了具体实施方
法，它能够及早发现并消除缺陷，显著提高软件
的正确性、可靠性和可理解性，降低项目的成本，
提高软件质量，延长软件的生命周期
净室与CMM
可将净室软件工程应用到CMM的实践中，从组织管理和
技术工程实践两个方面改进软件过程，从而更加经济有效
地提升软件质量
在CMM中，关键实践仅仅描述了应该“做什么”，并没有给
出更没有规定“如何”去具体操作，操作的方法和步骤必须
由软件组织自己去解决
CMM只是对软件组织过程改进的指导，而非解决一切软
件开发过程中的问题的法宝。在实施CMM的过程中，仍
然需要有效的软件工程技术和方法，如“净室软件工程”方
法的支持
净室与CMM
基于CMM的净室裁剪
由于净室过程和技术的优点以及在
软件企业中实施所遇到的困难，有必
要对净室进行基于CMM的裁剪
基于CMM的裁剪原则
裁剪必须符合净室的基本原则（是净室区别于传统软件工程方
法的关键）
设计原则：开发人员应该并且能够生产出在被测试前就已经
达到趋于零缺陷的产品
测试原则：净室测试的目的不是寻找缺陷，而是度量软件产
品的质量和性能，为软件过程的改进提供统计数据
必须结合软件组织自身的能力成熟度现状。自身软件能力不同，
过程改进的主要目标也不相同
必须结合所开发软件的类型
基于净室的裁剪方法
引入净室的三个阶段
初始阶段：首先要引入净室小组开发的组织模式和质量控制下
的增量式生命周期模型，将开发与测试分离，建立起基本项目过
程。结合自身能力，引入形式化程度较低的黑盒规范与验证方法
中级阶段：加入更多必须的管理规范，明确定义自身的软件过
程。同时引入比较形式化的净室规范和验证技术，进一步降低开
发阶段的缺陷率，提高软件生产率。并根据需要进行有限的统计
测试
高级阶段：引入净室统计测试技术,很好地实现对质量和性能的
量化，为高层的决策提供可靠的数据依据
针对净室技术形式化程度的裁剪
(1) 对盒式规范技术的裁剪：
黑盒规范对系统的外部可见行为做一个完整的定义，隐藏了
软件设计和实现的所有细节，适用于软件开发的任何粒度中。
规范的描述形式可以不同：自然语言、半形式化的规范语言、
而严格的函数表达方法
状态盒规范是对系统内部数据的描述，它的实现形式依赖于
黑盒规范
明盒规范是对黑盒与状态盒逐步求精的实现,最终形式便是
源代码。既可以是结构化的，也可以是面向对象的，不受开发
方法和语言的限制
针对净室技术形式化程度的裁剪
(2) 对盒式规范验证技术的裁剪：验证过程基于非执行的测试方法
寻找并消除开发阶段的缺陷。因盒式规范的形式化不同，验证方
法也有相应变化。
检查方法简单易行，但是不够严格，基于潜在错误清单的审查
方法有规范的步骤，是一种经济有效的错误检测方法
基于函数理论的正确性证明，要求在盒式规范过程中，建立明
确的预期函数，这就要求盒式规范本身的形式化程度较高，此外
要求评审人员有相应的数学知识和专用CASE工具的支持
(3) 对统计测试技术的裁剪：规范和验证阶段采用的技术都不严格
时，更需测试过程来保证产品发布前的低缺陷，以减少产品的维
护费用
针对净室技术形式化程度的裁剪
CMM与净室技术都不是万能的。CMM提出的是完
整的软件开发和管理的过程，而净室更多的是技术方
面的支持。两者相互一致并相互补充。将二者合理地
结合，能够获得更高的软件质量、更低的开发成本，
更高的生产效率和更长的软件生命周期
净室过程的优点
特点
小组开发的组
织模式
统计控制下的
增量开发
开发与测试并
行进行
所起作用 1）降低人员间
的通信和协调
2）减少对权威
的依赖
3）提高团队的
开发能力
4）小组评审尽
早发现缺陷并显
著降低成本
1）开发过程可预
测
2）开发进度可见
3）开发在智能控
制下易于适应需求
的变化，促进持续
的求精
1）开发阶段就完
成预防缺陷和修
正缺陷的工作
2）测试过程完全
从用户使用角度
出发
3）重视质量的度
量与反馈
CSE太理论化，需要更多的数学知识。其正确性
验证的步骤比较困难且比较耗时
CSE要求采用增量式开发、采用盒子结构、采用
统计测试方法，普通工程师必须经过加强训练才
能掌握
CSE开发小组不进行传统的模块测试，这是不现
实的。工程师可能对编程语言和开发环境还不熟
悉，而且编译器或操作系统的bug也可能导致未
预期的错误
净室软件工程的缺点
净室过程中的关键技术分析
关键技术 优点 缺点
盒式结构
的规范方法
促进对需求的明确和理解，
利于复用，规范的文档，
便于验证
严格的形式化语言描述规范,难
以掌握和使用，需要专有的
CASE工具的支持，用户难以
理解；初期投入大,回报慢
基于数学理论
的正确性验证
尽早发现并消除缺陷，提
高质量,显著降低成本
对一般软件来说，代价太昂贵；
正确性证明难以寻找合适的预
期函数规范
使用模型的建
立和统计测试
与认证
从用户使用角度出发，利
于需求的理解和对开发人
员的反馈，实现对质量和
性能的量化
使用模型不易建立；需要统计
学知识和CASE工具的支持;需
要其他测试方法的补充
净室软件工程方法的效果
爱立信公司在手机操作系统OS32的开发中引入了经过裁剪
的净室技术。73人以个人或组际(team of teams)的方式工作了
33个月，通过15个增量过程开发了约33万行代码
以通信业广泛使用的SDL（规范与描述语言）完成盒式规范；
使用了小组评审技术，但没有进行正确性证明；建立了使用模
型，但只进行了很有限的统计测试
这个项目取得了令人满意的结果：集成和测试的时间减少了，
缺陷率比预期低了50%，而生产率则提高了70%以上。这足以
说明，通过合理裁剪的净室技术是能够非常有效地预防缺陷，
提高软件质量和生产率的
The End
