在近期的一个大型项目中，我们在初期就制定了目标,我们不想让很多的QA人员手动测试我们的软件。通过手工测试来发现漏洞是非常耗时的，成本也很昂贵, 尝试尽可能从软件内部着手构建高质量的产品。这并不是说,手工测试应经无用武之地, 手动测试常常能触发某些你无法预期到的软件使用行为。

这是一个18个月左右的长期项目, 后续还会有持续更新。先前我们就发现,一个好的测试策略对项目的成功是至关重要的,特别是让我们的团队能够：1）随着时间的推移持续提高我们的效率,2)有信心应对我们的应用程序的大大小小的变更。

为了建立一个有效的策略，我们花了相当长一段时间。这主要是因为我们不得不学习如何在应用程序的每一层来设计我们的应用程序的可测试性。我们的团队成员之前都有很丰富的TDD经验,但这并不是我们需要创建一个有效的测试策略的唯一技能。

测试的层次

为不同的测试分类是很麻烦的。你需要有功能测试、集成测试、单元测试、验收测试,缓慢测试,快速测试,界面测试,等等。我们发现我们的测试属于三个主要类别:

*系统测试

*皮下测试

*单元测试

每个测试所测的内容的视角都是不同的。一个完整系统测试通过外部接口测试应用程序,测试诸如浏览器,文件下拉菜单,队列,WinForms应用程序这类问题。

皮下测试工作直接针对用户界面以下的内容。在一个web应用程序的环境中, 我们的我们用例的其中一个皮下测试是在所有的真实的类和实现都部署到位的前提下，通过命令行处理器发送的表单对象。我们绕过仅仅包含界面逻辑的控制层,直接到领域层。发送表单对象后,就能获取成功/失败的测试结果。

最后,我们有单元测试。单元测试的目的是测试一个类,可以是快或慢的测试。快速测试是正常的TDD测试,用于构建类的设计。根据需要进行重复测试,但严格interaction-based测试没有多大价值,除非我们找到非常有趣的交互。我们也有缓慢的单元测试,也可以归类为集成测试。这些将是诸如库测试、持久性测试,等等。

不同类型测试的比例，单元测试:皮下测试:系统测试在10:2:1附近徘徊。我们完成的这个项目大约有5000个单元测试，1000个皮下的测试中和500完整系统测试,使用WatiN和Gallio来驱动一个浏览器。这6000个单元/皮下测试大约10分钟执行完毕,然而500个UI测试需要大约50分钟完成。

单元测试策略

单元测试是在一个相当严格的TDD方式。在任何设备投入使用之前，我们都会编写测试，并使用测试驱动代码的设计。这些测试帮助识别设计问题,封装问题,代码问题等等。

我们努力避免编写纯粹用于提供测试的代码。它们常常意味着我们有设计问题、责任错位或封装已被破坏。

当我们进一步深入到项目管道,我们开始越来越少使用交互测试。也仅仅是满足对此真正感兴趣的人的兴趣而已。但更多的时候,我们更感兴趣的是它的副作用,而交互是一个实现细节而已。我们经常所做的反而是模拟缓慢或不可测试,如存储库,在外部服务facade,配置等。否则,我们模拟仅限于我们很感兴趣观察点。在大型项目中,它可以变得很明显,你的设计需要一个large-level重构,提取其中的概念使其更快实现交付功能。在我们最后的项目,一些概念发现包括:

§  AutoMapper

§  处理的形式作为单独的命令消息

§ Input builders

有了所有这些，单元测试实际上是重构的一个保障。但只有我们依赖这些测试来覆盖应用程序中所有有趣的行为时，才能起到保障的作用。为了有效地允许大型和中型的重构，我们需要额外的测试级别。

皮下测试策略

皮下测试,就像他们的名字所暗示的, 测试一切都只是用户界面的表面之下。在MVC应用程序中, 所有这些测试将只是控制器下的所有内容。对于一个web服务,一切都在端点。这个想法是，最上层的应用程序不执行任何实际的业务逻辑，而只是连接的外部接口与相关服务。

皮下测试的重要性体现在我们希望在绕开如用户界面和外部服务来测试业务逻辑的情况下。单元测试只是聚焦在小规模设计上,皮下测试并没有关注设计, 而是将被测系统作为一个整体来关注输入和输出。

为了构建一个有效的皮下测试,我们可以试着通过共同的逻辑流构建统一的压力点。例如,我们可以构建一个命令消息处理系统,或者一个通用的查询接口。在最近的一个项目中,批处理文件中的每一行变成了一条消息。我们可以起草一个消息，通过系统发送，然后验证处理该消息的所有副作用。

由于皮下测试解决高层次的行为，而不是设计,他们非常适合基于场景的测试策略，如BDD或测试类夹具的模式。如果我们希望能够执行大的重构,我们需要这些高级测试创建wide-cast安全网的业务行为。皮下测试也是调用功能的大目标点,他们关注的更多是终端到终端的逻辑。

而皮下测试使我们能够安全地执行较大的重构，他们仍然不提供一个我们的系统将在生产中运行的令人满意的信心水平。

全面的系统测试策略

我们的团队最初称这些测试为“UI测试”，直到我们更多的项目和更多的整合策略。其中输入我们的系统的不是一个浏览器，而是消息，一个REST端点，或FTP下拉菜单，批文件的处理。UI测试是全系统测试的子集。一个完整的系统测试背后的想法是,我们想要测试我们的软件,因为它可能会用于生产。对于一个MVC应用程序,这些将是基于浏览器的测试。对于批处理文件,我们将使用实际的文件。REST中，是实际的HTTP请求。消息，是真正的队列和消息。

在产品上线前，如果我们想知道应用程序能否按照预期运行,一个有效和高效的方法是创建一个自动化的测试,测试完整的系统。如果我的基于UI的测试可以登录应用程序，并下订单，然后可以验证是否生成一个订单。我感觉是一件很不错的事情。

有关完整的系统测试中一个常见的误解是，他们是黑盒测试。他有自身的特点，全系统测试要求必须能了解系统内部发生了什么。实际上，全系统测试甚至可以采用领域模型来构建数据，而不是通过纯粹为了测试的系统后门来创建测试数据。团队中常犯的错误是，不按照与产品实际应用一直的路径来测试代码，导致系统处于奇怪的、失效的和无法处理的状态。

在我们的项目中，全系统测试时我们生成一个特性/用户故事完成之前所写的最后的代码。手工测试的成本太高，而且也无法可靠地验证一个特性已完成。但如果我可以通过外部接口来验证产品实际使用时的操作，这是成功的。

整体策略

对于一个待测系统，为了提高覆盖率，我们发现最有效的测试策略是从全系统测试开始，逐渐深入到单元测试。首先使用宽松的但是简单的断言，然后逐渐深入单元级别的逻辑。对于一个新的应用程序，我们倾向于不只是关注一个区域，对于一个长期维护的系统来说，所有的测试都是很重要的。

我们这种测试策略确实需要一定程度的投入。当知道这个应用程序对于客户的业务来说至关重要时，我们发现这种整体策略是非常有效的。如果应用程序是关键业务, 它定会发生变更，如果发生需求变更，我们最好能安全的实施变更，而不会影响我们的客户的业务。

【英文原文：http://lostechies.com/jimmybogard/2010/08/25/an-effective-testing-strategy/】

一位网友问道：看似测试架构师与测试经理干的活很类似，很多都应该属于测试经理干的活，没看出测试架构师有什么不同。我想下面的内容应该能解决你的疑惑吧。

由于我们公司在中国有几百名测试人员，在测试团队中除了普通的测试工程师，主要就是测试经理和高级测试工程师，仅几个测试架构师在为少数的产品线所服务，而且大部分测试架构师也只为1个大产品而服务，能带领大产品线的人其实很少的。

先介绍目前测试经理，测试架构师，高级测试工程师三者的简单分工：

测试经理：人员考评，项目计划，人力资源和物料资源协调，测试活动组织；

高级测试工程师：为项目组完成测试技术准备，测试用例设计及指导，自动化测试设计及指导，培养测试人员业务技术能力和测试技术能力，支撑市场技术活动，规划自动化和测试工具需求，从技术角度支撑项目质量目标。总得来说，是测试组内的第一测试技术专家，是普通测试人员在技术上直接求助的对象。

测试架构师：把握产品测试重点和测试活动质量，领导和培养高级测试工程师，指导高级测试工程师选择正确的事来做，树立正确的意识，不断提高各种测试设计的质量，并传授新的测试方法或测试技术给高级测试工程师。通过高级测试工程师来影响和帮助产品测试组的测试质量持续改进。总得来说：是高级测试工程师技术上的直接求助对象。对于能力较强的测试架构师更能够拉通一个产品线多个产品的测试公共技术，向测试总监负责。

