银行性能测试项目小结

第一篇：银行性能测试项目小结

1、背景

本次性能测试的系统是X银行营销服务系统总行版，该系统使用的数据库服务器、应用服务器均布署在总行机房，各地分行通过 WEB 方式登录访问本系统。系统上线后的总用户数（包括各分行、支行主管，客户经理等）在 5000 左右。

该系统采用 DB2 数据库、WebLogic 应用服务器。

本次性能测试进入的条件是系统的代码已经基本完成并经过功能测试。

2、测试计划

在确定了本次性能测试的要点后，我们初步拟定一份性能测试计划，提交给客户，并获得了客户的认可。在本文中不列出项目测试计划中的所有内容，仅就主要问题进行说明。

测试范围：在真实业务局域网测试环境下，对系统实施并发性能测试的同时，监控 Web 服务器和数据库服务器的系统资源，以及数据库资源的使用情况。

测试内容：并发性能测试、系统资源监控。

测试方法与工具：采用自动测试与人工测试相结合的测试方法，测试工具使用 LoadRunner。

测试资源：测试环境及测试数据准备。

3、测试用例

确定了测试计划，我们针对该系统的特点，从中挑选出三个有代表性的功能点，作为本次性能测试的用例。我们认为作为银行的营销服务系统，最常使用且对于系统的整体性能有着较大影响的是“客户信息查询”和“客户对账单查询”两个模块。因此，我们设计了三个单交易性能测试用例，分别是：“用户签到 / 签退”、“客户信息查询”、“客户对账单查询”。然而客户却对此提出异议，他们认为我们设计的测试用例数量太少，要求我们的测试用例应包含更多的功能模块。经过会议讨论，最终我们根据客户给出的一份性能测试大纲，针对其中提出的测试内容、测试策略，以及测试目标，将单交易测试用例增加到十四个。

测试用例采用以下格式：

要求清晰地描述出详细的操作步骤。

4、测试数据

针对以上设计的测试用例，需要准备大量的业务数据。本次性能测试的环境即系统上线后真实运行的环境，所有的业务数据均来自兴业银行的真实核心系统（通过 ETL 转换），数据量已经能满足测试的需要。

由于测试用例中要求执行并发操作的时候使用不同身份的用户登录系统，因此在测试开始前需要准备一批具有不同身份的用户名（包括各分支行的主管以及客户经理），并且要有相应的操作权限。

对于“积分转移”、“积分兑换”、“礼品兑换”等等交易，则需要提供一批卡上有足够积分的客户理财卡号。

以上测试数据由兴业银行负责提供，在性能测试执行之前提供给我们。

5、测试脚本

使用性能测试工具 LoadRunner 录制并调试测试脚本，对相关的输入项进行参数化。

6、测试实施

在 LoadRunner 中执行测试脚本，实施性能测试。对于每个单交易测试脚本各执行一轮测试，并按一定的用户比例设计出一个混合交易场景，令其自动持续运行五小时左右，观察系统的性能表现。每次执行的结果文件均保存下来，待测试完成后连同性能测试报告一并交付客户确认。在此过程中，需要监视相关的系统资源使用情况，包括：应用服务器和数据库服务器的所有系统资源指标，所有数据库资源指标。

7、测试结果

经过本次性能测试，发现了系统五个主要的性能问题。我们与程序开发人员一同分析问题产生的原因，并给出改进建议，一起记录到测试报告中。其中的一个问题在性能测试报告提交客户之前已经过优化，得到显著改进。

8、测试结论

测试结果显示，系统性能能满足测试目标，交易并发数达到或超过30个，批量交易（查询记录50条以上的交易）并发数也能达到或超过10个，交易平均响应时间在2－12秒内，90％平均响应时间在2－15秒间完成。

混合交易案例持续运行 5 小时，运行结果正常，系统没有报任何错误，系统稳定，可用率应达到100％。

另外如在ETL批处理期间运行 营销服务系统，系统性能明显下降，建议ETL批处理在夜间处理，避免影响 系统的正常运行。

9、经验

在本次性能测试的过程中，我们遇到一些问题，通过解决这些问题，从中获得了一些经验。现总结如下：

问题一

