转自网络：http://www.cnblogs.com/panjun-Donet/archive/2008/10/20/1315030.html

    用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。


用例是从系统外部可见的行为，是系统为某一个或几个参与者（Actor）提供的一段完整的服务。从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。

共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。

1、包含(include)

 

    包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。

   包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。　

   例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。

2、扩展(extend)

扩展关系：将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。

对于一个扩展用例，可以在基用例上有几个扩展点。   

例如，系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述：





4、泛化(generalization)

 

泛化关系：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。

例如，业务中可能存在许多需要部门领导审批的事情，但是领导审批的流程是很相似的，这时可以做成泛化关系表示：




    上面是我参考的一篇文章，觉得将三种关系的区别讲得很清晰，在此基础上结合自己的系统，对项目(在线购物系统)的用例做了整体的描绘。

    *****************************************************************

    (1)系统整体用例图

    


   
    (商品用例图)

   
   
    
   
   
   （购买信息用例）
  
   

   
    (用户资料用例)


   

   
   
按照先整体用例，后子系统用例来进行描绘的，欢迎大家提出好的建议!

转：UML中扩展和泛化的区别

         泛化表示类似于OO术语“继承”或“多态”。UML中的Use Case泛化过程是将不同Use Case之间的可合并部分抽象成独立的父Use Case，并将不可合并部分单独成各自的子Use Case；包含以及扩展过程与泛化过程类似，但三者对用例关系的优化侧重点是不同的。如下：
          ●泛化侧重表示子用例间的互斥性；
          ●包含侧重表示被包含用例对Actor提供服务的间接性；
          ●扩展侧重表示扩展用例的触发不定性；详述如下：

        既然用例是系统提供服务的UML表述，那么服务这个过程在所有用例场景中是必然发生的，但发生按照发生条件可分为如下两种情况：
         ⒈无条件发生：肯定发生的；
         ⒉有条件发生：未必发生，发生与否取决于系统状态；

         因此，针对用例的三种关系结合系统状态考虑，泛化与包含用例属于无条件发生的用例，而扩展属于有条件发生的用例。进一步，用例的存在是为Actor提供服务，但用例提供服务的方式可分为间接和直接两种，依据于此，泛化中的子用例提供的是直接服务，而包含中的被包含用例提供的是间接服务。同样，扩展用例提供的也是直接服务，但扩展用例的发生是有条件的。

         另外一点需要提及的是：泛化中的子用例和扩展中的扩展用例均可以作为基本用例事件的备选择流而存在。

学习有关业务用例与系统用例相似和不同之处的知识，包括应该使用什么样的 UML 图，通过建模工具来建模这些用例。绝大多数构架师都认为业务建模是开发软件解决方案中到一个非常重要的活动。成功的解决方案会支持这个业务，它们能够解决业务问题并确保业务目标的实现。

当开发一个合理的业务模型以后，业务流程分析员能够探究不同业务改进的选项，比如取消多余的任务，使重复且平凡的任务或者容易出现的错误实现自动化操作。 IBM® Rational Unified Process®，或者 RUP®，以及 Unisys 3D Visual Enterprise，或者 3D-VE， 或者 3D-VE,提供了一个系统化的方法，利用统一建模语言（UML）可以直观地表现业务模型，同时还可以派生出一个一致的且能够追溯到这个业务模型的起点系统用例模型。

这篇文章提供了 RUP 业务建模的概述，并解决了以下的问题：

业务用例模型与系统用例模型有怎样的相似之处？

业务用例模型与系统用例模型有什么不同之处？

构建业务模型应该使用哪个 UML 图？

业务用例模型与系统用例模型之间有什么关系？

背景

在谈论这个问题之前，我想解释一下为什么要挑选这个特殊的话题来写。自从1990年我就作为一名软件构架师从事系统用例的工作。当我是一名由 Unisys Global Public Sector 开发的 Integrated Justice Information Sharing (IJIS) 框架解决方案的总构架师时，还没有接触到业务用例，直到2002年。IJIS 现在已经发展成为 Unisys Information Sharing Management Framework (ISM)。

ISM 是一套支持信息共享的总体业务过程的可重用的组件。ISM Framework 利用 Service Oriented Architecture (SOA) 技术整合了不同类型的司法与公共安全系统，从而在关键决定点时分配关键的数据，文档以及图片。ISM 解决方案将为司法与公共安全 团体提供了一个业务框架、技术框架、基础应用软件以及方法，使政府机构能够继续使用他们的遗留系统。

ISM 是使用 RUP 进行设计的，ISM 业务模型是为 ISM 项目开发的首批工件之一。开发 ISM 业务模型对我来说是一个有意义的学习经历：我认识到的一个问题是，对于如何开发一个业务模型有很多含混不清的地方，为开发 UML 业务模型提供指导的文献相对比较少，而且有些不一致。

自从我离开 Unisys Global Public Sector 加入到 Unisys University 作为一名培训和开发顾问后，就一直负责开发和交付软件构架和 IBM Rational 工具培训。我的职责之一就是 IBM Rational 课程 "Mastering Requirements Management with Use Cases" (MRMUC) 的教学。这门课程主要阐述的是开发系统用例，但是这门课程仅仅提供了什么是业务模型以及它如何与这个系统用例模型相联系的一个很有限的讨论。因此这篇文章的目的之一就是为 MRMUC 课程补充材料。

这篇文章假定您已经有了系统用例建模和 RUP 需求规程的基本知识。如果您对系统用例建模并不熟悉，我建议您学习 RUP 需求规程的知识。

正如前面提到的，这篇文献关于业务建模的内容比较少，但是我们发现了一些非常有用的参考资料，远远多于您在 RUP 中找到的信息：

Writing Effective Use Cases， 由 Alistair Cockburn 编著。这是我最喜欢的关于业务和系统用例说明的著作。Alistair 强调一个业务或者系统用例模型最重要的部分是用例说明。这本书强调的就是用例说明，而不是 UML。

UML for the IT Business Analyst， 由 Howard Podeswa 编写。本书主要强调的是利用 UML 来开发一个业务模型，以及对 Alistair 的书进行补充。 UML for the IT Business Analyst 帮助我完成了关于如何开发一个有效的业务用例模型的课程培训。

Rational Edge 中的文章“Effective Business Modeling with UML: Describing Business Use Cases and Realizations”，由 Pan-Wei Ng 编写。那篇文章与这篇文章有些类似。那篇文章是从 UML 1.x 的角度来编写的。而这篇文章是从一个 UML 2.0 的角度来编写的，并且阐述了业务用例模型，业务分析模型，以及系统用例模型之间更深刻的关系。既然我已经完成了预备工作，就让我们开始提一些问题。

业务用例模型与系统用例模型有什么相似之处？

业务用例模型与系统用例模型有很多相似之处。两个模型都有用例说明。如果您对业务用例模型以及系统用例模型的 RUP 模版进行检查，您会发现它们的格式十分相似。两者都包含先决条件、后置条件、扩展点 以及特殊需求。业务用例说明有基本的工作流和可选择的工作流，从而取代了基本的事件流和可选流。

业务用例说明与系统用例说明的格式十分相似，但是在设计范围上有些分歧。业务用例的设计范围是业务操作。它是这个组织外部的业务参与者，实现与业务组织相关的业务目标。让我们查看这个业务用例的 RUP 定义：

业务用例从一个外部的，增加值的角度来描述一个业务过程。为了给这个业务的涉众创造价值，业务用例是超越组织边界的业务过程，很可能包括合作伙伴和供应商。"
简单地说，这个定义标识了一些重要点，比如：

一个业务用例描述的是业务过程——而不是软件系统过程。

一个业务用例为涉众创造价值。这些涉众要么是业务参与者要么是业务工作者。

一个业务用例可以超越组织的边界。有些构架师对于这一点有非常严密的态度。许多业务用例确实超越来组织的边界，但是有些业务用例仅仅关注于一个组织。我稍后将在这篇中给出一些例子。

让我们也看看 Podeswa 的书 UML for the IT Business Analyst 中对业务用例的定义：

"业务用例：业务过程是描述这个业务的具体工作流的；一次涉众与实现业务目标的业务之间的交互。它可能包含手工和自动化的过程，也可能发生在一个长期的时间段中。"

这个定义表明了通过实现业务目标创造价值的观点。它通过把一个业务过程描述成一个可能包含手工和自动化过程的具体工作流来详述 RUP 的定义。这个定义还指出，工作流可能发生在一个长期时间段中。所有的这些都十分的重要。

那么系统用例又是怎样的呢？系统用例的设计范围就是这个计算机系统设计的范围。它是一个系统参与者，与计算机系统一起实现一个目标。系统用例就是参与者如何与计算机技术相联系，而不是业务过程。

理解业务用例与系统用例的相似和不同之处（二）

Cockburn 的 Writing Effective Use Cases 给业务和系统用例使用了相同的用例说明模版。业务用例与系统用例说明使用这个模版的区别是设计范围，而不是模版。Cockburn 想通过目标层次对用例进行分类，如表格1所示。

图1： Alistair Cockburn 对业务和系统用例的分类 高层概要

高层概要

概要

用户目标

子功能

最低层

Cockburn 编写 Writing Effective Use Cases 的最初目标是系统用例，但他在业务用例上也花了很多精力。他利用目标层次来区分业务与系统用例，而不是使用不同的模版类型。那么这些图标和目标层次又意味着什么呢？

这些图标本身代表着一个简单的系统，它是根据用例与“海平面”（用户的实际层次）的相对高低来确定的。系统用例的最佳点是用户目标，通过海平面图标来表明。有时候需要将复杂的系统用例分解成其它有子功能目标、通过鱼图标表明的用例。但是您应该尽量避免将海平面系统用例分解成蛤或者最低层系统用例。

也许您会猜测到，概要或者蛤用例应该是业务用例。云或者高层概要也可能是业务用例。

Cockburn 的方法是将这些用例看作是一个光谱，从一个组织的最高层次业务目标，到为实现这些业务目标而执行的软件解决方案的需求详细资料。这种方法将系统用例看作是一个业务用例的分解。这个用例分解方法可以用来帮助您从这个业务模型驱动系统用例模型，我稍后会对这个问题进行讨论。

那么业务用例模型与系统用例模型图有什么其他相似之处呢？

两者都有参与者。在业务用例图中，您将一个参与者原型化为 <<BusinessActor>>。

两者都有用例。在业务用例模型中，您将一个用例原型化为 <<BusinessUseCase>>。

在参与者与用例之间两者都有一个通信关联。

业务用例和系统用例都能够包含、扩展，以及一般化关联。

用例图中的通信关联对于学习用例建模的人们来说，通常是一个容易混淆的地方。我应该使用箭头吗？这个箭头应该指向什么方向呢？通信关联已经被描绘出来，因为 1.4 UML 规范是一条实线。这条线可以配上一个箭头。这条线和箭头代表角色与系统之间的双方对话。如果呈现出一个箭头，那么说明只有这个关联末尾的“这个事物”能够发起通信。没有箭头的表明任何一方都可以发起通信（而不是两端都发起通信）。

UML 2.0 规范使它更简单。UML 2.0 不允许角色与用例之间或者业务角色与业务用例之间存在这种可灵活操作的关联。我个人比较喜欢箭头，但是如果您把 IBM Rational Software Architect (RSA) 当作您的 UML 建模工具，您就不能在角色和用例之间描绘出一个箭头。此时的 RSA 是完全没有错的。 UML 2.0 是通信关联不可灵活操作的原因。

既然我们已经讨论了业务用例模型和系统用例模型之间的相似之处，下面我们就看看它们的不同点。

业务用例模型与系统用例模型之间究竟有怎样的差别呢？

业务用例模型与系统用例模型之间主要有三点重大不同之处：设计范围、白盒测试与黑盒测试，以及业务操作者。

范围

在前面的部分中，我借助 Alistair Cockburn 的处于“水平线”上面、下面，或正好处于“水平线”的规定对设计范围进行了讨论。

业务用例着重于业务操作。它们表示实现业务目标的业务中的具体工作流。业务过程可能涉及手工和自动过程，并且在一段长期的时间内进行。

系统用例着重于要设计的软件系统。参与者如何与软件系统进行交互？我们在系统用例说明中书写的事件流应该足够详细，从而用作编写系统测试脚本的出发点。

