测试人员 VS 质量工程师

　　测试人员：如同出考卷通过考试来考察学生，发现问题。介入时间较晚、被动、单一。

　　质量工程师：是一个系统的工程，在前期介入，发现学生的不足、进而制定提高的计划和方法。是积极主动的，能产生多方面影响的。

　　敏捷的测试：以feature为单位，快速介入测试，测试完成后直接发布

　　测试向前一步：早期介入，看需求、看dev design

　　如何做需求分析

　　1、编写需求：

　　a、了解用户/用户场景：产品真的能满足用户的需求吗？

　　如何了解用户场景？下面给出一些案例分析：

　　微博：微博被N多人关注&转发，满足自我实现需求；360：安全需求，开机速度领跑则满足成就感；豆瓣：高级豆粉评论的权威性；Alipay：支付安全需求；Online game：在网络世界中实现自我需求

　　b、有自己的设计原则：需要经验的累积，站在设计的角度，假设自己就是这个产品的设计者，从自己认为最优的方式去设计产品.

　　2、产品简单和易用、非二义性：一步到位而不是两步或者三步、避免做重复的事情、批处理任务。设计test case时，也遵循这个理念。

　　一个不太好的login case：以前淘宝login时，输入正确的用户名和密码，点击登录后会再跳出输入验证码的提示

　　3、查阅文档：“每个人看到的都是一样的吗？”、“将要”vs“可能、应该、可取”

　　4、可测试性与可持续性

　　5、智能

在上一节中，我们讲到吞吐量，做为一个用户你可以对吞吐量毫不关心，但响应时间却是用户感受系统性能的主要体现。

　　从用户角度来说，软件性能就是软件对用户操作的响应时间。说得更明确一点，对用户来说，当用户单击一个按钮，发出一条指令或在web页面上单击一个链接，从用户单击开始到应用系统把本次操作的结果以用户能察觉的方式展示出来，这个过程所消耗的时间就是用户对软件性能的直观印象。

　　响应时间过程分析

　　我们需要对这个过程进行分解，才能得到你真正想要的响应时间。我把整个过程分三个部分，呈现时间，数据传输时间和系统处理时间。

　　呈现时间

　　其实主要说的浏览器对接收到数据的一个处理展示的过程。几年前大家都在用IE，如果页面显示比较慢，我们肯定不会怪罪IE，只会怪罪电信运营商的网速或被访问的系统（其实，大多情况我们不会考虑是被访问系统的问题）。现在chrome来了，我们会发现同一台电脑同一个网站，通过chrome去访问，页面的呈现速度会比IE略快。这是各种评测及大众用户的整体感受。当然，我个人感觉，opera浏览器的呈现速度最快，但它的显示效果一直不太好。

　　当然，我说这个呈现时间总不能全怪罪与浏览器的身上吧！当然还和承载它的操作系统有关，以及电脑硬件（比如cpu 内存）。假如你有超快的浏览器，如果是一台极其垃圾的电脑，我想你多打开两个网页就有可能使电脑卡掉。

　　数据传输时间

　　千万不要忽视数据传输时间。如果你要寄信给你一个远方的朋友，你想是什么影响你将信息传递给远方的朋友？不是你写信的过程（如果你写的信不像书一样厚的话），也不是你朋友读信的过程，而是送信的过程。（ps， 我10天前在china-pub订购的一本书现在还没到货！XXX）

　　拿我们系统的数据传输过程来说，我们发送一个请求需要时间，系统处理完后返回给我们也需要时间。初学性能测试工具的同学喜欢拿工具去测试互联网上的一些系统，甚至不懂性能的同学认为可以用性能测试工具将互联网上的一些网站压崩溃。貌似这一招比任何黑客攻击厉害多去。

　　那么，我觉得这些同学应该补补网络知识了，你的带宽是多少？互联网是个网，就是算是相同的起点与终点，它有可能走的不同的路线。有没有考虑网络延迟？就算你的并发请求都能成功的发出，但到目的地的时候，已经不能叫并发了。

　　这也是为什么我们在一般做性能测试时，一般要强调要在局域网中进行。当然，也有特殊的性能测试需要在互联网中时行。它们重点不是求用户的最大的并发量。

　　我们每天的生活中都在用水用电，我只会关心自己的水管是否有水，水压是否稳定，如果我们把水龙头拧到最大，还是一滴一滴的流水。那我们就要愤怒了，直接找房东问明情况。我们从来没想过去找自来水公司。我们每天都会上网，网速很慢，看个电影很卡，需要等很久才缓冲一个画面，我们打开网页很慢，IE状态条一直50%，那我们就要愤怒了，直接找电信、网通公司问明情况。

