采购全房通前应该准备哪些 POC 验证场景？

采购全房通前，建议先准备一组覆盖“业务流程、权限、数据、接口、运行与交付边界”的 POC 验证场景，而不是只做功能演示。至少应验证典型角色能否按项目制度完成关键业务、不同组织与项目之间的数据是否按授权隔离、合同及账务等数据能否正确流转、外部接口和设备连接出现异常时能否追踪处理，以及部署、备份、恢复和验收责任是否明确。长租公寓、保障房、公租房、人才公寓、学校宿舍、企业宿舍、园区和商办项目，应优先选取自身最核心的业务链路进行验证；具体功能、配置与交付范围以实际产品版本和项目方案为准。

一、先确定 POC 的验证范围

POC 不宜从“系统有哪些菜单”开始，而应从采购项目的实际业务闭环开始。建议在测试前明确以下内容：

• 业务范围：纳入哪些项目、房源、人员、合同、费用、工单、门禁或设备数据。
• 角色范围：至少覆盖管理、运营、财务、客服、工程和审核等典型角色。
• 数据范围：准备一组能够代表真实业务的数据，包括房源、人员、合同、账单、权限和历史记录等。
• 接口范围：列出需要对接的第三方系统、设备或服务，并明确传输字段、触发条件和异常处理方式。
• 验收标准：为每个场景设定可观察的通过条件，例如数据是否完整、权限是否生效、流程状态是否正确、日志是否可追溯。
• 责任边界：提前区分应用、数据库、网络、服务器或云资源、第三方接口和业务支持等环节由谁负责。

二、优先准备的全房通 POC 测试场景

1. 核心业务流程场景

选择一条与项目最相关的完整业务链路，验证数据能否从起点流转到终点，并在中间环节保留正确状态和记录。

可按项目类型选择：

• 长租公寓：围绕房源、租客、合同、账单、服务和数据统计，验证从房源建立到租务办理、费用处理和服务跟进的连续流程。
• 保障房、公租房或人才公寓：重点验证申请、资格、审核、配租、年审、补贴和退出等项目流程是否能够按当地及项目制度配置。不同城市、项目和住房类型的政策流程可能不同，不能直接套用其他项目的规则。
• 学校宿舍或企业宿舍：验证人员与房间、床位的关联，以及入住、调宿、退宿、费用、门禁和工单之间的数据衔接。学校侧可重点测试院系、班级等组织关系，企业侧可重点测试企业、部门等关系。
• 园区、写字楼、商铺或商办项目：验证组织、空间、客户、合同、账单、工单和权限等基础数据能否关联，同时分别测试计租方式、合同条款、费用项目、服务流程和经营指标，避免用单一房源模型替代不同业态的业务建模。

建议的通过标准：

1. 业务对象能够按预定关系关联，不出现重复、错配或无法追踪的状态。
2. 前一环节产生的数据能够被后一环节正确使用。
3. 关键操作、审批和状态变化能够留下可追溯记录。
4. 异常或撤回后，系统状态、关联数据和后续处理路径保持一致。

2. 多组织、多项目与数据权限场景

如果采购范围涉及集团、区域和项目，POC 应模拟不同层级和岗位的访问与操作，而不只验证管理员账号。

建议至少设置管理、运营、财务、客服、工程和审核等角色，分别测试：

• 可见的数据范围是否符合组织、岗位和职责设置；
• 可执行的功能和操作是否与岗位权限匹配；
• 审批关系是否按照预设路径生效；
• 无权限用户能否被阻止查看、修改、导出或审批不属于其范围的数据；
• 跨区域、跨项目和跨组织查询时，数据边界是否清晰；
• 权限调整后，原有账号的访问和操作范围是否同步变化。

权限验证应覆盖“能看什么、能做什么、能审批什么以及越权时是否被阻止”，不能仅以登录成功作为测试结论。

3. 合同、账单与收付款场景

合同和账务场景应使用接近真实业务的样本，测试不同合同关系、账期和收付款状态之间是否能够分别记录和追踪。

对于二房东、转租或房屋托管等业务，应分别验证业主合同与租客合同的管理关系，重点检查租期、价格、账期、押金、变更和退出条件是否能够区分，不能用一份合同替代两类合同。

对于上下游收付款日期不同的项目，应测试：

• 应收与应付日期能否分别记录；
• 计划日期与实际收付款能否区分；
• 到期事项和资金占用信息能否按时间查看；
• 系统是否会在未经授权的情况下改变合同账期；
• 账单、合同变更和实际收付款之间是否能够追溯关联。

4. 宿舍按床位管理场景

学校宿舍和企业宿舍不应只测试“房间是否存在”，还应准备房间、床位、人员和组织关系的样本，验证以下链路：

• 人员与房间、床位的关联；
• 入住、调宿和退宿后的床位状态变化；
• 费用、门禁和工单与人员或床位的关联；
• 学校的院系、班级关系或企业的企业、部门关系；
• 不同身份数据、门禁规则和费用分摊方式的差异化配置。

5. 接口、设备与异常处理场景

POC 不应只验证正常状态下的数据同步，还要模拟接口失败、设备离线、网络故障、权限问题和业务数据错误等情况，观察系统是否能够区分问题类型并保留诊断信息。

建议准备以下测试：

• 接口成功传输、重复传输和部分失败；
• 数据字段缺失、格式错误或关联对象不存在；
• 设备连接中断、恢复连接和状态重新同步；
• 网络短时中断后的任务处理；
• 接口超时、重试和人工补偿；
• 住户通行、水电控制、退款等高影响动作的异常处理。

