操作系统课后答案Word文档下载推荐.docx

操作系统课后答案Word文档下载推荐.docx

《操作系统课后答案Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《操作系统课后答案Word文档下载推荐.docx（26页珍藏版）》请在冰豆网上搜索。

当用户输入有效日期时（从1800年1月1日到2050年12月31日之间的所有日期），系统将自动计算出前一天的日期，否则，系统不执行日期的计算，并给出消息提示输入无效。

10．请仿照NextDate问题，针对NextMultiDate问题设计测试用例。

NextMultiDate问题的功能简述如下。

若用户输入有效日期（从1800年1月1日到2050年12月31日之间的所有日期），并指定延迟的天数（最多不超过366天），假设为n，则系统将自动计算出从有效日期往后n天的日期。

对于无效日期或无效延迟天数，系统不执行日期的计算，并给出消息提示输入无效。

11．若需要对多个测试用例进行管理，除了ID、输入和输出之外，需针对每个测试用例补充哪些信息?

测试用例的构成：

ID、、项目/软件、程序版本、编制人/编制时间、功能模块、测试项、测试目的、预置条件、参考文献、测试环境、测试输入、操作步骤、预期结果、执行结果、优先级、测试用例之间的关联。

12．请针对1．4．5节NextDate问题的第二次测试中所给出的测试用例，补充测试环境。

NextDate的测试环境应根据实际的开发和使用环境而定，从软件使用环境、开发平台等角度考虑即可。

13．请针对第6题的PrevDate问题，补充测试环境。

同上题。

第2章软件测试原理

1、对待缺陷我们应遵循哪些基本原则?

对待缺陷的基本原则：

缺陷的群集现象、缺陷有免疫力（测试要使用不同的测试方法）、缺陷关联和依赖（单纯依赖、多重依赖、复合依赖）。

2、当受到进度压力的时候，是优先进行黑盒测试还是白盒测试?

应优先进行黑盒测试，因为黑盒测试不需要了解程序实现的细节，通过黑盒测试至少可以证明：

被测软件系统可以完成哪些功能，哪些功能不能正确的实现，哪些功能甚至完全没有实现。

3、针对同样的问题（例如相同的代码段），采用黑盒测试与白盒测试方法得到的测试用例会有很多是重复的，那么，白盒测试有意义吗?

白盒测试有重要的意义，它主要是覆盖黑盒测试方法检查不到或难以发现的某项缺陷，白盒测试指标还可以充当对黑盒测试方法效果的检查，判断测试是否存在漏洞或冗余。

4、静态测试不需要执行程序，那么，是否可以用静态测试替代动态测试呢?

不可以。

静态测试与动态测试之间即具有一定的协同性，同时又具有相对的独立性。

程序静态分析的目标不是证明程序完全正确，而是作为动态测试的补充，在程序运行前尽可能多地发现代码中隐含的缺陷。

5、良好的单元测试是否可以替代集成测试?

不能。

良好的单元测试只能确保通过测试的单元内部基本可以正常工作，但不能保证单元集成在一起之后，能够正常工作，特别要关注可能存在误差累积的情况。

在单元测试与集成测试的关系中，即使保证每个单个的单元具有优秀性能，也不能确保整体的性能。

6、自动化测试工具可以让繁重的手工劳动变得轻松，那么，我们还有必要做手工测试吗?

自动化测试目前不可能完全替代手工测试，一方面是由于自动化测试工具的适用面都相对较窄，一种测试工具往往仅能处理很小一方面的测试问题，另外，有些测试活动需要重复发挥人的创造力，采用自动化测试工具不可能收到同样的效果。

7、只要学会某种时下流行的自动化测试工具的使用，就可以轻松搞定测试工作了，是这样吗?

不管是什么测试工具，它实质反映的是其背后的测试思想，因此，抛开测试方法去学习测试工具的使用，是没有任何意义的。

而且，测试工具使用的前提是必须有测试用例为指导，得到的测试脚本才具有复用性，而测试用例的设计涉及多种测试方法。

因此，完全不懂测试技术是不能胜任软件测试岗位的。

8、什么是冒烟测试?

如何实施?

冒烟测试是通过简单测试来判断系统基本功能（通常是核心业务模块）的覆盖率如何，而不验证正确性。

例如能否正确安装/卸载，主要功能是否实现，是否存在严重死机或数据严重丢失等缺陷。

冒烟测试工作一般需要实现自动化，可以借助诸如WinRunner、QTP这样的工具来录制自动化测试脚本，脚本由专人维护，且随着测试的进展对脚本不断进行增补。