　　我想说以上的情况是正常的，如果你在优酷上看视频，需要缓冲很久。然后，你跟优酷客服打电话；访问博客园网站半天打不开，就跟dudu打电话，那我们如果不是对网络一窍不通的白痴，那一定是脑抽了。其实，我想说明的是，你可能从来不关心一个自来水厂供应多少水，但供应多少水对一个自来厂来说却非常重要。你可能从来不关心一个系统的吞吐量，但吞吐量对一个系统来说却非常重要。

　　ps：依照个人惯例，纯文字的内容必须配一张淡疼的图片！^_^

　　吞吐量

　　指在一次性能测试过程中网络上传输的数据量的总和。

　　对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，在容量规划的测试中，吞吐量是一个重点关注的指标，因为它能够说明系统级别的负载能力，另外，在性能调优过程中，吞吐量指标也有重要的价值。如一个大型工厂，他们的生产效率与生产速度很快，一天生产10W吨的货物，结果工厂的运输能力不行，就两辆小型三轮车一天拉2吨的货物，比喻有些夸张，但我想说明的是这个运输能力是整个系统的瓶颈。

　　提示，用吞吐量来衡量一个系统的输出能力是极其不准确的，用个最简单的例子说明，一个水龙头开一天一夜，流出10吨水；10个水龙头开1秒钟，流出0.1吨水。当然是一个水龙头的吞吐量大。你能说1个水龙头的出水能力是10个水龙头的强？所以，我们要加单位时间，看谁1秒钟的出水量大。这就是吞吐率。

　　吞吐率

　　单位时间内网络上传输的数据量，也可以指单位时间内处理客户请求数量。它是衡量网络性能的重要指标，通常情况下，吞吐率用“字节数/秒”来衡量，当然，你可以用“请求数/秒”和“页面数/秒”来衡量。其实，不管是一个请求还是一个页面，它的本质都是在网络上传输的数据，那么来表示数据的单位就是字节数。

　　不过以不同的方式表达的吞吐量可以说明不同层次的问题。例如，以字节数/秒方式表示的吞吐量主要受网络基础设置、服务器架构、应用服务器制约；以请求数/秒方式表示的吞吐量主要受应用服务器和应用代码的制约。

　　但是从业务的角度看，吞吐率也可以用“业务数/小时或天”、“访问人数/小时或天”、“页面访问量/小时或天”来衡量。例如，在银行卡审批系统中，可以用“千件/小时”来衡量系统的业务处理能力。那么，从用户的角度，一个表单提交可以得到一次审批。又引出来一个概念---事务。

事务

　　就是用户某一步或几步操作的集合。不过，我们要保证它有一个完整意义。比如用户对某一个页面的一次请求，用户对某系统的一次登录，淘宝用户对商品的一次确认支付过程。这些我们都可以看作一个事务。那么如何衡量服务器对事务的处理能力。又引出一个概念----TPS

　　TPS （Transaction Per second）

　　每秒钟系统能够处理事务或交易的数量，它是衡量系统处理能力的重要指标。

　　点击率（Hit Per Second）

　　点击率可以看做是TPS的一种特定情况。点击率更能体现用户端对服务器的压力。TPS更能体现服务器对客户请求的处理能力。

　　每秒钟用户向web服务器提交的HTTP请求数。这个指标是web 应用特有的一个指标；web应用是“请求-响应”模式，用户发一个申请，服务器就要处理一次，所以点击是web应用能够处理的交易的最小单位。如果把每次点击定义为一个交易，点击率和TPS就是一个概念。容易看出，点击率越大。对服务器的压力也越大，点击率只是一个性能参考指标，重要的是分析点击时产生的影响。

　　需要注意的是，这里的点击不是指鼠标的一次“单击”操作，因为一次“单击”操作中，客户端可能向服务器发现多个HTTP请求。

　　吞吐量指标的作用：

　　再次将话题回归到吞吐量上，在我们的性能测试中查看吞吐量对我们的测试有什么意义呢。

　　1、用户协助设计性能测试场景，以及衡量性能测试场景是否达到了预期的设计目标：在设计性能测试场景时，吞吐量可被用户协助设计性能测试场景，根据估算的吞吐量数据，可以对应到测试场景的事务发生频率，事务发生次数等；另外，在测试完成后，根据实际的吞吐量可以衡量测试是否达到了预期的目标。

