-
接口测试(转摘)
2010-01-08 14:32:01
好久没写东西了。人都是有惰性的,作为一个测试人员,应该定期的检查与反省自己,写些工作和生活总结。
今年没什么进步,该敲响警钟了。
测试代码都会分成以下几个部分:
* Caller
对开发接口函数调用的包装,使得案例有一个统一的入口调用开发的函数。开发接口函数变动,只需要变动我们的Caller。(封装变化)
* Checker
对接口函数调用的验证方式的封装。对被测函数的返回值检查是最基本的,更多的时候,返回值并不能告诉你一切,返回值告诉你它做了什么,但它没有证明给你看它确实做到了
* DataDefine
测试数据是必不可缺的,我将测试数据单独抽离出来,方便管理和组织。
* TestFixtureBases
TestFixture的基类,这是我喜欢使用的方式,定义某一类案例的基类,它们做同样的SetUp和TearDown,共享同样的函数调用。
* TestCases
最终到了测试案例这一分类,如果我们把上面的四个分类都做好了,就会发现,测试案例都可以使用一种非常简洁的方式来表达。在我看来,一个测试案例代码,五行左右代码是最优美的。
* (附加)CommonSpec
有时候,为了让测试案例更加容易理解,我还喜欢使用BDD的方式表述测试案例。因此,我个人可能还会有一个分类叫CommonSpec,定义的一些自然语言相关的函数。可能这个并不一定适合每个人。
5. 上周五去听了一个关于软件架构师的课程,总结一下大约有如下几点收获:
* 架构师首先要明白真正需要解决的问题是什么。例子:老太太买梨
* 一个优秀的架构师,必须有一套自己明确的方法论。
* 政治->经济->技术,架构师容易只看到技术上的问题,其实有时技术问题并不是最大的问题。
* 架构师是参谋长,也是辅导员。有了自己的架构设计,还要将自己的架构设计描述清楚,并推动设计方案的实施。
* (概念部分)架构师的定义,分类,架构设计的过程等等。
. 质量评估标准(淘宝):
* 接口覆盖率是否达到要求。内部接口90%,外部接口95%。
过度要求高的代码覆盖率,可能会造成反面影响。
* 测试用例中对接口业务规则的验证是否完整。
关键词:业务规则,保证了业务规则,就保证了用户使用的大部分功能。
* 测试用例中是否覆盖接口之间的关联性测试。
* 遗留的 bug对系统的影响程度。
* 测试用例与测试代码是否一致。
1. 能一定程度上说明测试覆盖的广度。
2. 通过代码覆盖率结果,能够比较直观的了解到哪些代码未被测试,哪些分支未被覆盖,进而补充相应的测试案例。
3. 代码覆盖率具有非常好的可操作性,可以在一定程度上衡量测试人员的工作。
4. 代码覆盖率给程序员和测试人员以信心。
但是,即使你的代码覆盖率达到了80%或者更高,不要被代码覆盖率蒙蔽了双眼!
1. 好好回想一下覆盖的80%的代码中,你一共发现了几个Bug?
2. 剩下的20%代码,极有可能产生80%的Bug!
3. 覆盖的80%代码中,你真正进行验证的代码函数有多少?
4. 覆盖的80%代码中,你真正了解的代码有多少?或者说,有多少代码是无意间被执行的。
5. 你是否保证了不同操作系统下测试案例的执行?
6. 这80%覆盖的代码中,你是否偷懒省去了某些复杂的检查点的检查?
7. 你是否会因为某个分支只有一行代码,而省去这个分支的测试案例?
8. 你是否存在一个检查点也没有的测试案例?
看了上面的8条,再想想你的80%代码覆盖率,还会感觉测试已经完全,无事可做了吗?
代码覆盖率只是一个最基本的前提,一定要保证,但不是意味着达到指标就代表测试的完成。
永远要记住,80%的代码覆盖率也许只是刚刚开始,被测试代码中到底潜藏有多少Bug,谁也不知道!
我们主要通过CodeReview和自己的人品,并没有做太多严格的审核。
* 测试用例是否可持续回归。
* 经过测试的接口是否达到了调用方的标准,调用方能否使用该接口来开发出产品设计说明书所设计的应用。
-
6门课程和测试的关系
2009-07-18 15:31:10
1、C 或C++ 或Java 和测试
不管是什么语言,在将来的测试工作中起到两个作用:
1)看懂开发人员写的代码,需要掌握基本概念,比如面向对象,以及基本语法和基本
编程思路
2)能编写简单的代码,为编写自动化测试脚本和测试代码做准备,将来测试用到的可
能是其它编程语言,比如tcl、perl 等,但都是类似的
需要做到能进行简单的编程,能准确使用循环、判断等语句
2、数据结构和测试
数据结构比较抽象、复杂,在将来的测试工作中起到两个作用:
1)看懂开发人员写的代码,程序等于数据结构加算法,不懂基本的数据结构和算法很
难看懂现在开发人员写的代码
2)锻炼逻辑思维能力,测试除了需要细心耐心之外,还需要很强的逻辑思维和分析能
力,而且是测试能否做好的关键
需要做到能编写基本的算法,搞清各数据结构的定义、特点和表示方法
3、操作系统和测试
应用软件都需要在操作系统上来运行,因此操作系统对于软件研发而言很重要,对于将
来的测试工作而言,主要和测试环境的搭建关联起来
需要做到:
1)安装、配置各种操作系统,如linux 等
2)在操作系统下进行熟练的操作,如输入命令等
3)了解操作系统的基本功能、基本参数,如虚拟内存等
4、数据库和测试
现在流行的web系统一般都带有数据库,因此数据库在当前的软件研发中非常重要,对
于将来的测试工作而言,不仅涉及到测试环境的搭建,还涉及到测试结果的检查
需要做到:
1)了解数据库基本原理和基本概念,如存储过程、事务、视图等
2)数据库的安装和配置
3)常用SQL 语句的编写
5、计算机网络和测试
和数据库类似,现在网络也是非常重要的,越来越多的单机软件变成了web软件,对于
将来的测试工作而言,不仅涉及到测试环境的搭建,还涉及到测试结果的检查
需要做到:
1)了解OSI 的7 层模型,搞清各层的作用
2)了解tcp/ip 协议
3)了解常见的应用层协议,如http 、ftp 等
6、计算机组成原理和测试
计算机组成原理涉及到计算机的硬件组成,对于将来的测试工作而言,主要涉及到测试
环境的 -
较好的测试方法
2007-12-26 18:12:11
微软在软件测试方面有很多值得一提的经验,在此我想以我个人的体会和思考,同大家一同进行一些探讨。这里有一点须要特别说明,尽管微软的方法已被微软的实践多次证明是成功的,非常有效的,但这并不意味着这些方法在中国的软件企业中有广泛的可行性。一种方法是否可行还受到很多其他因素的影响,比如企业类型(微软是生产平台软件和通用软件产品的企业),企业管理体制,企业文化等等。所以我的目的只是给大家一些思路和借鉴。两类经典的软件测试方法 在具体介绍微软的软件测试方法之前,我想首先从概念,或理念的层面上来理解究竟甚么是软件测试,目的是从中导出微软测试方法的理论根源。传统上认为软件测试的方法从总体上分为两类。第一类测试方法是试图验证软件是“工作的”,所谓“工作的”就是指软件的功能是按照预先的设计执行的;而第二类测试方法则是设法证明软件是“不工作的”。提出第一类方法的代表人物是软件测试领域的先驱Dr. Bill Hetzel(代表论著《The Complete Guide to Software Testing》),他曾于1972年6月在美国的北卡罗来纳大学组织了历史上第一次正式的关于软件测试的论坛。他首先在1973年给软件测试一个这样的定义:“就是建立一种信心,认为程序能够按预期的设想运行。Establish confidence that a program does what it is supposed to do. ”后来在1983年他又将定义修订为:“评价一个程序和系统的特性或能力,并确定它是否达到预期的结果。软件测试就是以此为目的的任何行为。 Any activities aimed at evaluating an attribute or capability of a program or system. ”在他的定义中的“设想”和“预期的结果”其实就是我们现在所说的用户需求或功能设计。他还把软件的质量定义为“符合要求”。
第一类测试可以简单抽象地描述为这样的过程:在设计规定的环境下运行软件的功能,将其结果与用户需求或设计结果相比较,如果相符则测试通过,如果不相符则视为Bug。这一过程的终极目标是将软件的所有功能在所有设计规定的环境全部运行,并通过。在软件行业中一般把第一类方法奉为主流和行业标准。1990年的IEEE/ANSI标准将软件测试进行了这样的定义:“就是在既定的状况条件下,运行一个系统或组建,观察记录结果,并对其某些方面进行评价的过程。The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component (IEEE/ANSI, 1990 [Std 610.12-1990]”这里所谓“既定的状况”也可理解为需求或设计。
尽管如此,这一方法还是受到很多业界权威的质疑和挑战。代表人物是Glenford J. Myers(代表论著《The Art of Software Testing》)。他认为测试不应该着眼于验证软件是工作的,相反应该首先认定软件是有错误的,然后去发现尽可能多的错误。他还从人的心理学的角度论证,将 “验证软件是工作的”作为测试的目的,非常不利于测试人员发现软件的错误。于是他于1979年提出了他对软件测试的定义:“就是以发现错误为目的而运行程序的过程。The process of executing a program or system with the intent of finding errors.” 这就是软件测试的第二类方法,简单地说就是验证软件是“不工作的”,或者说是有错误的。他甚至极端地认为,一个成功的测试必须是发现Bug的测试,不然就没有价值。这就如同一个病人(假定此人确有病),到医院做一项医疗检查,结果各项指标都正常,那说明该项医疗检查对于诊断该病人的病情是没有价值的,是失败的。我并不完全同意这一看法。第二类软件测试方法在业界也很流行,受到很多学术界专家的支持。大家熟悉的Ron Patton在《软件测试》( 中文版由机械工业出版社出版,具说此书是目前国内测试新手入门的经典教材)一书的第10页,有一个明确而简洁的定义:“软件测试员的目标是找到软件缺陷,尽可能早一些,并确保其得以修复。”有些软件企业以Bug数量来作为考核测试人员业绩的一项指标,其实就是接受了这样的方法。
两类方法的优劣对比 虽然软件测试总的目的是为了软件产品的质量,但很明显这两类测试方法在具体目标、或指导思想上截然相反。由此也决定了它们在思路、过程和测重点上有很大的差别,并各有利弊的。第一类测试方法以需求和设计为本,因此有利于界定测试工作的范畴,更便于部署测试的侧重点,加强针对性。这一点对于大型软件的测试,尤其是在有限的时间和人力资源情况下显得格外重要。而第二类测试方法与需求和设计没有必然的关联,如果计划管理不当,测试活动很容易丢失重点,走入歧途。第一类测试方法可以与软件的架构和软件开发的计划相配合,使软件测试活动逐层次的展开,从而使软件的功能和质量有计划地逐步完善和提高(关于测试的层次问题,我会在今后的讨论中专门介绍)。第二类测试方法不具备这种过程的渐进性。第一类测试方法的缺点是缺乏灵活性,不利于测试人员主观能动性的发挥,正像Myers先生所说,不容易找到软件的错误(Bug)。而这方面正是第二类测试方法的长处。 微软的策略 正是因为认识到两类测试方法各有利弊,微软在软件测试活动中将两类方法结合起来,以第一类测试方法为基础和主要线索,阶段性地运用第二类测试方法。 微软的第一类测试 微软的第一类测试总体上说分为三个步骤进行:审核需求和设计—〉设计测试—〉实施运行测试。前文已述,第一类测试是以需求和设计为本来验证软件的正确性。大家很自然的想到,需求和设计本身也有正确性的问题。依据不正确的需求和设计不可能开发出正确的软件产品,测试也将是徒劳的。因此验证需求和设计是微软进行第一类测试的第一步。有必要指出的是,这里所说的需求和设计具体说来它一般包括:(1)由项目经理根据用户要求(信息来源于市场部门,用户支持部门等等)而编写的需求文本(Requirement Specification);(2)由项目经理根据需求文本而编写的功能设计文本(Functional Design Specification);(3)由开发人员根据功能文本而编写的实施设计文本(Implementation Design Specification)。微软的测试人员要参与所有这些文本的审核。作为测试人员,审核重点是检查文本对用户需求定义的完整性、严密性和功能设计的可测性。同时这种审核对于测试人员也是一种热身活动,使他们尽早地进入技术和业务状态。第二步,测试人员要根据已审核通过的需求和设计编制测试计划,设计测试用例。在前面提到的三种文本中,功能设计文本是主要依据。原因很简单,这类测试关心的是软件是否能正确地实现功能,而不是这些功能如何被具体实施的。从这里大家可以看出这是典型的“黑盒测试”。确实微软的测试主要是从用户角度进行的黑盒测试。这一步的完成就意味着“测试计划”和“测试用例设计”两个文本的完成。“测试计划” 文本主要阐述测试的范畴、领域、方法、工具、资源和计划时间表等等。“测试用例设计”文本要列出测试用例、每个用例的设置、执行步骤和预期结果。测试的这两个文本也要被项目经理和开发人员审核。这样经过各种相互的审核,大家对项目形成了基本的共识。第三步的实施运行测试是整个开发过程中最长最复杂的一个阶段。从总体上说就是将上一步设计的测试用例按计划付诸实施的过程。这包括编写自动化测试程序、反复运行自动化测试程序,也包括阶段性执行手动测试用例。这一阶段的测试必须在周密的计划下进行,在前面我已提到,这正是第一类测试的特点和长处。这种计划性首先体现在开发和测试的相互协调配合,根据产品的架构和功能模块的依赖关系,按照项目的总体计划共同推进。从测试的过程来看,总是先运行或执行简单用例,然后再复杂用例;先验证单一的基本功能,再综合的端到端的功能;先发现解决表面的,影响面大的Bug,再深层的,不容易重现的Bug。因此随着项目开发和测试的进程,产品的功能不断完善,质量不断提高。这里有一点要特别指出,有很多测试用例是要反复运行的,特别是基本的自动化测试每一天,每一个Build上都要运行。尽管这些测试大多数情况下都是通过的,很少再发现新的Bug,但其价值是显而易见的,就是为了防止质量回归。可见Myers的理论在这里是不适用的。这一阶段测试人员还有一项繁琐但却很重要的工作,就是对已有的测试用例的维护。比如通常以下两种情况下要新增一些测试用例,一是对于当初测试设计不周全的领域,二是对于外部的Bug(比如从Beta客户报告来的),没有被现有测试用例所覆盖。当产品的功能设计出现更改时(在微软这是常事),所涉及的测试用例当然也要相应地修改。 微软的第二类测试 微软的第二类测试是阶段性的,常常根据需要而带有随机性和突击性。对于这类测试,在微软有一个专门的名称:“Bug Bash(Bug大扫除)”。 Bug Bash通常发生在项目开发各阶段(微软叫里程碑)的末期,比如Beta版发布前,划出一个专门的时间段(通常1-3天),在这期间所有参与项目的人员,集中全部精力,运用各方面的知识,尽全部智慧来搜寻项目的Bug。这是一个非常有意思的活动,但要组织好这样的活动并非易事。一般有以下要点:(1)尽管这是一个测试活动,但参与者并不仅限于测试人员。项目经理,开发人员甚至于高层管理人员都应参加,如同全民动员。目的是要集思广益;(2)要鼓励各部门,领域交叉搜索,因为新的思路和视角通常有助于发现更多的Bug;(3)为调动积极性,增强趣味性,可以适当引入竞争机制,比如当活动结束时,评出发现Bug最多,发现最严重Bug的个人,给以物质和精神奖励。(4)可以分专题展开,比如安全性、用户界面可用性、国际化和本地化等等。微软的第二类测试除了Bug Bash外,经常还有一些专业性的测试,最典型的是针对安全性攻击测试。一般会邀请公司内部,或业界的专家来搜寻产品的安全漏洞。 以上我从传统软件测试概念的角度,介绍了微软的策略和两类传统测试方法的具体做法,及其侧重点。这其实仅仅是一个基础,一个很原始的基础。软件测试在微软软件产品开发中的作用、地位远不是这些原始的方法所能达到的,也不是传统软件测试概念所函盖的。微软在软件测试方面有很多特有的做法,和概念上的突破,比如“软件测试的信息服务功能”、“以用户为中心的宏观质量体系”、“分级测试”、“项目的质量管理系统”、“Bug三方会审”、“测试自动化”和“软件测试的软硬件—部门、团队、人和基础设施”等等。这些我会在以后的讨论中分专题进行介绍。
测试何时结束? 在按计划结束的那一天结束! 我这个答案你听了一定不满意。但这个答案告诉你微软所依据的最基本的原则,这就是计划。在我前面介绍微软的第一类测试时我提到“测试计划”,这个“测试计划”实际上就是要回答测试的投入问题,包括人力资源、时限和过程。确定测试计划有这么几个依据:1)产品的功能。功能的量和复杂性直接影响测试的工作量;2)质量标准,有公司的标准、行业的标准、市场反馈的标准和客户要求的标准等;3)以往的经验,有以往的产品的经验,也有个人的经验。这一“测试计划”还要被项目的各方(开发,项目管理)审核通过,从而在整个产品部门形成一种共识,这种共识最终被纳入项目总体计划的一部分。对于第二类测试,它也是总项目总体计划的一部分,而且量也是可知的。一般地说在每个里程碑都会有几个分专题的“Bug Bash”,每次历时1-3天。在微软的项目计划书中总有那么一天,叫做“测试完成日 Test Complete Day”。它标志着所有计划的测试活动已全部完成,所有被发现的Bug被全部解决,并被测试所验证(有一些会因为某些原因被研究决定推迟解决)。 对于以上的分析你也许仍然不满意:难道微软的计划总能按期完成吗?当然不是,逾期的情况时常会有。几乎可以肯定,项目的实际执行与预先的计划一定会有或多或少的差距。微软会在项目过程中采取一些方法来感知这种差距,比如bitter提到的代码“覆盖率”分析和bug数量的变化趋势分析等。目的是为了尽早地发现差距,重新评估和修订计划。这样计划可以变化,但测试总是在计划结束的那一天结束。
对于TL_geong提到的随机测试造成收敛的缺陷趋势出现严重的发散现象,在微软也有。通常Bug Bash会产生超乎寻常数量的Bug。一般我们认为,产生Bug的量越大越好。因为,如果产生Bug的数量少,你很难判断是因为产品的质量确实很高,还是Bug Bash做得不彻底。而且事实往往是后者。 那么对Bug Bash所产生的大量Bug该怎么办?在微软,我们有“Bug Triage (测试,开发和项目管理,三方会审)”的制度。对于每个Bug,经过会审后不外乎有以下三中归宿(总体上来说): (1)被确认为“缺陷性”Bug,这样的Bug必须交开发人员解决,然后由原发现人验证。 (2)被调整为非“缺陷性”Bug,不用开发人员作任何更改,但必须将问题纳入产品用户文档,明确向用户解释,并告诉用户如何避免和应对。比如这里举一个假想的例子:产品的某个功能在系统内存严重不足的情况下,会暂时停止工作,并生成很多不易被用户理解的警告信息。这显然是个Bug(按微软的标准),正确的应该是,首先软件不应该完全停止工作,其次不应该多次警告,第三,警告信息应简明易懂,并给用户以措施和建议。但是考虑到,一方面这种情况在用户实际使用产品时发生的机率很低,而另一方面,从开发角度,解决这个问题有很大的技术难度,影响面也太大。这种情况下会把这个Bug改为“文本性”Bug,也就是要求文本遍写人员将这一情况作一技术性解释,并建议用户不要将此产品同其他消耗大量内存的软件同时使用。这类的Bug在Bug Bash中很常见,因为大家在这种测试活动中思维方式比较超常。 (3)被完全否定,立刻关闭,不再纠缠。这类的情况在Bug Bash中也很常见。因为参与Bug Bash人并不都很了解产品功能的准确用法,误报是难免的。尽管对这类问题没有直接的后续措施,但这些信息仍然是有一定价值的,因为将来用户中的新手很可能会犯同样的毛病,而产品支持部门如果预先有这样的经验,就能及时准确地提供帮助。所以这些信息要保存在Bug的管理库中,以备将来产品支持部门查询。 经过这样的会审,筛选,如果(1)(2)类Bug,特别是(1)类Bug仍然很多,那测试部门很可能需要重新论证原先的测试计划和测试用例设计,看是否需要增加测试用例。必要时还要尽早提出更改项目总体计划和发布日期。 大量Bug的出现也许不是件愉快的事,但和把这些Bug留给用户相比,代价要小得太多了。总之对于产品的Bug,要相对待身体的疾病一样,切末讳疾忌医。
微软的软件测试方法(二) 我在前一篇“微软的软件测试方法”中介绍了微软的两类基本测试方法,其基本思想大家应该是比较熟悉的,因为它们还只是传统的软件测试方法的综合。所以单从形式上,它并没有体现出对传统框架的突破。但是从另一个层面来考察微软软件测试时,你会对一些基本的事实感到惊讶。比如,“微软的测试人员和开发人员数量大致相等或略多”,“微软的产品成本中测试大约占40%以上”等等。人们会有疑问,仅仅是作为功能验证和搜寻Bug的测试能消耗这么大量的资源吗?有必要付出如此大的代价吗?应该有理由相信,微软作为一个软件企业,其每一份投入都是有意义的,因此也可断定微软在软件测试方面的努力一定超出传统测试方法的范畴。历史回顾 为了更好的理解微软件测试在方法和理念上的突破,我想首先回顾一下软件开发和软件测试的发展历史,并从中揭示其必然性。Edward Kit 在他的畅销书“Software Testing In The Real World : Improving The Process(1995, ISBN: 0201877562)”中将整个软件开发历史分为三个阶段:
第一个阶段是60年代及其以前,那时软件规模都很小、复杂程度低,软件开发的过程随意。开发人员的Debug过程被认为是唯一的测试活动。其实这并不是现代意义上的软件测试,当然一阶段也还没有专门测试人员的出现。
第二个阶段是70年代,这个阶段开发的软件仍然不复杂,但人们已开始思考开发流程问题,并提出“软件工程Software Engineering”的概念。但是这一阶段人们对软件测试的理解仅限于基本的功能验证和Bug搜寻,而且测试活动仅出现在整个软件开发流程的后期,虽然测试由专门的测试人员来承担,但测试人员都是行业和软件专业的入门新手。
第三个阶段是80年代及其以后,软件和IT行业进入了大发展。软件趋向大型化。与之相应,人们为软件开发设计了各种复杂而精密的流程和管理方法(比如CMM和MSF),并将“质量”的概念融入其中。软件测试已有了行业标准(IEEE/ANSI ),它再也不是一个一次性的,而且只是开发后期的活动,而是与整个开发流程融合成一体。软件测试已成为一个专业,需要运用专门的方法和手段,需要专门人才和专家来承担。 测试与开发的融合 在这一历史发展过程中,最值得注意的是测试与开发流程融合的趋势。人们对这种融合也许并不陌生。比如测试活动的早期展开,让测试人员参与用户需求的验证,参加功能设计和实施设计的审核。再比如测试人员与开发人员的密切合作,随着开发进展而逐步实施单元测试、模块功能测试和系统整合测试。的确这些都是测试与开发融合的表现形式,而且初期的融合也只反映在这个层次上。
90年代以后,软件的规模和复杂程度迅速提高,这种形式上的融合也迅速走向更深层次,更具实际意义。具体地说这种融合就是整个软件开发活动对测试的依赖性。传统上认为,只有软件的质量控制依赖于测试,但是现代软件开发的实践证明,不仅软件的质量控制依赖于测试,开发本身离开测试也将无法推进,项目管理离开了测试也从根本上失去了依据。在微软,测试的确有这样的地位和作用。这就是为什么微软在软件测试上有如此大的投入。 开发对测试的依赖 现代软件开发,特别是大型软件开发通常会遇到以下两个问题: (1) 在开发初期,如何能够展开大规模团队,群体齐头并进,而同时保持开发的有序性。从而有效利用资源,缩短开发周期。(2) 在开发后期,如何解决深层次的Bug,如何面对设计更改,而能够保证产品的质量不出现或少出现回落。 对于小型简单的软件,这两个问题也存在,但不突出,而且容易解决。但对于复杂的大型软件的开发,这两个问题常常会成为难以逾越的障碍。 通常大型项目的功能丰富,但架构、层次也会相当复杂。稳妥的开发方式是,一次投入少量的人员,逐层开发,逐层稳定。但这种方式显然资源利用率低,开发周期长,不能满足现代软件和IT行业高速发展、瞬息万变的需要。因此大型项目需要大型团队。在微软,产品开发团队(主要包括开发、测试和项目管理)一般都有百人以上规模,有些产品甚至上几千人(Windows2000的开发部门曾有3000多人)。这样大规模的人力资源作用在一个动态的,内部相互联系的系统中,若没有有效的协同,其混乱是不可避免的。试想,有两个开发人员,分别在开发两个不同的功能模块,其相互有依赖关系。为了相互协调,他们可以随时进行当面讨论。如果这种关系发生在五个开发人员和五个功能模块之间,这种协调就只能通过定期的会议来进行。而一个大型项目,会有许许多多这样的关系,而且很多时候这种关系有着不确定性和不可预见性。当一个开发人员编写一段新的代码或对已有代码进行改动和调整时,他(或她)常常无法确定,或无法完全确定究竟有哪些相关的模块会受到影响,以及在什么请况下这种影响会带来什么结果。因为系统的复杂性已远远超出了人的逻辑思维、技能和经验所能力及的范畴。因此这种传统的协调手段是远不能满足需要的。
在微软,这种协调是通过测试来实现的。具体来说就是:每日建造+自动化测试。关于每日编译和自动化测试,我将来会作专门介绍,这里简单的说就是每天都建造一个新版本,每个版本都要运行通过一定量的自动测试用例,以检验当天工作的质量。这里所说的质量当然有一般意义上质量的概念,但同时它也反映项目在开发过程中的整体协调性。 自动测试的最大优点在于它的高度可重复性。一个理想的自动测试系统能够让人随时、方便和迅速的运行大量的测试用例。因此一个开发人员可以通过检查当天的自动测试结果来分析前一天代码的质量(事后检查),也可以在当天存入代码前,先运行自动测试以进一步确保存入代码的质量(事前检查)。 在微软,每日建造都是在午夜开始,完成后紧接着就是全面的自动测试,到早晨上班时间之前就会把结果自动通过e-mail等方式发送出来。开发人员上班后的第一件事往往就是检查测试结果。如果没有问题就会开始新的工作。如果有测试有用例没有通过,开发人员则必须协同测试人员一起立刻找出原因,解决后才能开始新的代码。有时一个小的失误会引起大面积的测试用例失败,很大一部分开发团队会受到影响。为尽量避免这种情况,要求开发人员在存入代码之前先在自己的个人建造版本上运行一定量的自动测试,全部通过后在存入。如开发人员没有按照这样的要求,而擅自存入质量不高的代码而造成大量测试失败,这种不负责任的行为是要受到严厉批评的。
从这一过程可以看出,开发人员依赖测试来保证开发工作的质量,使开发整体地协调地向前推进。 当开发进入后期阶段,尽管项目已总体成型,开发人员也会不时遇到一些技术上的挑战。比如一些Bug的解决涉及对项目深层次结构的调整;再比如由于客户反馈的意见造成设计的修改。每一次这样的修改和调整事实上都是对一个稳定系统的破坏,如果处理不当往往一个Bug的修改会生成很多新的Bug,就像一系列联锁的恶性循环。很多项目工期的延误都是这样造成的。要避免或至少将这种破坏减少到最低限度,开发人员首先需要知道这种破坏的影响面。在这里单靠开发人员自身的逻辑思维、技能和经验是远远不够的,自动测试再一次成为一种有效的工具。往往开发人员会制定不止一个方案,对每个方案上都运行一遍同样一套自动测试用例,然后比较结果,选出最佳方案。自动测试在这方面所起的作用不仅在产品的开发过程中,它还延续到产品发布后。产品支持部门在为客户提供应急解决方案时也要依赖自动测试。 管理对测试的依赖 在微软,软件项目管理的主要线索就是Bug的管理,其中最直接具体的管理活动就是“Bug三方讨论会(Bug Triage)”。会议一般由项目管理Program Manager(简称PM)来主持,有开发人员和测试人员参加(所以叫三方会议)。会上对每个新生成的Bug进行讨论,并决定(1)是否接受这个Bug;(2)Bug的严重级别和优先级别;(3)Bug由谁来负责,是由测试提供进一步详细信息,还是交由开发人员解决,以及大致的解决方案等等。会议还要对老的Bug检查解决进度。这种讨论会常常会发生争论,要求测试人员具有足够的技术基础和用户经验,来捍卫产品的质量。可以说项目开发到了某一阶段后就是由这种Bug的管理所驱动的。这其中的原动力来自测试。 项目管理中一项非常重要但也十分困难的工作是衡量项目的进度,包括判断项目的状态,确定项目是否能预期完成。这方面,测试提供了两个非常重要的参数,一个是Bug数量的趋势,另一个是测试结果的趋势。 Bug趋势就是将每天新生成的Bug数和每天被解决的Bug数标成一个趋势图表。一般在项目的开始阶段新生Bug数曲线会呈上升趋势,到项目中后期被解决Bug数曲线会趋于上升,而新生Bug数曲线应下降,到项目最后,两条曲线都趋向于零。PM会持续观察这张图表,确保项目健康发展,同时通过分析预测项目Bug趋于零的时间。在一定的历史经验的基础上分析使用这一图表会得到很多有价值的信息,比如说,可分析开发和测试在人力资源的配比上是否恰当,可以分析出某个严重的Bug所造成的项目质量的波动。 每天的自动测试结果同样可以形成类似的图表。它同样非常有助于了解当前项目的质量状况,开发测试进度。 由测试产生的这些数据不仅在项目开发过程中为项目管理提供有效的依据,而且也是产品通过发布的必要条件。在微软,每个产品都要经过评审才能通过发布。前面介绍的几个图表是发布评审的重要内容,如果从图表中发现临评审前还出现过较大的质量波动,评审人员一定会对此提出质疑。 因此软件项目管理依赖软件测试提供其基本的管理素材。 可以说,现代大型软件开发过程中开发和管理对测试的依赖性是测试与开发流程融合的一个根本因素。从另一个角度看,测试与开发流程融合决不仅仅是简单的时间上的同步,更不是双方空间上的接近,而是这种内在的依存关系的外在表现。开发对测试的这种依赖性对测试和测是人员提出了更高的要求。在理念上,软件测试已远不仅仅只是软件功能的验证和Bug的搜寻;在具体方法上,自动测试和测试工具的使用已成为基本的要求。在微软,测试不仅使用一些通用的工具,每一个产品还有专门开发的专用工具库,测试的代码量常常超过项目本身的代码量。 一个软件企业要提高其软件开发的能力,特别是针对大型软件的大规模的快速开发能力,在测试方面对传统理念和方法进行突破是必要的。微软的实践就是一个很好的印证。
-
Linux实用代码(1)--文件系统操作
2007-10-24 13:10:43
Linux实用代码(1)--文件系统操作
2007-10-22 10:50:38 / 个人分类:linux
这篇文档实用性很强,它不是讲某个命令的参数具体含义,而是从实际
工作的角度来考虑,完成什么工作需要什么指令。
文件系统操作是最基本的操作,没有文件系统,操作系统根本就运行不了。
下面是我们经常要做的一些事情。在下面具体参数意义不解释,要了解这些
可以查询该命令帮助文档
1. 创建目录
mkdir
NO1. 在当前路径创建一级目录
[root@rehat root]# mkdir test
NO2. 在当前路径创建多级目录
[root@rehat root]# mkdir -p mytest/test1/test1_1
NO3. 在创建目录的同时给新建的目录赋权限
[root@rehat root]# mkdir -m 777 testmod
这样任何人对此目录都有任何权限
2. 复制文件与文件夹
cp
NO1. 复制指定目录的文件到当前目录,并重命名
[root@rehat root]# cp ~/.bashrc bashrc_bak
NO2. 强制复制指定目录的文件到当前目录,而不管当前目录是否含有该文件
[root@rehat root]# cp -f ~/.bashrc bashrc
NO2. 复制指定目录到当前目录
[root@rehat root]# cp -r /root/test .
[root@rehat root]# cp -r /root/test/ .
两者效果一样,在复制目录时,会将源路径的最后一级目录全部复制过去,包括它本身。
NO3. 复制指定目录的文件到指定目录
[root@rehat root]# cp ~/.bashrc /bak/.bashrc
NO4. 在复制时将源文件的全部属性也复制过来。若不指定参数,则目标文件与源文件属性可能不一致。
[root@rehat root]# cp -a ~/.bashrc /bak/.bashrc
NO5. 若两个文件夹要保证同步,一个文件的改了,另一个文件也跟着改,但是要保证两个文件的文件都是最新的。
[root@rehat root]# cp -u /src/.bashrc /bak_src/bashrc
3. 建立链接文件,包括硬链接与软链接
ln
NO1. 建立类似于 Windows 的快捷方式
[root@rehat root]# ln -s test.txt test.txt_slnk
NO2. 当想备份一个文件,但空间又不够,则可以为该文件建立一个硬连接。这样,就算原文件删除了,只要该
链接文件没被删除,则在存储空间里还是没有被删除。
[root@rehat root]# ln -l test.txt test.txt_hlnk
4. 删除文件
rm
NO1. 删除当前目录的文件
[root@rehat root]# rm test.txt
NO2. 强制删除当前目录的文件,不弹出提示
[root@rehat root]# rm -f test.txt
NO3. 强制删除整个目录,包括目录与文件全部删除,需要管理员权限
[root@rehat root]# rm -r -f test
5. 删除文件夹
rmdir
NO1. 删除一个空目录
[root@rehat root]# rmdir emptydir
NO2. 删除多级空目录
[root@rehat root]# rmdir -p emptydir/d1/d11
6. 挂载文件系统与卸载文件系统
mount / umount
NO1. 挂载光驱
[root@rehat root]# mount -t iso9660 /dev/cdrom /mnt/cdrom
NO2. 挂载光驱,支持中文
[root@rehat root]# mount -t iso9660 -o codepage=936,iocharset=cp936 /dev/cdrom /mnt/cdrom
NO3. 挂载 Windows 分区,FAT文件系统
[root@rehat root]# mount -t vfat /dev/hda3 /mnt/cdrom
NO4. 挂载 Windows 分区,NTFS文件系统
[root@rehat root]# mount -t ntfs -o iocharset=cp936 /dev/hda7 /mnt/had7
No5. 挂载 ISO 文件
[root@rehat root]# mount -o loop /abc.iso /mnt/cdrom
NO6. 挂载 软驱
[root@rehat root]# mount /dev/fd0 /mnt/floppy
NO7. 挂载闪盘
[root@rehat root]# mount /dev/sda1 /mnt/cdrom
NO8. 挂载 Windows 操作系统共享的文件夹
[root@rehat root]# mount -t smbfs -o username=guest,password=guest //machine/path /mnt/cdrom
NO9. 显示挂载的文件系统
[root@rehat root]# mount
[root@rehat root]# cat /etc/fstab 显示系统启动自动加载的文件系统
[root@rehat root]# cat /etc/mtab 显示当前加载的文件系统
7. 检查磁盘空间
df
NO1. 显示所有存储系统空间使用情况,同时显示存储系统的文件系统类型s
[root@rehat root]# df -aT
NO2. 显示指定文件系统的空间使用情况
[root@rehat root]# df -t ext3
NO3. 人性化显示各存储空间大小
[root@rehat root]# df -ah
NO4. 有时候挂载了网络文件系统,若只想看本机的文件系统用如下命令
[root@rehat root]# df -ahlT
NO5. 查看某个文件系统的磁盘使用情况
[root@rehat root]# df -h /dev/cdrom
8. 检查目录空间大小
du
NO1. 查看当前文件夹大小
[root@rehat root]# du -sh
NO2. 查看当前文件及文件中包含的子文件夹大小
[root@rehat root]# du -ch
NO3. 查看文件的大小
[root@rehat root]# du -h test1.txt
NO4. 同时查看多个文件的大小
[root@rehat root]# du -h test1.txt test2.txt
9. 磁盘碎片整理
linux 下基本上不用碎片整理,它每隔一段时间会自动整理
10. 创建/改变文件系统
NO1. 创建文件系统类型
[root@rehat root]# umount /dev/sdb1
[root@rehat root]# mkfs -t ext3 /dev/db1
[root@rehat root]# mount /dev/sdb1 /practice
11. 改变文件或文件夹权限
chmod
NO1. 将自己的笔记设为只有自己才能看
[root@rehat root]# chmod go-rwx test.txt
或者
[root@rehat root]# chmod 700 test.txt
NO2. 同时修改多个文件的权限
[root@rehat root]# chmod 700 test1.txt test2.txt
NO3. 修改一个目录的权限,包括其子目录及文件
[root@rehat root]# chmod 700 -R test
12. 改变文件或文件夹拥有者
chown 该命令只有 root 才能使用
NO1. 更改某个文件的拥有者
[root@rehat root]# chown jim:usergroup test.txt
NO2. 更改某个目录的拥有者,并包含子目录
[root@rehat root]# chown jim:usergroup -R test
13. 查看文本文件内容
cat
NO1. 查看文件内容,并在每行前面加上行号
[root@rehat root]# cat -n test.txt
NO2. 查看文件内容,在不是空行的前面加上行号
[root@rehat root]# cat -b test.txt
NO3. 合并两个文件的内容
[root@rehat root]# cat test1.txt test2.txt > test_new.txt
NO4. 全并两具文件的内容,并追回到一个文件
[root@rehat root]# cat test1.txt test2.txt >> test_total.txt
NO5. 清空某个文件的内容
[root@rehat root]# cat /dev/null > test.txt
NO6. 创建一个新的文件
[root@rehat root]# cat > new.txt 按 CTRL + C 结束录入
14. 编辑文件文件
vi
NO1. 新建档案文件
[root@rehat root]# vi newfile.txt
NO2. 修改档案文件
[root@rehat root]# vi test.txt test.txt 已存在
NO3. vi 的两种工作模式:命令模式,编辑模式
NO4. 进入 vi 后为命令模式,按 Insrt 键进入编辑模式
按 ESC 进入命令模式,在命令模式不能编辑,只能输入命令
NO5. 命令模式常用命令
:w 保存当前文档
:q 直接退出 vi
:wq 先保存后退出
15. 路径操作
cd pwd
NO1. 显示当前路径
[root@rehat root]# pwd
NO2. 返回用户主目录
[root@rehat root]# cd
NO3. 改变到其它路径
[root@rehat root]# cd /etc
NO4. 返回到上一级目录
[root@rehat root]# cd ..
NO5. 返回到根目录
[root@rehat root]# cd /
16. 查询文件或文件夹
find
NO1. 查找当前用户主目录下的所有文件
[root@rehat root]# find ~
NO2. 让当前目录中文件属主具有读、写权限,并且文件所属组的用户和其他用户具有读权限的文件;
[root@rehat root]# find . -perm 644 -exec ls -l {} \;
NO3. 为了查找系统中所有文件长度为0的普通文件,并列出它们的完整路径;
[root@rehat root]# find / size 0 -type f -exec ls -l {} \;
NO4. 查找/var/logs目录中更改时间在7日以前的普通文件,并在删除之前询问它们;
[root@rehat root]# find /var/logs -mtime +7 -type f -ok rm -i {} \;
NO5. 为/找系统中所有属于root组的文件;
[root@rehat root]# find / -group root -exec ls -l {} \;
NO6. find命令将删除当目录中访问时间在7日以来、含有数字后缀的admin.log文件
[root@rehat root]# find . -name "admin.log[0-9][0-9][0-9]" -atime -7 -ok rm { } \;
NO7. 为了查找当前文件系统中的所有目录并排序
[root@rehat root]# find . -type d | sort
NO8. 为了查找系统中所有的rmt磁带设备
[root@rehat root]# find /dev/rmt
17. 显示文件/文件夹清单
ls / dir
NO1. 显示所有文件,包括以.开头的隐含文件
[root@rehat root]# ls -a
NO2. 显示文件的详细信息
[root@rehat root]# ls -l
NO3. 显示当前目录及所有子目录信息
[root@rehat root]# ls -Rl
NO4. 以时间排序显示目录,这在找最新文件有用
[root@rehat root]# ls -tl
NO5. 以文件大小排序
[root@rehat root]# ls -Sl
NO6. 显示文件大小,并按大小排序
[root@rehat root]# ls -s -l -S
18. 移动或更改文件/文件夹名称
mv 与 cp命令用法相似
NO1. 若移动目标文件已存在,要在移动之前,先备份原来的目录文件
[root@rehat root]# mv -b test.txt test2/
这样在 test2 下将有两个文件 test.txt 及 text.txt~
其中 test.txt~ 是备份文件,test.txt是新的文件
NO2. 若移动目标文件已存在,但不想弹出是否覆盖的提示,直接覆盖
[root@rehat root]# mv -f test.txt test2/
NO3. 当源与目标都拥有同一个文件,若源文件比目标新则移动,否则不移动
[root@rehat root]# mv -u test.txt test2/
NO4. 更改文件名称
[root@rehat root]# mv test.txt test2.txt
NO5. 更改目录名称
[root@rehat root]# mv /test2 /test2_2 -
QTP的基本使用函数
2007-10-15 12:59:40
QTP的基本使用函数
2007-10-13 12:32:06
QTP的基本使用函数:
1,获取对话框相应的文字: GetVisible Text
2,查找相应的字符串: instr (1,查找目标字符串,所查找的字符串)
3,随机数的获取: Randomnumber.Value() 或cstr(int(Rnd*10)+1)
4,等待函数: Wait(秒数)
5,获取数组下标: UBound (数组名)
6,拆分数组:Split(MyString, ",", -1, 1)
7,可执行步骤:OptionalStep
8,报告信息: Reporter.ReportEvent 3, "Save Step", "Out of cycle!"
9,判断对话框是否存在: .exist
10,事件过滤函数:Reporter.Filter=过滤条件(0,1,2,3),0代表显示所有的error和warning,1,显示error,2,显示waining,3,任何error和warning都不显示。
11,循环函数:do … loop until,for…to… then next,while.
12,数据表格:DataTable,向外赋值,Dim aa = DataTable.value(“CellingName”,”ActionName”).
13,获得对象属性的三种方法GetTOProperty,GetTOProperties,GetROProperty,GetTOProperty获得程序中对象当前的属性,GetTOProperties获得当前属性所有集合,GetROProperty获得的是录制时对象所获得的属性。
14,检查点方法check和输出指定属性值output。
15,函数Descrīption,可以获得某页面同标签的属性进行操作。
16,函数nagative可以随便跳转页面到指定的URL。
17,函数Object可以获得当前页面同属性的控件。
18,函数Focus可以让控件获得焦点,函数Blur则是失去焦点,click单击,dbclick双击。
19,函数setAttribute可以设置控件属性,getAttribute可以获得属性。
添加数据:
1. 在每个要覆盖的域添加checkpoint。
2. 在不能同名的必填字段里,添加随机函数,循环增加。
查询数据:
1. 先添加数据,再查询数据更新,更新成功时设置checkpoint。
2. 最后删除成功时设置checkpoint
-
测试设计中需要考虑的22种测试类型
2007-08-07 16:57:28
测试设计中需要考虑的22种测试类型
黑盒测试:不基于内部设计和代码的任何知识,而是基于需求和功能性。
白盒测试:基于一个应用代码的内部逻辑知识,测试是基于覆盖全部代码、分支、路径、条件。
单元测试:最微小规模的测试;以测试某个功能或代码块。典型地由程序员而非测试员来做,因为它需要知道内部程序设计和编码的细节知识。这个工作不容易作好,除非应用系统有一个设计很好的体系结构; 还可能需要开发测试驱动器模块或测试套具。
累积综合测试:当一个新功能增加后,对应用系统所做的连续测试。它要求应用系统的不同形态的功能能够足够独立以可以在全部系统完成前能分别工作,或当需要时那些测试驱动器已被开发出来; 这种测试可由程序员或测试员来做。
集成测试:一个应用系统的各个部件的联合测试,以决定他们能否在一起共同工作。部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。这种类型的测试尤其与客户服务器和分布式系统有关。
功能测试:用于测试应用系统的功能需求的黑盒测试方法。这类测试应由测试员做,这并不意味着程序员在发布前不必检查他们的代码能否工作(自然他能用于测试的各个阶段)。
系统测试:基于系统整体需求说明书的黑盒类测试;应覆盖系统所有联合的部件。
端到端测试:类似于系统测试;测试级的“宏大”的端点;涉及整个应用系统环境在一个现实世界使用时的模拟情形的所有测试。例如与数据库对话,用网络通讯,或与外部硬件、应用系统或适当的系统对话。
健全测试:典型地是指一个初始化的测试工作,以决定一个新的软件版本测试是否足以执行下一步大的测试努力。例如,如果一个新版软件每5分钟与系统冲突,使系统陷于泥潭,说明该软件不够“健全”,目前不具备进一步测试的条件。
衰竭测试:软件或环境的修复或更正后的“再测试”。可能很难确定需要多少遍再次测试。尤其在接近开发周期结束时。自动测试工具对这类测试尤其有用。
接受测试:基于客户或最终用户的规格书的最终测试,或基于用户一段时间的使用后,看软件是否满足客户要求。
负载测试:测试一个应用在重负荷下的表现,例如测试一个 Web 站点在大量的负荷下,何时系统的响应会退化或失败。
强迫测试:在交替进行负荷和性能测试时常用的术语。也用于描述象在异乎寻常的重载下的系统功能测试之类的测试,如某个动作或输入大量的重复,大量数据的输入,对一个数据库系统大量的复杂查询等。
性能测试:在交替进行负荷和强迫测试时常用的术语。理想的“性能测试”(和其他类型的测试)应在需求文档或质量保证、测试计划中定义。
可用性测试:对“用户友好性”的测试。显然这是主观的,且将取决于目标最终用户或客户。用户面谈、调查、用户对话的录象和其他一些技术都可使用。程序员和测试员通常都不宜作可用性测试员。
安装/卸载测试:对软件的全部、部分或升级安装/卸载处理过程的测试。
恢复测试:测试一个系统从如下灾难中能否很好地恢复,如遇到系统崩溃、硬件损坏或其他灾难性问题。
安全测试:测试系统在防止非授权的内部或外部用户的访问或故意破坏等情况时怎么样。这可能需要复杂的测试技术。
兼容测试:测试软件在一个特定的硬件/软件/操作系统/网络等环境下的性能如何。
比较测试:与竞争伙伴的产品的比较测试,如软件的弱点、优点或实力。
Alpha 测试:在系统开发接近完成时对应用系统的测试;测试后,仍然会有少量的设计变更。这种测试一般由最终用户或其他人员员完成,不能由程序员或测试员完成。
Beta 测试:当开发和测试根本完成时所做的测试,而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员员完成,不能由程序员或测试员完成。 -
Web的系统测试要点
2007-08-07 14:46:44
Web的系统测试要点
一、功能测试
1、链接测试 链接测试可以用工具测试。链接测试必须在集成测试阶段完成,在整个Web应用系统的所有页面开发完成之后进行链接测试。
L"A1qqwB(Q7U131745测试所有链接是否按指示的那样确实链接到了该链接的页面; 51Testing软件测试网 K{ {qU4`:Vb%uz!Yk
测试所链接的页面是否存在; 51Testing软件测试网 xyn-r%W/i0x3x:A
保证Web应用系统上没有孤立的页面(所谓孤立页面是指没有链接指向该页面,只有知道正确的URL地址才能访问)。 51Testing软件测试网k2I;pk S:O'VZ)@}
2、表单测试包括注册、登陆、信息提交等,必须测试提交操作的完整性,以校验提交给服务器的信息的正确性。
用户填写的出生日期与职业是否恰当,填写的所属省份与所在城市是否匹配等;
*Fg+ZE4B1wnN131745检验默认值的正确性; 51Testing软件测试网2{ P+FwqG3T G
如表单只能接受指定的某些值,测试时跳过这些字符,看系统是否会报错。
V1U9c4CB+N!QJP1317453、Cookies测试Cookies是否起作用; 51Testing软件测试网Bi,c!Z9R MT7L
Cookies是否按预定的时间进行保存;
0@1ARat |n!rns131745刷新对Cookies有什么影响。 51Testing软件测试网4L2e:_2q*{;}6]}
4、设计语言测试Web设计语言版本的差异可以引起客户端或服务器端严重的问题,例如使用哪种版本的HTML等。除了HTML的版本问题外,不同的脚本语言,例如Java、Javascrīpt、 ActiveX、VBscrīpt或Perl等也要进行验证。
5、数据库测试
数据一致性错误:主要是由于用户提交的表单信息不正确而造成的;
|&J(Ko7KE#Jr131745输出错误:主要是由于网络速度或程序设计问题等引起的。 51Testing软件测试网 U2lSk}
二、性能测试1、连接速度测试
Web系统响应时间
:L` v%yb'Cj131745超时的限制
D!ULv }D:wT1317452、负载测试负载级别可以是某个时刻同时访问Web系统的用户数量,也可以是在线数据处理的数量。
3、压力测试
压力测试是测试系统的限制和故障恢复能力,也就是测试Web应用系统会不会崩溃,在什么情况下会崩溃。压力测试的区域包括表单、登陆和其他信息传输页面等。
三、可用性测试
1、导航测试
导航是否直观 51Testing软件测试网-v:J JC)hjG T
Web系统的主要部分是否可通过主页存取
z9Z-l]-tw4B?h131745Web系统是否需要站点地图、搜索引擎或其他的导航帮助 51Testing软件测试网 mbzz(]
Web应用系统的页面结构、导航、菜单、连接的风格是否一致
\ uw[ [.G9e w IS131745 Web应用系统导航帮助要尽可能地准确。Web应用系统的层次一旦决定,就要着手测试用户导航功能。2、图形测试
要确保图形有明确的用途,图片或动画不要胡乱地堆在一起,以免浪费传输时间。Web应用系统的图片尺寸要尽量地小,并且要能清楚地说明某件事情,一般都链接到某个具体的页面。
s5Cl Nc_lc131745验证所有页面字体的风格是否一致
,jBL&Ln7w'F131745背景颜色应该与字体颜色和前景颜色相搭配
yWf;K;?$@ ?T131745图片的大小和质量也是一个很重要的因素,一般采用JPG或GIF压缩
:E/HA-J5X1317453、内容测试信息的正确性
n2uabd9l131745信息的相关性 51Testing软件测试网|3`6A Ms}
4、整体界面测试整体界面是指整个Web应用系统的页面结构设计,是给用户的一个整体感。
四、客户端兼容性测试
1、平台测试
在Web系统发布之前,需要在各种操作系统下对Web系统进行兼容性测试。
2、浏览器测试
测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中,测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
五、安全性测试
现在的Web应用系统基本采用先注册,后登陆的方式。因此,必须测试有效和无效的用户名和密码,要注意到是否大小写敏感,可以试多少次的限制,是否可以不登陆而直接浏览某个页面等。
&e,^[v0S131745Web应用系统是否有超时的限制,用户登陆后在一定时间内(例如15分钟)没有点击任何页面,是否需要重新登陆才能正常使用。
d-I dT&h{"d0b131745为了保证Web应用系统的安全性,需要测试相关信息是否写进了日志文件、是否可追踪。 51Testing软件测试网5d:Vv,z*S&M V$b6G
当使用了安全套接字时,还要测试加密是否正确,检查信息的完整性。
1a0R ]D"fT3B;Y131745服务器端的脚本常常构成安全漏洞,这些漏洞又常常被黑客利用。所以,还要测试没有经过授权,就不能在服务器端放置和编辑脚本的问题。 51Testing软件测试网.`F)c+u-Bh.Mvh -
国外优秀测试网站
2007-07-22 17:29:47
国外优秀测试网站
2007-05-30 18:23:43
http://bdonline.sqe.com/ 一个关于网站测试方面的网页,对这方面感兴趣的人可以参考
http://citeseer.nj.nec.com/ 一个丰富的电子书库,内容很多,而且提供著作的相关文档参考和下载,是作者非常推荐的一个资料参考网站
http://groups.yahoo.com/group/LoadRunner
标题搜索
我的存档
数据统计
- 访问量: 4651
- 日志数: 11
- 建立时间: 2007-07-22
- 更新时间: 2010-01-08