CS、CSS架构应用的软件性能测试模型分析

-.z安博测试空间技术中心.btestingsky./地址：市海淀区学院路40号大唐电信测试空间楼联系：36230326062303230CS/CSS架构应用的软件性能测试模型分析夏海涛1.CS/CSS系统架构的根本概念1.1系统架构定义虽然B/S构造、J2EE架构愈来愈成为流行模式，但基于传统的C/S构造的应用程序还广泛地应用于各种行业。尤其是金融行业中的商业银行柜面－核心帐务系统等。一方面由于传统商业银行一般都有大量的字符终端等需要复用的设备，一方面也是因为他们存在大量密集的对实时性要求很高的高柜业务，使用传统的基于C/S构造或者C/S/S构造的应用效率更有保证。C/S构造即CLIENT/SERVER构造。传统的C/S构造一般分为两层：客户端和效劳器端。该构造的根本工作原理是，客户程序向数据效劳器发送SQL请求，效劳器返回数据和结果。客户端负责实现用户接口功能，同时封装了局部应用逻辑。效劳器端的数据库效劳器主要提供数据存储功能，也通过触发器和存储过程提供局部应用逻辑。C/S/S构造即客户/应用效劳器/数据库效劳器三层构造，中间增加了应用效劳器，通常实现应用逻辑，是连接客户与数据库效劳器的桥梁。它响应用户发来的请求执行*种业务任务，并与数据库效劳器打交道，技术实现上通常选用中间件产品，如BEA公司的TU*EDO和IBM公司的CICS等。〔事实上J2EE架构的应用也属于这种三层或多层构造，这里不包括。〕三层或多层C/S构造与两层C/S构造相比，它的优势主要表现在：平安性加强、效率提高、易于维护、可伸缩性、可共享性、开放性好等。1.2系统架构示意图1.3CS/CSS系统架构中性能测试的特点系统架构的性能影响因素由于CS/CSS系统的以下特性，测试工程师对一个CS/CSS系统实施性能测试具有很大的难度：*整个系统的各个局部使用多种操作系统，性能上有差异；*整个系统架构的各个环节上使用多种数据库，同样在性能上有差异；*应用是多个，分属多个种类，分布在不同设备上，包括自行开发的应用、第三方的应用；*系统中的设备、组件通过不同协议进展连接、通讯；*系统的内部接口多，性能瓶颈多；而系统的整体性能往往取决于最差的局部；需要分别测试和联合测试*系统的性能指标不光同应用系统架构有关，还和具体行业应用的业务模式有关；*采用此架构的行业应用往往是一个7×24小时系统；*采用此架构的行业应用可能高柜业务多，这样会影响对性能度量项的选取和转换；*各个环节根本上以交换数据报文的方式通信，其格式经常会比拟复杂。因此这样的系统对于对测试工程师的知识的深度和广度都是一个考验。对于这样的系统，到底如何使用什么样的测试策略、如何分析测试需求、如何选取性能度量项的转换计算模型、如何确定测试内容和轮次、如何设计性能测试案例等等以及规划和实施性能测试中的其它诸多问题，都需要遵循一个系统的方法来解决。系统架构中性能测试的根本策略1.确定好测试工作*围首先可以分析压力测试中最容易出现瓶颈的地方，从而有目的地调整测试策略或测试环境，使压力测试结果真实地反映出软件的性能。例如，效劳器的硬件限制、数据库的性能设置等常常会成为制约软件性能的重要因素，但这些因素显然不是用户最关心的，我们在测试之前就要通过一些设置把这些因素的影响调至最低。另外，用户更关心整个系统中哪个环节的性能情况也会影响工作*围。如有的环节是全新系统，而有的环节已经是成熟系统只是稍有改动，这样可能全新系统的局部性能测试就需要系统和全面一些。2.分析好客户的性能测试需求客户是已经明确提出了性能指标，还是只提供了用户使用方式和历史交易流量数据，需要我们自己进展性能基准的计算.性能测试的目的是验证系统性能还是想确定目标系统的理想配置.是否还要使用测试结果预测在不同机型的处理能力.是否要求在性能测试各个轮次中安排性能调优过程等等问题都需要有针对性的解答。3.要作好性能测试的方案和方案测试方案和方案中要注意测试需求分析阶段提出的问题的解决。4.确定的测试通过准则、性能测试的方案、结果要获得客户的认可要和客户确认，系统的性能指标达标的标准是什么；对于性能测试中各个局部和步骤的方案和结果，甚至是性能测试过程，都要根据其重要程度，决定是否需要客户进展确认和签字。获得客户的认可是最重要的。系统中性能测量与性能探测性能测量1.在性能测试开场前必须认真规划性能测量：软件性能测量技术*围很广。可以包括日志、事件计数、事件持续时间、采样等性能测量技术。*确定性能测量的策略：我们要测试什么.*规划性能测试中使用什么样的测量工具。2.测量的代表性*测量结果要能够反映出影响性能的重要因素：工作量负载、软件和计算机系统环境。3.测量的可重复性*能够控制工作量负载、软件和计算机系统环境，从而能够重复测试过程。性能探测技术在进展性能测量时，可以使用标准的商用工具进展，但是往往标准工具提供的数据不能满足要求。性能探测就是在程序的关键点插入代码探针来测量软件的执行特性。从而到达以下的目标：–性能数据获取更方便–数据的详细程度提高–数据收集方式更加可控依据SPE〔软件性能工程〕的建议，软件探测需求应该作为软件体系构造的组成局部。在设计软件时设计软件探针。所以在规划工程中的性能测试过程中，要建议进展软件设计时考虑岛性能探测需求，为性能测试中更好的进展性能测量做好准备。系统下性能测试的类型广义的性能测试包括许多类型。如：*Scalability/loadtesting(规模化/压力测试)：通过在被测系统上不断增加压力，直到性能指标例如响应时间超过预定指标或者*种资源已经到达饱和状态。这种测试可以找到系统的处理极限，为系统调优提供数据。*Performancetesting(性能测试)：通过模拟生产运行的业务压力量和使用场景组合测试系统的性能是否满足生产性能要求。如以实际投产构造测试，求出最大的吞吐量与最正确回应时间以保证上线的平稳，平安等。*Configurationtesting(配置测试)：通过测试找到系统各项资源的最优分配原则。*Concurrencytesting〔并发测试〕：测试多个用户同时同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题。*Stresstesting〔极限测试〕：测试系统在一定饱和状态下，例如CPU、内存在饱和使用饱和情况下，系统能够处理的会话能力，以及系统是否会出现错误。*Volumetesting〔容量测试〕：测试系统能够处理的最大会话能力。*Reliabilitytesting〔可靠性测试〕：通过给系统加载一定的业务压力〔例如资源在70-90%的使用率〕的情况下，运行一段时间。*Failovertesting〔失败测试〕：对于有冗余备份和负载均衡的系统，通过这样的测试来检验如果系统局部发生故障用户是否能够继续使用系统，用户将受到多大的影响。在CS/CSS系统下实际的性能测试中，需要根据具体情况进展性能测试类型的选取和组合。系统下性能测试的组成局部通常在一个CS/CSS系统中，分为用户界面层、效劳逻辑层和数据效劳层等几个层次，分别对应着客户、应用效劳器、数据库效劳器。如在金融行业应用中，客户端承载着柜面业务，部署在网点〔包括字符柜员或图形柜员〕，还包括部署在自助设备上面的自助业务等；应用效劳器上面主要是起到路由功能、业务处理功能、和渠道整合的作用；而核心业务处理系统包括交易平台、业务逻辑、核心处理、数据处理等。由于业务逻辑分布在不同的环节，导致系统的内部接口多，性能瓶颈多，而系统的整体性能往往取决于最差的局部。所以对于整个系统的整体性能的测试可能需要针对各个环节分别做好各自的内部性能测试。如下面的一个CS/CSS系统金融行业应用的例子：为了测试整个系统的性能，需要预先针对各个组成局部进展内部性能测试，如后台主机的压力测试、SNAgateway的压力测试、大前置系统的压力测试、前端系统的压力测试、外系统接入的压力测试等等。在本次进展的内部压力测试中，为了排除系统其它局部的影响，均需要隔离各自的局部，驱动和桩都使用软件测试工具或自行编制程序来代替。在每个局部的内部压力测试中，又均可以根据具体情况使用上一节说明的各种性能测试类型进展性能测量。2.CS/CSS系统架构中的性能测试的度量项计算模型2.1定义度量标准项进展性能测试的模型分析时，首先要确定关键性能目标。它应该是通过与客户沟通获得的，这些目标应该是解决客户关注的性能问题，也就是说，客户的性能测试需求表达为关键性能目标。性能目标应该是明确的、可度量的。例如：支持2000个并发用户；连续运行30天不停机等。在明确了关键性能目标和性能测试的通过/失败准则后，需要定义如何度量关键性能目标和性能测试的通过/失败准则。度量的标准项会影响测试方法和测试工具的选择。举例来说，如果要度量100个用户并发的响应时间，就必须明确要度量以下哪一个标准项：*每个并发用户的响应时间*在有99个用户已经接入的情况下，第100个用户的响应时间*两个指标都要度量2.2性能基准及测试强度估算实际上，关键性能目标并不总是很容易明确的。客户往往只有一些历史数据和业务增长的一些预期比例等等。但是这些数据对于我们也是很有用的，它们可以作为我们设计和测试使用的性能基准。对于性能测试，在设计时就要首先提出设计的性能基准。所谓性能基准，就是要思考：多少人使用这个系统.使用时最大的用户数是多少.用户顶峰期使用时间间隔多少，在多大数量级别上系统响应时间分别是什么.数据增长量有多大.数据增长到什么数量级和时间长短对硬件而言难于承受.网络实现条件是什么.在处理时CPU和内存增长如何控制.种种这些，然后设计时根据性能基准有条件的在编码实现和硬件配置方面进展优化，测试只不过验证系统是否到达预期设计目标。但是现在的情况却往往是：设计出来后要求性能测试，测试什么然后是什么，好比考试没有标准答案却要求大家及格一样。或者是，客户虽然已经明确的提出了关键性能指标，但是设计的时候没有考虑，依赖于性能测试给出实际性能数据，然后再比照优化。性能测试在基于性能基准上，特别是基于经过计算和转换得到的关键性能目标，才能得出预期结果。这一点，需要测试工程师向设计人员反复灌输这种观念，否则，性能测试研究包括工具研究总是停留在讨论阶段。不要在编码完成以后才考虑优化问题，如果等工程实施了，优化还没有完成，就很难保证客户满意。没有目标的设计，如同城市间的交通问题一样，我们抱怨建立者们缺乏远见，而软件设计人员同样缺乏想象力。对于性能基准向关键性能目标的转化，用以下例子来说明。有200个用户使用客户端软件进展业务处理〔并发度至少要到达200并发〕，每年通过软件进展处理的总业务量为：2000万笔业务/年。测试强度估算时采用如下假设前提：*全年的业务量集中在10个月完成，每个月20个工作日，每个工作日8个小时；*采用80—20原理，每个工作日中80%的业务在20%的时间内完成，即每天80%的业务在1.6小时内完成；测试压力的估算结果：去年全年处理业务约2000万笔，其中15%的业务处理每笔业务需对应用效劳器提交3次请求；70%的业务处理每笔业务需对应用效劳器提交2次请求；其余15%的业务每笔业务向应用效劳器提交1次请求。根据以往统计结果，每年的业务增量为15%，考虑到今后三年业务开展的需要，测试需按现有业务量的2倍进行。每年总的请求数量为：〔2000*15%*3+2000*70%*2+2000*15%*1〕*2="8000万次/年。每天的请求数量为：8000/200="40万次/天。每秒的请求数量为：〔400000*80%〕/〔8*20%*3600〕=55.6次/秒。正常情况下，应用效劳器处理请求的能力至少应到达：56次/秒。或者，忽略提交的请求数，以业务交易数为准，定义每秒钟的交易数，及“吞吐量〞。如果再考虑未来几年的交易量的增加〔每年增长15％〕，则可以归纳为：?吞吐量：(T4*80%)/(1.6*3600)–T4=T0*(1+15%)^4–T0：当前日均交易量2000万–T4：未来4年日均交易量另外，有时关键性能指标确实定和具体应用相关。如金融行业应用中的核心业务系统中会有日结、月结等批处理，往往使用一次批处理小于多少小时来表征性能指标。2.3度量标准项和可采集的测量数据项转换只有使用明确的可采集到的数据才能真正反映系统的性能状况。例如：*每秒钟运行成功的交易数量*单一客户端的响应时间(使用时间戳的差值，发出请求的时间和收到回应的时间)*CPU的占用率*网络流量占用率*内存的占用率*硬盘使用率2.4压力的分解对于一个由很多环节组成的复杂系统来说，如果想要模拟实际环境进展整体的联合性能测试的话，就需要针对整体压力进展各个层次的分解。如：以下图是一个实际系统进展的联合性能测试。后台主机系统最多的吞吐量是480笔/秒。。由于通信网关和主机在此环境中是1对1的关系，所以通信网关的压力要到达480笔/秒。而一个通信网关对应着三个前置机，所以每个前置机要到达160笔/秒送达主机的吞吐量，才可能使整个系统满负荷运转。考虑到其它层次类推。由于主机以外还存在其它效劳系统，所以在前置机的压力上面加了一个“*〞代表其它效劳系统要求的压力。当*个层次的设备短缺，无法实际上到达其分解下来的压力时，往往需要使用软件手段，在上一层次上直接加压力解决。3.CS/CSS系统架构中的性能测试的规划与实施要点3.1测试方案中的人力资源方案由于性能测试时软件测试领域比拟复杂的类型，所以性能测试方案中人力资源的方案也比拟重要。要充分考虑到测试组织、测试程序的编写、测试设计、实现和执行、测试报告等等各种工作任务的人力资源需求情况。一般情况下，一个工程类工程的性能测试工作由如下角色和职责：*测试分析师：负责分析测试策略、编写测试方案、制订测试方案、组织测试；*测试工程师：测试例设计、实现；环境协调；对测试结果进展分析，编写测试总结报告。*测试员〔通常也可测试工程师兼任〕：测试执行；对测试过程进展记录，收集、整理测试记录数据。*软件工程师〔有时由测试工程师兼任〕：负责编写、调试客户端测试软件和模拟软件；数据库管理系统的安装、ofs配置及系统的预埋数据准备。*系统工程师〔有时由测试工程师兼任〕：负责测试用的硬件维护及操作系统安装、配置。*上级测试负责人：负责对测试方案及测试总结报告进展批准。*客户：必要时可参加测试，并提出具体的测试要求；可要求暂停测试；重要测试结论要签字认可。3.2为工程选择适合的测试工具在性能测试过程中，一定要有适合的测试工具支持。性能测试所使用的测试工具包括：负载模拟类工具性能测量类工具系统级测量工具：CPU、内存使用率统计统计类：响应时间、吞吐剖析类：代码级测量工具，例如统计函数调用次数对于测试工具，每个具体工程的需求是有差异的，不存在通用解决方案。而且，工具的引入需要时间、资金和人力的投入。测试工具的选择需要考虑性能测试中被测系统的需要，以及测试工具需要完成的功能。一般情况下的选择方案包括：*真实生产系统*商用压力测试工具*定制压力测试工具第一种选择限于资源以及准确性等因素在压力测试中一般不采用，这里不再讨论。对于后两种选择的取舍主要考虑的因素包括：*是否能够满足压力测试中作为模拟程序、负载模拟的需要*是否能够提供详细，准确的性能测量数据*测试工具在本钱的限制因素，包括时间和金钱*测试组对测试工具的掌握程度有很多很好的自动化的性能测试工具。如：MI的Loadrunner、MI的AstraLoadTest、Empiri*的E-load、RationalTeamTest等等。其中又以MI的Loadrunner最为著名和常用。有时在性能测试过程中也会采用自编的或定制的压力测试工具的方案，主要基于如下的原因：首先、由于被测系统本身的特点，满足模拟程序需要的商用测试工具难以寻觅，即便是有靠近这方面需求的测试工具，考虑到费用以及培训时间的因素，也会增加测试过程的风险。其次，有时由于相关技术的成熟，选择定制压力测试工具的方案无论在设计，实现，还是在测试工具的掌握上都不存在不可控的风险；并且在测试过程中随时满足测试需要的及时性方面，定制的测试工具也有无可比拟的优势。最后、考虑到将来前置系统的产品化，对该系统进一步测试的需要会持续很久，定制的测试工具可以更好，更完善地满足这种需求。同时，对于与对象系统采用同样系统架构的工程都可以借鉴此定制测试工具的思想，快速地建立新的测试工具。3.3测试准备工作性能测试的准备工作，可以包括测试数据的准备、测试工具准备、测试环境准备、试执行等局部。测试数据的准备对于行业应用，尤其是金融行业应用，测试数据的准备中最重要的就是交易的选取。交易的选取有如下原则：内部压力测试：尽量选取几个最消耗系统资源的交易，并覆盖所有的交易形态〔如会话式、批量式、异步式之类〕，这样才有可能最大限度的检查出该局部的性能瓶颈；整体联合压力测试：由于一般整体联合压力测试需要完全模拟实际生产情况，所以交易的抽样选取相比照较复杂。通常需要进展当前交易量的收集和预测性能测试交易量，更重要的是确定交易发送比例的分布。如一个实际金融工程的交易发送比例的分布：先选取实际原始发送比例中前50位的交易。然后将其所有比例数相加〔一定小于1〕，做为新的