电泳漆性能测试标准

电泳漆性能测试标准（精选6篇）

篇1：电泳漆性能测试标准

loadRunner性能测试 1.什么是性能测试

软件的功能：对一个软件基本功能能够实现，比如：银行卡能够正常转账成功（用户数=1）软件的性能：要求软件性能更好，一般关注多用户的使用情况，软件的响应时间。响应时间例子：登录一个软件，点击“登录”按钮时，多久能够显示成功登录的页面。

性能问题: 1． 每秒平均浏览量：2200次/秒

浏览量（PV，Page View）：即页面访问量或点击量，用户每次刷新即被计算一次 购票申请：20万张/秒以上

自身设计浏览量100万次/小时 浏览量280次/秒

2.响应时间的358原则：

3秒之内，客户比较满意 5秒之内，客户可以接受 8秒之内，客户可以忍受 大于8秒，无法忍受

3.一般进行性能测试之前，要对系统尤其是数据库进行备份

负载测试是一种

正常 的测试（在正常测试的指标下测出最大的负载量）

指标或者某种资源达到某种指标，比如响应时间达到多少，比如CPU负载100%等

压力测试和负载测试二者的区别：

负载测试强调系统在正常工作情况下的性能指标

压力测试的目的是发现在什么条件下系统的性能变得不可接受，发现应用程序性能下降的拐点

影响系统性能的主要因素

（1）硬件： CPU,内存，硬盘，网卡及其他网络设备【最好解决】（2）操作系统（3）网络

（4）中间件（又叫应用服务器），web服务器（5）数据库服务器（6）客户端

（7）变成语言，程序实现方式，算法【最难解决】

客户端=服务端（Web服务器）=应用服务器=数据库服务器

性能测试主要关心两个部分：web服务器和应用服务器。客户端向服务器发送请求

服务器端向客户端返回应答（响应response）

性能测试的常用术语： 并发（Concurrency）：所有用户在同一时刻（一个时间点，可以精确到毫秒级）做同一件事情或操作，一般针对同一类型的业务

例如：在信用卡审批业务中，一定数目的用户在同一时刻对已经完成的审批业务进行提交 做并发的测试就称为“并发测试”。【发测试不包含睡眠时间】 在线（OnLine）：多用户在一段时间内对系统执行操作【包含睡眠时间】

并发测试与在线测试对系统的压力不同，一般来讲并发测试的压力和在线测试的压力的比值是10:1。例如：200用户并发测试相当于2000用户在线测试。

并发测试一定是多用户。

请求响应时间

指从客户端发送一个请求开始计时，到客户端接到从服务器端返回的响应结果计时结束。在一些工具中，请求响应时间通常被称为TTLB 即“Time to Last Byte”，意思是从开始发送第一个请求开始，到客户端收到最后一个字节的响应为止所耗费的时间。请求响应时间的单位一般为“秒”或者“毫秒”

再复杂的响应时间都可以分为3段：请求的响应时间=客户端的响应时间+网络的响应时间+服务器的响应时间

一般测试放在内网里，带宽，网络不会成为瓶颈。只用分析客户端的响应问题和服务器的响应问题。一般客户端的响应很少有问题，一般只分析服务器响应问题即可。

事务响应时间：用户完成某个具体事务（如跨行取款事务）所需要的时间。事务可能包含多个请求。比如点击“登录”按钮，到登录进页面。

事务的响应时间和请求响应时间的区别？

一个事务包含一个或多个请求（一般，一个请求指的是一个http请求）。

点击率：

每秒钟用户向web服务器提交的http请求数。---点击率越大，对服务器的压力也越大

---注意：点击不是指鼠标的一次“单击”操作。因为在一次“单击”操作中，客户端可能向服务器发出多个HTTP请求（比如跳转页面需要更新展示图片等）。

点击量的计算：假如单击“登录”按钮，请求一个页面登录后的欢迎页面中包含3个图片，则每个图片都需要重新发送一个http请求，所以，单击鼠标一次产生的http请求总数为4=1（登录请求）+3（图片请求）点击率=点击量/时间

吞吐量：