白盒与黑盒

业务用例常常是以白盒形式编写的。它们描述了被建模的组织中的人和部门之间的交互。我们使用业务用例来说明在“现有”业务模型中组织如何工作。然后我们重构“现有”的业务用例模型，让其面向将要建模的组织的未来设计。我们需要创建什么新角色和部门来提供更多价值，或者消除业务问题？什么角色和部门需要消失？

系统用例几乎总是以黑盒形式编写的。它们描述了软件系统之外的参与者如何与将被设计的系统进行交互。系统用例详细阐明了系统需求。系统用例模型的目的是从涉众的角度说明需求，而不是设计如何满足需求。

业务角色

那么业务角色是什么？在系统用例图中，您只让参与者与用例进行交互。但在业务用例图中，您可以让业务参与者和业务角色与业务用例进行交互。

业务参与者是业务之外的人。它可以是一个角色或其他组织实体。例如，在刑事审判系统中，业务参与者可以是证人、嫌疑犯、外部的政府机构，例如健康服务，或业务实体，例如，业务资信咨询机构。

业务角色是业务内部的某个人或某个部门。在刑事审判系统中，业务角色可以是治安人员、法官、检察官，或假释官。当您实现了一个业务用例，并且创建了时序图和/或 通信图来显示业务参与者、业务角色，和业务实体如何协作执行业务用例时，您将会把业务角色从业务用例模型转入业务分析模型，并且加入所需的额外业务角色来提供业务用例功能。图 1 显示了基于 ISM 项目的示例业务用例图。
理解业务用例与系统用例的相似和不同之处（三）

作为最佳实践，我推荐断开业务用例和业务角色之间的导航，从而保持业务角色与业务参与者的一致。业务角色及其用例关联应该按照业务参与者与业务用例通信的同样方式来绘制。
您必须在您的工程的 Properties 标签页中选择 Profiles 选项卡，然后单击 Add Profile 按钮，来向您的工程中添加业务建模和健壮性分析原型。在 IBM Rational Rose 中，这是自动包含的。在 UML 2.0 中，概要文件用于包装原型和标记值 UML 扩展。UML 2.0 规范要求您向 UML 建模工程中添加概要文件来使用业务建模原型。

UML 业务模型包括两个模型：用例视图（Use-Case View）中的业务用例模型和逻辑视图（Logical View）中的业务分析模型。 1 业务用例模型中的主图是业务用例图。您还可以随意加入表示单个业务用例的 UML 活动图，来图形化地显示工作流过程，如图 2 所示，逮捕被告业务用例的活动图。



图 2：ISM 逮捕被告业务用例活动图

业务分析模型描述了通过业务角色和业务实体的交互来实现业务用例。它用作业务角色和业务实体需要如何相关联，以及它们需要如何协作，来执行业务用例的抽象。业务分析模型中有三种类型的 UML 图，如图 3 所示：类（Class）、时序（Sequence）和通信（Communication）图。



图 3：业务分析模型图

业务分析模型中的主要的图是时序图。您手工地创建显示出业务参与者、业务角色，和业务实体如何交互执行业务用例的时序图。时序图显示出以时间时序安排的对象交互。特别是，它显示出参与交互的对象，以及消息交换的顺序。

通信图是以前在 UML 1.x 中所称的协作图（Collaboration diagram），它描述了对象之间交互的模式，通过对象间的链接和发送给对方的消息来展示参与交互的对象。通信图和时序图都显示出交互，但它们强调了不同的方面。时序图清楚地显示出时间顺序，但没有明确地显示出对象关系。通信图清楚地显示出对象关系，但必须从顺序号那儿获得时间顺序。

两个图都显示出同样的行为，但方式不同。我个人喜欢时序图，因为它通常比较容易读懂。您还可以使用参与类的视图（View of Participating Classes，VOPC）来显示协作执行业务用例的业务参与者、业务角色和业务实体的静态视图。

图 4 显示出 ISM 逮捕被告业务用例实现的时序图。图 5 显示出 ISM 逮捕被告业务用例实现的 VOPC。图 6 显示出 ISM 逮捕被告业务用例实现的通信图。



图 4：ISM 逮捕被告业务用例实现的时序图

在 ISM 逮捕被告业务时序图这部分中，如图 4 所示，有三个从业务用例模型转入的业务角色：执法人、签署者（Subscriber）和刑事审判系统。刑事审判系统是执法人、法院、检察官，等等的一般化。为了让时序图简单化，我们使用该泛化来表示 ISM 可以使用的任意刑事审判系统。

图 4 还显示出引入到业务分析模型中的两个新的业务角色：档案管理系统（Records Management System，RMS）和 ISM Broker。RMS 通常是商业化成品（commercial off-the-shelf，COTS）解决方案，它将地方的执法用作刑事案件管理系统。ISM Broker 是 Unisys 计划开发的软件解决方案的自动化候选者或代理。

Unisys ISM 解决方案利用中心辐射型 SOA 技术整合了多个各种各样的司法系统，从而在重要决策点处，分享关键任务的数据、文档、图像和事务。ISM 可以在 Microsoft BizTalk Server 或 IBM WebSphere Business Integration 上实现。ISM Broker 作为在审判团之中数据共享的导管，并且利用当前的技术来推、拉、发布和订阅信息，从而支持日常的审判操作。



图 5：ISM 逮捕被告业务用例实现的 VOPC 图

理解业务用例与系统用例的相似和不同之处（四）

图 5 中的 VOPC 图显示了参与逮捕被告业务用例的业务参与者、业务角色和业务实体的静态视图。注意为每个业务角色显示的操作。这些操作被称为业务职责。VOPC 图的更精确的名称是参与的业务参与者、业务角色和业务实体的视图（View of Participating Business Actors,、Business Workers 和 Business Entities）。在本实例中，只有业务角色协作执行业务用例。 图 6：ISM 逮捕被告业务用例实现的通信图 如前面所提到的，通信图（如图 6 所示）是观察时序图中所示行为的另一种方法。RSA 提供了从时序图创建通信图的自动能力，反之亦然。 还有一个要回答的问题。 业务用例模型和系统用例模型之间的关系是什么？ 图 7，业务用例到系统用例的向下流动（Business to System Use-Case Flow Down），出自我所教授的 IBM Rational 课程“Mastering Requirements Management with Use Cases”。 图 7，业务用例到系统用例的向下流动 图 7 例举了课程中最难教授的主题之一，因为您要理解该图所需的大部分基础不在标准课程材料之内。本文的其中一个目的是提供额外的基础。 图 7 显示了业务模型中所找到的东西和系统用例模型中的东西之间的清晰映射。在此特殊的实例中，可以看出，系统能够将业务角色的职责自动化。它还显示出关键的业务角色是自动化的候选者。 记住，业务模型包含业务用例模型和业务分析模型。业务分析模型是业务用例模型的实现，并且拥有紧密的集成化和可追溯性。系统用例模型可以追溯到业务分析模型。业务分析模型可以追溯到业务用例模型。 使用该方法，您可以构建从业务分析模型演化来的系统用例模型。这向您的整个 UML 模型提供了一致性和可追溯性。 那么系统参与者和系统用例从那里来的呢？系统参与者是根据业务分析模型中的业务参与者和业务角色而生成的。与业务角色自动化候选者交互的业务参与者总是成为系统参与者。不是自动化候选者的，与业务角色自动化候选者交互的业务角色成为系统参与者。例如，ISM 业务分析模型中的执法人和法院成为了系统参与者。ISM Broker 是“纯”自动化候选者。它不会成为系统参与者。 我所谓的纯是什么意思呢？简单的说，自动化候选者的唯一目的就是成为我们正在开发的软件解决方案的代理。注意到图 7 中的 Loan Specialist。Loan Specialist 业务角色转换为系统参与者和系统用例。让我来解释一下。 Loan Specialist 是图 7 中所示的业务模型中的角色。在我们的系统用例模型中，需要有作为 Loan Specialist 角色的参与者。但是，在我们正在开发的新的软件解决方案中将 Loan Specialist 的一些业务职责自动化了。业务分析模型中的那些业务职责成为了系统用例模型中的系统用例。 其他的纯业务角色自动化候选者将不会转换为系统用例模型中的系统角色。这回答了问题，“系统用例是从哪里来的？”系统用例是根据业务分析模型中的业务角色自动化候选者的业务职责而创建的。如果您回到图 5，显示了 ISM Broker 的 VOPC 图，每个业务职责，例如 Query for Information，都可以转换为系统用例模型中的系统用例。 分析模型显示了业务实体如何映射到系统分析模型中的类上。这些类表示系统将使用的“数据”。 总结 我的目标是概括出 RUP 业务建模和系统用例建模的比较情况。我讨论了相似点和差别，以及业务用例模型和系统用例模型之间的关系。如果您对这些比较和关系有任何疑问，可以通过 arthur.english@unisys.com 联系我。 注释 1用例视图（Use-Case View）、逻辑视图（Logical View）是 UML 4+1 视图模型架构（UML 4+1 View Model Architecture）的一部分。要了解更多关于 4+1 视图模型架构的信息，您应该学习分析与设计规程中的 URUP 软件架构概念。

对于一个测试人员来说测试用例的设计编写是一项必须掌握的能力。但有效的设计和熟练的编写却是一个十分复杂的技术，它需要你对整个软件不管从业务还是从功能上都有一个明晰的把握。

一、问题：

　许多测试类书籍中都有大幅的篇章介绍用例的设计方法，如等价类划分，边界值，错误推断，因果图等。但实际应用中这些理论却不能给我们很明确的行为指导，尤其是业务复杂，关联模块紧密，输入标准和输出结果间路径众多时，完全的遵循这些方法只能让我们在心理上得到一种满足，而无法有效的提高测试效率。有时我们只有依靠以前项目的用例编写经验（或习惯），希望能在这一个项目中更加规范，但多数情况下我们规范的只是“书写的规范”，在用例设计上以前存在的问题现在依旧。

　当好不容易用例基本完成，我们却发现面对随之而来的众多地区特性和新增需求，测试用例突然处于一种十分尴尬的境地：

• 从此几乎很少被执行
• 已经与程序的实现发生了冲突（界面变动，功能变动）
• 执行用例发现的bug很少
• 根本没有时间为新的功能需求增补用例
• 有时间补充，但用例结构越来越乱，
• 特性的用例与通性用例之间联系不明确（以新增需求为主线列出所有涉及到的更改，但特性与通行之间的数据或业务联系在用例中逐渐淡化）
• 知道怎样执行这个用例，但它要说明什么呢？（多数用例给我们的感觉是只见树木，不见森林，只对某一功能，无法串起）

通过上面的一系列问题可以看到，似乎测试用例给我们带来的问题远多于益处，也正是因为在实际过程中遇到的问题积累，导致我们有很充分的理由忽视或拒绝用例的应用。
但没有用例或简略用例的编写我们又会舒服很多么？不言自明，谁也不想倒退发展吧。

二、原因：

　事实上我们在测试用例编写和设计上遇到的一系列问题只是一种表面的呈现，究其原因我认为有如下几点：

1、没有适合的规范

　“适合的规范”或称“本地化的规范”。这是我们在测试过程中遇到的第一个问题，通常也是很容易习惯且淡忘的。我们拥有相当多的流程文档、书本上的定义，但它适合我们当前的项目么？

　每一个测试工程师在进入这个职业的初期都会了解一些测试上的概念和术语，进入公司或项目组后也会进一步学习相应的文档，例如怎样规范编写，怎样定义bug级别，软件实现的主要业务等。但当测试经理开始给我们分配某一模块的用例编写时，又有多少人知道该怎样去写，怎样写算是好？

　在测试论坛中常能看到介绍用例编写方法的帖子，而迷茫于怎样应用到实践的回复也不为少数。为何我们无法在公司和项目组内找到明确且适合的规范？于是我们只得选择从书本或之前的用例中复制，不管是结构还是方式都依赖于以往?的经验，我并不是说这样就是错误的，但不能总结成文的经验无法给予测试更多帮助。

　我们有太多经验，但却没有形成适合的规范。

2、功能与业务的分离

