探秘U9测试团队 软件测试的那些事儿

    从最开始徘徊在开发的边缘，软件测试正在不断找到自己的位置。软件测试不再是低技术含量、高重复工作的代名词，不再是可有可无、不被重视的部门，软件产品质量正在越来越依赖于测试部门的保障。

    除了更多技术高手开始担任测试工作，在管理软件行业，对某项业务的熟悉同样可以成为测试人员的利器。注册会计师出身的张茜就是这样一个例子。现在的她是用友U9部门质量总监，用友公司测试专家。2000年加入用友，她一直在从事管理软件测试工作，历任U8 V8.2、V8.5、V8.7系列的产品测试、发布；作为测试专家参与U9 1.0、1.5系列产品发布，负责U9 V1.5SP、V2.0、V2.0SP系列发版。从事测试工作10年的她，自己也没有想到会在好不容易考到注册会计师后却转行测试，并且在此后的这么长一段时间里和测试工作为伍。为此，她的惟一解释是：这是因为做ERP软件的测试需要和业务逻辑有着非常强的关联。而这一认识既来源于她多年测试工作的积累，也经过了时间和实践的考验。

    2010年4月的一天，在晒满阳光的办公室里，张茜将她最为熟悉，为之骄傲的整个U9测试的“那些事”娓娓道来。

    U9的测试体系和架构与整个用友产品的体系架构类似，但是U9的测试团队是独立服务于U9这个产品的测试团队。U9的整体开发过程都强调特性驱动，测试过程也不例外。在前一篇针对需求分析的文章中，我们已经提到并详细介绍特性驱动对需求分析流程的影响（http://cio.it168.com/a2010/0510/884/000000884294.shtml）。

    在产品开发过程中，特性驱动表现为特性开发，由需求设计、架构师、项目经理、开发、测试等人员动态地构成一个虚拟团队，进行特性的开发和测试，以保证该特性如期完成，并达到一定的稳定程度。在此期间，某几个人会专门负责这一特性的测试，比如经过两周时间该特性测试通过并提交主版本后，这几个人就可以释放出来，去做别的特性的测试。因此，特性驱动测试是一个相对动态的过程。

    从测试过程和人员分工上，U9的测试可以分为这样几个阶段：

    单元测试：程序员写完代码，按照U9的规范流程，由程序员自己进行单元测试，保证一定的质量才能提交给测试部门测试。测试人员会有一个接收的过程，进行单元验收。

    特性测试：单元验收后，测试人员会比开发人员更大范围的，从业务的角度，将整个流程特性贯穿起来运行测试。在特性范围内，达到U9的质量标准，才能向上一级提交，即特性提交，进入下一步特性验证的过程。

    特性验证：由主测人员，即产品设计层级的人员，对提交的特性进行特性验证。特性验证通过的代码是相对稳定的，可以合并入主版本。特性验证通过，将一个一个特性合并入主版后，在一个截止点上，把所有的特性都合并进来，进入下一步。

    系统测试：在U9团队被称为联调测试，即把所有的特性放在一起进行一个统一测试。联调测试更多地是从功能角度进行黑盒测试。模拟企业的流程从头到尾过一遍，保证流程、流转、控制等各方面，达到一定的稳定程度，才能进入下一步模拟用户的集成测试。

    集成测试：U9团队所说的集成测试就是收集典型行业的典型用户应用，将这些典型用户的行业案例和实施方案拿来在系统中进行模拟测试，如果整个系统跑下来能够确认符合质量标准就可以进入发版。

单元测试由谁测？

    目前，业内基本共识是：单元测试由开发人员完成。但是，让开发人员心甘情愿地进行单元测试，并完成好它并不是那么容易的事。在张茜看来，目前U9的开发人员基本能够完成单元测试，但还是不能达到一个理想的状态：即开发人员能够按照单元测试要求比较高质量的提交代码。在U9开发团队，开发人员能够进行基本单元测试工作，但还是需要测试部门对其进行验收，一次通过的概率还需要提高。

    一般来说，开发人员不是很容易接受单元测试工作，都会存在一些抗拒心理。如何让开发人员接受并完成单元测试？张茜认为：在这个问题上，开发部门主管的作用非常大。测试部门需要与开发部门主管在一开始就商量好，明确单元代码质量的提高是最终版本稳定的最基础和重要的方面。前面不稳定靠后面弥补只会适得其反。因此，一般U9测试团队会和开发主管达成一致。现在开发部门经理和项目经理也都很理解这一点，经过以前的实践，更加知道单元测试的重要性。因此，总的来说，由上而下对程序员灌输单元测试的重要性，并通过规范制度来保证这样一个流程的贯彻和执行，是非常有必要的。

    为了达到单元测试的目的和保证单元测试的质量，U9团队通过Checklist表，要求程序员完成代码后必须按照表格一条一条完成测试项目。这也解决了一开始开发人员不知道如何测试的问题。一开始，他们必须把最常规的几条都走到，把这些都测试完毕后才可以提交代码。测试用例也是由测试部门提供，开发人员直接去跑程序测试即可。这些用例相对比较简单，包括了录入边界值、基本功能、性能指标等共同项目。

    从单元测试引申到开发和测试的冲突，在张茜看来，开发和测试的冲突非常正常。大家必须互相牵制，才能共同保证产品质量。在U9团队，通过CQ检出Bug，一次修改通过，那么问题就友好地解决了。比较麻烦的是，一个Bug多次没有修改通过怎么办？张茜的经验是：一定要与开发经理沟通，安排其他主程序员对代码进行review，从这一层面来加强解决。毕竟，测试人员的目的是推动产品质量和产品发展，这也是大家共同的目标，这一点更需要向开发人员解释清楚。其实，有时候，程序员也可能对自己的代码也没底，遇到问题不知道如何去处理，这时程序员也需要测试人员站出来说话，推动整个过程向前发展。这时，测试人员对开发人员的帮助，就能形成一个良性的循环。