试想一下：一个产品的测试经理可能有一个或二个高级测试工程师帮他把组内的测试技术发展起来，扫清测试活动中的技术障碍。可是对于管理数个产品的高级测试经理或测试总监，他们的管理工作会耗掉大量的工作时间，日子一久在测试的技术上势必会逐渐跟不上业界的发展，即使依然能保持测试技术的先进性，也有心无力，没有时间来把握每个产品的测试技术方向。这时管理多个产品的测试管理者就需要一个能分担测试技术的帮助者，能替他继续把关每个产品的测试活动质量，专项解决各种测试技术问题。正如产品测试组中的高级测试工程师一样，这位帮助测试总监或高级测试经理的测试技术领导者就是测试架构师。

不过，目前为止所谈到的测试架构师只是复合型测试架构师，我们还可以针对测试专项技术细分专项的测试架构师，例如：专注于自动化测试平台的测试架构师，专注于代码级测试技术的测试架构师。这些专项测试架构师的工作成果不仅仅是只适用于一个产品或一个产品线，而是应该对整个公司所有产品线服务和支撑的，才能有足够大的平台或舞台供他施展。如果工作成果只是为一个产品服务，那么就和传统的高级测试工程师相当。

在业界不同的公司对测试架构师的要求也有所不同。在微软对测试架构师的定位是独立贡献者，在我们这里复合型测试架构师必须要有领导力和影响力，因为你是高级测试工程师的标杆和领导者，需要对多个测试团队服务，带领高级测试工程师团队。即使只是专项测试架构师也需要一定的领导力，因为专项测试技术的研究和落地基本都也是以团队的形式在进行，甚至有时是以虚拟团队的形式在开展工作，成员来自不同的团队，平时大部分时间是产品测试工作。这时是需要专项测试架构师做好团队的组织，分工，协调和领导工作的，团队的方向需要专项测试架构师来把握。

    最后，如果你所在公司的测试人员在20－30人以下，或许测试经理足够强，那么他可以一个人把测试项目经理，高级测试工程师，测试架构师的职责都包下来，这时的测试经理就包括了测试架构师的工作职责。如果你所在公司的测试人员在数百人以上，肯定公司会有同时管理数个产品或数十个产品的测试总监，或高级测试经理，这时为了更充分的利用测试队伍中稀有的有丰富测试经验的专家技能，不让其稀有的技能仅在一个产品中发挥作用，而在整个公司发挥作用，帮助尽可能多的产品测试组，就有必要组建测试架构师团队；或是为了能有人替高级测试管理者监控产品测试组测试技术活动的质量，也是有必要组建测试架构师团队，担负起测试活动质量的监督者和改进者。

    还有疑问，欢迎留言或与我email讨论。

序：此只是简单的一个打酱油似的B/S架构的自动化测试调研，希望能对大家一点点启发，最好集大家之所成能给我一些建议和启发，万分感谢

一、目的
为了能够提高B/S架构的应用程序测试的测试效率。
二、应用范围
B/S架构的应用程序的应用功能测试与验证测试。
三、工具选型与比较
3.1 主要应用工具介绍
主要应用的测试工具包括以下几种
1）QTP, QuickTest Professional. 采用了关键词驱动（Keyword-Driven）测试的理念,关键字驱动或者称为关键词驱动（Keyword－Driven），是为了解决通过录制的方法来产生脚本的问题。就是先把所有需要的Web对象都添加到对象库中，然后在关键字视图中手动添加测试步骤.
2）RFT, Rational Functional Tester，是一个面向对象的、自动测试工具，它能够测试各种应用程序。可以应用其进行WEB对象的抓取。
3）Selenium， ThoughtWorks 专门为 Web 应用而开发的自动化测试工具，适合进行功能测试、验收测试。
4）Watir ( Web Application Testing in Ruby) 是一个优秀的开源工具，用于开发基于Web 应用的自动化测试程序。它使用Ruby 脚本语言，提供了轻量级的自动化测试程序框架和丰富的开发库，有效地加速了自动化测试程序开发。
3.2、工具应用比较
1)、QTP采用关键词驱动和描述性编程的方法，其成熟度广，应用普及率较广，框架搭建较简单，但其价格昂贵，采用的是activex驱动模式，灵活性低，不易与自身平台进行结合。
2)、RFT可以支持WEB自动化测试，但仅仅是对其对象的获取，而且其还对C/S架构的APP支持，其灵活性低，价格昂贵，但其的自动化测试架构可以重用C/S类型的。自动化测试项目。
3)、selenium
 优点：a）其原理即基于WEB内核机制。其直接运行在浏览器之上，所见即所得，就像真实用户所做的一样。Selenium 的核心，也称 browser bot，是用 JavaScript. 编写的。这使得测试脚本可以在受支持的浏览器中运行。
      b）灵活性高，易整合到自己平台，其测试用例可以采用两种方式撰写：test runner （HTML文件）和 driven（脚本语言编写），其语言包括Java, .NET, Perl, Python 和 Ruby. 使用 driven 脚本，测试有一部分在浏览器之外运行，而如果使用 test runner 脚本的话，测试是完全在浏览器中运行的。
      c）开源，且应用较广泛，有一定的技术基础。
缺点：a）selenium不能简单的处理WEB上一些第三方插件，例如：当要从Web 上下载一些东西，自然此时就会弹出一个“下载框”，由于那个框框是Windows 窗口，Selenium 是处理不了的，所以必须通过第三方的脚本处理。
      b）selenium是轻量的测试框架， 脚本所处理的测试用例构成简单，其实质就是通过HTTP协议，发送请求（request）来完成测试用例，所以很困难处理业务逻辑关系强的测试用例。
3.3  应用总结
可以考虑先采用selenium进行预研究工作，将其轻量级的自动化框架搭建出来进行应用。

四、应用框架和策略
4.1 WEB自动化关注
1）Case的选择
   尽量采用google提出的721原则，即70%的测试工作在底层接口测试和单元测试；20%的测试工作在集成测试；10%的测试工作在界面测试。
   因此，对于B/S架构自动化测试，原则上若能采用二层的机制（API与底层命令机制）的话，尽量用二层机制；若无，则采用第三层机制，且主要定位在功能测试。
2）对业务变更的处理
1） 使用不便的元素进行定位，ID/name。
2） 动态的ID好于没有id，即尽量抓取WEB对象的唯一标示值去识别对象。
动态生成的ID，先利用Beautifulsoup等分析源码，通过属性，text(),css等定位到节点，然后获取id，操作的时候直接利用这个id进行操作。 这样好于直接在代码中书写xpath . UI MAP建立元素和一个别名的关联，以xml或者配置的形式存储，
当页面发生改变的时候，只需要更改这个关联文件即可。
因此，原则上要求研发人员在某些元素一定要设定id,name,并且不要改变。
展示的目的就是为了确认。
4.2 框架的设计思想
主要分为三层：
 业务（关键字、业务分层）
 数据（数据驱动、数据存储）
 结果（结果验证、结果报表）
因此，可以将selenium框架分为三个层次：
 appObjects —— Web 页面元素定位信息，如按钮与文本框等；
 appLibs ——测试步骤中可复用的行为；
 test cases ——由 tasks 组成的测试用例。
4.3 具体方案策略
1） selenium+eclipse+JUnit
a）、首先，工具包括：
Selenium IDE(可以结合Firefox进行录制，然后生成脚本用例，包括：ruby、java等)
Selenium RC(可以进行脚本的编辑和对浏览器的控制，其实其即为一个包，里面封装了对WEB进行控制的各种JS脚本，我们这里采用JAVA包)
Eclipse（执行平台）
b）、之后，可以利用IDE录制生成脚本或者自己应用selenium的API编写测试例脚本（JAVA）。
c）、启动selenium server(java -jar selenium-server.jar 启动selenium server)
d）、在Eclipse创建一个项目，右键项目build path，里面加上junit.jar和selenium-java-client-driver.jar
e）、编写Selenium测试用例,编写一个JUNIT的单元测试，要构建一个Selenium，包括步骤：
 构建一个Selenium实例
 启动Selenium实例
 执行Selenium命令，并验证结果。要执行一个命令是通过调用Selenium实例的方法来完成的，具体有哪些命令可以参见JAVADOC
 关闭Selenium实例
框架设计可以如下图所示：

2) selenium+TestNG
a） 框架如下图所示：
 
b) 工具介绍：TestNG是一个设计用来简化广泛的测试需求的测试框架，从单元测试（隔离测试一个类）到集成测试（测试由有多个类多个包甚至多个外部框架组成的整个系统，例如运用服务器）。编写一个测试的过程有三个典型步骤：
    * 编写测试的 业务逻辑并在代码中插入TestNG annotation。
    * 将测试信息添加到testng.xml文件或者build.xml中。
    * 运行TestNG。
