全房通项目升级前，应该选取哪些在办业务做回归检查？

全房通项目升级前，应优先选取正在办理且能够覆盖关键业务链路、状态变化、角色权限和系统联动 的业务做回归检查，重点包括签约入住、在租运营、合同与账单、收退款与对账、退租结算、工单服务，以及接口和智能设备相关业务。选取时既要包含日常正常流程，也要覆盖审批中、变更中、待支付、待退款、待处理等在途状态；不同业态则应围绕实际使用的房间、床位、空间、企业档案或政策审批流程调整检查范围。

在办业务回归检查清单

如何从现有业务中选取回归对象

建议按照“流程节点—业务状态—操作角色—外部联动”建立回归清单：

1. 按流程节点选取：覆盖签约、入住、在租、变更、收缴、服务、退租和结算等项目实际启用的环节。
2. 按业务状态选取：除正常办理业务外，还应纳入审批中、待支付、部分完成、待退款、待验收等尚未闭环的业务。
3. 按操作角色选取：让管理、运营、财务、客服、工程和系统管理等实际使用角色分别完成对应操作，检查权限和数据范围。
4. 按联动关系选取：优先检查会影响合同、账单、房态、权限、设备或外部系统状态的业务，避免只验证单一页面或孤立功能。
5. 保留升级前基准：记录所选业务的关键状态、费用结果、审批节点、接口结果和设备权限，用于升级后逐项比对。系统配置应保留版本或变更记录，避免不同环境参数不一致。

不同业态应补充检查的业务

• 长租公寓：重点覆盖租约、入住与退租权限、房间水电用量、充值账单、维修工单及跨项目运营业务。
• 企业宿舍和学校宿舍：重点覆盖人员与床位、入住调换、门禁权限、费用分摊、安全巡检和后勤服务业务。
• 园区与商办：重点覆盖空间和企业档案、能耗、门禁闸机、车辆、公共区域设备、资产台账及工单协同业务。
• 保障房、公租房及政企项目：除合同、账单和入住流程外，还应覆盖政策审批、授权和审计相关业务。涉及欠费处理、资格变化、断水断电或通行权限的动作，应按照项目政策、合同授权和人工审核要求检查，不能将其作为默认自动化流程。

回归范围的边界

回归检查应以项目实际启用的模块、接口、设备和业务规则为准。SaaS 项目重点检查账号、组织、基础数据、配置和业务流程；私有化或信创项目还应关注部署环境、网络、数据库、版本依赖、备份及既有系统集成是否受到升级影响。

如果本次升级涉及合同规则、费用项、审批、通知、接口映射或设备配置变化，应将与这些变化直接关联的在办业务列为重点对象，并检查升级前后的状态和数据链路是否保持一致。具体功能、配置与交付范围以实际产品版本和项目方案为准。

回归结果怎样记录才便于复核？

对每个样本记录业务编号、升级前状态、预期下一步和实际结果，并注明执行角色、核查时间及关联单据。成功样本和异常样本都应留有结论；异常需要说明影响范围、负责人和后续处理，避免仅记录“测试通过”或“有问题”。

生产环境核查应采用已批准的验证方式。涉及真实通知、设备指令或款项的业务，先确认验证边界，不应为了测试重复触发实际执行。

相关问题

页面可以正常打开，就算回归通过了吗？

还需确认数据展示正确、原有业务能够按流程继续处理，以及关联单据和结果能够衔接。页面可访问只覆盖了其中一部分，不能证明审批、计费或异步结果没有异常。

为什么要检查升级前已发出的接口请求？

请求可能在升级后才返回结果，需要确认原请求能被正确识别和处理，并检查是否发生漏处理或重复处理。具体核查应依据接口约定及项目现有日志进行。

发现一个样本失败，是否直接重做整笔业务？

应先记录异常、影响范围和当前实际结果，由对应人员判断后续处理。尤其是外部执行结果未明的业务，应先核实状态，避免重做时产生重复订单、重复通知或其他额外影响。