软件测试中通用的测试用例(很全).docx

软件测试中通用的测试用例(很全).docx
软件测试中通用的测试用例(很全).docx

B/S 程序通用测试点

1 、界面测试通用测试点

测试内容测试点

1、浏览器窗口标准或最大时页面元素显示是否正确,是否美观,窗口大小变

页面显示化时页面刷新是否正确;

2、电脑显示屏是宽屏或标屏下页面元素显示是否正确,是否美观;

3、用户常用的几种分辨率下页面元素显示是否正确,是否美观。

4、字体的大小要与界面的大小比例协调,通常使用的字体中宋体

美观,很少使用超过12 号的字体。

9-12较为5、前景与背景色搭配合理协调,反差不宜太大,最好少用深色,如大红、大

绿等。

6、页面弹出式提示界面必须大小合理,布局美观,符合系统风格。

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

2、相关页面元素的外形是否美观大方,大小是否合适,位置和页面的风格是

页面布局否协调。

3、页面相关说明性文字的位置是否正确合适,鼠标定位在需说明的控件上时

相关提示信息位置是否合理。

1、同一系统中不同页面的整体风格是否一致,是否美观;

页面风格2、各页面背景、色调是否正确,是否美观,是否适合应用环境。

3、主色调要柔和,具有亲和力与磁力,坚决杜绝刺目的颜色。

1、按钮名称易懂,用词准确,屏弃多义性字眼,要与同一界面上的其他按钮

易于区分,能望文知意最好。

2、对于完成同一功能的控件需要集中放置;Tab 键的顺序与控件排列顺序要

一致,目前流行总体从上到下,

同时行间从左到右的方式。

3、默认按钮要支持Enter 及选操作,即按Enter 后自动执行默认按钮对应操作。易用性

4、页面要支持键盘自动浏览按钮功能,即按Tab键、回車鍵的自动切换功能。

5、页面输入控件的选择要合理合适,同一界面复选框不能出现太多,下拉列表选

项也不宜太多。

6、常用菜单功能需提供操作快捷键,快捷键的定义应符合大众操作习惯。

7、页面存在工具栏的,工具栏需要设置默认停靠位置,工具栏长度不能太长,

工具栏上的按钮需提供提示信息,

工具栏功能可以用户自行定制。

1、对于需要等待的操作,如果时间稍长就应该提供进度条显示。

2、菜单深度一般要控制在三层以内,树状结构类似。

3、滚动条的长度要根据显示信息的长度或宽度能及时变换,以利于用户了解友好性

显示信息的位置和百分比。

4、对用户操作需要反馈足够的信息,例如提示、警告、或错误,信息表达应

该清楚、明了、恰当、准确。