　　2、用于协助分析性能瓶颈：吞吐量的限制是性能瓶颈的一种重要表现形式，因此，有针对性地对吞吐量设计测试，可以协助尽快定位到性能冰晶所在位置。

　　扩展：

　　RBI（rapid bottleneck identify）

　　是Empirix公司提出的快速识别系统性能瓶颈的方法。该方法基于以下事实。

　　1、发现的80%系统的性能瓶颈都由吞吐量制约；

　　2、并发用户数和吞吐量瓶颈之间存在一定的关联；

　　3、采用吞吐量测试可以更快速定位问题。

　　通过不断增加并发用户数和吞吐量观察系统的性能瓶颈。然后，从网络、数据库、应用服务器和代码本身4个环节确定系统的的性能瓶颈。

　　其实，我讲了这么多概念，我们无非是站在不同的角度去分解系统的性能，站在用户的角度，服务器的角度、系统的各种角度。了解一个人需要多方面，了解一个系统也需要多方面。我在尽量把这些东西讲的不枯燥，而且易懂。其实，自己写的过程也是思考的过程。

　不管是文档化的测试用例，还是存在于测试人员头脑中的测试想法和思维，针对测试对象的分析和设计都是整个测试过程的重要测试活动之一。在进行测试分析和设计之前，测试人员首先需要确定测试的需求来源，即测试用例设计需要参考哪些测试依据文档？

　　测试用例设计的输入文档是什么？测试人员头脑中第一个蹦出的参考依据就是需求规格说明。确实，需求文档是我们测试设计的最主要参考文档。但是，由于时间限制、成本限制和个人能力限制等方面的原因，提供完备的需求规格说明几乎是不可能的。现实情况是，需求规格说明常常是不全的、模糊的，甚至是错误的。

　　因此，测试设计中仅仅参考需求规格说明是不够的，测试人员需要从更广的范围来定义测试用例设计的参考来源。图1是作者提出的测试用例设计的参考输入的主要来源架构图。

图1 测试用例设计的参考输入的主要来源

　　除了软件产品相关的的开发文档之外，测试人员还需要收集来自用户的需求、与产品相关的标准与规范、以前类似产品的需求、测试团队的经验知识库，以及其他的一些隐现需求等。通过收集和分析这些参考输入来源，测试人员才能不断提高测试的覆盖率和质量。

　　1）开发文档

　　开发文档是测试人员进行测试用例分析与设计的最直接且必不可少的主要来源。这里的开发文档是一个统称，不同组织对其的称呼不同，包含了系统需求规格、概要设计规格、详细设计规格等不同的开发文档。

　　2）用户需求

　　软件测试同时包含了验证（Verification：Do you build the product right？）与确认（Validation：Do you build the right product？）两方面的工作。验证主要基于系统需求，来验证测试对象是否按照需求的定义实现了其中的功能和特性。而确认主要从用户的角度，保证经过测试的产品是真正客户所需要的，而不仅仅是了满足了系统的需求。因此，测试不仅仅是面向开发的，同时也应该关注面向用户。

　　用户需求可以来自各个方面，例如早期产品系统人员与客户直接沟通获取的需求、从产品技术支持人员和市场人员了解到的客户要求，以及从用户现场反馈的针对产品的缺陷和要求等。

　　3）标准与规范

　　针对特定的软件产品，不同标准组织和行业都制定了不同的标准和规范，而这些参考资料是开展测试分析和设计的又一个重要输入。例如电信产品相关的ITU-T标准、IEEE标准、RFC文档、国家电信行业规范等。

　　4）类似产品需求

　　随着软件产品越来越复杂，行业内采用增量-迭代开发模型的场合越来越多，例如敏捷开发。测试人员经常面临的软件产品是基于已有的系统之上，即测试对象是基于以前版本的功能增加、缺陷修复、平台移植等变更基础之上。因此测试人员需要分析历史测试是否全面，测试对象变更是否影响以前运行的软件版本等。基于这些信息，测试人员可以获取新的测试需求。

　　5）测试经验知识库

　　测试并不是存在编码之后的一个阶段，测试应该贯穿于整个软件开发生命周期。类似于开发过程改进一样，测试也应该是PDCA（戴明质量环）的过程。因此，不同项目中的测试经验是每次测试用例设计的重要输入。通过测试经验知识库，测试团队的测试经验和技能才能在整个组织中共享。

