Reporter.ReportEvent使用

Reporter.ReportEvent  有四个参数
第一个参数是状态,状态有四种 micPass 通过
                            micFail  失败
                            micDone 完成
                            micWarning 警告
第二个参数是步骤名称

第三个参数是内容描述

第四个参数可有可无 我也没有用过第四个参数呵呵

 

Msgbox "XXXXXXX"

print "XXXXXXX"

分页功能的测试：

With Browser("Browser").Page("Building List")
 If .Link("class:=nextpage").Exist(2) Then
  print "next page exists!"
    ' Reporter.ReportEvent micpass, "next page exists!","Next"
 'else
  
 End If
    .Link("class:=nextpage").Click
 .Sync
 wait 2
    If .Link("class:=prepage").Exist(2) Then
   'Reporter.ReportEvent micpass , "pre page exists!","Pre"
     print "next page exists!"
 'Else
 
 End If
End With

 

分页功能测试2

 

Public Sub Pagination ()
    Reporter.ReportEvent micDone ,"调用 Pagination ()","Start"
 
 intTotal_Page=Browser("name:="&strBrowserName).Page("title:="&strPageName).Frame("title:="&strFrameName).WebElement("html id:=total_page").GetROProperty("innertext")
    msgbox  intTotal_Page
 intCur_Page=Browser("name:="&strBrowserName).Page("title:="&strPageName).Frame("title:="&strFrameName).WebElement("html id:=cur_page").GetROProperty("innertext")
 msgbox  intCur_Page
    If (intTotal_Page=0and intCur_Page=0)or (intTotal_Page=1and intCur_Page=1) Then
   Reporter.ReportEvent micpass ,"分页","没有分页"
  End If
  if  (intCur_Page<intTotal_Page)  then
   Browser("name:="&strBrowserName).Page("title:="&strPageName).Frame("title:="&strFrameName).Image("file name:=pages_go.gif").Click
   end if
  If  (intTotal_Page= intCur_Page) then
   Browser("name:="&strBrowserName).Page("title:="&strPageName).Frame("title:="&strFrameName).Image("file name:=pages_back.gif").Click
   end if
    Reporter.ReportEvent micDone ,"调用 Pagination ()","End"
End Sub

 

 

 

 

 

 

2. Description 的使用

 

Set nline = Description.Create()
online("src").Value = "http://www.51testing.com/images/new/logo.gif"

 

Set nlineCo = Browser("51Testing软件测试网-中国软件测试人的精神家园").Page("51Testing软件测试网-中国软件测试人的精神家园").ChildObjects(online)

onlineCoCount = onlineCo.Count

If nlineCoCount = 0 Then

 MsgBox "这个页面没有打开"

 wait 2

 else

 Msgbox  "这个页面正常的打开了"
   ' Desktop.CaptureBitmap "d:\test.png",true
    'SendMail "XXXXX@QQ.com","XXXXX","XXXXX","XXXXX","XXXXX","XXXXX@163.com"

 

你可以使用Description对象，来返回一个Properties collection对象，该集合对象包括一系列Property对象。每个Property对象由Property name及value组成。

然后在语句中用Properties collection对象替代被测对象的名称。

注意：默认情况下，所有被添加到Properties collection中的Property对象的值被当成正则表达式对待。因此，当Property Value中包含正则表达式的特殊字符（如*，?，+）时，要在特殊字符前使用“\”符号。

你也可以在Properties Collection中，将RegularExpression属性值设置为False，这样即使在Property Value中用到了正则表达式的特殊字符，也会被视为普通字符。更多信息参考QuickTest Professional Object Model Reference的Utility部分。

要创建Properties collection，使用Dexcription Create语句，语法如下：

Set MyDescription = Description.Create()

一旦创建了Properties 对象（例如上例中的Mydescription）,在运行过程中，你就可以使用语句向Properties对象添加、编辑、移除或获取属性及属性值。这使你在运行过程中可以动态的决定：在对象描述中使用哪些属性、使用多少属性。

当你将一系列的属性及属性值加入到Properties collection中以后，你就可以在脚本语句中用Properties对象替代被测对象的名称。

