常用测试用例总结

登录、添加、删除、查询模块是我们经常遇到的，这些模块的测试点该如何考虑？

1)登录

　　① 用户名和密码都符合要求(格式上的要求)

　　② 用户名和密码都不符合要求(格式上的要求)

　　③ 用户名符合要求，密码不符合要求(格式上的要求)

　　④ 密码符合要求，用户名不符合要求(格式上的要求)

　　⑤ 用户名或密码为空

　　⑥ 数据库中不存在的用户名，不存在的密码

　　⑦ 数据库中存在的用户名，错误的密码

　　⑧ 数据库中不存在的用户名，存在的密码

　　⑨ 输入的数据前存在空格

　　⑩ 输入正确的用户名密码以后按[enter]是否能登陆

2) 添加

　　① 要添加的数据项均合理，检查数据库中是否添加了相应的数据

　　② 留出一个必填数据为空

　　③ 按照边界值等价类设计测试用例的原则设计其他输入项的测试用例

　　④ 不符合要求的地方要有错误提示

　　⑤ 是否支持table键

　　⑥ 按enter是否能保存

　　⑦ 若提示不能保存，也要察看数据库里是否多了一条数据

3) 删除

　　① 删除一个数据库中存在的数据，然后查看数据库中是否删除

　　② 删除一个数据库中并不存在的数据，看书否有错误提示，并且数据库中没有数据被删除

　　③ 输入一个格式错误的数据，看是否有错误提示，并且数据库中没有数据被删除。

　　④ 输入的正确数据前加空格，看是否能正确删除数据

　　⑤ 什么也不输入

　　⑥ 是否支持tab键

　　⑦ 是否支持enter键

4)查询

• 精确查询：

　　① 输入的查询条件为数据库中存在的数据，看是否能正确地查出相应得数据

　　② 输入正确的查询条件以前加上空格，看是否能正确地查出相应的数据

　　③ 输入格式或范围不符合要求的数据，看是否有错误提示

　　④ 输入数据库中不存在的数据

　　⑤ 不输入任何数据

　　⑥ 是否支持table键

　　⑦ 是否支持enter键

• 模糊查询：

　　在精确查询的基础上加上以下一点:

　　输入一些字符，看是否能查出数据库中所有的相关信息

设计功能测试用例

文本框、按钮等控件测试

文本框的测试

　　如何对文本框进行测试

　　a，输入正常的字母或数字。

　　b，输入已存在的文件的名称;

　　c，输入超长字符。例如在“名称”框中输入超过允许边界个数的字符，假设最多255个字符，尝试输入 256个字符，检查程序能否正确处理;

　　d，输入默认值，空白，空格;

　　e，若只允许输入字母，尝试输入数字;反之;尝试输入字母;

　　f，利用复制，粘贴等操作强制输入程序不允许的输入数据;

　　g，输入特殊字符集，例如，NUL及 等;

　　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，无中英文混合.

3)菜单

　　进行测试时要注意

　　a，选择菜单是否可以正常工作，并与实际执行内容一致;

　　b，是否有错别字:

　　c，快捷键是否重复;

　　d，热键是否重复;

　　e，快捷键与热键操作是否有效

　　f，是否存在中英文混合

　　g，菜单要与语境相关，如，不同权限的用户登陆一个应用程序，不同级别的用户可以看到不同级别的菜单并使用不同级别的功能;

h，鼠标右键快捷菜单

4)特殊属性

　　1，安装界面应有公司介绍或产品介绍，有公司的图标

　　2，主界面及大多数界面最好有公司图标

　　3，选择"帮助"->"关于"命令，应 看见相关版权和产品信息

总结

个人在总结软件测试知识的这段时间发现，软件测试工作要做好，如何提高我们测试的效率，首先就是要找出软件中的常用功能测试点，如此文中上面中的内容，把共性的工作抽取后，个性的工作再逐个突破，工作会变得轻松起来。

第二部分

一、文本框为字符型
必填项非空校验：
　　1、必填项未输入－－程序应提示错误；
　　2、必填项只输入若干个空格，未输入其它字符－－程序应提示错误；

