1、软件测试笔试必备之欧阳组创编选择题时间：2021.02.16创作：欧阳组1、 系统测试使用（C）技术, 主要测试被测应用的高级互操作性需求, 而无需考虑被测试应用的内部结构。A、 单元测试 B、 集成测试 C、 黑盒测试 D、白盒测试2、单元测试主要的测试技术不包括（B）。A、 白盒测试 B、 功能测试C、 静态测试 D、 以上都不是3、（A）的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。A、 系统测试 B、 集成测试C、 单元测试 D、 功能测试4、如果一个产品中次严重的缺陷基本完成修正并通过复测，这个阶段的成品是（A）。A、 Alpha版 B、Beta
2、版C、正版 D、以上都不是5、自底向上法需要写（A）。A、 驱动程序 B、 桩程序 C、驱动程序和桩程序D、 .以上都不是6、测试ATM取款功能，已知取款数只能输入正整数，每次取款数要求是100的倍数且不能大于500，下面哪个是正确的无效等价类（C）A、（0，100）、（100，200）、（200，300）、（300，400）、（400，500）、（500，+）;B、（500，+）C、（500，+）、任意大于0小于500的非100倍数的整数；D、（-，100）、（100，200）、（200，300）、（300，400）、（400，500）、（500，+）;7、因果图/判定表工程方法在以下那种情
3、况下不适用（C）A、输入输出明确，或输入输出因果关系明确的情况下B、被分析的特性或功能点复杂，输入项目很多的情况下C、系统输入之间相互约束多，需要做大范围的组合测试情况下D、系统输入之间基本没有相互联系8、以下说法不正确的是（D）A、测试原始需要明确了产品将要实现了什么B、产品测试规格明确了测试设计内容C、测试用例明确了测试实现内容D、以上说法均不正确9、可测试性中，有关系统可观察性的理解，下面说法那个是错误的（B）A、系统所有的输出结果可观察，错误输出易于识别；B、系统运行状态和内部处理的过程信息可观察；C、系统内部变量名及其取值可观察；D、系统内部重要对象的状态和属性可观察；E、系统内部重
4、要的操作的处理时间可观察；F、系统内部重要的资源的占用情况及单个资源的创建、保持、释放过程可观察10、测试脚本的编写规范强调：（ABCD ）A、可读行 B、可重用性 C、可维护性 D、可移植性11、当继承某个特性是，通常会从哪些角度对该特性进行测试分析？（AC ）A、失效影响度B、成熟度 C、继承方式 D、用户原始需求12、从下列关于软件测试的叙述中，选出正确的叙述（CD）A、用黑盒法测试时，测试用例是根据程序内部逻辑设计的B、测试的目的是验证该软件已正确的实现了用户的要求C、发现错误多的程序块，残留在模块中的错误也多D、测试设计时，应充分考虑异常的输入情况13、软件验收测试的合格通过准则是：
5、（ABCD）A 软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。B 所有测试项没有残余一级、二级和三级错误。C 立项审批表、需求分析文档、设计文档和编码实现一致。D 验收测试工件齐全。13、软件测试计划评审会需要哪些人员参加？（ABCD）A项目经理BSQA 负责人C配置负责人D测试组14测试设计员的职责有：（BC ）A制定测试计划B设计测试用例C设计测试过程、脚本D评估测试活动15软件实施活动的进入准则是：（ABC）A需求工件已经被基线化B详细设计工件已经被基线化C构架工件已经被基线化D项目阶段成果已经被基线化16软件验收测试的合格通过准则是：（ABCD）A 软件需求分析说
6、明书中定义的所有功能已全部实现，性能指标全部达到要求。B 所有测试项没有残余一级、二级和三级错误。C 立项审批表、需求分析文档、设计文档和编码实现一致。D 验收测试工件齐全。17软件测试计划评审会需要哪些人员参加？（ABCD）A项目经理BSQA 负责人C配置负责人D测试组18下列关于alpha 测试的描述中正确的是：（AD）Aalpha 测试需要用户代表参加Balpha 测试不需要用户代表参加Calpha 测试是系统测试的一种Dalpha 测试是验收测试的一种19测试设计员的职责有：（BC）A制定测试计划B设计测试用例C设计测试过程、脚本D评估测试活动20软件实施活动的进入准则是：（ABC）A
7、需求工件已经被基线化B详细设计工件已经被基线化C构架工件已经被基线化D项目阶段成果已经被基线化判断题1.软件测试的目的是尽可能多的找出软件的缺陷。（ Y）2.负载测试是验证要检验的系统的能力最高能达到什么程度。（N ）3.测试人员要坚持原则，缺陷未修复完坚决不予通过。（N）4.自动化测试能比手工测试发现更多的缺陷（N）5.错误猜测法基于这样一种假设，以前犯过的错误，以后同样会犯，我犯过的错误别人同样会犯，前人犯过的错误，后人同样会犯（N）6.软件测试中的二八原则暗示着测试发现的错误中的80%很可能起源于程序模块的20%（Y）7.某WEB系统设计中，用户点击“退出”按钮从系统中退出，界面回到初始
8、登陆界面。此时不关闭窗口，使用浏览器的回退功能，可以回到之前的用户界面，继续进行用户操作。这种合适的人性化设计，恩那个避免用户误点击退出按钮后重新登录的繁琐操作；这种说法是否正确（N）8.在确定性能测试指标值时，参考的国际标准、国标、运营商规范中对此要求并不一样，可以视情况选择有利于我们的指标值，但必须要比竞争对手高，这样才有利于市场竞争力（N）9.测试执行时，应该对每一个测试结果做全面的检查，包括日志，这种说法是否正确（ N）10.在测试执行时，我们主要是基于用户的使用场景来考虑功能实现的正确性，关键机要数据在数据库内是否加密存储或日志输出中是否采用加密、掩码处理不是我们测试关注的范围，毕竟
9、那产品的内部实现，用户看不到的，自然也是不关心的。这种说法是否正确。（ ）11软件测试的目的是尽可能多的找出软件的缺陷。（Y）12Beta 测试是验收测试的一种。（Y）13验收测试是由最终用户来实施的。（N）14项目立项前测试人员不需要提交任何工件。（Y）15单元测试能发现约80%的软件缺陷。（Y）16代码评审是检查源代码是否达到模块设计的要求。（N）17自底向上集成需要测试员编写驱动程序。（Y）18负载测试是验证要检验的系统的能力最高能达到什么程度。（N）19测试人员要坚持原则，缺陷未修复完坚决不予通过。（N）20代码评审员一般由测试员担任。（N）21我们可以人为的使得软件不存在配置问题。（
10、N）22集成测试计划在需求分析阶段末提交。（N）简答一、区别阶段评审的与同行评审同行评审目的:发现小规模工作产品的错误,只要是找错误;阶段评审目的:评审模块 阶段作品的正确性 可行性 及完整性同行评审人数:3-7人 人员必须经过同行评审会议的培训,由SQA指导阶段评审人数:5人左右 评审人必须是专家 具有系统评审资格同行评审内容:内容小 一般文档 40页, 代码 500行二、为什么要在一个团队中开展软件测试工作？ 因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比 ISO 质量认证一 样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。在测试的过程发现软件中存在的
11、问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。 三、您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？ 我曾经做过web 测试后台测试客户端软件，其中包括功能测试，性能测试，用户体验测试。最擅长的是功能测试 四、您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同。测试类型有：功能测试，性能测试，界面测试。 功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、
12、错 误推测、因果图和综合策略。 性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。 界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉
13、悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。 区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）？做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试。五、请试着比较一下
14、黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。 黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。 白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。 软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒 测试主要是为了发现以下几类错误： 1、是否有不正确或遗漏的功能？ 2、在接口上，输入是否能
15、正确的接受？能否输出正确的结果？ 3、是否有数据结构错误或外部信息（例如数据文件）访问错误？ 4、性能上是否能够满足要求？ 5、是否有初始化或终止性错误？ 软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行 如下检查： 1、对程序模块的所有独立的执行路径至少测试一遍。 2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍
16、。 3、在循环的边界和运行的界限内执行循环体。 4、测试内部数据结构的有效性，等等。 单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下 某个特定函数的行为。 单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。 集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是： 两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从
17、这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程 序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起 测试。最后，将构成进程的所有模块一起测试。 系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。（常见的联调测试） 系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。 验收测试是向未来
18、的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。 六、测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？ 软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程
19、中的各种变更。 测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法（最好是能先评审） 七、您认为做好测试计划工作的关键是什么？ a. 明确测试的目标，增强测试计划的实用性 编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确
20、。b坚持“5W”规则，明确内容与过程 “5W”规则指的是“What （做什么）”、“Why （为什么做）”、“When （何时做）”、“Where （在哪里）”、“How （如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理 解测试的目的（Why ），明确测试的范围和内容（What ），确定测试的开始和结束日期（When ）， 指出测试的方法和工具（How ），给出测试文档和软件的存放位置（Where ）。 c采用评审和更新机制，保证测试计划满足实际需求 测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围
21、的增减，而测试计划的内容没有及时更新，误导测试执行人员。 d. 分别创建测试计划与测试详细规格、测试用例 应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执 行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的 范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。 八、您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。 a等价类划分 划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输
22、入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试. 因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的 输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类. b边界值分析法 边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误. 使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界, 就是应着重
23、测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据. c错误推测法 基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法. 错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为 0 的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例. d因果图方法
24、前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条 件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的 合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）。因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况. 九、软件测试的目的？ 测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正种错误和缺陷提高软件质量，回
25、避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商 业风险。 十、什么是软件测试？ 使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。 软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。软件测试是为了发现错误而执行程序的过程。 十一、基于WEB 信息管理系统测试时应考虑的因素有哪些？ 1、功能测试 a)链接测试 b)表单测试 c)Cookies 测试d)设计语言测试e)数据库测试 2、性能测试 a)连接速度测试 b)负载测试 c)压力测试3、可用性测试 a)导航测试 b)
26、图形测试c)内容测试d)整体界面测试4、客户端兼容性测试 a)平台测试 b)浏览器测试 5、安全性测试 十二、软件本地化测试比功能测试都有哪些方面需要注意？ 软件本地化测试的目的： 软件本地化测试的测试策略：1.本地化软件要在各种本地化操作系统上安装并测试。2.源语言软件安装在另一台相同源语言操作系统上，作为对比测试。3.重点测试因本地化引起的软 件的功能和软件界面的错误。4.测试本地化软件的翻译质量。5.手工测试和自动测试相结合。 十三、软件测试项目从什么时候开始？为什么？ 软件测试应该在需求分析阶段就介入,因为测试的对象不仅仅是程序编码,应该对软件开发过程中产生的所有产品都测试,并且软件缺
27、陷存在放大趋势.缺陷发现的越晚,修复它所花费的成本就越大. 十四、需求测试注意事项有哪些？ 一个良好的需求应当具有一下特点： 完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。 正确性：每一项需求都必须准确地陈述其要开发的功能。 一致性：一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。 可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。 无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。 健壮性：需求的说明中是否对可能出现
28、的异常进行了分析，并且对这些异常进行了容错处理。 必要性：“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求 都能回溯至某项客户的输入，如Use Case 或别的来源。 可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。 可修改性：每项需求只应在 S R S中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。 可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（f i n e - g r a i n e d ）的方式
29、编写并单独标明，而不是大段大段的叙述。 十五、简述一下缺陷的生命周期 软件缺陷的生命周期指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程。 简单的软件缺陷生命周期： 1、发现打开：测试人员找到软件缺陷并将软件缺陷提交给开发人员； 2、打开修复：开发人员再现、修复缺陷，然后提交测试人员去验证； 3、修复关闭：测试人员验证修复过的软件，关闭已不存在的缺陷。 但是这是一种理想的状态，在实际的工作中是很难有这样的顺利的，需要考虑的各种情况都还是非常多的。 复杂的软件缺陷生命周期： 1、新建一个软件缺陷，这个软件缺陷是（open）状态，进行bug 审查，不是代码问题，就是设计需
30、要修改； 2、新建一个软件缺陷，这个软件缺陷是（open）状态，进行bug 审查，以后修改的，就可以延期； 3、新建一个软件缺陷，这个软件缺陷是（open）状态，进行bug 审查，实际没有这个bug，可以将其关闭； 4、新建一个软件缺陷，这个软件缺陷是（open）状态，看是否清楚可重现，如果不能重现，就是缺少信息，需要返回到（open）状态；如果能够重现，就进行修正，修正后关闭，进行回归测试。 十六、为什么要写用例： 我们编写测试用例，有如下的好处： 便于团队交流：假如说一个测试团队有 10 个成员，大家测试的时候都各自为政，没有统一的标准，测试的效率无疑会大打折扣；如果大家都遵循统一的用例规
31、范去写，就会解决这一 问题。 便于重复测试 ：大家知道，软件在实际开发过程中是会有不同版本的，比如会从 1.0 升级到 10.0，那么如果不写测试用例的话，在测试 10.0 版本的时候，你能完全记得 1.0 版本时你做过哪些测试吗？测试用例就像一个备忘录一样，便于重复测试。 便于跟踪统计：这一点是针对测试经理或是项目经理来说的，项目负责人通过看测试用例的执行情况，就能了解到项目目前的概况，比如已经执行了哪些测试，还有哪些测试没有执行，测试没有通过的地方主要集中在哪些模块等。 便于用户自测：尤其是项目软件，有的时候用户希望自己测试一下软件产品，但是用户大都 是非专业人士，他需要根据你写好的用例来更好的检验产品的质量。说了这么多编写测试用例的优点，那它有没有缺点呢？有一个明显的缺点就