在我们对系统进行测试的过程中，某些操作是相关联的。例如我们测试“查看客户资产历史” 这个交易的系统响应时间，这时需要先列出客户的基本信息，选中一个客户，点击打开另一个页面，才能查看到该客户的资产历史信息，同时，在测试脚本中需要对所选择的客户编号做一个参数化，但由于 LoadRunner 不提供像 WinRunner 或 QTP 一样识别页面对象的功能，如果在 Vugen 中直接抓取页面上显示的客户编号去参数化，实现起来将十分烦琐。考虑到在以上那两步操作中，第一步“列出客户基本信息”只是辅助的操作，而第二步操作“查看客户资产历史”才是我们要测试的功能点，因此我们忽略了这二者之间的关联性，仅对第二步操作中的客户编号进行参数化。（只要服务器端对此不加验证，甚至我们将第一步操作都忽略掉，也是可行的）。

结论： LoadRunner 的工作原理是根据所选择的协议组装成相应的报文在前后台之间通讯，以此达到模拟实际操作的目的，因此我们只需将要测试的交易或功能点所需要组装的报文传送给后台服务器即可（因为我们关注的只是系统的性能，不是功能），而不必像功能测试那样，按部就班地重现每一步操作。

问题二

在测试过程中，我们发现有一个查询交易的系统响应速度特别慢，无论是在 Controller 中使用单个虚拟用户执行脚本，还是在 Vuser 中直接运行，情况均是如此，然而当我们用手工进行同样操作的时候，响应时间却明显地小于工具统计出来的时间，也就是说，在 LoadRunner 中模拟操作的结果与真实操作的结果明显不一致。经过反复尝试与观察，我们才终于找到问题的原因所在：该查询交易是通过客户的证件号码查询客户信息，当用户输入客户的证件号码时，如果没

有选择证件类型，系统会自动将证件类型设置为默认值“身份证”。按“证件类型 + 证件号码”为组合索引查询客户信息表，查询速度极快，而在我们录制脚本时，忽视了“证件类型”这项输入，只有“证件号码”，因此查询的效率大为降低。解决办法：只需在测试脚本中，对 CertType（“证件类型”）一项赋值为“ A ”（“身份证”），此时在 LoadRunner 中重新运行该脚本，响应速度提高，统计结果与实际完全一致！

结论： LoadRunner 的工作原理是根据所选择的协议组装成相应的报文在前后台之间通讯，以此达到模拟实际操作的目的，因此我们在测试脚本中组装发送到服务器端的报文时，注意一定要和实际操作时的发送报文完全一致，这样才能保证测试的结果与真实情况相吻合。这就要求在测试正式开始执行时，要对测试脚本进行反复的调试，通常的做法是：在 Vugen 中执行一遍脚本，统计执行某个事务的时间，再用手工实际做一遍同样的操作，大体上比较一下，确保与实际估算的时间没有太大出入后，再逐渐增加并发用户数，正式开始性能测试。

问题三

在我们的每个测试脚本中的 init 部分，都录制了登录系统的操作，并且对登录的用户名进行了参数化，使用各种不同身份的用户（分行主管、支行主管、客户经理等）进行相同的操作。在并发测试过程中发现对某些查询交易测试的结果波动较大，系统响应时间从零点几秒到几十秒不等。经检查后发现原因在于：使用不同身份的用户登录系统后，在输入查询条件后，点击查询按钮后会将根据该用户的身份，将其所属的分行机构号、支行机构号、客户经理编号等一并提交，因此在脚本中，就必须根据不同的用户身份，分别将其对应的分支行机构号等也运用参数提交，否则在执行脚本时就会出现查询不到记录或查询速度变慢等各种问题。解决方法有三个： 1、修改脚本，使其能够依据用户的身份分别传送相应参数，2、针对不同类型的用户使用不同的脚本分别测试。3、输入参数使用统一的用户类型。在实际中，我们为了简化脚本的复杂度，节省对脚本编程的时间，采取的是第三种方法。

结论：由于 LoadRunner 的工作原理是根据所选择的协议组装成相应的报文在前后台之间通讯，因此它会跳过在应用程序前台进行的校验，所以在脚本回放的时候一定要注意在脚本中提前进行这些校验或改由人工控制，以保证发送报文的正确性（如操作权限的控制等）。

问题四

