51Testing软件测试论坛

标题: 小弟做黑盒测试及测试用例的一点心得，写出来原和大家一起分享。 [打印本页]

作者: lbzhong 时间: 2004-8-20 11:39
标题: 小弟做黑盒测试及测试用例的一点心得，写出来原和大家一起分享。
小弟认为做黑盒测试的基本条件是需要清楚你负责的模块的功能和与其它模块的联系及相互之间的关系、影响、数据流向。拿到一个模块后1、分析(需求文档和测试分析文档)2、大体查看3、在大体查看基础上与分析做对比实际软件与文档的出入4、清楚为何出入(需求、开发沟通)5、动手测试。

模块名称：人员信息
建立日期：2004-08-17
建立人员：xxx
修改日期：2004-08-17
状态：[√] 草稿 [ ] 正在修改 [ ] 正式发布

定义：人员信息模块是对需要与该软件系统发生关联的人员的新增、修改（无效性设置、删除）、打印等操作。

前续模块：部门信息。
后续模块：操作人员权限设置。

一、功能测试
1、对话框测试输入进行测试。包括中文字符、英文字符、数字字符、特殊字符、及几种字符的组合。
2、对界面可操作按钮进行测试。包括【新增(N)】【保存(S)】【修改(M)】【查询(A)】【打印(P)】【退出(X)】。同时需要对鼠标右键的菜单进行测试。
3、数据保存测试。将1和2进行组合。
4、必要条件控制测试。在做了3时将必要条件(a、编号、姓名不可为空b、编号、姓名不可重复)控制测试联合起来。

二、模块联合测试
1、与前续模块(部门信息)联合。
a、有部门信息情况下
b、无部门信息情款下
c、有部门信息的情况下录入人员信息后将该部门进行无效性设置后的人员信息情况。
2、与后续模块(操作人员权限设置)联合。
a、录入人员基本信息后是否可以增加、修改、删除权限信息。
b、在增加了该操作员的权限信息后，对该操作员的修改。

三、测试数据
1、【新增(N)】操作姓名＝王小可编号＝NO.0980 性别＝女加入公司时间＝2004-08-09 现职位＝规划设计人员(3极) 毕业学校＝北大毕业时间＝2003-06-30 专业＝城市规划学位＝学士备注＝xxxxxxxxxxxxxxxxxxxxxxx
2、【新增(N)】操作姓名＝王小可' 编号＝NO.0980@ 性别＝女加入公司时间＝2004-88-09 现职位＝规划设计人员(3极) 毕业学校＝北大毕业时间＝2003-06-30 专业＝城市规划学位＝学士学士学士学士学士学士学士学士学士学士备注＝xxxxxxxxxxxxxxxxxxxxxxx

数据说明：1为全正常数据2为非正常数据加入了特殊字符、非标准时间、字段长度加长。

--------------------------------------------------------------------------------------------------------
小弟的测试数据在这里并不完整。前两项也有所删改。希望大家多交流。:p

作者: suncaijun 时间: 2004-9-6 09:40
好像一般要求做需求的同时开始做测试计划，做设计的同时需要开始设计测试用例我新手大家指教

作者: 土豆泥 时间: 2004-9-13 11:50
标题: 写得不错！顶一下！！！！
但是我有一个不解点，就是写测试用例时，是根据需求规格说明书来写，我想知道　的是，如果需求说明书里没有写的比较细的话，怎么办？如：有什么按钮，输入些什么数据，数据类型的限制什么的，这样的话，我在写测试用例时怎么来编写这些数据？是靠自己想像的还是需要告诉开发人员，我们需要需求说明书中写的更详细一点的．请各位高手指点．

作者: paradoxer 时间: 2004-9-13 19:35
标题: to 楼上的
那就是需求说明书有问题了。需要记录下来提交给开发人员修改。
自然不能靠自己想象。

作者: 土豆泥 时间: 2004-9-14 09:18
标题: 多谢啦，
我这就整理问题，准备提交．．．呵呵;)

