测试实战面试常见问题题目及答案

测试实战面试常见问题题目及答案一、基础概念类【问题1】什么是软件测试？软件测试的核心目标是什么？【参考答案】软件测试是在规定条件下对程序、系统或其附属文档进行操作，以发现程序错误、衡量软件质量，并评估其是否满足设计要求的过程。核心目标分为三层：第一层是缺陷检出，尽可能早、尽可能全地发现软件全生命周期中的缺陷，降低缺陷流入线上的概率；第二层是质量评估，通过可量化的测试数据，客观评估软件在功能完整性、性能稳定性、安全性、兼容性等维度的质量水平，为项目上线决策提供核心依据；第三层是风险防控，通过测试左移、右移的全流程介入，提前识别需求歧义、设计缺陷、代码逻辑漏洞等风险，减少项目后期返工成本，同时监控线上运行状态，避免软件问题给企业造成经济损失、品牌负面影响。【问题2】请阐述黑盒测试、白盒测试、灰盒测试的区别及适用场景。【参考答案】三类测试的核心差异在于测试过程中是否关注程序内部逻辑实现：1.黑盒测试：也叫功能测试，测试过程中完全不关注程序内部代码逻辑，仅把程序看作不可见的黑盒，只验证输入和输出是否符合需求要求。适用场景包括系统测试、验收测试阶段的功能验证、兼容性测试、易用性测试等，是普通功能测试工程师最常用的测试方法。2.白盒测试：也叫结构测试，测试过程中完全开放程序内部逻辑，通过检查代码的分支、路径、循环、变量赋值等逻辑是否符合设计要求，针对性设计测试用例。适用场景包括单元测试、集成测试阶段的代码逻辑校验，通常由开发工程师或白盒测试工程师执行。3.灰盒测试：介于黑盒和白盒之间，既关注输入输出的正确性，也会参考部分内部逻辑实现来设计用例，不需要完全通读所有代码，仅需要了解核心模块的逻辑交互规则。适用场景包括集成测试阶段的接口测试、跨模块业务逻辑测试，是当前自动化测试、接口测试最常用的测试方法。【问题3】测试左移和测试右移分别是什么？对测试工作有什么价值？【参考答案】测试左移指将测试活动向软件生命周期的前期阶段延伸，打破“测试仅在开发完成后介入”的传统模式，在需求评审、方案设计、代码开发阶段就同步介入测试工作；测试右移指将测试活动向软件生命周期的后期延伸，打破“测试在上线后就结束”的模式，在上线后持续开展线上灰度测试、用户反馈收集、系统运行监控、故障复盘等工作。两者的核心价值：测试左移可以提前发现需求歧义、设计逻辑漏洞、代码不规范等问题，避免缺陷在后期迭代中放大，据行业统计，需求阶段发现的缺陷修复成本仅为上线后修复成本的1/300，可大幅降低项目返工成本；测试右移可以覆盖测试环境无法模拟的真实用户场景、高并发场景，及时发现线上隐蔽缺陷，同时积累真实场景数据反哺线下测试用例设计，提升测试覆盖度。二、功能测试类【问题1】请描述一个完整的功能测试流程？【参考答案】完整的功能测试流程共分为9个核心环节：1.需求评审：参与产品需求评审、技术方案评审，识别需求歧义、隐性需求、逻辑矛盾、技术实现风险，输出测试风险点同步项目组；2.测试计划制定：根据项目迭代周期、需求优先级、人力配置，制定测试进度安排、测试范围、测试重点、风险应对方案，同步所有项目干系人；3.测试用例设计：结合需求文档、设计方案，用对应的用例设计方法输出测试用例，覆盖正常场景、异常场景、边界场景、隐性需求场景，并明确用例优先级；4.用例评审：邀请产品、开发、测试负责人参与用例评审，补充遗漏场景、修正不符合需求的用例，最终形成定稿用例；5.测试环境搭建：搭建和生产环境配置一致的测试环境，部署对应版本的代码，准备测试数据，验证环境可用性；6.测试执行：按照用例优先级从高到低执行测试，提交发现的缺陷，跟进缺陷修复进度；7.回归测试：开发修复缺陷后，针对修复的缺陷以及关联功能开展回归测试，验证缺陷确实关闭且没有引入新的问题；8.测试报告输出：测试完成后输出测试报告，包含测试范围、用例执行情况、缺陷统计、遗留问题、风险评估、上线建议等内容；9.上线跟进与复盘：上线过程中配合运维开展冒烟测试，上线后收集线上用户反馈，迭代结束后参与项目复盘，优化后续测试流程。【问题2】如何设计高质量的测试用例？常用的用例设计方法有哪些？分别适用于什么场景？【参考答案】高质量测试用例需要满足5个标准：覆盖全面（正常、异常、边界、隐性场景全覆盖）、优先级清晰、可执行性强（步骤明确、预期结果可量化）、独立性强（用例之间没有依赖关系）、可维护性强。常用的用例设计方法及适用场景：1.等价类划分法：将输入域划分为若干个等价类，从每个等价类中选取少量代表性数据作为测试用例，适用于输入框类功能的用例设计，比如手机号、身份证号、金额输入框，可大幅减少用例数量；2.边界值分析法：针对输入域的边界值、临界值设计用例，统计显示80%的缺陷出现在20%的边界场景中，适用于数值类输入、数量限制类功能的用例设计，比如登录密码长度限制、购物车加购数量上限、优惠券满减门槛；3.错误推测法：基于测试工程师的经验、过往缺陷数据，推测程序中可能存在的错误场景，针对性设计用例，适用于高频缺陷模块、核心业务模块的用例补充；4.场景法：通过模拟用户真实的操作流程，覆盖业务流的各个分支，适用于核心业务流程的用例设计，比如电商的下单支付流程、用户注册登录流程；5.正交试验法：通过正交表选取多因素、多水平的组合场景，适用于多参数组合类功能的用例设计，比如筛选功能有10个筛选条件，每个条件有3个选项，用正交试验法可在保证覆盖度的前提下大幅减少用例数量；6.因果图法：通过梳理输入条件之间的因果关系、约束关系设计用例，适用于输入条件之间存在关联逻辑的功能，比如优惠券叠加规则、满减规则的测试。【问题3】缺陷的生命周期是什么？提交缺陷时需要包含哪些核心要素？【参考答案】标准缺陷生命周期为：新建→确认→分配→修复→回归→关闭/重新打开。其中缺陷经测试提交后，先由测试负责人或开发负责人确认是否为有效缺陷，确认后分配给对应开发工程师修复，修复完成后测试工程师开展回归，回归通过则关闭缺陷，回归不通过则重新打开，退回开发再次修复。提交缺陷的核心要素包括：1.缺陷标题：清晰描述缺陷的核心内容，比如“安卓端V1.2.0版本使用微信支付100元以上金额时提示支付失败”；2.前置条件：明确复现缺陷需要的环境、账号、数据等前提；3.复现步骤：分点列出可复现缺陷的操作步骤，确保其他人员可以按照步骤100%复现；4.预期结果：按照需求要求的正确输出；5.实际结果：测试过程中实际出现的错误输出；6.严重程度：分为致命、严重、一般、轻微四个等级，致命缺陷指阻断核心业务流程、造成数据损失、安全漏洞的缺陷，轻微缺陷指不影响功能使用的UI类问题；7.优先级：分为高、中、低三个等级，高优先级缺陷需要在上线前修复，低优先级缺陷可以后续迭代优化；8.辅助信息：包含缺陷截图、错误日志、版本号、环境信息、复现概率等，大幅提升缺陷修复效率。【问题4】给你一个电商购物车功能，你会怎么测试？【参考答案】我会从6个维度开展全场景测试：1.功能测试：覆盖所有核心逻辑：①加购逻辑：不同类型商品（实物、虚拟、预售、秒杀、限购）的加购、未登录用户临时加购、加购数量上限校验、商品下架/删除后加购列表的展示；②编辑逻辑：修改加购数量、删除单个/批量删除商品、勾选/取消勾选单个/全部商品、商品移入收藏夹；③联动逻辑：勾选商品的总价计算、和优惠券/满减/运费规则的联动、库存不足时的提示、结算按钮跳转正确性；④特殊场景：多门店商品加购是否拆分结算、会员价/折扣价计算正确性、限购商品加购数量超过限购阈值的提示。2.界面测试：验证购物车页面在不同分辨率下的展示兼容性、文案正确性、按钮交互反馈正常、加载状态提示清晰。3.兼容性测试：验证不同操作系统（iOS/安卓）、不同设备型号、不同浏览器、不同APP版本下购物车功能的可用性。4.性能测试：验证加购100件以上商品时的页面加载速度、高并发场景下加购是否出现超卖、加购接口的响应时间≤200ms。5.安全测试：验证是否存在越权查看其他用户购物车的漏洞、加购时篡改商品参数是否会导致价格异常、购物车数据是否加密存储、接口是否存在SQL注入、XSS漏洞。6.异常测试：验证加购过程中断网/弱网时数据不会丢失、加购时商品库存被其他用户抢光的提示、用户账号登出后临时加购数据是否保留、APP崩溃后再次打开加购数据不丢失。三、自动化测试类【问题1】什么样的项目适合引入自动化测试？自动化测试的投入产出比（ROI）如何评估？【参考答案】适合引入自动化测试的项目需要满足4个条件：需求变更频率低、项目迭代周期≥6个月、每次迭代回归测试工作量大、核心业务流程长期稳定。典型场景包括电商核心交易流程、企业内部管理系统、金融类核心业务系统等。需求变动极快的短期项目、一次性交付项目不适合引入自动化测试，会出现脚本开发完成后需求已经变更，脚本无法复用的情况。ROI评估需要计算成本与收益：首先计算自动化测试总成本=脚本开发人力成本+迭代过程中脚本维护成本；再计算节省的人工成本=每次迭代回归测试人工耗时×迭代次数×人均日成本。当节省的人工成本≥自动化测试总成本时，即达到回本点。举个实际测算示例：某电商项目每次迭代核心流程回归需要3个测试工程师投入2个工作日，人均日成本按1000元计算，每次回归人工成本为6000元；自动化脚本开发投入15人日，成本15000元，每个迭代脚本维护成本为0.5人日即500元。迭代3次时，人工总成本为18000元，自动化总成本为15000+3×500=16500元，已经实现回本，迭代次数越多，ROI越高，行业内成熟项目的自动化测试ROI普遍可达1:5以上。【问题2】你常用的自动化测试框架有哪些？分别适用于什么场景？【参考答案】我会根据测试对象的不同选择对应的框架：1.Web端自动化：常用Selenium、Cypress框架。Selenium是开源跨浏览器自动化框架，支持多语言、多浏览器，适合需要做多浏览器兼容性测试的项目；Cypress是近年流行的前端自动化框架，安装简单、内置等待机制、脚本稳定性高，适合前端项目的端到端测试，测试执行效率比Selenium高30%以上。2.APP端自动化：常用Appium、AirTest框架。Appium是跨平台自动化框架，支持iOS、安卓原生应用、混合应用，适合常规APP的自动化测试；AirTest是网易开源的基于图像识别的自动化框架，不需要获取APP元素属性，适合游戏类APP、无法获取元素的定制化APP测试。3.接口自动化：常用Pytest+Requests、JMeter、Postman+Newman框架。Pytest+Requests是轻量的Python技术栈接口测试框架，支持参数化、断言、插件扩展，配合Allure报告可生成直观的测试报告，适合中小项目的接口自动化测试；JMeter支持高并发压测，适合需要同时做接口功能测试和性能测试的项目；Postman+Newman学习成本低，适合小型项目、测试团队技术能力较弱的场景快速搭建接口自动化体系。【问题3】如何保证自动化测试用例的稳定性？【参考答案】自动化用例的稳定性直接决定自动化测试的价值，我通常从5个维度优化：1.用例设计优化：每个用例保持独立，不依赖其他用例的执行结果，每个用例有独立的前置条件和后置数据清理逻辑，避免脏数据影响用例执行；优先选取核心、稳定的业务流程做自动化，变动频繁的非核心功能不纳入自动化用例集。2.元素定位优化：优先使用id、name、自定义data-testid属性定位元素，避免使用绝对路径xpath、动态属性（比如随机生成的class、id）定位，元素定位失败时给出明确的报错信息，便于排查问题。3.等待机制优化：全部使用显式等待，仅针对特定场景使用隐式等待，完全禁用硬等待（比如time.sleep），根据页面加载速度设置合理的等待阈值，避免因网络波动、页面加载慢导致用例失败。4.环境与数据优化：自动化测试环境单独部署，不与功能测试环境混用，避免数据被人为修改；测试数据提前预制，用例执行后立即清理产生的临时数据，保证每次执行用例的环境都是一致的。5.运行机制优化：设置合理的失败重试机制，偶发失败的用例自动重试2次，排除网络波动、第三方接口临时故障的影响；每次迭代后同步更新自动化用例，定期清理失效用例，保证用例和当前需求一致。通过以上优化，我之前负责的项目自动化用例通过率长期稳定在95%以上。【问题4】请描述接口测试的核心价值？接口测试用例设计需要覆盖哪些维度？【参考答案】接口测试的核心价值有三点：第一是测试效率高，接口测试比UI测试执行速度快5倍以上，且不受前端页面变更的影响，可在开发阶段提前介入，实现测试左移；第二是覆盖度广，可覆盖UI层无法模拟的异常场景、参数篡改场景，更容易发现底层逻辑漏洞、权限漏洞、数据校验漏洞；第三是维护成本低，接口变动频率远低于UI页面，自动化脚本的维护成本仅为UI自动化的1/3。接口测试用例需要覆盖5个维度：1.功能校验：覆盖参数正确性校验、必填项校验、参数长度/类型/格式校验、枚举值校验、异常参数返回正确性，比如传非规定范围内的参数接口是否返回正确的错误提示，不会出现500报错。2.业务逻辑校验：覆盖接口的核心业务逻辑，比如下单接口的金额计算是否正确、库存扣减是否准确、支付接口的回调逻辑是否正确、重复提交订单是否会生成多个订单。3.权限校验：覆盖未登录调用接口是否拦截、普通用户调用管理员权限接口是否拦截、跨用户调用接口是否拦截（比如A用户修改B用户的订单），避免越权漏洞。4.性能校验：覆盖单接口响应时间、并发场景下的接口吞吐量、错误率，核心接口的TP99响应时间需≤300ms。5.异常场景校验：覆盖超时、断网、第三方接口故障、数据库宕机等异常场景下接口的容错性，比如调用第三方支付接口超时后是否会自动重试，不会出现订单状态异常。四、性能测试类【问题1】什么是性能测试？常见的性能测试类型有哪些？核心指标分别是什么？【参考答案】性能测试是通过模拟真实用户的业务场景，对系统的各项性能指标进行测试，验证系统是否满足预期的性能需求，同时排查系统性能瓶颈，为性能调优提供依据的过程。常见的性能测试类型及核心指标：1.基准测试：对单接口、单功能进行低压测试，得到系统的基础性能数据，作为后续性能测试的基准参考，核心指标为单接口响应时间、吞吐量。2.负载测试：逐步增加系统的负载压力，测试系统在性能指标满足要求的前提下能承受的最大负载，核心指标为最大并发用户数、最大TPS（每秒事务数）。3.压力测试：持续增加系统负载，直到系统的某项性能指标达到阈值（比如错误率≥1%），测试系统的极限承载能力，核心指标为系统极限TPS、极限并发用户数。4.稳定性测试：也叫可靠性测试，模拟系统在生产环境的正常负载下持续运行7*24小时，验证系统是否能稳定运行，核心指标为系统运行过程中的错误率、资源使用率波动、是否出现内存泄漏、服务宕机等问题。5.容量测试：测试系统在数据量持续增长的情况下的性能表现，比如订单表数据量达到1亿条时的下单接口性能，核心指标为不同数据量级下的响应时间、吞吐量。通用核心性能指标包括：响应时间（TP50、TP90、TP99，其中TP90指90%的请求响应时间都低于该值，是衡量用户体验的核心指标）、吞吐量（TPS/QPS）、错误率、资源使用率（CPU、内存、磁盘IO、网络带宽使用率）。【问题2】你做性能测试的完整流程是什么？如果发现系统TPS上不去，你会怎么排查？【参考答案】完整的性能测试流程分为8个环节：1.需求分析：明确性能测试的范围、核心业务场景、预期性能指标；2.测试计划：制定测试进度、人员分工、环境配置方案、数据准备方案；3.环境搭建：搭建和生产环境配置一致的性能测试环境，包括应用服务器、数据库、中间件配置；4.脚本开发：录制/编写性能测试脚本，调试脚本的正确性，设置参数化、关联、断言；5.场景设计：设计基准测试场景、负载测试场景、压力测试场景、稳定性测试场景；6.测试执行：执行性能测试场景，同步监控施压端、服务端、数据库的各项指标；7.瓶颈分析与调优：针对性能瓶颈分析根因，联合开发、运维开展性能调优，调优后开展回归测试；8.测试报告输出：输出性能测试报告，包含测试结果、瓶颈分析、调优方案、上线建议。TPS上不去的排查思路按照从外到内的顺序：1.施压端排查：首先排查施压机器的CPU、内存、带宽是否达到瓶颈，如果是单台施压机器性能不足，采用分布式压测；检查压测工具配置是否正确，比如JMeter是否使用非GUI模式、线程数设置是否合理、是否禁用了不需要的监听器，排除施压端本身的问题。2.网络排查：检查施压端和被测系统之间的网络带宽、丢包率、延迟，是否存在网络瓶颈，跨地域压测需要排除网络延迟的影响。3.应用服务器排查：检查应用服务器的CPU、内存使用率，是否存在FullGC频繁、内存泄漏的问题，检查线程池、连接池配置是否合理，是否有线程阻塞的情况。4.中间件排查：检查Nginx的worker进程数、最大连接数配置是否合理，Redis的缓存命中率、连接数是否正常，MQ是否存在消息堆积，限流熔断组件是否被触发。5.数据库排查：检查数据库的CPU、IO使用率，是否存在慢SQL、锁等待、连接数不足的问题，是否有未建索引的查询、全表扫描的情况。6.架构排查：检查是否存在架构层面的瓶颈，比如没有做缓存、没有做读写分离、服务没有集群部署，导致单点压力过大。【问题3】如何模拟10万用户的并发场景？需要注意哪些问题？【参考答案】模拟10万用户并发需要采用分布式压测方案：将多台压测机器组成压测集群，一台作为控制节点，其他作为执行节点，控制节点将压测脚本下发到所有执行节点，所有执行节点同时向被测系统发起请求，汇聚起来即可达到10万并发的压力。以JMeter为例，只需在所有执行节点启动JMeter-server服务，控制节点配置执行节点的IP地址，即可实现分布式压测，单台普通配置的压测机器可支撑1万-2万的并发请求，10万并发只需要5-10台压测机器即可实现。模拟10万并发需要注意5个核心问题：1.环境配置一致性：压测环境的服务器配置、数据库配置、中间件配置必须和生产环境一致，否则压测结果不具备参考价值。2.数据预热：提前预制测试数据，包括用户账号、商品数据、订单数据，数据量级和生产环境一致，避免压测过程中大量创建数据导致性能结果不准。3.梯度加压：不要直接一次性加压到10万，采用梯度加压的方式，每3分钟增加1万并发，观察每个梯度下的性能指标变化，便于定位不同负载下的性能瓶颈。4.依赖屏蔽：压测过程中屏蔽第三方依赖接口，用Mock服务替代，避免第三方接口的性能瓶颈影响压测结果，同时避免压测请求发送到第三方服务，造成不必要的损失。5.压测后清理：压测完成后及时清理测试数据，避免污染正式环境，同时关闭压测进程，释放压测机器资源。五、安全测试类【问题1】常见的Web安全漏洞有哪些？分别怎么测试？【参考答案】按照OWASPTop10的高频漏洞，常见的安全漏洞及测试方法如下：1.SQL注入漏洞：攻击者通过在输入框提交恶意SQL语句，绕过权限校验或者获取、篡改数据库数据。测试方法：在输入框输入'or1=1--、unionselect1,user(),database()等恶意语句，看是否能绕过登录、返回数据库敏感信息，或者接口传入恶意SQL参数，看是否能执行成功。2.XSS跨站脚本漏洞：攻击者在页面植入恶意脚本，窃取用户Cookie、诱导用户跳转钓鱼网站。测试方法：在输入框输入<script>alert('xss')</script>等脚本语句，提交后看页面是否弹出弹窗，是否会执行植入的脚本。3.CSRF跨站请求伪造漏洞：攻击者诱导用户在已登录的情况下访问恶意网站，冒用用户身份执行操作。测试方法：用两个浏览器登录同一个账号，在一个浏览器提交操作请求，复制请求的参数，在另一个浏览器构造相同的请求提交，看是否能执行成功。4.越权访问漏洞：分为水平越权（同角色用户访问其他用户的私有数据）和垂直越权（低权限用户访问高权限用户的功能）。测试方法：用普通用户的Token调用管理员的接口，看是否能执行成功；用A用户的Token调用查询B用户订单的接口，看是否能返回B用户的订单数据。5.文件上传漏洞：攻击者上传恶意脚本文件到服务器，获取服务器权限。测试方法：上传后缀为.php、.jsp、.asp的脚本文件，看是否能上传成功，上传后访问文件路径看是否能执行脚本。6.敏感信息泄露漏洞：系统返回、日志、前端代码中泄露用户隐私数据、密钥等敏感信息。测试方法：查看接口返回是否有明文的密码、手机号、身份证号，查看前端控制台是否泄露API密钥、数据库账号密码，查看日志是否打印用户敏感信息。【问题2】如何测试用户登录功能的安全性？【参考答案】我会从7个维度开展测试：1.密码复杂度校验：测试系统是否要求密码长度≥8位，包含大小写字母、数字、特殊字符，弱密码是否无法注册、修改。2.密码传输存储安全：抓包查看登录接口的密码参数是否为明文传输，是否用HTTPS加密传输；数据库中密码是否为加盐哈希存储，不能明文存储。3.暴力破解防护：测试连续输错密码5次以上是否会锁定账号1小时，或者要求输入验证码，是否有防暴力破解的机制。4.验证码安全：测试验证码是否为一次性，使用过的验证码再次提交是否会失败，验证码是否有过期时间，是否能被OCR识别。5.会话安全：测试登录后的Session、Token是否有过期时间，退出登录后Token是否失效，无法再次使用；是否支持多端登录，异地登录是否有通知。6.异常登录防护：测试非常用设备、非常用地区登录是否需要二次验证，是否有异常登录提醒。7.其他漏洞：测试登录接口是否存在SQL注入、XSS漏洞，是否存在手机号枚举、用户名枚举的漏洞。六、测试管理与流程类【问题1】你所在的团队用的是什么开发流程？测试在其中的角色是什么？【参考答案】我之前所在的团队用的是敏捷Scrum开发流程，迭代周期为2周，测试在其中的角色覆盖全流程：1.迭代前期：参与需求梳理会、迭代规划会，评估需求的测试难度、测试工作量，识别需求风险，确定本次迭代的测试范围、测试重点。2.迭代中期：在开发写代码的阶段同步设计测试用例，开展用例评审，开发提测后执行测试，提交缺陷，跟进缺陷修复进度，开展回归测试。3.迭代后期：输出测试报告，给出上线建议，上线后配合运维做线上冒烟测试，收集线上用户反馈，参与迭代回顾会，总结本次迭代中的问题，提出测试流程优化方案。对于部分传统的政府类项目，我们会采用瀑布开发流程，测试在需求、设计、开发、验收每个阶段都介入，分别开展需求测试、设计评审、系统测试、验收测试，保障项目交付质量。【问题2】如果开发认为你提交的缺陷不是问题，你会怎么处理？【参考答案】我会按照4步流程处理：1.先自查：首先重新复现缺陷，确认是否是自己操作错误、环境配置错误、理解错需求导致的误报，排查是否有复现条件遗漏的情况。2.沟通举证：如果确认是有效缺陷，拿出需求文档、设计方案作为依据，和开发说明缺陷的影响范围、对用户的影响，如果需求中没有明确说明，就从用户体验、行业通用规则的角度和开发沟通，说明问题的影响。3.三方评审：如果和开发还是无法达成一致，就拉产品经理、测试负责人、开发负责人一起参与缺陷评审，按照评审的结论处理，如果评审认为是缺陷，开发需要按要求修复，如果评审认为不是缺陷，就记录评审结论，关闭缺陷。4.记录归档：将整个沟通的过程、评审结论记录在缺陷的备注中，同步给项目组，避免后续出现同类问题时产生纠纷。【问题3】项目上线前发现了一个严重bug，但修复会影响上线时间，你会怎么处理？【参考答案】我会按照风险分级的原则处理：1.首先评估缺陷的影响等级：如果是核心业务阻断类缺陷，比如下单支付失败、用户无法登录、会造成数据损失、安全漏洞的缺陷，必须要求开发优先修复，延期上线，同时向项目负责人说明风险，如果强行上线会给企业造成巨大的损失，修复完成后全量回归通过再上线。2.如果是非核心功能的缺陷，影响范围小，有明确的规避方案，不会造成数据损失或者安全问题，就拉产品、项目负责人、开发负责人一起评估风险，确认是否可以带缺陷上线，上线后通过紧急补丁修复，同时在测试报告中明确标注已知问题和风险，同步给所有项目干系人，告知客服应对用户咨