探秘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个人做入库，报表，打印，不同人模拟完成不同业务，很实际地模拟企业日常工作场景。
 

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友