http://www.abab123.com/bbs/down.asp?html=1112434

服务器稳定性是最重要的，如果在稳定性方面不能够保证业务运行的需要，在高的性能也是无用的。

　　正规的服务器厂商都会对产品惊醒不同温度和湿度下的运行稳定性测试。重点要考虑的是冗余功能，如：数据冗余、网卡荣誉、电源冗余、风扇冗余等。

　　一些测试方法主要分以下几种：

　　压力测试：已知系统高峰期使用人数，验证各事务在最大并发数（通过高峰期人数换算）下事务响应时间能够达到客户要求。系统各性能指标在这种压力下是否还在正常数值之内。系统是否会因这样的压力导致不良反应（如：宕机、应用异常中止等）。

　　Ramp Up 增量设计：如并发用户为75人，系统注册用户为1500人，以5％－7％作为并发用户参考值。一般以每15s加载5人的方式进行增压设计，该数值主要参考测试加压机性能，建议Run几次。以事务通过率与错误率衡量实际加载方式。

　　Ramp Up增量设计目标： 寻找已增量方式加压系统性能瓶颈位置，抓住出现的性能拐点时机，一般常用参考Hits点击率与吞吐量、CPU、内存使用情况综合判断。模拟高峰期使用人数，如早晨的登录，下班后的退出，工资发送时的消息系统等。

　　另一种极限模拟方式，可视为在峰值压力情况下同时点击事务操作的系统极限操作指标。加压方式不变，在各脚本事务点中设置同集合点名称（如：lr_rendzvous("same");）在场景设计中，使用事务点集合策略。以同时达到集合点百分率为标准，同时释放所有正在Run的Vuser。

　　稳定性测试：已知系统高峰期使用人数、各事务操作频率等。设计综合测试场景，测试时将每个场景按照一定人数比率一起运行，模拟用户使用数年的情况。并监控在测试中，系统各性能指标在这种压力下是否能保持正常数值。事务响应时间是否会出现波动或随测试时间增涨而增加。系统是否会在测试期间内发生如宕机、应用中止等异常情况。

　　根据上述测试中，各事务条件下出现性能拐点的位置，已确定稳定性测试并发用户人数。仍然根据实际测试服务器（加压机、应用服务器、数据服务器三方性能），估算最终并发用户人数。

　　场景设计思想：

　　从稳定性测试场景的设计意义，应分多种情况考虑：

　　针对同一个场景为例，以下以公文附件上传为例简要分析场景设计思想：

　　1）场景一：已压力测试环境下性能拐点的并发用户为设计测试场景，目的验证极限压力情况下测试服务器各性能指标。

　　2）场景二：根据压力测试环境中CPU、内存等指标选取服务器所能承受最大压力的50%来确定并发用户数。

测试方法：采用

1)Ramp Up-Load all Vusers simultaneously

　　2)Duration-Run Indefinitely

　　3)在Sechedule-勾选Initalize all Vusers before Run

　　容错性测试：通过模拟一些非正常情况（如：服务器突然断电、网络时断时续、服务器硬盘空间不足等），验证系统在发生这些情况时是否能够有自动处理机制以保障系统的正常运行或恢复运行措施。如有HA（自动容灾系统），还可以专门针对这些自动保护系统进行另外的测试。验证其能否有效触发保护措施。

　　问题排除性测试：通过原有案例或经验判断，针对系统中曾经发生问题或怀疑存在隐患的模块进行验证测试。验证这些模块是否还会发生同样的性能问题。如：上传附件模块的内存泄露问题、地址本模块优化、开启Tivoli性能监控对OA系统性能的影响等等。

　　测评测试是用于获取系统的关键性能指标点，而进行的相关测试。主要是针对预先没有明确的预期测试结果，而是要通过测试获取在特定压力场景下的性能指标（如：事务响应时间、最大并发用户数等）。

　　评测事务交易时间：为获取某事务在特定压力下的响应时间而进行的测试活动。通过模拟已知客户高峰期的各压力值或预期所能承受的压力值，获取事务在这种压力下的响应时间。

　　评测事务最大并发用户数：为获取某事务在特定系统环境下所能承受的最大并发用户数而进行的测试活动。通过模拟真实环境或直接采用真实环境，评测在这种环境下事务所能承受的最大并发用户数。判定标准阈值需预先定义（如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等）。

评测系统最大并发用户数：为获取整个系统所能够承受的最大并发用户数而进行的的测试活动。通过预先分析项目各主要模块的使用比率和频率，定义各事务在综合场景中所占的比率，以比率方式分配各事务并发用户数。模拟真实环境或直接采用真实环境，评测在这种环境下系统所能承受的最大并发用户数。判定标准阀值预先定义（如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等）。取值标准以木桶法则为准（并发数最小的事务为整个系统的并发数）。

