在汇编指令中，操作数在某寄存器中的寻址方式称为（1）寻址。

计算机系统中，虚拟存储体系由（2）两级存储器构成。

程序计数器(PC)是（3）中的寄存器。

中断向量提供（4）。

在计算机系统中总线宽度分为地址总线宽度和数据总线宽度。若计算机中地址总线的宽度为32位，则最多允许直接访问主存储器（5）的物理空间。

为了提高计算机磁盘存取效率，通常可以（6）。

安全的电子邮件协议为（7）。

操作系统通过（8）来组织和管理外存中的信息。

下列操作系统中，（9）保持网络系统的全部功能，并具有透明性、可靠性和高性能等特性。

在进程状态转换过程中，可能会引起进程阻塞的原因是（10）。

假设系统有n个进程共享资源R，且资源R的可用数为3，其中n≥3。若采用PV操作，则信号量S的取值范围应为（11）。

已知函数f()、g()的定义如下所示，调用函数f时传递给形参x的值是5。若g（a）采用引用调用（callbyreference）方式传递参数，则函数f的返回值为（12）；若g（a）采用值调用（callbyvalue）的方式传递参数，则函数f的返回值（13）。其中，表达式《x>>1》的含义是将x的值右移1位，相当于x除以2。

已知函数f()、g()的定义如下所示，调用函数f时传递给形参x的值是5。若g（a）采用引用调用（callbyreference）方式传递参数，则函数f的返回值为（12）；若g（a）采用值调用（callbyvalue）的方式传递参数，则函数f的返回值（13）。其中，表达式《x>>1》的含义是将x的值右移1位，相当于x除以2。

设数组a[0．．n-1,0..m-1](n>1，m>1)中的元素以行为主序存放，每个元素占用4个存储单元，则数组元素a[i，j](0≤i<n,0≤j<m)的存储位置相对于数组空间首地址的偏移量为（14）。

线性表采用单循环链表存储的主要优点是（15）。

若某线性表长度为n且采用顺序存储方式，则运算速度最快的操作是（16）。

设元素a、b、c、d依次进入一个初始为空的栈，则不可能通过合法的栈操作序列得到（17）。

若要求对大小为n的数组进行排序的时间复杂度为O(nlog₂n)，且是稳定的（即如果待排序的序列中两个数据元素具有相同的值,在排序前后它们的相对位置不变），则可选择的排序方法是（18）。

对于一般的树结构，可以采用孩子-兄弟表示法，即每个结点设置两个指针域，一个指针（左指针）指示当前结点的第一个孩子结点，另一个指针（右指针）指示当前结点的下一个兄弟结点。某树的孩子-兄弟表示如下图所示。以下关于结点D与E的关系的叙述中，正确的是（19）。

某企业研发信息系统的过程中（20）不属于数据库管理员(DBA)的职责。

某高校人事管理系统中，规定讲师每课时的教学酬金不能超过100元，副教授课时的教学酬金不能超过130元，教授每课时的教学酬金不能超过160元。这种情况下所设置的数据完整性约束条件称之为（21）。

某教学管理数据库中，学生、课程关系模式和主键分别为：S（学号，姓名，性别，家庭住址，电话），关系S的主键为学号；C（课程号，课程名，学分），关系C的主键为课程号。假设一个学生可以选择多门课程，一门课程可以由多个学生选择。一旦学生选择某门课程必定有该课程的成绩。由于学生与课程之间的《选课》联系类型为（22）所以对该联系（23）。

某教学管理数据库中，学生、课程关系模式和主键分别为：S（学号，姓名，性别，家庭住址，电话），关系S的主键为学号；C（课程号，课程名，学分），关系C的主键为课程号。假设一个学生可以选择多门课程，一门课程可以由多个学生选择。一旦学生选择某门课程必定有该课程的成绩。由于学生与课程之间的《选课》联系类型为（22）所以对该联系（23）。

查询《软件工程》课程的平均成绩、最高成绩与最低成绩之间差值的SQL语句如下：
SELECT AVG(成绩)AS平均成绩，（24）
FROM C, SC
WHERE C．课程名=’软件工程’ AND C．课程号=SC．课程号；

能隔离局域网中广播风暴、提高带宽利用率的设备是（25）。

下面的协议中属于应用层协议的是（26），该协议的报文封装在（27）中传送。

下面的协议中属于应用层协议的是（26），该协议的报文封装在（27）中传送。

