{"name":"计算机软件测试员题库","level":"四级 / 三级 / 二级 / 一级","org":"人力资源和社会保障部门","count":300,"questions":[{"id":1,"type":"single","stem":"某测试员为一个登录模块设计用例，已覆盖“用户名正确+密码正确”场景，下一步补充“用户名正确+密码错误”用例时，他依据的最主要设计方法是","options":["等价类划分","边界值分析","错误推测","因果图"],"answer":[0],"explanation":"知识点：等价类划分把输入域分为有效和无效等价类，密码错误属于密码域的无效等价类。等价类划分类正确，因为密码错误是密码有效类之外的无效类划分。边界值分析针对取值边缘，此处非边界问题。错误推测依赖经验猜测，非系统划分依据。因果图处理输入条件组合关系，本题未涉及组合约束。","tier":"基础"},{"id":2,"type":"single","stem":"测试一个“年龄输入框允许18到60岁整数”的功能时，下列取值组合最符合边界值分析要求的是","options":["17、18、60、61","18、30、60","0、18、60、100","17、30、61、80"],"answer":[0],"explanation":"知识点：边界值分析取上点、离点、内点。17和61是刚好越界的离点，18和60是边界上点，组合最完整。18、30、60缺越界离点。0、18、60、100中0和100离边界过远不精确。17、30、61、80缺少60这个上边界点。","tier":"基础"},{"id":3,"type":"single","stem":"测试员发现某缺陷在开发环境无法复现，提交缺陷报告时最应优先补充的信息是","options":["复现该缺陷的精确环境与操作步骤","开发人员的历史提交记录","该模块的源代码行数统计","项目组当前使用的缺陷编号规则"],"answer":[0],"explanation":"知识点：缺陷报告需可复现，环境与步骤是核心。精确环境和操作步骤能让开发定位差异，正确。历史提交记录是开发排查手段，非报告首要补充。代码行数统计与复现无关。缺陷编号规则是流程规范，不影响复现。","tier":"挑战"},{"id":4,"type":"single","stem":"某缺陷被开发标记为“无法复现”并关闭，测试员确认该缺陷在测试环境仍稳定出现，此时正确的处置是","options":["附上最新复现日志和录屏后重新激活该缺陷","接受关闭结论并另建一个描述相同的新缺陷","直接在缺陷跟踪系统中把状态改回新建","在项目群发消息要求开发立即修复"],"answer":[0],"explanation":"知识点：缺陷生命周期中 reopened 需提供新证据。附日志录屏重激活能推动定位，正确。另建相同缺陷会造成重复记录。直接改状态缺少沟通证据链。群发消息不构成系统内可追溯处置。","tier":"挑战"},{"id":5,"type":"single","stem":"使用 Selenium 编写自动化脚本时，页面元素在固定等待 3 秒后仍偶发加载失败，最应采用的改进方式是","options":["改用显式等待指定元素可见条件","把固定等待时间延长到 10 秒","在脚本开头增加一次页面刷新","把该用例从自动化套件中移除"],"answer":[0],"explanation":"知识点：显式等待按条件轮询，比固定等待更稳。显式等待针对元素可见条件，正确。单纯延长固定等待仍可能偶发失败。开头刷新不解决元素加载时机问题。移除用例是回避而非解决。","tier":"基础"},{"id":6,"type":"single","stem":"在缺陷管理流程中，测试员提交缺陷后由开发修复，再由测试员验证关闭，其中“验证关闭”这一步的主要目的是","options":["确认修复后原缺陷不再出现且未引入新问题","统计开发人员本次修复所用的工时","评估该缺陷对项目进度的影响程度","决定该缺陷是否需要纳入回归测试范围"],"answer":[0],"explanation":"知识点：缺陷验证关闭确认修复有效且无回归。确认原缺陷消失且无新问题，正确。工时统计属度量活动。进度影响在缺陷评审阶段评估。是否回归在修复前已确定范围。","tier":"进阶"},{"id":7,"type":"single","stem":"某项目要求对一段根据用户等级计算折扣的代码设计用例，等级分为普通、银卡、金卡，且折扣还与是否促销叠加，最合适的设计方法是","options":["判定表","等价类划分","边界值分析","错误推测"],"answer":[0],"explanation":"知识点：判定表适合多条件组合逻辑。等级与促销叠加属条件组合，判定表能穷举规则，正确。等价类划分单条件为主。边界值分析针对数值边界。错误推测依赖经验不系统。","tier":"进阶"},{"id":8,"type":"single","stem":"测试员执行回归测试时发现某旧功能出现新缺陷，而该功能本次并未被修改，首先应排查的方向是","options":["本次变更是否影响了该功能的公共依赖","该功能的历史缺陷是否已全部关闭","测试用例的预期结果是否写错","测试环境是否安装了最新补丁"],"answer":[0],"explanation":"知识点：回归缺陷常由变更的间接影响引起。公共依赖被改动是首要排查方向，正确。历史缺陷关闭状态与本次新缺陷无直接因果。预期结果写错属用例问题但非首选。补丁安装属环境因素，通常先查代码依赖影响。","tier":"挑战"},{"id":9,"type":"single","stem":"使用 JUnit 编写单元测试时，某测试方法依赖数据库连接才能通过，为让该测试保持独立快速，较合理的做法是","options":["使用 Mock 对象替代真实数据库交互","把该测试标记为忽略并长期不执行","在测试类中硬编码一个测试数据库地址","把数据库连接改为每次测试前手动启动"],"answer":[0],"explanation":"知识点：单元测试应隔离外部依赖。Mock 替代数据库可保持独立快速，正确。标记忽略会丢失覆盖。硬编码地址仍依赖真实数据库。手动启动增加耦合和耗时。","tier":"进阶"},{"id":10,"type":"single","stem":"某缺陷报告只写了“登录有时失败”，未给出复现步骤和环境信息，这最可能导致的结果是","options":["开发难以定位问题而反复沟通延误修复","缺陷被自动分配给错误的开发人员","缺陷严重程度被系统自动调高","缺陷跟踪系统拒绝保存该记录"],"answer":[0],"explanation":"知识点：缺陷报告信息不足影响定位效率。缺少步骤和环境会使开发难以复现，正确。分配错误与报告内容质量无直接自动关联。严重程度不会因此自动调高。系统通常不会仅因描述简略拒存。","tier":"基础"},{"id":11,"type":"single","stem":"某团队用持续集成流水线自动运行回归测试，某次构建后大量用例失败，排查发现是测试数据被前一个用例污染，正确的改进措施是","options":["为每个用例准备独立数据并在结束后清理","把所有用例合并成一个大的测试方法","关闭失败用例的断言以让流水线通过","把回归测试改为每周手动执行一次"],"answer":[0],"explanation":"知识点：用例间数据隔离是自动化稳定的基础。独立数据并清理可消除污染，正确。合并大方法会加剧耦合。关闭断言掩盖问题。改为手动降低反馈效率。","tier":"挑战"},{"id":12,"type":"single","stem":"用等价类划分法为“年龄输入框（允许18~60的整数）”设计测试用例时，下列哪一组输入能同时覆盖一个有效等价类和一个无效等价类","options":["35 与 17","35 与 61","18 与 60","17 与 61"],"answer":[0],"explanation":"知识点是等价类划分中有效类与无效类各取一个代表。35落在有效区间，17落在小于下限的无效区间，构成有效+无效各一。35与61都是无效（61超上限），没有有效类；18与60都是有效类边界值，缺无效类；17与61虽都是无效类，但缺少有效类代表。","tier":"基础"},{"id":13,"type":"single","stem":"某登录功能规定密码长度为8~16位且必须含字母和数字，用边界值分析法设计用例时，下列哪个取值组合最能暴露长度边界缺陷","options":["7位含字母数字、8位含字母数字、16位含字母数字、17位含字母数字","8位纯字母、8位纯数字、16位纯字母、16位纯数字","8位含字母数字、12位含字母数字、16位含字母数字、20位含字母数字","7位纯字母、8位纯字母、16位纯字母、17位纯字母"],"answer":[0],"explanation":"知识点是边界值分析应取上点、离点和内点并保持其他条件满足。长度边界应取7、8、16、17且都含字母数字，才能单独暴露长度判定缺陷。第二组在长度合法时改字符类型，混入类型因素；第三组取了20位超界过多且漏7位；第四组全部纯字母，同时触发类型无效，无法单独判定长度缺陷。","tier":"进阶"},{"id":14,"type":"single","stem":"在缺陷管理流程中，测试人员提交缺陷后被开发人员标记为“无法复现”，此时测试人员下一步最恰当的处置是","options":["直接关闭该缺陷并在备注写明开发不配合","补充复现步骤、日志和录屏后重新激活缺陷","把缺陷优先级调高后再次指派给同一开发","将缺陷转给项目经理要求其判定责任归属"],"answer":[1],"explanation":"知识点是缺陷生命周期中“无法复现”状态的处理。正确做法是补充环境、步骤、日志、录屏等证据后重新激活，便于定位。直接关闭会漏掉真实缺陷；仅调高优先级不解决证据不足；转交项目经理属于升级路径，通常应在补充证据沟通无效后再考虑。","tier":"挑战"},{"id":15,"type":"single","stem":"使用Selenium WebDriver编写自动化脚本时，页面元素在点击前需要等待异步加载完成，下列哪种等待方式最符合稳定自动化的要求","options":["Thread.sleep固定等待3秒后点击","显式等待元素可点击条件成立后点击","隐式等待全局设置10秒后直接点击","循环刷新页面直到元素出现再点击"],"answer":[1],"explanation":"知识点是WebDriver等待机制。显式等待针对具体条件轮询，条件满足即继续，稳定且高效。固定睡眠浪费时间且不稳定；隐式等待只对查找元素生效，对可点击状态不保证；循环刷新会破坏页面状态并可能触发风控。","tier":"进阶"},{"id":16,"type":"single","stem":"某接口自动化用例断言响应状态码为200，但业务返回体中的code字段为5001表示“余额不足”，该用例当前判定为通过，这属于哪类问题","options":["断言覆盖不足，未校验业务返回码","接口协议设计错误，应直接返回500","测试数据准备错误，应改用有余额账号","环境配置错误，应切换生产环境重测"],"answer":[0],"explanation":"知识点是接口测试中HTTP状态码与业务状态码的区别。HTTP 200只说明请求被处理，业务失败需另断言code字段，因此是断言覆盖不足。协议是否用500是设计选择；换账号只是规避场景；切生产环境既危险又不解决断言缺失。","tier":"进阶"},{"id":17,"type":"single","stem":"在JUnit中为某个会抛出IllegalArgumentException的方法编写测试，验证其异常行为最规范的写法是","options":["用try-catch捕获异常后打印堆栈即可","用assertThrows断言异常类型并检查消息","在测试方法上声明throws后不做任何断言","用assertTrue判断返回值为null来推断异常"],"answer":[1],"explanation":"知识点是单元测试框架的异常断言。assertThrows可精确断言异常类型并校验消息，失败时定位清晰。仅捕获打印不算断言；方法声明throws等于放弃验证；用返回值推断异常既不可靠也不表达意图。","tier":"进阶"},{"id":18,"type":"single","stem":"在缺陷报告中，“标题”字段写成“登录有问题，赶紧修”，从缺陷管理规范看这主要违反哪项要求","options":["缺陷标题应简明描述现象与条件便于检索","缺陷标题必须由开发人员填写","缺陷标题应包含修复方案与代码位置","缺陷标题应使用英文且不超过五个单词"],"answer":[0],"explanation":"知识点是缺陷报告标题的书写规范。标题应具体描述现象与触发条件，便于检索和分派。标题由测试人员填写而非开发；标题不含修复方案，那是开发职责；是否英文无硬性规定，长度也非五个单词限制。","tier":"进阶"},{"id":19,"type":"single","stem":"某团队在回归测试阶段发现一个已修复缺陷再次出现，查看记录发现修复提交后未补充对应自动化用例，从质量保障角度最应改进的环节是","options":["提高缺陷优先级以引起开发重视","修复缺陷时同步补充回归测试用例","要求测试人员在发版前全量手工回归","将该模块移出本次迭代范围不再测试"],"answer":[1],"explanation":"知识点是缺陷修复与回归防护的闭环。修复时补充回归用例可防止再次回归。提高优先级不解决防护缺失；全量手工回归成本高且不针对该缺陷；移出迭代范围是逃避问题，不属质量改进。","tier":"挑战"},{"id":20,"type":"single","stem":"用Postman对某查询接口做数据驱动测试时，希望用同一脚本依次跑多组参数，最合适的做法是","options":["为每组参数复制一份请求并手动逐个发送","在集合中使用CSV或JSON数据文件配合Runner运行","把多组参数拼接到URL路径中依次请求","开启Postman代理后让浏览器自动重放请求"],"answer":[1],"explanation":"知识点是Postman数据驱动测试。Collection Runner支持绑定CSV/JSON数据文件，用变量迭代执行。复制请求手动发送效率低且易漏；拼接到路径改变接口语义；代理重放无法系统化参数化。","tier":"进阶"},{"id":21,"type":"single","stem":"某电商项目在“双十一”前对下单接口做性能测试，脚本中登录token在压测开始前获取一次并写入全局变量供所有虚拟用户使用，这种做法最可能导致","options":["压测结果偏高，因token复用减少登录开销","压测结果偏低，因token过期导致大量请求失败","压测结果不受影响，token只是身份标识","压测结果偏高，因全局变量读取比局部变量快"],"answer":[1],"explanation":"知识点是性能测试中会话数据的参数化与关联。token通常有有效期且与用户绑定，全局复用易过期或串号，导致大量请求鉴权失败，使结果偏低失真。token复用确实减少登录开销，但更主要风险是失效；token并非无影响标识；变量读取速度差异对结果影响可忽略。","tier":"进阶"},{"id":22,"type":"multi","stem":"在缺陷生命周期管理中，下列哪些状态转换属于常见且合理的流转","options":["新建→已指派→已修复→待验证→已关闭","新建→已拒绝→重新打开→已指派","已修复→重新打开→已指派→已修复","已关闭→新建→已指派→已拒绝","待验证→已关闭→已修复→重新打开"],"answer":[0,1,2],"explanation":"知识点是缺陷状态机的常见合法流转。新建到关闭的完整链路合理；被拒绝后经复核重新打开再指派合理；修复后验证不通过重新打开再指派合理。已关闭缺陷不应回到新建，通常需重新打开；已关闭直接回到已修复也跳过验证环节，最后一项流程倒置不合理。","tier":"进阶"},{"id":23,"type":"single","stem":"某测试员发现一个缺陷后，开发人员回复“无法复现”，此时测试员首先应当做的是","options":["直接关闭该缺陷并标注为无效","补充环境信息与复现步骤后重新提交","将该缺陷优先级降为最低等待观察","把缺陷转交给项目经理裁决"],"answer":[1],"explanation":"知识点：缺陷生命周期中“无法复现”的处理。补充环境、数据、操作步骤等复现要素后重新提交，是推动缺陷定位的标准做法。直接关闭会漏掉真实缺陷；降优先级并未解决复现信息不足的问题；转交项目经理跳过了先完善信息这一步。","tier":"挑战"},{"id":24,"type":"single","stem":"在缺陷报告中，“缺陷摘要”字段的主要作用是","options":["记录缺陷的详细复现步骤","用一句话概括缺陷的核心现象","说明缺陷对用户的影响程度","列出缺陷涉及的所有相关人员"],"answer":[1],"explanation":"知识点：缺陷报告字段职责。摘要是对缺陷核心现象的一句话概括，便于检索和快速判断。详细复现步骤属于“复现步骤”字段；影响程度属于“严重程度/优先级”；人员信息属于“指派/抄送”字段。","tier":"基础"},{"id":25,"type":"single","stem":"某缺陷在测试环境可稳定复现，但上线后用户从未遇到，从缺陷管理角度看最合理的处置是","options":["直接关闭该缺陷并注明环境差异","升级为最高优先级要求立即修复","保留该缺陷并记录环境差异待评估","将该缺陷重新指派给测试人员"],"answer":[2],"explanation":"知识点：缺陷环境差异的处置。测试环境与生产环境存在差异时，应保留缺陷并记录差异供评估，而非直接关闭或盲目升级。直接关闭会丢失信息；升级为最高优先级缺乏依据；重新指派给测试人员不能解决环境差异问题。","tier":"挑战"},{"id":26,"type":"single","stem":"在判定表中，若某条件桩对应的动作桩在多个规则下结果相同，通常采用的处理方式是","options":["将该条件合并以减少规则数","将该条件拆分为两条独立规则","删除该条件对应的所有动作","为该条件单独增加一条规则"],"answer":[0],"explanation":"知识点：判定表化简。当某条件取值不影响动作结果时，可将其合并（用“—”表示无关），以减少规则数量。拆分、删除、单独增加规则都不符合化简目的。","tier":"基础"},{"id":27,"type":"single","stem":"使用Postman对接口进行自动化断言时，若需要校验响应体中某字段的值等于预期值，应使用的断言脚本是","options":["pm.response.to.have.status(200)","pm.expect(pm.response.json().name).to.eql(\"张三\")","pm.response.to.have.header(\"Content-Type\")","pm.response.to.have.responseTime.below(200)"],"answer":[1],"explanation":"知识点：Postman断言API。校验响应体字段值应使用pm.expect配合eql进行值比较。status断言校验状态码；header断言校验响应头；responseTime断言校验响应时间。","tier":"进阶"},{"id":28,"type":"single","stem":"某测试用例在执行时发现实际结果与预期结果不一致，但经确认是测试用例的预期结果写错了，此时正确的做法是","options":["将该用例标记为失败并提交缺陷","修正用例预期结果后重新执行","直接删除该用例避免误导","保留失败记录并注明为环境问题"],"answer":[1],"explanation":"知识点：测试用例维护。预期结果写错属于用例本身缺陷，应修正后重新执行，而非提交产品缺陷。标记失败并提交缺陷会污染缺陷库；删除用例会丢失覆盖；注明环境问题与事实不符。","tier":"挑战"},{"id":29,"type":"single","stem":"在JMeter中，若需要模拟多个用户并发访问同一接口，应配置的元件是","options":["线程组中的线程数","HTTP请求的路径","响应断言的范围","监听器的保存路径"],"answer":[0],"explanation":"知识点：JMeter并发配置。线程数代表虚拟用户数，用于模拟并发。HTTP请求路径决定访问地址；断言范围决定校验范围；监听器保存路径决定结果存储位置，均与并发用户数无关。","tier":"基础"},{"id":30,"type":"single","stem":"在自动化测试中，若某测试脚本因页面元素加载延迟而偶发失败，最合适的改进方式是","options":["增加固定sleep等待时间","使用显式等待等待元素可见","降低脚本执行频率","将该脚本从测试集中移除"],"answer":[1],"explanation":"知识点：自动化测试等待策略。显式等待针对特定元素条件等待，兼顾稳定与效率。固定sleep会拖慢整体执行且仍可能不够；降低执行频率不解决根本问题；移除脚本会丢失覆盖。","tier":"进阶"},{"id":31,"type":"multi","stem":"关于缺陷严重程度（Severity）与优先级（Priority）的区别，下列描述正确的有","options":["严重程度反映缺陷对系统功能的影响大小","优先级反映缺陷被修复的紧急程度","严重程度高必然优先级也高","优先级可由测试人员根据业务影响提出建议","严重程度与优先级均由开发人员单独决定"],"answer":[0,1,3],"explanation":"知识点：严重程度与优先级的区别。严重程度衡量功能影响，优先级衡量修复紧急度，二者不一定正相关，测试人员可基于业务影响提出优先级建议。严重程度高不一定优先级高（如极端场景下影响大但极少发生）；二者通常由测试与开发共同评估，并非开发单独决定。","tier":"挑战"},{"id":32,"type":"single","stem":"在用等价类划分法为「年龄输入框（允许18至60的整数）」设计测试用例时，下列哪一组输入最能覆盖有效等价类边界与无效等价类","options":["17、18、60、61","18、30、60","18、19、59、60","0、18、60、100"],"answer":[0],"explanation":"知识点：等价类划分中的边界值分析。有效等价类为18到60，边界值取18和60，紧邻的无效值取17和61，故17、18、60、61覆盖最完整。18、30、60只覆盖有效类缺无效边界；18、19、59、60缺少无效等价类；0、18、60、100虽含无效值但缺61这一关键上边界紧邻值。","tier":"基础"},{"id":33,"type":"single","stem":"关于黑盒测试与白盒测试的区别，下列描述准确的是","options":["黑盒测试关注输入输出行为，白盒测试关注程序内部逻辑结构","黑盒测试只能由测试人员执行，白盒测试只能由开发人员执行","黑盒测试不需要设计用例，白盒测试必须写测试用例","黑盒测试用于单元测试，白盒测试用于系统测试"],"answer":[0],"explanation":"知识点：黑盒与白盒测试的本质区别。黑盒基于需求规格关注外部行为，白盒基于代码结构关注内部路径，故A正确。B错在角色与测试方法无必然绑定；C错在两种方法都需设计用例；D错在阶段与方法无固定对应关系。","tier":"基础"},{"id":34,"type":"single","stem":"使用Selenium编写自动化测试时，页面元素在操作瞬间才由JavaScript动态生成，导致偶发找不到元素，最合适的处理方式是","options":["使用显式等待等待该元素出现后再操作","在脚本开头统一加固定sleep等待若干秒","捕获异常后直接跳过该步骤","把定位方式从id改为class"],"answer":[0],"explanation":"知识点：自动化测试中的等待机制。显式等待针对特定条件轮询，能稳定应对动态元素。固定sleep浪费时间且不稳定；捕获异常跳过会掩盖失败；改定位方式不解决时序问题。","tier":"进阶"},{"id":35,"type":"single","stem":"在缺陷报告中，将「严重程度」与「优先级」混为一谈的典型错误表现是","options":["把界面文字错别字标为严重程度高、优先级高","把导致系统崩溃的缺陷标为严重程度高、优先级高","把偶现的功能缺陷标为严重程度中、优先级中","把安全漏洞标为严重程度高、优先级高"],"answer":[0],"explanation":"知识点：缺陷严重程度与优先级的区分。严重程度反映对系统的影响，优先级反映修复紧迫性。错别字影响极低，不应标为严重程度高。B、C、D的标注均符合各自缺陷的实际影响与紧迫性，属正确做法。","tier":"进阶"},{"id":36,"type":"single","stem":"某电商系统要求「订单金额满100元免运费」，用判定表设计测试用例时，条件桩应包含","options":["订单金额是否满100元、是否选择免运费活动","订单金额、运费金额、商品数量","用户等级、订单金额、支付方式","商品重量、配送地区、订单金额"],"answer":[0],"explanation":"知识点：判定表条件桩的确定。条件桩应对应影响动作的条件。该规则只有『金额是否满100』与『是否参与免运费活动』两个条件。B、C、D混入了不影响该规则的其他字段，条件桩选择错误。","tier":"基础"},{"id":37,"type":"single","stem":"在缺陷管理流程中，缺陷状态从「已修复」流转到「已关闭」之前，通常必须经过的环节是","options":["回归测试验证通过","开发人员再次确认代码","产品经理评审缺陷等级","测试经理统计缺陷数量"],"answer":[0],"explanation":"知识点：缺陷生命周期状态流转。已修复后必须由测试人员回归验证，通过后才能关闭。开发确认代码、产品评审等级、统计数量都不是关闭前的必要环节。","tier":"基础"},{"id":38,"type":"single","stem":"某登录功能测试中，输入正确用户名和错误密码，系统提示「用户名或密码错误」，这一设计主要出于","options":["避免攻击者通过提示差异枚举出有效用户名","减少前端校验代码的复杂度","提升数据库查询的执行效率","符合前端框架的默认提示规范"],"answer":[0],"explanation":"知识点：安全测试中的信息泄露防护。统一错误提示可防止用户名枚举攻击。减少代码复杂度、提升查询效率、框架默认规范均不是该设计的核心目的。","tier":"基础"},{"id":39,"type":"single","stem":"使用JMeter对接口做压力测试时，为模拟200个并发用户持续运行10分钟，应配置的线程组参数是","options":["线程数200、Ramp-Up时间0、循环次数勾选永远并设调度时长600秒","线程数200、Ramp-Up时间600、循环次数1","线程数10、Ramp-Up时间1、循环次数200","线程数200、Ramp-Up时间1、循环次数10"],"answer":[0],"explanation":"知识点：JMeter线程组参数配置。要模拟200并发持续10分钟，需线程数200、Ramp-Up为0（立即并发）、循环永远且调度600秒。B是10分钟渐增且只跑1次；C是10线程循环200次；D是200线程只跑10次，均不满足持续并发要求。","tier":"进阶"},{"id":40,"type":"multi","stem":"关于测试用例设计，下列做法正确的有","options":["为每个用例标注预期结果以便判定通过与否","用例应覆盖正常流程与异常流程","用例设计完成后无需评审直接执行","用例应包含可独立执行的前置条件","用例标题可用『测试登录』概括全部登录场景"],"answer":[0,1,3],"explanation":"知识点：测试用例设计规范。A标注预期结果是判定依据；B需覆盖正常与异常流程；D前置条件保证用例可独立执行，均正确。C错在用例需评审以保证质量；E错在标题过于笼统，无法区分不同场景。","tier":"进阶"},{"id":41,"type":"single","stem":"用等价类划分法为“年龄输入框（允许18到60的整数）”设计测试用例时，下列哪一组输入取值组合最符合等价类划分的要求","options":["17、18、60、61","18、30、60","17、30、61","0、18、60、100"],"answer":[0],"explanation":"知识点：等价类划分需覆盖每个有效等价类和无效等价类的边界代表值。18和60是有效边界，17和61分别是两侧无效等价类的代表，因此17、18、60、61最完整。选项18、30、60缺少无效等价类代表；17、30、61缺少有效边界值18和60；0、18、60、100虽含无效值，但0和100同属下界外无效类，未覆盖上界外无效类，且未给出有效类内的普通值。","tier":"基础"},{"id":42,"type":"single","stem":"在缺陷管理流程中，测试人员提交缺陷后开发人员标记为“无法复现”，测试人员下一步最恰当的做法是","options":["直接关闭该缺陷并记录为环境问题","补充复现步骤、日志和截图后重新激活","将该缺陷转给产品经理判断是否为需求","在缺陷描述中标注“开发不配合”后升级"],"answer":[1],"explanation":"知识点：缺陷生命周期中“无法复现”的处理方式。正确做法是补充更精确的复现步骤、运行环境、日志和截图等证据后重新激活，便于开发定位。直接关闭会遗漏真实缺陷；转给产品经理偏离了缺陷复现的技术处理路径；标注“开发不配合”属于情绪化操作，不能解决复现问题。","tier":"进阶"},{"id":43,"type":"single","stem":"某自动化测试脚本使用Selenium定位一个动态生成的按钮，该按钮的id每次刷新都会变化，但class和文本内容稳定，最合适的定位策略是","options":["By.id使用当前捕获到的id值","By.xpath使用按钮的绝对路径","By.cssSelector使用稳定的class属性","By.tagName使用button标签名"],"answer":[2],"explanation":"知识点：自动化测试中元素定位策略的稳定性选择。id动态变化时不能依赖id；绝对路径xpath随页面结构变动极易失效；tagName会匹配到多个button无法唯一定位；使用稳定的class属性配合其他属性定位最可靠。","tier":"进阶"},{"id":44,"type":"single","stem":"关于边界值分析，下列对“输入范围为1到100的整数”设计测试数据的做法中，最符合边界值分析原则的是","options":["取1、50、100三个值","取0、1、100、101四个值","取1、2、99、100四个值","取0、1、2、99、100、101六个值"],"answer":[1],"explanation":"知识点：边界值分析关注边界及其相邻值。对于1到100的范围，边界是1和100，边界外侧相邻值是0和101，因此0、1、100、101是典型边界值集合。取1、50、100只覆盖了边界和一个中间值，缺少边界外侧；取1、2、99、100只覆盖了边界内侧；取六个值虽更全，但标准边界值分析通常取边界及外侧相邻值即可，且题目问最符合原则，0、1、100、101最典型。","tier":"基础"},{"id":45,"type":"single","stem":"某测试人员发现一个缺陷在测试环境中稳定复现，但开发人员在本地环境中无法复现，此时最有效的下一步措施是","options":["要求开发人员更换电脑后重试","提供测试环境的版本号、配置和操作录屏","将该缺陷优先级直接降为最低","在测试环境中反复执行直到偶发失败为止"],"answer":[1],"explanation":"知识点：环境差异导致缺陷无法复现时的处理。提供测试环境版本、配置、依赖和操作录屏能帮助开发还原场景，是定位环境差异的关键。要求换电脑不是解决环境差异的规范做法；直接降优先级会掩盖问题；反复执行到偶发失败并不能解释环境差异。","tier":"挑战"},{"id":46,"type":"single","stem":"使用Postman对登录接口做自动化测试时，希望把上一个请求返回的token自动带入下一个请求的请求头，正确的做法是","options":["在Tests脚本中提取token并设置为环境变量，在下一个请求头中引用该变量","在Pre-request Script中把token写死在请求头里","在下一个请求的Body中手动粘贴token后发送","在Postman的History中复制上一个请求的响应头"],"answer":[0],"explanation":"知识点：接口自动化测试中的变量传递。正确方式是在Tests脚本中解析响应、提取token并写入环境变量，后续请求通过变量引用实现关联。写死token无法应对动态变化；手动粘贴无法自动化且易出错；复制响应头不能自动带入下一个请求。","tier":"进阶"},{"id":47,"type":"single","stem":"某电商系统在“提交订单”时，测试人员发现库存充足却提示“库存不足”，但刷新后又能正常下单，该缺陷最应优先记录的信息是","options":["下单按钮的CSS样式是否美观","出现提示时的库存数值与订单号","开发人员最近提交代码的提交人","该功能由哪个测试人员负责"],"answer":[1],"explanation":"知识点：偶现缺陷的记录要点。对于偶现的库存提示异常，记录出现提示时的库存数值和订单号有助于开发结合日志定位并发或缓存问题。按钮样式与缺陷无关；提交人和负责人信息对定位该缺陷无直接帮助。","tier":"挑战"},{"id":48,"type":"single","stem":"在自动化测试中，某用例断言“页面跳转到订单列表页”，但实际跳转到了登录页，日志显示会话已过期，此时测试脚本最合理的处理方式是","options":["将该断言直接改为登录页以让用例通过","在断言前增加登录状态检查并重新登录","删除该用例并标记为环境问题","把断言超时时间从5秒改为60秒"],"answer":[1],"explanation":"知识点：自动化测试中会话失效导致的用例失败处理。合理做法是在断言前检查登录状态，失效则重新登录后再继续，保证用例验证的是目标功能。直接改断言会掩盖缺陷；删除用例会丢失覆盖；延长超时无法解决会话过期问题。","tier":"挑战"},{"id":49,"type":"single","stem":"执行某查询模块的等价类划分测试时，已为“用户年龄”输入框划分出有效等价类（18~60 的整数）和三个无效等价类（小于18、大于60、非整数），下一步设计用例时最合适的做法是","options":["为每个等价类各取一个代表值设计一条用例，无效等价类单独覆盖","只对有效等价类取边界值设计用例，无效等价类合并成一条用例","对有效等价类取中间值和边界值各一条，无效等价类随机取值覆盖","把所有等价类的代表值合并到一条用例中一次性执行验证"],"answer":[0],"explanation":"知识点是等价类划分法：每个等价类取代表值，有效类可用尽量少的用例覆盖，无效类必须各自单独设计用例以避免相互屏蔽。选项0正确，为每个等价类取代表值且无效类单独覆盖；选项1错在无效等价类不能合并，合并后一个错误会屏蔽另一个错误的检出；选项2错在无效等价类不能随机取值，随机取值可能漏掉该类的代表情况；选项3错在多个等价类合并到一条用例，前一个输入失败会掩盖后续等价类的验证。","tier":"进阶"},{"id":50,"type":"multi","stem":"某团队用 Selenium 编写登录页自动化脚本，脚本在本地稳定通过，接入 CI 后频繁报“元素不可见”而失败，排查时符合缺陷管理与自动化测试实践的正确处置有","options":["在断言前加入显式等待，等待目标元素的可点击条件成立","把失败截图和页面源码随构建产物归档，便于定位环境差异","将脚本改为捕获异常后直接标记用例通过，避免流水线中断","核对 CI 环境浏览器版本与本地是否一致并统一驱动版本","把该用例从回归集中移除，改为每次由人工手动验证登录"],"answer":[0,1,3],"explanation":"知识点是自动化测试稳定性与缺陷定位：UI 自动化应使用显式等待而非固定延时，失败时应保留截图和页面源码等证据，并排查环境（浏览器与驱动版本）差异。选项0正确，显式等待可解决元素尚未可见的时序问题；选项1正确，归档截图和源码是定位环境差异的规范做法；选项2错在捕获异常后标记通过会掩盖真实缺陷；选项3正确，浏览器与驱动版本不一致是 CI 与本地表现不同的常见原因；选项4错在把自动化用例退回人工会降低回归覆盖，且未解决根因。","tier":"挑战"},{"id":51,"type":"single","stem":"在等价类划分法中，某输入框要求输入1到100的整数，下列划分出的等价类里属于有效等价类的是","options":["小于1的整数","1到100的整数","大于100的整数","非整数输入"],"answer":[1],"explanation":"知识点是等价类划分中的有效等价类与无效等价类。有效等价类指对规格说明合理、有意义的输入集合，1到100的整数符合规格，属于有效等价类。小于1的整数、大于100的整数、非整数输入都违反输入规格，属于无效等价类。","tier":"基础"},{"id":52,"type":"single","stem":"用边界值分析法为输入范围[10,50]设计测试用例时，按标准边界值取法应包含的边界点是","options":["9、10、50、51","10、30、50、51","10、11、49、50","9、10、11、49"],"answer":[0],"explanation":"知识点是边界值分析中标准边界点的取法。对闭区间[10,50]，标准边界值取略小于下界、下界、上界、略大于上界，即9、10、50、51。选项10、30、50、51漏掉下界外侧9；选项10、11、49、50漏掉上下界外侧点；选项9、10、11、49缺少上界及上界外侧点。","tier":"基础"},{"id":53,"type":"single","stem":"判定表法适合用来设计测试用例的场景是","options":["输入条件之间存在逻辑组合关系","输入数据是连续变化的数值","程序内部使用循环结构处理数据","性能指标随并发数变化"],"answer":[0],"explanation":"知识点是判定表法的适用场景。判定表用于描述多个输入条件之间逻辑组合与动作的对应关系。输入连续变化数值适合边界值或等价类；循环结构处理数据关注路径覆盖；性能指标随并发变化属于性能测试范畴，均非判定表典型用途。","tier":"基础"},{"id":54,"type":"single","stem":"缺陷报告中“缺陷可复现步骤”一栏应当填写的内容是","options":["开发人员修复该缺陷的代码位置","从初始状态到缺陷出现的最小操作序列","测试人员对缺陷严重程度的判断","该缺陷关联的需求文档编号"],"answer":[1],"explanation":"知识点是缺陷报告字段含义。可复现步骤记录从初始状态开始、能稳定触发缺陷的最小操作序列，便于开发定位。代码位置由开发填写；严重程度属于严重级别字段；需求编号属于关联信息字段，均不是步骤栏内容。","tier":"进阶"},{"id":55,"type":"single","stem":"在自动化测试中引入显式等待（如WebDriverWait）相比固定睡眠sleep的主要优势是","options":["能根据条件满足情况尽早继续执行","可以完全替代所有隐式等待","能自动修复页面元素定位错误","能降低被测系统的响应时间"],"answer":[0],"explanation":"知识点是显式等待机制。显式等待在条件满足时立即继续，条件未满足才等到超时，兼顾速度与稳定。它不能完全替代隐式等待（两者可配合）；不能修复定位错误；也不能改变被测系统响应时间。","tier":"基础"},{"id":56,"type":"single","stem":"某接口自动化用例断言时只检查HTTP状态码为200，未校验响应体内容，这属于","options":["断言过强导致误报","断言不足导致漏报","测试数据准备错误","测试环境配置错误"],"answer":[1],"explanation":"知识点是自动化断言充分性。仅校验状态码无法发现接口返回错误业务数据的缺陷，属于断言不足导致漏报。断言过强会因无关差异误报；数据准备与环境配置问题属于另一类缺陷，与断言覆盖不足无关。","tier":"基础"},{"id":57,"type":"single","stem":"在持续集成流水线中，冒烟测试用例集通常安排执行的时机是","options":["每次代码提交触发构建之后","产品正式发布上线之后","每个迭代全部回归测试完成后","仅在性能压测阶段执行"],"answer":[0],"explanation":"知识点是持续集成中的冒烟测试定位。冒烟测试用于快速验证构建基本可用，应在每次提交触发构建后立即执行。发布上线后、全部回归完成后都太晚；性能压测阶段也不属于冒烟测试的常规时机。","tier":"基础"},{"id":58,"type":"single","stem":"某测试人员在提交缺陷时把两个互不相关的界面崩溃问题写在同一条缺陷记录里，这种做法的主要问题是","options":["会导致缺陷严重级别被自动提高","不利于缺陷的跟踪、修复与回归验证","会使缺陷报告无法被开发人员看到","会导致该缺陷被系统自动标记为重复"],"answer":[1],"explanation":"知识点是缺陷记录的单一性要求。一条缺陷应描述一个独立问题，混合多个问题会导致修复进度、验证结论互相干扰，不利于跟踪与回归。严重级别不会被自动提高；开发仍能看到；系统也不会因此自动判重。","tier":"基础"},{"id":59,"type":"single","stem":"某电商项目在“双十一”前对下单流程做回归测试，测试经理要求优先覆盖最近改动过的支付模块及其被调用的订单模块，这种测试策略依据的是","options":["风险与变更影响范围","等价类划分结果","历史缺陷的严重级别分布","测试人员的个人经验偏好"],"answer":[0],"explanation":"知识点是回归测试的范围选择依据。优先覆盖改动模块及其影响到的调用链，属于基于风险与变更影响范围确定回归重点。等价类划分是设计用例的方法；历史缺陷分布可作为参考但不是此处的主要依据；个人偏好不是规范策略。","tier":"基础"},{"id":60,"type":"single","stem":"某测试员在缺陷管理工具中提交缺陷时，将“缺陷标题”写为“登录功能有问题”，该做法最可能造成的问题是","options":["缺陷标题无法被检索和快速定位","缺陷严重程度无法被系统自动计算","缺陷的复现步骤会被工具自动清空","缺陷修复人无法收到邮件通知"],"answer":[0],"explanation":"知识点：缺陷报告规范。缺陷标题需简明描述现象与条件，便于检索与统计；“登录功能有问题”过于笼统，导致检索与定位困难。严重程度由人工设定而非标题决定；“复现步骤会被自动清空”与标题无关；通知由指派与订阅规则决定，与标题笼统与否无关。","tier":"基础"},{"id":61,"type":"single","stem":"在等价类划分法中，某输入框要求输入1到100的整数，下列划分中属于无效等价类的是","options":["输入值为0","输入值为50","输入值为100","输入值为1"],"answer":[0],"explanation":"知识点：等价类划分。有效等价类为1至100的整数，0、101、非整数等属于无效等价类。50与1、100均落在有效区间内，属于有效等价类。","tier":"基础"},{"id":62,"type":"single","stem":"某测试员对同一段代码先按语句覆盖设计用例，再按判定覆盖设计用例，两次得到的用例集合关系通常是","options":["判定覆盖的用例集合不一定能覆盖全部语句","判定覆盖的用例集合必然少于语句覆盖","语句覆盖的用例集合必然满足判定覆盖","两种覆盖的用例集合完全一致"],"answer":[0],"explanation":"知识点：逻辑覆盖率强弱关系。判定覆盖强于语句覆盖，满足判定覆盖通常可满足语句覆盖，但“用例集合”大小与包含关系并不必然；“必然少于”“完全一致”均过于绝对。","tier":"进阶"},{"id":63,"type":"single","stem":"某项目采用敏捷开发，测试人员希望在每次代码提交后自动运行单元测试并给出结果，最合适的做法是","options":["在持续集成流水线中配置提交触发构建","由测试人员每天下班前手工执行一次","由开发人员在发布前集中执行一次","把单元测试脚本交给运维在周末执行"],"answer":[0],"explanation":"知识点：持续集成与自动化测试触发。持续集成可在代码提交后自动构建并执行单元测试，反馈最快。手工每日执行、发布前集中执行、周末执行均无法满足“每次提交后”的及时反馈要求。","tier":"挑战"},{"id":64,"type":"single","stem":"使用Selenium进行Web自动化测试时，页面元素在操作前需要等待其可点击，下列等待方式中稳定性通常较好的是","options":["显式等待指定元素可点击条件","固定休眠五秒后直接点击","循环点击直到不抛异常","刷新页面后立即执行点击"],"answer":[0],"explanation":"知识点：自动化测试中的等待策略。显式等待针对具体条件轮询，兼顾稳定性与效率。固定休眠浪费时间且可能仍不够；循环点击可能掩盖真实缺陷；刷新后立即点击未解决加载时序问题。","tier":"基础"},{"id":65,"type":"single","stem":"某缺陷在开发人员修复后，测试人员重新执行原失败用例并通过，同时执行了关联模块的回归用例，这一过程主要体现的缺陷管理活动是","options":["缺陷验证与回归测试","缺陷分配与优先级调整","缺陷去重与合并","缺陷统计与趋势分析"],"answer":[0],"explanation":"知识点：缺陷生命周期管理。修复后需验证原缺陷是否解决，并通过回归测试确认未引入新问题。分配、去重、统计均不涉及修复后的验证执行。","tier":"进阶"},{"id":66,"type":"single","stem":"某测试员在设计登录功能用例时，只考虑了用户名和密码均正确的情况，遗漏了密码错误、账号锁定等场景，这主要违反了用例设计的","options":["完整性原则","独立性原则","可重复性原则","可追溯性原则"],"answer":[0],"explanation":"知识点：测试用例设计原则。完整性要求覆盖正常与异常、边界等多种场景。独立性指用例间少依赖；可重复性指结果稳定；可追溯性指与需求关联，均与遗漏异常场景无直接对应。","tier":"基础"},{"id":67,"type":"single","stem":"在缺陷管理流程中，开发人员认为某缺陷不是问题并拒绝修复，测试人员不认可该结论，规范的处理方式是","options":["提交缺陷评审并由多方确认结论","直接关闭该缺陷并记录备注","将该缺陷优先级改为最低后搁置","重新提交一条相同缺陷并指派给测试经理"],"answer":[0],"explanation":"知识点：缺陷争议处理。存在分歧时应通过评审或三方确认达成结论。直接关闭会丢失问题；改优先级搁置未解决争议；重复提交会造成冗余且未走评审流程。","tier":"进阶"},{"id":68,"type":"single","stem":"某接口自动化测试脚本中，将登录返回的token硬编码在后续请求里，导致测试环境切换后脚本大量失败，正确的改进方向是","options":["在用例执行时动态提取并传递token","把token改为读取本地固定配置文件","在脚本中增加失败重试次数","将接口测试改为手工执行"],"answer":[0],"explanation":"知识点：自动化测试数据管理。token应作为关联参数在运行时提取并传递，避免环境耦合。固定配置文件仍会随环境失效；重试无法解决鉴权失败；退回手工则放弃自动化收益。","tier":"进阶"},{"id":69,"type":"single","stem":"某测试团队发现同一缺陷被三名测试人员分别提交，造成开发重复排查，为减少此类情况，最有效的措施是","options":["提交前按关键字检索已有缺陷","要求开发人员自行合并重复缺陷","限制每人每天提交缺陷的数量","关闭缺陷管理工具的邮件通知"],"answer":[0],"explanation":"知识点：缺陷去重。提交前检索可及时发现已存在的同类缺陷。让开发合并增加负担；限制数量会抑制正常提交；关闭通知会降低协作效率。","tier":"挑战"},{"id":70,"type":"single","stem":"某电商项目在“双十一”前进行性能测试，测试员发现下单接口在并发500时响应时间骤增，但服务器CPU利用率仅30%，下一步最应优先排查的是","options":["数据库连接池与慢查询情况","前端页面的图片加载大小","测试客户端的网卡带宽上限","商品详情页的静态资源缓存"],"answer":[0],"explanation":"知识点：性能瓶颈定位。CPU不高而响应骤增，常见于数据库连接池耗尽或慢查询等IO等待。前端图片、客户端带宽、静态资源缓存均与下单接口服务端处理变慢无直接关系。","tier":"挑战"},{"id":71,"type":"single","stem":"在等价类划分中，某输入框要求填写1到100之间的整数，下列哪组测试数据最能体现“有效等价类”的覆盖要求","options":["0、50、101","1、50、100","1、99、100","0、1、100、101"],"answer":[1],"explanation":"知识点是等价类划分中有效等价类的取值。有效等价类应取边界内及典型值，1、50、100均落在1到100区间内，覆盖下边界、中间值和上边界。选项0、50、101含无效值0和101，属于无效等价类；选项1、99、100虽均为有效值但缺少中间典型值，覆盖不如1、50、100充分；选项0、1、100、101混入无效值，不是纯有效等价类覆盖。","tier":"进阶"},{"id":72,"type":"single","stem":"某系统登录功能要求密码长度为8到20位且必须包含字母和数字，按边界值分析法设计测试用例时，下列哪个密码应作为长度为8的下边界有效用例","options":["abc12345","abcdefgh","12345678","abc1234"],"answer":[0],"explanation":"知识点是边界值分析中有效下边界用例需同时满足长度和字符组成要求。abc12345长度为8且含字母和数字，是有效的下边界用例。abcdefgh长度为8但只含字母，不满足字符组成要求；12345678长度为8但只含数字，同样不满足；abc1234长度为7，低于下边界，属于无效用例。","tier":"进阶"},{"id":73,"type":"single","stem":"在缺陷管理流程中，测试人员提交缺陷后，开发人员认为该问题不是缺陷而是需求设计如此，此时缺陷状态通常应流转为","options":["已修复","已关闭","已拒绝","待复测"],"answer":[2],"explanation":"知识点是缺陷状态流转。开发人员认为不是缺陷而拒绝修改时，缺陷应标记为已拒绝，由测试或需求人员进一步确认。已修复表示开发已修改代码等待验证；已关闭表示缺陷确认解决或无效后最终关闭；待复测表示修复完成等待测试验证，均不符合“开发认为不是缺陷”这一处置。","tier":"挑战"},{"id":74,"type":"single","stem":"使用Selenium进行Web自动化测试时，脚本在点击一个动态加载后才出现的按钮时频繁报元素不可见，下列处理方式中最恰当的是","options":["在点击前增加固定时长sleep等待","改用显式等待该按钮可点击","直接修改脚本忽略该次点击","将浏览器窗口最大化后重试"],"answer":[1],"explanation":"知识点是自动化测试中的等待机制。动态加载元素应使用显式等待，等待条件为该元素可点击，兼顾稳定性和效率。固定sleep等待时间难以适应加载波动，可能仍失败或浪费时间；忽略点击会使测试失去意义；最大化窗口与元素动态加载时机无关，不能解决不可见问题。","tier":"进阶"},{"id":75,"type":"single","stem":"某测试用例执行后发现实际结果与预期结果不一致，但再次执行同一用例时结果又变为通过，下列对该现象的分析中最合理的是","options":["该用例应直接标记为通过","该缺陷属于偶发缺陷需记录并追踪","应删除该用例避免误报","该用例的预期结果写错了"],"answer":[1],"explanation":"知识点是偶发缺陷的处理。结果不稳定说明可能存在并发、时序或环境依赖问题，属于偶发缺陷，应记录并追踪复现条件。直接标记通过会掩盖风险；删除用例会丢失覆盖；在未确认前判定预期结果错误缺乏依据。","tier":"挑战"},{"id":76,"type":"single","stem":"在测试用例设计评审中，发现某功能模块的用例只覆盖了正常流程，未覆盖输入非法字符、超长输入等场景，这主要违反了测试用例设计的哪项原则","options":["用例应具备可重复性","用例应覆盖有效与无效输入","用例应保持最小化","用例应优先覆盖高频操作"],"answer":[1],"explanation":"知识点是测试用例设计覆盖原则。用例需同时覆盖有效输入和无效输入，只测正常流程遗漏了异常和边界场景。可重复性指用例执行结果稳定；最小化指避免冗余；优先高频操作是执行排序策略，均不是此处缺失的核心原则。","tier":"挑战"},{"id":77,"type":"single","stem":"使用JUnit编写单元测试时，某测试方法需要验证被调用方法抛出了指定异常，下列注解用法中最合适的是","options":["@Test(expected = 异常类.class)","@Before 标注在测试方法上","@Ignore 标注在测试方法上","@Test 并捕获所有异常后不处理"],"answer":[0],"explanation":"知识点是JUnit异常测试。@Test的expected属性可声明期望抛出的异常类型，断言该异常发生。@Before用于测试前置准备，标在测试方法上语义错误；@Ignore会跳过测试；捕获异常后不处理无法验证异常是否按预期抛出。","tier":"挑战"},{"id":78,"type":"single","stem":"在缺陷报告中，“复现步骤”一栏的作用是","options":["说明缺陷的严重程度","记录缺陷被发现的时间","让开发人员能稳定重现问题","指定缺陷的修复负责人"],"answer":[2],"explanation":"知识点是缺陷报告要素。复现步骤描述操作序列和环境，目的是让开发人员能够稳定重现问题。严重程度由严重等级字段说明；发现时间由创建时间记录；修复负责人由指派字段确定，均不是复现步骤的作用。","tier":"基础"},{"id":79,"type":"single","stem":"某项目采用持续集成，每次代码提交后自动运行冒烟测试用例集，某次提交后冒烟测试失败，此时最合适的下一步处置是","options":["继续运行全量回归测试","暂停后续提交并通知开发排查","直接将该次提交回滚并关闭构建","等待下次提交后一起验证"],"answer":[1],"explanation":"知识点是持续集成中冒烟测试失败的处理。冒烟测试失败说明构建基本功能受损，应暂停后续提交并通知开发定位，避免问题扩散。继续全量回归会浪费资源且基于不可靠构建；直接回滚并关闭构建未经确认可能误判；等待下次提交会积累更多问题。","tier":"挑战"},{"id":80,"type":"single","stem":"在自动化测试脚本维护中，某页面元素的定位表达式因前端改版频繁失效，为降低维护成本，较合理的做法是","options":["为元素添加稳定的专用测试属性供脚本定位","每次改版后手动修改所有脚本中的定位","改用截图对比替代元素定位","降低自动化用例的执行频率"],"answer":[0],"explanation":"知识点是自动化测试的可维护性。为关键元素添加稳定且专用的测试属性，可使定位表达式与样式结构解耦，降低改版影响。手动逐个修改成本高且易遗漏；截图对比难以精确定位交互元素；降低执行频率不能解决定位失效问题。","tier":"进阶"},{"id":81,"type":"multi","stem":"在缺陷生命周期管理中，下列哪些操作属于测试人员通常应承担的职责","options":["提交新发现的缺陷并附复现步骤","验证开发修复后的缺陷是否通过","决定缺陷的最终修复方案","关闭确认已解决的缺陷","修改产品代码以修复缺陷"],"answer":[0,1,3],"explanation":"知识点是缺陷管理中测试人员职责。测试人员负责提交缺陷、复测修复结果并关闭确认解决的缺陷。决定修复方案通常由开发或技术负责人承担；修改产品代码属于开发职责，不是测试人员的常规职责。","tier":"进阶"},{"id":82,"type":"single","stem":"用等价类划分法为“年龄输入框（允许18至60的整数）”设计用例时，下列划分中最符合该方法要求的是","options":["有效类18~60，无效类小于18、大于60、非整数","有效类18~60，无效类17、61、abc","有效类18~59，无效类18以下、60以上","有效类18、60，无效类17、61、中间值"],"answer":[0],"explanation":"知识点：等价类划分要求按“有效/无效”区间划分，且无效类应覆盖各类非法输入。正确项把合法区间与小于18、大于60、非整数三类无效情形分开，覆盖完整。错项1把无效类写成具体点值，未体现区间划分；错项2有效类区间写成18~59，漏掉边界60；错项3把有效类写成两个边界点，混淆了边界值分析与等价类划分。","tier":"进阶"},{"id":83,"type":"single","stem":"判定表设计中，某规则的条件桩有3个条件，每个条件取“是/否”，若所有条件组合都需考虑，则规则总数应为","options":["6条","8条","9条","12条"],"answer":[1],"explanation":"知识点：判定表规则数等于各条件取值数的乘积。3个条件各取2值，规则数为2×2×2=8。错项1按3×2=6计算，误把条件数乘取值数；错项2按3×3=9计算，误用条件数的平方；错项3按3×4=12计算，无对应依据。","tier":"基础"},{"id":84,"type":"single","stem":"在缺陷管理流程中，测试人员提交缺陷后，开发人员判定为“不是缺陷”并说明原因，此时缺陷状态通常应流转为","options":["已关闭","已拒绝","已修复","待验证"],"answer":[1],"explanation":"知识点：缺陷生命周期中，开发判定不构成缺陷时应置为“已拒绝”并给出理由，由测试或评审确认。错项1“已关闭”通常是验证通过后的终态，此时尚未验证；错项2“已修复”表示开发已改代码，与“不是缺陷”矛盾；错项3“待验证”表示已修复等待回归，与场景不符。","tier":"挑战"},{"id":85,"type":"single","stem":"某缺陷在开发环境无法复现，测试人员下一步最合理的处置是","options":["直接关闭该缺陷并标注无法复现","补充复现步骤、环境版本和日志后重新指派开发","把缺陷优先级降为最低后继续保留","将该缺陷转给产品经理判定需求"],"answer":[1],"explanation":"知识点：缺陷无法复现时，应先完善复现要素再重新流转，而不是草率关闭或降级。正确项补充步骤、环境、日志，便于开发定位。错项1未补充信息直接关闭，可能漏掉真实缺陷；错项2降优先级保留而不补充信息，问题仍无法推进；错项3转产品经理属于需求争议场景，与复现问题无关。","tier":"进阶"},{"id":86,"type":"single","stem":"用Selenium编写自动化脚本时，页面元素在操作前需要等待异步加载完成，下列做法中最能兼顾稳定与效率的是","options":["使用固定sleep等待5秒再操作","使用显式等待等待目标元素可点击","使用隐式等待并设为30秒","循环刷新页面直到元素出现"],"answer":[1],"explanation":"知识点：显式等待针对具体条件轮询，兼顾稳定性与效率。正确项等待目标元素可点击，条件明确。错项1固定sleep浪费时间且仍可能不够；错项2隐式等待对所有查找生效，条件不针对可点击；错项3循环刷新会破坏页面状态且效率低。","tier":"挑战"},{"id":87,"type":"single","stem":"自动化测试中，某用例在本地通过但在CI流水线失败，日志显示“element not found”，最可能的原因是","options":["本地与CI的浏览器窗口尺寸或渲染时机不同","CI机器CPU性能低于本地开发机","测试用例的断言写错了预期结果","被测系统的数据库连接数不足"],"answer":[0],"explanation":"知识点：元素定位失败常与环境差异有关，如窗口尺寸、渲染时机、驱动版本。正确项指出窗口尺寸或渲染时机差异，符合“element not found”的典型诱因。错项1CPU性能影响速度但不直接导致找不到元素；错项2断言错误会报断言失败而非找不到元素；错项3数据库连接数不足通常表现为接口报错，不是元素定位问题。","tier":"进阶"},{"id":88,"type":"single","stem":"关于自动化测试脚本中“断言”与“验证”的区别，下列理解正确的是","options":["断言失败会中止当前用例，验证失败通常记录后继续执行","断言只用于接口测试，验证只用于界面测试","断言和验证都必须让脚本立即退出","验证失败比断言失败更严重，必须优先处理"],"answer":[0],"explanation":"知识点：断言失败一般抛出异常中止用例，验证失败记录后继续，便于收集多个问题。正确项描述了两者执行行为的差异。错项1按测试层次划分二者，属于错误归类；错项2说二者都立即退出，混淆了验证的继续执行特性；错项3比较严重程度，与二者定义无关。","tier":"进阶"},{"id":89,"type":"single","stem":"某电商项目在“双十一”前进行回归测试，时间紧、用例多，下列回归策略中最合理的是","options":["按用例编号顺序全部执行一遍","优先执行核心业务流程和高风险模块的用例","只执行上次发现的缺陷对应用例","随机抽取一半用例执行以节省时间"],"answer":[1],"explanation":"知识点：回归测试应基于风险与优先级，优先覆盖核心业务和高风险模块。正确项符合风险驱动策略。错项1按编号顺序执行未体现优先级；错项2只执行缺陷对应用例范围过窄，遗漏核心功能；错项3随机抽取缺乏依据，可能漏掉关键路径。","tier":"进阶"},{"id":90,"type":"multi","stem":"关于缺陷报告应包含的要素，下列描述正确的有","options":["缺陷标题应简明描述现象和触发条件","复现步骤应包含操作序列和输入数据","严重程度由测试人员根据影响自行确定","缺陷报告应记录发现时的环境与版本","开发人员可依据报告直接修改需求文档"],"answer":[0,1,3],"explanation":"知识点：缺陷报告要素包括标题、复现步骤、环境版本、期望与实际结果等。正确项1标题简明描述现象与条件，正确项2复现步骤含操作与数据，正确项4记录环境与版本，均属标准要素。错项1严重程度通常由测试初判、团队评审确定，不能仅凭测试自行确定；错项3缺陷报告用于修复缺陷，不能作为直接修改需求文档的依据。","tier":"进阶"},{"id":91,"type":"single","stem":"用等价类划分法为“用户名长度6~20个字符”设计用例时，下列划分方式最合理的是","options":["有效等价类取6~20，无效等价类取小于6和大于20","有效等价类取6~20，无效等价类只取小于6","有效等价类取7~19，无效等价类取小于7和大于20","有效等价类取6~20，无效等价类取0和21两个值"],"answer":[0],"explanation":"知识点：等价类划分需覆盖有效与无效区间。正确项将有效区间与两个方向的无效区间都划出，能完整覆盖边界外情况。错误项B遗漏了大于20的无效类；错误项C把有效区间错误缩小，忽略了6和20本身；错误项D把无效类只取两个点值，未按区间划分，遗漏了5、21等典型值。","tier":"挑战"},{"id":92,"type":"single","stem":"在缺陷管理流程中，测试人员提交缺陷后，开发人员标记为“无法复现”，此时测试人员最恰当的下一步操作是","options":["直接关闭该缺陷并记录为环境问题","补充复现步骤、日志和录屏后重新指派给开发","将该缺陷转交给项目经理判定责任","把缺陷优先级降到最低并等待后续版本观察"],"answer":[1],"explanation":"知识点：缺陷生命周期中“无法复现”的处理。正确项是补充可复现证据（步骤、日志、录屏）后重新指派，推动缺陷继续处理。错误项A未经核实直接关闭会漏掉真实缺陷；错误项C把技术复现问题升级为管理判定，流程不当；错误项D降级等待会延误缺陷处理，且未补充证据。","tier":"挑战"},{"id":93,"type":"single","stem":"使用 Selenium WebDriver 定位一个动态生成的按钮，其 id 每次刷新都会变化，最稳定的定位策略是","options":["使用该按钮的绝对 XPath 路径进行定位","使用按钮上固定不变的文本配合相对定位","使用按钮的 id 属性进行精确定位","使用页面加载顺序的索引进行定位"],"answer":[1],"explanation":"知识点：自动化测试中元素定位策略的稳定性。正确项利用固定文本配合相对定位，不受动态 id 影响，稳定性较好。错误项A绝对XPath极易随页面结构变动而失效；错误项C的id每次刷新变化，无法稳定定位；错误项D按索引定位在页面元素顺序变化时会错位。","tier":"进阶"},{"id":94,"type":"single","stem":"在边界值分析中，针对输入范围“1≤x≤100”的整数，下列取值集合最符合边界值分析法要求的是","options":["0、1、100、101","1、50、100","0、50、101","1、2、99、100"],"answer":[0],"explanation":"知识点：边界值分析取上点、离点及边界外侧值。正确项取0、1、100、101，覆盖下边界内侧、下边界、上边界、上边界外侧。错误项B只取边界与中间值，缺少边界外侧；错误项C缺少边界上的1和100；错误项D只取边界附近有效值，未覆盖无效边界外值。","tier":"进阶"},{"id":95,"type":"single","stem":"某缺陷在测试环境必现，但开发在本地环境无法复现，测试人员下一步最合理的做法是","options":["在缺陷报告中补充测试环境版本、配置和数据并协助开发复现","将缺陷状态改为“已修复”以便推进版本发布","要求开发必须在本机复现后才能继续处理","直接将该缺陷标记为“设计如此”并关闭"],"answer":[0],"explanation":"知识点：环境差异导致缺陷无法复现时的协作处理。正确项通过补充环境版本、配置、数据等信息，帮助开发在相同条件下复现。错误项B未修复就改状态属于流程造假；错误项C把复现责任强压给开发且未提供环境信息，不利于定位；错误项D未经确认关闭会遗漏真实缺陷。","tier":"挑战"},{"id":96,"type":"single","stem":"使用 JUnit 编写单元测试时，方法上标注 @BeforeEach 的作用是","options":["在所有测试方法执行前只运行一次","在每个测试方法执行前都运行一次","在每个测试方法执行后都运行一次","在所有测试方法执行后只运行一次"],"answer":[1],"explanation":"知识点：JUnit 生命周期注解。@BeforeEach 在每个测试方法前执行一次，用于准备独立测试环境。错误项A描述的是 @BeforeAll；错误项C描述的是 @AfterEach；错误项D描述的是 @AfterAll，三者作用时机均与 @BeforeEach 不同。","tier":"基础"},{"id":97,"type":"single","stem":"某项目采用敏捷开发，每个迭代只有两周，测试人员希望回归测试在每次代码提交后自动运行，最合适的做法是","options":["在每个迭代结束前集中执行一轮手工回归","配置持续集成流水线，在提交后触发自动化回归用例","要求开发人员提交前自行完成全部回归测试","把回归测试用例改为只覆盖新增功能"],"answer":[1],"explanation":"知识点：持续集成与自动化回归的结合。正确项在提交后由流水线触发自动化回归，能快速发现回归问题。错误项A集中手工回归反馈滞后，不符合敏捷迭代节奏；错误项C把回归责任转给开发且未自动化，仍无法及时覆盖；错误项D削减回归范围，会漏掉原有功能退化。","tier":"挑战"},{"id":98,"type":"single","stem":"在测试用例设计评审中，发现某条用例的预期结果写成了“系统正常运行”，最恰当的修改意见是","options":["保留该描述，因为运行正常已能说明预期","改为可观察的具体结果，如页面跳转地址和提示信息","删除预期结果，仅保留操作步骤","把预期结果改为“无异常”即可通过评审"],"answer":[1],"explanation":"知识点：测试用例预期结果的可验证性。正确项要求预期结果具体、可观察，便于判定通过与否。错误项A“正常运行”无法客观判定；错误项C删除预期结果使用例失去判定依据；错误项D“无异常”同样模糊，不能作为可验证的预期结果。","tier":"挑战"},{"id":99,"type":"multi","stem":"关于缺陷优先级与严重程度，下列描述正确的有","options":["严重程度高通常表示对系统功能影响大","优先级高表示应优先修复，可能与严重程度不一致","界面文字错别字严重程度低但可能优先级高","严重程度和优先级由测试人员单方面最终确定","优先级相同的缺陷严重程度必然相同"],"answer":[0,1,2],"explanation":"知识点：缺陷严重程度与优先级的区别与联系。正确项A、B、C分别说明严重程度反映影响、优先级反映修复顺序、二者可不一致。错误项D错误在于二者通常由测试与开发等共同评估，测试人员不能单方面最终确定；错误项E错误在于优先级相同不代表严重程度相同，二者维度不同。","tier":"进阶"},{"id":100,"type":"multi","stem":"某测试人员在缺陷管理平台提交缺陷后，开发人员将状态改为“已修复”，测试人员随后执行回归测试发现原缺陷现象消失但引发了一个新的关联问题，此时测试人员应在缺陷记录中执行的正确操作组合是（ ）。","options":["将原缺陷状态由“已修复”改为“重新打开”，并在备注中说明新发现的问题","针对新发现的关联问题单独提交一条新缺陷，并关联原缺陷编号","将原缺陷直接关闭，然后针对新问题另建一条缺陷记录","在未关闭原缺陷的情况下先提交新缺陷，再根据回归结论处理原缺陷状态","把新问题作为备注追加到原缺陷中，将原缺陷重新打开并继续跟踪"],"answer":[0,1],"explanation":"知识点：缺陷生命周期管理与回归测试后的状态流转。正确项0：回归测试失败说明修复未真正通过验证，应重新打开原缺陷并记录新现象，这是缺陷状态回退的标准做法。正确项1：回归引发的关联问题属于独立缺陷，需单独建单并关联原缺陷，便于追溯。错误项2：原缺陷现象虽消失但回归未通过，直接关闭会丢失验证结论，状态流转错误。错误项3：先建新缺陷再处理原缺陷的顺序本身不算错，但“根据回归结论处理原缺陷状态”表述含糊，未指明应重新打开，不能作为正确操作。错误项4：把新问题仅作为备注追加而不单独建单，会导致新缺陷无法独立跟踪和统计。","tier":"挑战"},{"id":101,"type":"single","stem":"用等价类划分法为“年龄输入框（允许18~60的整数）”设计测试用例时，下列划分中正确的是","options":["有效等价类为18~60的整数，无效等价类为小于18的整数与大于60的整数","有效等价类为18~60的整数，无效等价类为小于18的整数、大于60的整数与非整数","有效等价类为17~61的整数，无效等价类为小于17的整数与大于61的整数","有效等价类为18~60的整数，无效等价类为小于18的整数与大于60的整数及负数"],"answer":[1],"explanation":"知识点是等价类划分需覆盖所有可能输入类别。18~60整数为有效等价类；无效类应包含小于18、大于60以及非整数（如小数、字母），只写前两类会漏掉非整数输入；17~61边界错误；负数已属于小于18，单列会造成重叠。"},{"id":102,"type":"single","stem":"在缺陷生命周期中，测试人员提交缺陷后，开发人员判定“不是缺陷”并关闭，此时测试人员下一步正确的做法是","options":["重新打开该缺陷并附上复现步骤与日志，说明判定依据不足","直接新建一条相同缺陷并标注高优先级","接受关闭结论并在测试报告中记录该问题已关闭","将该缺陷转给项目经理要求强制指派给开发"],"answer":[0],"explanation":"知识点是缺陷状态流转中的争议处理。开发误判时测试应重新打开并补充证据推动复核；新建重复单会造成重复跟踪；接受关闭会漏掉真实缺陷；直接转项目经理跳过复核流程，不符合常规缺陷管理规范。"},{"id":103,"type":"single","stem":"某缺陷在测试环境可稳定复现，但在开发本地无法复现，开发据此将缺陷标记为“无法复现”并关闭，测试人员应优先采取的措施是","options":["补充环境信息、数据版本与操作录屏后重新打开缺陷","在缺陷备注中要求开发更换电脑再试一次","将该缺陷降级为建议并等待下个版本验证","在测试报告中标注该缺陷因环境差异不修复"],"answer":[0],"explanation":"知识点是缺陷复现与环境信息记录。补充环境、数据版本、录屏可帮助开发定位差异；要求换电脑未提供有效证据；直接降级会掩盖问题；在报告标注不修复属于绕过缺陷流程。"},{"id":104,"type":"single","stem":"在自动化测试中，使用数据驱动方式执行登录用例，下列做法正确的是","options":["将测试数据与测试脚本分离，脚本读取外部数据文件循环执行","把测试数据直接写死在脚本里，每次修改数据改脚本","为每条数据复制一份脚本，形成多个独立脚本文件","把测试数据放在断言中，断言失败时人工修改数据"],"answer":[0],"explanation":"知识点是数据驱动测试的核心思想。数据与脚本分离便于维护和扩展；写死数据降低可维护性；复制脚本造成冗余；把数据放断言里不符合断言用途且无法批量驱动。"},{"id":105,"type":"single","stem":"关于自动化测试与手工测试的关系，下列理解正确的是","options":["自动化测试可以完全替代手工测试","手工测试只用于自动化测试无法覆盖的场景","自动化测试适合稳定且重复执行的回归场景","自动化测试发现新缺陷的能力通常高于手工测试"],"answer":[2],"explanation":"知识点是自动化与手工测试的适用边界。自动化适合稳定、重复的回归场景；不能完全替代手工；手工测试还承担探索性、易用性等任务，不只是补充；自动化通常不擅长发现新缺陷。"},{"id":106,"type":"single","stem":"在测试用例评审中，发现某条用例的预期结果写为“系统正常”，下列修改意见中最合理的是","options":["把预期结果改为可观察、可判定的具体输出或状态","保留原描述并补充一句“由测试人员现场判断”","把该用例删除，改由探索性测试覆盖该场景","将预期结果改为“与需求一致”以便灵活判断"],"answer":[0],"explanation":"知识点是测试用例预期结果的可判定性。预期结果必须具体、可观察，如提示文案、页面跳转、数据变化；现场判断会引入主观性；删除用例会丢失覆盖；与需求一致过于笼统，无法作为通过标准。"},{"id":107,"type":"single","stem":"某项目使用持续集成，每次代码提交后自动执行冒烟测试，某次构建冒烟测试失败，正确的处置是","options":["阻止该构建进入后续测试阶段并通知相关人员修复","忽略冒烟失败继续执行完整回归以节省等待时间","先执行完整回归，若通过则视为冒烟失败可忽略","将冒烟失败记录为低优先级缺陷后继续后续流程"],"answer":[0],"explanation":"知识点是冒烟测试在持续集成中的门禁作用。冒烟失败说明基本功能不可用，应阻断后续阶段并通知修复；继续完整回归会浪费资源；完整回归通过不能否定冒烟失败；低优先级记录后继续会放过阻断性问题。"},{"id":108,"type":"single","stem":"使用 Selenium 编写 Web 自动化脚本时，页面元素加载较慢导致偶发找不到元素，下列处理方式最合理的是","options":["使用显式等待，等待目标元素满足指定条件后再操作","在查找元素前固定加长 sleep 时间到十秒","捕获异常后直接跳过该步骤继续执行","把该步骤改为手工执行，其余步骤仍自动化"],"answer":[0],"explanation":"知识点是自动化测试中的等待策略。显式等待针对具体条件，稳定且高效；固定 sleep 既慢又不保证成功；捕获异常跳步会掩盖真实失败；把步骤改手工破坏自动化完整性。"},{"id":109,"type":"multi","stem":"在缺陷管理过程中，下列做法有助于提升缺陷报告质量的有","options":["记录可复现的最小操作步骤与前置条件","附上实际结果与预期结果的对比说明","在标题中概括缺陷现象与影响模块","只写“页面报错，请修复”并附一张截图","把多个不相关缺陷合并到一条记录中提交"],"answer":[0,1,2],"explanation":"知识点是高质量缺陷报告的要素。最小复现步骤、实际与预期对比、清晰标题都有助于定位；只写报错加截图信息不足；合并不相关缺陷会导致跟踪与修复混乱。"},{"id":110,"type":"single","stem":"在等价类划分法中，若某输入字段要求为1到100之间的整数，则对无效等价类进行测试用例设计时，下列做法正确的是","options":["为每个无效等价类各设计至少一个用例，如0、101和非整数","将0和101合并为一个无效等价类，只需测试其中一个值","只测试边界值0和100，中间值无需覆盖","将1到100作为一个等价类，0和101作为另一个等价类合并测试"],"answer":[0],"explanation":"知识点是等价类划分法中无效等价类的处理原则。正确项对每个无效等价类分别设计用例，能保证各无效情况被独立覆盖。错误项将两个不同无效条件合并为一个等价类，会漏测其中一个；错误项只测边界值忽略了无效区间外的代表值；错误项把有效与无效等价类混在一起，无法区分缺陷来源。"},{"id":111,"type":"single","stem":"某支付系统要求金额输入精确到分，测试员在边界值分析时除了取0.01和99999.99，还应补充的关键边界值是","options":["0.00和100000.00","0.02和99999.98","0.01和99999.99的重复取值","1.00和10000.00"],"answer":[0],"explanation":"知识点是边界值分析中有效边界外侧的无效边界取值。正确项取刚超出有效范围的下界和上界，用于验证系统对越界金额的拒绝处理。错误项取的是有效范围内的内点，不构成边界外测试；错误项只是重复已有边界；错误项取的是中间常用值，与边界分析目的无关。"},{"id":112,"type":"single","stem":"在缺陷生命周期中，测试员提交缺陷后开发人员标记为“无法复现”，此时测试员最恰当的下一步处置是","options":["补充环境信息、操作步骤和日志后重新激活该缺陷","直接关闭该缺陷并记录为无效缺陷","新建一个相同描述的缺陷重新提交","将该缺陷优先级降为最低后保持打开"],"answer":[0],"explanation":"知识点是缺陷生命周期中“无法复现”状态的处理流程。正确项通过补充可复现证据重新激活，推动缺陷继续流转。错误项直接关闭会漏掉真实缺陷；错误项重复提单会造成缺陷库冗余；错误项降优先级但不补充信息，缺陷仍无法定位。"},{"id":113,"type":"single","stem":"某缺陷报告中写道“登录功能有时候会失败”，从缺陷报告质量角度看，该报告最主要的问题是","options":["缺少可复现的操作步骤和具体现象描述","未标注缺陷的严重程度等级","未指定修复该缺陷的开发人员","未附上测试用例的编号"],"answer":[0],"explanation":"知识点是缺陷报告应包含可复现步骤和明确现象。正确项指出该报告缺少复现路径和具体表现，导致开发无法定位。错误项严重程度可以后补，不是最主要缺陷；错误项指派开发通常由负责人处理；错误项用例编号是辅助信息，不影响缺陷可复现性。"},{"id":114,"type":"single","stem":"使用Selenium进行Web自动化测试时，脚本在本地运行正常，但在CI服务器上频繁报元素找不到，最可能的原因是","options":["CI环境页面加载速度与本地不同，元素定位前未等待条件满足","CI服务器未安装浏览器驱动导致所有元素都无法定位","Selenium版本与浏览器版本不兼容导致定位失效","测试脚本中使用了CSS选择器而非XPath定位"],"answer":[0],"explanation":"知识点是自动化测试中显式等待与运行环境差异。正确项指出环境性能差异导致元素未及时出现，应加显式等待。错误项若驱动未安装通常直接报启动失败；错误项版本不兼容往往表现为会话创建失败而非偶发找不到；错误项CSS选择器本身是合法定位方式，不是根因。"},{"id":115,"type":"single","stem":"在自动化测试框架中，将登录操作封装为公共方法供多个测试用例调用，这种做法主要体现的设计原则是","options":["提高代码复用性并降低维护成本","提高测试用例的执行速度","增加测试用例的覆盖范围","保证测试数据的独立性"],"answer":[0],"explanation":"知识点是自动化测试框架中的公共方法封装与可维护性。正确项说明封装减少重复代码，一处修改多处生效。错误项执行速度主要由等待和并发策略决定；错误项覆盖范围由用例设计决定；错误项数据独立性靠数据管理策略保证，与封装无直接关系。"},{"id":116,"type":"single","stem":"某项目采用敏捷开发，每个迭代只有两周，测试团队决定将回归测试自动化。下列最适合优先自动化的测试内容是","options":["核心业务流程的稳定回归用例","本迭代新增的探索性测试场景","界面布局和配色的人工评审项","需求仍在频繁变动的模块用例"],"answer":[0],"explanation":"知识点是自动化测试适用范围的判断。正确项核心稳定回归用例重复执行多、收益高，适合自动化。错误项探索性测试依赖人的判断，不适合；错误项界面审美评审需人工；错误项需求频繁变动会导致脚本频繁返工，投入产出比低。"},{"id":117,"type":"single","stem":"在使用JUnit编写单元测试时，某个测试方法依赖数据库中的固定数据，导致单独运行通过而全量运行失败，最合理的改进措施是","options":["在测试方法中自行准备和清理测试数据，保证用例独立","调整测试方法的执行顺序，让依赖数据的用例先运行","将该测试方法从测试套件中移除，改为手工验证","增加数据库连接池大小，避免连接不足"],"answer":[0],"explanation":"知识点是单元测试的独立性原则与测试夹具管理。正确项让用例自备数据并清理，消除执行顺序依赖。错误项靠执行顺序是脆弱的；错误项移除用例会丢失覆盖；错误项连接池大小与该失败原因无关。"},{"id":118,"type":"single","stem":"测试经理要求评估自动化测试脚本的稳定性，下列指标中最能直接反映脚本稳定程度的是","options":["脚本在多次运行中通过率的一致性","脚本单次运行的总耗时","脚本覆盖的测试用例总数","脚本中包含的断言数量"],"answer":[0],"explanation":"知识点是自动化测试稳定性的度量。正确项通过多次运行通过率的一致性反映脚本是否可靠。错误项耗时反映效率不反映稳定；错误项用例总数反映规模；错误项断言数量反映检查强度，均不能直接体现稳定性。"},{"id":119,"type":"single","stem":"用等价类划分法为“年龄输入框（合法范围18~60）”设计用例时，下列划分方式中正确的是","options":["有效等价类取18、60，无效等价类取17、61","有效等价类取19~59中任意值，无效等价类取18和60","有效等价类取18~60，无效等价类取小于18与大于60","有效等价类取18和60两个边界值，其余全为无效类"],"answer":[2],"explanation":"知识点是等价类划分的有效类与无效类定义。有效等价类应覆盖18~60整个合法区间，无效等价类为小于18和大于60；A把18、60当作有效但漏掉区间内部值且把合法端点拆散，B把合法端点18和60错划为无效类，D只取边界值属于边界值分析思路而非等价类划分。"},{"id":120,"type":"single","stem":"在缺陷管理流程中，测试人员提交缺陷后开发人员标记为“无法复现”，接下来测试人员最恰当的做法是","options":["直接关闭该缺陷并记录为无效缺陷","补充复现步骤、日志和运行环境后重新指派给开发","将缺陷优先级调低后继续保留在待修复列表","新建一条相同缺陷并抄送项目负责人"],"answer":[1],"explanation":"知识点是缺陷生命周期中“无法复现”状态的处理。正确做法是补充环境、步骤、日志等证据后重新指派，帮助开发复现；A直接关闭会漏掉真实缺陷，C调低优先级并不能推动复现，D重复建单会造成缺陷库冗余且未解决原问题。"},{"id":121,"type":"single","stem":"某登录功能需求为“用户名6~12位字母数字组合，密码至少8位且含大小写字母”，用边界值分析设计用户名长度用例，应优先选取的长度是","options":["5、6、12、13","6、7、11、12","5、6、7、12","6、12、13、20"],"answer":[0],"explanation":"知识点是边界值分析取上点、离点、内点。用户名长度合法区间为6~12，应取边界外侧5和13、边界上6和12；B全在合法区间内缺外侧离点，C缺13且多取内部点，D取20超出有效离点范围且缺5。"},{"id":122,"type":"single","stem":"使用Selenium编写自动化测试时，页面元素在操作前需等待异步渲染完成，下列等待方式中最能兼顾稳定性与执行效率的是","options":["Thread.sleep固定休眠5秒后再操作","隐式等待设置为全局30秒后直接操作","显式等待元素可点击条件成立后再操作","循环刷新页面直到元素出现再操作"],"answer":[2],"explanation":"知识点是Web自动化中的等待策略。显式等待针对具体元素条件轮询，条件满足即继续，兼顾稳定与效率；A固定休眠浪费时间且可能仍不够，B隐式等待对可点击等复杂条件支持有限且全局设置影响其他操作，D刷新页面会破坏会话状态并不可靠。"},{"id":123,"type":"single","stem":"测试报告中统计缺陷密度时，通常用“缺陷数/代码行数（KLOC）”作为指标，该指标主要用于","options":["衡量单个缺陷的严重程度等级","评估模块相对质量并定位高风险区域","计算缺陷修复所需的平均工时","判断测试用例执行的覆盖率"],"answer":[1],"explanation":"知识点是缺陷密度指标含义。缺陷密度反映单位规模代码中的缺陷数量，用于横向比较模块质量、识别高风险区域；A严重程度由缺陷等级定义，C是修复工时指标，D由用例覆盖率衡量，均与缺陷密度无关。"},{"id":124,"type":"single","stem":"对某支付接口做性能测试，需求为“在500并发下响应时间95%不超过2秒”，执行后统计结果为P95=2.4秒，正确的结论是","options":["响应时间满足需求，因为平均值低于2秒","响应时间不满足需求，95%分位已超过2秒","需重新执行，性能测试结果存在随机波动","应降低并发到400再判断是否达标"],"answer":[1],"explanation":"知识点是性能测试中的分位数指标判定。需求明确以P95≤2秒为准，实测2.4秒即不达标；A平均值不能替代分位要求，C不能因结果不利就否定有效测试，D擅自降低并发改变了需求约定条件，均属错误处置。"},{"id":125,"type":"single","stem":"在Git协作中，测试人员发现开发提交的修复分支存在回归缺陷，正确的反馈方式是","options":["在该分支直接修改代码后提交修复","在缺陷单中关联分支、提交号和失败用例证据并指派开发","将该分支合并到主干后由主干测试暴露问题","在本地回滚该分支并通知开发重新提交"],"answer":[1],"explanation":"知识点是缺陷反馈与版本协作规范。测试人员应保留证据并关联具体提交指派开发修复；A越权改代码破坏职责边界，C把有缺陷分支合入主干会污染主线，D本地回滚不能替代正式缺陷流程。"},{"id":126,"type":"single","stem":"某电商项目采用敏捷迭代，测试人员在迭代中期发现需求文档与已实现功能不一致，最合适的处理步骤是","options":["按需求文档为准提交缺陷要求开发修改","按已实现功能为准更新测试用例并放行","与产品、开发确认口径后统一需求并同步用例","暂停该模块测试等待下个迭代再澄清"],"answer":[2],"explanation":"知识点是敏捷中需求变更与测试协同。正确做法是三方确认口径后统一需求与用例，避免误判；A单方以文档为准可能文档已过时，B单方以实现为准可能放过需求偏差，D暂停测试会阻塞迭代交付。"},{"id":127,"type":"single","stem":"使用Postman对REST接口做自动化断言时，要校验响应体JSON中字段“status”值为“success”，应采用的断言方式是","options":["在Tests中用pm.response.json().status判断等于success","在Pre-request中设置环境变量status为success","在Headers中新增status:success后发送请求","在Params中传入status=success作为查询条件"],"answer":[0],"explanation":"知识点是接口测试断言位置与对象。断言应写在Tests脚本中解析响应体并比较字段值；B在请求前设置变量不是对响应做校验，C在请求头加字段不校验响应，D把校验值当请求参数改变了接口调用语义。"},{"id":128,"type":"single","stem":"对一段涉及金额计算的代码做单元测试，需覆盖“满减、折扣、无优惠”三种业务规则，最合适的设计方法是","options":["仅用随机金额大量执行以发现异常","用判定表梳理条件组合并据此设计用例","只对每种规则各取一个典型金额验证","按代码行数平均分配用例数量"],"answer":[1],"explanation":"知识点是判定表在业务规则组合测试中的应用。满减、折扣、无优惠属于条件组合，判定表可系统覆盖组合避免遗漏；A随机测试难以保证规则覆盖，C单值验证漏掉边界与组合，D按行数分配与业务规则无关。"},{"id":129,"type":"single","stem":"某缺陷在测试环境可稳定复现，但在生产环境无法复现，测试人员下一步最合理的处置是","options":["判定为环境差异缺陷并直接关闭","对比两环境差异并补充生产侧日志后再定位","要求开发按测试环境结果直接修复上线","将缺陷严重级别降为最低后搁置观察"],"answer":[1],"explanation":"知识点是环境相关缺陷的定位方法。应对比配置、数据、版本等差异并补充生产日志，缩小定位范围；A未定位就关闭会漏缺陷，C忽略环境差异可能误修，D降级搁置不能解决复现差异问题。"},{"id":130,"type":"multi","stem":"关于自动化测试用例的维护，下列做法中合理的有","options":["页面元素定位优先使用稳定的唯一属性而非绝对路径","对频繁变动的页面区域采用页面对象模型封装","用例失败时统一重跑三次仍失败才判定为缺陷","为提升覆盖把手工探索用例全部转为自动化脚本","定期清理长期失败且业务已下线的自动化用例"],"answer":[0,1,4],"explanation":"知识点是自动化用例可维护性实践。A用稳定定位减少脆弱性，B用页面对象模型隔离变化，E定期清理失效用例保持套件健康；C统一重跑三次会掩盖真实缺陷且拖慢反馈，D把探索性用例全部自动化不现实且违背探索测试目的。"},{"id":131,"type":"single","stem":"某测试员为一个电商下单接口设计用例，需求规定“库存充足时下单成功并扣减库存”，他除设计正常下单用例外，还设计了库存为0、库存等于购买量、库存小于购买量三种边界用例，这主要体现了哪项测试用例设计原则","options":["边界值分析覆盖临界条件","等价类划分减少冗余用例","因果图推导输入输出关系","正交试验平衡多因素组合"],"answer":[0],"explanation":"知识点是黑盒用例设计方法。库存0、等于、小于购买量都是边界附近的临界取值，属于边界值分析；等价类划分侧重把输入划分成有效无效区间而非专挑临界点；因果图用于输入条件与输出结果的逻辑组合；正交试验用于多因素多水平的组合压缩，与本题单因素临界场景不符。"},{"id":132,"type":"single","stem":"测试员提交缺陷后，开发回复“不是缺陷，是需求如此”，测试员核对需求文档发现文档对该行为未作任何说明，此时较妥当的处置是","options":["直接关闭缺陷并在备注写明非缺陷","请需求方确认预期行为后再决定缺陷状态","把缺陷标记为已修复并继续下一轮测试","将该缺陷降级为建议并转给产品经理归档"],"answer":[1],"explanation":"知识点是缺陷生命周期中的争议处理。需求未定义时预期行为不确定，应请需求方澄清后再定状态；直接关闭等于替需求方下结论；标记已修复属于状态造假；降级归档绕过了澄清环节，可能掩盖真实缺陷。"},{"id":133,"type":"single","stem":"某缺陷在测试环境稳定复现，但开发在本地环境无法复现并因此拒绝修复，测试员下一步最有效的做法是","options":["提供复现步骤、日志、数据快照与环境版本信息","把缺陷直接升级为严重级别迫使开发处理","在缺陷描述中补充一句“多试几次就能复现”","将该缺陷转为需求变更单交由产品评估"],"answer":[0],"explanation":"知识点是缺陷复现与信息完整性。环境差异导致的复现分歧要靠完整证据链消除，包括步骤、日志、数据与环境版本；升级级别不能解决复现差异；含糊描述无助于定位；转需求单回避了缺陷本身。"},{"id":134,"type":"single","stem":"测试员编写登录功能用例时，把“用户名正确、密码错误”和“用户名错误、密码正确”合并为一条用例执行，这种合并的主要风险是","options":["用例执行时间被明显拉长","不同错误分支的提示信息可能被漏测","用例编号无法被测试管理工具识别","自动化脚本无法读取该条用例"],"answer":[1],"explanation":"知识点是用例粒度与覆盖。两种输入组合对应不同的错误分支与提示语，合并后只验证其中一个结果就会漏测另一分支；合并通常缩短而非拉长执行时间；编号识别和脚本读取与是否合并无必然关系。"},{"id":135,"type":"single","stem":"某团队用 Postman 做接口测试，把登录接口返回的 token 通过环境变量传给后续下单接口使用，这种做法主要解决了什么问题","options":["接口请求之间的状态依赖","接口响应时间的统计误差","请求参数的加密传输问题","接口文档与实现不一致问题"],"answer":[0],"explanation":"知识点是接口测试的关联与变量传递。token 是登录后产生的动态凭据，用环境变量在请求间传递实现了有状态接口链的依赖；响应时间统计、参数加密、文档一致性都不是变量传递能解决的。"},{"id":136,"type":"single","stem":"测试员在缺陷报告中写“点击保存按钮后页面卡死”，但未写明浏览器版本、账号权限和操作前置数据，评审时该缺陷被退回，退回的最主要理由是","options":["缺陷标题描述不够简洁","缺陷缺少可复现的必要环境与前置条件","缺陷未附带修复建议代码","缺陷未标注对应的测试用例编号"],"answer":[1],"explanation":"知识点是缺陷报告要素。复现所需的环境、权限、数据属于必要信息，缺失会导致开发无法定位；标题简洁度、修复代码、用例编号都不是退回该缺陷的核心原因。"},{"id":137,"type":"single","stem":"某项目采用关键字驱动方式编写自动化测试，将“打开浏览器、输入用户名、点击登录”等操作封装为独立关键字，这样设计带来的主要好处是","options":["用例脚本与具体实现细节解耦便于维护","自动化用例的执行速度大幅提升","测试用例的缺陷检出率显著提高","脚本可以完全替代手工探索性测试"],"answer":[0],"explanation":"知识点是自动化框架设计思想。关键字驱动把操作步骤抽象为关键字，使脚本与底层实现解耦，便于复用和维护；它不直接提升执行速度或检出率；自动化也不能替代探索性测试。"},{"id":138,"type":"single","stem":"测试员对一个输入框设计用例，需求规定“长度1到20个字符”，他设计的用例中有一组是空字符串、1个字符、20个字符、21个字符，这组用例覆盖了","options":["仅有效等价类的边界","有效与无效等价类的边界","仅无效等价类的边界","全部等价类的中间值"],"answer":[1],"explanation":"知识点是边界值分析。1和20是有效边界，空字符串和21是无效边界，因此覆盖了有效与无效两类的边界；说仅有效或仅无效都不完整；中间值并非这组用例的取样点。"},{"id":139,"type":"single","stem":"某测试员在回归测试时只执行了上一轮失败的用例，未执行核心功能的通过用例，结果上线后核心下单流程出现故障，这暴露出的主要问题是","options":["回归测试范围选取过于狭窄","自动化脚本断言写得不够严格","缺陷优先级划分标准缺失","测试环境与生产环境版本不一致"],"answer":[0],"explanation":"知识点是回归测试策略。回归应覆盖变更影响范围与核心功能，只跑失败用例会遗漏被改动波及的通过用例；断言严格度、优先级标准、环境版本都不是本例直接暴露的问题。"},{"id":140,"type":"multi","stem":"某测试员准备把一批手工用例转为自动化脚本，以下哪些用例相对更适合优先自动化","options":["每次版本都要执行的核心业务流程用例","需求频繁变动且界面仍在调整的用例","需要大量数据组合驱动的参数化用例","仅执行一次的临时探索性用例"],"answer":[0,2],"explanation":"知识点是自动化用例选取标准。核心流程回归频繁、数据驱动组合多用例适合自动化；需求频繁变动导致脚本维护成本高，不适合优先自动化；一次性探索性用例靠人工判断，不适合脚本化。"},{"id":141,"type":"single","stem":"在等价类划分法中，某输入框要求输入1到100之间的整数，下列哪组测试数据最能体现\"有效等价类+无效等价类\"的完整覆盖？","options":["50、0、101","50、1、100","1、50、100","0、50、101"],"answer":[0],"explanation":"知识点是等价类划分需同时覆盖有效类和无效类。50属有效类，0和101分别代表低于下界和高于上界的无效类，覆盖最完整。选项1只有有效类无无效类；选项2三个均为有效类边界；选项3是有效类加一个无效类，遗漏另一侧无效类。"},{"id":142,"type":"single","stem":"某电商系统登录模块，需求为\"用户名6-12位字母，密码8-16位且必须含数字和字母\"，设计测试用例时下列做法正确的是","options":["对用户名和密码分别做等价类划分后组合覆盖","只对密码做边界值分析即可覆盖用户名","把用户名和密码当作一个整体做一个等价类","随机生成若干账号密码进行冒烟测试"],"answer":[0],"explanation":"多输入条件应分别划分等价类再组合，才能保证覆盖。只测密码会遗漏用户名规则；合并成一个等价类无法区分各字段约束；随机测试无法保证覆盖系统性，不能替代等价类设计。"},{"id":143,"type":"single","stem":"使用边界值分析法为\"年龄15-60岁可注册\"设计用例，下列哪组边界数据最符合标准边界值取法？","options":["14、15、60、61","15、30、60","14、15、59、60","15、16、59、60"],"answer":[0],"explanation":"边界值分析取上点、离点、内点，即刚好在边界两侧及边界上：14、15、60、61。选项1缺边界外点；选项2取的是边界和中间值；选项3取的是14、15、59、60，缺少上界外点61。"},{"id":144,"type":"single","stem":"在缺陷生命周期中，开发人员认为\"这不是缺陷，是需求如此\"，此时测试人员应将该缺陷状态置为","options":["已拒绝","已延期","重新打开","已关闭"],"answer":[0],"explanation":"开发判定非缺陷即拒绝（Rejected），需测试复核。已延期是确认缺陷但推迟修复；重新打开是针对已修复但仍存在缺陷；已关闭是验证通过后关闭，均不符合该场景。"},{"id":145,"type":"single","stem":"某缺陷被标记为\"无法复现\"，测试人员下一步最恰当的做法是","options":["补充日志、截图与复现步骤后再次提交验证","直接把缺陷关闭并记录为无效缺陷","把缺陷转给产品经理判断需求","降低缺陷优先级后继续观察"],"answer":[0],"explanation":"无法复现时应补充环境、日志、步骤等信息再提交。直接关闭会漏掉真实缺陷；转产品经理与复现无关；降优先级并不能解决可复现性，仍可能遗漏问题。"},{"id":146,"type":"single","stem":"缺陷报告中\"严重程度\"与\"优先级\"的关系，下列描述正确的是","options":["严重程度高不一定优先级高，二者独立评估","严重程度高则优先级必然高","优先级高则严重程度必然高","二者是同一指标的不同叫法"],"answer":[0],"explanation":"严重程度衡量对系统的影响，优先级衡量修复紧迫性，二者独立。例如界面文字错误严重程度低但优先级可能高。其余选项把二者等同或建立必然联系，均错误。"},{"id":147,"type":"single","stem":"在自动化测试中，某用例依赖前一个用例创建的数据，单独运行时失败，这属于典型的","options":["用例间存在依赖耦合","测试环境配置错误","定位器失效问题","断言逻辑错误"],"answer":[0],"explanation":"单独运行失败、连跑成功说明用例间存在数据或状态依赖。环境配置错误会影响所有用例；定位器失效与前后顺序无关；断言错误通常是稳定失败，与顺序无关。"},{"id":148,"type":"single","stem":"关于自动化测试适用场景，下列判断正确的是","options":["回归测试、接口稳定且重复执行的场景适合自动化","一次性探索性测试适合优先自动化","界面频繁变更的模块适合大规模UI自动化","需求尚未确定的新功能适合先做自动化"],"answer":[0],"explanation":"自动化适合稳定、重复、回归类场景。探索性测试依赖人的判断不宜自动化；界面频繁变更会导致脚本维护成本高；需求未定则脚本频繁返工，均不适合。"},{"id":149,"type":"single","stem":"某接口返回JSON中字段\"status\"取值应为0或1，测试用例设计时下列覆盖最合理的是","options":["分别验证status为0、1及非0/1的异常值","只验证status为0和1两种正常值","只验证status为1的正常场景","随机选取若干status值进行测试"],"answer":[0],"explanation":"应覆盖有效值0、1及无效值如2、null等。只测正常值遗漏异常分支；只测一个值覆盖不全；随机测试无法保证覆盖两个有效值和异常边界。"},{"id":150,"type":"single","stem":"测试人员发现一个偶现崩溃缺陷，复现概率约10%，提交缺陷报告时最恰当的做法是","options":["记录复现步骤、出现频率及日志，标注为偶现缺陷","因无法稳定复现暂不上报，继续观察","按必现缺陷描述并声称每次都崩溃","只截一张崩溃图，无需其他信息"],"answer":[0],"explanation":"偶现缺陷也应上报，并注明频率、日志、环境以帮助定位。暂不上报可能漏掉严重问题；谎称必现会误导开发；仅截图缺少关键信息不利于排查。"},{"id":151,"type":"multi","stem":"关于黑盒测试中的因果图法，下列描述正确的有","options":["因果图用于处理输入条件之间的组合与约束关系","因果图可将逻辑关系转换为判定表进而设计用例","因果图法只适用于单输入条件的简单场景","因果图能替代边界值分析完成所有用例设计"],"answer":[0,1],"explanation":"因果图用于分析输入条件组合及约束，并可转判定表设计用例，故前两项正确。它面向多条件组合，不限于单输入；也不能替代边界值等其他方法，故后两项错误。"},{"id":152,"type":"single","stem":"某电商项目在需求评审后编写测试用例，产品经理提出“满200减30”与“满300减50”两种促销规则可叠加使用，测试员设计用例时最应优先覆盖的测试点是","options":["两种优惠券的叠加计算顺序","促销活动页面的字体大小","商品详情页的图片加载速度","用户注册时的密码强度"],"answer":[0],"explanation":"知识点是等价类与边界值在业务规则组合中的应用。促销规则叠加的核心风险在计算逻辑，故应优先覆盖叠加计算顺序。页面字体、图片加载、密码强度均属其他功能或非功能维度，与促销叠加规则无直接关系。"},{"id":153,"type":"single","stem":"测试员在缺陷管理工具中提交一个“订单提交后金额为负数”的缺陷，开发回复“无法复现”并直接关闭，测试员下一步最恰当的做法是","options":["补充复现步骤、日志和环境信息后重新激活","接受关闭并在下个版本不再验证该场景","将该缺陷改为“设计如此”后关闭","在缺陷标题后加“紧急”并重新提交新缺陷"],"answer":[0],"explanation":"知识点是缺陷生命周期中“无法复现”的处理。正确做法是补充复现步骤、日志和环境后重新激活，便于开发定位。直接接受关闭会漏掉真实缺陷；改为“设计如此”是错误定性；重复提交新缺陷会破坏缺陷追踪的连续性。"},{"id":154,"type":"single","stem":"使用 Selenium 对登录页做自动化测试，脚本在本地稳定通过，接入 CI 后频繁失败并提示元素不可见，最可能的原因是","options":["CI 环境未等待页面异步加载完成","本地浏览器版本比 CI 环境更新","登录页的 HTML 标签语义不正确","测试数据中的用户名长度不一致"],"answer":[0],"explanation":"知识点是自动化测试中的等待机制与环境差异。CI 机器性能或网络差异导致异步渲染慢，需显式等待。浏览器版本更新通常导致兼容错误而非不可见；标签语义不影响 Selenium 可见性判断；用户名长度与元素不可见无直接因果。"},{"id":155,"type":"single","stem":"某支付接口的测试用例中，金额字段要求为 0.01 至 50000.00 元、最多两位小数，下列取值组合中边界值设计最完整的一组是","options":["0.00、0.01、50000.00、50000.01","0.01、1.00、49999.99、50000.00","0.00、0.01、0.02、50000.00","0.01、0.02、49999.99、50000.01"],"answer":[0],"explanation":"知识点是边界值分析：应取略小于最小值、最小值、最大值、略大于最大值。0.00 与 50000.01 分别是无效边界，配合 0.01 和 50000.00 覆盖完整。其余选项缺少一侧无效边界或混入中间值，边界覆盖不完整。"},{"id":156,"type":"single","stem":"测试员用等价类划分法为“年龄 18 至 60 可办理”设计用例，下列划分中最符合等价类划分原则的是","options":["有效类 18 至 60，无效类小于 18 和大于 60","有效类 18 至 30，无效类 31 至 60","有效类 18、60，无效类 17、61","有效类 18 至 60，无效类 0 至 17"],"answer":[0],"explanation":"知识点是等价类划分的有效类与无效类划分。年龄区间应划分为一个有效类 18 至 60 和两个无效类小于 18、大于 60。把有效区间再切分不减少用例且非必要；只取端点属于边界值思路；无效类漏掉大于 60 一侧。"},{"id":157,"type":"single","stem":"使用 JUnit 编写单元测试时，测试方法执行前需要初始化数据库连接，执行后需要释放连接，应使用的注解组合是","options":["@BeforeEach 与 @AfterEach","@BeforeAll 与 @AfterAll","@Test 与 @Ignore","@DisplayName 与 @Disabled"],"answer":[0],"explanation":"知识点是 JUnit 生命周期注解。每个测试方法前后各执行一次初始化与释放，应使用 @BeforeEach 与 @AfterEach。@BeforeAll/@AfterAll 只在整个类前后执行一次；@Test 是测试方法本身；@DisplayName 与 @Disabled 与初始化释放无关。"},{"id":158,"type":"single","stem":"某团队在回归测试阶段发现，同一批用例在开发修复缺陷后仍然失败，日志显示接口返回 500 错误，此时测试员首先应确认的是","options":["失败用例是否覆盖了本次修复的代码路径","失败用例的编写时间是否早于本次迭代","失败用例是否由自动化脚本执行","失败用例的优先级是否为最高"],"answer":[0],"explanation":"知识点是回归测试中的失败分析。修复后仍失败，应先确认用例是否命中本次修复路径，判断是修复未生效还是引入了新缺陷。用例编写时间、是否自动化、优先级高低都不直接决定失败根因。"},{"id":159,"type":"single","stem":"测试员在设计“用户登录”用例时，把“用户名正确、密码错误”“用户名错误、密码正确”“用户名和密码都错误”合并在一条用例中依次执行，这种做法最可能带来的问题是","options":["前一步失败会影响后续步骤的独立性","用例执行时间会显著缩短","用例的优先级无法正确设置","用例无法关联到需求编号"],"answer":[0],"explanation":"知识点是用例的独立性与原子性。多条场景合并会导致前一步失败影响后续执行，掩盖真实结果。合并用例通常减少而非增加执行时间；优先级和需求关联与合并本身无必然冲突。"},{"id":160,"type":"single","stem":"某项目采用敏捷开发，每个迭代两周，测试员在迭代中期发现需求频繁变更导致用例维护成本高，最有效的应对措施是","options":["将用例按业务功能模块化并建立需求追踪矩阵","停止编写新用例只执行已有用例","把所有手工用例一次性转为自动化脚本","要求产品经理在迭代结束前不再变更需求"],"answer":[0],"explanation":"知识点是敏捷环境下的测试用例维护策略。模块化与需求追踪矩阵可降低变更影响范围。停止编写新用例会漏测；盲目全量自动化成本高且不稳定；要求冻结需求不符合敏捷实践。"},{"id":161,"type":"multi","stem":"在缺陷管理流程中，下列做法有助于提升缺陷修复效率的有","options":["缺陷报告附带可复现的最小步骤和日志","为每个缺陷指定明确的严重程度和优先级","缺陷标题只写“有问题”以便快速提交","修复后由原提交测试员进行回归验证","将多个不相关的缺陷合并为一个缺陷单"],"answer":[0,1,3],"explanation":"知识点是缺陷管理最佳实践。附带复现步骤与日志、明确严重程度与优先级、由原提交人回归验证都有助于修复效率。标题写“有问题”信息不足；合并不相关缺陷会破坏追踪与验证，均不利于效率。"},{"id":162,"type":"single","stem":"某测试人员在设计登录功能测试用例时，把用户名和密码都取边界值组合后逐条执行，却发现遗漏了「用户名正确但密码为空」的情形，这最可能是哪类用例设计疏漏","options":["等价类划分时未单独划分空值等价类","边界值分析时未取最小值减一","判定表设计时未列出条件桩","场景法设计时未画基本流"],"answer":[0],"explanation":"知识点：等价类划分。空值属于有效/无效等价类中的特殊无效类，应单独划分，否则组合时会漏掉。边界值分析关注数值边界，空值不是数值边界；判定表未列条件桩会漏更多条件组合，但题干只漏空值一类；场景法关注业务流程，与此处单字段空值无关。"},{"id":163,"type":"single","stem":"执行一条测试用例时实际结果与预期结果不一致，测试员在提交缺陷报告前应先做哪项工作","options":["确认环境与步骤后复现一次并保留日志","直接修改用例预期结果使其通过","通知开发人员口头说明问题","将该用例标记为通过并继续执行"],"answer":[0],"explanation":"知识点：缺陷管理流程。提交缺陷前应复现并保留证据，避免误报。修改预期结果属于掩盖缺陷；仅口头通知不符合缺陷可追溯要求；标记通过会漏掉缺陷。"},{"id":164,"type":"single","stem":"使用 JUnit 编写单元测试时，若被测方法依赖数据库连接，为让测试可重复且快速，通常采用的做法是","options":["用 Mock 对象替换数据库访问层","每次测试连接真实生产数据库","把数据库连接超时调大后重试","在测试方法中手动开启事务并回滚"],"answer":[0],"explanation":"知识点：单元测试隔离。用 Mock 隔离外部依赖可保证快速可重复。连生产库有数据污染风险；调大超时不能解决依赖问题；手动事务回滚仍依赖真实数据库，速度慢且环境要求高。"},{"id":165,"type":"single","stem":"某缺陷报告中只写了「登录失败」，未写复现步骤、环境和账号信息，导致开发无法定位，这违反了缺陷报告哪项基本要求","options":["可复现性与信息完整性","缺陷严重性分级","缺陷优先级排序","缺陷状态流转"],"answer":[0],"explanation":"知识点：缺陷报告要素。报告需含复现步骤、环境、数据等，保证可复现。严重性与优先级是分级维度；状态流转是流程管理，均不是本条缺失的核心。"},{"id":166,"type":"single","stem":"某次回归测试中，测试员发现一个已关闭的缺陷在新版本中再次出现，正确的缺陷状态处理是","options":["将该缺陷重新打开并关联新版本信息","新建一条缺陷并把旧缺陷标记为重复","把旧缺陷状态改为已修复并追加备注","把新缺陷直接关闭并注明历史遗留"],"answer":[0],"explanation":"知识点：缺陷回归与重开。已关闭缺陷复现应重开并关联版本。新建重复单会割裂历史；旧缺陷已修复状态不真实；直接关闭会漏掉回归失败。"},{"id":167,"type":"multi","stem":"某测试团队准备引入自动化测试，下列做法中有利于提高脚本可维护性的有","options":["将页面元素定位信息集中到页面对象类中","对公共操作封装为可复用的关键字或方法","为每条用例硬编码元素绝对路径和等待时间","在脚本中直接写死测试账号与生产库连接串","为脚本加入版本控制并定期评审"],"answer":[0,1,4],"explanation":"知识点：自动化测试框架设计。页面对象、关键字封装、版本控制评审均提升可维护性。硬编码绝对路径和等待时间使脚本脆弱；写死账号与生产库连接串既难维护又有安全风险。"},{"id":168,"type":"single","stem":"用等价类划分法为“年龄输入框（允许18~60的整数）”设计测试用例时，下列哪个输入值属于有效的边界值","options":["17","18","19","61"],"answer":[1],"explanation":"知识点：边界值分析中，有效边界取边界上的值。18是有效区间的下边界，属于有效边界值，正确。17是下边界的下侧无效值，属于无效边界。19是有效区间内的普通值，不是边界值。61是上边界的上侧无效值，属于无效边界。"},{"id":169,"type":"single","stem":"某缺陷在开发人员修复后由测试人员重新执行原失败用例并通过，但随后发现该修复导致另一个模块出现新问题，这种缺陷状态变化应记录为","options":["缺陷重开","缺陷回归","缺陷引入","缺陷延期"],"answer":[2],"explanation":"知识点：缺陷修复引发的新问题属于回归缺陷/缺陷引入。修复导致其他模块出现新问题，应记录为引入的新缺陷，正确。缺陷重开指原缺陷修复无效需再次打开，与原场景不符。缺陷回归是验证修复是否影响既有功能的动作，不是缺陷状态名。缺陷延期指因故推迟修复，与场景无关。"},{"id":170,"type":"single","stem":"使用Selenium编写自动化脚本时，页面元素在点击前需要等待异步加载完成，下列等待方式中最适合应对“元素可见但尚不可点击”这一情形的是","options":["强制等待固定秒数","隐式等待全局生效","显式等待指定条件","线程休眠固定时长"],"answer":[2],"explanation":"知识点：显式等待可针对特定条件（如element_to_be_clickable）等待。显式等待指定条件能精确等待元素可点击，正确。强制等待固定秒数不判断条件，可能过短或过长。隐式等待只针对元素存在，不保证可点击。线程休眠固定时长与强制等待类似，属于盲目等待。"},{"id":171,"type":"single","stem":"某测试用例执行后实际结果与预期结果不一致，但经确认是测试用例中预期结果写错了，此时对该缺陷的正确处置是","options":["提交为有效缺陷","关闭并修改用例","标记为重复缺陷","转为需求变更"],"answer":[1],"explanation":"知识点：缺陷判定需先确认预期结果是否正确。预期结果写错属于用例问题，应关闭并修正用例，正确。提交为有效缺陷会把用例错误误报为产品缺陷。标记为重复缺陷与重复无关。转为需求变更属于需求层面流程，与用例笔误不符。"},{"id":172,"type":"single","stem":"在自动化测试中，为提高脚本稳定性，对动态变化的元素定位优先采用的方式是","options":["绝对XPath路径","元素索引位置","稳定属性组合","页面文本内容"],"answer":[2],"explanation":"知识点：自动化定位应选择稳定且唯一的属性。稳定属性组合（如id、name、自定义属性）不易随页面结构变化，正确。绝对XPath路径依赖层级，结构一变即失效。元素索引位置随元素增减而漂移。页面文本内容可能随多语言或文案调整而变化。"},{"id":173,"type":"single","stem":"某项目采用敏捷开发，测试人员希望在每次代码提交后自动运行单元测试并反馈结果，最合适的实践是","options":["每日构建","持续集成","验收测试","探索测试"],"answer":[1],"explanation":"知识点：持续集成强调代码提交后自动构建与测试。持续集成在每次提交后自动触发构建和测试并反馈，正确。每日构建频率为每天一次，无法覆盖每次提交。验收测试关注业务验收，不是提交触发。探索测试是人工设计执行，无法自动反馈。"},{"id":174,"type":"single","stem":"对一个登录功能设计测试用例时，下列哪项属于“错误推测法”的典型应用","options":["按用户名长度划分等价类","根据经验列出密码含空格的异常场景","用正交表组合浏览器与分辨率","覆盖所有判定条件的真假组合"],"answer":[1],"explanation":"知识点：错误推测法依赖经验推测易错场景。根据经验列出密码含空格等异常场景属于错误推测，正确。按长度划分等价类属于等价类划分法。正交表组合属于正交试验法。覆盖判定条件真假组合属于判定覆盖或决策表方法。"},{"id":175,"type":"single","stem":"缺陷报告中“可复现性”字段填写为“偶现”时，测试人员最应补充的信息是","options":["缺陷优先级","复现步骤与频率","开发人员姓名","预计修复工时"],"answer":[1],"explanation":"知识点：偶现缺陷需提供尽可能多的复现线索。补充复现步骤与出现频率有助于定位，正确。缺陷优先级是分级字段，不能帮助复现。开发人员姓名与复现无关。预计修复工时属于开发评估，不是测试补充内容。"},{"id":176,"type":"single","stem":"使用JUnit编写测试方法时，若希望在每个测试方法执行前都重新初始化测试数据，应使用的注解是","options":["@Test","@Before","@After","@Ignore"],"answer":[1],"explanation":"知识点：JUnit中@Before在每个测试方法前执行。@Before用于每个测试方法执行前的初始化，正确。@Test标记测试方法本身。@After在每个测试方法后执行，用于清理。@Ignore用于跳过测试方法。"},{"id":177,"type":"single","stem":"某电商系统在促销活动上线前，测试团队需要验证系统在预计峰值并发下的表现，此时应重点执行的测试类型是","options":["兼容性测试","性能测试","易用性测试","安装测试"],"answer":[1],"explanation":"知识点：峰值并发下的系统表现属于性能测试范畴。性能测试验证系统在预期负载下的响应与稳定性，正确。兼容性测试关注不同环境适配。易用性测试关注用户体验。安装测试关注部署安装过程。"},{"id":178,"type":"multi","stem":"在缺陷生命周期管理中，下列哪些操作会改变缺陷的状态字段","options":["测试人员提交新缺陷","开发人员将缺陷标记为已修复","测试人员验证通过后关闭缺陷","测试人员修改缺陷的标题描述","产品经理调整缺陷的优先级"],"answer":[0,1,2],"explanation":"知识点：缺陷状态随处理流程变化。提交新缺陷使其进入新建状态，正确。标记已修复使状态变为已修复，正确。验证通过关闭使状态变为关闭，正确。修改标题描述属于内容编辑，不改变状态。调整优先级属于属性修改，不改变状态。"},{"id":179,"type":"single","stem":"为“用户登录”功能设计测试用例时，密码框要求输入6至12位字符，按等价类划分法，下列哪组输入能同时覆盖两个有效等价类边界？","options":["输入5位字符和13位字符","输入6位字符和12位字符","输入6位字符和13位字符","输入5位字符和12位字符"],"answer":[1],"explanation":"知识点是等价类划分中的边界值分析，有效等价类的两个边界分别是6位和12位，取这两个值可同时覆盖有效边界。输入5位和13位属于无效等价类，不能覆盖有效边界；6位和13位混入了无效值；5位和12位也混入了无效值。"},{"id":180,"type":"single","stem":"某测试员提交缺陷后，开发人员回复“无法复现”并将缺陷置为“已解决”，测试员下一步应优先执行的操作是？","options":["直接关闭该缺陷并记录为无效缺陷","补充复现步骤与环境信息后重新打开缺陷","将该缺陷转交给项目经理判定责任","等待下一个版本发布后再尝试复现"],"answer":[1],"explanation":"知识点是缺陷生命周期中“无法复现”状态的处置。正确做法是补充复现步骤、环境、数据等证据后重新打开，推动开发确认。直接关闭会漏掉真实缺陷；转交项目经理不是测试员对缺陷验证的首要动作；等待下一版本会延误缺陷处理时机。"},{"id":181,"type":"single","stem":"在缺陷报告中，“严重程度”与“优先级”的关系，下列描述正确的是？","options":["严重程度高则优先级一定高","优先级高则严重程度一定高","两者可独立判定，严重程度高但优先级可能低","两者必须由测试员和开发员分别填写"],"answer":[2],"explanation":"知识点是缺陷严重程度与优先级的区别。严重程度反映缺陷对功能的影响，优先级反映修复的紧急程度，两者可独立判定，例如界面文字错误严重程度低但优先级可能高。严重程度高优先级不一定高；优先级高严重程度不一定高；两者并不强制由不同角色分别填写。"},{"id":182,"type":"single","stem":"某电商项目要求在“双十一”前完成性能测试，测试员在压测中发现响应时间随并发用户数增加呈线性上升且未出现错误，此时最应优先分析的是？","options":["是否存在内存泄漏导致响应变慢","系统吞吐量是否已达到瓶颈","并发用户数是否超过预期峰值","网络带宽是否被压测工具占满"],"answer":[1],"explanation":"知识点是性能测试结果分析。响应时间随并发线性上升且无错误，通常说明系统尚未达到瓶颈但吞吐量增长受限，应优先分析吞吐量是否达到瓶颈。内存泄漏通常表现为响应时间非线性恶化；并发是否超预期是需求确认问题；网络带宽被占满会有错误或吞吐下降，不是首要分析点。"},{"id":183,"type":"single","stem":"某测试员在回归测试中只执行了上次失败过的用例，未覆盖本次修改影响的其他模块，这种做法最可能导致？","options":["回归测试范围过窄而漏测新引入缺陷","回归测试执行时间过长而延误发布","自动化脚本维护成本显著增加","缺陷报告数量过多而难以分类"],"answer":[0],"explanation":"知识点是回归测试范围确定。只执行上次失败用例会导致范围过窄，无法覆盖修改波及模块，可能漏测新引入缺陷。执行时间过长与范围过窄相反；脚本维护成本与执行范围无直接关系；缺陷报告数量多不是该做法的主要后果。"},{"id":184,"type":"single","stem":"在自动化测试框架中，将登录操作封装为公共方法供多个测试用例调用，主要目的是？","options":["提高测试用例的执行速度","降低脚本的维护成本","增加测试用例的覆盖范围","减少测试数据的准备数量"],"answer":[1],"explanation":"知识点是自动化测试框架的封装与复用。封装公共操作可减少重复代码，修改时只需改一处，降低维护成本。封装不直接提高执行速度；覆盖范围由用例设计决定；测试数据准备数量与封装无直接关系。"},{"id":185,"type":"single","stem":"某缺陷在测试环境可稳定复现，但生产环境用户反馈偶尔出现，测试员应优先补充的信息是？","options":["用户的操作系统版本和浏览器类型","缺陷的严重程度和优先级","开发人员的修复方案","测试用例的编号和名称"],"answer":[0],"explanation":"知识点是缺陷复现的环境信息收集。生产环境偶现缺陷需补充用户环境信息（操作系统、浏览器等）以缩小复现条件。严重程度和优先级是缺陷属性而非复现信息；修复方案由开发提供；用例编号与复现无关。"},{"id":186,"type":"single","stem":"使用等价类划分法为“年龄输入框（18至60岁）”设计测试用例，下列输入中属于无效等价类的是？","options":["输入25","输入60","输入17","输入18"],"answer":[2],"explanation":"知识点是等价类划分中有效与无效等价类的区分。18至60为有效等价类，17小于下限属于无效等价类。25、60、18均落在有效范围内。"},{"id":187,"type":"single","stem":"某测试员在提交缺陷时只写了“登录失败”，未附日志和截图，开发人员最可能采取的处置是？","options":["直接根据经验修复该缺陷","将缺陷退回要求补充信息","忽略该缺陷并关闭","自行复现后修改缺陷状态"],"answer":[1],"explanation":"知识点是缺陷报告的基本要素。缺少日志、截图、复现步骤等信息，开发无法定位，通常退回要求补充。直接修复缺乏依据；忽略关闭会丢失缺陷；自行复现虽可能发生，但退回补充信息是更规范的处置。"},{"id":188,"type":"single","stem":"在持续集成环境中，自动化测试用例在代码提交后自动触发执行，若发现失败用例，团队首先应确认的是？","options":["失败是否为本次代码变更引入","测试环境是否已更新到最新版本","自动化脚本是否需要重构","测试数据是否需要重新生成"],"answer":[0],"explanation":"知识点是持续集成中自动化测试失败的处理。首先应确认失败是否由本次代码变更引入，以决定回退或修复。环境更新、脚本重构、数据生成是后续排查方向，不是首先确认的内容。"},{"id":189,"type":"multi","stem":"在缺陷管理流程中，下列哪些操作属于测试员在缺陷“验证”环节的职责？","options":["在修复版本上按原复现步骤执行验证","确认缺陷是否真正修复且未引入新问题","直接修改缺陷的严重程度以匹配开发意见","验证通过后将缺陷状态置为关闭","根据开发要求删除无法复现的缺陷记录"],"answer":[0,1,3],"explanation":"知识点是缺陷验证环节的职责。测试员需在修复版本上复现验证、确认修复且无回归、验证通过后关闭缺陷。修改严重程度以匹配开发意见不是验证职责；删除无法复现的缺陷记录会丢失追溯信息，均不正确。"},{"id":190,"type":"single","stem":"在等价类划分法中，某输入框要求输入1到100之间的整数，下列哪组测试数据的设计方式最符合有效等价类与无效等价类的划分原则","options":["取1、50、100作为有效等价类，取0、101作为无效等价类","取1、50、100作为有效等价类，取0、-1作为无效等价类","取0、50、101作为有效等价类，取1、100作为无效等价类","取1、100作为有效等价类，取0、101、50作为无效等价类"],"answer":[0],"explanation":"知识点是等价类划分中有效等价类覆盖合法区间、无效等价类覆盖区间外的两侧边界。正确项取区间内三个代表性值作有效类，取0和101分别覆盖下界外和上界外两个无效类，划分完整。错误项B只取了下界外的0和-1，漏掉了上界外101这个无效类。错误项C把非法值当成有效类，划分逻辑颠倒。错误项D把合法值50放进无效等价类，混淆了有效与无效的归属。"},{"id":191,"type":"single","stem":"使用边界值分析法测试一个取值范围为1到100的整数输入框，按照标准边界值设计方法应优先选取的测试数据组合是","options":["0、1、2、99、100、101","1、2、50、99、100","0、1、100、101","1、50、100、101"],"answer":[0],"explanation":"知识点是边界值分析要覆盖上点和离点，即最小值、略高于最小值、略低于最大值、最大值及其两侧紧邻值。正确项包含0、1、2、99、100、101，完整覆盖下边界及其内外和上边界及其内外。错误项B缺少边界外的0和101，无法检出越界处理缺陷。错误项C缺少边界内的2和99，遗漏了边界内侧的离点。错误项D同样缺少2和99，边界覆盖不完整。"},{"id":192,"type":"single","stem":"在判定表驱动测试中，某业务规则包含三个条件桩，每个条件取真或假两个值，理论上完整判定表应包含的规则条数是","options":["6条","8条","9条","12条"],"answer":[1],"explanation":"知识点是判定表规则条数等于各条件取值数的乘积，三个二值条件对应2的3次方即8条规则。正确项8条符合组合全覆盖原理。错误项A的6条是3乘2的误算，把条件数与取值数相乘。错误项C的9条是3的平方，混淆了条件数与组合数。错误项D的12条是3乘4，把条件数错当成四个。"},{"id":193,"type":"single","stem":"某缺陷在测试环境无法复现，但在生产环境偶发出现，测试员在缺陷报告中记录复现步骤时最恰当的做法是","options":["标注为不可复现并直接关闭该缺陷","记录已尝试的复现步骤并注明环境差异与发生频率","凭记忆补全一套看似合理的复现步骤","将缺陷转给开发并说明无法提供复现信息"],"answer":[1],"explanation":"知识点是缺陷报告应如实记录已知信息，包括复现尝试、环境差异和偶发频率，便于后续定位。正确项完整保留了排查线索和环境差异，符合缺陷管理规范。错误项A直接关闭会丢失问题，且偶发缺陷可能真实存在。错误项C凭记忆编造步骤会误导开发排查方向。错误项D只说无法提供信息，未记录已尝试的步骤和环境差异，信息量不足。"},{"id":194,"type":"single","stem":"测试员提交缺陷后，开发人员回复该现象属于设计如此并非缺陷，此时测试员下一步最合理的处置是","options":["直接关闭缺陷并修改测试用例不再覆盖该场景","与开发确认需求文档并请需求方裁定是否为缺陷","将该缺陷标记为已修复并继续后续测试","提升该缺陷严重级别以引起开发重视"],"answer":[1],"explanation":"知识点是缺陷争议时应回到需求基线由需求方裁定，测试员不能单方面判定。正确项通过查需求文档并请需求方裁定，能给出权威结论。错误项A未确认需求就关闭并放弃用例覆盖，可能漏掉真实缺陷。错误项C把争议缺陷当作已修复，状态流转错误。错误项D靠提高严重级别施压，没有解决需求判定问题。"},{"id":195,"type":"single","stem":"在缺陷生命周期中，测试员验证开发提交的修复版本时发现原问题已解决但引入了新的相关问题，此时应将缺陷状态置为","options":["已关闭","重新打开","已修复","延期处理"],"answer":[1],"explanation":"知识点是缺陷回归验证时若原问题未彻底解决或引入新问题，应重新打开缺陷。正确项重新打开能保留原缺陷记录并继续跟踪。错误项A已关闭说明验证通过，与发现新问题矛盾。错误项C已修复是开发提交后的状态，不能反映验证未通过。错误项D延期处理适用于暂不修复的规划决策，不适用于验证失败。"},{"id":196,"type":"single","stem":"使用Selenium编写自动化测试脚本时，页面元素在操作前需要等待其加载完成，相比固定时长休眠，更推荐的等待方式是","options":["显式等待指定条件成立后再操作元素","将休眠时间统一设置为十秒","在脚本开头一次性休眠等待整页加载","通过循环反复刷新页面直到元素出现"],"answer":[0],"explanation":"知识点是自动化测试中显式等待按条件轮询判断元素状态，兼顾稳定性与执行效率。正确项显式等待在条件满足时立即继续，超时才失败，最可靠。错误项B固定休眠十秒既可能不够也可能浪费时间，且不稳定。错误项C开头一次性休眠无法覆盖后续动态加载的元素。错误项D反复刷新会破坏页面状态并可能触发重复提交。"},{"id":197,"type":"single","stem":"在自动化测试中，某登录脚本因页面元素定位表达式依赖自动生成的随机属性值而频繁失败，最合理的改进措施是","options":["改用相对稳定的业务属性或层级关系进行定位","每次失败后手动修改脚本中的属性值","增加失败重试次数直到定位成功","将该用例从自动化套件中移除改为手工执行"],"answer":[0],"explanation":"知识点是自动化元素定位应优先选用稳定属性如id、name或业务语义属性，避免依赖随机生成值。正确项改用稳定属性从根源上解决脆弱定位问题。错误项B手动改属性值无法持续维护且随机值每次变化。错误项C重试对随机属性无效，定位表达式本身已失效。错误项D移除用例会损失自动化覆盖，未解决根因。"},{"id":198,"type":"single","stem":"某团队用持续集成流水线运行自动化测试，某次构建中大量用例因测试环境数据库未就绪而失败，正确的处置方式是","options":["在流水线中增加环境健康检查并在就绪后再执行用例","将这些失败用例标记为跳过并继续发布","直接重跑流水线直到用例通过为止","降低用例断言严格程度以减少失败数量"],"answer":[0],"explanation":"知识点是持续集成中应保证测试前置环境就绪，通过健康检查门禁避免环境问题导致误报。正确项增加环境健康检查能从流程上消除环境未就绪的干扰。错误项B跳过失败用例会掩盖真实问题并让流水线失去把关意义。错误项C盲目重跑不解决环境根因，浪费资源且结果不可信。错误项D放松断言会降低缺陷检出能力，属于错误的质量妥协。"},{"id":199,"type":"single","stem":"在性能测试中，某接口在并发用户数增加时响应时间急剧上升但吞吐量不再增长，这种现象通常说明系统已到达","options":["最佳并发点","瓶颈临界点","冷启动阶段","基线稳定点"],"answer":[1],"explanation":"知识点是性能测试中吞吐量饱和而响应时间陡增表明系统进入瓶颈临界点。正确项瓶颈临界点正对应吞吐不再增长、响应时间恶化的特征。错误项A最佳并发点位于吞吐上升而响应时间尚可的区间。错误项C冷启动阶段是系统初始预热阶段，与并发增加无关。错误项D基线稳定点是低负载下的参考性能，不会出现响应时间陡增。"},{"id":200,"type":"single","stem":"某测试员在编写测试用例时，对同一功能既写了正常流程用例，又补充了异常输入、边界数据和并发操作场景，这种做法主要体现了测试用例设计的哪一原则","options":["用例的可重复性","用例的完整性","用例的独立性","用例的优先级"],"answer":[1],"explanation":"知识点是测试用例完整性要求覆盖正常、异常、边界及并发等多类场景。正确项完整性正是指用例覆盖维度齐全。错误项A可重复性指同一用例多次执行结果一致，与场景覆盖无关。错误项C独立性指用例间不相互依赖，与补充多类场景无关。错误项D优先级指按重要程度排序，题干未涉及排序。"},{"id":201,"type":"multi","stem":"在缺陷管理流程中，下列哪些做法有助于提升缺陷报告的可处理性","options":["附上缺陷复现所需的测试数据与操作步骤","记录缺陷出现时的日志与环境版本信息","将多个不相关的缺陷合并到一条记录中提交","为缺陷指定合理的严重级别与优先级","在提交前先与开发口头沟通确认后再补记录"],"answer":[0,1,3],"explanation":"知识点是高质量缺陷报告应包含复现步骤、环境日志和合理的严重级别优先级。正确项A提供复现数据与步骤便于开发定位。正确项B记录日志与环境版本是定位问题的关键信息。正确项D合理定级有助于排期处理。错误项C把多个不相关缺陷合并会混淆跟踪与修复验证。错误项E仅口头沟通而不及时记录会导致信息丢失和流程不可追溯。"},{"id":202,"type":"single","stem":"在某电商结算模块的测试用例中，需要验证“满200减30”与“会员9折”叠加时的金额计算，按等价类划分应优先覆盖的组合是","options":["订单金额199元且为会员、订单金额200元且为会员、订单金额201元且为会员","订单金额200元且为会员、订单金额200元且非会员、订单金额0元且为会员","订单金额100元且为会员、订单金额200元且为会员、订单金额300元且为会员","订单金额200元且为会员、订单金额199元且为非会员、订单金额200元且为非会员"],"answer":[0],"explanation":"知识点是等价类划分中边界值与有效/无效类的组合覆盖。满减边界在200元，有效类含≥200，无效类含<200，同时会员与否影响叠加，故应覆盖199/200/201且都取会员这一维度变化点；B漏了边界上下值；C没覆盖无效类边界；D把会员状态与金额边界混搭但缺201元边界。"},{"id":203,"type":"single","stem":"自动化测试脚本中，某元素定位写成 By.id(\"submit-btn\")，但每次页面加载后该按钮的 id 会随机变化，最合适的改造方式是","options":["改用 By.xpath 按按钮文本定位","改用 By.cssSelector 按 class 链式拼接定位","改用 By.name 并保持原有 id 写法","改用 By.tagName(\"button\") 按标签定位"],"answer":[0],"explanation":"知识点是动态属性下的定位策略选择。id 随机时依赖稳定文本或稳定属性更可靠，按钮文本通常较稳定，故按文本 xpath 可行；B的class链若也动态则同样不稳；C的name若同样随机则无效且未解决根因；D按tagName会匹配到多个button导致不唯一，定位不精确。"},{"id":204,"type":"single","stem":"提交缺陷报告时，开发反馈“无法复现”，作为测试人员下一步最恰当的处置是","options":["补充环境版本、操作步骤、日志和截图后重新提交","将该缺陷关闭并标记为不是缺陷","在缺陷描述中追加一句“请开发再仔细看看”","把缺陷优先级降为最低并留给下个版本"],"answer":[0],"explanation":"知识点是缺陷生命周期中不可复现缺陷的处理。正确做法是补齐复现要素再提交；B在未确认前关闭会丢失问题；C没有提供新信息，无助复现；D降优先级并搁置会掩盖潜在缺陷，缺陷状态不应在未定位前随意降级。"},{"id":205,"type":"single","stem":"用 Pytest 编写测试函数时，希望该函数在某个前置条件不满足时被跳过而不是失败，应使用的标记是","options":["@pytest.mark.skipif","@pytest.mark.xfail","@pytest.mark.parametrize","@pytest.mark.usefixtures"],"answer":[0],"explanation":"知识点是Pytest标记语义。skipif按条件跳过，符合题意；xfail是预期失败，仍会执行并记录；parametrize是参数化；usefixtures是声明使用fixture，均不实现条件跳过。"},{"id":206,"type":"single","stem":"某登录功能测试中，输入正确用户名和错误密码，系统返回“用户名或密码错误”，这体现了安全测试中的哪项设计原则","options":["错误提示不区分账号是否存在","密码明文传输但前端加密","登录失败次数不限制","验证码在密码校验之后弹出"],"answer":[0],"explanation":"知识点是认证安全的错误信息最小化原则。统一提示可防止账号枚举；B即使前端加密也不能替代传输层保护且与题干无关；C不限次数属暴力破解风险，题干未体现；D验证码时序与题干提示内容无关。"},{"id":207,"type":"single","stem":"在缺陷管理工具中，将缺陷状态从“已修复”流转到“已关闭”之前，测试人员应执行的关键动作是","options":["在对应版本上回归验证并确认通过","直接根据开发邮件确认后关闭","把缺陷重新指派给开发确认","将缺陷标记为“重复”后关闭"],"answer":[0],"explanation":"知识点是缺陷状态流转的验证职责。修复后必须回归验证才能关闭；B仅凭邮件未验证；C已修复后再指派回开发不符合流程；D标记重复与关闭条件无关。"},{"id":208,"type":"single","stem":"使用 Selenium 的显式等待时，希望等待某元素可点击后再操作，应使用的条件类是","options":["element_to_be_clickable","presence_of_element_located","visibility_of_element_located","text_to_be_present_in_element"],"answer":[0],"explanation":"知识点是Selenium等待条件语义。element_to_be_clickable同时要求可见且可点击；presence只要求存在于DOM；visibility只要求可见但不保证可点击；text_to_be_present只判断文本出现，均不满足“可点击”要求。"},{"id":209,"type":"single","stem":"在测试用例设计中，针对“用户年龄输入框只允许18到60岁整数”，用边界值分析法应选取的典型值是","options":["17、18、60、61","18、30、60、61","17、18、59、60","0、18、60、100"],"answer":[0],"explanation":"知识点是边界值分析取上点、离点与内点。边界为18和60，应取17、18、60、61覆盖刚好越界与刚好合法；B缺少下边界越界值；C缺少上边界越界值；D取值过于分散且未覆盖紧邻边界。"},{"id":210,"type":"single","stem":"某团队在 CI 流水线中每次提交都运行全部自动化回归用例，导致反馈时间超过两小时，最合理的优化方向是","options":["按变更影响分层，提交时跑冒烟与核心回归，夜间跑全量","把全部用例改为并行执行以缩短时间","减少用例数量只保留通过率高的用例","关闭失败用例的告警以加快流水线"],"answer":[0],"explanation":"知识点是持续集成中的测试分层与反馈速度平衡。分层可在保证关键覆盖的同时缩短反馈；B并行受资源限制且未解决用例选择问题；C按通过率裁剪会丢失有效覆盖；D关闭告警会掩盖失败，风险极高。"},{"id":211,"type":"single","stem":"某缺陷报告写“点击支付按钮后页面偶尔白屏”，从缺陷描述质量看，最需要补充的信息是","options":["复现概率、环境、操作路径与日志","开发人员的姓名与工号","该页面的UI设计稿链接","同类功能的竞品实现方式"],"answer":[0],"explanation":"知识点是缺陷报告要素完整性。偶现问题必须补充概率、环境、路径与日志才能定位；B与缺陷定位无关；C设计稿不解决白屏根因；D竞品实现不属本缺陷必要信息。"},{"id":212,"type":"single","stem":"在某电商订单模块的测试中，测试员发现当用户使用优惠券下单后又取消订单，优惠券没有退回账户，但他不确定这是否属于缺陷，此时最合适的处置方式是","options":["记录为缺陷并附上复现步骤和实际结果，提交给开发确认","直接判定为设计如此，因为系统可能规定取消订单不退券","先不记录，等下次版本发布时再观察是否仍有该现象","口头告知开发人员，让对方判断后决定是否需要记录"],"answer":[0],"explanation":"知识点是缺陷管理流程中缺陷的识别与提交。正确项对：测试员发现实际结果与预期不符时应记录并提交缺陷，由开发确认是否设计如此。错误项一错在测试员无权单方面认定业务规则，需依据需求文档确认；错误项二错在缺陷不能因观察而延迟记录，可能遗漏且无法追踪；错误项三错在口头沟通无法留痕，缺陷必须走正式流程。"},{"id":213,"type":"single","stem":"使用等价类划分法为“用户年龄输入框（允许18至60周岁）”设计测试用例时，下列划分中正确的是","options":["有效类18~60，无效类小于18和大于60","有效类18~60，无效类小于等于18和大于等于60","有效类17~61，无效类小于17和大于61","有效类18~59，无效类小于18和大于59"],"answer":[0],"explanation":"知识点是等价类划分中有效类与无效类的边界取值。正确项对：允许范围18至60，有效类为18~60，无效类为小于18与大于60。错误项一错在把边界18和60划入无效类，与允许范围矛盾；错误项二错在扩大了有效类范围到17和61，包含了不允许的值；错误项三错在缩小有效类到18~59并错误处理边界59。"},{"id":214,"type":"single","stem":"在缺陷报告中填写“缺陷严重程度”和“缺陷优先级”时，下列理解正确的是","options":["严重程度反映缺陷对系统的影响，优先级反映修复的紧急程度","严重程度由测试员定，优先级必须由开发经理定","严重程度高的缺陷优先级一定也高，两者应保持一致","优先级反映缺陷对系统的影响，严重程度反映修复的紧急程度"],"answer":[0],"explanation":"知识点是缺陷严重程度与优先级的区别。正确项对：严重程度描述影响大小，优先级描述修复紧迫性，两者维度不同。错误项一错在优先级通常由团队协商确定而非必须由开发经理单独定；错误项二错在严重程度高不一定优先级高，如崩溃但极少触发的缺陷优先级可能低；错误项三错在把两者的定义完全颠倒。"},{"id":215,"type":"single","stem":"某测试员使用Selenium编写自动化脚本，脚本在本地运行通过，但在CI服务器上总是找不到页面元素，最可能的原因是","options":["CI服务器上页面加载速度与本地不同，元素定位前未等待加载完成","CI服务器没有安装浏览器驱动，导致脚本无法启动浏览器","CI服务器上运行的脚本没有使用相同的编程语言","CI服务器上的网络带宽不足，导致页面元素无法渲染"],"answer":[0],"explanation":"知识点是自动化测试中显式等待与隐式等待的使用。正确项对：本地与CI环境加载速度差异会导致元素未加载完成就定位失败，应加入等待机制。错误项一错在若驱动未安装脚本会直接报错而非仅找不到元素；错误项二错在脚本语言与运行环境无关，不会因语言不同导致定位失败；错误项三错在带宽不足通常表现为加载慢而非元素完全不渲染，且与定位失败无直接对应。"},{"id":216,"type":"single","stem":"在边界值分析中，对于输入范围“1到100的整数”，下列测试数据组合最符合边界值分析法的是","options":["0，1，100，101","1，50，100","1，2，99，100","0，50，101"],"answer":[0],"explanation":"知识点是边界值分析取边界及其邻近值。正确项对：应取最小值1、最大值100及刚超出边界的0和101。错误项一错在只取了边界和中间值，遗漏了边界外的邻近值；错误项二错在取了边界内邻近值而非边界外邻近值；错误项三错在只取了边界外值和中间值，遗漏了边界本身1和100。"},{"id":217,"type":"single","stem":"测试员在回归测试中发现上次修复的登录缺陷又出现了，但代码仓库显示相关修复提交仍在，最合理的下一步处置是","options":["核对该缺陷的修复分支是否已合并到当前测试版本，确认环境一致性","直接把缺陷重新打开并标注为开发修复无效","认为是环境问题，重新部署后再执行一遍相同用例","将该缺陷降级为轻微缺陷，因为修复代码确实存在"],"answer":[0],"explanation":"知识点是回归测试中缺陷重现的排查思路。正确项对：修复代码存在但缺陷重现，应先确认当前测试版本是否包含该修复，即分支合并与环境一致性。错误项一错在未排查前就定性为修复无效，结论过早；错误项二错在重新部署不能解决分支未合并的问题；错误项三错在缺陷重现不应降级，需先查明原因。"},{"id":218,"type":"single","stem":"使用JUnit编写单元测试时，某测试方法需要验证被调用方法抛出了指定异常，应使用的注解或方式是","options":["在@Test注解中声明expected属性指定异常类型","在测试方法中写try-catch并调用fail方法","在测试方法前加@Before注解并断言异常","在测试方法后加@After注解并捕获异常"],"answer":[0],"explanation":"知识点是JUnit中断言异常抛出的方式。正确项对：可在@Test的expected属性中声明期望异常类型。错误项一错在try-catch加fail虽可验证但并非题目所问的注解方式且易漏断言；错误项二错在@Before用于前置准备，不能断言异常；错误项三错在@After用于后置清理，不能捕获异常。"},{"id":219,"type":"single","stem":"某测试团队使用Postman对REST接口做自动化测试，需要验证接口返回的JSON中某个字段值随请求参数变化而正确变化，最适合使用的功能是","options":["在Tests脚本中编写断言，对响应JSON字段进行校验","在Pre-request Script中设置环境变量","在请求的Params中增加更多查询参数","在Collection中调整请求的执行顺序"],"answer":[0],"explanation":"知识点是Postman中接口自动化断言的使用。正确项对：应在Tests脚本中对响应JSON字段编写断言校验。错误项一错在Pre-request Script用于请求前准备，不做响应校验；错误项二错在增加查询参数是改变请求而非验证响应；错误项三错在调整执行顺序属于流程编排，不能校验字段值。"},{"id":220,"type":"single","stem":"在设计测试用例时，某功能有3个相互独立的输入条件，每个条件有2种取值，若采用判定表或因果图进行组合覆盖，最少需要覆盖的组合数是","options":["8","6","4","3"],"answer":[0],"explanation":"知识点是判定表与因果图中多条件组合的全组合数。正确项对：3个独立条件各2种取值，全组合为2的3次方等于8。错误项一错在6只是部分组合，遗漏了两种组合；错误项二错在4只覆盖了两个条件的组合；错误项三错在3只是条件个数，不是组合数。"},{"id":221,"type":"single","stem":"测试员在执行性能测试时发现系统在并发用户数达到500时响应时间急剧上升，但CPU和内存使用率并不高，最可能的原因是","options":["数据库连接池或线程池等资源池配置不足导致请求排队","服务器CPU性能不够，需要升级硬件","网络带宽不足，导致请求传输延迟","磁盘IOPS过低，导致日志写入阻塞"],"answer":[0],"explanation":"知识点是性能测试中瓶颈定位。正确项对：CPU和内存不高但响应时间陡增，常见于连接池、线程池等资源池耗尽导致排队。错误项一错在CPU不高说明不是CPU瓶颈；错误项二错在带宽不足通常伴随网络指标异常且与并发数关系不直接；错误项三错在日志写入阻塞一般会体现磁盘指标异常，且不会仅在500并发时突然出现。"},{"id":222,"type":"multi","stem":"在自动化测试框架设计中，下列做法有助于提高测试脚本可维护性的有","options":["将页面元素定位信息集中到页面对象类中统一管理","把公共的登录、初始化操作封装为可复用的方法","在每个用例中重复编写相同的元素定位和等待逻辑","对用例中的测试数据使用外部文件参数化驱动","将断言逻辑与业务操作步骤混合写在同一个方法中"],"answer":[0,1,3],"explanation":"知识点是自动化测试框架的可维护性设计。正确项一对：页面对象模式集中管理元素定位，便于修改。正确项二对：公共操作封装复用可减少重复代码。正确项三对：参数化数据驱动使用例与数据分离，便于维护。错误项一错在重复编写定位和等待逻辑会增加维护成本；错误项二错在断言与业务操作混合会降低可读性和复用性。"},{"id":223,"type":"single","stem":"用等价类划分法为“用户年龄输入框（允许18~60周岁）”设计测试用例时，下列哪一组年龄数据能同时覆盖两个无效等价类？","options":["17和61","18和60","17和18","60和61"],"answer":[0],"explanation":"知识点：等价类划分中无效等价类指不满足约束的输入。年龄小于18（如17）和大于60（如61）分属两个不同的无效等价类，17和61可同时覆盖。18和60是有效边界值；17和18只覆盖一个无效类；60和61只覆盖一个无效类。"},{"id":224,"type":"single","stem":"在缺陷生命周期管理中，测试人员提交缺陷后，开发人员认为“非缺陷”而将其关闭，测试人员复查后仍认为该问题存在，此时规范的处理流程是？","options":["直接重新打开缺陷并升级给测试经理仲裁","重新提交一条内容相同的新缺陷","在缺陷评论中与开发人员争论直到对方认可","将该缺陷标记为“延期处理”并继续测试"],"answer":[0],"explanation":"知识点：缺陷状态流转与争议处理。当开发关闭但测试不认可时，应重新打开（Reopen）缺陷并升级由测试经理或评审小组仲裁。重新提交新缺陷会造成重复记录；仅争论无法推动状态流转；标记延期属于回避问题，均不规范。"},{"id":225,"type":"single","stem":"使用Selenium WebDriver定位一个页面加载后动态生成、且class属性包含多个类名的按钮时，下列哪种定位方式最不容易因页面样式调整而失效？","options":["通过按钮可见文本使用linkText定位","通过完整class属性值使用className定位","通过按钮在DOM中的绝对路径使用XPath定位","通过按钮的name属性使用name定位"],"answer":[3],"explanation":"知识点：自动化测试元素定位稳定性。name属性通常与业务语义绑定，比样式类和绝对路径稳定。linkText只适用于链接；className受多类名和样式变动影响；绝对XPath对DOM结构调整极其敏感，最易失效。"},{"id":226,"type":"single","stem":"在编写测试用例时，为登录功能设计“用户名正确、密码错误”的用例，这属于哪种测试用例设计方法的典型应用？","options":["边界值分析","因果图分析","错误推测","场景法"],"answer":[1],"explanation":"知识点：测试用例设计方法。用户名与密码的正确/错误组合属于输入条件的组合关系，适合用因果图（判定表）分析。边界值侧重取值范围端点；错误推测依赖经验列举；场景法侧重业务流程串联。"},{"id":227,"type":"single","stem":"某项目使用Jenkins做持续集成，自动化测试脚本在开发人员提交代码后自动触发执行，这最能体现自动化测试的哪项价值？","options":["降低测试用例设计难度","提升回归测试的执行频率","替代手工探索性测试","减少测试环境的维护成本"],"answer":[1],"explanation":"知识点：自动化测试的价值定位。持续集成中自动触发执行使回归测试可高频运行。自动化不降低用例设计难度；无法替代依赖人的探索性测试；环境维护成本通常不会因自动化而减少。"},{"id":228,"type":"single","stem":"缺陷报告中的“缺陷摘要”应重点描述什么内容，才能帮助开发人员快速判断问题？","options":["复现缺陷的详细操作步骤","缺陷出现的模块与现象","测试人员对缺陷原因的推断","缺陷对应的需求文档章节号"],"answer":[1],"explanation":"知识点：缺陷报告要素。摘要是标题性描述，应简明指出模块与现象。详细步骤属于“复现步骤”字段；原因推断属于分析内容；需求章节号属于追溯信息，均不放在摘要。"},{"id":229,"type":"single","stem":"在缺陷管理中，将缺陷严重程度（Severity）设为“严重”而优先级（Priority）设为“低”，最可能的情形是？","options":["系统崩溃但仅在已废弃的旧版本中出现","界面文字错别字影响品牌形象","核心功能无法使用且客户正在验收","数据库连接池偶发泄漏导致性能下降"],"answer":[0],"explanation":"知识点：缺陷严重程度与优先级的区别。严重程度高指影响大，优先级低指当前不需优先修复，旧版本崩溃符合。错别字严重程度通常不高；核心功能不可用且客户验收通常优先级高；连接池泄漏影响性能，优先级一般不低。"},{"id":230,"type":"single","stem":"测试人员发现一个缺陷，但该缺陷在开发人员机器上无法复现，此时测试人员首先应当做的是？","options":["直接关闭该缺陷并记录为环境问题","整理复现步骤、环境信息和日志提交给开发","要求开发人员更换机器再试","将该缺陷优先级调低后继续测试"],"answer":[1],"explanation":"知识点：缺陷复现与协作。无法复现时应补充环境、步骤、日志等证据协助定位。直接关闭会遗漏问题；要求换机器属于推责；调低优先级未解决复现问题，均不妥。"},{"id":231,"type":"single","stem":"在等价类划分中，若某输入条件规定了取值范围，则有效等价类的划分应覆盖？","options":["取值范围内的任意一个值","取值范围内的全部边界值","取值范围内的一个合理代表值","取值范围内的最大值"],"answer":[2],"explanation":"知识点：等价类划分原则。有效等价类只需一个能代表该类的合理值即可，无需取全部边界或最大值。全部边界值属于边界值分析的取法；取最大值不具代表性。"},{"id":232,"type":"single","stem":"在等价类划分中，某输入框要求输入1到100的整数，下列哪组测试数据覆盖了有效的边界值","options":["0、1、100、101","1、2、99、100","0、50、101、102","1、50、100、101"],"answer":[1],"explanation":"知识点是边界值分析中有效边界值的选取。有效边界值应取边界本身及边界附近的有效值，1和100是有效边界，2和99是边界内侧有效值，全部落在有效区间内。选项0和101属于无效边界值，混入后不再全是有效边界；选项0、50、101、102同时含多个无效值；选项1、50、100、101含无效值101，均不符合只取有效边界的要求。"},{"id":233,"type":"single","stem":"某缺陷在开发人员本地环境无法复现，测试人员下一步最合理的做法是","options":["直接关闭该缺陷并注明无法复现","补充环境信息、操作步骤和日志后重新指派","将该缺陷标记为已修复并等待回归验证","把缺陷优先级降为最低后继续测试其他模块"],"answer":[1],"explanation":"知识点是缺陷不可复现时的处置流程。无法复现时应补充完整的环境、步骤、数据、日志等信息再重新指派，帮助开发定位。直接关闭会丢失缺陷线索；标记已修复并未真正修复；降优先级只是拖延，均不能解决复现问题。"},{"id":234,"type":"single","stem":"使用Selenium编写自动化脚本时，元素在页面加载完成后才出现，直接定位经常报找不到元素，最合适的处理方式是","options":["在脚本中固定增加一段sleep等待时间","使用显式等待直到元素可见再操作","改用findElements并遍历返回列表","把定位方式从id改为class后重试"],"answer":[1],"explanation":"知识点是自动化测试中的等待机制。显式等待针对特定条件轮询，元素可见即继续，兼顾稳定与效率。固定sleep时间靠猜，过短仍失败、过长拖慢；findElements遍历不解决时序问题；换定位方式与元素尚未出现无关。"},{"id":235,"type":"single","stem":"某登录功能测试中，输入正确用户名和错误密码，系统提示“用户名或密码错误”，这一设计主要考虑的测试点是","options":["错误提示是否区分了用户名和密码","是否防止了用户名枚举攻击","密码是否经过加密传输","登录失败次数是否受限"],"answer":[1],"explanation":"知识点是安全测试中防止用户名枚举。统一提示避免攻击者通过提示差异判断用户名是否存在。区分提示反而会泄露信息；加密传输和失败次数限制是另外的安全点，与本提示设计无直接关系。"},{"id":236,"type":"single","stem":"在测试用例设计方法中，判定表法最适合用于","options":["输入取值范围连续的数值型字段","多个条件组合决定不同处理动作的逻辑","界面元素布局是否符合设计稿","系统在高并发下的响应时间"],"answer":[1],"explanation":"知识点是判定表法的适用场景。判定表用于条件组合与动作对应关系明确的逻辑。连续数值范围适合边界值和等价类；界面布局属于UI检查；并发响应时间属于性能测试，均非判定表所长。"},{"id":237,"type":"single","stem":"关于缺陷生命周期中“重新打开”状态的使用，正确的是","options":["开发修复后测试验证不通过时由测试人员重新打开","开发认为不是缺陷时由开发人员重新打开","缺陷超过一周未处理时由系统自动重新打开","测试人员对缺陷优先级有异议时重新打开"],"answer":[0],"explanation":"知识点是缺陷状态流转。重新打开表示修复后验证仍未通过，应由测试人员操作。开发认为非缺陷应走拒绝或延期流程；系统自动重新打开没有这种规则；优先级异议应通过评审沟通而非重新打开。"},{"id":238,"type":"single","stem":"某接口返回JSON中字段值为null，接口文档约定该字段为必填且不能为空，测试人员应","options":["认为null等同于空字符串，忽略该问题","记录为缺陷并附上请求响应报文","直接修改文档把该字段改为可空","等待下一个版本再观察是否修复"],"answer":[1],"explanation":"知识点是接口测试中依据契约判断缺陷。文档约定必填非空而实际返回null，属于契约不符，应记录缺陷并附带证据。null与空字符串语义不同；擅自改文档是掩盖问题；等待观察会延误反馈。"},{"id":239,"type":"single","stem":"在性能测试中，逐渐增加并发用户数直到系统出现错误或响应时间超标，这一过程称为","options":["负载测试","压力测试","容量测试","冒烟测试"],"answer":[1],"explanation":"知识点是性能测试类型辨析。压力测试是不断加压直到系统失效以找瓶颈。负载测试是在预期负载下验证性能；容量测试关注系统可支撑的最大容量规划；冒烟测试是基本功能验证，均不符合逐步加压至失效的描述。"},{"id":240,"type":"single","stem":"自动化测试脚本中，把登录操作封装为公共函数供多个用例调用，主要带来的好处是","options":["提高脚本执行速度","降低脚本维护成本","增加测试覆盖率","减少测试数据准备量"],"answer":[1],"explanation":"知识点是自动化测试框架设计中的复用。封装公共操作后，登录逻辑变更只需改一处，维护成本降低。执行速度、覆盖率、数据准备量不因封装而直接改善。"},{"id":241,"type":"single","stem":"某电商项目在促销活动上线前，测试人员发现购物车金额计算在优惠券叠加时出现偏差，此时最合适的处置是","options":["记录缺陷并评估对本次上线的影响后上报","自行修改代码中的计算逻辑后继续测试","在测试报告中标注该问题但不上报","等促销活动结束后再提交缺陷"],"answer":[0],"explanation":"知识点是缺陷管理与上线风险评估。金额计算错误直接影响交易，应记录缺陷、评估影响并上报决策。测试人员不应改代码；仅标注不上报会遗漏风险；活动后再提交已造成损失。"},{"id":242,"type":"single","stem":"使用JUnit编写单元测试时，某个测试方法依赖数据库连接，为保证测试独立性和可重复执行，较合适的做法是","options":["在测试方法中直接连接生产数据库查询","使用内存数据库或Mock对象替代真实依赖","让所有测试方法共享同一个数据库连接","把数据库连接配置写死在测试代码中"],"answer":[1],"explanation":"知识点是单元测试的隔离性。使用内存数据库或Mock可避免外部依赖，保证可重复执行。连生产库有数据污染风险；共享连接会造成测试间耦合；写死配置不利于环境切换，均不恰当。"},{"id":243,"type":"multi","stem":"在缺陷报告中，下列哪些内容属于必须包含且有助于开发定位问题的信息","options":["缺陷所在模块及版本号","复现步骤与预期实际结果","测试人员当天的情绪状态","相关日志或截图附件","缺陷发现时的浏览器型号"],"answer":[0,1,3],"explanation":"知识点是缺陷报告的要素。模块版本、复现步骤与预期实际结果、日志截图都是定位问题的关键信息。情绪状态与缺陷无关；浏览器型号仅在特定前端问题时才需要，不是所有缺陷的必须项。"},{"id":244,"type":"single","stem":"设计登录功能的测试用例时，针对用户名输入框要求“6到12位字母数字组合”，下列用例中采用等价类划分法最应优先保留的是","options":["输入5位字母数字组合","输入6位纯字母用户名","输入13位字母数字组合","输入含空格的用户名"],"answer":[1],"explanation":"知识点是等价类划分中有效等价类与无效等价类的选取。6位纯字母属于有效等价类边界内的合法输入，应至少保留一个有效等价类用例。输入5位属于长度下边界外的无效等价类，输入13位属于长度上边界外的无效等价类，输入含空格属于字符类型不符合的无效等价类，三者都是无效等价类，通常优先各取一个代表即可，不应优先于有效类用例。"},{"id":245,"type":"single","stem":"某购物网站优惠券规则为“满100减20，满200减50”，用边界值分析法为订单金额设计测试数据，下列最合理的边界取值组合是","options":["99、100、101、199、200、201","100、200、300、400、500、600","0、50、100、150、200、250","99、150、200、250、300、350"],"answer":[0],"explanation":"知识点是边界值分析要取每个边界点的上点、内点、外点。满100和满200是两个业务边界，应取100与200前后的99、101、199、201以及边界本身。选项B只取整百递增点，缺少边界外侧数据；选项C把50、150、250当作边界，与规则不符；选项D虽含99和200，但150、250、350并非边界外侧点，覆盖不足。"},{"id":246,"type":"single","stem":"测试人员在缺陷管理工具中提交缺陷后，开发人员标记为“无法复现”并退回，测试人员下一步最恰当的做法是","options":["直接关闭该缺陷并记录为环境问题","补充复现步骤、日志和录屏后重新激活缺陷","把缺陷优先级改为最低等待后续版本观察","在缺陷描述中标注开发人员未按规范处理"],"answer":[1],"explanation":"知识点是缺陷生命周期中“无法复现”状态的处理流程。规范做法是补充可复现的证据（步骤、日志、录屏、环境信息）后重新激活，交回开发确认。直接关闭会漏掉真实缺陷；只降优先级不解决复现信息不足的问题；在描述中指责开发人员不解决技术问题且违反协作规范。"},{"id":247,"type":"single","stem":"在测试用例评审会上，有人提出“这条用例只验证了正常流程，没有覆盖异常分支”，该意见针对的测试用例质量属性是","options":["用例的可重用性","用例的覆盖率","用例的执行效率","用例的可追溯性"],"answer":[1],"explanation":"知识点是测试用例质量评价维度。覆盖异常分支属于覆盖率问题，即用例是否覆盖了需求或代码的各种路径。可重用性关注用例能否在其他场景复用；执行效率关注执行耗时与资源；可追溯性关注用例与需求、缺陷的对应关系，均与异常分支缺失无直接关系。"},{"id":248,"type":"single","stem":"某接口返回 JSON 中字段“status”取值应为 success、fail、pending 三种，测试时构造了 success 和 fail 两组数据，从用例设计完整性看还应补充","options":["status 为空字符串的用例","status 为 pending 的用例","status 为 SUCCESS 大写的用例","status 为数字 0 的用例"],"answer":[1],"explanation":"知识点是等价类划分中有效等价类要全覆盖。题干已给出三个合法取值，已测两个，还缺 pending 这一有效等价类。空字符串、大写 SUCCESS、数字0都属于无效等价类，虽也值得测，但从“合法取值完整性”角度最直接应补的是 pending。"},{"id":249,"type":"single","stem":"缺陷报告中写道“点击提交按钮后页面报错”，从缺陷描述质量看最需要补充的信息是","options":["报错页面的截图和复现步骤","开发人员的历史缺陷数量","该按钮的 UI 设计稿版本","测试人员当天的情绪状态"],"answer":[0],"explanation":"知识点是缺陷报告应包含可复现、可定位的必要信息。截图与复现步骤能让开发快速定位问题。开发人员历史缺陷数量与当前缺陷无关；UI设计稿版本只在界面样式争议时相关；测试人员情绪状态不属于缺陷报告内容。"},{"id":250,"type":"single","stem":"使用 Postman 对一组接口做回归测试，希望每次修改后自动校验响应状态码和关键字段，最合适的做法是","options":["每次手动点击 Send 后肉眼核对响应","在 Tests 标签中编写断言脚本并配合集合运行","把响应内容复制到 Word 中逐条比对","将请求保存后由开发人员代为执行检查"],"answer":[1],"explanation":"知识点是接口自动化测试中断言的使用。Postman 的 Tests 脚本可自动校验状态码和字段，配合 Collection Runner 批量回归。手动点击肉眼核对、复制到 Word 比对都不可重复且易漏；让开发代为执行不符合测试职责分离且仍非自动校验。"},{"id":251,"type":"multi","stem":"在缺陷管理中，下列属于缺陷严重程度（Severity）与优先级（Priority）关系正确描述的有","options":["严重程度高通常优先级也高，但并非绝对","严重程度低的功能缺陷也可能优先级很高","优先级由测试人员根据个人喜好单独决定","严重程度反映故障影响，优先级反映修复次序","严重程度和优先级在任何项目中都完全一致"],"answer":[0,1,3],"explanation":"知识点是缺陷严重程度与优先级的区别与联系。A正确，二者常正相关但可分离；B正确，如界面文字错误影响品牌发布时优先级可很高；D正确，分别描述影响程度和修复次序。C错误，优先级由团队按业务和发布计划共同确定，不是个人喜好；E错误，二者维度不同，不可能在任何项目都完全一致。"},{"id":252,"type":"single","stem":"某电商项目上线前发现一个仅在特定机型上出现的支付闪退问题，开发称“用户量少可暂不修复”，作为测试负责人最恰当的处置是","options":["同意暂不修复并在上线后不再跟踪","记录风险、评估影响并升级给产品与业务决策","自行修改代码后重新打包验证","将该机型从兼容性测试范围中永久移除"],"answer":[1],"explanation":"知识点是缺陷风险管理与决策流程。测试负责人应记录风险、量化影响并升级给产品或业务方决策，而不是自行决定放弃。A放弃跟踪会导致风险失控；C测试人员擅自改代码违反职责分离；D移除机型会掩盖真实兼容性问题且未经评估。"},{"id":253,"type":"single","stem":"用等价类划分法为「年龄输入框（允许18~60周岁）」设计测试用例时，下列取值组合中最能体现有效等价类与无效等价类完整覆盖的是","options":["17、18、60、61","18、30、60、61","17、18、30、61","18、40、59、60"],"answer":[0],"explanation":"知识点是等价类划分需同时覆盖有效与无效边界。17与61分别落在无效等价类两端，18与60为有效等价类边界，覆盖最完整。选项B缺无效下界17；选项C缺有效上界60；选项D全部为有效值，未覆盖无效等价类。"},{"id":254,"type":"single","stem":"某登录功能需求为「用户名6~12位字母数字、密码8位以上含大小写」，用边界值分析法设计用例时，针对用户名长度应优先选取的边界值是","options":["5、6、12、13","6、7、11、12","5、6、11、13","6、12、13、14"],"answer":[0],"explanation":"边界值分析取边界本身及其相邻值，即下界6、上界12以及6-1=5、12+1=13。选项B只取有效区内值，未覆盖无效边界；选项C把上界相邻值取成11而非13；选项D缺少下界相邻值5。"},{"id":255,"type":"single","stem":"判定表法中，若某规则的条件项组合在业务上根本不可能同时出现，对该规则的处理方式应为","options":["保留该规则并标注为不可达","删除该规则并减少用例数","把该规则条件改为任意值","将该规则合并到相邻规则"],"answer":[0],"explanation":"判定表中不可能出现的条件组合属于不可达规则，应保留并标注，以保证判定表逻辑完整可追溯。选项B直接删除会丢失逻辑覆盖依据；选项C改条件为任意值会掩盖真实约束；选项D强行合并会造成规则含义失真。"},{"id":256,"type":"single","stem":"使用场景法设计用例时，下列做法符合场景法要求的是","options":["先梳理基本流与各条备选流再组合用例","只针对基本流编写一条主用例","按输入框逐一遍历所有取值","把每个判定分支单独写成一条用例"],"answer":[0],"explanation":"场景法核心是围绕基本流与备选流构造场景并组合。选项B只写基本流会漏掉异常分支；选项C是等价类/边界值思路；选项D是判定覆盖思路，均非场景法。"},{"id":257,"type":"single","stem":"提交缺陷报告时，把「复现步骤」写成「打开页面后随便点点就报错」，从缺陷管理角度看该缺陷最可能面临的处置是","options":["被退回要求补充可复现步骤","被直接关闭并标记为无效","被降级为建议类缺陷","被自动分配给开发修复"],"answer":[0],"explanation":"缺陷报告要求步骤可复现，描述模糊时应退回补充信息。选项B直接关闭会误杀真实缺陷；选项C降级与信息缺失无关；选项D在信息不足时分配开发会导致无效沟通。"},{"id":258,"type":"single","stem":"缺陷生命周期中，开发修改完成后将缺陷置为「已修复」，测试人员复测发现原问题不再出现但引发了新问题，此时正确的状态流转是","options":["关闭原缺陷并针对新问题另提缺陷","把原缺陷重新打开并描述新问题","把原缺陷置为已修复并备注新问题","把原缺陷置为延期并等待下个版本"],"answer":[0],"explanation":"原问题已修复应关闭，新引入的问题属于不同缺陷，应另立单跟踪。选项B混用同一缺陷会污染历史记录；选项C状态与事实不符；选项D延期适用于暂不修复的情形，与场景不符。"},{"id":259,"type":"single","stem":"缺陷严重程度（Severity）与优先级（Priority）的关系，下列理解正确的是","options":["严重程度高的问题优先级不一定高","严重程度高的问题优先级必然高","优先级高的问题严重程度必然高","严重程度与优先级由同一人评定"],"answer":[0],"explanation":"严重程度描述技术影响，优先级描述修复紧迫性，二者可分离，如崩溃但极少触发的缺陷严重高而优先级可低。选项B、C把二者绑定；选项D评定人可不同，测试评严重度、业务方定优先级更常见。"},{"id":260,"type":"single","stem":"使用 Selenium 编写自动化脚本时，页面元素在异步加载后延迟出现，最稳妥的等待方式是","options":["显式等待指定元素可见","固定 sleep 等待若干秒","隐式等待设置全局超时","刷新页面后立即查找元素"],"answer":[0],"explanation":"显式等待针对具体条件轮询，效率与稳定性最好。选项B固定 sleep 易受环境波动影响且拖慢执行；选项C隐式等待对单元素条件不够精确；选项D刷新会丢失页面状态。"},{"id":261,"type":"single","stem":"对同一批测试用例反复执行时，为降低脚本维护成本，自动化测试中更推荐的做法是","options":["采用页面对象模型封装元素定位","把定位表达式直接写在每条用例里","用坐标点击代替元素定位","每次执行前重新录制一遍脚本"],"answer":[0],"explanation":"页面对象模型将定位与操作集中封装，界面变化时只需改一处。选项B散落定位导致维护量大；选项C坐标点击对分辨率敏感；选项D重录成本高且不可持续。"},{"id":262,"type":"single","stem":"在缺陷跟踪系统中，测试人员发现某缺陷在最新版本已无法复现，但代码未做相关修改，此时较合理的处置是","options":["标记为无法复现并附上验证环境信息","直接关闭该缺陷且不做任何说明","把缺陷重新打开要求开发排查","将缺陷严重程度改为最低级"],"answer":[0],"explanation":"无法复现时应如实标记并保留环境、版本、数据等信息以便后续追踪。选项B无说明关闭会丢失线索；选项C在无证据时重开易造成无效往返；选项D改严重度与复现性无关。"},{"id":263,"type":"multi","stem":"关于测试用例设计方法的选用，下列做法合理的有","options":["参数取值有限且需覆盖边界时用边界值分析法","业务存在多条分支流程时用场景法梳理基本流与备选流","输入条件之间存在逻辑组合约束时用判定表法","只需验证一条正常流程时用等价类划分覆盖全部输入","时间紧迫且质量要求高时随机挑几条用例执行"],"answer":[0,1,2],"explanation":"边界值、场景法、判定表分别对应边界覆盖、流程分支、条件组合，选用合理。选项D等价类划分不能靠一条正常流程覆盖全部输入；选项E随机挑用例会遗漏关键覆盖，违背测试充分性要求。"},{"id":264,"type":"single","stem":"用等价类划分法为「用户名长度6到20个字符」设计测试用例时，下列哪组数据最适合作为该规则的有效等价类代表值","options":["5、6、20、21","6、13、20","1、6、20、100","0、6、13、20"],"answer":[1],"explanation":"知识点是等价类划分中有效等价类取代表值。有效等价类是6到20之间的合法长度，取边界内和中间值6、13、20即可覆盖。选项A中5和21属于无效等价类边界，混入了无效值；选项C中1和100是无效等价类值，不能作为有效类代表；选项D中0属于无效值，混入后不再是纯有效等价类代表。"},{"id":265,"type":"single","stem":"在缺陷管理流程中，测试人员提交的缺陷被开发人员标记为「无法重现」后，测试人员下一步最恰当的做法是","options":["直接关闭该缺陷并记录为无效","补充复现步骤、环境信息和日志后重新激活","将该缺陷转给项目经理裁定责任","在缺陷描述中追加一句请再试一次"],"answer":[1],"explanation":"知识点是缺陷生命周期中「无法重现」状态的处理。正确做法是补充可复现的关键信息（步骤、环境、数据、日志）后重新激活，让开发能定位。选项A直接关闭会漏掉真实缺陷；选项C把技术复现问题上升为管理裁定，流程不当；选项D只追加一句话没有提供新信息，无法帮助复现。"},{"id":266,"type":"single","stem":"使用Selenium编写自动化测试时，页面元素在操作前需要等待其可点击，下列等待方式中最能兼顾稳定与效率的是","options":["Thread.sleep固定等待3秒","隐式等待统一设置10秒","显式等待直到元素可点击","循环刷新页面直到元素出现"],"answer":[2],"explanation":"知识点是自动化测试中的等待策略。显式等待针对具体条件（如elementToBeClickable）轮询判断，条件满足即继续，稳定且不浪费固定时间。选项A固定睡眠时间要么不够要么浪费；选项B隐式等待是全局兜底，对可点击条件判断不精确；选项D循环刷新会破坏页面状态且效率极低。"},{"id":267,"type":"single","stem":"某接口返回JSON中字段「status」取值应为枚举「active/inactive/pending」，测试时传入「ACTIVE」接口仍返回成功，这最可能暴露的问题是","options":["接口未对枚举值做大小写校验","接口返回码设计不符合REST规范","测试用例未覆盖正常枚举值","JSON解析库版本过低导致"],"answer":[0],"explanation":"知识点是接口参数校验与枚举边界测试。传入大写ACTIVE本应被拒绝却成功，说明服务端未对枚举做严格大小写匹配校验。选项B返回码规范与本次现象无关；选项C用例已覆盖了异常输入，方向相反；选项D解析库版本不会导致大小写被接受。"},{"id":268,"type":"single","stem":"在编写测试用例时，针对「登录密码错误3次锁定账户」这一规则，下列用例设计最能覆盖状态转换的是","options":["连续输错2次后输对一次","连续输错3次后再输正确密码","输错1次后关闭浏览器再登录","输错3次后等待5分钟再登录"],"answer":[1],"explanation":"知识点是状态转换测试。锁定规则的关键状态是「错误累计达到3次触发锁定」，需验证锁定后即使输入正确密码也应被拒。选项A未达到触发阈值；选项C只测1次错误后重新登录，未触及锁定；选项D等待时间与锁定状态验证无关，未验证锁定期内正确密码是否被拒。"},{"id":269,"type":"single","stem":"使用JMeter做性能测试时，要模拟100个用户各自独立登录并持续压测，最应配置的组件是","options":["线程组线程数100，循环1次","线程组线程数100，勾选调度器","线程组线程数100，使用CSV数据文件传参","线程组线程数1，循环100次"],"answer":[2],"explanation":"知识点是性能测试中并发用户与参数化。100个独立用户需要不同账号，用CSV数据文件为每个线程提供独立参数。选项A线程数对但无参数化，100线程会用同一账号；选项B调度器只控制运行时长；选项D是单用户循环100次，不是100并发用户。"},{"id":270,"type":"single","stem":"测试用例评审会上，某条用例的预期结果写为「页面显示正常」，评审员应给出的最恰当修改意见是","options":["将预期结果改为具体的字段值和提示文案","补充该用例的执行人和执行时间","把用例优先级调整为最高","增加一条相同的用例做交叉验证"],"answer":[0],"explanation":"知识点是测试用例预期结果的可验证性。「显示正常」无法判定通过与否，必须写成可观测的具体值或文案。选项B执行信息不属于预期结果；选项C优先级与预期结果描述无关；选项D重复用例不能解决预期结果模糊的问题。"},{"id":271,"type":"single","stem":"自动化测试脚本中，登录操作在多个用例里重复出现，为降低维护成本最合适的重构方式是","options":["把登录步骤复制到每个用例开头","把登录封装为公共方法供用例调用","把登录用例单独执行其余用例跳过","在每个用例中增加登录成功断言"],"answer":[1],"explanation":"知识点是自动化测试脚本的可维护性设计。将重复的登录操作封装为公共方法（或页面对象），一处修改全局生效。选项A复制导致修改时需改多处；选项C跳过登录会使后续用例前置条件缺失；选项D增加断言不能消除重复代码。"},{"id":272,"type":"single","stem":"某缺陷在测试环境必现，但在开发本地环境无法复现，测试人员排查时首先应对比的是","options":["双方的操作系统登录用户名","双方的环境配置与数据版本","双方使用的键盘品牌型号","双方的显示器分辨率设置"],"answer":[1],"explanation":"知识点是环境差异导致的缺陷复现排查。环境配置（依赖版本、配置项）和数据版本是导致环境差异缺陷的首要因素。选项A登录用户名通常不影响业务逻辑；选项C键盘品牌与软件行为无关；选项D分辨率只影响界面显示，不是必现缺陷的首要排查项。"},{"id":273,"type":"single","stem":"在测试一个购物车功能时，需求写明「满100元减10元」，测试人员设计了99元、100元、101元三个用例，这属于哪种测试设计方法","options":["等价类划分","边界值分析","错误推测","因果图"],"answer":[1],"explanation":"知识点是边界值分析。针对阈值100元取刚好低于、等于、刚好高于的边界值，是边界值分析的典型应用。选项A等价类划分取的是类内代表值而非紧贴边界；选项C错误推测依赖经验猜测易错点；选项D因果图用于梳理输入条件与输出的逻辑组合。"},{"id":274,"type":"single","stem":"回归测试中，开发修复了一个底层公共模块的缺陷，测试负责人安排测试范围时最恰当的策略是","options":["只重测该缺陷对应的那条用例","只重测该模块的直接相关用例","重测该模块及所有调用它的上层功能","重测全部用例不做任何筛选"],"answer":[2],"explanation":"知识点是回归测试的范围确定。底层公共模块被修改会影响所有调用方，回归应覆盖该模块及其上层调用链。选项A范围过窄会漏掉受影响功能；选项B忽略了上层调用方的连带影响；选项D全量重测成本过高且无必要。"},{"id":275,"type":"single","stem":"缺陷报告中「严重程度」与「优先级」的关系，下列描述正确的是","options":["严重程度高则优先级必然高","优先级高则严重程度必然高","两者相互独立需分别评估","优先级由严重程度唯一决定"],"answer":[2],"explanation":"知识点是缺陷严重程度与优先级的辨析。严重程度衡量缺陷对功能的影响，优先级衡量修复的紧迫性，两者独立评估。选项A错误，如界面文字错别字严重程度低但对外发布优先级可能高；选项B错误，如偶发崩溃严重程度高但当前版本可不急修；选项D错误，优先级还受发布计划、影响用户数等因素影响。"},{"id":276,"type":"single","stem":"用等价类划分法为「年龄输入框（允许18到60的整数）」设计测试用例时，下列哪个输入值属于有效等价类","options":["17","18","61","abc"],"answer":[1],"explanation":"知识点是等价类划分中的有效/无效等价类。18落在允许区间[18,60]内，是有效等价类；17小于下边界属于无效等价类；61超过上边界属于无效等价类；abc是非整数类型，也属于无效等价类。"},{"id":277,"type":"single","stem":"在判定表中，「若用户已登录且购物车非空则显示结算按钮」这条规则对应的条件项取值组合是","options":["已登录=是，购物车非空=是","已登录=是，购物车非空=否","已登录=否，购物车非空=是","已登录=否，购物车非空=否"],"answer":[0],"explanation":"知识点是判定表条件桩与动作桩的对应关系。规则要求两个条件同时成立才触发动作，因此只有「已登录=是且购物车非空=是」这一组合对应显示结算按钮；其余三种组合至少有一个条件不满足，不触发该动作。"},{"id":278,"type":"single","stem":"某缺陷在开发人员本地无法复现，测试人员下一步最合适的做法是","options":["直接关闭该缺陷并标注无法复现","补充复现步骤、环境信息与日志后重新指派","把缺陷优先级改为最低后继续等待","将缺陷转给产品经理判定是否保留"],"answer":[1],"explanation":"知识点是缺陷生命周期中的「无法复现」处理。补充复现步骤、环境与日志能帮助开发定位，是标准做法；直接关闭会丢失问题线索；改优先级不解决复现问题；转产品经理不属于缺陷复现的技术处理路径。"},{"id":279,"type":"single","stem":"某项目采用敏捷开发，每个迭代两周，回归测试用例数量大且手工执行耗时，最应该优先引入的自动化对象是","options":["本迭代新增功能的探索性测试","核心业务流程的冒烟与回归用例","一次性的界面样式走查用例","需求评审阶段的用例头脑风暴"],"answer":[1],"explanation":"知识点是自动化测试的适用场景选择。核心业务流程稳定、重复执行频率高，最适合自动化回归；探索性测试依赖人的判断不适合自动化；一次性样式走查执行次数少，投入产出比低；头脑风暴属于人工活动。"},{"id":280,"type":"single","stem":"提交缺陷时，把「预期结果」写成「应该正常显示」，这种写法最主要的问题是","options":["没有给出可判定的期望输出","没有标注缺陷的严重程度","没有附上开发人员姓名","没有写明测试用例的编号"],"answer":[0],"explanation":"知识点是缺陷报告的可判定性要求。预期结果必须具体可验证，「正常显示」无法作为判定依据；严重程度是另一个字段；开发人员姓名和用例编号不是预期结果字段的核心要求。"},{"id":281,"type":"single","stem":"用边界值分析法测试「密码长度6到12位」时，除6和12外还应重点选取的边界值是","options":["5和13","0和20","7和11","1和100"],"answer":[0],"explanation":"知识点是边界值分析中的上点、离点选取。6和12是上点，紧邻的5和13是离点，最易暴露边界判断错误；0和20、1和100离边界过远，属于一般等价类取值；7和11是区间内部值，不是边界。"},{"id":282,"type":"single","stem":"某测试用例执行后发现缺陷，开发修复并提交新版本，测试人员首先应执行的操作是","options":["直接对该缺陷执行关闭操作","在新版本上重跑该缺陷对应的用例验证修复","重新编写该模块的全部测试用例","把缺陷状态改为已解决并等待下次迭代"],"answer":[1],"explanation":"知识点是缺陷验证流程。修复后必须在对应版本重跑相关用例确认问题消失，才能进入关闭环节；未验证直接关闭不符合流程；重写全部用例成本过高且非必需；仅改状态而不验证无法确认修复有效。"},{"id":283,"type":"single","stem":"自动化测试脚本中大量使用硬编码的账号、密码和URL，最直接的改进措施是","options":["把配置抽取到独立配置文件或环境变量中","在每个脚本里增加注释说明这些值","把账号密码改为更长的字符串","将脚本拆分成更多的小文件"],"answer":[0],"explanation":"知识点是自动化测试的可维护性与配置管理。抽取配置便于多环境切换和集中维护；加注释不改变硬编码的本质；改长字符串不解决环境适配问题；拆分文件与配置外置是两回事。"},{"id":284,"type":"single","stem":"某电商项目在大促前临时修改了支付回调接口，测试时间只有一天，此时回归测试范围应优先覆盖","options":["全部历史功能用例并逐一执行","与支付回调直接相关的功能及主交易链路","仅本次修改的那一行代码对应函数","所有页面的视觉样式与文案"],"answer":[1],"explanation":"知识点是回归测试的范围确定，属于基于风险的取舍。时间受限时应优先覆盖改动影响面及核心链路；全量执行在一天内不现实；只看单行代码会漏掉集成影响；视觉样式与本次改动无关。"},{"id":285,"type":"single","stem":"某系统登录界面要求用户名长度为6到12位，测试员只测试了6位和12位用户名并判定通过，该做法最可能遗漏的缺陷类型是","options":["边界外越界输入未校验","用户名大小写敏感问题","密码加密传输问题","登录验证码刷新问题"],"answer":[0],"explanation":"知识点：边界值测试需同时覆盖边界内、边界上、边界外。只测6和12位无法发现5位或13位越界输入是否被拒绝。大小写敏感、密码加密、验证码刷新均与本题干测试范围无关。"},{"id":286,"type":"single","stem":"在缺陷生命周期中，开发人员认为缺陷不是问题而拒绝修复，测试人员补充证据后该缺陷状态通常应流转为","options":["已关闭","重新打开","延期处理","重复提交"],"answer":[1],"explanation":"知识点：缺陷状态流转。被拒绝后测试人员补充证据证明缺陷存在，应重新打开（Reopen）继续处理。已关闭表示确认解决；延期处理指暂不修复；重复提交针对的是重复缺陷。"},{"id":287,"type":"single","stem":"缺陷报告中“复现步骤”一栏的主要作用是","options":["说明缺陷对业务的影响程度","让开发人员能稳定重现该问题","记录测试用例的执行结果","标注缺陷所属的功能模块"],"answer":[1],"explanation":"知识点：缺陷报告字段含义。复现步骤用于让开发人员按步骤稳定重现问题。影响程度属于严重程度或优先级；测试用例执行结果属于测试记录；所属模块属于模块或组件字段。"},{"id":288,"type":"single","stem":"自动化测试中，使用Selenium定位一个动态生成的元素时，最不稳定的定位方式是","options":["通过id属性定位","通过name属性定位","通过绝对XPath路径定位","通过CSS选择器定位"],"answer":[2],"explanation":"知识点：自动化测试元素定位稳定性。绝对XPath依赖页面层级结构，页面微调即失效，最不稳定。id、name、CSS选择器相对稳定，只要属性不频繁变动即可。"},{"id":289,"type":"single","stem":"在自动化测试脚本中，断言失败后脚本直接终止且未清理测试数据，最可能导致的问题是","options":["后续用例被脏数据干扰","测试报告无法生成","浏览器驱动版本不匹配","元素定位速度变慢"],"answer":[0],"explanation":"知识点：自动化测试的用例隔离与数据清理。断言失败后未清理数据会造成脏数据残留，干扰后续用例。测试报告、驱动版本、定位速度与是否清理数据无关。"},{"id":290,"type":"single","stem":"某测试员在缺陷管理工具中将一个导致系统崩溃的缺陷优先级设为“低”，最合理的解释是","options":["崩溃缺陷严重程度低","该缺陷不影响当前版本发布","缺陷被误判为重复缺陷","开发人员要求降低优先级"],"answer":[1],"explanation":"知识点：缺陷严重程度与优先级的区别。严重程度高但若不影响当前版本发布，优先级可设低。崩溃缺陷严重程度并不低；重复缺陷是状态问题；开发人员要求不是合理依据。"},{"id":291,"type":"single","stem":"在敏捷迭代中，测试人员发现一个已修复缺陷在回归测试中再次出现，正确的处置是","options":["直接关闭该缺陷并新建一个","重新打开原缺陷并关联回归记录","将该缺陷标记为延期处理","删除原缺陷后重新提交"],"answer":[1],"explanation":"知识点：回归测试与缺陷重开。已修复缺陷再次出现应重新打开原缺陷并关联回归记录，便于统计修复质量。直接关闭并新建会丢失缺陷历史；延期处理不解决重现问题；删除后重提交破坏可追溯性。"},{"id":292,"type":"single","stem":"某电商项目在“双十一”前只对下单主流程做了自动化脚本，未覆盖优惠券叠加场景，上线后出现优惠券金额计算错误，该案例说明自动化测试设计时最应优先补充的是","options":["增加脚本执行并发数","补充高风险业务组合场景","更换自动化测试工具","提高脚本注释覆盖率"],"answer":[1],"explanation":"知识点：自动化测试的场景选择应基于风险。优惠券叠加属于高风险业务组合场景，应优先补充。并发数、更换工具、注释覆盖率均不能解决场景缺失问题。"},{"id":293,"type":"multi","stem":"在测试用例设计过程中，下列做法有助于提高用例可维护性的有","options":["用例步骤使用统一的动作描述模板","将测试数据与用例步骤分离存放","在用例标题中写明预期结果","对同一功能重复编写完全相同用例","用例编号采用可追溯的命名规则"],"answer":[0,1,4],"explanation":"知识点：测试用例可维护性设计。统一动作模板、数据与步骤分离、可追溯编号均提升可维护性。在标题写预期结果会降低可读性且易与步骤重复；重复编写相同用例增加维护成本且无收益。"},{"id":294,"type":"single","stem":"在等价类划分中，某输入框要求输入1到100的整数，下列哪组测试数据覆盖了全部有效等价类和两个无效等价类","options":["50、0、101","1、100、50","0、101、-1","50、100、1"],"answer":[0],"explanation":"知识点是等价类划分的有效与无效等价类覆盖。有效等价类为1~100，无效等价类为小于1和大于100，选项0中50为有效、0和101分别覆盖两个无效类，覆盖完整；选项1全部是有效等价类，缺少无效类；选项2中0、101、-1都属无效类，缺少有效类；选项3全部是有效等价类，缺少无效类。"},{"id":295,"type":"single","stem":"某缺陷报告写道“登录功能有问题，点登录没反应”，从缺陷管理规范看该报告最需要补充的是","options":["缺陷的严重等级和优先级","重现步骤、环境与预期实际结果","开发人员的修复方案","测试用例的编号与执行人"],"answer":[1],"explanation":"知识点是缺陷报告要素完整性。缺陷报告核心是让开发能重现问题，必须包含重现步骤、测试环境、预期结果与实际结果；选项0严重等级和优先级是分类属性，缺失不影响重现但非当前最需补充；选项2修复方案属于开发职责，不是报告人必须提供；选项3用例编号和执行人是追溯信息，不是重现问题的关键。"},{"id":296,"type":"single","stem":"使用Selenium编写自动化测试时，页面元素每次刷新后id都会变化，最稳妥的定位策略是","options":["改用XPath按绝对路径定位","改用CSS选择器按class定位","改用相对XPath结合稳定的文本或属性定位","改用id加通配符模糊匹配定位"],"answer":[2],"explanation":"知识点是自动化测试中元素定位的稳定性。id动态变化时，应选择相对稳定且语义明确的属性或文本用相对XPath定位；选项0绝对XPath依赖层级，页面微调即失效且脆弱；选项1若class也动态或不唯一则不可靠；选项3用id通配符模糊匹配易匹配到多个元素或失效。"},{"id":297,"type":"single","stem":"某测试员执行回归测试时发现上次已修复的缺陷再次出现，正确的首要处置是","options":["直接重新打开原缺陷并注明回归失败","新建一个缺陷并把原缺陷关闭","忽略该现象继续执行其余用例","在缺陷中改严重等级后通知产品经理"],"answer":[0],"explanation":"知识点是缺陷生命周期中的回归失败处理。已修复缺陷重现应重新打开原缺陷并注明回归结果，保留历史关联；选项1新建缺陷会割裂与原修复的关联，导致追溯困难；选项2忽略会漏掉回归问题；选项3仅改等级未记录重现事实，处置不完整。"},{"id":298,"type":"single","stem":"某电商项目在“双十一”前需对下单支付链路做性能验证，测试团队应优先选择的测试类型和关注指标组合是","options":["功能测试，关注用例通过率与缺陷密度","负载测试，关注响应时间与吞吐量","兼容性测试，关注不同浏览器渲染差异","安全测试，关注SQL注入与越权访问"],"answer":[1],"explanation":"知识点是性能测试类型与指标。大促前下单支付链路的核心风险是高并发下的响应与处理能力，应做负载测试并关注响应时间、吞吐量等指标；选项0功能测试关注正确性，不解决并发容量问题；选项2兼容性测试关注多端展示，与容量无关；选项3安全测试关注漏洞，不覆盖高并发性能风险。"},{"id":299,"type":"single","stem":"使用等价类划分法为“用户年龄输入框（允许18至60周岁）”设计测试用例时，下列哪一项属于有效的边界值用例设计","options":["输入17与18分别测试","输入18与60分别测试","输入0与100分别测试","输入18.0与60.0分别测试"],"answer":[1],"explanation":"知识点：等价类划分中的边界值分析，有效边界应取边界上的合法值。正确项：18和60是有效区间的两个端点，属于有效边界值用例。错误项：17是有效区间外的无效值，与18组合测试的是无效下边界；0和100远离有效边界，属无效等价类取值；18.0与60.0形式上虽数值相同，但年龄输入框通常按整数处理，小数写法并非标准边界值设计。"},{"id":300,"type":"multi","stem":"某测试人员对登录功能执行自动化回归时，发现脚本在本地运行通过、在持续集成环境却频繁失败，排查发现失败均发生在点击“登录”按钮后的元素定位环节；下列处置措施中恰当的有","options":["将固定等待改为显式等待目标元素可点击","为登录后页面元素增加唯一且稳定的定位属性","在脚本开头统一加入固定睡眠十秒再操作","将失败截图与页面源码保存到测试报告中","把该条用例从回归集中移除以降低失败率"],"answer":[0,1,3],"explanation":"知识点：自动化测试稳定性与缺陷定位。正确项：显式等待可适配环境加载差异；稳定唯一的定位属性可降低元素定位脆弱性；保存失败截图与源码便于复现和定位。错误项：固定睡眠十秒只是掩盖问题且拖慢执行，不能保证元素已就绪；直接移除用例会丢失回归覆盖，属于掩盖缺陷而非处置问题。"}]}