　字段唯一性校验：（不是所有字段都作此项校验，视实际项目情况而定）
　　1、新增时输入重复的字段值－－必须提示友好信息；
　　2、修改时输入重复的字段值－－必须提示友好信息；

　字段长度校验：
　　1、输入[最小字符数-1]－－程序应提示错误；
　　2、输入[最小字符数]－－OK；
　　3、输入[最小字符数+1]－－OK；
　　4、输入[最大字符数-1]－－OK；
　　5、输入[最大字符数]－－OK；
　　输入[最大字符数+1]－－程序应提示错误；
字段为特殊字符校验：
　　1、输入域如对某些字符禁止输入时，限制是否成功，提示信息是否友好 ；
　　2、中文、英文、空格，数字，字符，下划线、单引号 等所有特殊字符的组合 ；
　　3、所有特殊字符都必须进行测试
字段为特殊代码校验：
　　输入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－－程序应提示错误；
　　11、月输入[0月]－－程序应提示错误；
　　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、系统中所涉及时间是否取服务器时间；
页功能我们常碰到的一般有以下几个功能：
　　1、首页、上一页、下一页、尾页。
　　2、总页数，当前页数
　　3、指定跳转页
　　4、指定每页显示条数
　　当然，有一些是少于多少页，全部以数字的形式显示，多于多少页后，才出现下一页的控件。本文暂且用以上四点来做为通用的用例来设计吧。
对于“首页、上一页、下一页、尾页”。翻页链接或按钮的测试，主要要检查的测试点有：
　　1、有无数据时控件的显示情况
　　2、在首页时，首页和上一页是否能点击
　　3、在尾页时，下一页和尾页是否能点击
　　4、在非首页和非尾页时，四个按钮功能是否正确
　　5、翻页后，列表中的记录是否仍按照指定的排序列进行了排序
对于“总页数，当前页数总页数，当前页数”，主要要检查的测试点有：
　　1、总页数是否等于总的记录数/指定每页条数
　　2、当前页数是否正确
针对以上测试用例如下：
step 1: 列表无记录
　　expect: 1、四个翻页控件变灰不可点击
　　2、列表有相应的无数据信息提示
　　3、不可指定页数
　　4、不可指定跳转页
　　5、总页数显示为0
　　6、当前页数显示为0
step 2: 列表的记录数<=指定的每页显示条数
　　expect: 1、四个翻页控件变灰不可点击
　　2、总页数显示为1
　　3、当前页数显示为1
step 3: 列表的记录数>指定的每页显示条数
　　expect: 1、默认在首页，当前页数为1
　　2、列表的数据按照指定的排序列正确排序
　　3、记录数与数据库相符
　　4、总页数＝记录数/指定的每页显示条数
step 4: 列表的记录数>指定的每页显示条数，在首页
　　expect: 1、首页变灰不可点击
　　2、上一页变灰不可点击
　　3、下一页可点击，从（每页指定条数＋1）条记录开始显示，当前页数+1
　　4、尾页可点击，显示最后页的记录
step 5: 列表的记录数>指定的每页显示条数，在中间的某页
　　expect: 1、首页可点击，显示1到每页指定条数的记录
　　2、上一页可点击，显示上一页的记录
　　3、下一页可点击，从后一页的记录
　　4、尾页可点击，显示最后页的记录
　　5、列表的数据按照指定的排序列正确排序
　　6、当前页数为所在页
step 6:列表的记录数>指定的每页显示条数，在尾页
　　expect: 1、首页可点击，显示1到每页指定条数的记录
　　2、上一页可点击，显示上一页的记录
　　3、下一页变灰不可点击
　　4、尾页变灰不可点击
　　5、列表的数据按照指定的排序列正确排序
　　6、当前页数为最后一页的页数
对于“指定跳转页”，主要要检查的测试点有：
　　1、是否能正常跳转到指定的页数
　　2、输入的跳转页数非法时的处理
对于“指定每页显示条数”，主要要检查的测试点有：
　　1、是否有默认的指定每页显示条数
　　2、指定每页的条数后，列表显示的记录数，页数是否正确
　　3、输入的每页条数非法时的处理
针对以上测试用例如下：
step 7:输入每页显示条数为小于总记录的正整数
　　expect: 1、每页显示条数更新成指定的条数
　　2、超过指定的条数的记录分页显示
　　3、总页数更新成列表的记录数/每页显示条数
step 8:输入每页显示条数为0、负数、小数
　　expect: 1、提示“每页显示条数必须为大于1的整数”
　　2、提示后每页显示条数恢复为上次生效的条数
step 9:输入每页显示条数大于或等于总记录数的正整数时
　　expect: 1、四个翻页按钮变灰不可点击
　　2、总页数显示为1
　　3、当前页数显示为1
　step 10:输入每页显示条数长度超过数据库指定的长度<<>>
　　expect: 1、提示每页显示条数不能超过<<>>位
　　2、提示后每页显示条数恢复为上次生效的条数
step 11:输入每页显示条数为非数值、非法值时
　　expect: 1、提示每页显示条数必须为大于1的整数
　　2、提示后每页显示条数恢复为上次生效的条数
step 12:输入跳转的页数为存在的页数
　　expect: 1、正确跳转到指定的页数
　　step 13:输入跳转的页数不存在或非法值
　　expect: 1、跳转的页数值置为1，显示第一页的数据

 

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)：状态条的高度以放置五好字为宜，滚动条的宽度比状态条的略窄。
　　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：美观与协调性：
　　界面应该大小适合美学观点，感觉协调舒适，能在有效的范围内吸引用户的注意力。