　　测试经验知识库可以来自测试执行的经验、测试过程中发现的缺陷分析和分类、用户反馈的缺陷分析和分类等。

　　6）其他隐现的需求

　　测试用例设计的参考输入，除了上面提到的一些来源之外，测试人员还需要考虑其他一些隐现的需求来源：

　　（1）不同产品利益相关者针对测试对象中间版本的变更而达成的备忘录；

　　（2）已经发布的用户使用风格指南和用户接口标准等；

　　（3）和不同的利益相关者，例如：开发人员、用户和技术专家等面谈得到的备忘录或者邮件内容等；

　　（4）通过杂志、网络等查找类似测试对象产品的一些常见缺陷、失效，以及测试对象支持功能在用户现场使用的讨论

发现：

　　人来了，又走了！

　　有篇博文如是说，大体意思是有些的程序员，中途转测试，但很快又转回程序员。为何会这样，难道说测试不值得他们一试吗？普遍流行说测试工作如何如何简单，就是会点点鼠标、按钮就能做的工作；然而，事实恰恰相反，这些老到的程序员却是因为测试工作的复杂而没有既来之，则安之的。

　　软件测试乍看起来是件简单的工作，深入其中后，发现并不如所想，程序中各个模块之间的接口调用错综复杂（特别是大型程序），加之程序员的编写代码技巧以及个人习惯，使得一个程序有多种编程思路，只为实现功能，而不考虑代码的优化、效率、易读性以及接口之间的耦合关系，这样就会造成各种意想不到的bug，诸多因素都可能产生bug，应该怎么去测试，一个覆盖面比较全的测试用例文件是必不可少的；当然，程序中的各种复杂关系都是要在用例中考虑和体现的；

　　测试用例是软件测试的核心，重要性是毋庸置疑的。但如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。

　　之前我理解的测试用例仅仅是覆盖程序面广的测试方案表，后来知道作为白盒测试的脚本也称作测试用例，因为脚本的执行过程其实就是测试用例的执行过程，每个具体功能的脚本都是一个用例；

　　定义：

　　测试用例（TestCase）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

　　特点，

　　1、原理上可以完美的全面覆盖，但不具有显示意义；

　　2、测试用例不能避免系统带来的问题，如内存等等；

　　3、随需求变动；

　　好的用例：

　　不同的软件要设计不同的用例，以达到资源最优分化，诸如银行、医疗、航天、政府、科研类似软件具有高度安全性、保密性的软件，测试工作的工作量较其他软件相要大的多；对于一些个人应用软件相对优先级就会小很多；

　　1、要让不懂程序的人能看懂，能根据用例进行程序测试工作；

　　2、覆盖面全

　　3、冗余步骤少

　　4、简洁明了

　　如何写？

　　1、根据需求分析结果，编写每个小功能的测试用例；

　　2、小功能－>模块->模块间－>系统；

　　3、长流程；

　　4、路径；

　　5、特殊操作；

　　设计方法：

　　可以采用软件测试常用的基本方法：等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例。

　　独具匠心的考虑方法；

　　测试用例中的信息：

　　简洁信息：编写时间、测试目的、定义术语、程序名称、程序说明、参考文档、版本号；

　　正文内容：用例编号、模块名称、测试前提（环境）、用例级别、测试目的、操作步骤、预期结果、备注信息等等；

　　测试的几个关键点：

　　1、临界点

　　2、互斥操作（touch）

　　3、条件限制

　　4、层次影响（一个界面的操作影响了之前木块的页面或者操作）

　　测试用例不是一劳永逸的事情，但是最好的测试方案参考，因为程序不可能永远不变；

　　对于脚本用例子，可以尝试为测试脚本编写测试用例，已确保脚本的正确性，提高测试准确度；

　　评审与维护：

　　1、评审，

　　测试用例的覆盖面全不全，有无冗余，要有一个专门的机制进行评审，以确定测试用例的可用性；（项目经理、测试组、客户）

　　2、维护

　　包括了对用例的漏洞补充与及时更新；

　　想法：如果对每次出现问题的位置在用例表上做标记，那么就能在长期使用中做到对模块设计者的评估；

　　软件测试类型分析是进行细化测试用例条件的重要手段之一，通过测试类型的分类，软件测试人员可以将测试条件从不同的维度进行考虑，并发现不同的缺陷类型，从而提高测试的覆盖率。