~ , ` , ! , @, # , $ , %, ^ , & , * , ( , ) , ; , | , \ , / , < , > , , , . , { , } ,

特殊字符

[ , ] , ' , " 。一般的输入框中需要屏蔽上面列举的特殊字符,使其不能输入。

2、页面元素通用测试点

对页面元素最基本的测试点

1、对于必须输入的内容需要和非必输项需要明显的区分开来;

2、对于需要设置的内容的描述需要准确、易懂、符合行业表达习惯;

3、对于设置选项需要提供Tab 键切换,对于操作需要支持Enter 键确认。

4、页面功能容错性必须良好,对于操作需要有完善的警告、提示、出错处理机制。

页面元

测试点

1、输入内容应有长度限制,超出限定长度应给出准确提示信息;

文本输 2、不允许为空的输入项在不输内容的情况下应反馈准确提示信息;

入框 3、输入框的大小应该和输入内容相匹配,和界面布局相匹配;

4、综合运用等价类和边界值分析的方法确定输入内容长度进行测试。

1、不允许输入字符或汉字,不允许输入特殊字符;

数字输

2、应该根据允许输入的数据范围锁定输入长度;

入框

3、综合运用等价类和边界值分析的方法确定具体测试数据。

1、按钮应该美观,大小合理,按钮上的内容位置应居中;

2、按钮和整个页面风格保持一致,布局位置合理;

按钮

3、功能操作的确认、重置、取消按钮应该在所有输入控件下方的合适位置;

4、鼠标指针移动到按钮上时应该自动变为手形(也可同时变化按钮背景色)。

1、下拉列表中的选项内容是否正确,包括确定选项的下拉列表,从数据库中获

取数据的下拉列表,或既有确定.

下拉列选项又从数据库中获取数据几种情况;

表框2、下拉列表中选项内容应该根据拼音或是否常用进行排序;

3、下拉列表中的选项太多的情况下应该提供输入功能,并自动根据输入内容过

滤出对应选项,方便选择操作。

1、选择框中的选项内容是否正确,包括确定选项的下拉列表,从数据库中获取

数据的下拉列表,或既有确定选

项又从数据库中获取数据几种情况;

2、需提供Shift键和Ctrl键选择选项的功能;需提供全选和全取消的功能;选择框

3、对于已经选择的选项不应该再出现在被选列表中,而应该出现在已选择列表中,反之亦然;

4、对于有顺序要求的选择设置操作需要提供顺序调整功能。

5、选择框布局、前景、背景色应该美观合理,应该和所在界面,及整个系统

的风格、色调保持一致。

1、输入域要美观、漂亮,大小合理,和整个页面的布局融为一体;

2、输入域中输入内容时需提供自动换行功能,超出输入域长度或宽度时需要有

滚动条可以操作。

输入域

3、输入域中文字的默认字体、大小、颜色需和整个页面保持一致。

4、输入域中可输入内容应有长度限制,综合运用等价类和边界值分析的方法确

定输入内容长度进行测试。

1、控件上各功能按钮的图标应该符合大众的使用习惯,按钮大小应符合页面

环编辑控境;

件2、鼠标放到按钮上时应该有准确的提示或说明信息;

3、各编辑功能可以正确影响被编辑内容的显示效果,可以正确保存或回退。

单选框同一组单选框只能选择其中某一个选项,需要默认选择第一个选项。

1、存在比较多复选选择框需设置的情况下,需要提供复选框的全选、反选、全

不选的功能;

2、同一个页面不应该出现太多的复选框;如果有太多的选项,考虑其他实现方

复选框法,比如选择框;

3、树状复选框选中上层结点会自动选中所有下层结点,反之亦然;选中下层结

点会自动选中该结点对应的上层结点,

去掉下层结点的勾选不影响上层结点的选择。

1、日期时间控件需要和页面风格保持一致,大小合理,界面美观;

2、日期时间应该可以选择设置,同时也可以手工输入来进行设置;

日期时 3、设置内容可以正确返填到对应的输入框中。

间控件 4、日期设置中如果默认了日期,日期一般需要从服务器获得。

5、如果相关功能是根据时间段控制的话,程序需要控制起始时间不能大于结束

时间。

1、树形结构结点的展开收缩时树的刷新,及结点对应内容的刷新应正确及时;

2、树形结构应该控制最多有 3 层,否则会造成操作不方便。

树形结

3、树形结构应该和整个界面风格保持一致;

4、编辑树形结构的结点后树形结构刷新显示正确(树形结构不会自动收缩起

来等)。

1、弹出窗口的风格应该和系统风格保持一致,弹出窗口界面布局应该合理美观;弹出窗

2、弹出窗口应该屏蔽最小化和最大化按钮,只保留关闭按钮;

3、弹出窗口的显示位置应该合理美观,且允许拖动。

1、导航按钮风格和应用系统的页面结构、菜单、链接的风格是否一致;

页面导 2、图片按钮导航或按钮导航应该可以准确切换到对应功能;

航3、鼠标置于导航按钮上时应该显示成特殊的鼠标指针,且导航按钮应该高亮显示。

1、系统主窗口的标题显示内容应该是当前系统的名称,屏蔽掉其他无关的内容,严禁

出现与系统登陆和程序路径

相关的信息;

窗口标

2、弹出的操作功能窗口的标题为对应功能名称,屏蔽掉其他无关的内容;

3、提示信息弹出框标题直接显示为“提示”,警告和错误提示框的标题显示为

“警告”和“错误”,界面图标选

择合适图标。

1、根据页面空间合理确定每页显示的内容行数,在内容超出行数的情况下合理

提供翻页(上翻、下翻、首页、末页)

及跳转页面的功能;

内容列 2、内容不足一页及没内容的情况下不显示翻页及页面跳转功能按钮;

表3、新增、修改内容列表某条内容后应该定位到对应页面的对应内容上;

4、删除内容列表某条内容后应该定位到当前页面的第一条内容上,如果该条

内容删除后对应页面没有内容则定位到

上一页面内容列表中第一条内容上。

1、表格边线颜色应该符合整个界面的配色方案,表格大方美观;

2、表格边线一般要比内部线条稍粗一点;

3、表格中内容显示要求:表头内容统一加粗居中,内容长度不等的列统一水平

表格

靠左垂直居中,内容长度相等的列需

要居中显示。

4、表格中不允许出现按钮链接,统一使用字符串链接。

1、超级链接的文字颜色应该和所在页面普通文字的颜色区分开,但要融入整个

页面的配色方案;

超级链 2、当鼠标指针移动到超级链接上时应自动变为手形(也可同时变化链接的背景接色),且可以通过单击打开链接对应

的界面或文件。

3、鼠标指针在普通文本显示区域决不能随便变化鼠标指针的形状。

3、相关功能通用测试点

功能测试点

1、新增功能应该不允许新增对应数据表主键内容重复的数据;

2、新增功能是否正确保存数据到对应的数据表中的正确字段;

新增3、新增功能不会影响数据库中已经存在的数据。

4、新增成功或失败都应该反馈准确的提示信息。

5、新增时应该自动处理掉输入内容两端的空格。

1、修改功能是否正确修改数据库中对应表的对应字段的数据;

2、修改功能应该不允许修改数据库中对应表的对应记录的主键数据;

3、修改功能不会影响数据库中与对应修改数据无关的数据,不会新增数据

修改

(除非新增处理是作废原记录并新增记录)。

4、修改成功或失败都应该反馈准确的提示信息。

5、修改提交时应该自动处理掉输入内容两端的空格。

1、删除功能操作时必须提供删除确认步骤;

2、删除功能会正确删除数据库中对应的记录;

删除3、删除功能不会删除删除数据以外的任何数据。

4、删除成功或失败都应该反馈准确的提示信息。

5、根据条件删除数据的功能必须是精确条件删除。

1、查询功能需要区分实现精确查询和模糊查询功能;

2、查询功能需自动处理输入内容两端的空格;

查询

3、模糊查询需屏蔽掉SQL语句中用到的通配符;

4、查询效率应该可以符合平常使用要求。

1、文件下载应该可以选择文件的存储目录,下载过程需要有进度条跟踪显

示,可调用 Windows 的下载控件;

2、文件应该可以在客户端直接打开;

文件下载、3、文件下载保存时应该自动选择对应的正确文件格式和默认文件名,允许打开对文件重命名,一般情况下应不允许修改

文件的保存格式。

4、鼠标置于下载链接上时应该显示为特殊的鼠标指针,该指针符合大众的

使用习惯。

1、打印预览看到的文件效果和文件打印出来的效果应该是一致的;

打印预览及

2、文件多页的情况下打印预览应提供翻页的预览功能;

打印

3、文件打印时应该可以设置布局和选择纸张。

1、文件或报表导出后格式应该符合客户的格式要求,可以直接打开文件;

2、报表导出后需要验证导出的报表数据的正确性;可以和查询数据进行比文件 / 报表较来验证;

导出3、文件导出保存时应该自动选择对应的正确文件格式和默认文件名,允许对文件重命名,一般情况下应不允许修改

文件的保存格式。

1、对于文件上传需要提供浏览本地文件的功能;最好可以提供上传文件的

预览功能;

2、上传文件时间稍长的情况下需要提供过程进度条;

文件上传

3、文件上传后应该加密保存到服务器的特定目录下,只有解密后才可以正

确查看(暂不测试文件加密解密);

4、文件上传成功或失败都应该反馈准确的提示信息。

1、系统相关功能应该只有当操作员具有对应权限时才能使用;

2、新增、修改、删除等改变已有数据的功能需要具有操作权限才能进行;权限控制

3、查询数据需要具有数据的查询权限才能进行;

4、对于分层控制的权限,具有上层权限自然就拥有了下层权限。

文本框测试用例

一、文本框字符型

必填非空校:

1、必填未入--程序提示;

2、必填只入若干个空格,未入其它字符--程序提示;

字段唯一性校:(不是所有字段都作此校,目情况而定)

1、新增入重复的字段--必提示友好信息;

2、修改入重复的字段--必提示友好信息;

字段度校:

1、入 [最小字符数 -1] --程序提示;

2、入 [最小字符数 ]-- OK ;

3、入 [最小字符数 +1] -- OK ;

4、入 [最大字符数 -1] -- OK ;

5、入 [最大字符数 ]-- OK ;

6、入 [最大字符数 +1] --程序提示;

字段特殊字符校:

1、入域如某些字符禁止入,限制是否成功,提示信息是否友好;

2、中文、英文、空格,数字,字符,下划、引号等所有特殊字符的合;

3、所有特殊字符都必行(!~@#$^&*()_+{}|: “<>?/.,; =‘-`[]¥??()--:《》?、。,;’【】、 =- ·)

字段特殊代校:

1、入 htm 代:比如” 你好 ”;--必以文本的形式将代示出来。

2、入 JavaScript 代:比如 ;--必以文本的形式将代示出来。

多行文本框输入:

1、是否允许回车换行;

2、保存后再显示能够保持输入时的格式;

3、仅输入回车换行,检查能否正确保存;若能,查看保存结果。若不能,查看是否有

正确提示;

4、仅输入空格,检查能否正确保存;若能,查看保存结果。若不能,查看是否有正确

提示。

二、文本框为数值型

边界值:

1、输入 [最小值 -1] --程序应提示错误;

2、输入 [最小值 ]-- OK ;

3、输入 [最大值 ]-- OK ;

4、输入 [最大值 +1] --程序应提示错误;

位数:

1、输入 [限制位数 ]-- OK ;

2、输入 [限制位数 +1] --根据实际项目而定,是否自动四舍五入成限制位数,还是提