例如，有如下语句：

Window("Error").WinButton("text:=OK", "width:=50").Click

通过改造，成为：

Set MyDescription = Description.Create()

MyDescription("text").Value = "OK"

MyDescription("width").Value = 50

Window("Error").WinButton(MyDescription).Click

注：当为一个ActiveX对象创建编程性描述时，如果该对象的run-time对象是windowless的（即没有相应的window handel），就必须在属性描述中将它的windowless property设置为Ture。

例如：

Set ButDesc = Description.Create

ButDesc("ProgId").Value = "Forms.CommandButton.1"

ButDesc("Caption").Value = "OK"

ButDesc("Windowless").Value = True

Window("Form1").AcxButton(ButDesc).Click

获取Child Objects（Retrieving Child Objects）

通过ChildObjects方法，可以获取指定对象下的所有子对象，或只获取那些符合编程性描述的子对象。为了获取某对象的子对象的子集，首先需创建一个description对象，然后在该对象的descriptions collection中添加一系列的属性及属性值，这些属性及属性值必须符合子集的要求。

注意：你必须使用Description对象来为ChildObjects描述参数 创建编程性描述，不能使用property:=value语法直接将编程性描述添加到参数中。

一旦你已经在description对象中“built”了描述，就可以使用下面的语法来获取与描述匹配的子对象：

Set MySubSet=TestObject.ChildObjects(MyDescription)

例如：下面的语句使QTP选中网页中的所有选择框：

Set MyDescription = Description.Create()

MyDescription("html tag").Value = "INPUT"

MyDescription("type").Value = "checkbox"

Set Checkboxes = Browser("Itinerary").Page("Itinerary").ChildObjects(MyDescription)

NoOfChildObjs = Checkboxes.Count

For Counter=0 to NoOfChildObjs-1

Checkboxes(Counter).Set "ON"

Next

For more information about the ChildObjects method, refer to the QuickTest Professional Object Model Reference

 

3.

 

