软件界面测试方法.docx

上传人:b****3 文档编号:4002478 上传时间:2023-05-06 格式:DOCX 页数:16 大小:27.72KB
下载 相关 举报
软件界面测试方法.docx_第1页
第1页 / 共16页
软件界面测试方法.docx_第2页
第2页 / 共16页
软件界面测试方法.docx_第3页
第3页 / 共16页
软件界面测试方法.docx_第4页
第4页 / 共16页
软件界面测试方法.docx_第5页
第5页 / 共16页
软件界面测试方法.docx_第6页
第6页 / 共16页
软件界面测试方法.docx_第7页
第7页 / 共16页
软件界面测试方法.docx_第8页
第8页 / 共16页
软件界面测试方法.docx_第9页
第9页 / 共16页
软件界面测试方法.docx_第10页
第10页 / 共16页
软件界面测试方法.docx_第11页
第11页 / 共16页
软件界面测试方法.docx_第12页
第12页 / 共16页
软件界面测试方法.docx_第13页
第13页 / 共16页
软件界面测试方法.docx_第14页
第14页 / 共16页
软件界面测试方法.docx_第15页
第15页 / 共16页
软件界面测试方法.docx_第16页
第16页 / 共16页
亲,该文档总共16页,全部预览完了,如果喜欢就下载吧!
下载资源
资源描述

软件界面测试方法.docx

《软件界面测试方法.docx》由会员分享,可在线阅读,更多相关《软件界面测试方法.docx(16页珍藏版)》请在冰点文库上搜索。

软件界面测试方法.docx

软件界面测试方法

一、引言

预防胜于纠错。

一个界面不规范的软件,很难让用户相信其内部代码的条理性、精致、健壮和高效.伴随着我们软件项目的持续增多以及新团队成员的不断加入,软件的界面缺陷在系统测试阶段也表现得日益突出,因此有必要有针对性地通过对这些问题汇总和归纳,不断地明确软件界面的测试要求,使今后项目的界面质量问题从根本上得到重视和改观.

二、界面标准

2。

1有效性检查方面:

☐数据输入验证正确;输入数据宽度超出设定,是否给出提示;

☐数值型、日期型、字符型及‘-’、‘|’等特殊符号的检查;

☐数值字段(如重量、件数、体积)在非特殊情况下不允许可输入“0”及“负数”;

☐日期的控制,如:

结束日期不能早于开始时间、班次内的作业时间不能超出班次时间等;

☐具有输入的合法性验证机制,对于超常规和破坏性的录入,如输入的非有效性、超长、超边界、输入与字段类型不符等,应有提示并拒绝接受;

☐身份证号/邮编/Email地址应作用正则表达式进行验证;【B/S】

☐下拉列表过滤,对于有过滤要求的下拉列表,应按要求进行过滤。

2.2健壮性检查方面:

☐鼠标在窗口任意部分的点击是否正常;数据输出正确;

☐光标到不可输入、修改列时,是否可输入、修改数据;

☐鼠标对界面上的任何对象进行拖拽、点击、选取以及进行随意、无规律操作后,不出现未控制的意外错误;

☐对于超常规、破坏性和无序操作的录入可以安全控制,不出现意外的、非正常终止的错误(如:

插入重复记录、删除代码表等);

☐不出现因网络连接中断后系统崩溃情况(提供自动连接或手动连接功能)

2。

3一般性美观布局检查方面:

☐窗口标题是否正确;

☐窗口的位置和大小是否合理(居中);

☐窗口中的控件布局是否合理,排列是否整齐;

☐当超出一屏时,是否有垂直、水平滚动条(滚动条应位于数据块的右侧和底部);

☐一个屏幕有多个块时,每块的左上角是否有红色块标题;【或按照开发规范】

☐字段标签的对齐方式是否正确(两端对齐);【或按照开发规范】

☐是否有初始值和默认值,初始值和默认值是否合理;【或按照开发规范】

☐上页与下页的显示是否与实际一致;

☐代码与代码名称是否相符(内容正确);

☐按钮的名称是否正确、全面,如上页、下行等;

☐按钮的快捷键定义是否统一;

☐按钮功能是否有效;按钮的提示与功能是否贴切、规范、概括性强;

☐屏幕上数据显示的对齐方式是否满足以下原则:

字符列左对齐,数值列右对齐,日期型的应设置格式掩码。

☐查询结果多于一页时,是否显示页号,上页按钮在当前页为第一页时,下页按钮在当前页为最后一页时是否变灰;

☐查询结果是否可以修改;

☐单记录块中非空字段名是否为红色;

☐一个字段数据录入完毕跳到下个字段后,该字段数据显示的对齐方式是否自动满足以下原则:

字符列左对齐,数值列右对齐;

☐备注等说明信息较长的字段,双击是否可以弹出编辑框;

☐在执行完其他功能后是否返回默认焦点;

☐所有的下拉选择数据窗口、下拉列表是否确实可用(是否既可输入编号,又可输入名称);

☐确保数据精度显示的统一:

如单价0元,应显示为0.00元;

☐确保时间及日期显示格式的统一;

☐确保相同含义属性/字段名的统一;

☐“关于”窗口内容:

项目及产品信息LOGO、公司地址的检查;

