接受定制业务系统之前，如何检查和测试它

开发人员告诉您系统已经完成，最后一期款项的发票也已放在您的桌上。这正是大多数定制业务系统的拥有者最没有准备的时刻：您被要求验收一样从来没人教过您如何检查的东西。验收测试就是检查的方法。它不是技术活，而是您和您的团队按照业务真实运作的方式去使用这个系统，然后才宣布工作完成、最后一笔款项到期。本指南将一步一步教不懂技术的业主如何进行。

验收测试是什么，不是什么

验收测试是业务方确认完成的系统是否做到了双方约定的事情的阶段，依据的是真实的工作，而不是一场演示。您常会看到它被称为用户验收测试，即 UAT。“用户”二字很重要：评判系统的人应该是将要使用它的人，而不是建造它的人。

弄清楚它涵盖什么、不涵盖什么，很有帮助：

• 它不是开发人员自己的测试。开发人员检查软件能否无错误地运行，每个功能是否按他的设计工作。验收测试检查的是另一件事：做出来的东西是否符合您业务的需要。
• 它不是添加新想法的机会。从未列入约定范围的愿望属于变更，需要另行报价和排期。把它们混进测试，是让一次干净的验收变成争执的最快办法。
• 它不是代码审查。您不需要读一行代码。您评判的是结果：输入了什么、输出了什么，以及是否正确。
• 它不是可有可无的。如果跳过，您等于凭信任接受了系统，第一次真正的测试将发生在真实的客户和真实的记录上。

这个阶段在整体进度中的位置，以及不同规模的项目通常要多久，请参阅定制业务系统要花多长时间。本指南讲的是在这个阶段里该做什么。

为什么必须由业主来做，而不是开发人员

建造系统的人，恰恰是最不适合测试它的人。开发人员清楚每个界面应该怎么用，所以会不自觉地沿着自己搭建的路径操作。他们不知道您每周五的盘点总会有三个例外，不知道某位客户有两个公司名称，也不知道您的柜台员工是一手录入订单、一手招呼另一位顾客的。

还有一个实际的原因。验收是项目从“建设中”变为“已完成”的节点。在此之前，开发人员是在修正问题；在此之后，问题往往被当作支持请求或新的工作来处理，具体取决于您的协议。所以这是您影响力最大的时刻，也是认真检查成本最低的时刻。

这就是付款安排重要的原因。合理的报价会把最后一笔款项与您依据约定内容测试系统的机会挂钩，而不是只看日历上的日期。如果您还在比较供应商，我们关于比较两份定制软件报价的指南会教您在签约前如何检查这一点。

第一步：测试开始之前，先约定“完成”的含义

您无法凭感觉让一个系统通过或不通过。验收标准是简短、书面、可检查的陈述，说明完成的系统必须做到什么。理想情况下，它们直接来自报价中的范围。如果范围写得比较笼统，现在就把它整理成清单，并在测试开始前与开发人员书面确认，让双方对照同一张纸工作。

好标准的检验方法很简单：两个不同的人去检查，能得出同样的答案吗？下表展示了含糊的说法如何变成可测试的标准。

清单只保留真正约定过的内容。测试中想到的、不在清单上的任何东西，都放进另一栏“新需求”，下文会谈到。十到三十条清晰的标准，通常比一百条模糊的更有用。

准备真实的任务和贴近现实的数据

一个在整齐的示例数据上运行良好的系统，仍可能在您的业务里出问题。请根据真实的一周来设计测试，而不是理想的一周。

• 根据平常的一周编写场景。列出您的业务实际用这个系统做的八到十二件事。对每件事，写明谁来做、从什么开始、做什么，以及结束时应该发生什么。
• 包括特殊情况。退款、取消、分批交货、周中变价、重复录入的客户记录、开始后又放弃的订单。系统通常栽在例外上，而例外在真实工作中占了很大比例。
• 使用真实或贴近现实的数据。几十条形态各异、看起来真实的记录，比少数几条完美的记录更能发现问题。如果使用真实客户记录的副本，请限制谁能看到测试副本，并询问开发人员它如何与正式数据隔离、谁有权访问。
• 把迁移的数据与来源核对。如果您原有的记录已导入新系统，请抽取样本，把每个字段与原来的电子表格或旧工具逐项对比。把数据迁入新系统讲解了要准备什么，以及通常哪里会出错。
• 要求一个独立的测试副本。测试应在与正式记录分开的副本上进行，这样练习订单和失误就不会传到真实客户那里。请询问开发人员将如何设置。

选择由谁来测试

只有由合适的人来做，验收才有意义。业主或经理应该参与，但系统也应该让每天要使用它的人来试用。

• 每个角色至少一人。如果系统有收银员、主管、仓库团队和业主视图，每个角色都应测试自己的界面。不同角色看到的内容不同，每个账号都需要单独检查。
• 至少一位持怀疑态度的人。喜欢旧电子表格的员工很有用。如果系统能让他满意，大概也能让其他人满意。
• 有保障的时间。在顾客间隙匆匆测试，只会得到仓促而客气的结果。请预留一段时间，哪怕只是分散在几天里的几个小时。
• 允许“挑剔”。告诉测试者，发现问题就是他们的任务。为了避免尴尬而说“好像没问题”的测试者，还不如没有。
• 由一个人汇总结果。多人用不同方式发消息反馈，会让开发人员很难处理。由一个人负责清单，才能保持一致。

如果系统由多个门店或分店共用，至少要把其中一家门店的真实日常流程从头到尾测一遍。多站点的设置还有它自己的检查项，例如每家分店是否只能看到自己的数据。多门店管理指南介绍了需要留意的地方。

进行测试：一套简单的流程