测试多用户并发登录系统的时候，从虚拟用户图和事务图上发现，总有一部分用户在登录的时候要等待很长时间，用户登录的最小时间与最大时间相差非常大。于是我们在让脚本自动运行的同时，手工再登录一个用户，发现无论如何都不会发生等待的情况，多次试验的结果均是如此，也就是说 LoadRunner 测试的结果与实际结果再次发生了偏差！经过反复的调试，以及与程序开发人员沟通，我们终于发现问题的原因所在：在用户登录系统的时候，系统会自动记录登录用户的信息，并产生一个登录 ID，以此 ID 做为主键，向数据库插入记录。因此当大量用户在极短的时间内同时登录时，就有可能出现生成相同的登录 ID 的情况，此时便会造成数据库中的主键冲突，导致用户等待很长时间或登录失败。而我们手工测试时却无法做到在很短的时间内同时登录，因此很难用手工重现此种

情况。通过 LoadRunner 的模拟表现出来的状况，正是我们测试出程序存在的性能问题，并非与实际结果的偏差。

还有一个例子，在第二轮性能测试中，同样发生了类似的情况。在本系统中，如果同一个用户登录后，未正常退出超过 5 次，系统将会把该用户锁住，使其无法再次登录，而我们用于参数化的用户名个数有限，因此当脚本使用大量用户同时登录时，很容易造成同样的用户登录系统而未签退的情况发生（脚本正在执行，还未能退出），此时将会造成许多用户操作的失败。

结论：使用 LoadRunner 可以模拟出大量用户同时对系统操作的情况，而这些情况通过手工往往是很难重现出来的。例如大量用户在同时对系统做某些操作时，很容易造成数据库的死锁、锁等待、主键冲突、数据混乱等等问题，因此在做性能测试的同时，也常常可以连带测试出系统的一些隐蔽的“缺陷”。在本次性能测试中，这种例子是很多的。对待此类“缺陷”，应具体情况具体分析。有些确实是程序的 BUG，需要修正，而有些可能只是很极端的情况，只有在做压力测试时才有可能发生，可不必深究。

问题五

此问题发生在第二轮测试（即回归测试）中。在第一轮测试中发现的性能问题，经程序员修正后，我们对系统进行了第二轮性能测试，以验证其性能改进的效果。在前一轮测试中，我们发现通过选择客户级别为“未评级”时，查询的速度极慢，经过改进后，速度应有较大提高。然而在回归测试中，却依然很慢。经过对测试脚本和程序的仔细检查，才发现原来在程序中已将“未评级”这个选项去除，而我们的测试脚本的参数文件中仍然保留有该选项，因此测试的结果与前次没有区别。在参数文件中将该选项去掉后，测试结果正常，查询效率有所提高。

结论：使用录制好的测试脚本进行回归测试之前，一定要先仔细检查、了解程序的改动，对原先的测试脚本做必要的修改后，才可以重新测试，否则只是在做无用功。

10、教训

在本次测试过程中，由于经验不足，我们也得到了一些教训。前事不忘，后事之师，现总结出来与大家分享。

l 与客户的沟通做得不够，客户要求我们做的性能测试用例数量太多，我们未能据理力争，最后导致工作量过大。

l 按照原定的项目计划，我们要在系统的功能测试即将结束前进驻项目组，准备并进行性能测试。然而由于客户在功能测试的后期仍然不断的提出新需求，导致开发人员疲于奔命，系统的性能难以稳定下来，性能测试的前期准备工作也受到很大影响，不能正常开展，浪费了很多人力物力。

l 由于客户无法提供一个单独的性能测试环境，我们的性能测试工作与业务组的功能测试在同一个环境下进行，而系统的功能测试迟迟未能完成，加上 ETL（数据转换）小组对数据库资源的占用，因此我们的性能测试只能在夜间才能进行。导致时间上的浪费，使项目的成本增加。

l 没有将性能测试中发现的缺陷记录到缺陷管理工具中加以跟踪，而仅仅体现在最后的测试报告上，个人认为这是比较不规范的做法。

l 性能测试前的数据准备不够充分。客户提供测试的系统用户、身份数量有限，导致许多案例的测试只能使用少量数据进行参数化，由此带来许多本可以避免的问题。

l 测试计划及测试报告的书写格式缺乏规范，尤其测试计划书未能包含本应包含的所有内容。

l 在我们将 LoadRunner 的测试结果文件全部提交给客户的前提下，客户仍然要求我们在测试报告中将每一次测试的数据均以表格的形式填至测试报告中，此项工作的工作量十分巨大，个人认为这样做并无必要。

