接口测试之——soapui学习(1)

      WebService

它是一种构建应用程序的普遍模型,可以在任何支持网络通信的操作系统中实施运行;

它是一种新的web应用程序分支,是自包含、自描述、模块 化的应用,可以发布、定位、通过web调用。

Web Service是一个应用组件,它逻辑性的为其他应用程序提供数据与服务.各应用程序通过网络协议和规定的一些标准数据格式(Http,XML,Soap)来访问Web Service,通过Web Service内部执行得到所需结果.

Web Service可以执行从简单的请求到复杂商务处理的任何功能。一旦部署以后,其他Web Service应用程序可以发现并调用它部署的服务。

——————

在构建和使用Web Service时,主要用到以下几个关键的技术和规则:
1.XML:描述数据的标准方法.
2.SOAP:表示信息交换的协议.
3.WSDL:Web服务描述语言.
4.UDDI通用描述、发现与集成,它是一种独立于平台的,基于XML语言的用于在互联网上描述商务的协议。

FONT style=”BACKGROUND-COLOR: rgb(0,255,0)”>http://www.webxml.com.cn/zh_cn/index.aspx   这个网站中有不少免费的WebService可用

——————我个人觉得下面的这个理解起来更容易些,甚至我都觉得他有点想API,只是放到web中了而已————————-

1,什么是 Web Service?
Web Service 就是一个网络组件(一个可以通过网络访问的程序)。
它有一个或多个端口(Port),这些端口用于接收客户端的请求,并返回响应
请求和响应的 都是一种基于XML的消息。 不过这种消息遵循特定的格式(SOAP )。

2,怎样调用 Web Service?
   可能这样说不太准确,应该是“怎样调用Web Service中定义的操作 ”
每个Web Service 都有一个描述文件(WSDL ),
它描述 一个 Web Service 的如下方面:
(1)服务的端口(接收SOAP消息的端口)
(2)服务提供的操作
(3)操作的输入输出格式的定义(通过XMLSchema 定义输入输出格式)
有了Web Service 的描述文件(WSDL ),我们就知道怎样调用这个Web Service 中定义的操作了。
(1)通过服务提供的操作找到你想调用的操作
(2)找到这个操作的输入格式的定义(XMLSchema ),按照这种输入格式构造一个SOAP消息
(3)将这个SOAP消息发送到服务的指定端口
(4)准备接收一个从Web Service服务器返回的 SOAP 响应吧 !

3,Web Service服务器
   一个Web Service服务器,本质上和一个Web服务器是相同的。
它主要做下面这些事:
–> 监听网络端口(监听服务端口)
–> 接收客户端请求(接收SOAP请求)
–> 解析客户端请求(解析SOAP消息,将SOAP消息转换为数据对象)
–> 调用业务逻辑 (调用Web Service实现类的特定操作,参数是由SOAP消息转换而来的数据对象)
–> 生成响应 (将返回值转换为SOAP消息)
–> 返回响应 (返回SOAP响应)

 

=================================================================================

XML

什么是 XML?

·         XML 指可扩展标记语言(EXtensible Markup Language)

·         XML 是一种标记语言,很类似 HTML

·         XML 的设计宗旨是传输数据,而非显示数据

·         XML 标签没有被预定义。您需要自行定义标签。

·         XML 被设计为具有自我描述性。

·         XML 是 W3C 的推荐标准

XML 与 HTML 的主要差异

XML 不是 HTML 的替代。

XML 和 HTML 为不同的目的而设计:

XML 被设计为传输和存储数据,其焦点是数据的内容。

HTML 被设计用来显示数据,其焦点是数据的外观。

HTML 旨在显示信息,而 XML 旨在传输信息。

没有任何行为的 XML。XML 是不作为的。也许这有点难以理解,但是 XML 不会做任何事情。XML 被设计用来结构化、存储以及传输信息。

下面是 John 写给 George 的便签,存储为 XML:

        <note><to>George</to>

<from>John</from>

<heading>Reminder</heading>

<body>Don’t forget the meeting!</body>

</note>

       这个标签有标题以及留言。它也包含了发送者和接受者的信息。但是,这个 XML 文档仍然没有做任何事情。它仅仅是包装在 XML 标签中的纯粹的信息。我们需要编写软件或者程序,才能传送、接收和显示出这个文档。

XML 仅仅是纯文本

XML 没什么特别的。它仅仅是纯文本而已。有能力处理纯文本的软件都可以处理 XML。

不过,能够读懂 XML 的应用程序可以有针对性地处理 XML 的标签。标签的功能性意义依赖于应用程序的特性。

通过 XML 您可以发明自己的标签