作者: zerocci 时间: 2004-9-14 14:28
标题: to 土豆泥
其实在进行测试的很多项目中都会遇到需求不是很明细这种情况的，主要有两个方面：一就是正如你楼下所说的，需求分析错误（不清晰，不明确），那就要让development team去修改；（其实这也涉及到我们测试中的一个documentation testing方面的内容）。第二就是确实有些项目（特别是一些小项目），它们的需求都不是很详细的，一般都是给了一个基本框架，指出要实现什么功能，至于怎么去实现它就没有详细定义出来啦，所以面对这样的情况时，我们可以做的就是多跟PM和developement team沟通，从他们口中拿到那些我们想要的detail 需求啦。（千万不可以凭自己想象啵，即使是一个button的位置你不确定，你也要去搞清楚啦，不能认为是这样的就行啦）

作者: letian310 时间: 2004-9-29 13:28
如果在一些细节问题上和开发人员意见不一致，是该力争还是妥协？（在需求没有定义的情况下）

作者: zzm_test 时间: 2004-9-29 14:00
标题: to 楼上：
我认为首先验证需求，看需求是否具有可测试性，如果具有可测试性，可以先进行需求验证，验证的结果是否跟需求的结果一致；如果需求具有不可测试性，则看细节部分对整个系统的影响程度是否严重，原则上最终意见必须达成一致

作者: letian310 时间: 2004-9-29 15:09
那如果只是界面的一些问题呢？
比如说web界面中表格内容过多，需不需要分页显示

作者: freemail 时间: 2004-10-7 11:28
标题: 不错
楼主写得不错，测试用例思路清晰，用力明确。

但是，缺点是没有上升到理论高度。建议有兴趣的各位同仁可以看看符合ISO标准的“软件质量稳定的21个因素"标准，这个可以作为我们测试工作的指导方针，可以为测试用例的构造，测试模型的设计，测试思路的拓宽以及通过自己的整合和修改最终上升为指导你们公司测试部门测试设计的一个准则。

作者: luckhj 时间: 2004-10-15 09:10
lbzhong,写的不错.但分析(需求文档和测试分析文档)之前你还要做别的工作,比如测试需求什么的,有什么好的心得能说说吗?

作者: ting_yt2 时间: 2004-10-15 09:45

Originally posted by zerocci at 2004-9-14 14:28:
第二就是确实有些项目（特别是一些小项目），它们的需求都不是很详细的，一般都是给了一个基本框架，指出要实现什么功能，至于怎么去实现它就没有详细定义出来啦，所以面对这样的情况时，我们可以做的就是多跟PM和developement team沟通，从他们口中拿到那些我们想要的detail 需求啦。（千万不可以凭自己想象啵，即使是一个button的位置你不确定，你也要去搞清楚啦，不能认为是这样的就行啦）

可是有的小项目时间也很紧的啊，这样反复的沟通如何保证能够在指定的测试周期内完成任务呢？

作者: lbzhong 时间: 2004-10-22 16:40

但是，缺点是没有上升到理论高度。建议有兴趣的各位同仁可以看看符合ISO标准的“软件质量稳定的21个因素"标准，这个可以作为我们测试工作的指导方针，可以为测试用例的构造，测试模型的设计，测试思路的拓宽以及通过自己的整合和修改最终上升为指导你们公司测试部门测试设计的一个准则。

freemail 说的很好，我也发现在实际使用的时候有较多的问题，这样写的坏处最直接的就有两个
1、没有对流程进行详细的说明，那新接收的人员就不太容易懂。特别是数据流方面和数据的计算公式没有一个总体的把握。操作起来就只能按我写的用例来做，几乎没有自己的想象(发挥)空间，不太利于测试(关于不太利于测试自是我个人观点)。

2、可修改性实在太差，一旦开发做了修改那我的修改量是比较大的。

在整理了部分思路后我这里有一个关于数据流的用例。我认为它的开放性还是比较高的，大家讨论讨论啊！

作者: lbzhong 时间: 2004-10-22 17:11
<font size='4'>to： luckhj</font>

首先测试需求和分析是一个交互性的事物。
我对测试需求的理解是：软件的背景(包括行业、使用范围)、实现的流程、结果的表现方式。

