搜档网
当前位置:搜档网 › 接口测试方法

接口测试方法

接口测试方法
接口测试方法

接口功能测试策略

分类:java 学习 2012-04-18 15:30 1105人阅读评论(0) 收藏举报

测试服务器数据库游戏平台网络协议

由于平台服务器是通过接口来与客户端交互数据提供各种服务,因此服务器测试工作首先需要进行的是接口测试工作。测试人员需要通过服务器接口功能测试来确保接口功能实现正确,那么其他测试人员进行客户端与服务器结合的系统测试过程中,就能够排除由于服务器接口缺陷所导致的客户端问题,便于开发人员定位问题。以下便是个人的平台服务器接口功能测试经验总结:

一、接口测试范围

根据服务器的测试需求,接口测试范围主要分为:1、新增接口的测试;2、新增业务功能接口测试;3、整个服务器的接口测试。所需测试测试接口依次增多,在测试时间足够的条件下,当然需要对所有接口进行测试用例的设计,但如果测试较短的情况下,则应该首先根据用户的典型操作对测试接口进行优先级划分,对调用频繁接口需要优先进行测试。

二、接口测试策略

在进行平台服务器接口测试之前,首先需要整理服务器接口的测试方案,分析接口测试的要点,平台服务器的接口测试内容主要有:

接口设计检查

接口用于服务器与客户端的数据交互,客户端通过网络协议传递的数据为服务器接口的输入数据,因此应该首先通过服务器接口文档及客户端数据约束文档进行交互数据的有效性检查:

n 整数型数据位数

n 浮点型数据精度

n 字符串数据范围值

要求客户端的整数型、浮点型、字符串数据以及其最大值和最小值都能作为服务器接口的有效输入。这些工作在服务器设计评审时就可以进行,以便确保不会出现客户端上传数据被服务器自动进行截断或四舍五入的操作。

接口依赖关系检查

以上策略只谈到单个接口的测试方法,对于用户来说,一个操作可能会造成服务器调用多个接口来进行完成,因此还需要从业务处理的角度,对各种业务操作所涉及的多个接口之间依赖调用进行测试。

接口依赖关系检查主要是通过接口的输出值为另一接口的输入值来实现的,因此在进行接口测试之前,需要分析所测试接口的输入值是通过客户端还是其他接口输出来获取的,在设计测试用例时,加入接口的依赖关系说明以便于测试。

接口输入/输出验证

服务器接口功能测试类似于单元测试,在设计测试用例时,侧重点在于接口模块输入/输出项的正确性验证,根据接服务器接口处理方式,对各种接口进行分类:

第一类:条件判断接口

这类接口在接收到请求数据后,会根据输入参数进行条件判断,然后返回相应结果码,通常涉及条件判断的接口有:用户鉴权接口、升级状态上报、密码修改/重置等接口。因此输入/输出项验证的侧重点主要集中在:

1)判断条件的验证

要对判断条件进行验证,则需要知道接口是根据哪些输入项来进行判断的,以密码重置接口为例:

密码重置接口

『接口功能』:用户登录之后发起找回密码操作,用户输入邮箱信息后,游戏中心将向平台服务器发送请求,平台服务器将随机为用户生成新的密码,发到用户的邮箱中。

『接口方向』:游戏中心—>平台服务器

『遵循协议』:HTTPS,请求消息使用Post方式

响应消息(sendMessageRes)

此接口根据输入的userID、email参数来进行数据正确性的判断(key是接口名称,如果错误服务器将不会处理,version是版本号,其值只是用于记录,不参与判断),设计接口测试用例时,应该首先对接口的判断参数进行验证,这些输

入项不能为空,然后利用等价类划分、边界值方法来根据userID、email输入项设计各种合法的数据,验证接口是否可以正常处理。

2)异常数据的响应

只考虑正常情况,而不考虑异常场景是无法保证接口功能运行正常,对于密码重置接口,用户 ID不存在、不合法,邮箱输入格式错误、用户邮箱信息不存在或未激活就是测试时需要考虑的异常场景,设计这类输入值,并且检查接口返回的响应码,响应码的正确才能保证客户端根据异常情况来显示相应的提示信息。简而言之,条件判断的接口其测试策略就是根据判断条件来设计各种输入值来检验接口的功能。

第二类:数据查询接口

这类接口接收到请求数据后,首先会验证请求是否合法,然后会根据请求项查询数据库相应表中数据返回给客户端,通常涉及数据查询的接口有:用户基本资料/经验值/赛事信息查询、游戏列表获取、在线人数查询等接口。以用户经验值查询接口为例:

用户经验值查询接口

『接口功能』:用户登录游戏中心后,可以查询自己每个游戏项目的经验值信息,包括此项目的经验值等级、等级称号、今日经验值上限等。

『接口方向』:游戏中心—>平台服务器

『遵循协议』:HTTP+XML,请求消息使用Post方式

响应消息(sendMessageRes)

此接口首先会根据webkey来判断请求是否合法,然后根据请求参数中的userID、isAll、sportItemID来查询数据表中相应数据。除了象条件判断接口一样根据判断项webkey、请求参数userID、isAll、 sportItemID设计合法/不合法和正常/异常测试值之外,还需要结合数据库来对查询结果进行验证:

1)是否根据正确的关联数据表进行查询;

2)验证查询结果是否从数据表中正确项中获取,涉及到多表联合查询时,不同表中的相同项设计不同测试数据进行验证;

3)修改查询结果在数据表中对应项中的数据,使其为空值或客户端相应项的范围值的最大和最小值,查看接口输出是否正确。

第三类:逻辑运算接口

这类接口在收到请求数据之后,会进行一系列逻辑运算,然后根据处理结果更新数据库中的数据,通常涉及逻辑运算的接口有:比赛成绩同步、商品支付、各种数据报表等接口。以比赛成绩同步接口为例:

比赛成绩同步接口

『接口功能』:游戏服务器将用户每次的比赛成绩传给平台服务器,平台服务器根据用户的比赛成绩更新此用户的赛事排名,然后存入数据库。

『接口方向』:游戏服务器—>平台服务器

『遵循协议』:HTTPS+XML,请求消息使用Post方式

响应消息(sendMessageRes)

此接口比数据查询接口又更加复杂,除了用条件判断和数据查询类接口的策略对此接口进行测试用例设计之外,还需要验证对接口的算法规则进行检查,因为此接口涉及根据用户比赛成绩(record)进行排名然后返回其得分及排名情况(score、rank、upRankFlag、exp),通过对相关数据表中的数据进行查看方式,接口算法规则验证包括:

1)用户胜利、失败、中途主动/被动退出、规定时间内未完成比赛情况下,此场比赛得分(scroe)是否正确;

2)用户比赛成绩比上次成绩花费时间短、长、持平情况下,排名情况(upRankFlag)是否正确;

3)用户比赛成绩处于第一名、最后一名、比上次成绩花费时间短/长/持平情况下,用户积分排名(rank)是否正确;

4)用户胜利、失败、中途主动/被动退出、规定时间内未完成比赛,并且用户经验值在各种经验等级范围下,经验值根据得分进行计算的公式是否正确。

逻辑运算接口由于还涉及插入或更新数据库操作,因此测试时还需要考虑数据库特性,如数据精度问题,在MySQL数据库中,如果是浮点型数据,存入时会有精度误差(131072.32插入float(10,2)类型的数据会变为131072.31),因此对于需要用于金额计算、数据统计、成绩比较的数据,最好使用定点型。

最后服务器接口的测试如果有足够条件的话,还需要通过白盒测试来对接口代码做进一步的测试,通过编写关键代码的测试桩,可以有效查找将字符数组当成字符串使用造成的读越界这类不易通过黑盒测试发现的BUG。接下来的工作就是如何通过测试工具来执行服务器接口功能测试。

编写接口测试的测试用例体会

分类:测试用例 2011-08-23 19:22 2680人阅读评论(0) 收藏举报

测试数据库testing产品语言工作

来淘宝目前已经3周了,这三周只重复地做了一个事情,编写测试用例,修改测试用例。不断地修改让我对自己的语言组织能力和逻辑思维能力产生了怀疑,同时,越来越觉得测试用例的写法扑朔迷离。我问了3个人,结果每个人都告诉我不同的写法。把我自己弄的不知所措。但是问的多了,慢慢也就明白了,每个人都有每个人的编写风格,作为测试新人,我们要了解如何去编写测试用例,而不是copy别人的测试用例。只有真正了解了如何去编写,才能写出有自己风格的测试用例。

测试用例基本上都包括以下五部分:

1.前置条件

2.输入参数

3.执行步骤

4.校验点

5.期望值

这这是书写用例的一种形式而已。有些测试用例中,输入参数也可以省略掉。重要的是设计测试用例、

刚接手工作还没有编写日常用例就跟进了一个项目,我负责的是实体管理和属性管理的增删改查,这样涉及到了页面。我也最先接触到了功能测试和接口测试。

其实知道现在我还是没有完全区分开这两个测试。我觉得在书写测试用例的时候两者是相似的。

只是功能测试一般是在页面上,接口测试则接触底层代码。当然,在接口中我也按功能点书写了功能性的测试。

书写接口测试测试用例的考虑点:

1,充分滴熟悉PRD(产品需求设计)

了解PRD,熟悉业务规则,根据业务规则来确定测试点。为了辅助理解产品的架构,可以画mm图,将需求分类。在编写用例的过程中进行等价类的划分,最后用判定表进行评判,补充缺少的用例,剔除冗余的用例。做到对需求的100%覆盖。要明白哪些是核心功能!

2 .以下转载自https://www.sodocs.net/doc/1417399224.html,/?p=5154

(测试用例的有效性)测试用例应该包含清晰的输入数据以及预期输出,没有测试数据的用例更多的是具有指导意义,执行过程中更多的是靠个人根据指导的自由发挥。但是看看我们的基线库更多的是这样指导意义的用例。(但是输入数据又涉及到了维护的问题,以及环境或者业务发生变更后引起的有效性问题)。对于预期的结果不能仅仅是页面上或者界面上的可见结果,如果和数据库发生了交互,必须包含数据库里准确的验证结果。用例基于数据驱动。

(测试用例的可理解性)测试用例步骤必须描述清晰,不能出现模棱两可以及重复的话语,测试用例应该按照增删改的顺序进行安排,这样执行的时候效率比较高,避免不必要的重复测试,用例写完不是就ok了,我们最好通读2遍,进行修改,让单条用例流畅。

(测试用例的清晰性)测试用例的验证点必须明确清晰重点突出,按照最新的用例标准,一个用例进行一个功能点的验证,一个萝卜一个坑。对于流程性的用例也是建议按照流程顺序进行用例安排,从第一个验证点到最后一个验证点,组成流程的开始到结束,方便测试执行。测试用例包含前置条件的必须将前置条件描述清楚,包括入口等。