9、随机测试就是随便测试，往往会取得意想不到的效果，因此，我们应在软件开发过程中广泛使用随机测试。

是这样吗?

不能这样。

随机测试是没有测试用例的，且往往是不可重复的。

这对缺陷的重现十分不利，且广泛采用随机测试将不能保证测试的全面性，无法了解测试的整体效果。

若在软考开发过程中广泛使用，可以表明测试过程是混乱的，缺乏管理的，则最终提交的软件产品质量是完全无法保证的。

10、在任何情况下，我们执行回归测试时，都应将以前测试过的用例全部执行一遍，是这样吗?

不是这样的。

回归测试是贯穿在整个测试的各个阶段的一个测试活动，主要是对修改过的软件重新进行测试，目的是为了验证修改的正确性及其影响。

回归测试包的选择应根据进度、风险、修改情况等全盘考虑。

11、我们该如何应用各种测试过程模型？

12、软件测试的目的是证明程序可以工作。

软件测试的目的是证伪。

这两种说法哪个正确?

两种说法都正确，但有存在片面性，应视不同的情况予以应用。

13、对比软件测试工程师的素质要求，你认为自己可以胜任软件测试工程师的岗位吗?

软件测试工程师的素质要求：

两项意识：

服务意识、团队合作意识。

三颗“心”：

耐心、细心、信心。

四种能力：

技术能力、沟通能力、逆向思维能力、移情能力。

五个特性：

实在幽默、十足记忆、时刻怀疑、十面督促、十分周全。

第3章黑盒测试技术

1．进行边界值测试时，为何要以边界点为中心，以一个单位长度作为邻域，而不是直接选择“1”为邻域?

进行边界值测试时，当以一个单位长度为邻域时，邻域随着单位长度的变化而改变。

若研究的粒度较精细，可选择更小的邻域，而若边界粒度较粗，则应适当增加单位长度，扩大边界的邻域范围。

单位长度可方便地调节边界值测试的邻域。

若直接选择“1”为邻域，则有时会造成边界影响面太小，导致遗漏缺陷。

2．边界值测试中所选择的输入测试数据一定是有效数据。

不一定。

边界值测试仅关注边界，设计测试用例时不区分系统输入在边界点上是否有效。

因此，系统输入在边界点上可能是有效的，也可能是无效的。

3．边界值测试中，若考虑边界的组合情况，即缺陷出现在多个输入条件的边界或边界附近，则称这样的策略为最坏情况测试。

若给出两个输入条件x,y，其中条件x具有3个极值点（x1，x2，x3），条件y具有2个极值点（yl，y2），如图3-1所示。

请采用最坏情况测试方法，导出测试用例的数目，并设计相应的测试用例。

最坏情况测试方法相当于在基本边界值分析的基础上，考虑x,y条件同时取得边界，所以图1中矩形框的边界和边界附近都应取到测试用例。

测试用例如图3-1所示。

测试用例数目为4×

7＋4×

2＋7×

1＝43。

4．对于3．2．8节的Commission问题，请采用基本边界值分析方法，从输入域设计测试用例。

从输入域采用基本的边界值分析，得到测试用例集合见表3-2。

表中预期输出是指销售员的总提成。

表3-2输入域的基本边界值分析测试用例（Commission问题）

5．对于3．2．8节的Commission问题，请分析案例实践二（见本书光盘部分的图3．1）中所有边界点是如何得到的。

各种酒的单价为：

白酒168元/瓶，红酒120元/瓶，啤酒5元/瓶。

各销售员每月至少需售出白酒50瓶，红酒30瓶，啤酒300瓶。

由此得到最低销售额：

1.35万元，对应最小边界点。

每个销售员的月供最高为白酒5000瓶，红酒3000瓶，啤酒30000瓶，由此得到最高销售额：

135万元，对应最大边界点。

销售员的提成公式中，发生提成比例变化的点为：

2万元和4.5万元，由此得到中间的两个边界点。

6．当时间有限时，应优先针对输入域进行边界值测试，还是针对输出域分析边界?

为什么？

当时间有限时，应优先从输入域考虑边界值测试。

因为系统总是根据输入情况来决定如何进行输出响应。

且输出域的边界值测试用例与输入域的测试用例有很多重复的情况。

因此，一般情况下，先对输入域展开测试，然后根据输出域的特殊性，补充更多边界测试用例。

7．如何才能方便、快捷地了解划分出的等价类是否能够体现真正的等价呢?

有两种途径：

第一种方式是正向判断法。

