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

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

本文关键字: 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个人做入库,报表,打印,不同人模拟完成不同业务,很实际地模拟企业日常工作场景。
 

共2页: 上一页1 [2]
责编:王立新
vsharing微信扫一扫实时了解行业动态
portalart微信扫一扫分享本文给好友

发表评论

         看不清,换一个

著作权声明:畅享网文章著作权分属畅享网、网友和合作伙伴,部分非原创文章作者信息可能有所缺失,如需补充或修改请与我们联系,工作人员会在1个工作日内配合处理。
畅享
首页
返回
顶部
×
    信息化规划
    IT总包
    供应商选型
    IT监理
    开发维护外包
    评估维权
客服电话
400-698-9918