(测试用例的可维护性)我们的用例主要是基于web的,用例存在一定的变数。

因此在测试用例因为业务需求发生变更的时候,请及时修改,维护测试用例,做到测试用例的实时性与有效性,同时也方便后来的新人同学及时学习,不会产生误解与费解

【这里还应该有一个(测试用例的可重现性),这个在准备数据的时候要注意】

Ross Collard在”Use Case Testing”一文中说:“测试用例的前10%到15%可以发现75%到90%的重要缺陷”。如果你在项目或者日常结束后,仔细的分析过我们的bug列表,那么你会觉的这句话非常适用。合理提高我们的测试效率就是在编写测试用例时进行测试用例优先级的划分。

如何设计接口测试用例接口测试是项目测试的一部分,正如其名,它测试的主要对象是接口,是测试系统组件接口测试间接口的一种测试。接口测试主要用于检测外部系统与所测系统之间以及内部各系统之间的交互点。测试的重点是检查数据交互、传递、和控制管理过程以及系统间的相互依赖关系等。如何设计接口测试用例测试用例?测试用例首先,明确出发点。和所有的测试一样,接口测试出发点是你要证明所测的程序是错误的。以这个出发点为导向,你的设计行为就会尽量朝这个方向发展,更易发现问题,不会出现大方向的偏差。其次,选择好测试对象。对于一个系统做接口测试选择好的测试对象是接口测试关键。一个系统有无数的接口,每个接口如果分别测试,那将是很痛苦的一件事情,不光繁琐浪费,而且任何一个内部接口的变动,都将导致我们用例的不可用。这里推荐把整个系统作为一个整体,选择整个系统提供给外部使用、交互的最外层接口作为你的测试对象,以此为测试对象的用例将有很好的健壮性,并且更高效。另外,根据数据的流向,又可将这些最外层的接口分为两类:一类是数据进入系统的接口;一类是数据流出系统的接口。进入系统的接口实际是我们用例的执行调用的接口。可通过变化参数对这些接口进行调用,模拟外部的使用;而流出的接口则是我们用例真正该验证的点。数据从哪里流出,流出时的状态如何,此时系统又是什么状态都是我们所应该验证的。然后,确认完整的测试对象的功能:确认外部接口提供给使用这些接口的外部用户什么样的功能,外部用户真正需要什么样的功能。此两个功能一定要准确详细,用例的设计要严格按照测试对象功能设计才是正确的用例。最后当出发点、对象、功能都确定了,就可以真正设计用例了。下面详细介绍下如何去设计一个结构好、可读性高、渗透性强的接口测试用例。接口测试用例设计和其他其他测试用例设计一样,都应该本着尽可能的发现bug 的目标。用其他例设计的内容应该包括:主要测试功能点、测试环境、测试数据测试数据、执行操作以及预期结果。测试数据1)接口测试环境分为两种:一种是程序内部的环境;一种是程序的所调用外部接口的环境。用例在设计环境上有一个原则即:设计真实而危险的环境,不忽视偶发环境。真实,即你的用例在测试某种功能时,应该去思考这种情况发生时内部、外部环境是什么,通过各种手段将最准确的环境模拟出来。危险,即在这种环境下系统出问题的概率会很大。在设计用例环境时,如果两种环境都能达到你本用例的要求,更推荐选择更危险的环境。所谓偶发,即这种环境出现的概率很小。不要因为这种环境很少出现就无视它,开发很可能也是这种想法,此处很有可能隐藏着问题。2)接口测试测试数据分为接口参数数据和用例执行所需系统数据。数据的设计学问大,

不要在设计、准备测试用例的数据上偷懒。要通过好的测试数据使用例查错的功能充分发挥。接口参数数据需对每个参数根据测试接口的实际的功能进行分析,在符合业务逻辑的情况下进行逻辑组合排列,不要遗漏了某些边界值和错误点的数据。每个用例执行所需系统数据和接口参数数据尽可能的采用不一样的数据,使用例更容易发现问题。3)测试功能点,如果一个接口功能复杂时推荐对接口用例进行结构划分,这样子用例具有更好的可读性和维护性。接口划分原则为以接口提供的功能点的不同进行合适粒度的划分。同一功能点的用例又可根据测试环境的不同、数据的不同进行用例的填充。4)接口测试用例执行操作非常简单,就是所测接口的调用。5)预期结果验证,这也是接口用例设计的很关键的一步,应该细而不冗余。所谓细,用例中应详细列出应该验证的点。每个用例均需验证,不要因为前几个用例有验证就认为全部是正确的。避免一个用例中重复做相同的验证,提高测试用例的效率。

关于接口测试的总结1. 接口测试:是测试系统组件间接口的一种测试。主要用于检测外部系统于系统乊间以及系统内部各个子系统乊间的交互点。重点测试的时数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等等,这要求对业务逻辑有一定程度上的理解,对数据流向有较好的定位。2. 接口测试的分类:a) b) c) 系统不系统乊间的调用(如分享时,微信会提供接口给“跑向珠峰”;)上层服务对下层服务的调用服务乊间的调用(如添加一条数据时,会先调用数据查询的服务,查询改数据是否是重复数据);丌同类型的接口测试方法可能丌一致,但总体来说,丌管是哪种类型,被测接口即为服务方,测试手段为客户方,接口测试的目的就是:通过我们的测试手段,去验证满足其声明提供的功能。3. 接口测试的原理:通过测试程序模拟客户端向服务器发送请求报文,服务器接收请求报文后对相应的报文做出处理然后再把应答报文发送给客户端,客户端接收应答报文这一过程(request→response) 4. 接口测试的流程:类似于功能测试,需求讨论→评审需求→确定需求→产出接口定义→根据需求文档及接口定义设计测试用例(测试用例主要从业务场景,功能以及异常测试几个方面考虑)→评审用例→执行测试5. 接口测试的价值:降低成本,提高效率。接口测试能够提供系统复杂度上升情况下的低成本高效率的解决方案。它是一个完整的体系,还包括功能测试,性能测试等。 6. 接口测试的适用范围:一般用于多个系统间的交互开发,戒者拥有多个子系统的应用系统开发的测试。接口测试适用于为其他系统提供服务的底层框架系统和中心服务系统。主要测试这些对外部提供的接口的正确性和稳定性。它也同样适用于上层系统中服务层接口,测试难度随层级而上升。即越往上难度越大。7. 需求的频繁变化,做接口测试的测试人员应该如何应对:个人觉得此在于团队开发的流程,团队乊间的沟通和测试人员的警觉性。、在开发阶段,需求的变更是一件极为频繁和正常的事情,对于此点团队中的任何一人都应该以正确的心态来面对。团队需要规范的开发流程,良好的沟通方式,测试人员更需要及时跟迚软件迚度,和开发人员并迚齐行。同时,测试不开发需要相对独立的工作环境,总结而言为乊知己知彼,亦敌亦友。

8. 关于如何简单设计接口测试的设计用例a) 明确出发点——测试的目的是为了让找出软件的缺口,修复并使乊更加完善。在这一基础点上,接口测试也丌例外。以找出软件的误漏为出发点,测试用例需紧贴此线,更容易找出问题所在。b) 明确测试点——选择好的测试对象。系统内部层次繁复复杂,任何一个接口的变劢都将导致用例失效。(可将这些最外层的接口根据数据的流向分为迚入和流出两类,迚入系统的接口实际上是我们用例的执行调用的接口。可通过参数对这些接口迚行调用,模拟外部的使用;而流出的接口则是我们用例真正该验证的点。数据从哪里流出,流出的状态如何,此时系统的状态都是作为测试

目的所要着重关注的部分)c) 确认完整的测试对象的功能——确认外部接口提供给使用这些接口的外部用户什么样的功能,外部用户真正需要的时什么样的功能予以区别。用例的设计要严格按照测试对象功能设计才是正确的用例。

9. 设计(接口)测试用例有哪些要求:结构好,可读性高,渗透性强。10. (接口)测试用例包括的内容:功能点,测试环境,测试数据,执行操作以及预期结果。如下:a) 接口测试测试的功能点:如果一个接口功能过于复杂时,可以对接口用例迚行结构划分(如根据层次,平台,功能点等等),这样用例具有更好的可读性(接口划分原则为:以接口提供的功能点的丌同迚行合适粒度的划分,同一功能点的用例又可根据测试环境的丌同,数据的丌同迚行用例的填充)b) c) 接口测试用例的环境:程序内部环境和程序所调用的外部接口的环境。关于接口测试测试数据:分为两部分:接口参数数据和用例执行所需系统数据。数据的设计、准备测试用例的数据丌可马虎。通过好的测试数据查找问题,能极大的提高工作效率。接口参数数据需要对每个参数根据测试接口的实际功能迚行分析,在符合业务逻辑的情况下迚行逻辑组合排列,丌要遗漏某些边界值和错误点的数据,这样用例更容易发现问题。d) e) 执行操作:即对所测接口的调用。预期结果:根据需求迚行验证,是衡量软件是否达到预期的标准。应该着重细致,每个用例均需验证,应该避免一个用例重复做相同的验证,提高测试用例的效率。11. a) 具体测试用例的参考点:输入参数测试:针对输入参数迚行的测试,也可以说是假定接口参数的丌正确性迚行的测试,确保接口对任意类型的输入都做了相应的处理:输入参数合法(丌合法),输入参数为空,为null,输入参数超长等等;b) 功能测试“接口是否满足了所提供的功能,相当于正常情况测试,如果一个接口功能复杂时推荐对接口用例迚行结构划分,这样子用例觉有更好的可读性和可维护性;c) 逻辑测试:逻辑测试严格讲应为单元测试,单元测试应保持内部逻辑的正确性,可单元测试和接口测试的界限并丌是那么清楚,所以我们也可以从给出的设计文档中考虑内部逻辑错误的分乊情况和异常;d) 异常情况测试:接口实现是否对清楚情况都迚行了处理,接口输入参数虽然合法,但是在接口实现中,也会出现异常,因为内部的异常丌一定是输入的数据造成的,而有可能是其他逻辑造成的,程序需要对任何异常都迚行处理。题外关于单元测试,接口测试和白盒测试a) 单元测试:针对具体代码逻辑迚行测试,主要测试被测代码的一个很小,很明确的功能是否正确。即单元模块的逻辑是否正确,对业务关注丌大;b) 接口测试:针对程序内部的戒者外部的接口迚行的测试一个接口方法可能包含多个单元模块,并且,一个接口会有自己特定的业务定义:做接口测试更多的从业务的角度去考虑如何测试;c) 白盒测试:单元测试和接口测试都属于白盒测试的一个阶段

测试用例之性能测试用例

性能测试、压力测试、负载测试、强度测试、稳定性测试、健壮性测试、功能测试、接口测试……,这么多眼花缭乱的测试类型名称,估计很少有人能准确的区分并说出定义来,至于对应的测试用例如何编写和执行,就更不用说了。