即从正向观察系统是输入和输出，在划分得到的等价类中随便选择几个数据，并从如下方面来观察：

●这些数据是否包含相同的输入条件。

●这些数据是否导致程序执行类似的处理。

●这些数据是否影响相同的输出结果。

●这些数据要么都让软件执行错误处理，要么都不让。

若以上方面中任何一方面不成立，则等价类划分肯定有问题。

第二种方法是结合决策表方法，若从该等价类划分无法得到精确无误的决策表，则说明该等价类划分是不“等价”的。

8．为什么对无效等价类设计测试用例时要采取一一对应原则，这对测试有何好处?

设计测试用例时，采取一一对应原则的含义是每个测试用例唯一覆盖一个无效等价类，这样的处理方式有利于缺陷的定位。

一旦某个测试用例失败，我们可以很方便地了解，系统对于哪个输入条件的哪个无效等价类无法适当予以处理。

9．案例实践三的NextDate实例中，测试用例ND-EP-001到ND-EP-007（见本书光盘）可以很好地考查系统的容错能力，但从满足用户需求的角度而言，这个测试用例的集合违反了实际工作中的一些基本原则，是哪些原则呢?

在实际的测试工作中，我们总是优先满足系统的基本功能，即优先测试系统的基本功能，看是否能够正确实现，在测试用例上数目也会更多一些。

而在本例中仅有一个测试用例去测试基本功能，却有6个测试用例考查系统的容错能力，这是不合适的。

另外，测试应尽量避免漏洞，而不怕冗余，本例中只有一个针对正常数据的测试用例，由此导致的测试漏洞是很大的，因此也违反了测试应避免漏洞的基本原则。

10、对于NextDate问题，若将2000年从闰年有效等价类中分离出来，其余两输入条件的划分方式参照3．3．8节的第二次等价类划分尝试（见本书光盘部分的表3．9）。

请采用弱组合和强组合方式分别设计等价类测试的测试用例。

此时的等价类划分如表3-3所示。

若采用弱组合形式进行等价类测试，得到的一组测试用例构成和最终的用例集合分别如表3-4和表3-5所示。

若采用强组合形式的等价类测试，则可得到45（3×

3×

5）个测试用例，具体的用例设计方法参见表3.14。

不再一一列出。

11、对于3．2．8节的Commission问题，请针对输入域展开等价类测试。

针对Commission问题，对输入条件的上、下限构成的边界范围可自然形成一个有效等价类，所以采用等价类测试，只有一个测试用例。

等价类划分见表3-6，测试用例见表3-7。

表中预期输出是指销售商的总提成。

表3-6输入域的等价类划分（Commission问题）

表3-7输入域的等价类测试用例（Commission问题）

12、对于如下的枪支销售问题（简称Sales问题），分别从输入域和输出域着手，进行边界值测试和等价类测试。

Sales问题的简单描述如下。

某步枪销售商负责销售某军火制造商生产的步枪，包括枪机（Lock）、枪托（Stock）和枪管（Barrel）。

其中枪机、枪托和枪管的单价分别为45美元、30美元和25美元。

销售商每月至少应卖出一支完整的步枪，同时，销售商每月最多只允许销售70个枪机、80个枪托和90个枪管。

该销售商的提成每月结算一次。

根据其销售业绩，制造商按如下计算方式来计算销售商的提成。

●销售额不足（含）1000美元的部分，提成比例为10％。

●销售额在1000美元（不含）到1800美元（含）之间的部分，提成比例为15％。

●超过1800美元（不含）的部分，提成比例为20％。

最终输出为当月销售报告和销售商的总提成。

三个输入条件为：

枪机、枪托和枪管的销售量。

针对输入域展开边界值测试，则枪机的边界点为1和70，枪托边界点为1和80，枪管边界点为1和90。

基本边界值分析的测试用例集合见表3-8。

针对输出域展开边界值测试，以销售额为输出，得到测试用例集合见表3-9。

表3-8　Sales问题的边界值测试的测试用例（针对输入域）

表3-9Sales问题的边界值测试的补充测试用例（针对输出域）

针对输入域的等价类划分见表3-10。

针对输入域的等价类测试用例（强组合形式）见表3-11。

表3-10输入域的等价类划分（Sales问题）

表3-11输入域的等价类测试用例（Sales问题）

针对输出域的等价类划分见表3-12，对应等价类测试用例见表3-13。

表3-12　输出域的等价类划分（Sales问题，单位：

美元）

表3-13　输出域的等价类测试用例（Sales问题）

