截至第13章，小白已经完成了LoadRunner测试脚本的编写、场景的建立，并成功地执行测试及分析了整个测试结果、产生了测试报告。本书对于LoadRunner这一强大的工具也已经基本介绍完毕了。但是，在实际工作中，性能测试工程师可能并不一定采用LoadRunner，而是使用其他的工具甚至自行编程来取得相关的性能测试数据。那么，有没有通用的一些分析性能测试数据的经验呢？

　　本章的内容就能够回答上述这个问题。如果说第12章中LoadRunner所提供的性能图表与测试报告是汽车中的自动挡，那么本章就是汽车中的手动挡。作为一名性能测试工程师，必须能够脱离工具软件的束缚，直接从原始的数据中得到正确的结论，才称得上合格。

　 　初学者都知道，性能测试得到的数据，如果不进行分析，得到的结果是没有多大价值的。而在分析性能测试结果的过程中，往往需要用到简单的数学知识来进行评 估、敏锐的观察能力来发现隐藏在数据中的性能问题；另外，出色的文档编写能力和图表制作能力则有利于将测试工程师了解到的事实有效地传递到相关人员的印象 当中。其中，工作中最重要、也可能是最耗费时间与精力、同时又是收获最大的部分就是发现性能问题。

　　本章将依据以上这几种能力分为3节来 介绍：第1节介绍判别测试数据是否可靠的要点，其中包含了一些简单的统计学知识。第2节通过几个范例来讲解发现性能的技巧与经验。第3节将列出编写性能测 试报告的注意事项与要点，同时，对Office Excel软件中的画图功能也进行了较详细的说明。

　　14.1  性能测试结果的可靠性

　 　性能测试的结果往往由大量数据组成，在我们拿到这些数据之后，首先要判断这些数据是否可靠。一些简单的统计学指标可以使我们很快地从数据中获得对于性能 的基本印象。因此，本节先借助一些数学知识，让我们能够使用统计学上的简单指标对结果进行简单归纳；之后，再介绍判断性能测试结果可靠性的几条经验规则。

　　本节中将要介绍、同时也是测试结果分析中较为常用的数学指标有如下几种：

　　平均值（Mean Value）；

　　中值（Median Value）；

　　正常值（Normal Value）；

　　标准偏差（Standard Deviation）；

　　正态分布（Normal Distribution）；

　　一致分布（Uniform Distribution）；

　　置信区间（Confidence Intervals）。

　　为了理解方便，我们就使用小白获得的一手响应时间作为例子，学习如上数学指标的具体含义，从而获得总体性能的更直观印象。

　　14.1.1  原始数据

　　小白手中有关公司网站响应时间的数据一共分为4组，分别代表了客户端不同操作端系统、不同浏览器下访问首页的数据，分别如表14-1、表14-2、表14-3、表14-4所示。

　　表14-1  Windows XP下通过IE 6访问公司网站的响应时间数据（秒）

　　表14-2  Windows XP下通过Firefox 3访问公司网站的响应时间数据（秒）

　　表14-3  Windows Vista下通过IE 7访问公司网站的响应时间数据（秒）

　　表14-4  Windows Vista下通过Firefox 3访问公司网站的响应时间数据（秒）

　　从以上数据来初步观察，响应时间长短参差不齐，表面上看分布也没有什么规律。

　　所谓平均值（Mean Value），就是把所有数值都相加，然后除以这些数值的个数。平均值也叫做算术平均数。平均值对于某类数据是非常有用的，比如考试成绩，年龄数据等。但是，在14.1.1所举出的数据来说，平均值并不能说明问题，甚至会隐藏可能的性能问题。

　　【实战演练：平均值的计算】

　　比如，在14.1.1的4个表格当中，就平均值来看，表现最好的应该是表14-2。这是因为，表14-1、表14-2、表14-3、表14-4的平均值依次为：

　　（5+6+4+8+13+10+4+4+5+7+8+10）/12 = 7；

　　（1+12+5+7+8+2+2+4+12+13+1+1）/12 = 5.67；

　　（6+6+6+8+12+12+14+4+8+6+6+6+6）/12 = 8.33；

　　（6+6+7+8+8+7+6+6+9+6+11+9）/12 = 7.41。

　　以上数值的单位均为秒。从结果中可以发现，表14-2响应时间的平均值确实是最短的。但是，需要注意的是，表14-2中的数据"两极分化"比较 严重，既有很短的1秒，也有很长的13秒，而在平均值5.67秒附近的数值却很少。这样的情况就可能暴露出网站性能的某些问题，或者是数据采集中的不科学 性。

　　读者在实际工作中得到测试结果的时候，不能单单记录数值，同时还要思考如下等问题：

　　响应时间很短是否由于缓存的缘故？

　　响应时间很长是否是Web应用代码的问题？

　　不同浏览器的响应时间有什么规律？

　　在测试过程中，对得到的数据多问几个为什么，有助于提高测试的准确性。

　　14.1.3  中值

　　中值的引入能够发现部分14.1.2节中表14-2中的数据问题。

　　【中值是什么】

　　所谓中值（Median Value），就是将数据从小到大排列起来，中间那个数的数值。

　　将中值的定义应用于实际，比如对于表14-1来说，其数据从小到大的排列依次为：

　　如果这一系列数据的个数为单数，中值就是中间那个数的值。如果类似表14-1的情况，数据个数是12，为偶数，则中值一般认为是最中间两个数值（这里是第6个和第7个）的平均值，即（6+7）/2=6.5。

　　经过计算，表14-1、表14-2、表14-3、表14-4的中值分别为6.5、4.5、6和7。

　　【中值与平均值的关系】

　　中值虽然不等同于平均值，但若中值与平均值越接近，则说明数据分布的越均匀。

　　14.1.4  正常值

　　正常值（Normal Value）并不一定意味着它的值是正常的。所谓正常值，是指在数据结果中出现频率最多的那个值，通俗地说，就是在它们中间最容易碰到的数值。表 14-1、表14-2、表14-3和表14-4中的正常值分别为1、4、6、6秒，可见，正常值与平均值、中值可能会有很大差别。

　　【实战演练：正常值的判断】

　　设想这样一个场景：小白所测试的Web应用有某部分代码出现了问题，导致数据库连接经常超时，测得的响应时间序列为20、25、30、26、 26、27、26等，在这样的数值当中，26是正常值，但它绝不是网站正常时应该具备的响应时间，因此，它又是"不正常"的。实际工作中这样的情况并不鲜 见，读者在处理数据时一定要首先保证数据的有效性。

　　性能测试中正常值的意义在于发现当前配置下，多数情况采集到的数值是什么。

　　14.1.5  标准偏差

　　标准偏差提供了比中值更准确的方法，来确定数值是否"聚集"在平均值附近。标准偏差（Standard Deviation）是一种度量数据分布分散程度的标准，它可以用来衡量具体数据值偏离平均值（算术平均值）的程度。标准偏差越小，这些值偏离平均值就越 少，数据就越可信。反之，数值偏离平均值越大，数据就越不可信。

　　【实战演练：Excel计算标准偏差】

　　标准偏差的计算不是本书讲解的内容，我们只需理解它的含义会用工具计算就可以了。常见的计算标准偏差的工具软件就是微软的Excel。如图14-1中新建了一个工作表，其中有4列，每一列分别包含表14-1到表14-4的测试数据。

　　下面举例计算前面表14-1中数据（已经录入在图14-1工作表的A列之中）的标准偏差。首先，单击工作表中的A列，然后选择"插入"|"函 数"命令，如图14-2所示。之后Excel将弹出函数选择对话框，在其中找到计算标准偏差的STDEV函数即可，如图14-3所示。

　　计算标准偏差需要输入一系列的数值，这也是在图14-2中要首先选中A列或其他列的原因。在图14-3中单击"确 定"按钮之后，Excel将弹出函数参数对话框。如果其中的Number1文本框内没有数值，读者可以填入文字A1:A12，以表示A列的所有12个数值 作为计算的输入，依次类推。确认输入数据无误后，单击"确定"按钮，计算结果将立即显示在当前的对话框内，如图14-4所示。

　　通过前文这样的方法，依次可以得到从表14-1到表14-4所包含测试数据的标准偏差，分别为：2.8919、4.6384、3.1285和1.6213。根据前面所介绍的"标准偏差数值越小数据越值得信赖"原则，很显然，表14-4所包含的数据更具有可信度。

　　对测试结果进行标准偏差的计算，有利于从中发现更具可信度的度量数值。

　　正态分布（Normal Distribution）也叫做钟形分布，这个名字是因为正态分布的数值在图形上类似一口钟而得来。它的含义就是一系列的数值当中，靠近中值附近的数值 数量最多，而偏离中值的数值数量则不断减少。人类社会的很多行为都符合正态分布的特点，我们常说的"随大流"也可以说是一个体现吧：大多数人的行为都是非 常类似的。

　　一个典型的正态分布图如图14-5所示。在性能测试产生的数据中，足够大量的响应时间具有正态分布的特点。

图14-5  正态分布（钟形分布）示意图

　　【正态分布与标准偏差的关系】

　　正态分布与标准偏差有很大的关系，一般来说，标准偏差越小，数值越接近正态分布。因为正态分布存在非常普遍，所以才拥有了Normal这样的名字。

　　14.1.7  一致分布

　　一致分布（Uniform Distribution）顾名思义是指测试所取得的数据值相差很小，简单粗略地看，在图中会表现为波动很小的近似直线，如下面的情况。

　　【实战演练】

　　小白所在的公司每周要发送一个邮件列表给注册用户，该列表的内容实际上是一个由市场、销售部门HTML页面。由于发 送程序运行在数据库服务器上（因为每周一次，也是周日晚间发送，所以暂时没有必要使用专门的服务器来完成），为了不显著影响整体性能，需要对HTML页面 的大小进行限制。为此，小白记录了若干次的文件大小，如表14-5所示。