　我们知道怎样列举一个输入框的用例，但却很少考虑说明这个输入框是用来做什么的，如果仔细分析不难发现，用例中这种功能与业务的分离越来越普遍也越来越明显。

　边界值、等价类划分、因果图，这些用例方法是一种高度提纯的方法，本身就很偏向于功能及代码，所以怎样编写业务的用例我们就从理论上失去了参考。

　复杂的业务会贯穿于整个软件，涉及众多功能点，里面组合的分支更不可胜数。测试用例务求简洁、明确，这一点也与业务“格格不入”。功能用例依赖程序界面，业务描述依赖需求文档。于是我们更偏向于根据已实现的界面编写功能用例，列举出众多的边界值、等价类。流程的操作只有凭借经验和理解，这时测试出的bug是最多的，但我们却无法使这个bug对应到一个用例中（点击一个按钮报出的错误有时原因并不在这个按钮或按钮所在的窗体）。正因为我们没有很好的积累业务上的用例，才使得我们感到执行用例时发现的bug不多。

　用例结构的划分一定程度上也造成了功能和业务的分离，依照界面模块建立文件夹，并在其中新建不同用例，这使得用例从结构上就很难联通起来。

3、测试未能跟上变化

　变化！想象一下，当我们越来越多的听到开发人员在那里高呼“拥抱变化”“敏捷开发”的时候，测试又有什么举措呢？当地区特性，软件版本越来越多的时候，测试是否在积极响应呢？变化是我们面临的最大挑战，我认为测试未能跟上变化是造成测试过程中遇到种种问题和矛盾的主要原因。

　对需求和程序的变化测试人员的感受是非常深的，测试总是跟在需求和开发后面跑，使得所有风险都压在自己身上。不断压缩的时间和资源使我们只能放弃那些“不必要”的工作：尽快投入测试，尽快发现bug，而非从整体把握软件的质量情况，统筹策略。

　疲于应对的直接影响就是程序质量无法准确度量，进度无法控制，风险无法预估。用例与程序脱节，新增用例混乱和缺少。长此以往我们只得放弃修改、增补用例，甚至放弃之前积累的所有成果。用例变为程序变更的记录摘要，没有测试数据的保留，测试步骤和重点无法体现，新加功能与原来的程序逐渐“脱离”，可能还会出现相互违背的情况，但这我们却无法很快发现。

　永远是变化决定我们的下一步工作，这也是混乱的开始。

三、可能的解决办法：

　在这里我希望以探讨的方式提出一些可能的解决办法，因为上面的问题也许在成熟的公司和项目组内很少遇到，而遇到问题的也需根据不同的情况单独考虑。不用拘泥形式，最适合的就是最好的。

1、测试驱动开发，用例指导结果，数据记录变化

　“测试驱动开发”（TDD）是一个比较新的概念，在网上可以看到很多介绍文章，它主要讨论如何让开发的代码更奏效（Work）更洁净（Clean），“测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码”。可以看到，TDD是建立在“代码”级别的驱动，但目前我们需要探讨的问题是怎样在黑盒测试中做到“测试驱动开发”。

　首先我们需要纠正一个态度，很多人认为黑盒测试的技术含量不高，可思考可拓展的内容不多，主要的工作就是用鼠标在那里瞎点，于是很多“高级”的技术方法都试图与黑盒测试划清界限。但测试人员发现的bug有80％以上都是黑盒测试发现的，手工操作软件仍是目前检验软件质量最有效的一种方法。

　如何在黑盒测试中做到测试驱动开发？我认为可以从用例级别做起，以业务用例指导过程和结果。

　开发人员通常比较关注技术，对于业务上的理解容易忽视并出现偏差，而需求文档又不会很明确的指出应该实现怎样的结果，这使得从业务到功能出现一个“阅读上的障碍”，如果最后程序错误了还需返工，这样耗费的人力物力就非常大了。使用业务用例驱动开发，就是一个比较好的方法，同样这也需要运用测试中的各种方法，列举出业务流程里数据的等价类和边界值。

　业务用例的构造要先于程序实现，与需求和开发人员沟通一致，并以此作为一个基准，保证程序实现不会错，还能对整个软件的进度和质量有一个很好的估计和度量。业务用例可以不关注程序的界面，但一定要有数据的支持。这就是测试主导变化的另一点“数据记录变化”。

　我们不仅要应对变化，还要记录变化，使测试用例成为对程序持续性的监控，数据可以作为最基本、最简单的支持。当一个业务很复杂时可以拆分成段（业务段与程序中以窗体或页面的划分是不一样的），使用典型的用例方法列出实际输入和预期结果。我们希望数据能做到通用和共享，最理想的情况就是建立一个“数据库”，每个业务用例都从“数据库”中取得输入数据和预期结果，这个数据只是针对业务入口和出口的，当程序内部设计变更时，保留的数据不会因此而作废。举一个例子，例如我的程序要从某种文件中读取数据并计算结果，一段时间后程序内部字段增加了，如果是以保存的文件附件方式提供数据，则现在程序很可能就打不开这个文件了。使用“数据库”指导测试人员可以在变化的程序里直接针对业务输入，而不关心程序内部结构。

　再进一步的话“数据库”就开始涉及到程序内部的接口了，这需要开发人员的配合。

2、为用例标明时间（版本）和优先级

　为测试用例标明时间或版本可以起到一种基准的作用，标明项目进度过程中的每一个阶段，使用例直接和需求基线、软件版本对应。同样这需要规范流程，也是对变更的一种确认和控制。或者可以为用例增加一个状态，指明这个用例目前是否与程序冲突，当程序变更时改变用例的状态，并更新用例版本。

　为测试用例标明优先级可以指出软件的测试重点、用例编写的重点，减少用例回归的时间，增加重点用例执行的次数，帮助项目组新人尽快了解需求，在自动化测试的初期也可以参考这个优先级录制脚本。

3、功能用例与业务用例分开组织

　将功能用例与业务用例分开组织，按照不同关注点列举执行路径。业务用例应在开发前或同期编写，帮助测试人员和开发人员明确业务，了解正确流程和错误流程。功能用例更依赖于程序界面的描述，但功能用例并不等于使用说明。对某些模块的等价类、边界值测试会发现很多严重的bug，也许与业务无关，但用户往往很容易这样操作（例如登录名，你是否考虑到很长的名字，或者用户的键盘有问题，总是敲入n多空格在里面，这与业务无关，但程序将会怎样处理？）。

4、审核用例，结对编写

　测试组长或经理对用例进行审核可以做到用例的补充和校对，但一般情况下是很难做到的，我们可以采用另一种方法，就是结对编写测试用例（前提是你有两个以上的测试人员），内部审核。

　测试用例不是一个人编写一个人执行，它需要其他测试人员都能读懂且明白目标所指。结对编写可以尽量减少个人的“偏好习惯”，同时也能拓展思维，加强测试重点的确认，小组内部达到统一。一定程度上结对编写也可以减少组长或经理对用例的管理，提高组员的参与积极性。

四、发展

　上面的这些解决方法只是一种建议，具体怎样实施到项目中还需根据情况而定。可以看到测试的发展方向是很多很广的，传统的黑盒测试并不是毫无新意，测试工作怎样适合我们而发展，将给予我们更多的思考。

转自网络http://hi.baidu.com/xpup/blog/item/e023a5090027eecb3bc76359.html

RUP里有两个重要的概念，用例和业务用例。初识RUP人常常会问，到底什么是用例，用例和业务用例的区别是什么。以下简要说明一下用例以及用例与业务用例之间的区别。

用例又叫系统用例，是一种软件需求定义的方法或形式。基于用例的需求定义方法与其他需求定义方法相比，有如下一些特点：

一、用例更加从用户（actor）的角度定义需求、强调用户目标，因此很容易为用户所理解。

传统以特性或功能的方式定义需求常常表现为系统必须这样或系统应该那样。如在描述一个在线书店的系统时，基于特性的方法会描述为：

1.系统应该提供搜索功能；

2.系统必须具备分类浏览的功能；

3.系统必须具有按折扣计算最终价格的能力等。

系统需求以一条条孤立的特性的方式表现出来，如果系统相对复杂，用户可能就会发出如下的疑问：“系统到底能帮我做什么，怎么帮我做的？”。用例正好回答了这个问题。以用例的方式定义需求处处关心用户到底想用系统做什么，如何做。例如，上例中网上书店系统，用户到底用它做什么呢？购书！嗯，购书就是其中的一个用例。接着，在购书这个用例中就会具体描述用户怎样和系统交互并最终完成购书过程。基本事件流示意如下：

1.用户准备在网上书店购书，用例开始。

2.用户浏览图书分类，查找图书。系统显示分类、子分类以及子分类下的图书。

3.用户选择准备购买的图书，并加入购物车。系统记录已加入购物车的图书并计算价格。

4.用户准备结账，系统提示确认购物清单，并提示输入银行账号、送货地址等关键信息。

5.用户输入以上信息，并确认。系统完成交易，并显示交易信息。用例结束。

二、用例不是功能也不是特性，用例不能被逐层分解为更小的用例。

用例的价值在于展现系统最终能帮用户做什么以及如何做到的。如果我们试图分解用例，那么谁去承担这个责任呢？最终结果与以特性方式定义需求相比又能有什么优越性呢。

在FDD方法中，提倡将基于特性的需求描述方式改进为以特性集的方式来描述需求，即将任务相关性强的特性组织在一起。在XP中，需求以用户故事的方式来描述，即以相对随意的方式描述用户怎么使用系统完成任务。可见关注用户任务的整体性并不是用例特有的。只是用例方法更为形式化一些。

三、用例主要以事件流的方式定义需求，但不是唯一的方式，用例形式化程度很高。

用例的主体是事件流，事件流分为基本流和备选流。基本流是用户使用系统时，最常用路径，一般不包括异常和分支。备选流则相反，一般是分支或异常等。不论是基本流还是备选流，都是以用户与系统的交互方式定义的，即用户如何使用系统，系统如何响应，但描述中不应夹杂UI设计信息。

除了主事件流之外，参与者描述了谁会使用这个用例。前置条件描述了必须具备什么样的条件或状态才能执行该用例。后置条件描述用户成功执行后应处于什么样的状态。特殊需求则会以特性的方式描述与用例相关的其他功能或非功能性需求，一般以非功能性需求居多。与XP、FDD等敏捷方法相比，用例更加形式化，定义需求更为严谨，当然花费的时间也会相对较多。

四、用例在同一时间只能有一个主要参与者（actor）。

用例充分关注用户使用系统到底做什么，但它只关注特定参与者与特定系统的交互而不包括参与者之间如何交互。如果在同一时间有两个主参与者在执行用例，就意味着你描述的不只是系统需求还包括系统所处环境中参与者之间的协作关系。例如，如果你的用例中包括类似如下的描述：

1.学生准备申请助学金，系统提示学生输入学习成绩、家庭条件等信息。

2.学生提交以上信息等待审批。

3.助学金审批人员审查学生助学金申请，决定批准，系统提示输入核准意见。

4.助学金审批人员输入理由并确认。

那么，你的用例就包括两个参与者，你的用例就不是真正的用例。同一时间，用例之所以只能有一个参与者，是因为用例只定位在描述系统的需求上，而不是定位在描述参与者之间如何协作上。如果将让用例同时描述参与者间协作，那用例将不只是定义需求还将定义业务流程，用例的复杂性增加、针对性降低、实用性减弱。

那参与者之间协作在哪描述呢，我们也确实需要它。实际上那是业务用例实现的职责。

五、用例不是需求的唯一定义形式，用例需要和其他需求定义形式一起定义完整的需求。

用例较其他需求方法具有优越性，但只使用用例是无法有效地定义完整的需求。用例主要定义的是功能性和行为性的需求，系统还有大量的非功能性需求需要定义，如易用性、性能、可支持性等等。这些需求以用例的方式定义都是不可行的，而定义他们最好的形式还应该是特性。

另外对于一些功能性需求，可能也不适合使用用例来定义，如系统对外提供的服务接口等。而对于一些不与参与者交互的中间件产品中的大量需求尤其不适合使用用例定义。其需求定义的方式使用特性更为合适。

