软件缺陷内部数据库的重要性－文章不错，共享给大家学习

一、概述

测试质量和效率是软件测试的重要内容，其中对软件测试过程发现的软件缺陷（Bug）的管理具有重要作用。

软件测试缺陷管理数据库是管理软件测试缺陷的专用数据库系统，可以高效率地完成软件缺陷的报告、验证、修改、查询、统计、存储等任务。尤其适用于大型多语言软件的测试管理。

实际测试项目实施之前，客户都提供通过因特网访问的项目公共数据库。由于通过因特网访问速度比较慢，客户只给项目中的少数人登录权限，所以，不能满足测试组每个成员都可以方便地访问数据库。更重要的，如果每个测试工程师都各自直接向项目公共数据库报告和修改软件测试发现的缺陷，由于每个人软件测试的经验背景不同，很难控制报告的缺陷质量，也不利于保持软件缺陷报告的一致性。所以，为了保证报告软件缺陷的质量和格式的一致性，需要测试小组内部指定具有测试经验的人员验证和审查小组内部报告的软件缺陷，然后再通过因特网，统一报到项目公共数据库中。

据调查，很多从事多年软件测试的公司，都有内部的软件测试缺陷管理数据库。这些内部数据库大部分是公司内部开发的，也有一些是直接从市场上购买的。公司内部开发的功能更符合实际要求、具有良好的扩展性。直接购买的数据库节约了开发成本，但是往往价格较高，很多功能根本用不上，造成经济上的浪费。

大型的软件测试项目，需要多人组成一个或多个测试小组，通过有效管理和内部交流才能保证测试项目的顺利实施。因此，如果再单纯采用内部电子邮件的方法管理测试的软件缺陷，将造成测试项目实施过程中，软件测试缺陷的交流效率低，缺陷的流程管理难以实时控制。

二、采用电子表格与电子邮件管理软件缺陷引起的问题

在没有引入公司内部软件缺陷管理数据库之前，对于测试发现的软件缺陷，测试小组内部采用发送内部电子邮件的方式。测试工程师发现的软件缺陷，先书写测试基本信息（软件名称、版本号、语言、测试环境、测试内部、缺陷类别，测试者姓名、测试日期），然后加入详细的测试步骤，和/或捕捉缺陷的图像。再发送给测试组内部的软件缺陷验证工程师，为了使内部其他测试工程师注意已经发现的缺陷，还要同时抄送邮件。负责向客户提供的项目数据库测试团对中的工程师，首先要检查测试工程师邮件中的软件缺陷是否正确和完整，包括格式、步骤，然后报告到客户提供的项目数据库。为了便于统计工作量、进度、缺陷类型和数量，通常创建电子表格文件，将缺陷类型、报告者、报告日期、缺陷状态等进行记录。

这种测试工作方式最大的不便之处在于：

1、测试效率不高

测试组每个成员在测试过程中要不断受到中断，需要随时阅读和回复这些邮件，工作效率很低。尤其当测试成员很多，测试的语言版本很多时，缺陷严重工程师的压力更大。内部缺陷验证工程师的工作量很大，不仅要验证缺陷的正确性，报告缺陷到客户的项目数据库，还要逐个向电子表格文件输入每个缺陷的处理情况。另外，如果报告的缺陷很多，很难分类查找某个或某种类型的缺陷。

2、测试质量难保证

由于个人的测试经验和习惯不同，每个人报告的软件缺陷的内容和格式很难保持一致，甚至往往遗漏关键内容。软件缺陷验证时，需要花费很多时间对其内容进行检查，对于检查中发现的问题还要发邮件或口头交流。如果缺陷被验证通过，再报告到客户提供的因特网测试缺陷管理数据库中，并且发送缺陷编号和标题等内容给测试工程师，并抄送给内部其他相关测试工程师，又一次造成测试中断和处理邮件。

3、实时管理难度大

测试过程中，经常需要迅速定位查找某个软件错误，由于没有内部数据库管理，只能从很多测试邮件和缺陷统计电子表格文件中寻找，或者从因特网的项目测试数据库查找，查找耗费大量的时间。另外，如果多个人同时测试不同语言的软件，由于发现的测试缺陷种类不同，缺陷验证工程师可能需要不断切换操作系统验证缺陷，效率很低。

三、引入软件测试缺陷管理内部数据库的重要性分析

以下从软件测试的流程管理的要求和大型多语言软件测试特征方面，论述引入内部软件测试缺陷管理系统的必要性。

1、提高软件缺陷的报告效率和质量

引入内部专用软件测试缺陷数据库具有以下优点：

第一、保持高效率的测试过程。由于测试缺陷数据库通过测试组内部局域网运行，因此打开和操作速度快。测试工程师随时向内部数据库添加新发现的缺陷，而且如果遗漏某项缺陷的内容，数据库系统将会及时给出提示，保证软件缺陷报告的完整性和一致性。软件缺陷验证工程师将主要精力验证数据库中新报告的缺陷，保证了效率。