以上是在本次性能测试及回归测试过程中总结出来的一些经验教训，在此做一个小小的总结，以便下次工作中改进。

第二篇：喷漆性能测试

6.4 喷漆性能测试（样品数量：每种颜色6套外壳）

试验条件：物理测试需要在注塑完成，产品放置72小时以后进行，化学测试则需6天以后。喷涂干燥 硬化后应在常温下放置48小时以后再进行试验。

试验方法：

1）把滤纸放于酸性（PH=2.6）溶液中充分浸透；

2）用胶带将浸有酸性溶液的滤纸分别粘在两套喷涂样品表面，确保滤纸与样品喷漆 表面充分接触，将样品放入试验箱。

3）测试时间以试验箱达到所需温湿度条件时开始计算。在24小时与48小时分别取 出一套样品，揭下滤纸，并放置2小时后，检查样品表面喷涂。

检验标准：样品表面无变色、起气泡、起皮、脱落、褪色以及其他与测试前状态不一致的现象。

6.4.5 镜面划伤测试

测试环境：室温（20~25° C）；

测试目的：验证镜面耐硬物划伤性能的可靠性

样品数量：不少于2个

试验方法：将实验样品固定在划伤试验机上，接触部分为直径为1mm的碳化钨球，硬度为90.5～ 91.5，用载重（load）为500g的力在样品表面往复划伤50次，划线速度为3～4cm/秒，接触部分与被测面成90度角，对样品的X和Y轴两个轴向进行测试。每10次对镜面进行外观检查，并对镜面表面进行清洁。检验标准：镜面表面划伤宽度应不大于100μm（依靠目视分辨、参照缺陷限度样板）

6.4.6 紫外线照射测试

测试环境：50° C

测试目的：验证喷涂抗紫外线照射的可靠性

样品数量：不少于1套壳体

试验方法：在温度为50° C，紫外线为340W/mm2的光线下直射油漆表面48小时。

试验结束后 将手机外壳取出，在常温下冷却2小时后检查喷漆表面。

检验标准：印刷、电镀无褪色、变色、纹路、开裂、剥落以及与测试前不一致的现象。

6.4.7盐雾测试

测试环境：35° C

测试目的：测试样机抗盐雾腐蚀能力

试验方法：a.溶液含量：5%的氯化钠溶液b.将手机关机放在盐雾试验箱内，合上翻盖，样机用绳子悬挂起来，以免溶液喷洒 不均或有的表面喷不到。c.样机需要立即被放入测试箱。实验周期是48个小时。实验过程中样机不得被中途 取出，如果急需取出测试，要严格记录测试时间，该实验需向后延迟相同时间。d.取出样机，放置48小时进行常温干燥，对其进行外观检查。

检验标准：外观检查无异常：表面喷涂、丝印、电镀、装饰件、标牌等无脱落、起泡、腐蚀以及与测试前不一致的现象。

试验环境：温度20~25度，湿度65＋/-20% 6.4.1 耐磨测试测试环境：室温（20~25° C）；测试目的：喷涂/印刷等抗摩擦性能的可靠性 样品数量：不少于1套壳体

试验方法：将最终喷涂的手机外壳固定在RCA试验机上，用175g力队同一点进行摩擦试验。对于表面摩擦300cycles，侧面和侧棱摩擦150 Cycles。特殊形状的手机摩擦点的确定由测试工程师和设计工程师共同确定

检验标准：对于喷涂、电镀、IMD等，涂层不能脱落，不可露出底材质地；对于表面印刷类，印刷图案、字体不能出现缺损、不清晰现象。

6.4.2 附着力测试

测试环境：室温室温（20~25° C）；高低温箱

测试目的：喷涂附着力测试

样品数量：不少于1套壳体

试验方法：选最终喷涂的手机外壳表面，使用百格刀刻出25个1mm2方格，划线应深及底材；使用毛刷将划线处的喷漆粉屑清除干净；再用3M610号胶带纸完全粘贴在方格面，1分钟后迅 速以90度的角度撕下胶带，检查被测区域表面。

检验标准：有涂层脱落的方格数应不大于总方格数的3%；单个方格涂层脱落面积不大于单个方格总面积的50%。

6.4.3 硬度测试

测试环境：室温（20~25° C）；

测试目的：表面喷涂硬度的可靠性

样品数量：不少于1套壳体