用户在任意给定一秒从服务器端获得的全部数据量，单位是字节 吞吐量/传输时间=吞吐率

吞吐率很重要，反应了服务器的处理速度和性能，也是衡量网络性能的重要指标。TPS（事务数/秒）

在性能测试过程中，要监控服务器系统的各项资源情况，比如：CPU，内存，磁盘及网络等情况。

吞吐率和点击率的区别：

吞吐率：指服务器每秒处理的数据量。反应了服务器的处理能力，吞吐率越大，服务器处理能力越强。

点击率：客户端每秒向服务器发送请求的数量。反应了服务器的压力，点击率越大，服务器的压力越大

吞吐率受点击率影响，也受服务器性能的限制。

完美的吞吐率是：在带宽充足的情况下，吞吐率随着点击率的增加而增加。

资源利用率

指对不同的资源系统的使用程度，包括web服务器，操作系统，数据库服务器，网络，硬件，是测试和分析瓶颈的主要参数

-如：服务器cpu利用率，磁盘利用率等

它是分析系统性能指标进而改善性能的主要依据，因此是web性能测试工作的重点。

性能测试的策略（即方法）：重点测试方法：基准测试，并发测试，综合场景测试，疲劳强度测试，极限测试，递增测试

基准测试：一般做的是单用户测试（Benchmark Testing）

----指测试环境确定以后，对业务模型中涉及的重要业务做单独的测试。

----目的是获取单用户执行时的各项性能指标，为多用户并发和综合场景等性能测试分析提供参考依据。

并发测试：就是多用户的并发测试某个测试点。并发测试对系统要求比较严格，因为要模拟一个瞬间压力。并且要忽略系统的睡眠时间（思考时间）。

递增测试：

A）指每隔一定时间段（如5秒，10秒）加载不同数目的虚拟用户执行测试点操作，对测试点进行递增用户压力加载测试。原因：所有用户（5000）共同登陆可能会导致系统压力过大，进而影响到后面关心的测试点（buy）的性能，导致关心的测试点结果不准确，所以采取递增，分散一下前面的压力，使系统关心的测试点能够正常的测试。（这里是递增着登陆）B）测试一个测试点（如：购票），先测试单用户，再测试20用户，40用户等情况，有利于分析，也称为递增测试。（这里是递增着全套测试）

综合场景测试【重难点】：

通过对系统结构和功能的分析，对用户的分布和使用频率的分析，来构造系统综合场景的测试模型，模拟不同用户执行不同操作。

如10%的用户执行浏览首页，50%的用户执行查询订单，40%的用户执行订购机票，最大限度地模拟系统的真实场景，使用户预知系统投入使用后的性能水平。没特别指明的话，一般都是指在线的。

Login不适合放在综合场景中运行。

综合场景：号称能最真实的模拟实际的生产环境。如测试时间为50分钟，则综合场景中的每个脚本都是在循环执行。所以综合场景中不宜加入login测试点，因为不能真实模拟实际的生产环境。

疲劳强度测试：是一种特殊的强度测试（压力测试）。指在一定的压力下（如：相同的用户数）长时间（疲劳）对系统进行测试，并监控服务器的各项资源情况。如：7x24小时,24小时（如移动电信银行的服务器）。测试其服务器的稳定性：指长时间的运行过程中，系统的各项资源及时间等指标表现是否正常。

内存泄露：系统的服务器内存都被占用，而没有释放。导致系统没有可用内存。

内存泄露测试：通过LR监控时查看具体的几项指标，或者通过其它的专门内存泄露检测工具测试。

数据容量测试：查看系统服务器能否实现大数量下使用情况，系统的各项资源表现情况。如：200G，或者3个T。

极限测试：也叫“摸高测试”，测试系统的极限，如系统最大能承受的用户数，吞吐量等。

虚拟用户：Virtual Users 控制台：Controller 分析工具：Analysis

LoadRunner的三大组件：

虚拟用户脚本生成器（Virtual User Generator）---Creat/Edit Scripts【Generator：生成器】 压力调度控制台（Controller）---Run Load Tests 压力结果分析器（Analysis）---Analyze Test Results

