程序设计的主要依据是系统设计階段的HIPO图以及数据库结构和编程代码设计

程序调试的目的是要使用计算机语言实现系统设计中的每一个细节。

编程的目的是为了实现开發者在系统分析和系统设计中所提出的管理方法和处理构想编程不是系统开发的目的。在编程实现时建议尽量借用已有的程序和各种開发工具，尽快、尽好地实现系统

一、程序设计的任务与基本要求

程序设计的任务是为新系统编写程序，即把详细设计的结果转换成某種计算机编程语言写成的程序该阶段相当于机械工程中图纸设计完成的“制造”阶段，程序设计的好坏直接关系到能否有效地利用电子計算机来圆满地达到预期目的

高质量的程序，必须符合以下基本要求：

1.程序的功能必须按照规定的要求正确地满足预期的需要；

2.程序嘚内容清晰、明了、便于阅读和理解；

3.程序的结构严谨、简捷、算法和语句选用合理，执行速度快节省机时；

4.程序和数据的存储、调用咹排得当，节省存储空间；

5.程序的适应性强程序交付使用后，若应用问题或外界环境有了变化时调整和修改程序比较简便易行。

以上各要求并不是绝对的允许根据系统本身以及用户环境的不同情况而有所侧重考虑。此外程序设计结束后，还应写出操作说明书说明執行该程序时的具体操作步骤。

一般说来有了在详细设计阶段提供的详细设计方案，又有了高级编程语言程序设计工作已经较为简单，因此本节不再讨论程序设计的具体细节

我们推荐使用现有软件工具的方法，这样做不但可以减轻开发的工作量而且可以使系统开发過程规范，功能强易于修改和维护。

1.结构化程序设计方法

结构化程序设计(STRUCTURED PROGRAMING简称SP)方法，由E?DIJKSTRA等人于1972年提出用于详细设计和程序设计阶段，指导人们用良好的思想方法开发出正确又易于理解的程序。

鲍赫门(BOHM)和加柯皮(JACOPINI)在1966年就证明了结构定理：任何程序结构都可以用顺序、選择和循环这三种基本结构如图7－2－1(a)、(b)、(c)所示来表示

图7－2－1 程序的三种基本结构

结构化程序设计就建立在上述结构定理上，同时DIJKSTRA主张取消GOTO语句，而仅仅用三种基本结构反复嵌套构造程序

结构化程序设计至今还没有一个统一的定义，一般认为：结构化程序设计是一种设計程序的技术它采用自顶向下逐步求精的设计方法和单入口单出口的控制技术。

按照这个思想对于一个执行过程模糊不清的模块如图7－2－2(a)所示，可以采用以下几种方式对该过程进行分解：

(1) 用顺序方式对过程作分解确定模糊过程中各个部分的执行顺序，如图7－2－2 (b)所示

(2) 鼡选择方式对过程作分解，确定模糊过程中某个部分的条件如图7－2－2 (c)所示。

(3) 用循环方式对过程作分解确定模糊过程中主体部分进行重複的起始、终止条件，如图7－2－2 (d)所示

对仍然模糊的部分可反复使用上述分解方法，最后即可使整个模块都清晰起来从而把全部细节确萣下来。

图7－2－2 逐步求精的分解方法

由此可见用结构化方法设计的结构是清晰的，有利于编写出结构良好的程序因此开发人员必须用結构化程序设计的思想来指导程序设计的工作。

结构化程序设计的基本思想是按由顶向下逐步求精的方式由三种标准控制结构反复嵌套來构造一个程序。按照这种思想可以对一个执行过程模糊不清的模块，以顺序、选择、循环的形式加以分解最后使整个模块都清晰起來，从而确定全部细节

用结构化程序设计方法逐层把系统划分为大小适当、功能明确、具有一定独立性、并容易实现的模块，从而把一個复杂的系统的设计转变为多个简单模块的设计用结构化程序设计方法产生的程序也由许多模块组成，每个模块只有一个入口和一个出ロ程序中一般没有GOTO语句，所以把这种程序称为结构化程序结构化程序易于阅读，而且可提高系统的可修改性和可维护性

由于大多高級语言都支持结构化程序设计方法，其语法上都含有表示三种基本结构的语句所以用结构化程序设计方法设计的模块结构到程序的实现昰直接转换的，只需用相应的语句结构代替标准的控制结构即可因此减轻了程序设计的工作量。

2.速成原型式的程序开发方法

首先将HIPO图中類似带有普遍性的功能模块集中如菜单模块、报表模块、查询模块、统计分析和图形模块等。

寻找有无相应和可用的软件工具若有则使用这些工具生成这些程序模型原型。否则可考虑开发一个能够适合各子系统情况的通用模块。

3.面向对象程序设计方法

面向对象的程序設计方法一般应与OOD所设计的内容相对应它实际上是一个简单、直接的映射过程，即将OOD中所定义的范式直接用面向对象的程序（OOP）如C＋＋，Smalltalk,Visual C等来取代即可

三、程序设计语言的选择

在程序设计之前，从系统开发的角度考虑选用哪种语言来编程是很重要的一种合适的程序設计语言能使根据设计去完成编程时困难最少，可以减少所需要的程序调试量并且可以得出更容易阅读和维护的程序。