　　表14-5  每周邮件列表文件大小

　　如果在Excel中对表14-5所列出的数据画成图，就可以看成是一致分布，如图14-6所示。

图14-6  邮件列表内容文件大小呈一致分布

　　每次邮件列表大小基本一致，是因为市场、销售部充分利用了文件大小的上限，尽量争取在有限的大小之内，放入更多的宣传内容。当然，在实际工作情形中，不一定每次都会出现这样的情况。

　　如果在性能测试中出现了一致分布的数据，测试工程师需要找出原因，一般来说，这样的数据反而是值得怀疑的。比如响应时间，如果用户的响应时间惊人的一致，则要考虑是否有部分用户因为某些原因根本无法访问网站等原因。

　　14.1.8  置信度与置信区间

　　在性能测试领域，置信度指的是测试结果与真实结果之间的差别。由于具体的测试结果是由用户使用Web应用方式的估计模型和性能测试方法决定的，因此也可以认为置信度反映了网站人员与最终用户在使用该Web应用上的相似度。

　　【置信度举例】

　　举例来说，小白所在公司的人都认为用户将更喜欢网站的A栏目，因此在资源有限的情况下，测试部对该栏目的功能进行了重点性能测试，并进行了优 化，获得了不错的结果；但实际网站上线后，用户却更喜欢另外某个栏目，经常使用的功能也与事先预想的不同。这就会导致性能测试结果与实际性能测量值有所误 差。这种误差大小的程度就是置信度。当然，这样的理解在数理统计方面并不严格，但对于性能测试工程师在工作中的使用已经可以了。

　　置信度越高，置信区间（Confidence Interval）也就越接近真实值的范围。置信区间是指在某一置信度水平下，性能测试结果与Web应用上线后实际运行结果间的误差范围。要知道在Web 应用上线前，没有谁能准确地预计用户行为，因此有必要在进行性能测试时预估一个置信度，再根据结果得到置信区间。

　　【置信区间的实际使用】

　　假设公司对网站响应时间设置的合理值为10秒以下，置信度估计为80%。小白在对网站使用LoadRunner进行并发测试后，发现：由于使用 页面功能不同，最差的情况一次并发50个用户就可能令第51个用户响应时间超标；而最好的情况则是一次并发300个用户才能令响应时间超标。那么，在测试 结果报告中，小白应当这样进行陈述：根据80%置信度，在一般工作负荷下，并发数为50×80%到300×80%，即40～240个用户，都不会引起响应 时间超标。这里的40～240就是置信区间。

　　综上所述，置信度也可以理解为一种形式的安全系数。

　　14.1.9  数据可靠性判断的规则

　　前面讲述了一些统计学的知识，实际目的都是为了使得我们的性能测试报告能够更接近于真实，这样才能发挥最大的作用。因此，在测试结果出来之后，并不要立刻发送测试报告，而是要先判断取得的测试数据是否可靠，这样的能力对于性能测试工程师来说是非常必要的。

　　数据可靠性有如下几条经验规则：

　　（1）如果有超过20%的测试数据明显与其他数据有很大差别，则应该先检查测试过程中是否出现问题。这样的情况是经常发生的：小白使用很多台测 试机器在下班后运行自动访问公司网站的脚本程序，从而记录响应时间等数据。但由于其中某些机器设置了Windows系统默认凌晨3点发生的自动更新，可能 会强迫重启电脑，从而导致测试中断，在重启过程中取得的响应时间数据当然是不可靠的。

　　（2）如果进行了多次相同目的的性能测试，如果某一次测试绝大多数结果比其他几次测试中最大的结果都要大，或者比它们当中最小的结果都要小，那 么应该考虑这次测试结果的有效性问题。这一点是很好理解的。至于绝大多数的比例设定为多少，可以根据实际情况来定，一般至少在75%以上。

　　根据以上这两条基本原则，再结合具体被测试软件的实际情况，就可以判断出哪些数据是可靠的，哪些数据是不可靠的。有了可靠的数据，才能编写出可靠的测试报告，这是最重要的一点。

　　在14.2节，本书将简要介绍性能测试结果的分析方法，这是性能测试报告的关键。

　　（未完待续）

相关链接：

捉虫记--大容量Web应用性能测试与LoadRunner实战(连载一)

捉虫记--大容量Web应用性能测试与LoadRunner实战(连载二)

捉虫记--大容量Web应用性能测试与LoadRunner实战(连载三)

捉虫记--大容量Web应用性能测试与LoadRunner实战(连载四)

捉虫记--大容量Web应用性能测试与LoadRunner实战(连载五)

捉虫记--大容量Web应用性能测试与LoadRunner实战(连载六)

　　关键字：敏捷开发；测试模式；TD；QTP；

　　（一）前言

　　敏捷开发是一个迭代的、增量的、需求频繁变更的过程，客户每周都希望看到新变化，而这些变化最直观体现给客户的就是产品功能的增减，这种非常短的循环，使终端客户可以及时、快速地看到他们花钱构建的软件是一个什么样的结果。因此直接做成可以工作的软件比大量的描述性文档更有效。

　　正因为敏捷开发的特殊性，敏捷开发的测试无法像传统测试那样：项目初期根据详细的需求文档、设计文档来设计测试用例。因为最初的需求只是一个雏形，甚至连界面也没定，做成什么样子，有什么样的功能开发也不能确定，只能一步步的与客户确认和修改才能定下来；因此用例设计只 能通过产品写用例；即先根据简单的需求写出用例的框架，然后拿到产品后，一边添加测试用例一边进行测试。同时敏捷开发的测试模式与传统测试模式不同的还有 一个方面，那就是包括PM、开发人员等也都会一起投入测试。提高系统质量是个Team work，在开发过程中每个成员都有责任提交高质量的软件交付物（需求、代码、设计文档...），尤其我们团队的“敏捷开发”的项目中，我们还面临人员缺 乏、项目多而分散的背景，更加需要整个团队都必须积极投入到测试过程中，PM、DEV、测试都需要积极参与测试和项目的质量保证工作。

　　（二）介绍新型的测试模式

图1 敏捷开发测试模式

　　从图1 不同的环中表示不同的敏捷实践，外环主要是开发的角度，内环为测试的角度。

　　测试计划和用例：在测试初期，主要是审核用户需求（FRD）定义的完整性、严密性和功能设计的可测性，然后根据用户需求设计测试计划。测试计划主要说明，（1）测试资源：在测试过程中需要的软件（包括操作系统，补丁版本，数据库版本，被测软件版本，还有诸如打印机、扫描仪等外部信息）和人力资源；（2）测试内容：测试的功能点，测试的类型（功能测试，性能测试， 安全性测试，压力测试等）测试的方法，哪些可以自动化测试，哪些需要手动测试。如果是后期，主要是设计测试用例，包括性能测试用例，功能测试用例以及界面 测试用例。同时完成配置库的配置，平台的搭建等内容，如一些管理工具（CQ，TestDirector，SVN）以及用户分配等。这个阶段主要输出：测试 计划和测试用例。

　　更新测试：如果是在迭代（发布不同版本）过程中，客户可以根据上次所提供的产品做出一些新的合理的变更，这时我们需要根据变更来更新测试用例。准备在下一个版本中进行测试，也是新版本测试的重点。

　　执行测试：这时的测试主要分为两大类：接口测试和功能测试。接口测试推荐开发人员在提交代码前直接运行自动单元测试脚 本来验证。功能测试：新功能代码提交后，由测试人员单独执行，首先会验证需求文档中的基本功能，一旦出现问题，那就说明开发人员的实现违反了最初客户定义 的需求，应及时向开发说明问题，并且和客户沟通，确认开发和测试理解是否一致。之后再进行其它全面的功能测试，那么测试人员要及时与开发人员沟通。同时提 交缺陷并且跟踪。这个阶段输出的制品是：本版新的测试用例的执行，缺陷记录。

　　自动化测试：主要用于回归测试阶段。在发布周期中，随着功能的不完添加与完善，回归测试的任务也就越来越重，同时也是必不可少的。

　　实际参与测试的敏捷开发项目是Webpos。该项目就是采用的敏捷开发的模式：接受客户频繁的需求变更来适应变化；经常性地交付可以工作的软件，交付的间隔一般为一周。这就要求测试组在短期内迅速的对应新增或者变更的需求进行验证测试。我们采用的测试流程如图2：

　　敏捷开发web项目测试流程

图2 测试流程

　　在WebPos 项目的测试中，贯穿全部测试的主要是新增功能测试和回归测试。测试执行的一开始可以是针对部分功能的，之后可以逐步扩展。接着开始采用迭代的过程完成测试 任务，即将测试任务划分为多个周期，一开始可以做些关键的功能性测试，可以对代码中的可复用部分（组件，构件）做完整的测试。接着的迭代周期可以做边缘化 的功能测试和其他测试，最后的几个迭代应该用于回归测试，和关键的性能和稳定性测试。特别是回归测试尤为重要，最好的方式就是采用自动化测试工具来提高测 试效率。因此我们引入了测试管理工具TestDirector 和自动化测试工具Quick Test Professional（QTP）。这样在每次发布版本时，TD 上面可以建立一个新的测试集。如图3 所示。

图3 TD 测试集

　　导入自动化测试脚本，运行完毕后对回归测试结果进行分析。自动化测试结果如果出现错误，一般是两个原因：一是程序本 身就存在缺陷，二是由于测试脚本错误的原因。测试人员可以通过错误结果分析出错的原因：程序本身的问题就提交给开发人员进行修改；若是测试脚本的问题，则 由测试人员自己修正测试脚本。执行完毕后，可以将执行结果导出保存为回归测试记录。