　　测试类型并不是一个标准，它的定义需要考虑公司内部不同的产品，结合项目开发特点和软件产品的特点，以及测试人员在行业领域的技能和经验的积累。图1是作者提出的测试类型定义需要考虑的几个方面：

图1 测试类型的主要来源

　　测试类型定义需要综合考虑各个方面的输入，包括开发文档定义的需求（包括涉及的一些标准与规范等）、ISO/IEC 9126质量模型、测试经验，以及通过分析在研发阶段发现的缺陷、产品发布之后用户反馈的缺陷分析等，不断分类提炼之后形成可用的测试类型。同时测试类型是一个不断迭代和更新的过程，在测试过程中可以不断改进测试类型。

　　1）需求文档分析

　　首先，测试对象相关的软件工作产品，包括相关的标准与规范等，是定义测试类型需要考虑的最主要来源。也就是说，软件产品的具体特点、实现的功能、面向的客户等是确定测试类型首先需要考虑的。例如：有的软件产品主要关注在用户体验上面，而有的软件产品是安全关键系统，那么它们在定义测试类型的时候是需要首先考虑的。

　　2）ISO/IEC 9126质量模型

　　不同的产品利益相关者，其对软件产品质量的描述和要求是不一样的，而测试人员需要兼顾不同人员对产品质量的要求。因此，仅仅依赖于产品的需求文档，测试人员无法设计有效的测试用例（用户反馈的缺陷就是一个有力的例证）。ISO/IEC 9126质量模型中定义的质量特性，可以为测试人员选择质量特性提供较好的思路，如图2所示。

图2 ISO/IEC 9126质量模型

　　3）测试经验

　　测试人员在行业和软件产品方面的经验也是测试类型定义中的重要输入之一。不同工作经验和行业工作经验的测试人员，在定义和分类测试类型过程中提出各自不同的观点和思路，有助于完善测试类型。

　　4）发布前的缺陷分析

　　测试人员在测试过程中可以发现大量的缺陷，通过分析不同产品、不同阶段发现的缺陷，也有助于测试类型的分类和完善。

　　5）发布后的缺陷分析

　　穷尽测试不可能，因此软件产品发布之后，总是能在用户使用现场发现不同类型的缺陷，通过分析和归类这些缺陷，同样也有助于完善测试类型。

　　（译注 ：解Bug时常发生分析时总感觉快找到答案了，而后面却一再陷入僵局。比如，将线程同步问题引起的一些时而有，时而没有的问题。分析时可能会认为这是个典型的线程同步问题，A线程没有按照预期的方式改变某个变量，导致了B线程处理出错。这样的分析结果如果没有调试（Debug）的支持，就有可能将开发者带入死胡同，找出一大堆的解决方案可能都无法完整地解掉Bug。一定要在每次陷入困境的时候，回头想一想，还有没有什么被忽略了。在一开始就对问题进行充分的了解是十分必要的。下文中作者提供了一个简单的流程可供参考。）

　　过去两年工作中，我竟然成了一个擅长解Bug的家伙。真不知道为什么偏偏是解Bug成了自然而然的事。在这段时间里我总结出了一套解bug的流程，简称为RED方法吧（译注：感 觉可以像是红色警戒！）。不过，这也不是什么新的方法论了。事实上，它成为标准的软件开发实践已经有些年头了。但是我依然见到许多开发者无法系统运用这个方法，总是被解Bug弄得头大。这就是写这篇文章的原因。

　　RED方法是什么？它其实上就是三个步骤： 重现（Reproduce），评估（Evaluate），和调试（Debug）。这三个步骤已经让我能够快速识别Bug的来源并快速的除掉它。c以下是详细的步骤：

　　重现（Reproduce）

　　重现一个 bug，除了验证它确实存在，也是为了找到一个测试用例供解决时使用。能够自信地测试您的解决方案对确保解掉这个bug 至关重要。（译注：常常有程序员看到Bug描述，就想当然的认为如何如何，结果可与之相反，这样的状况屡见不鲜。重现是第一步，特别是理解Bug背后的意图，就像是软件开发中的需求之于设计一样重要。）

　　评估（Evaluate）

　　面对Bug， 大多数开发者会将时间花在这里。坦率地说，这是错误的。评估应当用于找出一些显而易见的问题 （错误字符、 错误的常量等），然后调试程序，这样可以快速从代码中隔离出来这个Bug。解bug需要更多地关注代码。评估很重要，但不能靠它来解掉bug。