　　评测不同数据库数据量对性能的影响：针对不同数据库数据量的测试，将测试结果进行对比，分析发现数据库中各表的数据量对事务性能的影响。得以预先判断系统长时间运行后，或某些模块客户要求数据量较大时可能存在的隐患。

　　问题定位测试在通过以上测试或用户实际操作已经发现系统中的性能问题或怀疑已存在性能问题。需通过响应的测试场景重现问题或定义问题。如有可能，可以直接找出引起性能问题所在的代码或模块。
　　该类测试主要还是通过测试出问题的脚本场景，并可以增加发现和检测的工具，如开启Tivoli性能监控、开启HeapDump输出、Linux资源监控命令等。并在场景运行过程中辅以手工测试。

 

            BUGZILLA的使用

 

目   录

 

1  用户登录及设置流程：. 3

2  BUG处理流程. 4

3  Bug的提交过程. 5

4  对于Bug的不同处理情况. 7

5、关于权限的说明. 8

6  查询. 9

7 消遣一下吧. 13

8 Bugzilla管理员操作指南. 14

 

Bugzilla的使用

1        用户登录及设置流程：

打开浏览器，进入Bugzilla主页面。

进入主页面后，点击【新建帐号】，进入注册页面。

在注册页面中输入E-Mail和真实姓名（为了统一，这里我们都使用计算机名），然后，点击【Create Account】，随后，你将收到一封包含初始密码的E-Mail。

在收到E-Mail之后，点击【登录】，在帐号栏输入注册时使用的E-Mail地址，在密码栏输入邮件里通知的初始密码，然后，点击【Login】。

如忘记密码，在登陆页面中输入注册用户名，点击【Submit Request】,根据收到的邮件进行重新设置密码。

成功登录后，点击【Edit属性】->【帐号设置】，进行密码修改。

点击【Edit属性】->【邮件设置】，进行邮件通知设置。

点击【Edit属性】->【权限】，进行权限查询。

注意：在登陆使用之后，一定要退出登陆，这不仅是一个好不好习惯的问题，在bugzilla中将成为一个隐患——当你没有退出登陆而关闭页面，当用同一台机器再次访问的时候，系统会以上次登陆的用户访问——小心你的权限被错误使用哦！

 

2  BUG处理流程

①     测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，系统会自动通过Email通知项目组长或直接通知开发者。

②     项目组长根据具体情况，重新reassigned分配给bug所属的开发者。

③ 开发者收到Email信息后，判断是否为自己的修改范围.
　1） 若不是,重新reassigned分配给项目组长或应该分配的开发者。
　2） 若是，进行处理，resolved并给出解决方法。（可创建补丁附件及补充说明）
④ 测试人员查询开发者已修改的bug，进行重新测试。（可创建test case附件）
　1） 经验证无误后，修改状态为VERIFIED。待整个产品发布后，修改为CLOSED。
　2） 还有问题，REOPENED，状态重新变为“New"，并发邮件通知。
⑤ 如果这个BUG一周内一直没被处理过。Bugzilla就会一直用email骚扰它的属主，直到采取行 动。管理员可以设定最迟采取行动的期限，比如说3天，系统默认为7天。

Bug开始

初始状态

指派处理人员

二次指派

处理Bug

确认处理

关闭

Bug结束

重新 打开

3        Bug的提交过程

Ⅰ要先进行查询

◎确认要提交的bug报告不会在原有纪录中存在，若已经存在，不要提交，若有什么建议，可在原有纪录中增加注释，告知其属主。

◎确认你发现的Bug是否在最新的版本中所发生的。

 

Ⅱ若Bug不存在，原谅自己的无情了,添加吧！！

操作：

点击【新建】—〉选择发现的bug所在的产品名称。

在选择的产品bug提交页面中，选择或者输入bug信息。

◎模块：点“模块”两个字，可以查看关于这个产品的模块的详细信息。

◎平台、操作系统：可以根据发现bug的实际情况来选择，如果确定这个bug可以发生在所有的平台，选择all好了！

◎优先级：P1至P5优先级逐渐减弱。

◎严重级：blocker到enhancement严重程度降低。

  Blocker:阻碍了项目开发或者测试的继续进行。

  Critical:冲突，数据丢失和严重的内存泄漏等问题。

  Major:较大的功能缺陷。

  Minor:较小的功能缺陷。

  Trivial:拼写、对齐类的错误。

  Enhancement:需要改进的。

◎初始状态：开发人员的默认状态为“unconfirmed”(这个要由管理员设置，参见管理员操作指南)，测试人员或者管理员此处为可选状态：unconfirmed和new.

◎Assigned to: 为空时默认为管理员指定的 owner, 也可手工制定。

◎CC: 可为多人，需用"，"隔开。

◎URL: bug的定位（可选）。

◎注释：是对bug的概述（必须填写）。

◎Desription中要详细说明下列情况：
1） 发现问题的步骤