试验方法：将铅笔芯削成圆柱形并在400目砂纸上磨平后，装在铅笔硬度测试仪上，以500g 的力度，铅笔与水平面的夹角为45度，在样品表面从不同方向划出30~50mm长的线条3~5条。对于喷漆表面的硬度标准为2H（三菱牌），500g的载荷；对于Lens表面的硬度标准为3H（三菱牌），500g的载荷；每划完一次都应将铅笔磨平。

检验标准：用橡皮擦去铅笔痕迹，目视喷漆、印刷、电镀、Lens表面无划痕。

6.4.4 汗液测试

测试环境：60° C，95%RH

测试目的：表面抗汗液腐蚀的能力

样机数量：不少于2套

注：部品由于使用场所、材质、色泽等有特殊要求时可以考虑采用其他标准。

7.2 整机状态下的可靠性试验

温度冲击测试（Thermal shock）

测试环境：低温箱：-40° C ；高温箱：+80° C

试验方法：将手机设置成关机状态放置于高温箱内持续30分钟后，在15秒内迅速移入低温箱并持续30分钟，为一个循环，共循环27次。实验结束将样机从温度冲击箱中取出，并在 室温下恢复2小时，进行外观、机械和电性能检查。

试验标准：手机各项功能正常；外观检验：壳体表面喷涂、丝印、电镀无气泡、褶皱、裂纹、起皮、脱落；装饰件无翘起、脱落以及其他与测试前状态不一致的现象。跌落试验（Drop Test）测试条件：1.5m高度，20mm大理石板。

试验方法：将手机处于开机状态，进行6个面的自由跌落实验，每个面的跌落次数为1次，跌 落之后进行外观、机械和电性能检查。对于翻盖手机，在跌翻盖一面时，应将一半样品合上翻盖跌，一半样品打开翻盖跌。

试验标准：手机各项功能正常；

外观检查：壳体表面无明显掉漆，无裂纹、破损、冲击痕以 及其他与测试前不一致的现象。振动试验（Vibration test）

测试条件：振幅：0.38mm；振频：10~30Hz；振幅：0.19mm；振频：30~55Hz；

试验方法：将手机开机放入振动箱。X、Y、Z三个轴向分别振动1个小时之后取出，然 后进行外观、机械和电性能检查。

试验标准：振动前5分钟内手机内存和设置没有丢失现象，后55分钟可以出现关机现象，手机各项功能正常，尤其是显示和SPL，外壳无严重损伤（如掉漆），内部元件无脱落。

湿热试验（Humidity test）

测试环境：60oC，95%RH

试验方法：将手机处于关机状态，放入温度实验箱内的架子上，持续60个小时之后 取出，恢复2小时，然后进行外观、机械和电性能检查。

试验标准：手机各项功能正常；外观检查：外观测试无异常（壳体、Lens表面无裂纹、气泡；Lens 无被腐蚀现象；金属、电镀壳体或装饰件无变色、腐蚀，以及无其他与测试前不一致的现象）。

高温/低温参数测试（Parametric Test）

测试环境：-10oC/55oC

试验方法：将手机处于开机状态，放入温度实验箱内的架子上。持续2个小时之后(与 环境温度平衡)，然后在此环境下进行电性能检查，检查项目见附表1。

试验标准：手机电性能指标满足要求，功能正常，表面喷涂、电镀无裂纹等。高温高湿参数测试（Parametric Test）

测试环境：+45oC，95%RH

试验方法：将手机处于开机状态，放入温度实验箱内的架子上。持续48个小时之 后，然后在此环境下进行电性能检查。

试验标准：手机电性能指标满足要求，功能正常；结构检查：装饰件、Logo及机壳 等无脱落，壳体卡钩无脱出、断裂，外壳无变形；

外观检查：壳体表面无明显掉漆，无裂纹、破损、冲击痕以及其他与测试前状态不一致现象。高温/低温功能测试（Functional test）

测试环境：-40oC/+70oC

第三篇：性能测试工程师心得

高级性能测试工程师培训心得

--税务事业部 魏琳

