导读：前段时间收到一个朋友的信息，说他们目前正在实施ERP系统，已经到了集成测试环节了，但整个测试过程下来并不是太理想，很多接口不通，功能也还在开发或修改中。其实早些天之前我就收到他发给我的集成测试脚本，让我参考给些意见。虽然我不了解他们公司的业务，但从这份脚本来看，其实做得不怎么样，完全达不到合格的标准：
1、没有描述清楚当前测试的业务具体内容、业务场景、特殊点以及涉及到的系统；2、相关系统操作环节的事务代码不明确、操作环节的关键点以及期望并没有描述清楚；3、相关步骤责任部门、岗位、操作人不明确，尤其要注意上下节点部门之间的信息对接方式；4、整个操作过程只列出了ERP系统很核心很标准的操作，但平时操作流程节点里，会有不少查询和报表的需要，这里也没体现；他们公司实施了大半年，得到了这样的结果其实是很有风险的，集成测试不过关，侧面反映了这个项目的质量堪忧。集成测试实际上对前面蓝图的实现做的一次彻底的验证，蓝图是否真的合理、业务上能否跑的通就能够在集成测试环节体现出来。所以说，把握好集成测试大关，不让整个系统的落地实现偏离蓝图和业务的轨道，ERP就成功了一大半。当然，不要为了测试而测试。曾经我就遇到过一些乙方团队在做集成测试的会议室上，一开始就打开ERP系统，对着集成测试脚本一步一步操作下来，操作非常顺滑。对不起，这个叫操作练习，不叫集成测试。真正合格的集成测试，是需要边测试边讲解业务流程和场景的，让每个参与测试的关键用户都非常清楚他们在测什么东西，要非常明白自己所处的角色和作用，知道自己从哪里获取信息，结束之后可能需要谁对接等。测试环节的上游和下游都要交代清楚，包括数据流向，部门沟通，数据验证等。这里举个例子，仓库人员在收到一批货之后，查看货物标签，就能知道是哪个供应商、什么货物、多少量、哪个采购订单入的。扫描二维码，PDA能够看到相关的采购员及订单信息，便于核对。输入点收数量，能够正确入库。之后通过系统查询就能知道有多少量已经入到仓库里了。系统发出通知，采购员能够第一时间知道订单已经做了入库。集成测试过程实际上也是一次统一系统认识，统一业务理解，消除认知误差的过程。不要为了测试而测试，不要只停留在系统操作层面。各个部门关键用户要清晰他这个环节的上下游都是谁，提供什么数据，明白自己做这个动作是为了啥，目的是啥，不做会怎么样等等。关于那位朋友的问题，我也只能依据有限的信息给出自己的建议：不妨把一些没来得及做或者没做好的、相对不重要不紧急的功能对接分两期进行，第一期先不上，等系统上线稳定1-2个月之后再继续第二期对接优化。不要为了工期而牺牲质量，用户有信心，质量有把握，系统稳定才是主要的，适当延期1-2个月也是可以的。