如果问测试工程师测试用例如何编写,就象是问程序员如何编写代码得到的答案一样,每个人都会给出不同的编写方法,但实用的测试用例却象优秀的程序一样难以编写。

目前国内,测试工程师却时常要面对“已经延期几倍计划时间的项目”,测试用例如何发挥更大的作用,是一个迫切需要解决的问题。事实上,完全可以把测试用例看成是测试工

程师编写的程序:这个“程序”是为了辅助测试工作的进行而开发的,目的是为了发现软件问题,同时“顺便”证明软件功能是否符合要求。

本文针对上面的问题,以设计性能测试用例为示范,讲解在企业实际工作中,如何有效划分测试种类和编写对应的测试用例,使测试工作更加合理、高效率的开展。

1测试种类和阶段

1.1 测试种类

对于测试种类的说法多种多样,最多的能达到30多种测试类型。而实际工作中很多测试是互相包含的。按照企业中实际工作需要,通常主要进行下面几种类型的测试:功能测试、健壮性测试、接口测试、强度测试、压力测试、性能测试、用户界面测试、可靠性测试、安装/反安装测试、文档测试。

下面介绍几种重要的测试种类及其测试的内容:

功能测试:功能测试主要针对产品需求说明书的测试,是验证功能是否否合需求,包括原定功能的检验、是否有冗余功能、遗漏功能。这类测试应由测试员做,这并不意味着程序员在发布前不必检查他们的代码能否工作,他们也需要进行基本功能的测试。

接口测试:程序员对各个模块进行系统联调的测试,包含程序内接口和程序外接口测试。这个测试,在单元测试阶段进行了一部分工作,而大部分都是在集成测试阶段完成的。由开发人员进行。

性能测试:在交替进行负荷和强迫测试时常用的术语。性能测试关注的是系统的整体。它和通常所说的强度、压力/负载测试测试有密切关系。所以压力和强度测试应该与性能测试一同进行。

用户界面测试:对系统的界面进行测试,测试用户界面是否友好、是否方便易用、设计是否合理、位置是否正确等一系列界面问题

安装/反安装测试:安装测试主要检验软件是否可以正确安装,安装文件的各项设置是否有效,安装后能否影响原系统;反安装是逆过程,测试是否删除干净,是否给影响原系统等。

文档测试:主要测试开发过程中针对用户的文档,以需求、用户手册、安装手册等为主,检验文档是否和实际应用存在差别。文档测试不需要编写测试用例。

测试种类的划分不要拘泥于上面的形式,总体来说应该服从于测试策略,可以根据具体工作的特点进行安排,为了工作更容易开展,完全可以把一些测试合在一起进行。在后面的性能测试用例的编写上,充分体现了这一思想。

1.2 测试阶段

和开发过程相对应,测试过程会依次经历单元测试、集成测试、系统测试、验收测试四个主要阶段。对应关系如图1所示:

需求开发

高层设计

详细设计

编程

单元测试

集成测试

系统测试

验收测试

图1 开发与测试的“V”型关系

单元测试:单元测试是针对软件设计的最小单位——程序模块甚至代码段进行正确性检验的测试工作,通常由开发人员进行。

集成测试:集成测试是将模块按照设计要求组装起来进行测试,主要目的是发现与接口有关的问题。由于在产品提交到测试部门前,产品开发小组都要进行联合调试,因此在大部分企业中集成测试是由开发人员来完成的。。

系统测试:系统测试是在集成测试通过后进行的,目的是充分运行系统,验证各子系统是否都能正常工作并完成设计的要求。它主要由测试部门进行,是测试部门最大最重要的一个测试,对产品的质量有重大的影响。

验收测试:验收测试以需求阶段的《需求规格说明书》为验收标准,测试时要求模拟实际用户的运行环境。对于实际项目可以和客户共同进行,对于产品来说就是最后一次的系统测试。测试内容为对功能模块的全面测试,尤其要进行文档测试。

尽管测试阶段的划分十分明确,但是在具体的项目和产品的测试中,尤其在执行测试时,会根据实际需要来开展。

1.3 测试种类、阶段和用例的关系

为了便于在实际工作中提高效率,同时方便测试用例的编写和执行,可以把上面提到的各个测试类型与对应的测试用例合并。合并后的测试用例主要有以下几种:1.功能测试用例:包含功能测试、健壮性测试、可靠性测试

2.性能测试用例:包含性能测试、压力测试、强度测试

3.集成测试用例:包含接口测试、健壮性测试、可靠性测试

4.安全测试用例:安全测试用例

5.用户界面测试用例:包含用户界面测试用例、少量功能测试用例

6.安装/反安装测试用例:安装/反安装测试用例

综合上面的分析,测试种类、测试阶段以及执行人员具体的关系如表1所示。

表1 测试的种类、阶段和执行人员的关系

总之,测试的种类应该尽量的少,这样每次都可以执行更多的测试内容。例如在进行功能测试的同时,完全可以进行健壮性的测试。(当然如果产品健壮性方面要求较高,就可以把健壮性测试作为独立的测试。)

2性能用例编写方案

性能测试在软件测试中占有重要的地位,而性能测试又关联很多内容。例如压力和强度测试就与性能测试密切相关:针对一个网站进行测试,模拟10到50个用户就是在进行常规性能测试,用户增加到1000乃至上万就变成了压力/负载测试,如果同时对系统进行大量的数据查询操作,就包含了强度测试。

为了便于性能测试工作的实施,这里的性能测试综合了性能、强度、压力、负载等多方面的测试内容,主要包含的内容有:预期性能指标测试、用户并发性能测试、疲劳强度测试、大数据量测试和速度测试、网络、服务器等方面的内容。

性能测试不同的系统有不同的要求,编写方法要根据实际要求进行编写,本文提出一个常见的参考方案,在实际工作中,可以根据需要加入其它例如内存泄露等和性能相关的测试用例。

下面介绍各个部分性能测试用例包含的内容:

2.1预期性能指标测试用例

通常系统在设计前都会提出一些性能指标,这些指标是性能测试要完成的首要工作之一。针对每个指标都要编写多个测试用例来验证是否达到要求,并根据测试结果来改进系统的性能。

这类通常以单用户为主,如果遇到并发用户的情况,可以归到并发用户测试用例中。这类用例通常都是可以通过手工来执行的用例,例如示例中的上传一份文件,期望的性能为2M/S,完全可以手动上传文件,同时用秒表计时。这些内容通常在需求说明书中可以显而易见的查到。不过当看到如支持并发用户300人,就应该放到后面进行。测试结果也是直接记录是否达到要求,如果系统没有达到要求则进行改善。

2.2用户并发性能测试用例

用户并发测试是性能测试的最主要部分,包含了负载测试和压力测试的过程。主要是逐渐增加用户数量来加重系统负担,直到出现不能接收的性能点或者瓶颈。一般要测试正常数量的用户并发和极限数量下用户并发的情况。

并发用户测试主要是对系统的核心功能和重要业务进行测试,要以真实的业务数据作为输入,选择有代表性和关键的业务操作来设计测试用例。主要编写以下两个方面的用例:核心模块的测试(可以理解为“单元性能测试”):对核心功能模块进行并发用户测试,测试系统是否能够稳定运行。例如对于互联网的公用邮件系统,每天早上9点左右可能是收发邮件的高峰,这时候上千的用户都要在上班后进入邮件系统,系统这个时候需要接收和发送大量的邮件。所以邮件系统这一功能模块要进行并发测试。通过测试可以知道数据库服务器、操作系统、网络设备等是否能够承受住考验,同时可以对瓶颈进行分析。

表2列出来一些常见的参数(表格中的数据为示例的测试用例和测试结果),可以根据实际需要进行增加和删除,其中磁盘I/O、数据库相关测试参数要根据实际情况进行选择,因

表2 核心模块的性能测试用例

在编写这类用例时,要进行综合分析,选出系统中的各个核心模块,分别设计每个模块的测试用例:把模块划分成小的“事务”进行测试,这样在测试分析中便于定位问题究竟出现在哪里。例如邮件系统可以划分成:接收邮件、发送邮件、打开邮件等小的事务进行测试用例的编写,每个操作做为一个用例来执行。

业务组合性能测试(可以理解为“集成性能测试”):所有的用户不会只使用核心模块,通常每个功能都可能被使用到,所有既要模拟多用户的“相同”操作,又要模拟多用户的不同操作,对多个业务进行组合性能测试。

业务组合测试是更接近用户实际操作系统的测试,因此用例编写要充分考虑实际情况,

选择最接近实际的场景进行设计。这里的业务组成单位以不同模块中的“子操作事务”为单位,进行各个模块的不同业务的组合。例如在办公自动化系统中就可以选择“公文模块中的发送公文、电子公告模块中的查看公告信息、网上论坛模块中的上传文件”等事务作为一组组合业务进行测试,用例设计信息如下:

功能:在线用户达到高峰时,用户可以正常使用系统,保证500个以内用户可以同时在线使用系统。

目的:测试系统500个以内的用户同时在线能否使用比较常见的模块:公文系统、电子公告、网上论坛。

方法:采用LoadRunner的录制工具录制三个业务:

业务1——在公文系统内,进行打开、修改等操作;

业务2——在电子公告系统内,查看、发布公告;

业务3——在网上论坛系统内发布帖子,查看文章。每个业务分配一定数目的用

户,利用LoadRunner来完成相关参数的测试。

其它部分设计可以参考表2。执行时要分别记录各个事务的执行情况。

多用户并发性能测试是性能测试的核心内容,包含了全部与多用户相关的测试。因此设计时要全面考虑,不要有遗漏。在测试执行时,本部分通常是采用性能测试工具例如LoadRunner来进行测试的,因此更容易执行和提高效率。

2.3疲劳强度与大数据量测试

疲劳强度测试是在系统稳定运行下模拟最大用户数量、并长时间运行系统,通过综合分析执行指标和资源监控来确定系统处理最大业务量时的性能。

疲劳强度测试的目的就是检验系统长时间运行后的性能,因此设计用例时,需要编写不同参数或者负载条件下的多个测试用例,对服务器、软件、网络进行不同条件下的综合测试分析,测试时要记录系统发生故障的信息作为测试结果。疲劳强度测试也是采用测试工具进行的。

大数据量测试分为两种:一个是针对某些系统存储、传输、统计查询等业务进行大数据量的测试;另一个是与前面并发测试相结合的综合数据测试。编写用例时主要编写前一部分,后一部分尽量放在并发测试中。

大数据量测试一般是针对那些对数据库有特殊要求的系统进行测试,例如电信业务系统的手机短信息表,由于有的用户关机或者不在服务区,每秒钟需要有大量的短信息保存,同时在用户联机后还要及时发送,因此对数据库性能有极高的要求,需要专门测试。