　　调试（Debug）

　　这是最重要的一步。一旦确定了Bug出现的位置，就要以单步执行的方式跟踪代码并加以分析。Bug 往往更多地取决于程序的状态，而不是它的位置。如果一个Bug发生是因为某个不应该为NULL的变量却赋成了NULL，那么这个Bug的根本原因可能在此位置之前了。（代码死掉的位置并不一定是Bug存在的位置）。

　　代码的运行状态比代码本身更重要。运用调试可以让你真正了解程序的运行状态。一行一行地逐步执行程序可以最终发现您的代码在哪里出错了和什么状态导致了这个问题。只有了解了代码为什么出错，而不是只了解代码在什么位置出错，才能找出最佳的解决方案。

　　例如，刚刚提到的那个Bug可以有两种方案：

　　1、添加判断，以确认该变量不是NULL。

　　2、消除所有可能导致此变量为NULL值的情况。

　　第一种方法有时可能是正确的。但如果在设计时该变量无论在哪里都不应为空，那这样做就有问题了。这样做只会暂时掩饰掉它，而以后可能就要花更多的时间来解决变量为NULL的情况了。

　　如果先确定导致该变量为NULL的所有情况，对于先前的设计，消除掉这些异常的情况，这样才算真正解掉了这个bug。解bug应当是修复代码中的缺陷，而不只是隐藏起来。

　　原文出自：http://blog.csdn.net/horkychen/article/details/7686204

图5.多个发布服务器和多个订阅服务器　　简介

　　本篇文章根据发布服务器，分发服务器和订阅服务器的组织方式和复制类型来讲述常用复制的几种模式。

　　模式的选择

　　选择复制的模式取决于多个方面。首先需要考虑具体的业务需求，在此之后还需要考虑硬件和网络的限制。对于业务需求来说考虑的角度可以分为两个部分：自治和延时。自治是指”数据不被影响的程度”，比如说一个业务场景：公司的总部在北京，发布服务器和分发服务器全在总部，各个地区的分部有订阅服务器，使用快照复制来接收推送订阅总部每个月一次的公司员工通讯录。在这个业务场景中，订阅服务器仅仅是接收发布服务器发布的通讯录信息，对于这些信息的修改是不会回传给总部服务器的，这个业务场景的自治程度就是非常低的。而对于延时来说，就是”在发布服务器上的数据修改应用到订阅服务器上的时间”，比如还是上面那个例子，每次订阅服务器的订阅周期是一个月，在此期间总部的通讯录可能经过了多次修改，但一个月以后才会同步到订阅服务器，那么这种场景的延时是非常高的。

　　其次就是硬件和网络的限制，比如将发布服务器和分发服务器设置在一台服务器上，在现有的情况下CPU是否能够承受这些负担？或是使用快照复制，发布服务器和订阅服务器之间的网络宽带是否能够承受在一定发布周期内的数据量传输？

　　在简单了解了模式选择的标准后，下面我们来看常用的几种复制模式。

　　以发布服务器为中心的复制模式

　　这种模式多个订阅服务器以一个发布服务器为中心进行订阅，如图1所示。

图1.多个订阅服务器以发布服务器为中心的模式

　　这种模式也是复制模式中最简单的模式，这种模式可以使用快照发布和事务发布。不难看出，这种情景的自治性是比较低的，因此这种模式适用于以下几种业务场景。

　　● 订阅服务器用于报表生成.

　　● 发布服务器用来发布类似前文所说的员工通讯录，产品资料等主（Master)信息

　　● 使用事务发布，使得订阅服务器承担部分负载

　　● 在发布服务器Down了以后，作为紧急备用服务器

　　当然，这种模式的缺陷也是显而易见的。

　　● 首先是发布服务器和分发服务器在同一台服务器上对CPU和内存的消耗服务器硬件是否能够承受是一个问题

　　● 在OLTP环境中如果每天要修改的数据量过大，比如超过10%，那么需要传送到的订阅服务器的数据量过大也是不得不考虑的一个问题

　　以发布服务器和分发服务器为中心的复制模式

　　这种模式其实和上一种模式区别不大，只是分离了发布服务器和分发服务器，如图2所示。

图2.以发布服务器和分发服务器为中心的复制模式

　　这种模式是将分发任务对CPU，内存和网络带来的负载转移到另一台分发服务器了。从而减轻发布服务器的压力和支持更多的订阅服务器。此外，我们知道一个分发服务器支持多个发布服务器的，因此也可以多个发布服务器使用一个分发服务器。