c)、结合TestNG,可以提高其脚本用例的重用性，可以实现系统级别的测试,支持数据驱动，结果报表。

 更多测试技能在线学习，更多测试文章，请访问http://www.zhibokeji.com/

ACC（Attributes Components Compatibilities）是Google测试团队使用的一种建模方法，用来快速地建立产品的模型，以指导下一步的测试计划和设计。在Google内部，ACC得到较普遍的应用，一些工程师还开发了支持ACC模型的Web应用，并将其开源。本文将介绍ACC的内容，所引用的Google+的例子摘录自《How Google Tests Software》一书。此外，本文还将使用启发式测试策略模型（Heuristic Test Strategy Model，简称HTSM）来分析ACC。

运用ACC建模的第一步是确定产品的Attributes（属性）。按照谷歌的定义，Attributes是产品的形容词（adjectives），是与竞争对手相区别的关键特征。按照敏捷开发的观点，Attributes是产品所交付的核心价值（values）。从HTSM的角度，Attributes位于HTSM->Quality Criteria->Operation Criteria，隶属于面向用户的质量标准。

Google+的Attributes如下：

• Social（社交）：鼓励用户去分享信息和他们的状态
• Expressive（表现力）：用户可以运用各种功能去表达自我
• Easy（容易）：让用户以直观的方式做他们想做的事
• Relevant（相关）：只显示用户感兴趣的内容
• Extensible（可扩展）：能够与Google的已有功能、第三方网站和应用（Application）集成
• Private（隐私）：用户数据不会泄漏

ACC以Attribute开始，是产品竞争的自然选择，也符合Google的开发实践。在Google的项目中，开发人员和测试人员的比例通常是10：1或更高。开发人员会编写大量的自动化测试用例，对产品实施周密的测试，因此测试人员主要关注用户价值和系统级测试。即便如此，测试人员也没有足够的资源测试所有用户行为。所以，测试人员需要通过确定Attributes来明确产品的核心价值，从而区分出测试对象的轻重缓急（priorities）。获取Attributes的信息源可以是产品经理、市场营销人员、技术布道者、商业宣传材料、产品广告等。测试人员也可以使用“卖点漫游”（The Money Tour）来发掘和检验产品的卖点。

第二步是确定产品的Components（部件）。Components是产品的名词（nouns），可以理解为产品的主要模块、组件、子系统。从HTSM的角度，Components位于HTSM->Product Elements->Structure和HTSM->Product Elements->Function，即同时具备代码结构和产品功能的特征。

Google+的Components如下：

• Profile（个人资料）：用户的帐户信息和兴趣爱好
• People（人脉）：用户已经连接的好友
• Stream（信息流）：由帖子、评论、通知、照片等组成的有序的信息流
• Circles（圈子）：将好友分组，如把不同的好友归于“朋友”、“同事”等小组
• Notifications（通知）：当用户被帖子提到时，向他显示提示信息
• Hangouts（视频群聊）：视频对话的小组
• Posts（帖子）：用户和好友所发表的信息
• Comments（评论）：对帖子、照片、视频等的评论
• Photos（照片）：用户和好友所上传的照片

Components可以看作功能列表（Function List）的顶层元素，是产品核心功能的清单。《How Google Tests Software》建议Components列表要尽可能简单，10个Components很好，20个就太多了。其目的是重点考虑对产品、对用户最重要的功能与代码，并避免漫长的Components列表所导致的分析瘫痪。

第三步是确定产品的Capabilities（能力）。Capabilities是产品的动词（verbs），描述了一个Component提供了何种能力来实现一个Attribute。在HTSM的角度，Capabilities位于HTSM->Product Elements->Function和HTSM->Quality Criteria->Operation Criteria->Capability，刻画了产品实现其核心价值的手段。

Google+的Capabilities矩阵如下：

	Social	Expressive	Easy	Relevant	Extensible	Private
Profile	在好友中分享个人资料和兴趣爱好	用户可以在网上表达自我	很容易创建、更新、传播信息		向被批准的、拥有恰当访问权限的应用提供数据	用户可以保密隐私信息 只向被批准、拥有恰当访问权限的应用提供信息
People	用户能够连接他的朋友	用户可以定制个人资料，使自己与众不同	提供工具让管理好友变得轻松	用户可以用相关性规则过滤好友	向应用提供好友数据	只向被批准、拥有恰当访问权限的应用提供信息
Stream	向用户提示其好友的更新			用户可以根据兴趣过滤好友更新	向应用提供信息流
Circles	将好友分组	根据用户的语境创建新圈子	鼓励创建和修改圈子		向应用提供圈子数据
Notifications			简明地展示通知		向应用提供通知数据
Hangouts	用户可以邀请他们的圈子加入群聊 用户可以公开其群聊 好友访问用户的信息流时，他们被告知群聊	加入群聊前，用户可以预览自己的形象	只要几次点击就可以创建并加入群聊 只要一次点击就可以关闭视频和音频输入 可将好友加入已有的群聊		用户可以在群聊中使用文字交流 YouTube视频可以加入群聊 在“设置”中可以配置群聊的硬件 没有摄像头的用户可以音频交谈	只有被邀请的用户才能加入群聊 只有被邀请的用户才能收到群聊通知
Posts		表达用户的想法			向应用提供帖子数据	帖子只向被批准的用户公布
Comments		用评论表达用户的想法			向应用提供评论数据	评论只向被批准的用户公布
Photos	用户可以分享他的照片		用户能方便地上传照片 用户能方便的从其他来源导入照片		与其他照片服务集成	照片只向被批准的用户公布

Capabilities通常是面向用户的（user-oriented），反映了用户视角的产品行为。测试人员也应该保持Capabilities矩阵的简洁，他们应该关注对用户而言最有价值、最有吸引力的能力，并在合适的抽象层次（right level of abstraction）记录Capabilities。最重要的是，Capabilities应该是可测的（testable），测试人员能够设计测试来检查产品实现了预期的Capabilities。

有了Capabilities矩阵，测试团队就完成初始的测试计划。这就是前Google测试总监James Whittaker所说的10分钟测试计划（The Ten Minutes Test Plan）。其基本思路是专注于核心属性、核心功能和核心能力，而省略一切不必要的细节。之后，测试团队会利用矩阵去指导测试设计，通常矩阵中的一条Capabilitiy就是一个测试对象、测试策略或测试情景，而复杂的Capability会演化出更多的测试设计。

Google所提供的开源Web应用可以分析项目信息，包括测试用例、代码变更、产品缺陷等，以确定Capabilities矩阵中的高风险区域。下图引用自James Whittaker在GTAC 2010的闭幕演讲的幻灯片，是Chrome OS的Capabilities矩阵的热点图（heap map）。图中绿色表示低风险区域，红色表示高风险区域，粉红色和橙色则表示风险居于前两者之间。测试人员可以根据热点图，更好地确定测试优先级，将有限的资源运用在最需要的地方。

许多团队的风险分析依赖于测试人员的经验和猜测，Google的ACC工具则通过分析项目元素（测试用例、代码变更、产品缺陷等）来识别风险。这些被分析的元素位于HTSM->Project Environment，是项目环境的一部分。即便不使用Google的工具，测试人员也可以利用电子表格记录Capabilities矩阵，并自行计算各个条目的风险（一些Google的测试人员也是这么做的）。在评估风险时，他可以考虑如下因素：

• 自动化测试用例：该区域有自动化测试用例吗？测试在定期运行吗？测试通过率是多少？测试用例覆盖了哪些方面，没有覆盖哪些方面？
• 手动测试：有人手动测试该区域吗？经过测试，他们对该区域有信心吗？如果满分是10分，他们会打几分？
• 代码变更：该区域近期存在代码变更吗？变更频繁吗？变更是新增功能、代码重构、还是缺陷修复？
• 代码复杂度：代码的规模是多少？代码是否复杂？如果复杂度的满分是10分，该区域的代码能得几分？
• 产品缺陷：该区域的缺陷多吗？有哪些典型缺陷？哪些缺陷已经被修复？哪些缺陷还没有被修复？活跃的缺陷是在快速增加还是稳步下降？

在计算此类风险因素时，测试人员可以采用尽可能简单的度量方法。一方面，简单的方法更容易解释度量值的含义，从而有助于针对度量值采取相应的行动。另一方面，复杂的方法增大了分析的难度，却往往不能提供更多的收益。通过测试去获得直接的反馈，并定期重新度量风险因素，是更注重实效的方法。这也符合ACC的风格：快速的前进，持续的迭代。在测试计划时，测试人员只要快速地确定Capabilities矩阵，而不必担心遗漏。随着测试的进展，他会对矩阵做出必要的调整，以优化测试的价值。