QTP（功能自动化的工具）和LR（性能测试工具）的区别： QTP关心的是功能方面，LR关心的是性能方面。

QTP关心界面的控件属性（对象，对象的属性，属性值等）等，LR关心的是客户端和服务器之间往来的数据包。

LR的工作原理：

录制时，LR记录客户端和服务器二者之间的所有对话（数据包），形成脚本，回放时，LR模拟真实的客户端，向服务器发送请求。并验证服务器的响应。

LR是怎么记录下数据包的：（1）基于局域网的广播原理。【这种用的很少】（2）基于一种嗅探原理sniffer。【目前在用的方式】

虚拟用户脚本生成器：是用来生成脚本的

LR的常用术语：

虚拟用户（Virtual User 【简称VU】）：在场景中，loadRUnner用VU代替实际用户。Vuser模拟实际用户执行操作。一个场景可以包含几十，几百甚至几千个Vuser。（每个虚拟用户是一个进程或者线程，一般用的是线程）

Vuser脚本（Virtual User Script）：用于描述VU在场景中执行的操作。（记录的客户端发送的请求。）

事物（Transaction）：为度量服务器的性能，需要定义事务。事务表示要度量的最终用户业务流程或操作。

为何要定义事务：因为脚本中将关心的操作（如购票）定义为一个事务，则结果报告中（analysis）就会返回事务的响应时间。不关心的操作就不需要定义成事务。

场景（Scenario）：场景是一种文件，用于根据性能要求定义在每一个测试回话运行期间发生的事件。模拟真实环境中，用户运行的情况。【将脚本放到控制台去运行（包括设置各种参数）】

综合场景：将不同的脚本，至少3个放到控制台去共同运行一段时间。具体定义见PPT。

测试注意：

----设置IE（清楚浏览器缓存）：进入工具Internet选项常规设置每次访问此页面时检查

----LR中修改参数：进入ControllerRunTime SettingTnternet Protocol Proxy，选择No Proxy。

Jojo /bean

LR基本测试流程：

制定性能测试计划（部分）创建测试脚本编译，运行测试脚本【VUG】创建场景运行，监控场景，收集数据【Con 控制台】生成测试报告，分析测试结果【analysis】

最好用英文命名

小技巧： 弹出结果

日志文件

Transaction 事务

将一个操作设置成事务的目的：获取操作的响应时间（在analysis报告里）

在带宽充足的情况下，完美的吞吐率应该随着点击率的升高而升高。反过来，当服务器压力过大服务器处理能力不足时，吞吐率会随着点击率的增高而保持恒定或者降低，那么点击率也会受到相应影响而变慢。

即吞吐率和点击率是相互影响的。

脚本生成器可以模拟1个用户，多用户一定要用控制台来实现。（控制台就是来生成管理多用户的。）

基准测试是单用户测试，可用脚本生成器（生成的调试结果是没有响应时间的），但是也还是需要控制台。因为结果要写到报告里。（结果生成器analysis得出单用户测试的结果，比如响应时间等等）

疲劳测试和综合场景测试的区别就是时间的长短，疲劳测试运行的时间会长一些。

只要业务逻辑不变（操作不变），则不需要重新调试脚本，回归测试中可以直接利用原来脚本。

调试脚本时请频繁保存副本，因为LR回退键效果不是很好。

脚本必须现在脚本生成器进行运行，执行通过将脚本放入控制台，在控制台执行完毕后生成结果报告

总的吞吐率

服务水平等级协议

报告中事务响应时间的标准方差值：越趋近于0，说明系统越稳定（每一项事务的响应时间非常相似）

90percent：表示90%的事务都可以在该响应时间内完成。代表一个大多数情况。

HTTP状态码： 200表示成功

4XX表示客户端的失败 5XX表示服务器的失败

当场景设定的duration时间结束时，所有的虚拟用户需要运行完当前的transaction以及action再结束。

基准测试执行方法

单用户执行脚本操作1分钟 单用户执行脚本操作5次

B/S脚本必须要有登陆，有退出（否则假退出其实链接还没断开，会影响测试结果）