13、对3．5．6节的NextDate问题进行第一次决策表尝试时，为何所得决策表中会输出不确定的测试用例?

该决策表中打问号的测试用例反映出系统对输入的不确定无法处理，输入的含义是：

对于任意年份，月份是每月有31天的月份，日期是31号，这时存在一个年末日期的问题，对于12月31日，系统输出应为次年的1月1日，而对于其他月份（如7月31日），系统输出应为下月1日（如8月1日），因此，系统无法针对相同的输入等价类给出明确的输出。

这时应将月份的等价类进一步划分下去。

14、请仿照NextDate问题，针对PrevDate问题使用边界值、等价类和决策表方法展开测试。

PrevDate问题中特殊的日期包括：

年初日（即每年的1月1日）、月初日（即每月1日）和闰年情况（即3月1日）。

PrevDate问题包括三个输入条件：

年份、月份、日。

边界点分别为：

●年份：

1800年，2050年

●月份：

1月，12月

●日：

1号，31号

根据这些边界点，使用基本边界值分析方法进行边界值测试，与NextDate问题的分析方法完全相同，所以得到的测试用例也非常相似（输入完全相同，预期输出不同而已）。

等价类划分如表3-14所示，得到决策表见表3-15，采用决策表得到的测试用例见表3-16。

表3-14　PrevDate问题的等价类划分

表3-15PrevDate问题的决策表

表3-16PrevDate问题的测试用例集合

15、根据3．7．5节的规则（详见本书光盘），检查测试用例表3．24发现输入条件“账面余额”未取到“I”，说明测试用例有漏洞，而表3．24中又显示测试用例覆盖了所有五个场景，为什么会出现这种相互矛盾的情况?

是规则有错，还是别的什么原因呢?

对于备选流4的含义是：

输入金额校验失败，这里有很多情况可以导致金额校验失败，如输入金额格式错误、账面余额不足等，表3.24的测试用例ATM-ST-006的触发事件是输入金额格式错误的情况，而未测试账面余额不足的情况，所以输入条件“账面余额”未取到“I”。

这里并不矛盾，因为表3.24中的第2列是从较粗的粒度来考查用例覆盖的，而设计测试用例时若需要覆盖备选流4，却需要从细节来考虑，所以出现了不一致的情况。

第4章白盒测试技术

1、对于4.2.2节中的函数FuncSC，随着三个布尔变量取值的不同，在特殊的取值组合条件下，程序的输出与输入是不相等的。

请问在什么条件下，该函数的输出不等于输入?

当函数FuncSC的第1和第2个布尔变量不同时取真值的时候，函数的输出不等于输入。

2、对于4.2.2节中的函数Func7，其代码中隐含一个空间分配的缺陷，请找出该缺陷。

函数Func7中的缺陷在第3-5行代码处，即当变量bFlag为假的时候，未对pArray分配空间，该指针为空，所以后续操作将失败。

3、4.2.3节中，表4.3中取LC-003到LC-005中的任意一个与LC-002组合起来，都满足判定覆盖。

请问，LC-003到LC-005这三个测试用例中，哪个测试效果相对更好?

在同时满足覆盖指标的前提下，应从判定表达式的屏蔽效应以及边界值测试的角度判断测试数据选择的好坏。

为执行路径L13，两判定节点都应取假值，为了避免判断表达式的屏蔽现象，必须保证T1为真（即（a>

1）为真），测试用例LC-004显然不满足该要求。

另外，应保证T4为假（即（x>

3）为假），考虑到3是x取值的边界，因此，应针对边界值来选择测试数据，所以LC-005更优于LC-003。

总体看来LC-005是三个测试用例中最优的一个。

4、4.2.5节中，按照函数Func6Modified将复杂逻辑表达式拆分为简单的表达式之后，请设计两个测试用例来满足判定覆盖。

设计的测试用例见表4-1。

表4-1函数Func6Modified的测试用例集合（满足判定覆盖）

5、给定以下代码，请利用逻辑覆盖的各项覆盖指标分别设计测试用例。

列出真值表如表4-2所示。

表4-2　真值表

●对于语句覆盖和判定覆盖，选择测试用例005和006。

●条件覆盖，选择测试用例004和005。

●判定/条件覆盖，选择测试用例004和005。

●条件组合覆盖，选择所有。

●修正的判定/条件覆盖，选择测试用例003、005、006、007。

6、当判定表达式具有三个简单逻辑判断条件时，所有可能构成的表达式形式如题表4.1所示，请针对下表中的四种组合情况，分别采用修正的判定/条件覆盖指标设计测试用例。