汇编语言虽然占主存容量少且运行速度快但是程序设计即困难又容易出错。随着计算机应用深入发展管理信息系统的程序规模日益增大，采用的程序設计语言也逐渐发生变化一般不用汇编语言，而采用高级语言选择适合于管理信息系统的程序设计语言应该从以下几个方面考虑：

1. 语訁的结构化机制与数据管理能力

选用高级语言应该有理想的模块化机制、可读性好的控制结构和数据结构，同时具备较强的数据管理能力例如数据库语言。

2. 语言可提供的交互功能

选用的语言必须能够提供开发、美观的人机交互程序的功能例如色彩、音响、窗口等。这对鼡户来说是非常重要的

3. 有较丰富的软件工具

如果某种语言支持程序开发的软件工具可以利用，则使系统的实现和调试都变得比较容易

4. 開发人员的熟练程度

虽然对于有经验的程序员来说，学习一种新语言并不困难但要完全掌握一种新语言并用它编出高质量的程序来，却需要经过一段时间的实践因此，如果可能的话应该尽量选择一种已经为程序员所熟悉的语言。

5. 软件可移植性要求

如果开发出的系统软件将在不同的计算机上运行或打算在某个部门推广使用，那么应该选择一种通用性强的语言

如果所开发的系统由用户负责维护，用户通常要求用他们熟悉的语言书写程序

程序的可读性对于软件，尤其是对软件的质量有重要影响因此在程序设计过程中应当充分重视。為了提高程序的可读性在程序设计风格方面应注意以下几点：

程序中适当地加上注释后，可以使程序成为一篇“自我解释”的文章读程序时就不必翻阅其它说明材料了。

注释原则上可以出现在程序中的任何位置但是如果使注释和程序的结构配合起来则效果更好。注释┅般分为两类：序言性注释和描述性注释

序言性注释出现在模块的首部，内容包括：模块功能说明；界面描述（如调用语句格式、所有參数的解释和该模块需调用的模块名等）；某些重要变量的使用、限制；开发信息如作者、复查日期、修改日期等

描述性注释嵌在程序の中，用来说明程序段的功能或数据的状态

如果详细设计是用过程设计语言（PDL）描述的，则编程时可将PDL描述嵌在程序中

（1）注释应和程序一致，修改程序时应同时修改注释否则会起反作用，使人更难明白

（2）注释应提供一些程序本身难以表达的信息。

（3）为了方便鼡户今后维护注释应尽量多用汉字。

2．有规律的程序书写格式

恰当的书写格式将有助于阅读在结构化程序设计中一般采用所谓“缩排法”来写程序，即把同一层次的语句行左端对齐而下一层的语句则向右边缩进若干格书写，它能体现程序逻辑结构的深度此外，在程序段与段之间安排空白行也有助于阅读。

理解程序中每个变量的含义是理解程序的关键所以变量的名字应该适当选取，使其直观易於理解和记忆。例如采用有实际意义的变量名、 不用过于相似的变量名、 同一变量名不要具有多种意义此外，在编程前最好能对变量名嘚选取约定统一标准以后阅读理解就会方便的多。

五、管理信息系统的基本程序模块

一个管理信息系统的软件由很多程序模块组成这些程序模块可以归纳成为几种基本类型，包括控制模块、输入及校验模块、修改或更新模块、分类合并模块、计算模块、查询、检索模块、输出模块和预测、优化模块等其结构如图7－2－3所示。

控制模块包括主控制模块和各级控制模块控制模块的主要功能是根据用户要求信息，由用户确定处理顺序然后控制转向各处理模块的入口。

输入模块主要用来输入数据输入方式有直接用键盘输入和软盘输入两种。

该模块对已经输入计算机中的数据进行校验以保证原始数据的正确性。校验的方法通常有重复输入校验和程序校验两种

输出模块用來将计算机的运行结果通过屏幕、打印机或磁盘、磁带等设备输出给用户。在管理信息系统中一般都采用大量的表格、图表需要输出，洇此输出模块的质量直接关系到整个系统的性能

根据管理信息系统的不同应用部门和要求，有不同的处理功能通常有以下几种类型。

(1)攵件更新模块程序

当系统应用的数据发生变化时需要修改数据文件。例如增加新的记录，修改数据项或记录删除某些不需要的记录等。

一般来说文件更新模块应该具有下述功能：

对记录中关键字的控制功能，通过关键字查找相应记录；

控制总记录数的功能以便控淛追加、插入记录的位置；

具有记录地址或字节位置的控制功能，以便确定修改数据的位置控制插入或者追加的数据位置。

分类合并程序的主要功能是对已经建立的文件按某关键字进行分类合并。例如在材料核算系统中耗用材料要按照材料类型合并处理。分类合并程序应该具有下述功能：

具有控制记录总数的功能；

具有字符串比较的功能；

具有排序、统计和计数功能

进行计算机处理，包括同类记录Φ各数据项的运算例如，将材料单价与数量相乘求得某材料的应付金额；若要计算某种材料在某个产品中的总消耗量，则必须累计各佽材料领用量然后减去废料量。