软件背景：软件背景的了解对于我们在做测试分析、测试需求阶段是比较有帮助的(当然这是一个比较理想的方式，绝大部分实际情况是我们对软件的背景的了解还是来自于需求部门提供的文档，在一定程度上我们就比较容易陷入一种我们自己都不太容易发现的陷阱中去，我们就需要尽量的避免出现这种情况的发生，一旦发生了上述情况很有可能在做测试需求、测试用例都会有致命的漏洞，对于这部分漏洞我们可能在软件出来后在测试的过程中会发现，但是到那是我们就会付出代价了)。

实现的流程：这里的实现流程包括了两个流程(实际流程、软件流程)对于这两个流程有差异那是很正常的事情，开发部会处于一定的考虑不完全按实际流程来进行开发(绝大部分公司的现状)，我们这里就需要确认按软件的流程是否可以将客户的流程完成并不会有太多的影响。

结果的表现方式：这个就比较简单了，主要体现在它的表现方式我需要对应的准备环境(对于绝大部分软件来说它的结果的表现在pc机上就能看见，而对于有的特殊行业软件来讲那就需要借助余其它的外设来实现了)。

作者: 森林一木 时间: 2004-10-23 21:44
标题: 一点话
有时候并不是单单以需求为主的，我现在的做法是以需求为根本，以软件界面，详细设计文档为辅助来编写测试用例。

作者: lbzhong 时间: 2004-10-26 13:31
楼上的说的并不是没有道理的，但是在输出部分（如查询、报表）它的查询条件和结果都是可预见性的，按单一条件或组合条件来进行，我们将可能出现的组合模式列出即可。对于输入部分我们可以采用楼上的模式。

作者: pktest 时间: 2004-11-13 12:10
标题: 我觉得不是考虑的很充分.
测试的外部条件怎么没有考虑!

作者: lbzhong 时间: 2004-11-15 17:06
想请问楼上的你指的外部条件是指的那部分。
如果是硬件方面的由于这不是一个文档，只是部分没有贴出，我表示很抱歉。不过也感谢楼上的如此细心发现这个问题。

作者: newzxf 时间: 2004-11-23 10:52
对流程的测试用例编写很关键。

作者: whr 时间: 2004-11-26 16:26
标题: 请教不同测试方法的用例实例
黑盒测试有很多方法，不同测试方法用例设计也不同，请问哪位有不同用例的实例可否传一份过来，谢谢！

作者: yuelin 时间: 2004-11-29 15:51
头大了，说事情尽量的简单一点点就好了啊！~

作者: wangying1982_0 时间: 2004-12-18 14:37
我是新手，请多关照。以前我按别人写的测试用例测试，但基本上测不出什么问题，不知是我本身的原因还是.....？

作者: 小鱼oO 时间: 2004-12-21 08:41
很多时候文档不详细，且没有及时更新怎么办？

作者: 依伊卜舍 时间: 2005-1-10 09:27

Originally posted by wangying1982_0 at 2004-12-18 14:37:
我是新手，请多关照。以前我按别人写的测试用例测试，但基本上测不出什么问题，不知是我本身的原因还是.....？

一可能是测试用例的问题，二是否真正理解测试用例，三程序没有问题了

作者: njalic 时间: 2005-1-10 19:10
楼主讲解的还是有一定的首理的,但是有个疑问:如果项目需要录入大量的数据,例如现在的ERP软件,里面就有很多需要录入大量的数据,如果按这种方式进行测试用例的编写,可以想像有多大的数据量?而且这样编写对于以后的系统测试有什么用呢?

作者: snake 时间: 2005-1-10 20:03
大家继续讨论，帖子尽管不能升为精华帖，但是高亮显示还是很有必要的，希望调动更多原创出来跟大家分享和讨论

作者: fly-bird 时间: 2005-1-14 10:10
标题: 我觉得是不是应该再详细点啊？

作者: fly-bird 时间: 2005-1-14 10:15
虽然我自己没有写过，但是感觉仅仅是这样好像比较笼统
一点意见，仅供参考

