QA考核试题(附答案)

QA考核试题(附答案)一、单项选择题（每题2分，共20分）1.以下关于软件测试原则的描述，错误的是（）A.测试应尽早介入，覆盖需求分析阶段B.完全测试是不可能的，需基于风险选择测试用例C.缺陷具有群集现象，80%的缺陷集中在20%的模块中D.测试应由开发人员执行，以确保对代码的深度理解2.某电商系统支付功能需支持微信、支付宝、银联三种方式，且每种方式需验证支付成功、失败、超时三种场景。若使用正交试验法设计测试用例，至少需要（）个用例覆盖所有组合A.3B.6C.9D.123.缺陷报告中“重现步骤”的核心要求是（）A.详细描述操作路径，包括具体输入数据和系统状态B.仅记录关键操作，避免冗余信息C.重点说明预期结果与实际结果的差异D.标注缺陷发现的测试环境配置4.以下不属于性能测试指标的是（）A.TPS（事务处理速率）B.内存泄漏C.并发用户数D.错误率5.自动化测试脚本开发中，“数据驱动”设计模式的主要目的是（）A.减少脚本维护成本，通过外部数据文件驱动测试逻辑B.提高脚本执行速度，避免重复编码C.增强脚本的可读性，符合代码规范D.支持多浏览器并行执行6.对“用户注册时，手机号需符合11位数字格式”进行测试，最适合的用例设计方法是（）A.场景法B.边界值分析C.等价类划分D.因果图7.以下关于测试用例评审的描述，正确的是（）A.仅需测试团队内部评审，确保用例覆盖全面B.需开发、产品、测试人员共同参与，验证需求理解一致性C.评审重点是用例格式是否规范，无需关注逻辑合理性D.评审应在测试执行完成后进行，用于总结经验8.某系统升级后，需验证原有核心功能是否受影响，应执行（）A.冒烟测试B.回归测试C.压力测试D.验收测试9.缺陷生命周期中，“Reopened”状态通常出现在（）A.测试人员提交缺陷后，开发人员首次确认B.开发人员修复缺陷，测试人员验证未通过C.缺陷修复后，测试人员验证通过D.缺陷因优先级低被暂时搁置10.以下关于接口测试的描述，错误的是（）A.需验证接口参数的正确性、业务逻辑的合理性B.仅需关注返回状态码（如200、404），无需检查返回数据内容C.可使用Postman、Jmeter等工具辅助测试D.需考虑接口的幂等性、安全性（如Token验证）二、多项选择题（每题3分，共15分，多选、少选、错选均不得分）11.测试计划的核心内容包括（）A.测试范围与目标B.测试资源（人员、工具、环境）分配C.测试进度安排D.缺陷管理流程12.以下属于黑盒测试方法的是（）A.路径覆盖B.等价类划分C.边界值分析D.状态转移测试13.自动化测试的适用场景包括（）A.需求频繁变更的项目B.重复执行的回归测试C.关键业务流程的冒烟测试D.探索性测试14.性能测试中，常见的性能瓶颈可能出现在（）A.数据库查询效率（如索引缺失）B.服务器硬件配置（如CPU、内存不足）C.前端页面渲染逻辑（如大量JS阻塞）D.网络带宽限制15.测试人员在需求评审中的职责包括（）A.确认需求描述的清晰性、完整性B.识别需求中的模糊点或矛盾点C.评估需求对测试设计的影响（如测试复杂度、资源需求）D.直接修改需求文档中的错误描述三、简答题（每题5分，共30分）16.简述V模型与W模型的核心区别，并说明W模型的优势。17.设计测试用例时，“覆盖性”与“有效性”的含义分别是什么？如何平衡二者？18.缺陷报告中“严重程度”与“优先级”的区别是什么？请举例说明。19.自动化测试脚本设计时，为什么需要使用“页面对象模式（PageObjectModel）”？20.性能测试中，如何判断“响应时间过长”是由前端还是后端引起的？21.测试过程中发现某功能与需求文档描述不一致，但产品经理声称“需求已口头变更，未更新文档”，此时测试人员应如何处理？四、案例分析题（共35分）22.（15分）某银行APP“转账功能”需求如下：支持本行卡、他行卡转账（他行卡需选择开户行）单日转账限额：本行卡50万元，他行卡20万元转账金额需为100元整数倍（最低100元，最高不超过单日限额）需验证收款方姓名与银行卡号的一致性（不一致时提示“信息不符”）转账成功后发送短信通知（含转账金额、时间、对方账户后4位）请设计该功能的测试用例（至少10条），要求覆盖功能、边界、异常、安全等维度。23.（10分）某系统登录模块自动化测试脚本执行时频繁报错“元素未找到”，可能的原因有哪些？请提出至少3种排查方法。24.（10分）某电商大促活动前，对核心交易系统进行性能测试，发现“下单接口”TPS（每秒事务数）仅为200，而预期目标为500。请从测试和开发两个角度分析可能的原因，并提出改进建议。答案一、单项选择题1.D（测试应避免由开发人员单独执行，需保持独立性）2.C（3种支付方式×3种场景=9种组合，正交试验法在因子数与水平数较少时可直接覆盖）3.A（重现步骤需可重复，需包含具体操作、输入数据、系统状态）4.B（内存泄漏属于稳定性测试关注的内容，非性能指标）5.A（数据驱动通过外部数据文件（如Excel、CSV）分离测试数据与逻辑，降低维护成本）6.C（验证格式符合性，等价类划分可将手机号分为有效等价类（11位数字）和无效等价类（非11位、含非数字字符等））7.B（测试用例评审需多角色参与，确保需求理解一致）8.B（回归测试用于验证原有功能是否受变更影响）9.B（开发修复后测试未通过，需重新打开缺陷）10.B（接口测试需验证返回数据内容的正确性，如字段是否完整、数值是否符合业务规则）二、多项选择题11.ABCD（测试计划需明确范围、资源、进度、流程等关键要素）12.BCD（黑盒测试基于需求，不关注内部代码；路径覆盖属于白盒测试）13.BC（需求频繁变更时自动化维护成本高，探索性测试依赖人工经验，不适合自动化）14.ABCD（性能瓶颈可能出现在数据库、服务器、前端、网络等多个层面）15.ABC（测试人员无权限直接修改需求文档，需推动产品经理更新）三、简答题16.核心区别：V模型仅体现测试与开发阶段的对应关系（如单元测试对应编码，系统测试对应系统设计），未强调需求阶段的测试；W模型将测试与开发同步进行（如需求分析阶段同步开展需求测试，设计阶段同步开展设计测试）。优势：W模型更早介入测试，可在需求或设计阶段发现缺陷，降低修复成本。17.覆盖性：测试用例对需求或功能点的覆盖程度（如是否覆盖所有输入场景、业务规则）；有效性：用例能高效发现缺陷的能力（如重点场景用例应优先设计）。平衡方法：通过风险评估识别高风险功能（如核心交易、高频操作），对其设计详细用例（覆盖性+有效性）；低风险功能可适当简化用例（侧重覆盖性）。18.严重程度：缺陷对系统功能/性能的影响程度（如“交易失败”为严重，“界面文字错别字”为轻微）；优先级：缺陷需修复的紧急程度（如大促前“交易失败”缺陷优先级为高，日常迭代中“错别字”优先级为低）。示例：某支付接口返回错误码导致交易失败（严重程度：致命），若发生在大促当天（优先级：高），需立即修复；若发生在内部测试阶段（优先级：中），可安排次日修复。19.页面对象模式将页面元素（如按钮、输入框）和操作（如点击、输入）封装为独立类，避免脚本中直接硬编码元素定位符。优势：①提高脚本可维护性（页面变更时仅需修改对应类，无需调整所有调用脚本）；②增强可读性（通过方法名直观描述操作）；③减少代码冗余（复用页面操作逻辑）。20.判断方法：①前端层面：使用浏览器开发者工具（如ChromeDevTools）的“Network”标签，查看页面加载时各请求的响应时间，若“DOMContentLoaded”或“Load”时间过长，可能是前端渲染（如JS执行、图片加载）导致；②后端层面：通过服务器日志或APM工具（如Zipkin）追踪接口调用链，若接口响应时间（如数据库查询、逻辑计算）超过阈值，可能是后端性能问题；③对比测试：单独测试后端接口（绕过前端），若接口响应时间正常，则问题可能在前端；若接口响应时间仍过长，则问题在后端。21.处理步骤：①记录当前功能实际表现与原需求的差异，同步产品经理要求提供“口头变更”的依据（如会议记录、聊天记录）；②推动产品经理更新需求文档，明确变更内容（避免后续争议）；③若变更涉及测试范围调整（如新增功能、修改规则），重新评估测试用例并补充测试；④若变更未被正式确认，将当前功能标记为“需求不明确”，暂停测试并上报测试负责人协调。四、案例分析题22.测试用例设计（示例）：用例编号测试项输入/操作预期结果测试类型TC01本行卡转账（正常）输入本行卡号、姓名（一致）、金额100元转账成功，短信通知包含金额、时间、对方卡号后4位功能测试TC02他行卡转账（正常）输入他行卡号、选择开户行、姓名（一致）、金额20万元转账成功功能测试TC03本行卡超单日限额金额500001元（本行限额50万）提示“超过单日转账限额”边界测试TC04他行卡金额非100元整数倍金额150元（符合）、155元（不符合）150元：可提交；155元：提示“金额需为100元整数倍”异常测试TC05收款方姓名与卡号不一致输入正确卡号+错误姓名提示“收款方信息不符”功能测试TC06他行卡未选择开户行输入他行卡号、未选开户行、其他信息正确提示“请选择开户行”异常测试TC07转账金额99元（低于最低限额）输入金额99元提示“金额最低100元”边界测试TC08同一卡号连续转账（防重复提交）快速点击“确认转账”两次仅一次转账成功，第二次提示“操作已提交，请勿重复请求”安全测试TC09转账时网络中断（断网恢复后）提交转账时关闭网络，恢复后查看页面提示“网络异常”，恢复后可重新提交健壮性测试TC10短信通知内容完整性转账成功后查看短信包含金额（如“5000元”）、时间（如“2023-10-0114:30”）、对方卡号后4位（如“1234”）功能测试23.可能原因及排查方法：原因①：页面元素定位方式不稳定（如使用动态ID、XPath层级过深）；排查方法：检查元素定位表达式，改用更稳定的定位方式（如CSS选择器、基于文本的定位），或通过工具（如SeleniumIDE）验证定位是否准确。原因②：脚本执行速度过快，元素未加载完成即尝试操作；排查方法：添加显式等待（如WebDriverWait），设置超时时间并等待元素可见/可点击后再操作。原因③：测试环境不稳定（如前端框架升级导致页面结构变化）；排查方法：对比测试环境与脚本开发环境的页面版本，确认是否有代码变更未同步，若有则更新元素定位方式。原因④：多浏览器兼容性问题（如Chrome与Firefox的元素渲染差异）；排查方法：在目标浏览器中单独执行脚本，或使用浏览器工具（如BrowserStack）验证元素在不同浏览器中的表现。24.测试角度原因及建议：原因：性能测试场景设计不合理（如未模拟真实用户行为，仅测试接口本身未关联上下游系统）；建议：基于用户行为日志设计混合场景（如下单+支付+查询），更贴近实际流量。原因：测试数据准备不充分（如数据库数据量过小，未触发真实索引或缓存机制）；建议：使用生产数据脱敏后填充测试库，确保数据库压力与生产环境一致。开发角度原因及建议：