软件测试教程 -方法与实践(第2版) 参考答案 第1-10章

第1章软件测试核心概念

一、测试员在测试过程中应尽量追求完美。该描述正确吗？

错。不能穷尽测试，成本太高。

二、软件测试的目的是发现缺陷。该描述正确吗，

正确。软件测试的目的就是为了发现软件中的缺陷，从这个怠义上面说上面的这个论断

是正确的。不少人会认为软件测试可以保证软件的质量，其实这个观点是错误，测试只是软

件质量控制中的一个角色，其活动并不能达成软件质量保证的效果。所以不要认为一个公司

里面如果有了软件测试人员，产品的质量就会好起来。

三、自动化测试的难点在于如何快速学会使用测试工具?该描述正确吗？

该描述正确，因为国内对使用测试工具技术方面还不成熟。

随着国内企业软件开发及;则试水平的提升，许多企业开始尝试开展自动化测试的应用，以提

高测试效率和测试质量。虽然在国外自动化测试工具应月已经很普遍，但国内许多企业对于

软件自动化测试的理解还停留在表面上，没有深入的理解到企业实施自动化测试所要具备的

条件以及自动化测试本身的局限性，导致自动化并没有给企业带来多少实际的价值，反而还

浪费了资源。

四、为什么说软件的需求规格说明书往往是软件缺陷的最大来源?对软件测试工

作有何启发？

软件缺陷；存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差，

Bug是口语化的缺陷。缺陷在没有被激活的状态下，软件可以正常运行，但是一旦在某一触

发条件下，缺陷被激活，软件内部就会出现故障。

因为软件缺陷产生的原因有很多，典型的原因如下：

软件本身的复杂性，开发人员的问题，需求的变化，进度的压力，对文档不重视，沟通

不畅，偏差的累积。

各种来源导致缺陷会广泛分布在软件开发的各个阶段，需求规格说明书、软件设计、代

码中都可以看到缺陷的身影。特别是由于需求的变化和人们对文档的轻视，导致需求规格说

明书中的缺陷通常会占缺陷总数一半还多。

五、请仿照NextDate问题，针对PrevDate问题设计测试用例。PrevDate问题

的功能简述如下：当用户输入有效日期时（从1800年1月1日到2050年12月

31日之间的所有日期:，系统将自动计算出前一天的日期。否则，系统不执行日

期的计算，并给出消息提示输入无效。

略

六、请根据测试用例的定义和管理的需要，设计一个测试用例报告的模板。

略

第2章软件测试背景

七、软件测试的目的是什么？

1、提高软件的质量

软件测试的首要目的就是提高软件的质量，也就是让用户对产品有更好的体验，保证软

件的高质量。

2、保证软件的安全

软件测试的第二大目的就是保证软件的安全，有一些软件是经过数据加密的，比如各大

银行系统的APP。涉及到资金的支出和存入，对软件的安全性要求是特别高的。所以要通

过反复测试来提高产品的安全性，保证产品在上线之后不会出现bug,尤其对于金融方面的

APP来说，任何漏洞都是致命的。

3、降低软件开发成本

软件测试的另外一个目的就是降低软件的开发成本，在开发过程中发现bug及时调整,

这样的损失是很小的，一旦产品上线或是即将完成开发而发现bug,那么可能会造成产品大

改动，这样就意味着以往的精力全部白费。因此测试的存在就是为了降低开发成本。比如迪

士尼的一款狮子王的软件，借着狮子王的名声，预期本应是好评如潮，也能通过这款软件获

益不匪。但因为在很多系统上都无法使用，所以造成了大量的用户投诉和下线、卸载等。对

成本造成「非常大的损失，那如果当时这款软件能够在不同的系统上进行测试，在上线前将

所有的问题全部解决掉，肯定会大大降低成本。

4、降低企业风险

除了降低开发成本，还可以降低企业风险，试想，如果软件存在的问题过多，亳无疑问

会影响企业的信誉，最终直接导致企业的合作企业变少，直接损害公司的收益。但如果有测

试人员在中间严格把关，就完全不会出现这样的问题。

5、提升用户体验感

开发人员在开发过程中都是以顺向思维来写程序代码的，所以很少有开发人员能够站在

用户角度去思考，但测试人员不一样，测试要以逆向思维来思考程序会在哪一步有问题，站

在用户的角度进行测试，这样上线的产品将很符合用户的需求，用户使用时也比较顺手，增