作者: lbzhong 时间: 2005-1-20 17:20

Originally posted by lbzhong at 2004-10-26 13:31:
但是在输出部分（如查询、报表）它的查询条件和结果都是可预见性的，按单一条件或组合条件来进行，我们将可能出现的组合模式列出即可。对于输入部分我们可以采用楼上的模式。

没错！这样写的确是非常的麻烦！而且不利于用例的修改！
其实我们可以将数据和用例步骤分开进行。对于数据来讲可以分为两部分，功能数据和流程数据。
功能数据：是对功能测试时使用的数据，这部分数据就比较多并且比较乱。它的目的是为了验证功能，当然会有正常数据和非正常数据。
流程数据：是为了对流程测试的连冠性使用，在做这部分数据的时候会充分考虑到流程，这部分数据建立后会贯穿整个流程，主要是以正常数据为主。
这样做还有一个好处就是对于数据测试的稳定性会有一定的提高。

作者: shelly 时间: 2005-1-21 12:55
标题: 3Q
新手,目前正要求写test case.受益匪浅.谢谢ing

作者: flyingpig 时间: 2005-1-23 20:27
我的一些看法，可能和楼主的考虑角度不一样。一起讨论。

1、保证基本的通过测试。
2、失败测试
A.0输入的测试：是否有出错提示或是否能正常保存、
B、连续输入的测试
C、压力测试：比如根据软件的基本功能进行的多窗口操作测试

3、通过准则

作者: srnwork 时间: 2005-1-26 13:54
对，楼上的看法和楼主的角度不同，
楼上的是编写测试用例的大方向，而楼主的则是具体的细节讨论。
都很精彩，努力学习中……

作者: xiao_jie98 时间: 2005-1-26 15:41
大家觉得写用例有用吗？要花很长的时间写，而且需求一变又得跟着改，郁闷！

作者: xiao_jie98 时间: 2005-1-26 15:41
不知道正规公司是怎么操作的，大家能不能谈谈？

作者: ailine 时间: 2005-1-28 11:15
标题: 嗯！
整体思路还比较清晰，运用了数学中的排列组合，再一次体现了数学在计算机中的重要性了！呵呵！

作者: yanru3987 时间: 2005-1-28 15:14
标题: lbzhong我很同意你的两种数据的准备
但是我不知道再用例中怎么体现出来，因为总感觉如果用两中数据来的话就有两中测试用例出现那样对维护文档来说很麻烦不知道你是怎么处理这样的问题的

作者: Angela 时间: 2005-1-30 23:04
标题: 这是必须的

Originally posted by xiao_jie98 at 2005-1-26 15:41:
大家觉得写用例有用吗？要花很长的时间写，而且需求一变又得跟着改，郁闷！

我觉得测试用例是测试最基础的保证，写用例不是浪费时间，相反是在给你节省时间，因为一个好的用例户会让你的测试轻松而高效，且会保证你测试的全面性，可能开始的时候会多花些时间，但是熟悉了测试用例的方法会让你倍感快乐。

作者: neogeo2697321 时间: 2005-2-1 09:33
写的好像简单了点！！

作者: 0421 时间: 2005-2-1 16:16
TO lbzhong
老兄有什么好的资料多拿点出来大家共享一下了,谢谢了,有没有性能,强度,压力这方面的测试用例拿来给我们大家看一下,想多学一点,谢谢!!

作者: bethapple 时间: 2005-2-2 17:55
标题: 帖子太多我没仔细看好像没有说到边界测试吧
边界测试也是很重要的呀。
对于界面应该有相应的界面设计文档作为依据的。
同时很少有公司能做到需求，设计文档很完备，且及时。这也是没有办法的。
但我们测试的人当然不能根据开发人员自己做出的东西来作为依据。

作者: lhy 时间: 2005-2-5 09:53
标题: 同意你的说法
边界很容易被开发人员忽视,所以测试人员应该重视起来

作者: firego007 时间: 2005-2-16 10:00
Quote:
Originally posted by wangying1982_0 at 2004-12-18 14:37:
我是新手，请多关照。以前我按别人写的测试用例测试，但基本上测不出什么问题，不知是我本身的原因还是.....？