Replay log：脚本执行日志 Recording log：录制时的日志

Generation log：所有客户端和服务器二者之间的对话

快捷键：

ctrl+G

Go to Line 跳到某一行

跳到对应的日志

基准测试：单用户测试。3.4 1.7 1.8 1.6 为了规避第一次测试的不准确性，则有两种测试方法：（1）设置循环5次（N次）

Run-time Setting 循环5次，或者持续运行1分钟。（取平均值）Run logic：循环次数----设置为5 Pacing：两次循环之间的步长值（时间间隔）----随机值2-4秒 Think time：ignore（忽略思考时间），因为对结果没什么影响

Pacing：步长值，为了更真实的模拟环境（断开连接，释放资源），一般选随机值

基准测试单用户对服务器压力不大，一般可以ignore think time。

监控资源：监控服务器的资源

客户端的资源：自己随时把握一下，不要成为测试的瓶颈即可。

（2）持续运行1分钟

当duration和run_time setting中循环（run logic）都有值的话，duration的优先级比较高【二者循环的位置都为action】 Run logic：循环次数----设置为1

Pacing：步长值，为了更真实的模拟环境（断开连接，释放资源），一般选随机值 基准测试单用户对服务器压力不大，一般可以ignore think time。监控资源：监控服务器的资源

客户端的资源：自己随时把握一下，不要成为测试的瓶颈即可。

并发测试执行方法： 脚本添加集合点

在控制台设置并发策略

注意：refresh中有两个选择，看情况使用。

脚本和控制台的run-time setting都设置的话，哪个优先级高？控制台的优先级高！脚本中的run-time setting 何时使用？运行脚本的时候使用

并发测试有两个步骤：

1）脚本中加并发点（即集合点）

2）在控制台设置：5个虚拟用户（VU），可以设置递增（不设也可），设置并发策略。

Run-time Setting---忽略休息时间，因为需要瞬间压力。

篇2：电泳漆性能测试标准

1.拉伸实验

[1] 标准

金属拉伸试件按国标GB/T6397-1986《金属拉伸试验试样》[1] 标准ASTM D3039-76用于测定高模量纤维增强聚合物复合材料面内拉伸性能；ASTM D638用于测定试件的拉伸强度和拉伸模量[2]； 2.压缩试验

[1] 标准

压缩试件按国标GB/T7314-1987《金属压缩实验试样》[1] ASTM D3410-75(剪切荷载法测定带无支撑标准截面的聚合体母体复合材料压缩特性的试验方法)[3]。3.弯曲试验

[1] 标准

ASTM D7624用于测定聚合物基复合材料的弯曲刚度与强度性能[2]。

4.剪切试验

[1] 标准

ASTM D5379适用大部分的纤维增强型复合材料[2]。

5.层间断裂

[1] 标准

ASTM D5528和JIS K7086，仅适用于单向分层测试。其他的还未有相关标准[2]。6.冲击试验

[1] 标准

金属材料按照GB/T229-1994加工成V形缺口或U形缺口[1] 目前复合材料在冲击后的损伤性能表征主要是损伤阻抗(Damage Resistance)和损伤容限(Damage To tolerance)。

目前关于损伤阻抗和损伤容限的测试标准有ASTM D6264-98(04)和ASTM D7136 /D7136M-05标准。D6264-98用来测量纤维增强复合材料对集中准静态压痕力的损伤阻抗；D7136用来测量材料对落锤冲击试件的损伤阻抗[2]。7.疲劳试验

[1] 疲劳极限测试标准

单点试验按照航标HB5152-1980规定；升降试验法按照国标GB/T3075-1982和GB/T4337-1984[1]。

参考文献

篇3：评价阴极电泳漆性能的新方法

对新品种阴极电泳漆材料的性能进行评价时, 按照标准试验方法, 完成所有项目至少需要近2个月的时间。但在某些特殊情况下, 需要在短时间内 (如20天左右) 完成评价工作。为此, 需要建立新的电泳漆性能评价方法。

2 制定新的试验方法