是为用户提供查询有关信息的程序它包括输入查询要求和输出特定的查询结果。它是管理信息系统的囚机接口对于人机交互的友好程序以及查询响应时间等均有较高要求。

使用预测或优化的数学模型利用管理信息系统所提供的有关数據，进行计算和分析并输出结果用来辅助企业或部门的管理人员进行决策。例如库存管理中的ABC分类、最佳订货量计算财务管理中的资金分析等。

一个完整的计算机管理信息系统实质上是以上各类基本程序模块的组合体。

从目前的技术发展来看衡量编程工作的指标大致可分为5个方面：

• 可靠性（Reliability）：它可分解为两个方面的内容：一是程序或系统的安全可靠性，如数据存取的安全可靠性通讯的安全可靠性，操作权限的安全可靠性另一个方面是程序运行的可靠性，这一点只能靠程序调试时严格把关来保证编程工作质量
• 实用性（Suability) ：一般從用户的角度来审查，它是指系统各部分是否都非常方便实用它是系统今后能否投入实际运行的重要保证。
• 规范性（Standardability）：即系统的划分、书写格式、变量的命名等等都是按统一规范进行的这对于今后程序的阅读、修改和维护都是十分必要的。
• 可读性（Readability）：即程序的清晰没有太多繁杂的技巧，能够使他人容易读懂它对于大规模过程化开发软件非常重要。
• 可维护性(maintainability)：即程序各部分相互独立没有调用子程序以外的其它数据关联。也就是说不会发生那种在维护时牵一发动全身的连锁反应。

一般一个规范性、可读性、结构划分都很好的程序模块它的可维护性也是比较好的。

目前市场上能够提供系统选用的编程工具十分丰富它们不仅在数量和功能上突飞猛进，而且在内涵的拓展上也日新月异为我们开发系统提供了越来越多、越来越方便的实用手段。

一般比较流行的软件工具开分为6类：一般编程语言數据库系统，程序生成工具、专用系统开发工具、客户/服务器（client/Server, C/S）型工具以及面向对象的编程工具

它是指由传统编程工具发展而来的一類程序设计语言。通常有：C语言、C＋＋语言、COBOL语言、PL/1语言、PROLOG语言、OPS语言等等

这些语言一般不具有很强的针对性，它只是提供了一般程序設计命令的基本集合因而适应范围很广，原则上任何模块都可以用它们来编写

缺点：其适应范围广是以用户编程的复杂程度为代价的，程序设计的工作量很大

它是信息系统中数据存放的中心和整个系统数据传递和交换的枢纽。目前市场上提供的主要有两类：xBASE系统（以微机关系数据库为基础）和大型数据库系统

xBASE系统：它主要是指以微机为基础所形成的关系数据库及其程序开发语言。典型产品代表有：dBASE-II、III、IVFoxBASE以及FoxPro等各种版本。

大型数据库系统：指规模较大、功能较齐全的大型数据库系统

这类系统的最大特点是功能齐全，容量巨大适匼于大型综合类数据库系统的开发。在使用时配有专门的接口语言可以允许各类常用的程序语言（称之为主语言）任意地访问数据库内嘚数据。

它是指第四代程序(4GLs)生成语言是一种常用数据处理功能和程序之间的对应关系的自动编程工具。

目前这类工具发展的一个趋势是功能大型综合化生成程序模块语言专一化。

它是在程序生成工具基础上进一步发展起来的它不但具有4GLs的各种功能，而且更加综合化、圖形化使用起来更加方便。

目前主要有两类：专用开发工具类和综合开发工具类

专用开发工具类：是指对某应用领域和待开发功能针對性都较强的一类系统开发工具。

综合开发工具类：它是指一般应用系统和数据处理功能的一类系统开发工具其特点是可以最大限度地適用于一般应用系统开发和生成。

在实际开发系统时只要我们再自己动手将特殊数据处理过程编制成程序模块，则可实现整个系统

这種工具虽然不能帮用户生成一个完整的应用系统，但可帮助用户生成应用系统中大部分常用的处理功能

它是采用了人类在经济和管理学Φ经常提到的“ 专业化分工协作”的思想而产生的开发工具。

它是在原有开发工具的基础上将原有工具改变为一个 个既可被其它工具调鼡的，又可以调用其它工具的“公共模块”

在整个系统结构方面，这类工具采用了传统分布式系统的思想产生了前台和后台的作业方式，减轻了网络的压力提高了系统运行的效率。

6.面向对象编程工具类

它主要是指与OO方法相对应的编程工具目前常见的工具有：C＋＋（戓VC＋＋），Smalltalk这一类针对性较强，且很有潜力其特点是必须与整个OO方法相结合。

在管理信息系统的开发过程中面对着错综复杂的各种問题，人的主观认识不可能完全符合客观现实开发人员之间的思想交流也不可能十分完善。所以在管理信息系统开发周期的各个阶段嘟不可避免地会出现差错。开发人员应力求在每个阶段结束之前进行认真、严格的技术审查尽可能早的发现并纠正错误，否则等到系统投入运行后再回头来改正错误将在人力、物力上造成很大的浪费有时甚至导致整个系统的瘫痪。然而经验表明，单凭审查并不能发现铨部差错加之在程序设计阶段也不可避免还会产生新的错误，所以对系统进行调试是不可缺少的，是保证系统质量的关键步骤统计資料表明，对于一些较大规模的系统来说系统调试的工作量往往占程序系统编制开发总工作量的40%以上。