本部分用例设计表格可以参考用户并发性能测试部分。

2.4网络性能测试

网络性能测试主要是为了准确展示带宽、延迟、负载和端口的变化是如何影响用户的响应时间的。在实际的软件项目中,主要是测试用户数目与网络带宽的关系。

表3 网络性能测试

本部分可以独立测试,也可以和用户并发性能测试、疲劳强度与大数据量性能测试结合起来,在原有的基础上采用工具来调整网络设置,从而达到监视网络性能的目的。通常网络性能都是采用工具进行性能评估,由系统集成工程师来进行。

2.5服务器性能测试

本部分的测试用例不必独立编写,或者根据实际需要编写少量的测试用例,建议这部分的用例编写和前两部分结合起来,在用户并发性能测试、疲劳强度与大数据量性能测试时完成对服务器性能的监控,完成对服务器性能的评估。

2.6性能分析基本策略

在上面的用例执行完成后,接下来要进行性能分析。性能分析是性能测试的最终目的,否则测试出的指标就不会有实际意义,这里主要介绍一下性能分析的基本思路。性能分析通常要围绕三个方面进行:软件、服务器、网络。

软件主要是分析具体事务执行时间,尤其并发用户部分,根据测试工具测试出的结果分析那些事务执行的慢,然后可以分析执行较慢的代码,针对网页可以分析具体的页面元素执行情况。

服务器的分析要结合软件的运行情况进行分析,着重分析硬件的执行参数,CPU、硬盘、内存、中断、内存等情况,分析尤其要注意对这些参数进行综合分析,往往各个参数之间会互相影响,最后在调查、分析整体系统的基础上,找出影响服务器整体性能的瓶颈,确定相应的升级需求:

1. 服务器硬盘负载较重,需增加硬盘。

2. CPU整体性能偏低,需增加或更新CPU。

3. 网卡性能偏低,需更换光纤网卡。

4. 硬盘I/O负载任务繁重,需使用高转速硬盘或采用RAID卡。

5. 内存资源短缺,需增大内存。

6. 其他方面,需要升级软件系统、合理进行子网划分、加强管理等。

网络性能分析要结合结合服务器和测试目标软件,通常网络传输慢会有软件和服务器方面的原因,甚至有时候会有客户端方面的原因。不过目前网络的环境普遍可以,不管是局域网还是广域网,网络的环境越来越好。

3用例管理

测试用例的管理我们可以借鉴开发过程中对程序的管理方法,我们可以把测试用例看

成程序——测试工程师编写的程序,这个程序也要经过“设计”、“开发”、“测试”、“版本管理”、“发布”、“维护”等一系列操作,然后按照管理软件程序的方法来管理测试用例。

用例管理主要包含评审、修改、执行用例、用例版本维护、用例升级方面的内容。

3.1 用例评审

测试用例评审是测试用例不可缺少的一个环节,这是对“测试部门开发出的产品”进行的“测试”。基本思路是对测试准备阶段的成果进行分期评审,依次评审系统/验收测试用例、集成测试用例、单元测试用例。

评审用例在比较正规的公司更容易实施,要求相应的软件开发团队必须在实际工作中对测试给予足够的重视,才可以把这项工作做好,否则只是走走形式。有效的用例评审通常由下面两种形式组成:

测试部门外部评审——主要是由开发部、项目实施部、甚至销售人员参加的评审,目的主要是查找测试工程师编写的用例是否缺少内容。建议采用非正式评审的形式进行,因为我们很难把开发人员组织在一起,一般来说他们的开发进度压力很大,能够抽出时间看文档已经是“很给面子了”。当然不统一进行评审会耽误工程的进度,所以在实际工作中如果时间紧迫,可以提前启动测试实施工作,待评审完成后进行用例的修改工作。通常测试工作进行一段时间评审就会结束,这个时候测试执行人员可以在工作中对测试用例的内容进行动态的调整,再次执行被修改过的部分用例(如果能够采用正式评审,效果肯定会更好。)。

外部评审主要工作方式是用文档直接记录评审结果,测试人员根据评审结果对用例进行升级修改。

测试部门内部评审——部门内部同行对测试策略的评审,评审的核心内容是测试策略和用例编制思路是否正确,以此来保证测试用例的有效性。可以组织正式的评审,由用例的设计人员进行讲解,然后大家共同评审;也可以把文档发给部门的同事进行评审。内部评审有些象开发人员在单元测试中的交叉测试。

内部评审的主要工作方式是项目会议,大家可以进行激烈的讨论,共同探讨用例编写、交流经验,这样用例的编写水平才能提高,同时可以进行一些创新。

评审方式中的外部评审最为重要。因为开发人员很容易发现用例中遗漏了什么内容,同时还可以发现错误的用例——因为存在对需求理解的偏差。用例外部评审可以理解为开发人员在查找测试人员编写的“程序”缺陷。

通常情况下先执行内部评审,然后执行外部评审。很多时候,内部评审会被忽略,建议要进行内部评审。这样至少有两个好处:集思广益和提高测试小组输出文档的质量。

3.2 管理方案

国内大多数IT公司在测试用例的发展经历了以下几个阶段:

无用例而执行测试:测试的初级阶段,完全手工测试,测试执行工程中没有测试用例作为执行依据,可能会按照需求进行测试;

有用例而不使用用例执行测试:已经编写测试用例,但是受各种环境的影响,例如需求变动频繁、编写的用例过于简单等,测试用例编写后在实际工作中不能使

用;

按照部分用例执行测试:随着用例编写水平的提高,部分测试用例可以在测试中发挥作用;

完全按照用例执行测试:组织建立了规范的项目管理过程,对测试用例进行规范的管理,执行测试用例以用例为准则来执行测试。

完全按照测试用例执行测试是一个公司测试水平的体现,测试用例管理成为这一阶段的主要内容。测试用例管理的核心内容是版本管理。如果测试用例是采用文字编辑软件例如word编写,建议采用工具(例如Visual SourceSafe)对用例进行控制。可以参照图2进行。

编写用例

用例评审

进入版本控制库

用例修改

使用用例&维护&升级

图2 测试用例管理示意图

1、编写用例:测试工程师根据需求分析、概要设计、详细设计等文档编写测试用例。

2、用例评审:3.1小结说明了用例的评审。原则上用例像程序一样,要经过多次的修

改才可以通过,而实际工作中只进行一到两次。

3、用例修改:评审结束后,需要根据评审意见进行修改,修改后通常不再进行评审。

建议在时间和人力资源比较充裕的情况下,对用例的评审要像测试开发部门的产品

一样,经过反复的评审和修改,然后正式投入使用,因为每次评审可能都有新的发

现。

4、使用用例:在执行任务时,从版本控制库取出用例,执行时建议直接在用例上记

录测试结果。这样做会带来两个好处:首先是下次测试时可以看见上次测试的结果

记录,可以起一个提醒的作用;其次可以一次性的把发现的缺陷输入到缺陷跟踪

数据库中,在输入时可以进行综合统计,避免输入重复的缺陷。每次使用后送入版

本控制库中,进行版本的管理。

5、用例升级/维护:随着软件产品的不断修改、升级,对应的用例也需要升级和维护。

针对同一个项目,可以根据需求的变更不断进行维护;如果是产品,用例的维护则

更加重要,要达到用例和产品的版本一一对应。

测试用例的管理还可以采用专门的测试软件例如TestDirector等来进行管理,测试工具通常会具备上面的功能。如果有条件,建议采用集成华的测试工具,这样更容易对测试执行全程进行监控,可以把测试需求、测试用例、缺陷管理统一起来,大大提高测试效率。

在测试用例管理规范化并成为测试的执行准则后,管理测试用例带来的巨大好处开始逐渐显现出来,测试用例成为评估测试和改进测试工作的主要依据,可以给工具带来巨大的方

关键功能接口测试用例

1.目的 测量手机各关键硬件接口在工作状态的性能符合设计规范,以确保手机性能的稳定性符合设 计要求; 2.适用范围 适用于新开发手机产品在试产阶段的评测及相关功能重大更改时; 3.测试准备和说明: 3.1电池或程控电源,四通道数字示波器,相关机型的原理图及PCB丝印图,万用表(直流电 流档),原配耳机,各种不同类型的SIM卡至少三张以上,不同容量的TF卡至少三张,烙 铁,电批,细导线若干,SIM卡转接座(自制),100欧可调电阻器一个。 3.2各项测试前应确保手机基本功能正常; 3.3测试过程中必须配带静电环,确保静电安全; 3.4测试结果如有必要需附测试波形图; 3.5测试过程中示波器负极应就近接地,如有必要,测试结果应附波形图。 3.6 DP04034数字示波器的使用请参考指导:。 4.内容: 4.1 摄像头回路测试(测试用例编号: 5.1.1) 4.1.1 测试条件: 3.8V电源,示波器,相关机型的原理图及PCB图,细导线,电流表,拍照状态。 4.1.2 测试步骤: 1)手机开壳,根据原理图、PCB图找到摄像头AVDD/DVDD/CMRST脚,将数字示波器CH1,CH2,CH3分别接入手机AVDD,DVDD及CMRST端,负极接地。 2)示波器选用采样直流模式;电压标度设置1V/格,时间标度设为1S/格;添加测量幅值和最大值; 3)手机开机进入拍照模式,记录进入拍照过程中示波器的电压变化情况;测量VCAM-A 上升2/3到CMRST所需时间T1; 4)在VDD供电端串入一个电流表,测量摄像头工作状态的电流并记录。 4.1.3 预期结果: 摄像头工作电压、电流最大不应超过规格书要求的额定功率。 4.2 MIC偏置电压(测试用例编号: 5.1.2) 4.2.1 测试条件: 电源,示波器,原理图及PCB图,细导线,耳机,录音状态。 4.2.2 测试步骤:

视频信号指标与测试方法

1.视频信号幅度: 标准的视频信号幅度是1Vp-p,由两个测试指标组成: 1) 白条幅度(视频电平):700mV 2) 同步脉冲幅度:300mV 图1 视频信号 幅度对视频的影响: l 同步幅度:超出指标值会引起图像扭曲,甚至图像显示无法观看 l 白条幅度:超出指标值会造成图像过亮或过暗 2.亮度非线性 从消隐电平(黑电平)到白电平之间变化的线性度。 5级幅度的阶梯信号(每级140mV)通过被测通道后,计算相应各阶梯幅度值之间的最大差值.

图2 亮度非线性计算 亮度非线性对视频的影响: l 图象失去灰度,层次减少。 l 分辨率降低,产生色饱和度失真(由于色度信号是叠加在亮度信号上)。 3.K系数 把各种波形失真按人眼视觉特性给予不同评价的基础上来度量图象损伤,这里的失真是短时间波形失真。 一般用“2T正弦平方波失真”( K-2T)作为测试指标。

