sdlkfj1
我是在群里提过这个问题，用例写完了，但是觉得问题好像还是存在。
用例和数据分开？怎么分开？请赐教～谢谢～
不好意思，对你那个问题有点误解。
我觉得11034说的对，看公司对用例的要求严不严了。
把用例分两部分，一部分是相同输入的用例，说明那些地方用得上，后面再分别写不同地方的用例
我没觉得有不完整的感觉。sdlkfj3
[ 本帖最后由 boliping 于 2006-12-4 14:29 编辑 ] 原帖由 云淡风轻 于 2006-12-3 16:04 发表
再问sdlkfj1
1.如果是下拉框，是不是每个选项都要写？还是只是随机选一种就可以了？
2.我自己觉得每个输入框都是一样的用例感觉不太好，可是如果不copy的话好像又显得用例不全，有没有好一点的方法？比 ...
1.随机选择.补充一点:如果你感觉这样的测试不充分,你可以补充一些等级较低的用例进行充分覆盖,最后执行的时候有时间就执行,没时间就不执行.
2.对于第2个问题我想问清楚,你是说 重复的用例 是否要拷贝;还是说一个用例中出现了重复的输入,那个输入是否要拷贝? 或者说是,对于同一功能点,写出的几个用例,用例中同一个输入项 是否要拷贝?
对于功能 数据分开,如果是用自动化工具写的脚本的话,是可以实现的,比如QTP中,你可以将测试数据放在数据表或数据文件中.但是像手工测试的用例,我不是很了解 怎样实现功能 数据分开. 还是说,你的意思是用例中不写具体测试数据,用"变量"代替.再在数据文件中定义"变量"的内容.执行的时候再把内容带入用例中. 比如说用例中 输入项 "姓名" 输入值为:USERNAME. 而数据文件中定义了 USERNAME:一二三四五六七.不知道是不是这样理解.
如果那位对功能 数据分开有研究,希望解答一下 原帖由 boliping 于 2006-12-4 14:27 发表
不好意思，对你那个问题有点误解。
我觉得11034说的对，看公司对用例的要求严不严了。
把用例分两部分，一部分是相同输入的用例，说明那些地方用得上，后面再分别写不同地方的用例
我没觉得有不完整的感觉 ...
公司倒是不严格，但是我自己想尽量规范点、写全点。sdlkfj1
明白你的意思了～谢谢～我觉得这样比较好。 原帖由 11034 于 2006-12-4 14:46 发表
1.随机选择.补充一点:如果你感觉这样的测试不充分,你可以补充一些等级较低的用例进行充分覆盖,最后执行的时候有时间就执行,没时间就不执行.
2.对于第2个问题我想问清楚,你是说 重复的用例 是否要拷贝;还是说一个用例中出现了重复的输入,那个输入是否要拷贝? 或者说是,对于同一功能点,写出的几个用例,用例中同一个输入项 是否要拷贝?
对于功能数据分开,如果是用自动化工具写的脚本的话,是可以实现的,比如QTP中,你可以将测试数据放在数据表或数据文件中.但是像手工测试的用例,我不是很了解怎样实现功能 数据分开. 还是说,你的意思是用例中不写具体测试数据,用"变量"代替.再在数据文件中定义"变量"的内容.执行的时候再把内容带入用例中. 比如说用例中输入项 "姓名" 输入值为:USERNAME. 而数据文件中定义了 USERNAME:一二三四五六七.不知道是不是这样理解.
1.不太明白sdlkfj1什么样的用例等级算比较低的？怎么才算充分覆盖？
2.手工测试用例，是对系统中同样功能的测试用例的copy。
3Q~~~~~~ 感觉测试用例不需要精确到具体数据，那工作量不是一般的大啊 理论上,测试用例是必须做到 用例编号要规范 测试目的要明确 用例等级要严格 预置条件要清楚 输入数据要精确,测试步骤要完整,预期输出要明确.现在有些公司会有一些测试用例输出到其他公司的,其他公司组织人员进行执行.像这种用例就必须做到规范.当然不是说让我们平时写用例不要规范.个人认为测试本身就是一份要求很严谨的工作,只要有时间,尽量细致点 不会错的.
RE:云淡风轻
1.测试用例的等级划各个公司好象不一致.这里给个参考吧.(是从一个前辈的文章摘下来的)
1 –小版本确认测试（Build Verification Tests (BVTs)：也叫做“冒烟测试”，一组你想先运行的以确定这个给出的小版本是否可以测试的测试用例。如果你不能访问每一个功能区域或执行其他测试用例依赖的基本操作，那么在执行这个优先的测试用例之前，试图做其他任何的测试都是没有意义的，因为他们大多数肯定要失败。
2 – 高（Highs）：最常执行以保证功能性是稳定的，目标的行为和能力可以正常的工作，和重要的错误和边界被测试的测试用例的集合。
3 – 中（Mediums）：这是使给出的功能区域或功能变得更详细，检查功能的多数方面包括边界，错误和配置测试的测试用例
4 – 低（Lows）：这是通常最少被执行的测试用例。但这并不意味着这些测试都不重要，只是说他们在项目的生命期间里不是常常被运行，例如GUI，错误信息，可用性，压力和性能测试。
BVT为10-15%，高为20-30%,，中为40-60%，低为10-15% 。
这只是一个参考,不能完全照搬的.一切都要和具体实际联系起来. 原帖由 11034 于 2006-12-5 18:59 发表
理论上,测试用例是必须做到 用例编号要规范 测试目的要明确 用例等级要严格 预置条件要清楚 输入数据要精确,测试步骤要完整,预期输出要明确.现在有些公司会有一些测试用例输出到其他公司的,其他公司组织人员进 ...
狂谢啊～这位前辈sdlkfj5
具体的你看看
设计功能和界面测试用例设计功能和界面测试用例
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,选择"帮助"->"关于"命令,应 看见相关版权和产品信息 不错 收藏了 顶！
学习了！！
正在努力中 sdlkfj3 我也是在学习中 学习了,顶....... 收藏 谢谢！学习中！ 看了一点点 发表了个人意见 呵呵！写的比较细，可是感觉思维很乱 非常感谢楼上的意见，收着了，有空的时候好好看看 谢谢，我最近也在写呢。比较才知道我还是不够细心 我以前也只是在练习而已，现在发现如果真的把所有的情况，所有的测试数据都写在用例里，工作量还不是一般的大呢。
并且感觉写了很多重复的东西，比如，基本上所有的输入都要有：数据为空，数入一个字符的数据，输入最大长度的数据，输入超过最大长度范围的数据。
最后我就、就把所有相同的操作都写在一起，不再每个用例里都说明，这样虽然简单了，但每个用例看起来又不那么完整了。
我是觉得理论和实际的差距挺大的，不过我们的最重目的是测试系统，不是写测试用例，只要能很好的测试系统，设么样的用例都可以，不用拘泥于形式吧。
反正我是觉得把时间花在写那些重复的文档上是有些郁闷的，也许我对测试理论还需要了解sdlkfj1 原帖由 qi_cy 于 2007-1-1 21:13 发表
看了一点点 发表了个人意见 呵呵！写的比较细，可是感觉思维很乱
是很细致很全面，可是你写用例的时候真的把文章中的每一点都写进去了吗？这样会不会太繁琐了？