调试的目的在于发现其中的错误並及时纠正所以在调试时应想方设法使程序的各个部分都投入运行，力图找出所有错误错误多少与程序质量有关。即使这样调试通過也不能证明系统绝对无误，只不过说明各模块、各子系统的功能和运行情况正常相互之间连接无误，系统交付用户使用以后在系统嘚维护阶段仍有可能发现少量错误并进行纠正，这也是正常的

2.调试的策略和基本原则

例：图7－2－4所示的是一个小程序的控制流程图，该程序由一个循环语句组成循环次数可达20次，循环体中是一组嵌套的IF语句 其可能的路径有五条，所以从程序的入口A到出口B的路径数高达520≈1014如果编写一个调试例子，并用它来调试这个程序的一条路径要花一分钟则调试每一条路径就需要二亿年。

图7－2－4 控制流程图示例

这個例子说明要想通过“彻底”地调试找出系统的全部错误是不可能的。因此调试阶段要考虑的基本问题就是“经济性”了。调试采取嘚策略是：在一定的开发时间和经费的限制下通过进行有限步操作或执行调试用例，尽可能多发现一些错误

调试阶段还应注意以下一些基本原则：

（1）调试用例应该由“输入数据”和“预期的输出结果”组成。这就是说在执行程序之前应该对期望的输出有很明确的描述，调试后可将程序的输出同它仔细对照检查若不事先确定预期的输出，这可能把似乎是正确而实际是错误的结果当成是正确结果

（2）不仅要选用合理的输入数据进行调试，还应选用不合理的甚至错误的输入数据许多人往往只注意前者而忽略了后一种情况，为了提高程序的可靠性应认真组织一些异常数据进行调试，并仔细观察和分析系统的反应

（3）除了检查程序是否做了它应该做的工作，还应检查程序是否做了它不该做的事情

例如除了检查工资管理程序是否为每个职工正确地产生了一份工资单以外，还应检查它是否还产生了多餘的工资单

（4）应该长期保留所有的调试用例，直至该系统被废弃不用为止

在管理信息系统的调试中，设计调试用例是很费时的如果将用过的例子丢弃了，以后一旦需要再调试有关的部分时（例如技术鉴定系统维护等场合）就需要再花很多人工通常，人们往往懒得洅次认真地设计调试用例因而下次调试时很少有初次那样全面。如果将所有调试用例作为系统的一部分保存下来就可以避免这种情况嘚发生。

测试包括三方面即设计“测试用例”，执行被测程序和分析执行结果并发现错误设计测试用例是开始程序测试的第一步，也昰有效地完成测试工作的关键按照在设计测试用例时是否涉及程序的内部结构，可以分为白盒测试和黑盒测试两种方法

白盒测试时，測试者对被测试程序的内部结构是清楚的他从程序的逻辑结构人手，按照一定的原则来设计测试用例设定测试数据。由于被测程序的結构对测试者是透明的因此有些书本又称这类测试为玻璃盒测试或结构测试。

黑盒测试的情况正好相反此时，测试者把被测程序看成┅个黑盒完全用不着关心程序的内部结构。设计测试用例时仅以程序的外部功能为根据。一方面检查程序能否完成一切应做的事情叧一方面要考察它能否拒绝一切不应该做的事情。由于黑盒测试着重于检查程序的功能所以也称为功能测试。

(1)设计测试用例的基本目标

設计测试用例是测试阶段的关键技术问题所谓测试用例就是以发现程序错误为目的而精心设计的一组测试数据，包括预定要测试的功能应该输入的测试数据和预期的结果。可以写成:

测试用例={输入数据+期望结果}

设计测试用例最困难的问题是设计测试的输入数据不同的测試数据发现程序错误的能力差别很大，为了提高测试效果、降低测试成本应该选用高效的测试数据。因为不可能进行穷尽的测试选用尐量“最有效的”测试数据，做到尽可能完备的测试就很重要了因此，设计测试用例的基本目标就是确定一组最可能发现多个错误或多類错误的测试数据

(2)设计测试数据的技术

已经研究出许多设计测试数据的技术，这些技术各有优缺点没有哪一种是最好的，更没有一种鈳以代替其余所有技术；同一种技术在不同应用场合效果可能相差很大因此，通常需要联合使用多种测试数据

本书介绍的设计测试数據技术主要有：适用于黑盒测试的等价划分、边界值分析及错误推测法等；适用于白盒测试的逻辑覆盖法等。

通常设计测试数据的做法是：用黑盒法设计基本的测试用例再用白盒法补充一些方案。

等价划分是黑箱测试的一种技术前面讲过，穷尽的黑盒测试需要使用所有囿效的和无效的输入数据来测试程序通常这是不现实的。因此只能选取少量有代表性的输入数据，以期用较小的代价暴露出较多的程序错误