新产品或工程管理流程
1.1、需求调研
在软件需求分析阶段，测试人员从软件生命周期的需求阶段就开始介入在需求阶段的测试人员参与软件需求调研，以测试角度分析需求的可测性，可构思将来对其测试的方法、原则等；同时全面了解系统需求，从客户角度考虑软件测试需要达到的验证状态，即哪些功能点需重点测试、哪些无需，以便将来制定测试计划。
1.2、制定测试计划
进行每一种测试之前，测试负责人要根据“产品定义书”及“总体设计说明”和“详细设计文档”制定“测试计划”，制定总体的测试计划，详细阐明本次测试目的、对象、方法、范围、过程、环境要求、接受标准以及测试人员和测试时间等内容，“测试计划”经过审查通过，才能实施。
1.3、需求Review
开发在完成软件需求分析之后，会提交需求分析文档，测试人员根据需求调研所了解的需求以及产品需求说明文档等资料，对需求分析文档进行Review，检查文档是否满足了需求，是否与需求一致等等。
1.4、设计Review
在软件分析设计阶段，测试人员参与设计讨论，了解系统的实现方式和原理，并对概要设计和详细设计提出自己的见解。设计结束之后，开发提交概要设计文档和详细设计文档，测试人员对设计进行Review，检查设计规划和实现方案是否合理，如果不合理，存在的问题是什么、如何改进等等。
1.5、测试设计
在设计测试方案时，首先分解测试内容，对于一个复杂系统，通常可以分解成几个互相独立的子系统，正确地划分这些子系统及其逻辑组成部分和相互间的关系，可以降低测试的复杂性，减少重复和遗漏，也便于设计和开发测试用例，有效的组织测试，将系统分析人员的开发分析文档加工成以测试为角度的功能点分析文档，重要的是描述对系统分解后每个功能点逐一的校验描述，包括何种方法测试、何种数据测试、期望测试结果等。然后以功能点分析文档作为依据进行测试用例的设计，设计测试用例是关系到测试效果以至软件质量的关键性一步，也是一项非常细致的工作，根据对具体的北侧系统的分析和测试要求，逐步细化测试的范围和内容，设计具体的测试过程和数据，同时将结果写成可以按步执行的测试文档。
每个测试用例必须包括以下几个部分：
（1） 标题和编号；
（2） 测试的目标和目的；
（3） 输入和使用的数据和操作过程；
（4） 期望的输出结果；
（5） 其他特殊的环境要求、次序要求、时间要求等。
1.6、开发测试工具和准备测试数据
在软件测试中，为了提高测试工作的效益和质量，只要条件许可，应尽可能采用计算机自动或半自动测试的方法，利用软件工具本身的优势来提高工作效率。
1.7、测试执行
当所有必需的测试准备工作都已完成，并且产品已经开发完毕并提交测试，则可以按照预定的测试计划和测试方案逐项进行测试。在测试过程中发现的任何与预期目标不符的现象和问题都必须详细记录下来，填写测试记录。为了能准确的找出问题产生的原因，及时的解决问题，保证测试工作的顺利进行，一般来说所发现的问题必须是能够重视的。
1.8、回归测试
在测试中发现的任何问题和错误都必须有一个明确的解决方法。一般来说，经过修改的软件可能仍然包含着错误，甚至引入了新的错误，因此，对于修改以后的程序和文档，按照修改的方法和影响的范围，必须重新进行有关的测试。另一方面，对于版本更新后的软件也必须进行同样的测试过程。
1.9、测试分析报告
?测试结束后要及时地进行总结，对测试结果进行分析，由测试负责人提交“测试分析报告”。
1.10、产品发布?
测试完毕，整理产品发布包和相关文档并发布。对于新产品来说，必要的文档必须包括：
（1） 安装操作手册
（2） 产品白皮书
（3） 管理维护手册
（4） 用户操作手册
（5） 测试报告
1.11、版本控制
新版本软件发布之后，马上对代码进行质量控制。
（1） Build Master给新版本的源代码打一个cvs tag，方便代码回滚check out。比如，发布版本为p2p3.3.2，则给该软件源代码也打一个与发布版本相同名字的tag p2p3.3.2。这样做的一个好处是，在目前的软件的基础上做了修改并发布新的版本后，如果需要check out某个版本的源代码，则可以通过这个版本的tag来check out，代码的修改可以在该版本上进行。
（2） Build Master对新发布的软件源代码进行cvs lock，不允许开发人员在软件发布之后commit源代码，直到有新版本需求修改再给开发人员开放commit权限。这样做的好处是避免开发人员随意修改和commit源代码，确保源代码服务器上的源版本版本与当前最新的发布版本一致。

二、 工程维护管理流程
2.1、收集新需求
新功能和不紧急的故障，其代码的修改操作不必马上进行，取而代之的是做好新需求与故障统计；对已经确认的故障也可以先在bug管理系统报bug，但只是记录，不需要马上修改。当然了，对于紧急的工程故障，需要马上修改和测试。
2.2、确认新需求
与工程人员或客户或产品经理确认新需求，确保需求被理解正确。
2.3、需求讨论
当需求与故障积累到一定数量或者工程有新版本需求，进行一次发布测试，在新版本开始修改之前把近期积累的需求与故障整理，与相关开发人员、测试人员、项目经理和测试经理讨论，确认哪些新功能可以实现、新功能的实现方法与业务流程、新功能开发修改时间、测试版本、测试时间与发布时间。
2.4、在bug跟踪管理系统报bug
确认所有需要修改的新功能和需求录入bug跟踪管理系统，并在bug跟踪管理系统中详细描述新功能需求和解决方法，同时整理相关bug列表，交付开发修改。
2.5、制定测试计划
A、 根据用户需求，定义并完善测试需求，作为测试的标准；
B、 确定重点测试事项，哪些功能需要重点测试；
C、 测试时间计划，并详细计划具体测试任务与时间；
D、 风险说明；
E、 测试准备，提前对测试环境和测试资源进行准备；
F、 发布具体时间；
G、 资源需求：包括测试人员、硬件需求、软件需求和培训计划；
2.6、编写测试案例
根据功能需求编写测试案例；
2.7、测试开发
开发自动测试脚本，补充自动测试案例；
2.8、测试实施
按照测试计划进行测试，发现并申报bug；
2.9、测试评估
A、 哪些需求通过了测试；
B、 有哪些遗留问题；
C、 测试效率评估；
D、 开发质量度量和评估；
E、 并根据评估编写测试报告；
2.10、发布新版本
A、 编写新功能文档，给工程提供新功能说明；
B、 编写升级文档，给工程提供升级参考方案；
C、 软件发布，包括新版本软件、新功能文档、升级文档和测试报告；
2.11、代码版本控制
新版本软件发布之后，马上对代码进行质量控制。
A、 Build Master给新版本的源代码打一个cvs tag，方便代码回滚check out。比如，发布版本为p2p3.3.2，则给该软件源代码也打一个与发布版本相同名字的tag p2p3.3.2。这样做的一个好处是，在目前的软件的基础上做了修改并发布新的版本后，如果需要check out某个版本的源代码，则可以通过这个版本的tag来check out，代码的修改可以在该版本上进行。
B、 Build Master对新发布的软件源代码进行cvs lock，不允许开发人员在软件发布之后commit源代码，直到有新版本需求修改再给开发人员开放commit权限。这样做的好处是避免开发人员随意修改和commit源代码，确保源代码服务器上的源版本版本与当前最新的发布版本一致。