以上大致描述的什么是用例，用例有什么特点。实践中总是有人分不清用例和业务用例。业务用例是用例思想的延续，只是改变了使用场合。用例是从使用者的角度定义“软件系统”需求。而业务用例不研究“软件系统”需求，它更关心一个“业务组织”对外提供哪些服务。如住房公积金中心是一个业务组织，你或许就是一个业务参与者（如果你准备作住房公积金贷款）。那么办理住房公积金贷款就是一个业务用例。这个业务用例会描述什么呢？它会描述类似如下内容(由于内容复杂仅作示意)：

1.职工准备相关资料去住房公积金中心办理货款。业务用例开始。

2.职工向中心提交准备贷款的相关资料，中心工作人员对资料进行初审。

3.若审核通过，职工准备办理抵押合同，中心工作人员委托担保公司与职工签订抵押合同。

4.担保办理完成后，职工与中心签订理借款合同，中心工作人员要求职工办理银行卡并提供卡号。

5.借款合同签订后，中心工作人员要求贷款合同必须办理公证，职工与中心一道办理公证。

6.职工办理完公证后，中心发放贷款。业务用例结束。

可见，此处的业务用例描述的是业务参与者（职工）如何使用业务组织（中心）提供的服务的过程。因此业务用例实际上是一种业务流程。它以业务组织外部业务参与者的角度定义业务组织提供的服务。当然业务用例还包括一些内部流程，它可能不是由业务参与者启动的，如采购流程等。因此，业务用例只是使用了用例的思想和形式而已，研究的主题是完全不同的。用例研究软件系统，借助用例定义软件系统需求。而业务用例研究一个目标组织，借助业务用例定义目标组织应该具有哪些业务流程，以及这些流程应该是什么样子的。

一个完整的Web安全体系测试可以从部署与基础结构，输入验证，身份验证，授权，配置管理，敏感数据，会话管理，加密，参数操作，异常管理，审核和日志记录等几个方面入手.
数据加密： 某些数据需要进行信息加密和过滤后才能进行数据传输，例如用户信用卡信 息、用户登陆密码信息等。
此时需要进行相应的其他操作，如存储到数据库、解密发送要用户电子邮箱或者客户浏览器。
目前的加密算法越来越多，越来越复杂，但一般数据加密的过程时可逆的，也就是说能进行加密，同时需要能进行解密！
登录： 一般的应用站点都会使用登录或者注册后使用的方式，因此，必须对用户名 和匹配的密码进行校验，以阻止非法用户登录。
在进行登陆测试的时候，需要考虑输入的密码是否对大小写敏感、是否有长度和条件限制，最多可以尝试多少次登录，
哪些页面或者文件需要登录后才能访问/下载等。超时限制：WEB应用系统需要有是否超时的限制，
当用户长时间不作任何操作的时候， 需要重新登录才能使用其功能。

SSL： 越来越多的站点使用SSL安全协议进行传送。SSL是Security Socket Lauer(安全套接字协议层)的缩写，
是由Netscape首先发表的网络数据安全传输协议。SSL是利用公开密钥/私有密钥的加密技术。
（RSA），在位于HTTP层和TCP层之间，建立用户与服务器之间的加密通信，确保所传递信息的安全性。
SSL是工作在公共密钥和私人密钥基础上的，任何用户都可以获得公共密钥来加密数据，
但解密数据必须要通过相应的私人密钥。
进入一个SSL站点后，可以看到浏览器出现警告信息，然后地址栏的http变成https，
在做SSL测试的时候，需要确认这些特点，以及是否有时间链接限制等一系列相关的安全保护。
服务器脚本语言：脚本语言是常见的安全隐患。每种语言的细节有所不同。有些 脚本允许访问根目录。其他只允许访问邮件服务器，
但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己。找出站点使用了哪些脚本语言，并研究该语言的缺陷。
还要需要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。
最好的办法是订阅一个讨论站点使用的脚本语言安全性的新闻组。
注：黑客利用脚本允许访问根目录的这个安全隐患特性攻击网站。
这个网站包含了脚本代码（有允许访问根目录的特性）就可能有这个安全隐患。
日志文件： 在服务器上，要验证服务器的日志是否正常工作，
例如CPU的占用率是否很高，是否有例外的进程占用，所有的事务处理是否被记录等。
目录： WEB的目录安全是不容忽视的一个因素。
如果WEB程序或WEB服务器的处理不适当，通过简单的URL替换和推测，会将整个WEB目录完全暴露给用户，
这样会造成很大的风险和安全性隐患。
我们可以使用一定的解决方式，如在每个目录访问时有index.htm,或者严格设定WEB服务器的目录访问权限，
将这种隐患降低到最小程度。
注：每个目录访问时有index.htm
目的： 通过首页中的登陆验证功能进行访问权限控制。

http://www.rkb.gov.cn/jsj/cms/s_contents/jjrk/jjrk2009112701.html

*1.1 功能测试*
l         *概述*
：确保测试的功能正常，如导航，数据输入，处理、检索是否正确，以及业务规则的实施是否恰当。即对交互的输出或结果进行分析，以此来核实应用程序及其内部进程,
这是目前的测试重点。
l         *目标*：利用有效的和无效的数据来执行各个用例流，以核实以下内容：
²        在使用有效数据时得到预期的结果
²        在使用无效数据时显示相应的错误消息或警告消息。

单一界面测试的参考表格如下：

   *编号*
 *场景/条件*
 *操作*
 *预期结果*
 1.
 用户通过用户界面输入信息
 输入任何东西，重填
 客户端页面恢复到初始状态
 2.
 用户通过用户界面输入信息
 输入刚好等于字数限制的正确信息，提交
 1.所填信息正确保存到相应的数据库表中
2.客户端提示提交成功
 3.
 用户通过用户界面输入信息
 输入略超过字数限制的正确信息，提交
 1.所填信息不能正确保存到相应的数据库表中
2.客户端提示字数超长
3.引导用户定位超长输入
 4.
 用户通过用户界面输入信息
 输入略少于字数限制的正确信息，提交
 1.所填信息正确保存到相应的数据库表中
2.客户端提示提交成功
 5.
 用户通过用户界面输入信息
 输入非法字符，提交
 1.     所填信息不能保存到相应的数据库表中
2.     客户端提示有错误输入
3.     引导用户定位错误输入
 6.
 用户通过用户界面输入信息
 输入为空，提交
 1.应有必填项判断
2.客户端提示必填项不能为空
3.引导用户定位必填项
4.所填信息不能保存到相应的数据库表中
 7.
 用户通过用户界面输入信息
 该输入汉字的输入英文字符，提交
注：其余类同
 1.客户端提示错误输入
2.引导用户定位错误输入项
3.所填信息不能保存到相应的数据库表中

具体功能测试参考表格如下：

功能A描述

用例目的

前提条件

输入/动作

期望的输出/相应

实际情况

示例：典型值…

示例：边界值…

示例：异常值…

功能B描述

用例目的

前提条件

输入/动作

期望的输出/相应

实际情况

……

注：除测试所提供的功能外，还需添加Cookies测试

 参考如下：

Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web
服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。

如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies
是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。

 1.2 用户界面测试

l         *概述*：用于核实用户与网站界面之间的交互是否正常

l         *目标*：核实下列内容

²        确保各种浏览以及各种访问方法（鼠标移动、快捷键等）都使用正常

²        确保窗口对象及其特征（菜单、大小、位置、状态和中心）都符合标准等

       参考表格如下：

  检查项

测试人员的类别及其评价

窗口切换、移动、改变大小时正常吗？

各种界面元素的文字正确吗？（如标题、提示等）

各种界面元素的状态正确吗？（如有效、无效、选中等状态）

各种界面元素支持键盘操作吗？

各种界面元素支持鼠标操作吗？

对话框中的缺省焦点正确吗？

数据项能正确回显吗？

对于常用的功能，用户能否不必阅读手册就能使用？

执行有风险的操作时，有"确认"、"放弃"等提示吗？

操作顺序合理吗？

按钮排列合理吗？

导航帮助明确吗？

提示信息规范吗？

以下为软件界面测试的一些规则，亦可部分作为WEB用户界面测试的一些参考。

  界面测试
  界面设计与测试规则

界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度远远不够，直到最近网页制作的兴起，才受到专家的青睐。而且设计良好的界面由于需要具有艺术美的天赋而遭拒绝。目前流行的界面风格有三种方式：多窗体、单窗体以及资源管理器风格，无论那种风格，以下规则是应该被重视的。

  1：易用性：

按钮名称应该易懂，用词准确，屏弃没楞两可的字眼，要与同一界面上的其他按钮易于区分，能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。

  易用性细则：
  1):完成相同或相近功能的按钮用Frame框起来，常用按钮要支持快捷方式。
  2):完成同一功能或任务的元素放在集中位置，减少鼠标移动的距离。
  3):按功能将界面划分局域块，用Frame框括起来,并要有功能说明或标题。
  4):界面要支持键盘自动浏览按钮功能，即按Tab键的自动切换功能。
  5):界面上首先应输入的和重要信息的控件在Tab顺序中应当*前,位置也应放在窗口上较醒目的位置。
  6):同一界面上的控件数最好不要超过10个，多于10个时可以考虑使用分页界面显示。
  7):分页界面要支持在页面间的快捷切换，常用组合快捷键Ctrl+Tab
  8):默认按钮要支持Enter及选操作，即按Enter后自动执行默认按钮对应操作。
  9):可写控件检测到非法输入后应给出说明并能自动获得焦点。
  10):Tab键的顺序与控件排列顺序要一直，目前流行总体从上到下，同时行间从左到右的方式。
  11):复选框和选项框按选择几率的高底而先后排列。
  12):复选框和选项框要有默认选项，并支持Tab选择。
  13):选项数相同时多用选项框而不用下拉列表框。
  14):界面空间较小时使用下拉框而不用选项框。
  15):选项数叫少时使用选项框，相反使用下拉列表框。
  16):专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词眼。

  还有[转贴]   界面测试

  界面测试
  界面设计与测试规则

界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度远远不够，直到最近网页制作的兴起，才受到专家的青睐。而且设计良好的界面由于需要具有艺术美的天赋而遭拒绝。目前流行的界面风格有三种方式：多窗体、单窗体以及资源管理器风格，无论那种风格，以下规则是应该被重视的。

  1：易用性：

按钮名称应该易懂，用词准确，屏弃没楞两可的字眼，要与同一界面上的其他按钮易于区分，能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。

  易用性细则：
  1):完成相同或相近功能的按钮用Frame框起来，常用按钮要支持快捷方式。
  2):完成同一功能或任务的元素放在集中位置，减少鼠标移动的距离。
  3):按功能将界面划分局域块，用Frame框括起来,并要有功能说明或标题。
  4):界面要支持键盘自动浏览按钮功能，即按Tab键的自动切换功能。
  5):界面上首先应输入的和重要信息的控件在Tab顺序中应当*前,位置也应放在窗口上较醒目的位置。
  6):同一界面上的控件数最好不要超过10个，多于10个时可以考虑使用分页界面显示。
  7):分页界面要支持在页面间的快捷切换，常用组合快捷键Ctrl+Tab
  8):默认按钮要支持Enter及选操作，即按Enter后自动执行默认按钮对应操作。
  9):可写控件检测到非法输入后应给出说明并能自动获得焦点。
  10):Tab键的顺序与控件排列顺序要一直，目前流行总体从上到下，同时行间从左到右的方式。
  11):复选框和选项框按选择几率的高底而先后排列。
  12):复选框和选项框要有默认选项，并支持Tab选择。
  13):选项数相同时多用选项框而不用下拉列表框。
  14):界面空间较小时使用下拉框而不用选项框。
  15):选项数叫少时使用选项框，相反使用下拉列表框。
  16):专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词眼。

  还有:   规范性、合理性、美观与协调性、菜单设置、独特性、快捷方式的组合、容错性考虑、多窗口的应用与系统资源。

Thanks a million. I really appreciate it.万分感谢,真的是帮了我大忙啦.


I really appreciate what you've done for me these days.
我真的很感激这些天来你对我的帮助.

It's very kind of you to help me.
你能帮助我真是太好了.

I really don't know what I would have done without your help.
真不知道没有你的帮助我该怎么办

Thank you for one of the most enjoyable visits we have had in many months.
在您处的参观访问,是我们几个月中最愉快的一次.谨向您表示感谢.