图4 功能测试流

　　自动化测试用例也是通过TestDirector 来管理，可分模块和功能来管理，不同的测试人员也可以随时添加和更新测试用例的脚本。在执行测试阶段中，测试人员需要对已有的测试用例进行及时的维护。通 常以下两种情况下要新增一些测试用例：一是对于当初测试设计不周全的领域，二是对于外部的Bug（比如从客户报告来的），没有被现有测试用例所覆盖。当产 品的功能设计出现更改时和现有的功能需求同步。如下图5：

图5 自动化测试用例

　　测试结果的分析同回归测试结果分析。

　　在每一次提交版本后，把开发人员和顾客代表包括进来，不要只是测试员自己做测试，开发也和测试人员一起测试新的版本。计划在每个迭代中探索产品，寻找bug、遗漏的问题和改进的机会。

　　（四）新型测试模式在敏捷开发中的优点

　　1、可以快速对应频繁的变更。

　　由于敏捷式开发持续地改进设计，以便于每次迭代结束生成的系统都具有最适合于那次迭代中需求的设计。那频繁的变更和版本的发布，只能通过自动化测试来保证已经确认的功能，而新功能和需求的测试成相应版本的重点。

　　纯粹的自动化功能测试，而不是手工测试。即使测试用例有上千个，自动化测试也可以每天可以回归几十次。而手工测试如果要回归，将花费大量的人力和重复劳动。

　　也许，测试最重要的好处就是它对于构架和设计的影响。为了使一个模块或者应用程序具有可测试性，必须对它进行解耦合。越是具有可测试性，耦合关系就越弱。全面的考虑验收测试和单元测试的行为对于软件的结构具有深远的正面的影响。

　　（五）新型测试模式的不足

　　1、频繁的变更，对自动化测试架构提出了更高的要求。

　　由于自动化功能测试是基本UI 的测试，如果是频繁的变更，不便于自动化脚本的维护。那么这就对代码的架构提出更高的要求，怎么样让自动测试脚本快速对应变更？开发人员在设计初期就应该 考虑到测试先行的问题，就应该有不同于普通的系统架构方面的权衡，而不是在进行迭代后，使用自动化测试工具出现很多问题之后，才发现架构的问题，这时的人 力、物力的浪费都是很巨大的，在Webpos 项目中，就是因为没有考虑到这个问题，导致自动化测试脚本在每次版本变更后对应起来非常困难，甚至在项目中期因为可扩展性差的问题而重新进行架构设计，造 成了大量的人力成本的浪费。

　　2、如果太多依赖客户，影响我们在客户心中的信誉度。

　　由于敏捷开发中频繁变更的需求都是从客户那里获取的，所以对于一些建议性方面的bug 是否该提，测试人员的立场非常尴尬。因为开发人员不愿意为了这些建议性的问题来增加工作量，特别是这些问题客户可能并未提出。时间久了就会对测试人员产生 抱怨。这样，测试人员的积极性也会被降低甚至从此不再关注此类问题；但是对于客户来说，遇到此类问题就可能会抱怨为何测试人员没能及早发现而遗留到最终用 户手上。

　　3、由于自动化测试，对测试人员提出了更高的要求。

　　敏捷开发的测试人员不但要熟悉开发语言、自动化测试工具，能够编写自动化测试脚本或者用工具录制，而且要参与项目和系统的需求分析和架构设计 中。但是对于目前实际的项目，测试人员只是被要求进行验收测试，并没有被要求更多的思考需求的可实现性，也没有将自身作为第一用户参与项目和系统的需求分 析，设计和开发。当然这也是很多敏捷开发项目中测试人员甚至开发人员都无法达到的水平。这也是我们今后努力的方向。

　　（六）改进

　　无论是传统开发的测试模式，还是新型开发的测试模式，目的都是为了保证产品质量，达到客户满意。对于目前实际项目来说，目前仍旧需要持续改进的就是：

　　1、系统架构的设计应该充分考虑测试的需求和可测试性。

　　2、测试人员加强主流测试工具的学习，提高测试水平，并且积极的参与到项目讨论及客户交流中去。

　　希望能通过我们的持续改进，使我们的团队充满激情和活力，能够适应更大的变化，做出更高质量的软件。

　　多通道 描述的是具有多个界面的应用程序。随着我们从桌面发展到基于 Web 的计算甚至是移动计算，多通道越来越常见。由于设备（平板、手机、 笔记本电脑、台式计算机）以及与设备交互方式（特定于设备的 “应用程序”、浏览器和传统的客户端应用程序）的组合，同一个应用程序的界面越来越多。比如，使用相同业务逻辑的面向 Web 应用程序、移动应用程序甚至是一个 CLI（命令行界面）的银行应用程序。由于面向服务的架构 （SOA） 和 Web 服务日益流行，在很多情况下，集成者要做的工作就是把服务与新的前端重新组合。但业务逻辑（亦称服务）则保持相同。

　　以开发团队重用代码来减少维护成本并提高生产效率相同的方式，要跟上开发团队，测试团队就需要一些方法来重用测试场景并实现自动化。

　　应对多通道测试的挑战

　　几年前，我是一名自动化测试架构师，负责为具有多个界面的两个（而不是一个）应用程序构建所有的自动化。二者都有遗留的 “本地” 用户界面，使用的是 Microsoft Windows 32 位 MFC （Microsoft Foundation Class） 控件、一个使用了 JavaScript 的 Web 界面、ASP 和 JSP（Active Server Pages 和 JavaServer Pages）、一个新的（更新的）Eclipse SWT （Standard Widget Toolkit） 界面以及一个命令行界面。当然，不可能找到对所有这些界面均有效的自动化工具，但我们可以暂时将其放到一边。

　　编程时，您往往会专注于通 过促进重用减少需要维护的代码量。有了面向对象的编程和重构，很少有理由需要在多个地方具有相同的代码了。但是需要设计一个架构，这样我就可以考虑如何从 一个单一的测试自动化代码库解决多个界面的测试。首先，尽管它们是同一个应用程序的所有界面，但并不是所有的界面都会浮现相同的功能，更不用说使用同样的 方式了。但也有许多以客户为中心的场景（用例），这对跨所有界面进行测试很有意义。

　　然而，负责设计测试用例和测试计划的测试团队没有以这种方式考虑他们的测试。事实上，他们是分离的，并根据他们所要处理的界面以竖井方式分离。构建并测试了该 CLI 的团队认为他们只需要少量的客户场景测试。他们主要集中于单元测试， 并没有真正考虑通过 CLI 的一个客户流。负责 Eclipse UI 的测试团队想要大量的 UI 特性和自动化的功能。他们有一长串需要执行的测试用例，要实现这个目标，需要完全专注于客户流。但是，我们为什么就不能使用由主题专家 （SME） 为应用程序煞费苦心完成的用来测试所有界面的这些信息呢？

　　一种层次结构方式

　　使用 面向对象的编程 （OOP） 的典型测试自动化框架一般会抽象化控制集的实现细节，而不是通过控件表达的概念性操作。这实际上是许多商业 GUI 自动化工具使用的方式。例如，所有文本字段会接受文本，用 setText（string） 方法定义一个文本字段类，并在此应用程序的所有版本上使用它。但这并不适用于跨界面构建自动化测试的所有情况。当一个 GUI 使用单选按钮而另一个使用复选框时会发生什么呢？您实际上不能对于相同操作依靠于同一界面。以下显示了这种传统的 OOP 方式。

图 1. GUI 控制层次结构

　 　在我们的示例中，界面的差异很大，但所代表的操作和业务流程则实质上相同。为了最大化重用，我们选定了一个业务逻辑层次结构（参见图 2）以跨多个界面重用测试场景。这不仅能最大化我们的代码重用，还意味着将会依赖测试工具来管理 GUI 界面，而这正是他们的设计初衷。图 2 显示了此方式，您可能已经识别出了这个抽象工厂模式。

图 2. 业务逻辑层次结构

图 3. 抽象类的代码示例

　　Query 是一个抽象类，收集创建和执行查询所需的有趣数据，以及有趣操作，如运行、创建、编辑和重命名。重命名方法需要新名称的额外参数，但当它成功后，会自动更 新此查询对象的名称值。在这个级别对用户界面没有假设。用户界面的细节只在特定于界面的具体类内表达。要在一个给定的界面上执行，需要在运行时为每个界面 实例化一个具体类并调用此操作，具体类似于如下所示：

　　基于应用程序的框架

　　定义用来描述测试所需操作的抽象业务逻辑类的一个后果是可以将所定义的方法重组成新的流。此外，还可以指定在运行时运行哪个界面。这是一个强大的组合，可以完成几件事情：

　　● 针对此应用程序的操作只定义一次

　　● GUI元素只被发现和处理一次

　　● 为一个界面设计的测试场景可以在另一个界面上运行

　　● 因重用的增加，维护显著减少

　　当然，这其中的诀窍是在每个要测试的界面内如何对任何给定的操作进行编码。这需要面对大量的工作，但在一个界面完成后，有许多测试脚本可用于任何其他的界面。而这就是必须为每个后续界面要实现的全部步骤：

　　● 添加在该界面上执行操作所需的实际步骤

　　● 补充此框架来涵盖其他界面内所没有的任何功能

　　清单 1 是与 Eclipse 视图交互的一个示例代码。

　　清单 1. 与 Eclipse 视图交互的代码

　　采用这种方法可以降低维护成本，并能确保对于 GUI 的任何部分，在自动化测试代码内都只需在一个地方进行调整。但这种方法的好处只有在 CLI 上实现了进行业务逻辑的具体步骤之后才会变得真正清晰。