第二、提高软件缺陷报告的质量。软件缺陷报告的一致性和正确性是衡量软件测试公司测试专业程度的指标之一。通过正确和完整填写软件缺陷数据库的各项内容，可以保证不同测试工程师的缺陷报告格式统一。为了提高报告的效率，缺陷数据库的很多字段内容可以直接选择，而不必每次都手工输入。

第三、实时管理，安全控制。软件缺陷查询、筛选、排序、添加、修改、保存、权限控制是数据库管理的基本功能和主要优势。通过方便的数据库查询和分类筛选，便于迅速定位缺陷和统计缺陷的类型。通过权限设置，保证只有适当权限的人才能修改或删除软件缺陷，保证了测试的质量。

软件自动化测试工具的评测方法
                               ------整理


软件测试的主要评测方法包括测试覆盖和质量评测。测试覆盖是对测试完全程度的评测，它是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。质量评测是对测试对象（系统或测试的应用程序）的可靠性、稳定性以及性能的评测，它建立在对测试结果的评估和对测试过程中确定的变更请求（缺陷）分析的基础上。
1 覆盖评测
覆盖指标提供了“测试的完全程度如何？”这一问题的答案。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。简而言之，测试覆盖是就需求（基于需求的）或代码的设计/实施标准（基于代码的）而言的完全程度的任意评测，如用例的核实（基于需求的）或所有代码行的执行（基于代码的）。
◆基于需求的测试覆盖
基于需求的测试覆盖在测试生命周期中要评测多次，并在测试生命周期的里程碑处提供测试覆盖的标识（如已计划的、已实施的、已执行的和成功的测试覆盖）。 测试覆盖通过以下公式计算：
测试覆盖 = T^(p,i,x,s) / RfT
其中：T是用测试过程或测试用例表示的测试 (Test) 数（已计划的、已实施的或成功的）。RfT 是测试需求 (Requirement for Test) 的总数。
◆基于代码的测试覆盖
基于代码的测试覆盖评测测试过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流（语句、分支或路径）或数据流的基础上。基于代码的测试覆盖通过以下公式计算：
测试覆盖 = I^e / TIic
其中：I^e 是用代码语句、代码分支、代码路径、数据状态判定点或数据元素名表示的已执行项目数。TIic (Total number of Items in the code) 是代码中的项目总数。
2 质量评测
测试覆盖的评估提供对测试完全程度的评测，对在测试过程中已发现缺陷的评估提供了最佳的软件质量指标。因为质量是软件与需求相符程度的指标，所以在这种环境中，缺陷被标识为一种更改请求，该更改请求中的测试对象与需求不符。
◆缺陷报告
一般，可以将缺陷计数作为时间的函数来报告，即创建缺陷趋势图或报告；也可以将缺陷计数作为一个或多个缺陷参数的函数来报告，如作为缺陷密度报告中采用的严重性或状态参数的函数。这些分析类型分别为揭示软件可靠性的缺陷趋势或缺陷分布提供了判断依据。
◆性能评测
评估测试对象的性能行为时，可以使用多种评测，这些评测侧重于获取与行为相关的数据，如响应时间、计时配置文件、执行流、操作可靠性和限制。这些评测主要在“评估测试”活动中进行评估，但是也可以在“执行测试”活动中使用性能评测评估测试进度和状态。
主要的性能评测包括：
◆动态监测 - 在测试执行过程中，实时获取并显示正在执行的各测试脚本的状态。

◆响应时间/吞吐量 - 测试对象针对特定主角和/或用例的响应时间或吞吐量的评测。

◆百分位报告 - 数据已收集值的百分位评测/计算。

◆比较报告 - 代表不同测试执行情况的两个（或多个）数据集之间的差异或趋势

易用性（Useability）是交互的适应性、功能性和有效性的集中体现。
人体工程学（ergonomics）是一门将日常使用的东西设计为易于使用和实用性强的学科。
在 2003 年颁布的 GB/T16260-2003(ISO 9126-2001) 《软件工程 产品质量》质量模型中，提出易用性包含易理解性、易学习性和易操作性；即易用性是指在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。
（ 1 ）易理解性；（ 2 ）易学习性；（ 3 ）易操作性；（ 4 ）吸引性；（ 5 ）依从性。


易用性测试包括针对应用程序的测试，同时还包括对用户手册系统文档的测试。通常采用质量外部模型来评价易用性。包括如下方面的测试：
（ 1 ）易理解性测试；
（ 2 ）易学性测试；
（ 3 ）易操作性测试；
（ 4 ）吸引性测试；
（ 5 ）易用的依从性测试。


易用性测试方法有：静态测试；动态测试；动态和静态结合测试。

