件测试知识帖(21-40)

件测试知识帖(21-40)

第21帖【2004－6－6】：回归测试

Roger S. Pressman

每当一个新的模块被当作集成测试的一部分加进来的时候，软件就发生了改变。新的数据流路径建立起来，新的I/O操作可能也会出现，还有可能激活了新的控制逻辑。这些改变可能会使原本工作得很正常的功能产生错误。在集成测试策略的环境中，回归测试是对某些已经进行过的测试的某些子集再重新进行一遍，以保证上述改变不会传播无法预料的副作用。

在更广的环境里，（任何种类的）成功测试结果都是发现错误，而错误是要被修改的，每当软件被修改的时候，软件配置的某些方面（程序、文档、或者数据）也被修改了，回归测试就是用来保证（由于测试或者其他原因的）改动不会带来不可预料的行为或者另外的错误。

回归测试可以通过重新执行所有的测试用例的一个子集人工地进行，也可以使用自动化的捕获回放工具来进行。捕获回放工具使得软件工程师能够捕获到测试用例，然后就可以进行回放和比较。回归测试集（要进行的测试的子集）包括三种不同类型的测试用例：

·能够测试软件的所有功能的代表性测试用例。

·专门针对可能会被修改影响的软件功能的附加测试。

·针对修改过的软件成分的测试。

在集成测试进行的过程中，回归测试可能会变得非常庞大。因此，回归测试应当设计为只对出现错误的模块的主要功能进行测试，每当进行一个修改时，就对每一个程序功能都重新执行所有的测试是不实际的而且效率很低的。

第22帖【2004－6－7】：测试与调试

测试的目的是显示存在错误，而调试的目的是发现错误或导致程序失效的错误原因，并修改程序以修正错误。调试是测试之后的活动。[Beizer,1984]认为，测试和调试在目标、方法和思路上都有所不同，如下：

1、测试从一个已知的条件开始，使用预先定义的过程，有预知的结果。调试从一个未知的条件开始，结束的过程不可预计。

2、测试过程可以实现设计，进度可实现确定。调试不能描述过程或持续时间。

3、测试是显示错误的行为。调试是推理的过程。

4、测试显示开发人员的错误。调试是开发人员为自己辩护。

5、测试能预期和可控。调试需要想象，经验和思考。

6、测试能在没有详细设计的情况下完成。没有详细设计的信息调试不可能进行。

7、测试能由非开发人员进行。调试必须由开发人员进行。

第23帖【2004－6－8】：系统测试方法之功能测试

功能测试又称正确性测试，它检查软件的功能是否符合规格说明。由于正确性是软件最重要的质量因素，所以其测试也最重要。

基本的方法是构造一些合理输入，检查是否得到期望的输出。这是一种枚举方法。测试人员一定要设法减少枚举的次数，否则测试投入太大。关键在于寻找等价区间，因为在等价区间中，只需用任意值测试一次即可。等价区间的概念可表述如下：

记（A，B）是命题f(x)的一个等价区间，在（A，B）中任意取x1进行测试。如果f(x1) 错误，那么f (x) 在整个（A，B）区间都将出错。如果f(x1) 正确，那么f (x) 在整个（A，B）区间都将正确。

上述测试方法称为等价测试，来源于人们的直觉与经验，可令测试事半功倍。

还有一种有效的测试方法是边界值测试。即采用定义域或者等价区间的边界值进行测试。因为程序员容易疏忽边界情况，程序也“喜欢”在边界值处出错。

例如测试平方根函数的一段程序。凭直觉输入等价区间应是（0，1）和（1，+∞）。可取x=0.5以及x=2.0进行等价测试。再取x=0以及x=1进行边界值测试。

有一些复杂的程序，我们难以凭直觉与经验找到等价区间和边界值，这时枚举测试就相当有难度。

第24帖【2004－6－9】：黑盒测试的端口测试模型

端口测试模型侧重于对被测对象的抽象，它阐明的是我们要测试什么。它将被测试者间的共性抽象出来，使测试者和被测者可以最大程度地分离开来。