本人是05年应届本科毕业生,目前在上海从事测试工作,对测试工作有强烈的兴趣，希望能进入北京的重视测试工作的公司.
熟悉软件开发过程，测试步骤及报告编写，理解测试流程、测试统计及测试软件的开发
熟悉测试理论及方法，熟悉CMMI模型
可以根据功能说明书和测试说明书，创建测试案例
具有设计编写、执行和评估测试用例的能力，具有对测试结果进行分析、总结的能力
具备管理测试小组的能力、沟通能力和文字表达能力，有很强沟通能力和团队合作精神
具有java程序开发经验，熟悉Linux、UNIX等操作系统，Tomcat等应用服务器.
能熟练的使用英文编写文档

 

考官从办公室（面试现场）随意选取一个简单物品，假定是一个喝水的带广告图案的花纸杯，让应聘人对它设计出尽可能多的测试用例。

测试项目：杯子

需求测试:查看杯子使用说明书

界面测试:查看杯子外观

功能度：用水杯装水看漏不漏；水能不能被喝到

安全性：杯子有没有毒或细菌

可靠性：杯子从不同高度落下的损坏程度

可移植性：杯子再不同的地方、温度等环境下是否都可以正常使用

兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等

易用性：杯子是否烫手、是否有防滑措施、是否方便饮用

用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述

疲劳测试：将杯子盛上水（案例一）放24小时检查泄漏时间和情况；盛上汽油（案例二）放24小时检查泄漏时间和情况等

压力测试：用根针并在针上面不断加重量，看压强多大时会穿透

跌落测试:   杯子加包装(有填充物),在多高的情况摔下不破损

震动测试: 杯子加包装(有填充物),六面震动,检查产品是否能应对恶劣的铁路\公路\航空运输

测试数据：

测试数据具体编写此处略（最讨厌写测试数据了）。其中应用到：场景法、等价类划分法、因果图法、错误推测法、边界值法等方法

期望输出：

该期望输出需查阅国标、行标以及使用用户的需求

说明书测试: 检查说明书书写准确性

给大家提三个产品:1.手机 2.电饭锅 3.电梯

 

网上解答之一：

特点：
1.关系型数据库
2.客户/服务器体系
3.SQL兼容性：mysql遵循SQL:2003标准，并且有自己的扩展
4.子查询：从4.1版开始支持子查询
5.视图：从5.0版开始支持视图
6.存储过程：从5.0版开始支持存储过程
7.触发器：触发器是由数据库服务器在一些特定的数据库操作（INSERT,UPDATE和DELETE）过程中自动执行的一组SQL命令。MySQL从5.0版开始支持触发器（但不完备）
8.Unicode:Mysql支持Unicode
9.全文搜索：仅限英文字符
10.镜像复制：动态将一个数据库复制到另一个数据库，有限制（INnodb表格式支持）
11.事务：MyISAM表格式不支持，InnoDB表格式支持
12.外键约束：MyISAM表格式不支持，InnoDB表格式支持
13.GIS函数
14.ODBC：MySQL支持ODBC接口

