一个人能走多远,不在于你的体力有多好和你是否有一双好的鞋子,而在于你的视野和你所选择的路。

发布新日志

  • TestDirector8.0测试管理工具使用培训视频

    2009-09-29 17:52:23

    在播布客中看到一个关于TD8.0的培训视频,是Mike Gao老师的杰作,感觉不错,现整理出来和大家共享。

    TD8.0 视频:
    第一部:软件测试管理工具TestDirector8.0介绍
    本视频的内容主要包括:
    1.TD8.0简介
    2.安装及配置
    URL:
    http://www.boobooke.com/v/bbk1004

    第二部:软件外包测试的基本介绍
    URL:
    http://www.boobooke.com/v/bbk1015

    第三部:TD8.0后台项目管理
    本视频的内容主要包括:
    1.如何在TD后台添加项目
    2.如何在TD后台删除项目
    3.如何在TD后台重命名项目
    4.如何在TD后台编辑项目
    另:将TD中Defects关键字改为Bugs:Insert into dataconst(dc_const_name,dc_value)values('replace_title','Defect:Bug;Defects:Bugs')
    URL:
    http://www.boobooke.com/v/bbk1018

    第四部:TD8.0后台用户管理
    本视频的内容主要包括:
    1.如何在TD后台添加用户
    2.如何在TD后台编辑用户
    3.如何在TD后台把用户分配到特定的项目并分配特定的角色。
    URL:
    http://www.boobooke.com/v/bbk1022

    第五部:TD的需求管理
    本视频的内容主要包括:
    1.添加需求;
    2.查看需求;
    3.修改需求;
    4.转换需求;
    URL:
    http://www.boobooke.com/v/bbk1035

    第六部:TD的计划测试
    本视频的内容主要包括:
    1.开发测试计划树
    2.设计测试步骤
    3.复制编辑测试步骤
    4.建立需求和测试相互连接
    URL:
    http://www.boobooke.com/v/bbk1038/

    第七部:TD的测试运行
    本视频的内容主要包括:
    1.定义测试集
    2.将测试添加到测试集
    3.运行测试
    URL:
    http://www.boobooke.com/v/bbk1039/

  • 服务器稳定性测试方法

    2009-09-24 11:28:46

        服务器稳定性是最重要的,如果在稳定性方面不能够保证业务运行的需要,在高的性能也是无用的。正规的服务器厂商都会对产品惊醒不同温度和湿度下的运行稳定性测试。重点要考虑的是冗余功能,如:数据冗余、网卡冗余、电源冗余、风扇冗余等。
      一些测试方法主要分以下几种:
      压力测试:已知系统高峰期使用人数,验证各事务在最大并发数(通过高峰期人数换算)下事务响应时间能够达到客户要求。系统各性能指标在这种压力下是否还在正常数值之内。系统是否会因这样的压力导致不良反应(如:宕机、应用异常中止等)。
     Ramp Up 增量设计:如并发用户为75人,系统注册用户为1500人,以5%-7%作为并发用户参考值。一般以每15s加载5人的方式进行增压设计,该数值主要参考测试加压机性能,建议Run几次。以事务通过率与错误率衡量实际加载方式。
      Ramp Up增量设计目标: 寻找已增量方式加压系统性能瓶颈位置,抓住出现的性能拐点时机,一般常用参考Hits点击率与吞吐量、CPU、内存使用情况综合判断。模拟高峰期使用人数,如早晨的登录,下班后的退出,工资发送时的消息系统等。
      另一种极限模拟方式,可视为在峰值压力情况下同时点击事务操作的系统极限操作指标。加压方式不变,在各脚本事务点中设置同集合点名称(如:lr_rendzvous("same");)在场景设计中,使用事务点集合策略。以同时达到集合点百分率为标准,同时释放所有正在Run的 Vuser。
      稳定性测试:已知系统高峰期使用人数、各事务操作频率等。设计综合测试场景,测试时将每个场景按照一定人数比率一起运行,模拟用户使用数年的情况。并监控在测试中,系统各性能指标在这种压力下是否能保持正常数值。事务响应时间是否会出现波动或随测试时间增涨而增加。系统是否会在测试期间内发生如宕机、应用中止等异常情况。
      根据上述测试中,各事务条件下出现性能拐点的位置,已确定稳定性测试并发用户人数。仍然根据实际测试服务器(加压机、应用服务器、数据服务器三方性能),估算最终并发用户人数。
      场景设计思想:
      从稳定性测试场景的设计意义,应分多种情况考虑:
      针对同一个场景为例,以下以公文附件上传为例简要分析场景设计思想:
      1)场景一:已压力测试环境下性能拐点的并发用户为设计测试场景,目的验证极限压力情况下测试服务器各性能指标。
      2)场景二:根据压力测试环境中CPU、内存等指标选取服务器所能承受最大压力的50%来确定并发用户数。
      测试方法:采用1)Ramp Up-Load all Vusers simultaneously
      2)Duration-Run Indefinitely
      3)在Sechedule-勾选Initalize all Vusers before Run
      容错性测试:通过模拟一些非正常情况(如:服务器突然断电、网络时断时续、服务器硬盘空间不足等),验证系统在发生这些情况时是否能够有自动处理机制以保障系统的正常运行或恢复运行措施。如有HA(自动容灾系统),还可以专门针对这些自动保护系统进行另外的测试。验证其能否有效触发保护措施。
      问题排除性测试:通过原有案例或经验判断,针对系统中曾经发生问题或怀疑存在隐患的模块进行验证测试。验证这些模块是否还会发生同样的性能问题。如:上传附件模块的内存泄露问题、地址本模块优化、开启Tivoli性能监控对OA系统性能的影响等等。
      测评测试是用于获取系统的关键性能指标点,而进行的相关测试。主要是针对预先没有明确的预期测试结果,而是要通过测试获取在特定压力场景下的性能指标(如:事务响应时间、最大并发用户数等)。
      评测事务交易时间:为获取某事务在特定压力下的响应时间而进行的测试活动。通过模拟已知客户高峰期的各压力值或预期所能承受的压力值,获取事务在这种压力下的响应时间。
      评测事务最大并发用户数:为获取某事务在特定系统环境下所能承受的最大并发用户数而进行的测试活动。通过模拟真实环境或直接采用真实环境,评测在这种环境下事务所能承受的最大并发用户数。判定标准阈值需预先定义(如响应时间,CPU占用率,内存占用率,已出现点击率峰值,已出现吞吐量峰值等)。
      评测系统最大并发用户数:为获取整个系统所能够承受的最大并发用户数而进行的的测试活动。通过预先分析项目各主要模块的使用比率和频率,定义各事务在综合场景中所占的比率,以比率方式分配各事务并发用户数。模拟真实环境或直接采用真实环境,评测在这种环境下系统所能承受的最大并发用户数。判定标准阀值预先定义(如响应时间,CPU占用率,内存占用率,已出现点击率峰值,已出现吞吐量峰值等)。取值标准以木桶法则为准(并发数最小的事务为整个系统的并发数)。
      评测不同数据库数据量对性能的影响:针对不同数据库数据量的测试,将测试结果进行对比,分析发现数据库中各表的数据量对事务性能的影响。得以预先判断系统长时间运行后,或某些模块客户要求数据量较大时可能存在的隐患。
      问题定位测试在通过以上测试或用户实际操作已经发现系统中的性能问题或怀疑已存在性能问题。需通过响应的测试场景重现问题或定义问题。如有可能,可以直接找出引起性能问题所在的代码或模块。
      该类测试主要还是通过测试出问题的脚本场景,并可以增加发现和检测的工具,如开启Tivoli性能监控、开启HeapDump输出、Linux资源监控命令等。并在场景运行过程中辅以手工测试。
  • TestDirector Checker中"TD Virtual Directory " 错误的解决方法

    2009-07-16 14:57:03

    用TD的TestDirector Checker检查了一下,看见里面有一些红字如下:
     
    The TestDirector installation process creates a virtual directorywhich it attempts to places in High (Isolated)Application Protection,If,after the installationprocess,the virtual directory is otherwise protected,TestDirector cannot word properly,To rectify thissituation,you must resynchronize the IWAM_XXXX accountpassword,or place the virtual directory in Low(IIS process) Application Protection,For instructions onsynchronizing IWAM_XXXX account passwords,refer toArticle#324 on the following Web site:www.IISFAQ.com.
    根据上面的提示,到IIS里面的TDBIN目录里修改了属性“应用程序保护”,选择“高(独立)”结果提示如下:
    com+无法与Mircrosoft分布式事务协调程序交谈

    我在网上搜索后,发现很多网友提供了以下解决方法:

    解决方法一:首先先到IIS里面的TDBIN目录里修改属性的“应用程序保护”,选择“高(独立)”,(附图1)再浏览主页就没事了。如果选择项为灰色的话(附图2),则需要点击创建,将应用程序名建立即可,然后再选择“应用程序保护”的“高(独立)”属性,再用TestDirector Checker检查一遍就OK了
    如果上面的方法不行,就先试试下面的,再试试上面的
    解决的办法如下:
    进入注册表,删除注册表中的下面三键值:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSDTC 
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC 
    HKEY_CLASSES_ROOT\CID 
    打开“运行”框,输入:“net stop msdtc”(不含引号,下同) 停止MSDTC服务命令
    接着打开“运行”框,输入:“msdtc -uninstall” 卸载MSDTC服务命令
    再打开“运行”框,输入:“msdtc -install” 重新安装MSDTC服务命令
    然后在“运行”框,输入:“net start msdtc”
    再在事件查看器中确认msdtc服务已经正常启动,这步很关键,如果启动了就代表成功了
    注意 :有很多人在删除注册表里面的“HKEY_CLASSES_ROOT\CID”时,发现CID键删除不了,这是很多人安装了360安全卫士造成的,只要下载个"IISfixer"的修理程序,然后再删除CID就可以删除了,然后按着我刚说的过程来就可以安装成功了

    解决办法二:
    手工同步IIS用户密码,步骤如下:
    1)重新设置IIS的IWAM账号密码。右键单击我的电脑->管理,打开计算机管理界面打开本地用户和组->用户 右键单击启动IIS进程帐号 IWAM_****(注:****一般是计算机名)点击设置密码,设置为一个你想要的密码。
    2)同步IIS metabase中IWAM_MYSERVER的密码,在CMD中:c:\inetpub\adminscrīpts>adsutil set w3svc/wamuserpass "yourpassword"
    3)同步COM+应用程序所用的IWAM_MYSERVER密码,在CMD中:c:\inetpub\adminscrīpts>cscrīpt synciwam.vbs -v。
    但是在进行第三步操作时总是报8004e00f错误。进入组件服务,查看组件服务/计算机/我的电脑/COM+应用程序,结果报错"COM+ 无法与 Microsoft 分布式事务协调程序交谈",无法查看里面的对象。在事件查看器中msdtc服务没有正常启动。解决方法:运行 msdtc -resetlog

    我使用以上两种方法问题都没有得到解决,最后卸载了IIS和TD,再重新安装IIS和TD问题解决了。:)

    注:在安装TD时提示:“[87,22]属性值无效: progid,详细如下图:

    解决方法:在安装IIS时记得安装:UDDI服务,这样此问题可以得到解决。

  • 从进销存谈报表测试

    2009-07-15 10:17:40

         报表的重要性,大家都知道它有举足轻重的地位,特别是成本/利润类报表、月报、年报等,这里就废话少说了!所以,它对测试条件的要求、测试覆盖率的要求、测试深度的要求都非常高,而且不是一般的测试员和新手随便就能测试的,一定是对业务和相关的法规非常熟悉,最好能有实践经验的、较强分析能力、综合能力高的测试员来做!

    总结了报表在测试时需要关注的十大特性:
    一、 正确性
    报表的最低要求和基本特征就是它的正确性!
        1.报表格式的正确
    不同的报表有不同的格式,有些是行业内默认的,有些是明文规定的,还有自定义的,按照不同条件还可以分各种各样的,如:按照货品的仓库进出情况,分入库类报表、出库类报表和仓库类报表等;按照报表的类型,分图表,固定行列报表,分栏报表、交叉报表等等!因此,报表的格式不是随便增减的,一般包括表头、表体、表尾、以及附注等,测试时需要具体问题具体分析,根据需求提供的标准格式模板!
        2.报表内容的正确
    这是测试的重中之重,包括数据的算法、数据的来源、数据的对应关系、小数位问题、四舍五入问题、单位换算问题、税率换算问题、明细与合计是否一致、单据的类型/状态改变后对报表的影响等!

    二、 时段性
    这个很容易了解,没有那张报表在时空上的统计是漫无边际的,就算是“所有”或者“全部”,都是有它的时效!特别是财务类报表,有月报、季报、年报、甚至还有现金日记帐等,都表现出时段在报表中的必要。

    三、 条件性
    每个报表都是针对特定的条件而作出的输出,要想达到目的,是需要一定条件的。如:统计XX供应商XX业务员在XX时期采购XX商品的情况,在查询时就至少需要四个条件了!
    在测试查询条件时,通常采用正交的方法来增加它的测试覆盖率,但是要注意的是,测试数据的选取非常重要,我们都尽量模拟真实的、有代表性的、经过精心设计的数据!

    四、 可比性
    这在报表的分析和成效的判定上,显得尤其重要,通常报表的测试,不仅只是对单张报表的测试,还需要多张同时进行比较,多张可以是指同一时期不同类型的报表、不同时期同一类型的报表、不同类型与不同类型的报表(但它们之间必然存在某种关系的);还有什么同比的、类比的等!
    目的是找出它们之间的联系和区别,然后获得更深层次的某种规律或者业务流程的脉络。简单来说,就是从实践上升到理论!
    举个简单的例子:我们都知道财务报表的会计原则是“有借必有贷,借贷必相等”,因此,每个财务类报表都有借、贷两方;然而从销售收入报表、销售支出报表和销售利润表,显然得出:销售收入-销售支出=销售利润,这一条无人不晓的规律!

    五、穿透性
    这个也很容易理解,大多数的报表都不是孤立的,例如:从汇总表可以穿透到明细表,从明细表又可以穿透到单据,从单据甚至可以穿透到具体的产品;虽然它们的层次深度可能不一样,但它们与某某之间有着奇妙的联系!
    在测试中,一定要理清它们之间的层次、顺序,这就需要对业务的理解和知识的积累!

    六、隐蔽性
    这里不是指报表的数据或者结果隐蔽,而是指所统计的数据来源的隐蔽。例如:入库类的,除了正规的采购入库,还会有估价入库、退货入库、盘盈入库、报溢入库、拆卸入库(将组装产品或者已经打包的产品,拆卸后将元素产品重新入库)等;出库类的,除了常见的销售出库,还会有采购退货、盘亏出库、报损出库、生产领用、组装领用等。请注意的是,有些进销存系统还分有帐面库存数和实际库存数两种的!
    另一个陷阱:有些进销存系统的应收帐款是由正常的应收帐款加上预付转应收的部分组成的;同理,应付帐款是由正常的应付帐款加上预收转应付的部分组成!

    七、时序性
    上面说了时段性,现在到说说时序性,顾名思义,就是指业务发生的时间顺序。在明细报表中,每项明细都应该有记录业务发生的时间,它的先后顺序很重要。
    举个简单的例子:某仓库库存量为100,三月份销售出库50,四月份采购入库也是50,如果将四月份的采购入库计入三月份的,虽然年仓库库存量还是100,没有变,但是对于月度库存量和季度库存量就影响大了!

    八、安全性
        1.这个主要体现在报表的权限控制上。因为报表是针对不同的用户设计的,特别是敏感的数据,如个人资料、产品成本、商业信息等,这就需要加强访问权限的控制,有的是只读的,不能过滤条件或者修改其他的查询条件;有的根据用户等级来分配权限等!
        2. 通过用户角色和密码来控制:业务员只能看到自己的业绩报表
        3.通过用户角色的等级来控制:非财务主管不能打开销售收入利润表等

    九、 直观性
    报表的数据、结果清晰明了,页面简洁、排版合理,不能给用户产生模糊或者引起奇异的感觉;一般合计的部分或者关键字段都需要突出显示;有的报表需要图文并茂,选择最佳的报表类型。

    十、 打印
    仅仅测试通过查询得到的报表,是不足够的;通过屏幕看到报表的效果,也是不能全信的,需要持有怀疑的态度,把报表打印出来,重新检查是否适合所需的效果!
    包括:打印模板的设计、套打样式、自定义模板、打印调试、打印时间等方面。

  • 可用性测试

    2009-04-22 14:07:54

    可用性测试是指,让一群有代表性的用户尝试对产品进行典型操作,同时观察员和开发人员在一旁观察,聆听,做记录。该产品可能是一个网站,软件,或者其他任何产品,它可能尚未成型。测试可以是早期的纸上原型测试,也可以是后期成品的测试。

      你能从可用性测试获得什么?在每一轮的可用性测试中,你都应该先明确具体的测试问题和目标,针对这些目标进行测试。举例来说,项目刚刚起步,你可以对定量的指标(如时间,错误率和满意度)进行测试,为日后修改网站提供参照。再例如,如果你已经设定了可测量的可用性目标,你可以看看你的产品是否切合这些目标。对于一个典型的可用性测试,你可以:找出该产品的任何的可用性问题从测试参与者的表现收集定量数据确定该产品的用户满意度

      可用性测试和以用户为中心的设计的关系?可用性测试是以用户为中心的设计的一个重要组成部分。用户为本的设计过程本身就应该包括对性能和偏好进行评价的一系列测试。

      什么时候该做可用性测试?尽早做,经常做。可用性测试可以让设计师和开发团队在产品成形之前尽早发现问题。 问题越早发现和弥补,所造成的损失就越低。这些问题是找到并固定好,越昂贵的补丁程序。随着项目的进展,对设计主体进行改动会变得越来越困难和昂贵。你测试的越多,并就相应测试进行改进,你就可以更加确信你的网站没有偏轨,确信它是符合您的目标和用户的需要的。迭代开发过程——开发原型,测试用户,分析结果,随之修改原型,然后再重复测试、分析、修改周期——是开发一个成功的网站或软件的最好方式。

      通过可用性测试你能学到什么?通过一个典型的可用性测试,你可能找到这些问题的答案:测试参与者能成功完成任务吗?在成功完成的任务中,每项任务能做的多快?在成功完成的任务中,每项任务要多少页(或者点击多少次)才能完成?测试参与者的表现是否满足可用性目标?测试参与者对网站的满意度如何?做出什么改变才能确保更多用户能够完成地更顺利?可能还有更具体的问题。举例来说,如果这一轮测试主要关注的是搜索功能,你可能会关注这些问题:测试参与者会在页面上浏览还是直接使用搜索?他们搜索时最常用的关键字是什么?搜索框是否足够大,能呈现大部分的搜索关键字?它的位置是否合理?搜索结果是否能引导用户的快速找到答案?如果搜索结果恰好包含用户想要的答案,这些答案是否经常显示在第一页?搜索是否能检测到拼写错误并帮助纠正?

      可用性测试中你该注意什么?必须牢记以下四点:1. 你测试的是产品,而不是使用者。2. 更多地依靠用户的表现,而不是他们的偏好。3. 把你掌握的测试结果应用起来。4. 基于真实的用户体验,找出问题的最佳解决方法。1. 你测试的是产品,而不是使用者。对一些用户而言, "测试"有负面的涵义。我们要努力确保他们不认为测试是针对他们。我们要让他们明白,他们正在帮助我们测试原型或网站。事实上,我们可以不使用“测试”这个术语。相反,我们是邀请参加者为我们提供帮助,"勇于尝试原型" 。当用户难以完成任务时,我们应该改变网站,而不是改变用户。同时我们还应该思考该网站能在多大程度上符合那些典型用户的的目标,而不是关注用户在这个任务做的多好。2. 更多地依靠用户的表现,而不是他们的偏好。通过测试我们可以测量到用户的表现,以及他们的偏好。用户的表现包括是否成功完成,所用时间,产生的错误等等。偏好包括用户自我报告的满意度和舒适度 。一些设计人员认为,如果他们的设计能迎合用户的喜好,用户在该网站上就会有良好的表现。但证据并不支持这一点。事实上,用户的表现以及他们对产品的偏好并非一一对应。一项研究发现,约有百分之七十的用户同意表现和喜好有联系。也就是说,他们在喜爱的网站上表现良好,在不喜欢的网站上表现欠佳。然而,还有相对比较大比例的人( 30 % )认为 ,用户的表现以及他们对产品的偏好并非一一对应。他们在不喜爱的网站上可能表现良好,在喜欢的网站上也可能表现不佳。关于人们为什么会对自己表现欠佳的网站给出较高的评价有多种解释。他们可能会把表现不佳归结到自己,而不是网站。或者说,他们可能担心给一个较低的评价会伤害网站设计者,也就是我们的感情。或者说,他们可能并没有完成任务,却自认为成功完成了,他们并没有意识到问题所在。基于所有这些理由,我们建议你:更多地依靠用户的表现,而不是他们的偏好。3. 把你掌握的测试结果应用起来。可用性测试不仅仅是用于核对项目进度的一个里程碑,你要知道,当最后一个参与者完成任务的时候,可用性测试还没有结束。整个团队必须仔细研究结果,设定优先次序,基于结果对或者网站原型进行修改。4. 基于真实的用户体验,找出问题的最佳解决方法。制造任何产品,包括大部分网站和软件,需要考虑许多不同的用户的工作方式、体验、问题以及需要。大多数项目,包括设计或修改网站,都要处理时间、预算和资源等方面的限制。平衡各个方面对大部分项目来说都是一个重大的挑战。在你权衡利弊时,最好优先开发那些能使最多用户完成任务的网站或软件。有研究表明,产品推出后,用于支持失败客户的花费远远高于开发时对产品修正所付出的花费。你需要认真考虑假定用户、使用场景以及可用性测试的结果,试图找出针对不同客户需求的理想解决方法。找不到最好的解决方法,用户就不能够顺畅地完成任务。有证据表明,即使用户延长使用时间在一个不太完美的产品界面完成任务,也远不及在一个更好的产品界面带来的成功感。

      你是否需要一个实验室做可用性测试?用不着,无论使用正式的或非正式的设备你都可以做可用性测试。使用任何类型的设备,你都可以采用各种正式或非正式的方法。使用下述任何一种设置,你都可以进行有效的可用性测试:两室或三室的固定实验室,配备视听设备会议室,用户的家或工作室,配备便携式录音设备会议室,用户的家或工作室,没有录音设备也可以用人眼观察和笔记来代替当用户在不同地点可以远程控制因此,即使你没有或没法找到一个固定的实验室,你也应该进行可用性测试。不要说,“因为我们没有一个可用性实验室,所以我们没法做可用性测试。"只要去做!在任何空间你都可以完成。可用性测试需要多少人参与?看情况。一个典型的测试需要8至16个人(每用户组)。如果每个用户将花费一小时,就意味着每个用户组的测试需要一到两个工作日。当你的项目处在:纸上原型或早期开发阶段计划通过几轮测试整个开发有相当一致的用户群如果只要人帮忙找出严重问题,你可能只需要4到6人。如果您有不同的潜在用户群组(例如医生、病人、研究人员),你需要所有这些群体的用户代表。如果你对用户的电脑操作或网络经验有要求,还需要包括经验较少的和经验较多的用户。如果你要对你的产品或系统进行正式的定量测试,你将需要更多的人以获得统计上有意义的结果。对于诊断型的可用性测试,6至8个用户通常是不足以揭露产品的大部分问题的。如果在网站开发过程中你一直在做迭代(重复)的可用性测试,就会有许多用户参加其中一个或另一个版本的网站测试。因此,尽管每个可用性测试只有少于10名的测试参予者,但在网站推出前你可能需要15到30人参加测试。

      做可用性测试需要多少费用?成本要看网站的大小,你的测试量,预期的用户类型数目,以及你期望这个测试正规到什么程度。如果你已经有一个标准的测试程序和可用的材料设备,可用性测试将进行地很快很便宜。如果你或你的用户招聘公司拥有一个用户数据库,用于招募的时间就可以大量节约,因此,花费会更少。在对可用性测试进行预算时应该考虑这些因素:计划所用的时间:确定测试的主要问题,需要测试的用户类型,招聘的用户的筛选问卷以及测试场景。招聘的花费:公司人员的时间,给招聘公司(通常是一个很好的选择)的花费,可用性专家需要花时间熟悉网站及其制作团队,设计相应的测试场景,如果你需要录制测试过程,还需要花费实验室或便携式摄录设备的租金。团队观察用户(进行测试)花费的时间付给测试参与者的报酬或礼物分析视听资料,查找存在的问题以及推荐解决办法所用的时间和开发人员讨论变动和修改方案,撰写调查结果和建议报告所用的时间。记住,预算分析要包含多个可用性测试。打造一个网站(或产品)的可用性是一个反复迭代的过程。你会发现,用在在开发过程中几个小测试的预算比起在项目末期只做一个大型测试要有价值的多。

  • 虚拟机中安装“VMware Tools”

    2008-12-05 15:48:45

    “VMware Tools”的作用:如果虚拟机中安装了VMware Tools,鼠标就可以随意进出vm虚拟机系统和自己的主机系统,主机的东西可以直接拖到(或者粘贴、复制到)虚拟机里,虚拟机里的东西也很方便的粘贴、复制到主机中。如果没有安装,你是不是要按住ctrl+alt才能释放鼠标吧,操作很不方便。

    第一步、在上方菜单栏找到并点击“安装VMware Tools”。如没有反应,请按第二步手动安装(以虚拟win98系统为例):

    第二步、在虚拟机-虚拟机-设置-硬件中,选中你的光驱选项(cd-rom)在右侧的连接中选使用ISO镜像,然后浏览找到你主机上的VMware安装目录,例如D:\Program Files\VMware下面,选中其下的windows.iso,这时虚拟机会自动启动VMware Tools安装程序。(如果你禁止了光驱自动运行,需手动到光驱盘符下安装)

  • 测试用例设计方法

    2008-11-26 14:22:05

    以下是51testing中关于测试用例设计方法的讲解,觉得比较全面,因而汇总于此和大家共同分享、学习。

     1.场景设计方法:http://www.51testing.com/html/200811/n97993.html

     2.因果图方法:http://www.51testing.com/html/200811/n97777.html

     3.错误推测方法:http://www.51testing.com/html/200811/n97674.html

     4.等价类划分方法:http://www.51testing.com/html/200811/n97668.html

     5.边界值分析方法:http://www.51testing.com/html/200811/n97459.html

     6.功能图分析方法:http://www.51testing.com/html/200811/n96773.html

     7.正交实验设计方法:http://www.51testing.com/html/200811/n96675.html

     8.判定表驱动分析方法:http://www.51testing.com/html/200801/n73189.html

     

     

  • 网站安全性测试(转)

    2008-10-23 16:04:29

    本文出自51Testing软件测试论坛每周一问活动, 作者: jacky19840707   

    一个完整的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服务器的目录访问权限,将这种隐患降低到最小程度。

  • 性能测试—并发用户数的估算

    2008-10-17 10:29:24

    在实际的性能测试工作中,测试人员常常会关心到并发用户数,也就是从业务角度关注究竟应该设置多少个并发数比较合理,以下是一个估算并发用户数的方法:

      (1) 计算平均的并发用户数: C = nL/T

      (2) 并发用户数峰值: C’ ≈ C+3根号C

      公式(1)中,C是平均的并发用户数;n是login session的数量;L是login session的平均长度;T指考察的时间段长度。

      公式(2)则给出了并发用户数峰值的计算方式中,其中,C’指并发用户数的峰值,C就是公式(1)中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。

      实例:

      假设有一个OA系统,该系统有3000个用户,平均每天大约有400个用户要访问该系统,对一个典型用户来说,一天之内用户从登录到退出该系统的平均时间为4小时,在一天的时间内,用户只在8小时内使用该系统。

      则根据公式(1)和公式(2),可以得到:

      C = 400*4/8 = 200

      C’≈200+3*根号200 = 242

  • 嵌入式软件测试策略

    2008-07-25 13:29:58

        在嵌入式领域目标系统的应用系统日趋复杂,而由于竞争要求产品快速上市,开发技术日新月异,同时硬件发展的日益稳定,而软件故障却日益突出,软件的重要性逐渐引起人们的重视,越来越多的人认识到嵌入式系统的测试势在必行。提到嵌入式软件测试,首先要简单介绍一些软件工程的一些观点,现在,被普遍接受的软件的定义是:软件(software)是计算机系统中与硬件(hardware)相互依存的另一部分,它包括程序(program)、相关数据(data)及其说明文档(document)。其中程序是按照事先设计的功能和性能要求执行的指令序列;数据是是程序能正常操纵信息的数据结构;文档是与程序开发维护和使用有关的各种图文资料。
      对于一般商用软件的测试,嵌入式软件测试有其自身的特点和测试困难。
      由于嵌入式系统的自身特点,如实时性(Real-timing),内存不丰富,I / O通道少,开发工具昂贵,并且与硬件紧密相关CPU种类繁多,等等。嵌入式软件的开发和测试也就与一般商用软件的开发和测试策略有了很大的不同,可以说嵌入式软件是最难测试的一种软件。
      嵌入式软件测试使用有效的测试策略是唯一的出路,它可以使开发的效率最大化,避免目标系统的瓶颈,使用在线仿真器节省昂贵的目标资源。自从出现高级语言,开发环境与最终运行环境通常都是存在差异的,嵌入式系统更是如此。开发环境被认为是主机平台,软件运行环境为目标平台。相应的测试为host-target测试或cross-testing
      讨论嵌入式软件测试首先就会遇到一个问题:为什么不把所有测试都放在目标上进行呢?因为若所有测试都放在目标平台上有很多不利的因素:
    1
    )测试软件,可能会造成与开发者争夺时间的瓶颈,避免它只有提供更多的目标环境。
    2
    )目标环境可能还不可行。
    3
    )比起主机平台环境,目标环境通常是不精密的和不方便的。
    4
    )提供给开发者的目标环境和联合开发环境通常是很昂贵的。
    5
    )开发和测试工作可能会妨碍目标环境已存在持续的应用
    从经济上和开发效率上考虑,软件开发周期中尽可能大的比例在主机系统环境中进行, 其中包括测试。
    确定host-target测试环境后,开发测试人员又会遇到以下的问题:
    1
    )多少开发人员会卷入测试工作(单元测试,软件集成,系统测试)?
    2
    )多少软件应该测试,测试会花费多长时间?
    3
    )在主机环境和目标环境有哪些软件工具,价格怎样,适合怎样?
    4
    )多少目标环境可以提供给开发者,什么时候?
    5
    )主机和目标机之间的连接怎样?
    6
    )被测软件下载到目标机有多快?
    7
    )使用主机与目标环境之间有什么限制(如软件安全标准)?
    任何人或组织进行嵌入式软件的测试都应深入考虑以上问题,结合自身实际情况,选定合理测试策略和方案。
    对于嵌入式软件测试或叫交叉测试(cross-test),在测试的各个阶段有着通用的策略:
    1
    .单元测试:
    所有单元级测试都可以在主机环境上进行,除非少数情况,特别具体指定了单元测试直接在目标环境进行。最大化在主机环境进行软件测试的比例,通过尽可能小的目标单元访问所有目标指定的界面。
    在主机平台上运行测试速度比在目标平台上快的多,当在主机平台完成测试,可以在目标环境上重复作一简单的确认测试,确认测试结果在主机和目标机上没有被他们的不同影响。在目标环境上进行确认测试将确定一些未知的,未预料到的,未说明的主机与目标机的不同。例如,目标编译器可能有bug,但在主机编译器上没有。
    2
    .集成测试:
    软件集成也可在主机环境上完成,在主机平台上模拟目标环境运行,当然在目标环境上重复测试也是必须的,在此级别上的确认测试将确定一些环境上的问题,比如内存定位和分配上的一些错误。
    在主机环境上的集成测试的使用,依赖于目标系统的具体功能有多少。有些嵌入式系统与目标环境耦合的非常紧密,若在主机环境做集成是不切实际的。一个大型软件的开发可以分几个级别的集成。低级别的软件集成在主机平台上完成有很大优势,越往后的集成越依赖于目标环境。
    3
    .系统测试和确认测试
    所有的系统测试和确认测试必须在目标环境下执行。当然在主机上开发和执行系统测试,然后移植到目标环境重复执行是很方便的。对目标系统的依赖性会妨碍将主机环境上的系统测试移植到目标系统上,况且只有少数开发者会卷入系统测试,所以有时放弃在主机环境上执行系统测试可能更方便。
    确认测试最终的实施舞台必须在目标环境中,系统的确认必须在真实系统之下测试,而不能在主机环境下模拟。这关系到嵌入式软件的最终使用。
    包括恢复测试、安全测试、强度测试、性能测试,已超出了软件测试的范畴,本文暂不讨论。
    使用有效的cross-test测试策略可极大的提高嵌入式软件开发测试的水平和效率,当然正确的测试工具使用也是必不可少的:
    总结一下,应用以上测试工具进行.Cross-test时的策略:
    A)
    使用测试工具的插装功能(主机环境)执行静态测试分析,并且为动态覆盖测试准备好一插装好的软件代码。
    B)
    使用源码在主机环境执行功能测试,修正软件的错误和测试脚本中的错误。
    C)
    使用插装后的软件代码执行覆盖率测试,添加测试用例或修正软件的错误,保证达到所要求的覆盖率目标。
    D)
    在目标环境下重复(B),确认软件在目标环境中执行测试的正确性。
    E)
    若测试需要达到极端的完整性,最好在目标系统上重复(C),确定软件的覆盖率没有改变。
    通常在主机环境执行多数的测试,只是在最终确定测试结果和最后的系统测试才移植到目标环境,这样可以避免发生访问目标系统资源上的瓶颈,也可以减少在昂贵资源如在线仿真器上的费用。另外,若目标系统的硬件由于某种原因而不能使用时,最后的确认测试可以推迟直到目标硬件可用,这为嵌入式软件的开发测试提供了弹性。设计软件的可移植性是成功进行cross-test的先决条件,它通常可以提高软件的质量,并且度软件的维护大有益处。以上所提到的测试工具,都可以通过各自的方式提供测试在主机与目标之间的移植,从而使嵌入式软件的测试得以方便的执行。
    使用有效的cross-test测试策略可极大的提高嵌入式软件开发测试的水平和效率,提高嵌入式软件的质量。
    附录:
    1)HOST-TARGET
    的连接方法简介:

    直接连接

    通过仿真器连接

    使用介质进行间接连接

    使用PROM等传递被测软件

    测试的交互界面

    无交互界面的连接

  • 游戏软件测试方法汇总

    2008-07-25 13:26:58

    1. 运行环境
     
    需要多高的配置,是否主流机器,是否网吧流行的机器,可以看出这个
     
    游戏的传播范围及用户群。
    2.
    资源占用情况
     
    与其他常用软件的兼用性如何,有无内存泄露的情况
    3.
    稳定性
     
    是否经常非法跳出
    4.
    用户帮助信息
     
    用户是否能够很容易找到相关的帮助信息(主页网站之类)
    5.
    界面的复杂度及友好度
     
    是否可以很快上手,很容易明白各种操作
    6.
    网络的要求
     
    对于带宽的要求如何,是否有大量的冗余信息传输
    7.
    新手帮助系统
     
    是否有协助新手尽快熟悉游戏的功能
    8.
    交流系统
     
    关于聊天、交流是否方便,快捷
    9.
    提倡的升级方式
     
    组队?独练?打怪?任务?在线时间?
    10.
    战斗系统
     
    技能的作用是否清晰,技能升级是否合理,技能之间是否平衡,有无绝
     
    对的压倒优势的练法,战斗是否容易控制
    11.
    经济系统
     
    是否有灵活的赚钱方式,无论是在线人多的时候,还是人少的时候,是
     
    否有恶性竞争的情况,是否有赚钱的可能也有花钱的需要,是否容易出
     
    现通货膨胀
    12.
    社会系统
     
    玩家之间的组织性如何,凝聚力如何,有无结婚、帮派之类的提升凝聚
     
    力的方式,这些方式中的交流程度是否足够,管理方式是否合情合理
    13. PK
    制度
     
    有无方便的方式给予玩家解决恩怨,会不会出现恶性PK,屠杀的情况,
     
    会不会对危害到新人的生存
    14.
    系统负荷
     
    能支持多少人在线
    15.
    持续发展
     
    随着玩家的成长,有什么可以新的可以做的吸引人的东西
    16.
    管理制度
     
    是否有良好的GM管理,畅通的游戏返馈方式
    17.
    外挂处理
     
    杜绝恶性外挂的能力如何

    初级玩家
    1.
    详细描述自己遇到的BUG
    2.
    描述自己遇到的不方便之处
    中级玩家
    1.
    描述自己感觉到的不合理之处
    2.
    提出自己认为的不平衡的地方
    高级玩家
    1.
    探讨管理模式
    2.
    探讨游戏平衡
    3.
    探讨中后期发展
    策划模式
    1.
    玩家的发展问题
    2.
    游戏的平衡问题
    3.
    世界经济、社会的均衡发展
    4.
    玩家的心理与游戏模式的平衡
    5.
    吸引新手、留住老玩家的平衡
    6.
    当前需要做工作的轻重缓急

  • TamperIE - a little tool for Web testing

    2008-05-09 15:39:41

    TamperIE is a little tool which could catch the information of user’s request in UI. It is an IE plug-ins, if you install it successful you will find it in IE toolbar. You can also use it in VMWare.

    For Web testing, we can use it to catch the data of transferred between UI and Web server. And we can modify any parameters value to we want. Just like : Boundary valueinvalid date etc.

    1.      How to install TamperIE in VMWare

    Ø      You should download the install file first.

    Ø      It is very simple to install it successful. Just click the “next” button step by step.

    Ø      after install , it should be configured then check it work correctly

    2. How to configure TamperIE

    Ø      Open an IE, find “TamplerIE control panel” in IE panel and click it

    Ø      In the panel, select “TamplerIE with Http POSTs” from checkbox

    Ø      Close the panel

                           

    Normally, we can use TamplerIE to get HTTP POSTs correctly. If you open an IE and click any button or link from page, TamplerIE-Edit Request panel will show up and you can change any parameters values or add parameters freely.

    3. How to change the value of the parameters in TamperIE

    Ø      On the bottom of the TamplerIE-Edit Request panel, click “Pretty POST” button

    Ø      It shows the list of parameters, you can click on any parameters and then change it in Edit Field

    Ø      Then click Send altered data to finish it

    4. How to add a parameter in TamperIE

         It's almost like alter value of parameters

    Ø      On the bottom of the TamplerIE-Edit Request panel, click “Pretty POST” button

    Ø      It shows the list of parameters, you should click “Add field” icon to add a new  field in the list

    Ø      Click the new parameter from the list and fill the Name and Value in Edit Field   

    Ø      Then click Send altered data to finish it

     

    5. How to get XML from TamperIE

                There are 2 parameters to get XML in TamplerIE which need you manual add them into parameter list.

    Ø      mver: the parameter is about the request/response version about XML..

    Ø      ofmt: the tag could get the ofmtxml format which different from other format.

    E.g. In Row POST panel, you can add “&mver=3&ofmt=3” in it and then click send altered data to get XML.

  • QTP9.0破解方法

    2008-05-07 22:22:58Digest 1

    QTP9.0破解方法:


    1.安装试用版QTP9.0;
    2.安装16进制编辑器,并用16进制编辑器打开QTPro.exe;

     (该文件在:安装盘:\Mercury Interaction\QuickTest Professional\bin\) 
    3.把 00002B70 h 和 00122900 h地址 处的 10 改成0B;

    4.修改完后保存,破解成功.无QTP license过期错误提示。

    这个方法我已经试过,可以成功破解。

  • 负载测试、容量测试和强度测试的区别[转]

    2008-04-28 10:52:47

      负载测试:负载测试是一种性能测试,指数据在超负荷环境中运行,程序是否能够承担。 强度测试:强度测试是一种性能测试,他在系统资源特别低的情况下软件系统运行情况。
     容量测试:确定系统可处理同时在线的最大用户数。

    1.强度测试或压力测试:强度或压力测试是在一种需要异常数量、频率或资源的方式下,执行可重复的负载测试,以检查程序对异常情况的抵抗能力,找出性能瓶颈。异常情况,主要指那些峰值、极限值、大量数据的长时间处理等,包括:连接或模拟了最大(实际或实际允许)数量的客户机; 所有客户机在长时间内执行相同的、性能可能最不稳定的重要业务功能;已达到最大的数据库大小,而且同时执行多个查询或报表事务当中断的正常频率为每秒一至两个时,运行每秒产生十个中断的测试用例;运行可能导致虚存操作系统崩溃或大量数据对磁盘进行存取操作的测试用例等。压力测试可以分为稳定性测试和破坏性测试:
    稳定性压力测试。在选定的压力值下,持续运行24小时以上的测试。通过压力测试,可以考察各项性能指标是否在指定范围内,有无内存泄漏、有无功能性故障等。 破坏性压力测试。在压力稳定性测试中可能会出现一些问题,如系统性能明显降低,但很难暴露出其真实的原因。通过破坏性不断加压的手段,往往能快速造成系统的崩溃或让问题明显的暴露出来。
    在压力测试中,会给程序加上一些跟踪机制(如log、日志等),然后查看监视系统、服务器等性能的日志文件是必要的,找出问题出现的关键时间或检查测试运行参数,通过分析问题或参数从而有目的地调整测试策略或测试环境,使压力测试结果真实地反映出软件的性能。

    2.性能测试系统的性能指标,一般赢在产品需求文档中有明确定义,有三种形式描述软件系统的性能指标:
    给出产品性能的主要指标,如在100000记录中查询一个特定数据的时间为0.5秒。以某个已发布的版本为基线,如比上一个版本的性能提高30-50%。 和竞争对手的同类产品比较。
    性能测试,根据其目的分为:产品性能质量测试,通过测试,决定产品是否达到产品规格书所要求的性能指标(非功能性需求)基准值测试,通过对当前产品的性能测试,确定产品具体的性能指标,建立性能指标基准。基准值,作为后继产品发布的性能参考(在新版本中,性能指标要求只升不降)或和竞争对手产品比较的参考。
    性能规划测试,通过不断的测试,确定所需要的硬件配置(内存、CPU、网络等)、软件配置,以满足实现定义的性能指标要求。这种测试,对于软件系统的部署是非常有意义的。同时,也可以进一步了解硬件参数、软件参数对系统性能的影响程度,从而保证系统具有很好的扩充性或事先制定较好的系统增容的计划。
    性能测试的方法,主要有:稳定压力加载,一次性将负载加到某个水平,持续一段时间,也称为flat测试。 逐渐加载或交替加载到某个负载水平,也称为“ramp-up”测试。 峰谷测试,确定从系统高峰时间的负载转为几乎空闲、再攀升到高负载这样峰值交替情况下的系统性能状态/指标。这种测试兼有容量测试的特点或属于容量测试的一部分。
    性能测试,一般都通过测试工具来模拟人为的操作而进行。性能测试的重点在于测试环境的建立、前期数据的设计与后期数据的分析。因为性能测试需要获得一定特定条件下(如100、200、500、1000个实时的连接)的系统占用资源(CPU、内存等)数据或系统行为表现,而且还要依靠测试工具或软件系统记录下这些指标变化的数据结果。例如,如果对一个Browser/Server结构的网络实时在线的培训系统软件进行测试,系统性能焦点是在不同数量的并发连接下,服务器的CPU、内存的占用率、客户端的响应时间等。测试过程中,并发连接的不断增加(负载的增加)在系统性能上的表现越来越明显。在系统性能测试时,加载过程中,每到一个测试点时须让系统平稳运行一段时间后再获取数据,以消除不同测试点的相互影响。从表中可以看出,同样是300个用户,1?00与60?的性能表现差别很大,加载的方式对系统性能影响也较大,所以,尽量模拟不同的加载方式来进行系统的性能测试。除此之外,还可以测试TCP、HTTPS等不同连接方式下的数据,进行比较。通过比较和分析,可以清楚知道系统的性能状况,以及什么样的条件下系统性能达到最佳状况、什么地方是性能的瓶颈。性能测试要求测试环境应尽量与产品运行环境保持一致,应单独运行,尽量避免与其他软件同时使用。

    3.容量测试软件测试专业网站:51Testing软件测试网/HXEnm mB
    通过性能测试,如果找到了系统的极限或苛刻的环境中系统的性能表现,在一定的程度上,我们完成了负载测试和容量测试。容量可以看作系统性能指标中一个特定环境下的一个特定性能指标,即设定的界限或极限值。容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值(如最大并发用户数、数据库记录数等),系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。对软件容量的测试,能让软件开发商或用户了解该软件系统的承载能力或提供服务的能力,如某个电子商务网站所能承受的、同时进行交易或结算的在线用户数。知道了系统的实际容量,如果不能满足设计要求,就应该寻求新的技术解决方案,以提高系统的容量。有了对软件负载的准确预测,不仅能对软件系统在实际使用中的性能状况充满信心,同时也可以帮助用户经济地规划应用系统,优化系统的部署。

       压力测试、容量测试和性能测试的关系:压力测试可以看作是容量测试、性能测试和可靠性测试的一种手段,不是直接的测试目标。压力测试的重点在于发现功能性测试所不易发现的系统方面的缺陷。而容量测试和性能测试是系统测试的主要目标内容,也就是确定软件产品或系统的非功能性方面的质量特征,包括具体的特征值。容量测试和性能测试更着力于提供性能与容量方面的数据,为软件系统部署、维护、质量改进服务,并可以帮助市场定位、销售人员对客户的解释、广告宣传等服务。压力测试、容量测试、性能测试,测试的方法相似、相通,在实际测试工作中,往往结合起来进行,以提高测试效率。一般会设置专门的性能测试实验室,完成这些工作。即使用虚拟的手段模拟实际操作,所需要的客户端有时还是很大的,所以性能测试实验室的投资较大。

  • 性能测试系列视频讲座

    2008-04-28 10:38:45Digest 2

    推荐一个不错的性能视频讲座连接:

    性能测试系列讲座-小布老师主讲:

    URLhttp://www.sg138.cn/page.php?pageid=3

  • 界面测试 [转]

    2008-04-26 15:03:04

       界面是软件与用户交互的最直接的层,界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作,起到向导的作用。同时界面如同人的面孔,具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉,相反由于界面设计的失败,让用户有挫败感,再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度还远远不够,直到最近网页制作的兴起,才受到专家的青睐。
     
    目前流行的界面风格有三种基本方式:多窗体、单窗体以及资源管理器风格,无论那种风格,以下规则是应该被重视的。
     
    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):专业性强的软件要使用相关的专业术语,通用性界面则提倡使用通用性词眼。
     
    2: 规范性:
    通常界面设计都按Windows界面的规范来设计,即包含“菜单条、工具栏、工具厢、状态栏、滚动条、右键快捷菜单”的标准格式,可以说:界面遵循规范化的程度越高,则易用性相应的就越好。小型软件一般不提供工具箱。
     
    规范性细则:
    1):常用菜单要有命令快捷方式。
    2):完成相同或相近功能的菜单用横线隔开放在同一位置。
    3):菜单前的图标能直观的代表要完成的操作。
    4):菜单深度一般要求最多控制在三层以内。
    5):工具栏要求可以根据用户的要求自己选择定制。
    6):相同或相近功能的工具栏放在一起。
    7):工具栏中的每一个按钮要有及时提示信息。
    8):一条工具栏的长度最长不能超出屏幕宽度。
    9):工具栏的图标能直观的代表要完成的操作。
    10):系统常用的工具栏设置默认放置位置。
    11):工具栏太多时可以考虑使用工具箱。
    12):工具箱要具有可增减性,由用户自己根据需求定制。
    13):工具箱的默认总宽度不要超过屏幕宽度的1/5。
    14):状态条要能显示用户切实需要的信息,常用的有:
     
    目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等,
     如果某一操作需要的时间较长,还应该显示进度条和进程提示。
    15):滚动条的长度要根据显示信息的长度或宽度能及时变换,以利于用户了解显示信息的位置和百分比。
    16):状态条的高度以放置5号字为宜,滚动条的宽度比状态条的略窄。
    17):菜单和工具栏要有清楚的界限;菜单要求凸出显示,这样在移走工具栏时仍有立体感。
    18):菜单和状态条中通常使用5号字体。工具栏一般比菜单要宽,但不要宽的太多,否则看起来很不协调。
    19):右键快捷菜单采用与菜单相同的准则。
     
    3:帮助设施:
     
    系统应该提供详尽而可靠的帮助文档,在用户使用产生迷惑时可以自己寻求解决方法。
     
    帮助设施细则:
    1):帮助文档中的性能介绍与说明要与系统性能配套一致。(我们的系统帮助文档都是系统的祖先时期的说明,让人困惑)。
    2):打包新系统时,对作了修改的地方在帮助文档中要做相应的修改。
    3):操作时要提供及时调用系统帮助的功能。常用F1。
    4):在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。也就是说帮助要有即时针对性。
    5):最好提供目前流行的联机帮助格式或HTML帮助格式。
    6):用户可以用关键词在帮助索引中搜索所要的帮助,当然也应该提供帮助主题词。
    7):如果没有提供书面的帮助文档的话,最好有打印帮助的功能。
    8):在帮助中应该提供我们的技术支持方式,一旦用户难以自己解决可以方便的寻求新的帮助方式。
     
    4:合理性:
     
    屏幕对角线相交的位置是用户直视的地方,正上方四分之一处为易吸引用户注意力的位置,在放置窗体时要注意利用这两个位置。
     
    合理性细则:
    1):父窗体或主窗体的中心位置应该在对角线焦点附近。
    2):子窗体位置应该在主窗体的左上角或正中。
    3):多个子窗体弹出时应该依次向右下方偏移,以显示窗体出标题为宜。
    4):重要的命令按钮与使用较频繁的按钮要放在界面上注目的位置。(默认界面应该只显示目标用户最常使用的功能,至于不常用到的高级功能,可以“隐藏”起来,比如说,放到菜单里,不要都做成按钮摆到界面上。果真需要需要这些高级功能的话,用户自然会到菜单里去找的。 )
    5):错误使用容易引起界面退出或关闭的按钮不应该放在易点位置。横排开头或最后与竖排最后为易点位置。
    6):与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示,没法使用该按钮)。
    7):对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会。
    8):非法的输入或操作应有足够的提示说明。
    9):对运行过程中出现问题而引起错误的地方要有提示,让用户明白错误出处,避免形成无限期的等待。
    10):提示、警告、或错误说明应该清楚、明了、恰当。
     
    5:美观与协调性:
    界面应该大小适合美学观点,感觉协调舒适,能在有效的范围内吸引用户的注意力。
    美观与协调性细则:
    1):长宽接近黄金点比例,切忌长宽比例失调、或宽度超过长度。
    2):布局要合理,不宜过于密集,也不能过于空旷,合理的利用空间。
    3):按钮大小基本相近,忌用太长的名称,免得占用过多的界面位置。
    4):按钮的大小要与界面的大小和空间要协调。
    5):避免空旷的界面上放置很大的按钮。
    6):放置完控件后界面不应有很大的空缺位置。
    7):字体的大小要与界面的大小比例协调, 通常使用的字体中宋体9-12较为美观,很少使用超过12号的字体。
    8):前景与背景色搭配合理协调,反差不宜太大,最好少用深色,如大红、大绿等。蓝色文字以白色背景容易识别,而在红色背景则不易分辨,原因是红色和蓝色没有足够反差,而蓝色和白色反差很大。除非特殊场合,杜绝使用对比强烈,让人产生憎恶感的颜色。常用色考虑使用Windows界面色调。
    9):整个界面色彩尽量少的使用类别不同的颜色。统一色调,针对软件类型以及用户工作环境选择恰当色调:如:安全软件,根据工业标准,可以选取黄色,绿色体现环保,蓝色表现时尚、紫色表现浪漫等等,淡色可以使人舒适,暗色做背景使人不觉得累等
    10):如果使用其他颜色,主色要柔和,具有亲和力与磁力,坚决杜绝刺目的颜色。
    11):大型系统常用的主色有"#E1E1E1"、"#EFEFEF"、"#C0C0C0"等。
    12):界面风格要保持一致,字的大小、颜色、字体要相同,除非是需要艺术处理或有特殊要求的地方。
    13):如果窗体支持最小化和最大化或放大时,窗体上的控件也要随着窗体而缩放;切忌只放大窗体而忽略控件的缩放。
    14):对于含有按钮的界面一般不应该支持缩放,即右上角只有关闭功能。
    15):通常父窗体支持缩放时,子窗体没有必要缩放。
    16):如果能给用户提供自定义界面风格则更好,由用户自己选择颜色、字体等。

    6:菜单位置:
    菜单是界面上最重要的元素,菜单位置按照按功能来组织。
    菜单位置细则:
    1):菜单通常采用“常用--主要--次要--工具--帮助”的位置排列,符合流行的Windows风格。
    2):常用的有“文件”、“编辑”,“查看”等,几乎每个系统都有这些选项,当然要根据不同的系统有所取舍。
    3):下拉菜单要根据菜单选项的含义进行分组,并切按照一定的规则进行排列,用横线隔开。
    4):一组菜单的使用有先后要求或有向导作用时,应该按先后次序排列。
    5):没有顺序要求的菜单项按使用频率和重要性排列,常用的放在开头, 不常用的靠后放置;重要的放在开头,次要的放在后边。
    6):如果菜单选项较多,应该采用加长菜单的长度而减少深度的原则排列。
    7):菜单深度一般要求最多控制在三层以内。
    8):对常用的菜单要有快捷命令方式,组合原则见8。
    9):对与进行的操作无关的菜单要用屏蔽的方式加以处理,如果采用动态加载方式——即只有需要的菜单才显示——最好。
    10):菜单前的图标不宜太大,与字高保持一直最好。
    11):主菜单的宽度要接近,字数不应多于四个,每个菜单的字数能相同最好。
    12):主菜单数目不应太多,最好为单排布置。

    7:独特性:
    如果一味的遵循业界的界面标准,则会丧失自己的个性.在框架符合以上规范的情况下,设计具有自己独特风格的界面尤为重要。尤其在商业软件流通中有着很好的迁移默化的广告效用。
    独特性细则:
    1):安装界面上应有单位介绍或产品介绍,并有自己的图标。
    2):主界面,最好是大多数界面上要有公司图标。
    3):登录界面上要有本产品的标志,同时包含公司图标。
    4):帮助菜单的“关于”中应有版权和产品信息。
    5):公司的系列产品要保持一直的界面风格,如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致。
     
    8:快捷方式的组合
    在菜单及按钮中使用快捷键可以让喜欢使用键盘的用户操作得更快一些。在西文Windows及其应用软件中快捷键的使用大多是一致的。
    菜单中:
    1):面向事务的组合有:
            Ctrl-D 删除
            Ctrl-F 寻找
            Ctrl-H 替换
            Ctrl-I 插入
            Ctrl-N 新建
            Ctrl-S 保存
            Ctrl-O 打开
    2):列表:
            Ctrl-R   刷新
            Ctrl-G   定位
            Ctrl-Tab 下一分页窗口或反序浏览同一页面控件
    3):编辑:
            Ctrl-A 全选
            Ctrl-C 拷贝
            Ctrl-V 粘贴
            Ctrl-X 剪切
            Ctrl-Z 撤消操作
            Ctrl-Y 恢复操作
    4):文件操作:
            Ctrl-P 打印
            Ctrl-W 关闭
    5):系统菜单
            Alt-A 文件
            Alt-E 编辑
            Alt-T 工具
            Alt-W 窗口
            Alt-H 帮助
    6):MS Windows保留键:
            Ctrl-Esc 任务列表
            Ctrl-F4 关闭窗口
            Alt-F4 结束当前程序
            Alt-Tab 切换当前程序
            Enter 缺省按钮/确认操作
            Esc 取消按钮/取消操作
            Shift-F1 上下文相关帮助
    按钮中:
    可以根据系统需要而调节,以下只是常用的组合。
            Alt-Y 确定(是)
            Alt-C 取消
            Alt-N 否
            Alt-D 删除
            Alt-Q 退出
            Alt-A 添加
            Alt-E 编辑
            Alt-B 浏览
            Alt-R 读
            Alt-W 写
    这些快捷键也可以作为开发中文应用软件的标准,但亦可使用汉语拼音的开头字母(不推荐)。

    9:安全性考虑:
    在界面上通过下列方式来控制出错几率,会大大减少系统因用户人为的错误引起的破坏。开发者应当尽量周全地考虑到各种可能发生的问题,使出错的可能降至最小。
    如应用出现保护性错误而退出系统,这种错误最容易使用户对软件失去信心。因为这意味着用户要中断思路,并费时费力地重新登录,而且已进行的操作也会因没有存盘而全部丢失。

    安全性细则: 
    1):最重要的是排除可能会使应用非正常中止的错误。
    2):应当注意尽可能避免用户无意录入无效的数据。
    3):采用相关控件限制用户输入值的种类。
    4):当用户作出选择的可能性只有两个时,可以采用单选框。
    5):当选择的可能再多一些时,可以采用复选框,每一种选择都是有效的,用户不可能输入任何一种无效的选择。
    6):当选项特别多时,可以采用列表框,下拉式列表框。
    7):在一个应用系统中,开发者应当避免用户作出未经授权或没有意义的操作。
    8):对可能引起致命错误或系统出错的输入字符或动作要加限制或屏蔽。
    9):对可能发生严重后果的操作要有补救措施。通过补救措施用户可以回到原来的正确状态。
    10):对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符。
    11):对错误操作最好支持可逆性处理,如取消系列操作。
    12):在输入有效性字符之前应该阻止用户进行只有输入之后才可进行的操作。
    13):对可能造成等待时间较长的操作应该提供取消功能。
    14):特殊字符常有;;’”><,`‘:“[”{、\|}]+=)-(_*&&^%$#@!,.。?/还有空格。(此外,还要注意全角和半角符号的区别)
    15):与系统采用的保留字符冲突的要加以限制。
    16):在读入用户所输入的信息时,根据需要选择是否去掉前后空格。
    17):有些读入数据库的字段不支持中间有空格,但用户切实需要输入中间空格,这时要在程序中加以处理。

    10:多窗口的应用与系统资源:
    设计良好的软件不仅要有完备的功能,而且要尽可能的占用最底限度的资源。
    应用细则:
    1):在多窗口系统中,有些界面要求必须保持在最顶层,避免用户在打开多个窗口时,不停的切换甚至最小化其他窗口来显示该窗口。
    2):显示多个窗口时,窗口的名称是否被适当地表示?
    3):活动窗口是否被适当地加亮?
    4):如果使用多任务,是否所有的窗口被实时更新?
    5):在主界面载入完毕后自动卸出内存,让出所占用的WINDOWS系统资源。
    6):关闭所有窗体,系统退出后要释放所占的所有系统资源 ,除非是需要后台运行的系统。
    4):尽量防止对系统的独占使用。
    美丽的事物常常会让人无法抗拒。这就是为什么产品出色的外观设计对于电脑、汽车、日用品、家具、食品、服装等等几乎所有商品的销售与推广,都有着举足轻重的作用的原因。
    同样的道理,对于软件公司来说,软件产品就是他们的商品,而软件界面就是他们产品的外观,界面的美观与否,直接关系到了软件产品的营销成败。

  • 安装与卸载测试

    2008-04-26 14:56:40

    一、安装测试
    常规功能测试
    0、安装手册给的所有步骤得到验证;
    1、安装过程中所有缺省选项得到验证;
    2、安装过程中典型选项得到验证;
    3、测试各种不同的安装组合,并验证各种不同组合的正确性(包括参数组合,控件执行顺序组合,产品安装组件组合,产品组件安装顺序组合(如b/s)等)
    4、安装界面的所有信息都显示正确、没有错误别子、没有二义性;
    5、安装界面的每个按钮都进行校验有效性;
    6、安装后是否能产生正确的目录结构和文件,文件属性正确;
    7、安装后动态库是否正确;
    8、安装后软件能否正确运行;
    9、安装后没有生成多余的目录结构,文件,注册表信息,快捷方式等;
    10、如果安装程序有重新安装功能的话,要考虑重新安装是否正常。
    增强测试
    1、验证用户机器已安装相同产品的情况下再进行安装,安装程序是否有进行相应校验;
    2、安装测试应该在所有的运行环境上进行验证(手册上指定如:操作系统(XP\2000\2003),数据库,硬件环境,网络环境等)
    3、安装路径要考虑几种情况:a、安装路径较长;b、安装路径中包含空格;c、安装路径包含中文;d、安装路径包含特殊字符;e、安装路径编码规范校验(比如c:crm或c:/crm)
    4、硬盘分区、可用空间校验:a、硬盘空间不足;b、硬盘分区不存在(如用户机器不存在F盘,安装路径输入F盘);c、空间本来充足的情况下,在安装过程中往磁盘空间放入大量文件,导致磁盘空间不足的情况。
    5、目的安装文件夹为只读的情况;
    6、在安装过程中人为访问其他软件,比如安装过程中打开word文档或打开IE上网;
    7、同时运行两个安装程序的情况:验证同时运行相同的安装程序及同时运行不同的安装程序两种情况;
    8、在笔记本环境下进行安装卸载,因为有很多产品在笔记本中会出现问题,尤其是系统级的产品;
    9、考虑文件被占用的情况下进行程序回滚或卸载;
    10、校验执行安装包的系统权限,即以系统管理员权限进行安装及非系统管理员权限进行安装;
    异常测试
    1、安装过程中计算机断电,要保证重新插上电源,重新安装可以正常安装;
    2、安装过程中计算机重启,要保证计算机重启后,重新安装可以正常安装;
    3、安装过程中安装进程被迫停止(即手动停止进程),要保证重新安装可以正常安装;
    4、安装包如果有创建数据库步骤,则要考虑在创建数据库步骤时数据库服务停止,安装包是否进行友好提示;重启数据库服务后,是否还可以重新安装;
    二、卸载测试
    1、文件删除情况---卸载后是否删除安装时所创建的文件及文件夹(如:程序安装在几处的)、非安装目录(向系统其它地方添加的文件及文件夹),它们包括(exe,dll,配置文件等) ,快捷方式-(桌面,菜单,任务栏,系统栏,控件面板,系统服务列表等)
    2、复原方面---卸载后,系统能否恢复到软件安装前的状态(包含目录结构、动态库,注册表,系统配置文件,驱动程序,关联情况等)(专门的测试工具regsnap)
    3、卸载方式--程序自带卸载程序/系统的控件面板卸载/其它自动卸载工具(如:优化大师)
    4、卸载状态--程序在运行/暂停/终止等状态时的卸载
    5、非正常卸载情况-卸载软件过程中,取消卸载进程,或计算机断电,或计算机重启;然后,启动计算机后,重新卸载软件,如果软件无法卸载,则重新安装软件,安装之后再重新卸载。
    6、卸载环境--不同的(操作系统,硬件环境,网络环境等)下进行卸载
    7、卸载后,该系统是否对其他的应用程序造成不正常影响(如操作系统,应用软件等)
    8、健壮性测试:在用户机器上进行反复的安装-卸载-再安装
  • How to write a good bug?

    2007-12-31 15:48:25

       We hear it often from mentors & managers the importance of writing good bug reports. But it is really beneficial to everyone who looks at your bugs especially if the bug is assigned to someone else to verify or if the triage group (who has no idea about your feature) wants to understand the impact of the bug. While writing a bug, always write it with the thought in mind that if a totally new person were to read this bug, he/she would understand the exact problem and the expected results. If all the relevant information is included in the bug, then less time will also be spent in trying to gather all the information by the assignee (EX:Dev/PM) of the bug, who is trying to fix it.
    EX:

    • While reading a bug assigned to a developer, he/she should have all the information related to the bug. (Ex: Environment, IP, exact repro steps, what is the actual result, what is the expected result, any other notes you need to include etc. Other very useful information to include in the bug is any error events in the event viewer logs, SQL query you used against the db (to verify information logged in db), which SQL server & db you are using, a screenshot if it is a UI bug, etc if applicable etc.

    How to Steps

    Notes: Before filing a bug, make sure of the following :

    • Make sure it is a bug & not expected functionality. Verify against spec. If information is missing from the spec, check with PM & file a spec bug to update the spec.
    • Check for duplicates. If a bug already exists for the issue at hand, read the bug. If you think you have gathered more information than what is included in the bug or have exact repro steps, please include them in the existing bug as well.
    • Check on HF box if bug is existing on live site as well.
    • Does it repro on other place (if applicable).
    • If your bug includes more than one issue, try to search if the other issues are already in . If yes, link the bugs.
    • If the bug fix or details for the same are being discussed in email, make sure to include those details in the bug as well.
    • When closing a bug, please include details on the repro steps you followed & all the areas you verified (db, event logs, different place, etc), especially if you are verifying a bug that is not opened by you.
    • When regressing a bug, also include other existing functionality verified in addition to the bug fix in the bug details, to make sure all the areas affected by the fix are working correctly.

    Anatomy of a bug:

    • Title: Titles should be Clear, Concise, and describe the problem accurately. If you are writing one bug for 2 related issues, please file 2 different bugs & link them. A good title of a bug should include three sides , just “Who , What , Where”.
    • Status:
      1. Status: By default opening a bug sets it state to active. If you resolve a bug, make sure you change the status to resolved.
      2. Assigned To: Assign bug to the right person. If you are not sure, check with feature PM or your manager.
      3. Issue Type: Select the correct Issue type from the drop down.
      4. Severity & Priority: Complete these fields correctly with the new definitions.
    • Opened:
      1. Open name: Who opened this bug?
      2. Date: When is this bug be opened?
      3. How Found: by check requirement or by test etc.
    • Project:
      1. Project name: Which the project name did you find the bug in?
      2. Module name: Which the module name did you find the bug in?
      3. Open Version: Which environment did you open the bug in ?
      4. Fix Version: Which envt do you want this bug fixed in?
      5. Milestone: When do you want the bug fixed by?
    • Bug Descrīption:
      1. Descrīption: A more detailed explanation of the problem.
      2. Steps to Repro: Good repro steps require less investigation by both dev and test.              Good repro steps always begin with a link to the site where you found the problem. Good repro steps can be followed by someone unfamiliar with your area.
      3. Expected Result: The descrīption should also contain the result you witnessed and the result you expected (and any clarification needed as to the difference).
      4. Actual Result: A descrīption of what happened after the above steps were followed.
      5. Attachments: A screen shot can also be attached and can add a great deal of clarity. A picture is worth 1000 words... (save as jpg or gif, to avoid 2 MB bitmap files, Power Point is a good tool to show successive steps to repro the bug ) .
      6. Other place: This kind of bug if it can be find in any other place or not. Does it happen in the other condition? Does it happen in the other language?
      7. Browser: Which browser is this bug be found in? (use in WEB test)
      8. Automation/Tools: If it is found by auto tools or not.
      9. Events/Logs
      10. DB Server/DB/SQL query
  • C/S结构与B/S结构的特点分析(转载)

    2007-05-27 17:49:32

    C/S结构与B/S结构的特点分析

    为了区别于传统的C/S模式,才特意将其称为B/S模式。认识到这些结构的特征,对于系统的选型而言是很关键的。

      1、系统的性能

      在系统的性能方面,B/S占有优势的是其异地浏览和信息采集的灵活性。任何时间、任何地点、任何系统,只要可以使用浏览器上网,就可以使用B/S系统的终端。

      不过,采用B/S结构,客户端只能完成浏览、查询、数据输入等简单功能,绝大部分工作由服务器承担,这使得服务器的负担很重。采用C/S结构时,客户端和服务器端都能够处理任务,这虽然对客户机的要求较高,但因此可以减轻服务器的压力。而且,由于客户端使用浏览器,使得网上发布的信息必须是以HTML格式为主,其它格式文件多半是以附件的形式存放。而HTML格式文件(也就是Web页面)不便于编辑修改,给文件管理带来了许多不便。

      2、系统的开发

      C/S结构是建立在中间件产品基础之上的,要求应用开发者自己去处理事务管理、消息队列、数据的复制和同步、通信安全等系统级的问题。这对应用开发者提出了较高的要求,而且迫使应用开发者投入很多精力来解决应用程序以外的问题。这使得应用程序的维护、移植和互操作变得复杂。如果客户端是在不同的操作系统上,C/S结构的软件需要开发不同版本的客户端软件。但是,与B/S结构相比,C/S技术发展历史更为“悠久”。从技术成熟度及软件设计、开发人员的掌握水平来看,C/S技术应是更成熟、更可靠的。

      3、系统的升级维护

      C/S系统的各部分模块中有一部分改变,就要关联到其它模块的变动,使系统升级成本比较大。B/S与C/S处理模式相比,则大大简化了客户端,只要客户端机器能上网就可以。对于B/S而言,开发、维护等几乎所有工作也都集中在服务器端,当企业对网络应用进行升级时,只需更新服务器端的软件就可以,这减轻了异地用户系统维护与升级的成本。如果客户端的软件系统升级比较频繁,那么B/S架构的产品优势明显——所有的升级操作只需要针对服务器进行,这对那些点多面广的应用是很有价值的,例如一些招聘网站就需要采用B/S模式,客户端分散,且应用简单,只需要进行简单的浏览和少量信息的录入。

      4、C/S 模式的优点和缺点

      ★ C/S 模式的优点
      ● 由于客户端实现与服务器的直接相连,没有中间环节,因此响应速度快。
      ● 操作界面漂亮、形式多样,可以充分满足客户自身的个性化要求。
      ● C/S结构的管理信息系统具有较强的事务处理能力,能实现复杂的业务流程。

      ★ C/S 模式的缺点
      ● 需要专门的客户端安装程序,分布功能弱,针对点多面广且不具备网络条件的用户群体,不能够实现快速部署安装和配置。
      ● 兼容性差,对于不同的开发工具,具有较大的局限性。若采用不同工具,需要重新改写程序。
      ● 开发成本较高,需要具有一定专业水准的技术人员才能完成。

      5、B/S模式的优点和缺点

      ★ B/S 模式的优点
      ● 具有分布性特点,可以随时随地进行查询、浏览等业务处理。
      ● 业务扩展简单方便,通过增加网页即可增加服务器功能。
      ● 维护简单方便,只需要改变网页,即可实现所有用户的同步更新。
      ● 开发简单,共享性强。

      ★ B/S 模式的缺点
      ● 个性化特点明显降低,无法实现具有个性化的功能要求。
      ● 操作是以鼠标为最基本的操作方式,无法满足快速操作的要求。
      ● 页面动态刷新,响应速度明显降低。
      ● 无法实现分页显示,给数据库访问造成较大的压力。
      ● 功能弱化,难以实现传统模式下的特殊功能要求。
      近年来,随着软硬件技术发展和人们意识的提高,Web应用得到广泛的普及,一方面在互联网浪潮的推动下,基于互联网的信息共享和电子商务不断发展,像新浪、搜狐、8848等大型网站不断涌现出来,另一方面随着Java、CGI等网络技术的成熟,基于B/S结构的大型软件逐渐显示出巨大的优势。同时,也就产生了一个焦点问题,什么样的服务器能够满足不同用户的需求,怎么能够保证Web服务器能够长期稳定地运行,为了满足这样的需求Web测试也就同样变得十分重要。

      当前Web测试主要通过Web测试工具加上良好的测试案例完成的,我们认为主要有以下两种测试类型:基准测试、非基准测试

      基准测试:主要指测试工具已经提供了标准的测试案例库,包括静态测试案例(HTM、JPG)、动态测试案例(CGI)和SSL测试案例等。这类测试工具分为测试案例库、控制台程序、客户端程序三个部分。它的原理是,Web服务器开启特定的Web服务程序,并且运行上述测试案例,由控制台程序控制各个客户端按照一定的脚本访问顺序遍历Web服务器的各个测试案例,每个请求完成后,各个客户端向控制台报告访问的结构,当一个测试集完成后由控制台将所有的信息综合统计,测试过程中控制台还需要采用SNMP协议对服务器进行实时监控,综合两个方面的因素可以反映出Web服务器在不同压力情况下的综合性能。

      在测试过程中,主要影响测试结果的因素有网络环境、客户端性能。目前无论IA架构服务器还是SUN、HP、IBM的UNIX服务器性能都越来越优越,有可能出现在100MB网络下不能够提供足够的网络压力,有可能网络首先出现瓶颈,这样就需要扩展到1000MB网络环境或使用多个网段对服务器提供足够的压力,而稳定的客户端对于测试来说也是十分重要的,因为客户端如果出现性能下降,就会造成系统崩溃或者不能提供稳定的测试压力从而导致测试结果出现偏差;一台客户端到底能够稳定运行多少数量的连接是根据不同的硬件配置和操作系统决定的,因此对客户端的硬件资源进行监控是保证客户端可以稳定运行的必要手段。

      由于这类测试工具使用的是工具开发商提供的测试案例集,虽然也具有一定的权威性,但是目前再完美的测试案例集也不能涵盖所有的Web应用情况,所以也不能够完全体现出Web服务器完整的性能,因此该类测试工具更加适合IT媒体对Web类服务器软硬件的横向对比测试,在测试对象和环境大体统一的情况下,可以比较出各个测试对象的性能差异。而对于有实际应用背景的Web服务器进行测试,使用这样的测试工具就不适合了,我们在以后的测试漫谈中会继续介绍。

  • 常规测试方法汇总

    2007-02-15 09:08:12

     

    常规测试方法

     

     

    一. 功能测试

     

    1. 安装测试

    1)     安装过程中对于缺省安装目录及任意指定的安装目录,是否都能正确安装;

    2)     若是选择安装,查看能否实现其相应的功能;

    3)     在所有能中途退出安装的位置退出安装程序后,验证此程序并未安装成功(没有程序组及程序项产生);

    4)     软件安装后,对其它已经安装的软件是否有影响;

    5)     裸机安装后,各功能点是否可用;

    6)     安装前,安装程序是否判断可用磁盘空间大小,如果不能满足安装空间要求,安装程序能否继续;

    7)     安装过程中查看 版权声明、版本信息、公司名称、LOGO等是否符合标准;

    8)     安装过程中界面显示与提示语言是否准确、友好;

    9)     重复安装时系统是否有提示、是否可以覆盖安装、是否可以升级安装、是否允许多版本共存;

    10)  是否有注册码或硬件加密狗,在没有它们(或错误)存在的情况下能否顺利安装。

     

    2.配置测试

    1)    是否可以按照用户手册的说明,运行于多种操作系统(Windows 各版本 、Unix Linux 等);

    2)    按系统最低要求进行软件的安装配置,查看能否正常实现各种功能;

    3)    数据源等信息配置不正确时能否给出提示信息;

    4)    是否可以按照用户手册的说明,支持多种数据库。

     

    3. 卸载测试

    1)     卸载后注册表中的注册信息及相关的程序安装目录是否能完全删除掉;

    2)     卸载过程中完全删除共享文件后,看其它程序能否正常运行;

    3)     卸载后,是否对其它已经安装的软件有影响;

    4)     系统卸载后用户建立文档是否保留;

    5)     软件卸载画面上的软件名称及版本信息是否正确;

    6)     在所有能中途退出卸载的位置是否能正确退出;

    7)     卸载过程中界面显示与提示语言是否准确、友好;

    8)     卸载后安装此系统能否打开原来保存的文件,并一切运行正常;

    9)     卸载程序如果要求重新启动机器,在重启动之间是否给用户提示以保存现有的己运行的程序的资料;

    10)  是否可以选择组件进行卸载;

    11)  卸载过程中,对意外情况的处理(掉电等)。

    12)  在卸载过程中,是否有终止或者结束按钮。

     

    4. 运行与关闭测试

    1)     运行时是否与其它应用程序有冲突(内存冲突)

    2)     是否可以同时运行多个程序;

    3)     任务栏有无程序运行提示;

    4)     若有未保存的数据,关闭系统时是否有提示;

    5)     后台服务程序在点击关闭按钮时是否有确认提示;

    6)     运行时是否过份占用系统资源、退出时能否完成释放占用的系统资源。

     

    5. 服务程序的测试

    1)    系统是否限制服务器程序启动的数量,如不限制,同一范围内启动多个服务是否对系统有影响;

    2)    服务程序能否长时间正常运行;

    3)    外界异常后,服务程序的自动恢复能力(服务器掉电、网络中断后恢复、数据库异常后恢复);

    4)    在点击关闭按钮时是否有确认提示;

    5)    应用程序与其他程序是否兼容(能否避免内存冲突)。

     

    6. 系统管理(参数设置)

    1)     参数设置后,能否正确的进行应用;

    2)     设置错误参数,系统的容错能力;

    3)     修改参数,对与之相关模块的影响;

    4)     系统是否有默认的参数,A 有:默认的参数是否起到作用;B 没有:不设置,系统能否运行或者给出提示。

     

    7. 用户、权限管理

    1)     赋予一个人员相应的权限后,在界面上看此人员是否具有此权限,并以此人员身份登陆,验证权限设置是否正确(能否超出所给予的权限);

    2)     删除或修改已经登陆系统并正在进行操作的人员的权限,程序能否正确处理;

    3)     重新注册系统变更登陆身份后再登录,看程序是否能正确执行,具有权限是否正确;

    4)     在有工作组或角色管理的情况下,删除包含用户的工作组或角色,程序能否正确处理;

    5)     不同权限用户登录同一个系统,权限范围是否正确;

    6)     覆盖系统所有权限设定;

    7)     能否添加信息为空的用户(其中包括空用户名及空口令、空用户名非空口令、非空用户名及空口令)

    8)     能否添加长用户名及长口令,如果允许,新用户能否正确登录;

    9)     系统是否允许删除系统管理员这一特殊用户或修改系统管理员口令,删除或修改后系统的实际情况;

    10)  登录用户能否修改自己的权限;

    11)  添加用户(有标识或编号):标识相同,用户名不同;标识相同,用户名相同;标识不同,用户名相同;标识不同,用户名不同;

    12)  登录用户能否修改本人(或其他人)的信息,删除本人(或其他人);

    13)  修改用户的信息(包括权限,口令,基本信息等),对其他模块的影响;

    14)  修改用户信息:修改后的用户信息和已经存在的用户信息相同;修改后的用户信息和已经存在的用户信息不同;

    15)  不给用户授权,是否允许登录;

    15)  改某些设置时,是否会影响具有上级权限及相同权限人员的设置;

    16)  系统管理员修改了某些数据,以其他人员身份登录时数据是否改变;

    17)  用户能否同时属于多个组,各个组的权限能否交叉;

    18)  删除后重新添加的用户是否具有以前的权限;更改用户各项属性(包括权限)看对权限是否有影响。

     

    8. 系统登录测试

    1)     使用合法用户登录系统;

    2)     用户名、口令错误或漏填时能否登陆;

    3)     系统是否容许多次非法登陆,是否有次数限制;

    4)     使用已登录账号登录系统系统能否正确处理;

    5)     使用禁用帐号登陆系统能否正确处理;

    6)     删除或修改后的用户用原用户登录;

    7)     不输入用户名和口令,重复点“确定”和“取消”按钮,是否允许登录。

     

    9.    注销

    1)    注销为原模块、新模块系统能否正确处理;

    2)    中止注销能否返回原模块、原用户;

    3)    注销为原用户、新用户系统能否正确处理;

    4)    使用错误的帐号、口令或无权限帐号、被禁用帐号进行注销。

     

    10. 修改口令

    1)    正常情况;

    2)    输入错误的原口令或新口令与确认口令不一致系统能否正确处理;

    3)    修改口令后,用原口令是否能登录(同时验证新口令是否有效);

    4)    是否能修改其它用户的口令。

           

    11. 右键功能

    1)     右键菜单中的功能是否与菜单(或工具栏)中对应的功能一致;

    2)     右键菜单中的功能能否正确实现;

    3)     同一菜单下的热键是否相同。

     

    12. 记录列表

    1)     增加重复记录、空白记录,系统能否正确处理;

    2)     修改后不保存(有保存按钮),系统能否正确处理;

    3)     删除或修改正在使用信息,系统能否正确处理;

    4)     删除级联记录的上游或下游记录,系统能否正确处理;

    5)     删除记录时是否有提示;

    6)     记录中包含的缺省系统信息能否删除和修改;

    7)     记录列表能否及时反应记录的变化;

    8)     记录变化之后系统相关信息能否及时更新;

     

    13. 统计、查询

    1)     对非法的时间范围系统能否正确处理;

    2)     统计查询语句包含多个与或非条件时,系统能否正确处理;

    3)     条件逻辑混乱,系统能否正确处理;

    4)     多表查询统计及单表查询统计功能是否正确实现;

    5)     分类查询、精确查询、无条件查询、组合查询能否完整列出满足条件的记录;

    6)     能否按系统默认的条件进行查询;

    7)     当统计时间段为当日、跨日、跨月、跨季、跨年度时,统计查询结果是否正确;

    8)     当某些操作被别人取消后,设置条件段为取消前、取消后、包含取消操作的一段时间;

    9)     以不同的权限登录时,统计、查询是否正确;

    10)  在查询或统计大数据量时,系统是否允许终止操作;

    11)  查询、统计按钮是否允许双击或更多的点击,系统做何反映;

    12)  查询出的数据是否允许修改。

     

    <SPAN lang=EN-US style="COL

331/212>