其主要思想是：被测试者可以用测试端口集来表达。

测试功能体现在测试端口对外协议（称为端口协议）的实现，对不同系统的测试或对同一系统中不同子系统的测试都表现为对不同端口的测试。端口协议一般是非确定的有限自动机（NFA)，它可以分解成确定的有限自动机（DFA)的集合（对应于功能迁移路径集），并可以用结构化语言描述在测试用例中。这样，端口协议的差异就不会影响测试者的内部实现（与被测者的接口除外）。

第25帖【2004－6－10】：黑盒测试的对象测试模型

对象测试模型注重于测试内容的表达，它阐明的是如何表达我们的测试内容。它把分散的功能测试单元有机地组合起来，使实际测试更逼近真正的系统测试。

其主要思想是：测试内容及测试的实现方法（指对测试数据的处理）可以被封装在一个个的测试对象中。

测试对象有三个层次：数据对象、业务对象和事务对象，它们的关系是逐级被包含。简单来说，数据对象是指业务（或功能）数据的载体，它通常有物理对应，其主要测试内容是一个状态迁移图；业务对象指共同实现一种业务（或功能）的数据对象集合，它一般都只有逻辑对应，其主要测试内容是一个时间追踪图；事务对象是指一组业务相关的业务对象的有序组合，其主要测试内容是业务间的关系图，准确地说是业务结果间的布尔关系图。

第26帖【2004－6－11】：黑盒测试的分层设计模型

分层设计模型侧重于黑盒自动测试工具的实现，它阐明的是我们如何设计测试工具。它将测试工具的功能进行抽象和分层，使测试工具的积木化开发现实可行。

其主要思想是：测试工具可划分为五个不同的层次，从低到高依次是：端口驱动层、测试执行层、测试表达层、测试管理层、测试设计层。通过规范这五个层次间的接口，可以使按照这个设计模型设计的测试工具或提供相同的接口的其它测试工具无缝地集成在一起，从而实现理想的积木式开发。

第27帖【2004－6－12】：QA的职责

QA到底应该在企业里起什么作用呢？下面是QA职责的总结：

1、保障软件组织流程体系得到遵守；

2、促使软件组织过程改进；

3、指导项目实施流程，；

4、增加开发活动透明度；

5、评审项目活动；

6、审核工作产品；

7、协助工作产品问题解决；

8、度量数据采集、分析，提供决策参考；

9、进行缺陷预防；

10、实现质量目标。

第28帖【2004－6－13】：软件走读

软件走读的目的是为了对软件产品进行评价，软件走读也可以是为给参与走读的人员培训有关软件产品知识而举行，软件走读的主要目的是：

1）发现软件产品中的软件异常，缺陷、遗漏和自相矛盾的地方，以改进产品并提出可供选择的实现方案；

2）改进软件产品；

3）考虑可选项方案的实现方法；

4）评价与标准和规格的符合性；

5）进行技术交流，人员培训。

在软件走读中可以指出各种缺陷，例如软件产品中的效率和可读性问题，设计或编码中模块化问题，或者规格书中的可测试问题等等。

要求进行软件走读的软件产品，包括但不限于：

1）软件需求规格，

2）软件设计文档，

3）源代码，

4）软件测试文档，

5）软件用户文档，

6）维护手册，

7）安装过程

第29帖【2004－6－14】：TCL简介

TCL是一脚本解释器，具有基本的语言特性，支持整型和字符串变量，支持循环等控制结构；同时它具有灵活的扩展性和跨平台的特性，后者是它最主要的特性。通过TCL脚本可以编写测试用例，通过扩展功能，可以扩展你想要的测试动作。最终目的是将测试的自动化和灵活性（可扩展性）结合在一起。

TCL提供以下接口：

1、用户接口

对用户提供语言特性，如循环、条件判断等控制结构，通过它用户可以灵活的书写测试用例；当然只提供语言特性远远不够，因为业务千差万别，所以用户需要业务接口，从而完成特定的测试任务。 而业务接口，是通过下面的程序员接口实现。