Thank you for contributing so much to the pleasure of our staying...
感谢您使我们在......停留期间的愉快所作的许多努力.


Thank you so much for your generous hospitality.
非常感谢您慷慨的款待.

You must give me the chance to return your kindness when you visit here.
希望您光临我处,使我能答谢您的盛情.


Thank you very much (ever so much) (most sincerely) (indeed)(from the bottom of my heart).
很(非常)(最真诚地)(确实)(衷心)感谢您.


It's generous of you to take so much interest in my work( togive me so much of your time) (to show me so much consideration).
承蒙您对我的工作如此操心(为我花费这么多时间)(对我如此关怀).


At the outset, I want to thank you for your kindness to me and for your compliments.
首先,我要感谢您对我的友爱和问候.

白领的一天 场景1:Interview我要找工作

1．Interview我要找工作

常用应急场景

范例一：I am working on it

Hi, Monica, how is everything going?

Everything goes well, but I am thinking about quitting my current job.

Why? You’re not satisfied anymore?

I just sense. But I cannot grow anymore. My boss is not really supporting me. I am interested in some positions in other JV companies, but I need to do some more in-step research before I send my application letters out.

That is important. Doing research on a company you are interested in will definitely help your application.

Certainly, it is very nice talking with you. But I really have to go now. Catch you later.

Ok, good luck to you.

范例二：Calling a company

ABC Company, my name is Lucy. How can I help you?

Hello, Lucy, this is Monica. I’m calling for the accountant position. I saw the information about the vacancy on your company’s website. Is it still available?

Thank you for your interest. The position is still available. Have you already sent your CV to us?

No, not yet. First, I want to check about the availability and see if you could give more information.

It is urgent for us to fill this position now and I would like to stress that English is a must because of the international contacts and most likely traveling abroad very soon. If all these is not problem for you, I recommend you to mention these in your cover letter and send it to me directly.

The notification period of my current job is not that long and I’m quite profession to English and I am happy with the traveling abroad as I’m good dealing with the people from other cultures. It makes the whole job even more interesting. I will send my resume to you still this week.

范例三：E-resume or paper resume

Hello, Lucy. This is Monica again. I have a question.

Please ask.

I was wondering what kind of resume do you prefer, an e-resume or paper one?

For this position we prefer e-resume at the very beginning. Please send it to our department’s e-mail box.

Ok, thank you.

You’re welcome.

2.接到猎头电话

常用应急场景

范例一：A call from a head-hunter

R: Hello, I am Richard from the Brooks Head-hunter company. Can I have a private talk with you?

M: Er? I am driving right now. Can you call back in 30 minutes?

R: Sure.

R: Hi, Monica, Richard again. Have you ever heard about our company? It is an international one with good reputation. We have a lot of successful cases. If you’re trying advance your career, I would love to help you. XYZ Company is one of our clients. They’re in need of the talent like you. Would you be interested in taking part in an interview? It is scheduled some time within this week.

M: Thank you for calling. I really appreciate your kindness. But right now, I’m very busy preparing for an interview of another company. I don’t think I am available for this opportunity.

R: Ok, I see. Good luck to you. You have my number. Call me when you change your mind. I can send you more detailed information about company and jobs you might be interested in if you give me your private e-mail address.

M: Well, I will text to you. Thank you, bye for now.

R: You’re welcome. Bye.

3.第一次去公司

常用应急场景

范例一：How can I get there?

Hello, this is Lucy from ABC Company. Is this Monica?

Yes, it is.

I am calling to inform. you that we have arranged an interview for this accountant position at 2 PM this Thursday afternoon. Please come on time.

Ok, thank you. By the way, could you please tell me how I can get there from A community?

Oh, you can take the subway, get off at B stop and walk north for several minutes. You will find a building. It will take about 40 minutes in total.

I got it. Thank you so much.

You’re welcome.

范例二：Could you show me the way?

Excuse me, could you please show me the way to the human resource department?

Yeah, but have you made an appointment ahead?

Yes, of course. I am Monica. I have made an appointment with your HR manager.

Just a minute please. I’ll make a call to the HR office.

Yes, they confirm your appointment. Please come in. it is on the 3rd floor, room 3106. You can take the right elevator as the left on is in maintenance today.

Thank you very much.

You’re welcome.

4.初次面试

常用应急场景

范例一：Three rounds is successful

Good afternoon. How can I help you?

Good afternoon. My name is Monica. I am here for the job interview at 2 PM.

Ok, please first fill in the form. and return it to me. You can do it in the next door.

Done. Here is my paper.

Everybody attention. I would like to make sure you all know the process. The interview consists of three parts. One, all of the interviewees will answer the question there and lasts for maximum one hour. Two, we will take a 30-minute’s break. After the break, we all come back to this office and I will announce the successful candidates for the 2nd round. In which, you have a small interview with your future manager.

What about the 3rd round?

Good question. But I will tell you when you pass the first two.

范例二：Meeting the manager

Good afternoon. I suppose you are Ms. Monica. My name is Mr. Thomas, the general manager of ABC Company. Here is my business card.

Thank you very much.

I am very impressed by your resume. Therefore, I am very interested to know why you’re willing to leave your current company.

I am looking for a more challenging position. I can’t grow anymore in my current job.

Ok, I understand. But why you choose us to work for?

I have studied carefully the information about your company on the internet and I have checked your company’s homepage. I am impressed by the company. And I like the products a lot. Since you’re growing steadily, I would be very eager to help you to improve your accounting system.

How do you work with a team?

I work quite well with a team. I’m a good team player. I respect people, cooperate well with member’s team. And I will do my best to help team members.

What’s your long term goal?

I’d like to bring to ABC Company not only my technical skills, ambition, enthusiasm, but also my loyalty, a sensor desire to become an administrative assistant. It is the hardest of my career plans.

5.面试终于结束了

常用应急场景

范例一：It is enough for today

It is enough for today. Do you have any last question? If not, thank you for taking your time to come to our interview.

You’re welcome. For the moment, I have no further questions. I got a good picture of the job and the company. All my questions have been answered. Thank you for your time.

We will have an internal discussion and then we will contact to inform. you of our decision on whether we continue with you or not.

Ok, it was very nice to talk with you and I look forward to your decision at your earliest convenience. Bye.

Goodbye.

范例二：Still a little on the edge

Any plans tonight?

Not really, do you?

Well, I am wondering if we took a hang-out for a drink or something. You know, I just came back from a really tough interview. I was quite nervous during the interview. I really want to have the job. Right now, I am still a little on the edge. I am not sure if I could convince them during the interview.

Take it easy. It is all over now. How was it going, anyway?

I don’t know. I think I did well in the paper exams. I was prepared to answer a lot of questions, but they didn’t ask those as I expected. To my surprise, the manager tried to talk about the Chinese poesy with me.

That’s strange. But probably, it is the new interview technique they call it “Getting to know you more personally”. What about your answers?

Just did my best.

 

6.复试通知

常用应急场景

范例一：Please come for the next round

Hello. This is Lucy from ABC Company. Is this Monica?

Yes.

I am calling to inform. you that you have passed the first two rounds of interview. Could you please come for the final round? It is scheduled on the morning of next Monday 10AM in the HR manager office.

Thank you for calling me. I will be there on time.

Ok, see you then, bye.

Bye.

范例二：Share the news with Tina

Hi, Tina, I’ve got good news. I have successfully passed the first two rounds of interview with ABC Company. They informed me to go to the final round next Monday. It looks very promising.

That is awesome. Congratulation! I know you can make it.

Thanks. Let’s go for a celebration this evening. Are you free?

Yes. Wait for me at the café down my office building. See 5PM, ok?

No problem. See you!

See you!

1、术语解释

　　测试程序：提供给测试组测试的程序；
　　测试计划：对测试程序（构件、应用程序、系统等）及其目标进行简要说明；
　　测试bug：不符合测试需求的错误，也就是缺陷；
　　错误跟踪系统：是某个程序或应用系统，使得项目组可以报告、管理以及分析错误报告和错误趋势，如RationalClearQuest就是一个错误跟踪系统。
　　2、为什么要提交bug
　　在得到一个详尽的测试程序后，剩下的工作就是执行测试计划了。但是由于任何由人编写的程序都不可避免的存在着不符合测试需求的错误，也就是bug。因 此需要一个方法来跟踪、分析和展示那些测试活动，避免偏离最小。这种方法称之为错误跟踪系统。它主要是有效的管理缺陷，实现以下作用：
　　1)减少由于缺陷报告不明确而被开发组驳回的情况；
　　2)加快缺陷的处理速度；
　　3)提高测试的可信度；
　　4)加强测试组与开发组在整个项目过程中的团队合作
　　3、如何才能提交好的测试bug
　　在有些组织里，程序员几乎会把一半的测试bug返回给测试组，因为那些错误不可再现、没有发现错误、同设计要求一致，或者错误报告根本无法操作。如果 错误报告有如此高的返回率，基本可以认为是过程崩溃，需要立即解决：因为编写这些报告浪费了时间；会影响程序员和测试人员之间的团队凝聚力；最糟糕的是失 去改进产品质量的机会。
　　有些错误总是不可再现的或提出质疑的。有些错误只是间断地在模糊的或极端的条件下表现出来。有时候，测试环境和程序员之间的不一致会导致“在我的系统 上工作良好”的反应。在需求不清楚的项目中，在一定的测试条件下，对“正确”行为的观点可以存在合理的不同。有时候，当真正的问题在于糟糕的测试过程、测 试数据或不正确的测试用例时，测试人员可能错误解释测试测试结果和报告错误。
为了防止这类问题，要提交好的测试bug，作为一个好的测试人员，必须遵循以下八个步骤：
　　1) 结构：无论你是做探索性的或是描述性的、手工的或自动的测试，都要认真仔细的测试；
　　一个好的错误跟踪系统包括了错误的必要信息，如果做得不好，会造成迷惑，并误导读者。好的故障描述应该包括十个基本部分：标题、项目、所属模块、优先级、重要性、异常等级、可重复性、现象、操作过程和附件。
　　①标题
　　使用一两句话来描述错误，告诉经理、开发人员以及其他读者为什么应该关心该问题。好的标题应该着重于出现的bug现象。但是过于简洁易引起误导，使得 原本重要的问题被忽视。因此必须应该采用简洁、切中要害的概要，这样才能引起读者的重视。不重要的就描述比较轻微，例如：“联系人的email没有检查合 法性”；重要的就要体现比较严重，例如：“填了运营商仍然提示运营商不能为空，使得无法进行下一步的操作”，会更容易让开发人员理解究竟是什么问题及其重 要性，并及时处理。 　　分为以下5级：1级：“非常严重”，表示缺陷不修改整个系统流程不能继续；2级：“比较严重”，表示缺陷不修改不影响系统其他流程，但是本模块流程不 能继续；3级：“一般”，表示缺陷不影响流程；4级：“轻微”，表示缺陷可以延期解决；5级：“优化”，表示修改以后流程会更好。
http://www.rjgc.net/control/content/content.php?nid=17482

从测试过程的角度来说我们也可以把数据库测试分为：