某公司内部使用wb.xyz.com.cn作为访问某服务器的地址，其中wb是（28）。

如果路由器收到了多个路由协议转发的关于某个目标的多条路由，那么决定采用哪条路由的策略是（29）。

下面是路由表的4个表项，与地址220．112．179．92匹配的表项是（30）。

某开发小组欲开发一个软件系统，实现城市中不同图书馆的资源共享，包括实体资源和电子资源，共享规则可能在开发过程中有变化。客户希望开发小组能尽快提交可运行的软件，且可以接受多次交付。这种情况下最适宜采用（31）开发过程模型。主要是因为这种模型 （32） 。

某开发小组欲开发一个软件系统，实现城市中不同图书馆的资源共享，包括实体资源和电子资源，共享规则可能在开发过程中有变化。客户希望开发小组能尽快提交可运行的软件，且可以接受多次交付。这种情况下最适宜采用（31）开发过程模型。主要是因为这种模型 （32） 。

某软件项目的活动图如下图所示，其中顶点表示项目里程碑，连接顶点的边表示包含的活动，边上的数字表示活动的持续时间（天），则完成该项目的最少时间为（33）天。活动BC和BF分别最多可以晚开始（34）天而不会影响整个项目的进度。

某软件项目的活动图如下图所示，其中顶点表示项目里程碑，连接顶点的边表示包含的活动，边上的数字表示活动的持续时间（天），则完成该项目的最少时间为（33）天。活动BC和BF分别最多可以晚开始（34）天而不会影响整个项目的进度。

结构化开发方法中，（35）主要包含对数据结构和算法的设计。对算法设计时，其主要依据来自（36）描述算法时，（37）不是理想的表达方式。

结构化开发方法中，（35）主要包含对数据结构和算法的设计。对算法设计时，其主要依据来自（36）描述算法时，（37）不是理想的表达方式。

结构化开发方法中，（35）主要包含对数据结构和算法的设计。对算法设计时，其主要依据来自（36）描述算法时，（37）不是理想的表达方式。

模块A的功能为：从数据库中读出产品信息，修改后存回数据库，然后将修改记录写到维护文件中。该模块内聚类型为（38）内聚。以下关于该类内聚的叙述中，正确的是（39）。

模块A的功能为：从数据库中读出产品信息，修改后存回数据库，然后将修改记录写到维护文件中。该模块内聚类型为（38）内聚。以下关于该类内聚的叙述中，正确的是（39）。

某个应用中，需要对输入数据进行排序，输入数据序列基本有序(如输入为1,2,5,3,4,6,8,7)。在这种情况下，采用（40）排序算法最好，时间复杂度为（41）。

某个应用中，需要对输入数据进行排序，输入数据序列基本有序(如输入为1,2,5,3,4,6,8,7)。在这种情况下，采用（40）排序算法最好，时间复杂度为（41）。

在结构化分析中，用数据流图描述（42）。当采用数据流图对银行客户关系管理进行分析时，（43）是一个加工。

在结构化分析中，用数据流图描述（42）。当采用数据流图对银行客户关系管理进行分析时，（43）是一个加工。

以下关于用例图的叙述中，不正确的是（44）。图书馆管理系统需求中包含《还书》用例和《到书通知》用例，对于《还书》用例，应先查询该书是否有人预定，若有则执行《到书通知》。《还书》用例和《到书通知》用例是（45）关系，以下用例图中，（46）是正确的。管理员处理《还书》用例时，需要先执行《验证身份《用例，那么《还书》用例和《验证身份》用例之间是（47）关系。

以下关于用例图的叙述中，不正确的是（44）。图书馆管理系统需求中包含《还书》用例和《到书通知》用例，对于《还书》用例，应先查询该书是否有人预定，若有则执行《到书通知》。《还书》用例和《到书通知》用例是（45）关系，以下用例图中，（46）是正确的。管理员处理《还书》用例时，需要先执行《验证身份《用例，那么《还书》用例和《验证身份》用例之间是（47）关系。

以下关于用例图的叙述中，不正确的是（44）。图书馆管理系统需求中包含《还书》用例和《到书通知》用例，对于《还书》用例，应先查询该书是否有人预定，若有则执行《到书通知》。《还书》用例和《到书通知》用例是（45）关系，以下用例图中，（46）是正确的。管理员处理《还书》用例时，需要先执行《验证身份《用例，那么《还书》用例和《验证身份》用例之间是（47）关系。

