大家好，我是测试奇谭的作者风风。
不久前，我司出现过一起生产事故（已达事故级别，说明了bug的严重性）。
表象是，开发为了让测试复现一个bug，让测试打开了线上环境某商家（测试验收专业）的一个开关，然而工作完成之后，他们忘记关闭它，造成线上用户发现了我司的“骚”操作，薅了公司的羊毛。
实际是，该开关和羊毛被薅没有直接关系，而是这个“骚”操作无意间触发了一个隐藏许久的bug，该bug导致我司被薅羊毛。
因bug流程触发较为复杂，我简言之：两个redis库的业务配置同为真，业务正常，但因某些原因，其中一个配置未同步到位，导致业务异常，出现bug。
关于此事，测试团队展开了关于如何打开正确的线上测试验收，进行了一番群策讨论和重点总结，个人觉得十分有意义，故分享之。
总结
01 测试应当充分理解系统和业务
针对测试环境和线上环境配置不一致的情况，必须跟进处理（在我司，测试环境由测试维护）。拿上面的redis库来说，该业务系统在测试环境只部署了一个redis库，凭功能测试不可能测出来这个bug。
故，
短期措施——保持测试环境和线上环境部署一致，避免遗漏其他问题；
长期措施——测试需熟悉开发设计。因为针对类似问题，如果测试足够了解系统和业务的设计方案，在测试环境能够想到办法验证。
关于这点，风风有话要讲，之前我做专项测试时，全面了解过开发的设计方案和整条业务链路，才发现之前写的测试用例缺失了不少场景。
所以，了解系统设计，特别重要。
02 做上线checklist，保障做过的操作有记录
避免打开某个线上开关之后，又忘记关闭的场景。
03 项目或需求有依赖
针对此次事故的一个点——测试在线上操作时，只知道有这个开关，但不知道该开关打开的影响（涉及另一个测试团队的业务）。
故要求测试A在线上使用B系统（测试B负责的业务），需提前联系测试B，让B操作或者咨询B业务相关，并记录到checklist。即，确保对业务特别熟悉之后，才能进行线上操作。
04 日志优化
针对此事故的另一个点——在线上定位bug原因时，因为某系统返回的json数据过大，该系统和关联的几个系统都未记录响应日志，导致花费很长时间才定位到原因。
故，要求开发保障，即便响应的json特别大，也要提取出关键信息记录到日志上，方便快速定位问题。
05 线上测试数据
梳理线上环境用来测试的数据，比如商品数据，将主图和名称等前端展示信息打上测试、请勿下单等明显的提示标记。
06 线上操作权限
严格按业务团队、部门职级控制，收敛测试和开发（非领导职级、非业务专精同学）的线上操作权限。
07 不要放过任何一个bug
经回溯，触发该问题的某个操作，在测试环境短暂出现过，只是当时不以为然，后来环境稳定后，自然没有追踪，认为是环境不稳定导致的。
08 线上测试数据落影子库
线上测试数据单独落库——测试验收操作只会从该库读写数据，不会读写线上环境的主库；反之，线上业务亦不会读写影子库的数据。
这属于技术规避，需要架构师、运维、开发、测试通力协作才能完成，故作为一种解决方案，以低优先级提上日程。
一如既往，做个总结
别的不说，就一句话：提出解决方案后，关键在于闭环落实，这才是重中之重！！！
发布于刚刚
1895
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