5.美观与协调性细则：
　　1): 长宽接近黄金点比例，切忌长宽比例失调、或宽度超过长度。
　　2): 布局要合理，不宜过于密集，也不能过于空旷，合理的利用空间。
　　3): 按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置。
　　4): 按钮的大小要与界面的大小和空间要协调。
　　5): 避免空旷的界面上放置很大的按钮。
　　6)：放置完控件后界面不应有很大的空缺位置。
　　7): 字体的大小要与界面的大小比例协调， 通常使用的字体中宋体9-12较为美观，很少使用超过12号的字体。
　　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):公司的系列产品要保持一直的界面风格，如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致。

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)：在主界面载入完毕后自动卸出内存，让出所占用的WINDOWS系统资源。
　　3)：关闭所有窗体，系统退出后要释放所占的所有系统资源 ，除非是需要后台运行的系统。
　　4)：尽量防止对系统的独占使用。
　　1.输入验证 输入验证主要包括：数字输入验证、非法字符输入验证、输入长度验证、必填项验证和信息提示 1.数字输入验证：分别输入数字(正数、负数、零值、单精度、双精度)、字符串、空白值、空值、临界数值。不合法的输入，系统给出必要的判断提示信息
　　2.字符输入验证：分别输入单字节字符、双字节字符、大小写字符、特殊字符、空白值、空值。不合法的输入，系统给出必要的判断提示信息
　　3.日期、时间输入验证：分别输入任意字符、任意数字、非日期格式的数据、非正确日期(错误的闰年日期)、空值、空白值。不合法的输入，系统给出必要的判断提示信息。注：有些系统会不让输入当日以后或者以前的日期、时间；有些系统会通过JavaScript来自动填写日期时间，这时需要注意是否能否人工主观填写输入
　　4.多列表选择框：测试是否能否多选，列表框中的数据是否能否显示完全。当列表框的数据过多时，需要对数据有一定格式的排序
　　5.单列表下拉框：测试是否能否手工输入，下拉框中的数据是否能否显示完整。当下拉框的数据很多时，需要对数据有一定格式的排序。如果下拉框数据值过多时，下拉框可能会超出IE显示范围，此种情况不能够被接收
　　6.大文本输入框(textArea)：虽然它能够满足大数据量的输入，但最好能够显示地标明输入字符的长度限制，并且应该结合“字符输入验证”进行。需要注意的是，应该允许标点的存在
　　7.文件输入框输入验证：该输入框主要用做文件上传操作。在测试过程中，应该注意输入文件的扩展名。从测试角度来看，要求开发人员必须对扩展名进行输入限制，并且在适当的地方输入格式提示。当输入是空值等不合法的输入时，系统给出必要的判断提示信息。另外，对于上传的文件大小应该做限制，不宜太大
　　8.输入字符长度验证：输入字符的长度是否超过实际系统接收字符长度的能力。当输入超出长度时，系统给出必要的判断提示信息
　　9.必填项验证：输入不允许为空的时候，系统需要有提示用户输入信息功能
　　10.格式、规则输入验证：当输入需要一定的格式时，系统需要有提示用户输入信息功能。比如身份证号码可以输入18位或者15位，部分身份证最后一位为字母，身份证上生日与身份证号码有一定规则。