人体工程学的主要目标是达到易用性。
1、用户界面测试
用于与软件交互的方式称为用户界面或UI。
2、优秀UI的构成
软件测试员要负责测试软件的易用性，包括其用户界面。
记住，软件测试员不需要去设计UI，只需要把自己当作用户，然后去找出UI中的问题。
优秀UI具备的七个要素：
（1）符合标准和规范
最重要的用户界面要素是软件符合现行的标准和规范——或者有真正站得住脚的不符合的理由。
注意：如果测试在特定平台上运行的软件，就需要把该平台的标准和规范作为产品说明书的补充内容。像对待产品说明书一样，根据它建立测试用例。
这些标准和规范由软件易用性专家开发。它们是经由大量正规测试、使用、尝试和错误而设计出的方便用户的规则。
也并非要完全遵守准则，有时开发小组可能想对标准和规范有所提高。
平台也可能没有标准，也许测试的软件就是平台本身。
在这种情况下，设计小组可能成为软件易用性标准的创立者。
（2）直观
用户界面是否洁净、不唐突、不拥挤？
UI的组织和布局合理吗？
有多余功能吗？
帮助系统有效吗？
（3）一致
如果软件或者平台有一个标准，就要遵守它。如果没有，就要注意软件的特性，确保相似的操作以相似的方式进行。
快捷键和菜单选项
术语和命名
听众
诸如OK和Cancel按钮的位置。
（4）灵活
多种视图的选择：
状态跳转
状态终止和跳过
数据输入和输出
（5）舒适
软件使用起来应该舒适，不能给用户工作制造障碍和困难。
恰当；
错误处理；
性能。
（6）正确
要测试正确性，就是测试UI是否做了该做的事。
注意：市场定位偏差、语言和拼写、不良媒体、WYSIWYG（所见即所得）。
（7）实用
是否实用事优秀用户界面的最后一个要素。
3、为有残疾障碍的人员测试：辅助选项测试
辅助选项测试（accessibility testing）也就是为有残疾障碍的人测试。
残疾有许多种：视力损伤、听力损伤、运动损伤、认知和语言障碍。
（1）法律要求：
开发残疾人可以使用的用户界面的软件有一些法律规定。在美国，有3条法律：
美国公民残疾人条例（ADA）声明
居民条例第508款
通信条例第255款
（2）软件中的辅助特性
软件可以有两种方式提供辅助。
最容易的方式是利用平台或者操作系统内置的支持。
如果测试的软件不在这些平台上运行，或者本身就是平台，就需要定义、编制和测试自己的辅助选项。
注意：如果正在测试产品的易用性，一定要专门为辅助选项建立测试用例。
如windows系统，提供了：粘滞键，筛选键，切换键，声音卫士，声音显示，高对比度，鼠标键，串行键。
4、总结
总之，不要让易用性测试的模糊性和主观性阻碍测试工作。易用性测试的模糊和主观是固然的，即使设计用户界面的专家也会承认有的地方是这样的。

软件项目开发是个分工明确的系统工程，不同的人员扮演了不同的角色，包括部门经理、产品经理、项目经理、系统分析师、程序员、测试工程师、质量保证人员等。可见，软件测试工程师只是软件项目开发中的一个角色而已。 戏剧舞台上的生、旦、丑是不同的角色，其表演方式具有明显的特征，这是由于角色决定的。同样，软件测试工程师的角色，在软件项目开发中也存在如何定位和表现自身的行为和责任的问题。
此处讨论测试工程师的角色并非毫无意义。须知，角色不明，责任不清，行为就失去了参照目标，结果就可能很不理想了。轻则降低了工作质量和效率，重则被视为工作能力低下，可能要退出软将项目组的舞台了。
    软件测试工程师承担的任务
角色决定工作内容和承担的任务。测试工程师的角色应该承担什么任务呢？这没有统一的答案。因为，这与软件公司的规模，软件项目管理制度，公司领导和项目经理的管理风格，以及具体软件项目自身的特点有很大关系。而且，测试工程师也有普通和高级之分。
笼统的答案列举如下：

• 设置软件测试环境，安装必要的软件工具。
• 运行软件，发现和报告软件缺陷或错误。尤其需要快速定位软件中的严重的错误。
• 对软件整体质量提出评估
• 确认软件达到某种具体标准
• 以最低的成本，最短的时间，完成高质量的测试任务
• ......

在这其中，最重要的是要明确，程序员的责任和目标。在执行任何具体测试任务前，都要在项目组内对于责任和目标达成共识，以免带来后续工作的相互推诿。
    提高测试质量的要诀
另外一个值得注意的方面就是工作效率和质量，或许高级测试工程师与普通测试工程师的主要区别在于高级测试工程师可以更快地发现更多软件中的严重错误。对此，有什么可以借鉴的诀窍吗？请尝试以下方法，保证不会是您失望。