先交代一下写作背景：这二年在软件项目中非常流行一个词——敏捷。大大小小的项目，通常都打着敏捷的旗号招摇过市，有自我感觉良好的，有感觉很坑爹的，也有更多的公司是为了利益，披着敏捷的外衣，却做着浮躁的事。其实我觉得敏捷本身是一种很好的思想，是当软件工程发展到一定阶段后必然出现的事。面对风云变幻的市场，谁都想自己身手矫健，迅速响应市场或客户的变化。但如何真正在项目中做到敏捷，却不是想得那么容易，除了方法论之外，还有各种外部条件的制约。而现实是很多研发团队只注重了方法论的学习，而没注意组织结构应该如何变化才能适应敏捷测试的需要。就像人类的进化史一样，大脑在逐渐变得发达和更加善于思考，但如果手脚不能进化到可以独立行走，把双手解放出来劳动，那人类根本也就走不到今天。有的童鞋可能又想说了，敏捷强调的不是人人都应该是开发和测试吗？OK，我不反对，但我们不是活在童话世界中，你的理想有多丰满，现实就有多骨感。在真实项目中，肯定还是存在测试和开发的分工的。所以本文想谈谈在敏捷测试中，我们的测试组织应该如何建设，才能合理将工作进行分工，充分发挥组织内部每个人的长处。再说直白点就是，在敏捷测试环境中，我们应该用什么样的人，去做什么样的事，才能获得最大的效率。

当考虑团队的组织结构的时候离不开两点考虑：要做什么事和要什么样的人去做这些事。其实很多人对敏捷测试并不太熟悉，甚至不知道谈到敏捷测试，我们究竟指的是哪些测试，要怎么做才能使测试敏捷起来。所以我们先来看看第一个问题：要做什么事，也就是说当我们谈到敏捷测试时，我们究竟谈了些什么。

在一本比较著名的讲敏捷测试实践的书《A Practical Guide for Testers and Agile Teams》中，明确将敏捷测试的所有测试类型划分为了四个象限的测试，按照测试内容来分，可以主要分为面向技术(Technology-Facing)和面向业务(Business-Facing)的测试。在面向技术的测试中，主要包括我们熟悉的Unit/Component测试，PSR(Performance, Security, Reliability)测试，Usability测试等等。而在面向业务的测试中，主要包括手动的探索性测试，User-story和系统测试，以及自动化的BAT和回归测试等等。由于这里所讲的测试类型的特点都会跟什么样的人去做有很大的联系，所以在接下来的部分我再详细讨论各种测试的特点。

OK，知道了敏捷测试究竟在做什么，也就是它所指的范围(Scope)之后，我们接下来就可以根据所要做的这些事的特点，再去甄选合适的人去完成它。这里需要注意的一个原则是：尽量发挥每个人的特长，让专业的人去做专业的事，杀鸡用牛刀或者杀牛用匕首都是不可取的。我先给出具体的组织架构图，再来看看为什么安排这些人去做这些事。


先来看看面向技术的测试。为什么是面向技术呢？因为这些测试类型都是需要深入到代码级或者是需要工具去实现的，而且跟具体的业务逻辑和业务流程关系不大。

Unit/Component测试(负责人：开发人员)
这部分的测试应该由开发人员自己去完成。原因很简单，谁最清楚代码的结构和代码逻辑？开发人员。我们完全不必专门安排所谓的白盒测试或者单元测试工程师去帮开发去完成这些事，这些是他们应该完成的事，往大了说就是每个人都应该为质量负责。而且，特别是在测试驱动开发的模式中，我们更是绝对不能让测试人员越俎代庖地去做这些事，那样做是得不偿失的。因为如果不是由开发人员自己去写的测试代码，那么到时出了错，要想debug或者是找rootcause的话，将会花费更多的代价。所以记住在测试驱动开发模式下，开发和测试那块根本就没测试人员什么事，作为测试人员大可不必想着一定要读懂代码才牛，从老板或者是组织管理者的角度看的，那简直就是浪费钱，测试人员应该做的是，如何更好地帮助开发去理解需求，也就是敏捷中常说的user-story，以及如何设计测试来验证产品是否真正完成了这个user-story，接下来面向业务的测试中还会说到这点。

PSR以及各种"ility"测试(负责人：相关测试类型专家)
性能、安全性以及各种用户体验啊，易用性健壮性测试对产品的重要性不言而喻，而这些测试类型往往又是非常专业的，复杂性程度相当高。要想做好，不仅仅是会用一点工具，会录制下脚本，或者是懂看代码就能实现的。它要求测试人员不仅对工具使用非常娴熟，更重要的是要深入了解系统架构以及系统所运行环境的具体情况，如桌面程序，在安全性方面往往跟系统本身的安全性紧密相关，要求测试的人对所在的系统也要了如指掌，web程序，性能瓶颈更是跟系统软硬件，所用协议等密切相关，没有对这些相关方面有系统地把握和学习，根本做不好。所以如果是组织内部有条件，可以由专门做这些非功能性系统测试的专家或者资深工程师负责这些类型的测试，才能得到比较理想的测试效果，不然最大的可能性就是走走过场而已，得不到实际的效果。

再来看看面向业务的测试。面向业务的测试是大部分测试人员所熟悉和了解的，但测试工程师也有好几种类型，初级的，高级的，做自动化的，做手动的，该如何按照不同的测试类型来进行分配？

ET/User-Story/System测试(负责人：有经验的/高级测试工程师)
在敏捷测试中，这几种测试的重要性也是不言而喻的。像探索性测试在敏捷测试中，甚至超过了系统测试的重要性，是敏捷测试面向系统和业务的核心测试类型。探索性测试的特点是测试人员可以事先对被测系统没有任何的了解，通过一边学习一边测试，快速地在有限时间内根据优先级最大限度地发现系统中存在的问题，所以说效率非常高。当然，同时对测试人员的要求也就非常高。它可以没有测试用例，但一定有很多引导测试人员思考的test idea，只有测试人员自身经验非常丰富的情况下，他才有可能根据最少的线索，猜测最有可能发现bug的地方。并且快速学习和总结能力是个不可或缺的条件，这就注定了只能由经验丰富的高级测试工程师才能hold住。User-story分析要求测试人员具备良好地沟通和理解能力，能够将客户表达出来的或者潜在的客户需求转换为我们的用户故事和业务逻辑的描述，供开发人员进行参考。系统测试就不说了，大家都很了解，要做好需要对被测系统有深入全面的了解。所以在这几个测试类型中，是对测试工程师能力的一个综合考验，虽然没有涉及到代码以及自动化，但必须要求测试经验丰富，测试方法掌握扎实，对业务精通的人员来进行。

BAT/Regression(负责人：初级测试工程师)
估计没人会反对我们在项目里要最大限度地利用自动化测试来开展BAT和regression测试，这是由自动化测试的特点和对ROI的考虑来决定的。敏捷测试中不可避免地要用到自动化测试，不然一切敏捷都是扯蛋了。而要想提高自动化测试的复用率和降低维护的难度，我们最好能够考虑根据业务更多地使用测试框架，将业务逻辑、测试数据和测试脚本高度解耦，例如使用关键字+数据驱动的混合型框架。这里实际上为什么说BAT和regression只需要没什么测试经验的人去做呢？实际上前提条件就是我们要合理利用框架，像关键字框架等等，用这些框架的人不需要去学习编程，他们只需要能够利用已有的关键字根据测试的需要去组合测试用例即可。所以并不是每个做自动化测试的人都必须具备编程能力的，他们在没有太多测试经验的情况下，做探索性测试是不合适的，但他们可以利用这些关键字练习和设计测试用例，又可以帮助组织执行自动化测试，充分发挥他们应该有的价值，同时自身也可以得到提高。

Test framework development(负责人：自动化测试开发工程师)
测试框架的应用在敏捷测试中也是举足轻重的，因为它涉及到自动化测试的复用性和可维护性的问题。脚本的复用性低和维护性差往往成为很多组织自动化测试失败的根本原因。辛辛苦苦开发的测试脚本不能复用，一点小小的功能改动都涉及大批脚本的改动，实在是伤不起。而不管是利用现成的测试框架，如robot或者是自己根据产品的需求开发的测试框架，其本身实际上都是一个完整的开发项目，所以需要负责框架开发的人非常熟悉软件设计方法和扎实的编程技能，这样的要求通常只有对技术狂热爱好的人才有可能达到。他们可能不需要太关心产品业务层面的东西，那不是他们关注的重点。他们需要的产品方面的知识往往可以从其他测试人员那里了解到，这就足够了，如需要开发哪些关键字，都可以由其他人告诉他们即可。他们应该关心地如何使得测试框架本身可以灵活适应产品需求的变化，如何提高框架的复用性。所以归根结底就是对编程和程序设计方面的要求较高，他们具备这些能力后，可以专门关注测试框架方面的工作，从而为BAT和Regression测试的工程师提供有力的帮助。