　　系统测试
　　传统软件系统测试的测试重点是需求覆盖，而对于我们的数据库测试同样也需要对需求覆盖进行保证。那么数据库在初期设计中也需要对这 个进行分析,测试.例如存储过程，视图，触发器，约束，规则等我们都需要进行需求的验证确保这些功能设计是符合需求的.另一方面我们需要确认数据库设计文 档和最终的数据库相同，当设计文档变化时我们同样要验证改修改是否落实到数据库上。
　　这个阶段我们的测试主要通过数据库设计评审来实现。
　　集成测试
　　集成测试是主要针对接口进行的测试工作，从数据库的角度来说和普通测试稍微有些区别对于数据库测试来说，需要考虑的是数据项的修改 操作、数据项的增加操作、数据项的删除操作、数据表增加满、数据表删除空、删除空表中的记录、数据表的并发操作、针对存储过程的接口测试、结合业务逻辑做 关联表的接口测试。
　　同样我们需要对这些接口考虑采用等价类、边界值、错误猜测等方法进行测试。
　　单元测试
　　单元测试侧重于逻辑覆盖，相对对于复杂的代码来说，数据库开发的单元测试相对简单些，可以通过语句覆盖和走读的方式完成。
　　系统测试相对来说比较困难，这要求有很高的数据库设计能力和丰富的数据库测试经验。而集成测试和单元测试就相对简单了。
　　而我们也可以从测试关注点的角度对数据库进行分类：
　　功能测试
　　对数据库功能的测试我们可以依赖与工具进行：
　　DBunit：一款开源的数据库功能测试框架，可以使用类似与Junit的方式对数据库的基本操作进行白盒的单元测试，对输入输出进行校验。
　　QTP：大名鼎鼎的自动测试工具，通过对对象的捕捉识别，我们可以通过QTP来模拟用户的操作流程，通过其中的校验方法或者结合数据库后台的监控对整个数据库中的数据进行测试。个人觉得比较偏向灰盒。
　　DataFactory：一款优秀的数据库数据自动生成工具，通过它你可以轻松的生成任意结构数据库，对数据库进行填充，帮助你生成所需要的大量数据从而验证我们数据库中的功能是否正确。这是属于黑盒测试。
　　数据库性能虽然我们的硬件最近几年进步很快，但是我们需要处理的数据以更快的速度在增加。几亿条记录的表格在现在是司空见惯的，如此庞大的数据量在大 量并发连接操作时，我们不能像以前一样随意的使用查询，连接查询，嵌套查询，视图，这些操作如果不当会给系统带来非常巨大的压力，严重影响系统性能。
　　性能优化分4部分：
　　1、物理存储方面
　　2、逻辑设计方面
　　3、数据库的参数调整
　　4、SQL语句优化
　　性能测试：
　　我们如何对性能方面进行测试呢，业界也提供了很多工具通过数据库系统的SQL语句分析工具，我们可以分析得到数据库语句执行的瓶颈，从而优化SQL语句。
　　Loadrunner：这个不用多说，我们可以通过对协议的编程来对数据库做压力测试。
　　Swingbench：（这是一个重量级别的feature，类似LR，而且非常强大，只不过专门针对oracle而已）数据库厂商也意识到这点，例如oracle11g已经提供了real applicationtest，提供数据库性能测试，分析系统的应用瓶颈。
　　还有很多第三方公司开发了SQL语句优化工具来帮助你自动的进行语句优化工作从而提高执行效率。
　　安全测试
　　软件日益复杂，而数据又成为了系统中重中之重的核心，从以往对系统的破坏现在更倾向于对数据的获取和破坏。而数据库的安全被提到了最前端自从SQL 注入攻击被发现，
http://www.rjgc.net/control/content/content.php?nid=17611

1页面部分

　　（1） 页面清单是否完整（是否已经将所需要的页面全部都列出来了）
　　（2） 页面是否显示（在不同分辨率下页面是否存在，在不同浏览器版本中页面是是否显示）
　　（3） 页面在窗口中的显示是否正确、美观（在调整浏览器窗口大小时，屏幕刷新是否正确）
　　（4） 页面特殊效果（如特殊字体效果、动画效果）是否显示
　　（5） 页面特殊效果显示是否正确
　　2 页面元素部分
　　（1）页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等）
　　（2）素是否显示（元素是否存在）
　　（3）页面元素是否显示正确（主要针对文字、图形、签章）
　　（4）页面元素的外形、摆放位置（如按钮、列表框、核选框、输入框、超连接等）
　　（5） 页面元素基本功能是否实现（如文字特效、动画特效、按钮、超连接）
　　（6） 页面元素的容错性列表（如输入框、时间列表或日历）
　　（7） 页面元素的容错性是否存在
　　（8） 页面元素的容错性是否正确
　　3 功能部分
　　（1） 数据初始化是否执行
　　（2） 数据初始化是否正确
　　（3） 数据处理功能是否执行
　　（4） 数据处理功能是否正确
　　（5） 数据保存是否执行
　　（6） 数据保存是否正确
　　（7） 是否对其他功能有影响
　　（8） 如果影响其他功能，系统能否作出正确的反应
　　（9） 其他错误
　　（10） 对模块的具体功能进行测试时可以列出功能模块的所有功能，进行排列组合，测试所有情况
　　如：某一功能模块具有最基本的增删改查功能，则需要进行以下测试
　　单项功能测试（增加、修改、查询、删除）
　　增加——>增加——>增加 （连续增加测试）
　　增加——>删除
　　增加——>删除——>增加 （新增加的内容与删除内容一致）
　　增加——>修改——>删除
　　修改——>修改——>修改 （连续修改测试）
　　修改——>增加 （新增加的内容与修改前内容一致）
　　修改——>删除
　　修改——>删除——>增加 （新增加的内容与删除内容一致）
　　删除——>删除——>删除 （连续删除测试）
　　（11）查询功能分为两种情况，验证操作结果。
　　一、打开页面时自动显示结果，则不特别强调；
　　二、需要手工操作进行查询，则每次在其他功能完成后进行。
　　4 提示信息
　　（1） 成功、失败提示
　　（2） 操作结果提示
　　（3） 确认提示
　　（4） 危险操作、重要操作提示
　　（5） 返回页面 提示后显示的页面
　　5 容错性
　　注意以下几种情况
　　（1） 为空、非空
　　（2） 唯一性
　　（3 ）字长、格式
　　（4） 数字、邮政编码、金额、电话、电子邮件、ID号、密码
　　（5） 日期、时间
　　（6） 特殊字符 （对数据库）英文单、双引号，&符号
　　6 权限部分
　　功能权限： 指定用户可以使用那些功能，不能使用那些功能
　　数据权限： 指定用户可以处理那些数据，不可以处理那些数据。可以合并到功能测试
　　操作权限： 在逻辑关系上，操作前后顺序、数据处理情况。可以合并到功能测试
　　权限变化： 可以合并到功能测试
　　（1） 功能权限是否存在
　　（2）功能权限是否正确
　　（3） 数据权限是否存在
　　（4） 数据权限是否正确
　　（5）操作权限是否存在
　　（6） 操作权限是否正确
　　（7） 引起权限变化的功能列表
　　（8） 功能权限变化还是数据权限变化，或两者兼有
　　（9） 权限变化是否正确
　　7 键盘操作
　　（1） Tab键的使用
　　（2） 上下方向键的使用
　　（3） Enter键的使用
　　（4） 系统设定快捷键的使用（如果设置有快捷键）
　　8 测试中还应注意的其他事项
　　（6） 完整性：是否是一个整体，没有功能缺损
　　（7） 易用性：使用是否方便
　　（8） 一致性：类似的问题用类似的方法处理
　　（9） 提示信息：提示信息是否完整、正确、详细
　　（10） 帮助信息：是否提供帮助信息，帮助信息的表现形式（页面文字、提示信息、帮助文件），帮助信息是否正确、详细
　　（11） 兼容性：包括操作系统兼容和应用软件兼容，可能还包括硬件兼容
　　（12） 可扩展性：是否由升级的余地，是否保留了接口
　　（13） 稳定性：运行所需的软硬件配置，占用资源情况，出现问题时的容错性，对数据的保护
　　（14） 运行速度：运行的快慢，带宽占用情况
　　有几点：
　　1.功能点测试：是否满足需求所要求的功能
　　2.字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.
　　3.字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.
　　4.标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.
　　5.中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.
　　6.信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.
　　7.界面测试：界面的正确性、一致性、友好性、易用性。
　　用户界面测试是从最终的使用者用户的角度来看软件，软件难以理解，不易使用就是软件缺陷。可以从以下几个方面重点来检查用户界面：
　　1.易用性检查：确保软件易于理解，方便使用。
　　2.一致性检查：
　　a.注意系统页面的风格是否一致，如字的大小、颜色、字体要相同。
　　b.提示信息的表达方式是否一致。
　　c.按钮排列顺序是否一致。
　　d.back, cancel等按钮跳转页面处理是否一致。
　　e.各字段的名称，位置、长度、类型是否和设计文档要求一致，如Employee No和LoginName不一致。
　　3.正确性检查：检查页面上的form, button, table, header, footer,提示信息，还有其他文字拼写，句子的语法等是否正确。
　　4.友好性检查：
　　a.提示信息是否友好.
　　b.系统应该在用户执行错误的操作之前提出警告，提示信息.
　　c.页面分辨率检查，在各种分辨率浏览系统检查系统界面友好性。
　　5.合理性检查：做delete, update, add, cancel, back等操作后，查看信息回到的页面是否合理。
　　6.检查本地化是否通过：英文版不应该有中文信息，英文翻译准确，专业。
　　7.页面最大化检查：测试最大化/最小化/还原时页面是否做了对应的处理。
http://www.rjgc.net/control/content/content.php?nid=11715

1 概述

　　在一个软件项目开发中，系统测试是保证整体项目质量的重要一环，本文将就网站的测试技术及相应的自动测试工具做一个简要的介绍。主要就如下几个方面进行探讨：
　　功能测试
　　性能测试
　　安全性测试
　　稳定性测试
　　浏览器兼容性测试
　　可用性/易用性测试
　　链接测试
　　代码合法性测试
　　2 测试内容
　　2.1 功能测试
　　在实际工作中，功能在每一个系统中的具有其不确定性，而我们不可能采用穷举的方法进行测试，因而导致了功能测试较为困难，我们依据80/20原则（即80%的错误存在于系统的20%的部分）对于测试用例的设计采用如下两种方法
　　2.1.1 白盒测试
　　白盒测试即使用程序设计的控制结构导出测试用例。基于目前的现状我们采用基本路径测试方法进行白盒测试，此种方法简单高效。基本路径测试方法的简单说明如下：
　　¨ 首先通过系统设计的流程图导出数据流图
　　¨ 根据数据流图计算其环形复杂性
　　V(G)=E-N+2
　　或 V(G)=P+1
　　V(G)：环形负责性
　　E ：流图中边的数量
　　N ：流图中节点的数量
　　P ：流图中判定节点的数量
　　¨ 我们设定V(G)条路径
　　¨ 我们设计V(G)条路径的模拟数据
　　¨ 根据数据进行相应的测试
　　2.1.2 黑盒测试
　　黑盒测试即派生出执行程序所有功能需求的输入条件，从而导出测试用例，进行测试的方法，黑盒测试用于辅助白盒测试。
　　我们采用等价划分的方法进行测试，即为将程序的输入域划分为数据类，以便导出测试用例。一般情况下输入条件为：一个特定的数值、一个数值域、一组相关值或者一个布尔条件。
　　2.1.3 网站功能测试
　　对于网站的测试而言，每一个独立的功能模块需要单独的测试用例的设计导出，主要依据为《需求分析》，对于应用程序模块需要设计者提供基本路径测试法的测试用例
　　具有测试用例后可以采用OpenSTA(Open System Testing Architecture)进行自动化测试
　　2.2 性能测试
　　网站的性能测试对于网站的运行而言异常重要，但是目前对于网站的性能测试做的不够，我们在进行系统设计时也没有一个很好的基准可以参考，因而建立网站的性能测试的一整套的测试方案将是至关重要的。
　　网站的性能测试主要从两个方面进行：负荷测试(Load)和压力测试(Stress),负荷测试指的是进行一些边界数据的测试，压力测试更像是恶意测试，压力测试倾向应该是致使整个系统崩溃。
　　性能测试可以采用相应的工具进行自动化测试，我们目前采用如下工具
　　ab -----Apache 的测试工具
　　OpenSTA—开发系统测试架构
　　2.3 安全性测试
　　目前网络安全问题日益重要，特别对于有交互信息的网站及进行电子商务活动的网站尤其重要。目前我们的测试没有涵盖网站的安全性的测试，我们拟定采用工具来测定，工具如下
　　SAINT------- Security Administrator's Integrated Network Tool
　　此工具能够测出网站系统的相应的安全问题，并且能够给出安全漏洞的解决方案，不过是一些较为常见的漏洞解决方案。
　　2.4 稳定性测试
　　网站的稳定性测试是指网站的运行中整个系统是否运行正常，目前没有更好的测试方案，主要采用将测试服务器长时间运转进行测试。
　　2.5 浏览器兼容性测试
　　通过白盒测试或者黑盒测试导出的测试用例，采用相应的工具进行测试，可以采用OpenSTA进行测试，此测试工具可以采用不同的浏览器进行测试。
　　2.6 可用性/易用性测试
　　可用性/易用性方面目前我们只能采用手工测试的方法进行评判，而且缺乏一个很好的评判基准进行，此一方面需要大家共同讨论。
　　2.7 链接测试
　　超级链接对于网站用户而言意味着能不能流畅的使用整个网站提供的服务，因而链接将作为一个独立的项目进行测试。目前我们已经有了一个测试工具
　　Xenu------主要测试链接的正确性的工具
　　可惜的是对于动态生成的页面的测试会出现一些错误。
　　2.8 代码合法性测试
　　代码合法性测试主要包括2个部分：程序代码合法性检查与显示代码合法性检查
　　¨ 程序代码合法性检查
　　程序代码合法性检查主要标准为《intergrp小组编程规范》，目前采用由SCM管理员进行规范的检查，未来期望能够有相应的工具进行测试。
　　¨ 显示代码合法性检查
　　显示代码的合法性检查，主要分为Html、JavaScript、Css代码检查，目前采用
　　HTML代码检查------采用CSE HTML Validator进行测试
　　JavaScript、Css也可以在网上下载相应的测试工具。
　　3 测试工具
　　OpenSTA
　　主要做性能测试的负荷及压力测试，使用比较方便，可以编写测试脚本，也可以先行自动生成测试脚本，而后对于应用测试脚本进行测试。
　　SAINT
　　网站安全性测试，能够对于指定网站进行安全性测试，并可以提供安全问题的解决方案。
　　CSE HTML Validator
　　一 个有用的对于HTML代码进行合法性检查的工具
　　Ab(Apache Bench)
　　Apache自带的对于性能测试方面的工具，功能不是很多，但是非常实用。
　　Crash-me
　　Mysql自带的测试数据库性能的工具，能够测试多种数据库的性能。
　　上述工具除Ab及Crash-me外均可在以下目录中找得到
　　\smbserver\apps\linuxapp\intergrp
　　ab及Crash-me请至相应的网站上察看相应的资料}
　　4 后记
　　此文只是对于网站的测试方面做了一个简单的介绍，提供的工具比较少，但是可以保证能够使用（当然都是可以从网上免费得到的），另外还有很多测试工具是 需要Money的，大家有兴趣可以试用，对于上述提到的测试工具我也只是做了一个初步的调研，详细的功能说明请察看相关的说明文档。
　　对于网站的测试中比较重要的还有一个部分就是对于数据库的测试，由于对于数据库性能测试较好的工具需要一些Money因而我们采用Mysql的 Crash-me,但是同时也存在一个问题就是对于不同的数据库的测试采用第三方的工具较好。因而大家可以对于其他数据库性能测试的工具进行研究。
http://www.rjgc.net/control/content/content.php?nid=17981