　　负责测试该特性的团队已宣布 “完成”，且没有明显的缺陷。自动化的实现是为了为未来版本确保一个回归测试套件。但是当我们运行用来针对此 CLI 实现测试 GUI 的测试脚本时，就会发现 50 多个缺陷！这些都是重要的缺陷，肯定会被我们的客户发现。

　　作为测试人员，我们总是很兴奋能首先发现缺陷，因为早期发现问题能明显节约成本。另外，构建不只能验证产品稳定性的测试自动化也很令人兴奋。同样重要的就是信誉、既有的顾客满意度，以及此测试自动化所带来的整体质量改进方面的商业利益。

　　如今的多通道测试

　　在上述的项目过程中，我们可以在运行时只选择一个界面。一个测试脚本必须是完全自动化的，且必须要有为每个需要测试的界面实现的一个完整的业务 逻辑操作集。这种方式在当时是合理的也是可以接受的，这是因为最终用户一般不会在一组操作期间从一个桌面客户端切换到一个 Web 客户端。

　　但时过境迁。现在考虑一个可能开始于 Web 客户端、穿过一个移动应用程序、然后再回到 Web 的测试场景，甚或是一个针对数据库后端的独立验证已不再符合实际了。

　　考虑这样一个场景：有人在 eBay 竞价。使用一个台式计算机和浏览器（Web 客户端）对商品进行搜索和研究更容易。一旦决定了想要的商品，就可以进行竞价。您可以离开计算机，并在您的智能手机收到一个通知，告知您竞价胜出，于是您 从手机上更新出价。当赢得竞价时，您再回到计算机前，在浏览器中输入付款信息。

　　这是一个测试场景，与其从屏幕上此界面的一个部分（使用屏幕抓取或对象属性）中验证交易的成功，还不如直接使用数据库并检查记录。这种独立于界 面的验证更健壮，也更稳定。我们可以把这种方式称为 “混合” 测试场景。并且，从理论上来说，当自动化一些产品区域太难（或过于昂贵）时，混合场景应该允许混合进手动测试执行来提高测试覆盖率。

　　所以，我已经开始幻想如何能实现这样一个流，于是我将不同的界面和操作实现拼装成一个能在界面之间无缝移动的复杂流。可以肯定的是，的确存在挑 战，并且挑战可能会不可逾越。而了解了当运行时环境受制约时哪些数据在操作间移动则会相对简单得多。而当跨越界面时，哪些数据可能需要在操作间传输则不能 立即清晰。使用上面的示例，将需要先登录到一个 Web 客户端和移动电话。身份验证明显是个问题，但实现这些混合测试场景注定会有很多并发问题。

字体:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿  | 推荐标签： Bug 软件测试 缺陷管理

　　微博上抛出一个讨论话题：下午一test lead问到，有些测试的 bug会在A版本里出现，然后记录它；但开发人员在当前B版本试图重现时发现不能重现，故reject它。那么测试就郁闷了，待到下一轮回归测试可能是C 版D版本，如果再出现自然reopen，但如果不复现是否真的应该关掉它吗？各位对这种sometimes bug怎么处理的啊？

　　这个问题可能每个测试人员都会遇到，我说说我个人观点，供大家讨论。

　　1、在A版本发现的bug应该在A版本进行重现

　 　我们知道，有很多原因会导致A版本的bug可能不能在B版本重现：1）开发人员自己偷偷解了bug，以免受到KPI考核；2）环境差异，可能B版本的代 码在A版本的环境也会出问题，但是在开发环境可能就不能复现；3）代码变更，也许是其他的代码引起的bug，B版本时其他开发已经修改，此类可以归纳为相 关联功能引起的bug；4）AB两版本进行复现的前置条件及步骤已不同。

　　既然有这么多可能性，那我们就应该排除影响，让问题简单化，保持环境和代码一致的情况下进行复现。A版本的bug如果在B版本不能复现，时间和条件允许的话，那就回退代码到A版本，有个前提不用回退，那就是已准确定位问题了，并且确定在B版本已经解决它了。

　　2、项目时间允许的情况下，开发人员应大力协作复现bug

　　对于”疑难杂症“，开发人员应大力配合测试人员进行复现：1）如果对于不好调试的代码就打印更多log；2）可以通过连接测试环境数据库并 回滚代码到A版本，根据获悉的已有情况添加断点调试代码；3）做更细致的code review等等方式。在自己负责的那部分代码确定完没有问题，这时候就需要考虑到接口，是否在接口数据处理上的问题，就需要其他开发人员配合。而测试人 员需要尽最大努力来还原当时的场景：环境，数据，前置条件及测试步骤等。

　　3、测试人员要再次确认用例设计的覆盖度及周密性

　　有几种情况会导致不可复现：1）环境；2）代码；3）数据。而数据又可以归纳到代码容错性处理上，环境其实是可以很好还原的，那出现不容易复现的bug就大多数是归于代码和数据上了，对于测试而言，用例设计的覆盖不够，不够严谨就会导致bug不在我们的掌握中。

　　这个时候，我们有两种情况：一是原本用例就没有好好设计过，未经评审过，大家测试时就很随意，勿容置疑，赶紧把用例好好琢磨琢磨，再叫上项目相关人员进行评审，这么做的目的也是为了保证测试用例得到了项目相关人员的认可，各种情况大家都讨论过，保证在需求上大家的一致性，保证软件覆盖度能满足本次项目需求的要求，做到需求100%覆盖，开发人员若再提出更多建议，那也可以弥补一些黑盒测试时可能遗漏的情况；二是该项目已经经过严格的需求评审及用例评审了。当然，即便如此也不能避免漏测以及对特殊情况的考虑。

　　当然，要这么做的前提是这个bug很严重，影响了版本的发布，有必要召集大家协力解决掉它。

　　4、绞尽脑汁，它仍然不能复现时，保持关注

　 　我相信，通过以上步骤的努力，仍然不能复现的bug一定是优先级不高的，那就再评估重要度，若通过项目组决定不影响版本发布，就密切关注此bug，在发 布后验证时也重点关注下。而且该bug不能关闭，依次往以后版本中顺延，并且每轮测试时都要尝试再次复现。那何时可以关闭呢？也许3，5个版本发布后，没 有出问题就可以决定关闭它了。

　　5、思考测试流程及测试规范，及时更正走过的弯路，制定提交bug的规范，便于开发及我们自己复现

　 　有一次，就会有第二次，我们应该及时响应，即便不能亡羊补牢，也要防患未然。 提交bug的规范，这个可能每个公司情况不一样，有些公司木有限制，提交的bug也是千人千面，这对于开发人员理解bug和复现bug无疑增加了难度。而 规范了bug提交，若记录了此bug的前置条件，使用的数据及操作步骤，可能会大有益处。当然，此处不是说每个bug都这么详细。

版权声明：本文出自 zzzmmmkkk 的51Testing软件测试博客：http://www.51testing.com/?258885

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。

　　随着计算机软件技术的发展，各种计算机软件种类繁多，功能各异，加上计算机软件规约的约束和发展，软件的规范性变得更加重要。为了开发合格的软件，在软件开发过程中，离不开软件测试。为了更好的完成软件测试工作，在软件测试过程中进行配置管理和版本控制尤为重要。

　 　本文首先介绍了软件测试过程中的配置管理概念和版本控制概念，然后对软件测试过程中的配置管理和版本控制做出了详细分析，论述了配置管理的流程、方法意 义。接着介绍了版本控制的评价标准，软件测试过程中版本控制方法的应用及几种版本控制软件，最后阐述了在软件测试过程中的版本控制的作用，以及怎样有效的 在软件测试过程中进行软件测试版本控制。

　　关键词：软件测试；配置管理；版本控制；

　　1、软件测试的基本概念

　　在现代社会，随着计算机时代的到来，计算机的应用已扩大深入到社会生活的 方方面面，而随着计算机技术和计算机软件的不断发展，软件的规模日趋大型化和复杂化，致使软件开发中的软件测试工作变得越来越繁杂，工作量越来越大。为了 更好的对软件测试进行控制和管理，节约时间、人员、成本等，软件测试中的配置管理和版本控制随之产生。对软件测试中的资源如何调配，人员如何配置管理和控 制成为我们更加关心的问题。

　　对此，为了理解软件测试中的配置管理和版本控制，我们先了解软件测试的概念和意义。当我们清楚的认识到为软件测试的作用和意义，我们才能更加清楚的认识到软件测试过程中的配置管理和版本控制的重要性。

　　1.1 软件测试的概念

　　软件测试作为软件开发过程中的重要组成部分，是用来确认一个程序的品质或者性能是否达到开发之前所提出的一些要求。换句话讲，软件测试就是为了发现程序中的错误而不得不进行并且不可避免必须要执行的过程。

　 　从一个软件的立项之初，软件测试工作就将开始，并且将会贯穿整个软件开发过程。首先了解下测试人员的任务：寻找bug，避免软件开发过程中的缺陷，衡量 软件的品质，关注用户的需求。通过了解测试人员在测试过程中的任务，我们就会对软件测试产生一个大概的了解。进行软件测试工作的最终目的是什么呢？目的其 实只有一个就是要确保软件的质量。满足用户的需要，使用户对软件质量产生足够的信心。

　　1.2 软件测试的分类

　　软件测试是一项复杂而又细致的工作，作为计算机科学的一门学科，它自有其独到的作用和规则。软件测试从产生一直发展到如今，已经拥有了很完善的软件测试理论体系和知识概念体系。如今，软件测试大致分为功能性测试和性能测试，其中又包括手工测试和自动化测试。 随着软件测试工作的日益繁杂和工作量的加大，手工测试不再能够满足测试需求，因而自动化测试越加显得重要。我们之所以做这么多工作，都是为了检验程序是否 满足规格需求说明书，能否满足用户需求，或者预期结果与实际结果之间的差别。通过了解软件测试的分类，我们知道软件测试在软件生命过程中的重要性和不可或 缺性。