当然，这只是在敏捷测试中一种较为理想的测试资源的组织安排模式。它的前提是我们现在有所有这样的一些人，那么我们就可以把他们安排到他们最擅长的测试类型中去。这样做的意义主要有以下两点：

1. 就是实现了我刚刚说的那个原则：让专业的人去做专业的事。这句话说起来简单，但如果我们无法理清敏捷测试中的各种测试类型，需要什么样的测试能力，我想这个原则是很难实现的。我见过和听过太多测试中一做自动化就要求所有的人都去学习编程，学习工具，对于没有这方面兴趣的人来说，这简直就是痛苦得要命的过程，何必呢？如果他擅长于测试理论，熟悉产品业务和需求，那就让他去做探索性测试，让他去分析user-story或者是系统测试，没必要吊死在自动化这一棵树上。只要测试组织者或者团队建设者真正清楚了测试的需求，那我相信他就不会大而全地要求每个人都是每一方面的专家。

2. 招聘的时候可以更加有的放矢。我的组织中需要完成什么样的任务了，我就去招什么样的人。现在很多企业的招聘广告上都会写：要有自动化测试的经验，有编程经验，会脚本，精通测试理论等等等等。这样大而全的要求会带来什么样的后果？你对人家的要求多，那他必然要价就高，那企业白白浪费大把金钱去招了一些能力强但不适合的人进来，从而实际效率得不到提高，而且很可能招不到合适的人。比如测试团队里面缺的就是做探索性测试的人，我为什么一定要他具备自动化测试的经验呢，为什么要他有编程能力呢？完全没必要。再比如我现在有几个经验比较丰富的测试工程师做探索性测试了，但BAT和Regression没多少人做，那我完全可以招没什么经验的实习生进来，又好用又不贵，何乐而不为呢？如果觉得要做一套测试框架，也没必要要求人家有很深的测试背景，懂得多高深的测试理论，只要开发功底扎实，我想那一定就符合你的需求了。我突然想起一句广告说得非常对：只选对的，不要贵的。

当然，我这里只说出了我的一点想法，欢迎更多的看官童鞋们一起分享你们的经验，分享创造价值嘛。如果喜欢敏捷测试的朋友可以看看我文中说的那本敏捷测试实践的书，网上有英文版的下载，相信会对大家有好处，呵呵。

楼主原创，如蒙转载，请注明出处，谢谢。

现在软件的规模越来越大，过去那个一个人关在房子里二、三个月编写一套软件的个人英雄时代已经过去了，团队的合作越来越被大家重视，也是软件发展的必然趋势。而如何有效地管理一个团队也是仁者见仁智者见智，我把我个人的一些认识写出来，也供大家讨论一下。管理是一门艺术，而艺术是需要天赋的。

首先我们来讨论一下做为一个团队的领导者的基本要求：
1、态度
   我认为态度是第一位的，做为一个团队的领导者，是带领团队攀登一个又一个高峰获得一个又一个辉煌还是混日子就决定了一个团队的方向。
2、性格
   每个人的性格因为成长的环境不同是千差万异，但做为一个团队的领导者沉着稳重是必须具有的。
3、能力

  亲和力和凝聚力：
   这决定了你是否能真正融入你的测试团队，你只有真正融入到这个团队，而不是一个高高在上的领导者，这个团队才是一个有真正战斗力的团队，大家如果有对历史有兴趣，大家可以看看为什么中国共产党领导的军队为何能在实力相差非常悬殊的情况下能打败美式装备的国军，官兵一体，干部冲锋在前是非常重要的一项。得民心者得。。。。。
   组织协调能力：
一般一个测试团队的领导要向公司的高层管理者负责，要管理测试团队，还要与用户交流（外包类），因此如何灵活地协调各方的关系就考研测试团队领导者的水平了。测试团队是一个技术团队，团队内部的技术交流、项目信息的交流沟通也是非常重要的。
 
   技术能力：
   在中国这种环境下，做为一个技术团队的领导者我绝对不赞同用外行，那样不仅用户不放心，团队成员也不会尊重他（她），但也不是说明非得该领域内的专家来做为管理者，做为一个技术团队的管理者你最少要对该技术领域很熟悉，并且要有很强的学习能力，现在软件技术的发展日新月异，测试技术要求知识面要宽，但深度就要求的相对开发要低。

其次我们来讨论一下测试团队的组成：
    战争是集体作战，不是个人间的单打独斗，而团队作战，阵法和阵型在战术层面就是第一位的（战略最重要，本文中不涉及）如篮球、足球，包括现代的特种战争也非常重视战斗队形。在这里我说一下我非常尊重的抗倭名将戚继光的鸳鸯阵，该阵队形是2－3－2或2－2－1或2－1队形，可以随着地形或战争的变化而变化，最基本的配置是这样，2名藤牌手在队伍的最前面，配腰刀，主要是防守整改队伍，3名长枪手，在中距离上进攻，保护藤牌手和后面的毛筅手（长竹子），毛筅手利用很长的竹子在远距离上攻击敌人，这样长、中、短距离都能攻击，并且互相配合、互相保护。毛筅手是该小组的领导者。
    在一个测试团队中最少要有这样四种岗位：测试领导者、测试设计者、测试执行者、测试分析者，随着项目的不同还可以邀请开发人员、数据库人员、网络管理员、系统管理员参加。
    测试团队组建完成，也要根据每个人的知识、性格、爱好进行分工，我认为要全面培训、重点侧重。争取在每个领域都要有一个领域专家，如一个团队中有一到两个DBA，所有关于数据库测试的设计、监控、分析都可以有这一二个人完成。当然团队内部关于测试工具、测试方法的培训也要让他们参加，让他们也了解。这样的团队是一个分工合作的团队才是一个可功可守的团队。

好了，写了这些，一家之言。
  

                                测试之-七年之痒
    多许流年，老了激情闲剩梦，往事如风，落于文字化成烟，梦里随风万里飞。回忆当年青春埋葬荒凉，指尖飞洒青春不再殇，人生就这样数着数着就这样过去了。
    把酒人生，闲话家常时，坐战IT7年，弹指纷飞，工作间少许寂寥回荡，大部分忙里偷忙，闲中待忙。
    所谓的职业生涯，其实你很难预测到你将来真正要从事什么工作，将来所要从事的工作，是否跟你在大学里学的专业有关。大多数人，很有可能将来所作的工作，跟他当初所学的专业一点关系都没有。
    重要的不是你做了什么，重要的是你在工作中养成了怎么样的良好的工作习惯。这个良好的工作习惯，指的是：认真，踏实的工作作风，以及是否学会了如何用最快的时间接受新的事物，发现新事物的内在规律，比别人更短时间内掌握这些规律并且处理好它们。具备了以上的要素，你就成长为一个被人信任的工作的人。人都有惰性，也都愿意用那些用起来顺手的人。当你具备了被人信任的基础，并且在日常的工作中逐渐表现出你的踏实，聪明，和细致的时候，越来越多的工作机会就会提供到你面前。原因很简单，用一句话就能交代清楚并且能被你顺利完成的工作，谁愿意说三句话甚至半小时交待一个怎么都不明白的人呢？沟通也是一种成本，沟通的时间越少，内耗越少，这是作为管理者最清楚的一件事。当你有比别人更多的工作机会去接触那些你没有接触过的工作的时候，你就有了比别人多的学习机会，人人都喜欢聪明勤奋的学生，作为管理者，大概更是如此。

   有些人，在做测试前期几年，都是埋怨，整体看需求文档，根据需求写测试案例，执行测试，写测试报告等等，几乎在每个项目都是做同等流程。甚至有些项目周期很长，一做就是好几年，就像我们公司现在做的一个信贷类项目我06年入项目到现在该项目还在增量型的开发维护。如果让一个人天天面对着这个项目，做类似相同的事情，我想会发疯，我曾经也是这样想，我在这个项目做下性能测试一做就两三年
这几年工作期间虽然我也有协助其他合作公司和客户方做很多其他项目，但是还是一直挂在该项目组，此项目一有事情就优先处理。就这样从这项目测试初期我学会了怎么做性能测试，然后怎么诊断分析问题，由于这个项目非常的大，数据量很大，业务很复杂导致表关联关系复杂，上线没几年问题慢慢暴露出来，就这样慢慢测试慢慢积累经验，我慢慢学会了基础性的优化，偶尔开发解决不了的，我也能提供解决建议，也慢慢了解了应用单实例到怎么集群，然后怎么通过apache做负载、到数据库RAC，然后跟其他系统接口测试等等，同时也明白了怎么构建测试体系架构和测试平台，知道怎么做好上线后的性能巡检工作确保上线后的稳定运行等等。虽然一直在一个项目组中直到至今我虽然换了家公司做了测试部主管，但是最终还是回来这个项目挂在这个项目做业务需求分析和测试组长。然而回忆下从开始学习做性能测试到诊断分析优化到学会做测试管理都是在这个项目中实践体会到的。一个大的项目，管理规范的项目从中可以学习到很多的东西，有时感觉受益良多，也许可能受益终身。
    个人认为：工作需要一个聪明人，工作其实更需要一个踏实的人。聪明人有时是先天赋予的这点我没得到上帝的垂怜所以我只能选择后者。。。踏实，是人人都能做到的与先天条件没有太大关系。
    七年也只是开始，前7年只是做好技术基础的积累和简单的部门管理学习工作，但是做IT行业也是人生路漫漫长，技术常相伴。接下来的工作就是挑战BI测试，无论是功能测试还是技术测试，同时也是把BI测试体系平台构建完成是我今年开始的最大工作目标。