一可能是测试用例的问题，二是否真正理解测试用例，三程序没有问题了

我认为，程序不可能没有问题，是测试用例设计的不好。

作者: jackei 时间: 2005-2-16 17:03
firego007 ，或许你需要新的测试用例。

作者: billsong 时间: 2005-2-17 21:47
看了这么长的帖子我也想说几句，在我的工作中我们把测试用例分为功能性和非功能性两个方面的Case，功能性的Case包括Spec中提供的一些基本的功能以及各子模块（小的功能）间的联系；非功能性Case则包括一些习惯操作，压力测试，稳定性测试等Case。

作者: billsong 时间: 2005-2-17 21:56
还有刚才关于“按照Test Case执行测试，但是还是没发现问题”，
首先，一个再好的程序不可能没有Bug。
我觉得很有可能是Test Case设计的问题；不过在实际测试中，其实很大一部分Bug不是靠Test Case发现的。

作者: caohfei 时间: 2005-2-20 09:50
标题: 感觉
感觉理论方面说的多了些，可是有没有人能有针对性的说一下，比如举个例子，将该例子详细说一下，

作者: xuerzj 时间: 2005-2-22 17:17
这是个测试思路，但具体测试用例怎么写，还是不清楚呀。

作者: bethapple 时间: 2005-2-22 18:09
标题: 其实我觉得代码走查最能发现bug了
另外，如果你的测试流程别的阶段和你采取相同的测试方法，那你可能就发现不了bug了。我觉得谁写的case谁测的好，一者对bug比较敏感，可能出bug了，你都没意识到。另外，找错误也比较容易。没有完美的文档，在执行的时候经常又会有其他的思路了。

测试用例大多还是要根据需求文档，界面根据界面的设计文档。
来做，一条一条的对应起来，一般一条需求对应很多case.会很多的说，也挺烦的,如果需求总变的话。

作者: bethapple 时间: 2005-2-22 18:31
标题: 对于容易出错的地方，case 最好能100%覆盖。
20%的代码导治80%的错误；
我很有体会。刚测了一个exposed interface
开始执行我的test code 出现了bug. 因为刚做测试半年怕是自己的driver的问题，就跟进去，发现这个developer 的 code 写的很不规范。又加了很多case居然测出很多的bug。

作者: hongtang 时间: 2005-2-27 23:31
标题: 其实好的测试用例 ~就能让不了解的人能够轻松执行并发现错误

作者: lxg327 时间: 2005-3-1 14:16

Originally posted by hongtang at 2005-2-27 11:31 PM:

我觉的老兄说的很准确，赞！

作者: ruben78 时间: 2005-3-5 14:36
标题: 什么才能写一份好的用例？
但是要什么样才能写出一份好用例，虽然到现在我有写这一些测试用例，但是在实际中的应用不大

作者: zhengyh1980 时间: 2005-3-11 12:40
大家应该把常用的经典测试用例总结一下，还有常见的缺陷。（可能不同的系统情况不同吧）

作者: liangyan_58 时间: 2005-3-12 10:13
唉,我们公司不能上网,资料也不能带出来.所以不能拿出来和大家分享

作者: y123456 时间: 2005-3-18 17:08
感觉楼主所设计的测试用例是一个用例思路，如果要其他测试员执行的话可能可执行性会低一点，又或者出现BUG的机率会低很多；个人觉得要写出执行性高的用，还需要对测试的功能进行细分和规划，别外测试数据可以分开来管理和维护的话会更好点。

作者: luowangjun 时间: 2005-3-21 15:20
标题: 顶一下！
有心得就互相交流嘛！
这样大家才有技术积累，才能互相进步！爽也

作者: jacckljl 时间: 2005-4-12 16:12
标题: 测试需求分析怎么弄？
经常听说要测试需求分析，但是却不知道怎么弄！
因为一般需求分析都是开发部的经理写的，而测试人员又很少能够参与他们写
需求分析的过程！到手的都是已经写好的了。
所以我们又怎么知道这个需求分析有问题，要测试？
而且我们还要根据这个需求分析写STP呢？
再说测它又怎么测？？