　　1.3 软件测试的国内外现状

　　为了了解软件测试在国内外的现状，我们经过 深入调查了解到，随着软件开发的日趋成熟，国内外的软件企业逐步认识到软件测试在软件开发过程中的重要性。软件测试受到国内外软件企业越来越多的重视，纷 纷不约而同的加大了对软件测试的投入。我们先看两组数据，2007年中国软件企业对软件测试的投入为：1%一下：24%；1%-5%：34%；5 %-10%：22%；10%-30%：16%；30%以上：4%。我们再从微软的 项目人员比例上看：Windows200 Team：程序经理 450，开发人员 900， 测试人员 1800，技术支持人员 600， 技术传播人员 1120， 本地化人员 110，培训人员 115，文档人员 100，市场人员 100， 内部IT 50，合计 5345。仔细分析对比这两组数据，从中我们可以看出，国内外软件企业对软件测试的重视程度，他们不惜将大量的资金，人力物力投入其中。国内外的软件企业 之所以如此重视软件测试，原因只有一个那就是软件测试已成为软件开发过程中不可或缺的一部分。假如软件开发过程中离开了软件测试，我们可以想象后果将会有 多么的严重。首先我们无法保证软件的质量，也无法保证软件是否满足用户的需求，也无法保证我们程序的可用性。在软件开发中如果不进行软件测试，很可能使我 们的程序成为镜中花水中月，不可实现。唯有充分了解软件测试在软件开发过程中的重要性，我们才能更加重视软件测试工作。

　　了解了软件测试 在软件开发过程中的作用和意义，以及国内外对软件测试的重视程度和资源投入对比，为了保证软件质量，使我们的软件更加符合用户需求，我们应当思考如何更好 地进行软件测试，在软件企业投入了足够的人力物力等资源之后，怎样利用这些资源来更好的进行软件测试工作自然成为了我们应该思考的问题。

　　2、软件测试的测试配置管理

　　2.1 进行测试配置管理的必要性

　 　在拥有了足够的资源和人力之后，我们能否认为软件测试工作可以很好的进行并且能够保证软件测试过程不会出现问题呢？也许我们认为只要需要的测试条件满足 了，我们就可以圆满的完成测试工作了，其实这样的观点是错误的。软件测试工作是由人来进行的，因而首先要考虑到人的问题，一项工作只要有人的参与，就必须 要将人的因素考虑进去。人无完人，金无足赤，测试人员对软件测试工作造成的负面影响在软件测试中是不能够忽略的。软件是由人来编写实施的，但是软件开发又 是一个极其容易产生错误的复杂过程，因其产生就注定了它不会是一个简单的过程。尽管程序员和软件工程师等为了完善软件而做出了巨大的努力和工作，但是软件 错误仍然是不可避免的。世上不存在百分百完美的软件，因此软件过程中的软件错误是不可避免的，这是他自身的一种特性。我们所能做的就是尽量减少软件中的错 误，争取做到使这些错误可以忽略不计，或者尽量不影响我们的正常使用。给定了足够的资源之后，我们再进行软件测试工作，这时仍然不能认为没有问题了，还需 要在软件测试时进行配置管理。在软件测试中缺少了测试的配置管理我们是做不好测试工作的。我们进行软件测试就是为了以最少的时间，最少的人力物力去尽可能 多的发现软件中潜藏着的各种错误和缺陷。但是伴随着软件测试工作量的加大，软件企业仅仅投入更多的人力物力以及其他各种资源是不够的，他们还需要思考除此 之外怎样才能更好的进行软件测试。为了更好的进行软件测试，我们应该对测试人员、测试环境、生产环境进行配置管理。只有建立了完整的合理的软件测试配置管 理体系，软件测试工作才能更好的进行，更加完美的完成测试目标。

　　如果在软件测试过程中缺少了测试配置管理将会造成及其严重的后果。据我 们实际调查了解到，在日常的软件研发工作中，很多软件企业都会或多或少的在软件测试时遇到很多的问题，而这些问题的产生都是因为在测试过程中缺乏配置管理 流程和工具。因为人员具有频繁的流动性，并且在组织的过程中会产生知识和财富的流失，再加上现代社会的激烈竞争，如果一个企业没有设计配置管理流程和使用 必要的配置管理工具，就可能会因此而造成无可估量的损失，甚至导致整个软件项目的崩溃。因而作为一个软件企业，必须要做到及时了解项目的进展状况，对项目 进行管理，遇到突发状况的解决。软件工程思想发展到现在，认为在软件过程中如果能够越早的发现缺陷和风险，这时只要采取相应的措施，所要付出的代价就越 小。缺乏配置管理流程的一个很明显之处就是测试过程中缺乏并发执行的手段，没有了配置管理的支持，软件过程中的并发执行将会变得十分的困难。这时往往会造 成修改过的bug重复出现，又或者几个人员进行相同的测试工作和进程，从而产生不必要的浪费。如果企业不能很清晰很流畅的对整个软件测试过程进行管理，就 会造成测试工作的不同步，不一致。在测试工作中需要测试人员完成的没有完成，而暂时不需要或者以后在完成的却首先完成了，这样会增加测试工作的复杂性和难 度，因此我们需要在软件测试中进行配置管理。

　　既然测试配置管理在软件测试中如此重要，企业该如何进行测试配置管理呢。我们首先简单谈谈软件测试的测试配置管理体系。它一般由两种方法构成： 那就是应用过程方法和系统方法。意思就是在测试过程中，我们应该把测试管理这块单独作为一个系统去对待。识别并且管理组成这个系统的每个过程，从而实现在 测试工作开始之初设定的目标。在上面的基础之上，我们还要做到使这些过程在测试工作中能够协同作用，互相促进，最终使他们的总体作用更大。在软件测试配置 管理中的主要目标是在设定的条件限制下，企业应当尽最大的努力去发现和排除软件缺陷。测试配置管理其实是包含在软件配置管理中的，是软件配置管理的子集。 测试配置管理作用于软件测试的各个阶段，贯穿于整个测试过程之中。它的管理对象包括以下内容：测试方案，测试计划或者测试用例，测试工具，测试版本，测试 环境以及测试结果等。这些就构成了软件测试配置管理的全部内容。

　　2.2.1 测试配置管理的目标和阶段

　　现在我们了解软件测试配置管理的目标：第一步是在测试过程中控制和审计测试活动的变更，第二步是在测试过程中随着测试项目的里程碑，同步建立相 应的基线；第三步是在测试过程中记录并且跟踪，测试活动过程中的变更请求；第四步是在测试过程中针对相应的软件测试活动或者产品，测试人员应将他们标识为 被标识和控制并且是可用的。

　　软件测试配置管理的阶段：第一阶段为需求阶段：我们要进行客户需求调研和软件需求分析；第二阶段为设计阶段：在这个阶段我们要进行概要设计和详 细设计工作；第三阶段为编码阶段：这时我们主要进行的工作是编码；第四个阶段是测试和试运行阶段：在这个阶段我们要进行：单元测试，用户手册编写，集成测 试，系统测试，安装培训，试运行和安装运行这些工作；第五阶段也就是最后一个阶段是正式运行及维护阶段：这是要做的是对产品进行发布和不断的维护。

图2.1 配置管理阶段示意图

　　在软件测试的过程中会产生很多东西，比如测试的相关文档和测试各阶段的工作成果，这些包括测试计划文档，测试用例，还有自动化测试执行脚本和测试缺陷数据等。为了以后可能的查阅和修改，我们应该将这些工作成果和文档保存起来。

　　2.2.2 测试配置管理的过程管理

　　了解了软件测试过程中配置管理的目标和阶段，接下来就应该进行软件测试配置过程管理了。他的配置管理过程包括：

　　（1）建立配置变更控制委员会：配置控制委员会（CCB）应该要做到对项目的每个方面都有所了解，并且CCB这个团体不应该由选举产生，它的人员构成包括主席和顾问，在软件研发中每一个项目组都必须建立CCB作为变更权威。

　　（2）SCM库的建立和使用：我们要求在每一个项目过程中都要维护一个软件配置管理库。在项目中通过使用配置管理工 具，简称（VSS），企业通过该工具在配置管理服务器之上，建立和使用软件配置管理库。这些操作有助于在技术和管理这两个方面对所有的配置项进行控制，并 且对他们的发布和有效性也能起到控制作用。同时还有很重要的一点就是我们应该对SCM库进行备份。这样做的目的是为了在产生意外或者风险时，能够作为保存 灾难恢复备份的副本。

　　（3）配置状态报告：配置状态报告是软件测试配置管理过程中的一项重要的活动，在软件测试配置管理过程中，配置人员 要管理和控制所有提交的产品，然后在有产品提交或者变更为完成时，配置人员要经过相应的质量检查，这就是配置人员应该进行的工作。而在这之后，配置人员不 但要将批准通过的配置项放入基线库中。并且还要记录配置项及其状态，编写配置状态说明和报告。通过配置人员的这些工作来确保所有应该了解情况的组或者个人 能够及时的知道相关的信息。

　　（4）评审、审计和发布过程：为了保持SCM库中内容的完整性和质量，我们应该采取适当的质量保证活动来应对SCM库中各项的变化。以此来确保在基线发布之前能够执行审计活动，该活动包括这几点：基线审计，基线发布和产品构造。

　　软件测试过程中的配置管理就是由这些构成的。该过程不但提供给了我们良好的理论知识和清醒的认知，还让我们清楚的了 解到软件测试过程中应该进行的工作有哪些。要想研发出好的软件需要进行好的软件测试。而要想进行好的软件测试，就需要我们掌握软件测试过程中的配置管理， 并且了解该怎么样去运用它。只有对其有了深入的了解之后我们才能更好的进行软件测试工作，运用科学而且标准的测试配置管理知识为软件质量提供保障。

