App 外包怎么验收：一份可以直接用的验收清单

本文由北京橙智合科技有限公司撰写，立场公开。文中客户一律用描述性别名，不出现客户名称。

外包 App 的验收，最常见的失败模式是：对方打开手机演示一遍，流程顺畅，甲方看着没问题，就签字结项。等真正上线、真正有用户、真正要换人维护的时候，问题才一个一个冒出来。

验收不是「看一眼好不好用」，而是「逐项确认交到我手上的东西能不能长期用下去」。下面这份清单是我们自己交付时对照的，也建议甲方直接拿去当验收表用。

一、先验交付物，不验演示

• 可编译的完整工程：iOS 是 .xcodeproj / .xcworkspace，Android 是完整 Gradle 工程。拿不到工程、只拿到一个安装包，后面想改都没法改。
• 依赖清单：iOS 的 Podfile、Android 的 build.gradle 依赖树，第三方库要一目了然。
• 构建与部署说明：怎么打包、怎么签名、环境参数在哪配。
• 文档：需求定版文档、接口文档、数据库设计。

一条硬标准：把工程在干净的机器上重新编译一次。编不过的「交付物」，等于没有交付。

二、功能验收：按需求清单逐项对，不看口才

验收要有基准，基准就是双方签字的需求清单，以及过程中的变更记录。逐项过，每一项标「通过 / 不通过 / 待定」，不靠印象。

特别提醒：变更过的功能，要按变更后的口径验收，而不是按最早那一版需求文档。变更记录没留档的项目，这一步必然扯皮。

三、异常路径：正常流程谁都能跑通

演示永远走的是最顺的那条路。真正决定可用性的是异常路径：

• 网络断了、弱网、请求超时；
• 后端返回错误、重复提交、连续点击；
• 空数据、超长文本、特殊字符、边界数值；
• 权限被拒绝、被系统回收、中途切后台。

这一块不要求「零缺陷」，要求的是：已知问题有没有被记录、有没有处置结论。

四、机型与系统版本：列清单，真机逐台过

适配不能只看一款手机。把要支持的设备清单和系统版本列出来，逐台真机走完整流程。

有的品类还要多一层。我们做过带深度相机的扫描类 App，就遇到过一个具体故障：同一套扫描逻辑，在摄像头位于短边的机型上正常，到了摄像头在长边的新设备上方向就拧了。这类问题模拟器发现不了，只能真机逐机型过——所以我们把它当成独立的验收项，而不是「适配一下」带过去。

五、性能与稳定性：定场景，不定口号

「流畅」不是验收标准。把它拆成可以观察的场景：

• 冷启动到可操作、页面切换、长列表滚动；
• 连续使用一段时间之后的内存表现；
• 崩溃与卡死：有没有崩溃采集，出问题能不能定位到具体版本。

具体的门槛值应该由双方在需求阶段约定，写进验收标准里——事后补指标，等于没有指标。

六、数据与接口：口径对不上，功能再全也没用

接口文档、字段定义、状态流转，要能对得上。我们做过一个连锁品牌的订货与结算系统，最花时间的不是页面，而是三方对账的口径：同一张订单，平台、品牌方、供应商看到的「正确」各不相同。系统能自动对齐的前提，是这些口径在需求阶段就定死。

验收时可以直接问一句：这套系统的关键数字，按哪个口径算，谁定义的？ 答不上来，说明口径还没定。

七、权限与隐私合规：不是杂活

• 每项权限都要有用途说明，申请的时机要对；
• 隐私政策要覆盖实际采集的数据类型与用途；
• iOS 的隐私清单（PrivacyInfo.xcprivacy）要把用到的 Required Reason API 逐条声明；
• 国内发布的 App 要完成工信部备案，备案号要在 App 内展示，通常在「设置 → 关于」。

这几项的特点是：开发时不做，上线前一定会卡你，返工成本还不低。

八、上架：真传过才知道的事

有一类问题本地打包永远测不出来，只有真正提交上传才会暴露。比如部署目标版本不被 Apple 服务端接受，本地 Archive、导出、校验全部正常，提交那一刻直接拒收。

所以验收时要看上传回执：每一次提交都要有记录，出问题能定位卡在哪一步。同时把账号主体、发布证书、App Store 与 Ad Hoc 两套描述文件的状态一并核清。

九、知识产权与交接：把「源代码」三个字说清楚

• 「源代码」指可编译的完整工程，含构建配置与依赖版本说明，不是一堆文件；
• 第三方组件要说清哪些是开源、哪些是商业授权、许可证类型是什么；
• 交接动作写进合同：验收后多长周期内答疑、配合到什么程度；
• 通用底座与定制部分的归属分别是什么。

合同里「全部成果归甲方」这一句话，看着对甲方有利，实际常常两头都吃亏：甲方拿到的东西支撑不了二次开发，乙方也没有产品化空间。权属写得越清楚的项目，后期合作往往越顺。

一份可以直接用的清单

把上面拆的收成一张核对表，验收时逐项打勾：

1. 完整可编译工程 + 依赖清单 + 构建部署说明；
2. 干净机器上重新编译通过；
3. 需求清单逐项确认，含变更记录；
4. 异常路径已过一遍，已知问题有记录与结论；
5. 目标机型与系统版本清单真机逐台通过；
6. 性能与稳定性按约定场景确认，有崩溃采集；
7. 接口文档与关键口径确认；
8. 权限用途说明、隐私政策、隐私清单齐备；
9. 备案号与展示位置确认；
10. 上传回执、账号与证书状态核清；
11. 源码、文档、部署说明按清单交接签认；
12. 第三方组件许可说明、权属条款确认。

写在最后

验收清单的价值不在条款多，而在于它把「感觉没问题」换成了「逐项确认过」。清单越具体，双方扯皮的空间越小——这对甲方和乙方都不是坏事。

如果你正处在验收阶段，可以把这份清单直接拿去用；如果项目还没开始，那更应该在需求阶段就把验收标准一起定下来。

---

了解更多：原生 App 开发　·　App 上架与发布服务　·　技术咨询

需要一份写清范围的清单？把你的业务说一遍，几秒生成需求清单。