以下关于用例图的叙述中，不正确的是（44）。图书馆管理系统需求中包含《还书》用例和《到书通知》用例，对于《还书》用例，应先查询该书是否有人预定，若有则执行《到书通知》。《还书》用例和《到书通知》用例是（45）关系，以下用例图中，（46）是正确的。管理员处理《还书》用例时，需要先执行《验证身份《用例，那么《还书》用例和《验证身份》用例之间是（47）关系。

用面向对象方法设计了一个父类File和两个子类DiskFile和TapeFile，这两个子类继承了其父类的open方法，并给出不同的实现。不同的子类执行open方法时，有不同的行为，这种机制称为（48）。

在计算机系统中，系统的（49）可以用MTTF/（1+MTTF）来度量，其中MTTF为平均无故障时间。

修改现有软件系统的设计文档和代码以增强可读性，这种行为属于（50）维护。

以下不属于系统测试范畴的是（51）。

以下关于文档测试的说法中，不正确的是（52）。

软件测试的对象不包括（53）。

测试用例的三要素不包括（54）。

以下关于软件测试原则的叙述中，正确的是（55）。
①测试开始得越早，越有利于发现缺陷
②测试覆盖率和测试用例数量成正比
③测试用列既需选用合理的输入数据，又需要选择不合理的输入数据
④应制定测试计划并严格执行，排除随意性
⑤采用合适的测试方法，可以做到穷举测试
⑥程序员应尽量测试自己的程序

以下关于测试时机的叙述中，正确的是（56）。
①应该尽可能早地进行测试
②软件中的错误暴露得越迟，则修复和改正错误所花费的代价就越高
③应该在代码编写完成后开始测试
④项目需求分析和设计阶段不需要测试人员参与

以下属于软件测试工具的是（57）。
①JTest ②LoadRunner
③Visual Studio ④JBuilder

兼容性测试不包括（58）。

根据输出对输入的依赖关系设计测试用例的黑盒测试方法是（59）。

以下关于边界值测试法的叙述中，不正确的是（60）。

一个程序的控制流图中有6个节点，10条边，在测试用例数最少的情况下，确保程序中每个可执行语句至少执行一次所需要的测试用例数的上限是（61）。

对于逻辑表达式( (b1&b2)||in)，需要（62）个测试用例才能完成条件组合覆盖。

测试执行过程的阶段不包括（63）。

以下关于回归测试的叙述中，不正确的是（64）。

以下属于测试停止依据的是（65）。
①测试用例全部执行结束 ②测试覆盖率达到要求
③测试超出了预定时间 ④查出了预定数目的故障
⑤执行了预定的测试方案 ⑥测试时间不足

以下关于测试方法的叙述中，不正确的是（66）。

以下关于性能测试的叙述中，不正确的是（67）。

不同加密机制或算法的用途、强度是不相同的，一个软件或系统中的加密机制使用是否合理，强度是否满足当前要求，需要通过测试来完成，通常（68）是测试的一个重要手段。

安全日志是软件产品的一种被动防范措施，是系统重要的安全功能，因此安全日志测试是软件系统安全性测试的重要内容，下列不属于安全日志测试基本测试内容的是（69）。

下到关于DoS攻击的描述中，错误的是（70）。

Software entities are more complex for their size than perhaps any other human construct, because no two parts are alike (at least above the statement level). If they are, we make the two similar parts into one, a （71）, open or closed.In this respect software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound.
Digital computers are themselves more complex than most things people build; they have very large numbers of states.This makes conceiving, describing, and testing them hard.Software systems have orders of magnitude more（72）than computers do.
Likewise, a scaling-up of a software entity is not merely a repetition of the same elements in larger size; it is necessarily an increase in the number of different elements.In most cases, the elements interact with each other in some（73）fashion, and the complexity of the whole increases much more than linearly.
The complexity of software is a(an) （74）property, not an accidental one.Hence descriptions of a software entity that abstract away its complexity often abstract away its essence.Mathematics and the physical sciences made great strides for three centuries by constructing simplified models of complex phenomena, deriving, properties from the models,and verifying those properties experimentally.This worked because the complexities（75）in the models were not the essential properties of the phenomena.It does not work when the complexities are the essence.
Many of the classical problems of developing software products derive from this essential complexity and its nonlinear increases with size.Not only technical problems but management problems as well come from the complexity.

