软件测试要以客户为关注焦点

lenny82 · 发表于 2007-12-11 23:27:18

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

上海交行年金项目

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

测试流程
第一轮：功能测试。

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

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

第四轮：真实业务测试。

渠道测试，性能测试。

功能测试

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

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

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

UAT测试

UAT(user acceptance Test)，用户接受度测试。其实本阶段测试我感觉就是系统上线前的真实业务测试。

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

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

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

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

真实业务测试

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

渠道测试，性能测试

渠道测试，与前面所说的第二轮UAT测试同步开始，由交行各渠道的年金工作人员进行测试，测试出的问题也在第一时间反馈项目组。

性能测试，交行请了Mercury的工作人员使用loadrunner进行了性能测试，同时也让他们对一些相对简单的功能给录制了QTP脚本，用来对这些功能进行更新后的验证。

测试结论由于需求的不断变更，交行年金的测试仍在不断的进行终。但在上线前后的两个月的测试过程中，我感觉受益匪浅，留给我印象最为深刻的是他们对测试流程的设计以及测试案例的组织，上线后的测试，由于测试人员对系统已经非常熟悉并且按照银行的工作流程进行测试，以致使我感觉自己就是交行的一名工作人员。

新汶考核管理系统
单元测试
新汶考核测试，从7月份，就由新汶工作人员开始了单元测试（前期我也参与了大约10天左右的时间），由于他们对业务比较了解，而且也参与了前期的开发工作，所以在单元测试过程中，对需求的掌控还是不错的，也为以后的集成测试减轻了一些对照需求来对功能进行验证的工作量。
集成测试前期准备
在集成测试开始的前一周内，我通过了解需求设计以及数据结构，大体掌握了新汶考核系统的整体结构以及流程。并且拿到了客户的实际数据，我感觉只当我真正看到和了解了客户实际数据以后，我才真正“入戏”，我的思维意识才真正的发生了变化，才真正的开始站在客户的角度去尝试了解这个系统。
通过对需求设计和客户数据的了解，我组织了一套测试流程和测试数据。因为考核系统的流程比较简单，大体流程即是按照需求设计和功能菜单来设计的。而测试数据则绝大部分参照了用户数据，对照着各个功能菜单分别组织出来，并且通过这些数据也可将查询功能的结果大体计算出来，各功能之间的业务关联关系（例如参照、引用、回写等）也通过这些数据很明显的体现出来，这些都为为测试过程中数据的正确性验证提供了方便。
再有一点就是，新汶考核系统具有很强煤炭行业性质，在系统中有不少煤炭行业名词（例如巷道、工作面、断面、落煤方式），这些名词在我们测试标准版产品的过程中几乎没有出现过，对我来说是比较陌生的。虽然这些专业名词对测试过程来说并不是很重要，但是如果想真正融入这个系统，真正以客户的角度来看待这些功能，了解这些名词还是很有必要的。我主要通过三个方式来了解这些：
第一，网上查阅。
第二，与开发人员和客户之间的交流。
第三，结合客户实际数据来加深理解。譬如，工作面综合单价维护，通过客户数据可以很明确的看出，工作面的属性有支护方式和落煤方式，而工作面为断面的支护方式和落煤方式通常为综采和机；而综合单价一列，很明显是由各经营项目单价之和得出，固定金额则是根据历史数据得出的一个警戒值，与目前的各经营项目无关。
测试前期的准备，或许时间很短，或许看似并不重要，但是对于一个从来没有涉及过的项目，或者需求变更过的项目，我感觉还是非常重要的。了解系统需求设计和数据结构，对后面的测试作用巨大，测试开始后省去了通常的需要的熟悉阶段，结合需求，很快就能投入正常业务测试。了解客户实际数据和行业知识，可能对测试流程上不会产生的质的影响，但会对我们的测试思维产生巨大的影响，能让我们从思维意识上真正开始了解客户，测试过程中我们将不在是一个单纯的检验功能点的测试工程师，我们同样也是一个客户使用者，会提高我们的投入程度和责任感，我们会更多的从业务方面查找系统的Bug，这样，应该会对最后提交的产品的质量产生质的影响。
测试过程
本次集成测试，在GS3.5标准版的基础上进行的升级，共历经一个月时间，分了五个Build，其中两个Build测试以新建帐套为主，这是为了发现更多基础的Bug；另三个Build测试以恢复帐套数据（GS3.5标准版的测试数据库）为主，这主要是为了模拟客户现场进行升级，因为新汶矿业集团使用了我们的GS系统已经有一段时间，在系统已产生很多数据的情况下，对升级过程的测试中一个是要确保升级程序没有错误，另一个就是要确保对升级前的数据没有产生影响。

数据正确性的验证，可以结合程序、测试用例和数据结构三个方面来进行，主要包括了两个步骤，一是有关联业务之间的数据关系是否正确；二是查询结果的数据是否正确。譬如，产量单查询，如果单据录入时严格按照测试用例的话，那么查询结果的数据验证可以直接参照测试用例；如果和测试用例有差别，那么可以在数据库里查询CLD表，如查询条件为已记帐单据，那么验证时便可在查询语句里加入条件CLD_DJZT=’1’（单据状态＝已记帐），这个过程要对照数据结构。
测试结论
由于新汶考核系统要在短时间给客户完成演示，所以本次测试时间紧，任务急，但由于前期开发组内部和客户一起作过单元测试，并在集成测试前做了充分的准备，所以集成测试进行的较为顺利，在9月底给客户演示的过程中取得了很好的效果。
总结
经过了这些测试项目，我逐步体会到，软件测试如要真正以客户为关注焦点，可以从以下几个方面入手：

1.    制定完善的测试周期。这是一个循序渐进的过程，而且必须有充足的时间和人员来做保证。
2.    测试环境尽量模拟客户现场环境。不能单一的依照我们内部的测试环境，应该多了解一些客户现场的环境情况。
3.    组织完备的测试用例。对于一个成熟的测试项目来说，提前准备一套完备的测试用例非常重要，可以完全避免执行测试过程的混乱局面。
4.    深入了解客户实际业务和实际数据。这也是测试前的准备工作，是一个转换测试思维的过程，是一个融入客户的过程。

[ 本帖最后由 lenny82 于 2007-12-15 11:37 编辑 ]