2、程序员接口

用户可以编写自己命令，它包括用户层（即名字）和实现层（通过C语言实现），然后用TCL提供的注册函数登记，以后命令就可灵活的嵌入到脚本中了。

TCL测试模型分三部分：

被测试程序（由开发人员编写）----测试人员应搞清楚程序结构和业务功能，指导扩展命令的设计。

测试代码（由测试设计人员编写） ---通过程序员接口，提供给脚本扩展命令。

测试用例（TCL脚本形式，由测试执行人员编写）---通过脚本对扩展命令进一步组合。

第30帖【2004－6－15】：CMM的五级简介

CMM为企业的软件过程能力提供了一个阶梯式的进化框架，阶梯共有五级。第一级只是一个起点，任何准备按CMM体系进化的企业都自然处于这个起点上，并通过它向第二级迈进。除第一级外，每一级都设定了一组目标，如果达到了这组目标，则表明达到了这个成熟级别，可以向下一级别迈进。

第一级、初始级：

初始级的软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的。也许有些企业制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，且执行没有政策、资源等方面的保证时，那么它仍然被视为初始级。

第二级、重复级：

根据多年的经验和教训，人们总结出软件开发的首要问题不是技术问题而是管理问题。因此，第二级的焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程，可重复的过程才能逐渐改进和成熟。可重复级的管理过程包括了需求管理、项目管理、质量管理、配置管理和子合同管理五个方面；其中项目管理过程又分为计划过程和跟踪与监控过程。通过实施这些过程，从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。

第三级、定义级：

在可重复级定义了管理的基本过程，而没有定义执行的步骤标准。在第三级则要求制定企业范围的工程化标准，并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程，裁剪出与项目适宜的过程，并且按照过程执行。过程的裁剪不是随意的，在使用前必须经过企业有关人员的批准。

第四级、管理级：

第四级的管理是量化的管理。所有过程需建立相应的度量方式，所有产品的质量（包括工作产品和提交给用户的最终产品）需要有明确的度量指标。这些度量应是详尽的，且可用于理解和控制软件过程和产品。量化控制将使软件开发真正成为一种工业生产活动。

第五级、优化级：

优化级的目标是达到一个持续改善的境界。所谓持续改善是指可以根据过程执行的反馈信息来改善下一步的执行过程，即优化执行步骤。如果企业达到了第五级，就表明该企业能够根据实际的项目性质、技术等因素，不断调整软件生产过程以求达到最佳。

第31帖【2004－6－16】：CMM 2级KPA的目标

CMM 2级：可重复级

Requirement Management

需求管理

Goal 1 System requiremnets allocated to software are controlled to establish a baseline for software engineering and management use.

目标1：分配到软件部分的系统需求通过建立基线受控。

Goal 2 Software plans, products, and activities are kept consistent with the system requirements allocated to software.

目标2：软件计划、产品和活动与分配到软件部分的系统需求一致。

Software Project Planning

软件项目计划

Goal 1 Software estimates are documented for use in planning and tracking the software project.

目标1：用来计划和跟踪软件项目的软件估计文档化。

Goal 2 Software project activities and commitments are planned and documented.

目标2：制定了软件项目活动和任务书的计划，并且有文档记录。

Goal 3 Affected groups and individuals agree to their commitments related to the software project.

目标3：受影响的小组和个人接受和软件项目相关的任务书。

Software Project Tracking and Oversight

软件项目跟踪及监控

Goal 1 Actual results and performances are tracked against the software plans.

目标1：按照软件计划跟踪实际结果和性能。

Goal 2 Corrective actions are taken and managed to closure when actual results and performance deviate significantly from the software plans.

目标2：当实际的结果和性能严重偏离软件计划时，采取了正确的行动终止这种状况。

Goal 3 Changes to sofware commitments are agreed to by the affected groups and individuals.

目标3：受影响的小组和个人接受软件任务书的变化。

Software Subcontract Management

软件子合同管理

Goal 1 The prime contractor selects qualified software subcontractors.