　　这种模式还有一个好处是可以将分发服务器放到DMZ区域和订阅服务器连接以避免发布服务器直接暴漏在外网。

　　当然了，这种模式最重要的一点是发布服务器和分发服务器一定要有可靠的网络连接，这种模式和图1提到的第一种模式适用的业务场景基本一致。

：QTP资源

http：//www.advancedqtp.com/

http：//knowledgeinbox.com/

http：//www.learnqtp.com/

http：//relevantcodes.com/

http：//www.intellipro.co.uk/

http：//www.softwareinquisition.com/

http：//www.qtp10.com/

2、HP官方QTP主页

https：//h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp？zn=bto&cp=1-11-127-24^1352_4000_100__

3、QTP第三方工具TestDesign Studio的主页

http：//www.patterson-consulting.net/products/test_design_studio/Default.aspx

4、QTP WEB测试辅助工具IE Developer Toolbar下载页面

http：//www.microsoft.com/downloads/details.aspx？familyid=e59c3964-672d-4511-bb3e-2d5e1db91038&displaylang=en

5、QTP论坛

SQAForums论坛上的QTP版块：

http：//www.sqaforums.com/postlist.php？Cat=0&Board=UBB20

AdvancedQTP论坛上启动的一个QTP虚拟项目（围绕QTP附带的样例程序Flight开展）：

http：//www.advancedqtp.com/forums/index.php/board，5.0.html

6、自动化测试方面的网站

http：//www.automatedtestinginstitute.com/

http：//safsdev.sourceforge.net/

http：//www.io.com/~wazmo/qa/#test_automation

QTP项目实战课程测试脚本下载（以Discuz论坛测试为例讲解QTP脚本设计）：

http：//files.cnblogs.com/testware/QTP_Training_Scripts.rar

相关课程：

http：//blog.csdn.net/Testing_is_believing/category/639478.aspx

《软件自动化测试成功之道》学习资源：

http：//blog.csdn.net/Testing_is_believing/archive/2010/05/27/5628697.aspx

QTP基础视频（《软件自动化测试成功之道》光盘视频）：

http：//www.verycd.com/topics/2823906

《QTP自动化测试进阶》一书附带的源代码，包含脚本例子、小工具：

http：//download.csdn.net/source/2473429

ADO教程：

http：//www.w3school.com.cn/ado/index.asp

QTP读取PDF、测试PDF

http：//files.cnblogs.com/testware/AccessingPDF.rar

QTP认证考试题目样例：

选择题

http：//www.softwaretestinggenius.com/categoryDetail.php？catId=147

描述问答题

http：//www.softwaretestinggenius.com/categoryDetail.php？catId=118

自动化测试框架

1、《测试对象级框架 - QTestWare》

http：//blog.csdn.net/Testing_is_believing/archive/2010/01/03/5125592.aspx

2、《QTP面向对象框架》

http：//blog.csdn.net/Testing_is_believing/archive/2009/12/19/5040680.aspx

3、《自动化测试框架剖析》

http：//blog.csdn.net/Testing_is_believing/archive/2009/12/20/5042211.aspx

4、《QTRunner》

http：//blog.csdn.net/Testing_is_believing/archive/2009/12/19/5037830.aspx

5、《自动化测试框架开发5步法》

http：//blog.csdn.net/Testing_is_believing/archive/2009/12/17/5026712.aspx

6、《QTP下基于XML+DP的关键字驱动DEMO》

http：//blog.csdn.net/Testing_is_believing/archive/2009/11/29/4900529.aspx

7、《如何选择自动化测试框架》

http：//blog.csdn.net/Testing_is_believing/archive/2008/06/29/2595477.aspx

8、《自动化测试框架设计指南》

http：//blog.csdn.net/Testing_is_believing/archive/2008/06/22/2576208.aspx

9、《QTP的报告管理扩展框架 - ReporterManager》

http：//blog.csdn.net/Testing_is_believing/archive/2008/01/27/2068905.aspx

10、《透析QTP自动化测试框架SAFFRON》

http：//blog.csdn.net/Testing_is_believing/archive/2008/08/28/2845530.aspx

11、《Test Automation Frameworks》

http：//safsdev.sourceforge.net/FRAMESDataDrivenTestAutomationFrameworks.htm

12、《QTP关键字驱动框架 - RelevantCodes[1]One》