　　了解了配置管理的目标和阶段以及如何进行软件测试配置过程管理，仅仅这些是不够的。有了这些知识，我们还不能够对软件测试进行完整的配置管理， 不能凭借这些来有效的保障我们的软件质量。在这些基础之上，我们还需要对软件测试配置管理中的角色进行分配和分工。唯有如此才能确保在软件的开发和维护 中，我们能够使配置管理活动得到贯彻执行。因此在制定测试配置管理计划和开展测试配置管理之前，我们首先要确定配置管理活动的相关人员以及他们的职责和权 限，下面我们来详细的了解配置管理过程中主要的参与人员和他们分职责分工。

　　（1）项目经理（PM，Project Manager）。项目经理作为整个软件的开发以及整个软件的维护活动的负责人，那么他的职责是什么呢？他的主要职责包括采纳软件测试配置控制委员会的建 议，对配置管理的各项活动进行批准，并且在批准之后还要控制它们的进程。项目经理的具体工作职责如下：首先制定项目的组织结构以及配置管理策略；然后要批 准和发布配置管理计划；再然后要对项目起始基线和软件开发工作里程碑进行制定；最后要接受并审阅配置控制委员会的报告。

　　（2）配置控制委员会（CCB，Configuration Control Board）。该委员会的职责则是对配置管理的各项具体活动进行指导和控制，并且为项目经理的决策提供建议。该委员会的具体工作职责如下：首先是要批准软 件基线的建立以及配置项的标志；然后是制定访问控制策略；再然后是建立、更改基线的设置，和审核变更申请；最后是根据配置管理员的报告从而决定相应的对 策。

　　（3）配置管理员（CMO，Configuration Management Officer）。根据制定的配置管理计划执行各项管理任务这就是配置管理员的职责，配置管理员要定期向CCB提交报告，同时还要列席CCB的例会，他的 具体工作职责如下：第一，对软件配置管理工具进行日常管理与维护；第二，提交配置管理计划；第三，各配置项的管理与维护；第四，执行版本控制和变更控制方 案；第五，完成配置审计并提交报告；第六，对开发人员进行相关的培训；第七，开发过程中存在的问题加以识别并制定解决方案。

　　（4）开发人员（Dev，Developer）。开发人员的职责为在了解了项目组织确定的配置管理计划和相关规定之后，按照配置管理工具的使用模型来完成开发任务。

　　只有在清晰的了解了软件测试配置管理的概念，构成，原理和配置管理的人员及其分工之后，企业才能去灵活的应用它，在企业的软件测试过程中去严格的执行它，我相信一个企业只要做好这一步，就一定能够做好软件测试工作。从而保证软件的质量，满足用户的需求。

　　2.3 测试配置管理的应用

　　下面我们以一个实际项目中的配置管理的例子来介绍项目中的配置管理应用。我们用来示例的项目是电信的一个项目，项目人员为16人，项目周期为一 年，前期主要为开发工测试工作，后期的主要是由维护人员进行系统维护和调整。在整个项目正式启动之前，配置管理工作就可以开始了。首先，应该评估团队当前 的配置管理现状：清楚了解测试团队当前配置管理的现状是计划配置管理实施的基础，评估团队当前的配置管理现状有两种方法，一种是自己进行，另外一种是引入 外部专业咨询人员来完成评估活动。有了评估的结果之后才能进行改进，因此，这项工作一定要做好。然后，定义实施的范围，在经过了评估之后，会找出很多的改 进点，对于这些改进点，必须要花费大的精力来思考解决。还需要指定一个专门的人员就是配置管理员。在一个建立了配置管理平台的团队中他负责掌控整个团队的 工作流程和成果，要负责维护和管理配置管理系统。有一个合格的配置管理员能够为整个团队的进度带来极其良好的影响。而在配置管理工作开始后的第一步就是一 份配置管理计划。一般而言，需要在配置管理计划中明确的内容包括：1、配置管理软硬件资源；2、配置库结构；3、人员、角色以及配置管理规范；4、基线计 划；5、配置库备份计划，6执行配置审计；下面我们来围绕其中一些内容就行详细描述：

　　配置管理环境：包括软硬件环境。具体的资源需求应该根据项目实际情况来确定，一般需要考虑的包括：网络环境、配置管理服务器的处理能力、空间需 求，配置管理软件的选择等。配置管理环境的确定需要综合考虑各个方面的因素，包括我们采用的工具，人员对配置管理工具的熟悉程度等，同时，配置管理软件和 测试工具的集成程度也是一个必须考虑的因素，根据我们的经验，选择一个和测试环境集成紧密的配置管理工具至少可以减少20%花费在Check In/Check Out和配置管理人员保持配置库完整上的工作量。

　　然后是配置管理工具的选择：从测试人员具有的配置管理工具使用经验和配置管理工具使用的难易度方面来说，VSS是最好的选择，在现有的基础上只 需要对测试人员进行简单培训；考虑到和测试工具的集成，VSS也是一个不错的选择。不过本项目还要求对远程接入方式的支持，以及对Solaris平台的支 持，VSS肯定是不能满足要求的（VSS通过VPN方式应该是可以实现对远程访问的支持，但VSS的完全共享方式实在是不敢在Internet上使用）。 除VSS外，可以选择的配置管理工具还有CCC Harvest、ClearCase、CVS等，但Harvest和ClearCase使用起来比较复杂，需要一个专门的配置库管理员负责技术支持，还需 要对测试人员进行较多的培训。

　　最后是配置库维护和备份计划：配置库的维护的备份需要专职的配置库管理员来负责。在整个项目中我们采用的配置库维护策略是根据 Microsoft的Best Practice白皮书建议，包括以下要点：1.保持配置数据库的大小不超过5G；Microsoft建议，配置库的大小在3-5G比较合适，太大的数据 库会极大影响VSS的效率；2.每周进行VSS数据库的分析（Analysis），发现问题及时修正；VSS提供了Analysis和Fix工具，由于不 合理的Delete等操作，VSS数据库有可能会出现一些Interrupt Data之类的问题，通过定期的每周的分析工作，可以极大减少数据库出现问题的风险；3.每日进行配置库的增量备份，每周进行数据库的完全备份；VSS库 的备份可以通过VSS自己的Archive功能或者是操作系统的Backup程序来进行。VSS的Archive功能对VSS中的文件数据进行压缩并保留 VSS的所有状态，但只能对VSS库进行完全备份，不能实现增量备份功能。Windows2000 Server提供的Backup实用程序可以对文件进行备份，由于VSS库就是以文件形势存在的，因此针对VSS的data目录进行备份也可以完全达到备 份的目的，使用系统备份工具的好处是可以实现增量备份。我们在实际中使用的系统的备份工具，每周五生成的完全备份采用刻录光盘的方式保存，每天的增量备份 数据存放在文件服务器上进行备份。

　　3.1 测试版本控制的必要性

　　通过上面我们对软件测试的配置管理有了详细的了解，此外我们还需要了解配置管理中的一方面，那就是软件测试过程中的版本控制，这同样也是软件测 试过程中不可缺少的一部分。很多人不了解软件测试过程中的版本控制，甚至认为软件测试不需要版本控制。这种想法是错误的，在软件测试中也同样需要版本控 制，这是软件测试中不能缺少的一部分。如果测试组长或者测试人员不对软件测试进行版本控制，那么这样带来的危害也是显而易见的。软件测试过程中如果缺乏版 本控制，我们很难保证测试进度和测试的一致性。我们知道在进行测试工作时，很容易出现的是出现冗余这一问题，这样很容易导致本地版本和服务器版本的不一 致，软件测试过程中缺乏版本控制就会造成上面这些问题。由此可见，软件测试是离不开版本控制的。在测试过程中适合的版本控制可以有效的提高开发和测试效 率，消除很多由于版本带来的问题，并且可以确保在软件开发和测试过程中，能够及时并且正确的更新不同的人员所涉及的同一文档。

　　3.1.1 测试版本控制的概念

　　软件测试的版本控制简单的说就是对测试有明确的标识、说明、并且测试版本的交付是在项目管理人员的控制之下。用来识别所用版本的状态就是对测试 版本的标识，对不同的版本进行编号，软件质量稳定度趋势的反映也可以由测试的版本控制体现。版本控制是软件测试的一门十分实用的实践性技术，将各次的测试 行为以文件的形式进行记录，并且对每次的测试行为进行编号，标识公布过的每一个测试版本，以此来进行测试排序，比如将最初的版本标识为1，经过测试后，之 后的版本依次标识为2，3，4等等。

图3.1 Linux下的版本控制

图3.2 Git版本控制

　　3.1.2 测试版本控制的作用

　　软件测试的版本控制有两个方面的作用：一个方面是标记历史上产生的每个版本的版本号和测试状态，另一个方面是保证测 试人员得到的测试版本是最新的版本。所谓版本控制其实就是跟踪标记测试过程中的软件版本，以方便对比的一个过程，通过版本控制来表明各个版本之间的关系， 和不同的软件开发测试阶段。从而方便测试工作的进行。版本控制是测试人员不可缺少的一种技术。有了软件测试的版本控制，测试人员在软件测试工作可以更加高 效并且有针对性的进行。

　　软件测试版本控制其实是在软件测试中为了便于追溯和跟踪问题而出现的，对测试版本的控制实际上就是对软件测试过程中的各种测试行为的管理和控 制。软件测试的版本控制，主要是指对于测试对象的版本控制，也就是指测试小组在软件测试过程中对开发部提交给测试部门的产品进行版本控制。如果开发小组不 能够规范的管理软件版本，那么这时候测试小组对于产品进行版本控制就将显得十分重要，这时软件测试小组要保证测试对象的可控性被限制在我们可以控制的范围 之内。对此，我们建议开发小组和测试小组要做到如下要求：两个小组不但分工明确，还要协商出一个明确的约定，指定专门的测试版本负责人来专门负责版本控制 这一块，让这个负责人去制定版本控制的提交原则，在软件研发过程中对提交的情况要进行详细的记录，通过这些措施，这样就能在基本上对因为版本失控可能造成 的测试失误或者无效加以避免。