上例中的标签没有在任何 XML 标准中定义过(比如 <to> 和 <from>)。这些标签是由文档的创作者发明的。这是因为 XML 没有预定义的标签。在 HTML 中使用的标签(以及 HTML 的结构)是预定义的。HTML 文档只使用在 HTML 标准中定义过的标签(比如 <p> 、<h1> 等等)。XML 允许创作者定义自己的标签和自己的文档结构。

XML 不是对 HTML 的替代

XML 是对 HTML 的补充。XML 不是对 HTML 的替代,理解这一点很重要。在大多数 web 应用程序中,XML 用于传输数据,而 HTML 用于格式化并显示数据。

XML 应用于 web 开发的许多方面,常用于简化数据的存储和共享。

XML 把数据从 HTML 分离

如果你需要在 HTML 文档中显示动态数据,那么每当数据改变时将花费大量的时间来编辑 HTML。通过 XML,数据能够存储在独立的 XML 文件中。这样你就可以专注于使用 HTML 进行布局和显示,并确保修改底层数据不再需要对 HTML 进行任何的改变。通过使用几行 JavaScript,你就可以读取一个外部 XML 文件,然后更新 HTML 中的数据内容。

XML 简化数据共享

在真实的世界中,计算机系统和数据使用不兼容的格式来存储数据。XML 数据以纯文本格式进行存储,因此提供了一种独立于软件和硬件的数据存储方法。这让创建不同应用程序可以共享的数据变得更加容易。

XML 简化数据传输

通过 XML,可以在不兼容的系统之间轻松地交换数据。对开发人员来说,其中一项最费时的挑战一直是在因特网上的不兼容系统之间交换数据。由于可以通过各种不兼容的应用程序来读取数据,以 XML 交换数据降低了这种复杂性。

XML 简化平台的变更

升级到新的系统(硬件或软件平台),总是非常费时的。必须转换大量的数据,不兼容的数据经常会丢失。XML 数据以文本格式存储。这使得 XML 在不损失数据的情况下,更容易扩展或升级到新的操作系统、新应用程序或新的浏览器。

XML 使您的数据更有用

由于 XML 独立于硬件、软件以及应用程序,XML 使您的数据更可用,也更有用。不同的应用程序都能够访问您的数据,不仅仅在 HTML 页中,也可以从 XML 数据源中进行访问。通过 XML,您的数据可供各种阅读设备使用(手持的计算机、语音设备、新闻阅读器等),还可以供盲人或其他残障人士使用。

XML 用于创建新的 Internet 语言

很多新的 Internet 语言是通过 XML 创建的:

其中的例子包括:

·  XHTML – 最新的 HTML 版本

·  WSDL – 用于描述可用的 web service

·  WAP 和 WML – 用于手持设备的标记语言

·  RSS – 用于 RSS feed 的语言

·  RDF 和 OWL – 用于描述资源和本体

·  SMIL – 用于描述针针对 web 的多媒体

假如开发人员都是理性的

假如他们都是理性的,就让未来的应用程序使用 XML 来交换数据吧。

未来也许会出现某种字处理软件、电子表格程序以及数据库,它们可以使用纯XML

=================================================================================

WSDL          什么是 WSDL?

·  WSDL 指网络服务描述语言

·  WSDL 使用 XML 编写

·  WSDL 是一种 XML 文档

·  WSDL 用于描述网络服务

·  WSDL 也可用于定位网络服务

·  WSDL 还不是 W3C 标准

WSDL 可描述网络服务(Web Services)

WSDL 指网络服务描述语言 (Web Services Description Language)。

WSDL 是一种使用 XML 编写的文档。这种文档可描述某个 Web service。它可规定服务的位置,以及此服务提供的操作(或方法)。

WSDL 文档仅仅是一个简单的 XML 文档。

它包含一系列描述某个 web service 的定义。

WSDL 文档结构

WSDL 文档是利用这些主要的元素来描述某个 web service 的:

元素 定义
<portType> web service 执行的操作
<message> web service 使用的消息
<types> web service 使用的数据类型
<binding> web service 使用的通信协议

一个 WSDL 文档的主要结构是类似这样的:

 <definitions>
<types>
definition of types……..
</types>

<message>
definition of a message….
</message>

<portType>
definition of a port…….
</portType>

<binding>
   definition of a binding….
</binding>

</definitions>

   PS:实际上以上的结构,可以用浏览器打开一个具体的webservice来看,比如以下查询手机归属地的wsdl格式的webservice

http://fy.webxml.com.cn/webservices/EnglishChinese.asmx?wsdl


WSDL 文档可包含其它的元素,比如 extension 元素,以及一个 service 元素,此元素可把若干个 web services 的定义组合在一个单一的 WSDL 文档中。

WSDL 端口