图3 2T脉冲 图4 K-2T计算 K系数对视频的影响: 导致图像出现多轮廓、造成重影,使清晰度下降。 4.微分增益(DG): 由图像亮度信号幅度变化引起的色度信号幅度失真。 5级带色度调制的阶梯信号通过被测通道后,计算各阶梯上的色度幅度值之间的最大差值。

图5 DG测试信号调制的五阶梯 图6 微分增益(DG)计算 微分增益(DG)对视频的影响 l 不同亮度背景下的色饱和度失真,影响彩色效果。比如:穿鲜红衣服从暗处走向亮处,鲜红衣服会变浓或变淡。 5.微分相位(DP): 由图像亮度信号幅度变化引起的色度信号相位失真。

5级带色度调制的阶梯信号通过被测通道后,计算各阶梯上的色度副载波的相位角和消隐电平上副载波信号的相位角之差,超前为正。 DP的测试信号与DG相同。 微分相位(DP)对视频的影响 在不同亮度背景下,色调产生失真,影响彩色效果。例如:鲜红衣服从暗处走到明处,鲜红衣服就偏黄或偏紫。 6.色度/亮度增益差 把一个具有规定的亮度和色度分量幅度的测试信号通过被测通道,输出端信号中亮度分量和色度分量幅度比的改变称色度/亮度增益差。 图7 20T脉冲

网站功能测试的方法

网站功能测试方法 功能测试就是对产品的各功能进行验证,根据功能测试用例,逐项测试,检查产品是否达到用户要求的功能。 针对Web系统的常用测试方法如下: 1. 页面链接检查:每一个链接是否都有对应的页面,并且页面之间切换正确。 2. 相关性检查:删除/增加一项会不会对其他项产生影响,如果产生影响,这些影响是否都正确。 3. 检查按钮的功能是否正确:如更新、取消l、删除、保存等功能是否正确。 4. 字符串长度检查:输入超出需求所说明的字符串长度的内容,看系统是否检查字符串长度,会不会出错。 5. 字符类型检查:在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错。 6. 标点符号检查:输入内容包括各种标点符号,特别是空格、各种引号、回车键。看系统处理是否正确。 7. 中文字符处理:在可以输入中文的系统输入中文,看会否出现乱码或出错。 8. 检查带出信息的完整性:在“查看”信息和“更新”信息时,查看所填写的信息是不是全部带出,带出信息和添加的是否一致。 9. 信息重复:在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否做出正确处理。

10. 检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”删除”,看系统如何处理,会否出错; 然后选择一个和多个信息,进行删除,看是否正确处理。 11. 检查添加和修改是否一致:检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填; 添加规定为整型的项,修改也必须为整型。 12. 检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错。同时,也要注意,会不会报和自己重名的错。 13. 重复提交表单:一条已经成功提交的纪录,“返回”后再提交,看看系统是否做了处理。 14. 检查多次使用“返回”键的情况:在有“返回”的地方,“返回”,回到原来页面,再“返回”,重复多次,看会否出错。 15. 搜索检查:在有“搜索”功能的地方输入系统存在和不存在的内容,看“搜索”结果是否正确。如果可以输入多个“搜索”条件,可以同时添加合理和不合理的条件,看系统处理是否正确。 16. 输入信息位置:注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方。 17. 上传下载文件检查:上传下载文件的功能是否实现,上传文件是否能打开。对上传文件的格式有何规定,系统是否有解释信息,并检查系统是否能够做到。 18. 必填项检查:应该填写的项没有填写时系统是否都做了处理,对必填项是否有提示信息,如在必填项前加*

高效空气过滤器检测方法

JL-12型高效空气过滤器检测方法 一、简介 在净化系统中,高效空气过滤器是高洁净度空气净化的关键设备,对于过滤器生产厂家,出厂的高效空气过滤器要求进行逐台检漏。目前,通行的高效过滤器检测方法有光度计扫描法和计数扫描法,这两种检测方法虽然普及率高,但扫描效率低,劳动强度大,对于特定结构的过滤器(如W型过滤器)无法进行检测。因此,目前市场亟须一种操作简便,检测效率高,检漏可靠的检测设备。 JL-12型高效空气过滤器检漏台是我公司顺应市场发展的趋势,基于高效过滤器能过滤烟雾的原理,在烟缕检测的基础上,自行开发研制出的新型检测设备。 二、JL-12型高效空气过滤器检漏台技术参数 ◆额定电压:220V/380V50HZ ◆额定功率: 3.56KW ◆最大检测工件尺寸:1200x700x300mm ◆最小检测工件尺寸:300x300mm 三、JL-12型高效空气过滤器检漏台性能特点 ◆发烟颗粒粒径为0.3~0.5um,粒径分布均匀,与计数扫描法发尘粒径一 致,能够满足高效过滤器检漏要求。 ◆适用范围广,能对各类有隔板及无隔板高效过滤器进行检测。 ◆检测效率高,单台过滤器检测时间最短只需2秒,有效节省检测时间,降低生产生成本。 ◆符合环保要求,设备发出的烟雾对操作人员无任何伤害。检测过程中几乎 无烟雾外排现象,对周边环境无任何影响。 ◆电气控制系统采用PLC控制,操作简便,工作可靠性高。 ◆设备所用的原料消耗品价格低廉,检测成本可以忽略不计,是目前国内检 测高效空气过滤器性价比最高的检测设备。 四、JL-12型高效空气过滤器检漏台操作说明 4.1开机前检查所接电源应符合使用说明书的要求,清理检漏台上的杂物。

【WebService】接口的测试方法

【WebService】接口的测试方法 有以下多种方式: 一、通过WSCaller.jar工具进行测试: 前提:知道wsdl的url。 wsCaller可执行程序的发布方式为一个wsCaller.jar包,不包含Java运行环境。你可以把wsCaller.jar复制到任何安装了Java运行环境(要求安装JRE/JDK 1.3.1或更高版本)的计算机中,用以下命令运行wsCaller: java -jar wsCaller.jar 使用wsCaller软件的方法非常简单,下面是wsCaller的主界面: 首先在WSDL Location输入框中输入你想调用或想测试的Web Service的WSDL位置,如“https://www.sodocs.net/doc/1417399224.html,/axis/services/StockQuoteService?wsdl”,然后点“Find”按钮。wsCaller就会检查你输入的URL地址,并获取Web Service的WSDL信息。如果信息获取成功,wsCaller会在Service和Operation下拉列表框中列出该位置提供的Web Service服务和服务中的所有可调用的方法。你可以在列表框中选择你要调用或测试的方法名称,选定后,wsCaller窗口中间的参数列表框就会列出该方法的所有参数,包括每个参数的名

称、类型和参数值的输入框(只对[IN]或[IN, OUT]型的参数提供输入框)。你可以输入每个参数的取值。如下图: 这时,如果你想调用该方法并查看其结果的话,只要点下面的“Invoke”按钮就可以了。如果你想测试该方法的执行时间,则可以在“Invoke Times”框中指定重复调用的次数,然后再按“Invoke”按钮。wsCaller会自动调用你指定的方法,如果调用成功,wsCaller会显示结果对话框,其中包括调用该方法所花的总时间,每次调用的平均时间和该方法的返回值(包括返回值和所有输出型的参数)。如下图:

接口自动化测试方案

接口自动化测试方案 2018年4月9日 文档编号:(V1.0) 目录 目录 1测试需求及范围 (2) 1.1测试目的 (2) 1.2测试需求 (2) 2测试方法 (3) 3测试工具及框架拓扑图 (3) 3.1测试工具 (3) 3.2自动化测试拓扑图 (3) 4流程示例 (3) 5测试环境 (5) 2.1硬件配置 (5) 2.2软件配置 (5)

6测试思路 (6) 6.1通用测试场景 (6) 6.2逻辑场景 (7) 6.3断言检查 (7) 1测试需求及范围 1.1测试目的 随着公司项目的不断增大,接口的服务随之增多,回归的任务量越来越大,需要对接口进行定时回归测试来保证系统的稳定性。 1.在开发提交新的接口前进行冒烟测试,以保证系统是能够正常开展测试的 2.功能测试完成/bug回归完成后进行回归测试,保证bug修改完成后没有引入新的问题 1.2测试需求 1、目前提供的接口多为Rest 规范的接口,需要使用JMeter进行自动化接口测试,核对接口入参及返回报文格式、内容的正确性,最终通过Jenkins持续集成生成测试报告。 2、对开发人员的需求 接口文档的规范,如:输入输出模板,输出类型是否全面

2测试方法 根据开发人员提供的接口访问地址、入参格式、请求格式,进行接口请求数据拼接,并查看返回结果及返回报文、响应时间,检查返回Json内容是否符合接口定义规范,是否符合预期的返回结果。 3测试工具及框架拓扑图 3.1测试工具 Jemeter+Jenkins 3.2自动化测试拓扑图 4流程示例 测试数据从csv或者txt文件里读取,包含入参、出参、预期结果/断言

线性测量方法

一、检验项目:原材料的线性成品线性 二、定义:量测待测物(以下简称为试片)测量电压值与理论电压值的误差 三、适用范围:本标准检验方法适用于公司所有须做线性测试之试片。 四、目的:本实验的目的在测试试片的导电情形是否良好。 五、检验方法: Ⅰ、方法一(适用于纳米银导电材料) 1. 样品准备:SNWFilm 2. 使用装置:激光机、万用表、稳压电源 3. 测量原理 a)在导电膜上刻上电极(宽度10mm),给电极加5V(DC)电压,然后用电压表测量待测 位置的电压,如图1所示 b)按图2所示分好测试点,(长220mm、23个测试点)A点、B点电压在所示位置取 得,10mm为距离测一个点 c)测量参数:E A:输出电压测量起点A处的电压 E B:输出电压测量终点B处的电压 E X:输出电压测量任意点X处的电压 E XX:理论计算电压 L:线性 计算公式: E XX(理论电压)=E AB*X/(B-A)+ E A L(%)= (︱E XX- E X︱)÷(E B- E A)×100 图 1

图 2 V A(0) mm 5V 0V EB 图 3 4. 操作步骤: a) 设计图纸,开好材料,覆膜 b) 激光镭射 c) 将稳压电源调至ON ,电压调至5V 。 d) 将稳压电源正极夹至右边银棒、负极夹至左边银棒。 e) 将万用表表负极夹至右边银棒,正极拿来测试。 f) 将试片置入定位,开始测试并记录分压值。 g) 将所测得之电压值输入表(一)~表(五),计算其线性。 Ⅱ、方法二(适用于成品) 1. 样品准备:成品