示信息;

3、输入 [限制位数 -1]-- OK ;

异常值、特殊值:

1、输入非数值型数据:汉字、字母、字符--程序应提示错误;

2、输入负数--根据实际项目而定,如果不允许输入负数,必须提示友好信息;

3、字段禁止直接输入非数值型数据时,使用“粘贴”、“拷贝”功能尝试输入,并测试能否正常提交保存--只能使用“粘贴”、“拷贝”方法输入的特殊字符应无法保存,并应给出相应提示;

4、全角数字和半角数字的情况--全角数字不能保存,提示友好信息,半角数字正常

保存;

5、首位为零的数值:如01 = 1--视实际项目情况而定;

三、文本框为日期型

合法性检查:

1、日输入 [0 日 ]--程序应提示错误;

2、日输入 [1 日 ]-- OK;

3、日输入 [32 日 ]--程序应提示错误;

4、月输入 [1、 3、

5、 7、8 、 10、 12月 ]、日输入 [31 日 ]-- OK ;

5、月输入 [4、

6、 9、 11月 ] 、日输入[30日 ]-- OK ;

6、月输入 [4、 6、 9、 11 月 ] 、日输入[31 日 ]--程序应提示错误;

7、输入非闰年 ,月输入 [2 月 ]、日输入[28日 ],比如 2009.2.28-- OK ;

8、输入非闰年 ,月输入 [2 月 ]、日输入 [29日 ],比如 2009.2.29--程序应提示错误9 、

(闰年 )月输入 [2 月 ]、日输入 [29 日 ],比如 2008.2.29 -- OK ;

10 、 (闰年 )月输入 [2 月 ]、日输入 [30 日 ],比如 2008.2.30 --程序应提示错误;

12 、月输入 [1 月 ]-- OK ;

13 、月输入 [12 月 ] -- OK ;

14 、月输入 [13 月 ] --程序应提示错误;

格式检查:

1、不合法格式:2009-09 、 2009-09 - 、 200-2-2 ;

2、视具体项目而定是否合法:2009/09/01 、 2009.09.01、20090901、2009-09-01;

异常值、特殊值:

1、输入汉字、字母、字符--程序应提示错误;

四、文本框为时间型

合法性检查:

1、时输入 [24 时 ] --程序应提示错误;

2、时输入 [00 时 ] -- OK ;

3、分输入 [60 分 ] --程序应提示错误;

4、分输入 [59 分 ] -- OK ;

5、分输入 [00 分 ] -- OK ;

6、秒输入 [60 秒 ] --程序应提示错误;

7、秒输入 [59 秒 ] -- OK ;

8、秒输入 [00 秒 ] -- OK ;

格式检查:

1、不合法格式:12:30: 、 123000 ;

2、视具体项目而定是否合法:12:30 、 1:3:0 ;

异常值、特殊值:

1、输入汉字、字母、字符--程序应提示错误;

2、系统中所涉及时间是否取服务器时间;

版权声明:本文出自zll_618 的 51Testing软件测试博客:

软件测试用例设计方法---决策表

决策表,也叫判定表。在所有的功能性测试方法中,基于决策表的测试方法被认为是最严格的,因为决策表具有逻辑严格性。 在一些数据处理问题当中,某些操作的实施以来与多个逻辑条件的组合,既针对不同逻辑条件的组合之,分别执行不同的操作;决策表就是分析和表达多逻辑条件下执行不同操作情况的工具。 1 决策表通常由以下4部分组成: 条件桩(condition stub):列出了问题的所有条件。通常认为列出的条件的次序无关紧要。 动作桩(action stub):列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。 条件项(condition entry):列出针对它所列条件的取值,在所有可能情况下的真假值。作项(action entry):列出在条件项的各种取值情况下应该采取的动作。 2 决策表的生成: (1)确定规则的个数 ?有n个条件的决策表有2n个规则(每个条件取真、假值)。(2)列出所有的条件桩和动作桩 (3)填入条件项 (4)填入动作项,得到初始决策表 (5)简化决策表,合并相似规则

?若表中有两条以上规则具有相同的动作,并且在条件项之间存在极为相似的关系,便可以合并。 ?合并后的条件项用符号“-”表示,说明执行的动作与该条件的取值无关,称为“无关条件”。 举个例子↓↓

3 决策表的优缺点: 决策表最突出的优点是,能够将复杂的问题按照各种可能的情况全部列举出来,简明并避免遗漏。 ? 利用决策表能够设计出完整的测试用例集合。 ? 运用决策表设计测试用例可以将条件理解为输入,将动作理解为输出 4 何种情况下使用? ? 规格说明以决策表形式给出,或较容易转换为决策表;

软件测试标准和测试用例汇总

软件测试标准 前言 前一版的《软件测试标准》,在测试工作中发挥了很好的指导作用。本次修改在原标准基础上,提出了新的测试理念、工作方法、组织方式,使之更贴近实际工作,真正起到纲领的作用。 一、软件测试 1、软件测试的目的 软件测试是指为了度量和提高被测试对象的质量、对测试对象进行工程设计、使用和维护的与软件开发过程并发的生命周期过程。软件测试的目的为:验证软件产品的实现状态以及实现质量。 2、软件测试相关概念 2.1白盒测试 指基于程序结构的测试,测试目标是检查程序内部逻辑结构和逻辑路径,是代码级的测试。 2.2黑盒测试 基于程序功能的测试,根据输入输出的关系推断程序功能的正确性。 2.3测试用例 测试方案,包括数据输入和相应的期望输出。依据测试用例来执行具体操作。 2.4预防性测试 其原理为:只要测试在生命周期中进行得足够早,就能够提高待测软件的质量。 2.5测试风险分析 其目的为:确定测试对象、测试的优先级、测试的深度。 2.6软件测试模型 公司目前采用V模型,实现测试与软件开发的同步进行。 2.7等价类划分 将测试对象按某种约定划分为有限个组成部分,提高测试的有效性。 2.8边界值分析 分析测试对象的所有边界值及边界附近的临界值。 二、测试工作流程

三、开发—测试流程 说明: 1、新版本提供时间,由程序员与测试员按实际情况协调; 2、BUG审核的范围包括对BUG的抽查;对标注为不修改或待讨论BUG的管理; 3、软件涉及到功能性修改时,应该先提供修改设计说明,讨论通过后方可进行修改。 四、测试角色与职责 五、BUG主要参数 1、当前状态 记录BUG的状态,包括已修改、未修改、已验证。 2、严重程度 BUG严重程度分为四个级别

软件测试用例实例非常详细

1、兼容性测试在大多数生产环境中,客户机工作站、网络连接和数据库服务器的具体硬件驱动程客户机工作站可能会安装不同的软件例如,应用程序、规格会有所不同。序等而且在任何时候,都可能运行许多不同的软件组合,从而占用不同的资源。测试目的 操作系统系统软件外设应用软件结果配置说明 Window2000(S) 服务器 WindowXp Window2000(P) Window2003 TestCase_LinkWorks_WorkEvaluate 用例编号LinkWorks项目名称WorkEvaluate模块模块名称研发中心-质量管理部项目承担部门 用例作者2005-5-27 完成日期质量管理部本文档使用部门评审负责人审核日期 批准日期 注:本文档由测试组提交,审核由测试组负责人签字,由项目负责人批准。 历史版本: 备注起止日期参与者作者状态/版本 V1.1 1.1. 疲劳强度测试用例