<portType> 元素是最重要的 WSDL 元素。 它可描述一个 web service、可被执行的操作,以及相关的消息。 可以把 <portType> 元素比作传统编程语言中的一个函数库(或一个模块、或一个类)。

WSDL 消息

<message> 元素定义一个操作的数据元素。 每个消息均由一个或多个部件组成。可以把这些部件比作传统编程语言中一个函数调用的参数。

WSDL types

<types> 元素定义 web service 使用的数据类型。 为了最大程度的平台中立性,WSDL 使用 XML Schema 语法来定义数据类型。

WSDL Bindings

<binding> 元素为每个端口定义消息格式和协议细节。

 

WSDL 实例

这是某个 WSDL 文档的简化的片段:

 <message name=”getTermRequest”>
<part name=”term” type=”xs:string”/>
</message>

<message name=”getTermResponse”>
<part name=”value” type=”xs:string”/>
</message>

<portType name=”glossaryTerms”>
<operation name=”getTerm”>
<input message=”getTermRequest”/>
<output message=”getTermResponse”/>
</operation>
</portType>

       在这个例子中,<portType> 元素把 “glossaryTerms” 定义为某个端口的名称,把 “getTerm” 定义为某个操作的名称。

操作 “getTerm” 拥有一个名为 “getTermRequest” 的输入消息,以及一个名为 “getTermResponse” 的输出消息。

<message> 元素可定义每个消息的部件,以及相关联的数据类型。

对比传统的编程,glossaryTerms 是一个函数库,而 “getTerm” 是带有输入参数 “getTermRequest” 和返回参数 getTermResponse 的一个函数。

软件测试之黑盒——等价类划分

是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法.

1)划分等价类:等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能.

无效等价类:与有效等价类的定义恰巧相反.

设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性.

2)划分等价类的方法:下面给出六条确定等价类的原则.

①在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类.

②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类.

③在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类.

④在规定了输入数据的一组值(假定n个),并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类.

⑤在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则).

⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类.

3)设计测试用例:在确立了等价类后,可建立等价类表,列出所有划分出的等价类:

输入条件有效等价类无效等价类

然后从划分出的等价类中按以下三个原则设计测试用例:

①为每一个等价类规定一个唯一的编号.

②设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步.直到所有的有效等价类都被覆盖为止.

③设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步.直到所有的无效等价类都被覆盖为止.

软件测试之黑盒——错误推测法

          错误推测法

基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法.

错误推测方法的基本思想:列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例.例如,在单元测试时曾列出的许多在模块中常见的错误.以前产品测试中曾经发现的错误等,这些就是经验的总结.还有,输入数据和输出数据为0的情况.输入表格为空格或输入表格只有一行.这些都是容易发生错误的情况.可选择这些情况下的例子作为测试用例.

因果图方法

前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系,相互组合等.考虑输入条件之间的相互组合,可能会产生一些新的情况.但要检查输入条件的组合不是一件容易的事情,即使把所有输入条件划分成等价类,他们之间的组合情况也相当多.因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例.这就需要利用因果图(逻辑模型).

因果图方法最终生成的就是判定表.它适合于检查程序输入条件的各种组合情况.

利用因果图生成测试用例的基本步骤:

(1)分析软件规格说明描述中,那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件),并给每个原因和结果赋予一个标识符.

(2)分析软件规格说明描述中的语义.找出原因与结果之间,原因与原因之间对应的关系.根据这些关系,画出因果图.

(3)由于语法或环境限制,有些原因与原因之间,原因与结果之间的组合情况不不可能出现.为表明这些特殊情况,在因果图上用一些记号表明约束或限制条件.

(4)把因果图转换为判定表.

(5)把判定表的每一列拿出来作为依据,设计测试用例.

从因果图生成的测试用例(局部,组合关系下的)包括了所有输入数据的取TRUE与取FALSE的情况,构成的测试用例数目达到最少,且测试用例数目随输入数据数目的增加而线性地增加.

前面因果图方法中已经用到了判定表.判定表(Decision Table)是分析和表达多逻辑条件下执行不同操作的情况下的工具.在程序设计发展的初期,判定表就已被当作编写程序的辅助工具了.由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确.

判定表通常由四个部分组成.

条件桩(Condition Stub):列出了问题得所有条件.通常认为列出得条件的次序无关紧要.

动作桩(Action Stub):列出了问题规定可能采取的操作.这些操作的排列顺序没有约束.

条件项(Condition Entry):列出针对它左列条件的取值.在所有可能情况下的真假值.

动作项(Action Entry):列出在条件项的各种取值情况下应该采取的动作.

规则:任何一个条件组合的特定取值及其相应要执行的操作.在判定表中贯穿条件项和动作项的一列就是一条规则.显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列.

判定表的建立步骤:(根据软件规格说明)

