浅析自动化测试框架(一)  自动化测试框架是什么？

    本文为原创，欢迎转载，转载请注明作者及来源(Felix ，TIB工作室)

   本文章是一个系列文章，主要的撰写目的是通过该系列文章，让大家对自动化测试框架的概念，类型以及创建有个大概的了解和认识，通过该系列文章，也许无法使人一下子可以构建起自己的框架，但至少希望可以帮助初学者可以在创建测试框架的旅程中踏下坚实的一步。当然由于本人的能力或视野的局限性，在文中有谬论之处，也请读者海涵。另外注意，本系列文章是针对功能测试自动化，而非单元测试或性能测试。本系列文章的初步计划编写的目录为：

1.       自动化测试框架是什么

2.       几种自动化框架的介绍

3.       如何构建数据驱动框架

4.       如何构建关键字驱动框架

5.       如何构建混合型测试框架

 

  自动化测试是什么？大家都很清楚，就是用程序测试程序的过程。那么,自动化测试框架是干什么的呢？维基百科上是这么给出定义的，“测试自动化框架就是支撑自动化测试的一系列假设，概念和工具。”这个概念定义的比较抽象，事实上，我个人认为自动化测试框架的概念并不是唯一的，因为在不同情况下，自动化测试框架的核心组成部分并不一定是固定。

比如大至整个自动化测试项目的文档，流程规定，约束，工具 ，小到一个简单的帮助函数都可能被称为自动化测试框架(只是很少有这种情况而已,^_^)。本系列文章依然着重于技术层次上的自动化测试框架，不会设计流程，管理层次上的。

 

  在我看来，自动化测试框架就像是个容器，一个包括了一系列构件的容器,每个构件包含一系列的约束，规则。我们把符合规则的文件放入各自的构件中，由框架解析文件，并根据预先制定的规则进行自动化测试，然后输出测试结果。如果这个大家还是不理解，没关系，我会在后面具体讲述如何创建框架时来诠释这个概念。

那为什么一定要创建自动化测试框架呢?它能解决哪些问题？其实构造不同类型的框架，其目的还是存在一定差异性的，但总体说来，构造框架的目的有以下这么几个

1.       类似于开发的框架，构建框架有利于自动化测试的协同开发

2.       框架中编写的公共函数库，可以避免代码的重复编写

3.       框架的不同构件设计，有利于松耦合测试脚本中数据，对象，逻辑之间的依赖关系，利于自动化测试的维护

4.       构建框架有利于多工具的整合使用，有利于跨平台操作，可以初始化测试环境

5.       如果需要分布式执行，那么也可以通过构建框架来处理相关的事务。

这里不理解也没关系，这些都会在后续的文章中提到。

  其实是否构建自动化测试框架，以及如何构建都是根据实际情况不同而具体分析，但一般情况下，构建自动化测试框架都是在已有的框架或工具上进行二次开发。毕竟现在开源资源这么丰富，实现没有必要再去重新写一个底层处理的工具。比如如果是进行web功能测试，可以有watir,watin,selenium等工具可供选择，进行C/S架构的客户端功能测试可以选择white等，当然如果条件允许，也可以选择商业工具，如QTP，Testcomplete，这些商业工具一般都提供扩展接口，对象接口可供使用。

  本文主要介绍了自动化测试框架的概念，目的，仅希望读者对框架有个初步的概念，在后续的文章中会进一步结合实际来阐述这些概念。

   使用OLeDB导入Excel，但是自己的机器上总是提示“数据提供程序要求 MDAC”之类的信息，连续搞2天才搞定它。现记录下来以备忘记。

  1.你的机器的mdac的版本确实过低，下载mdac进行安装

  2.机器上mdac的版本不低，但是就是提示版本过低，就是我这种情况，网上的主要解决办法是修复mdac，方法就是到 C:\Windows\Inf 这个目录，去重新安装mdac.inf.具体的可以google。但是我尝试了这个方法，问题依旧。那么，下载一个mdac的检查工具Componet Checker。运行后，会显示当前的mdac版本。然后选择第二项检查，选择对应的分析版本，然后就会出现一系列的分析结果，有mach,nomacht,not found。然后把缺失的文件以及注册表信息补齐就可以了。我是直接导入了别人的注册表信息（很危险的操作）才ok的。