目标1：主签约人挑选有资格的子签约人。

Goal 2 The prime contractor and the software subcontractor agree to their commitments to each other.

目标2：主签约人和子签约人互相接受他们的任务书。

Goal 3 The prime contractor and the software subcontractor maintain ongoing communications.

目标3：主签约人和子签约人保持持续的沟通。

Goal 4 The prime contractor tracks the software subcontractor's actual results and performance against its commitments.

目标4：主签约人按照任务书跟踪子签约人的实际结果和效能。

Software Quality Assurance

软件质量保证

Goal 1 Software quality assurance activities are planned.

目标1：制定了软件质量保证计划。

Goal 2 Adherence of software products and activities to the applicable standards, procedures, and requirements is verified objectively.

目标2：客观地检验软件产品和活动是否符合适用的标准、过程和需求。

Goal 3 Affected groups and individuals are informed of software quality assurance activities and results.

目标3：软件质量保证的活动和结果通知了受影响的小组和个人。

Goal 4 Noncompliance issues that cannot be resolved within the software project are addressed by senior management.

目标4：高层管理着手解决在软件项目内部不能解决的不符合项。

Software Configuration Management

软件配置管理

Goal 1 Software configuration management activities are planned.

目标1：制定了软件配置管理活动的计划。

Goal 2 Selected software work products are identified, controlled, and available.

目标2：选定的软件工作产品是被标识的、受控的和可利用的。

Goal 3 Changes to identified software work products are controlled.

目标3：被标识的软件工作产品的变化是受控的。

Goal 4 Affected groups and individuals are informed of the status and content of software baselines.

目标4：软件基线的状态和内容通知受影响的小组和个人。

第32帖【2004－6－17】：Logiscope的功能

LOGISCOPE是为软件的全面质量控制而开发的强大工具，可以用在编程、测试和维护阶段。LOGISCOPE五个模块的功能：

(1) 阅读器(Viewer)：以文件调用图(各部件文件之间的关系)及组件调用图(函数和程序间的调用关系)的形式进行可视化应用软件设计。可以在各种各样的抽象级别上分析应用程序，在不同级别上的引导有助于整个应用程序的理解。

(2) 效果检查器(ImpactChecker)：允许用户检查使用的资源(文件、函数、用户定义类型、全局变量、结构成员常量)。它有助于我们理解函数间的信息流(参数传递)，以及数据和其它应用程序资源间的关系。

(3)规则检查器(RuleChecker)：软件公司应该定义自己的编程规则和质量目标。这样做的好处是公司编程行为保持一致性、易于维护、提高可靠性、易于移植到其它机器上。我们可以用规则检查器(RuleChecker)确立编程标准，保证质量控制。

(4) 测试检查器(TestChecker)：实时度量测试覆盖率、显示未覆盖路径原始数据、生成测试报告、帮助管理测试实例。测试检查器(TestChecker)和动态分析器 (Dynamic Analyzer)通过阅读器产生用于应用程序分析的数据。

(5) 代码检查器(CodeChecker)：验证应用程序与质量模型的一致性。代码检查器和静态分析器(Static Analyzer)通过阅读器(Viewer)产生用于应用程序分析的数据。代码检查器(CodeChecker)可以使我们尽早发现和修改质量缺陷。这对质量控制尤为重要。

第33帖【2004－6－18】：α测试

α测试是由一个用户在开发环境下进行的测试，也可以是开发机构内部的用户在模拟实际操作环境下进行的测试。软件在一个自然设置状态下使用。开发者坐在用户旁边，随时记下错误情况和使用中的问题。这是在受控制的环境下进行的测试，α测试的目的是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。尤其注重产品的界面和特色。α测试人员是除开产品开发人员之外首先见到产品的人，他们提出的功能和修改意见是特别有价值的。 α测试可以从软件产品编码结束之时开始，或在模块（子系统）测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程序之后再开始。有关的手册（草稿）等应事先准备好。

第34帖【2004－6－19】：β测试

