测试用例编写说明
测试用例编写说明 ................................................................................................................... 1 一、
二、
三、
四、
五、
六、
七、
八、
什么是测试用例 ........................................................................................................ 1 我们的测试原则 ........................................................................................................ 1 理解设计 .................................................................................................................... 1 构造测试用例的框架 ................................................................................................ 2 充实用例内容 ............................................................................................................ 2 可玩性测试部分 ........................................................................................................ 3 易用性测试部分 ........................................................................................................ 3 后续维护更新 ............................................................................................................ 4
一、 什么是测试用例
为测试游戏中某一个或一组特定功能而制订的测试方法,通常是关于该功能中若干测试点的集合。
我们的测试用例与软件工程行业略有些不同,我们将一组测试点的集合放进一个EXCEL文档中,然后将这个文档称为一个测试用例。
二、 我们的测试原则
测试人员对自己的定位应该是把关人,不仅检查制作质量是否合乎设计和有无错误,同时还要考虑设计质量,包括逻辑合理性、可玩性、数值平衡等方面,以及提示信息、学习门槛、操作便捷性等影响使用感受的其它因素。
因此,测试主要有三个目地:检验功能正确、检验设计合理、检验使用感受。 在测试中,测试在检验、试用功能的同时,还需要有积极主动的心态,去思考功能系统中的各个元素、各个数值实际所起到的作用,以及它的价值,这些和设计定位是否一致、各组成部分之间的设计有无冲突、实际运行是否能达到设计目地。
所有这些考虑,都应将其记录下来,向策划反馈、沟通,尽量能够说服策划,或被策划说服,尽量少留“保留意见”这样的分歧。
只有收集冲突观点,并且将其解决,才能排除设计盲点、照顾更大群体、做出最好的游戏。
三、 理解设计
编写测试用例之前,要明确该功能的设计,在脑中构造出这个设计的基本框架与内容。
这样编写出来的用例才能做到测试条理清晰、减少测试漏洞。
为达到这个目地,我们使用功能覆盖法与路径分析法相结合的测试方法。
? 功能覆盖法就是全面列举系统所表现出来以及自己能想得到的各个细节,并逐一进
行测试。这种方法直观简单,但不容易保证测试的全面性。
? 路径分析法是从设计核心思想出发,按照系统流程与设计框架进行功能划分。这样
脉络清晰的方式可以较好地保证测试思路清晰,但需要对设计有较深的理解。
为保证达到目标,我们使用如下步骤与方法来理解功能设计:
1、 确认设计者(策划负责人)、实现者(程序负责人),并在测试用例的表头部分写明。
a) 如果有多个策划合作设计,或分块由不同程序实现,或责任人发生了转移,应
在负责人后注明其负责的部分。
2、 明确策划负责人之后,向其索要设计文档,并且尽可能地多利用策划沟通、交流、
测试实见等各种方式加强对该功能系统的了解。
3、 将各个方面收集掌握的信息,在脑中、草稿纸或草稿文档中还原出基本设计模型。
并与策划沟通核对所还原的设计模型正确、无偏差、无遗漏。
a) 游戏中大部分表现都是由规则驱动的。
b) 一个系统中最根本的思路、最核心的规则通常可以用很少的几句话表述出来。 c) 系统中每一个模块(功能块)都是为一定的目地而存在,都将为丰富、完善、
保护系统本身而起到一定的作用。
四、 构造测试用例的框架
按设计的脉络,把系统进行功能块划分,将整个系统拆分为多个功能块。这样就形成了测试用例的基本框架。
? 一个良好的设计结构中,通常功能块本身就已经有了良好的划分。
? 划分时要注意不遗漏、不交叉。功能块划分不清晰的部分往往最终就会成为测试盲
点。
? 除了功能块划分之外,测试用例框架中还可以包含公共条件类型、关注点类型、功
能与列举类型等其它不同划分。根据具体系统而实际选择,或双重划分方式进行展开来构造用例的框架。
这个阶段完成时,需要上传测试用例,以便及时审核,发现问题时也便于修改调整。
五、 充实用例内容
在框架的基础上继续细化,尽可能将功能块中的所有细节、边界、条件都列举出来,最终形成完善的测试用例。
用例中功能块的细则大体上可以分为条件功能型,与元素列举型两大类:
1、 条件功能型:由规则得出结果,在某个(某些)条件下成功完成功能,而另一些条
件下提示不可完成功能。包括游戏中大部分具体操作如购买道具、使用技能等等。 a) 这类功能以边界检查为主。检验在正确条件下系统完成了它所应该做的事情,
以及在错误条件下系统没有做它所不应该做的事情。
b) 要考虑到各种可能的条件。例如一个金钱输入框,要确认以下合法与非法的输
入:0、负数、小数、超过身上携带有的金钱、超过设计上限、刚好达到身上携带金钱、刚好达到设计上限、公式、字母、汉字、特殊符号,以及不输入直
接点确定、输入后点取消等各种边界。
2、 列举元素型:许多系统为了丰富而使用了大量列举元素(如生活技能产出的各种装
备、游戏中存在的各种野外常规小怪等)。这些列举元素规则都完全相同,而在输入不同时产生不同的结果。测试时根据具体情况决定是逐个列举全部测试或是抽查结合直接检查策划配置表的方式进行测试。
a) 这类功能需要为每个元素都进行一次相关测试点的验证。确保每一个元素的相
关所有信息全部正确无误。
b) 可以复制粘贴,不要嫌麻烦。
c) 列举时要注意各个元素有无和其它元素所不同的特例。有的话要单独写测试
点,并且高亮显示出来。
? 由统一的公式规则演化出来多个元素的可以直接检查边界条件即可。
? 由列举(逐个填表)产生的多个元素,如果数量很多,且影响范围较小、BUG级
别较低,可以进行抽查。(如剧情任务的任务文本等)
? 由列举产生的多个元素,如果影响范围较大、BUG级别较高的,必须进行遍历全
部测试。(如生活技能产品等)
? 不管哪种类型,都需要考虑各种资源(模型、贴图、动作、特效、音效等)与提示
信息。
六、 可玩性测试部分
可玩性是针对策划设计的把关,目地是检验这种设计在游戏推出之后它能足够好玩,能起到预期的作用。
绝大部分系统都是由策划为了好玩的目地而设计(包括好友、邮件等通常称为基础功能的系统),只有极少数纯功能性质的部分是完全没有可玩性概念的。
通常可玩性设计需要进行以下几个步骤:
1、 在理解设计结构的基础上,进一步理解策划做这种设计的意图目地,以及对这种设
计将要起到什么样作用的期望。并填写到用例中。
2、 解析系统设计中的每一个组成部分(功能块),并理解策划期望这个功能块的作用
目地。并填写到用例中。
3、 系统中的各个条件、操作、数值是否会产生不良感受,为每一个功能块考虑是否有
进行此项评估的必要,若有则填写到用例中。
在可玩性测试部分,需要注意几点:
? 注意,用例中的可玩性测试,是考察点,而不是考察结果。所以应该把所有认为值
得进行考察的内容都写进来,而不是仅仅记录有问题的部分。
? 可玩性测试是一个主观测试,它经常会没有客观量化的标准,而是以自己感觉是否
合适、是否舒服为依据。
? 一个设计在很多时候并没有绝对的好坏,而是在性价比、优缺点之间进行取舍。所
以在感受到缺点时,应该与策划沟通,但不应该固执已见。
七、 易用性测试部分
游戏软件是软件工程的一个分支,但游戏软件的特殊目地、特殊用户群等差异使得我们会更加注重软件的易用性。易用性测试主要包括:容易理解、容易学习、方便操作、吸引用
户、依从于主体风格与标准。
在我们已经有了各个功能部分的边界、细节之后,系统功能整体层面的易用性考虑主要有以下几个方面:
? 容易学习、理解、上手:一个一无所知的新玩家是否能顺利知道并掌握该功能。功
能的学习模块是否足够傻瓜化。(不要高估玩家的智商和求知欲)
? 界面清晰、方便、统一:界面的排版、布局、分组、分级是否足够清晰。(不要挑
战玩家的忍耐力和观察力)
? 操作方便顺手符合习惯:操作尽量考虑到一鼠走天下的低操作玩家和左右开弓的强
操作玩家的差异,并且与windows以及其它游戏一致。能单个操作解决的不要用多个操作,能单键放得下的不要设计成组合键。等等。(不要期望玩家为了你而改变自己的操作习惯)
? 提示清晰、细致、统一:这个数字或符号代表着什么?我正在做的操作将会导致什
么结果?破坏性的操作是否有足够强烈的警告?这两个词是指的同一个东西吗?等等。(不要指望玩家能记得所有细节,更不要逼着他去用猜的)
? 世界观统一且符合常理:同一阵营的角色们大方向应该统一而不是制造混乱认知、
游戏内的道德观应该与现实社会相一致等等。(不要让玩家忍受价值观相悖的不适感,更不要逼迫玩家为了一个游戏而改变他的人生价值观)
八、 后续维护更新
? 当设计或实现发生改变时,需要更新测试用例。
? 每一次进行测试时,要思考有没有遗漏的测试点,尤其是细节边界部分。发现的遗
漏要及时更新进用例中。
设计功能测试和界面(GUI)用例注意项:
1.1 文本框、按钮等控件测试
1.1.1 文本框的测试
如何对文本框进行测试
a,输入正常的字母或数字。
b,输入已存在的文件的名称;
c,输入超长字符。例如在“名称”框中输入超过允许边界个数的字符,假设最多255个字符,尝试输入 256个字符,检查程序能否正确处理;
d,输入默认值,空白,空格;
e,若只允许输入字母,尝试输入数字;反之;尝试输入字母; f,利用复制,粘贴等操作强制输入程序不允许的输入数据; g,输入特殊字符集,例如,NUL及\n等;
h,输入超过文本框长度的字符或文本,检查所输入的内容是否正常显示;
i,输入不符合格式的数据,检查程序是否正常校验,如,程序要求输入年月日格式为yy/mm/dd,实际输入yyyy/mm/dd,程序应该给出错误提示
在测试过程中所用到的测试方法:
1,输入非法数据;
2,输入默认值;
3,输入特殊字符集;
4,输入使缓冲区溢出的数据;
5,输入相同的文件名;
命令按钮控件的测试
测试方法:
a,点击按钮正确响应操作。如,单击确定,正确执行操作;单击取消,退出窗口;
b,对非法的输入或操作给出足够的提示说明,如,输入月工作天数为32时,单击”确定“后系统应提示:天数不能大于31;
c,对可能造成数据无法恢复的操作必须给出确认信息,给用户放弃选择的机会;
单选按钮控件的测试
测试方法:
a,一组单选按钮不能同时选中,只能选中一个。
b,逐一执行每个单选按钮的功能。分别选择了“男”“女”后,保存到数据库的数据应该相应的分别为“男”“女”;
c,一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中,不能同时为空;
up-down控件文本框的测试
测试方法:
a,直接输入数字或用上下箭头控制,如,在“数目”中直接输入10,或者单击向上的箭头,使数目变为10;
b,利用上下箭头控制数字的自动循环,如,当最多数字为253时,单
击向上箭头,数目自动变为1;反之亦适用;
c,直接输入超边界值,系统应该提示重新输入;
d,输入默认值,空白。如,“插入”数目为默认值,点击“确定”;或,删除默认值,使内容为空,单击“确定”进行测试; e,输入字符。此时系统应提示输入有误。
组合列表框的测试
测试方法:
a,条目内容正确,其详细条目内容可以根据需求说明确定; b,逐一执行列表框中每个条目的功能;
c,检查能否向组合列表框输入数据;
复选框的测试
测试方法:
a,多个复选框可以被同时选中;
b,多个复选框可以被部分选中;
c,多个复选框可以都不被选中;
d,逐一执行每个复选框的功能;
列表框控件的测试
测试方法:
a,条目内容正确;同组合列表框类似,根据需求说明书确定列表的各项内容正确,没有丢失或错误;
b,列表框的内容较多时要使用滚动条;
c,列表框允许多选时,要分别检查shift选中条目,按ctrl选中条
目和直接用鼠标选中多项条目的情况;
滚动条控件的测试
要注意一下几点:
a,滚动条的长度根据显示信息的长度或宽度及时变换,这样有利于用户了解显示信息的位置和百分比,如,word中浏览100页文档,浏览到50页时,滚动条位置应处于中间;
b,拖动滚动条,检查屏幕刷新情况,并查看是否有乱码; c,单击滚动条;
d,用滚轮控制滚动条;
e,滚动条的上下按钮。
各种控件在窗体中混和使用时的测试
a,控件间的相互作用;
b,tab键的顺序,一般是从上到下,从左到右;
c,热键的使用,逐一测试;
d,enter键和esc键的使用;
在测试中,应遵循由简入繁的原则,先进行单个控件功能的测试,确保实现无误后,再进行多个控件的的功能组合的测试。
ps:密码输入框测试时要特别注意进行字母大写输入的测试。 查找替换操作
案例演示:打开word中的"替换"对话框
测试本功能有通过测试和失败测试两种情况
通过测试:
1,输入内容直接查找,或查找全部
2,在组合框中寻找已经查找过的内容,再次查找并确认文档的内容正确,如,已经查找过"测试用例",再次进入不用重新输入查找内容,直接在文档中搜寻就可以.
失败测试:
1,输入过长或过短的查询字符串.如,假设查询的字符串长度为1到255,那么输入0,1,2,256,255和254进行测试;
2,输入特殊字符集,如,在word中.^g代表图片,^代表分栏符,可以输入这类特殊字符测试;
替换测试大体相同.
关于编辑操作窗口的功能测试的用例:
1,关闭查找替换窗口.不执行任何操作,直接退出;
2,附件和选项测试.假如,设定"精确搜寻","向后"搜索等附件选项等等来测试;
3,控件间的相互作用.如,搜寻内容为空时,按钮"搜寻全部","搜寻","全部替换","替换"都为灰色.
4,热键, Tab键.回车键的使用.
插入操作
1,插入文件
测试的情况
a,插入文件;
b,插入图像;
c,在文档中插入文档本身;
d,移除插入的源文件;
e,更换插入的源文件的内容;
2,链接文件
测试方法:
a,插入链接文件;
b,在文档中链接文档本身;
c,移除插入的源文件;
d,更换插入的源文件的内容.
3,插入对象
要测试的内容
a,插入程序允许的对象,如,在word中插入excel工作表; b,修改所插入对象的内容.插入的对象仍能正确显示;
c,卸载生成插入对象的程序,如,在word中插入excel工作表后卸载excel,工作表仍正常使用.
编辑操作
编辑操作包括剪切,复制,粘贴操作.
测试剪切操作的方法
a,对文本,文本框,图文框进行剪切;
b,剪切图像
c,文本图像混合剪切
复制操作方法与剪切类似.
测试时,主要是对粘贴操作的测试,方法是:
a,粘贴剪切的文本,文本框及图文框;
b,粘贴所剪切的图像;
c,剪切后,在不同的程序中粘贴
d,多次粘贴同一内容,如,剪切后,在程序中连续粘贴3次; e,利用粘贴操作强制输入程序所不允许输入的数据.
界面测试用例的设计方法
1,窗体
测试窗体的方法:
a,窗体大小,大小要合适,控件布局合理;
b,移动窗体.快速或慢速移动窗体,背景及窗体本身刷新必须正确; c,缩放窗体,窗体上的控件应随窗体的大小变化而变化;
d,显示分辨率.必须在不同的分辨率的情况下测试程序的显示是否正
常;
进行测试时还要注意状态栏是否显示正确;工具栏的图标执行操作是否有效,是否与菜单懒中图标显示一致;错误信息内容是否正确,无错别字,且明确等等;
2,控件
测试方法:
a,窗体或控件的字体和大小要一致;
b,注意全角,半角混合
c,无中英文混合.
菜单
进行测试时要注意
a,选择菜单是否可以正常工作,并与实际执行内容一致; b,是否有错别字:
c,快捷键是否重复;
d,热键是否重复;
e,快捷键与热键操作是否有效
f,是否存在中英文混合
g,菜单要与语境相关,如,不同权限的用户登陆一个应用程序,不同级别的用户可以看到不同级别的菜单并使用不同级别的功能; h,鼠标右键快捷菜单
特殊属性
1,安装界面应有公司介绍或产品介绍,有公司的图标
2,主界面及大多数界面最好有公司图标
3,选择"帮助"->"关于"命令,应看见相关版权和产品信息
界面风格与测试的必要规则
无意中看到下面这篇文章,觉得很不错,推荐给大家看看。
正文:
界面是软件与用户交互的最直接的层,界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作,起到向导的作用。同时界面如同人的面孔,具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉,相反由于界面设计的失败,让用户有挫败感,再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度还远远不够,直到最近网页制作的兴起,才受到专家的青睐。 目前流行的界面风格有三种基本方式:多窗体、单窗体以及资源管理器风格,无论那种风格,以下规则是应该被重视的。
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):尽量防止对系统的独占使用。
美丽的事物常常会让人无法抗拒。这就是为什么产品出色的外观设计对于电脑、汽车、日用品、家具、食品、服装等等几乎所有商品的销售与推广,都有着举足轻重的作用的原因。
同样的道理,对于软件公司来说,软件产品就是他们的商品,而软件界面就是他们产品的外观,界面的美观与否,直接关系到了软件产品的营销成败。
我们可以清楚地看到,微软公司对软件界面设计的重视。请回想一下您在第一次见到win2000时的情景,与nt4.0相比是否惊叹他界面的美观性与易用性?而您如果使用过xp系统,则会被其令人神奇的感官概念而震惊折服!金山公司的金山词霸就是国内软件成功的例子了,从金山词霸3.0到金山词霸2001 的变化堪称经典。著名的网页动画制作软件flash从3.0到4.0,仅仅修改了图标和窗体,立即大为增色?
现今世界上成功的软件公司都非常重视软件界面的美化设计工作,因为他们深刻地知道,在激烈的市场竞争中,仅仅有强大的功能是远远不够的,不足以战胜强劲的对手。我们可以相象一下,您在挑选手机的时候,如果有两款手机,性能相同,而第一款比第二款要美观很多,那么您将选择哪一款呢?当然是美观的那一款了。试想,您的客户,也会拿您和您竞争对手的软件做这样的比较的。
现在的软件企业都知道,广告和市场推销活动对市场营销的作用是多
么的重要,并不遗余力地打广告、做活动、做推广。但我们知道,这些活动的最终目的,是为了让用户购买并使用软件产品,而用户最终使用的也是您的产品,那么为什么不在软件界面的美观性上多下些工夫呢?在诸如家用电器、汽车、电脑等成熟的市场中,用非常精美的广告去推广一种功能强大却丑陋无比的产品,是一种笑话。然而,这样的笑话在软件行业里却屡见不鲜。这也是像中国足球一样,中国软件业与国外相比较存在的一个很大的差距。
登陆测试用例测试编号001测试目标验证系统是否对输入合法用户名和密码时做出正确的响应测试环境windowsXP操作系统和浏览器IE…
PsnCodeSharer个人代码在线共享管理系统测试用例PsnCodSharer个人代码在线共享管理系统测试用例作者吕佳芯完成日…
MicroBlog微博统测试用例说明书MicroBlog微博1系统测试用例说明书MicroBlog微博统测试用例说明书变更记录2M…
1测试CASE的理解11事前条件111事前条件的含义事前条件是测试式样书中每一条CASE的公共入口112事前条件的书写方法建议在编…
1测试环境本章包含进行测试执行的测试环境的相关描述11手机端硬件和软件配置HuaweiU8825D手机或模拟器Sfa57手机端安装…
测试用例说明书1引言11编写的目的在本机票预定系统项目的前一阶段也就是需求分析阶段中已经将系统用户对本系统的需求做了详细的阐述这些…
XXXX信息化建设项目应用软件开发子项目测试规格说明书XXXX信息工程有限公司版权声明XXXX信息化建设项目应用软件开发子项目系统…
登陆测试用例测试编号001测试目标验证系统是否对输入合法用户名和密码时做出正确的响应测试环境windowsXP操作系统和浏览器IE…
PsnCodeSharer个人代码在线共享管理系统测试用例PsnCodSharer个人代码在线共享管理系统测试用例作者吕佳芯完成日…
MicroBlog微博统测试用例说明书MicroBlog微博1系统测试用例说明书MicroBlog微博统测试用例说明书变更记录2M…