不足：
1.MyISAM表格式进行操作时是表锁定，InnoDB表格式是行锁定
2.MyISAM表操作时不能热备份，解决方法是换成InnoDB表格式
3.MySQL不支持自定义数据类型
4.MySQL对XML支持不够良好
5.MySQL对存储过程和触发器支持不够良好

文章出处：http://www.diybl.com/course/7_databases/mysql/myxl/20081127/152729.html

 

 

软件工程中的tt应用：冒烟测试是指对提交测试的软件在进行详细深入的测试之前而进行的预测试，这种预测试的主要目的是暴露导致软件需重新发布的基本功能失效等严重问题。冒烟测试可以由开发人员执行，也可以由测试人员来执行。即，在版本编译后正式提交测试之前由开发人员执行；或开发发布版本后，测试人员在接受这个版本作为正式版本进一步测试前执行。微软提出在审查了变更的代码后，冒烟测试是确认修复的缺陷及功能变更是否有效的最经济有效的方法。冒烟测试能手动执行，也可以在版本编译后自动化执行，它是对基本功能的确认，非深入测试，但要覆盖到面，即所有的更改点都要进行确认。采用自动化执行是，可以结合每日构件后进行自动化的每日smoking test，如果测试通过，则把更改后的代码自动合并到主干代码仓库中，作为正式提交测试的版本。

　　对于smoking test在软件开发过程中的应用，下面提出一种可实施的步骤：

　　1. 根据软件的变更，包括新需求的实现、bug修复，设计出更改满足预期的功能级checklist。

　　2. 准备好测试环境。如：软件的运行环境是嵌入式产品，如手机，数码相机，医疗仪器等，需准备好用户使用的真实运行环境。如果是windows平台运行环境，请准备干净的操作系统。

　　3.执行checklist，确认基本功能有效，足以支持更进一步的详细、全面测试。

World Association of Psychoanalysis, WAP)

是一种向移动终端提供互联网内容和先进增值服务的全球统一的开放式协议标准， 是简化了的无线Internet 协议。WAP 将Internet和移动电话技术结合起来，使随时随地访问丰富的互联网络资源成为现实。WAP 服务是一种手机直接上网，通过手机WAP“浏览器”浏览wap 站点的服务，可享受新闻浏览、股票查询、邮件收发、在线游戏、聊天等多种应用服务。通过GPRS 网络接入WAP，可充分发挥接入时延短（2 秒接入）速率高、永远在线、切换方便等优点

WAP的基本原理

　　WDP：WAP数据报协议层，是发送和接收消息的传输层。

　　WTLS：无线传输安全层，是为像电子商务这样的应用提供安全服务。

　　WTP：WAP传输协议层，提供传输支持，增加由WDP提供的数据报服务的可*性。

　　WSP：WAP会话协议层，提供不同应用间的有效数据交换。

　　HTTP接口：支持移动终端的信息检索请求。

 

 