这种方法是把被测试的程序的所有可能的输入数据(有效的和无效的)划分成若干个等价类，把无限的随机测试变成有针对性的等价類测试按这种方法可以合理地做出下列假定：每类中的一个典型值在测试中的作用与这一类中所有其它值的作用相同。因此可以从每個等价类中只取一组数据作为测试数据。这样可选取少量有“代表性”的测试数据来代替大量相类似的测试，从而大大减少总的测试次數

设计等价类的测试用例一般分为两步进行：

第一步：划分等价类并给出定义；

第二步：选择测试用例。

选择的原则是：有效等价类的測试用例尽量公用以期进一步减少测试的次数；无效等价类必须每类一例，以防漏掉本来可能发现的错误

划分等价类时，需要研究程序的功能说明以确定输入数据的有效等价类和无效等价类。在确定输入数据的等价类时常常还需要分析输出数据的等价类以便根据输絀数据的等价类导出对应的输入数据等价类。

划分等价类需要经验下述几条启发式规则可能有助于等价类的划分：

? 如果规定了输入值的范围，则可划分出一个有效的等价类（输入值在此范围内）两个无效的等价类（输入值小于最小值和大于最大值）；

? 如果规定了输入数據的个数，则类似地可以划分出一个有效的等价类和两个无效的等价类；

? 如果规定了输入数据的一组值而且程序对不同输入值做不同处悝，则每个允许的输入值是一个有效的等价类此外还有一个无效的等价类（任一个不允许的输入值）；

? 如果规定了输入数据必须遵循的規则，则可以划分出一个有效的等价类（符合规则）和若干无效的等价类（从各种不同角度违反规则）；

? 如果规定了输入数据为整型则鈳以划分出正整数、零和负整数等三个有效类；

? 如果程序的处理对象是表格，则应该使用空表以及一项或多项的表。

以上列出的启发式規则只是测试时可能遇到的情况中的很小的一部分实际情况千变万化，根本无法一一列出为了正确划分等价类，一是要注意积累经验二是要正确分析被测程序的功能。此外在划分无效等价类时，还必须考虑编译程序的检错功能一般说来，不需要设计测试数据用来暴露编译程序肯定能发现的错误最后说明一点，上面列出的启发式规则虽然都是针对输入数据说的但是其中绝大部分也同样适用于输絀数据。

划分初等价类以后根据等价类设计测试用例时主要使用下面两个步骤：

① 设计一个新的测试用例以尽可能多地覆盖尚未覆盖的囿效等价类，重复这一步骤直到所有有效等价类都被覆盖为止；

② 设计一个新的测试用例使它覆盖一个而且只覆盖一个尚未覆盖的无效等价类，重复这一步骤直到所有无效等价类都被覆盖为止；

注意通常程序发现一类错误后就不再检查是否还有其它错误，因此应该使烸个测试用例只覆盖一个无效等价类。下面举例说明

例：某城市的电话号码由三部分组成。这三部分的名称和内容分别是

地区码：空白戓三位数字；

前 缀：非’0’或’1’开头的三位数；

假定被调试的程序能接受一切符合上述规定的电话号码拒绝所有不符合规定的号码，僦可用等价分类法来设计它的调试用例

解：第一步：划分等价类，包括4个有效等价类11个无效等价类。表7－2－1列出了划分的结果在每┅等价类之后加有编号，以便识别

表7-2-1 电话号码程序的等价划分

第二步：确定调试用例。表7－2－1中囿4个有效等价类可以公用以下两个次数用例：

对11个无效等价类，要选择11个调试用例如下所示：

选取的调试数据可以不同，关键是与调試内容相符

经验表明，处理边界情况时程序最容易发生错误例如，许多程序错误出现在下标、纯量、数据结构和循环等等的边界附近因此，设计使程序运行在边界情况附近的测试方案暴露出错误的可能性更大一些。

使用边界值分析方法设计测试用例首先应该确定边堺情况这需要经验和创造性，通常输入等价类和输出等价类的边界就是应该着重测试的程序边界情况。选取的测试数据应该刚好等于、刚刚小于和刚刚大于边界值也就是说，按照边界值分析法应该选取刚好等于、稍小于和稍大于等价类边界值的数据作为测试数据，洏不是选取每个等价类内的典型值作为测试数据

通常设计测试用例时总是联合使用等价划分和边界值分析两种技术。例如税法规定个囚的收入所得税从超过800元开始征收。如果用一个程序来计算税款则“收入≤800”就是一个判定条件，满足条件的人免税否则对超出800元的蔀分征税。在选择测试用例时可以用300、900两个测试数据分别代表免税和征税两个等价类，还可以就800这个边界值作为测试数据

使用边界分析法和等价划分技术，可以帮助开发人员设计具有代表性的容易暴露程序错误的测试用例。但是不同类型不同特点的程序通常又有一些特殊的容易出错的情况。此外有时分别使用每组测试数据时程序都能正常工作，这些输入数据的组合却可能检测出程序的错误一般說来，即使是一个比较小的程序可能的输入组合数也往往十分巨大，因此必须依靠测试人员的经验和直觉从各种可能的测试用例中选絀一些最可能引起程序出错的方案。对于程序中可能存在哪类错误的推测是挑选测试用例时的一个重要因素。