• 首先测试程序的核心功能，然后测试辅助功能。
• 首先测试功能，然后测试性能。
• 首先测试常见情况，然后测试异常情况。
• 首先测试经过变更的部分，然后测试没有变更的部分。
• 首先测试影响大的问题，然后测试影响小的问题。
• 首先测试必须测试的部分，然后测试可选或没有要求测试的部分

    软件测试工程师是项目团队中的服务员
需要强调的一点是，无论你是多么高级的测试工程师，都要明白无论测试需要的工具多么复杂，测试步骤多么冗长，测试工程师在软件项目开发中始终都是扮演服务员的角色，这是由测试工作的特点决定的。任何服务都有被服务对象—客户，软件测试工程师的服务对象有哪些呢？

• 最重要的客户是软件的用户。测试工程师需要站在客户的使用和需求角度测试软件，报告问题。
• 项目经理也是客户。测试工程师需要报告测试工作进度和发现的问题，尤其是严重的问题。
• 程序员是最经常打交道的客户。为了便于程序员重复报告的错误，尽量提供良好的软件问题报告，以便程序员可以更快的修复软件错误。
• 技术文档工程师、市场开发人员和技术支持工程师也都是测试工程师的服务对象。

软件测试工程师避免犯的几个错误
前文已经指出测试工程师应该明确角色，明确任务和责任。知道哪些是自己份内的事，哪些是不属于自己的事。一定要尽最大努力完成份内的事，不要做不属于自己的事情，以免弄巧成拙。
为了更好的扮演软件测试工程师的角色，尽量避免犯下面的错误：

• 承诺完成测试的软件没有质量问题

软件测试只是保证质量的一种方法，软件测试工程师的工作不会直接提高软件质量，因为绝大多数软件错误都需要程序员修复。软件测试只能证明软件存在错误，不能保证软件没有错误，不可能找出全部软件错误。个人的能力和对质量的影响范围很小，软件质量的提高要靠软件项目团队全体成员的共同努力。 　

• 承担软件的发布权利

不要因为软件中存在还没有修复的错误，而试图提出更改软件发布的计划。也不要认为已经完成了测试计划，自己决定可以发布软件。因为，改变软件发布计划可能要失去进入市场的良机和很多客户，对此造成的经济和公司市场的损失将不是测试工程师能够承担的。另外，软件发布后，如果用户发现了新的软件错误，公司领导或项目经理可能将过错加在软件测试人员的头上，因为他们同意发布软件。通常软件发布的权利由产品经理、项目经理、测试经理、市场经理共同集体讨论决定。 　

• 扮演过程改进成员的角色

软件测试工程师必须报告错误，有时也要分析错误的类型、特征和产生错误的原因。但是，不要主动提出改进软件过程的具体改进措施，更不要直接干涉程序员的工作方式，以免出力不讨好，影响今后的愉快合作。软件过程改进的方法是软件质量控制部门的事情，这是他们的本职工作。

你会选择哪里落脚呢？发表你个人意见吧！

UNIX/Linux系统的日志整理

我们在测试web应用时，测试环境往往都是搭建在unix/linux系统上的，有jboss、apache等一些应用，但环境异常时，我们如何去查去分析呢？是很多新同学碰壁。

LOG日志的介绍.doc
(2008-10-30 13:46:53, Size: 82 kB, Downloads: 18)

在测试B/S结构的系统中，尤其是web测试中，需求经常变更乃是家常便饭，作为测试人员，终端的软件质量把关者，我们该如何去控制，大家可以发表下自己的意见，分享自己公司的一些好的处理方法或个人见解,一起学习！

现在软件测试的数据库，很多是用oracle数据库，以前使用MY-sql的一些查询语句中oracle中可能不能通用，下面是我很久以前看oracle技术时整理的一些sql语句，希望能对新人或是想学习oracle中的sql语句提供帮助

oracle_sql笔记.rar
(2008-10-30 13:55:04, Size: 2.35 kB, Downloads: 77)

请问下bss楼主，自己开通个人空间，论坛中的帖子怎么才能导入到个人空间内，要什么等级才可以呢？？？

 

   没有人会否认ORACLE是全球最有影响的数据库产品之一；不过好的东西似乎总不是那么好用（初看起来如

此），甚至有些无情－－总会给layman们一个个无情的错误号。下面是我个人的总结，条条有用，希望能给初学者一点启示。

1、ORA－12541：TNS：没有监听器

　　原因：没有启动监听器或者监听器损坏。如果是前者，使用命令net start OracleOraHome81TNSListener（名字可能有出入）即可；如果是后者，则使用“Net8 Configuration Assistant”工具向导之“监听程序配置”增加一个监听器即可（基本不用写任何信息，一路OK。在添加之前可能需要把所有的监听器先删除！）

2、ORA－12500：TNS：监听程序无法启动专用服务器进程
　　或
　 ORA－12560：TNS：协议适配器错误