Software entities are more complex for their size than perhaps any other human construct, because no two parts are alike (at least above the statement level). If they are, we make the two similar parts into one, a （71）, open or closed.In this respect software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound.
Digital computers are themselves more complex than most things people build; they have very large numbers of states.This makes conceiving, describing, and testing them hard.Software systems have orders of magnitude more（72）than computers do.
Likewise, a scaling-up of a software entity is not merely a repetition of the same elements in larger size; it is necessarily an increase in the number of different elements.In most cases, the elements interact with each other in some（73）fashion, and the complexity of the whole increases much more than linearly.
The complexity of software is a(an) （74）property, not an accidental one.Hence descriptions of a software entity that abstract away its complexity often abstract away its essence.Mathematics and the physical sciences made great strides for three centuries by constructing simplified models of complex phenomena, deriving, properties from the models,and verifying those properties experimentally.This worked because the complexities（75）in the models were not the essential properties of the phenomena.It does not work when the complexities are the essence.
Many of the classical problems of developing software products derive from this essential complexity and its nonlinear increases with size.Not only technical problems but management problems as well come from the complexity.

Software entities are more complex for their size than perhaps any other human construct, because no two parts are alike (at least above the statement level). If they are, we make the two similar parts into one, a （71）, open or closed.In this respect software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound.
Digital computers are themselves more complex than most things people build; they have very large numbers of states.This makes conceiving, describing, and testing them hard.Software systems have orders of magnitude more（72）than computers do.
Likewise, a scaling-up of a software entity is not merely a repetition of the same elements in larger size; it is necessarily an increase in the number of different elements.In most cases, the elements interact with each other in some（73）fashion, and the complexity of the whole increases much more than linearly.
The complexity of software is a(an) （74）property, not an accidental one.Hence descriptions of a software entity that abstract away its complexity often abstract away its essence.Mathematics and the physical sciences made great strides for three centuries by constructing simplified models of complex phenomena, deriving, properties from the models,and verifying those properties experimentally.This worked because the complexities（75）in the models were not the essential properties of the phenomena.It does not work when the complexities are the essence.
Many of the classical problems of developing software products derive from this essential complexity and its nonlinear increases with size.Not only technical problems but management problems as well come from the complexity.

Software entities are more complex for their size than perhaps any other human construct, because no two parts are alike (at least above the statement level). If they are, we make the two similar parts into one, a （71）, open or closed.In this respect software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound.
Digital computers are themselves more complex than most things people build; they have very large numbers of states.This makes conceiving, describing, and testing them hard.Software systems have orders of magnitude more（72）than computers do.
Likewise, a scaling-up of a software entity is not merely a repetition of the same elements in larger size; it is necessarily an increase in the number of different elements.In most cases, the elements interact with each other in some（73）fashion, and the complexity of the whole increases much more than linearly.
The complexity of software is a(an) （74）property, not an accidental one.Hence descriptions of a software entity that abstract away its complexity often abstract away its essence.Mathematics and the physical sciences made great strides for three centuries by constructing simplified models of complex phenomena, deriving, properties from the models,and verifying those properties experimentally.This worked because the complexities（75）in the models were not the essential properties of the phenomena.It does not work when the complexities are the essence.
Many of the classical problems of developing software products derive from this essential complexity and its nonlinear increases with size.Not only technical problems but management problems as well come from the complexity.

Software entities are more complex for their size than perhaps any other human construct, because no two parts are alike (at least above the statement level). If they are, we make the two similar parts into one, a （71）, open or closed.In this respect software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound.
Digital computers are themselves more complex than most things people build; they have very large numbers of states.This makes conceiving, describing, and testing them hard.Software systems have orders of magnitude more（72）than computers do.
Likewise, a scaling-up of a software entity is not merely a repetition of the same elements in larger size; it is necessarily an increase in the number of different elements.In most cases, the elements interact with each other in some（73）fashion, and the complexity of the whole increases much more than linearly.
The complexity of software is a(an) （74）property, not an accidental one.Hence descriptions of a software entity that abstract away its complexity often abstract away its essence.Mathematics and the physical sciences made great strides for three centuries by constructing simplified models of complex phenomena, deriving, properties from the models,and verifying those properties experimentally.This worked because the complexities（75）in the models were not the essential properties of the phenomena.It does not work when the complexities are the essence.
Many of the classical problems of developing software products derive from this essential complexity and its nonlinear increases with size.Not only technical problems but management problems as well come from the complexity.