①确定规则的个数.假如有n个条件.每个条件有两个取值(0,1),故有种规则.

②列出所有的条件桩和动作桩.

③填入条件项.

④填入动作项.等到初始判定表.

⑤简化.合并相似规则(相同动作).

B. Beizer指出了适合使用判定表设计测试用例的条件:

①规格说明以判定表形式给出,或很容易转换成判定表.

②条件的排列顺序不会也不影响执行哪些操作.

③规则的排列顺序不会也不影响执行哪些操作.

④每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则.

⑤如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要.

软件测试之黑盒——黑盒测试之边界值分析法

边界值分析方法是对等价类划分方法的补充.

(1)边界值分析方法的考虑:

长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.

使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

(2)基于边界值分析方法选择测试用例的原则:

1)如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据.

2)如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据.

3)根据规格说明的每个输出条件,使用前面的原则1).

4)根据规格说明的每个输出条件,应用前面的原则2).

5)如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例.

6)如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例.

7)分析规格说明,找出其它可能的边界条件.

测试用例设计的两个阶段


一、测试用例分析阶段

测试用例设计的基础文档是需求文档,如果测试人员能拿到一份完整的准确的需求文档,那么对测试人员来说,工作量可以减轻大半,工作效果会大幅提高。但是我们在需求分析阶段,即便是在需求评审之后,我们拿到的需求文档,仍然是存在一些疑义的或者是分析不透,表达不清的一些需求文档。这样的时候,测试人员是否有自己的分析方法,显得尤为重要。

测试人员对付需求文档,从操作策略上来说,可以从以下两点出发:

(一)、对于需求规格全面、完整的需求文档来说,我们可以采取“切割策略”,把需求按一定的粒度进行分解,来编写测试用例。

(二)、对于简单不全面、需求规格含糊的需求文档,我们可以采取的策略:“联想策略”。这点还是主要来自工作经验及对该行业的理解,把一些含糊的内容补充起来。

在参与需求文档阅读的过程中,我们还可以采用一些小方法,把需求吃透。例如:

1、在参与需求阅读的过程中,我们可以把需求中的一些边界或者异常的情况列出来,这些往往是以后bug的多发地带。

2、对于需求文档中的一些隐式缺陷,我们需要补充清楚质量属性,例如一些安全性、性能、UI等的一些质量属性内容,我们需要补充清楚。

3、对需求文档的阅读,我们还可以采用一些工具:思维导图工具及UI界面设计工具,把图给画出来,有助于我们理解需求,找到测试点。例如思维导图工具,通过名词+动词的方法,可以把测试数据和操作动作列出来,有利于理清测试的要点。

通过以上的一些策略和方法,我们大致上可以把需求测试分析做的比较到位了。

测试人员对需求文档分析后,接下去还需要对设计文档进行分析,大部分的测试人员,不是太注重开发组的这份设计文档,觉得与己无关,其实,理解设计文档,有利于降低我们的测试规模,降低劳动负荷。一般来说缺陷会与内部结构映射,如果你了解了代码的结构,一般来说,我们都可以找到缺陷出现的真正原因了。这里有一种工具,可以帮助我们进行这方面的工作,就是UML的反向工程获得设计模型,该工具网上大家也可以找到。

  二、测试用例设计阶段

通过以上对需求文档和设计文档的分析,下面我们来浅谈下测试用例的设计,测试用例一般由三部分内容组成:步骤、数据、标准。步骤一般与需求规格说明书相对应,对于某些共享步骤,可以进行参数化,或借用工具进行管理,步骤的描述应该无二义性。测试标准,主要为预期值与结果值的对比方式。

对于测试数据的设计,这里我们讲解以下几种方法:

1、最原始的方法:排列组合。通过排列组合,把所有的数据都遍历过,这样的穷举的方法,尽可能的把系统都测试到位。但数据庞大,这样穷举的方法,会让测试陷入困境。

2、边界值和等价类的方法。通过边界值和等价类划分,可以大大的缩小测试范围,提高了测试效率。在任何情况下都必须使用边界值分析方法,经验表明用这种方法设计出测试用例发现程序错误的能力最强。必要时用等价类划分方法补充一些测试用例。

3、因果图表和决策表法。如果程序的功能说明中含有输入条件的组合情况,则一开始就可选用因果图法。因果图分析法,是为了解决边界值分析和等价划分的一个弱点:未对输入条件的组合进行分析。而因果图恰恰有助于用一个系统的方法选择出此类高效的测试用例集,并且可以指出规格说明的不完整性和不明确之处。步骤如下:

1)将规格说明分解为可执行的片段;

2)确定规格说明中的因果关系;

3)分析规格说明的语义内容,并将其转换为连接因果关系的布尔图,即:因果图;