　　原因：ORACLE的数据库服务没有启动。使用命令net start ORACLESERVICEORADB（ORADB为数据库名字）即可。如果仍没有解决，请继续向下看。

Oracle认证最新题库，到www.pass4side.cn

3、如果数据库服务启动失败，则很有可能是其注册表项值损坏，最好的做法是以下两步：

　　1）ORADIM -DELETE -SID oradb 删除数据库服务项
　　2）ORADIM -NEW -SID oradb 新增数据库服务项
　　注：这个过程中如果出错，就重启计算机！

4、ORA－12154：TNS：能解析服务名

　　原因：ORACLE的网络服务名没有正确配置。请使用“Net8 Configuration Assistant”工具向导之“本地网络服务名配置”配置TNS即可。如果仍没有解决，请继续向下看。

5、ORA－1034 ：TNS：ORACLE不可用

　　原因：ORACLE的数据库服务正确启动，但是数据库没有打开！

　　使用命令：

　　1）svrmgrl 启动服务管理器
　　2）connect internal 以internal身份登陆
　　3）startup 打开数据库

6、ORA－12560：TNS：协议适配器错误（顽固性的）

　　原因：未知。

　　解决：必杀技－－打开“Windows任务管理器”，杀死ORACLE.exe及ORADIM.exe进程，书写自己的ora_startup.bat，执行之！

 <1>. 能力验证

        能力验证一般采用这样的描述：“该系统是否能在A条件下具备B能力？”。这里强调以下内容：

        （1） 充分准备以下内容：硬件设备、软件环境、网络条件、基础数据

        （2） 充分准备测试场景、典型的场景包括操作序列、并发用户数量条件、用例。

        该部分包括使用到上述测试方法：性能测试方法、可靠性测试、压力测试、失效恢复测试。

 <2>. 规划性能

        该分析方法关心的是“应该如何才能使系统具有我们要求的性能能力”，“应该如何调整系统配置，使系统能够满足增长的用户数的需要”等问题。这个部分常常使用到的测试方法是：负载测试、配置测试、压力测试。

 <3>. 性能调优

        一个标准的性能调优过程是：

        （1） 确定基准环境、基准负载和基准性能指标。

        （2） 调整系统运行环境和实现方法，执行测试。

        （3） 记录测试结果、进行分析。

        在J2EE性能测试中有很多常见的错误，比如：对于某些建立在J2EE/EJB技术上的应用，在服务启动的时候，没有注意到测试之前首先进行一段时间的预热。这是因为JAVA语言的hot-spot技术特性决定的，这种技术允许weblogic第一次运行应用的时候将字节码编译为本地代码并执行，这样在后续的执行过程中执行过程会大大加快，但第一次由于存在一个编译过程会比较慢。如果使用这个时间来作为基准那么就容易得出错误的结论。

        我对第2个过程比较擅长、具体下来包括硬件环境的调优、Weblogic调优、Oracle调优。这个过程中也是使用工具最多的测试环节。

 <4>. 发现缺陷

        这个环节中是交付给用户的主要工作成果。需要多和开发人员作沟通、多次迭代发现问题、根据用户的需求定义与缺陷的涉及范围、制定一个解决缺陷的优先级。由于软件永远有BUG这一真理，所以发现缺陷不是一次就能结束的工作。比较适合作为服务外包。持续进行。

        1. SEI负载测试计划过程

        目标：产生一个清晰、好理解、可验证的负载测试计划。

        内容：关注6个区域：目标、用户、用例、生产环境、测试环境、测试场景。

        工具：IBM、HP、OpenSource工具都支持。需有文档配合。

        2. RBI方法

        目标：快速识别性能瓶颈。

        内容：重点测试“吞吐量”指标，因为RBI认定80%的系统性能瓶颈由吞吐量造成。按照网络、硬件、数据库、应用服务器、代码的顺序自上而下分析性能。

        工具：IBM、HP、OpenSource工具都支持。需使用分析模块、根据Weblogic、Oracle区别有专门的工具实现RBI。

        3. 性能下降曲线分析法

        目标：性能随着用户数的增加而出现下降趋势的曲线分析、查看性能下降的环境点与上下文。确定性能阀值。

        内容：通过单用户区域、性能平坦区域、压力区域、性能拐点进行监控和分析。

        工具：IBM、HP、OpenSource工具都支持。IBM报表功能更强。

        4. HP（LoadRuner）性能分析法

        特点：侧重于该厂商的性能分析方法、主要体现在需求收集、VU脚本。

        缺点：没有对测试计划阶段、测试设计阶段的具体行为、方法、目的进行描述,方法局限于LoadRuner产品的特性上,不能通用。

        5. IBM（Rational UP）软件测试方法

        特点：软件产品生命周期RUP的实现、侧重于迭代测试、宽广的方法论。可适合任意测试环境及方法、工具。

        缺点：需要根据测试环境进行剪裁、难以掌握、但掌握后非常成熟、高品质工具：涉及到IBM Rational 测试环境的所有软件、功能强大。

        6. PTGM性能测试模型

        内容：一个非常适合行业用户（电力、金融、政务、制造）的性能测试过程模型。规范化的测试模型、每个环节都做到迭代测试、每一个过程的工作产品明显可察、测试流程、测试上下文方面很优秀。包括以下环节：前期准备、工具引入、测试计划、测试设计与开发、测试执行与管理、测试分析。

        工具：可以使用任意商业工具全新部署测试流程、不限于任何厂商工具的局限、也可以使用部分工具即可完成整个流程、或结合自己需要基于OpenSource工具进行定制。个人倾向使用多个产品的整合、综合使用、扬长避短。