您不需要特殊工具。一份共享的电子表格、一份记事文档和一部用来截图的手机就够了。按固定的流程逐个走完场景：

• 第1步：确认测试的对象。问开发人员您测试的是哪个版本，并请他在一轮测试中途有变动时通知您。如果系统在测试者脚下不断变化，结果就没有多大意义。
• 第2步：按顺序走完每个场景。对照标准记录通过或不通过。每次失败都要写下确切的步骤、发生了什么和您预期什么，并截图。
• 第3步：试着制造错误。必填项留空、在数字栏输入字母、按返回键、刷新页面、重复录入同一内容。好的系统会告诉用户哪里出了错。
• 第4步：检查每一项输出。报表、导出文件、打印单据、电子邮件和通知，才是业务真正依赖的东西。把其中的数字与您确知的事实对比。
• 第5步：两人同时测试。如果多名员工一起使用系统，让其中两人同时处理同一个项目或同一批库存，看看会怎样。
• 第6步：结算一天或一个月。对测试数据执行期末流程，检查总数是否与您录入的一致。
• 第7步：一次性发送所有问题。把一份整理好的清单交给开发人员，而不是零零散散地发一条条消息。

建立问题清单，并如实分类

问题清单（punch list）是把发现的每个问题编号后集中记录的清单。每一项写明编号、来自哪个场景、重现步骤、发生了什么、您预期什么、截图，以及状态，例如待处理、已修复或待复测。这样的清单把“它不好使”变成开发人员可以着手处理的事项，事后也能证明什么时候提出过什么问题。

并非每一项都是同一类问题，把它们一视同仁正是项目停滞的原因。记录时就为每一项分类：

最后一行最容易引起摩擦。不符合约定清单的，是缺陷；您想要但从未约定的，是变更。两者都应列入清单，但标注不同，这样即使有分歧，也是在书面上、在早期发生。事先了解您的报价如何对待这两类，也很有帮助，这正是要仔细阅读上线后条款的原因。

复测，然后书面确认验收

修复一处，可能悄悄弄坏另一处。开发人员处理完清单后，请复测每一个已修复的项目，再重跑核心场景，确保附近的功能没有变化。持续进行，直到妨碍工作的问题全部清除。

然后做出决定，并且要明确。诚实的结果只有三种：

• 通过验收。每一条约定的标准都通过。
• 带列明例外通过验收。仍有小问题，每一项都写明负责人和约定的处理方式，例如在某个日期前修复，或列入变更清单。
• 不通过验收。仍有一项或多项妨碍工作的问题。问题清单成为下一轮的议程。

书面的验收确认书（sign-off）应写明测试的版本、日期、测试人员、通过了哪些标准，以及哪些项目仍未解决、各自如何处理。它应由业务方中有权验收的人给出。走廊里的口头同意，正是争议的开端。

签字之前，还要检查随系统交付的内容。交接应包括登录凭据、文档，以及系统运行所在的账户，如有约定，应登记在贵公司名下。谁拥有您的定制业务系统的源代码说明了需要确认什么。最后一笔款项请按已约定的付款条款支付，并且只有在您确信确认书与您测试的内容相符时才支付。

可重复使用的验收清单

把这张表复制到电子表格里，为每个方面加一列结果。任何未确认的项目都成为问题清单上的一行。

常见错误

• 让开发人员来主持测试。演示展示的是系统按设计运作的样子，并不能显示它在您手里的表现。
• 只测顺利的路径。如果每个场景都一帆风顺，说明几乎没测什么。
• 使用整齐的示例数据。完美的记录会掩盖杂乱的真实记录才会暴露的问题。
• 把真正的用户排除在外。如果只有业主测试，必须与系统共处的人会在上线后才发现缺陷。
• 把愿望和缺陷混在一起。把新点子当作错误来报告，会搅乱清单，并损害双方的信任。
• 靠消息和记忆来达成一致。没有书面的标准清单和书面的验收确认，日后没有人能证明接受过什么。
• 在时间压力下签字。上线日期不是接受妨碍工作的缺陷的理由。要么记录例外，要么推迟验收。
• 测试之前就付款。检查付款条款是否让您有真正的机会先行测试。

Gotka Technologies 在其中的角色

Gotka Technologies的应用与系统开发服务可建设Web应用、业务系统和手机应用，参考起价为：Web应用与仪表盘RM8,000，业务系统与集成RM12,000，手机应用RM15,000，范围明确后均以书面报价为准。任何项目的验收测试如何进行，包括涵盖几轮修复、付款与验收确认如何挂钩，都应写进书面报价，所以请向您接洽的每一家供应商（包括我们）要求书面说明。想先了解价格方面，请参阅我们的手机应用成本指南；如果您仍在权衡购买还是自建，请阅读现成软件与定制软件。完成的系统也需要一个可靠的运行环境，这正是Gotka云主机的用武之地。

本指南中使用的关键术语

• 验收测试：业务方在接受之前，对照约定内容测试完成的系统的阶段。
• UAT（用户验收测试）：由将要使用系统的人进行的验收测试。
• 验收标准：书面、可检查的陈述，说明完成的系统必须做到什么。
• 测试场景：一项贴近现实的任务，逐步写明，并附上您预期的结果。
• 测试数据：测试期间使用的记录，最好是真实的，或形态上贴近现实。
• 问题清单（punch list）：测试中发现的每个问题的编号记录及其状态。
• 缺陷：没有做到约定内容的地方。
• 变更请求：要求添加或修改约定范围之外内容的请求。
• 复测：再次检查已修复的项目现在是否正常，且附近的功能没有被弄坏。
• 验收确认书（sign-off）：业务方接受系统的书面确认，包括列明的例外。