加用户体验感。

八、为什么国内软件测试的发展相比欧美等发达国家存在较大的差距？

1.我国现代工业体系起步晚，工业软件发展存在代差

（1）工业软件较发达的国家，如美国、法国、德国等，都是完成了工业化进程的工业强

国，已经经历了几十年的发展，工业软件配套体系比较完整。

（2）国内起步落后于国外20-30年，与国外相比具有技术代差，单元应用与系统应用举

步维艰，需要一定时间去耐心追赶。

<3）在引进国外先进设备与工艺的同时，大量国外软件产品“乘虚而入”并形成依赖,

国产工业软件市场占率极低，关键领域和环节技术产品严重受制于人。

2.工业软件基础与核心技术薄弱

(1)过去几十年来，国内CAD(计算机辅助设计)和CAE(计算机辅助仿真)等核心

工业基础软件，却一直由西门子、达索、欧特克等欧美企业研发的软件做主导，国产工业软

件长期缺位。我国工业软件自主基础与核心技术薄弱，特别是三维几何引擎(CAD内核)、

CAE求解器等核心技术存在卡脖子风险。

(2)工业软件是买不来的关键技术，对于国产工业软件来说，“核心技术”不仅在于简

单的开发和应用，还在于后期的管理以及标准建设。

3.工业软件产品产用脱节，形成恶性循环

我国航天、航空、船帕、电子、石油化工等重点制造领域产品创新设计、仿真模拟、工

艺流程控制等高端工业软件几乎都是清一色的国外工业软件，不仅影响我国工业产品正向设

计能力，而且使得国外软件不断拉大与国内软件的差距，形成了应用生态壁垒。

4.行业高端人才和复合型人才缺口较大

(1)行业高端专业人才紧缺，高端专业人才是指深入掌握专业知识的领军人才。工业软

件企业难以给予具有竞争力的薪酬待遇，造成工业软件行业高端领军的缺失。

(2)复合型人才缺失，工业软件开发人员在掌握一定软件开发能力的同时，还要掌握相

关工业领域专业知识，更需要对复杂工业机理、产品对象、业务场景、操作流程等具有较为

深入的理解和认知，复合型人才培养难度大。

九、根据国内软件测试从业人员的现状分析，你认为如何才能做一个合格的软件

测试工程师呢？

1.专业技术能力

熟练掌握测试基础知识，永远是成为合格的软件测试工程师的决定性条件。

2.团队协作能力

(I)合理进行人员分工

合理的进行人员分工是提高工作效率的重要保证。

(2)协助组员解决问题

比如说测试在赶进度，或者这个软件项目的质量把控是一个团队来把控的，协助组员解

决问题就显得尤为关键。

(3)配合完成测试任务

一个团队里边的人员分工，他们的任务都是不一样的，这就是咱们说的配合。你的东西

做完了，要轮到我了，我的性能测完了之后该轮到你了，所以整个的一个流程下来之后，大

家应该是各司其职，配合得非常紧密的一个过程。

(4)配合开发重现缺陷

我给你提bug,你改我的bug,咱们的目的只有一个，就是让这个软件变得更好，所以

在这样的情况下，咱们就一定要配合开发。

(5)督促项目整体进度

既然是一个团队协作的过程，就一定要互相的去督促对方，包括督促开发人员去改bug,

因为开发人员他们有时候工作很忙，他们不知道要先改哪些问题，要后改哪些问题，但是往

往有一些缺陷，它影响了测试的这个时间，影响了测试的进度，那么这个时候就需要测试员

去督促开发人员，让他尽快的去解决你棘手的问题。这个东西能够提高咱们的测试效率。

(6)出现问题勇于承担责任

愿意背锅的最后都成为了领导，不愿意背锅的最后依然是员工。

3.乐观的心态和耐心的态度。

测试工程师每天面对的是程序中的“错误”，而程序员每天都在创造代码。

第3章黑盒测试技术

十、在3.2节介绍的边界值测试中，为何不区分边界点的有效性，即不考虑边界

点是否为系统可以接受的数据，且不考虑边界点附近的测试数据是否为系统可以

接受的数据？

如果是闭区间，有效性包括边界点，如果是开区间，边界点包含在无效输入里。人们从

长期的测试工作中总结出一个经验：大量缺陷发生在被测对象的输入域或输出域的边界(即

极值)卜，而非输入或输某域的内部°设计测试用例时,如果针对边界附沂重点加以检验.