β测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。这些用户是与公司签定了支持产品预发行合同的外部客户，他们要求使用该产品，并愿意返回有关错位错误信息给开发者。与α测试不同的是，开发者通常不在测试现场。因而，β测试是在开发者无法控制的环境下进行的软件现场应用。在β测试中，由用户记下遇到的所有问题，包括真实的以及主观认定的，定期向开发者报告，开发者在综合用户的报告之后，做出修改，最终将软件产品交付给全体用户使用。 β测试主要衡量产品的FLURPS。着重于产品的支持性，包括文档、客户培训和支持产品生产能力。只有当α测试达到一定的可靠程度时，才能开始β测试。由于它处在整个测试的最后阶段，不能指望这时发现主要问题。同时，产品的所有手册文本也应该在此阶段完全定稿。

由于β测试的主要目标是测试可支持性，所以β测试应尽可能由主持产品发行的人员来管理。

第35帖【2004－6－20】：面向对象的集成测试

传统的集成测试，是通过各种集成策略集成各功能模块进行测试，一般可以在部分程序编译完成的情况下进行。而对于面向对象程序，相互调用的功能是散布在程序的不同类中，类通过消息相互作用申请和提供服务。类的行为与它的状态密切相关，状态不仅仅是体现在类数据成员的值，也许还包括其他类中的状态信息。由此可见，类相互依赖极其紧密，根本无法在编译不完全的程序上对类进行测试。所以，面向对象的集成测试通常需要在整个程序编译完成后进行。此外，面向对象程序具有动态特性，程序的控制流往往无法确定，因此也只能对整个编译后的程序做基于黑盒子的集成测试。

面向对象的集成测试能够检测出相对独立的单元测试无法检测出的那些类相互作用时才会产生的错误。基于单元测试对成员函数行为正确性的保证，集成测试只关注于系统的结构和内部的相互作用。面向对象的集成测试可以分成两步进行：先进行静态测试，再进行动态测试。

静态测试主要针对程序的结构进行，检测程序结构是否符合设计要求。现在流行的一些测试软件都能提供一种称为"可逆性工程"的功能，即通过原程序得到类关系图和函数功能调用关系图，例如International Software Automation 公司的Panorama-2 、Rational公司的Rose C++ Analyzer等，将"可逆性工程"得到的结果与OOD的结果相比较，检测程序结构和实现上是否有缺陷。换句话说，通过这种方法检测OOP是否达到了设计要求。

动态测试设计测试用例时，通常需要上述的功能调用结构图、类关系图或者实体关系图为参考，确定不需要被重复测试的部分，从而优化测试用例，减少测试工作量，使得进行的测试能够达到一定覆盖标准。测试所要达到的覆盖标准可以是：达到类所有的服务要求或服务提供的一定覆盖率；依据类间传递的消息，达到对所有执行线程的一定覆盖率；达到类的所有状态的一定覆盖率等。同时也可以考虑使用现有的一些测试工具来得到程序代码执行的覆盖率。

具体设计测试用例，可参考下列步骤：

1. 先选定检测的类，参考OOD分析结果，仔细出类的状态和相应的行为，类或成员函数间传递的消息，输入或输出的界定等。

2. 确定覆盖标准。

3. 利用结构关系图确定待测类的所有关联。

4. 根据程序中类的对象构造测试用例，确认使用什么输入激发类的状态、使用类的服务和期望产生什么行为等。

值得注意，设计测试用例时，不但要设计确认类功能满足的输入，还应该有意识的设计一些被禁止的例子，确认类是否有不合法的行为产生，如发送与类状态不相适应的消息，要求不相适应的服务等。根据具体情况，动态的集成测试，有时也可以通过系统测试完成。

第36帖【2004－6－21】：面向对象的系统测试

通过单元测试和集成测试，仅能保证软件开发的功能得以实现。但不能确认在实际运行时，它是否满足用户的需要，是否大量存在实际使用条件下会被诱发产生错误的隐患。为此，对完成开发的软件必须经过规范的系统测试。换个角度说，开发完成的软件仅仅是实际投入使用系统的一个组成部分，需要测试它与系统其他部分配套运行的表现，以保证在系统各部分协调工作的环境下也能正常工作。　　