11.系统错误定位的输入验证：当输入存在问题时，被系统捕获到，此时页面上的光标能够定位到发生错误的输入框
　　12.单选框、多选框的输入验证：单选框需要依次验证单选框的值是否都有效；多选框需要依次验证多选框的值是否都有效 13.验证码验证：做验证码输入验证时，先结合“字符输入验证”进行测试，然后注意的地方是，当利用IE回退或者刷新时，显示的验证码应该和实际系统验证码一致。如果验证码以图片形式显示，但图片由于其他原因(如网络)不能看到或者显示不完整，系统应该允许进行重新获取，最好不要做整个页面刷新 2.操作验证(CZ) 该用例库主要针对页面操作
　　1.页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确
　　2.相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确
　　3.检查按钮的功能是否正确：如增、删、改、查等功能是否正确
　　4.重复提交表单：一条已经成功提交的记录，用IE回退后再提交，看看系统是否做了处理
　　5.多次IE回退：检查多次使用IE回退的情况，在有回退的地方，回退，回到原来页面，再回退，重复多次，看是否出错
　　6.快捷键检查：是否支持常用快捷键，如Ctrl+C、Ctrl+V、Backspace等，对一些不允许输入信息的字段，如选人、选日期对快捷方式是否也做了限制
　　7.回车键检查：在输入结束后直接回车键，看系统处理如何，能否报错
　　8.上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开，对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能否做到
　　9.其他验证：在页面上图片的大小不宜太大，需要第三方软件支持时，应该给出必要的信息，比如需要jre的支持，但用户机器还没有安装jre，那么此时在页面上应该有显著的标志来提醒用户进行安装
　　3.登录模块测试用例 该用例库主要针对登录模块。需要结合“访问控制验证(FWKZYZ)”用例库 1.登录名输入：进行“输入验证”。需要注意登录名是否区分大小写和空格
　　2.密码输入：进行“输入验证”
　　3.提交操作：结合“访问空值验证(FWKZYZ)”。当输入正确的登录名和密码后，该用户能够进入到指定的正确页面。当输入的登录名和密码有误时，系统限制其登录，并且给出适当的提示信息。当遇到错误时，应该进行“错误页面测试”
　　4.重设操作：当进行重设操作时，当前页面上所有输入项被清空
　　4.增加操作测试用例(ZJ) 该用例库主要针对增加操作
　　1.添加输入内容，进行“输入验证” 2.应该限制重复增加，具体操作：利用网络传输以及服务器的延迟，多次单击“增加”按钮，经常在数据库发现重复提交的数据 3.当增加成功或者失败后，应该有必要的信息提示 4.文件数据的增加：有些增加包含了数据库数据的增加，和一些文件的增加，此时的数据会保存在两个地方，所以测试时，需要对相关的数据做全面的验证 5.文件数据验证：进行“输入验证”值“文件输入框输入验证”。注意：当上传的文件为中文文件名时，上传到服务器后，可能会出现乱码现象。现在一般的做法是将原文件名替换成字母和数字的组合，以克服汉字文件名的弊端，另外，可以增加文件的安全性 5.删除操作测试用例(SC) 该用例库主要针对删除操作
　　1.选择需要删除的数据字段。有时候系统会根据ID来删除，有时候系统会根据名称来删除，测试的时候应该多注意，一般要求按照ID来删除，因为根据名称来删除，名称可能会存在重名问题 2.应该限制重复删除。具体操作：利用网络传输以及服务器的延迟，多次单击“删除”按钮，经常在数据库中发现重复提交的数据 3.当删除的数据还有文件时，西药去验证存在数据库中的数据，以及硬盘下的文件是否都被同时删除 4.当数据被删除成功或者失败后，要有响应的信息提示 5.进行“操作验证” 6.修改操作测试用例(XG) 该用例库主要针对修改操作
　　1.打开需要修改的数据页面，注意与增加页面相比，只能修改部分数值，例如关键字等是不能被修改的，并且二者数据应该是一致的 2.增加页面上的输入限制与修改页面的输入限制应该一致 3.修改成功或者失败后，应该有相应的信息提示 7.查询操作测试用例(CX) 该用例库主要针对查询操作
　　1.条件输入查询，先进行条件输入框的“输入验证” 2.条件组合查询，将多个条件进行组合查询，结果可以通过数据库验证。需要注意的是，整个数据查询和条件查询数据结果条数要一致，另外，如果遇到某天的查询时间段，有的数据库认为一天不包括零点零分，有的数据库认为包括 3.所有查询结果，必须进行一定顺序的排列，可以按照ID或按照名称来排列 4.当查询成功或者失败后，系统应给出必要的信息提示
　　8.翻页操作测试用例(FY) 该用例库主要针对翻页操作
　　1.当数据量很大的时候，需要进行分页显示，每页显示的行数最好不要超过20行，每页列表上最好有序号标识，行与行之间颜色要有一定区分，这样有利于用户的查找
　　2.翻页按钮应该包括：首页、前一页、后一页、尾页、当前X页、共X页，这些常用按钮和显示，并且按钮都能正常翻页
　　3.翻页按钮的每页显示的数据要准确，确保没有查不出来的数据，最好的做法就是和数据库结合起来验证
　　4.页面太多，翻页数据不能全部显示时，系统应该有完善的应对机制，比如值显示当前页的前三页和该页的后三页的页数码 5.当翻到某页时，系统应该有明显的标识，标出该页面所处的页码
　　9.错误页面测试(CW) 错误页面是在遇到系统异常的情况产生的友好界面
　　1.当系统遇到致命错误时，不能将服务器的调试信息出现在页面上，因为这样做会带来不安全，应该给出一个合适的提示信息
　　2.由于系统繁忙，无法及时给出正确信息时，系统可以给出友好的错误页面，如：“请用户稍后再试”等提示信息。