@write by lymking#hotmail.com at 2011-11-27 22:30
经常在论坛或群里见网友问，测试应当具备什么能力或知识，又或着目前国内的测试人员大都只关注测试工具的学习而忽略了很多更重要的东西，所以今天花时间结合国外一些站点资料总结了下从事测试应当具备的知识和技能，希望对大家有点用。
技能列表：
1、测试理论和测试技术技术技能
2、策略性、启发式创造能力
3、业务分析和业务流程建模能力
4、技术写作能力
5、技术研究和实验能力
6、人多事杂时的演讲或表达能力
7、软件体系结构原理
8、编程和脚本能力
9、风险评估能力
10、投资回报分析能力
11、网络技术能力
12、数据存储和数据库能力
13、统计学和其他测试相关数据能力
14、直觉和撰写有意义的测试数据报告能力
15、使用图形演示复杂信息能力

  昨日参加了一次小型民间敏捷聚会，心情很愉快。从09年开始间接参与敏捷，到领导敏捷项目，还从未写过一篇敏捷的体会总结文章。今天简短整理一下，不足之处和不正确之处还忘各位理解。

    首先敏捷的核心思想是提升质量，而加快进度的效果通过三个维度实现：

    1、遵循测试的原则之一尽早测试（不仅仅是代码级测试，还包括更充分的对需求、架构、设计文档的测试），减少了发现缺陷，修复缺陷的成本从而实现了一部分的加快进度的效果；

    2、敏捷思想提倡“以客户为中心” 而非以“以技术为中心”，减少了需求开发的浪费从而实现了一部分的加快进度的效果；

    3、敏捷活动中“关注人”，注重“方法论”的使用，又提升了每个人的工作效率和质量，从而实现了一部分的加快进度的效果。方法论的出现和应用无论是开发领域还是测试领域都是必然规律，这些方法论要么提升单位时间内的工作质量，要么提升工作效率，从而体现在项目中就是项目按时有质量交付。

   其次对于大型复杂项目和小型项目的敏捷测试要所区分，没有统一的测试模式：

   1、大型复杂项目除了测试人员在敏捷团队中为开发人员提供方法论开展早期测试外，测试人员还可以参与story的编写开发，写的好的story甚至可以直接作为功能测试用例的标题。测试人员还应该代表客户进行story之间依赖关系图的建立（以我经验开发人员更容易画出模块实现的关系依赖图），然后PO再从story之间的依赖关系图中梳理出story开发的先后顺序。这样的迭代计划才是有设计依据的， 保障迭代计划的质量。你的迭代计划的质量有依据吗？

  2、大型复杂项目的story测试更多还是功能级测试，对于很多系统级的测试还是需要有专门的系统级测试技术人员来实施更好。而小型项目的story测试就足够了，可以省却系统级测试活动。

  3、在进行验收测试时，建议PO参与测试组一起测试，PO必须审查测试用例。我曾作为PO领导过2个软件的开发，由于测试组同事没有条件和资源像PO一样从全局对需求有了解，因此开发的验收测试用例还是有些不足，因此2次审核测试组的用例都提供了很多补充意见，从而提升了测试用例质量。

  4、对于一些开发生命周期很短的项目或团队成员很少（2-3个人）的项目，不一定要搭建一个第三方CI环境才能开始敏捷。因为这时你自己都可以通过本地的开发环境编译器进行编译，当然每天要编译至少几次，每次新增点什么代码或修改点什么代码就要马上编译，开发人员本地自验——这就体现了敏捷的思想尽早测试了。

     最后敏捷中的每日晨会不要流于形式， 要与风险管理结合起来：

   1、每日晨会每人就三句话：昨天我做了什么？遇到什么困难？今天计划做什么？ 谁在混日子马上都能暴露了。PO也可以及时了解项目新产生的风险。

   2、PO除了从成员反馈的困难中收集新风险，还应该凭借自己的经验提前分阶段去识别项目所存在的技术风险，质量风险，进度风险 用一个表从每个迭代一开始到结束都跟踪起来。把风险尽早第一时间管理好项目怎么能不成功。

   在我领导的敏捷项目中实践了：结对编程（1人code 1人review）, 代码共享（我们两人轮流在同一个文件中写代码）、每日构建（有一个项目每日构建几次每日集成几次），开放办公，每日晨会、尽早测试、重构、简单设计等。但我认为对项目成功最关键的是：每次遇到开发人员提出要新增某个功能或改进某个实现时，我脑海中只有一个标准谁能马上证明这个要求是客户在迭代交付时间点需要的，如果找不到充分理由，我就会否定这样请求。在整个敏捷项目中每次决策时，我脑海中都是反复在问：会影响按时交付吗？会影响交付质量吗？会导致新增大量测试成本吗？

    其实我认为衡量敏捷实践效果的标准不是单元测试覆盖率或自动化率，或是我用了哪些实践活动。而是通过深刻认知和运用敏捷的原则，最终保障了项目的每个迭代都是按时甚至提前完成了有质量保障的交付，那么无论团队的士气提升或敏捷的价值都会得到认可。我个人作为PO兼Master所带2个敏捷项目的所有迭代都是按时甚至提前交付，并无返工或重大质量问题反馈，因此我很认同也喜欢敏捷的这种工作模式（不是开发模式），喜欢敏捷的“以客户为中心”的思想。真“客户为中心”是以质量为前提，通过质量保障的方法论间接加大了测试投入；假“客户为中心”是以进度为前提，克扣质量保障的投入。 大部分敏捷的优秀实践本质都是质量提升的方法论，尽早测试尽早发现问题修复问题，减少返工才是敏捷的核心。

 

   

   在新浪微博上大家常讨论和抱怨，中国测试所处的环境多么初级和落后。我也常参与讨论，无奈微博140字的限制，表达有限，还导致一些误解。其实下面的内容，我在2011年2月就整理最原始的思路，今天周末正好拿出来与大家分享，听听大家的意见和批判：

   我在某软件工程积累很多的大公司从事过一段时间early testing工作的探索，因此有几个月时间经常和公司的产品架构师混在一起工作，全程参与了需求和设计工作。从而积累了很多软件设计，软件开发工程领域的认知，也对软件开发工程的发展历史和规律有了更多了解。（early testing就是没写代码前的测试怎么做？测试人员如何尽可能去发现需求，架构，设计中的缺陷或不足）

   原来软件开发也经历了：没有章法单兵作战，凭感觉开发的1.0时代——>接着有了开发流程的2.0时代——>接着又发现流程的每个环节如何做好，还需要一些更具体的指导（方法论）和帮助（技术工具）， 于是有了软件开发3.0时代，各种IDE开发工具，各种编程规范，各种编程技巧——>进入九十年代后软件领域有了更多的开发框架（比一般的API库集成度更高）如J2EE，.net，这些框架不是API代码或函数的简单拼凑，而是重用了前辈或领域专家们的设计经验，系统性的构建起来，是对前人设计技术和思想的继承重用，从而既提升了开发效率也提升了质量。唯一坏处多增加了一些学习成本（不光学基本语言，还要学习前人定下了的设计规则）。

  一直以来测试行业的难题，如何评审用例，如何评审测试设计？在自动化测试运动结束后，这个问题最终还是被测试经理们提出落到我头上去解决，原来那些评审单个用例文字编写规范的东西早已不被一线测试经理们认可，必须要有所突破否则整个组织的测试用例质量无法提升，绝大部分的测试执行和测试资源都将在地基不牢的地方浪费，质量提升就等同皇帝新装。 当时我另开辟渠道，想了解软件开发如何评审设计的？后来看了一个公司软件开发专家的内部ppt，他在几年前也在解决软件设计如何评审的问题？最终我暂时找到了一个可用答案——设计约束、设计模板、设计回溯 三板斧。 原来现在很流行的J2EE，.net的框架不仅仅是加快开发速度，还提供了设计模板，通过设计约束来保障了基本的设计质量。从而我认为测试设计领域也应该有自己的设计约束和设计模板，测试分析设计人员可以按设计约束和设计模板来填空，测试技术主管或管理主管可以用设计约束和设计模板通过设计回溯的方法评审测试用例。 需要特别强调的是：测试设计模板，不是传统意义上单个用例的结构或文字描述规范的规定。而是测试用例是通过什么严谨系统的大脑处理流程而来的。为此，我从2010年底到2011年初整理开发了《软件可靠性测试分析设计框架》，《压力测试分析设计框架》《长时间测试分析设计框架》来辅助不同项目组改进现有这些领域的专项测试用例，改善了用例不再完全凭个人经验和感觉编写的问题，给测试经理接下来测试用例评审的武器。