信息	描述
Action	选择一个Action，这样你就可以查看该Action的所有对象。
Object repository tree	包括当前所选的Action的所有对象（所有本地对象及共享对象）。 注意：假设在多个关联的共享仓库中具有相同的对象（同名、同类、同父节点），则树中只显示第1个对象（即根据Action Properties->Associated Repositories页共享仓库列表的顺序，找到的第1个对象）。 你可以对树中的对象进行筛选，选择显示所有对象、本地对象、或某共享仓库的对象。
Name	QTP指定给测试对象的名称。该名称可以修改。
Class	对象所属的类。
Repository	对象所属仓库的位置。如果是本地对象，则显示Local字样。
Test object details	对象的属性及属性值。你可以修改本地对象的详细信息。可通过按钮显示或隐藏详细信

1. I'm dying to see you.
我真想见到你.

2.I'm flattered.
过奖了.

3.I'm not in the mood.
我没有心情.

4.I won't buy your story.
我不吃你这一套(我不买你的帐).

5.It hurts like hell.
痛死了.

6.It can't be helped.
无能为力.

7.I'm always punctual.
我总是很准时.

8.I wish I could.
不行.

9.What's the rush?
什么事这么麻烦?

10.What's so funny?
有什么好笑的.11.I couldn't agree more.
我完全同意.

12.I couldn't do less.
我将竭尽全力.

13.I can't care less.
我不在乎.

14.Stay out away with the matter please.
别管这事.

15.Mind your own business.
少管闲事.

16.Don't jump to conclusions.
不要过早下结论.

17.Forgive me for breaking my promise.
请原谅我食言.

18.Let's forgive and forget.
让我们既往不咎.

19.She gives me a headache.
她让我头疼.

20.He often fails to keep his words.
他常不守诺.

21.Who do you think you are?
你以为你是谁?

22.You're wasting your breath.
你在白费口舌.

23.Don't get on my nerves.
不要搅得我心烦.

24.His argument doesn't hold water.
他的论点站不住脚.

25.Your face tells it all.
你的表情透露了一切.

26.Don't look wise.
不要自作聪明.

27.You're too much(going too far)
你太过分了.

28.I don't have the nerves to do it.
我没有勇气去做.

29.It's the matter of life and death.
这事生死攸关.

30.Nothing works.
一筹莫展.
31.Money will come and go.
钱财乃身外之物.

32.You're too out-spoken.
你太鲁莽了.

33.He puts me into shame.
他使我难堪.

34.Every dog has his day.
人人都有得意之日.

35.Are you out of your mind.
你疯了吗?

36.Who's to blame?
怪谁呢?

37.It's raining cats and dogs.
天正下着倾盆大雨.

38.You won't get away with the publishment.
你逃脱不了惩罚.

39.His idea is childish/naive.
他的想法太天真.

40.I hope I'm not in the way.

我希望我没有妨碍.

41.What brings you here.
什么风把你吹来了.

42.She looks blue.
她看起来很忧郁.

43.You're the boss.
你说了算.

44.Where to, chief?
老兄,到哪儿去?

45.as high as a lark
心情愉快

46.I get a bang out of you.
你给我极大的乐趣.

47.i'm all ears
洗耳恭听

48.Take your time.
打扰了.

49.I'm mad/crazy about
...我对...着迷

50.How do I address you?
怎么称呼你?

51.Over my dead body.
没门.

52.I like to see a job done quickly.
我喜欢速战速决.

53.More haste,no speed.
欲速则不达.

54.That's not like him.
那不像他的风格.

55.Be my guest.
别客气.

56.Don't beat around the bush. Let's get to the point.
不要拐弯抹脚,直谈要点.

57.Far from it.
不是这回事.

58.It doesn't make any difference.
没有什么差别.

59.It's better than nothing.
廖胜于无.

60.I'm not myself today.
我心神不安.

61.Late is better than never.
迟做总比不做好.

62.It all depends.
看条件决定.

63.Put the cart before the horse.
本末倒置.

64.Once in a blue moon.
罕见.

65.I came with the express purpose of seeing you.
我是特意来看你的.

66.They greeted him with many expressons of pleasure.
他们说拉许多表示欢迎的话.

67.To put all cards on the table.
打开天窗说亮话.

68.No smoke without fire.
无风不起浪.

69.As red as a rose.
艳若桃李

70.To beat all air.
捕风捉影.

原文出处：

http://www.cnblogs.com/xuben/archive/2009/03/23/1333520.html

一、无法识别控件。
       二、错误回放过程未知弹出窗口。
       三、加载.net插件后和TD的关联问题。
       四、动态加载元素的识别问题。
       五、调用外部dll的问题。
       六、随机验证码的问题。

问题一，解决办法有三种：
   1、更改QTP自身对某控件的识别方式，在 tools——Object Identification 中。在这里列出了所有QTP能识别的控件，以及控件的识别方式。你可以给他添加X、Y坐标进行识别。或更明显的，列表中的信息，不按名称识别，而是按ID识别。这个修改可以解决一些问题，具体的赶紧动手试试吧……
   2、使用虚拟物件，来定义一个控件，在 tools——Virtual Object 中。在这里可以自定义一个控件。例如在ASP的程序中，程序出错，在客户端的表现形式大部分是一样的，你可以把整个错误页面当成一个控件来识别（感觉不错）。如果加一个判断，出错后你想做什么就由你自己定了。
   3、使用低级录制或鼠标录制。用 Test——LowLevelRecording/AnlogRecording 吧，用它录制就不需要什么设置了，他会记录你的程序控件相对屏幕的位置。用LowLevelRecording还有代码可改，用AnlogRecording动作就被封装了（维护性极差）。两者因实际环境更取其长吧……

问题二的解决过程：
关于弹出提示的问题，我当时需要情况是这样的。一个信息录入系统，由于数据量很大，查询需要一段时间。QTP回放时动作比较快，点了保存，程序还没反应过来它就进行了下一步操作。这时的操作就和录制时不一样了，程序给出一个提示，但这个提示是录制过程没有的。弹出框是一般都是POP形势（至上）的，导致QTP无法继续回放，结果就是回放失败。 
解决办法有两个：
        1、进行判断，当出现这个提示时，点是/否/取消按钮。
        2、通过 Tools——Recorvery Scenario Manager 设置默认操作。
    我最初就是用的第一种方法。写一个函数判断是否出现这个提示，如果出现就点“取消”然后wait(2)。    每个可能出现弹出框的动作后都调用一次这个函数。虽然可以解决这个问题，但回放的效率就低了，而且需要你预知提示框的信息。
    当我知道了第二种方法，显然更科学^_^。它可以对所有预知甚至不知的提示进行指定的操作。
    实际上，当程序出现了未预知的提示时，可能就是程序的BUG，所以使用上述办法解决工具问题时，也要考虑是否会掩盖程序的缺陷。

问题三的解决办法：
      用好QTP后，会不自觉的和TD关联起来。但从TD直接启动QTP时，程序只会加载QTP自带的插件，如果你安装了其它插件（如.net、java、etc.），默认是不加载的。这会导致上传的脚本无法正确执行。解决办法很简单，去 Test——Setting里进行Modify 吧。从本地打开的脚本，这里不能进行Modify的。所以办法很简单，但如果不知道的话就很难了。当初为这个问题我可是废了八牛三虎之力呢……

问题四的解决过程：
     当我开始改代码时，定义一个动作，然后可以生成N个动作。假设N个动作产生了N个结果，你要对这结果进行处理时，你会发现这N个结果都不能被识别:

网页上有个表格，是往数据库里加数据的。
两个表格显示在同一个页面上，左边为父表，右边为子表。
点击左表，右表显示其子项目。
结构如下： 
A
├─1
├─2
├─3
└─4
B
├─1
├─2
├─3
└─4
                    ……
思想很清晰：
添加一个父项A、选中此父项A、对其添加子项1、2、3、4
添加一个父项B、选中此父项B、对其添加子项1、2、3、4  ……

代码也很简单：
dim M          '定义父项数
dim N          '定义每个父项包含的子项数

For i=1 to M
      Call 添加父项( i )       
      选中父项( i )              '问题就出在这里 
   For j=1 to bwfl step 1
       Call 添加子项( j )
    Next       
Next

现在问题出来了，思路应该没有问题（除非这方法真的行不通），循环也是顺着思想来的。

问题是，无法实现选中的父项（最多识别到一个）。
由于此循环可以在录制过程进行，如果不改变变量名称，循环可且只可以成功运行一次。问题是这个名称都是从DataTable里获取的。
因为，在运行过程中生成的项目没有加到对象库中，无法被识别。

   这个问题最后是从思想上解决的。答案是我做的是功能测试，为什么不先加父项，检查父项的功能是否正常，然后再去测子项的功能。不去改变名字，因为那没有必要。核心答案“功能测试、测试功能”。即对测试工具首先需要有正确的认识。
   当然，这个问题可以用代码去实现，但那需要有一定的编程功底且耗时，可维护性不一定好。有需要的朋友可以去试一下，然后把你的经验也共享一下。  *^_^*

问题五，是对QTP很大的一个扩充。 
    对于QTP调用外部DLL的功能，由于我的编程功底不够，没有相关人士配合我，我只能望之垂涎了！
    如果能调用外部DLL的话，QTP的功能就可以变得很强大。自己写的程序，自己编一些过程用QTP进行测试，我想“后果很严重”  。真想有一次给我尝试的机会……