一、 Cluster的概念及优势

   Weblogic支持集群技术，即让一组Server指向同一域名一起工作从而提供一个更强大、更可靠的应用平台。对于客户端而言，无论Cluster中有几个Server在工作，看上去都是一个。集群技术有两个最明显的特色：
(1)可伸缩性：Cluster对加入其中的Server在性能上没有限制，为了提高性能，当客户端的请求大幅增加时，可以动态地向Cluster中添加Server。并且，配置Cluster当一台机器的资源没有被完全利用时，可以在同一机器上启动多个Server，但要求每一个Server使用不同的IP，而不能用同一IP的不同端口。
(2)高可用性：由于在Cluster中同一service在多个Server上同时存放或放在一个共享文件系统中，因此相同的请求可以有多个Server提供，并且Server间还可以复制状态信息。这样，当其中某一Server宕机或无法响应请求时，其它的Server会立即接管它的任务，从而把应用和客户端完全隔离开来。

二、Cluster的工作机制
   每一个Clustered   service,在每一个server上都会有一个instance，即一个replica，这些replicas集合在一起形成一个replica-aware stub。这些stubs负责客户端与相关的服务器段对象的通信，当客户端请求该service时，实际上是向stub发出请求，stub根据不同的算法调用集合中某一replica，如果调用失败，stub会检测到错误并重新调用其它的replica。Cluster支持多种算法：随机、轮循、基于性能的负载均衡的轮循(Weight-based round-robin)、根据参数值调用(Parameter-based routing)。
Weblogic Cluster通过负载均衡和容错最大程度的实现了它的可伸缩性和可用性。
为了提高Cluster的可伸缩性，必须保证充分利用每一个Server。Weblogic可以在不同平台、不同性能的机器上安装Server并进行Cluster,然后采用Weight-based round-robin算法达到负载均衡，从而使每一个Server都得到充分的利用。
为了使Cluster具有高可用性，必须具备故障恢复的能力，这一点可以通过replica-aware stub的容错功能来实现。Stub 主要是通过在检测到错误信息时重新进行调用的方式实现容错。当重新调用不会导致错误的结果时(如stub确认failed server不能接收到请求)，容错功能自动实现。而有些情况下，重新调用可能会导致某一service被请求了多次的错误结果。例如：客户端C请求Clustered购物车服务中的additem()方法，replica-aware stub接收到请求，根据算法调用Server1上的service,Server1响应请求并返回结果，但在结果成功到达客户端之前，Server1出现错误。此时stub接收到错误信息，因此重新调用Server2上的这一方法，但实际上Server1已经将item加入购物车，这样就造成重复。为了解决这种问题，可以为服务添加一个唯一标识，如上述的additem()方法中可添加一个参数——序列号。每一个item有一个唯一的sequence,相同sequence的item不能被重复添加。

三、 Cluster的命名服务

    在Weblogic Server中使用命名服务时，客户端通过JNDI存取service，JNDI tree上绑定了Server提供的所有的公共服务。Server提供一个新的service时，是将service以某一名称绑定到JNDI tree上，客户端和Server建立连接并按照名称获取相应的stub。
Custer扩展了Server的这种命名服务机制，它不仅包含了每一个Server上的非Clustered的stub,而且包含了多个Server间的Clustered 的replica-aware stub。

四、 Cluster的服务类型

在Weblogic中，有多种服务可以进行cluster，如：RMI对象、EJB、Servlets、Jsp、Web Application。