最后再总结整理下软件开发的发展趋势：

1.0时代混乱；2.0时代流程化；3、方法和技术；4设计框架。

测试行业的发展和软件开发发展趋势也会一致：

1.0时代无流程   （我入行前）  某公司1998年前

2.0有测试流程      （我刚入行）  某公司1998年-2003年

3.0时代大量测试方法和技术  （我2010年前） 某公司2003至今，特别是08年至今有了大量突飞猛进的突破，正在大面积普及的路上

4.0时代有测试设计框架（设计和经验复用） （我2010年至今，先走一步探索啦）

  通过读史明鉴，找到事物发展的规律后，我有信心并相信，中国测试业界相比开发只是晚1个时代，未来10年内中国多数公司的测试也会进步到3.0和4.0时代。某公司走过的历史，也必将是国内才起步后来者们未来走的路以及趋势。

     各位tester看到未来的发展方向了吗？

欢迎提意见给我：新浪微博 http://weibo.com/dongjietest  (架构师Jack)

             个人email: dongjietest#163.com  (#换为@)

 

 

序言：也许到现在大家对所谓的“自动化测试框架”仍然觉得是一种神秘的东西，仍然觉得其与各位很远；其实不然，“自动化测试框架”从理念来说，并不复杂，但其之所以神秘，是因为其运用起来很是复杂，每个公司，每个部门其产品线，其运作流程都是不同的，所以就导致了在想运用“自动化测试框架”去完成自动化测试时产生了很多不定因素，导致了很多自动化测试项目的失败，让人对“自动化测试框架”开始敬而远之。

      而自动化测试发展也有一段时间了，为什么到现在虽见其火热，但难见其规模，关键是大家对其的定位，很多公司以及很多人都知道做好自动化测试不简简单单的靠一个工具，而更需要一个框架，但其总是对“自动化测试框架”缺乏清晰的定位，很容易将其定位成了一个固定的框架，其实个人理解不然，自动化测试框架不是一个模式，而是一系列思想的集合，是将各种自动化测试框架思想集合应用去搭建成的一个分层组织。

 

一、 简述自动化测试框架

  也许很多人印象里的自动化测试框架就是一个能够进行自动化测试的程序似的。其实这不全面，真正的自动化测试框架可以不是一个程序，它仅仅是一种思想和方法的集合，说白了，就是一个架构，大家应该都知道操作系统其实也是一个架构吧，你可以把其理解成一个基础的自动化测试框架为一个简单的操作系统，它定义了几层架构，定义了各层互相通信的方式。通过这个架构我们才能在上面进行拓展我们的测试对象（核心体）、测试库（链接库）、测试用例集（各个windows进程）、测试用例（线程）,而其之间的通过参数的传递进行通信（即相当于系统中的消息传递）。

 

二、 自动化测试框架思想

  接触过自动化测试的，一定不会对以下几种“自动化测试框架思想”陌生吧。

l  模块化思想

l  库思想

l  数据驱动思想

l  关键字驱动思想

很多人都将以上定义为“框架”，而我却觉得它们都只是代表了一种自动化测试的思想，不能以纯粹的框架定义。

首先，我们来看看自动化测试的一个发展，就能更加明白这些思想的真谛了。

 

    a)         第一代自动化测试，即自动化测试思想刚开始诞生时，依靠的是传统的“录制-回放”技术，这种技术与现在的工具的“录制-回放”思想不一样，其其实就是一个“模拟”的过程，即模拟你对PC的操作而形成的，其基于你对键盘的输入与对鼠标的操作，原理与按键精灵等类似，这种机制对环境的依赖性太强，对变化性太过于敏感，因此不可能发展成一种规模。

 

    b)         第二代自动化测试，即脚本化的自动化测试，利用脚本进行结构化的自动化测试，此可以应用于CLI与API的自动化测试，在其就开始集成了模块化与库思想。

 

    c)         第三代自动化测试，开始产生了各种自动化测试思想，包括数据驱动与关键字驱动思想，其伴随着对象化思想的产生，而且也造就了现在一系列的自动化测试软件，其实其中都集成了这些思想，从这时候开始，自动化就开始实现了一定的规模，开始运用在各个行业，并且发展趋势越来越快。

 

现在将一一根据自己的个人理解来介绍这些“自动化测试框架思想”：

    1、    所谓模块化思想，就是将一个测试用例中的几个不同的测试点拆分并且将其单个点的测试步骤进行了封装，形成了一个模块。

例如：一个测试用例要对一个登录程序进行测试，其中包括：用户名输入、密码输入、以及确定登录；

      那么就可以将用户名输入、密码输入、确定登录、取消登录四个操作分别封装在四个不同的模块中。测试时，只需调用其模块即可。这样的话，当一个模块有变化，你只需单独维护那个模块即可，也可以根据模块的不同组合成不同的测试用例。

 

    2、    所谓测试库思想，就是模块化思想的升华，其为应用程序的测试创造了库文件（可以是APIs、DLLs等），这些库文件为一系列函数的集合。其与模块化思想不同的是，其拓展了接口思想，即可以通过接口去传递参数，而不是一个封死的模块，可以说是一个多了一个“门”的交互型模块。

例如：还是以上那个测试用例，只是将用户名输入、密码输入、确定登录、取消登录封装成一个库，这个库含有一个函数Login，这个函数Login接收两个参数“用户名、密码”，对输入不同的用户名和密码可以进行不同的测试用例。也可以另外一个函数Cancle。

 

    3、    所谓数据驱动思想，众说纷纭，很多人都觉仅仅依靠用EXCLE表进行不同数据的读取仅是一个高级的参数化，其实怎么理解并不重要，关键是其思想能够好的应用到你的框架中。而我的理解就是变量不变，数据驱动结果，不同的数据导致了不同的结果的产生。而对于数据的导入，可以通过很多方式，例如：EXCLE表、XML（用在WEB中）、数据库(DB)、CSV文件、TXT等都可以。

 

  4、  所谓关键字思想，这个思想，我曾经一直思考，它与面向对象的关系，与交互模块化思想的区别。后来个人理解，其实关键字驱动就是一种面向对象的思想，例如：QTP、RFT中，对象可以为一个数据或者一个关键字，对对象的抓取，可以将其测试对象封装为一个关键字（即可以将gui元素封装成了一个个关键字），这样可以对其关键对象进行各种操作了，不同的对象可以驱动不同的测试流向与结果。

简单的应用的方式可以用一个EXCEL表，里面包括“对象类型”“对象名称”“对象操作名称”“判断方式”“预期结果”。这样的话，可以通过导入不同的对象类型和名称、不同的对象操作来构建成了一个测试用例表了。

        

      以上只是对这些思想的个人理解，做好自动化测试，不是说你掌握了一个框架，而是要掌握其自动化的思想，然后根据这些思想，结合你不同的测试环境和流程来构建你自己的自动化测试框架。

 

三、     构建自动化测试框架的策略

    1、    永远记住，你的“自动化测试框架”是给测试人员用的，如果你真的想把自动化测试做成一个规模，那么你需要将测试工程师当做你的用户，你不能指望他们有耐心的去编写测试脚本或者指望他们能够像你一样对这些思想有良好的掌握。你要将他们当成什么都不懂的用户，因此你的框架必须是“一切简单化”的化身，简单的操作、简单的维护、简单的拓展。

 

  2、  做一个自动化测试框架主要是从分层上去考虑，而不是简简单单的应用一种思想，它是各种思想的集合体。

例如，做GUI自动化测试，简单的一般就将其分为三层，其框架如下图所示：

     

而其中，可以贯穿着自动化测试的各种思想，例如：对象层中有关键字的思想、可以将对象库标示在Excel表中进行管理，或者应用动态搜索的方式传递对象识别参数。tasks层中可以封装各种方法，形成一个大型的方法库，而每个方法中可以应用上数据驱动的思想。

 

  3、  真正的自动化测试框架是与流程上结合的，而不简简单单的靠技术实现，技术其实不是很复杂，关键就在于对其架构和流程的深刻把握，而这需要很长的一段时间，所以不要指望一口气能吃成胖子，只能一步一步按需求来，需求指导思想的应用。

 