常常可取得良好的测试效果，取得较高的测试回报率。边界值测试符合人们的一个基本假设:

如果软件在能力达到极限的时候能够运行，那么其在正常情况下一般也不会有什么问题。

十一、请对3.2节的佣金问题，采用边界值测试方法，从输入域的角度设计测试

用例。

略

十二、针对无效等价类，为何不采用强组合方式设计测试用例，即测试到所有可

能的无效等价类组合情况？

等价类划分法是黑盒；则试中非常重要的测试方法，采用等价类划分法时，无需考虑程序

内部结构，设计测试用例是依据游戏策划案进行设计的。

等价类是输入条件的一个子数据集合，该输入集合中的数据对于揭示程序中的错误是等

价的，从每一个子集中选取少数代表性的数据，从而进行梳理，组合成测试用例。

等价类划分法分为：有效等价类、无效等价类。

有效等价类：有效等价类代表对程序的有效输入数据

无效等价类：无效等价类则是以任何方式的无效输入数据。

有效等价类和无效等价类都是使用等价类划分法设计用例时所必须的，被测程序需要能

够保证正确的数据输入以及错误的输入数据检验，这样才能确保游戏具有更高的可靠性。

等价类划分法的优缺点

优点：

使用等价类划分法能对某一个数据子集进行详细的划分，顺序性强，逻辑清晰，确保无

冗余。等价类划分法能够将无穷的输入数据限制在一个指定范围，能够使用少量数据发现更

多Bugo

缺点：

数据集成输入间的内容过少，数据与数据之间的牵连性会存在考虑不周全，还需要其他

用例设计方法来补充测试，例如边界值分析法，等价类划分法通常与边界值分析法在数据输

入的场景配合使用。

十三、请对3.3节的佣金问题，采用等价类测试方法，从输入域的角度设计测试

用例。

略

十四、当在某个校验点上可能得到的备选流数量很多时，将导致备选流数目的激

增，如何解决该问题？

1、首先，使用“分层聚类”分析。

2、其次，选择聚类类别，SPSSAU默认聚为三类。

3、最后，结合树状图进行分析，分层聚类出来，具体聚成几个类别较好，需要结合树

状图结果及实际数据情况进行分析对比。

第4章黑盒测试案例实践

十五、下面是一个有关人寿保险的案例。描述如下：某保险公司的人寿保险的保

费计算方式为投保额X保险费率，其中保险费率依点数不同而有区别，10点及

10点以上保险费率为0.6%,10点以下保险费率为0.1%,且点数由投保人的年龄、

性别、婚姻状况和抚养人数来共同决定，具体规则如下：

年龄性别婚姻抚养人数

20-3940〜59其他女男已婚未婚

1人扣0.5点,最多扣3点（四舍五入取整）

6点4点2点5点3点3点5点

特别地，当人的年龄达到80岁或抚养人数达10人时，不接受投保。请针对该人

寿保险金的计算问题，利用本章所介绍的测试方法来设计测试用例，并关注这些

测试用例是否切实可行，是否符合常理。

略

十六、如何快速校验划分出的等价类能否体现真正的“等价”？

有两种途径：

第一种方式是正向判断法。即从正向观察系统是输入和输出，在划分得到的等价类中随

便选择几个数据，并从如下方面来观察：

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

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

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

•这曲数据要么都让软件执行错误处理.，要么都不让。

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

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

该等价类划分是不“等价”的。

十七、当时间有限时，应优先针对输入域进行测试，还是针对输出域进行测试?

为什么？

当时间有限时，应优先从输入域考虑边界值测试。因为系统总是根据输入情况来决定如

何进行输出响应。且输出域的边界值测试用例与输入域的测试用例有很多重复的情况。因此,

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

第5章白盒测试技术

十八、给定以下代码，请以判定表达式为测试重点，选择合适的覆盖指标设计测

试用例。

boolTestLogicCoverage(boola,boolb,boolc)

{

1boolx=false;

2if((a||b)&&c)

3x=tu;

4clse

5x=false;

6re(urnx

判定入达式只。•?.为Ta||b)&&c个科电条件•这里•我

达大分收2，分,05tfia||b稗"la||b)&&c

于这个表达由与这个表达式.啊州翻

5,—WK.•bM——T

表中可以曾出需试用例2和4nl以体］laM(“|b)的/响,用例3加4可

以体现bW(a||b)的彩响用例】与兑他比较不能&出aufbM(allb)的

影响刷试用例1世冗余的♦修正5

冉6(a||b)&&c.MF6个表达式.由(a||b)'ic>响谊个表达式.从

。影峋题中的x.轿(a||b)。成一个整体均利的％祟如下：

友中可以11出篇忒用倒】和3，1r“标也叫b)时(a||b)&&c尚影响,用倒