对新品种阴极电泳漆材料而言, 为了在较短的时间内获得相对准确的评价结果, 在完成短周期 (5天以内) 试验项目后, 通过技术分析和研究, 针对槽液稳定性、漆膜耐盐雾性能、与面漆配套后的耐老化性能等长周期 (约1 000 h) 项目制定了新的试验方案, 具体见表1。

针对表1有以下几点说明。

(1) 电泳漆槽液稳定性试验的新方法

为缩短电泳漆槽液稳定性试验周期, 通过提高电泳漆槽液温度的方法加速其老化进程、增加其破乳的风险。参考面漆材料的加速稳定性试验方案, 制定了电泳漆的槽液稳定性试验的新方法。槽液参数主要指电导率和pH值, 电泳漆膜的外观质量和厚度通过按照工艺规定的电泳条件和烘干条件制作的样板来检验和评价。

(2) 电泳漆膜耐盐雾性能试验的新方法

按照标准要求, 电泳涂层进行盐雾试验时, 一般将涂层厚度控制在20～23μm。对不同厚度的电泳涂层进行的盐雾试验表明, 电泳涂层厚度大于13μm时, 涂层厚度对其耐盐雾性能 (1000 h以内) 基本没有影响;当电泳涂层厚度为8～9μm时, 耐盐雾性能约为原来 (膜厚为20～23μm时) 的50%左右。据此制定了如下电泳漆膜耐盐雾试验的新方法。

在按照标准要求进行盐雾试验的同时, 再进行低膜厚 (8μm左右) 电泳涂层的耐盐雾试验, 400 h后对两种不同厚度的电泳涂层进行综合评价, 根据试板表面状态及腐蚀发生趋势判断其耐盐雾性能。

(3) 电泳漆与金属漆配套后的涂层耐老化试验的新方法

该涂装线部分颜色的金属漆采用了无中涂的涂装工艺。以前进行过的大量的耐人工紫外老化试验结果表明, 金属漆涂层的外观指标 (如光泽、鲜映性PGD值和色差等) 基本能够满足质量要求, 但力学性能 (如耐冲击性能、杯突值、电泳漆与金属漆的层间附着力等) 因采用不同的电泳漆而有明显差异。因此, 新方法重点考察了金属漆涂层在加速老化试验后力学性能的变化情况, 而紫外线辐射是造成电泳涂层粉化, 进而影响整个金属漆涂层冲击、杯突和层间附着力的主要原因。

通过提高紫外光照时间的比例 (12 h/24 h→20h/24 h) 和温度 (60℃→70℃) 加速热老化进程、缩短老化试验周期, 制定了表1中新的耐人工紫外老化试验 (采用荧光紫外线冷凝型试验机进行) 新方法。试验条件:以紫外线曝晒70℃/10 h→冷凝曝露50℃/2 h为1个循环, 往复进行, 400 h (其中紫外照射333 h/70℃应接近500 h/60℃的效果) 后检验、评价金属漆涂层的有关指标变化。

3 新试验方法的验证

按照新试验方法对选定的A、B两种电泳漆进行了长周期项目的性能评价, 具体结果如下。

(1) 电泳漆槽液的稳定性试验

对A、B两种电泳漆槽液的稳定性进行了试验, 并与采用标准试验方法的结果进行了对比, 见表2和表3。

由表2的试验结果得出以下结论。

a.经过16天加速槽液稳定性试验后, 电泳槽液参数变化较小, 漆膜厚度和外观质量满足要求。

b.采用标准槽液稳定性试验方法——室温放置30天后, 漆膜厚度由21μm下降至19μm (满足要求) , 漆膜外观质量满足要求。

可见, 两种试验方法的结果相近。

由表3的试验结果得出以下结论。

a.经过16天加速槽液稳定性试验后, 电泳槽液参数变化较小, 漆膜厚度和外观质量满足要求。

b.采用标准槽液稳定性试验方法——室温放置30天后, 漆膜厚度由27μm下降至18μm, 漆膜外观质量满足要求。

可见, 两种试验方法的结果相近。

(2) 电泳漆膜的耐盐雾试验