强度测试也是性能测试是的一种,实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足,测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源(如数据库锁或网络带宽)而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。 测试目的 测试说明 用户并发设置添加10连续运行8前提条件小时,输出/响应输入测试需求/动作是否正常运行1 2小时功能4小时6小时8 小时 2小时功能1 4小时6小时 小时8 一、功能测试用例 此功能测试用例对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。主要测试技术方法为用户通过GUI(图形用户界面)与应用程序交互,对交互的输出或接受进行分析,以此来核实需求功能与实现功能是否一致。

测试用例实例—常见功能测试点

测试用例实例--常见功能测试点 笔者在网上看到了一篇文章,个人认为此文对于“软件常用功能测试点”总结的很好,特此摘录下来和大家一起分享。 1. 登陆、添加、删除、查询模块是我们经常遇到的,这些模块的测试点该如何考虑 1)登陆 ①用户名和密码都符合要求(格式上的要求) ②用户名和密码都不符合要求(格式上的要求) ③用户名符合要求,密码不符合要求(格式上的要求) ④密码符合要求,用户名不符合要求(格式上的要求) ⑤用户名或密码为空 ⑥数据库中不存在的用户名,不存在的密码 ⑦数据库中存在的用户名,错误的密码 ⑧数据库中不存在的用户名,存在的密码 ⑨输入的数据前存在空格 ⑩输入正确的用户名密码以后按[enter]是否能登陆 ------------------------------------------------------------------------------------------------------ 2) 添加 ①要添加的数据项均合理,检查数据库中是否添加了相应的数据 ②留出一个必填数据为空

③按照边界值等价类设计测试用例的原则设计其他输入项的测试用例 ④不符合要求的地方要有错误提示 ⑤是否支持table键 ⑥按enter是否能保存 ⑦若提示不能保存,也要察看数据库里是否多了一条数据 ------------------------------------------------------------------------------------------------------ 3) 删除 ①删除一个数据库中存在的数据,然后查看数据库中是否删除 ②删除一个数据库中并不存在的数据,看是否有错误提示,并且数据库中没有数据被删除 ③输入一个格式错误的数据,看是否有错误提示,并且数据库中没有数据被删除。 ④输入的正确数据前加空格,看是否能正确删除数据 ⑤什么也不输入 ⑥是否支持table键 ⑦是否支持enter键 ------------------------------------------------------------------------------------------------------ 4)查询 精确查询:

报表测试用例设计方法总结

报表测试用例设计方法总结 报表的测试主要分为以下几个方面:界面,安全性,准确性,展示速度(性能) 数据统计方面 1、报表统计数据的正确性; 2、报表统计数据的完整性; 3、报表统计数据的合法性;比如,统计金额字段需求要求有“$”等; 报表格式 1、表头字段表示的正确性; 2、表头字段表示的完整性; 3、表头字段表示的字体,字号,美观程度; 4、各统计字段的显示是否满足需求;比如:数据过长时要求折行还是缩小; 5、页眉和页角的表示; 报表的预览和印刷 1、预览中的显示完整性; 2、多页情况下,第2页的表头显示; 3、能否实现需求要求的特定印刷情况;(比如,印刷使用指定的模板) 4、预览后印刷; 5、不预览,直接印刷 6、需求规定各类打印机的测试; 数据准确性测试,带有报表测试的系统分为两类,一类是业务系统中,带有统计分析功能模块,该模块中包含分析报表,这个系统的主体是业务系统,报表是为**业务的而提供帮助的。 比如说,应年检统计报表,某月应交罚款车辆统计报表,这样的报表数据准确与否,可通过增加、删减、修改相关业务或相关业务的参数,查看统计报表数据变化,检查数据准确性。

另一类是系统只有统计功能,就是我说的数据仓库展现这类,它与业务系统分离,并且经过多层处理,比如数据仓库的数据,经过抽取,清洗,展现前会经过数据挖掘,数据再处理,有些字段在原始数据表中根本就没有。这样的数据准确性测试比较复杂,当然检查出数据错误,修改定位也是很不容易的。 从整个项目节约成本看,逐层测试效果是最好的。完全修改率也是最高的。 首先建立测试数据模型,模拟所有应用表,建立简单易跟踪的数据用例,底层的数据表测试,方法很原始,嘿嘿,通过SQL语句和手工计算,对数据进行比对。对系统中的报表数据准确性测试方法较为灵活, ①系统中报表重叠的进行比对 ②对子报表汇总与父报表比对,就是对月报表汇总与年报表比对,日报表汇总与月报表比对,这只是一个方面,可以从维度关系考虑,地域,行政级别、时间,个人等方面下手,进行汇总比对 ③这个方法如果延伸点呢,可以将报表间的业务逻辑关系作为比对依据。呵呵,这要看测试人员的需求了解深度个人能力了。插几句不想干的话,做测试工作总让我保持快乐状态,前两天我的一个同事说,公司里一直没有人喜欢做测试工作,这个工作太枯燥。嘿嘿,我当时就说我做了这么多年的测试工作从来没有感觉到枯燥。重复性工作不代表枯燥,编程其实不也是重复嘛,人每天谁不重复昨天的事啊,吃饭,吃这个动作重复一生,有谁觉得麻烦枯燥啦? ④使用SQL和手工计算进行比对。以上是差错方式,接下来讲一下查什么错?哪些地方容易出错 ● 原始表使用错误:因为表比较多,又加上没有统一的数据关系对应表,很容易表使用错误,当然这应该是单元测试检查出来的错误。 ● 数据处理逻辑错误:这一点容易因为测试人员和开发人员对需求理解有偏差造成争执,所以在需求评审时,对数据处理规则用表达式或伪代码表示清楚。还有就是程序员失误,逻辑编写有偏差,边界值、特殊情况处理不当。 ● 数据权限:不同用户对数据有着不同的查看权限。这关系到数据的安全性。 ● 数据误差:数据的保留位数,数据是否是处理计算是否是最后一次计算使用了位数保留和四舍五入。 ● 由于字典表,数据错误,而造成的数据错误,如,根据性别统计,购买量,表中的男女颠倒,或者没有考虑性别缺失项,用了if else,这样就是把表中缺失该项内容的算成了

功能测试用例的设计

功能测试用例的设计 LG GROUP system office room 【LGA16H-LGYY-LGUA8Q8-LGA162】

一、实验目的 1.用因果图法分析原因结果,并决策表设计测试用例。 2.使用场景法设计测试用例。 二、实验内容 1. 将三角形问题的可能结果扩展为:一般三角形、等腰三角形、等边三角形、直角三角形、等腰直角三角形和非三角形,考虑用因果图法设计测试用例,给出完整步骤。 2. 有一个在线购物的实例,用户进入一个在线购物网站进行购物,选购物品后,进行在线购买,这时需要使用帐号密码登录,登录成功后,进行付钱交易,交易成功后,生成订购单,完成整个购物过程。使用场景法设计上述问题的测试用例。 三、实验环境 Windows XP系统 四、实验步骤和结果 1. 将三角形问题的可能结果扩展为:一般三角形、等腰三角形、等边三角形、直角三角形、等腰直角三角形和非三角形,用因果图法设计测试用例,给出完整步骤。具体如下: 1)输入的三边分别为a,b,c(斜边) 且a