4)给图加上注解符号,说明由于语法或环境的限制而不能联系起来的“因”和“果”;

5)经过仔细地跟踪图中的状态变化情况,将因果图转换成一个有限项的判定表;

6)将判定表中的列转换成测试用例。

4、“猜”技术。为特殊测试点准备测试数据。

看完了上面的测试用例设计方法,我们来看下测试用例的设计步骤:

1)构造根据设计规格得出的基本功能测试用例;

2)边界值测试用例;

3)状态转换测试用例;

4)错误猜测测试用例;

5)异常测试用例;

6)性能测试用例;

7)压力测试用例。

以上我主要讲解了一些平时比较常用的测试用例设计方法,如果更细化,还可以找出更多的测试用例设计方法。其实,这些方法和设计步骤通过我们的加工,都融入到了测试用例中去了,所以测试用例

测试之用例设计

测试设计中需要考虑的22种测试类型

黑盒测试:不基于内部设计和代码的任何知识,而是基于需求和功能性。

白盒测试:基于一个应用代码的内部逻辑知识,测试是基于覆盖全部代码、分支、路径、条件。

单元测试:最微小规模的测试;以测试某个功能或代码块。典型地由程序员而非测试员来做,因为它需要知道内部程序设计和编码的细节知识。这个工作不容易作好,除非应用系统有一个设计很好的体系结构; 还可能需要开发测试驱动器模块或测试套具。

累积综合测试:当一个新功能增加后,对应用系统所做的连续测试。它要求应用系统的不同形态的功能能够足够独立以可以在全部系统完成前能分别工作,或当需要时那些测试驱动器已被开发出来; 这种测试可由程序员或测试员来做。

集成测试:一个应用系统的各个部件的联合测试,以决定他们能否在一起共同工作。部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。这种类型的测试尤其与客户服务器和分布式系统有关。

功能测试:用于测试应用系统的功能需求的黑盒测试方法。这类测试应由测试员做,这并不意味着程序员在发布前不必检查他们的代码能否工作(自然他能用于测试的各个阶段)。

系统测试:基于系统整体需求说明书的黑盒类测试;应覆盖系统所有联合的部件。

端到端测试:类似于系统测试;测试级的“宏大”的端点;涉及整个应用系统环境在一个现实世界使用时的模拟情形的所有测试。例如与数据库对话,用网络通讯,或与外部硬件、应用系统或适当的系统对话。

健全测试:典型地是指一个初始化的测试工作,以决定一个新的软件版本测试是否足以执行下一步大的测试努力。例如,如果一个新版软件每5分钟与系统冲突,使系统陷于泥潭,说明该软件不够“健全”,目前不具备进一步测试的条件。

衰竭测试:软件或环境的修复或更正后的“再测试”。可能很难确定需要多少遍再次测试。尤其在接近开发周期结束时。自动测试工具对这类测试尤其有用。

接受测试:基于客户或最终用户的规格书的最终测试,或基于用户一段时间的使用后,看软件是否满足客户要求。

负载测试:测试一个应用在重负荷下的表现,例如测试一个 Web 站点在大量的负荷下,何时系统的响应会退化或失败。

强迫测试:在交替进行负荷和性能测试时常用的术语。也用于描述象在异乎寻常的重载下的系统功能测试之类的测试,如某个动作或输入大量的重复,大量数据的输入,对一个数据库系统大量的复杂查询等。

性能测试:在交替进行负荷和强迫测试时常用的术语。理想的“性能测试”(和其他类型的测试)应在需求文档或质量保证、测试计划中定义。

可用性测试:对“用户友好性”的测试。显然这是主观的,且将取决于目标最终用户或客户。用户面谈、调查、用户对话的录象和其他一些技术都可使用。程序员和测试员通常都不宜作可用性测试员。

安装/卸载测试:对软件的全部、部分或升级安装/卸载处理过程的测试。

恢复测试:测试一个系统从如下灾难中能否很好地恢复,如遇到系统崩溃、硬件损坏或其他灾难性问题。

安全测试:测试系统在防止非授权的内部或外部用户的访问或故意破坏等情况时怎么样。这可能需要复杂的测试技术。

兼容测试:测试软件在一个特定的硬件/软件/操作系统/网络等环境下的性能如何。

比较测试:与竞争伙伴的产品的比较测试,如软件的弱点、优点或实力。

Alpha 测试:在系统开发接近完成时对应用系统的测试;测试后,仍然会有少量的设计变更。这种测试一般由最终用户或其他人员员完成,不能由程序员或测试员完成。

Beta 测试:当开发和测试根本完成时所做的测试,而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员员完成,不能由程序员或测试员完成。

登陆测试用例设计