2. 使用仪器:线性测试机 3. 测量原理及要求 ※线性度的定义:当施加DC 5V在“X”方向电极和“Y”方向电极时,用笔(Special stylus)压点(X,Y)以得到各自输出电压(E OX,E OY)。如Fig.1(测量关系)。在A和B的区域内(Active area),在X,Y方向各以2mm为间隔划直线。如Fig2。 ※注:线性测量范围:A.A区边缘单边内缩2mm。 测量关系 测 量 Y 坐 标 Y (X+电极) Vcc (Y+电极) 测量X坐标 X Fig 2 ※计算公式:V XX(理论电压)=V AB*X/(B-A)+ V A L(%)= (︱V XX- V X︱)÷(V B- V A)×100 V A:输出电压测量起点A处的电压 V B:输出电压测量终点B处的电压 V X:输出电压测量任意点X处的电压 V XX:理论计算电压 L:线性 4. 操作步骤:见作业指导书 六、检验数据处理: 1、表(一):分压表&线性表。 2、表(二):线性错误及异常对照表。 3、表(三):线性错误及异常统计表。 4、表(四):平均线性分析图。 5、表(五):平均电压分析图。

高效过滤器检测方法

高效过滤器的检测方法 1:钠焰法Sodium Flame 源于英国,中国通行,欧洲部分国家于20世纪70?90年代实行。试验尘源为单分散相氯化钠盐雾。“量”为含盐雾时氢气火焰的亮度。主要仪器为光度计。 盐水在压缩空气的搅动下飞溅,经干燥形成微小盐雾并进入风道。在过滤器前后分别采样,含盐雾气样使氢气火焰的颜色变蓝、亮度增加。以火焰亮度来判断空气的盐雾浓度,并以此确定过滤器对盐雾的过滤效率。 国家标准规定的盐雾颗粒平均直径为0.4mm但对国内现有装置的实测结果为0.5mm欧洲对实际试验盐雾颗粒中径的测量结果为0.65mm 随着扫描法的普及,欧洲已经不再使用钠焰法。国内有关部门正在修订原有的国家标准,是废止还是继续使用钠焰法,两种意见的都没有结论。 相关标准:英国BS3928-1969,欧洲Eurovent 4/4,中国GB6165-85 2:DOP 法 源于美国,国际通行,中国从未实行过。试验尘源为0.3mm单分散相DOP(塑料工业常用增塑剂)液滴。“量”为含DOP空气的浑浊程度。测量粉尘的仪器为光度计(photometer)。以气样的浊度差别来判定过滤器对DOP?粒的过滤效率。 对DOP液体加热成蒸汽,蒸汽在特定条件下冷凝成微小液滴,去掉过大和过小的液滴后留下 0.3mm左右的颗粒,雾状DOP进入风道。测量过滤器前后气样的浊度,并由此判断过滤器对0.3mm 粉尘的过滤效率。 DOP法已经有50多年的历史,这种方法曾经是国际上测量高效过滤器最常用的方法。早期, 人们认为过滤器对0.3mm的粉尘最难过滤,因此规定使用0.3mm粉尘测量高效过滤器。 DOP中含苯环,人们怀疑它致癌,因此许多实验室改用性能类似但不含苯环的替代物,如DOS 但试验方法仍称“ DOP法”。 通过改变发尘参数,可以获得其它粒径的DOF液滴。于是就有20年前欧美国家测量超高效过滤器的0.1mmDOP法,有时测量仪器也改为凝结核激光粒子计数器。有些国外厂家曾标出对0.05mm 或0.03mm DOP勺过滤效率,那都是商业上无科学依据的标新立异。 测量高效过滤器的DOF法也称“热DOP法”。与此对应的“冷DOP是指Laskin喷管(用压缩空气在液体中鼓气泡,飞溅产生雾态人工尘)产生的多分散项DOP粉尘,在对过滤器进行扫描测试时,人们经常使用冷DOP 相关标准:美国军用标准MIL-STD-282。

接口测试方法

接口功能测试策略 分类:java 学习 2012-04-18 15:30 1105人阅读评论(0) 收藏举报 测试服务器数据库游戏平台网络协议 由于平台服务器是通过接口来与客户端交互数据提供各种服务,因此服务器测试工作首先需要进行的是接口测试工作。测试人员需要通过服务器接口功能测试来确保接口功能实现正确,那么其他测试人员进行客户端与服务器结合的系统测试过程中,就能够排除由于服务器接口缺陷所导致的客户端问题,便于开发人员定位问题。以下便是个人的平台服务器接口功能测试经验总结: 一、接口测试范围 根据服务器的测试需求,接口测试范围主要分为:1、新增接口的测试;2、新增业务功能接口测试;3、整个服务器的接口测试。所需测试测试接口依次增多,在测试时间足够的条件下,当然需要对所有接口进行测试用例的设计,但如果测试较短的情况下,则应该首先根据用户的典型操作对测试接口进行优先级划分,对调用频繁接口需要优先进行测试。 二、接口测试策略 在进行平台服务器接口测试之前,首先需要整理服务器接口的测试方案,分析接口测试的要点,平台服务器的接口测试内容主要有: 接口设计检查 接口用于服务器与客户端的数据交互,客户端通过网络协议传递的数据为服务器接口的输入数据,因此应该首先通过服务器接口文档及客户端数据约束文档进行交互数据的有效性检查: n 整数型数据位数 n 浮点型数据精度 n 字符串数据范围值 要求客户端的整数型、浮点型、字符串数据以及其最大值和最小值都能作为服务器接口的有效输入。这些工作在服务器设计评审时就可以进行,以便确保不会出现客户端上传数据被服务器自动进行截断或四舍五入的操作。 接口依赖关系检查 以上策略只谈到单个接口的测试方法,对于用户来说,一个操作可能会造成服务器调用多个接口来进行完成,因此还需要从业务处理的角度,对各种业务操作所涉及的多个接口之间依赖调用进行测试。

测试方案

目录 一. 相关检测测试仪器仪表 二. 相关检测项目及方法 三. 检测方案及价格

一. 相关检验测量仪器仪表

二相关检验项目及测试方法 第一节风量或风速的检测 (一)单向流洁净室 对于单向流洁净室,采用室截面平均风速和截面积乘积的方法确定送风量。离高效过滤器0.3m,垂直于气流的截面作为采样测试截面,截面上测点间距不宜大于0.6m,测点数不应少于5个,以所有测点风速读数的算术平均值作为平均风速。 (二)非单向流洁净室 对于非单向流洁净室,采用风口法或风管法确定送风量,做法如下: 1.风口法是在安装有高效过滤器的风口处,根据风口开头连接辅助风管进行测量。即 用镀锌钢板或其他不产尘材料做成与风口开头及内截面相同,长度等于2倍风口长边长的直管段,连接于风口外部。在辅助风管出口平面上,按最少测点数不少于6点均匀布置,使用风速仪测定各测点之风速。然后,以求取的风口截面平均风速乘以风口净截面积求取测定风量。 2.对于风口上风侧有较长的支管段,且已经或可以钻孔时,可以用风管法确定风量。 测量断面应位于大于或等于局部阻力部件前3倍管径或长边长,局部阻力部件后5部管径或长边长的部位。 3.对于矩形风管,是将测定截面分割成若干个相等的小截面。每个小截面尽可能接近 正方形,边长不应大于200mm,测点应位于小截面中心,但整个截面上的测点数不宜少于3个。 4.对于圆形风管,应根据管径大小,将截面划分成若干个面积相同的同心圆环,每个 圆环测4点。根据管径确定圆环数量,不宜少于3个。

第二节静压差的检测 1.静压差的测定应在所有的门关闭的条件下,由高压向低压,由平面布置上与外界最 远的里间房间开始,依次向外测定。 2.采用的微差压力计,其灵敏度不应低于2.0Pa。 3.有孔洞相通的不同等级相邻的洁净室,其洞口处应有合理的气流流向。洞口的平均 风速大于等于0.2m/s时,可用风速仪检测。 第三节空气过滤器泄漏测试 1.高效过滤器的检漏,应使用采样速率大于1L/min的光学粒子计数器。D类高效过滤 器宜使用激光粒子计数器或凝结核计数器。 2.采用粒子计数器检漏高效过滤器,其上风侧应引入均匀浓度的大气尘或含其他气溶 胶尘的空气。对大于等于0.5μm尘粒,浓度应大于或等于3.5×105pc/m3 ;或对大于或等于0.1μm尘粒,浓度应大于或等于3.5×107pc/m3;若检测D类高效过滤器,对大于或等于0.1μm尘粒,浓度应大于或等于3.5×109pc/m3。 3.泄漏率的检测应在接近设计风速的条件下进行。将受检高效过滤器下风侧测得的泄 漏浓度换算成透过率,高效过滤器不得大于出厂合格透过率的2倍;D类高效过滤器不得大于出厂合格透过率的3倍。 4.在移动扫描检测工程中,应对计数突然递增的部位进行定点检验(适合于FFU检测)。 第四节室内空气洁净度等级的检测 一) 空气洁净度等级的检测应在设计指定的占用状态(空态、静态、动态)下进行。 二) 检测仪器的选用:应使用采样速率大于1L/min的光学粒子计数器,在仪器选用时 应考虑粒径鉴别能力,粒子浓度适用范围和计数效率。仪表应有有效的标定合格证书。 三) 采样点的规定: ,见下表; 1.最低限度的采样点数N L

线性度

TP 线性度测试 一:线性度定义 备注: △ Ymax :输出平均值与最佳直线问的最大偏差 Ymax-Ymin :传感器的量程,是测量上限(高端)和测量下限(低端)的代数差 ? 以电阻屏为例:电阻式TP 由上下两个导电层构成,其等效电阻为Rx 、Ry 。测试时,先给X 向加基准 电压5V ,测试Y 向电压。因为触摸压力使两个导电层接触,通过计算测量Y 向电压就可以解析出触点Y 向基于相对零点的偏移量。同理可以测得X 向基于相对零点的偏移量。 在线性度测试中,根据所选定参考直线的不同,可获得不同的线性度 在不同衡量标准中,独立线性度足衡量线性特性的最客观标准(以最佳直线作为参考直线) 独立线性度定义为实际平均输 特性曲线对最佳直线的最大偏差,以满量程输出的分比来表示 Xmax-Xmin Lx=± △Xmax X 100% Ymax-Ymin Ly=± △Ymax X 100% Ymax Ymi Xmi Xma

二:测试原理 测试接触点的选择:在测试触摸屏线性度时,为了能够精确反应触摸屏的整体特性,需要选取尽量多的测 点。然而,对于测试时间与效率而言,希望选取尽量少的测试点。因此,在精度和效率之间需要选取一个平衡点。 线性度:支持并行线、垂直线、对角线、圆弧等多种图像来检测产品的线性偏差,可在测试区域内任意设 臵线距、线数及弧度大小,并支持两点同时划线、两点划圆等多种测试方式,达到更精确的体现产品特性; 灵敏度:可设定不同的划线轨迹,实现接触式划线或非接触式划线,触笔离产品的高度可按设定调节,并 能自动找出触控高度 在实际应用中,常用两个步进电机作为驱动装臵实现一个二维定位系统控制测试笔在触摸屏上打点,实现 测试的输入。 根据接触点输入集P (P1,P2,P2……….Pn-1,Pn )与输出集T (T1,T2,T3……Tn-1,Tn )中对应点的最大偏差 值即可求出整块屏的线性度 测试点分布示意 测试区域定位图