2） 执行上述步骤后出现的情况
3） 期望应出现的正确结果

◎关键字：单击“关键字”三个字，会显示管理员已经设定的关键字，选择其一，便于以查询。注意：此处不可以随意添加，必须使用已经存在的关键字才好。另外，如果管理员没有创建关键字的话，那么此项缺省。

◎依赖：直接输入与当前bug有依赖关系的bug的编号。简单地说，比如说这里输入“3”，那么就是说当前提交的bug有依赖关系，不是由于3导致了当前bug，就是当前bug导致了bug3。

确认无误后，“commit”!

提交之后，系统会提示：bug 已经提交。在此页面的下半部分，会再次显示刚才提交的bug的详细信息，你可以在这里进行修改，重新commit,也可以在此增加新的附件或是附加说明来进一步说明bug。

◎投票：可以查看票数,只要点击【显示这个bug的票数】，也可以参加投票，【为这个bug投票】—〉在“票数”一栏中直接输入票数—〉【change my votes】.

需要说明的是：票数并不是任意的，管理员为每一个用户设置了可以投票的最大数目和每个用户为某个bug投票的最大数目。

建议：一次只投一票，多投也没什么意义。

 

Ⅲ 冲突

当两个或几个人同时修改一个bug提交信息的时候，bugzilla会有弹出 Mid- air collision!提示，并且列出解决冲突的选择：◎提交修改，但是会导致覆盖别人所做的修改。

◎不改了，返回。

建议选择返回，看看别人修改了什么，不同的话，添加一个附加说明来补充吧！！

以上各项可能会因为权限的关系，有所缺省。

4  对于Bug的不同处理情况

4.1 Bug的属主 (owner) 处理问题，提出解决意见及方法。
给出解决方法并填写附加说明（Additional Comments），还可创建附件（如：更改提交单）。
填表提示：
　FIXED 描述的问题已经修改，该bug已经修复并检查过，源文件已经检入CVS库。

INVALID 描述的问题不是一个bug (输入错误后，通过此项来取消)
　　WONTFIX 描述的问题将永远不会被修复。
　　LATER 描述的问题将不会在产品的这个版本中解决。
　　DUPLICATE 描述的问题是一个存在的bug的复件。
　　WORKSFORME 所有要重新产生这个bug的企图是无效的。如果有更多的信息出现，请重新分配这个bug，而现在只把它归档。

 

4.2 项目组长或开发者重新指定Bug的属主。
①bug不属于自己的范围，可置为 Assigned ,等待测试人员重新指定。
②bug不属于自己的范围，但知道谁应该负责，在Reassign bug to的输入框中直接输入被指定人的Email。　　

③操作结果：此时bug状态又变为New，此bug的owner变为被指定的人。

 

4.3 测试人员确认开发人员报告的Bug是否存在.

查询状态为“Unconfirmed"的Bug,

测试人员对开发人员提交的Bug进行确认，确认Bug存在。

具体操作：选中“Confirm bug(change status to New)"后，进行commit.

操作结果：状态变为“New".

 

4.4 测试人员验证已修改的 Bug
① 测试人员查询开发者已修改的bug，即Status为"Resolved", Resolution为"Fixed".进行重新测试。（可创建test case附件）
② 经验证无误后，修改Resolution为VERIFIED。待整个产品发布后，修改为CLOSED。
　若测试之后发现还有问题，REOPENED，状态重新变为“New"，并发邮件通知。

5、关于权限的说明

◎组内成员对bug具有查询的权利,但不能进行修改。

◎ Bug的owner 和 reporter 具有修改的权利。
◎ 具有特殊权限的用户具有修改的权利。

6        查询

6.1 登录Bugzilla缺陷跟踪系统后，点击查询（如上图），可以按照指定的一个或者多个查询条件进行查询。

◎摘要(Summary)：下拉列表框选择查询规约。在其后的输入框中输入包含的信息，此信息的指定与提交bug时的注释信息相一致。

◎产品(Product)：选择所要查找的bugs所在的产品。

◎模块(Component)：选择bugs所在的模块。

◎版本(Version)：选择bugs版本。

◎注释(Comments)：可在下拉列表框中选择将要输入的包含信息的规约，其后指定包含的信息。此信息的指定根据提交bugs时所填写的描述信息。

◎URL： 指定关于bugs所在的URL。

◎关键字(Keywords)：指定包含或不包含该关键字的bugs。每个bug可以被指定关键字，bugs报告人或者管理员可以编辑关键字。

◎状态(Status)：选择bugs状态。

◎处理(Resolution)：选择bugs处理的结果。

◎严重性(Severity)：选择bugs的严重级别。

◎优先级(Priority)：选择bugs的优先级别。

◎硬件(Platform)：选择存在bugs程序运行的平台。

◎操作系统(OpSystem)：选择存在bugs程序所运行的操作系统。

 

6.2 邮箱和编号