2. 行在线购买,这时需要使用帐号密码登录,登录成功后,进行付钱交易,交易成功后,生成订购单,完成整个购物过程。使用场景法设计上述问题的测试用例。

(注:在下面的矩阵中,V(有效)用于表明这个条件必须是 VALID(有效的)才可执行基本流,而 I(无效)用于表明这种条件下将激活所需备选流,“n/a”(不适用)表 对生成的所有测试用例重新复审,去掉多余的测试用例,测试用例确定后,对每一个测

五、实验结果和讨论 成功使用因果图法、场景法设计了测试用例。 六、总结 1.因果图法的定义是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件的各种组合情况。 2.在事件触发机制中场景法用得最多。在测试一个软件的时候,先确定基本流也就是测试流程中软件功能按照正确的事件流实现的一条正确流程,接着去确定备选流也就是那些出现故障或缺陷的过程,用备选流加以标注。然后可以采用矩阵或决策表来确定和管理测试用例。

软件测试用例实例非常详细汇总

1、兼容性测试 在大多数生产环境中,客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如,应用程序、驱动程序等而且在任何时候,都可能运行许多不同的软件组合,从而占用不同的资源。测试目的 配置说明操作系统系统软件外设应用软件结果 服务器Window2000(S) WindowXp Window2000(P) Window2003 用例编号TestCase_LinkWorks_WorkEvaluate 项目名称LinkWorks 模块名称WorkEvaluate模块 项目承担部门研发中心-质量管理部 用例作者 完成日期2005-5-27 本文档使用部门质量管理部 评审负责人 审核日期 批准日期 注:本文档由测试组提交,审核由测试组负责人签字,由项目负责人批准。历史版本: 版本/状态作者参与者起止日期备注

1.1. 疲劳强度测试用例 强度测试也是性能测试是的一种,实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足,测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源(如数据库锁或网络带宽)而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。 测试目的 测试说明 前提条件连续运行8小时,设置添加10用户并发 功能1 2小时 4小时 6小时 8小时 功能1 2小时 4小时 6小时 8小时 一、功能测试用例 此功能测试用例对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。主要测试技术方法为用户通过GUI(图形用户界面)与应用程序交互,对交互的输出或接受进行分析,以此来核实需求功能与实现功能是否一致。

[方案]编写软件测试用例文档的例子

[方案]编写软件测试用例文档的例子TestCase_LinkWorks_WorkEvaluate 用例编号 LinkWorks 项目名称 WorkEvaluate模块模块名称 研发中心-质量管理部项目承担部门 用例作者 2005-5-27 完成日期 质量管理部本文档使用部门 评审负责人 审核日期 批准日期 注:本文档由测试组提交~审核由测试组负责人签字~由项目负责人批准。 历史版本: 版本/状态作者参与者起止日期备注 V1.1 一、功能测试用例 此功能测试用例对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。主要测试技术方法为用户通过GUI(图形用户界面)与应用程序交互,对交互的输出或接受进行分析,以此来核实需求功能与实现功能是否一致。 项目名称用例标识 LinkWorks_ WorkEvaluate_02 MIIP 陈谦模块名称开发人员 WorkEvaluate 参考信息工作考核系统界面设计(2005_03_28).vsd 用例作者

设计日期测试人员高珍珍测试类型 2014-8-25 黑盒测试日期测试方法 用例描述 前置条件 编号权限测试项测试描述/输入/操作期望结果真实备注 (并列类别结果 关系) 无列导航栏导航浏览\点击导航连接详细正确导航页面所 00001 表测试在位置 页添加删除修添加修改删除按钮是否不可用 00002 面改按钮可用 接受、汇报按1) 不是自己负责的数据不能 钮未考核之前能否接受 \汇报 2) 属于自己负责的未接能 受之前时候是否可以 接受 00003 3) 属于自己负责的数据能 接受后但未考核能否 可以汇报 4) 接受后的数据没有汇不能 报但考核了,是否仍 可以汇报 考核审核按这俩按钮是否可用这两按钮为置灰,不 00004 钮可用 二级联动下功能下拉列表选择 1)默认为“本月由我

软件测试用例设计--场景分析方法

·软件测试用例设计--场景分析方法 方法简介 现在的软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中,可以比较生动地描绘出事件触发时的情景,有利于测试设计者设计测试用例,同时使测试用例更容易理解和执行。 基本流和备选流:如下图所示,图中经过用例的每条路径都用基本流和备选流来表示,直黑线表示基本流,是经过用例的最简单的路径。备选流用不同的色彩表示,一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中(如备选流1和3);也可能起源于另一个备选流(如备选流2),或者终止用例而不再重新加入到某个流(如备选流2和4)。 二.实战演习 1. 例子描述 下图所示是ATM例子的流程示意图。

表3-8 场景设计 注:为方便起见,备选流3和6(场景3和7)内的循环以及循环组合未纳入上表。 3.用例设计 对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式,其中各行代表各个测试用例,而各 列则代表测试用例的信息。本示例中,对于每个测试用例,存在一个测试用例

ID、条件(或说明)、测试用例中涉及的所有数据元素(作为输入或已经存在于数据库中)以及预期结果。 表3-9 测试用例表 4.数据设计 一旦确定了所有的测试用例,则应对这些用例进行复审和验证以确保其准确且适度,并取消多余或等效的测试用例。

测试用例一经认可,就可以确定实际数据值(在测试用例实施矩阵中)并且设定测试数据,如表3-10所示。 表3-10 测试用例表

通用测试用例模板

通用软件测试用例模板

用例说明 一、用例编号:每个用例唯一的标识 二、用例类型:用例的优先级(根据BUG的等级划分、用户使用的主次功能划分、根据流程划分如基本流或备选流)。 三、用例名称:填写用例的名称,如删除对象,添加内容,进行查询等。 四、模块名称:该用例属于哪个主要模块 五、测试环境: 硬件环境: 列出为测试本软件所使用硬件的配置,如: a.处理机的型号、内存容量; b.所要求的外存储器、媒体、记录格式、设备的型号和台数、联机/脱机; c.I/O设备(联机/脱机?); d.数据传输设备和转换设备的型号、台数。 软件环境: 说明为测试本软件所使用的软件,如: a.操作系统的名称、版本号; b.开发工具名称和版本号; c.数据库管理系统的名称和版本号; d.使用什么测试软件 e.其他支持软件。 六、测试目标:明确测试后所要实现的基本功能及结果,简要强调下面所有子功能可实现的功能和方法,使测试人员了解测试的意图。写出预期要达到的最好状态。 七、用户需求:写出测试模块所要达到的基本用户需要或者用户所需要的完整功能描述 八、前置条件: 描述该操作的前提条件。如:前面删除的对象有(废弃的对象、被引用对象、处在流程中的对象等)各种情况,该处可以描述其中一种。。 九、后置条件: 描述该操作的先关后续链接 十、特殊说明:用户或者开发者有特殊需求或注意事项,需添加在此项。 十一、用例的测试过程 1步骤:用例中需要测试进行的步骤,如1。 2测试内容:测试内容, 3测试预期结果:未测试前合理的正确的结果。 4操作描述:如:点击“高级查询”进入高级查询的页面,键入“姓名”。 5测试输入数据:如果此处输入姓名或其中几个字如“欧阳菲菲”或“欧阳”,均可记录。 6测试结果:记录输出的结果。正确或者错误均记录。对于一个测试完整功能点都会有一个对应的期望的正确结果。该结果可能是一个输出的数据值,也可能是一个 显示效果结果 7测试完成后功能描述 测试无误后对该子项功能模块的整体详细描述。

