1.当前测试的具体业务内容、业务场景、特殊点及相关系统描述不清；

　　2.相关系统运营环节的交易代码不清晰，运营环节的重点和预期描述不清晰；

　　3.相关步骤的责任部门、岗位、操作人员不明确，特别注意上下节点部门之间的信息对接方式；

　　4.整个运营流程只列出了ERP系统的核心和标准运营，但运营流程节点有很多查询和报表，这里不做体现；

　　他们公司已经实施了半年，得到这样的结果其实风险很大，集成测试也过不去，反映出这个项目质量堪忧。实际上，集成测试是对之前蓝图实现的彻底验证。蓝图是否真的合理，业务能否顺利运行，都可以在集成测试中体现出来。

　　所以，如果把握好集成测试关口，防止整个系统的实施偏离蓝图和业务轨道，ERP就成功了一大半。

　　当然，不要为了测试而测试。有一次在会议室遇到一些做集成测试的乙方团队，开始打开ERP系统，一步一步操作集成测试脚本，操作很流畅。不好意思，这叫操作练习，不是综合测试。

　　一个真正合格的集成测试，需要在测试的同时解释业务流程和场景，让每一个参与测试的关键用户都非常清楚自己在测试什么，非常清楚自己的角色和功能，知道自己从哪里获取信息，知道测试后可能需要对接谁。测试环节的上下游要交代清楚，包括数据流、部门沟通、数据验证等。

　　这里举个例子，仓库人员收到一批货物后，可以查看货物的标签，知道输入了哪个供应商，什么货物，多少数量，哪个采购订单。扫描二维码，PDA可以看到相关买家和订单信息，方便查看。输入入库数量，可以正确入库。之后通过系统查询就可以知道入库数量了。系统发出通知，买家可以第一时间知道订单已经入库。

　　其实，集成测试过程也是一个统一系统理解、统一业务理解、消除认知错误的过程。不要为了测试而测试，不要只停留在系统操作层面。每个部门的关键用户都应该清楚这个环节的上下游是谁，他们提供了什么数据，他们做这个动作是为了什么，目的是什么，如果不做会怎么样，等等。

　　关于朋友的问题，我只能基于有限的信息给出自己的建议：

　　对于一些没有及时做好或者做的不好的功能，比较重或者比较紧急的，分两个阶段进行对接可能是可取的。第一阶段先不放，对接优化第二阶段在系统上线1-2个月后继续。不要为了工期牺牲质量。用户有信心，质量有保证，系统稳定为主。适当推迟1-2个月是可以的。