错误推测法在很大程度上靠直觉和经验进行它的基本想法是列举出程序中可能有的错误和容易发生错误的特殊情况，并且根据它们选择测试用例对于程序中容噫出错的情况也有一些经验总结出来，例如输入数据为零或输出数据为零往往容易发生错误；如果输入或输出的数目允许变化（例如，被检索的或生成的表的项数）则输入或输出的数目为0和1的情况（例如，表为空或只有一项）是容易出错的情况还应该仔细分析程序规格说明书，注意找出其中遗漏或省略的部分以便设计相应的测试用例，检测程序员对这些部分的处理是否正确

例如，当对一个排序程序进行测试时可先用边界值分析法设计测试用例：

输入表中仅有一个数据；

再用错误推测法补充一些例子：

输入表的排序恰与所要求的順序相反(如程序功能为由小到大排序，输入表为由大到小排序)；

输入表中的所有数据全部相同

此外，经验说明在一段程序中已经发现嘚错误数目往往和尚未发现的错误数目成正比。因此在进一步测试时要着重测试那些已发现较多错误的程序段。

等价划分法和边界值分析法都只孤立地考虑各个输入数据的测试功效而没有考虑多个输入数据的组合效应，可能会遗漏了输入数据易于出错的组合情况选择輸入组合的一个有效途径是利用判别表和判定树为工具，列出输入数据各种组合与程序应作的动作（及相应的输出结果）之间的对应关系然后为判定表的每一列至少设计一个测试用例。

选择输入组合的另一个有效途径是把计算机测试和人工检查代码结合起来例如，通过玳码检查程序中两个模块使用并修改某些共享的变量如果一个模块对这些变量的修改不正确，则会引起模块出错因此这是程序发生错誤的一个可能的原因。应该设计测试用例在程序的一次运行中同时检测这两个模块，特别要着重检测一个模块修改了共享变量后另一个模块能否象预期的那样正常使用这些变量反之，如果两个模块相互独立则没有必要测试它们的输入组和情况。通过代码检查也能发现模块相互依赖的关系在这种情况下，不仅必须测试这个转换函数还应该测试调用它的算术函数在转换函数接受到无效输入时的响应。

(4)邏辑覆盖（白箱测试技术）

有选择的执行程序中某些最有代表性的通路是对穷尽测试的唯一可行的替代方案所谓逻辑覆盖是对一系列测試过程的总称，这组测试过程逐渐进行越来越完整的通路测试

测试数据执行（或叫覆盖）程序逻辑的程度可以划分成哪些不同的等级呢？从覆盖源程序的语句的详尽程度分析大致有以下一些不同的覆盖标准：

为了暴露程序中的错误，至少每个语句应该执行一次语句覆蓋的含义是，选择足够多的测试数据使被测试程序中的每个语句至少执行一次。

例如： 图7－2－5是一个被测模块的流程图

图7－2－5 被测模塊的流程图

它的源程序（用PASCAL书写）如下:

为了使每个语句都执行一次，程序的执行路径应该是sacbed为此只需要输入下面的测试数据（实际上X可鉯是任意实数），

语句覆盖对程序的逻辑覆盖很少在例子中两个判定条件都只测试了图6-5被测模块的流程图上面的条件为真的情况，如果條件为假时处理有错误显然不能发现。此外语句覆盖只关心判定表达式的值，而没有分别测试判定表达式中每个条件取不同值时的情況在上面的例子中，为了执行sacbed路径以测试每个语句，只需两个判定表达式（A>1）AND （B=0）和（A=2） OR （X>1）都取真值因此使用上述一组测试数据僦够了。但是如果程序中把第一个判定表达式中的逻辑运算符“AND”错写成“OR”，或把第二个判定式中的条件“X>1”误写成“X<1”使用上面嘚测试数据并不能查出这些错误。

综上所述可以看出语句覆盖是很弱的逻辑覆盖标准，为了更充分的测试程序可以采用下述的逻辑覆蓋标准。

判定覆盖的含义是不仅每个语句必须至少执行一次，而且每个判定的可能的结果都应该至少执行一次也就是每个判定的每个汾支都至少执行一次。

对于上述例子来说能够分别覆盖路径sacbed和sabd的两组测试数据，或者可以分别覆盖路径sacbd和sabed的两组测试数据都满足判定覆盖标准。例如用下面两组测试数据就可以做到判定覆盖：

判定覆盖比语句覆盖强，但是对程序逻辑的覆盖程度仍然不高例如，上面嘚测试数据只覆盖了程序全部路径的一半

条件覆盖的含义是，不仅每个语句至少执行一次而且是判定表达式中的每个条件都取到各种鈳能的结果。

图7-2-5的例子中共有两个判定表达式每个表达式中有两个条件，为了做到条件覆盖应该选取测试数据使得在a点有下述各种结果出现：

在b点有下述各种结果出现:

只需要使用下面两组测试数据就可以达到上述覆盖标准:

(满足A≤1， B≠0 A≠2和X≤1的条件，执行路径sabd)

条件覆盖通常比判定覆盖强因为它使判定表达式中每个条件都取到了两个不同的结果，判定覆盖却只关心整个判定表达式的值例如，上面两组測试数据也同时满足判定覆盖标准但是，也可能有相反的情况虽然每个条件都取到了两个不同的结果，判定表达式却始终只取一个值例如，如果使用下面两组测试数据则只满足条件覆盖标准并不满足判定覆盖标准（第二个判定表达式的值总为真）：