输入 预期结果

键盘或软键盘输入 用户名正确显示输入用户名
输入合法密码 密码显示为“*”
输入含中文或非法字符密码 不能输入中文或非法字符密码
拷贝密码 不能拷贝密码,拷贝出来粘贴后页必须是乱码
输入错误的验证码 验证码错误
正确用户名、密码,点击登录 登陆成功
正确用户名、密码,用Tab键切换,Enter键登录 Tab正常切换,Enter正常登录,正常跳转
正确用户名(不区分大小写),正确密码用户名不区分大小写 登陆成功
用户名超出规定长度,正确密码 超出部分不能输入
错误用户名,正确密码 提示用户名错误(若为了防止恶意猜测16用户名和密码,可以显示为用户名或密码错误)
正确用户名,密码超出规定长度 超出部分不能输入
正确用户名,错误密码 提示密码错误(若为了防止恶意猜测用19户名和密码,可以显示为用户名或密码错误)
错误用户名,错误密码 提示用户名错误或密码错误
用户名为空或输入空格,正确的密码 提示输入用户名
正确用户名,密码为空或输入空格 提示输入密码
验证码为空 提示输入验证码
通过已经登陆的账号单点登录其他系统 注意单点登陆时登陆连接中的用户名或者密码是否是已经加密
登陆用户输入密码的错误次数限制 密码错误*次后,锁定账户,30分钟内禁止登陆

测试用例设计——用户注册与密码修改

一.用户注册

只从用户名和密码角度写了几个要考虑的测试点,如果需求中明确规定了安全问题,Email,出生日期,地址,性别等等一系列的格式和字符要求,那就都要写用例测了~

以等价类划分和边界值法来分析
1.填写符合要求的数据注册: 用户名字和密码都为最大长度 (边界值分析,取上点)
2.填写符合要求的数据注册 :用户名字和密码都为最小长度 (边界值分析,取上点)
3.填写符合要求的数据注册:用户名字和密码都是非最大和最小长度的数据(边界值分析,取内点)
4.必填项分别为空注册
5.用户名长度大于要求注册1位(边界值分析,取离点)
6.用户名长度小于要求注册1位(边界值分析,取离点)
7.密码长度大于要求注册1位(边界值分析,取离点)
8.密码长度小于要求注册1位(边界值分析,取离点)
9.用户名是不符合要求的字符注册(这个可以划分几个无效的等价类,一般写一两个就行了,如含有空格,#等,看需求是否允许吧~)
10.密码是不符合要求的字符注册(这个可以划分几个无效的等价类,一般写一两个就行了)
11.两次输入密码不一致(如果注册时候要输入两次密码,那么这个是必须的)
12.重新注册存在的用户
13.改变存在的用户的用户名和密码的大小写,来注册。(有的需求是区分大小写,有的不区分)
14.看是否支持tap和enter键等;密码是否可以复制粘贴;密码是否以* 之类的加秘符号显示
二.修改密码
当然具体情况具体分析哈~不能一概而论~
实际测试中可能只用到其中几条而已,比如银行卡密码的修改,就不用考虑英文和非法字符,更不用考虑那些TAP之类的快捷键.
而有的需要根据需求具体分析了,比如连续出错多少次出现的提示,和一些软件修改密码要求一定时间内有一定的修改次数限制等等。

1.不输入旧密码,直接改密码
2.输入错误旧密码
3.不输入确认新密码
4.不输入新密码
5.新密码和确认新密码不一致
6.新密码中有空格
7.新密码为空
8.新密码为符合要求的最多字符
9.新密码为符合要求的最少字符
10.新密码为符合要求的非最多和最少字符
11.新密码为最多字符-1
12.新密码为最少字符+1
13.新密码为最多字符+1
14.新密码为最少字符-1
15.新密码为非允许字符(如有的密码要求必须是英文和数字组成,那么要试汉字和符号等)
16.看是否支持tap和enter键等;密码是否可以复制粘贴;密码是否以* 之类的加秘符号
17.看密码是否区分大小写,新密码中英文小写,确认密码中英文大写.
18.新密码与旧密码一样能否修改成功.

WEB测试的测试点

这里给大家分享篇关于WEB测试的测试点的文章

                               一、功能测试

对于网站的测试而言,每一个独立的功能模块需要单独的测试用例的设计导出,主要依据为《需求规格说明书》及《详细设计说明书》,对于应用程序模块需要设计者提供基本路径测试法的测试用例。

    1、链接测试

链接是Web应用系统的一个主要特征,它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面:

1)测试所有链接是否按指示的那样确实链接到了该链接的页面;

2)测试所链接的页面是否存在;

3)保证Web应用系统上没有孤立的页面,所谓孤立页面是指没有链接指向该页面,只有知道正确的URL地址才能访问。