　　举一个软件测试项目中版本控制的例子，一个公司的员工负责了一个软件测试项目，在项目开展初期，该项目的测试工作进行的还算顺利。但是在测试后 期工作即将结束时，却出现了问题。而这个问题的出现正是由于版本控制不当，在这个软件测试项目中，他们将测试过程中发现的bug提交给开发人员，开发人员 在对测试人员提交的bug进行修改，在对这些bug修改后开发人员会将修改后的代码放入当前的软件版本之中，问题正是出现在这个阶段。那么为什么问题会出 现在这个阶段呢？其实是因为对于修改过的代码，我们不能够保证他们一定是正确的，很可能在开发人员修改过之后，仍然是错误的，或者在修改过之后仍然会给软 件带来别的问题，这种情况下就会给软件测试人员的测试工作带来新的麻烦。这样就会造成一个很严重的后果，那就是测试人员对开发人员提交的新代码会很紧张， 不能彻底放心，测试人员对新提交的新修正的代码还要在进行验证，进行排错，来确保不会因此而带来新的隐患，新的漏洞。在这个时候我们就应该思考怎样去解决 这个问题了，这时我们就可以尝试一下软件测试的版本控制了。首先测试人员要测试开发人员提交的代码，将测试过程中查找到的bug进行提交。而当测试人员提 交的bug到了开发人员手中之后，开发人员要针对这些bug进行修复工作，并且将修改后的代码放入程序中，作为新的软件版本。但是绝对不能将它再放回到现 在正在进行的测试版本中。而测试人员在完成这一轮的测试工作后，在对新的版本也就是对经过开发人员修改过得下一个版本展新一轮的测试。而这就是软件测试过 程中的版本控制。

　　3.1.4 缺乏测试版本控制的危害

　　软件测试缺乏测试版本控制会带来很多危害：随着计算机软件技术的日趋成熟和日益复杂。现代的软件产品规模越来越大，结构越来越复杂。单纯的手工 测试不再能够满足软件工程中的测试需要。一两个人完成一个项目的测试工作的时代不复存在，一个大型项目的测试工作，现在都是由很多测试人员参与并且有不同 的分工，以团队合作流水线式的方式来开展工作的，他们在测试过程中是协同完成测试工作的。在进行测试的时候，同一个板块的测试会由很多人共同负责，他们将 会分配到同样的任务。在这么多人完成同一板块的过程中，企业怎样去保证每个人的测试工作对软件产生的影响能够综合到一起产生好的作用。而不是因为人员的差 异而对测试版本造成不一致性呢？运用软件测试中的版本控制就成为此时有效地解决途径，有效的版本控制能够很好的解决这些问题，并对软件的开发进行产生好的 积极的影响。但是如果版本控制不当则会造成很多让人搞到棘手的问题。

　　（1）缺乏版本控制，将难以保证测试进度

　　大多数的测试人员都希望他们进行的测试工作是完美的，经过他们测试后的软件更是完美无缺的。这种想法是好的，但是一个软件在它的整个生命过程中 是不可能完美到没有一点错误存在的，我们只能尽我们所能去不断地完善它。这时如果能够提供有效的版本控制就会极大地提高软件测试的工作效率。在测试中对测 试版本进行版本控制时，我们起码要做到能够掌握软件过程中的每个版本。在每个版本中，我们能够找到哪些功能不过关，哪些功能没问题。对于新的测试版本不管 在测试工作中的哪个时间段，都应该有一个可以用来比较的对象。并且能够与之前的版本进行对比。

　　（2）缺乏版本控制，难以保证测试的一致性

　　软件测试工作因为十分复杂并且有很多人员参与其中，在进行测试工作时，因为测试人员的分工不同，不同的测试人员要负责不同的测试模块。但是因为 软件有其整体性，所以测试人员要互相协作，那么在测试过程中则必然会产生交叉。所以测试工作是一项十分复杂的工作，它是由很多人一起共同协作完成的。在整 个测试中为了保证测试过程中的一致性我们必须要找到一个平衡点。而大量的实践证明如果进行有效的版本控制，将有效保证测试过程中的一致性，大大的降低因为 缺乏版本控制或者流程管理可能带来的诸多问题。

　　（3）测试版本冗余，易出现误用风险

　　因为有众多测试员参与到软件测试过程中，而进行测试工作时每个人都必须使用一台机器，那么在每个人的机器上都要拷贝一个待测软件。随着测试工作 的进行，在测试过程中会不断产生新的软件版本，为了测试需要，每个人的机器上都要不断更新软件版本，那么每个人的电脑上必然会保存不同时期的软件版本。而 这些不同的测试版本随着时间的推移和测试工作的复杂很容易混杂在一起，造成测试人员无法分清每个版本之间的差异，甚至分不清对于当前版本应该做什么事情， 从而给测试工作带来极大的困扰，出现版本的冗余。这时，如果缺乏有效的测试版本控制就会增大测试风险，给测试工作带来麻烦。

　　（4）容易导致本地版本和服务器版本不一致

　　因为测试版本的众多和混乱，测试小组在测试工作上不但要花费更多的时间和精力，还可能造成不必要的重复性测试和不必要性测试，当测试版本不及时 更新时，会造成测试版本和现行版本的不一致，这些就是缺乏版本控制和管理的结果。因而加强测试过程中的版本控制是一项很重要的工作。

　　版本控制在提供可追溯性的文件的同时还能够为各种测试版本提供文档管理支持。使我们能够很方便的随时查阅在软件测试过程中生成的各种文档。

　　3.2 测试版本控制方法及工具解析

　　3.2.1 测试版本控制的方法

　　有效的版本控制能够极大的方便软件测试工作，提高测试工作的效率，那么我们如何才能成功的进行版本控制呢？为此我们应该制定一套标准，制定相应的版本控制方法规划来规范化软件测试的版本控制。方法如下：

　　（1）在软件测试过程中制定规范的版本控制管理制度，明确整个测试中的测试需求，选择合适的版本控制切入点，把版本控制和测试里程碑结合到一起 来实现阶段性成果，从而避免测试规划过程混乱的风险。（2）通过制定合理版次规划和监控机制来进行版本控制，为了有效的管理测试项目所需的版本次数，应该 对测试工作量进行合理的评估，以此来做出合理的版次规划。（3）我们不能忽略版本控制管理员在版本控制中的重要性，版本控制管理员在测试版本控制中的重要 性是不可估量的，离开了版本控制管理员和缺乏版本控制的情况是等效的。（4）我们还要做好版本控制的文档管理，对相关文档进行严格规范的管理，将测试过程 中版本控制产生的相关文档记录、标识是很重要的，有了这些能够很方便的跟踪和监控测试版本的执行。（5）选择合理的应用版本控制的软件工具，能够极大的提 高测试工作的效率，大大提高测试活动的优质性。

　　3.2.2 版本控制工具解析

　　工欲善其事，必先利其器。介绍完了版本控制的方法和软件测试中版本控制的重要性，要想方便的进行测试工作就必须进行有效的版本控制，选择一款好 的测试工具这时就显得尤为重要。下面我就简单介绍一种版本控制工具，同时它也是一种配置管理的工具。那就是ClearCase。这是由RATIONAL公 司开发的一款配置管理工具。下面我来讲解下ClearCase的四种功能：（1）控制任何文件的版本（Version Control），它能够维护和控制软件版本，有效的管理版本内容。（2）在版本树中组织元件发展的过程（Workspace Management）。针对目录结构它可以定制一个版本树的结构，并且其中包含多层分支和子分支。（3）对目录和子目录进行版本控制（Build Management），比如：在其中建立一个新的文件夹，或者对文件名进行修改，又或者新建子目录或者在不同的目录间移动文件等。（4）明确项目设计的 流程（Process Control）。比如：可以通过将不同的权限授权给全体人员来阻止某些修改的发生，立刻通知团队成员任何时刻某一事件的发生，对开发的进程建立一个永久 记录并不断维护它。

　　3.3 测试版本控制应用