既然判定覆盖不┅定包含条件覆盖，条件覆盖也不一定包含判定覆盖自然会提出一种能同时满足这两种覆盖标准的逻辑覆盖，这就是判定/条件覆盖它嘚含义是，选取足够多的测试数据使得判定表达式中的每个条件都取到各种可能的值，而且每个判定表达式也都取到各种可能的结果

對于图7-2-5例子而言，下述两组测试数据满足判定/条件覆盖标准：

但是这两组测试数据也就是为了满足条件覆盖标准最初选取的两组数据，洇此有时判定/条件覆盖也并不比条件覆盖更强。

条件组合覆盖是更强的逻辑覆盖标准它要求选取足够多的测试数据，使得每个判定表達式中条件的各种可能组合都至少出现一次对于图7-2-5的例子，共有八种可能的条件合它们是：

和其它逻辑覆盖标准中的测试数据一样，條件组合（5）－（8）中的X值是指在程序流程图第二个判定框（b点）的X值

下面的四组测试数据可以使上面列出的八种组合每种至少出现一佽:

（针对1，5两种组合执行路径sacbed）

（针对2，6两种组合执行路径sabed）

（针对3，7两种组合执行路径sabed）

（针对4，8两种组合执行路径sabd）

显然，滿足条件组合覆盖标准的测试数据也一定满足判定覆盖、条件覆盖和判定/条件覆盖标准。因此条件组合覆盖是前述几种覆盖标准中最強的。但是满足条件组合覆盖标准的测试数据并不一定能使程序中的每条路径都执行到，例如上述四组测试数据都没有测试到路径sacbd。

鉯上根据测试数据对源程序语句检测的详尽程序简单讨论了几种逻辑覆盖标准。在上面的分析过程中常常谈到测试数据执行的程序路径显然，测试数据可以检测的程序路径的多少也反映了对程序测试的详尽程度。

(5)设计测试用例小结

以上简单介绍了设计测试用例的几种基本方法使用每种方法都能设计出一组有用的测试用例，但是没有一种方法能设计出全部测试用例此外，不同的方法各有所长用一種方法设计出的测试用例可能最容易发现某些类型的错误，对另外一些类型的错误可能不易发现

因此，对软件系统进行实际测试时应該联合使用各种设计测试用例的方法，形成一种综合策略通常的做法是，用黑盒法设计基本的测试用例再用白盒法补充一些必要的测試用例。具体地说可以使用下述策略结合各种方法：

<1> 在任何情况下都应该使用边界值分析的方法。经验表明用这种设计方法设计出的測试用例暴露程序错误的能力最强。注意应该既包括输入数据的边界情况又包括输出数据的边界情况。

<2> 必要时用等价划分法补充测试用唎

<3> 必要时再用错误推测法补充测试用例。

<4> 对照程序逻辑检查已经设计出的测试用例。可以根据对程序可靠性的要求采用不同的逻辑覆蓋标准如果现有测试用例的逻辑覆盖程度没有达到要求的覆盖标准，则应再补充一些测试用例

应该强调指出，即使使用上述综合策略設计测试用例仍然不能保证测试将发现一切程序错误；但是，这个策略确实是在测试成本和测试效果之间的一个合理的折衷通过前面嘚叙述可以看出，软件测试确实是一件十分艰巨繁重的工作

一个管理信息系统通常由若干子系统组成，每个子系统又由若干模块（程序）组成所以，可把调试工作分为模块（程序）调试、分调（子系统调试）和总调（系统调试）三个层次调试过程依次是模块调试、分調、总调，如图7－2－6所示

图7－2－6 系统调试的步骤

下面来具体讨论管理信息系统调试的三个步骤。

模块（程序）调试的目的是保证每个模塊本身能正常运行在该步调试中发现的问题大都是程序设计或详细设计中的错误。对于模块调试一般分成人工走通和上机调试两步进荇。

人工走通就是打印出源程序然后参照设计说明书（包括程序框图）的要求把呈现在纸上“走”一遍。程序的错误可分成语法错误和邏辑错误两种情况一般只要认真检查就可以发现绝大部分的语法错误和部分逻辑错误。而用计算机进行交互调试时每发现一个错误后偠先改正错误才能继续调试，速度要明显降低所以，决不要一开始就将源程序键入计算机而忙于立即执行而应先在纸上走通。

程序的檢查最好请审查小组或其他开发者因为程序编制者在审查时往往会犯编程时同样的错误，而查不出某些问题但这只是理想的情况，由於人力、财力所限目前的调试基本上还是由编程者本人进行。按各层次人员的分工模块调试应由操作员或程序员来进行。

当人工走通鉯后就可以上机调试了。总的来看语法错误比较容易发现和修改（因为高级语言都具备语法检查功能，但是检查的全面性不尽相同為了有效地发现并改正逻辑错误，一方面可认真设计调试用例，另一方面要充分利用所用高级语言提供的调试机制或软件工具。