了解性能测试-Part 251Testing软件测试网,F/y�h wQ6i

OkMkR.LjM61753作者： Dale Perry

Part 1V)v*dn k B @ V.w�r0l61753

• 测试过程中测试员的职责
• 确定性能和商业目标
• 如何把性能测试加入到开发过程

Part 2

_k qwi9M�|61753

• 系统架构和基础结构
• 选择要运行的测试类型

Part 351Testing软件测试网,yo e"` T!qgY

• 了解负载(业务概况)
• 测量的量化和界定

Part 4

Zg�z-[^C v61753

• 了解工具
• 执行测试和报告结果

  在本系列的第二部分，我将关注处理架构和基础设施的问题，选择合适的测试类型。本文的目标并不会涉及到所有的架构和基础设施，也不会涉及到所有的测试类型。但是会提供一般性的指导以帮助测试人员完成一份比较合理的性能测试报告。
 系统架构和基础设施

  架构和基础设施可能是致使软件性能测试失败最常见的原因。为了正确的测试一个系统或者应用程序，有几个关键的因素必须得到确保，至少也要提供相关有用的信息。

  我们将首先涉及有关物理架构的相关问题。这里有两个主要元素：1）应用程序和系统 2）软件运行所处的平台和网络

  如果部署的测试系统和生产环境(或目标环境)完全不同，那么测试就不能提供准确的性能数据。当我们涉及到系统的物理层，有几个关键的元素必须要阐述。

  系统的物理痕迹是很关键的。如果生产系统工作在一个多服务器集群，而测试环境是一个单服务器(没有服务器集群)，由于可测量性因素(scalability factor)，测试可能是没有价值的。可测量性因素是测试环境设备与生产环境设备的比例。一些人认为10：1的比例是可以接受的，但是我发现一旦比例超过5：1，就无法确保架构和基础设施的真实性。
图1展示一个3:1比例模型

 

Figure 1

 这可能是一个合理的数字，但是它们并不是一定契合生产环境的保证。在上图中我们漏掉了一个关键因素，在服务器集群中,你需要构建负载平衡。测试环境配置中没有这个因素。生产环境中的负载均衡是个瓶颈，因为所有事务都必须通过它来到达各自服务器。

除了物理层的可测量性问题外，我们也不得不检查每个平台的内部特性，以包含在测试中。

 

Figure 2

   上述模型在测试实验室是3：1，然而，在如下领域是有可疑的。它们之所以被怀疑是因为以下元素。第一部分描述一个系统和产品。第二个部分描述测试系统。他们在规模上是大大不同的。

• 生产环境的DB服务器是10 CPU，20GB内存
• 相当于1CPU对应2GB内存
• 测试环境的DB服务器是2CPU分享10GB内存
• 每个CPU有5GB内存
• 生产环境的APP服务器是20CPU分享10GB内存
• 相当于1CPU对应0.5GB内存
• 测试环境的APP服务器有2CPU分享10GB内存
• 每个CPU有5GB内存
• 生产环境的Web服务器是5CPU分享10GB内存
• 相当于1CPU对应2GB内存
• 测试环境的Web服务器是2CPU分享10GB内存
• 每个CPU有5GB内存

  架构的内部差异可能使测试环境产生或隐藏的问题而在生产系统中不会出现。如果你因为出现在测试环境下的问题而对系统或架构进行调整的话，你可能已经犯下了致命的错误并带到了生产系统中。

  确认架构和设施模型尤其是具有风险的。一些关系数据库的功能在不同的比例模型下的表现是有很大不同的。有很多方面需要调查:

• 驱动器的数量和大小
• 分发表和数据驱动器
• 表中的混合数据
• 索引，关键字，信号量的使用，等等
• 数据库管理系统的使用
• 参照完整性,存储过程
• 连接类型
• SAN，NAS，直接地
• 物理属性
• RAID, Mirrored, etc.
• 被其它应用程序分享

  当评估基础设施相关的物理层和可测量行问题时，我们也需要考虑某些要素的性质。一些机构中的元素是非线性的。拥有相等数量的资源不一定获得相应的性能。

  查看系统中的CPU使用情况。如果单处理器可以支持100用户，这样的话，是否再加一个处理器就可以支持200用户？不是这样的，这是不会发生的。两个处理器还要消耗部分能力用于处理它们之间的交互。添加第三个处理器可以进一步增加处理用户的数量，但同时降低效率。最后添加另外的处理器可能造成负面影响，进一步减少所支持的用户数量。
一个简单的CPU可扩展性的例子如下：

Figure 3

下面介绍架构和基础设施的最后一个元素 – 网络。 网络是一个类似管道系统的复杂的系统。小管道连接到大管道,大管道连接到更大的管道。信息从小管道流向大管道然后再返回。甚至可能你有一些控制点(阀门？)来管理流向。
How does the network in the test lab compare to the production environment? As with every aspect of the architecture and infrastructure, there are several key issues that need to be addressed, as shown in figure 4.

  测试环境的网络如何与生产环境的进行比较呢？有几个关键的问题需要解决，如下：

 

Figure 4

有两个途径评判系统和应用程序的可扩展性：

• 当前架构缩放比例（规划方面的能力）
• 测试瓶颈是为了防止系统处理过大的工作量
• 测试系统的功能和特性被忽视,但是它会随着系统的增长而变得重要。
• 一旦当前系统达到有效容量，架构要自我调整。
• 为了执行测试，需要额外的架构和设施

  由于各种类型的数据需要相当数量的架构和设施来模拟真实的目标环境（还有支持负载生成工具的环境）,大多数组织不能承受这些费用，这使我们又想到了外推法。

  外推法是一种趋势预测的方法。随着被测试系统的负载逐步递增,数据库或网络也呈现相当的递增级数。性能测试团队根据绘制的趋势图表

 问题是这种方法准确吗? 外推法本质上是一种系统功能的线性推测。正如我们早期关注的可扩展问题，系统和应用程序在很多关键方面的趋势并不是线性的。

如果你的环境不是很均衡的，预测将会更加不准确。

  当这种技术应用到复杂的系统或应用程序时具有很大的潜在隐患。所以最好在可行且存在的架构或者设施中进行测试，而不是靠推测。

  外推法可以应用到很有限的情况下。如果性能只是关注单一组件或者系统方面。

而且该部分具有线性特性，只有这样该方法才能应用。

• 举例来说，评估数据库一系列事务消耗空间数量是一个线性行为。数据的分散可能或可能不使用线性算法。如果只关注磁盘的使用情况，那么每个事务消耗的存储空间是有具体数量的。

正如我们所见，架构和设施需要的性能测试是非常难以确定和管理的。甚至还有很多问题这里都没有涉及到，如果在测试实验室中测试系统失败了，在生产环境中也可能失败。

选择测试类型

   当在确定哪种性能测试类型之前，我们必须首先知道我们需要解决什么问题。一旦你知道测试的总体目标和对问题有充分的来哦接，你就可以选择一个测试或者一系列的测试去审查那些问题。

通常地，我盟把性能测试分为3种普遍的类型：

• 基于负载源或类型的测试
• 基于我们想测量什么（测量目的）的测试
• 测试系统压力或发现瓶颈

上述列出的这些分类都有多种子分类和变种。我不会尝试去涉及每个可能的变种，但是会关注每个类型的子分类。那些测试可以回答我们在本系列之前部分讨论的大多数问题。下面让我们来看看具体内容。

大部分性能测试是由一种或多种测试类型（一个或多个分类）组成的。

基于负载源或类型的测试

• 基于使用的测试：根据业务概况，在测试环境下以同样的方式实际运行系统。
• 用户场景：一系列真实的活动，取决于用户如何实际操作系统。功能测试人员使用标准测试用例设计技术设计常规测试。就如边界值法，一个功能对应一个测试用例。这常常用在各个事务之间有复杂的交互的场景。
• 基准测试：使用标准的工作量，而不是用户指定的，当很难确定系统实际上如何被使用时，大多数的商业基准通过TPC.org公布。
• 负载变化和活力测试： 在模拟的真实环境中，观察负载在一段时间内的变化，以及相应的各种性能指标的变化。模拟系统需要在早期部署好。
• 可扩展性测试： 通过增加每个用户的工作量，并发用户数量，数据库的大小，连接到网络设备的数量等等，考察系统增长能力(能否适应这些增长)
• 正如我们之间提到的，有两种可扩展类型。在当前架构和基础设施达到满负荷下扩展；自行的扩展架构和基础设备。
• 特定组件测试：考察性能和系统组件的健壮性。在被测组件准备好就可以进行测试，不必等其它组件。
• 校准测试： 检查系统是否符合委托的标准。

基于测量目的的测试

• 响应时间测试：测量系统完成一个或一组任务的时间
• 响应时间通常关注使用者和客户的感受。
• 一些响应时间测试可能是由组件和SLA驱动的，比如测试第三方接口(比如电子商务程序的信用卡处理过程)
• 吞吐量测试：测量一个单元的吞吐量，比如系统中一个点会通过多少流量，在指定的时间內或者指定的压力下完成多少任务。
• 可用性测试：记录系统或组件运行时间的百分比
• 一个通用的行业参考，被称为5个九 – 99.999%。这是一个可用性和可靠性都相当高的水准。
• 资源利用测试：监视系统资源使用的情况，如内存，CPU，线程等等。
• 出错率测试：有些地方也称为“健壮性”。测量当系统处于正常或过重负载情况下的功能出错率。还有当负载增加或者改变时可能引起错误的增加。
• 系统和应用程序是否可以处理错误的增加？如果用户不能使用功能，再快的响应和再大的吞吐量也是没用的。

测试系统压力或者发现瓶颈

• 斜坡式测试：对于这个概念有几个解释。
• 测量启动进程所需的时间。
• 比方说,一个未工作的网络设备在需要它工作而被启动时，它必须在50毫秒内开始工作。
• 术语斜坡式测试也可以被解释：在系统开始运转期间， 逐渐地增加测试负载而不是突然增加到最大负载以避免系统崩溃。
• 在极端情况下，可能出现在系统上的活动突然激增。这方面的一个例子是如果用户尝试登录崩溃后重新回复的系统，突然增加的活动可能再次导致系统崩溃。
• 持续和耐力测试：有人把这个当作可靠性测试的一部分。在测试环境下持续运行被测系统一段时间(几天或者几周),这样可以用来发现那些需要运行长时间才会出现的bug，比如内存泄漏。这对于那些不间断的系统特别重要，比如电子商务系统或自动柜员机。
• 热点测试：关注系统中指定的，有限的一部分以确定该部分是否是个薄弱点。
• 在一个应用程序的通常部分也能可能进行该类型测试。比如，待电子商务网站出售特殊时刻的礼品。可以预见在节假日会出现蜂拥而至的交易。然而目标系统应对这种情况是非常困难的。在母亲节，整个网站都处于活跃状态，但是在情人节，大多数活动都集中在单个产品区域（长茎红玫瑰和巧克力）。我们就可以在这些点设立“热点”进行测试。
• 钉子测试：在非常短的时间内使系统处于高负荷的工作状况下，用于确定系统如何处理突然增加的高负载需求。此测试用以验证系统能够应对快速的重大变化以及改变资源的使用。比如，使用负载均衡。
• 这种测试类型的有效性取决于被测系统的类型
• 主机，局域网/广域网和局域网类型的程序对连接到系统中的设备数量只有相当有限的潜力。
• Web 和 基于局域网应用程序拥有几乎无穷尽访问的可能。某些安全攻击，拒绝服务攻击和分布式拒绝服务攻击是极端的由黑客引起负荷的例子。
• 断点或故障测试：增加负载直到系统出现故障或达到测试环境负荷极限。它也许不可能生成足够的负载以使系统发生崩溃，取决于负载生成的用户（授权的数量是个关键因素）
• 这个测试对于验证系统工程师是否已经对系统进行了安全设置有帮助,比如应用程序阀值。这些内在的控制可以防止应用程序或系统发生崩溃。
• 死锁测试：运行高容量测试（可能来自不同应用程序源）来发现系统中是否存在资源竞争，比如多请求试图同时访问同一数据库，并造成由于区域冲突而被系统锁定用户请求，比如数据库记录锁定。
• 运行退化模式测试：在不是所有资源在工作的情况下，确定系统是否仍能提供预期的服务水准。（一个降级模式测试的例子是在服务器集群中故意断电一台服务器，并试图继续正常操作。）

使用哪种类型的测试取决于早期确定的性能目标和潜在问题存在于应用程序，系统或者架构中的位置。测试的压力类型通常与测量类型结合。我们使用业务跟踪（在本系列第三部分介绍）来创建我们需要的应用程序或系统的活动类型，进而评估出那些我们感兴趣的区域。

如果我们对以用户的角度看端对端的响应时间感兴趣，我们应该运行基于使用的测试并结合测量类型。（测量CPU，内存使用，线程等等）。当我们不知道问题将发生的位置时，我们需要结合几种测试类型。如果我们发现响应时间的异常，我们需要采取措施帮助性能测试团队的技术人员定位和解决问题。

  我们已经了解性能测试过程，性能目标，以及已经涉及了架构和基础设施问题，我们需要关注测试的内容。在本系列的下一部分，我将介绍确定负载（操作跟踪） 和 测试中的测量。

原文地址:http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=14891&tth=DYN&tt=siteemail&iDyn=2

`!@*H5Z Ae2E.C61753

  本文章由本人翻译供大家学习之用，版权归原作者所有。原作者如有任何异议，请通知本人删除,且未经书面授权许可，任何网站或个人不得转载。另由于本人翻译水平有限，很多不当之处请见谅。

了解性能测试-Part 1

作者： Dale Perry
   大多数软件性能测试项目失败，这里我所说的失败，并不是意味着测试不正常的终止，而是不能给需求方提供任何有用的信息。

  引起失败的原因有很多。在这个系列的文章中，我将讲述性能测试中出现的基本问题和如何去避免他，你将理解很多问题以及你能不能解决它们。本系列并不能涉及到所有问题，也不适合于高级性能测试工程师。希望大多数读者可以学到如何从失败中找到解决的方法。
 本系列文章中将涵括以下几个方面的内容：
Part 1

• 测试过程中测试员的职责
• 确定性能和商业目标
• 如何把性能测试加入到开发过程

Part 2

• 系统架构和基础结构
• 选择要运行的测试类型

Part 3

• 了解负载(业务概况)
• 测量的量化和界定

Part 4

• 了解工具
• 执行测试和报告结果

以上这些内容可以按照很多不同的次序讲述。但我将按照我认为最有效的次序进行阐述。这种方法已经被应用到各种类型的平台:大型机，C/S，嵌入式,web等等。 第一部分讲述测试者的职责，了解性能目标以及如何使性能测试适合开发过程。
测试者的职责

 在性能测试中，性能测试员很像一个顾问，你指导和协助技术人员识别和改正问题。性能测试员进行测试，并不改正,调试或者关闭发现的问题。成功的性能测试是团队共同努力的结果。任何关键的成员都可能不得不条则会调整，修复，调试系统或应用程序，做出对实现性能目标有益的事情。
 

完整的性能测试团队应该包含如下关键成员：

•  测试/质保团队
•  用户/顾客
•  经理
•  市场销售人员
•  开发全体人员
•  网络管理员
•  系统管理员
•  安全管理员

 没有尽早的使关键人员加入到测试过程中，几乎一定会有问题在后面被提出。促使关键人员尽早的加入到性能测试计划可以确保减少后面出现问题，尤其是在测试结果不是太好的时候。

 

 验证性能和商业目标.
接下来，我们需要明确验证的目标和性能测试的目的。人们在性能测试中最好犯的一个错误是思考的全是他们需要的性能测试工具(我们将在第四部分讨论工具)。当然工具是必不可少的，工具提供了解决问题的答案。但是在此之前，你需要知道问题是什么。不知道哪些性能问题需要你解决，就很难鉴定你的性能测试是成功还是失败。
   我经常被问到的第一个问题是“我如何分析工具产生的测试结果？”。我的回答是“你希望你的工具做些什么？”。大多数人不能回答这个问题。这是第一个指标指示你的性能测试可能是没有什么价值的。
   大多数情况，测试员从经理那里获取整体的指导。然而，经理倾向于关注投资效益和用户满意度，但是那些都不是性能指标。不了解性能测试项目目标和目的，即使工具带给你的大量信息，你也无法解释，乃至达到经理的预期。
   收集和确定性能测试目标可能是整个性能测试过程中最枯燥的部分。然而，时间会告诉你有些事情必须在前期就要做。如果你不能获取你需要的性能指标，进行性能测试是没有任何意义的。
 了解性能指标的第一步就是把它们从商业目标中分离出来。如下图1

图1：从商业目的中分离出性能指标

  为了达到软件性能指标，有一些系统或者应用程序的指标是需要我们在测试过程中去度量的。糟糕的性能表现通常是在压力或者即将到达最大容量的时候发生的。如果你不能设计这些方面的测试，那么就不能算是完成任务。下面是一些问题，这些问题对于确定性能目标与测试目标的异同点是很有好处的：

• 我将执行什么测试？
• 我将收集哪些数据？
• 为了度量“ 性能”，你必须收集系统和应用程序运行时的相关信息
• 我如何证明目标已经实现？
• 我测量什么才能证明制定目标或目的已经达到？

“性能”定义是在给定的环境下的行为表现。比如你评审一个用户的效率。没有系统指标给你去测量以证明哪个用户效率更高。

如何使性能测试融入到开发过程

很多人把性能测试看作产品在交给客户之前才要做的最后一件事。这既是错误的也是危险的。图2显示了性能测试的通用做法。它依赖于一个完整的系统或者应用程序。

图2：性能测试的一般做法

使用这个方法的主要问题是:如果有问题产生而要做需求变更时可能要重新测试变更对功能的影响。这时重点需要注意的是同一时间超过一个功能变更就将很难协调。多个技术团队将问题变得复杂且难于协调。也有可能产生模糊不清的解决方案。同时调整数据库和程序代码可能会出现彼此覆盖的情况。因此，很多团队是使用一次一个的方法（OFAT）

遗憾的是，OFAT在如下的情况下并不能很好的工作：

• OFAT假设元素是彼此孤立的
• 有很多复杂的，难于理解和隐藏的依赖关系
• OFAT花费时间太长
• 其它方法很难很好的应用

举例来说，一旦问题被“fixed”并重新进行测试，我们可能发现新的关于网络或程序的问题而不得不去“fixed”。而这可能又产生更多的问题。这可能最终成为死循环，周而复始。
   是的，性能测试需要一个稳定的环境和软件。然而，这并不意味着所有功能都要是完整的。可以使用预防性思维（静态测试）和增量迭代开发方法，在有几个稳定可用功能的情况下也可以进行性能测试。
   增量和迭代开发模式给尽早的执行性能测试提供了便利。通过在开发过程早期确定性能问题，就有很多机会在解决问题成本提高之前去改正设计和架构 。


图3：增量和迭代开发过程中允许早期进行性能测试

一旦第一个build版本的功能测试结束，在开发团队继续开发下一个迭代时性能团队就可以开始测试了。这样做有两个好处：基本架构得到了尽早的测试，由于只是局限于一个完整的功能，修改架构和设计的代价也很小。缺点是协调开发团队和性能测试团队比较复杂。

 如下列出开发过程早期可能通过静态方法发现的在网络，应用程序以及数据库中存在的问题
    网络问题：

• IP连接和HTTP的使用情况
• 过度的使用安全功能
• 负载均衡的类型和特征
• 应用程序服务器与数据库服务器之间的交互
• 包的大小(应用程序网络规模的大小)
• 连接池和连接共享
• 服务器在网络中的位置
• 增加的延迟

应用程序问题：

• 过多的内存分配和取消分配
• 不正确的任务初始化和管理
• 不正确的垃圾收集,特别是产生失败或故障之后
• 缓存丢失或者缓存存在太久
• 持久性应用，比如黑莓设备
• 应用程序配置参数冲突
• 高资源消耗的功能(CAD/CAM，等等)

数据库问题：

• 索引设计
• 动态索引的使用
• 锁定连接中可能存在的死锁
• 使用效率低的缓存
• 过度使用的缓存
• 使用资源集中的功能，比如参照完整性
• 存储过程和触发事件的使用
• 表碎片(第三范式过度使用)
• 不正确的时间表和索引重组

如果你能在他们系统设计之前发现性能问题，他们将节约很多的钱去做正确的事情。诚然，这将减缓项目进度用以整治和改正需求或者设计。然而，项目后期做设计修改将对项目有更大的影响，而且重新设计还要承受影响项目进度的风险。

无论选择哪种方法，性能测试的设计和分析活动都必须从需求阶段就开始。等待太久对于性能测试团队就意味着灾难。测试者是性能专家的眼睛和耳朵(典型的是系统管理员，数据库管理员，网络工程师，和开发人员)。

由于性能测试的复杂性，需要大量的资源。有些公司会外包一些或全部的测试工作。通常情况下，会外包那些与业务知识关联不大的而不是那些需要精通公司业务的测试者参与的测试工作（比如性能测试）

专注于性能测试的公司具有很多重要的技术。但是，除非你有妥善的计划，否则不要指望外包测试。外包测试者需要做同你一样的任务，而且他们要从你那获取信息。这相当于你付钱让别人告诉你已经知道的答案。如果你请昂贵的专家帮助你解决性能问题，确保在他们抵达之前你已经准备好初步的性能测试脚本。这可以节省大量昂贵的“闲暇”时间。

如果性能测试是远程的，而且应用程序或者系统在开发或测试以及处在组织的防火墙下，要进行可行性测试以确保远程测试员可以通过防火墙访问被测试系统。

大多数的外包承包商可以分为以下一个或多个类型：

• 现场顾问 – 顾问在客户的县城工作
• 远程顾问 – 顾问在他们自己地方工作，系统或者应用程序位于客户端。
• 测试实验室 – 应用程序或系统处于远程测试的位置，在那儿顾问可以安装和测试他们
• 应用服务提供商或管理服务供应商 - 内部工作人员利用硬件和软件托管在第三方的位置测试他们部署在自己站点的应用程序或系统。

了解关于性能测试各种作用以及把性能测试尽早得整合到开发过程中是测试成功的关键。如果你没有把握关键和尽早的开始计划，成功地几率是很低的。一旦那些关键问题处于可控状态，我们就可以开始分析问题，设计一套必要的性能测试。在本系列的下一部分，我将把问题通架构和基础结构结合起来，从而确定需要进行的性能测试类型。

原文地址:http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea&id=118

  本文章由本人翻译供大家学习之用，版权归原作者所有。原作者如有任何异议，请通知本人删除,且未经书面授权许可，任何网站或个人不得转载。

 

什么是测试计划？

回答：

 

2. 测试计划在什么时候创建为最佳？

回答：在项目的一开始就应该创建最初的测试计划，该计划成为“主测试计划”。随着每次迭代的筹划，将创建一个或多个更精确的“迭代测试计划”，其中包含与指定迭代有关的更精确的数据。所有测试计划内容都建立在测试计划模版的基础上。上面一段话可能难于理解，下面以“瀑布式”开发模式为例来讲解一下具体情况：

如上图所示，对于确认及系统测试，在需求阶段就可以进行《测试计划》的编写，在执行测试计划之前的几个阶段都是在对测试计划进行完善设计的过程。

3. 测试计划的作用是什么？

回答：1） 提高测试工作的效率以及准确性，让测试工作有条理，有计划的进行，避免测试的“事件驱动”

      2） 使测试工作与整个开发活动更好的融合

      3） 规避风险，使资源和变更事先作为一个可控制的风险。

4. 测试计划由哪些部分组成，各有什么作用？

回答：《测试计划》作为一个测试阶段的重要文档，各个公司根据实际情况的不同会定制符合自己情况的模版，下面我给出了一份在RUP中定义的《测试计划》模版，此模版可以自己根据情况定制。

《测试计划》模版 见附件

5. 制定测试计划有哪些步骤？

回答：

6. 什么是测试需求？

回答：

 

7. 确定测试需求的作用是什么？

回答：1）确定测试对象以及测试工作的范围和作用

2）确定整个测试工作（如安排时间表、测试设计等）并作为测试覆盖的基础

8. 确定测试需求的信息来源是什么？

回答：现有的需求列表，、用例、用例模型、用例实现、补充规约、设计需求、商业理由、最终用户访谈以及对现有系统的复审（PS：上面几种来源中最重要的是设计需求，其他文档在很多公司都是缺少的）

9. 测试需求有哪几种类型，它们的具体内容分别是什么？

回答：分为 功能性测试需求，性能测试需求，可靠性测试需求。

  功能性测试需求来自于测试对象的功能性行为说明。

  性能测试需求来自于测试对象的指定性能行为。

可靠性测试需求有若干个来源，它们通常在补充规约、用户界面指南、设计指南和编程指南中进行说明。

10. 评估风险的目的是什么？

回答：最大限度的提高测试效率并确定测试工作的优先级，制定一个可接受的测试顺序。(PS:简单的说就是把测试需求进行优先等级的划分，并描述这样划分的理由)

11. 确定测试优先级的目的是什么？

回答：1）确保将测试工作的重点放在最恰当的测试需求上

2）确保尽早地处理最关键，最有意义或风险最高的测试需求

3）确保在测试中考虑到了任意依赖关系（序列，数据等等）

12. 如何评估风险并确定测试优先级？

（PS：该问题篇幅很大，但在实际应用中大部分公司都没有应用该技术，所以只需了解即可，不必认真研究）

回答：具体的步骤如下：（图在下一页）

1）评估风险

第一步：在评估风险之前，首先要确定并说明将要使用的风险程度指标（即优先级别的具体划分），一般的划分方法如下：

H  - 高风险，无法忍受。

极易遭受外部的风险，公司公司将遭受巨大的经济损失、债务或不可恢复的名誉损失。

M - 中等风险，可以忍受，但是不希望其出现。遭受外部风险的可能性最小，公司可能会遭受经济损失，但只存在有限的债务或名誉损失

L - 低风险，可以忍受。根本不会或不太可能遭受外部的风险，公司只有少许经济损失或债务或根本没有损失。公司的名誉也不会受到影响  

第二步：列出测试需求并为每个测试需求确定风险程度指标，并简要说明选择相应指标的理由。

可以从三个方面来评估风险：

（PS: 一般确定一个测试需求只需从一个方面来确定风险指标，但是对于确定为低风险的测试需求，最好在从另一方面进一步来确定风险指标）

影响 - 指定用例（需求等）失效后将造成的影响或后果

简单的来讲，就是如果测试需求没有得到满足，会产生什么不利影响，而这个影响处在什么风险等级上。

询问下面的问题来确定影响，“如果。。。。。。。。。，将出现什么情况”

原因 - 用例失效所导致的非预期结果

  根据原因评估风险。在开始时可以声明某个非预期的事件或条件，并确定一组能够允许该条件存在的事件。询问如下问题：

“___________为什么会发生？”

可能性 - 用例失效的可能性

根据可能性来评估风险也就是确定用例（或实施用例的构件）失效的概率。这种概率通常基于某个外部因素，例如：

故障率和/或密度

变更率

复杂性

来源/始创人

 

应该注意的是：当根据这一方面来评估风险时，风险程度指标与发生故障的概率相关，而不是与故障对组织的影响（它用于根据结果和原因来评估风险）相关。

这些因素与发生故障的概率之间存在以下相关性：

 

2）确定实施概要

  第一步，确定实施概要程度指标，一般的划分方法如下：

H - 使用得相当频繁，在每个时期会使用很多次，或者由多个主角或用例使用。

M - 使用得比较频繁，在每个时期会使用若干次，或者由若干个主角或用例使用。

L - 很少使用，或者由很少的几个主角或用例使用

通常，用例或构件的使用次数越多，实施概要指标也就越高

第二步，列出测试对象中的每个用例或构件。为列出的每一项确定一个实施概要指标并且说明每个指标值的理由。工作量分析文档中的信息（请参阅工件：工作量分析文档，该工件我会在另一个问题中进行讲解）可用于此评估。

3）确定测试优先级

第一步，确定和说明将要使用的测试优先程度指标，一般的划分方法为：

H - 必须测试

M - 应该测试，只有在测试完所有 H 项后才进行测试

L - 可能会测试，但只有在测试完所有 H 和 M 项后才进行测试

第二步，列出测试对象中的每个用例或构件。然后，为列出的每一项确定一个测试优先级指标并且说明您的理由。以下为确定测试优先级指标提供了一些指南。

当确定每一项的测试优先级指标时，应考虑下列各项：

先前确定的风险程度指标值

先前确定的实施概要程度指标值

主角说明（主角是否有经验？他们是否能够接受变通方法？等等）

合同责任（如果不交付用例或构件，测试对象能否被接受？）

确定测试优先级的策略包括：

对于每一项，将最高的评估因素（风险、实施概要等）值用作总体优先级。

确定一个最有意义的评估因素（风险、实施概要及其他），然后将该因素的值用作优先级。

使用评估因素的组合来确定优先级。

采用权重方案。在该方案中，将确定每个因素的权重，然后根据权重来计算各因素的值和优先级。

示例：

当使用最高的评估值来确定优先级时，得到的优先级为：