作者: zyh2008108 时间: 2005-4-15 13:50
我们刚培训完,部门分工,我搞测试用例设计,这刚开始,不怎么会写,望大家多多指导!!!在论坛上多发点帖子!!

作者: coolseal 时间: 2005-4-15 17:00
一般测试用例都是由有经验的测试设计员来编写的，测试新手编写的测试用例可能不可靠，因为它对测试还不太了解，所以不能说谁的测试用例谁来测试比较好，这点事不正确的。好的测试用例不管那个测试人员来测试都是效率比较高的。

作者: wiser.cheng 时间: 2005-4-20 16:43
个人心得：
写测试用例不是为了反映问题，而是为了解决问题

作者: zshf235 时间: 2005-4-29 23:40
标题: 个人经验：
1、测试用例是一个软件在真正进入测试阶段的前提条件(软件要实现的功能、所用的测试数据等)。
2、其次就是搭建你的测试环境。
3、测试的方法即黑盒、白盒、临界条件等等！！

作者: color 时间: 2005-5-9 09:49
正在学习中！
不过，看了这么长，还是希望能够多看到一些测试用例的具体实例，如果大家能拿出来分析一下，就好了！

作者: Chenny 时间: 2005-5-17 16:30
标题: 如何设计Mp3测试用例？
我要对Mp3解码程序进行测试，现在需要一些测试用例，我已经选取了一些Mp3，可是发现程序代码覆盖率还是不高。为提供测试覆盖率，该如何创建一些特殊的Mp3测试用例呢？各位有这方面的PCM文件么？我可以将PCM（.wav）转换为可播放的mp3。
欢迎讨论，请大家指点！！

作者: jiangwb1 时间: 2005-5-19 10:13
对啊
拿个具体例子说一下
说这么抽象

作者: 浪漫小站 时间: 2005-5-19 12:14
标题: 谢谢楼主！！！！！！！！1
楼主说得话很有道理，我现在测试的系统同楼主测试的系统有点相似，让我又可以更进一步去把之前测试用例来更新一下；

作者: wl7532329 时间: 2005-5-19 13:43
经典之帖~~从2004说到2005~~佩服~~
不过楼主例子对我还是有帮助，希望以后能有更多这样的帖子哈~~

作者: 红汤_benny 时间: 2005-5-25 11:38
标题: Very good
不错,我顶一顶

作者: 小丫头 时间: 2005-5-25 21:16
怎么好像都是些理论方面的东西啊

作者: syycrazy 时间: 2005-6-5 18:39
谢谢例子

作者: tw0202 时间: 2005-6-15 11:07
各位:
我是做手机软件测试的,目前只是使用黑盒测试的方法,请问各位说的这些个测试用例是否也可以用于手机的测试?
请回复,谢谢!

作者: jerayyao 时间: 2005-6-15 17:15
标题: 我们是怎么写测试用例的
我们写测试用例的步骤:
      1 根据画好的模块界面 ,在TD里的TEST PIAN 里编写它的功能点 ,还有集成测试点
      2好了, 写完了
我们写的测试用例该称为测试功能点  , 唉很不规范啊
  我才做4个月的测试 ,还是一个新人 ,请大家多多指教啊

作者: matr 时间: 2005-6-15 21:52
我都是根据Detail design specifiction and UI design specification 来写的。

作者: 夏天 时间: 2005-7-1 12:02
标题: 希望楼主就管理软件的测试用例说得再多一点,实惠一点点,3Q
希望楼主就管理软件的测试用例说得再多一点,实惠一点点,3Q

作者: 测试有前途 时间: 2005-8-9 14:37
其实有时候觉得像黑盒测试用例的编写,只能从预计的输入/输出来编写；这样会照成用例的编写会考虑不周(这个是摆脱不了的么)；

作者: lixin1020 时间: 2005-8-10 16:12
我现在惨了连需求还没有呢就让我先写计划书和用例真不知怎么写

