小弟认为做黑盒测试的基本条件是需要清楚你负责的模块的功能和与其它模块的联系及相互之间的关系、影响、数据流向。拿到一个模块后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

好像一般要求做需求的同时开始做测试计划，做设计的同时需要开始设计测试用例 我新手大家指教

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

那就是需求说明书有问题了。需要记录下来提交给开发人员修改。
自然不能靠自己想象。

我这就整理问题，准备提交．．．呵呵;)

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

如果在一些细节问题上和开发人员意见不一致，是该力争还是妥协？（在需求没有定义的情况下）

我认为首先验证需求，看需求是否具有可测试性，如果具有可测试性，可以先进行需求验证，验证的结果是否跟需求的结果一致；如果需求具有不可测试性，则看细节部分对整个系统的影响程度是否严重，原则上最终意见必须达成一致

那如果只是界面的一些问题呢？
比如说web界面中表格内容过多，需不需要分页显示

楼主写得不错，测试用例思路清晰，用力明确。

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

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

引用:

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

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

引用:

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

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

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

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

<font size='4'>to： luckhj</font>

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

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

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

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

有时候并不是单单以需求为主的，我现在的做法是以需求为根本，以软件界面，详细设计文档为辅助来编写测试用例。

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

测试的外部条件怎么没有考虑!

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

对流程的测试用例编写很关键。

黑盒测试有很多方法，不同测试方法用例设计也不同，请问哪位有不同用例的实例可否传一份过来，谢谢！