系统测试应该尽量搭建与用户实际使用环境相同的测试平台，应该保证被测系统的完整性，对临时没有的系统设备部件，也应有相应的模拟手段。系统测试时，应该参考OOA分析的结果，对应描述的对象、属性和各种服务，检测软件是否能够完全"再现"问题空间。系统测试不仅是检测软件的整体行为表现，从另一个侧面看，也是对软件开发设计的再确认。

这里说的系统测试是对测试步骤的抽象描述。它体现的具体测试内容包括：

· 功能测试：测试是否满足开发要求，是否能够提供设计所描述的功能，是否用户的需求都得到满足。功能测试是系统测试最常用和必须的测试，通常还会以正式的软件说明书为测试标准。

· 强度测试：测试系统的能力最高实际限度，即软件在一些超负荷的情况，功能实现情况。如要求软件某一行为的大量重复、输入大量的数据或大数值数据、对数据库大量复杂的查询等。

· 性能测试：测试软件的运行性能。这种测试常常与强度测试结合进行，需要事先对被测软件提出性能指标，如传输连接的最长时限、传输的错误率、计算的精度、记录的精度、响应的时限和恢复时限等。

· 安全测试：验证安装在系统内的保护机构确实能够对系统进行保护，使之不受各种非常的干扰。安全测试时需要设计一些测试用例试图突破系统的安全保密措施，检验系统是否有安全保密的漏洞。

· 恢复测试：采用人工的干扰使软件出错，中断使用，检测系统的恢复能力，特别是通讯系统。恢复测试时，应该参考性能测试的相关测试指标。

· 可用性测试：测试用户是否能够满意使用。具体体现为操作是否方便，用户界面是否友好等。

· 安装/卸载测试（install/uninstall test）等等。

系统测试需要对被测的软件结合需求分析做仔细的测试分析，建立测试用例。

第37帖【2004－6－22】：TMM介绍

测试是软件开发的重要过程之一，但是CMM没有充分的定义测试，没有提及测试成熟度的概念，没有对测试过程改进进行充分说明，在KPA中没有定义测试问题，与质量相关的测试问题如可测性，充分测试标准，测试计划等方面也没有满意的阐述。　

TMM是受CMM模型启发产生的，关注于测试的成熟度模型。它描述了测试过程，是项目测试部分得到良好计划和控制的基础。TMM测试成熟度分解为5级别，关注于5个成熟度级别递增：　

Phase 0 ：测试和调试没有区别，除了支持调试外，测试没有其他目的

Phase 1 ： 测试的目的是为了表明软件能够工作

Phase 2 ：测试的目的是为了表明软件不能够能够正常工作

Phase 3 ： 测试的目的不是要证明什么，而是为了把软件不能正常工作的预知风险降低到能够接受的程度

Phase 4 ： 测试不是行为，而是一种自觉的约束(mental discipline)，不用太多的测试投入产生低风险的软件上的

第38帖【2004－6－23】：软件测试自动化的概念

软件测试自动化，是一项让计算机代替测试人员进行软件测试的技术。他可以让测试人员从繁琐和重复的测试活动中解脱出来，专心从事有意义的测试设计等活动。如果采用自动比较技术，还可以自动完成测试用例执行结果的判断，从而避免人工比对存在的疏漏问题。设计良好的自动化测试，在某些情况下可以实现“夜间测试”和“无人测试”。在大多数情况下，软件测试自动化可以减少开支，增加有限时间内可执行的测试，在执行相同数量测试时节约测试时间。　

软件测试自动化通常借助测试工具进行。测试工具可以进行部分的测试设计、实现、执行和比较的工作。通过运用测试工具，可以达到提高测试效率的目的。所以测试工具的选择和推广使用应该给予重视。部分的测试工具可以实现测试用例的自动生成，但通常的工作方式为人工设计测试用例，使用工具进行用例的执行和比较。　

