1、1第 1 章 软件测试的基本概念1、什么是软件测试？软件测试的定义(IEEE1983):是使用人工和自动手段来运行或测试某个系统的过程，目的在于检验其是否满足规定的需要或是弄清楚预期结果与实际结果之间的差别。2、什么是软件缺陷？软件缺陷的定义(IEEE1983):从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题。从产品外部看，软件缺陷是系统所需实现的某种功能的失效或违背。3、什么是测试用例？测试用例的定义(IEEE1990):是一组测试输入、执行条件和预期结果，目的是要满足一个特定的目标，比如执行一条特定的程序路径或检验是否符合一个特定的需求。4没有安装操作系统的裸
2、机中有软件吗?有软件。在主板上的 CMOS 芯片中嵌入了 BIOS 程序，可以看做是一个简单的嵌入式软件。5软件测试就是通过运行程序来查看错误。对吗?错。软件测试不仅包括动态测试，还包括静态的检查。测试的对象不仅针对查程序，还需要针对文档。6软件产品发布给用户之后发现了缺陷，将导致怎样的后果?软件产品发布给用户之后，若由用户发现了缺陷，则视缺陷的严重程度和影响范围，导致的后果不同。若导致用户系统崩溃、严重数据丢失、巨大的经济损失，甚至造成人身伤害，则对公司的影响很大。若只是造成用户使用不便，则其产品可能遭到用户的抛弃或投诉。7手机测试是硬件测试，还是软件测试?既是硬件测试，又是软件测试。针对手
3、机外壳、抗摔、防水等方面的测试是硬件测试，针对手机的通话质量、短信、游戏等方面的测试属于软件测试。8为什么说软件的需求规格说明书往往是软件缺陷的最大来源?其结论对软件测试工作有何启发?需求规格说明是通过需求分析得到，需求的变动，需求本身描述的不一致、不正确、不完整将导致设计的变更和设计的缺陷，并进一步影响编码的正确性。因此，导致软件与预期结果的偏差越来越大。9请仿照 NextDate 问题，针对 PrevDate 问题设计测试用例。PrevDate 问题的功能简述如下。当用户输入有效日期时(从 1800 年 1 月 1 日到 2050 年 12 月 31 日之间的所有日期)，系统将自动计算出前
4、一天的日期，否则，系统不执行日期的计算，并给出消息提示输入无效。210请仿照 NextDate 问题，针对 NextMultiDate 问题设计测试用例。NextMultiDate 问题的功能简述如下。若用户输入有效日期(从 1800 年 1 月 1 日到 2050 年 12 月 31 日之间的所有日期)，并指定延迟的天数(最多不超过 366 天)，假设为 n，则系统将自动计算出从有效日期往后 n 天的日期。对于无效日期或无效延迟天数，系统不执行日期的计算，并给出消息提示输入无效。311若需要对多个测试用例进行管理，除了 ID、输入和输出之外，需针对每个测试用例补充哪些信息?测试用例的构成：I
5、D、 、项目/软件、程序版本、编制人/编制时间、功能模块、测试项、测试目的、预置条件、参考文献、测试环境、测试输入、操作步骤、预期结果、执行结果、优先级、测试用例之间的关联。12请针对 145 节 NextDate 问题的第二次测试中所给出的测试用例，补充测试环境。NextDate 的测试环境应根据实际的开发和使用环境而定， 从软件使用环境、 开发平台等角度考虑即可。13请针对第 6 题的 PrevDate 问题，补充测试环境。同上题。第 2 章 软件测试原理1、对待缺陷我们应遵循哪些基本原则?对待缺陷的基本原则：缺陷的群集现象、缺陷有免疫力(测试要使用不同的测试方法 )、缺陷关联和依赖（单纯
6、依赖、多重依赖、复合依赖） 。2、当受到进度压力的时候，是优先进行黑盒测试还是白盒测试?应优先进行黑盒测试，因为黑盒测试不需要了解程序实现的细节，通过黑盒测试至少可以证明：被测软件系统可以完成哪些功能，哪些功能不能正确的实现，哪些功能甚至完全没有实现。3、针对同样的问题(例如相同的代码段)，采用黑盒测试与白盒测试方法得到的测试用例会有很多是重复的，那么，白盒测试有意义吗?白盒测试有重要的意义，它主要是覆盖黑盒测试方法检查不到或难以发现的某项缺陷，白盒测试指标还可以充当对黑盒测试方法效果的检查，判断测试是否存在漏洞或冗余。4、静态测试不需要执行程序，那么，是否可以用静态测试替代动态测试呢?不可以
7、。静态测试与动态测试之间即具有一定的协同性，同时又具有相对的独立性。程序静态分析的目标不是证明程序完全正确，而是作为动态测试的补充，在程序运行前尽可能多地发现代码中隐含的缺陷。5、良好的单元测试是否可以替代集成测试?不能。良好的单元测试只能确保通过测试的单元内部基本可以正常工作，但不能保证单元集成在一起之后，能够正常工作，特别要关注可能存在误差累积的情况。在单元测试与集成测试的关系中，即使保证每个单个的单元具有优秀性能，也不能确保整体的性能。6、自动化测试工具可以让繁重的手工劳动变得轻松，那么，我们还有必要做手工测试吗?自动化测试目前不可能完全替代手工测试，一方面是由于自动化测试工具的适用面都
8、相对较窄，一种测试工具往往仅能处理很小一方面的测试问题，另外，有些测试活动需要重复发挥人的创造力，采用自动化测试工具不可能收到同样的效果。7、只要学会某种时下流行的自动化测试工具的使用，就可以轻松搞定测试工作了，是这样吗?不管是什么测试工具，它实质反映的是其背后的测试思想，因此，抛开测试方法去学习测试工具的使用，是没有任何意义的。而且，测试工具使用的前提是必须有测试用例为指导，得到的测试脚本才具有复用性，而测试用例的设计涉及多种测试方法。因此，完全不懂测试技术是不能胜任软件测试岗位的。8、什么是冒烟测试?如何实施?冒烟测试是通过简单测试来判断系统基本功能（通常是核心业务模块）的覆盖率如何，而不
9、验证正确性。例如能否正确安装/卸载，主要功能是否实现，是否存在严重死机或数据严重丢失等缺陷。冒烟测试工作一般需要实现自动化，可以借助诸如 WinRunner、QTP 这样的工具来录制自动化测试脚本，脚本由专人维护，且随着测试的进展对脚本不断进行增补。9、随机测试就是随便测试，往往会取得意想不到的效果，因此，我们应在软件开发过程中广泛使用随机测试。是这样吗?4不能这样。随机测试是没有测试用例的，且往往是不可重复的。这对缺陷的重现十分不利，且广泛采用随机测试将不能保证测试的全面性，无法了解测试的整体效果。若在软考开发过程中广泛使用，可以表明测试过程是混乱的，缺乏管理的，则最终提交的软件产品质量是完
10、全无法保证的。10、在任何情况下，我们执行回归测试时，都应将以前测试过的用例全部执行一遍，是这样吗?不是这样的。回归测试是贯穿在整个测试的各个阶段的一个测试活动，主要是对修改过的软件重新进行测试，目的是为了验证修改的正确性及其影响。回归测试包的选择应根据进度、风险、修改情况等全盘考虑。11、我们该如何应用各种测试过程模型？12、软件测试的目的是证明程序可以工作。软件测试的目的是证伪。这两种说法哪个正确?两种说法都正确，但有存在片面性，应视不同的情况予以应用。13、对比软件测试工程师的素质要求，你认为自己可以胜任软件测试工程师的岗位吗?软件测试工程师的素质要求：两项意识：服务意识、团队合作意识。
11、三颗“心”：耐心、细心、信心。四种能力：技术能力、沟通能力、逆向思维能力、移情能力。五个特性：实在幽默、十足记忆、时刻怀疑、十面督促、十分周全。第 3 章 黑盒测试技术1进行边界值测试时，为何要以边界点为中心，以一个单位长度作为邻域，而不是直接选择“1”为邻域?进行边界值测试时，当以一个单位长度为邻域时，邻域随着单位长度的变化而改变。若研究的粒度较精细，可选择更小的邻域，而若边界粒度较粗，则应适当增加单位长度，扩大边界的邻域范围。单位长度可方便地调节边界值测试的邻域。若直接选择“1”为邻域，则有时会造成边界影响面太小，导致遗漏缺陷。2边界值测试中所选择的输入测试数据一定是有效数据。是这样吗?不
12、一定。边界值测试仅关注边界，设计测试用例时不区分系统输入在边界点上是否有效。因此，系统输入在边界点上可能是有效的，也可能是无效的。3边界值测试中，若考虑边界的组合情况，即缺陷出现在多个输入条件的边界或边界附近，则称这样的策略为最坏情况测试。若给出两个输入条件 x,y，其中条件 x 具有 3 个极值点(x1，x2，x3)，条件 y 具有2 个极值点(yl，y2)，如图 3-1 所示。请采用最坏情况测试方法，导出测试用例的数目，并设计相应的测试用例。最坏情况测试方法相当于在基本边界值分析的基础上，考虑 x,y 条件同时取得边界，所以图 1 中矩形5框的边界和边界附近都应取到测试用例。测试用例如图
13、3-1 所示。测试用例数目为 4742 7143。674对于 328 节的 Commission 问题，请采用基本边界值分析方法，从输入域设计测试用例。从输入域采用基本的边界值分析，得到测试用例集合见表 3-2。表中预期输出是指销售员的总提成。表 3-2 输入域的基本边界值分析测试用例（Commission 问题）5对于 328 节的 Commission 问题，请分析案例实践二(见本书光盘部分的图 31)中所有边界点是如何得到的。各种酒的单价为：白酒 168 元/瓶，红酒 120 元/瓶，啤酒 5 元/瓶。各销售员每月至少需售出白酒 50瓶，红酒 30 瓶，啤酒 300 瓶。由此得到最低销售
14、额：1.35 万元，对应最小边界点。每个销售员的月供最高为白酒 5000 瓶，红酒 3000 瓶，啤酒 30000 瓶，由此得到最高销售额：135 万元，对应最大边界点。销售员的提成公式中，发生提成比例变化的点为：2 万元和 4.5 万元，由此得到中间的两个边界点。6当时间有限时，应优先针对输入域进行边界值测试，还是针对输出域分析边界?为什么？当时间有限时，应优先从输入域考虑边界值测试。因为系统总是根据输入情况来决定如何进行输出响应。且输出域的边界值测试用例与输入域的测试用例有很多重复的情况。因此，一般情况下，先对输入域展开测试，然后根据输出域的特殊性，补充更多边界测试用例。7如何才能方便、快
15、捷地了解划分出的等价类是否能够体现真正的等价呢?有两种途径：第一种方式是正向判断法。即从正向观察系统是输入和输出，在划分得到的等价类中随便选择几个数据，并从如下方面来观察：这些数据是否包含相同的输入条件。这些数据是否导致程序执行类似的处理。这些数据是否影响相同的输出结果。这些数据要么都让软件执行错误处理，要么都不让。若以上方面中任何一方面不成立，则等价类划分肯定有问题。第二种方法是结合决策表方法，若从该等价类划分无法得到精确无误的决策表，则说明该等价类划分是不“等价”的。8为什么对无效等价类设计测试用例时要采取一一对应原则，这对测试有何好处?设计测试用例时，采取一一对应原则的含义是每个测试用例
16、唯一覆盖一个无效等价类，这样的处理方式有利于缺陷的定位。一旦某个测试用例失败，我们可以很方便地了解，系统对于哪个输入条件的哪个无效等价类无法适当予以处理。89案例实践三的 NextDate 实例中，测试用例 ND-EP-001 到 ND-EP-007(见本书光盘)可以很好地考查系统的容错能力，但从满足用户需求的角度而言，这个测试用例的集合违反了实际工作中的一些基本原则，是哪些原则呢?在实际的测试工作中，我们总是优先满足系统的基本功能，即优先测试系统的基本功能，看是否能够正确实现，在测试用例上数目也会更多一些。而在本例中仅有一个测试用例去测试基本功能，却有 6 个测试用例考查系统的容错能力，这是
17、不合适的。另外，测试应尽量避免漏洞，而不怕冗余，本例中只有一个针对正常数据的测试用例，由此导致的测试漏洞是很大的，因此也违反了测试应避免漏洞的基本原则。10、对于 NextDate 问题，若将 2000 年从闰年有效等价类中分离出来，其余两输入条件的划分方式参照338 节的第二次等价类划分尝试(见本书光盘部分的表 39)。请采用弱组合和强组合方式分别设计等价类测试的测试用例。此时的等价类划分如表 3-3 所示。若采用弱组合形式进行等价类测试，得到的一组测试用例构成和最终的用例集合分别如表 3-4 和表 3-5 所示。若采用强组合形式的等价类测试，则可得到 45（335）个测试用例，具体的用例设
18、计方法参见表3.14。不再一一列出。11、对于 328 节的 Commission 问题，请针对输入域展开等价类测试。针对 Commission 问题，对输入条件的上、下限构成的边界范围可自然形成一个有效等价类，所以采用等9价类测试，只有一个测试用例。等价类划分见表 3-6，测试用例见表 3-7。表中预期输出是指销售商的总提成。表 3-6 输入域的等价类划分（Commission 问题）表 3-7 输入域的等价类测试用例（ Commission 问题）12、对于如下的枪支销售问题(简称 Sales 问题)，分别从输入域和输出域着手，进行边界值测试和等价类测试。Sales 问题的简单描述如下。某
19、步枪销售商负责销售某军火制造商生产的步枪，包括枪机(Lock)、枪托(Stock)和枪管(Barrel)。其中枪机、枪托和枪管的单价分别为 45 美元、30 美元和 25 美元。销售商每月至少应卖出一支完整的步枪，同时，销售商每月最多只允许销售 70 个枪机、80 个枪托和 90 个枪管。该销售商的提成每月结算一次。根据其销售业绩，制造商按如下计算方式来计算销售商的提成。销售额不足(含)1000 美元的部分，提成比例为 10。销售额在 1000 美元(不含)到 1800 美元(含)之间的部分，提成比例为 15。超过 1800 美元(不含)的部分，提成比例为 20。最终输出为当月销售报告和销售商
20、的总提成。三个输入条件为：枪机、枪托和枪管的销售量。针对输入域展开边界值测试，则枪机的边界点为 1 和70，枪托边界点为 1 和 80，枪管边界点为 1 和 90。基本边界值分析的测试用例集合见表 3-8。针对输出域展开边界值测试，以销售额为输出，得到测试用例集合见表 3-9。表中预期输出是指销售商的总提成。表 3-8 Sales 问题的边界值测试的测试用例（针对输入域）表 3-9 Sales 问题的边界值测试的补充测试用例（ 针对输出域）10针对输入域的等价类划分见表 3-10。针对输入域的等价类测试用例（强组合形式）见表 3-11。表 3-10 输入域的等价类划分（Sales 问题）表 3
21、-11 输入域的等价类测试用例 （Sales 问题）针对输出域的等价类划分见表 3-12，对应等价类测试用例见表 3-13。表 3-12 输出域的等价类划分（Sales 问题，单位：美元）表 3-13 输出域的等价类测试用例（Sales 问题）13、对 356 节的 NextDate 问题进行第一次决策表尝试时，为何所得决策表中会输出不确定的测试用例?该决策表中打问号的测试用例反映出系统对输入的不确定无法处理，输入的含义是：对于任意年份，月份是每月有 31 天的月份，日期是 31 号，这时存在一个年末日期的问题，对于 12 月 31 日，系统输出应为次年的 1 月 1 日，而对于其他月份（如
22、7 月 31 日） ，系统输出应为下月 1 日（如 8 月 1 日） ，因此，系统无法针对相同的输入等价类给出明确的输出。这时应将月份的等价类进一步划分下去。14、请仿照 NextDate 问题，针对 PrevDate 问题使用边界值、等价类和决策表方法展开测试。PrevDate 问题中特殊的日期包括：年初日（即每年的 1 月 1 日） 、月初日（即每月 1 日）和闰年情况（即 3 月 1 日） 。PrevDate 问题包括三个输入条件：年份、月份、日。边界点分别为：11年份：1800 年，2050 年月份：1 月，12 月日：1 号，31 号根据这些边界点，使用基本边界值分析方法进行边界值测
23、试，与 NextDate 问题的分析方法完全相同，所以得到的测试用例也非常相似（输入完全相同，预期输出不同而已） 。等价类划分如表 3-14 所示，得到决策表见表 3-15，采用决策表得到的测试用例见表 3-16。表 3-14 PrevDate 问题的等价类划分表 3-15 PrevDate 问题的决策表表 3-16 PrevDate 问题的测试用例集合1215、根据 375 节的规则(详见本书光盘)，检查测试用例表 324 发现输入条件“账面余额”未取到“I”，说明测试用例有漏洞，而表 324 中又显示测试用例覆盖了所有五个场景，为什么会出现这种相互矛盾的情况?是规则有错，还是别的什么原因呢
24、?对于备选流 4 的含义是：输入金额校验失败，这里有很多情况可以导致金额校验失败，如输入金额格式错误、账面余额不足等，表 3.24 的测试用例 ATM-ST-006 的触发事件是输入金额格式错误的情况，而未测试账面余额不足的情况，所以输入条件“账面余额”未取到“I” 。这里并不矛盾，因为表 3.24 中的第2 列是从较粗的粒度来考查用例覆盖的，而设计测试用例时若需要覆盖备选流 4，却需要从细节来考虑，所以出现了不一致的情况。第 4 章 白盒测试技术1、对于 4.2.2 节中的函数 FuncSC，随着三个布尔变量取值的不同，在特殊的取值组合条件下，程序的输出与输入是不相等的。请问在什么条件下，该
25、函数的输出不等于输入?当函数 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 这三个测试用例中，哪个测试效果相对更好?在同时满足覆盖指标的前提下，应从判定表达
26、式的屏蔽效应以及边界值测试的角度判断测试数据选择的好坏。为执行路径 L13，两判定节点都应取假值，为了避免判断表达式的屏蔽现象，必须保证 T1 为真（即(a1)为真） ，测试用例 LC-004 显然不满足该要求。另外，应保证 T4 为假（即(x3)为假） ，考虑到 3是 x 取值的边界，因此，应针对边界值来选择测试数据，所以 LC-005 更优于 LC-003。总体看来 LC-005是三个测试用例中最优的一个。134、4.2.5 节中，按照函数 Func6Modified 将复杂逻辑表达式拆分为简单的表达式之后，请设计两个测试用例来满足判定覆盖。设计的测试用例见表 4-1。表 4-1 函数 F
27、unc6Modified 的测试用例集合（满足判定覆盖）5、给定以下代码，请利用逻辑覆盖的各项覆盖指标分别设计测试用例。列出真值表如表 4-2 所示。表 4-2 真值表对于语句覆盖和判定覆盖，选择测试用例 005 和 006。条件覆盖，选择测试用例 004 和 005。判定/条件覆盖，选择测试用例 004 和 005。条件组合覆盖，选择所有。修正的判定/条件覆盖，选择测试用例 003、005、006、007。6、当判定表达式具有三个简单逻辑判断条件时，所有可能构成的表达式形式如题表 4.1 所示，请针对下表中的四种组合情况，分别采用修正的判定/条件覆盖指标设计测试用例。14题表 4.1 三个简
28、单逻辑判断条件构成的所有可能的判定表达式根据题目中给出的真值表，采用唯一原因法得到各条件的独立影响对如表 4-3 所示。因此得到满足不同表达式的修正判定/条件覆盖的测试用例集合分别见表 4-3。表 4-3 不同复合表达式的条件独立影响对7、请针对扩展的 Trgl 问题展开基路径测试。Trgl 问题描述为：给定三角形的三条边长，分别为 a、b 和 c，且边长均为整数，要求根据三条边长的关系输出：不构成三角形、不等边三角形、等腰但不等边三角形或等边三角形，具体的程序代码如下。15考虑到不可行路径，最终测试 4 条路径：Path1：1,3,4,7,8,9,EndPath2：1,3,4,7,8,10,
29、11,EndPath3：1,3,4,7,8,12,13,EndPath4：1,3,5,6,7,15,16,End得到测试用例见表 4-4。且应考虑到输入的各种组合，所以给出了更多的测试用例。表 4-4 三角形问题测试用例集合8、请针对以下的 Commission 代码进行基路径测试该 CommissionModify 函数只有 3 条路径。若用 A 表示 1,2,3,4,5 号语句，则有Path1：A,6,7,12,13Path2：A,6,8,9,12,13Path3：A,6,10,11,12,13这其实已经等同于等价类测试+边界值测试了。测试用例不再列出。16第 5 章 面向对象软件测试1、
30、所有类都需要进行单元测试吗?并非所有类都需要进行单元测试，类的优先级可从三方面来衡量：类在系统中所起的作用类自身的复杂度和与其他类之间的交互复杂度 开发该类的测试程序所需的成本2、私有方法可以测试吗?私有方法可以测试，测试方法有：直接修改被测代码的访问权限在被测类中加入公有方法利用内类机制3、对于一个类而言，测试用例设计的一般策略是怎样的?面向对象的单元测试一般策略：首先根据方法特性划分：构造函数、功能函数和接口函数。针对构造函数，根据前置和后置条件设计用例。针对功能函数公有方法：基于前置条件和后置条件设计测试用例。受保护的方法：严格区分有访问权限和无访问权限的前置条件和后置条件，设计测试用例
31、。私有方法：根据实际情况选用适当的策略进行测试。针对接口函数，根据状态转换设计测试用例。对于以上每种情况，都应结合边界值、等价类等测试方法来选择测试数据。、将测试代码直接写在被测类的代码中即可，对吗?可以将测试代码直接写在被测类的代码中，但这不利于开发代码与测试代码的分开，不 利于后续测试代码的维护和开发产品的交付。5、抽象类无法实例化，所以不能测试，对吗?抽象类虽然无法实例化，但可以通过以测试类的内类继承方式来测试，是可以的。6、顺序图和协作图可用作面向对象的单元测试，对吗?顺序图和协作图适用于面向对象的集成测试。第 6 章 单元测试、良好的单元测试是否能够代替集成测试?若每个模块都经过了严
32、格的单元测试，还需要集成测试。我们在测试过程中经常遇到的情况是：单元测试中每个模块都能单独工作，但将这些模块集成在一起之后，某些模块就不能正常工作了。例如，接口数据丢失，模块之间的不良影响，误差的不断累积等。因此，单元测试无法代替集成测试，每个模块的性能最优并不能保证集成之后的指标达到最优。、什么是驱动模块?什么是桩模块?为什么需要驱动模块和桩模块?驱动模块是模拟被测单元的上级模块，用于接收测试数据、启动被测模块和输出结果。桩模块是模拟被测单元所调用的模块。测试时需要通过驱动模块和桩模块搭建单元测试环境。、单元测试的过程是怎样的?单元测试的过程可划分三个阶段：计划阶段：完成单元测试计划，制定单
33、元测试策略。设计实现阶段：建立单元测试环境，完成测试设计和开发。17执行评估阶段：执行单元测试用例，记录和评估测试结果。、为第 4 章白盒测试中的 Commission 问题进行单元测试。、针对第 3 章的思考题 14（PrevDate 问题） ，写出程序代码，并进行单元测试。第 章 集成测试、什么是集成测试?集成测试是在单元测试的基础上，将所有已通过单元测试的模块按照概要设计的要求组装为子系统或系统，进行集成测试，目的是确保各单元模块组合在一起后能够按既定意图协作运行，并确保增量的行为正确。 、集成测试与单元测试的区别在哪里?与单元测试的区别：单元测试关注模块内部，集成测试关注模块接口；单元
34、测试也关注模块接口，但它从内部查看接口，从个数、属性、量纲和顺序等方面查看输入的实参与形参的匹配情况。集成测试查看接口时主要关注穿越接口的数据、信息是否正确，是否会丢失。单元测试主要依据是详细设计说明书，集成测试的主要依据是概要说明书。、集成测试与系统测试的区别在哪里?与系统测试的区别：集成测试仅针对软件系统展开测试，系统测试中所涉及的系统则不仅包括被测试的软件本身，还包括硬件及相关外围设备。集成测试的主要依据是概要说明书，系统测试的主要依据是需求规格说明书及行业标准。、如何评价某种集成测试方法?集成测试策略的评价标准：测试用例的规模驱动模块的设计桩模块的设计缺陷定位的难易程度、成对集成与邻居
35、集成各自的思想是怎样的?有何特点?成对集成基本思想：将每个集成测试用例限定在一对调用单元上。特点是仍需要开发桩模块和驱动模块。邻居集成基本思想：将每个集成测试用例限定在某个节点的邻居（直接调用或被调用的模块）上。特点是：可以减少桩模块和驱动模块的开发工作量，但缺陷定位困难。、请比较大爆炸集成、自顶向下、自底向上和三明治集成策略。大爆炸集成基本思想：将所有经过单元测试的模块一次性组装到被测系统中进行测试，完全不考虑模块之间的依赖性和可能的风险。自顶向下集成的基本思想：从主控模块（主程序，即根节点）开始，按照系统程序结构，沿着控制层次从上而下，逐渐将各模块组装起来。 自底向上集成的基本思想：从最底
36、层模块（即叶子节点）开始，按照调用图的结构，从下而上，逐层将各模块组装起来。 三明治集成的基本思想：策略 1：将系统划分为三层，中间层为目标层，测试时对目标层上面的层使用自顶向下的集成策略，对目标层下面的层使用自底向上的集成策略。 策略 2：在第 1 种集成策略的基础上，对目标层采用独立测试的策略，以确保目标层模块在集成测试之前得到充分的测试。18策略 3：对包含读操作（系统输入）的子系统自底向上集成测试直至根节点，然后对包含写操作（系统输出）的子系统自顶向下集成测试直至叶子节点。 、集成测试的一般过程是怎样的，与单元测试的过程有何区别?集成测试的过程可划分三个阶段：计划阶段：完成集成测试计划
37、，制定集成测试策略。设计实现阶段：建立集成测试环境，完成测试设计和开发。执行评估阶段：执行集成测试用例，记录和评估测试结果。单元测试的过程可划分三个阶段：计划阶段：完成单元测试计划，制定单元测试策略。设计实现阶段：建立单元测试环境，完成测试设计和开发。执行评估阶段：执行单元测试用例，记录和评估测试结果。第 章 系统测试、系统测试与单元测试和集成测试的区别是什么?系统测试的最终目的是保证开发方交付给用户的软件产品能够满足用户的需求，因此，测试的测试用例应在实际的用户使用环境下来执行，系统测试是涉及软件、硬件、网络方面因素的过程。这是系统测试与集成测试、单元测试最大的不同之处。、功能测试与界面测试
38、有何区别?界面测试应与功能测试区分开来，界面测试中不应涉及具体的逻辑功能实现，只是关于布局、字体、风格等有关界面上的一些问题。且在界面测试过程中，我们可以通过创建界面测试检查单的方式来简化测试用例，简化测试过程。、请为某图书馆信息管理系统设计功能测试策略。功能测试的策略因不同类型系统差异较大。图书馆信息管理系统是一个以数据为中心的系统，可以从两个方面考虑展开功能测试，即从实体关系模型来考虑和从对数据的操作来考虑。从实体关系模型来考虑，检查实体之间的对应关系和逻辑关系，包括 1 对 1、1 对多、多对 1、多对多；从对数据的操作来考虑，检查各种操作是否能正常实现，包括增加、删除、查找、修改。、请
39、为从 ATM 机系统设计功能测试策略。以活动序列为中心的系统可基于以下策略进行功能测试：基于系统输入的测试用例设计 、基于系统输出的测试用例设计、基于系统状态的测试用例设计、基于系统事件的测试用例设计。、压力测试和负载测试有何区别?压力测试指持续不断地给被测系统增加压力，直到被测系统被压垮，从而确定系统能承受的最大压力。（强调施加压力的大小）负载测试指让被测系统在其能忍受的压力极限范围内（或临界状态下）连续运行，来测试系统的稳定性。 （侧重压力持续的时间）、兼容性测试需要考虑哪几方面的内容?兼容性测试的内容包括与硬件兼容、与其他软件平台和应用程序兼容、数据共享。、安装软件的一般流程是怎样的?1
40、9执 行 启 动 程 序检 测 到 以 前 版 本 ？是 否选 择 目 标 路 径选 择 安 装 选 项开 始 安 装是 否 重 启 ？是 否退 出 启 动 程 序并 手 工 重 启完 成 其 他 遗 留的 安 装 任 务结 束 安 装第 9 章 测试用例的组织和管理1、测试用例为什么需要管理?因为测试用例是软件测试的核心和本质，它需要具有组织性、重复性、跟踪性、客观性，良好的测试用例管理和跟踪是良好测试质量的保障。2、测试用例有几种形式的模板?各有什么特点?严格来讲，有无数多种形式的模板， 任何公司都将根据自己的实际情况来确定测试用例模板。如Word、Excel、IEEE829 标准和 Bu
41、gFree 工具模板。3、如何划分测试用例的优先级?在大部分情况下，可能发现的缺陷的严重性越高，对应的测试用例就越重要，其优先级也越高。根据这一假设，我们可将测试用例分为四个基本等级。冒烟测试：在正式测试之前进行的测试工作，冒烟测试中选择的测试用例能测试到被测软件的核心功能或新增功能。高：最常执行的测试用例集合，这些测试用例可以保证功能稳定，系统可以正常工作，并包含对重要边界的测试。中：一般需要执行的测试用例集合，这些测试用例可使得功能区域或功能更加详细。低：通常最少执行的测试用例。低优先级并非意味着这些测试不重要，只是这些用例在项目生存周期内并非反复地运行而已，例如用户界面、错误提示信息、性
42、能测试等。这四个等级可以作为测试用例的初始优先级，之后基于质量目标和项目需求再对初始优先级进行提升或降级。4、测试用例组织和管理的一般步骤是怎样的?基本步骤：整理模块需求撰写测试计划设计测试思路编写测试用例评审测试用例（内部和外部评审）修改更新测试用例（给出变更记录或版本升级）执行测试用例分析评估测试用例质量，包括测试用例的设计质量、测试用例的执行情况。205、测试用例的评审有几种形式?有效的测试用例评审一般分为两种形式：测试部门内部的评审、测试部门外部的评审。6、测试用例应写得越详细越好，是这样吗?测试用例设计并非越详细越好。测试用例的执行人员是测试用例的设计者，或对被测软件非常熟悉，则测试
43、用例不必描述太详细；测试用例的执行人员是刚入公司的新人，或将测试外包给第三方，则测试用例的描述应尽量详细；设计测试用例时，应关注核心功能、高风险功能，且应满足合理的覆盖指标。7、测试用例的设计可以一次性完成吗?不行，而是应该随软件版本的变化而及时修改和更新。第 10 章 缺陷管理1所有缺陷都可以重现吗?并非所有缺陷都可重现。有些缺陷是具有累积效应的，由长期积累而形成。有些缺陷涉及对日期等的处理，只有当满足特殊条件的日期出现时，才会触发缺陷。有些缺陷仅在第一次运行的时候才出现，其余时候都运行正常。有些缺陷会导致恶劣的影响，以至于系统崩溃、数据丢失等，此时由于破坏了初始环境或部分处理的数据，且因测
44、试前未及时备份，导致无法完全恢复原始状态。2严重性高的缺陷，其处理优先级一定也高吗?严重性与优先级的关系并非绝对对应，高严重性，可能低优先级，低严重性，可能高优先级。3有效缺陷不一定能够得到修复，无效缺陷也不一定得不到修复。为什么这样说?当一个缺陷被暂缓处理之后，有可能因为管理的原因而忘记修复，而有些不可重现的缺陷往往是由于测试人员的步骤描述不清而导致，当步骤清晰之后缺陷是可以重现的，于是该缺陷可能会很快得到修复。4缺陷的状态和处理方式有何区别?缺陷状态是指缺陷在整个生命周期中所处的状态，这些状态定义了不同角色的人对缺陷的处理方式，典型的状态包括打开（Open） 、指派（Assigned） 、
45、关闭（Close） 、重新打开（Reopen） 、激活（Active） 、已解决（Resolved） 。缺陷处理方式是指缺陷到达不同角色的人手中后，不同角色的人决定如何对缺陷处理，典型的处理方式包括已修复（Fixed） 、暂缓（Postponed 或 Later） 、外部原因（External 或 Onhold） 、不修复（Wontfix） 、重复的（Duplicate） 、不可重现（Notrepro） 、符合设计（Bydesign 或 Notabug） 。5缺陷报告中应包含哪些基本信息?缺陷报告核心：标题、操作步骤、隔离缺陷处理信息：ID、缺陷所在位置、版本号、严重性/优先级、是否可重现、缺
46、陷类型、相关缺陷、指派的修复人员、附件、个人注释。6缺陷必须由提交的人来关闭，是这样吗?一般情况下，缺陷应由提交的人来关闭。但在有些企业中，所有缺陷只能由测试经理来审核并关闭。7目前市面上有哪些常见的缺陷管理工具?商业软件 TestDerictor、开源软件 BugFree。8请以自己正在做的项目(可以是一些程序作业)为例，尝试用一款开源缺陷管理工具来对缺陷进行管理。第 11 章 自动化测试1自动化测试可以代替手工测试吗?自动化测试不可能完全替代手工测试，虽然自动化测试结合手工测试在时间、成本、质量、人际沟通等方面显示出巨大优势，但在以下方面并不适用：周期短的项目、定制型的项目、业务规则复杂的
47、项目、21硬件测试、易用性测试。2自动化测试比手工测试发现更多的新缺陷。是这样吗?自动化测试主要用在回归测试和系统测试中，目的是能够在短时间内准确、高效率地重复执行大量测试用例，自动化测试一般发现的都是旧的缺陷 ，它在发现新缺陷方面效果很差。3自动化测试一旦引入企业或项目组，可以立即缩短测试的进度。是这样吗?自动化测试刚引入的时候，会导致测试流程的改变、人员结构的变化、提高测试的风险，只有引入一段时间后，才有可能展现其巨大的优势。4自动化测试的一般过程是怎样的?自动化测试的一般过程（公司级）：公司从资金和管理上给予支持；成立专门的测试团队来建立自动化测试的流程和测试体系；将源代码从版本库中取出
48、、编译、集成、发布和自动化测试。 自动化测试的一般过程（团队级）：明确需求获取测试用例和脚本执行和分析脚本5目前市面上主流的测试工具有哪些，是哪些公司的产品?主流的测试工具：MI 公司：WinRunner, LoadRunner, TD, QTPRational 公司：Robot, PurifyPlus, TestManager, CQCompuware 公司：QARun, QALoad, DevPartner, QACenter, TrackRecord6请指出一款最好的测试工具。不存在最好的测试工具，每种工具都有其特长和局限性，应根据公司和项目组的实际需要来选择适合的测试工具。7只要花一个星期时间掌握了一种工具的使用，就可以到软件公司去找一份高级测试师的工作了，是这样吗?仅仅会使用测试工具的基本功能并不能成为测试专家，最重要的是具有测试方面的知识基础和实践经验的积累，测试工具离开了测试知识，离开测试用例的指导 ，是没有意义的。得到的测试脚本不具备可重用性，自动化测试将变成测试人员乃至整个项目组的负担。更多课程资料请到大学课程网 www.0206.cc 学习
