从事软件测试工作已经有两年多的时间了，在这期间内，我曾和大家一起参与过PS、GS多个版本的产品发版测试，也曾单独或与客户一起参与了多个项目的测试。通过这些经历，我个人对ERP软件测试有了一个更高的认识，只有真正以客户为关注焦点，ERP软件测试才能有质的提高。我想从今年我所经历的两个项目，分别是上海交行年金项目和新汶考核管理，来详细的说明一下，在这两个项目的测试过程中，是如何尽量做到以客户为关注焦点的。

　　上海交行年金项目

　　这次年金项目测试，是由交行的工作人员带领进行的一次上线前的测试。整个测试过程在交行内部进行，历经两个月，截止年金系统上线试运行后一个月结束。

　　测试流程

　　第一轮：功能测试。

　　第二轮：第一轮UAT分组测试。

　　第三轮：第二轮UAT分组测试。

　　第四轮：真实业务测试。

　　渠道测试，性能测试。

　　功能测试

　　本次功能测试就是在集成环境针对各功能点的测试，主要目的是为了确保各功能点无严重影响流程的问题，暂没有更深一步的测试。

　　虽然交行年金系统功能点巨多，但由于测试人员也比较多，每个人分别负责不同的功能模块，大约一周时间就几乎将所有功能点覆盖了一遍。这个过程没有测试用例，所有测试人员均是手动自行输入数据，亦没有进行数据记录，每天下午5点和晚上9点进行两次程序更新。

　　虽然功能测试进行的并不深入，时间也比较短，但是效果非常明显，为后面的UAT测试和真实业务测试做出了很好的铺垫。

　　UAT测试

　　UAT（User Acceptance Test），用户接受度测试。其实本阶段测试我感觉就是系统上线前的真实业务测试。

　　由于本次UAT测试之前，进行了一次功能测试，所以测试人员的系统结构和业务流程都有了一定的了解，更为重要的是交行工作人员提供了三份非常完备的测试案例，这些案例都是根据交行的客户的真实数据组织而来，客户资料，业务流程、客户职责、输入数据、输出数据，甚至连登记日期时间都非常详细，完全避免了由于测试人员对新系统陌生而感觉测试无从下手的尴尬局面。

　　测试执行过程中，将所有测试人员按照三份交行客户的测试案例分成了三个测试小组，每个组内又按照不同的职责进行了分工，而不是再按照功能模块进行分工了，所以每个测试人员几乎都要按照业务流程测到所有的模块。譬如海尔测试用例就分别设置了海尔集团，海尔总部公司，海尔分公司，虚拟公司四个职责，在一起初始完基础数据和客户资料后，各测试人员就会按照职责的分工，并分别按照着测试案例里的流程和数据进行测试。由于各职责之间不管是业务还是数据都存在着一定的关系，譬如，上级公司可引用下级公司的数据，上级公司下达的指标下级公司是否准确收到并报告完成情况，所以在测试时大家既独立又关联，需要所有测试人员功能尽力协作才能顺利的完成本阶段测试。

　　UAT测试分了两轮，第二轮测试新建了帐套，各测试人员对职责进行了互换，流程和数据没有变化。

　　在UAT测试的同时，也进行着一项非常重要的测试，也是本次测试所需攻占的最难点，就是日终测试。日终，应该是银行系统所特有的一项功能，这个测试主要有两个目的：一是确保各功能模块的日终过程均无问题；二是确保日终后的数据正确。这个测试在独立于UAT测试的另一套帐套里进行，每天分别进行一个功能模块的日终测试，测试人员还是按照功能测试的分工进行。测试数据手动输入，并且要对输入的数据进行记录，顺利完成日终后，按照公式手动计算来验证日终后的数据是否正确。

　　真实业务测试

　　本阶段测试是在年金系统3月5日上线后的试运行阶段进行的，在正式服务器上建立了一套与正式帐套并行的测试帐套，测试分工和测试数据仍沿用UAT测试阶段的方案，不同的是本次测试严格按照银行的工作安排进行，譬如，系统每天都是早上9点开门，晚上9点日终，每天发生的业务和需要录入的数据都要严格按照案例在当天进行。不管是流程还是数据，这个阶段的测试都是最接近客户实际业务的测试。