文件类型：PPT/Microsoft Powerpoint 文件大小：字节
软件测试技术与质量保证09软件测试技术与质量保证
主讲人:徐丽
第三章 软件质量保证
3.1 软件质量的定义
ANSI/IEEE 定义软件质量为"与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体"和M.J.Fisher定义软件质量为"所有描述计算机软件优秀程度的特性的组合".也就是说,为满足软件的各项精确定义的功能,性能需求,符合文档化的开发标准,需要相应地给出或设计一些质量特性及其组合,作为在软件开发与维护中的重要考虑因素.
软件质量反映了以下三方面的问题:
⑴ 软件需求是度量软件质量的基础.不符合需求的软件就不具备质量.
⑵ 在各种标准中定义了一些开发准则,用来指导软件人员用工程化的方法来开发软件.如果不遵守这些开发准则,软件质量就得不到保证.
⑶ 往往会有一些隐含的需求没有明确地提出来.例如,软件应具备良好的可维护性.如果软件只满足那些定义了的需求而没有满足这些隐含的需求,软件质量也不能保证.
软件质量是各种特性的复杂组合.它随着应用的不同而不同,随着用户提出的质量要求不同而不同.因此,有必要讨论各种质量特性,以及评价质量的准则.
3.1.1 影响软件质量的主要因素
虽然软件质量是难于定量的软件属性,但是仍然能够提出许多重要的软件质量指标.从管理角度对软件质量进行度量,可以把影响软件质量的主要因素分成以下几类:
⑴ 正确性:系统满足规格说明和用户目标的程度,即在预定环境下能正确地完成预期功能的程度.
⑵ 健壮性:在硬件发生故障,输入的数据无效或操作错误等意外环境下,系统能做出适当响应的程度.
⑶ 效率:为了完成预定的功能,系统需要的计算资源的多少.
⑷ 完整性(安全性):对未经授权的人使用软件或数据的企图,系统能够控制(禁止)的程度.
⑸ 可用性:系统在完成预定应该完成的功能时令人满意的程度.
⑹ 风险:按预定的成本和进度把系统开发出来,并且为用户所满意的概率.
⑺ 可理解性:理解和使用该系统的容易程度.
⑻ 可维修性:诊断和改正在运行现场发现的错误所需要的工作量的大小.
⑼ 灵活性(适应性):修改或改进正在运行的系统需要的工作量的多少.
⑽ 可测试性:软件容易测试的程度.
⑾ 可移植性:把程序从一种硬件配置和(或)软件系统环境转移到另一种配置和环境时,需要的工作量的多少.
⑿ 可复用性:在其他应用中该程序可以被再次使用的程度(或范围).
⒀ 互运行性:把该系统和另一个系统结合起来的工作量的多少.
3.1.2 改进关键质量因素
1.提高可复用性
人们在考虑做一件事的时候,总是习惯地先回想一下这件事以前做过没有,是如何做的.如果没有,则从头开始,否则就会沿用已有的经验和方法,提高做事的效率和准确度.这些经验和方法不断地总结和推广,就形成了解决新问题时常见的复用思想.在计算机程序设计中调用标准函数库中的函数,可以视为软件复用的早期的例子.
2.提高可扩充性
可扩充性问题是一个与规模有关的问题.通常的情况是:一个大型软件系统就像是一个宏伟但又很脆弱的大厦,只要抽出其中的一块砖头,都会使这座巨大的建筑物倒塌.
对改善可扩充性来说,主要应遵循两条原则:
⑴ 设计简单:简单的系统结构总是比复杂的系统结构更容易适应修改.
⑵ 控制分解:在软件系统结构中模块的独立性愈强,一个简单的修改只影响一个模块或只影响很少几个模块的可能性也就愈大,也就愈不致引起整个系统都需要修改那种连锁反应.
3.提高健壮性
健壮性讨论的是异常条件下软件的行为.它与正确性不同,正确性讨论的是在需求规格说明中明确陈述的软件行为.
健壮性在本质上是比正确性更为模糊的观念,它讨论的并不是在需求规格说明中明确陈述的问题,而是在某种情况下可能发生的问题.健壮性需求的作用在于保证:如果情况一旦发生,它应使系统的执行终止,或进入"降级运行"模式,而不致使系统发生灾难性事件.
3.2 软件质量保证的方法
为了在软件开发过程中保证软件的质量,主要采取下述方法:
1.审查
在软件生命周期每个阶段结束之前,都正式使用结束标准对该阶段生产出的软件配置成分进行严格的技术审查.
审查小组通常由4人组成:组长,作者和两名评审员.组长负责组织和领导技术审查,作者是开发文档或程序的人,两名评审员提出技术评论.建议评审员由和评审结果利害无关的人担任.
审查的步骤如下:
S1:计划:组织审查组,分发材料,安排日程等.
S2:概貌介绍:当项目复杂庞大时,可考虑由作者介绍概貌.
S3:准备:评审员阅读材料取得有关项目的知识.
S4:评审会:目的是发现和记录错误,通常每次会议不超过90分钟.
S5:返工:作者修改已经发现的问题.
S6:复查:判断返工是真正解决了问题.
一般说来,至少在生命周期每个阶段结束之前,应该进行一次正式的审查,某些阶段可能需要进行多次审查.
2.复审和管理复审
复查是检查已有的材料,以断定特定阶段的工作是否能够开始或继续.每个阶段开始时的复查,是为了肯定前一个阶段结束时确实进行了认真的审查,已经具备了开始当前阶段工作所必需的材料.管理复审通常指向开发组织或使用部门的管理人员,提供有关项目的总体状况,成本和进度等方面的情况,以便从管理角度对开发工作进行审查.
3.测试
所谓测试就是用已知的输入在已知环境中动态地执行系统(或系统的"部件").如果测试结果和预期结果不一致,则很可能发现了系统中的错误.测试过程中将产生下述基本文档:
⑴ 测试计划(通常包括单元测试和集成测试):确定测试范围,方法和需要的资源等.
⑵ 测试过程:详细描述和每个测试方案有关的测试步骤和数据,包括测试数据及预期的结果.
⑶ 测试结果:把每次测试运行的结果归入文档,如果运行出错,则应产生问题报告,并且必须通过调试解决发现的问题.
3.3 提高软件质量的技术
3.3.1 模块化
模块是数据说明,可执行语句等程序对象的集合,模块是可以单独命名的,而且可通过名字来访问,例如:C 语言中的函数,宏等都可作为模块.
把大型软件按照规定的原则划分成一个个较小的,相对独立但又相互关联的模块,叫做模块化设计.分解和模块独立性,是实现模块化设计的重要指导思想.
1.分解
分解是人们处理复杂问题常用的方法.对问题求解的大量实验表明,将一个复杂的问题分解为几个较小的问题,能够减少解题所需要的总工作量.用数学式来表示,可以写成:_
C ( P1 + P2 ) > C ( P1 ) + C ( P2 )
E ( P1 + P2 ) > E ( P1 ) + E ( P2 )
_ 其中,P1 ,P2 为问题,由问题 P1 + P2 分解而得,C 为问题的复杂度,E 为解题需要的工作量.
继续进行分解,问题的总复杂度和总工作量将继续减少,但如果无限的分下去,是否会使总工作量越来越小,最终变成可以忽略呢 不会.因为在一个软件系统内部,各组成模块之间是相互关联的.模块划分的数量越多,各模块之间的联系也就越多.模块本身的复杂度和工作量虽然随模块的变小而减少,模块的接口工作量却随着模块数的增加而增大.每个软件都存在一个最小成本区,把模块数控制在这一范围,可以使总的开发工作量保持最小.
2.模块独立性
模块独立性概括了把软件划分为模块时要遵守的准则,也是判断模块构造是不是合理的标准.坚持模块的独立性,一般认为是获得良好设计的关键.
独立性可以从两个方面来度量,即模块本身的内聚和模块之间的耦合.
内聚——是指模块内部各个成分之间的联系,所以也称为块内联系或模块强度;
耦合——是指一个模块与其它模块之间的联系,所以也称为块间联系.
模块的独立性愈高,则块内联系越强(高内聚),块间联系越弱(低耦合).
高内聚一般表现为:一个模块只做一件事.
低耦合一般表现为:与其它模块没有太多的联系.
模块化设计追求的目标是:低耦合,高内聚,但是实践表明内聚更重要,应该把更多注意力集中到提高模块的内聚程度上.
3.3.2 结构化
1966年,Bohm和Jacopini就在一篇文章中证明了:任何程序的逻辑均可用顺序,选择和循环(while 型)3种控制结构或它们的组合来实现,从而在理论上为结构程序设计奠定了基础.
1968年,Dijkstra建议仅使用这3种控制结构来构成程序.
1972年,Mills又向我们提示了一个重要的事实:如果在详细设计中,所有的模块都只使用单入口,单出口的3种基本控制结构,则不论一个程序包含多少模块,也不论一个模块包含多少基本控制结构,整个程序将保持一条清晰的线索.
这就是常说的控制结构的"结构化",它是程序设计阶段确保模块逻辑清晰的关键技术.
这里还有几点要补充说明:
⑴ 方便使用或者提高程序效率,大多数软件项目还允许在程序设计中补充使用(do – while)和(switch – case)两种控制结构.
⑵ 在许多情况下,当程序执行到满足某种条件时,需要立即从循环中转移出来.如果死抠单出口的原则,就会不必要地使循环重复下去,延长程序的执行时间.为了解决这类问题,在C语言中允许用break语句提前退出循环.
例如:
int n = 0;_
while (n b)
if (x > y)
b = y;
else
a = x;
else
a = b;
这种"if (…)"后面紧接着又出现"if"的结构含义模糊,不易分清其后出现的"else"究竟应与第一个"if"配套,还是与第二个"if"配套.改写为"else -- if"结构后,不仅可消除模糊理解,且提高了可读性.
if (a y)
b = y;
else
a = x;
3.3.3 文档化
我们知道一句名言"软件=程序+文档",但人们对软件的一般理解是限定于程序而不是文档,这是很多人对软件的一种误解,这种误解有其根深蒂固的生长土壤.人们确实将软件看成是一种产品,具有与其他产品一样的共性.直至现在,还常常有人喜欢按照自已的一套来"编程序",拿到一个软件开发课题后,在没有搞好需求分析,结构设计等工作的情况下,就急急忙忙动手来编程,
表面来看,这是赶进度,节约了时间,但欲速则不达,由于急于求成,编写程序时也往往忽略好的编码风格,这些都给以后的软件开发和维护工作带来潜在的隐患和很大的困难,也许过了一段时间才意识到,但为时已晚.应该说,这只是在写程序(代码),而不是在开发软件,对这样的人,宁愿称其为程序工人而非软件工程师,软件发展历史上的"力拔山兮气盖世"的个人英雄主义时代已经过去.无可讳言,单枪匹马,自以为是,孤芳自赏的作坊式作风仍然是制约我国软件产业发展的严重问题.
软件开发是一个把用户需求转化为软件需求,把软件需求转化为软件设计,用软件代码来实现软件设计,对软件代码进行测试,并确认它可以投入运行使用的过程.在这个过程中的每一阶段,都应该包含有相应的文档编制工作.在软件开发过程中,没有充分的分析,合理的设计,实现,这样开发中的软件产品必然是豆腐渣产品,经不起实际的检验.常常有人认为,软件项目成功的标志是交出能够正确运行的程序,文档是可有可无的.如果一定需要,也只是在程序本身完成之后再补上.这种仅仅为了交差才补写的文档往往和实际开发的程序存在很大差距,难以发挥其应有的作用.
符合要求的,规范化的文档在软件开发中的作用就如同零件图纸在产品开发中的作用一样,起着表达思想,传递信息的重要作用,是保证软件开发质量,提高软件可维护性,可靠性和可生产性的重要保障.
因此,软件绝不是程序的同义词.软件是与计算机系统的操作有关的程序,规程,规范及任何与之有关的文档及数据.
以上所述,是从软件工程的角度而非编码角度,虽然编码的目的是产生程序,但是为了提高程序的可维护性,源代码也需要实现文档化,这些称为内部文档编制.源程序文档包括选择标识符的名字,安排注释以及程序的视觉组织等.
3.3.4 程序设计风格
程序设计风格又称编码风格.
从20世纪70年代以来,编码的目标从强调效率转变到强调清晰.与此相应,编码风格也从追求"聪明"和"技巧",变为提倡"简明"和"直接".人们逐渐认识到,良好的编码风格能在一定程度上弥补语言存在的缺点,反之,不注意风格,即使使用了结构化的现代编程语言,也很难写出高质量的程序.当多个程序员合作编写一个大的程序时,尤其需要强调良好的和一致的风格,以利于相互通信,减少因不协调而引起的问题.
总而言之,程序设计风格要求编码时"清晰第一,效率第二".但需要重申的是清晰第一并非不要效率,而是在清晰的前提下求取效率.下面,我们借用Kernighan等在《程序设计风格要素》一书中的几条指导原则,来说明程序正确性,清晰度和效率之间的关系.它们是:
⑴ 先求正确后求快;
⑵ 先求清晰后求快;
⑶ 求快不忘保持程序正确;
⑷ 保持程序简单以求快;
⑸ 书写清晰,不要为"效率"牺牲清晰.
主讲人:徐丽
第三章 软件质量保证
3.1 软件质量的定义
ANSI/IEEE 定义软件质量为"与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体"和M.J.Fisher定义软件质量为"所有描述计算机软件优秀程度的特性的组合".也就是说,为满足软件的各项精确定义的功能,性能需求,符合文档化的开发标准,需要相应地给出或设计一些质量特性及其组合,作为在软件开发与维护中的重要考虑因素.
软件质量反映了以下三方面的问题:
⑴ 软件需求是度量软件质量的基础.不符合需求的软件就不具备质量.
⑵ 在各种标准中定义了一些开发准则,用来指导软件人员用工程化的方法来开发软件.如果不遵守这些开发准则,软件质量就得不到保证.
⑶ 往往会有一些隐含的需求没有明确地提出来.例如,软件应具备良好的可维护性.如果软件只满足那些定义了的需求而没有满足这些隐含的需求,软件质量也不能保证.
软件质量是各种特性的复杂组合.它随着应用的不同而不同,随着用户提出的质量要求不同而不同.因此,有必要讨论各种质量特性,以及评价质量的准则.
3.1.1 影响软件质量的主要因素
虽然软件质量是难于定量的软件属性,但是仍然能够提出许多重要的软件质量指标.从管理角度对软件质量进行度量,可以把影响软件质量的主要因素分成以下几类:
⑴ 正确性:系统满足规格说明和用户目标的程度,即在预定环境下能正确地完成预期功能的程度.
⑵ 健壮性:在硬件发生故障,输入的数据无效或操作错误等意外环境下,系统能做出适当响应的程度.
⑶ 效率:为了完成预定的功能,系统需要的计算资源的多少.
⑷ 完整性(安全性):对未经授权的人使用软件或数据的企图,系统能够控制(禁止)的程度.
⑸ 可用性:系统在完成预定应该完成的功能时令人满意的程度.
⑹ 风险:按预定的成本和进度把系统开发出来,并且为用户所满意的概率.
⑺ 可理解性:理解和使用该系统的容易程度.
⑻ 可维修性:诊断和改正在运行现场发现的错误所需要的工作量的大小.
⑼ 灵活性(适应性):修改或改进正在运行的系统需要的工作量的多少.
⑽ 可测试性:软件容易测试的程度.
⑾ 可移植性:把程序从一种硬件配置和(或)软件系统环境转移到另一种配置和环境时,需要的工作量的多少.
⑿ 可复用性:在其他应用中该程序可以被再次使用的程度(或范围).
⒀ 互运行性:把该系统和另一个系统结合起来的工作量的多少.
3.1.2 改进关键质量因素
1.提高可复用性
人们在考虑做一件事的时候,总是习惯地先回想一下这件事以前做过没有,是如何做的.如果没有,则从头开始,否则就会沿用已有的经验和方法,提高做事的效率和准确度.这些经验和方法不断地总结和推广,就形成了解决新问题时常见的复用思想.在计算机程序设计中调用标准函数库中的函数,可以视为软件复用的早期的例子.
2.提高可扩充性
可扩充性问题是一个与规模有关的问题.通常的情况是:一个大型软件系统就像是一个宏伟但又很脆弱的大厦,只要抽出其中的一块砖头,都会使这座巨大的建筑物倒塌.
对改善可扩充性来说,主要应遵循两条原则:
⑴ 设计简单:简单的系统结构总是比复杂的系统结构更容易适应修改.
⑵ 控制分解:在软件系统结构中模块的独立性愈强,一个简单的修改只影响一个模块或只影响很少几个模块的可能性也就愈大,也就愈不致引起整个系统都需要修改那种连锁反应.
3.提高健壮性
健壮性讨论的是异常条件下软件的行为.它与正确性不同,正确性讨论的是在需求规格说明中明确陈述的软件行为.
健壮性在本质上是比正确性更为模糊的观念,它讨论的并不是在需求规格说明中明确陈述的问题,而是在某种情况下可能发生的问题.健壮性需求的作用在于保证:如果情况一旦发生,它应使系统的执行终止,或进入"降级运行"模式,而不致使系统发生灾难性事件.
3.2 软件质量保证的方法
为了在软件开发过程中保证软件的质量,主要采取下述方法:
1.审查
在软件生命周期每个阶段结束之前,都正式使用结束标准对该阶段生产出的软件配置成分进行严格的技术审查.
审查小组通常由4人组成:组长,作者和两名评审员.组长负责组织和领导技术审查,作者是开发文档或程序的人,两名评审员提出技术评论.建议评审员由和评审结果利害无关的人担任.
审查的步骤如下:
S1:计划:组织审查组,分发材料,安排日程等.
S2:概貌介绍:当项目复杂庞大时,可考虑由作者介绍概貌.
S3:准备:评审员阅读材料取得有关项目的知识.
S4:评审会:目的是发现和记录错误,通常每次会议不超过90分钟.
S5:返工:作者修改已经发现的问题.
S6:复查:判断返工是真正解决了问题.
一般说来,至少在生命周期每个阶段结束之前,应该进行一次正式的审查,某些阶段可能需要进行多次审查.
2.复审和管理复审
复查是检查已有的材料,以断定特定阶段的工作是否能够开始或继续.每个阶段开始时的复查,是为了肯定前一个阶段结束时确实进行了认真的审查,已经具备了开始当前阶段工作所必需的材料.管理复审通常指向开发组织或使用部门的管理人员,提供有关项目的总体状况,成本和进度等方面的情况,以便从管理角度对开发工作进行审查.
3.测试
所谓测试就是用已知的输入在已知环境中动态地执行系统(或系统的"部件").如果测试结果和预期结果不一致,则很可能发现了系统中的错误.测试过程中将产生下述基本文档:
⑴ 测试计划(通常包括单元测试和集成测试):确定测试范围,方法和需要的资源等.
⑵ 测试过程:详细描述和每个测试方案有关的测试步骤和数据,包括测试数据及预期的结果.
⑶ 测试结果:把每次测试运行的结果归入文档,如果运行出错,则应产生问题报告,并且必须通过调试解决发现的问题.
3.3 提高软件质量的技术
3.3.1 模块化
模块是数据说明,可执行语句等程序对象的集合,模块是可以单独命名的,而且可通过名字来访问,例如:C 语言中的函数,宏等都可作为模块.
把大型软件按照规定的原则划分成一个个较小的,相对独立但又相互关联的模块,叫做模块化设计.分解和模块独立性,是实现模块化设计的重要指导思想.
1.分解
分解是人们处理复杂问题常用的方法.对问题求解的大量实验表明,将一个复杂的问题分解为几个较小的问题,能够减少解题所需要的总工作量.用数学式来表示,可以写成:_
C ( P1 + P2 ) > C ( P1 ) + C ( P2 )
E ( P1 + P2 ) > E ( P1 ) + E ( P2 )
_ 其中,P1 ,P2 为问题,由问题 P1 + P2 分解而得,C 为问题的复杂度,E 为解题需要的工作量.
继续进行分解,问题的总复杂度和总工作量将继续减少,但如果无限的分下去,是否会使总工作量越来越小,最终变成可以忽略呢 不会.因为在一个软件系统内部,各组成模块之间是相互关联的.模块划分的数量越多,各模块之间的联系也就越多.模块本身的复杂度和工作量虽然随模块的变小而减少,模块的接口工作量却随着模块数的增加而增大.每个软件都存在一个最小成本区,把模块数控制在这一范围,可以使总的开发工作量保持最小.
2.模块独立性
模块独立性概括了把软件划分为模块时要遵守的准则,也是判断模块构造是不是合理的标准.坚持模块的独立性,一般认为是获得良好设计的关键.
独立性可以从两个方面来度量,即模块本身的内聚和模块之间的耦合.
内聚——是指模块内部各个成分之间的联系,所以也称为块内联系或模块强度;
耦合——是指一个模块与其它模块之间的联系,所以也称为块间联系.
模块的独立性愈高,则块内联系越强(高内聚),块间联系越弱(低耦合).
高内聚一般表现为:一个模块只做一件事.
低耦合一般表现为:与其它模块没有太多的联系.
模块化设计追求的目标是:低耦合,高内聚,但是实践表明内聚更重要,应该把更多注意力集中到提高模块的内聚程度上.
3.3.2 结构化
1966年,Bohm和Jacopini就在一篇文章中证明了:任何程序的逻辑均可用顺序,选择和循环(while 型)3种控制结构或它们的组合来实现,从而在理论上为结构程序设计奠定了基础.
1968年,Dijkstra建议仅使用这3种控制结构来构成程序.
1972年,Mills又向我们提示了一个重要的事实:如果在详细设计中,所有的模块都只使用单入口,单出口的3种基本控制结构,则不论一个程序包含多少模块,也不论一个模块包含多少基本控制结构,整个程序将保持一条清晰的线索.
这就是常说的控制结构的"结构化",它是程序设计阶段确保模块逻辑清晰的关键技术.
这里还有几点要补充说明:
⑴ 方便使用或者提高程序效率,大多数软件项目还允许在程序设计中补充使用(do – while)和(switch – case)两种控制结构.
⑵ 在许多情况下,当程序执行到满足某种条件时,需要立即从循环中转移出来.如果死抠单出口的原则,就会不必要地使循环重复下去,延长程序的执行时间.为了解决这类问题,在C语言中允许用break语句提前退出循环.
例如:
int n = 0;_
while (n b)
if (x > y)
b = y;
else
a = x;
else
a = b;
这种"if (…)"后面紧接着又出现"if"的结构含义模糊,不易分清其后出现的"else"究竟应与第一个"if"配套,还是与第二个"if"配套.改写为"else -- if"结构后,不仅可消除模糊理解,且提高了可读性.
if (a y)
b = y;
else
a = x;
3.3.3 文档化
我们知道一句名言"软件=程序+文档",但人们对软件的一般理解是限定于程序而不是文档,这是很多人对软件的一种误解,这种误解有其根深蒂固的生长土壤.人们确实将软件看成是一种产品,具有与其他产品一样的共性.直至现在,还常常有人喜欢按照自已的一套来"编程序",拿到一个软件开发课题后,在没有搞好需求分析,结构设计等工作的情况下,就急急忙忙动手来编程,
表面来看,这是赶进度,节约了时间,但欲速则不达,由于急于求成,编写程序时也往往忽略好的编码风格,这些都给以后的软件开发和维护工作带来潜在的隐患和很大的困难,也许过了一段时间才意识到,但为时已晚.应该说,这只是在写程序(代码),而不是在开发软件,对这样的人,宁愿称其为程序工人而非软件工程师,软件发展历史上的"力拔山兮气盖世"的个人英雄主义时代已经过去.无可讳言,单枪匹马,自以为是,孤芳自赏的作坊式作风仍然是制约我国软件产业发展的严重问题.
软件开发是一个把用户需求转化为软件需求,把软件需求转化为软件设计,用软件代码来实现软件设计,对软件代码进行测试,并确认它可以投入运行使用的过程.在这个过程中的每一阶段,都应该包含有相应的文档编制工作.在软件开发过程中,没有充分的分析,合理的设计,实现,这样开发中的软件产品必然是豆腐渣产品,经不起实际的检验.常常有人认为,软件项目成功的标志是交出能够正确运行的程序,文档是可有可无的.如果一定需要,也只是在程序本身完成之后再补上.这种仅仅为了交差才补写的文档往往和实际开发的程序存在很大差距,难以发挥其应有的作用.
符合要求的,规范化的文档在软件开发中的作用就如同零件图纸在产品开发中的作用一样,起着表达思想,传递信息的重要作用,是保证软件开发质量,提高软件可维护性,可靠性和可生产性的重要保障.
因此,软件绝不是程序的同义词.软件是与计算机系统的操作有关的程序,规程,规范及任何与之有关的文档及数据.
以上所述,是从软件工程的角度而非编码角度,虽然编码的目的是产生程序,但是为了提高程序的可维护性,源代码也需要实现文档化,这些称为内部文档编制.源程序文档包括选择标识符的名字,安排注释以及程序的视觉组织等.
3.3.4 程序设计风格
程序设计风格又称编码风格.
从20世纪70年代以来,编码的目标从强调效率转变到强调清晰.与此相应,编码风格也从追求"聪明"和"技巧",变为提倡"简明"和"直接".人们逐渐认识到,良好的编码风格能在一定程度上弥补语言存在的缺点,反之,不注意风格,即使使用了结构化的现代编程语言,也很难写出高质量的程序.当多个程序员合作编写一个大的程序时,尤其需要强调良好的和一致的风格,以利于相互通信,减少因不协调而引起的问题.
总而言之,程序设计风格要求编码时"清晰第一,效率第二".但需要重申的是清晰第一并非不要效率,而是在清晰的前提下求取效率.下面,我们借用Kernighan等在《程序设计风格要素》一书中的几条指导原则,来说明程序正确性,清晰度和效率之间的关系.它们是:
⑴ 先求正确后求快;
⑵ 先求清晰后求快;
⑶ 求快不忘保持程序正确;
⑷ 保持程序简单以求快;
⑸ 书写清晰,不要为"效率"牺牲清晰.
·上一篇：软件测试引论
·下一篇：先进软件测试技术