软件测试经典案例

软件测试-测试用例的经典例子 一、等价类划分 问:某程序规定:"输入三个整数 a、 b、 c分别作为三边的边长构成三角形。通过程序判定所构成的三角形的类型,当此三角形为一般三角形、等腰三角形及等边三角形时,分别作计算… "。用等价类划分方法为该程序进行测试用例设计。(三角形问题的复杂之处在于输入与输出之间的关系比较复杂。) 解: 分析题目中给出和隐含的对输入条件的要求: (1)整数 (2)三个数 (3)非零数 (4)正数 (5)两边之和大于第三边 (6)等腰 (7)等边 如果 a、 b 、 c满足条件( 1 ) ~ ( 4 ),则输出下列四种情况之一: 1)如果不满足条件(5),则程序输出为 " 非三角形 " 。 2)如果三条边相等即满足条件(7),则程序输出为 " 等边三角形 " 。 3)如果只有两条边相等、即满足条件(6),则程序输出为 " 等腰三角形 " 。

4)如果三条边都不相等,则程序输出为 " 一般三角形 " 。列出等价类表并编号

覆盖有效等价类的测试用例: a b c覆盖等价类号码 3 4 5(1)--(7) 4 4 5(1)--(7),(8) 4 5 5(1)--(7),(9) 5 4 5(1)--(7),(10) 4 4 4(1)--(7),(11)覆盖无效等价类的测试用例: 二、边界值分析法 NextDate函数的边界值分析测试用例

在NextDate函数中,隐含规定了变量mouth和变量day的取值范围为1≤mouth≤12和1≤day≤31,并设定变量year的取值范围为 1912≤year≤2050 。

三、错误推测法 测试一个对线性表(比如数组)进行排序的程序,可推测列出以下几项需要特别测试的情况: I.输入的线性表为空表; II.表中只含有一个元素; III.输入表中所有元素已排好序; IV.输入表已按逆序排好; V.输入表中部分或全部元素相同。 四、因果图法 有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下:若投入5角钱或1元钱的硬币,押下〖橙汁〗或〖啤酒〗的按钮,则相应的饮料就送出来。若售货机没有零钱找,则一个显示〖零

软件测试之测试用例设计

软件测试之测试用例设计 软件和其他工程产品的测试设计与产品本身的设计一样具有挑战性,然而由于已经讨论过的一些原因,软件工程师经常将测试作为一种事后的措施,开发一些“感觉上正确”但是缺乏完整保证的测试用例。再回头看看测试目标,我们必须设计出最可能发现最多数量的错误、并耗费最少时间和最小代价的测试。 在过去的20年,出现了大量的测试用例设计方法,为开发人员进行测试提供了系统的方法。更重要的是,方法提供了一种有助于确保完全测试的机制,并提供了揭示软件错误的最高可能性。 能够采用以下两种方法之一对任何工程化产品(以及大多数其他东西)进行测试: (1)若了解产品的特定功能,则构造测试,以证实各功能完全可执行,同时在各功能中寻找错误; (2)若了解产品的内部构造,则构造测试,以确保“所有齿轮吻合”,即内部操作依据规约执行,而且所有的内部构件被充分利用。第一种测试方法被称为黑盒测试,第二种则被称为白盒测试。 如果考虑计算机软件,黑盒测试指在软件界面上进行的测试,虽然设计黑盒测试是为了发现错误,它们却被用来证实软件功能的可操作性;证实能很好地接收输入,并正确地产生输出;以及证实对外部信息完整性(例如:数据文件)的保持。黑盒测试检验系统的一些基本特征,很少涉及软件的内部逻辑结构。 软件的白盒测试依赖对程序细节的严密检验,提供运用特定条件和/与循环集的测试用例,对软件的逻辑路径进行测试,在不同的点检验“程序的状态”以判定预期状态或待验证状态与真实状态是否相符。

一眼看去,可能认为全面的白盒测试将产生“百分之百正确的程序”,需要我们做的只是定义所有的逻辑路径、开发相应的测试用例,并评估结果,简而言之,详尽地生成用例以测试程序逻辑。不幸的是,穷举测试带来了必然的计算问题,即使是很小的程序,可能的逻辑路径数量也非常大,例如,考虑 100行C语言程序,在一些基本的数据声明之后,程序包含两个嵌套循环,根据输入的条件分别执行1到20次,在内部循环中,需要四个if-then-else结构,该程序中大约有1014条可能路径! 为了正确表达这个数值,我们假设开发了一个有魔力的测试处理器(“有魔力”是因为不存在这样的处理器)进行穷举测试。该处理器能在一毫秒内开发一个测试用例、进行运行并评估结果,如果每天运行24小时,每年运行365天,则需要3170年的时间来测试这个程序。不可否认,这将导致大多数开发进度表的混乱,对大型软件系统不可能进行穷举测试。 然而,白盒测试不应该被抛弃,可选择有限数量的重要逻辑路径进行测试,检测重要数据结构的有效性,可以综合黑盒测试和白盒测试的属性提供一种方法,以验证软件界面,并有选择地保证软件内部工作的正确性。

如何设计和执行测试用例

如何设计和执行测试用例测试需求收集完毕后,开始测试设计。 测试用例是什么?测试用例就是一个文档,描述输入、动作、或者时间和一个期望的结果,其目的是确定应用程序的某个特性是否正常的工作。设计测试用例需要考虑以下问题: 测试用例的基本格式: 软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果,下面逐一介绍。 用例编号:测试用例的编号有一定的规则,比如系统测试用例的编号这样定义规则: PROJECT1-ST-001 ,命名规则是项目名称+测试阶段类型(系统测试阶段)+编号。定义测试用例编号,便于查找测试用例,便于测试用例的跟踪。 测试标题:对测试用例的描述,测试用例标题应该清楚表达测试用例的用途。比如“测试用户登录时输入错误密码时,软件的响应情况”。 重要级别:定义测试用例的优先级别,可以笼统的分为“高”和“低”两个级别。一般来说,如果软件需求的优先级为“高”,那么针对该需求的测试用例优先级也为“高” ;反之亦然, 测试输入:提供测试执行中的各种输入条件。根据需求中的输入条件,确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性,如果软件需求中没有很好的定义需求的输入,那么测试用例设计中会遇到很大的障碍。 操作步骤:提供测试执行过程的步骤。对于复杂的测试用例,测试用