采用新方法, 即在对标准厚度的电泳涂层进行盐雾试验的同时, 附加进行低膜厚 (8μm左右) 电泳涂层的耐盐雾试验, 400 h后对A、B电泳漆两种不同厚度的电泳样板进行耐盐雾性能综合评价;标准厚度的电泳样板评价后继续进行耐盐雾试验至1 000 h再进行一次结果评价。具体试验结果见表4。

(3) 与金属漆配套后涂层的耐老化性能试验

采用新方法, 对A电泳漆和B电泳漆分别与金属漆配套后的涂层进行了耐人工紫外老化试验, 结果见表5和表6;然后又按照标准试验方法进行了对比试验, 结果见表7和表8。从失光率和色差变化等指标判断两种试验方法的结果接近。

由表5的结果看出, 经400 h紫外老化 (紫外线曝晒70℃/10 h—冷凝曝露50℃/2 h为1个循环) 试验后, 涂层的光泽度、鲜映性、色差和力学性能的指标满足质量要求。

由表7的结果看出, 经1000 h紫外老化试验 (紫外线曝晒60℃/4 h→冷凝曝露40℃/4 h为1个循环) 后, 涂层的光泽度、鲜映性、色差和力学性能的指标满足质量要求。

由表6的结果看出, 经400 h紫外老化试验后, 涂层的光泽度、鲜映性、色差和力学性能的指标满足质量要求。

由表8的结果看出, 经1000 h紫外老化试验后, 涂层的光泽度、鲜映性、色差和力学性能的指标满足质量要求。

4 结论

上述一系列试验证明, 创新的阴极电泳漆的部分性能评价方法能够在较短的时间内完成新品电泳漆的性能评价工作。这为应对某些特殊情况 (如供应商突然停供) 提供了解决方案。

摘要：在某些特殊情况下, 需要在较短时间内完成新品种阴极电泳漆材料的性能评价工作。为此, 建立了评价阴极电泳漆部分长周期性能指标 (如槽液稳定性、耐盐雾性能、电泳漆与面漆配套后涂层的耐老化性能) 的新方法, 并利用两种电泳漆材料将新方法和标准试验方法进行了对比。结果表明, 新评价方法能够取得和标准试验方法相近的试验结果, 并且显著缩短了阴极电泳漆材料性能评价的周期。

篇4：电泳漆性能测试标准

概念及特点

医疗器械包装分为外部附属包装和内部初包装两个部分。外部附属包装主要是指可为处于仓储或物流过程中的医疗器械提供保护性、便利性、可追溯性的包装形式，包括纸箱、塑料袋、标签、托盘、集装箱等缓冲包装或集合包装等；内部初包装即灭菌包装，主要是指可与医疗器械直接接触，并对其进行灭菌或无菌处理（如洁净开启）的包装形式。按照ISO 11607-2006《最终灭菌医疗器械的包装》标准，医疗器械灭菌包装也被称为“无菌屏障系统 （Sterilization Barrier System）”。

医疗器械灭菌包装的主要功能是将最终灭菌的医疗器械装入包装内，密封后再通过物理或化学的方法，将医疗器械上的微生物杀灭，形成微生物阻隔屏障，使医疗器械在一定的使用有效期内处于无菌环境。与医疗器械附属包装不同，医疗器械灭菌包装的外观并不注重色彩的鲜艳程度和图文的复杂程度，而是更加重视具有标签性质的提示性内容。

材料性能

医疗器械灭菌包装的主要材料包括纸塑复合材料、塑料、透析纸、吸塑成型膜、吸塑纸盒，以及以100%HDPE为基材的无纺布等。由此可见，医疗器械灭菌包装属于以纸塑材料为主体的软包装范畴，与传统软包装材料有很多共同点。但是，与传统软包装相比，医疗器械灭菌包装对材料的要求更高，除了要求其具备基本的物理性能和化学性能外，更强调材料性能的持续性和稳定性，以及与医疗器械、灭菌工艺的适应性，对微生物的阻隔性和无毒无害性，这些特殊要求都是阻碍工业产品或食品包装企业进入医疗器械灭菌包装领域的高门槛。

1.基本性能

