即使有了这些方法，让两个人来进行测试用例设计也会有不一样的地方，他们划分的等划域有可能会不相同，要保证一个软件的质量还得从上层来着手，一层层的细分，这样写出的用例出入才不会大。
之前有人提到测试用例的输入，我认为一般是产品需求包、软件需求规格说明书、软件测试方案，而最主要的是软件测试方案。测试方案中必须明确：1、测试重点；2、测试模块划分；3、测试用例的设计方法；4、各个模块的子特性；5、所有子特性的测试方法。有了这些，测试工程师再根据这个再写测试用例就可以把所有子特性的测试方案写成详细的用例。
举个例子来说明：
有一个接口，功能是：在数组当中查找某一个数（这个是产品包需求）
需求规格：使用二分法查找
成功：返回数据地址，重复数据返回第一个数的地址
失败：返回相应错误代码
假设以上就是开发给出的产品包需求（用户需求）和软件需求规格（系统工程师分析后的软件需求）在此测试系统工程师就得写出测试方案。
（以下是我自己的分析结果，如果有人有异议的话可以讨论一下，因为需求太小没有模块化，所以就只有直接介绍特性的设计方法）
测试分析的结果：
特性1：排序功能
测试方法：
1、输入升序数组
2、输入降序数组
3、输入乱序数组
特性2：查找
测试方法：
1、输入数据在数组内
2、输入数据不在数组内
3、数组长度为0
特性3：查找错误返回
1、输入数组指针为空
其它测试：
1、在内存不足的情况下查找超大数据
以上例子我只是举例说明在一个测试流程中，如何保证一个测试用例的设计覆盖得更全面。当然我也写得不好还没写完，如果写完的话，每个特性的测试方案都应该对应一条测试用例。而测试用例只是把这些全部给总结出来，形成一份可以在测试的时候执行的文档，然后对执行步骤进行详细的描述。详细的测试用例就不写了，相信大家看了后便应该知道大概要写些什么用例和怎么执行测试了吧！
但实际现在大多数公司都是没有写过测试方案的，或都写得很简单，写测试方案的人往往是写测试用例的人，所以也没啥好写的，都是直接写测试用例。
在最后还要说一下，测试用例一定要即时更新，软件有了新需求又得写出具体的测试方案，并且添加用例，要不然测试用例就没用了。写出的用例是否好能够看出测试人员的水平，用例的执行能够看出一个人的态度。
TO ALL
新手上路最关心的话题．做测试用例最忌讳些什么？？测试用例设计更多得是考虑异常情况
一直浏览，也该说句话了，呵呵测试用例得设计，正常得流程一般都是比较简单，如果能够提交测试得话，一般很正常得基本功能应该没有什么大问题，所以测试用例想要真正发现问题得话，在关注正常操作得情况下，更多得要考虑一些非正常得或非法操作。
例如测试下载功能，正常添加一个下载任务，应该能够下载，如果这个功能也不能实现得话，就根本没有达到进入测试得条件，拒绝测试！
接着那尝试如下操作：
1.添加多个下载任务，看看能否正常下载
2.下载过程中暂停，然后开始，看是否从上次下载的位置继续
3.下载过程中强制关闭程序，看下载的任务是否正常，下载的任务是否丢失
4.机器重启后，看下载的任务是否丢失
5.下载的过程中断网，过一段时间，再联通网络，看看软件有什么反应
6.频繁开始和暂停下载任务，查看cup、内存和gdi的占用率
7.同时下载大量任务，查看cup、内存和gdi的占用率
另外还有下载分类的管理等等
一点浅见，请多指教！ 有点想法就是测试就是有点搞破坏。 很多时候很疑惑，因为想让测试用例统一格式，但是统一的格式有不能适应各种情况。所以测试用例写起来也很郁闷。我们公司的软件开发不是很规范，因为很多时候项目时间很紧。 我写测试用例的时候主要会征对PM的spec.来写,逐个功能点的去实现它.再加上一点场景设计.但在测试的时候往往会有一些突发奇想,而往往,这种临时的想法确更容易找到bug.这个让我比较郁闷,总是觉得自己的测试用例不够完善.怎样才能全面的覆盖呀?大家帮帮忙,发表一下看法了 楼上的踩疼我了 新手，学习ing
So Good
真是不错呀学习了不少原以为黑测没什么呢不简单呀06年开始寻Testing 工作了 现在正在着手写测试用例，但是需求说明又只是功能性的介绍，我可怎么写啊？？？有什么方法吗？
帮帮忙啊！
谢谢了 在产品早期，是没以什么规格的，而且，测试后期，常规测试，根本没有什么问题，我有时候，只要把自己的当成客户，来使用产品，就行了 谢谢楼主的经验分享 楼上说的ISO标准的“软件质量稳定的21个因素是什么，能否贴出来共享一下，谢谢！ 踩死我吧 你 恩，不错，有启发的说。 谢谢啊 是不是，刚开始接触测试，用的都是黑盒测试法阿！ 还不错啊 写测试用例 记录测试过程真的好麻烦啊 咳。。
怕死不做共产党