　　我们以一个实际项目中的例子来介绍项目中的版本控制。在这个项目中，我们已经分好了测试小组及组内成员的分工，启动软件测试的条件已经具备，在 开发人员发布了测试版本后，有相应的文档支持比如自测报告、软件版本说明等等，然后启动测试工作，其中在对其版本进行测试的过程中，测试小组对项目进行版 本控制分以下几步：第一，制定规范的版本控制管理制度，测试小组要了解和明确整个测试的需求，选择合适的版本控制切入点，对于测试中产生的测试版本要进行 严格控制，还要规范化的控制测试过程中产生的不同时期的测试版本，通过把版本控制与测试里程碑的结合来实现阶段性成果，以规避测试过程混乱的风险。第二， 应该制定合理版次规划和监控机制，对测试项目所需的版次数量进行有效管理，并且对版次做出合理的规划。在整个测试项目的关键位置要设立检查点，要能根据版 次规划随时监控版本更新，及时发现问题，并对出现的异常现象做出快速反应，这样才能使得测试过程更加清晰和更有计划性。第三，测试小组要指定版本控制管理 员。测试版本控制作为一个贯穿整个测试周期的一项活动，测试版本控制会涉及到很多的人员角色，其中最为主要的人力资源就是测试版本控制管理员。在一个建立 了良好版本控制机制的测试团队中测试版本控制管理员是十分重要的。他负责掌控整个测试过程的测试版本，要负责记录和监控测试中不同测试阶段产生的测试版 本。他的地位是不可动摇的。有一个合格的测试版本控制管理员能够为版本控制工作带来极其良好的影响。最后是选择一款合适的版本控制工具，在进行版本控制的 过程中测试小组选择一款合适的测试版本控制软件是不可缺少的。常见的版本控制工具有CVS，SVN，Clearcase，其中CVS 是一款开放源代码软件，其功能强大、跨平台、支持并发版本控制而且免费，所以它在中小型软件企业中得到广泛使用。但是它最大的遗憾就是缺少相应的技术支 持，许多问题的解决需要自己寻找资料，甚至是研究源代码。而SVN是对CVS的缺点进行改进产生的版本控制工具，相比于CVS而言，SVN更为简单易用， 且SVN有其特定平台的客户端工具。如TortoiseSVN，是为windows外壳程序集成到windows资源管理器和文件管理系统的SVN客户 端，使用相当方便。最后一种版本控制工具Clearcase是Rational公司一款重量级的软件配置管理工具。与CVS和SVN不同的 是，Clearcase涵盖的范围包括版本控制、建立管理、工作空间管理和过程控制。Clearcase贯穿于整个软件生命周期，支持现有的绝大多数操作 系统，但它的安装、配置、使用相对较复杂，需要进行团队培训。选择一款合适的版本控制工具不但能够提高测试工作效率，而且也会大大提高测试活动的优质性。

　　4、小结与展望

　　本文从对软件测试概念的讲解，软件测试工作的重要性讲解开始，又通过国内外软件企业软件测试的现状为切入点，对软件测试过程中必须要进行软件测 试配置管理进行了讲解和叙述。详细介绍了软件测试配置管理的必要性和不可或缺性，并且详细叙述了配置管理的概念，过程和方法，以此来保证软件产品质量。又 通过对软件测试过程中的版本控制进行讲解，叙述了版本控制在软件测试中的重要性。同时对版本控制的概念，意义还有方式方法进行了论述。讲述了版本控制在软 件测试以及整个软件过程中的重要性。本文从软件测试的配置管理和版本控制两个方面，讲述了如何有效的进行软件测试工作来保证软件的质量。

　　由于公司及部门的发展，项目经理已经开始面对人数众多，时间跨度较长的版本管理挑战。

　　如张湘辉（1994年加盟微软，现任微软大中华区CTO）所说：

　　以Windows 7为例，包含七八千万条甚至上亿条代码，五六千人同时开发，还有很多合作伙伴确保周边产品兼容。对这样一个超大的项目而言，不能一眼盯到结果，不能像跑百米一样，始终盯着终点。我们的经验是盯终点肯定乱，因为要经历非常漫长的过程。

　 　从心理上说，当发现离终点还很遥远时，人就会泄气，不能以那么快的速度玩命跑下去。最好的方式，是将事情分成很多步骤来做。Windows7从开始到完 成可能要耗时两年，以两年时间为一个周期，那么前六个月团队就会被弄垮，所以你必须以也许每两个月为一个终点。就像跑一千五百米，我们要考虑第一圈跑多 快，第二圈跑多快。

　　这就需要把每个终点区分得很好，设定有效的里程碑，在逻辑上要很精准，是不是到了这个里程碑，同样要非常清楚。这样每个里程碑达到时，大家可以庆祝一下，重又奔向下个目标。如同爬珠穆朗玛峰，没有说不断爬上去，而是先到大本营，再到第几个营地，最后才能登顶。

　　从过去的3.0，BM2.0等较长时间的版本管理中，能够看出我们的里程碑管理做得并不好。以前的里程碑就是一些项目关键时间点的划分，例如：转测试，转联调等，项目组在里程碑处的行为基本就是核实是否满足进入下个阶段的标准，满足则进入。总体来说项目还是以最终发布时间点为目标，这样非常容易导致团队的疲惫。因此结合部门历史经验和其他公司的做法，产出里程碑管理的概念。

　　二、目的

　　里程碑管理目的是解决时间跨度较长或任务比较艰巨的版本管理问题。里程碑管理期望可以达到以下4个效果：

　　1、使团队将长期目标划分为不同的短期目标，就像跑长跑一样，不是以5W米为目标，而是把目标分解到每一圈

　　2、在里程碑处，团队进行有效的休整。就像队伍打仗时，一定要有休整，才能持续保证旺盛的战斗力

　　3、促使组员进行上个阶段的总结，找出自己的不足，并吸取其他人的优点，从而让组员进行成长

　　4、整理下个阶段的工作思路，促进大家进行整体思考，并对模块进行全面分析。

　　三、具体内容

　　1、给予项目组时间，进行全员总结，包括上个阶段的总结，下个阶段的工作思路，做成PPT

　　2、由每个人在会议上将自己的总结PPT进行分享 （做成ppt并在项目会议上进行分析，会引起大家的重视，自然效果会好）

　　3、进行表彰，表彰做得好的人员，由主管亲自颁发奖品（结合奖励措施）

　　4、用本小组经费进行欢庆，吃饭+KTV之类

　　四、计划支持

　　1、项目计划中安排好总结时间

　　2、制定里程碑奖励措施，并且在上个里程碑点处进行宣传，过程中进行相关数据统计

　　3、向公司提前申请所需的时间和金钱资源

相关链接：

项目实战笔记之一：高效会议的组织方法

项目实战笔记之二：风险管理

项目实战笔记之三：时间估算的三步曲

项目实战笔记之四：团队建设（尊重）

　　现实当中将对共享资源的共有操作方法放在接口或抽象类，这样在通过继承抽象类或实现这个接口可以得到更好的效果！这样代码也更清晰，更有层次感！

　　本文主要描述对Oracle监听器日志文件的配置与管理。

　　一、监听器日志特性

　　1、监听器日志是一个纯文本文件，通常位于$ORACLE_HOME/network/log目录下，与sqlnet.log日志文件处于同一路径

　　2、其缺省的文件名为listener.log。对于非缺省的监听器，则产生的日志文件通常为listenername.log

　　3、该文件缺省由监听器自动创建，当日志文件丢失时或不存在时，会自动重新创建一个同名的文件，与alert_<SID>.log文件类似

　　4、该文件的尺寸会不断自动增长，当尺寸过大时或不便于阅读时，考虑将其备份

　　5、Oracle监听器在运行时不允许对日志文件做删除，重命名操作

　　6、可以设置日志状态为ON或OFF来实现启用或关闭日志

　　二、设置日志文件目录及路径

　　1、设置日志文件目录的两种方法

　　2、设置日志文件的两种方法

　　3、设置日志的状态

　　4、演示设置

　　a）切换到日志目录查看日志文件

　　b）查看当前监听器的状态

　　d）查看新路径下产生的日志文件

　　e）查看listener.ora配置文件的变化

　　通常情况下，需要停止监听器来对日志文件进行备份，下面使用不停止监听的情况下对日志文件重命名以实现备份

　　1、Windows平台的处理

　　2、Unix/Linux平台的处理

　　3、演示Linux平台下重命名日志文件

　　首先用虚拟机重装了centos系统，虚拟机采用了VMware workstation9.0，系统用的centos5.5版本。

　　新建虚拟机，选用了自定义高级模式，我的大致参数是内存1024MB,硬盘选用SCSI类型，大小20G，网络连接采用网桥模式。因为不需要打印机的功能，所以在设备状态把打开电源时连接去除了。采用的时先建立虚拟机，再采用镜像安装系统，由于用的Windows XP SP3系统，选用的32位版本centos。采用图形界面安装，建立自定义分区结构，Linux目录如下：

　　建立四个分区：

　　顺便补充一个知识linux系统下对硬盘和分区的命名方法。

　　在Linux下对IDE的设备是以hd命名的，第一个ide设备是hda，第二个是hdb。依此类推。

　　我们一般主板上有两个IDE接口，一共可以安装四个IDE设备。主IDE上的两个设备分别对应hda和hdb，第二个IDE口上的两个设备对应hdc和hdd。

　　一般我们的硬盘安装在主IDE的主接口上，所以是hda，光驱一般安装在第二个IDE的主接口上，所以是hdc(应为hdb是用来命名主IDE上的从接口)，SCSI接口设备是用sd命名的，第一个设备是sda，第二个是sdb。依此类推。

　　分区是用设备名称加数字命名的。例如hda1代表hda这个硬盘设备上的第一个分区。每个硬盘可以最多有四个主分区，作用是1-4命名硬盘的主分区。逻辑分区是从5开始的，每多一个分区，数字加以就可以。

　　比如我们一般的系统都有一个主分区用来引导系统，这个分区对应我们常说的C区，在linux下命名是hda1。后面我们分三个逻辑分区对应常说的D、E、F，在linux下命名是hda5、hda6、hda7。

　 　在可选软件上我的勾选的是Desktop-Gnome和Server,Server-GUI,软件定制这次选择了稍后定制，在现在定制可以勾选点自己所 需要的软件。选定后，会检查软件包的依赖关系，默认安装后重新引导系统即可。在第一次启动系统设置初试选项时，可以把防火墙禁用，把时间修改下。登录系统 就行了。

　　若是普通用户则在终端使用  su - root 然后输入口令进入root用户操作。

　　系统安装后，在终端使用ifconfig查看虚拟IP,在DOS系统下ping了下该IP，出现了下面这些提示：

　　或者目标不可达，目标未发现等提示。

　　方法一：进入控制面板-安全中心，防火墙关闭，若不行则进入第二种方法。

　　点击添加硬件，流程如下：

　　然后安装好后，右键我的邻居--属性：

　　安装后虚拟机后，会出现VMware的两块虚拟网卡，暂时可以停用。然后右键本地连接2--属性，设置下IP地址。