从中国的软件现状来看，各式各样的软件层出不穷，但是好的却并不多，能够走向国际的更是少之又少。中国的软件要想与国际接轨，就必须要完善自己的软件产业，使软件产业走向正规化、国际化，从而更加完善自己的软件产品，这就使软件测试工程师的人员缺口很大。很多人认为软件测试无非就是找错误，挑程序员的毛病，仅此而已，其实不然，测试并不只是单纯的挑刺，更多的意义是在辅助程序员，让程序员的程序更加完美，让公司的产品能够更稳固的占据市场，尤其是现在这个软件行业竞争异常激烈的时代，只有公司的产品站住了脚，公司才会有更多的效益产生，只有公司有了效益，员工才会领到更多的工资，这样公司才能长久的生存下去，而帮助产品能够更坚牢的站住市场的，就是软件测试人员。

这次有幸参加公司组织的为期五天的高级性能测试工程师的培训，虽然课程紧密，内容繁多，但是我却乐在其中，受益匪浅。借此机会与大家分享一下我这几天以来的学习心得：

首先，知识日新月异，不学则惘。在当今这个信息高速传递的社会，不难感受到知识爆炸的巨大威力，特别对于我们IT行业，更加深刻体会到什么叫做“日新月异”，更加深刻认识到，先进的知识与技术是一个企业立于不败之地关键因素。但是对于已经步入社会的我们，已经远离校园的我们，现在的学习缺乏系统性，往往不能自觉主动地抽出时间，静下心来学习，常常是需要什么，急用什么，才想起来学什么，遇到问题才翻理论、寻政策，临时抱佛脚，学习缺乏“挤”劲和“钻”劲，浅尝辄止，通过这次培训，使我在老师那里学到了当今最流行的测试技术以及测试管理，当然这只是其次，最重要的是在同行中营造了浓厚的学习氛围，大家互相取长补短，分享工作中遇到的各种问题，与老师讨论如何提升自己的价值。知识就是力量，知识就是本钱，我们应该以这次培训为契机认真学，努力学。

其次，责任重于泰山，无为则殆。做而不学等于蛮干，学而不做等于白学。我们学习的根本目的就是要用所学的知识来指导我们做事。通过这次学习，我更清楚地感到自己肩上责任的重大，无论我们从事哪种行业，无论我们身兼何职，责任心、使命感和进取心是我们一辈子不能舍弃的东西。通过这次学习，使我感觉到学习的重要性和紧迫性，我们学习的自觉性、主动性、积极性得到了激发，把所学的知识应用到自己的岗位当中，提升自己的价值，当我们付出艰苦劳动得到的产品传递的客户那里，获得的是一份肯定，一份赞赏时，我们才可以如释重负，我们的努力才没有白费。

最后，学以致用，做好本职工作。通过五天的学习，使我的理论水平、知识素养都有了很大的提高，但归根到底还是要把工作做好。NO excuse！不为失败找借口，要为成功找方法。我们在工作中要完成一项工作，往往会碰到这样那样的问题和困难，如何正确的对待这些问题和困难?没有任何借口，只有千方百计地寻找解决问题、克服困难的办法。

北京学习虽然短暂，但是我们从中获得的东西却是受益终生的！

第四篇：性能测试学习总结

性能测试学习总结

一、明确性能测试的范围

例如：以iptv系统为例，是需要测试bss页面、中间件具体接口、boss/crm具体接口

二、明确性能测试的指标 例如：

1、支持最大并发用户数是多少？（压力测试）

2、每秒n个用户并发，能正常持续运行多久？（负载测试）

3、在系统用户为n个的情况下，每秒x个用户并发，持续运行y分钟，查看系统硬件io、cpu、内存；查看软件平均吞度量、tps、平均响应时间、事务成功率、事务失败率、错误率等（性能测试）、响应时间：事务从开始到完成所花费时间

平均吞吐量：指单位时间内系统处理用户的请求数

TPS：transaction per second 服务器单位时间处理的事务数（事务数/运行时间s）

事务：指访问并可能更新数据库中各种数据项的一个程序执行单元。例如订购操作，它含有多个请求

事务成功率：成功事务数占完成总事务数的比率 事务失败率：失败事务数占完成总事务数的比率

三、定义数据模型

1、目标系统用户数、目标每秒并发数、硬件系统配置情况，如下：模板

IPTV-BSS 性能指标.docx

四、设计性能测试方案

IPTV BSS四川电信版本性能

五、搭建性能测试环境

1、尽可能模拟现网的环境与组网结构

2、前台应用和后台数据库安装在独立干净的服务器上。

3、当前性能测试环境分别为：192.168.12.11（前台）192.168.12.31（数据库）192.167.12.177（Loadrunner）

六、构造性能测试数据