第三部分

测试用例编写规范

目录：

一.测试用例包含的元素

二.测试用例编写原则及规范

1. 用例模块划分规范
2. 用例颗粒度划分规范
3. 用例编写要求规范
4. 用例维护规范

三.测试用例编号规则

---

一.测试用例包含的元素

1. 序号：就是按顺序下去的。
2. 模块：该功能点具体属于哪个模块的，如：注册/登录模块
3. 编号：对每个用例进行编号，方便后期跟进。建议编号设计的有点规则，方便快速定位查找。如：A0001。其中A表示注册/登录模块。00表示账号登录，01 表示账号密码登录下的第一个测试用例。
4. 功能点：具体指某个功能，如：账号登录、首页、发布等。
5. 子功能点：具体指功能点，如：账号密码登录、手机验证码登录、邮箱登录、第三方授权登录等。
6. 用例名称：具体测试用例的名称。如：输入账号、输入密码、密码不合规等等。
7. 前置条件：指要达到预期测试结果，需要满足哪些条件才能达到。
8. 操作步骤：指要达到预期测试结果，需要按这些步骤来。最好说明在什么页面，点击或操作什么内容，输入什么内容。
9. 预期结果：说明按照前面写的应该呈现出怎样的结果。
10. 测试结果：如果符合预期结果，直接填写正常或OK，如果不符合，则说明不符合或NO，
11. 结果描述：如果正常，可以不用填写，如果不符合预期结果，则说明哪里不符合。
12. 测试人员：填写测试人的名字，方便后期跟踪BUG。
13. 测试日期：填写测试的时间，方便后期查询。
14. BUGID：跟测试编号一样，自己设定ID规则，方便快速查询。
15. BUG负责人：此处应该由技术那边填写，具体落实到某个人身上，才能更好的解决到问题。

二.测试用例编写原则及规范

• 统一测试用例编写的规范，为测试设计人员提供测试用例编写的指导，提高编写的测试用例的可读性，可执行性、合理性。
• 测试用例，不仅仅用于QA阅读和执行。它们也可能会被开发、PD、PM等阅读审查或执行；也更可能被其他测试人员或者新员工作为业务学习、测试执行的参照。
• 编写测试用例的最终目标是：一个对于产品毫无所知的人员，也能够快速的熟悉用例并执行用例。

 