四、 自动化测试框架的发展趋势

  个人认为，自动化测试从初始诞生到至今，已经经过了一段漫长的日子，而其仍处于上升期，特别是现在软件大爆炸、敏捷模式、云端的开始热门，测试难度和质量保证的难度开始越来越大，自动化测试的比重也会越来越大，而单存的自动化测试是无法实现规模化的，因此，自动化测试框架热门化的趋势化的必然的，那是，在各种框架思想的集合中，各种框架将散发出各自的璀璨，来帮助我们快速的完成各种测试。

 

以上仅仅是至今，个人对“自动化测试框架”的理解，也许在以后的日子，因为认识的加深而会有不同的火花蹦出，但至少觉得现在的框架对自己的项目能够进行应用，也许某一天，需求饱和时，那么，新一轮的远征探索就又要开始……

希望，我们大家在自动化测试的征程上能越走越远，也希望自动化测试能真正成为测试流程中“不可缺少”的一部分。共勉之。

—散步的SUN

 

这里提出用“三步法”尽可能实现完整测试:

第一步：基本功能测试
程序的功能是人为的规定，工具不可能自动了解，因此，针对基本功能的测试用例需要人工来建立，这是无可躲避的。根据程序的设计要求，基本功能用例通常不难设计，把程序功能细化、明确化，列成“什么输入，应产生什么输出”的形式，就是测试用例。程序员准备编码时和编码过程中，是建立基本功能用例的最佳时机，为什么呢？因为程序员编码之前和编码过程中，一定要弄明白程序的功能，也就是要想清楚“会有哪些输入？某种输入时程序应该做什么？产生什么结果？”，这里，“哪些输入”就是指有哪些等价类，产生的“结果”就是输出，从编码的角度来看，这些就是程序的功能点，从测试的角度来看，这些就是现成的用例。如果有详细设计文档，那么测试人员可以根据文档来设计用例，否则最好由程序员建立基本功能用例。这一步可视为“黑盒方法”。

第二步：用白盒方法找出遗漏用例
    正因为程序功能是人为的规定，“黑盒方法”很难衡量完整性，而“白盒方法”恰恰具有易于衡量测试完整性的优点，两者可以很好互补，请看下面的示例代码：

    void Func(int* p)
    {
        if(p)
        {
            *p = 0;
        }
        else
        {
            return;
        }
    }

    参数p是一个指针，测试时当然要将空指针作为一个等价类，如果漏了这个等价类，会怎么样呢？分支覆盖会不完整：else分支未覆盖。从这个例子可以看出，未覆盖的逻辑单位通常对应未测试的等价类，因此，白盒覆盖可以衡量等价类是否完整并可帮助找出遗漏的用例。

　　“白盒方法”用逻辑覆盖率来衡量测试的完整性。逻辑单位主要有：语句、分支、条件、条件值、条件值组合，路径。语句覆盖就是覆盖所有的语句，其他类推。还有一种判定条件覆盖，其实是分支覆盖与条件覆盖的组合。跟条件有关的覆盖就有三种：条件覆盖是指覆盖所有的条件表达式，即所有的条件表达式都至少计算一次，不考虑计算结果；条件值覆盖是指覆盖条件的所有可能取值，即每个条件的取真值和取假值都要至少计算一次；条件值组合覆盖是指覆盖所有条件取值的所有可能组合。与条件直接有关的错误主要是逻辑操作符错误，例如：||写成&&，漏了写!什么的，采用分支覆盖与条件覆盖的组合，基本上可以发现这些错误，另一方面，条件值覆盖与条件值组合覆盖往往需要大量的测试用例，因此，这两种覆盖的效费比偏低。基于以上理由，这里提出采用语句、条件、分支、路径覆盖的组合来衡量测试完整性和找出遗漏用例。

第三步：用自动用例捕捉漏网之鱼
    还是上面的例子，假如程序员完全忘了有空指针这回事，把代码写成这样：
    void Func(int* p)
    {
            *p = 0;
    }

    由于判断p是否为空指针的代码不存在，白盒覆盖当然不会提示“某某代码或某某分支未覆盖”，因此，白盒覆盖不能发现“程序员未处理某些特殊输入”形成的错误，即使达到了无与伦比的白盒覆盖率，仍然不能保证找出所有等价类。
    程序员会忘记处理哪些输入呢？常见的输入一般是不会记的，否则程序的起码功能都未实现，容易忘记的是一些"偏僻"的输入，例如，空指针、空字符串、很大的数、很小的数、合法取值边界附近的值等等，从输入的角度来看，这些特殊值通常跟数据类型有关，从程序的行为来看，这些特殊输入常常会导致崩溃、产生异常，或超时，即具有行为特征，正好是自动用例可以发现的，因此，可以利用自动用例来捕捉“程序员未处理某些特殊输入”形成的错误。这就是“三步法”中的第三步。

　1、逆向思维方式

　　● 逆向思维在测试中用的很多，比如将根据结果逆推条件，从而得出输入条件的等价类划分

　　● 其实逆向思维在调试当中用到的也比较多，当发现缺陷时，进一步定位问题的所在，往往就是逆流而上，进行分析

　　● 逆向思维是相对的，就是按照与常规思路相反的方向进行思考，测试人员往往能够运用它发现开发人员思维的漏洞

　　2、组合思维方式

　　● 很多东西单一的思考都没有问题，当将相关的事物组合在一起却能发现很多问题；如多进程并发，让程序的复杂度上了一个台阶，也让程序的缺陷率随之而增长

　　● 按照是否排序组合可以分为：排列（有序）和组合（无序）；针对不同的应用，可以酌情考虑使用“排列”或者“组合”

　　● 为了充分利用组合思维而不致于让自己的思维混乱，要注意“分维”，将相关的因素划分到不同的维度上，然后再考虑其相关性

　　3、全局思维方式

　　● 事物往往存在多面性，当我们掌握了越多的层面，我们对它的认识就越清楚，越有利于我们掌握其本质，全局思维方式就是让我们从多角度分析待测的系统；试着以不同角色去看系统，分析其是否能够满足需求

　　● 其实平常我们在软件开发过程中，进行的各种评审，就是借助全局思维的方式，让更多的人参与思考，脑力激荡，尽可能的实现全方位审查某个解决方案的正确性以及其他特性

　　4、两极思维方式

　　● 边界值分析是两极思维方式的典范

　　● 为了看系统的稳定性，我们采用了压力测试

　　● 两极思维方式，是在极端的情况下，看是否存在缺陷？

　　● 注意是两极，不是一极

　　● 测试人员做久了，往往容易走极端——职业病，不利于与人沟通**ing软件测试网

　　5、简单思维方式

　　● 剥离一些非关键特征，追逐事物的本质，让事物简单的只剩下“根本”

　　● 针对事物本质（解决问题的本质）的测试，让我们不至于偏离方向

　　6、比较思维方式

　　● 认识事物时，人们往往都是通过和头脑中的某些概念进行比较，找出相同、相异之处，或者归类，从而将其加入大脑中的知识体系，可能的话，再建立好的搜索方式，以便以后使用

　　● 应用模式是“比较思维”很常见的例子，现在模式很火，有设计模式、体系结构模式、测试模式、等等，一些专家针对一些相关问题的共性找出来的解决方法，取完名字后，可以让大家方便的复用

　　● 让经验在这里发挥作用，测试中经验很重要，比较思维是使用经验的方式

　　7、动起来，更精彩

　　● 关注程序的运行时状态

　　● 传统的基于结构的程序可以更多的在代码中反映将来程序的运行方式；而面向对象将代码和运行时显著分离

　　● 让我们在关注代码静态结构（如类结构）的同时，也要谨慎关注其动态（对象交互网）表现

　　其实这些思维方式，大家都在有意识或者无意识的使用着，它们各自都有自己的妙处，将我们的思维发散，有意识的将他们用在问题的思考上，有时可以给我们一种“柳暗花明又一村”的感觉。

　　最后想说，只是知道这些原则意义不是很大，如果真能让它们成为思考的血液，才能发挥它的真正价值。那真的需要很多的历练，其实成为一名出色的测试人员，远没有那么简单，需要简单，需要（不断的学习＋不断的经历＋不断的思考）。

 

     QTP作为自动化测试的倚天剑已经成为每个测试人员必备技能，自己一直想系统的学习一下，可是由于种种原因，没有时间坚持下去，今天开个日志，希望各路高手指教！！同在学习的同行们也可以共享交流一下！自己的目标21天攻克QTP。

     大致的学习思路应该是 第一部分主要在QTP_Tutorial.chm ，然后研究一下VBS，之后研究一下框架之类的，恩，先这样进行吧，呵呵！

     QTP基础篇

QuickTest 的測試流程七大階段

总结一下就是：录制脚本，优化，执行，分析，回馈

悲剧啊，好久没有用过了，这个工具竟然损坏了，要重新安装过，今天就先这样吧，先去破解一下~