题表4.1三个简单逻辑判断条件构成的所有可能的判定表达式

根据题目中给出的真值表，采用唯一原因法得到各条件的独立影响对如表4-3所示。

因此得到满足不同表达式的修正判定/条件覆盖的测试用例集合分别见表4-3。

表4-3　不同复合表达式的条件独立影响对

7、请针对扩展的Trgl问题展开基路径测试。

Trgl问题描述为：

给定三角形的三条边长，分别为a、b和c，且边长均为整数，要求根据三条边长的关系输出：

不构成三角形、不等边三角形、等腰但不等边三角形或等边三角形，

具体的程序代码如下。

考虑到不可行路径，最终测试4条路径：

Path1：

1,3,4,7,8,9,End

Path2：

1,3,4,7,8,10,11,End

Path3：

1,3,4,7,8,12,13,End

Path4：

1,3,5,6,7,15,16,End

得到测试用例见表4-4。

且应考虑到输入的各种组合，所以给出了更多的测试用例。

表4-4　三角形问题测试用例集合

8、请针对以下的Commission代码进行基路径测试

该CommissionModify函数只有3条路径。

若用A表示1,2,3,4,5号语句，则有

A,6,7,12,13

A,6,8,9,12,13

A,6,10,11,12,13

这其实已经等同于等价类测试+边界值测试了。

测试用例不再列出。

第5章面向对象软件测试

1、所有类都需要进行单元测试吗?

并非所有类都需要进行单元测试，类的优先级可从三方面来衡量：

①类在系统中所起的作用

②类自身的复杂度和与其他类之间的交互复杂度

③开发该类的测试程序所需的成本

2、私有方法可以测试吗?

私有方法可以测试，测试方法有：

①直接修改被测代码的访问权限

②在被测类中加入公有方法

③利用内类机制

3、对于一个类而言，测试用例设计的一般策略是怎样的?

面向对象的单元测试一般策略：

①首先根据方法特性划分：

构造函数、功能函数和接口函数。

②针对构造函数，根据前置和后置条件设计用例。

③针对功能函数

公有方法：

基于前置条件和后置条件设计测试用例。

受保护的方法：

严格区分有访问权限和无访问权限的前置条件和后置条件，设计测试用例。

私有方法：

根据实际情况选用适当的策略进行测试。

④针对接口函数，根据状态转换设计测试用例。

⑤对于以上每种情况，都应结合边界值、等价类等测试方法来选择测试数据。

４、将测试代码直接写在被测类的代码中即可，对吗?

可以将测试代码直接写在被测类的代码中，但这不利于开发代码与测试代码的分开，不利于后续测试代码的维护和开发产品的交付。

5、抽象类无法实例化，所以不能测试，对吗?

抽象类虽然无法实例化，但可以通过以测试类的内类继承方式来测试，是可以的。

6、顺序图和协作图可用作面向对象的单元测试，对吗?

顺序图和协作图适用于面向对象的集成测试。

第6章单元测试

１、良好的单元测试是否能够代替集成测试?

若每个模块都经过了严格的单元测试，还需要集成测试。

我们在测试过程中经常遇到的情况是：

单元测试中每个模块都能单独工作，但将这些模块集成在一起之后，某些模块就不能正常工作了。

例如，接口数据丢失，模块之间的不良影响，误差的不断累积等。

因此，单元测试无法代替集成测试，每个模块的性能最优并不能保证集成之后的指标达到最优。

２、什么是驱动模块?

什么是桩模块?

为什么需要驱动模块和桩模块?

驱动模块是模拟被测单元的上级模块，用于接收测试数据、启动被测模块和输出结果。

桩模块是模拟被测单元所调用的模块。

测试时需要通过驱动模块和桩模块搭建单元测试环境。

３、单元测试的过程是怎样的?

单元测试的过程可划分三个阶段：

计划阶段：

完成单元测试计划，制定单元测试策略。

设计实现阶段：

建立单元测试环境，完成测试设计和开发。

执行评估阶段：

执行单元测试用例，记录和评估测试结果。

４、为第4章白盒测试中的Commission问题进行单元测试。

５、针对第3章的思考题14（PrevDate问题），写出程序代码，并进行单元测试。

第７章集成测试

１、什么是集成测试?

集成测试是在单元测试的基础上，将所有已通过单元测试的模块按照概要设计的要求组装为子系统或系统，进行集成测试，目的是确保各单元模块组合在一起后能够按既定意图协作运行，并确保增量的