链接测试可以自动进行,现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成,也就是说,在整个Web应用系统的所有页面开发完成之后进行链接测试。

Xenu——主要测试链接的正确性的工具

可惜的是对于动态生成的页面的测试会出现一些错误。

 2、表单测试

当用户给Web应用系统管理员提交信息时,就需要使用表单操作,例如用户注册、登陆、信息提交等。在这种情况下,我们必须测试提交操作的完整性,以校验提交给服务器的信息的正确性。例如:用户填写的出生日期与职业是否恰当,填写的所属省份与所在城市是否匹配等。如果使用了默认值,还要检验默认值的正确性。如果表单只能接受指定的某些值,则也要进行测试。例如:只能接受某些字符,测试时可以跳过这些字符,看系统是否会报错。

要测试这些程序,需要验证服务器能正确保存这些数据,而且后台运行的程序能正确解释和使用这些信息。

B/S结构实现的功能可能主要的就在这里,提交数据,处理数据等如果有固定的操作流程可以考虑自动化测试工具的录制功能,编写可重复使用的脚本代码,可以在测试、回归测试时运行以便减轻测试人员工作量。

我们对UM子系统中各个功能模块中的各项功能进行逐一的测试,主要测试方法为:边界值测试、等价类测试,以及异常类测试。测试中要保证每种类型都有2个以上的典型数值的输入,以确保测试输入的全面性。

3、Cookies测试

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

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

4、设计语言测试

Web设计语言版本的差异可以引起客户端或服务器端严重的问题,例如使用哪种版本的HTML等。当在分布式环境中开发时,开发人员都不在一起,这个问题就显得尤为重要。除了HTML的版本问题外,不同的脚本语言,例如Java、Javascrīpt、 ActiveX、VBscrīpt或Perl等也要进行验证。

5、数据库测试

在Web应用技术中,数据库起着重要的作用,数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中,最常用的数据库类型是关系型数据库,可以使用SQL对信息进行处理。

在使用了数据库的Web应用系统中,一般情况下,可能发生两种错误,分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的,而输出错误主要是由于网络速度或程序设计问题等引起的,针对这两种情况,可分别进行测试。

二、性能测试

网站的性能测试对于网站的运行而言异常重要,但是目前对于网站的性能测试做的不够,我们在进行系统设计时也没有一个很好的基准可以参考,因而建立网站的性能测试的一整套的测试方案将是至关重要的。

网站的性能测试主要从三个方面进行:连接速度测试、负荷测试(Load)和压力测试(Stress),

连接速度测试指的是打开网页的响应速度测试。负荷测试指的是进行一些边界数据的测试,压力测试更像是恶意测试,压力测试倾向应该是致使整个系统崩溃。

 1、连接速度测试

用户连接到Web应用系统的速度根据上网方式的变化而变化,他们或许是电话拨号,或是宽带上网。当下载一个程序时,用户可以等较长的时间,但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长(例如超过5秒钟),用户就会因没有耐心等待而离开。

另外,有些页面有超时的限制,如果响应速度太慢,用户可能还没来得及浏览内容,就需要重新登陆了。而且,连接速度太慢,还可能引起数据丢失,使用户得不到真实的页面。

2、负载测试

负载测试是为了测量Web系统在某一负载级别上的性能,以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量,也可以是在线数据处理的数量。例如:Web应用系统能允许多少个用户同时在线?如果超过了这个数量,会出现什么现象?Web应用系统能否处理大量用户对同一个页面的请求?
3、压力测试

负载测试应该安排在Web系统发布以后,在实际的网络环境中进行测试。因为一个企业内部员工,特别是项目组人员总是有限的,而一个Web系统能同时处理的请求数量将远远超出这个限度,所以,只有放在Internet上,接受负载测试,其结果才是正确可信的。

进行压力测试是指实际破坏一个Web应用系统,测试系统的反映。压力测试是测试系统的限制和故障恢复能力,也就是测试Web应用系统会不会崩溃,在什么情况下会崩溃。黑客常常提供错误的数据负载,直到Web应用系统崩溃,接着当系统重新启动时获得存取权。

压力测试的区域包括表单、登陆和其他信息传输页面等。

采用的测试工具:

性能测试可以采用相应的工具进行自动化测试,我们目前采用如下工具

ab —–Apache 的测试工具

OpenSTA—开发系统测试架构

           三.接口测试

在很多情况下,web 站点不是孤立。Web 站点可能会与外部服务器通讯,请求数据、

验证数据或提交订单。

1、 服务器接口

第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事务,然后查看服务器

记录,并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库,确认事务数据已正确保存。

2、 外部接口

有些 web 系统有外部接口。例如,网上商店可能要实时验证信用卡数据以减少欺诈行