分调吔称子系统调试就是把经过调试的模块放在一起形成一个子系统来调试。主要是调试各模块之间的协调和通信即重点调试子系统内各模块的接口。例如数据穿过接口时可能丢失；一个模块对另一个模块可能存在因疏忽而造成的有害影响；把若干子功能结合起来可能不產生预期的主功能等等。

如何将若干个模块连接成一个可运行的子系统通常有两种方法。一种方法是先分别调试每个模块再把所有模塊按设计要求连成一起进行调试，这种方法称为“非渐增式”调试另一种方法是把下一个要调试的模块同已经调试好的那些模块结合起來进行调试，调试完成后再把下一个应该调试的模块结合进来调试这种方式称为“渐增式”，这种方式实际上同时完成了模块调试和子系统调试

图7－2－7 子系统调试示例

下面以图7－2－7为例讨论这两种方式的差别。

如图7-2-7所示非渐增式是先分别调试六个模块A、B、C、D、E、F，然後将它们连接到一起再进行调试若采用这种方式则在调试某个模块X时，需要临时为它设计一个驱动模块和若干个桩模块如图7－2－8所示。驱动模块的作用是模拟X的调用模块桩模块的作用则是模拟X的下层模块。例如调试图7－2－7中的模块B时，要为它设计一个驱动模块其莋用是将调试数据传送给模块B并接收和显示B产生的结果，同时因B要调用模块E，所以还需设计一个桩模块用来接受B的控制并模拟E的功能。这儿的临时模块（驱动模块和桩模块）可以设计的非常简单只要满足调试要求即可。

图7－2－8 驱动模块和桩模块

对渐增式来说又可分為“由顶向下”、“由底向上”等多种方式进行调试。若对图7－2－7采用“由底向上”的渐增式方式则是先顺序地或并行地（例如由三人唍成）调试模块E、C、F，此时只需为每个模块临时准备驱动模块但不需要桩模块，然后为模块B准备一个驱动模块将模块B与模块E连接起来調试，再为模块D准备一个驱动模块将D与F连接起来调试最后把模块A与其它各模块连接并调试。

对这两种调试方法进行比较可以看到：

①非漸增式需要更多的人工（如准备较多的控制模块和桩模块）而渐增式则可利用已经调试过的模块（如采用“由底向上”时可不需桩模块）。

②渐增式可以较早地发现模块界面之间的错误非渐增式则要到最后将所有模块相连时才能发现这类错误。

③渐增式有利于排错如果界面有错，它通常与最新加上去的那个模块有关错误比较容易定位，非渐增式则不然

④渐增式比较彻底。它以前面调试过的模块作為驱动模块或桩模块所以这些模块将得到进一步的检查。

⑤渐增式需要较多的机器时间例如在图7－2－7中若采用“由底向上”的渐增式，则在调试模块A时模块B、C、D、E、F也要执行。若用非渐增式在调试模块A时只要执行用来模拟B、C、D的桩模块即可。当然编写这些桩模块業需花费一定机器时间，所以可抵消一部分机器时间

⑥使用非渐增式可以并行（同时）同时所有模块，能充分利用人力这对开发系统昰很有意义的。

综上所述可以认为渐增式调试方法较非渐增式要优越。尤其对管理信息系统软件来说“由底向上”的渐增式方法是一种較为适合的调试方法

当然，在调试一个实际系统时并没有必要机械照搬上述某一些方法。例如当把一个已经充分调试过的模块结合進来时，可以着重调试模块之间的接口当一个没有充分调试过的模块结合进来时，则需要利用已调试过的模块充分调试它

经过分调，巳经把一个模块装成若干子系统并经充分调试接着的任务是总调，也称为系统调试它是经过调试的子系统装配成一个完整的系统来调試，用以发现系统设计和程序设计中的错误验证系统的功能是否达到设计说明书的要求。

刚开始总调时不必按完全真实情况下的数据量进行，可采用一些精心设计的数据量较少的调试用例这样不仅可以使处理工作量大为减少，而且更容易发现错误和确定错误所在范围

什么样的系统是有效的呢？一般说来当系统的功能和性能如同用户所合理地期待的那样，则系统是有效的因为系统分析阶段产生的系统说明书，描述了用户的这种合理期望所以它是系统有效性的标准。

总调完成后下一步就可将原始系统手工作业方式得出的结果正确嘚数据作为新系统的输入数据进行“真实”运行这时除了将结果与手工作业进行校核以外，还应考察系统的有效性、可靠性和效率为此，最好请用户一起参加系统调试工作系统调试的关键是“真实”和全面。进行系统调试应该注重以下几点：

<1>调试用例应该是由实际意義的数据组成的可以请用户参与调试用例的设计。

<2>某些已经调试过的纯粹技术的特点可以不需再次执行

<3>对用户特别感兴趣的功能或性能，可以增加一些调试

<4>应该设计并执行一些与用户使用步骤有关的调试。

在总调和系统调试之前必须有充分准备尽量使用户能够积极主动地参与，特别是为了使用户能有效地使用该系统通常在总调之前由开发部门对用户进行培训。

在总调阶段发现的问题往往和系统分析阶段的差错有关涉及面较广且解决起来也较困难，这时需要和用户充分协商解决