功能测试6步骤

功能测试大全 1、在测试过程中所用到的测试方法: 1,输入非法数据;2,输入默认值;3,输入特殊字符集;4,输入使缓冲区溢出的数据;5,输入相同的文件名; 2、登陆 ①用户名和密码都符合要求(格式上的要求)②用户名和密码都不符合要求(格式上的要求)③用户名符合要求,密码不符合要求(格式上的要求)④密码符合要求,用户名不符合要求(格式上的要求)⑤用户名或密码为空⑥数据库中不存在的用户名,不存在的密码⑦数据库中存在的用户名,错误的密码⑧数据库中不存在的用户名,存在的密码⑨输入的数据前存在空格⑩输入正确的用户名密码以后按[enter]是否能登陆⑾输入的密码是否以*显示⑿输入密码错误次数是否有限制 ⒀密码输入框测试时要特别注意进行字母大写输入的测试。 3、添加 ①要添加的数据项均合理,检查数据库中是否添加了相应的数据②留出一个必填数据为空③按照边界值等价类设计测试用例的原则设计其他输入项的测试用例④不符合要求的地方要有错误提示⑤是否支持table键⑥按enter是否能保存 ⑦若提示不能保存,也要察看数据库里是否多了一条数据⑧如果存在两条相同的记录是否也能添加成功 4、删除 ①删除一个数据库中存在的数据,然后查看数据库中是否删除②删除一个数据库中并不存在的数据,看书否有错误提示,并且数据库中没有数据被删除③输入一个格式错误的数据,看是否有错误提示,并且数据库中没有数据被删除。④输入的正确数据前加空格,看是否能正确删除数据⑤什么也不输入⑥是否支持table键⑦是否支持enter键 ⑧若记录与其它表的数据有关联,是否允许删除 5、查询 1)精确查询: ①输入的查询条件为数据库中存在的数据,看是否能正确地查出相应得数据②输入正确的查询条件前加上空格,看是否能正确地查出相应的数据③输入格式或范围不符合要求的数据,看是否有错误提示④输入数据库中不存在的数据⑤不输入任何数据⑥是否支持table键⑦是否支持enter键 ⑧ 要关注组合查询和分页控件 2)模糊查询: ①输入一些字符,看是否能查出数据库中所有的相关信息 6、设计功能和界面测试用例 6.1文本框、按钮等控件测试 6.1.1文本框的测试 a,输入正常的字母或数字。b,输入已存在的文件的名称;c,输入超长字符。例如在“名称”框中输入超过允许边界个数的字符,假设最多255个字符,尝试输入256个字符,检查程序能否正确处理;d,输入默认值,空白,空格;e,若只允许输入字母,尝试输入数字;反之;尝试输入字母;f,利用复制,粘贴等操作强制输入程序不允许的输入数据;g,输入特殊字符集,例如,NUL及\n等;h,输入超过文本框长度的字符或文本,检查所输入的内容是否正常显示;i,输入不符合格式的数据,检查程序是否正常校验,如,程序要求输入年月日格式为yy/mm/dd,实际输入yyyy/mm/dd,程序应该给出错误提示 6.1.2命令按钮控件的测试 a,点击按钮正确响应操作。如,单击确定,正确执行操作;单击取消,退出窗口;b,对非法的输入或操作给出足够的提示说明,如,输入月工作天数为32时,单击”确定“后系统应提示:天数不能大于31;c,对可能造成数据无法恢复的操作必须给出确认信息,给用户放弃选择的机会; 6.1.3单选按钮控件的测试 a,一组单选按钮不能同时选中,只能选中一个。b,逐一执行每个单选按钮的功能。分别选择了“男”“女”后,保存到数据库的数据应该相应的分别为“男”“女”;c,一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中,不能同时为空; 6.1.4控件文本框的测试 a,直接输入数字或用上下箭头控制,如,在“数目”中直接输入10,或者单击向上的箭头,使数目变为10;b,利用上下箭头控制数字的自动循环,如,当最多数字为253时,单击向上箭头,数目自动变为1;反之亦适用;c,直接输入超边界值,系统应该提示重新输入;d,输入默认值,空白。如,“插入”数目为默认值,点击“确定”;或,删除默认值,使内容为空,单击“确定”进行测试;e,输入字符。此时系统应提示输入有误。

高效空气过滤器检测方法介绍

高效过滤器试验方法 1)钠焰法Sodium Flame 源于英国,中国通行,欧洲部分国家于20世纪70-90年代实行。 试验尘源为单分散相氯化钠盐雾。“量”为含盐雾时氢气火焰特征光的光强。主要测试仪器为光度计。 原理(GB/T6165-2008):用雾化干燥的方法人工发生氯化钠气溶胶,气溶胶颗粒的质量中值直径约为0.5μm。将过滤器上下游的氯化钠气溶胶采集到燃烧器中并在氯化钠火焰下燃烧,将燃烧产生的钠焰光转变为电流信号并由光电测量仪检测,电流值代表了氯化钠气溶胶的质量浓度,用测定的电流值即可求出过滤器的过滤效率。随着扫描法的普及,欧洲已经不再使用钠焰法。 相关标准:英国BS3928-1969,欧洲Eurovent 4/4,我国有GB/T6165-2008。 2) 油雾法Oil Mist 原西德,原苏联,和中国采用过该方法。 尘源为油雾。“量”为含油雾空气的浊度。仪器为浊度计。以气样的浊度差别来判定过滤器对油雾颗粒的过滤效率。 原理(GB/T6165-2008):在规定的试验条件下,用汽轮机油通过汽化—冷凝式油汽发生炉人工发生油雾气溶胶,气溶胶粒子的质量平均直径为0.28μm~0.34μm。使经过与空气充分混合的油雾气溶胶通过被测过滤器,分别采集过滤器上下游的气溶胶,通过油雾仪(或浊度计)测量其散躲光强度。散射光强度的大小与气溶胶浓度成正比,由此即可求出过滤器的过滤效率。 德国规定用石蜡油,油雾粒径为0.3~0.5mm。中国标准规定的油雾平均重量直径为0.28~0.34mm,对油的种类未做具体规定。 油雾法在德国本土已经成为历史,德国于1993年率先搞出了计数扫描法的国家标准,欧洲标准EN1882就是以德国计数扫描法标准为蓝本制定的。 原苏联帮中国搞过滤器时使用的是油雾法,虽然中国标准规定可以用油雾法,但国内厂家更愿意使用同一标准规定的另一种钠焰法,只有部分生产滤材的厂家及少量军工单位依在测量过滤材料时仍使用油雾法。 相关标准:我国有GB/T6165-2008。德国DIN24184-1990 3) DOP法 源于美国,曾在国际通行。 试验尘源为0.3μm单分散相DOP(邻苯二甲酸二辛脂,一种塑料工业常用增塑剂)液滴。“量”为含DOP空气的浑浊程度。测量粉尘的仪器为光度计(photometer)。以气样的浊度差别来判定过滤器对DOP颗粒的过滤效率。 对DOP液体加热成蒸汽,蒸汽在特定条件下冷凝成0.3μm左右的微小液滴,雾状DOP 进入风道。测量过滤器前后气样的浊度,并由此判断过滤器对0.3μm粉尘的过滤效率。 DOP法已经有50多年的历史,这种方法曾经是国际上测量高效过滤器最常用的方法。早期,人们认为过滤器对0.3μm的粉尘最难过滤,因此规定使用0.3μm粉尘测量高效过滤器。 DOP法也称为气胶光度计测试法,是最早期的测试方式,但是因为效果非常好,到今天仍旧沿用。气胶光度计(Aerosol Photometer)是微粒计数器的一种,也是使用雷射科技,但是它在扫描空气样本的投料之后,所给的是微粒的总体强度,不是微粒数目。DOP是一种油性化学物质,加压或加热雾化之后,可以产生次微米等级的微粒,可用来仿真无尘室的微粒,因此被当成验证微粒。泄漏的定义是泄漏出上游浓度万分之一,由于气胶光度计可以

实验一输入输出接口实验

实验一输入、输出接口实验 一、实验要求 1、P1 口做输出口,接八只发光二极管。 2、P3.0,P3.1 作输入口接两个拨动开关 3.要求若P3.0单独闭合,则LED灯从L7-L0循环闪烁,每次亮一个,若P3.1单独闭合,则led灯从L0-L7闪烁,每次亮一个。若P3.0 P3.1同时闭合,则所有灯一起闪烁,闪烁间隔为1S。若P3.0 P3.1全部断开,则所有灯全不亮。 4、将闪烁间隔修改为30MS,观察现象。 二、实验目的 1、学习 I/0 口的使用方法。 2、学习延时子程序的编写和使用。 三、实验设备 1、IPC-610研华工控机一台, 2、伟福LAB2000P教学实验系统。 四、实验电路及连线 五、实验说明 1、P1口是准双向口。它作为输出口时与一般的双向口使用方法相同。由准双向口结构可知当 P1口用为输入口时,必须先对它置1。若不先对它置1,读入的数据是不正确的。 2、8051 延时子程序的延时计算问题,对于程序 Delay: MOV R6,#0H MOV R7,#0H DelayLoop: DJNZ R6,DelayLoop DJNZ R7,DelayLoop RET 查指令表可知 MOV,DJNZ 指令均需用两个机器周期,在 6MHz 晶振时,一个机器周期时间长度为12/6MHZ,所以该段程序执行时间为: ((256×2+2)×256+4)×2=263176

六、实验报告 1、解释为什么P1端口作为输入口时,需先对它置1,才能读取正确的外部输入数据? 2、画出完整的实验电路原理图 2、整理实验程序