作者: 素素 时间: 2005-8-15 12:45
标题: 我也正需要......
大家看看我在网上拷的,我也正学习中......,
1.评判依据:

各公司的标准定制的不一样，有些公司可能更细化些，在这里仅作一个粗略依据。产品的好坏由用户说的算，一切为用户服务！
依据：软件研制规范，软件需求说明书，用户手册（罗嗦两句，国外的说明书写的很细，比如不可以用电熨斗烧咖啡，国内的使用说明书绝对不会这么写的，但是使用说明书上具有的功能在产品上如果没有的话，可就是不符合项喽）。

4、基本功能说明：

添加、删除、修改、查找
设置（各MMI不一样，在这里不进行举例）
批量操作：SIM卡记录复制到手机，手机记录复制到SIM卡，SIM卡记录移动到手机，手机记录移动到SIM卡……

5、功能测试：

在这里只讨论名片夹的功能性和可靠性的测试，对名片夹模块的易用性，效率，维护性以及可移植性不做考虑。

按是否通过测试，则分为两种，顾名思意即通过测试和失败测试。通常的失败测试，也就是说要设计测试用例，迫使软件出错。通过测试则是要保证软件实现基本功能。

5.1 基本功能测试：

手机输入法有很多种，比如T9,拼音，字母，数字等等。在编写测试用例的时候，首先要保证各输入法是否能正常输入；能否正常保存；在进行错误输入的时候，是否有响应的提示。在这里举出几个例子：

5.1.1、存储在SIM卡上的记录

5.1.1.1、添加：
1）姓名输入：
i)是否可以使用任意输入法添加汉字、字母、数字，达到姓名允许的最大字节，并能正常保存。
ii)是否可以使用任意输入法添加汉字、字母、数字，在没有进行输入时，是否有警告提示或是否可以正常保存（根据产品要求）。
iii)是否可以使用任意输入法添加汉字、字母、数字，超过姓名允许的最大字节，是否有告警提？是否可以正常保存。
iV)是否可以进行汉字、字母、数字的混合输入，并重复i~iii，是否有异常。

2）电话号码的输入：
   i)是否可输入数字至最大值，并可正常保存。
   ii）在不输入数字时，进行保存时，是否有告警提示。
   iii）是否可以输入汉字，字母，此时是否有告警提示或异常。
   iv)是否可以输入特殊字符，如+、P、*、#，是否可以正常保存。这里给介绍个出错的案例：连续输入多个*，P或+，不按电话的号码的正常顺序进行输入，试试，比如"++139***P123",看看是个什么样的效果，是否显示正常。

3）在输入过程中按返回键、挂机键、或翻合翻盖、电源键，是否有告警提示或异常。

4）在各MMI界面下，各按键功能是否正常。

5）待机界面下直接输入数字至最大值，是否可以正常保存。

6）待机界面下直接输入数字即特殊字符（＋，P），是否可以正常保存。

7）将1），6）步骤进行一下排列组合，查看是否有异常情况。

1对2，2对4，4对16，所以测试用例经常的几千条，几万条根本就不希奇，一个名片夹写上1K条也之是写了个小部分。呵呵，罗嗦话又一堆。继续......

作者: 素素 时间: 2005-8-15 12:48
大家有意见发表哦!!!

作者: 素素 时间: 2005-8-15 12:49
大家有意见发表哦!!!

作者: flytigerboy 时间: 2005-8-16 15:57
先借楼主的文档看看再说！

作者: 大妮 时间: 2005-8-16 16:05
lixin1020，你们公司居然这样。。。。。
没有需求，那里来的计划与用例???

郁闷～～～～

作者: 大妮 时间: 2005-8-16 16:45
4天后一定再来顶贴。。。
^_^

作者: zhengfeng 时间: 2005-8-17 13:35
内容还行。不过内容太少。

测试数据2条，少了点哦。不能覆盖所有path.

作者: zhengfeng 时间: 2005-8-17 13:37
需要根据SA,SD ,具体要求来定测试数据。

不能搞大一统。