第 1 页 共 4 页
软件的界面测试与设计
在当今的软件领域，已经几乎找不到没有界面的应用软件了，而界面的设计和测试在我国却发展缓慢。
目前，界面设计引起软件设计人员的重视程度远远不够，直到最近网页制作的兴起，才受到大家的青睐。
而设计优良的界面由于需要具有艺术美的天赋而遭到拒绝。国内软件企业对此均不太重视。
界面是软件与用户交互的最直接的层面，界面的好坏决定用户对软件的第一印象。而设计优良的界面
能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。
设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，
再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。
目前流行的界面风格有三种方式：多窗体、单窗体以及资源管理器风格，无论那种风格，以下原则应
该得到重视或参考。
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）专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词眼。
17）对于界面输入重复性高的情况，该界面应全面支持键盘操作，即在不使用鼠标的情况下采用键盘
进行操作。
2. 规范性原则
通常界面设计都按Windows 界面的规范来设计，即包含“菜单条、工具栏、工具厢、状态栏、滚动条、
右键快捷菜单”的标准格式，可以说：界面遵循规范化的程度越高，则易用性相应的就越好。小型软件一
般不提供工具厢。
规范性细则：
1）常用菜单要有命令快捷方式。
2）完成相同或相近功能的菜单用横线隔开放在同一位置。
3）菜单前的图标能直观的代表要完成的操作。
4）菜单深度一般要求最多控制在三层以内。
5）工具栏要求可以根据用户的要求自己选择定制。
6）相同或相近功能的工具栏放在一起。
7）工具栏中的每一个按钮要有及时提示信息。
8）一条工具栏的长度最长不能超出屏幕宽度。
9） 工具栏的图标能直观的代表要完成的操作。
10）系统常用的工具栏设置默认放置位置。
第 2 页 共 4 页
11）工具栏太多时可以考虑使用工具厢。
12）工具厢要具有可增减性，由用户自己根据需求定制。
13）工具厢的默认总宽度不要超过屏幕宽度的1/5。
14）状态条要能显示用户切实需要的信息，常用的有：目前的操作、系统状态、用户位置、用户信息、
提示信息、错误信息、使用单位信息及软件开发商信息等，如果某一操作需要的时间较长，还应该显
示进度条和进程提示。
15）滚动条的长度要根据显示信息的长度或宽度能及时变换，以利于用户了解显示信息的位置和百分
比。
16）状态条的高度以放置五好字为宜，滚动条的宽度比状态条的略窄。
17）菜单和工具条要有清楚的界限；菜单要求凸出显示，这样在移走工具条时仍有立体感。
18）菜单和状态条中通常使用5 号字体。工具条一般比菜单要宽，但不要宽的太多，否则看起来很不
协调。
19）右键快捷菜单采用与菜单相同的准则。
3. 帮助设施原则
系统应该提供详尽而可靠的帮助文档，在用户使用产生迷惑时可以自己寻求解决方法。
帮助设施细则：
1）帮助文档中的性能介绍与说明要与系统性能配套一致。
2）打包新系统时，对作了修改的地方在帮助文档中要做相应的修改，做到版本统一。
3）操作时要提供及时调用系统帮助的功能。常用F1。
4）在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。也就是说帮助要有即时针对性。
5）最好提供目前流行的联机帮助格式或HTML 帮助格式。
6）用户可以用关键词在帮助索引中搜索所要的帮助，当然也应该提供帮助主题词。
7）如果没有提供书面的帮助文档的话，最好有打印帮助的功能。
8）在帮助中应该提供我们的技术支持方式，一旦用户难以自己解决可以方便的寻求新的帮助方式。
4. 合理性原则
屏幕对角线相交的位置是用户直视的地方，正上方四分之一处为易吸引用户注意力的位置，在放置窗
体时要注意利用这两个位置。
合理性细则：
1）父窗体或主窗体的中心位置应该在对角线焦点附近。
2）子窗体位置应该在主窗体的左上角或正中。
3）多个子窗体弹出时应该依次向右下方偏移，以显示窗体出标题为宜。
4）重要的命令按钮与使用较频繁的按钮要放在界面上注目的位置。
5）错误使用容易引起界面退出或关闭的按钮不应该放在易点位置。横排开头或最后与竖排最后为易点
位置。
6）与正在进行的操作无关的按钮应该加以屏蔽。
7）对可能造成数据无法恢复的操作必须提供确认信息，给用户放弃选择的机会。
8）非法的输入或操作应有足够的提示说明。
9）对运行过程中出现问题而引起错误的地方要有提示，让用户明白错误出处，避免形成无限期的等待。
10）提示、警告、或错误说明应该清楚、明了、恰当并且应避免英文提示的出现。
5. 美观与协调性原则
界面应该大小适合美学观点，感觉协调舒适，能在有效的范围内吸引用户的注意力。
美观与协调性细则：
1）长宽接近黄金点比例，切忌长宽比例失调、或宽度超过长度。
2）布局要合理，不宜过于密集，也不能过于空旷，合理的利用空间。
3）按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置。
4）按钮的大小要与界面的大小和空间要协调。
5）避免空旷的界面上放置很大的按钮。
6）放置完控件后界面不应有很大的空缺位置。
7）字体的大小要与界面的大小比例协调， 通常使用的字体中宋体9-12 较为美观，很少使用超过12
第 3 页 共 4 页
号的字体。
8）前景与背景色搭配合理协调，反差不宜太大，最好少用深色，如大红、大绿等。常用色考虑使用
Windows 界面色调。
9）如果使用其他颜色，主色要柔和，具有亲和力与磁力，坚决杜绝刺目的颜色。
10）大型系统常用的主色有"#E1E1E1"、"#EFEFEF"、"#C0C0C0"等。
11）界面风格要保持一致，字的大小、颜色、字体要相同，除非是需要艺术处理或有特殊要求的地方。
12）如果窗体支持最小化和最大化或放大时，窗体上的控件也要随着窗体而缩放；切忌只放大窗体而
忽略控件的缩放。
13）对于含有按钮的界面一般不应该支持缩放，即右上角只有关闭功能。
14）通常父窗体支持缩放时，子窗体没有必要缩放。
15）如果能给用户提供自定义界面风格则更好，由用户自己选择颜色、字体等。
6. 菜单位置原则
菜单是界面上最重要的元素，菜单位置按照按功能来组织。
菜单设置细则：
1）菜单通常采用“常用--主要--次要--工具--帮助”的位置排列，符合流行的Windows 风格。
2）常用的有“文件”、“编辑”，“查看”等，几乎每个系统都有这些选项，当然要根据不同的系统有所取
舍。
3）下拉菜单要根据菜单选项的含义进行分组，并切按照一定的规则进行排列，用横线隔开。
4）一组菜单的使用有先后要求或有向导作用时，应该按先后次序排列。
5）没有顺序要求的菜单项按使用频率和重要性排列，常用的放在开头， 不常用的靠后放置；重要的
放在开头，次要的放在后边。
6）如果菜单选项较多，应该采用加长菜单的长度而减少深度的原则排列。
7）菜单深度一般要求最多控制在三层以内。
8）对常用的菜单要有快捷命令方式，组合原则见8。
9）对与进行的操作无关的菜单要用屏蔽的方式加以处理，如果采用动态加载方式—即只有需要的菜单
才显示—最好。
10）菜单前的图标不宜太大，与字高保持一直最好。
11）主菜单的宽度要接近，字数不应多于四个，每个菜单的字数能相同最好。
12）主菜单数目不应太多，最好为单排布置。
7. 独特性原则
如果一味的遵循业界的界面标准，则会丧失自己的个性。在框架符合以上规范的情况下，设计具有自
己独特风格的界面尤为重要。尤其在商业软件流通中有着很好的迁移默化的广告效用。
独特性细则：
1）安装界面上应有单位介绍或产品介绍，并有自己的图标或徽标。
2）主界面，最好是大多数界面上要有公司图标或徽标。
3）登录界面上要有本产品的标志，同时包含公司图标或徽标。
4）帮助菜单的“关于”中应有版权和产品信息。
5）公司的系列产品要保持一直的界面风格，如背景色、字体、菜单排列方式、图标、安装过程、按钮
用语等应该大体一致。
6）应为产品制作特有的图标并区别于公司图标或徽标
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 关闭。
第 4 页 共 4 页
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）在主界面载入完毕后自动卸出内存，让出所占用的WINDOWS 系统资源。
3）关闭所有窗体，系统退出后要释放所占的所有系统资源 ，除非是需要后台运行的系统。
4）尽量防止对系统的独占使用。
注：此文章来源于测试管理中心论坛，本人在原有基础之上根据自己的经验进行了小范围的修改。
修正：Alan zhou
Email：foralanzhou@163.com

/**/ 百度首页 | 百度空间  document.write('| 登录'); 登录