连线 连接孔 1 连接孔 2 1 P1.0 L0 2 P1.1 L1 3 P1.2 L2 4 P1.3 L3 5 单脉冲输出 T0 实验二 外中断及定时、计数器实验 一、实验目的 1、掌握外部中断的运用方法,本实验中采用边沿触发模式。 2、学习 8051 内部 T0 T1 定时/计数器使用方法。 3、掌握中断处理程序的编程方法。 二、实验内容及要求 1、用单次脉冲申请外中断INTO ,采用边沿触发模式,在外中断处理程序中对输出信号灯LED6(P3.1控 制)进行反转(采用CPL 指令) 2、8031 内部定时计数器 T0,按计数器模式和方式2工作,对 P3.4(T0)引脚进行计数。将其数值按二进制数在 P1 口驱动 LED 灯上(L0,L1,L2,L3)显示出来。 3、用 T1作定时器中断方式计时,实现每一秒钟LED7(L7)(P3.0控制)灯闪烁一次 三、实验设备 1、IPC-610研华工控机一台。 2、伟福LAB2000P 教学实验系统。 四、实验电路及连线 注意: 本实验中,“单次脉冲”同时作为计数脉冲输入T0引脚,同时也引到引脚INTO 申请外部中断,本实验中将要求同时开放外部中断INTO 和T1的定时中断这两个中断。 五、实验说明 1、关于内部计数器的编程主要是定时常数的设置和有关控制寄存器的设置。内部计数器在单片机中主要有定时器和计数器两个功能。本实验T0使用的是计数器。T1使用的是定时器。 2.本实验中内部T0起计数器的作用。外部事件计数脉冲由 P3.4 引入定时器 T0。 单片机在每个机器周期采样一次输入波形,因此单片机至少需要两个机器周期才能 检测到一次跳变。这就要求被采样电平至少维持一个完整的机器周期,以保证电平在变化之前即被采样。同时这就决定了输入波形的频率不能超过机器周期频率。 3、定时器有关的寄存器有工作方式寄存器 TMOD 和控制寄存器 TCON 。TMOD 用于设置定时器/计数器 连线 连接孔 1 连接孔 2 1 P3.0 L7

传感器线性度的概念及表示方法

传感器线性度的概念及表示方法 1传感器线性度的概念 线性度是描述传感器静态特性的一个重要指标,以被测输入量处于稳定状态为前提。 线性度又称非线性,表征传感器输出—输入校准曲线(或平均校准曲线)与所选定的作为工作直线的拟合直线之间的偏离程度。这一指标通常以相对误差表示如下。 %100.max ??±=S F L y L ξ (1) 式中:max L ?——输出平均校准曲线与拟合直线间的最大偏差; S F y .——理论满量程输出。 由式(1)可见,拟合直线是获得相应的线性度的基础,选择的拟合直线不同,max L ?不同,计算所得的线性度数值也就不同。 2线性度表示方法 线性度表示方法很多,一般常用的有以下四种方法。 2.1理论直线法 理论直线法是以传感器的理论特性直线作为拟合直线,与传感器被测输出值无关。 例如:在一个标准大气压力试验条件下,设定被测温度传感器下限值为0℃,上限值为100℃,以测量范围为0℃~100℃的二等标准水银温度计作为标准计量器具,不管温度标定试验级数如何确定,均以标准水银温度计示值作为拟合直线,即试验各温度测试点温度传感器计算温度值均直接与该测试点标准水银温度计示值进行比较,从中获取max L ?,max L ?值即为被测温度传感器线性误差,暂名之以“理论线性度”。理论直线法示意见图1。 图1 理论直线法示意图 0 y x

2.2最佳直线法 通过图解法或计算机辅助解算,获得一条“最佳直线”,使得传感器正反行程校准曲线相对于该直线的正、负偏差相等且最小,如图2所示。由此所得的线性度称为“独立线性度”。 2.3端点直线法 以传感器校准曲线两端点间的连线作为拟合直线,这种方法可为称之为端点直线法,端基直线法,相应地线性度称之为端点线性度或端基线性度。端点直线法示意见图3。 图3 端点直线法示意图 端点直线法拟合直线方程为: kx b y += (2) 2.4最小二乘直线法 利用最小二乘原理获取拟合直线的方法称为最小二乘直线法。这种方法的基本原理是使传感器校准数据的残差的平方和最小。 最小二乘法拟合直线以式(2)表示,设定传感器校准测试点为n ,第i 个标准数据i y 的残差i ?为: )(i i i kx b y +-=? (3) 按最小二乘法原理,应使∑=?n i i 12 最小。因此,以∑=?n i i 12 分别对b 和k 求一阶偏0 x y 0

常用的测试方法和测试工具-1

常用的测试方法 一、黑盒测试 1.黑盒测试其实是一种功能测试,主要在软件的接口处进行。主要测试的以下几类错误: ·是否有不正确或遗漏的功能 ·在给出的接口处正确的输入是否有正确的输出 ·是否有数据结构错误或外部信息访问错误 ·性能上是否满足要求 ·是否有初始化或终止性错误 2.黑盒测试用例 ·等价类划分 等价类即输入域的子集合,测试用例设计时应设计出对应的有效等价类和无效等价类 ·边界值 边界值法是对等价类划分方法的补充,主要是测试发生在输入和输出域边界上的错误.等价类划分和边界值着重考虑输入条件,但测试时还应考虑输入条件之间的关系,各种条件的组合情况,即因果图 ·因果图 根据输入条件间的关系生成判定表,根据判定表的每一列来设计测试用例·功能图 包括状态迁移图和逻辑模型 二、白盒测试 1.白盒测试是对软件过程性细节做细致的检查。主要对软件程序模块做以下检 查: ·对模块的所有路径至少执行一次 ·对模块的所有逻辑判断,取“真”和“假”两种情况各执行一次 ·在循环边界和运行界限内执行循环体 ·测试内部数据结构的有效性 2.白盒测试用例 1)逻辑覆盖 ·语句覆盖 ·分支覆盖 对程序模块中的每个取真分支和取假分支执行一遍 ·条件覆盖 对程序模块中的每个判断的每个条件执行一遍 由于以上的测试用例都有较大的缺陷,所以一般不会使用,采用条件组合覆盖更为合理有效 ·条件组合覆盖(逻辑覆盖的主要方法) 2)基本路径测试用例 测试步骤: ①根据详细设计或源代码导出程序控制流图 ②计算程序环路复杂性,即独立路径的数目(一条新的路径必须包含

一条新边) ③生成测试用例(辅助工具:图形矩阵) 测试策略 一、单元测试 1.单元测试时主要对模块的以下5个方面进行检查: ·模块接口 ·局部数据结构 ·边界条件 ·独立路径 ·出错处理 二、集成测试 1.集成测试时主要要考察程序的以下几个方面: ·各个模块连接时,穿越模块接口的数据是否会丢失 ·一个模块是否会对另一个模块的功能产生不利的影响 ·各个子功能组合起来,能否达到预期的父功能 ·全局数据结构是否有问题 ·单个模块的误差累积起来,是否会被放大,从而达到不可接受的程度 2.集成测试的组织和实施中考虑的因素: ·选用何种系统集成方法来进行集成测试 ·各个模块连接的顺序 ·模块代码编制和测试进度是否集成测试的顺序是否一致 ·测试过程中是否需要有专门的硬件 3.集成测试完成的标志 ·成功执行了测试计划中规定的所有组装测试 ·修正了所发现的错误 ·测试结果通过了专门小组的评审 三、确认测试 1.确认测试流程: ·进行有效性测试,即在模拟的环境下(可能是开发环境),运用黑盒测试的方法,验证所没软件是否满足需求说明书列出的需求。对于测试结果与预期结果不相符进,要提交一份问题报告。 ·软件配置复查 软件配置复查的目的是保证软件配置的所有成份都齐全,各方面的质量都符合要求。 ·a测试和?测试 a测试是一个用户在开发环境下进行的测试,也可以是开发机构内部的用户在模拟实际操作环境下进行的测试。?测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试 ·验收测试 验收测试时软件开发人员和QA人员也应参加,由用户参加设计测试用例,使用用户界面输入测试数据,并分析测试结果。

高效设计测试用例

高效设计测试用例(总结) 第一章:软件测试用例 测试用例的概念:为实施测试,向被测试系统提供的输入数据、操作、环境的设置以 及预期结果的一个特定的集合。 编写测试用例的好处: v组织性:编写测试用例有利于测试的组织。 v功能覆盖:测试用例可以确保功能不被遗漏。 v重复性:在项目进行期间对不同的版本必须要多次重复执行同样的测试,以寻找新的软件缺陷,保证老的软件缺陷已被修复。 v跟踪:通过对测试用例的统计,以确定下一步的测试重点,缺陷多的模块在后续测试中进行重点测试。 v测试确认:在少数高风险的测试中,必须证明确实按照设计执行了所有的测试用例。探索性测试用来加强测试,不能用他来代替其他的测试。 更新和维护测试用例 在测试过程中,测试用例并不是一成不变的,需要不断的更新和维护: v无论测试人员在开始执行测试之前把测试用例设计得如何好,开始执行测试后,肯定又会考虑编写新的测试用例。 v在实际项目中,所有的需求、设计很早就形成了文档,并且可以利用的情况非常罕见。 测试用例必须在开发流程的每个阶段不断的发展。 v在执行测试时,测试人员会了解到关于该系统的更多知识,设计出新的测试用例。 v测试用例可以用配置管理系统来维护。 第二章:通用的测试技术 方法一:等价类划分 概念:等价类划分发作为一种最为典型的黑盒测试方法,他完全不考虑程序内容结构,而只是根据对程序的要求和说明进行测试用例的设计。

划分等价类的步骤: 1.划分等价类。 2.建立等价类表。 3.确定测试用例。 ?为等价类表中的每一个等价类分配一个唯一的编号。 ?设计一个新的测试用例,使他能够尽量覆盖尚未覆盖的有效等价类。(重复这一步,从而使所有有效等价类均被测试用例所覆盖) ?设计一个新的测试用例,使他只能覆盖一个无效等价类。(重复这一步,从而使所有无效等价类均被测试用例所覆盖) 4.细画等价类。 等价类的特点: v测试的内容相同。 v如果等价类中的一个测试能够捕获一个缺陷,那么选择该等价类中的其他测试也能捕获该缺陷。 v如果等价类中的一个测试不能捕获缺陷,那么选择该等价类中的其他测试也不会捕获缺陷。 等价类划分中的核心要点: v若某个输入条件说明了一个必须成立的情况,则可划分一个有效等价类和一个无效等价类。 v若某个输入条件对取值范围或值的个是数进行了规定,则可以确定一个有效等价类和两个无效的等价类。 v如果输入条件一个布尔量,则可以确定一个有效等价类和一个无效等价类。 v若在某个输入条件中对输入数据的一组可能值进行了规定,并且程序是用不同的方式处理每一种值的,则可以为每一种值划分一个有效等价类,并针对这组值确立一个无效等价类,他是所有不允许的输入值的集合。 v如果规定了输入数据必须遵守的规则,则可以确定一个有效等价类和若干个无效等价类。 v若已划分的某等价类中的各个元素在程序中的处理方式不同,则应当将此等价类进一步划分更小的等价类。 划分等价类要注意的问题: v考虑有效等价类,同时也要考虑无效等价类。 v利用有效等价类生成的测试用例,可以检验程序是否实现了需求规格说明书中预先规定的功能和性能。 v利用无效等价类生成的测试用例,可以检查程序中的功能和性能的实现是否不符合规格说明要求。 v仔细划分,审核划分。 v等价类的目标就是把所有可能的测试用例组合数量缩减到仍然足以测试软件的范围。方法二:边界值分析

相关主题