软件测试自动化的设计并不能由工具来完成，必须由测试人员进行手工设计，但是在设计时却必须考虑自动化的特殊要求，否则无法实现利用工具进行用例的自动执行。为此，就必须在测试的设计和内容的组织方面采取一些特殊的方法。　

对于软件测试自动化的工作，大多数人都认为是一件非常容易的事。其实，软件测试自动化的工作量非常大，而且也并不是在任何情况下都适用，同时软件测试自动化的设计并不比程序设计简单。

第39帖【2004－6－24】：自动化测试的优点

通过自动化测试，可以使某些任务提高执行效率。除此之外，还有其它优点：　

① 对程序的回归测试更方便。这可能是自动化测试最主要的任务，特别是在程序修改比较频繁时，效果是非常明显的。由于回归测试的动作和用例是完全设计好的，测试期望的结果也是完全可以预料的，将回归测试自动运行，可以极大提高测试效率，缩短回归测试时间。　

② 可以运行更多更繁琐的测试。自动化的一个明显的好处是可以在较少的时间内运行更多的测试。　

③ 可以执行一些手工测试困难或不可能进行的测试。比如，对于大量用户的测试，不可能同时让足够多的测试人员同时进行测试，但是却可以通过自动化测试模拟同时有许多用户，从而达到测试的目的。　

④ 更好地利用资源。将繁琐的任务自动化，可以提高准确性和测试人员的积极性，将测试技术人员解脱出来投入更多精力设计更好的测试用例。有些测试不适合于自动测试，仅适合于手工测试，将可自动测试的测试自动化后，可以让测试人员专注于手工测试部分，提高手工测试的效率。　

⑤ 测试具有一致性和可重复性。由于测试是自动执行的，每次测试的结果和执行的内容的一致性是可以得到保障的，从而达到测试的可重复的效果。　

⑥ 测试的复用性。由于自动测试通常采用脚本技术，这样就有可能只需要做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例。

⑦ 可以让产品更快面向市场。自动化测试可以缩短测试时间，加快产品开发周期。　

⑧ 增加软件信任度。由于测试是自动执行的，所以不存在执行过程中的疏忽和错误，完全取决于测试的设计质量。一旦软件通过了强有力的自动测试后，软件的信任度自然会增加。　

总之，通过较少的开销获得更彻底的测试，提高软件质量，这是测试自动化的最终目的。

第40帖［2004-6-25］：自动化测试中常见的问题

在软件测试自动化的实施过程中会遇到许多问题，以下是一些比较普遍的问题：　

① 不现实的期望。一般来说，业界对于任何新技术的解决方案都深信不疑，认为可以解决面临的所有问题，对于测试工具也不例外。但事实上，如果期望不现实，无论测试工具如何，都满足不了期望。　

② 缺乏测试实践经验。如果缺乏测试的实践经验，测试组织差，文档较少或不一致，测试发现缺陷的能力较差，那么首先要做的是改进测试的有效性，而不是改进测试效率。只有手工测试积累到一定程度，才能做好自动化测试。　

③ 期望自动测试发现大量的新缺陷。测试第一次运行时最有可能发现缺陷。如果测试已经运行，再次运行相同的测试发现新缺陷的概率就小得多。对回归测试而言，再次运行相同的测试只是确保修改是正确的，并不能发现新的问题。　

④ 安全性错觉。如果自动测试过程没有发现任何缺陷，并不意味着软件没有缺陷。可能由于测试设计的原因导致测试本身就有缺陷。　

⑤ 自动测试的维护性。当软件修改后，通常也需要修改部分测试，这样必然导致对自动化测试的修改。在进行自动化测试的设计和实现时，需要注意这个问题，防止自动化测试带来的好处被高维护成本所淹没。　

⑥ 技术问题。商业的测试工具也是软件产品，并不能解决所有问题，通常在某些地方还会有欠缺。测试工具都有适用范围，要很好的利用它，对使用者进行培训是必不可少的。　

⑦ 组织问题。自动测试实施并不简单，必须有管理支持及组织艺术。