1、使用LR、QTP自动化工具构造（比较慢，不需要了解表结构，但是需要了解业务流）

2、编写存储过程构造用户、包月、订购数据（比较快，需要对相关表结构和数据库了解）

七、录制、调试测试脚本

1、中间件接口目前是web services协议，因当前测试指标均超过100个并发，故使用web（http/html）协议录制。中间件接口录制页面：

2、boss接口当前有两种协议，一种是web services协议，一种是sockets协议，因当前测试指标最大为100个并发，故可以使用web services协议或http/html协议录制。

3、bss页面基于ie运行，故使用web（http/html）协议录制。

注明：当前中间件接口，四川boss接口，浙江电信bss部分页面均有现成的脚本，如果其它局点需要测试可使用原有的脚本调试即可。

详细参考：LoadRunner性能测试_刘双林_20110115.doc

2.3/2.4章节 进行学习

八、执行性能测试场景

1、按照测试方案文档中的测试用例执行即可。

2、在执行性能测试过程中会具体使用到性能测试工具LR。关于性能测试工具的使用方法网上有大把资料。请自行学习：场景设置、参数化等

详细参考：LoadRunner性能测试.doc

3章节 进行学习

九、监控并记录性能测试结果

1、硬件性能：bss应用服务器cpu、内存；数据库服务器cpu、内存、io 内存、cpu 不高于70% ；IO不高于80% 否则可能存在性能瓶颈 统计方式：

（1）通过命令在服务器上查询

内存 sar-r 5 120

（每5s刷新1次共刷新120次）cpu sar-u 5 120 io

iostat 5 120（2）在服务器上安装rpc.rstatd工具，通过LR客户端窗口监控记录

2、软件性能：平均吞度量、tps、平均响应时间、事务成功率、事务失败率、错误率等（场景运行完毕可通过loadrunner工具导出性能测试结果），是否达标是要与性能测试指标进行比对。

详细参考：LoadRunner性能测试.doc

4章节 进行学习

十、分析性能测试结果输出总结报告

1、将实际测试结果和性能测试指标进行对比，总结出不达标测试对象及具体测试数据

2、测试与开发人员根据性能测试数据，从硬件环境和软件本身进行分析。例如：优化硬件配置、软件处理逻辑、数据库架构脚本等。

3、具体分析的方法：一般是具体问题具体分析，查找瓶颈时按以下顺序，由易到难。（1）服务器硬件瓶颈

（2）网络瓶颈(对局域网，可以不考虑)（3）服务器操作系统瓶颈(参数配置)（4）中间件瓶颈(参数配置，数据库，web 服务器等)（5）应用瓶颈(SQL 语句、数据库设计、业务逻辑、算法等)注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力(并发用户数、数据量)下，系统的硬件瓶颈在哪儿就够了。

十一、LoadRunner性能测试工具操作文档

LoadRunner性能测试.doc

loadrunner8.1教材.pdf

第五篇：锅炉性能试验小结

培训小结

本次培训内容是电站锅炉燃烧调整、性能试验及运行相关问题的探讨，培训时间2016年11月1日至2日，授课内容主要包括锅炉燃烧调整试验、冷态动力场试验、电站锅炉性能试验、煤质对锅炉运行的影响。最后并讲解了一个超超临界机组实例。

本次培训以PPT课件形式由浅入深进行理论授课，内容详细，重点突出，岗位人员学习的积极性提高明显，印象深刻。

以课件形式讲解各知识点时，有疑问，培训课上大家可以进行探讨，发散思维，丰富专业知识。对于新来的同事，尤其是非本专业的同事来说，可以加深印象。

培训课上现场讲解流程，非本专业的同事可以很快熟悉现场工艺系统和设备工作特性，同时在讲解流程的同时顺便加入了一些设备的工作原理，结构及运行特性，效果很好，尤其是新同事，容易理解，记忆深刻。培训课上也播放了一下视频，让大家更直观的了解相关内容，并结合现场作业情况学习了一下监护知识，提高专业和安全知识。这对于非本专业员工来说，非常重要，学习作业监护是提高他们专业知识和安全知识最快最好的方法。通过此次培训，让科晨公司所有员工系统的学习了锅炉燃烧调整试验、冷态动力场试验和电站锅炉性能试验。使得非锅炉专业人员也更快更好的熟悉锅炉试验，下一步更好的参与并完成锅炉相关试验。