软件工程导论第7章编码和单元测试.docx
《软件工程导论第7章编码和单元测试.docx》由会员分享，可在线阅读，更多相关《软件工程导论第7章编码和单元测试.docx（51页珍藏版）》请在冰豆网上搜索。
软件工程导论第7章编码和单元测试
第7章实现
通常把编码和测试统称为实现。
所谓编码就是把软件设计结果翻译成用某种程序设计语言书写的程序。
作为软件工程过程的一个阶段，编码是对设计的进一步具体化，因此，程序的质量主要取决于软件设计的质量。
但是，所选用的程序设计语言的特点及编码风格也将对程序的可靠性、可读性、可测试性和可维护性产生深远的影响。
无论怎样强调软件测试的重要性和它对软件可靠性的影响都不过分。
在开发大型软件系统的漫长过程中，面对着极其错综复杂的问题，人的主观认识不可能完全符合客观现实，与工程密切相关的各类人员之间的通信和配合也不可能完美无缺，因此，在软件生命周期的每个阶段都不可避免地会产生差错。
我们力求在每个阶段结束之前通过严格的技术审查，尽可
能早地发现并纠正差错；但是，经验表明审查并不能发现所有差错，此外在编码过程中还不可避免地会引入新的错误。
如果在软件投入生产性运行之前，没有发现并纠正软件中的大部分差错，则这些差错迟早会在生产过程中暴露出来，那时不仅改正这些错误的代价更高，而且往往会造成很恶劣的后果。
测试的目的就是在软件投入生产性运行之前，尽可能多地发现
软件中的错误。
目前软件测试仍然是保证软件质量的关键步骤，它是对软件规格说明、设计和编码的最后复审。
软件测试在软件生命周期中横跨两个阶段。
通常在编写出每个模块之后就对它做必要的测试（称为单元测试），模块的编写者和测试者是同一个人，编码和单元测试属于软件生命周期的同一个阶段。
在这个阶段结束之后，对软件系统还应该进行各种综合测试，这是软件生命周期中的另一个独立的阶段，通常由专门的测试人员承担这项工作。
大量统计资料表明，软件测试的工作量往往占软件开发总工作量的40％以上，在极端情况，测试那种关系人的生命安全的软件所花费的成本，可能相当于软件工程其他开发步骤总成本的3倍到5倍。
因此，必须高度重视软件测试工作，绝不要以为写出程序之后软件开发工作就接近完成了，实际上，大约还有同样多的开发工作量需要完成。
仅就测试而言，它的目标是发现软件中的错误，但是，发现错误并不是最终目的。
软件工程的根本目标是开发出高质量的完全符合用户需要的软件，因此，通过测试发现错误之后还必须诊断并改正错误，这就是调试的目的。
调试是测试阶段最困难的工作。
在对测试结果进行收集和评价的时候，软件所达到的可靠性也开始明朗了。
软件可靠性模型使用故障率数据，估计软件将来出现故障的情况并预测软件的可靠性。
7.1编码
7.1.1选择程序设计语言
程序设计语言是人和计算机通信的最基本的工具，它的特点必然会影响人的思维和解题方式，会影响人和计算机通信的方式和质量，也会影响其他人阅读和理解程序的难易程度。
因此，编码之前的一项重要工作就是选择一种适当的程序设计语言。
适宜的程序设计语言能使根据设计去完成编码时困难最少，可以减少需要的程序测试量，并且可以得出更容易阅读和更容易维护的程序。
由于软件系统的绝大部分成本用在生命周期的测试和维护阶段，所以容易测试和容易维护是极端重要的。
使用汇编语言编码需要把软件设计翻译成机器操作的序列，由于这两种表示方法很不相同，因此汇编程序设计既困难又容易出差错。
一般说来，高级语言的源程序语句和汇编代码指令之间有一句对多句的对应关系。
统计资料表明，程序员在相同时间内可以写出的高级语言语句数和汇编语言指令数大体相同，因此用高级语言写程序比用汇编语言写程序生产率可以提高好几倍。
高级语言一般都容许用户给程序变量和子程序赋予含义鲜明的名字，通过名字很容易把程序对象和它们所代表的实体联系起来；此外，高级语言使用的符号和概念更符合人的习惯。
因此，用高级语言写的程序容易阅读，容易测试，容易调试，容易维护。
总的说来，高级语言明显优于汇编语言，因此，除了在很特殊的应用领域（例如，对程序执行时间和使用的空间都有很严格限制的情况；需要产生任意的甚至非法的指令序列；体系结构特殊的微处理机，以致在这类机器上通常不能实现高级语言编译程序），或者大型系统中执行时间非常关键的（或直接依赖于硬件的）一小部分代码需要用汇编语言书写之外，其他程序应该一律用高级语言书写。
为了使程序容易测试和维护以减少软件的总成本，所选用的高级语言应该有理想的模块化机制，以及可读性好的控制结构和数据结构；为了便于调试和提高软件可靠性，语言特点应该使编译程序能够尽可能多地发现程序中的错误；为了降低软件开发和维护的成本，选用的高级语言应该有良好的独立编译机制。
上述这些要求是选择程序设计语言的理想标准，但是，在实际选择语言时不能仅仅使用理论上的标准，还必须同时考虑实用方面的各种限制。
下面是主要的实用标准：
（1）系统用户的要求。
如果所开发的系统由用户负责维护，用户通常要求用他们熟悉的语言书写程序。
（2）可以使用的编译程序。
运行目标系统的环境中可以提供的编译程序往往限制了可以选用的语言的范围。
（3）可以得到的软件工具。
如果某种语言有支持程序开发的软件工具可以利用，则目标系统的实现和验证都变得比较容易。
（4）工程规模。
如果工程规模很庞大，现有的语言又不完全适用，那么设计并实现一种供这个工程项目专用的程序设计语言，可能是一个正确的选择。
（5）程序员的知识。
虽然对于有经验的程序员来说，学习一种新语言并不困难，但是要完全掌握一种新语言却需要实践。
如果和其他标准不矛盾，那么应该选择一种已经为程序员所熟悉的语言。
（6）软件可移植性要求。
如果目标系统将在几台不同的计算机上运行，或者预期的使用寿命很长，那么选择一种标准化程度高、程序可移植性好的语言就是很重要的。
（7）软件的应用领域。
所谓的通用程序设计语言实际上并不是对所有应用领域都同样适用，例如，FORTRAN语言特别适合于工程和科学计算，COBOI。
语言适合于商业领域应用，c语言和Ada语言适用于系统和实时应用领域，LISP语言适用于组合问题领域，PROLOG语言适于表达知识和推理。
因此，选择语言时应该充分考虑目标系统的应用范围。
7.1.2编码风格
源程序代码的逻辑简明清晰、易读易懂是好程序的一个重要标准，为了做到这一点，
应该遵循下述规则。
1.程序内部的文档
所谓程序内部的文档包括恰当的标识符、适当的注解和程序的视觉组织等等。
选取含义鲜明的名字，使它能正确地提示程序对象所代表的实体，这对于帮助阅读者理解程序是很重要的。
如果使用缩写，那么缩写规则应该一致，并且应该给每个名字加注解。
注解是程序员和程序读者通信的重要手段，正确的注解非常有助于对程序的理解。
通常在每个模块开始处有一段序言性的注解，简要描述模块的功能、主要算法、接口特点、重要数据以及开发简史。
插在程序中间与一段程序代码有关的注解，主要解释包含这段代码的必要性。
对于用高级语言书写的源程序，不需要用注解的形式把每个语句翻译成自然语言，应该利用注解提供一些额外的信息。
应该用空格或空行清楚地区分注解和程序。
注解的内容一定要正确，错误的注解不仅对理解程序毫无帮助，反而会妨碍对程序的理解。
程序清单的布局对于程序的可读性也有很大影响，应该利用适当的阶梯形式使程序的层次结构清晰明显。
2.数据说明
虽然在设计期间已经确定了数据结构的组织和复杂程度，然而数据说明的风格却是在写程序时确定的。
为了使数据更容易理解和维护，有一些比较简单的原则应该遵循。
数据说明的次序应该标准化（例如，按照数据结构或数据类型确定说明的次序）。
有次序就容易查阅，因此能够加速测试、调试和维护的过程。
当多个变量名在一个语句中说明时，应该按字母顺序排列这些变量。
如果设计时使用了一个复杂的数据结构，则应该用注解说明用程序设计语言实现这个数据结构的方法和特点。
3.语句构造
设计期间确定了软件的逻辑结构，然而个别语句的构造却是编写程序的一个主要任务。
构造语句时应该遵循的原则是，每个语句都应该简单而直接，不能为了提高效率而使程序变得过分复杂。
下述规则有助于使语句简单明了：
·不要为了节省空间而把多个语句写在同一行；
·尽量避免复杂的条件测试；
·尽量减少对“非”条件的测试；
·避免大量使用循环嵌套和条件嵌套；
·利用括号使逻辑表达式或算术表达式的运算次序清晰直观。
4.输入输出
在设计和编写程序时应该考虑下述有关输入输出风格的规则：
·对所有输入数据都进行检验；
·检查输入项重要组合的合法性；
·保持输入格式简单；
·使用数据结束标记，不要要求用户指定数据的数目；
·明确提示交互式输入的请求，详细说明可用的选择或边界数值；
·当程序设计语言对格式有严格要求时，应保持输入格式一致；
·设计良好的输出报表；
·给所有输出数据加标志。
5.效率
效率主要指处理机时间和存储器容量两个方面。
虽然值得提出提高效率的要求，但是在进一步讨论这个问题之前应该记住3条原则：
首先，效率是性能要求，因此应该在需求分析阶段确定效率方面的要求。
软件应该像对它要求的那样有效，而不应该如同人类可能做到的那样有效。
其次，效率是靠好设计来提高的。
第三，程序的效率和程序的简单程度是一致的，不要牺牲程序的清晰性和可读性来不必要地提高效率。
下面从三个方面进一步讨论效率问题。
（1）程序运行时间
源程序的效率直接由详细设计阶段确定的算法的效率决定，但是，写程序的风格也能对程序的执行速度和存储器要求产生影响。
在把详细设计结果翻译成程序时，总可以应用下述规则：
·写程序之前先简化算术的和逻辑的表达式；
·仔细研究嵌套的循环，以确定是否有语句可以从内层往外移；
·尽量避免使用多维数组；
·尽量避免使用指针和复杂的表；
·使用执行时间短的算术运算；
·不要混合使用不同的数据类型；
·尽量使用整数运算和布尔表达式。
在效率是决定性因素的应用领域，尽量使用有良好优化特性的编译程序，以自动生成高效目标代码。
（2）存储器效率
在大型计算机中必须考虑操作系统页式调度的特点，一般说来，使用能保持功能域的结构化控制结构，是提高效率的好方法。
在微处理机中如果要求使用最少的存储单元，则应选用有紧缩存储器特性的编译程序，在非常必要时可以使用汇编语言。
提高执行效率的技术通常也能提高存储器效率。
提高存储器效率的关键同样
是“简单”。
（3）输入输出的效率
如果用户为了给计算机提供输入信息或为了理解计算机输出的信息，所需花费的脑力劳动是经济的，那么人和计算机之间通信的效率就高。
因此，简单清晰同样是提高人机通信效率的关键。
硬件之间的通信效率是很复杂的问题，但是，从写程序的角度看，却有些简单的原则可以提高输入输出的效率。
例如：
·所有输入输出都应该有缓冲，以减少用于通信的额外开销；
·对二级存储器（如磁盘）应选用最简单的访问方法；
·二级存储器的输入输出应该以信息组为单位进行；
·如果“超高效的”输入输出很难被人理解，则不应采用这种方法。
这些简单原则对于软件工程的设计和编码两个阶段都适用。
7.2软件测试基础
本节讲述软件测试的基本概念和基础知识。
表面看来，软件测试的目的与软件工程所有其他阶段的目的都相反。
软件工程的其他阶段都是“建设性”的：
软件工程师力图从抽象的概念出发，逐步设计出具体的软件系统，直到用一种适当的程序设计语言写出可以执行的程序代码。
但是，在测试阶段测试人员努力设计出一系列测试方案，目的却是为了“破坏”已经建造好的软件系统——竭力证明程序中有错误不能按照预定要求正确工作。
当然，这种反常仅仅是表面的，或者说是心理上的。
暴露问题并不是软件测试的最终目的，发现问题是为了解决问题，测试阶段的根本目标是尽可能多地发现并排除软件中潜藏的错误，最终把一个高质量的软件系统交给用户使用。
但是，仅就测试本身而言，它的目标可能和许多人原来设想的很不相同。
7.2.1软件测试的目标
什么是测试?
它的目标是什么?
G.Myers给出了关于测试的一些规则，这些规则也可以看作是测试的目标或定义。
（1）测试是为了发现程序中的错误而执行程序的过程；
（2）好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；
（3）成功的测试是发现了至今为止尚未发现的错误的测试。
从上述规则可以看出，测试的正确定义是“为了发现程序中的错误而执行程序的过程”。
这和某些人通常想象的“测试是为了表明程序是正确的”，“成功的测试是没有发现错误的测试”等等是完全相反的。
正确认识测试的目标是十分重要的，测试目标决定了测试方案的设计。
如果为了表明程序是正确的而进行测试，就会设计一些不易暴露错误的测试方案；相反，如果测试是为了发现程序中的错误，就会力求设计出最能暴露错误的测试方案。
由于测试的目标是暴露程序中的错误，从心理学角度看，由程序的编写者自己进行测试是不恰当的。
因此，在综合测试阶段通常由其他人员组成测试小组来完成测试工作。
此外，应该认识到测试决不能证明程序是正确的。
即使经过了最严格的测试之后，仍然可能还有没被发现的错误潜藏在程序中。
测试只能查找出程序中的错误，不能证明程序中没有错误。
关于这个结论下面还要讨论。
7.2.2软件测试准则
怎样才能达到软件测试的目标呢?
为了能设计出有效的测试方案，软件工程师必须深入理解并正确运用指导软件测试的基本准则。
下面讲述主要的测试准则。
（1）所有测试都应该能追溯到用户需求。
正如上一小节讲过的，软件测试的目标是发现错误。
从用户的角度看，最严重的错误是导致程序不能满足用户需求的那些错误。
（2）应该远在测试开始之前就制定出测试计划。
实际上，一旦完成了需求模型就可以着手制定测试计划，在建立了设计模型之后就可以立即开始设计详细的测试方案。
因此，在编码之前就可以对所有测试工作进行计划和设计。
（3）把Pareto原理应用到软件测试中。
Pareto原理说明，测试发现的错误中的80％很可能是由程序中20％的模块造成的。
当然，问题是怎样找出这些可疑的模块并彻底地测试它们。
（4）应该从“小规模”测试开始，并逐步进行“大规模”测试。
通常，首先重点测试单个程序模块，然后把测试重点转向在集成的模块簇中寻找错误，最后在整个系统中寻找
错误。
（5）穷举测试是不可能的。
所谓穷举测试就是把程序所有可能的执行路径都检查一遍的测试。
即使是一个中等规模的程序，其执行路径的排列数也十分庞大，由于受时间、人力和资源的限制，在测试过程中不可能执行每个可能的路径。
因此，测试只能证明程序中有错误，不能证明程序中没有错误。
但是，精心地设计测试方案，有可能充分覆盖程序逻辑并使程序达到所要求的可靠性。
（6）为了达到最佳的测试效果，应该由独立的第三方从事测试工作。
所谓“最佳激果”是指有最大可能性发现错误的测试。
由于前面已经讲过的原因，开发软件的软件工程师并不是完成全部测试工作的最佳人选（通常他们主要承担模块测试工作）。
7.2.3测试方法
测试任何产品都有两种方法：
如果已经知道了产品应该具有的功能，可以通过测试来检验是否每个功能都能正常使用；如果知道产品的内部工作过程，可以通过测试来检验产品内部动作是否按照规格说明书的规定正常进行。
前一种方法称为黑盒测试，后一种法称为白盒测试。
对于软件测试而言，黑盒测试法把程序看作一个黑盒子，完全不考虑程序的内部结构和处理过程。
也就是说，黑盒测试是在程序接口进行的测试，它只检查程序功能是否能按照规格说明书的规定正常使用，程序是否能适当地接收输入数据并产生正确的输出信息，程序运行过程中能否保持外部信息（例如，数据库或文件）的完整性。
黑盒测试又称为功能测试。
白盒测试法与黑盒测试法相反，它的前提是可以把程序看成装在一个透明的白盒子里，测试者完全知道程序的结构和处理算法。
这种方法按照程序内部的逻辑测试程序，检测程序中的主要执行通路是否都能按预定要求正确工作。
白盒测试又称为结构测试。
7.2.4测试步骤
除非是测试一个小程序，否则一开始就把整个系统作为一个单独的实体来测试是不现实的。
根据第4条测试准则，测试过程也必须分步骤进行，后一个步骤在逻辑上是前一个步骤的继续。
大型软件系统通常由若干个子系统组成，每个子系统又由许多模块组成，因此，大型软件系统的测试过程基本上由下述几个步骤组成。
1.模块测试
在设计得好的软件系统中，每个模块完成一个清晰定义的子功能，而且这个子功能和同级其他模块的功能之间没有相互依赖关系。
因此，有可能把每个模块作为一个单独的体来测试，而且通常比较容易设计检验模块正确性的测试方案。
模块测试的目的是保证每个模块作为一个单元能正确运行，所以模块测试通常又称为单元测试。
在这个测试步骤中所发现的往往是编码和详细设计的错误。
2.子系统测试
子系统测试是把经过单元测试的模块放在一起形成一个子系统来测试。
模块相互间的协调和通信是这个测试过程中的主要问题，因此，这个步骤着重测试模块的接口。
3.系统测试
系统测试是把经过测试的子系统装配成一个完整的系统来测试。
在这个过程中不仅应该发现设计和编码的错误，还应该验证系统确实能提供需求说明书中指定的功能，而且系统的动态特性也符合预定要求。
在这个测试步骤中发现的往往是软件设计中的错误，也可能发现需求说明中的错误。
不论是子系统测试还是系统测试，都兼有检测和组装两重含义，通常称为集成测试。
4.验收测试
验收测试把软件系统作为单一的实体进行测试，测试内容与系统测试基本类似，但是它是在用户积极参与下进行的，而且可能主要使用实际数据（系统将来要处理的信息）进行测试。
验收测试的目的是验证系统确实能够满足用户的需要，在这个测试步骤中发现的往往是系统需求说明书中的错误。
验收测试也称为确认测试。
5.平行运行.
关系重大的软件产品在验收之后往往并不立即投入生产性运行，而是要再经过一段平行运行时间的考验。
所谓平行运行就是同时运行新开发出来的系统和将被它取代的旧系统，以便比较新旧两个系统的处理结果。
这样做的具体目的有如下几点：
（1）可以在准生产环境中运行新系统而又不冒风险；
（2）用户能有一段熟悉新系统的时间；
（3）可以验证用户指南和使用手册之类的文档；
（4）能够以准生产模式对新系统进行全负荷测试，可以用测试结果验证性能指标。
以上集中讨论了与测试有关的概念，但是，测试作为软件工程的一个阶段，它的根本任务是保证软件的质量，因此除了进行测试之外，还有另外一些与测试密切相关的工作应该完成。
这就是下一小节要讨论的内容。
7.2.5测试阶段的信息流
图7.1描绘了测试阶段的信息流，这个阶段的输入信息有两类：
（1）软件配置，包括需求说明书、设计说明书和源程序清单等；
（2）测试配置，包括测试计划和测试方案。
所谓测试方案不仅仅是测试时使用的输入数据（称为测试用例），还应该包括每组输入数据预定要检验的功能，以及每组输入数据预期应该得到的正确输出。
实际上测试配置是软件配置的一个子集，最终交出的软件配置应该包括上述测试配置以及测试的实际结果和
调试的记录。
比较测试得出的实际结果和预期的结果，如果两者不一致则很可能是程序中有错误。
设法确定错误的准确位置并且改正它，这就是调试的任务。
与测试不同，通常由程序的编写者负责调试。
在对测试结果进行收集和评价的时候，软件可靠性所达到的定性指标也开始明朗了。
如果经常出现要求修改设计的严重错误，那么软件的质量和可靠性是值得怀疑的，应该进
一步仔细测试。
反之，如果看起来软件功能完成得很正常，遇到的错误也很容易改正，则仍然应该考虑两种可能：
（1）软件的可靠性是可以接受的；
（2）所进行的测试尚不足以发现严重的错误。
最后，如果经过测试，一个错误也没有被发现，则很可能是因为对测试配置思考不充分，以致不能暴露软件中潜藏的错误。
这些错误最终将被用户发现，而且需要在维护阶段改正它们（但是改正同一个错误需要付出的代价比在开发阶段高出许多倍）。
在测试阶段积累的结果，也可以用更形式化的方法进行评价。
软件可靠性模型使用错误率数据估计将来出现错误的情况，并进而对软件可靠性进行预测。
7.3单元测试
单元测试集中检测软件设计的最小单元——模块。
通常，单元测试和编码属于软件过程的同一个阶段。
在编写出源程序代码并通过了编译程序的语法检查之后，就可以用详细设计描述作指南，对重要的执行通路进行测试，以便发现模块内部的错误。
可以应用人工测试和计算机测试这样两种不同类型的测试方法，完成单元测试工作。
这两种测试方法各有所长，互相补充。
通常，单元测试主要使用白盒测试技术，而且对多个模块的测试可以并行地进行。
7.3.1测试重点
在单元测试期间着重从下述5个方面对模块进行测试。
1.模块接口
首先应该对通过模块接口的数据流进行测试，如果数据不能正确地进出，所有其他测试都是不切实际的。
在对模块接口进行测试时主要检查下述几个方面：
参数的数目、次序、属性或单位系统与变元是否一致；是否修改了只作输入用的变元；全局变量的定义和用法在各个模块中是否一致。
2.局部数据结构
对于模块来说，局部数据结构是常见的错误来源。
应该仔细设计测试方案，以便发现局部数据说明、初始化、默认值等方面的错误。
3.重要的执行通路
由于通常不可能进行穷尽测试，因此，在单元测试期间选择最有代表性、最可能发现错误的执行通路进行测试就是十分关键的。
应该设计测试方案用来发现由于错误的计算、不正确的比较或不适当的控制流而造成的错误。
4.出错处理通路
好的设计应该能预见出现错误的条件，并且设置适当的处理错误的通路，以便在真的出现错误时执行相应的出错处理通路或干净地结束处理。
不仅应该在程序中包含出错处理通路而且应该认真测试这种通路。
当评价出错处理通路时，应该着重测试下述一些可能发生的错误：
（1）对错误的描述是难以理解的；
（2）记下的错误与实际遇到的错误不同；
（3）在对错误进行处理之前，错误条件已经引起系统干预；
（4）对错误的处理不正确；
（5）描述错误的信息不足以帮助确定造成错误的位置。
5.边界条件
边界测试是单元测试中最后的也可能是最重要的任务。
软件常常在它的边界上失效，例如，处理n元数组的第n个元素时，或做到i次循环中的第i次重复时，往往会发生错误。
使用刚好小于、刚好等于和刚好大于最大值或最小值的数据结构、控制量和数据值的测试方案，非常可能发现软件中的错误。
7.3.2代码审查
人工测试源程序可以由编写者本人非正式地进行，也可以由审查小组正式进行。
后者称为代码审查，它是一种非常有效的程序验证技术，对于典型的程序来说，可以查出309，6～70％的逻辑设计错误和编码错误。
审查小组最好由下述4人组成：
（1）组长，应该是一个很有能力的程序员，而且没有直接参与这项工程；
（2）程序的设计者；
（3）程序的编写者；
（4）程序的测试者。
如果一个人既是程序的设计者又是编写者，或既是编写者又是测试者，则审查小组中应该再增加一个程序员。
审查之前，小组成员应该先研究设计说明书，力求理解这个设计。
为了帮助理解，可以先由设计者扼要地介绍他的设计。
在审查会上由程序的编写者解释他是怎样用程序代码实现这个设计的，通常是逐个语句地讲述程序的逻辑，小组其他成员仔细倾听他的讲解，并力图发现其中的错误。
审查会上进行的另外一项工作，是对照类似于上一小节中介绍的程序设计常见错误清单，分析审查这个程序。
当发现错误时由组长记录下来，审查会继续进行（审查小组的任务是发现错误而不是改正错误）。
审查会还有另外一种常见的进行方法，称为预排：
由一个人扮演“测试者”，其他人扮演“计算机”。
会前测试者准备好测试方案，会上由扮演计算机的成员模拟计算机执行被测试的程序。
当然，由于人执行程序速度极慢，因此测试数据必须简单，测试方案的数目也不能过多。
但是，测试方案本身并不十分关键，它只起一种促进思考引起讨论的作用。
在
升级会员 