http：//blog.csdn.net/Testing_is_believing/archive/2010/03/14/5378979.aspx

13、《介绍一个QTP基础框架 - SIFL》

http：//blog.csdn.net/Testing_is_believing/archive/2010/03/16/5384390.aspx

文章

1、《QTP10调试时查看变量显示空白 - 补丁QTP_00591》

http：//blog.csdn.net/Testing_is_believing/archive/2010/02/28/5333934.aspx

2、《HP发布QTP的新补丁支持FireFox3.5》

http：//blog.csdn.net/Testing_is_believing/archive/2010/01/10/5170279.aspx

3、《QTP10的Reporter对象》

http：//blog.csdn.net/Testing_is_believing/archive/2010/01/02/5121064.aspx

4、《QTP10的Tips.txt文件》

http：//blog.csdn.net/Testing_is_believing/archive/2009/12/13/4996879.aspx

5、《HP发布了针对QTP 10的Web2.0 Feature Pack》

http：//blog.csdn.net/Testing_is_believing/archive/2009/11/22/4851752.aspx

6、《QTP的智能识别(Smart Identification)过程》

http：//blog.csdn.net/Testing_is_believing/archive/2010/02/01/5277890.aspx

7、《如何让你的QTP脚本执行效率更高》

http：//blog.csdn.net/Testing_is_believing/archive/2009/12/19/5040174.aspx

8、《用户体验测试的自动化实现》

http：//blog.csdn.net/Testing_is_believing/archive/2008/05/27/2488303.aspx

9、《使用QTP进行非GUI的自动化测试》

http：//blog.csdn.net/Testing_is_believing/archive/2010/03/14/5379213.aspx

10、《QTP调用外部应用程序的4种方法》

http：//blog.csdn.net/Testing_is_believing/archive/2010/03/18/5394213.aspx

11、stickyminds网站上关于QTP和自动化测试的一些文章：

由软件测试bug状态转换想到的

　　上周四，不得不对客户新启用的bug管理工具Redmine中的bug状态进行验证。当然Redmine其实是一个项目管理工具，bug管理只是它的一部分功能而已。我在验证之前，是让一个经验不多的同事去验证的，主要是因为Redmine是客户的testmanager自定义了，我们发现之前的配置下某些状态下不能修改bug的状态了，或者说bug可选的状态不对。所有有必要在客户又重新调整后验证一下，是否符合我们一般的要求。同事的工作经验不多，估计又是忙着下班，着急的看了就画了个流程图，用邮件发给我且没有标题。收到以后，我自己也看了看，自己创建了一个testbug，发现流程图中出现的一个reopen状态，在现在的配置下根本就没有，我就不知道他是怎么画的了，我知道的是之前有reopen的，但最新的是没有的嘛。因此，我不得不重新研究。

　　说实话，我被气的够呛。如果简单的一个任务，作为测试每天都要接触的问题，怎么就不能研究好了，我自己也画了一个，发了邮件，发之前为了验证我画的流程图是不是，找了一个开发来帮我一起看看，让他看看在我不解释的情况下能不能理解。其实工作很简单，根据现有的配置，检查在各个状态下是否能流转到想要的状态去，不对的地方就提出来。为什么会做不好呢？同样一个任务，我和他做的效果就完全不一样。这个应该有那位同事去思考，而我却得到了一个新的面试题。

　　面试题：

　　1、请列出你说知道的bug的状态一般有哪些？

　　2、请根据你列出的状态，画出bug状态的转换流程图？

　　3、请根据上述的流程图，写出或列出对该流程图的用例

　　我觉得这是一个不错的面试题。第一个问题比较基础，但不容易答全了，bug的状态很多，并且各个公司对状态的定义可能会存在差别，但这种差别不影响回答这个问题。特别想提的是客户在bug状态中加了一个monitoring，我觉得很好，这是用来监控哪些不易产生，但有时常产生的bug，开发说改了，这样的bug测试人员就很纠结，验证的时候是没有出现，但这能代表问题真的修改好了。所以在一定时间内做监控，是有必要的。

　　第二个问题能考察应聘者的综合能力。是否仔细想过各状态之间转换的关系。是否能够将理解的内容转换成图形。是否有足够的耐心去做好事情。这基本和测试技能没什么关系，重点在其他基本素质。

　　第三个题目，考测试用例编写的思想。对于状态转换如何测试。这就是一个状态机的测试。也可以用场景法（路径法）测试。