作为用于医疗领域的灭菌包装材料，无毒无害是其最基本的性能。除此之外，医疗器械灭菌包装在物理性能和化学性能方面也有一些指标要求。物理性能指标主要包括透气性、阻隔性、机械强度、透明度、雾度、耐高温性、耐辐照性等；化学性能指标主要包括环境稳定性、溶剂耐抗性等。

2.与医疗器械的适应性

包装材料与医疗器械的适应性是灭菌包装企业应该考虑的首要因素，主要包括医疗器械在灭菌、运输和仓储过程中所能承受的应力极限值，医疗器械的重量和结构，由医疗器械敏感性（如射线、水分、机械振动、静电）而可能对灭菌包装造成的特殊影响等方面。

3.与灭菌工艺的适应性

由于医疗器械灭菌包装在完成密封之后还要经过一个预先设计好的灭菌过程，因此必须要考虑到包装材料本身对灭菌工艺的适应性。例如，环氧乙烷蒸汽（EO）灭菌工艺要求包装材料具备良好的透气性；辐照灭菌（Gamma）和电子束灭菌（E-Beam）工艺要求包装材料拥有足够的耐辐照性，以免发生老化、脆裂现象；高温蒸汽灭菌（Steam）工艺要求包装材料具有耐高温性，即在121～136℃的高温环境下放置15～30分钟而无损坏。

4.对微生物的阻隔性

对微生物的阻隔性是保障灭菌包装完好和医疗器械安全的重要指标。作为医疗器械的“无菌屏障系统”，灭菌包装需要通过特定工艺（通常指热封）形成密封系统，这样才能达到防止微生物入侵的目的。评价该性能主要有两种方法，一种是适用于不渗透材料的方法，如复合薄膜、硬吸塑纸盒等材料；另一种是适用于多孔材料的方法，如医用包装纸等。

测试标准

目前，医疗器械灭菌包装的测试标准主要包括国际标准ISO 11607和EN 868系列，以及国内标准GB/T 19633-2005《最终灭菌医疗器械的包装》，这3个标准都属于通用标准的范畴，涵盖了很多关于医疗器械灭菌包装的具体测试方法和测试标准，具有一定的参考价值。

1.ISO 11607标准

ISO 11607国际标准共有3个版本，分别是1997版、2003版和2006版。其中，最新的2006版由两个部分组成，即ISO 11607-1∶2006《最终灭菌医疗器械的包装 第1部分：材料、无菌屏障系统、包装系统的要求》和ISO11607-2∶2006《最终灭菌医疗器械的包装第2部分：成形、密封和组装过程的确认要求》，这样就把医疗器械灭菌包装按照包装系统设计和包装工艺确认两大主体内容区分开来了。该标准是医疗器械灭菌包装测试程序的关键指南，对医疗器械灭菌包装的研发极为重要。

2.EN 868系列标准

EN 868系列标准是被国际广泛认可和参照的医疗器械灭菌包装的标准体系，共分为10部分。该标准对医疗器械灭菌包装的原材料、形式、尺寸、规格、测试方式等均给予了明确要求，医疗器械灭菌包装的主要规范归列于EN 868-5《经消毒医疗设备用包装材料和设备 第5部分：纸和塑料薄膜制热封袋和自封袋和卷轴 要求和试验方法》中。

3.GB/T 19633-2005标准

在我国，医疗器械灭菌包装测试标准主要参照GB/T 19633-2005，该标准借鉴了国际标准ISO 11607-2003。该标准提出了用于医疗器械灭菌包装的一次性材料和可再利用容器的使用要求；概述了医疗器械制造商对灭菌包装研发过程的要求，其中成型和密封被认为是最关键的过程，同时也不能忽视其他过程对灭菌包装的影响；规定了评价医疗器械灭菌包装性能的基本指标。

篇5：性能测试学习总结

一、明确性能测试的范围

例如：以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

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

本次性能测试的系统是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 的测试结果文件全部提交给客户的前提下，客户仍然要求我们在测试报告中将每一次测试的数据均以表格的形式填至测试报告中，此项工作的工作量十分巨大，个人认为这样做并无必要。