☐弹出窗口/页面的标题应与对应的功能名称相符,不出现不合适窗口标题

☐多记录窗口显示应有默认的排序

☐控件排列整齐、整体上界面风格一致;(如:

日期格式统一、选船、选箱、操作员名称显示等;集装箱业务领域中的字段标签箱公司、箱主、箱代理、控箱公司、箱经营人、航次号及到验号、“修改员”、“最后修改员"、“更改员”等定义的统一);

☐按钮应提供快捷键;按钮标签文本除快捷外不出现英文;

☐焦点控制不合理或不全面;

☐按美工的设计要求进行布局。

2。

4提示信息检查方面:

☐删除时应有提示信息,删除窗口的按钮缺省焦点在[否]上;编辑状态下,若窗口数据发生了变化,在退出窗口或进行刷新时应有提示信息(或交由业务规则来确定是否进行显示)

☐操作失败时有提示,同样操作成功是也应有提示(或根据业务规则)

☐在某些数据输入界面,如果要求输入的数据符合某项规则,应在输入界面提供相应的规则描述(如:

日期格式);当输入数据不符合规则时应提示用户是否继续.

☐在对任何配置信息修改后,都应该在用户退出该界面时提示用户保存(如果用户没有主动保存的情况下);

☐录入的查询条件不合法是否给出正确提示;

☐窗口中的提示信息有无错别字,标点符号是否合理,字体是否合理;

☐窗口中的静态提示信息的意义表达是否准确(不产生歧义);

☐一条记录有非空字段未输入而存盘,是否给出面向用户的提示信息,而非专业提示,并且仍保持在录入状态;

☐录入非法字符是否能马上识别且给出提示;

☐主键重复存盘时,是否给出提示;

2.5友好性方面:

☐界面相应速度应使操作者感觉不出明显的操作迟滞和等待;如果某一操作需要的时间较长,应有相应进度条显示或动态提示信息;

☐下拉列表数据应按用户习惯(如:

代码、名称、简称等)进行排序;

☐状态条要能显示用户需要的信息,如:

 用户信息、数据库连接信息(当前库/历史库信息)、当前日期及时间等;

☐可以根据业务规则定义来控制当查询/报表输出的数值型字段为0时显示为“--"或NULL的能力;

☐数据保存后,立刻能看到修改后的数据情况,不必依赖于手工刷新;

☐对于在操作过程中获取到的例外错误的显示要利于操作者的理解;

☐若项目基于已有项目,应不出现原项目字样及敏感数据,如客户代码、费率、电话等。

2。

6正确顺序显示方面:

☐进入系统或增加记录时,是否将光标置于用户可能实施操作的第一个对象上;

☐字段及按钮选择,用键盘或鼠标是否都能达到目的;

☐各数据项的键盘导航顺序是否正确;在编辑状态下使用Enter键、Tab键字段导顺序与控件排列顺序要一致;

☐通过键盘移动光标时,是否会出现丢失焦点的现象;

☐控制好按钮使用的先后顺序。

例如只有确认之后才能进行反核;

三、参考资料

补充:

1。

在宽屏显示模式下正常,普通窄屏模式下也能显示正常;

 

软件易用性测试

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

通常对易用性有如下定义:

易见Easytodiscover:

单单凭观察,用户就应知道设备的状态,该设备供选择可以采取的行动。

易学Easytolearn:

不通过帮助文件或通过简单的帮助文件,用户就能对一个陌生的产品有清晰的认识。

易用Easytouse:

用户不翻阅手册就能使用软件。

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

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、内容测试

内容测试用来检验应用系统提供信息的正确性、准确性和相关性.信息的正确性是指信息是可靠的还是误传的.例如,在商品价格列表中,错误的价格可能引起财政问题甚至导致法律纠纷;信息的准确性是指是否有语法或拼写错误。

这种测试通常使用一些文字处理软件来进行,例如使用MicrosoftWord的”拼音与语法检查"功能;信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口,也就是一般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)MSWindows保留键:

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)在一个应用系统中,开发者应当避免用户作出XX或没有意义的操作。

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

(9)对可能发生严重后果的操作要有补救措施。

通过补救措施用户可以回到原来的正确状态.

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

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

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

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

(14)特殊字符常有;;’”〉〈,`‘:

“[”{、\|}]+=")—(_*&&^%$#@!

,。

?

/还有空格.

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

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

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

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

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

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

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

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

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

按照测试实施组织划分,软件测试可分为开发方测试、用户测试(β测试)、第三方测试。

●开发方测试。

通常也叫“验证测试”或“α测试"。

开发方通过检测和提供客观证据,证实软件的实现是否满足规定的需求。

验证测试是在软件开发环境下,由开发者检测与证实软件的实现是否满足软件设计说明或软件需求说明的要求。

主要是指在软件开发完成以后,开发方对要提交的软件进行全面的自我检查与验证,可以和软件的“系统测试”一并进行。

●用户测试.

在用户的应用环境下,用户通过运行和使用软件,检测与核实软件实现是否符合自己预期的要求.通常情况用户测试不是指用户的“验收测试",而是指用户的使用性测试,由用户找出软件的应用过程中发现的软件的缺陷与问题,并对使用质量进行评价。

β测试通常被看成是一种“用户测试"。

β测试主要是把软件产

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 求职职场 > 简历

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2