测试用例从何来？

    前面谈到，单元测试的测试用例由测试部门提供。而集成测试的用例则来源于一线的实施方案，包括由架构师提供的特性和对应的场景。在比需求更高一层的架构师立项时，就要确定这一版需覆盖哪些用户，解决哪些特性，并进行场景描述。测试人员根据场景找到目前正在实施的项目，将不同场景和不同特性组合并找到典型用户，这些用户能够比较全面地覆盖以上场景和特性。由测试骨干和专家，结合特性和企业情况，与实施经理和实施顾问深入沟通，与架构师充分沟通，找到典型用户关注的特性、自身的流程、应用，最终形成一个完整的集成测试方案。这一方案要经过由架构师、需求、开发、部分市场、实施组成的评审团队的审慎评审。这是发版前一个关键的质量控制环节。

    在U9测试团队，测试人员会与实施人员有着非常紧密的沟通。一方面是为了尽快解决早一版本在实施过程中的现有问题。另一方面，是因为U9产品属于起步初期，产品规模较大，实施周期较长，一个小版的发版周期都需要3~6个月。往往是新版本还没有发布，但是已经有几个项目在等着了。因此，前期的实施准备阶段，一方面对发版构成一定压力，但另一方面也是非常好的资源，它的针对性特别强。张茜谈到：测试团队会和这样的项目密切配合，因为他们也非常希望通过测试把关，让新产品切合企业的实际功能和流程需求。

    性能测试和压力测试会在联调的时候进行。U9的性能测试分几个方面：单点效率，每一点在一定数据量的支持下能够达到指标；流畅性指标，比如一个完整的收货业务或者领料任务，从头到尾要花费多少时间；压力测试，主要由Loadrunner工具实现，U9也有与微软的合作，模拟5000~8000人同时登录，服务器、线程、应用端、网络部署各方面的压力分别怎样；200人场景测试（压力测试），一个真实的200人场景，进一步模拟企业中的实际应用场景。200人的场景测试算作压力测试的一部分，结合集成方案，制订场景测试，比如10个人做收货，10个人做领料，10个人做入库，报表，打印，不同人模拟完成不同业务，很实际地模拟企业日常工作场景。

测试工具用什么？

    压力测试中，U9团队主要使用Loadrunner工具来实现，同时，U9也与微软的合作，来模拟5000~8000人的同时登录。但整个U9测试团队使用最多的还是
RFT工具。目前U9开发管理都是采用CC、CQ进行代码管理、权限管理和缺陷跟踪管理等，为了方便与开发平台的集成，U9的测试平台也使用了RTF平台。但是，张茜也表示：集成的效果并不好。IBM可能自己有很好的实践，利用测试工具测试部分代码，自动化测试后产生结果，传到CQ，达到一个集成的效果。而U9团队在这个集成过程中却有很多问题，所以并没有真正集成起来。但是，U9团队也在这个过程中慢慢摸索、通过改造等工作实现测试目标。

    U9测试团队从4年前开始使用RFT，在其基础上进行了大量框架开发和成果积累。比如，RFT测试主要是一个录制回放的过程，但是回放的成功率通常不是很高，产品是靠抓UI上的坐标方位来实现，界面一动录制脚本就废了。U9在这方面做了大量基础工作，通过一个测试框架，我们抓的不再是界面上的坐标尺寸，而是抓的一个自设ID。不论前台还是后台的每一个按钮，控件都有自己的编码，编码具有唯一性，由编码转换成RFT的东西，再进行回放。这样界面上的UI轻微变动是不会影响，在不同的机器上回放，成功率也高了很多。

如何建设一个好团队？

    目前，U9的测试团队共有60多名正式人员和20多位外包人员，开发人员和测试人员的比例基本达到2:1，远远优于目前国内平均水平。而张茜的理想状态是1:1。但是，U9测试团队的开发能力却不容小觑。

    虽然U9测试团队中从事自动化测试的人员只有4~5位，但却都个个具有相当的开发能力，也愿意做些开发工作。比如，上面提到的对RFT测试框架的改进，以及自动抓取ID工具等。U9自动化测试力量都强于其他产品。

    在从事测试工作10年，从会计行业转行而来的张茜看来，做ERP软件的测试和业务逻辑有非常强的关联。因此，她面试时会更加注重面试者的业务能力，业务的背景会比测试的背景重要很多。而测试工作，特别是黑盒测试相对比较简单，更多地是对产品业务流程的把控能力，对数据的敏感程度和控制能力。

    目前，U9测试团队层次分开。主测试人员有4~5个，主要负责测试架构和规划方面的工作。主测试的目的是把自己负责这一块的流程把握，测试重点在哪里，测试方案是否合理。而测试的执行则需要执行力强、更仔细、更勤勉的人，需要一遍一遍地反复测试，并能敏锐地发现问题。边角工作则可以由实习人员完成，比如性能、UI交互，这些比较机械地工作可以在方案设计好后由他们来逐条测试。这样便形成一个完美的金字塔结构的测试团队。

    最后，张茜也透露，U9产品的发版密度较大，虽然今年已经比去年有所减少，但也有1大2小三个版本。每个版本的测试周期和回归压力还是比较大的。马上要发布的将是U9 2.0SP版本。大版则是在今年8月将要发布的的U9 2.1版。10月还将推出U9 2.1 SP1版本。

    后续，我们还将继续关注U9开发团队的开发管理经验。敬请期待！