（1）RMI和EJB Clustering
RMI和EJB对象在Cluster过程中使用JNDI命名服务机制。RMI和EJB对象发送remote stubs到客户端，客户端获取的这些stubs可以是已经clustered的，也可以是没有clustered的。对于Clustered的服务，Stubs根据负载均衡和容错的不同需求调用Cluster中合适的Server；而对没有Clustered的服务，所有对此stub的调用只能由提供此服务的Server来处理。
有些有状态的RMI和EJB对象是不可以进行clustered的，因为客户端必须总是和同一个Server上的对象实例相联系。所有的EJB都是clusterable，虽然EJB也有有状态的，但是EJB home interface 都是无状态的，可以进行clustered，这样就可以从JNDI tree上获取 Clusterable EJB 的home stub 对象。然后通过home stub的方法创建或检索相应的EJB bean,若为stateful session bean 或entity bean，那么此时得到的stub就是不可clusterable。为了使有状态的对象可以更好的cluster，可以将一些操作作为一个事务来执行，如果工作中的Server出现意外，可以重新获取此对象并进行事务操作。
RMI和EJB不同，RMI没有定义有状态和无状态分类，因此必须特意绑定一个有状态的RMI对象到Server上。可以仿效EJB home interface的方式即客户端从JNDI tree上获取一个clusterable factory method,然后factory method 可以调用集群中的任意一台Server,但是被调用的Server上必须有由此factory调用的对象。

（2）Clustered Servlets
Servlets也是可以进行Cluster的。对于Servlets，它用replica-aware proxy替代了replica-aware。这个proxy接受web server上所有请求，并转给集群中的某一Server。Proxy对cluster的所有请求进行负载均衡，并且当请求失败时会进行恢复处理。Proxy还可以在cluster中特别是Server没有正常完成请求响应时保持session状态。当session初始化时，proxy按照负载均衡算法选择一台Server保存session，此后，所有与此session相关的请求都由这同一台Server处理。为了避免当此Server出错时，无法保存客户端状态信息，所以session会被复制下来，并且session的所有变化都会在备份中进行及时更新，这样，当原有Server在响应请求过程中失败时，proxy会立即获取session的备份，并由此继续响应客户端请求，同时做新的复制。


(3)JDBC  clustering
为了利用Weblogic Server cluster的负载均衡和容错的性能，Weblogic JDBC连接池也可以在replicated naming tree上注册。通常情况下，cluster中的每一个Server都进行连接池属性配置来访问同一个后端的DBMS实例，即对相同数据库的访问，每一个Server都有一个连接池。然后通过在配置文件中定义一个DataSource属性来在naming tree 上注册连接池。客户端使用Weblogic JDBC/RMI JDBC 驱动程序从cluster中获取数据库连接，即客户端按照DataSource name获取连接池，然后按照负载均衡的算法选择相应的Weblogic Server来响应请求。

第1. 本帖内的书和简介都是转自网上卖书的书网,故在此向大家说明！
<<软件测试>>
作　者：[美]Paul C.Jorgensen译者：韩柯 杜旭涛
出版社：机械工业出版社 原出版社： CRC
图书简介：
一本同名的经典测试书籍。如果说上面那本的目的是快速的将你引入测试的殿堂，或者说作为一本“快速职业培训”的话，这本则是更深入的介绍了软件测试的基本知识和方法。其中重点介绍了黑盒测试（功能性测试）、白盒测试（结构性测试）的技术和方法，以及如何开展集成测试和系统测试工作。另外，书中还包含了对于面向对象测试的内容。这本书可以作为夯实测试基础的教材，建议阅读。
第2.<<软件测试>> 
作　者：（美）Ron Patton 译者：周予滨 姚静
出版社：机械工业出版社
图书简介：
我所见过的最好最经典的软件测试入门书，有一个别名叫“软件测试的本质”。书中没有讨论太多的软件测试理论，只包含了一部分常用的、基本的知识。从什么是软件测试、为什么要作软件测试开始，逐步引入基本的和高级的测试技术和方法，然后开始把读者引入实际工作中，讲述了一般的测试过程中要经历哪些阶段，要作哪些具体的工作，如何开展测试工作，如何找到缺陷并提交缺陷。甚至还包括了对测试人员的职业指导。建议所有的测试人员都读一读。

第3.<<软件测试自动化>>
作　者：Daniel J.Mosley, Bruce A.Posey/著
出版社：机械工业出版社
图书简介：
可以把这本书当做第一本书的延续——不过我指的是作用和风格，作者当然不是同一个人了——你可以把它理解为“软件测试自动化”方面的经典入门书。作者从实际工作的角度对自动化测试进行了详细的论述，包括应该何时开始自动化、测试自动化同软件开发过程中其他工作的关系，以及测试自动化工作开展的过程。还介绍了“自动化测试框架”。不过这本书最吸引我的，还并不是它将我轻松的引入了自动化测试的世界，它还在每个章节的后面提供了很多链接和文档资料，大都可以在网上搜索到和打开。配合这些资料的学习，更深一步的理解了自动化测试的本质。 建议准备学习自动化测试和已经开始尝试自动化测试的朋友阅读多几遍。