作者: 素素 时间: 2005-8-17 18:37
标题: 测试用例怎么写。。。。。。学习中。。
大家好！！我也在学写的过程中。黑盒测试用例个人的一些想法。可以从7个方面来考虑。
1.基本功能（MMI）
2.中断操作对MMI的影响
3.边界值
4.异常操作
5.压力和疲劳测试

作者: yulinger110 时间: 2005-8-18 15:06
我也是在写测试用例，但是我写的测试用例，执行人员基本上不看，我也就不知道自己写得好还是不好了，因为没有人提意见，郁闷！

作者: tongfenglcz 时间: 2005-8-30 10:54

Originally posted by 土豆泥 at 2004-9-13 11:50 AM:
但是我有一个不解点，就是写测试用例时，是根据需求规格说明书来写，我想知道　的是，如果需求说明书里没有写的比较细的话，怎么办？如：有什么按钮，输入些什么数据，数据类型的限制什么的，这样的话，我在写测 ...

一般我会在设计和需求分析完成之后，才开始设计测试用例
输入的数据、类型一般我会参考数据库设计

不过具体一个表单中应该有哪些字段以及有什么功能键，这些是取决于需求和开发人员

拙见，请多多交流……

作者: tongfenglcz 时间: 2005-8-30 10:57

Originally posted by letian310 at 2004-9-29 01:28 PM:
如果在一些细节问题上和开发人员意见不一致，是该力争还是妥协？（在需求没有定义的情况下）

一般会和PM和开发人员沟通并参考PM的建议

作者: dongt 时间: 2005-9-1 12:44
标题: 谢谢
学习ing~~~~~

作者: wangxh 时间: 2005-9-2 16:11
标题: 测试用例与测试文档
请问各位同行,测试用例文档和测试文档有啥区别

作者: pokka 时间: 2005-9-6 16:43
标题: 不明白！
请问在写功能测试的测试用例时，那些可能值及可能值之间的组合怎么的来啊？靠自己想像还是有别的什么方法啊？Sample Text

作者: pokka 时间: 2005-9-6 17:24
请问可以根据开发级用例来写测试用例嘛？

作者: zhtjo 时间: 2005-9-26 19:52
新人，一直摸不着头脑。
看了用例，似乎明白一点点了。
楼主的帖子，赞。
多来多来

作者: haozhijian 时间: 2005-9-29 10:38
原来做黑盒测试也有这么多内容清楚了谢谢

作者: yanru3987 时间: 2005-10-9 10:15
标题: 我正郁闷呢
刚刚接了个项目，需求那就是一个粗基本就讲了些功能点具体怎么实现都没什么按钮痛苦啊关键是我们这个是个外包项目不知道怎么办才好

作者: Erdosfish 时间: 2005-10-10 18:41
应该把测试数据做汇总之后，组合成几条测试流放到这里。

作者: Erdosfish 时间: 2005-10-10 18:45
1、根据需求说明书，解决UI和功能正确性的问题
2、根据测试工程师分析，解决容错和易用性，性能，稳定性，安全性等方面的问题。
3、贯穿整个的数据流视具体项目而言，准备得数据量如果大的话，能组织到一起共同输出就汇总，如果不能汇总最好单列。

作者: persimmon 时间: 2005-10-12 17:21
刚做测试不久，最早测试的时候是已经比较成熟的系统，根本就没看过需求分析，只是凭借着前辈指点的经验去做，前不久看过公司的一个需求分析也是下一步将要开发的系统，比较粗略，只是介绍了大概的功能、流程,真的不知到时候测试用例要怎么写才好？

作者: vivianonion 时间: 2005-10-21 13:21
赞，贴子不错！学习中！

作者: 必要时 时间: 2005-10-25 17:27

Originally posted by color at 2005-5-9 09:49 AM:
正在学习中！
不过，看了这么长，还是希望能够多看到一些测试用例的具体实例，如果大家能拿出来分析一下，就好了！

我跟你一样，这句话说出了我的想法。

作者: 悠悠岛 时间: 2005-10-27 09:26
标题: 留个大脚印！！
使劲踩一下

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)