问题六，解决办法有4个：
    1、测试的时候，让程序员把这块限制去掉，免去验证这关。
    2、让程序员提供一个万能验证码，测试可以绕过这一关。
    3、请程序员提供识别的方法，从获取的图片读出验证数据，再传给QTP。
    4、进行位图检查，将验证码分段进行图像验证。
    实际上，验证码的目的就是防止用程序灌水或机器录入信息。所以有点为难我们测试了。
方法1，如果程序已在发布并有客户使用，危险性是可想而知的。方法2虽然可以解决验证这一关，但跳过了输入码与验证码一致性问题。方法3就需要程序员配合了，可能就需要调用DLL了。方法4却将图像分段，把获取的图像和已经的图像进行比对，比对通过取对应的值；这个在数字验证会好做一点，因为最多就四个图像的比对。
    关于网上的汉字验证码，那块的测试我就不知道他们是怎么做的了。真想了解一下！ 

VB里的Select语句的格式是这样的：

Select Case <变量名>

Case <情况1>
  ……
Case <情况2>
  ……
Case <情况3>
  ……
  ……
  ……
Case Else
  ……

End Select

例如：

Select Case a%

Case 1
  Print “a=1”
Case 2
  Print “a=2”
Case Else
  Print “a does not equal to 1 or 2.”

End Select

五、循环语句

For <循环变量>=<初赋值> To <终值> [Step <步长>]

……
……

Next <循环变量>

在默认情况下，Step被设为“1”，可以省略，Step也可以设为负值，例如：

Dim a=0

For I=1 To 10

a=a+I

Next I

这是一个最简单的累加器的例子，把1到10累加在一起，然后赋值给“a”这样的效果和上面是一样的，只不过是倒着加罢了，请看：

Dim a=0

For I=10 To 1 Step –1

a=a+I

Next I

百合姐姐：你好！

我也是从你那篇测试入门心得受到鼓舞，于是在几个月前就开始学习测试了，只不过我现在遇到一些问题还要请百合姐姐给我一点建议；

不好意思xiaomaogege，最近比较忙，我今天才看到这个留言，一看都过去二十多天了，你的空间进不去，所以我就在这里回复你的问题了，首先谢谢你对我的信任，我的回答可能不是最好，只代表我个人的想法，希望你看看就好了，不要影响自己的判断，从你的留言中看得出你己经了解了很多测试方面的知识，应该是下了很大功夫了，但只是因为没有走出去工作所以才对工作学习充满迷茫，其实这个没有关系的，我当年也是这个样子，要知道我当时的水平还不如你呢，现在也可能没有你懂的多，所以你要相信自己大胆去找工作吧，你的问题太多我就一个个回答咯

1，我也和姐姐一样没有钱去培训；只有靠自学。我觉得自己好像没有进步很多；我想问你以前自学的一些学习经验，按照什么样的进度；照着什么东西慢慢学习的；

-----其实我想说你比我幸运多了，因为现在论坛上有很多引导新手入门的贴子，不像我哪个时候盲目却没有人引导，我完全是糊里糊涂的去论坛看贴的，下了一大堆资料，其实也没有完全看完，因为东西都差不多的，起初怎么看都看不懂，但是后来看的多了就有熟悉是哪个词了，要说真正理解了它还是参加工作之后，在工作中体验到的，你也没有必要完全去扣每个专业术语的意思，说实话到现在还有很多专业术语我见都没有见过呢，这些只有在工作工学习了

2，我觉得学的东西太多了，我好像失去方向，例如手机测试，游戏测试，Web测试，很多，
你觉得那些东西是每个测试员必须学到的；

------这个只能说你了解的关于测试方面的东西太多了，呵呵，我找工作之前可不知道测试分这么多种，只知道软件测试，哪时候比较傻只在新手区肯，没有去其它区，其实我觉得你没有找到工作之前最好不要锁定方向，因为哪样会让你的求职范围缩小，而你例举的都是以后测试的方向，建议你先去理解软件测试的理论，只要待遇工作机会差不多就先干，边干边去培养你以后要发展的方向，这只是我个人的理解哦。

3，我编程能力不行，还没有学习面向对象的语言；所以单元测试，集成那方面没有学好；那些驱动函数，桩函数都不知道编写；是否这些东西现在不学了，以后再去学习，我看到很多地方说测试员不需要做单元测试，和集成测试；

------至于你的编程能力没有关系的，因为单无测试集成测试等你提到的这些属于性能测试方面，而刚开始一般都是做功能测试，在工作中再去学习性能测试吧，没关系的，大家都是在工作中边学习边工作的。现在你不要被这些吓到，这些都需要时间

4，学到什么样的程度就可以去应聘找工作了；（我想这个问题有点问得不好，但我还是希望你能给点建议）

------学到什么程度去找工作合适，我觉得这个不是我们自己来定的，需要用人单位来定，哪怕你刚刚学，但是哪个公司愿意给你机会，这时你就要把握机会了，哪怕你觉得你精通了所有，而公司没有用你，其实也并不代表你程度不好。怎么说呢，公司也是在找适合哪个职位的员工。所以这个问题吗，呵呵，你工作找起来吧，哪怕失败也会有面试经历，从面试中也会学到很多的。

5，可以什么都不学，就来学习性能测试，和功能测试？（本人），学习这2个需要一些什么基础知识；
------你所谓的什么都不学怎么来讲呢？呵呵，一切从基础学起吧，一般都是从功能到性能的，加油吧。

近几个月，每当我打开电脑，刷下51就会有人加我好友，还留言说，自己是新人，知道我是自学的，想向我讨下学习方法，以及学习资料，让我帮帮他们，其实我每当看到这种消息，就有两种感觉，其一，我谢谢大家对我的信任；其二，我有点惭愧。我因为前几天忙，所以在回信都说等我忙完给你们找下资料，现在我不一一回信了，所以才在这里发个贴，希望见谅。
一年前的今天我也和你们一样，这样迷茫，也是在测试的门外蹲着，疯狂的找测试群，然后眼巴巴的盯着群里滚动的汉字，他们在交流，他们在教与学，我因为什么都不懂，所以不敢发问。终于有一天敢问了，就在里面发个贴，求教一下，当然有热心的朋友给我指点，可是哪也不过是说一说方向，真正的东西还是很让我发愁，因为听人一说简单，可自己不会真难，再问又不好意思问了，可是路还要走下去，于是就利用百度去搜相关的关键字。最后，我就埋在51新手区里挖坑。就这样从08年挖到07年再挖到06年。功夫不负有心人，终地挖了很多宝贝。存在自己的电脑里慢慢看，因为没有头绪，没有分前序后序，所以很多东西看起来真的很吃力。起初很浮躁，看不懂。我也想过去参加个培训，可是培训也是师傅领进门修行在个人，这还不是我放弃培训的主要原因，真正的让我放弃培训的还是哪一笔昂贵的培训费。
还好我自学能力比较强，能控制好自己的时间，让自己就这样坚持下来了。后来求职因为没有经验，所以网投的简历都沉入大海。两个星期过去了，我有点绝望，想着把求职方向改了吧。可是还是不死心，毕竟也是花了时间去学习了。我和你们一样悄悄的加坛友为好友，又悄悄的向他询求帮助，说了自己的苦恼，呵呵，哪个人是‘狗蜡笔粉丝’，在这里还是要感谢当初他对我的鼓励呢。要说去靠运气找工作是不行的，主要还是要自己有准备，要真说运气，可能我是比你们运气好点，哪就是我在经济危机之前找到了工作。而你们面临着经济危机，让你们更难加入这个行例，不过这不可怕的，真正可怕的是，你被经济危机吓倒了，现在你们要静下心来去学习，还好你们都还没有毕业，到毕业还有几个月的时间，完全够你们去了解理论知识的。所以我想说如果你们真的下决心要去做测试，把它做为了你们职业规划的方向了，哪么你们利用现在到毕业这一段时间，把心放平静了，去看看理论吧，等你们毕业后去找找工作，不要要求太高，真想进入这个行业，而又没有经验的话，哪么就把自己看低一点，不要去计较工资待遇，我想再经济危机，企业还是需要用人的，只要你去找，只要你不要去计较其它的，能有一个进入测试的平台，哪么机会是一定有的。
我很惭愧的是，你们让我帮助的时候，我自身没有技能上的提高，不能用在技术上帮助你们。因为我也是一个测试行业摸索大军中的其中一员。但是既然你们找到了我，我如果不回信息，或者只说一句，“对不起，我也不会帮不了你们”的话，我想或许会有人说我轻高，说我自私，自己会却不愿意传教，可是如果我真的去教你们，自己也连半两都不到的水平，在前辈面前是买弄啊。可是一年前我在测试边缘挣扎的场景依然在现，所以我很能理解你们现在的处境和心情。对于未入门的你们，我知道你们现在需要的不是高深的技能，而是如何入门，所以我在今天上午做完工作后，在论子里又开始第二次“盗墓”。意义不一样的是，一年前挖宝是为了自己的，如今天再次盗墓是为了你们。为什么这次我说是‘盗墓“呢，哪是因为我知道论坛里有很多宝，都是前辈们辛辛苦苦为我们积累的，我们一定要利用它们为自己创造价值。我盗来借花献佛啦，好了我废话不说了，下面贴出我总结出来了的一些贴子，里面都是带有附件的，大家慢慢看吧，我想等你们看完了，对测试理论也掌握了，到哪个时候信心十足的去找工作吧。
第一阶段：
软件测试职业道德和工作责任
http://bbs.51testing.com/viewthr ... 26amp%3Btypeid%3D14
软件测试新手学习宝典
http://bbs.51testing.com/viewthr ... 26amp%3Btypeid%3D14
软件性能测试从这里开始V1.0.0.0
http://bbs.51testing.com/thread-78735-1-1.html
软件测试新手入门资料
http://bbs.51testing.com/thread-90137-1-20.html
软件测试-适合新手学习
http://www.qiannao.com/space/show/yiduspace/上传分享/2009/2/21/软件测试.chm/.page
测试员 培训 入门教材
http://bbs.51testing.com/thread-77775-1-15.html
测试员培训速成教材
http://bbs.51testing.com/thread-93455-1-8.html
经典《测试指南》
http://bbs.51testing.com/viewthr ... 26amp%3Btypeid%3D14
软件测试技术培训资料
http://bbs.51testing.com/thread-17293-1-1.html
软件测试基础知识培训PDF
http://bbs.51testing.com/thread-2160-1-1.html
测试的基本概念
http://bbs.51testing.com/thread-88032-1-2.html
软件测试基本方法
http://bbs.51testing.com/thread-13775-1-3.html
新手入门之测试工作流程（PPT）
http://bbs.51testing.com/viewthr ... 26amp%3Btypeid%3D14
第二阶段
软件测试技术教程下载
http://bbs.51testing.com/thread-35946-1-1.html
测试书籍
http://bbs.51testing.com/thread-130536-1-6.html
软件测试书籍整理
http://bbs.51testing.com/thread-30935-1-7.html
软件测试(原书中文第二版)PDF版
http://bbs.51testing.com/thread-140368-1-9.html
http://bbs.51testing.com/thread-125195-1-39.html
软件测试技术-电子版
http://bbs.51testing.com/thread-91360-1-10.html
[软件测试][(美)Ron Patton中文电子版!
http://bbs.51testing.com/thread-110047-1-11.html
Jorgensen《软件测试》原书第2版中文
http://bbs.51testing.com/thread-102776-1-13.html
测试用例教程
http://bbs.51testing.com/thread-89823-1-16.html
软件测试综合资料库
http://bbs.51testing.com/thread-79154-1-20.html
《软件工程思想》
http://bbs.51testing.com/thread-136491-1-24.html
软件开发的科学和艺术之软件测试
http://bbs.51testing.com/thread-137737-1-29.html
软件测试的艺术
http://www.51testing.com/html/200710/n64420.html
软件测试经验与教训
http://bbs.51testing.com/thread-117962-1-1.html
中文版 <软件测试自动化>
http://bbs.51testing.com/viewthr ... 26amp%3Btypeid%3D14

软件测试的详细流程！
http://bbs.51testing.com/viewthr ... 26amp%3Btypeid%3D14
自制的软件测试方面的一个电子书
http://bbs.51testing.com/viewthr ... 26amp%3Btypeid%3D14

软件测试方面的书籍大合集下载
http://bbs.51testing.com/viewthr ... 26amp%3Btypeid%3D14