例的输入需要分为几个步骤完成,这部分内容在操作步骤中详细列出。 预期结果:提供测试执行的预期结果,预期结果应该根据软件需求中的输出得出。如果在实际测试过程中,得到的实际测试结果与预期结果不符,那么测试不通过;反之则测试通过。 软件测试用例的设计主要从上述 6 个域考虑,结合相应的软件需求文档,在掌握一定测试用例设计方法的基础上,可以设计出比较全面、合理的测试用例。具体的测试用例设计方法可以参见相关的测试书籍,白盒测试方法和黑盒测试方法在绝大多数的软件测试书籍中都有详细的介绍。 一般来说,每个软件公司的项目可以分为固定的几大类。可以按业务类型划分,比如 ERP 软件、产品数据管理软件、通信软件、地理信息系统软件等等;可以按软件结构来划分,比如 B/S 架构的软件、 C/S 架构的软件、嵌入式软件等等。参考同类别软件的测试用例,会有很大的借鉴意义。如果,公司中有同类别的软件系统,千万别忘记把相关的测试用例拿来参考。如果,系统非常接近,甚至经过对测试用例简单修改就可以应用到当前被测试的软件。“拿来主义”可以极大的开阔测试用例设计思路,也可以节省大量的测试用例设计时间。 加强测试用例的评审: 测试用例设计完毕后,最好能够增加评审过程。 同行评审是 CMM3 级的一个 KPA ,如果因为公司没有通过 CMM3 级,就不开展同行评审是不恰当的。测试用例应该由产品相关的软件测试人员和软件开发人员评审,提交评审意见,然后根据评审意见更新测试用例。如果认真操作这个环节,测试用例中的很多问题都会暴露出来,比如用例设计错

软件测试用例实例(非常详细)汇总

软件测试用例实例(非常详细)汇总

1、兼容性测试 在大多数生产环境中,客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如,应用程序、驱动程序等而且在任何时候,都可能运行许多不同的软件组合,从而占用不同的资源。 测试 目的 配置说明操作系 统 系统 软件 外设应用软件结果 服务器Windo w2000( S) Windo wXp Windo w2000( P) Windo w2003 用例编号TestCase_LinkWorks_W orkEvaluate 项目名称LinkWorks

1.1.

1.2. 疲劳强度测试用例 强度测试也是性能测试是的一种,实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足,测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源(如数据库锁或网络带宽)而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。测试目的 测试说明 前提条件连续运行8小时,设置添加 10用户并发 测试需求输入/ 动作 输出/响应是否正常运行 功能1 2小时 4小时 6小时 8小时功能1 2小时 4小时 6小时

8小时 一、功能测试用例 此功能测试用例对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。主要测试技术方法为用户通过GUI (图形用户界面)与应用程序交互,对交互的输出或接受进行分析,以此来核实需求功能与实现功能是否一致。 用例标识LinkWorks_ WorkEvaluate _02 项目 名称 https://www.360docs.net/doc/9e8504618.html, 开发人员模块 名称 WorkEvaluate 用例参考工作考核系统界面设计

软件测试中如何编写单元测试用例(白盒测试)

软件测试中如何编写单元测试用例(白盒测试) 测试用例(T est Case)是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。 测试用例(T est Case)目前没有经典的定义。比较通常的说法是:指对一项特定的软件产品进行测试任务的描述,体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等,并形成文档。 不同类别的软件,测试用例是不同的。不同于诸如系统、工具、控制、游戏软件,管理软件的用户需求更加不统一,变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。 随着中国软件业的日益壮大和逐步走向成熟,软件测试也在不断发展。从最初的由软件编程人员兼职测试到软件公司组建独立专职测试部门。测试工作也从简单测试演变为包括:编制测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等多项内容的正规测试。测试方式则由单纯手工测试发展为手工、自动兼之,并有向第三方专业测试公司发展的趋势。 要使最终用户对软件感到满意,最有力的举措就是对最终用户的期望加以明确阐述,以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。然而,核实这些需求可能通过不同的方式并由不同的测试员来实施。例如,执行软件以便验证它的功能和性能,这项操作可能由某个测试员采用自动测试技术来实现;计算机系统的关机步骤可通过手工测试和观察来完成;不过,市场占有率和销售数据(以及产品需求),只能通过评测产品和竞争销售数据来完成。 既然可能无法(或不必负责)核实所有的需求,那么是否能为测试挑选最适合或最关键的需求则关系到项目的成败。选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果。 确定测试用例之所以很重要,原因有以下几方面。 测试用例构成了设计和制定测试过程的基础。测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流,因而,随着测试用例数量的增加,您对产品质量和测试流程也就越有信心。判断测试是否完全的一个主要评测方法是基于需求的覆盖,而这又是以确定、实施和/或执行的测试用例的数量为依据的。类似下面这样的说明:“95 % 的关键测试用例已得以执行和验证”,远比“我们已完成95 % 的测试”更有意义。测试工作量与测试用例的数量成比例。根据全面且细化的测试用例,可以更准确地估计测试周期各连续阶段的时间安排。测试设计和开发的类型以及所需的资源主要都受控于测试用例。测试用例通常根据它们所关联关系的测试类型或测试需求来分类,而且将随类型和需求进行相应地改变。最佳方案是为每个测试需求至少编制两个测试用例:·一个测试用例用于证明该需求已经满足,通常称作正面测试用例;·另一个测试用例反映某个无法接受、反常或意外的条件或数据,用于论证只有在所需条件下才能够满足该需求,这个测试用例称作负面测试用例。 前段时间公司进行有关测试的培训,集成测试,性能测试,压力测试说了很多。由于本人还处于Coder阶段,只是对单元测试有了些了解。写下来怕以后自己忘记了。都是些自己的看法,不一定准确,欢迎高手指教。 一、单元测试的概念 单元通俗的说就是指一个实现简单功能的函数。单元测试就是只用一组特定的输入(测试用

软件测试用例设计规范

软件测试用例设计规范Software Test Case Design Specification

版本历史 版权信息 本文件内容由XX集团信息技术部负责解释 本文件的版权属于XX集团 任何形式的散发都必须先得到XX集团信息技术部的许可 https://www.360docs.net/doc/9e8504618.html,/

【目录】 1目的 (4) 2范围 (4) 3名词定义 (4) 4工件 (4) 4.1 输入 (4) 4.2 输出 (5) 5规范内容 (5) 5.1 设计原则 (5) 5.1.1可执行性 (5) 5.1.2可维护性 (5) 5.1.3可代表性 (5) 5.1.4可判定性 (6) 5.2 必要元素 (6) 5.2.1用例包和用例对象名命 (6) 5.2.2测试目的 (6) 5.2.3测试优先级 (6) 5.2.4测试环境 (7) 5.2.5前提条件 (7) 5.2.6后置关联 (7) 5.2.7用例状态 (7) 5.3 综合策略 (7) 5.3.1必要的边界值分析 (7) 5.3.2必要的等价类划分 (8) 5.3.3必要的因果图方法 (8) 5.3.4必要的性能测试方法 (8) 5.3.5面向对象设计方法 (8) 5.4 设计活动 (8) 5.4.1分析和建立测试用例包 (8) 5.4.2分解并建立测试用例对象 (10) 5.4.3建立测试用例对象间关系 (11) 5.4.4设计测试用例 (12) 5.4.5测试实施 (14) 5.5 检查点 (17)

1目的 本规范的目的是为了明确软件测试用例的设计原则,活动和方法,提高软件测试用例的可读性、可执行、可维护性、覆盖程度、以及测试的灵活性,使软件测试用例真正能够指导测试的实施和执行,并成为评估测试结果的度量基准。 2范围 本规范适用于春秋信息技术部所有软件开发项目和产品集成测试和系统测试用例的设计。 3名词定义 4工件 4.1 输入

软件测试中UI测试及其测试用例设计

界面是软件与用户交互的最直接的层,界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作,起到向导的作用。同时界面如同人的面孔,具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉,相反由于界面设计的失败,让用户有挫败感,再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度还远远不够,直到最近网页制作的兴起,才受到专家的青睐。而且设计良好的界面由于需要具有艺术美的天赋而遭拒绝。 目前流行的界面风格有三种方式:多窗体、单窗体以及资源管理器风格,无论那种风格,以下规则是应该被重视的。 按钮名称应该易懂,用词准确,屏弃没楞两可的字眼,要与同一界面上的其他按钮易于区分,能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。 易用性细则: 1) 完成相同或相近功能的按钮用Frame框起来,常用按钮要支持快捷方式。 2) 完成同一功能或任务的元素放在集中位置,减少鼠标移动的距离。 3) 按功能将界面划分局域块,用Frame框括起来,并要有功能说明或标题。 4) 界面要支持键盘自动浏览按钮功能,即按Tab键的自动切换功能。 5) 界面上首先应输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。 6) 同一界面上的控件数最好不要超过10个,多于10个时可以考虑使用分页界面显示。 7)分页界面要支持在页面间的快捷切换,常用组合快捷键Ct r l+Tab 8) 默认按钮要支持Ent er及选操作,即按Ent er后自动执行默认按钮对应操作。 9) 可写控件检测到非法输入后应给出说明并能自动获得焦点。 10) Tab键的顺序与控件排列顺序要一直,目前流行总体从上到下,同时行间从左到右的方式。 11) 复选框和选项框按选择几率的高底而先后排列。 12) 复选框和选项框要有默认选项,并支持Tab选择。 13) 选项数相同时多用选项框而不用下拉列表框。 14) 界面空间较小时使用下拉框而不用选项框。 15) 选项数叫少时使用选项框,相反使用下拉列表框。

