许多应用软件项目的管理者认为，在软件编码阶段，开发者已经对软件进行了大量的白盒、黑盒等多种测试。因此，编码阶段结束，软件就可以交付用户试用了。但无数事实证明，这种直接交付用户试用的软件，或者千疮百孔，或者处于“僵局状态”，进退两难；有的甚至夭折于“襁褓”之中。总之，这些软件的寿命很短暂。究其基本原因，是忽视或跳过了用户测试的阶段（过程）。

　　用户测试阶段是用户结合工作实际，亲手测试软件的功能和流程的过程。通过这一过程，用户逐步了解、确认和认同该软件，同时，也是开发人员逐步验证软件对用户需求的符合程度并完善优化软件的过程。用户和开发人员，以公开签字确认的需求书为基本依据（包括后来追加确认的需求），平等探索和解决应用软件实用化过程中存在的问题。双方紧密配合，但有时争论得脸红脖子粗。正是在这一过程中，软件逐步扎根于用户心中，其生命力也随之茁壮成长。但是用户测试何时结束？何时才能转入系统试运行？其突出标志是什么？

　　设计——“真实”测试

　　我们的做法和经验是，把用户集成测试作为用户测试阶段结束并转入系统试运行的标志和里程碑。我们定义用户集成测试的概念是：当用户测试达到集成测试条件时，建立一个最小的真实系统（未来实际运行的小系统），并用真实角色（真实机构、真实岗位、真实领导）、真实数据，并参考真实业务，设计典型案例，进行实际模拟演习。

　　典型案例的设计原则是：尽可能多地集成主要业务功能；尽可能多地集成主要业务流程及其全过程；尽可能多地集成各个子系统；尽可能多地采用管理工作的实际。

　　由此可见，用户集成测试追求的是实用性和集成后的整体效果。过去由于种种原因，用户单位的领导和业务骨干，对新系统整体效果并不了解，通过用户集成测试，他们亲手处理真实业务和数据，取得满意的实际结果，使他们建立了信心，主动要求尽快开始试运行或实行新旧业务双轨制。

　　准备——目标清晰

　　为了切实做好用户集成测试，我们的具体做法如下：

　　首先，制定必要的用户集成测试的准入条件。不同的应用项目有不同的特点，因而准入条件不同，但基本原则是：根据需求书的要求（包括后来确认增加的需求），用户亲手完成所有的功能和流程测试。我们所指的完成，是指用户和开发者对用户所测的结果有基本一致的认识，并由用户签字确认。由于用户测试都是从一个一个功能和从局部流程到系统流程进行测试的，因此集成测试不但是用户测试的最后阶段，也是用户测试全面集成的最高阶段。

　　其次，制定必要的集成测试达标条件。不同的应用项目，其集成测试的达标条件是不同的，但基本原则是：把所有典型案例的结果，以双轨制方式报送各级主管领导进行审核和签批。如果符合工作的要求，并签批“通过”，则集成测试达标。否则，把发现的问题进行整理分析，继续优化完善程序和进行用户测试，而后再进行集成测试，直至通过。

　　第三， 认真做好集成测试准备工作。具体包括如下几个方面：

　　1、典型案例的设计和用户审核确认。典型案例由开发方设计和提出，但必须经用户方确认后，方有效可用。这样既充分体现应用系统技术先进性，更能体现对业务的促进和发展。用户的确认，实质上是对应用软件的初步认可，意义非同一般，可能会反复多次，必须认真对待。

　　2、甲方进行集成测试的组织安排和时间安排。一般由用户部门主管领导和甲方领导共同全面主持和协调集成测试；由用户各业务部门，负责典型案例的实际操作，并填写意见或建议反馈表；由开发人员到用户第一线全程跟踪和技术支持，并负责填写技术跟踪表。

　　3、甲方负责，并和乙方及用户方一起，进行用户真实人员的角色设置，具体分工，并约定相互间的联络办法。

　　4、最小真实运行环境的搭建、调试和初始化；开发人员对典型案例进行实际测试，并确认正常。

　　5、准备真实的数据、报表和文档。

　　6、参测人员的培训。