面试被问：测试环境没有问题，上线后有问题，或是测了 10 几次没有问题，之后出现问题，这个情况要如何避免？
今天面试遇到一个问题，如果说测试环境没有问题 上线后有问题，有的地方是没有测试到，或者说测了 10 几次没有问题，之后出现问题 这个情况要如何避免
回答·12
最热
最新
- 没有测到说明是漏测如何避免漏测可以通过： case 评审 大家一块评估测试范围 这个应该很常见的方法 其次借助代码覆盖率工具评估是否被覆盖这是一个技术方法 交叉测试 也是很常见的方法 探索测试 是近年来敏捷开发倡导的方法 测了很多次没测出来多数是我们的测试环境不够复杂比如 测试数据不标准，数据量不够 数据类型覆盖不全等 网络或者受限于服务器数量等原因达不到缺陷的触发条件！ 多数是指的一些性能上的疑难杂症或者用户及其隐蔽的行为链路 还有可能是因为我们多数是微服务架构受其他服务异常拖累而造成我们服务本身的不健壮问题，鲁棒性差问题！
- 1.评估漏测逃逸，获取线上缺陷的复线条件，检查配套用例、数据、测试环境缺陷是否已经覆盖，判定是否漏测 2.评估环境差异，检查生产、测试环境的框架是否一致，版本号是否一致，判定环境是否存在差异 3.评估代码变动，检查封包前后的代码变动记录，此功能出现时的代码详情，判定是否存在未告知的改动
- 建立预生产环境进行验证 建立自动化质量保障体系，提高系统反馈速度
- 交叉进行用例 错误推段法 因果图分析
- 这是两种情况，首先测试环境 OK，上线后有问题、优先考虑是测试环境和线上环境之间该功能依赖的某一块配置是否不同。我之前遇到过测试环境换头像墙没问题，线上频繁切换会导致两张图变成一个的问题就是因为线上 redis 和测试的 redis 配置不一样，因此测不出来。 测了 N 次没有问题 之后出现问题那一定是之前 N 次的步骤后出问题的步骤不同，这属于漏测 避免方法 要从进行总结，测试后 review（含参加代码 review）完善用例，上线前必要功能 check 等方向进行回答
- 两个人可以进行交叉测试
- 这应该归于测试用例不完善，未对需求条目测试完全。应对需求条目进行分析，看看依据现在的用例组织是否完善，当前用例的设计方法是否需要增加。
- 测试环境没问题，线上出问题，那就是测试环境就是问题。 测试了十几次没问题，线上出问题，测试组合有问题。 APM/telemetry 确认故障，reproduce，fix/isolate，RCA/postmortem，document/train 大致上这个走一圈能避免后续复发。
- 个人感觉具体看看是什么问题，是不是环境或者测试条件导致的。如果不是那么测试上线流程是否规范，测试数据是否合理，测试通过的包和实际上线的包是否一致。如果也是一致，那么就要复盘下测试用例和执行了🤣是漏写了用例还是漏执行了。如果是涉及盲区漏的那么做好复盘和以后的预防，如果是失误的漏了那就要看情况，看能不能通过机器自动化，如果时间很紧或者几乎一次性项目自动化性价比不是很高，那就只能加强制度要求，采用交叉测试啥的。
- 先找问题根源，再做判断，不一定给出答案