为的发生。测试的时候,要使用 web 接口发送一些事务数据,分别对有效信用卡、无效信用卡和被盗信用卡进行验证。如果商店只使用 Visa 卡和 Mastercard 卡, 可以尝试使用 Discover 卡的数据。(简单的客户端脚本能够在提交事务之前对代码进行识别,例如 3 表示 American Express,4 表示 Visa,5 表示 Mastercard,6 代表Discover。)通常,测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。

3、错误处理

最容易被测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错

误,但却无法预期系统所有可能的错误。尝试在处理过程中中断事务,看看会发生什么情况?

订单是否完成?尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用卡验证服

务器的连接。在这些情况下,系统能否正确处理这些错误?是否已对信用卡进行收费?如果

用户自己中断事务处理,在订单已保存而用户没有返回网站确认的时候,需要由客户代表致

电用户进行订单确认。

四、可用性测试

可用性/易用性方面目前我们只能采用手工测试的方法进行评判,而且缺乏一个很好的评判基准进行,此一方面需要大家共同讨论。

 1、导航测试

导航描述了用户在一个页面内操作的方式,在不同的用户接口控制之间,例如按钮、对话框、列表和窗口等;或在不同的连接页面之间。通过考虑下列问题,可以决定一个Web应用系统是否易于导航:导航是否直观?Web系统的主要部分是否可通过主页存取?Web系统是否需要站点地图、搜索引擎或其他的导航帮助?

在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动,很快地扫描一个Web应用系统,看是否有满足自己需要的信息,如果没有,就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构,因此,Web应用系统导航帮助要尽可能地准确。

导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容,内容在什么地方。

Web应用系统的层次一旦决定,就要着手测试用户导航功能,让最终用户参与这种测试,效果将更加明显。

2、图形测试

在Web应用系统中,适当的图片和动画既能起到广告宣传的作用,又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有:

(1)要确保图形有明确的用途,图片或动画不要胡乱地堆在一起,以免浪费传输时间。Web应用系统的图片尺寸要尽量地小,并且要能清楚地说明某件事情,一般都链接到某个具体的页面。

(2)验证所有页面字体的风格是否一致。

(3)背景颜色应该与字体颜色和前景颜色相搭配。

(4)图片的大小和质量也是一个很重要的因素,一般采用JPG或GIF压缩。

 3、内容测试

内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。

信息的正确性是指信息是可靠的还是误传的。例如,在商品价格列表中,错误的价格可能引起财政问题甚至导致法律纠纷;信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行,例如使用Microsoft Word的”拼音与语法检查”功能;信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口,也就是一般Web站点中的所谓”相关文章列表”。

4、整体界面测试

整体界面是指整个Web应用系统的页面结构设计,是给用户的一个整体感。例如:当用户浏览Web应用系统时是否感到舒适,是否凭直觉就知道要找的信息在什么地方?整个Web应用系统的设计风格是否一致?

对整体界面的测试过程,其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式,来得到最终用户的反馈信息。

对所有的可用性测试来说,都需要有外部人员(与Web应用系统开发没有联系或联系很少的人员)的参与,最好是最终用户的参与。

        五、兼容性测试

需要验证应用程序可以在用户使用的机器上运行。如果您用户是全球范围的,需要测试各种操作系统、浏览器、视频设置和 modem 速度。最后,还要尝试各种设置的组合。

1、平台测试

市场上有很多不同的操作系统类型,最常见的有WindowsUnix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统,取决于用户系统的配置。这样,就可能会发生兼容性问题,同一个应用可能在某些操作系统下能正常运行,但在另外的操作系统下可能会运行失败。

因此,在Web系统发布之前,需要在各种操作系统下对Web系统进行兼容性测试。

2、浏览器测试

浏览器是Web客户端最核心的构件,来自不同厂商的浏览器对Java,、Javascrīpt、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如,ActiveX是Microsoft的产品,是为Internet Explorer而设计的,Javascrīpt是Netscape的产品,Java是Sun的产品等等。另外,框架和层次结构风格在不同的浏览器中也有不同的显示,甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。

测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中,测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。

采用测试工具:

通过白盒测试或者黑盒测试导出的测试用例,采用相应的工具进行测试,可以采用OpenSTA进行测试,此测试工具可以采用不同的浏览器进行测试。

3.视频测试

页面版式在 640×400、600×800 或 1024×768 的分辨率模式下是否显示正常? 字体是否太小以至于无法浏览? 或者是太大? 文本和图片是否对齐?

 4.Modem/连接速率测试

是否有这种情况,用户使用 28.8 modem下载一个页面需要 10 分钟,但测试人员在测

试的时候使用的是 T1 专线? 用户在下