2023年6月21日发(作者：)
CSCSS系统架构的基本概念CS/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公司的TUXEDO和IBM公司的CICS等。（事实上J2EE架构的应⽤也属于这种三层或多层结构，这⾥不包括。）三层或多层C/S结构与两层C/S结构相⽐，它的优势主要表现在：安全性加强、效率提⾼、易于维护、可伸缩性、可共享性、开放性好等。1.2系统架构⽰意图1.3CS/CSS系统架构中性能测试的特点1.3.1CS/CSS系统架构的性能影响因素由于CS/CSS系统的以下特性，测试⼯程师对⼀个CS/CSS系统实施性能测试具有很⼤的难度：*整个系统的各个部分使⽤多种操作系统，性能上有差别；*整个系统架构的各个环节上使⽤多种数据库，同样在性能上有差别；*应⽤是多个，分属多个种类，分布在不同设备上，包括⾃⾏开发的应⽤、第三⽅的应⽤；*系统中的设备、组件通过不同协议进⾏连接、通讯；*系统的内部接⼝多，性能瓶颈多；⽽系统的整体性能往往取决于最差的部分；需要分别测试和联合测试*系统的性能指标不光同应⽤系统架构有关，还和具体⾏业应⽤的业务模式有关；*采⽤此架构的⾏业应⽤往往是⼀个7×24⼩时系统；*采⽤此架构的⾏业应⽤可能⾼柜业务多，这样会影响对性能度量项的选取和转换；*各个环节基本上以交换数据报⽂的⽅式通信，其格式经常会⽐较复杂。因此这样的系统对于对测试⼯程师的知识的深度和⼴度都是⼀个考验。对于这样的系统，到底如何使⽤什么样的测试策略、如何分析测试需求、如何选取性能度量项的转换计算模型、如何确定测试内容和轮次、如何设计性能测试案例等等以及规划和实施性能测试中的其它诸多问题，都需要遵循⼀个系统的⽅法来解决。1.3.2CS/CSS系统架构中性能测试的基本策略1. 确定好测试⼯作范围⾸先可以分析压⼒测试中最容易出现瓶颈的地⽅，从⽽有⽬的地调整测试策略或测试环境，使压⼒测试结果真实地反映出软件的性能。例如，服务器的硬件限制、数据库的访问性能设置等常常会成为制约软件性能的重要因素，但这些因素显然不是⽤户最关⼼的，我们在测试之前就要通过⼀些设置把这些因素的影响调⾄最低。另外，⽤户更关⼼整个系统中哪个环节的性能情况也会影响⼯作范围。如有的环节是全新系统，⽽有的环节已经是成熟系统只是稍有改动，这样可能全新系统的局部性能测试就需要系统和全⾯⼀些。2. 分析好客户的性能测试需求客户是已经明确提出了性能指标，还是只提供了⽤户使⽤⽅式和历史交易流量数据，需要我们⾃⼰进⾏性能基准的计算？性能测试的⽬的是验证系统性能还是想确定⽬标系统的理想配置？是否还要使⽤测试结果预测在不同机型的处理能⼒？是否要求在性能测试各个轮次中安排性能调优过程等等问题都需要有针对性的解答。3. 要作好性能测试的计划和⽅案测试计划和⽅案中要注意测试需求分析阶段提出的问题的解决。4. 确定的测试通过准则、性能测试的计划、结果要获得客户的认可要和客户确认，系统的性能指标达标的标准是什么；对于性能测试中各个部分和步骤的计划和结果，甚⾄是性能测试过程，都要根据其重要程度，决定是否需要客户进⾏确认和签字。获得客户的认可是最重要的。1.3.3CS/CSS系统中性能测量与性能探测性能测量1. 在性能测试开始前必须认真规划性能测量：软件性能测量技术范围很⼴。可以包括⽇志、事件计数、事件持续时间、采样等性能测量技术。*确定性能测量的策略：我们要测试什么？*规划性能测试中使⽤什么样的测量⼯具。2. 测量的代表性*测量结果要能够反映出影响性能的重要因素：⼯作量负载、软件和计算机系统环境。3. 测量的可重复性*能够控制⼯作量负载、软件和计算机系统环境，从⽽能够重复测试过程。性能探测技术在进⾏性能测量时，可以使⽤标准的商⽤⼯具进⾏，但是往往标准⼯具提供的数据不能满⾜要求。性能探测就是在程序的关键点插⼊代码探针来测量软件的执⾏特性。从⽽达到以下的⽬标：– 性能数据获取更⽅便– 数据的详细程度提⾼– 数据收集⽅式更加可控依据SPE（软件性能⼯程）的建议，软件探测需求应该作为软件体系结构的组成部分。在设计软件时设计软件探针。所以在规划项⽬中的性能测试过程中，要建议进⾏软件设计时考虑岛性能探测需求，为性能测试中更好的进⾏性能测量做好准备。1.3.4CS/CSS系统下性能测试的类型⼴义的性能测试包括许多类型。如：*Scalability/load testing (规模化/压⼒测试) ：通过在被测系统上不断增加压⼒，直到性能指标例如响应时间超过预定指标或者某种资源已经达到饱和状态。这种测试可以找到系统的处理极限，为系统调优提供数据。*Performance testing (性能测试)：通过模拟⽣产运⾏的业务压⼒量和使⽤场景组合测试系统的性能是否满⾜⽣产性能要求。如以实际投产结构测试，求出最⼤的吞吐量与最佳回应时间以保证上线的平稳，安全等。*Configuration testing(配置测试)：通过测试找到系统各项资源的最优分配原则。*Concurrency testing（并发测试）：测试多个⽤户同时访问同⼀个应⽤、同⼀个模块或者数据记录时是否存在死锁或者其他性能问题。*Stress testing （极限测试）：测试系统在⼀定饱和状态下，例如CPU、内存在饱和使⽤饱和情况下，系统能够处理的会话能⼒，以及系统是否会出现错误。*Volume testing （容量测试）：测试系统能够处理的最⼤会话能⼒。*Reliability testing （可靠性测试）：通过给系统加载⼀定的业务压⼒（例如资源在70-90%的使⽤率）的情况下，运⾏⼀段时间。*Failover testing （失败测试）：对于有冗余备份和负载均衡的系统，通过这样的测试来检验如果系统局部发⽣故障⽤户是否能够继续使⽤系统，⽤户将受到多⼤的影响。在CS/CSS系统下实际的性能测试中，需要根据具体情况进⾏性能测试类型的选取和组合。1.3.5CS/CSS系统下性能测试的组成部分通常在⼀个CS/CSS系统中，分为⽤户界⾯层、服务逻辑层和数据服务层等⼏个层次，分别对应着客户、应⽤服务器、数据库服务器。如在⾦融⾏业应⽤中，客户端承载着柜⾯业务，部署在⽹点（包括字符柜员或图形柜员），还包括部署在⾃助设备上⾯的⾃助业务等；应⽤服务器上⾯主要是起到路由功能、业务处理功能、和渠道整合的作⽤；⽽核⼼业务处理系统包括交易平台、业务逻辑、核⼼处理、数据处理等。由于业务逻辑分布在不同的环节，导致系统的内部接⼝多，性能瓶颈多，⽽系统的整体性能往往取决于最差的部分。所以对于整个系统的整体性能的测试可能需要针对各个环节分别做好各⾃的内部性能测试。如下⾯的⼀个CS/CSS系统⾦融⾏业应⽤的例⼦：为了测试整个系统的性能，需要预先针对各个组成部分进⾏内部性能测试，如后台主机的压⼒测试、SNA gateway的压⼒测试、⼤前置系统的压⼒测试、前端系统的压⼒测试、外系统接⼊的压⼒测试等等。在本次进⾏的内部压⼒测试中，为了排除系统其它部分的影响，均需要隔离各⾃的部分，驱动和桩都使⽤软件测试⼯具或⾃⾏编制程序来代替。在每个部分的内部压⼒测试中，⼜均可以根据具体情况使⽤上⼀节说明的各种性能测试类型进⾏性能测量。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万次/天。每秒的请求数量为：（*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笔/秒送达主机的吞吐量，才可能使整个系统满负荷运转。考虑到其它层次类推。由于主机以外还存在其它服务系统，所以在前置机的压⼒上⾯加了⼀个“X”代表其它服务系统要求的压⼒。当某个层次的设备短缺，⽆法实际上达到其分解下来的压⼒时，往往需要使⽤软件⼿段，在上⼀层次上直接加压⼒解决。3. CS/CSS系统架构中的性能测试的规划与实施要点3.1 测试计划中的⼈⼒资源计划由于性能测试时软件测试领域⽐较复杂的类型，所以性能测试计划中⼈⼒资源的计划也⽐较重要。要充分考虑到测试组织、测试程序的编写、测试设计、实现和执⾏、测试报告等等各种⼯作任务的⼈⼒资源需求情况。⼀般情况下，⼀个⼯程类项⽬的性能测试⼯作由如下⾓⾊和职责：*测试分析师：负责分析测试策略、编写测试计划、制订测试⽅案、组织测试；*测试⼯程师：测试例设计、实现；环境协调；对测试结果进⾏分析，编写测试总结报告。*测试员（通常也可测试⼯程师兼任）：测试执⾏；对测试过程进⾏记录，收集、整理测试记录数据。*软件⼯程师（有时由测试⼯程师兼任）：负责编写、调试客户端测试软件和模拟软件；数据库管理系统的安装、ofs配置及系统的预埋数据准备。*系统⼯程师（有时由测试⼯程师兼任）：负责测试⽤的硬件维护及操作系统安装、配置。*上级测试负责⼈：负责对测试计划及测试总结报告进⾏批准。*客户：必要时可参加测试，并提出具体的测试要求；可要求暂停测试；重要测试结论要签字认可。3.2 为项⽬选择适合的测试⼯具在性能测试过程中，⼀定要有适合的测试⼯具⽀持。性能测试所使⽤的测试⼯具包括：负载模拟类⼯具性能测量类⼯具系统级测量⼯具：CPU、内存使⽤率统计统计类：响应时间、吞吐剖析类：代码级测量⼯具，例如统计函数调⽤次数对于测试⼯具，每个具体项⽬的需求是有差异的，不存在通⽤解决⽅案。⽽且，⼯具的引⼊需要时间、资⾦和⼈⼒的投⼊。测试⼯具的选择需要考虑性能测试中被测系统的需要，以及测试⼯具需要完成的功能。⼀般情况下的选择⽅案包括：*真实⽣产系统*商⽤压⼒测试⼯具*定制压⼒测试⼯具第⼀种选择限于资源以及准确性等因素在压⼒测试中⼀般不采⽤，这⾥不再讨论。对于后两种选择的取舍主要考虑的因素包括：*是否能够满⾜压⼒测试中作为模拟程序、负载模拟的需要*是否能够提供详细，准确的性能测量数据*测试⼯具在成本的限制因素，包括时间和⾦钱*测试组对测试⼯具的掌握程度有很多很好的⾃动化的性能测试⼯具。如：MI的Loadrunner、MI的Astra LoadTest、Empirix的E-load、Rational TeamTest等等。其中⼜以MI的Loadrunner最为著名和常⽤。有时在性能测试过程中也会采⽤⾃编的或定制的压⼒测试⼯具的⽅案，主要基于如下的原因：⾸先、由于被测系统本⾝的特点，满⾜模拟程序需要的商⽤测试⼯具难以寻觅，即便是有靠近这⽅⾯需求的测试⼯具，考虑到费⽤以及培训时间的因素，也会增加测试过程的风险。其次，有时由于相关技术的成熟，选择定制压⼒测试⼯具的⽅案⽆论在设计，实现，还是在测试⼯具的掌握上都不存在不可控的风险；并且在测试过程中随时满⾜测试需要的及时性⽅⾯，定制的测试⼯具也有⽆可⽐拟的优势。最后、考虑到将来前置系统的产品化，对该系统进⼀步测试的需要会持续很久，定制的测试⼯具可以更好，更完善地满⾜这种需求。同时，对于与对象系统采⽤同样系统架构的项⽬都可以借鉴此定制测试⼯具的思想，快速地建⽴新的测试⼯具。3.3 测试准备⼯作性能测试的准备⼯作，可以包括测试数据的准备、测试⼯具准备、测试环境准备、试执⾏等部分。3.3.1测试数据的准备对于⾏业应⽤，尤其是⾦融⾏业应⽤，测试数据的准备中最重要的就是交易的选取。交易的选取有如下原则：内部压⼒测试：尽量选取⼏个最消耗系统资源的交易，并覆盖所有的交易形态（如会话式、批量式、异步式之类），这样才有可能最⼤限度的检查出该部分的性能瓶颈；整体联合压⼒测试：由于⼀般整体联合压⼒测试需要完全模拟实际⽣产情况，所以交易的抽样选取相对⽐较复杂。通常需要进⾏当前交易量的收集和预测性能测试交易量，更重要的是确定交易发送⽐例的分布。如⼀个实际⾦融项⽬的交易发送⽐例的分布：先选取实际原始发送⽐例中前50位的交易。然后将其所有⽐例数相加（⼀定⼩于1），做为新的基数，分别于各个交易的原始⽐例相除，即可得到使⽤⼯具模拟发送的⽐例。此外，主要实际交易数据的获得通常要从数据库中使⽤脚本提取出来；还有可能需要⾃⼰利⽤某些规则⾃造⼀些数据。3.3.2测试⼯具的准备通常，要为测试⼯具的编制和学习使⽤预留充⾜的时间。对于商⽤的测试⼯具，通常需要进⾏脚本的录制和修改，场景的设定⼯作；对于⾃编⼯具，要有设计、编码过程。⽽且，它还通常有其⾃⼰的配置⽂件和使⽤的数据⽂件，需要进⾏配置或数据格式转换。3.3.3测试环境准备这⾥需要注意的问题是，可能在后台（充当桩的）数据库中需要⽣成预埋测试数据，要保证其⾜够且可重复⽣成或容易清理。另外测试环境准备好了以后，每次执⾏前的检查环境过程也是⾮常重要的，可以避免⼤量的⽆⽤功。4. 性能测试报告4.1 测试结构数据的整理和分析测试报告⽂档的撰写1． 测试中应该⽣成的测试⽂件测试记录（测试负责⼈和参与测试的⼈员签字）；测试总结报告。2． 测试总结报告中⼀般必须包含的内容被测试软件名称、测试项、测试环境；被测试软件的压⼒测试结论：响应时间、最⼤/最⼩并发数、失败的次数、正常连续运⾏的最长/最短时间，并发数与失败的关系等总之必须包含预先定义的关键性能指标的数据、变化曲线分析和结论。5. CS/CSS系统架构下性能测试中需要注意的问题5.1 注意中间件的license、数据库的⽤户数等影响因素有时候测试结果没有达到预期并不⼀定是被测对象的问题，可能是中间件的license不⾜或者是使⽤的数据库系统的并发⽤户数的限制导致，有时还因为配置项有问题等，需要综合分析。5.2 数据聚集问题性能测试中选⽤的数据应该在差异上进⾏分散，与实际⽣产数据的随即差异分布相似，充分测试系统在不同数据下的状态。如果使⽤较单⼀的数据进⾏测试，⼀⽅⾯可能使系统的局部功能没有被使⽤，导致性能测试数据不可靠；另外，如果系统对于同样的数据处理有优化处理功能，也导致性能测试数据不可靠。
2023年6月21日发(作者：)
CSCSS系统架构的基本概念CS/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公司的TUXEDO和IBM公司的CICS等。（事实上J2EE架构的应⽤也属于这种三层或多层结构，这⾥不包括。）三层或多层C/S结构与两层C/S结构相⽐，它的优势主要表现在：安全性加强、效率提⾼、易于维护、可伸缩性、可共享性、开放性好等。1.2系统架构⽰意图1.3CS/CSS系统架构中性能测试的特点1.3.1CS/CSS系统架构的性能影响因素由于CS/CSS系统的以下特性，测试⼯程师对⼀个CS/CSS系统实施性能测试具有很⼤的难度：*整个系统的各个部分使⽤多种操作系统，性能上有差别；*整个系统架构的各个环节上使⽤多种数据库，同样在性能上有差别；*应⽤是多个，分属多个种类，分布在不同设备上，包括⾃⾏开发的应⽤、第三⽅的应⽤；*系统中的设备、组件通过不同协议进⾏连接、通讯；*系统的内部接⼝多，性能瓶颈多；⽽系统的整体性能往往取决于最差的部分；需要分别测试和联合测试*系统的性能指标不光同应⽤系统架构有关，还和具体⾏业应⽤的业务模式有关；*采⽤此架构的⾏业应⽤往往是⼀个7×24⼩时系统；*采⽤此架构的⾏业应⽤可能⾼柜业务多，这样会影响对性能度量项的选取和转换；*各个环节基本上以交换数据报⽂的⽅式通信，其格式经常会⽐较复杂。因此这样的系统对于对测试⼯程师的知识的深度和⼴度都是⼀个考验。对于这样的系统，到底如何使⽤什么样的测试策略、如何分析测试需求、如何选取性能度量项的转换计算模型、如何确定测试内容和轮次、如何设计性能测试案例等等以及规划和实施性能测试中的其它诸多问题，都需要遵循⼀个系统的⽅法来解决。1.3.2CS/CSS系统架构中性能测试的基本策略1. 确定好测试⼯作范围⾸先可以分析压⼒测试中最容易出现瓶颈的地⽅，从⽽有⽬的地调整测试策略或测试环境，使压⼒测试结果真实地反映出软件的性能。例如，服务器的硬件限制、数据库的访问性能设置等常常会成为制约软件性能的重要因素，但这些因素显然不是⽤户最关⼼的，我们在测试之前就要通过⼀些设置把这些因素的影响调⾄最低。另外，⽤户更关⼼整个系统中哪个环节的性能情况也会影响⼯作范围。如有的环节是全新系统，⽽有的环节已经是成熟系统只是稍有改动，这样可能全新系统的局部性能测试就需要系统和全⾯⼀些。2. 分析好客户的性能测试需求客户是已经明确提出了性能指标，还是只提供了⽤户使⽤⽅式和历史交易流量数据，需要我们⾃⼰进⾏性能基准的计算？性能测试的⽬的是验证系统性能还是想确定⽬标系统的理想配置？是否还要使⽤测试结果预测在不同机型的处理能⼒？是否要求在性能测试各个轮次中安排性能调优过程等等问题都需要有针对性的解答。3. 要作好性能测试的计划和⽅案测试计划和⽅案中要注意测试需求分析阶段提出的问题的解决。4. 确定的测试通过准则、性能测试的计划、结果要获得客户的认可要和客户确认，系统的性能指标达标的标准是什么；对于性能测试中各个部分和步骤的计划和结果，甚⾄是性能测试过程，都要根据其重要程度，决定是否需要客户进⾏确认和签字。获得客户的认可是最重要的。1.3.3CS/CSS系统中性能测量与性能探测性能测量1. 在性能测试开始前必须认真规划性能测量：软件性能测量技术范围很⼴。可以包括⽇志、事件计数、事件持续时间、采样等性能测量技术。*确定性能测量的策略：我们要测试什么？*规划性能测试中使⽤什么样的测量⼯具。2. 测量的代表性*测量结果要能够反映出影响性能的重要因素：⼯作量负载、软件和计算机系统环境。3. 测量的可重复性*能够控制⼯作量负载、软件和计算机系统环境，从⽽能够重复测试过程。性能探测技术在进⾏性能测量时，可以使⽤标准的商⽤⼯具进⾏，但是往往标准⼯具提供的数据不能满⾜要求。性能探测就是在程序的关键点插⼊代码探针来测量软件的执⾏特性。从⽽达到以下的⽬标：– 性能数据获取更⽅便– 数据的详细程度提⾼– 数据收集⽅式更加可控依据SPE（软件性能⼯程）的建议，软件探测需求应该作为软件体系结构的组成部分。在设计软件时设计软件探针。所以在规划项⽬中的性能测试过程中，要建议进⾏软件设计时考虑岛性能探测需求，为性能测试中更好的进⾏性能测量做好准备。1.3.4CS/CSS系统下性能测试的类型⼴义的性能测试包括许多类型。如：*Scalability/load testing (规模化/压⼒测试) ：通过在被测系统上不断增加压⼒，直到性能指标例如响应时间超过预定指标或者某种资源已经达到饱和状态。这种测试可以找到系统的处理极限，为系统调优提供数据。*Performance testing (性能测试)：通过模拟⽣产运⾏的业务压⼒量和使⽤场景组合测试系统的性能是否满⾜⽣产性能要求。如以实际投产结构测试，求出最⼤的吞吐量与最佳回应时间以保证上线的平稳，安全等。*Configuration testing(配置测试)：通过测试找到系统各项资源的最优分配原则。*Concurrency testing（并发测试）：测试多个⽤户同时访问同⼀个应⽤、同⼀个模块或者数据记录时是否存在死锁或者其他性能问题。*Stress testing （极限测试）：测试系统在⼀定饱和状态下，例如CPU、内存在饱和使⽤饱和情况下，系统能够处理的会话能⼒，以及系统是否会出现错误。*Volume testing （容量测试）：测试系统能够处理的最⼤会话能⼒。*Reliability testing （可靠性测试）：通过给系统加载⼀定的业务压⼒（例如资源在70-90%的使⽤率）的情况下，运⾏⼀段时间。*Failover testing （失败测试）：对于有冗余备份和负载均衡的系统，通过这样的测试来检验如果系统局部发⽣故障⽤户是否能够继续使⽤系统，⽤户将受到多⼤的影响。在CS/CSS系统下实际的性能测试中，需要根据具体情况进⾏性能测试类型的选取和组合。1.3.5CS/CSS系统下性能测试的组成部分通常在⼀个CS/CSS系统中，分为⽤户界⾯层、服务逻辑层和数据服务层等⼏个层次，分别对应着客户、应⽤服务器、数据库服务器。如在⾦融⾏业应⽤中，客户端承载着柜⾯业务，部署在⽹点（包括字符柜员或图形柜员），还包括部署在⾃助设备上⾯的⾃助业务等；应⽤服务器上⾯主要是起到路由功能、业务处理功能、和渠道整合的作⽤；⽽核⼼业务处理系统包括交易平台、业务逻辑、核⼼处理、数据处理等。由于业务逻辑分布在不同的环节，导致系统的内部接⼝多，性能瓶颈多，⽽系统的整体性能往往取决于最差的部分。所以对于整个系统的整体性能的测试可能需要针对各个环节分别做好各⾃的内部性能测试。如下⾯的⼀个CS/CSS系统⾦融⾏业应⽤的例⼦：为了测试整个系统的性能，需要预先针对各个组成部分进⾏内部性能测试，如后台主机的压⼒测试、SNA gateway的压⼒测试、⼤前置系统的压⼒测试、前端系统的压⼒测试、外系统接⼊的压⼒测试等等。在本次进⾏的内部压⼒测试中，为了排除系统其它部分的影响，均需要隔离各⾃的部分，驱动和桩都使⽤软件测试⼯具或⾃⾏编制程序来代替。在每个部分的内部压⼒测试中，⼜均可以根据具体情况使⽤上⼀节说明的各种性能测试类型进⾏性能测量。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万次/天。每秒的请求数量为：（*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笔/秒送达主机的吞吐量，才可能使整个系统满负荷运转。考虑到其它层次类推。由于主机以外还存在其它服务系统，所以在前置机的压⼒上⾯加了⼀个“X”代表其它服务系统要求的压⼒。当某个层次的设备短缺，⽆法实际上达到其分解下来的压⼒时，往往需要使⽤软件⼿段，在上⼀层次上直接加压⼒解决。3. CS/CSS系统架构中的性能测试的规划与实施要点3.1 测试计划中的⼈⼒资源计划由于性能测试时软件测试领域⽐较复杂的类型，所以性能测试计划中⼈⼒资源的计划也⽐较重要。要充分考虑到测试组织、测试程序的编写、测试设计、实现和执⾏、测试报告等等各种⼯作任务的⼈⼒资源需求情况。⼀般情况下，⼀个⼯程类项⽬的性能测试⼯作由如下⾓⾊和职责：*测试分析师：负责分析测试策略、编写测试计划、制订测试⽅案、组织测试；*测试⼯程师：测试例设计、实现；环境协调；对测试结果进⾏分析，编写测试总结报告。*测试员（通常也可测试⼯程师兼任）：测试执⾏；对测试过程进⾏记录，收集、整理测试记录数据。*软件⼯程师（有时由测试⼯程师兼任）：负责编写、调试客户端测试软件和模拟软件；数据库管理系统的安装、ofs配置及系统的预埋数据准备。*系统⼯程师（有时由测试⼯程师兼任）：负责测试⽤的硬件维护及操作系统安装、配置。*上级测试负责⼈：负责对测试计划及测试总结报告进⾏批准。*客户：必要时可参加测试，并提出具体的测试要求；可要求暂停测试；重要测试结论要签字认可。3.2 为项⽬选择适合的测试⼯具在性能测试过程中，⼀定要有适合的测试⼯具⽀持。性能测试所使⽤的测试⼯具包括：负载模拟类⼯具性能测量类⼯具系统级测量⼯具：CPU、内存使⽤率统计统计类：响应时间、吞吐剖析类：代码级测量⼯具，例如统计函数调⽤次数对于测试⼯具，每个具体项⽬的需求是有差异的，不存在通⽤解决⽅案。⽽且，⼯具的引⼊需要时间、资⾦和⼈⼒的投⼊。测试⼯具的选择需要考虑性能测试中被测系统的需要，以及测试⼯具需要完成的功能。⼀般情况下的选择⽅案包括：*真实⽣产系统*商⽤压⼒测试⼯具*定制压⼒测试⼯具第⼀种选择限于资源以及准确性等因素在压⼒测试中⼀般不采⽤，这⾥不再讨论。对于后两种选择的取舍主要考虑的因素包括：*是否能够满⾜压⼒测试中作为模拟程序、负载模拟的需要*是否能够提供详细，准确的性能测量数据*测试⼯具在成本的限制因素，包括时间和⾦钱*测试组对测试⼯具的掌握程度有很多很好的⾃动化的性能测试⼯具。如：MI的Loadrunner、MI的Astra LoadTest、Empirix的E-load、Rational TeamTest等等。其中⼜以MI的Loadrunner最为著名和常⽤。有时在性能测试过程中也会采⽤⾃编的或定制的压⼒测试⼯具的⽅案，主要基于如下的原因：⾸先、由于被测系统本⾝的特点，满⾜模拟程序需要的商⽤测试⼯具难以寻觅，即便是有靠近这⽅⾯需求的测试⼯具，考虑到费⽤以及培训时间的因素，也会增加测试过程的风险。其次，有时由于相关技术的成熟，选择定制压⼒测试⼯具的⽅案⽆论在设计，实现，还是在测试⼯具的掌握上都不存在不可控的风险；并且在测试过程中随时满⾜测试需要的及时性⽅⾯，定制的测试⼯具也有⽆可⽐拟的优势。最后、考虑到将来前置系统的产品化，对该系统进⼀步测试的需要会持续很久，定制的测试⼯具可以更好，更完善地满⾜这种需求。同时，对于与对象系统采⽤同样系统架构的项⽬都可以借鉴此定制测试⼯具的思想，快速地建⽴新的测试⼯具。3.3 测试准备⼯作性能测试的准备⼯作，可以包括测试数据的准备、测试⼯具准备、测试环境准备、试执⾏等部分。3.3.1测试数据的准备对于⾏业应⽤，尤其是⾦融⾏业应⽤，测试数据的准备中最重要的就是交易的选取。交易的选取有如下原则：内部压⼒测试：尽量选取⼏个最消耗系统资源的交易，并覆盖所有的交易形态（如会话式、批量式、异步式之类），这样才有可能最⼤限度的检查出该部分的性能瓶颈；整体联合压⼒测试：由于⼀般整体联合压⼒测试需要完全模拟实际⽣产情况，所以交易的抽样选取相对⽐较复杂。通常需要进⾏当前交易量的收集和预测性能测试交易量，更重要的是确定交易发送⽐例的分布。如⼀个实际⾦融项⽬的交易发送⽐例的分布：先选取实际原始发送⽐例中前50位的交易。然后将其所有⽐例数相加（⼀定⼩于1），做为新的基数，分别于各个交易的原始⽐例相除，即可得到使⽤⼯具模拟发送的⽐例。此外，主要实际交易数据的获得通常要从数据库中使⽤脚本提取出来；还有可能需要⾃⼰利⽤某些规则⾃造⼀些数据。3.3.2测试⼯具的准备通常，要为测试⼯具的编制和学习使⽤预留充⾜的时间。对于商⽤的测试⼯具，通常需要进⾏脚本的录制和修改，场景的设定⼯作；对于⾃编⼯具，要有设计、编码过程。⽽且，它还通常有其⾃⼰的配置⽂件和使⽤的数据⽂件，需要进⾏配置或数据格式转换。3.3.3测试环境准备这⾥需要注意的问题是，可能在后台（充当桩的）数据库中需要⽣成预埋测试数据，要保证其⾜够且可重复⽣成或容易清理。另外测试环境准备好了以后，每次执⾏前的检查环境过程也是⾮常重要的，可以避免⼤量的⽆⽤功。4. 性能测试报告4.1 测试结构数据的整理和分析测试报告⽂档的撰写1． 测试中应该⽣成的测试⽂件测试记录（测试负责⼈和参与测试的⼈员签字）；测试总结报告。2． 测试总结报告中⼀般必须包含的内容被测试软件名称、测试项、测试环境；被测试软件的压⼒测试结论：响应时间、最⼤/最⼩并发数、失败的次数、正常连续运⾏的最长/最短时间，并发数与失败的关系等总之必须包含预先定义的关键性能指标的数据、变化曲线分析和结论。5. CS/CSS系统架构下性能测试中需要注意的问题5.1 注意中间件的license、数据库的⽤户数等影响因素有时候测试结果没有达到预期并不⼀定是被测对象的问题，可能是中间件的license不⾜或者是使⽤的数据库系统的并发⽤户数的限制导致，有时还因为配置项有问题等，需要综合分析。5.2 数据聚集问题性能测试中选⽤的数据应该在差异上进⾏分散，与实际⽣产数据的随即差异分布相似，充分测试系统在不同数据下的状态。如果使⽤较单⼀的数据进⾏测试，⼀⽅⾯可能使系统的局部功能没有被使⽤，导致性能测试数据不可靠；另外，如果系统对于同样的数据处理有优化处理功能，也导致性能测试数据不可靠。
发布评论