软件测试中十大负面测试用例

软件测试中十大负面测试用例 负面测试(Negative testing)是相对于正面测试(Positive testing)而言的。它们也是测试设计时的两个非常重要的划分。简单点说,正面测试就是测试系统是否完成了它应该完成的工作;而负面测试就是测试系统是否不执行它不应该完成的操作。形象一点,正面测试就象一个毕恭毕敬的小学生,老师叫我做什么,我就做什么;而负面测试就象一个调皮捣蛋的孩子,你叫我这样做,我偏不这样做,而且和你对着干。开发人员也是最讨厌修改此类bug的。 正面测试主要根据需求,功能说明书,设计文档等相关参考文档来执行测试,而负面测试则主要根据错误猜测,逆向思维来测试系统,一定程序上的的依赖测试人员的经验积累。 执行负面测试时,不单单要测试系统是否处理了用户的异常操作,还要检查系统对于这些异常操作是否给予了正确的错误提示。它是系统对用户进行继续正确操作的指引。 简言之负面测试的三部曲就是: 1、检查程序中的屏幕或页面是否给出了清晰且充分的提示或约束; 2、测试系统是否处理了用户的异常操作; 3、检查系统的错误提示是否清晰且充分。 以下是Steve Miller的《Top 10 Negative Test Cases》,概括性的提到了一些做负面测试时经常需要注意的测试。 负面测试用例被设计于用软件未意欲被使用的方式测试软件,它也应该是测试工作的一部分。以下就是在设计测试工作量时你应该考虑的十大负面测试用例。 1、植入的单引号。大多数基于SQL的数据库系统在用户存储包含一个单引号的信息时会出现问题,例如John's car。每一个可以接受文字数字型数据条目的屏幕都要试试输入包含一个或多个单引号的文本。 【补充】其实不只是单引号,基本上测试人员应该测试所有的特殊字符和空/空格(单纯的空格和文本前后的空格)。单引号,逗号,/,<,>(对于web的应用程序)都是很容易引发错误的。在开发早期测试组就可以建议开发组写一个通用的函数来处理这些特殊字符,然后在处理用户的输入时套用这个函数就可以避免此类错误了。 2、必需输入的数据条目。功能说明书上应该清楚的指出屏幕上必须输入数据条目的字段。测试屏幕上每一个被说明为必须输入的字段以保证它强制要求你在字段中输入数据。 【补充】对于强制输入的字段,在屏幕上最好有些标识以说明其为必须输入的字段。一般在字段前或后用红色的*号表示。测试时必须要检查有标识的字段是否和功能说明书或其他参考文档一致,错误信息提示是否正确,强制输入的字段是否真的必须输入。

手机软件系统测试用例设计举例

一、等价类分析法 等价类划分方法针对手机状态大致可以归几个大类: 1. 按键类(等价法):有效输入和无效输入(有效输入指UM和菜单指示;无效输入指测试菜单功能此时没有定义的按键和用户动作); 2. 外部中断类(等价法):常用、不常用及无效 2.1. 常用:来电和来消息(短信、彩信、push消息);掀合盖;侧键;耳机&FM;情景模式;电量不足 2.2. 不常用:充电;闹钟&记事本&关机时间&整点报时提示;Icon&动画显示;Icon &动画刷新;编辑界面&pop显示框输入为空或满;编辑界面&pop显示框状态输入法默认&字符编码默认;失效SIM卡;大容量等SIM卡兼容;排序;号码识别; 2.3. 无效:“资料读取中…”;“复制中…”;“请稍后再试” 3. 存储器类 3.1. 等价法分类:读或写;不读或不写。 3.2. 因果法分类:先SIM卡后手机;先手机后SIM卡;提示用户选择存储器(对比Nokia)。 3.3. 操作分类:读;写;新增;删除;复制(先删除后新增;先新增后删除) 4. 状态类:正确;错误;变更;用户设定变更 举例一,短消息发送功能: 英文:Default 7-bit alphabet (over 160 characters) 合法等价类:0~160 非法等价类::>160 The quick fox jumps over the lazy brown dog 中文:UCS-2 alphabet (over 70 characters)

合法等价类:0~70 非法等价类::>70 诺基亚(英文):Extended default 7-bit alphabet (over 140 Bytes),智慧短信,可以携带黑白图片。 合法等价类:0~140 非法等价类::>140 在写字板里面输入“联通”二字,保存后,再打开,即出现乱码。 举例二,单个通话实例的拨打与挂断 测试用例标识 测试阶段:系统测试 测试项 单个通话实例的拨打与挂断 测试项属性 A 参照规范 重要级别 高 测试原因 手机在待机状态下,确保手机能正常拨出电话 预置条件 1. 正常信号环境 2. IDLE状态 3. 默认原厂参数设定

相关文档
最新文档