每天学一点,知识多一点。

发布新日志

  • SQL语句大全(转)

    2007-10-29 11:34:16

      --数据操作

      SELECT --从数据库表中检索数据行和列

      INSERT --向数据库表添加新数据行

      DELETE --从数据库表中删除数据行

      UPDATE --更新数据库表中的数据

      --数据定义

      CREATE TABLE --创建一个数据库表

      DROP TABLE --从数据库中删除表

      ALTER TABLE --修改数据库表结构

      CREATE VIEW --创建一个视图

      DROP VIEW --从数据库中删除视图

      CREATE INDEX --为数据库表创建一个索引

      DROP INDEX --从数据库中删除索引

      CREATE PROCEDURE --创建一个存储过程

      DROP PROCEDURE --从数据库中删除存储过程

      CREATE TRIGGER --创建一个触发器

      DROP TRIGGER --从数据库中删除触发器

      CREATE SCHEMA --向数据库添加一个新模式

      DROP SCHEMA --从数据库中删除一个模式

      CREATE DOMAIN --创建一个数据值域

      ALTER DOMAIN --改变域定义

      DROP DOMAIN --从数据库中删除一个域

       --数据控制

      GRANT --授予用户访问权限

      DENY --拒绝用户访问

      REVOKE --解除用户访问权限

      --事务控制

      COMMIT --结束当前事务

      ROLLBACK --中止当前事务

      SET TRANSACTION --定义当前事务数据访问特征

      --程序化SQL

      DECLARE --为查询设定游标

      EXPLAN --为查询描述数据访问计划

      OPEN --检索查询结果打开一个游标

      FETCH --检索一行查询结果

      CLOSE --关闭游标

      PREPARE --为动态执行准备SQL 语句

      EXECUTE --动态地执行SQL 语句

      DESCRIBE --描述准备好的查询

      ---局部变量

      declare @id char(10)

      --set @id = '10010001'

      select @id = '10010001'

  • WEB测试资料

    2007-05-31 15:53:16

    关于web测试
    1页面部分
    (1) 页面清单是否完整(是否已经将所需要的页面全部都列出来了)
    (2) 页面是否显示(在不同分辨率下页面是否存在,在不同浏览器版本中页面是是否显示)
    (3) 页面在窗口中的显示是否正确、美观(在调整浏览器窗口大小时,屏幕刷新是否正确)
    (4) 页面特殊效果(如特殊字体效果、动画效果)是否显示
    (5) 页面特殊效果显示是否正确

    2 页面元素部分
    (1)页面元素清单(为实现功能,是否将所需要的元素全部都列出来了,如按钮、单选框、复选框、列表框、超连接、输入框等等)
    (2)素是否显示(元素是否存在)
    (3)页面元素是否显示正确(主要针对文字、图形、签章)
    (4)页面元素的外形、摆放位置(如按钮、列表框、核选框、输入框、超连接等)
    (5) 页面元素基本功能是否实现(如文字特效、动画特效、按钮、超连接)
    (6) 页面元素的容错性列表(如输入框、时间列表或日历)
    (7) 页面元素的容错性是否存在
    (8) 页面元素的容错性是否正确

    3 功能部分
    (1) 数据初始化是否执行
    (2) 数据初始化是否正确
    (3) 数据处理功能是否执行
    (4) 数据处理功能是否正确
    (5) 数据保存是否执行
    (6) 数据保存是否正确
    (7) 是否对其他功能有影响
    (8) 如果影响其他功能,系统能否作出正确的反应
    (9) 其他错误
    (10) 对模块的具体功能进行测试时可以列出功能模块的所有功能,进行排列组合,测试所有情况
    如:某一功能模块具有最基本的增删改查功能,则需要进行以下测试
    单项功能测试(增加、修改、查询、删除)
    增加——>增加——>增加 (连续增加测试)
    增加——>删除
    增加——>删除——>增加 (新增加的内容与删除内容一致)
    增加——>修改——>删除
    修改——>修改——>修改 (连续修改测试)
    修改——>增加 (新增加的内容与修改前内容一致)
    修改——>删除
    修改——>删除——>增加 (新增加的内容与删除内容一致)
    删除——>删除——>删除 (连续删除测试)
    (11)查询功能分为两种情况,验证操作结果。
    一、打开页面时自动显示结果,则不特别强调;
    二、需要手工操作进行查询,则每次在其他功能完成后进行。
    4 提示信息
    (1) 成功、失败提示
    (2) 操作结果提示
    (3) 确认提示
    (4) 危险操作、重要操作提示
    (5) 返回页面 提示后显示的页面
    5 容错性
    注意以下几种情况
    (1) 为空、非空
    (2) 唯一性
    (3 )字长、格式
    (4) 数字、邮政编码、金额、电话、电子邮件、ID号、密码
    (5) 日期、时间
    (6) 特殊字符 (对数据库)英文单、双引号,&符号
    6 权限部分
    功能权限: 指定用户可以使用那些功能,不能使用那些功能
    数据权限: 指定用户可以处理那些数据,不可以处理那些数据。可
    以合并到功能测试
    操作权限: 在逻辑关系上,操作前后顺序、数据处理情况。可以合
    并到功能测试
    权限变化: 可以合并到功能测试

    (1) 功能权限是否存在
    (2 )功能权限是否正确
    (3) 数据权限是否存在
    (4) 数据权限是否正确
    (5)操作权限是否存在
    (6) 操作权限是否正确
    (7) 引起权限变化的功能列表
    (8) 功能权限变化还是数据权限变化,或两者兼有
    (9) 权限变化是否正确

    7 键盘操作
    (1) Tab键的使用
    (2) 上下方向键的使用
    (3) Enter键的使用
    (4) 系统设定快捷键的使用(如果设置有快捷键)

    8 测试中还应注意的其他事项
    (6) 完整性:是否是一个整体,没有功能缺损
    (7) 易用性:使用是否方便
    (8) 一致性:类似的问题用类似的方法处理
    (9) 提示信息:提示信息是否完整、正确、详细
    (10) 帮助信息:是否提供帮助信息,帮助信息的表现形式(页面文字、提示信息、帮助文件),帮助信息是否正确、详细
    (11) 兼容性:包括操作系统兼容和应用软件兼容,可能还包括硬件兼容
    (12) 可扩展性:是否由升级的余地,是否保留了接口
    (13) 稳定性:运行所需的软硬件配置,占用资源情况,出现问题时的容错性,对数据的保护
    (14) 运行速度:运行的快慢,带宽占用情况

    有几点:
    1.功能点测试:是否满足需求所要求的功能
    2.字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.
    3.字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.
    4.标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.
    5.中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.
    6.信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.
    7.界面测试:界面的正确性、一致性、友好性、易用性。

    用户界面测试是从最终的使用者用户的角度来看软件,软件难以理解,不易使用就是软件缺陷。可以从以下几个方面重点来检查用户界面:
    1.易用性检查:确保软件易于理解,方便使用。
    2.一致性检查:
    a.注意系统页面的风格是否一致,如字的大小、颜色、字体要相同。
    b.提示信息的表达方式是否一致。
    c.按钮排列顺序是否一致。
    d.back, cancel等按钮跳转页面处理是否一致。
    e.各字段的名称,位置、长度、类型是否和设计文档要求一致,如Employee No和LoginName不一致。
    3.正确性检查:检查页面上的form, button, table, header, footer,提示信息,还有其他文字拼写,句子的语法等是否正确。
    4.友好性检查:
    a.提示信息是否友好.
    b.系统应该在用户执行错误的操作之前提出警告,提示信息.
    c.页面分辨率检查,在各种分辨率浏览系统检查系统界面友好性。
    5.合理性检查:做delete, update, add, cancel, back等操作后,查看信息回到的页面是否合理。
    6.检查本地化是否通过:英文版不应该有中文信息,英文翻译准确,专业。
    7.页面最大化检查:测试最大化/最小化/还原时页面是否做了对应的处理。

     

  • 如何测试web网站?

    2007-05-28 23:34:42

       web网站本质上带有web服务器和客户端浏览器的C/S结构的应用程序。主要考虑web页面、TCP/IP通讯、Internet链接、防火墙和运行在web页面上的一些程序(例如,applet、javascrīpt、应用程序插件),以及运行在服务器端的应用程序(例如,CGI脚本、数据库接口、日志程序、动态页面产生器,asp等)。另外,因为服务器和浏览器类型很多,不同版本差别很小,但是表现出现的结果却不同,连接速度以及日益迅速的技术和多种标准、协议。使得web测试成为一项正在不断研究的课题。其它要考虑的如下:

    1、服务器上期望的负载是多少(例如,每单位时间内的点击量),在这些负载下应该具有什么样的性能(例如,服务器反应时间,数据库查询时间)。性能测试需要什么样的测试工具呢(例如,web负载测试工具,其它已经被采用的测试工具,web 自动下载工具,等等)?

    2、系统用户是谁?他们使用什么样的浏览器?使用什么类型的连接速度?他们是在公司内部(这样可能有比较快的连接速度和相似的浏览器)或者外部(这可能有使用多种浏览器和连接速度)?

    3、在客户端希望有什么样的性能(例如,页面显示速度?动画、applets的速度等?如何引导和运行)?

    4、允许网站维护或升级吗?投入多少?

    5、需要考虑安全方面(防火墙,加密、密码等)是否需要,如何做?怎么能被测试?需要连接的Internet网站可靠性有多高?对备份系统或冗余链接请求如何处理和测试?web网站管理、升级时需要考虑哪些步骤?需求、跟踪、控制页面内容、图形、链接等有什么需求?

    6、需要考虑哪种HTML规范?多么严格?允许终端用户浏览器有哪些变化?

    7、页面显示和/或图片占据整个页面或页面一部分有标准或需求吗?

    8、内部和外部的链接能够被验证和升级吗?多久一次?

    9、产品系统上能被测试吗?或者需要一个单独的测试系统?浏览器的缓存、浏览器操作设置改变、拨号上网连接以及Internet中产生的“交通堵塞”问题在测试中是否解决,这些考虑了吗?

    10、服务器日志和报告内容能定制吗?它们是否被认为是系统测试的主要部分并需要测试吗?

    11、CGI程序、applets、javascrīpts、ActiveX 组件等能被维护、跟踪、控制和测试吗?
  • ERP功能测试最佳实践:10个步骤确保ERP系统的可靠性

    2007-05-26 13:57:18

     

    简 介

    企业资源规划(ERP)软件应用为企业提供管理大规模关键业务功能的能力,包括产品规划、部件采购、库存维护、和供应商的互动交流、提供客户服务,以及订单跟踪等。有些ERP解决方案还可能包括一些财政和人力资源方面的应用模块。尽管这些应用通常不会直接生成效益,但是它们能让企业以一种有效的、切合实际的方式使用现有的客户数据,帮助合理化企业的业务活动,为企业新的和当前的客户提供高质量的服务。

     

    ERP应用通常使用一个单一的、中央数据存储器来服务于所有的模块。因此,当这些应用产生了性能问题时,很有可能影响到使用同一存储器的所有业务领域。ERP和共享数据结构间的这种关系决定了它必须实施稳固的测试和监测程序才能确保企业关键应用的健康运行。 

     

     步骤1:初始规划和收集需求

    步骤2:定义测试目标和选择合适的测试

    步骤3:定义目的,以满足测试目标

    步骤4:发现功能测试案例

    步骤5:文档记录关键的业务流程

    步骤6:开发模块化的测试组件

    步骤7:建立测试实验室

    步骤8:掌握和利用“冒烟测试”

    步骤9:执行回归测试

    步骤10:分析缺陷和创建测试报告

    Mercury QuickTest Professional

    ERP应用的功能测试

    更多信息

     

     

    由于业务流程交易跨越企业中的多个部门和区域,并且涉及ERP应用本身的多个模块,因此测试ERP应用应该采用一种整体的方式。当验证这些业务流程的功能时,关键在于捕获自动化测试解决方案中的业务流程测试,用于实现快速的测试重复。由于ERP应用跨越多个业务领域,存在不可避免的复杂性,因此,对每个ERP应用以及每个应用发布版本展开功能测试是非常重要的。

     

    每个ERP实施中都会面临的主要挑战之一就是确保应用在上线之前能满足所有的业务需求。关键在于测试和验证这些应用的运作情况是否符合设计要求。在数千个客户实施基础上,美科利已经编纂了一套最佳实践,来确保关键业务应用的功能。在下文中将详细描述10个关键步骤,使用这些步骤能为企业的关键ERP应用来设计和实施有效的功能测试程序。

     

    步骤1:初始规划和收集需求

    在任何一个环境中,功能测试的最重要阶段之一就是规划。对于ERP应用来说,这个步骤就更为重要了,因为其中涉及环境的复杂性以及推动这些应用实施的错综复杂的业务需求。不完善的规划可能导致失望的结果和不完整的测试覆盖面。经过深思熟虑的规划使您能避免一种“垃圾进,垃圾出(garbage in, garbage out)”的局面,使企业能衡量和最大化他们的测试工作,获取更多的投资回报(ROI)。

     

    许多公司购买预先打包的ERP解决方案,希望能实现业务管理各个领域的快速整合。然而,这种被称之为“vanilla”的ERP打包方案必须经过客户定制,才能部署到它所要支持的业务中去。从逻辑上来说,收集需求是规划阶段的起点,因为开发人员通常根据需求来定制ERP应用;测试人员使用它来测试系统和客户定制项目;而最终用户使用它进行用户接受测试和终结测试。通过提前仔细地定义需求,测试人员可以规划和管理那些更加注重业务需要的测试。接着,需求可以同测试和实际测试结果(被识别的缺陷)相结合,以全面覆盖所有的功能测试。

     

    步骤2:定义测试目的和选择合适的测试

    测试人员通过创建主要的测试目的,将决定所需的特定测试类型。 测试目的、项目计划和团队结构也将从这些测试目标中形成。当功能测试一个ERP实施时,有多种不同的验证测试需要执行:

     

    l          数据映射:由于许多ERP实施和后端大机系统紧密地集成在一起,因此测试ERP应用所显示的数据和在大机系统中被发现的数据之间的数据映射是十分关键的。很可能在大机系统中隐藏着一些陈旧的或无效的数据,这些数据会引起应用当中的问题。

    l          业务流程测试:应该使用测试来验证各种业务流程是否正确运作。由于工作流对强化业务规则来说是非常重要的,因此测试应该覆盖整个整合系统中的所有导航项目和直接功能。应用的业务规则和启动项必须通过全面地测试,确保所有规则能被正确地执行。

    l          权限控制系统ERP权限控制系统决定了用户可以使用哪些信息,用户在这些信息中可以看到哪些数据。当涉及到供应链和合作伙伴入口时,将会增加安全方面的考虑。从用户界面的角度出发测试安全性可以确保严格执行验证规则。数据驱动的测试使IT人员能使用具有不同登录凭证的相同脚本去验证安全规则。

    l          回归测试:每次部署一个“Code Drop”时,对位于这些程序的每个对象的功能进行回归测试是非常重要的。这其中包括测试它的存在、功能、值等等。“code drop”指的是任何一次新的ERP应用、补丁程序和/hot fix的发布。

     

    步骤3:定义目标,以满足测试目的

    当完成所有的目的定义,选择好测试类型,接下去就要创建一系列的阶段目标来实现所定义的目的。一套最普通的初始阶段目标包括:

    l          分析应用功能,并识别关键业务流程。在一个ERP应用中的关键业务流程实例就是“服务请求”的创建。

    l          建立“冒烟测试”,在开发周期中快速执行该类测试。冒烟测试不应深入被测试应用的功能,而是应该测试关键的业务功能。例如,用户是否能够创建可以和“Trouble Ticket”相应的活动。

    l          在每次正式发布形成后运行冒烟测试。

    l          着手创建自动化测试来降低手动运行冒烟测试的成本。

     

    实现了这些初始阶段目标之后,应该建立一套后续阶段目标。

    l          分析应用,展开功能识别,这将扩大测试范围,涵盖超过75%的总的应用功能数量。(取得100%的脚本自动化测试是非常困难的,因为自动化测试工具无法进行如可用性测试这样的事宜。)

    l          建立可持续运作的自动化测试,从而降低测试的工作量。

     

    步骤4:区分功能测试案例

    在区分测试案例时,关键要记住,重要的业务功能必须在应用中才能发挥作用。由于每个企业具有独特的业务需求,大多数企业即使完成了基本的或标准的实施,也无法上线。因为那些客户定制的区域必须经过彻底地测试才能保证上线时功能的稳定。ERP应用的主要优势之一就是能和现有的大机系统集成,来满足必要的业务需求。再者,因为这些集成不是标准(非客户定制)实施,它们必须经过严格地测试。

     

    最初,要避免用各种不同的方法去测试相同的功能。开发团队经常会强调一个应用应具有完美架构,可以灵活地让用户通过不同的方式来完成他们的日常任务。关键在于要经常部署测试案例,确保需求驱动、user-path的覆盖面。初期测试应该具有一些共有的特性:

     

    l          它们应该测试关键的业务功能。

    l          它们应该测试应用的关键业务流程。

    l          它们应该识别出经客户定制过的ERP应用的测试区域。

    l          应用功能应该稳定,不在主要开发范围之内。

    l          初期测试应该是冒烟测试的候选方式。

     

    一旦初期自动化测试创建完成,并成功地运行后,测试目标通常会改变,测试包会扩张。这种扩张通常表现为在功能成熟之后,增加更多的测试到测试包中。还可以在应用问题区域,如和大机系统的界面中增加测试,从而对该区域展开持续地检查。

     

    步骤5:文档记录关键的业务流程

    当记录那些将要成为测试脚本的业务流程时,收集所有和测试案例相关的信息是非常重要的。每个测试案例需要具备一份和被测业务区域相关的目的说明。测试案例的目的应该是和满足一个需求或一系列需求有关。关键之处还在于,要文档记录下逻辑步骤,在整个系统中执行这些步骤可以实现测试的需求。由于使用测试案例可以衡量业务流程的成功与否,因此,文档中应该指出,需要验证哪些内容才能保证测试的成功。

     

    除了为测试案例而展开的执行和验证操作外,还需要在测试案例中成功地执行适用的数据值。这种数据可以是来自数据库的主数据(master data)、或是能够凭空增加的用户创建输入数据、或者在脚本创建之前被置入数据库的准备数据。

     

    步骤6:开发模块化的测试组件

    创建模块化测试脚本是非常重要的。测试的模块化能够使开发人员创建单元测试unit test),在整个系统完成之前,测试ERP应用模块和模块的定制项目。接着,被用于单元测试的模块测试会移交给QA测试人员,他们会将模块测试和测试包结合在一起,来满足特定的测试目标。美科利提供一款最新的功能测试解决方案(即“业务流程测试”),它能帮助企业管理与业务组件和端到端流程验证有关的所有测试案例。

     

    步骤7:建立测试实验室

    建议建立一个QA测试实验室,作为ERP应用的测试和调优整体战略的一个组成部分。在一个独立的测试实验室中运行测试的主要优势在于,机器配置可以达到一种理想的状态,因而减少了由于机器配置不完善而引起的各类问题。此外,当模块定制完成之后,开发人员和测试人员可以在新代码发布之前,使用该实验室来运行单元测试。

     

    步骤8:掌握和利用“冒烟测试”

    在大多数ERP应用中,不完善的发布浪费了大量的测试工作。通常,当开发团队完成一个发布版本后将移交给测试团队,接着展开为期数天的测试过程。而测试结果往往是软件的发布版本存在重大的和根本的问题,不值得再进行深入地测试。不幸地是,当开发人员着手为该发布版本增加新的功能时,测试团队已经浪费了几天的时间去发现其薄弱之处。

     

    改变这种情况的捷径就是建立一种“冒烟测试”,它可以覆盖关键的业务功能。冒烟测试结合了手动测试和自动化测试,可以在短时间内被创建和运行(通常在1个小时之内)。运行冒烟测试可以为开发团队提供发布版本质量方面的快速信息反馈,帮助他们集中力量解决严重阻滞的问题,而不是一些新的特性。冒烟测试所利用的脚本可以从开发人员已经创建的单元测试中获取。

     

    步骤9:执行回归测试

    回归测试包应该覆盖关键的业务流程,应该在每个新的ERP应用版本发布时运行。回归测试不同于冒烟测试注重测试核心的业务功能,它能更加深入地测试应用的功能。正如前文所提到的,由供应商和任何定制所带来的应用更新都可能对应用功能和性能产生负面影响,必须在每次发布版本之后进行测试。

     

    步骤10:分析缺陷和创建测试报告

    ERP应用准备就绪的重要指标之一就是被识别的系统缺陷数量。在执行测试时,测试中产生的失误必须被跟踪和分析。一种稳固的功能测试解决方案应该能跟踪和汇报所有存在于业务流程中的缺陷。测试团队可以利用这类信息来衡量和管理缺陷是如何被优先级划分、修复、重复测试和关闭的。

     

    用全面的报告来完整记录所有的测试流程和结果,这也是非常重要的一项工作,可以使测试团队能正确分析测试结果,同时在未来测试中重复使用测试案例和脚本。

     

    美科利QuickTest Professional

    Mercury QuickTest Professional™提供功能和回归测试自动化方面的业界最佳解决方案――可覆盖每个主要的软件应用和环境,包括来自OraclePeopleSoftSAPSiebleERP应用。这种新款的自动化测试解决方案采用一种关键词驱动测试的理念,能够完全简化测试的创建和维护。有了美科利QuickTest Professional的关键词驱动方式,测试自动化专家就能通过一种和关键词视图(Keyword View)相互同步的、集成的脚本和纠错环境,进入到基层测试和目标领域中去。

     

    美科利QuickTest Professional同时满足了技术和非技术用户的需要。它使高质量应用部署的过程变得更为快捷和经济,同时风险也更小。它和Mercury Business Process Testing™(美科利业务流程测试)协同工作,使非技术型的对象专家(subject matter expert)也能参与到质量流程中。

     

    美科利业务流程测试使对象专家无需任何编程知识,就能创建、数据驱动和执行测试自动化。它降低了自动化测试维护的经常性费用,将测试自动化和文档记录两个流程合并为一。它使对象专家和业务分析人员可以根据业务流程测试框架中所定义的业务概念来衡量应用实施的质量。

     

    ERP应用的功能测试

    通过使用美科利QuickTest Professional和美科利业务流程测试,QA团队可以开发和利用统一的、可重复的测试流程,更快、更经济和更便捷地对ERP应用就绪情况提前作出决策。当初期功能测试计划完成之后,测试团队可以使用美科利解决方案来自动验证ERP应用中所有业务交易的完整性。美科利解决方案从业务流程的角度出发,展开ERP应用测试。这些解决方案通过执行分步操作――如更新库存信息,或从供应商处定购某部分商品,就像在实际生产操作中一样来测试ERP应用。

     

    当在测试创建阶段捕获了业务流程后,美科利QuickTest Professional和美科利业务流程测试将ERP业务相关信息与输入数据相互分离。测试人员可以根据选择列表,改变选择项和数据条目。使用同一数据对应用展开反复测试通常不会取得实际结果。要真实地验证应用的功能,测试人员需要不同的数据包来模拟多个用户的实际操作行为。美科利产品允许用户直接输入测试数据,或从一个数据库中导入数据,从而创建一个实际的、数据驱动的测试方案。通过这种方式,测试人员就能使用可变的输入数据,分析实际的ERP业务流程。

     

    打包的ERP应用通常具有很高的复杂性。创建一个简单的记录定制可能会对其它记录或整体性能产生无法预料的影响。当更新发布(甚至是简单的定制更新),都需要对所有业务流程展开全面彻底地测试,而不仅仅是测试变更所发生的区域。这样,测试人员就能衡量更新会对应用产生的影响,确保不会引起缺陷的产生。

     

    更多信息

    美科利解决方案使机构能采用稳固的功能测试程序来展开他们所有的ERP解决方案。解决方案让整个测试团队能够以最少的培训,创建成熟的测试系列;确保在整个环境、数据包和业务流程中应用功能的正确运作;并为开发人员提供全面记录和复制缺陷的能力――帮助团队尽快修复缺陷,跟上苛刻的生产进度。

     

    想获取更多有关美科利QuickTest Professional、美科利业务流程测试,或其它美科利服务和解决方案的信息,请联系当地的美科利销售代表或访问www.mercury.com

     


  • 软件界面的美观性及软件的易用性方面

    2007-05-26 11:33:52

     易用性 
      考察评定软件的易学易用性,各个功能是否易于完成,软件界面是否友好等方面进行测试,这点在很多类型的管理类软件中是非常重要的。 

    通常对易用性有如下定义: 
      易见Easy to discover:单单凭观察,用户就应知道设备的状态,该设备供选择可以采取的行动。 
      易学Easy to learn:不通过帮助文件或通过简单的帮助文件,用户就能对一个陌生的产品有清晰的认识。 
      易用Easy to use:用户不翻阅手册就能使用软件。 

    对于易用性测试可遵循以下原则:

    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、专业性强的软件要使用相关的专业术语,通用性界面则提倡使用通用性词眼。

    17、对于界面输入重复性高的情况,该界面应全面支持键盘操作,即在不使用鼠标的情况下采用键盘进行操作。

    对于易用性测试还可从以下几个方面入手:

    1、导航测试
     

       导航描述了用户在一个页面内操作的方式,在不同的用户接口控制之间,例如按钮、对话框、列表和窗口等;或在不同的连接页面之间。通过考虑下列问题,可以决定一个应用系统是否易于导航:导航是否直观?系统的主要部分是否可通过主页存取?系统是否需要站点地图、搜索引擎或其他的导航帮助? 
       在一个页面上放太多的信息往往起到与预期相反的效果。应用系统的用户趋向于目的驱动,很快地扫描一个应用系统,看是否有满足自己需要的信息,如果没有,就会很快地离开。很少有用户愿意花时间去熟悉应用系统的结构,因此,应用系统导航帮助要尽可能地准确。导航的另一个重要方面是应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道应用系统里面是否还有内容,内容在什么地方。
    应用系统的层次一旦决定,就要着手测试用户导航功能,让最终用户参与这种测试,效果将更加明显。

    2、图形测试 

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

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

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

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

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

    3、内容测试

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

    4、整体界面测试

       整体界面是指整个应用系统的页面结构设计,是给用户的一个整体感。例如:当用户浏览应用系统时是否感到舒适,是否凭直觉就知道要找的信息在什么地方?整个应用系统的设计风格是否一致?
       对整体界面的测试过程,其实是一个对最终用户进行调查的过程。一般应用系统采取在主页上做一个调查问卷的形式,来得到最终用户的反馈信息。对所有的可用性测试来说,都需要有外部人员(与应用系统开发没有联系或联系很少的人员)的参与,最好是最终用户的参与。  


    界面

       界面是软件与用户交互的最直接的层面,界面的好坏决定用户对软件的第一印象。而设计优良的界面能够引导用户自己完成相应的操作,起到向导的作用。同时界面如同人的面孔,具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉,相反由于界面设计的失败,让用户有挫败感,再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。
       目前流行的界面风格有三种方式:多窗体、单窗体以及资源管理器风格,无论那种风格,以下原则应该得到重视或参考。在测试人员进行测试过程中,也可参考以下原则对产品进行评价。

    1、规范性原则

       通常界面设计都按Windows 界面的规范来设计,即包含“菜单条、工具栏、工具厢、状态栏、滚动条、右键快捷菜单”的标准格式,可以说:界面遵循规范化的程度越高,则易用性相应的就越好。小型软件一般不提供工
    具厢。
    规范性细则:

    (1)常用菜单要有命令快捷方式。

    (2)完成相同或相近功能的菜单用横线隔开放在同一位置。

    (3)菜单前的图标能直观的代表要完成的操作。

    (4)菜单深度一般要求最多控制在三层以内。

    (5)工具栏要求可以根据用户的要求自己选择定制。

    (6)相同或相近功能的工具栏放在一起。

    (7)工具栏中的每一个按钮要有及时提示信息。

    (8)一条工具栏的长度最长不能超出屏幕宽度。

    (9)工具栏的图标能直观的代表要完成的操作。

    (10)系统常用的工具栏设置默认放置位置。

    (11)工具栏太多时可以考虑使用工具厢。

    (12)工具厢要具有可增减性,由用户自己根据需求定制。

    (13)工具厢的默认总宽度不要超过屏幕宽度的1/5。

    (14)状态条要能显示用户切实需要的信息,常用的有:目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息、使用单位信息及软件开发商信息等,如果某一操作需要的时间较长,还应该显示进度条和进程提示


    (15)滚动条的长度要根据显示信息的长度或宽度能及时变换,以利于用户了解显示信息的位置和百分比。

    (16)状态条的高度以放置五好字为宜,滚动条的宽度比状态条的略窄。

    (17)菜单和工具条要有清楚的界限;菜单要求凸出显示,这样在移走工具条时仍有立体感。

    (18)菜单和状态条中通常使用5 号字体。工具条一般比菜单要宽,但不要宽的太多,否则看起来很不协调。

    (19)右键快捷菜单采用与菜单相同的准则。

    2、帮助设施原则

       系统应该提供详尽而可靠的帮助文档,在用户使用产生迷惑时可以自己寻求解决方法。
    帮助设施细则:

    (1)帮助文档中的性能介绍与说明要与系统性能配套一致。

    (2)打包新系统时,对作了修改的地方在帮助文档中要做相应的修改,做到版本统一。

    (3)操作时要提供及时调用系统帮助的功能。常用F1。

    (4)在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。也就是说帮助要有即时针对性。

    (5)最好提供目前流行的联机帮助格式或HTML 帮助格式。

    (6)用户可以用关键词在帮助索引中搜索所要的帮助,当然也应该提供帮助主题词。

    (7)如果没有提供书面的帮助文档的话,最好有打印帮助的功能。

    (8)在帮助中应该提供我们的技术支持方式,一旦用户难以自己解决可以方便的寻求新的帮助方式。


    3、合理性原则

       屏幕对角线相交的位置是用户直视的地方,正上方四分之一处为易吸引用户注意力的位置,在放置窗体时要注意利用这两个位置。
    合理性细则:

    (1) 父窗体或主窗体的中心位置应该在对角线焦点附近。

    (2) 子窗体位置应该在主窗体的左上角或正中。

    (3) 多个子窗体弹出时应该依次向右下方偏移,以显示窗体出标题为宜。

    (4) 重要的命令按钮与使用较频繁的按钮要放在界面上注目的位置。

    (5)错误使用容易引起界面退出或关闭的按钮不应该放在易点位置。横排开头或最后与竖排最后为易点位置。

    (6) 与正在进行的操作无关的按钮应该加以屏蔽。

    (7) 对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会。

    (8) 非法的输入或操作应有足够的提示说明。

    (9)对运行过程中出现问题而引起错误的地方要有提示,让用户明白错误出处,避免形成无限期的等待。

    (10)提示、警告、或错误说明应该清楚、明了、恰当并且应避免英文提示的出现。

    4、美观与协调性原则

       界面应该大小适合美学观点,感觉协调舒适,能在有效的范围内吸引用户的注意力。
    美观与协调性细则:

    (1)长宽接近黄金点比例,切忌长宽比例失调、或宽度超过长度。

    (2)布局要合理,不宜过于密集,也不能过于空旷,合理的利用空间。

    (3)按钮大小基本相近,忌用太长的名称,免得占用过多的界面位置。

    (4)按钮的大小要与界面的大小和空间要协调。

    (5)避免空旷的界面上放置很大的按钮。

    (6)放置完控件后界面不应有很大的空缺位置。

    (7)字体的大小要与界面的大小比例协调,通常使用的字体中宋体9-12 较为美观,很少使用超过12号的字体。

    (8)前景与背景色搭配合理协调,反差不宜太大,最好少用深色,如大红、大绿等。常用色考虑使用Windows 界面色调。

    (9)如果使用其他颜色,主色要柔和,具有亲和力与磁力,坚决杜绝刺目的颜色。

    (10)大型系统常用的主色有"#E1E1E1"、"#EFEFEF"、"#C0C0C0"等。

    (11)界面风格要保持一致,字的大小、颜色、字体要相同,除非是需要艺术处理或有特殊要求的地方。

    (12)如果窗体支持最小化和最大化或放大时,窗体上的控件也要随着窗体而缩放;切忌只放大窗体而忽略控件的缩放。

    (13)对于含有按钮的界面一般不应该支持缩放,即右上角只有关闭功能。

    (14)通常父窗体支持缩放时,子窗体没有必要缩放。

    (15)如果能给用户提供自定义界面风格则更好,由用户自己选择颜色、字体等。

    5、菜单位置原则

       菜单是界面上最重要的元素,菜单位置按照按功能来组织。
    菜单设置细则:

    (1)菜单通常采用“常用--主要--次要--工具--帮助”的位置排列,符合流行的Windows 风格。

    (2)常用的有“文件”、“编辑”,“查看”等,几乎每个系统都有这些选项,当然要根据不同的系统有所取舍。

    (3)下拉菜单要根据菜单选项的含义进行分组,并切按照一定的规则进行排列,用横线隔开。

    (4)一组菜单的使用有先后要求或有向导作用时,应该按先后次序排列。

    (5)没有顺序要求的菜单项按使用频率和重要性排列,常用的放在开头,不常用的靠后放置;重要的放在开头,次要的放在后边。

    (6)如果菜单选项较多,应该采用加长菜单的长度而减少深度的原则排列。

    (7)菜单深度一般要求最多控制在三层以内。

    (8)对常用的菜单要有快捷命令方式,组合原则见7。

    (9)对与进行的操作无关的菜单要用屏蔽的方式加以处理,如果采用动态加载方式—即只有需要的菜单才显示—最好。

    (10)菜单前的图标不宜太大,与字高保持一直最好。

    (11)主菜单的宽度要接近,字数不应多于四个,每个菜单的字数能相同最好。

    (12)主菜单数目不应太多,最好为单排布置。

    6、独特性原则

       如果一味的遵循业界的界面标准,则会丧失自己的个性。在框架符合以上规范的情况下,设计具有自己独特风格的界面尤为重要。尤其在商业软件流通中有着很好的迁移默化的广告效用。
    独特性细则:

    (1)安装界面上应有单位介绍或产品介绍,并有自己的图标或徽标。

    (2)主界面,最好是大多数界面上要有公司图标或徽标。

    (3)登录界面上要有本产品的标志,同时包含公司图标或徽标。

    (4)帮助菜单的“关于”中应有版权和产品信息。

    (5)公司的系列产品要保持一直的界面风格,如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致。

    (6)应为产品制作特有的图标并区别于公司图标或徽标

    7、快捷方式的组合原则

       在菜单及按钮中使用快捷键可以让喜欢使用键盘的用户操作得更快一些,在西文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 写。
    这些快捷键也可以作为开发中文应用软件的标准,但亦可使用汉语拼音的开头字母。

    8、排错性考虑原则

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

    (1)最重要的是排除可能会使应用非正常中止的错误。

    (2)应当注意尽可能避免用户无意录入无效的数据。

    (3)采用相关控件限制用户输入值的种类。

    (4)当用户作出选择的可能性只有两个时,可以采用单选框。

    (5)当选择的可能再多一些时,可以采用复选框,每一种选择都是有效的,用户不可能输入任何一种无效的选择。

    (6)当选项特别多时,可以采用列表框,下拉式列表框。

    (7)在一个应用系统中,开发者应当避免用户作出未经授权或没有意义的操作。

    (8)对可能引起致命错误或系统出错的输入字符或动作要加限制或屏蔽。

    (9)对可能发生严重后果的操作要有补救措施。通过补救措施用户可以回到原来的正确状态。

    (10)对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符。

    (11)对错误操作最好支持可逆性处理,如取消系列操作。

    (12)在输入有效性字符之前应该阻止用户进行只有输入之后才可进行的操作。

    (13)对可能造成等待时间较长的操作应该提供取消功能。

    (14)特殊字符常有;;’”><,`‘:“[”{、\|}]+=")-(_*&&^%$#@!
    ,。?/还有空格。

    (15)与系统采用的保留字符冲突的要加以限制。

    (16)在读入用户所输入的信息时,根据需要选择是否去掉前后空格。

    (17)有些读入数据库的字段不支持中间有空格,但用户切实需要输入中间空格,这时要在程序中加以处理。

    9、多窗口的应用与系统资源原则

       设计良好的软件不仅要有完备的功能,而且要尽可能的占用最底限度的资源。

    (1)在多窗口系统中,有些界面要求必须保持在最顶层,避免用户在打开多个窗口时,不停的切换甚至最小化其他窗口来显示该窗口。

    (2)在主界面载入完毕后自动卸出内存,让出所占用的WINDOWS 系统资源。

    (3)关闭所有窗体,系统退出后要释放所占的所有系统资源,除非是需要后台运行的系统。

    (4)尽量防止对系统的独占使用。

      以上文章转自一只猪的小小城堡,作者 purpledd,做个人学习之用。

Open Toolbar