1.用例模块划分规范

• 产品、功能点同一层级的结构按同一个纬度来划分。如应用、同等级产品、同等级功能点等；
• 产品是指产品线下大的业务模块。如交易购物车、交易下单；
• 功能点指业务模块下的子功能点，是最小功能点叶子节点。如01 功能_02 购物车展示_01 顶部及导航；
• 功能点目前无法再细分层级，后续会扩展功能点层次，在此之前，允许使用功能点名进行分层用例划分。
• 产品、功能点划分不允许包含冒烟、回归、自动化这类以测试阶段或测试方法的命名的名称；

 

2.用例颗粒度划分规范

用例颗粒度原则：测试用例是执行的最小实体。用例划分基本原则是以最小功能模块来划分，为保障用例的可执行性、覆盖度，规范编写用例的粒度要求如下：

• 一个功能正常流程，编写一个测试用例；
• 一个功能中多个异常流程，应分开编写多个测试用例；
• 同一功能不同入口，可合并编写一个测试用例；
• 同一功能不同数据准备，应分开编写多个测试用例；
• 同一个功能用例的自动化用例和功能用例要匹配，若自动化用例不能完全覆盖功能用例，自动化用例和功能用例拆分两个互补测试用例；

 

3.用例编写要求规范

• 具有清晰名称、前置条件、操作步骤、期望结果；
• 可被他人理解的；
• 可被他人执行的；

具体分项要求如下：

用例名称

• 常用的结构“主、谓、宾”；
• 名称简洁易懂，不要包括具体操作步骤；

 

前置条件

• 执行用例测试步骤前需要做的所有必备条件，原则上所有用例都有前置条件；
• 不可将其他用例作为前置条件，前置条件需要语言描述；
• 完整清楚，包括入口、帐号类型、账号权限、数据准备等，具体要求如下：

1. 入口：覆盖所有功能入口，包含URL直接访问；
2. 账号类型和权限：覆盖全部账号类型，注意业务权限控制，比如子账号权限
3. 数据准备：数据准备完整正确，覆盖到线上环境的所有情况；标识出业务流程处于的条件，写明数据库表字段值；对于复杂的数据准备，写清具体SQL

 

操作步骤

• 操作步骤描述清晰。如：在什么页面，点击什么链接或按钮；页面入口、链接、按钮名称都要写清楚；
• 操作和结果是一一对应的，但操作中不要包含结果的检查；
• 用例描述中不允许存在连词、介词，比如：而且，和，还（这种情况可以拆分为多个点）；
• 用例描述中不允许出现假设性词汇，比如：假如，或许，可能，…的时候等；
• 用例描述中不允许出现二义性语句；

 

预期结果

• 原则上每个用例必需要有预期结果，结果不能为空；
• 结果中只能包含结果，不能有步骤；
• 一个结果有多个检查点时，确保检查点完整：

1. 结果包含需要验证的所有结果输出，如页面检查、存储检查、消息检查等；
2. 结果涉及页面，需明确页面提示结果、数据变化；
3. 结果涉及存储：需明确关键值变化、数据库具体的表和关键字字段值变化；
4. 结果涉及消息：需明确关键查看内容；
5. 结果对应不同输入数据有差别时需分别对应描述清晰；

 

4.用例维护规范

• 新项目需求变更，应及时对测试用例进行修改；
• 维护期项目，可根据项目组情况周期对用例进行维护；
• 所有发现的bug和故障，基于测试用例无法发现，需转化为测试用例。

三.测试用例编号规则

1. 目的：好的测试用例编号，可以更好的去了解此项用例所针对的模块，也有助于记忆和新用例的增加。
2. 规则：测试用例编号采用“版本+细类+编号”的形式。
3. 备注：其中“版本”为设计此测试用例的软件版本。
4. “细类”为小模块中的汉字头一个字母，以最多5个字母为标准。
5. “编号”为BUG用例的编号，以4位为标准，依次递增。
6. 例如：引导系统V2.01版本中，候车点设置，用例编号可以书写为：

2.01_HCDSZ_0001