第4.<<有效软件测试>>
作　者：[美]Elfriede Dustin/著
出版社：清华大学出版社
图书简介：
虽然这本书国内也出了影印版，但是个人感觉中文版的质量还是不错的，从中也可以看出译者有着很深的软件工程实践功底。作为一本实践经验性的著作，书中涵盖了从测试过程到测试管理，从测试方法到测试技术，以及自动化测试方面的内容，所以要求读者应当具有相当的软件测试实际工作经验，否则只有理论知识恐怕也很难理解其中的一些做法，“知其然”却无法“知其所以然”。建议先看过上面介绍的四本书（或者至少前三本）并有了一些实际测试的经验以后，再来阅读这本书效果会好一些。你会在阅读的过程中发现，原来很多测试工作开展时遇到的难题可以这样解决，原来测试工作可以通过这样来提高效率…… 虽然这本书的内容并没有特别的依赖于某些测试工具，不过看的出作者和译者的工作大都是基于RUP的，所以如果读者有这方面的了解和实践经验，阅读起来效果会更好一些。

第5.<<自动化软件测试>>
作　者：[美]Elfriede Dustin等著
出版社：清华大学出版社
图书简介：
这本书虽然在国内也有中文版，我一开始看的也是中文版，不过限于中文版的质量，这里还是推荐有能力的朋友看影印版吧。 虽然书名中大主题是“自动化软件测试”，但是这本书中介绍的更多的并不是自动化测试的具体实现，而是侧重于测试过程和测试管理方面的内容，这也是因为自动化软件测试工作的开展必须依赖于一个完善的测试过程吧。 从某个角度来看，上述的三本书从测试技术、方法和测试过程几个方面都进行了详细的论述，可以作为逐步深入的“测试学习路线图”，先看第一本入门，然后通过第二本强化对测试方法和技术的理解，然后通过第三本来更深入、全面的理解测试过程。其实书不在多，如果但作为基础学习，找到基本合适的，然后反复的阅读、研究、实践，就应该足够了。

第6.<<国际化软件测试>>
出版社　： 电子工业出版社
作者　　： 崔启亮/ 胡一鸣/
出版日期：2006年4月
版别版次：2006年4月第1版第1次印刷
图书简介：
本书阐述了国际化软件测试的根本问题，深入剖析了如何有效进行软件国际化测试和软件本地化测试，旨在帮助读者学习和掌握国际化软件测试的概念、技术、流程、方法和市场状况，分享业界同行的最佳实践。
国际化软件测试主要包括软件国际化测试和软件本地化两个阶段。本书将围绕这两个主题深入、详细的进行论述。软件外包测试与国际化软件测试紧密相关，本书最后将对其进行简要介绍。
全书分为三个部分：国际化软件基础，国际化软件测试，软件外包测试展望。每一部分根据内容的逻辑性和重要性分多章分别论述一个主题，每章以概述开始，随后重点阐述专题内容，最后进行本章小结。

第7.＜＜软件测试的有效方法＞＞ [美]佩里 著，兰雨晴等 译
　　本书提供了两种可以改进软件测试质量的策略，一是对团队软件测试能力的评估，二是对软件测试人员测试资格的评价。本书介绍了一套软件测试的方法，这种方法对应于软件开发生命周期的各个阶段，用11步软件测试过程详细讲述了从制定测试计划到执行测试以及获得最终测试结果的全过程，并对测试策略、测试工具、测试方法、测试指标等具体内容进行了全面的阐述。另外，本书还对一些特殊系统，如客户/服务器系统、基于Web的软件系统的测试过程做了专门介绍，并提出了一整套的测试指标，使测试活动能够得到量化的结果，便于做出测试结论。　　本书内容丰富、实用性强，既可作为计算机及相关专业学生的学习用书，同时又可用作广大软件工程技术人员的指导用书。　　为了保证软件能够按照计划运行，我们就需要了解有关软件测试的技术。否则，可能会导致生产率下降、收入降低、顾客不满意等情况的发生。　　本书提出了一个11步软件测试过程，涵盖了评价软件的所有测试内容。这个测试过程包含了大量的工作表和检查单，可以直接采用或修改，以测试软件的各个方面。　　在组建有效的软件测试环境时，从制定测试策略到选择和使用测试工具，读者都可以从本书中得到非常有益的指导。本书还提供了—些改进软件开发过程和提高软件测试人员能力的方法。　　

   需要特别指出的是，本书在第2版中对以下内容给出了详细的测试程序：　　·Internet／Intranet应用　　·成品软件　　·多平台环境　　·系统安全　　·数据仓库应用　　·客户／服务器系统　　·快速应用开发　　本书较少谈及理论，而更多地去指导如何解决疑难问题，为软件测试提供了有效的方法。从而可以向客户保证生产出最可靠的软件。

在设置了自己的音乐盒，刚设置好了，首页音乐可以正常播放，但关闭IE后一段时间再进入就不能正常播放了，估计与session有关，我的音乐盒肯定有bug。不知道有谁也碰到这样的问题。