制定合理的软件测试流程
作者：佚 名
首先向大家介绍一下我理解的测试流程是什么，流程在词典上的解释是“工艺程序,从原料到制成品的各项工序安排的程序”，那测试流程就是指从软件测试开始到软件测试结束经过的一系列准备、执行、分析的过程。所以我认为测试流程并不是只存在于有完整测试团队的公司，它分布在每一个对软件执行测试的公司中，哪怕这个公司只有一个测试人员。
软件测试想要在一个公司中从无到有进而逐步完善，也需要公司上层领导、开发人员等人从接受到理解、支持到尊重的一个过程。要想完成这个目标并不容易，需要公司外部整个软件测试行业和公司内部软件测试工作的双重影响。而整个软件测试行业实际上又是由各个公司内部的软件测试团体组成的，归根结底要让大家都接受软件测试还是要靠每个公司内部软件测试工作的影响。只有合适的测试流程才能快速的显示出测试工作的作用，才能让大家更快的接受测试工作，主动配合测试工作，进而完善测试工作，达到良性循环的作用。
制定合理的测试流程需要考虑的因素很多，毕竟它是大家进行测试工作的依据，又需要理清和需求人员、开发人员、市场人员等多方人员的关系，而且公司不同侧重点又有所不同，所以在这里不可能面面俱到列出所有因素，只是根据自己的经验列出认为比较重要的几点。
制定测试流程首先要清楚自己所在的公司正处在什么发展阶段，是处在最初的创业期还是已经度过了创业期希望通过测试来提高产品质量，以便取得更多的业务创造更大的效益。可能有的同行会觉得奇怪，我们软件测试是做技术的只管做好本职工作，为什么制定流程时要这么重视公司的发展情况呢。其实公司的情况和制定测试流程有非常大的联系，公司的情况直接决定着公司对产品的要求，而测试部门一般来说是产品投入市场的最后一个关口，这也就等于公司的发展情况决定了公司对测试部门的要求。开发软件前要先了解软件的需求，制定测试流程前当然也要了解清楚公司对测试部门的需求。了解了公司的情况和要求后，就要根据这些要求结合制定者的测试知识和经验，制定即符合公司要求又能起到软件测试目的的软件测试流程。当然这样做并不是说让软件测试向公司的一些不利于开展软件测试工作的现实情况妥协，只是根据公司的实际情况制定一些可以马上改变公司测试工作现状的流程。
一般正在创业期的公司面临的是公司生存的问题，它需要和其他公司抢市场，这时公司为了配合市场的要求不光要求软件产品的质量更要求整个项目的进度，但是对一些在软件测试过程需要的文档和产生的文档却不是特别在意。而且这样的公司开发人员往往都是测试人员8倍10倍，经常是软件代码已经快写完了，测试人员才会进入项目。这样我们在制定测试流程时就要注意软件测试工作的重点是执行测试，虽然前期的一些测试准备对以后的执行测试工作有很大的指导性作用，但前期准备工作如测试用例的写作等也会增加软件测试的时间，尤其是软件测试人员在软件已经开发出来才进入项目的时候，如果还要花大量时间去准备软件测试，更会让不了解软件测试的人误认为是软件测试拖延了整个项目的进度，让软件测试的推广工作受到更多的阻碍。这样我们就可以适当删减一些前期的准备工作，如减去用例评审工作，减少一些测试文档的写作工作，对一些测试文档的写作要求适当放宽等，更具体的就是我们可以不要求测试用例将操作步骤描述的很详细，但是要记录测试的思路可以简化为测试方案，达到对测试工作的跟踪目的就可以。但测试用例最好不要省略因为这个文档可以为以后再测试类似功能的产品做好经验的积累。
如果公司已经度过最初的生存期，这时公司会对产品的质量有更高的要求并且体现到对软件开发过程的要求。而且公司从软件开发计划制定、进度跟踪、项目管理等都有了一定的经验也有了一些历史数据可以参考。这样对软件测试的一些前期准备工作也会有所考虑，并适当满足，这时软件测试流程可以加强前期测试准备工作、后期测试分析工作。具体可以要求软件测试从需求介入以便尽早了解产品，制定独立的软件测试计划并将软件测试时间纳入整个项目进度中，细化测试用例写作的力度，增加后期对缺陷分析的工作进而逐步提高整个软件测试团队的技术力量，让软件测试渗透到整个软件过程中。
其实公司内软件测试一片空白或者测试流程比较完善的公司流程制定和执行相对来说都会比较容易一些，如果是一片空白你可以完全按照自己的想法去建立软件测试流程，剩下的困难只是如何去说服领导和开发配合这个流程。如果软件测试流程已经比较完善，大家对软件测试已经有了一定的支持和理解并且现阶段运行良好，你只需要在一些小节上进行一些修改，如果的确有利于工作会得到大多数人的支持。最难制定的是软件测试刚刚起步有了一些不成型的测试流程，也许不太符合你的想法也许不太适合公司的实际情况但的确在公司运行了一段时间，如果想改变不光要说服测试部门以外的人还要说服测试工作人员，增加了工作的难度，如果公司是这种情况请大家在制定软件测试流程前更要慎重考虑，详细了解公司的情况。
制定软件测试流程时可以参照一些比较完善的软件测试流程，但切忌不可照搬这些流程。我们经常会遇到这样的情况，如果在测试工作过程中碰到一些问题有人会说如果在微软或IBM公司是这样处理的，我们也可以这样。但是我们的工作环境和这些公司是不一样的，测试的思想已经深入贯穿到他们开发的每一个步骤中，而我们目前大多数公司的软件开发过程并没有达到这样的程度，我们大多需要解决的是在测试思想还没有贯彻彻底的公司我们怎么处理这个问题。无论是软件测试刚刚起步还是已经有了一定软件测试团队规模有多年软件测试经验的公司，都有一些属于自己公司特定的测试方法和流程，就是完善的软件测试流程也各有各的不同，IBM和微软在测试流程肯定是有所差别的。如果将他们的流程照搬过来，没有给公司同事一个慢慢接受消化的过程，很容易适得其反甚至引起公司同事的抵触情绪。这里并不是说这些测试流程不好，只是这些测试流程也不是一开始就建立起来的，而是通过多年的经验和教训逐步完善一步一步慢慢建立的，并且现在它们仍在进一步完善中。我们不仅要学习这些完善的软件测试流程是什么样的，我们更要学习为什么制定这套软件测试流程。给人金子不如给人点金术，也就是这个道理。那些软件测试流程比较完善的公司走在了我们的前面，我们就要学习他们这一路走来的经验和教训，避免走他们走过的弯路，缩短完善公司流程的时间。
制定软件测试流程要明确测试部门的职责。经常会有测试人员抱怨自己在公司里就是一个打杂的，什么工作都要做，其实这就是职责不明确引起的问题，这样会很大程度打击测试人员的工作积极性影响工作情况进而影响大家对软件测试工作的看法。一些如写用户手册、给用户培训等工作在公司里如果没有专门的部门来做，就很容易推给软件测试人员来做，但是都没有明文规定而且在对软件测试人员进行工作考核时又很容易疏忽这些工作，而且这些工作有时候看起来不太起眼，但是需要耗费大量的时间。所以我们要明确制定软件测试部门的职责、软件测试人员担任的工作内容，其他一些工作如果由测试人员来做，就要在制定软件测试计划中明确写出这些工作需要的时间，以防止这些工作占用测试时间，使测试人员陷于被动之中。
制定软件测试流程不光要制定软件测试部门内部的工作流程，更要制定与开发部门、需求部门等外部部门的接口工作的流程，一旦项目在进度、功能上有了变化要及时和测试部门沟通，不要让测试部门成为最后一个知情人。
另外在具体执行测试流程时要注意执行的效果，将测试工作落实到实处，而不是为了走过场证明测试工作已经达到了某种程度，否则再好再适合的流程也不能起到它的作用。例如大家都一致认为测试应该从需求开始介入，但是从需求开始介入并不是测试人员参与了需求评审会议提出一些问题就达到了目的。而是要求测试人员在开发把产品开发出来前就要了解这个产品都要实现什么功能，虽然不知道开发怎么去实现这些功能，但是要知道实现了哪些功能。因为在产品在开发提交测试之后往往由于产品一些基本功能没有实现，使测试人员很难深入的对产品进行业务流程的测试，所以一些重大的流程问题往往在测试的后期发现，但是这时可能离产品提交用户的时间很近了，开发人员修改这个问题很可能会引发其他的问题增加产品的风险，而且一些开发还会抱怨为什么测试不早发现这些问题，还有可能使公司怀疑测试人员的能力，让测试工作的开展受到一定的阻碍。只有越来越熟悉产品才会发现越来越深入的问题，这是一般的发展规律我们难以改变。但是如果我们前期对产品需要实现的功能有很深的了解，前期就可以提前设计一些业务流程上的问题，一旦产品基本功能可以完成就马上进行业务流程的测试，使这个过程大大缩短。
制定合理的软件测试流程是一门很深的学问，它需要制定者有丰富的软件测试理论知识，软件测试执行经验、管理经验以及沟通能力等等多方面的经验能力，还需要许多测试人员经过长时间的实践来验证完善，仅希望此文对大家有所启发。
--------------------------------------------------------------------------------------------
因上传文件大小受限，如果文件上传不完全或图片无法显示请到：http://www.testage.net 《测试员》电子杂志下
载区下载查看。
欢迎您在线阅读并留下您的宝贵意见。为《测试员》杂志投稿，请发送至：webmaster@testage.net。
登陆测试时代论坛：http://www1.testage.net/bbs/index.asp
登陆慧灵科技：http://www.testage.com.cn
testage发表于 >2006-2-20 17:01:12 [全文] [评论] [引用] [推荐] [档案] [推给好友] [收藏到网摘]
2006-2-20
软件测试过程管理实践
软件测试过程管理实践
作者：杨静波 田悦峰
摘要
随着测试技术的蓬勃发展，测试过程的管理显得犹为重要，过程管理已成为测试成功的重要保证。经过多年努力，测试专家提出了许多测试过程模型，包括V模型、W模型、H模型等等。这些模型定义了测试活动的流程和方法，为测试管理工作提供了指导。但这些模型各有长短，并没有哪种模型能够完全适合于所有的测试项目，在实际测试中应该吸取各模型的长处，归纳出合适的测试理念。“尽早测试”、“全面测试”、“全过程测试”和“独立、迭代的测试”是从各模型中提炼出来的四个理念，这些思想在实际测试项目中得到了应用并收到了良好的效果。在运用这些理念指导测试的同时，测试组应不断关注于基于度量和分析的过程的改进活动，不断提高测试管理水平，更好的提高测试效率、降低测试成本。
关键词
测试过程模型 测试管理理念 可持续改进
0 引言
1963年，在美国发生了这样一件事：编程人员把一个FORTRAN程序的循环语句DO 5 I=1，3误写为DO 5 I=1.3。一点之差导致飞往火星的火箭爆炸，造成1000多万美元的损失。这种情况的发生，迫使人们考虑在软件投入使用之前必须进行彻底的测试。今天，在软件比较发达的国家，软件测试已经成为一个独立的产业，软件公司纷纷建立独立的测试队伍研究测试技术并开展测试工作。中国的软件测试起步较晚，但随着我国软件产业的蓬勃发展以及人们对软件质量的重视，软件测试正在成为一个新兴的产业。近两年来，国内新成立专业性测试机构10余家，一批批专业的软件测试人员正涌现出来。每年国内都有大量的测试技术交流会议举办，有大量的测试研究论文在专业刊物上发表。在测试技术发展的同时，测试过程的管理显得犹为重要。一个成功的测试项目，离不开对测试过程科学的组织和监控，过程管理已成为测试成功的重要保证。
1 测试过程概述
1．1 软件测试过程概述
软件测试过程是一种抽象的模型，用于定义软件测试的流程和方法。众所周知，开发过程的质量决定了软件的质量，同样的，测试过程的质量将直接影响测试结果的准确性和有效性。软件测试过程和软件开发过程一样，都遵循软件工程原理，遵循管理学原理。
随着测试过程管理的发展，软件测试专家通过实践总结出了很多很好的测试过程模型。这些模型将测试活动进行了抽象，并与开发活动有机的进行了结合，是测试过程管理的重要参考依据。
1．2 软件测试过程模型介绍
Ｖ模型
V模型最早是由Paul Rook在２０世纪８０年代后期提出的，旨在改进软件开发的效率和效果。Ｖ模型反映出了测试活动与分析设计活动的关系。在图1-1中，从左到右描述了基本的开发过程和测试行为，非常明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系。
图1-1 软件测试V模型
V模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同的要求。
但V模型存在一定的局限性，它仅仅把测试作为在编码之后的一个阶段，是针对程序进行的寻找错误的活动，而忽视了测试活动对需求分析、系统设计等活动的验证和确认的功能。
Ｗ模型
W模型由Evolutif公司公司提出，相对于V模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动。如图1-2所示，W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。
W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。
但W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。
图1-2 软件测试W模型
Ｈ模型
V模型和W模型均存在一些不妥之处。如前所述，它们都把软件的开发视为需求、设计、编码等一系列串行的活动，而事实上，这些活动在大部分时间内是可以交叉进行的，所以，相应的测试之间也不存在严格的次序关系。同时，各层次的测试（单元测试、集成测试、系统测试等）也存在反复触发、迭代的关系。
为了解决以上问题，有专家提出了H模型。它将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来，如图1-3所示。
图1-3 软件测试H模型
这个示意图仅仅演示了在整个生产周期中某个层次上的一次测试“微循环”。图中标注的其他流程可以是任意的开发流程。例如，设计流程或编码流程。也就是说，只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以（或者说需要）进行了。
H模型揭示了一个原理：软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。H模型指出软件测试要尽早准备，尽早执行。不同的测试活动可以是按照某个次序先后进行的，但也可能是反复的，只要某个测试达到准备就绪点，测试执行活动就可以开展。
其他模型
除上述几种常见模型外，业界还流传着其他几种模型，例如X模型、前置测试模型等。X模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接，通过集成最终合成为可执行的程序。前置测试模型体现了开发与测试的结合，要求对每一个交付内容进行测试。这些模型都针对其他模型的缺点提出了一些修正意见，但本身也可能存在一些不周到的地方。所以在测试过程管理中，正确选取过程模型是一个关键问题。
1．3 软件测试过程模型选取策略
前面介绍的测试过程模型中，V模型强调了在整个项目开发中需要经历的不同的测试级别，但忽视了测试的对象不应该仅仅是程序。而W模型在这一点上进行了补充，明确指出应该对需求、设计进行测试。但是V模型和W模型都没有将一个完整的测试过程抽象出来，成为一个独立的流程，这并不适合当前软件开发中广泛应用的迭代模型。H模型则明确指出测试的独立性，也就是说只要测试条件成熟了，就可以开展测试。
在实际测试工作中我们应该尽可能地去应用各模型中对项目有实用价值的方面，不能强行的为使用模型而使用模型。在测试实践中，我们采用的方法是：以W模型作为框架，及早的、全面的开展测试。同时灵活运用H模型独立测试的思想，在达到恰当的就绪点时就应该开展独立的测试工作，同时将测试工作进行迭代，最终保证完成测试目标。
2 测试过程管理理念
生命周期模型为我们提供了软件测试的流程和方法，为测试过程管理提供了依据。但实际的测试工作是复杂而烦琐的，可能不会有哪种模型完全适用于某项测试工作。所以，我们应该从不同的模型中抽象出符合实际现状的测试过程管理理念，依据这些理念来策划测试过程，以不变应万变。当然测试管理牵涉的范围非常的广泛，包括过程定义、人力资源管理、风险管理等等，本节仅介绍几条从过程模型中提炼出来的，对实际测试有指导意义的管理理念。
2．1 尽早测试
“尽早测试”是从W模型中抽象出来的理念。我们说测试并不是在代码编写完成之后才开展的工作，测试与开发是两个相互依存的并行的过程，测试活动在开发活动的前期已经开展。
“尽早测试”包含两方面的含义：第一，测试人员早期参与软件项目，及时开展测试的准备工作，包括编写测试计划、制定测试方案以及准备测试用例；第二，尽早的开展测试执行工作，一旦代码模块完成就应该及时开展单元测试，一旦代码模块被集成成为相对独立的子系统，便可以开展集成测试，一旦有BUILD提交，便可以开展系统测试工作。
由于及早的开展了测试准备工作，测试人员能够于早期了解测试的难度、预测测试的风险，从而有效提高了测试效率，规避测试风险。由于及早的开展测试执行工作，测试人员尽早的发现软件缺陷，大大降低了BUG修复成本。但是需要注意，“尽早测试”并非盲目的提前测试活动，测试活动开展的前提是达到必须的测试就绪点。
2．2 全面测试
软件是程序、数据和文档的集合，那么对软件进行测试，就不仅仅是对程序的测试，还应包括软件“副产品”的“全面测试”，这是W模型中一个重要的思想。需求文档、设计文档作为软件的阶段性产品，直接影响到软件的质量。阶段产品质量是软件质量的量的积累，不能把握这些阶段产品的质量将导致最终软件质量的不可控。
“全面测试”包含两层含义：第一，对软件的所有产品进行全面的测试，包括需求、设计文档，代码，用户文档等等。第二，软件开发及测试人员（有时包括用户）全面的参与到测试工作中，例如对需求的验证和确认活动，就需要开发、测试及用户的全面参与，毕竟测试活动并不仅仅是保证软件运行正确，同时还要保证软件满足了用户的需求。
“全面测试”有助于全方位把握软件质量，尽最大可能的排除造成软件质量问题的因素，从而保证软件满足质量需求。
2．3 全过程测试
在W模型中充分体现的另一个理念就是“全过程测试”。双V字过程图形象的表明了软件开发与软件测试的紧密结合，这就说明软件开发和测试过程会彼此影响，这就要求测试人员对开发和测试的全过程进行充分的关注。
“全过程测试”包含两层含义：第一，测试人员要充分关注开发过程，对开发过程的各种变化及时做出响应。例如开发进度的调整可能会引起测试进度及测试策略的调整，需求的变更会影响到测试的执行等等。第二，测试人员要对测试的全过程进行全程的跟踪，例如建立完善的度量与分析机制，通过对自身过程的度量，及时了解过程信息，调整测试策略。
“全过程测试”有助于及时应对项目变化，降低测试风险。同时对测试过程的度量与分析也有助于把握测试过程，调整测试策略，便于测试过程的改进。
2．4 独立的、迭代的测试
我们知道，软件开发瀑布模型只是一种理想状况。为适应不同的需要，人们在软件开发过程中摸索出了如螺旋、迭代等诸多模型，这些中需求、设计、编码工作可能重叠并反复进行的，这时的测试工作将也是迭代和反复的。如果不能将测试从开发中抽象出来进行管理，势必使测试管理陷入困境。
软件测试与软件开发是紧密结合的，但并不代表测试是依附于开发的一个过程，测试活动是独立的。这正是H模型所主导的思想。“独立的、迭代的测试”着重强调了测试的就绪点，也就是说，只要测试条件成熟，测试准备活动完成，测试的执行活动就可以开展。
所以，我们在遵循尽早测试、全面测试、全过程测试理念的同时，应当将测试过程从开发过程中适当的抽象出来，作为一个独立的过程进行管理。时刻把握独立的、迭代测试的理念，减小因开发模型的繁杂给测试管理工作带来的不便。对于软件过程中不同阶段的产品和不同的测试类型，只要测试准备工作就绪，就可以及时开展测试工作，把握产品质量。
3 测试过程管理实践
本节以一个实际项目系统测试过程（不对单元测试和集成测试过程进行分析）的几个关键过程管理行为为例，来阐述上节中提出的测试理念。在一个构件化ERP项目中，由于前期需求不明确，开发周期相对较长，为了对项目进行更好的跟踪和管理，项目采用增量和迭代模型进行开发。整个项目开发共分三个阶段完成：第一阶段实现进销存的简单的功能和工作流；第二阶段：实现固定资产管理、财务管理，并完善第一阶段的进销存功能；第三阶段：增加办公自动化的管理（OA）。该项目每一阶段工作是对上一阶段成果的一次迭代完善，同时将新功能进行了一次叠加。
3．1 策划测试过程
依据传统的方法，将系统测试作为软件开发的一个阶段，系统测试执行工作将在三个阶段完成后开展，很明显，这样做不利于BUG的及时暴露。有些缺陷可能会埋藏至后期发现，这时的修复成本将大大提高。我们依据“独立和迭代”的测试理念，在本系统中，对测试过程进行独立的策划，找出测试准备就绪点，在就绪点及时开展测试。
该系统的三个阶段具有相对的独立性，在每一阶段完成所提交的阶段产品具有相对的独立性，可以作为系统测试准备的就绪点。故而，在该系统开发过程中，系统测试组计划开展三阶段的系统测试，每个阶段系统测试具有不同的侧重点，目的在于更好的配合开发工作尽早发现软件BUG，降低软件成本。软件开发与系统测试过程的关系如图3-1所示。
实践证明，这种做法起到了预期的效果，与开发过程紧密结合而又相对独立的测试过程，有效的于早期发现了许多系统缺陷，降低了开发成本，同时也使基于复杂开发模型的测试管理工作更加清晰明了。
图3-1 软件开发与系统测试关系图
3．2 把握需求
在本系统开发过程中，需求的获取和完善贯穿每个阶段。对需求的把握很大程度上决定了软件测试是否能够成功。系统测试不仅仅确认软件是否正确实现功能，同时还要确认软件是否满足用户的需要。依据“尽早测试”和“全面测试”原则，在需求的获取阶段，测试人员参与到了对需求的讨论之中。测试人员与开发人员及用户一起讨论需求的完善性与正确性，同时从可测试性角度为需求文档提出建议。这些建议对开发人员来说，是从一个全新的思维角度提出的约束。同时，测试组结合前期对项目的把握，很容易制定出了完善的测试计划和方案，将各阶段产品的测试方法及进度、人员安排进行了策划，使整个项目的进展有条不紊。
实践证明，测试人员早期参与需求的获取和分析中，有助于加深测试人员对需求的把握和理解，同时也大大促进需求文档的质量。在需求人员把握需求的同时，于早期制定项目计划和方案，及早准备测试活动，大大提高了测试效率。
3．3 变更控制
变更控制体现的是“全过程测试”理念。在软件开发过程中，变更往往是不可避免的，变更也是造成软件风险的重要因素。在本系统测试中，仅第一阶段就发生了7次需求变更，调整了两次进度计划。依据“全过程测试”理念，测试组密切关注开发过程，跟随进度计划的变更调整测试策略，依据需求的变更及时补充和完善测试用例。由于充分的测试准备工作，在测试执行过程中，没有废弃一个测试用例，测试的进度并没有因为变更而受到过多影响。
3．4 度量与分析
对测试过程的度量与分析同样体现的“全过程测试”理念。对测试过程的度量有利于及时把握项目情况，对过程数据进行分析，很容易发现优势劣势，找出需要改进的地方，及时调整测试策略。
在ERP项目中，我们在测试过程中对不同阶段的BUG数量进行了度量，并分析测试执行是否充分。如图3-2所示，通过分析我们得出：相同时间间隔内发现的BUG数量呈收敛状态，测试是充分的。在BUG数量收敛的状态下结束细测是恰当的。
图3-2 软件开发与系统测试关系图
测试中，我们对不同功能点的测试数据覆盖率和发现问题数进行度量，以便分析测试用例的充分度与BUG发现率之间的关系。如表3-1所示，对类似模块进行对比发现：某一功能点上所覆盖的测试数据组越多，BUG的用例发现率越高。如果再结合工作量、用例执行时间等因素进行统计分析，便可以找到适合实际情况的测试用例书写粒度，从而帮助测试人员判断测试成本和收益间的最佳平衡点。
表3-1 测试数据覆盖率与BUG发现率对应表
模块名称 功能点数 测试数据数 测试数据覆盖率 BUG的用例发现率（）
模块AA 6个 75组 12.5组/每功能点 40% （6/15）
模块BB 30个 96组 3.3组/每功能点 17% （7/42）
模块CC 15个 87组 5.1组/每功能点 18% （5/28）
模块DD 16个 46组 2.8组/每功能点 23% （5/22）
… … … … ...
注：通过统计可以得出测试数据与BUG发现率之间的关系，便于及时调整测试用例编写策略。
所有这些度量都是对测试全过程进行跟踪的结果，是及时调整测试策略的依据。对测试过程的度量与分析能有效的提高了测试效率，降低了测试风险。同时，度量与分析也是软件测试过程可持续改进的基本。
4 测试过程可持续改进
测试技术发展到今天，已经存在诸多可供参考的测试过程管理思想和理念。但信息技术发展一日千里，新技术不断涌现，这就注定测试过程也需要不断的改进。我们提倡基于度量与分析的可持续过程改进方法（本文不做详细论述）。在这种方法中，对现状的度量被制度化，并作为过程改进的基础。组织可以自定义需要度量的过程数据，将收集来的数据加以分析，以找出需要改进的因素。在不断的改进中，同步的调整需要度量的过程数据，使度量与分析始终为了过程改进服务，而过程改进也包含对度量和分析的改进。
掌握了基于度量和分析的可持续过程改进方法，测试过程管理将能够不断完善，测试活动将能够始终处于优化状态。
参考文献：
[1] 郑人杰，殷人昆．实用软件工程．第二版．北京：清华大学出版社，１９９７：２０３．
[2] 柳纯录，黄子河，陈渌萍．软件评测师教程．北京：清华大学出版社，２００５：９２．
[3] 林锐，等．CMMI3级软件过程改进方法与规范．北京：电子工业出版社，２００３：１１９．
[4] 中华人民共和国国家标准．评价者用的过程．ＧＢ／Ｔ１８９０５．
--------------------------------------------------------------------------------------------
因上传文件大小受限，如果文件上传不完全或图片无法显示请到：http://www.testage.net 《测试员》电子杂志下
载区下载查看。
欢迎您在线阅读并留下您的宝贵意见。为《测试员》杂志投稿，请发送至：webmaster@testage.net。
登陆测试时代论坛：http://www1.testage.net/bbs/index.asp
登陆慧灵科技：http://www.testage.com.cn
testage发表于 >2006-2-20 16:58:41 [全文] [评论] [引用] [推荐] [档案] [推给好友] [收藏到网摘]
2006-2-20
性能测试原理及实例分析
性能测试原理及实例分析
作者：柳 胜
【摘要】 在大型软件系统投入生产之前进行性能测试已经成为趋势，本文结合一个性能测试案例对性能测试的过程和原理进行了介绍。
【关键字】 性能测试 并发测试 负载测试
• 软件测试中的性能测试
软件测试是保证软件质量的重要手段，也是软件过程中一个必不可少的环节。而性能测试则隶属于软件测试中的系统级测试，它对软件在集成系统中运行的性能行为进行测试，旨在及早确定和消除软件中与构架有关的性能瓶颈。
• 性能测试的含义
目前对性能测试没有明确的定义，一般地，它主要是针对系统的性能指标制定性能测试方案，执行测试用例，得出测试结果来验证系统的性能指标是否满足既定值。性能指标里可能包括系统各个方面的能力，如系统并发处理能力，批量业务处理能力等。
• 性能测试的分解
在性能测试的执行中，可以根据具体的性能指标，分解为几种测试，根据其关系，可以在不同的时间和空间内执行。这些子测试通常包括以下几种：
并发测试：验证系统的并发处理能力。一般是和服务器端建立大量的并发连接，通过客户端的响应时间和服务器端的性能监测情况来判断系统是否达到了既定的并发能力指标。
负载测试：验证系统的负载工作能力。系统配置不变的条件下，在一定时间内，服务器端在高负载情况下的性能行为表现。这里的负载可以是用户数，交易数，事务数等。
配置测试：核实在操作条件保持不变的情况下，系统在使用不同配置时其性能行为的可接受性。
健壮性测试：核实被测系统的性能行为在异常或极端条件之下的可接受性。这里的异常或极端条件指的是资源过少，用户数过多，突发故障等。
随着软件系统的规模日益庞大，结构日趋复杂，对软件系统的性能测试已经成为必须和趋势。尤其大型的分布式软件系统更要在正式运行前进行性能测试，因为这样的系统在投入生产之后，往往要接受大批量的业务量，这对应用程序本身，操作系统, 中心数据库服务器，中间件服务器，网络设备的承受力都是一个严峻的考验。在其中任意一个环节出现的问题都可能给用户带来巨大的商业损失。预见软件系统的并发承受能力以避免商业风险，这是在软件测试阶段就应该解决的。例如中国人民银行的现代化支付系统和上海外汇交易中心的本币交易系统都在投入生产之前进行了多轮的第三方性能测试，起到了很好的作用。
下面我就介绍一个性能测试案例。
• 一个性能测试实例
• 被测系统
1)被测系统介绍
本系统应我国金融信息化发展设计，采用当今比较先进和流行的技术，是运行在城域网上的大型分布式应用系统。
本系统遵循J2EE规范，采用B/S体系结构进行设计和开发。业务主要分为交易业务和查询业务，查询业务采用J2EE规范，交易业务以J2EE体系架构为基础，进行进一步的处理，采用了TCP的四层结构。系统体系结构图如下：
图表 1被测系统体系结构设计图
• 表示层：
运行在终端上。运行javaapplet程序，提供协议控制和用户界面，与系统最终用户实现直接交互，通过TCP/HTTP与前置系统通讯。向前置系统发送请求报文，并接收前置系统返回的回应报文。
• 商业逻辑层：
作为中间层实现核心业务逻辑服务。
交易应用服务：运行在交易主机上。在tuxedo中间件上运行业务处理程序，按交易规则处理前置机发来的交易指令，通过tuxedo jolt与前置机连接，通过DB2 C API与数据库连接。
交易前置服务和查询前置服务：运行在前置机上。交易前置服务运行服务程序接收终端请求报文并通过tuxedo jolt客户端将其转发给交易主机，再通过轮询和同步反馈接收交易主机返回的报文，将其转发给业务终端；查询前置服务运行在weblogic应用服务器上并调用Jreport组件，通过JDBC完成对查询流指令的发送并接受数据库返回的结果给业务终端。
• 数据层：
运行在数据库主机上。负责整个系统中数据信息的存储、访问及其优化。运行DB2数据库服务程序。通过DB2 C API与交易主机通讯，JDBC与查询前置服务通讯。
数据库主机和交易主机运行在交易中心城市，前置机运行在各个分中心城市，终端是各个城市参加交易的单位，整个系统覆盖城域网。
2) 被测系统的性能要求和性能指标
金融系统是业务处理十分频繁、数据交换吞吐量很大的系统，业务处理的速度直接关系到公司的经济效益和客户对公司的评价。在客观条件下，整个广域网系统必须在大业务量的情况下同时保持快速的实时响应能力，以保证整个业务系统的通畅运行。用户对此提出如下性能指标：
表格1用户要求性能指标表
下面我们会根据此系统和给定的性能指标来进行性能测试：
• 对被测系统进行性能测试
性能测试的目的是最大程度地模拟真实业务场景，来验证系统的性能指标，并发现可能存在的性能瓶颈。
1)对被测系统进行系统分析
我们可以看到本系统大体上由终端、前置机、交易主机、数据库主机节点组成。
在整个业务流程中，业务终端→前置机→交易主机→数据库主机形成了一个压力流串，每个节点在压力下能够正常工作是整个系统正常运转的基础。也就是说，如果其中任意一个节点在业务压力下发生了拥塞、处理不力等不正常情况，那整个系统都无法正常运转。
我们来看一下业务流程。
首先，从终端到前置机，终端产生业务报文发送至前置机，前置机上运行查询前置服务和交易前置服务，查询前置服务向下通过HTTP协议以WEB服务形式和终端连接，向上通过JDBC直接与数据库系统相连。交易前置服务向下通过基于TCP协议的socket连接和终端通讯，向上通过tuxedo jolt客户端和交易应用服务连接。交易应用服务进行业务逻辑计算，并操作数据库系统。
由以上分析，我们可以整理出整个系统的两条压力流程线来，之所以我们把其分为两条流程线，是因为交易前置服务和查询前置服务的工作原理完全不同，下与终端的连接，上与交易主机的连接也完全是独立的两个通路。
终端→交易前置机→交易主机→数据库系统
终端→查询前置机→数据库系统
下面我们先独立分析两条流程线，之后我们将再次综合分析，以考虑二者之间的相互影响作用。
第一条路线上主要运行的是登陆指令和交易指令信息。
当系统运作时，多个交易终端与交易前置服务建立socket连接，完成登陆，之后发送交易指令，造成对交易前置服务的压力。交易前置服务通过运行服务程序接收到交易指令，并检验其合法性，然后通过交易中间件tuxedo的客户端把业务的压力传递给交易主机进行处理。交易主机进行必要的金融计算和业务逻辑运行，得出反馈结果，生成消息，一方面顺原路返回到各个终端上去，一方面记录入数据库。
在本条流程线上的加压主要考验交易前置服务程序的socket多连接建立能力，tuxedo交易中间件的即时响应能力，交易主机的计算能力，以及DB2数据库的DML语句加锁机制。
第二条路线上主要运行的是查询指令信息。
查询指令产生时，通过http协议访问weblogic上的web服务器和应用服务器上的相应组件，以JDBC接口访问后台的DB2数据库，并把数据库返回的结果发送至终端界面。
在本条流程线上的加压主要验证weblogic处理能力，数据库中索引是否创建合理。
两条流程线相对独立，但又是互相依赖的。由于是对同一个数据库系统进行读操作和写操作，查询流程的结果依赖于交易流程数据的产生，交易流程的产生的数据又通过查询流程得到验证。在进行压力测试时，两者的协同会对数据库形成压力的冲击。
鉴于以上分析，结合用户性能指标，我们决定把本次性能测试分解为如下几个子测试来进行。
A: 并发登陆测试：750个终端一分钟内并发登陆系统，并且响应时间在30秒之内。
B: 业务负载测试
此下又有三个子测试。
• 交易流程测试：多个终端发起交易请求，逐渐加压，以达到300笔/秒的压力为限。
• 查询流程测试：多个终端进行查询，逐渐加压，以达到400笔/秒的压力为限。查询成功与否以所请求的web页面完全展现为标准。（查询响应能力其实和数据库中的数据量有关系，后来和用户进一步确认，基础数据为30万条）
• 综合测试：
在上面两种测试都通过的情况下，进行综合测试。
2)性能测试的执行过程，性能测试依照下面的步骤来进行：
• 第一步：测试脚本的开发
本次压力测试采用MI公司的loadrunner工具，脚本编辑和编译工作在VU Generator(脚本作坊)中进行。
理想的脚本是对现实世界的业务行为进行了完全无误的模拟，这其实是不可能的。我们的目标是使模拟的误差在我们认可的范围之内，并能有方法加以控制。
针对并发登陆测试和交易流程测试，由于两者运行机理相同，都是终端调用socket client，和交易前置的socket server建立连接，将请求消息发送至交易前置机。我们考虑采用将此部分java socket程序编入测试脚本程序，生成登陆和交易业务脚本，通过loadrunner来执行。这样做的好处是绕过终端IE界面复杂的处理逻辑，直接施压在前置机上（这种方式同时也带来了偏差，在执行测试场景时通过其它方法得到了一定的弥补）。
脚本除了要实现与前置机的socket连接，业务发送等功能，还要建立用户信息数据池，设置检测点、异常退出点，为脚本执行后的结果统计和分析提供正确的依据。
交易业务脚本内容略。部分如下：
publicclass Actions {/*登陆变量初始化*/ProtocolManager protocol;//ProtocolManager为实现socket连接的类 ServiceName service; //ServiceName对服务端的信息进行了封装，包括IP地址和端口号。LoginMessage login；//LoginMessage为登陆时需要向服务器发送的消息，待服务器确认并返回回应消息时，登陆成功。protocol = new ProtocolManager(); //创建ProtocolManager类的protocol对象service = ServiceName.getInstance();//获得ServiceName的实例login=new LoginMessage();//创建LoginMessage类的login对象service.setIP("200.31.10.18";//设置服务端的IP地址service.setPort(17777);//设置服务端的端口号/*设置登陆消息*/ login.serUserName(lr.eval.string(“{loginName}”));//从数据池里读出用户名，设置在login成员变量里login.setPasswd(“1234”);//数据库中添加的用户密码都为1234/*发送登陆消息*/protocol.login(login);//发送登陆消息lr_start_transaction("trade";//交易开始点TradeMessage trademessage;//生成交易消息/*设置交易消息*/
………………………….
………………………….
/*发送交易消息*/
………………………….
………………………….
if(sendfail)lr_end_transaction("trade", LR_FAIL);//如果发送交易消息失败，交易结束，返回。/*循环回收主机返回的处理信息*/
…………………………
…………………………
if(recievefail)lr_end_transaction("trade", LR_FAIL);//如果不能接收到主机处理回应消息，交易结束，返回。if(recievesuccess)lr_end_transaction("trade", LR_PASS);//如果接收到主机成功处理的回应消息，交易结束，返回。
…………………………..
}
在上面的例子中，我们主要对每笔交易进行了transaction化。在交易开始时设置开始检测点，交易结束时设置结束检测点，并给loadrunner报出交易状态。实际的脚本中在回收交易响应消息时还进行了拆包，在应用层上对交易状态进行识别，并非例子中只在socket层加以判断。
针对查询流程测试，由于loadrunner工具支持基于http的web访问录制功能，我们将考虑采用以录制脚本为主，手工编写脚本为辅的方法，生成查询业务脚本，通过loadrunner来执行。由于查询脚本基本由录制生成http请求和应答，不同的压力测试工具录制会有差别，这里就不再写出查询脚本样例。
• 第二步：根据用户性能指标创立测试场景
在本次性能测试中，用户提出的性能指标不够细致和确切，通过对用户调查和实际业务分析，我们把性能指标的实现方式进行了明确的定位。
A:并发登陆测试场景
并发登陆750用户/分钟，登陆响应时间在30秒之内。仔细考虑一下，这里的并发登陆750用户/分钟指的是系统能够在1分钟内接受750个用户的登陆请求，而处理的效果如何则在交易终端体现，即登陆响应时间。基于这样的理解，我们把用户性能指标转化为如下的测试场景：
从第一秒钟开始，用loadrunner每秒钟登陆13个用户，并保持socket连接，直到1分钟结束，从终端向系统一共发送750个左右的用户登陆请求，系统在一分钟内建立了750个连接。在终端观察并统计登陆响应时间。如果系统不能响应持续增加的登陆请求或平均登陆响应时间大于30秒，并发登陆测试场景都不能算通过。
为了帮助用户更加深入了解系统的能力，我们对系统的瞬时并发能力进行测试，即测试系统所能承受的最大的瞬时并发用户登陆连接请求个数。这个场景通过loadrunner在登陆前设置同步点来实现，这个结果将结合上一个结果一同反映系统的登陆处理能力。
B:交易流程测试和查询流程测试：
在这里我们只对系统的业务负载能力做测试（并发处理能力在登陆测试中已经得到考证）。测试场景如下：
在loadrunner中，建立goal-orented的测试场景，以400笔/秒为目标，将调度权交给loadrunner来试图达到这个指标。
C: 综合测试：
交易流程测试和查询流程测试同时进行。
以上的测试场景要求均可在loadrunner中的Controller进行设置完成。
测试场景的创建之后，我们的测试任务更加具体化和清晰化。
• 第三步：运行测试场景，同步监测被测系统性能行为
在loadrunner中的controller中开启unix系统资源计数器，weblogic计数器，DB2计数器，检测系统资源消耗情况，并最终和测试结果数据合并，成为分析图表。
测试结果可在测试执行完毕后，通过loadrunner工具中的Analysis（分析器）获得。
A: 并发登陆测试
依照设计好的测试场景，用loadrunner工具在一分钟内渐增向系统发送登陆请求。分别进行三次，结果如下
表格 2登陆测试结果数据表
注：这里的登陆成功用户指的是系统接受了登陆请求，并建立了连接。平均响应时间在登陆脚本里设置检测点，由loadrunner工具自动获得。
考察系统的瞬时并发处理能力：在完成上一步测试的前提下，逐步增加瞬时并发登陆用户数，直到系统极限。
测试执行结果如下：
表格3瞬时并发登陆测试结果数据表
B: 负载测试
• 交易流程测试：
测试结果如下：
对于通过网络接口发送的批量业务请求，均在性能指标所指定的时间范围内得到请求成功的反馈消息，说明主机已经处理成功。
在通过网络接口发送业务请求的同时，开启IE，通过实际终端界面进行登陆和交易，系统响应时间延长，界面显示和刷新明显变慢，到业务量高峰时期，界面已经不能显示任何信息，处于不可工作的状态。
需求说明的是系统正常工作时，每个界面终端不仅应该能够展示己方的交易信息，还要展示其他交易单位的交易信息和系统信息。因此当交易量大的时候，界面需要展示的信息量是巨大的，这本身对终端界面是一个性能考验。
• 查询流程测试：
本流程测试在交易流程测试之后进行,以利用其生成的数据。
测试结果基本满足性能指标。
• 综合测试
由于交易流程测试的未通过，本测试已经不能执行。
• 第四步：测试结果分析及性能评价
A:并发测试结果分析
根据上述的并发测试响应时间表，我们可以得出以下的结论：
被测系统在一分钟内并不能接受750个用户的登陆请求，其可接受的登陆请求用户数大概为490个左右。在这样的条件下，登陆响应时间在用户要求范围之内。
被测系统的瞬时并发处理能力约为122个用户。
B: 交易流程测试结果分析及性能评价
根据交易流程测试结果可知，通过脚本程序进行业务行为，发送业务请求消息到回收主机处理回应消息，这段时间系统是顺畅的，反应也是迅速的，但是在终端界面却不能即时展现消息。这说明信息的回馈通路在终端界面出现了性能瓶颈。当界面需要在短时间内展示大量交易信息时，已经不能承受负荷。这与终端采用java applet技术有关。
C: 查询流程测试结果分析
查询流程基本符合性能指标。
需要说明的是，实际中，以上每个场景的测试都执行了多次，中间件参数进行了多次的调优。从以上测试的结果分析也可以看出，我们的性能测试瓶颈不是出现在中间件产品上，而是在自身开发的程序上。
• 总结
由以上的实例过程我们可以看出性能测试基本由以下几个步骤进行
1．系统分析
将系统的性能指标转化为性能测试的具体目标。通常在这一步骤里，要分析被测系统结构，结合性能指标，制定具体的性能测试实施方案。这要求测试人员对被测系统结构和实施业务的全面掌握。
2．建立虚拟用户脚本
将业务流程转化为测试脚本，通常指的是虚拟用户脚本或虚拟用户。虚拟用户通过驱动一个真正的客户程序来模拟真实用户。在这一步骤里，要将各类被测业务流程从头至尾进行确认和记录，弄清这些交易过程可以帮助分析到每步操作的细节和时间，并能精确地转化为脚本。此过程类似制造一个能够模仿人的行为和动作的机器人过程。这个步骤非常重要，在这里将现实世界中的单个用户行为比较精确地转化为计算机程序语言。如果对现实世界的行为模仿失真，不能反映真实世界，性能测试的有效性和必要性也就失去了意义。
3．根据用户性能指标创建测试场景
根据真实业务场景，将单个用户的行为进行复制和控制，转化为多个用户的行为。在这个步骤里，对脚本的执行制定规则和约束关系。具体涉及到交易量，并发时序等参数的设置。这好比是指挥脚本运行的司令部。这个步骤十分关键，往往需要结合用户性能指标进行细致地分析。
4．运行测试场景，同步监测应用性能
在性能测试运行中，实时监测能让测试人员在测试过程中的任何时刻都可以了解应用程序的性能优劣。系统的每一部件都需要监测：客户端，网络，web服务器，应用服务器，数据库和所有服务器硬件。实时监测可以在测试执行中及早发现性能瓶颈。
5．性能测试的结果分析和性能评价
结合测试结果数据，分析出系统性能行为表现的规律，并准确定位系统的性能瓶颈所在。在这个步骤里，可以利用数学手段对大批量数据进行计算和统计，使结果更加具有客观性。在性能测试中，需要注意的是，能够执行的性能测试方案并不一定是成功的，成败的关键在于其是否精确地对真实世界进行了模拟。
在整个性能测试过程中，自动化测试工具的选择只能影响性能测试执行的复杂程度，简便一些或繁杂一些；但人的分析和思考却会直接导致性能测试的成败。所以本篇着重于对性能测试思路的整理。测试工具的介绍可以参看有关压力测试工具的资料。
注1：在本次性能测试案例中，还涉及到健壮性测试和可恢复性测试，限于篇幅，只介绍了并发测试和负载测试。
注2：loadrunner脚本样例并非实际运行脚本，只是为了表示其流程。
• 参考文献
Roger S. Pressman：软件工程实践者的研究方法黄柏素梅宏译机械工业出版社