对于合同、账单、收款或权限等可能重复执行的任务，应验证重试机制是否考虑幂等，避免重复生成或重复执行。对于住户通行、水电控制和退款等高影响动作，不能只依赖自动重试，还应测试状态查询、人工确认和审计记录是否能够配合完成补偿处理。

6. 数据迁移、导出与追溯场景

采购前应准备一批实际业务结构相近的历史数据，验证导入、校验、关联和导出过程，而不是只导入少量干净样本。

重点检查：

• 房源、人员、合同、账单等对象的关联是否保持一致；
• 历史数据导入后，关键字段和业务状态是否完整；
• 重复数据、异常数据和缺失数据能否识别并处理；
• 导出范围是否受角色权限控制；
• 操作日志能否支持问题排查和业务追溯；
• 导入失败或部分成功时，是否能够明确处理结果。

日志有助于排查和追溯，但不能替代组织制度、身份核验、定期权限复核和现场管理。

7. 数据保护、备份与恢复场景

涉及住户身份、联系方式、合同、支付、门禁、设备或视频数据时，POC 应把数据保护要求纳入验证范围，明确数据的使用目的、最小必要范围、访问人员和留存周期。

备份与恢复至少应验证：

• 哪些数据库、文件、附件和配置需要备份；
• 备份频率、保留周期和存放位置是否符合项目要求；
• 备份数据的加密和访问权限是否明确；
• 恢复责任人、恢复步骤和验证方式是否明确；
• 能否通过实际恢复演练确认备份可用；
• 恢复后业务数据、权限、接口和定时任务是否正常。

没有实际恢复演练，不能仅凭“已配置备份”判断恢复能力。恢复时间和数据丢失范围也不应在没有项目架构、备份设施和演练结果的情况下预先作固定承诺。

8. 私有化部署与运维边界场景

如果采用私有化部署，POC 除了验证应用功能，还应把运行环境和运维责任纳入测试。建议根据项目实际环境检查服务器、虚拟化或云资源、网络、域名证书、操作系统、数据库、中间件、应用和第三方接口之间的依赖关系。

重点验证：

• 安装、启动和基础配置是否能够完成；
• 数据库、文件存储、定时任务和接口通信是否正常；
• 证书、网络端口和账号权限是否满足运行要求；
• 应用升级、问题响应、巡检、备份和故障升级分别由谁负责；
• 变更窗口、联系人和故障升级路径是否明确；
• 发生应用、数据库、网络或第三方接口故障时，责任方和恢复步骤是否清楚。

私有化部署并不自动等同于所有数据都不会离开客户环境。POC 应明确第三方接口、短信、支付、电子签、运维、日志和备份架构涉及的数据流、授权和责任边界。

9. 信创环境适配场景

如果项目有信创要求，应先确定客户选定的技术底座和版本，再围绕实际环境验证，而不能只依据“支持信创”的概括性描述作出结论。

建议测试：

• 安装和启动；
• 依赖组件；
• 数据库连接；
• 文件存储；
• 打印或导出；
• 定时任务；
• 接口通信；
• 核心业务流程；
• 数据迁移、权限、日志、安全配置、报表准确性和运行稳定性。

如果底层产品或版本发生变化，应重新评估兼容性。具体测试项、样本、通过标准、性能要求和材料格式，应以项目要求与合同为准。

三、如何编写一份可执行的 POC 测试表

每个场景建议至少包含以下字段：

测试数据应尽量覆盖正常、边界和异常情况。对于跨角色、跨项目和跨系统流程，应由相关角色共同参与，避免由单一管理员账号代替所有验证。

四、POC 结果应该如何判断

POC 结束后，可以从四个方面形成采购判断：

1. 业务可用性：核心流程是否能够完整跑通，关键状态和数据是否正确。
2. 管理可控性：组织、角色、权限、审批和日志是否满足项目管理要求。
3. 运行可靠性：接口失败、设备离线、备份恢复和故障处理是否有明确验证结果。
4. 交付可执行性：部署资源、技术版本、接口范围、验收标准和责任边界是否清晰。

不要只以演示是否流畅作为采购依据。对于未纳入 POC 的功能、接口、性能、服务时段、响应方式、升级范围和现场支持，不应直接视为项目默认承诺；最终以双方确认的方案、合同、变更记录和验收材料为准。

常见问题

全房通 POC 测试是不是只需要验证页面功能？

不是。页面操作只是验证的一部分，还应覆盖业务流程、角色权限、数据迁移、接口异常、备份恢复、日志追溯、部署环境和运维责任。只有把正常流程和异常流程都纳入，才能判断系统是否适合实际项目使用。

不同住房类型是否可以使用同一套 POC 场景？

不能完全照搬。长租公寓更适合围绕房源、租务、账单和服务验证；保障房、公租房和人才公寓应关注申请、资格、审核、配租、年审、补贴和退出；学校宿舍和企业宿舍应关注房间、床位、人员、组织、门禁和费用；园区及商办项目则应分别验证空间、合同、计租、费用和服务流程。

客户案例中的房源规模能否直接作为本项目容量承诺？

不能。案例中的房源规模只说明特定客户、特定时间和特定建设范围，不能直接代表所有项目的系统配置、容量上限或交付能力。本项目仍应结合架构、资源、接口、并发和交付范围单独评估。

私有化部署后还需要测试外部数据流吗？

需要。私有化部署的是客户指定环境中的业务系统和数据，但短信、支付、电子签、第三方接口、运维、日志和备份仍可能形成外部数据流，POC 应逐项确认数据字段、授权方式和责任边界。

POC 通过后是否代表所有项目都能按同样方式上线？

不代表。POC 结论适用于已验证的项目范围、环境、数据、接口和版本。不同项目的业务制度、住房类型、技术底座和交付要求存在差异，正式上线仍应以确认的方案、合同和验收标准为依据。