袅中叫H*IE.»HFl«：3、体;"a||b)r，a||b)&&c的，口以依

1HJ2-111ftWc*t(«||b»&U•>.Mf-4JtF.t-KWfifL(a||b)

，"纣"||b4&c'F»•.明*41工余的•"d.Hi

耨表1用及2lEi>d«

十九、当判定表达式具有3个简单逻辑判断条件时，所有可能构成的表达式形式

如表5.36所示。请针对下表中的4种组合情况，分别采用修正的判定/条件覆盖

指标设计测试用例。

希363个柳•厮辘蹄礴济淀罚弑

ABCAAND(BANDC)AAND(B0RC)AOR(BANDC)AOR(BORC)

TTTTTTT

TTFFTTT

TFTFTTT

TFFFFTT

FTTFFTT

FTFFFFT

FFTFFFT

FFFFFFF

略

二十、请针对佣金问题代码进行基路径测试。

连通路径i18/5+2=5

1测试川川uaMLB«nlKt；

Case18090100IABC2

X*o10101ABDEFG2

3*o20301ABDEHIG2

|CM<M2020301ABDEWKG2

CaseS7080901ABDEHJLM2

二十一、请用反证法证明独立路径之间是线性无关的。

线性无关是维性的史的"期间瓢..它被广泛地应用王睢优蜘泛的分析中，有关线性无关的许多问题都可用反证法^解决.

例1设A是编拄间卜±69辘艘，如射C‘⑹叫回/⑷叫我工A&）,•••・A‘"）（Q°）蜴线关.

证明假设臬A（《）•…，A’’6）线性相关，则存在不全为零的敌使得

储+仇@+・一+九4'⑷=0.

假设〃是不等于零的系数中下标国JWA个，则有

M（G+&A%）+・•・+如A-⑷=0.

等式两端同｛饺换Al,得

//”）+，，（＜）+…+*A”々舁=。，

曲/⑷=o,得"）=。,从而1=0,这Y

第6章白盒测试案例实践

二十二、当时间有限时，是优先进行黑盒测试，还是优先进行白盒测试?为什么?

优先黑盒，黑盒测试基本上类似于模拟用户测试，尤其是可以测试漏洞，后门溢出，服务

器稳定性等重要问题，最起码基本功能能达到基本完善。

就测试来说，当源代码较长时，可采用独立测试的思想，将源代码中较为独立的结构化

设计代码段抽取出来，单独设计测试用例，然后对整个代码设计测试用例，这样得到的测试

不容易出错。

尽管人寿保险金问题也是一个函数层面的案例，然而，如果函数代码设计不合理，会对

测试工作造成巨大的障碍，因此，白盒测试一般是要求程序员来完成的，主要目的是使得程

序员带着测试的思想来编写代码，提高代码的质量,这样才能更有效地确保软件产品的质量。

二十三、当对代码进行测试时，若发现被测代码结构不合理，或过于复杂，测试

人员能否修改代码结构?为什么？

略

二十四、具备良好的测试习惯能够帮助程序员提高代码编写的质量吗？

1.注重代码质量

良好的编程习惯之•是注重代码质量。编程人员应该编写易于理解、易于维护和易于扩

展的代码。这样做可以帮助他们快速定位和修复错误，并且更容易推出新的功能。此外，优

秀的代码质量也可以提高产品质量和用户体验O

2.坚持测试和调试

另一个良好的编程习惯是坚持测试和调试。编程人员应该编写测试用例，确保代码能够

正常运行，并尽早发现和解决错误。他们还应该使用调试器和其他的工具来分析代码并找到

错误的根源。这些实践可以帮助他们提高代码的质量和稳定性，并且减少错误的数量。

3.保持文档更新

编程人员还应该保持文档的更新。编程代码本身并不足以解释软件的所有细节和设计决

策。因此，他们应该编写却维护文档，记录软件的特性、设计技术和其他重要的信息，从而

方便团队成员和其他人员了解产品和开发过程。这样做匕以帮助编程人员更好地协作并促进

知识共享。

4.不断学习和改进

最后一个重要的编程习惯是不断学习和改进。编程技术一直在不断发展和改进，因此编

程人员必须保持更新并学习新技术和更好的实践。他们可以通过参加培训、阅读文献、观看

培训视频等方式来学习并掌握新技术。这样做可以帮助他们更好地完成工作，并且为未来的

职业生涯做好准备。

良好的编程习惯对职场人士来说非常重要。它们可以提高代码质量和稳定性、减少错误

的数量、促进知识共享、提高工作效率以及为未来的职业生涯做好准备。职场人士应该注重

这些良好的编程习惯，并不断改进和提高自己的技能和实践。这样做可以帮助他们更好地实

现自己的职业目标，并为公司的成功做出贡献。

第7章单元测试

二十五、良好的单元测试是否能够代替集成测试，

不能。单元测试和集成测试有很多共性，例如都是为了确保程序可以正确运行、减少错

误；同时，两者都需要编写相应的测试用例、执行测试、分析测试结果等。但是，两者也有

一些区别。

首先，单元测试强调代码功能的独立性，感觉模块与其他部分解耦后，才能使用自动化

测试框架进行测试。而集成测试强调不同模块之间的互联互动及完整性，因此需要将所有模

块一起整合才进行测试。其次，单元测试关注程序内部逻辑是否正确，而集成测试则验证模

块之间的交互是否正确。最后，单元测试和集成测试的测试成本和风险不同，前者成本较低，

缺陷更容易被修复，但不足以覆盖整个系统；后者成本较高，缺陷修复困难，但可以保证系

统整体性和一致性。

单元测试和集成测试各有其优点和限制，因此在软件开发过程中，需要设计一个有效的

测试策略来平衡二者之间的关系。

下面是一些相关建议：1.避免过度依赖单元测试。虽然单元测试能够检测程序的小错误,

但它不足以覆盖所有场景及交互，因此不能完全取代集成测试。2.明确测试目标和范围。在

测试中，需要明确测试目标和测试用例并提出相应的测试计划，以帮助确保测试的准确性和

全面性。3.合理安排测试时间。测试是个重要的工作，但是不能占用软件开发时间的大部分，

需要也需要权衡人力资源和时间投入等方面的问题。4.使用良好的集成测试工具。采用自动

化测试和持续集成可降低则试成本及风险。

二十六、什么是驱动模块?什么是桩模块?如何设计驱动模块和桩模块?

桩模块:一个软件组件框架的实现或特殊FI的的实现川于开发和测试另一个调试或依赖

于该组件的组件，它代替了被调用的组件。

驱动模块:代替某个软件组件来模拟控制和/或调用其他组件或系统的软件或测试工具。

驱动模块一般是应用于自底向上的集成测试环境中

桩模块一般是应用于自顶向下的集成测试环境中

在自底向上的集成测试环境中：

・E、F、G、D是被测试模块，此时需要模拟出两个上级模块来为这四个数据传递数据，那

么中间位置的两个模块就是驱动模块，同理当测试中间两个模块的时候，最终的模块也就是

驱动模块（被多个同级模块调用但是被虚拟假设出来的）

自哽向上臬或

在自顶向下的集成测试环境中:

是先从Ml开始测试的，然后逐层的向下进行分解测试，在测试上层模块的过程中需要调用

下层的模块完成输入输出就被称为桩模块（例如M2、M3、M4就称为Ml的桩模块）

M1■

M2M3S4

M5M6S7

M8

二十七、单元测试的过程是怎样的？

通常单元测试在编码阶段进行。在源程序代码编制完成，经过评审和验证，确认没有语

法错误之后，就开始进行单元测试的测试用例设计。利用设计文档，设计可以验证程序功能、

找出程序错误的多个测试用例。对于每一组输入，应有预期的正确结果。

模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些

辅助模块去模拟与被测模块相联系的其它模块。这些轴助模块分为两种：

驱动模块：相当于被测模块的主程序。它接收测试数据，把这些数据传送给被测模块，

最后输出实测结果。

桩模块：用以代替被测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子

模块所有功能都带进来，但不允许什么事情也不做。

被测模块、与它相关的驱动模块及桩模块共同构成了一个“测试环境”。

如果一个模块要完成多种功能，且以程序包或对象类的形式出现，例如Ada中的包，

Modula中的模块，C++中的类。这时可以将这个模块看成由几个小程序组成。对其中的每

个小程序先进行单元测试要做的工作，对关键模块还要做性能测试。对支持某些标准规程的

程序，更要着手进行互联测试。有人把这种情况特别称为模块测试，以区别单元测试。

二十八、请针对第5章白盒测试中的佣金问题进行单元测试实践。

略

第9章系统测试

二十九、系统测试完成后就可以发布软件了吗？

系统测试不能省略。一般地，对于开发人员来说，系统测试是产品交付给用户前的最后

一个测试环节，占有重要的地位。当面临紧迫的交付压力时，单元测试和集成测试很可能被

取消，但系统测试只能被压缩，不可能完全不做系统测试。

系统测试主:要是针对需求规格说明中所描述的系统功能和非功能需求进行测试,对应的

测试活动包括功能测试、性能测试、安全性测试、兼容性测试等，下面分别展开讨论。

三十、功能测试是功能性测试吗？

功能测试（FunclionTesling）主要针对系统的功能需求展开测试，以确认被测系统是否满

足用户的功能使用要求。它是系统测试中最基本的测试。总体来说，在功能测试中，主要应

结合黑盒测试的基本思想，从系统输入（包括合法输入和非法输入）、系统内部处理（包括数据

计算和存储）、系统输出（包括正常输出、针对错误输入的提示性输出、各种输出设备等）这三

个方面设计测试用例。由「不同的应用系统具有不同的特点，功能测试的侧重有所不同，在

此不妨将被测系统分为以数据为中心的系统（即各种管理信息系统）和以活动序列为中心的

系统（即大部分基于Web的应用系统），分别讨论测试的设计。

三十一、当时间紧迫时，可以不做性能测试吗？

不能。性能测试（PerformanceTesting）就是对软件的运行性能指标进行测试，判断系统集

成之后在实际的使用环境下能否稳定、可靠地运行。软件性能主要考虑系统的时间和空间性

能。其中，时间主要指软件的一个具体事务的响应时间。不同公司和项目对不同事务可能具

有不同的响应时间要求，例如，某项目中要求所有涉及新增、修改的操作响应时间在3秒以

内，而针对查询的响应时间仅要求在7秒以内即可。空间性能主要指软件运行时消耗的系统

资源，该指标主要影响系统的最低配置和推荐配置。典型的性能指标包括CPU的使用情况、

I/O的使用情况、主要存储内存的使用情况、每个模块的执行时间百分比、系统反应时间、

系统吞吐量等。

三十二、用户界面测试只不过是在界面上东看看西看看，没有什么技术含量，是

这样的吗？

不是。用户界面是软件与用户交互的最直接的层，界面质量决定了用户对软件的第二印

象（安装是第一印象）。随着用户对软件的要求越来越高，用户界面设计越来越重要，而随着

用户界面越来越复杂，用户界面测试也变得异常困难。

第11章测试应用案例实践

三十三、自动化功能测试适合在什么阶段使用？

1、测试需求分析阶段。测试需求分析阶段主要工作是获得测试项目的测试需求（测试

规格）。输出产物：《可测试性需求说明书》和《测试规格》。

2、测试计划阶段。以测试需求为基础，分析产品的总体测试策略。输出产物：《产品

总体测试策略》。

3、测试方案设计阶段。本阶段主要是以测试规格为基础获得特性测试方案，对于有自

动化测试的项目，进行自动化测试的分析，获得测试策略。输出产物：《产品或者版本总体

测试方案》。

4、测试用例实现阶段。本阶段主要是完成各个特性的测试用例的编写和自动化脚本的

编写。输出产物：《产品自动化测试用例》和《手工执行测试用例》。

5、测试执行阶段。本阶段是根据测试策略开展测试执行和回归测试。输出产品：《产

品或版本测试报告》和《缺陷分析报告》。

6、评估与关闭阶段。只对前面的各个阶段的执行情况，完成对测试项目的关闭，同时

提供完整的度量数据和项目总结报告。

三十四、请从Web应用测试的角度谈谈在网络教学平台的系统测试阶段，还要从

哪些方面考虑测试，并说明可以使用的测试工具。

面向Web应用系统的测试与传统的软件测试不同，不仅需要检查和验证是否按照需求

规格说明书的要求运行，而且还要测试Web应用系统在不同浏览器上显示是否符合要求，

与不同的数据库连接是否有效、更重要的是在性能、安全性、可用性等方面功能测试、性能

测试、安全性测试、配置和兼容性测试、可用性测试、链接测试等。

使用Cookie技术，当用户使用Web应用系统时，能够在访问者的机器上创立一个叫做

Cookie的文件，把部分信息（访问过的页面、登录用户名、密码等）写进去，来标识用户状态。

如果该用户下次再访问这个Web应用系统，就能够读出这个文件里面的内容，正确标识用

户信息如果Web应用系统使用了Cookie,必须检杳Cookie是否能正常工作，是否按预定的

时间进行保存内容设计语言测试在Web应用系统开发初始，根据软件工程的要求用文档的

形式确定Web应用系统使用哪个版本的HTML标准，允许使用何种脚本语言及版本，允许

使用何种捽件,这样可以有效的避免Web应用系统开发过程中出现设计语言问题,

方法是实际破坏Web应用系统，测试系统的反应压力测试是测试系统的限制和故障恢

复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃，崩溃以后会怎么样。

在Web应用系统性能测试过程中，常常将压力测试和负载测试结合起来。在负载测试的基

础上，增大负载最，直到系统崩溃实施性能测试需要注意测试工具灵活使用性能测试计划的

制定由于数据库安全性导致的Web应用系统安全性问题Access数据库文件被下载用户重要

信息没有经过加密而存于数据库中确认操作系统安全性，避免因操作系统漏洞导致Web应

用程序的安全性问题Web应用系统多采用登录的方式，产品发布时提供默认的管理员用户

名和密码确保应用系统实际应用中可修改默认管理员帐号和密码用户名和密码设置要求（长

度、大小写敏感、复杂度）允许错误登录的次数是否可以不登录而直接浏览某个页面保证口

志文件记录了Web应用系统的主要操作过程，并可根据日志文件追查到系统使用情况:同时

还需要保证日志文件本身的安全性、完整性，防止被入侵者删除、获得当Web应用系统采

用/SSL等加密技术之后，需要确认加密、解密后信息传递的正确性和完整性需要确认Web

应用系统是否有超时设置，如有，则保证在超时设置时间内，如果未操作Web应用系统，

当再次访问系统，需要重新登录了解安全漏洞信息，避免Web应用系统中出现的漏洞被入

侵者利用;及时升级补丁程序，提高系统安全性Web应用系统多采用分布式体系结构，服务

器端通常包括Web服务器组件、数据库服务器组件等。

三十五、请针对分布式搜索系统谈谈该系统还需从哪些方面展开性能测试。

观察前端应用的返回结果。这里需要分两种情况来考虑：第一，按照前端应用业务功

能点及流程进行操作，观察返回结果是否符合业务方的需求预期；第二，操作后端的服务器

（通常是重启、宕机、断网等操作），观察前端应用的返I可结果是否符合系统的设计需求。

分析服务器日志。在功能测试过程中，当我们在启动服务器的时候，需要将日志级别定

义为Debug级别（最低级别）。

分析操作系统的一些重要信息。我们测试的分布式系统绝大多数是基于Linux操作系统

开发的，在测试的过程中，除了详细分析程序口志以外，还需要对操作系统的一些重要数据

信息进行分析，从而来诊断服务器程序是否存在异常。

借助其他分析工具。例如，如何判断服务器程序是否产生了内存泄漏？通常需要借助于

内存检测工具来进行分析，在Linux环境下，我们常用Valgrind来进行内存检测。

数据准备。如何准备海量的测试数据并保证模拟数据的真实性？以•个分布式的文件系

统为例，预先存入100GB的数据还是存入100TB的数据、存入的文件是大小基本一致差别

不大还是各不相同甚至差异很大（例如，从几十字节至儿十兆字节不等），这些因素对于分

布式系统的性能影响是有很大差异的。

性能或压力测试工具。通常来说，分布式系统的测试需要开发一些测试工具来满足性能

测试的需求。如果可以的话，建议这样的测试工具最好由测试工程师自己来实现，因为测试

工程师更清楚自己的测试需求。

涉及平台多且硬件杂，测试流程控制困难。在实施自动化测试的过程中，测试脚本需

要控制的操作系统和应用程序很多，而且存在跨平台的特性，同时还有可能需要控制一些网

络设备。

测试结果验证复杂。对于分布式系统的自动化测试又说，我们需要通过测试脚本来收集

各种测试结果数据以验证测试结果的正确性。在实施自动化测试的过程中，我们可以将测试

结果数据收集部分模块化，通过各子模块来检测各项数据是否正确。

第8章集成测试

三十六、什么是集成测试？

集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求

（如根据结构图）组装成为子系统或系统，进行集成测试。

实践表明，i些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。--

些局部反映不出来的问题，在全局上很可能暴露出来。

集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它最简单的形式是：把

两个已经测试过的单元组合成一个组件，测试它们之间的接口。从这一层意义上讲，组件是

指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合为程序的

更大部分。方法是测试片段的组合，并最终扩展成进程，将模块与其他组的模块一起测试。

最后，将构成进程的所有模块•起测试。此外，如果程序由多个进程组成，应该成对测试它

们，而不是同时测试所有进程。

集成测试是单元测试的逻辑扩展。在现实方案中，集成是指多个单元的聚合，许多单元

组合成模块，而这些模块又聚合成程序的更大部分，如分系统或系统。集成测试采用的方法

是测试软件单元的组合能否正常工作，以及与其他组的模块能否集成起来工作。最后，还要

测试构成系统的所有模块组合能否正常工作。集成测试所持的主要标准是《软件概要设计规

格说明》，任何不符合该说明的程序模块行为都应该加以记载并上报。

三十七、集成测试与单元测试有何区别？

・测试对象不同。单元测试对象是实现了具体功能的程序单元:集成测试对象是概要设

计规划中的模块及模块间的组合。

・测试方法不同。单元测试中的主要方法是基丁•代码的白盒测试:集成测试中主要使用

基于功能的黑盒测试。

•测试时间不同。集成测试晚于单元测试。

・测试内容不同。单元测试主要是模块内程序的逻粗、功能、参数传递、变量引用、出

错处理及需求和设计中具体耍求方面的测试:集成测试主耍验证各个接口、接口之间的数据

传递关系，及模块组合后能否达到预期效果。

三十八、如何评价某种集成测试方法？

1）集成测试就是在单元测试的基础上，将所有已通过单元测试的模块按照概要设计的要

求组装为子系统或系统，并进行测试的过程，目的是确保各单元模块组合在一起后能够按既定

意图协作运行，并确保增量的行为正确。

2）从四个方面对集成测试策略进行评价：

测试用例的规模

驱动模块的设计

桩模块的设计

缺陷的定位

三十九、成对集成与邻居集成的基本思想是怎样的?有何特点？

成对集成的基本思想是将每个集成测试用例限定在一对调用单元上，每个集成测试用例

都是最小的集成单元，仅涉及一对调用的接口。这样做最大的好处就是使得缺陷非常容易定

位，一旦某个集成测试用例失败，可以肯定地说，一定是该用例涉及的这一对模块的接口有

问题。

邻居集成的基本思想是将每个集成测试用例限定在某个节点的邻居上，针对某个模块的

集成测试用例应同时包含该模块及其邻居。所谓邻居，是对应某个模块的一个特定邻域模块

集合，它包括指定的某个模块、所有直接调用该模块的上层模块以及所有被该模块直接调用

的下层模块。

邻居的构成有两种方式：

(I)处于中间层的模块。每个处于调用图中间层的模块既有上层调用模块，又有下层被

调用模块，自然形成一组邻居，构成一个集成测试用例。

(2)根节点直接调用叶子节点。当根节点模块直接调用叶子节点模块时，根模块与所有

被它直接调用的叶子模块共同形成一组邻居，构成一个集成测试用例。

四十、请比较大爆炸集成、自顶向下、自底向上和三明治集成策略。

大爆炸集成(BigBangj是将所有经过单元测试的模块一次性组装到被测系统中进行测试,

完全不考虑模块之间的依赖性和可能的风险。

大爆炸集成就是将所有7个模块放在一起进行测试，即仅需一个测试用例，达到用例规

模的最小化。同时，由于该测试一次性包含了所有模块，无须开发桩和驱动模块。显而易见

的弊端是直接导致缺陷定位异常困难。一旦用例失败，完全不知道是哪对模块的调用接口出

了问题。特别地，即使被测系统能够一次性集成成功，也会有许多接口缺陷逃过测试而进入

系统测试，给系统测试带来不良影响，大大增加系统测试的负担。

大爆炸集成违反了测试从小范围到大范围展开的基本原则，一般情况下不采用这种集成

方式，仅在涉及模块和接口数最不多的情况下使用