关于测试需求和测试用例的问题
小妹遇到如下困惑，望各位前面能予以解答，谢谢了——测试需求是不是越细越好？ 一条需求对应一条用例是否可行？
目前公司里需求和用例是写在一个文档里，要求需求能够比较详细，尽量做到一条需求对应一条用例，但我再编写的时候就会感到困惑，有些是几个用例对应一条需求，如果硬是细化需求，基本上就是添几个形容词 来将需求细分开来 就感觉有些重复劳动 : (
所以想请教各位 这样做是不是有必要？多谢了！ 我个人认为这个问题要具体情况具体分析，如果非要一个需求对应一个用例的话，那只有把测试用例的粒度再大一些了 加强用例的力度是什么意思？ 当用例非常详细的时候很难做到需求也如此详细，从而来和用例一一对应 一个需求应该对应一个或者一个以上的用例。需求并不是分的越细越好，需求关键要明确，也就是每条需求要有明确的输入、处理过程、输出。这样，即便输入和输出有很多种组合方式，只要彼此关系明确，也可以写出完整的测试用例，不会导致软件功能的漏测。 个人认为如果需求不明确不详细，怎么能实现一对一的关系。并不见得一个用例对应一个需求会好些，如果需求过去简单，那写出来的用例会不会显得很庞大，不便于维护，如需求分的很细，一个用例能体现出它的价值所在吗？ 用例的好与坏，不是在于它是否和需求一一对应，而是在于它是不是正确的实现了需求所要求的功能。
如何区分用例的好与坏？
我本人认为，一份好的用例应该是对应需求覆盖很全面的，不仅包括正确的操作应该得到的结果，而且包括错误的操作应该得到什仫样的结果及相应的信息提示等。 小可有篇文章，不日将呈现给大家。 期待中。。。 往往进行测试的时候，一个软件只使用一个用例的可能性几乎没有。一般来说，单个功能模块需使用１～３个测试用例（似乎情况而定）。 需求（requirement）、脚本（Scenario）和用例（Test Case）是完全不同的3个概念，不存在一一对应关系。需求是指用户希望达成何种效果。
脚本是指用户会如何使用软件通过一系列动作来达成这种效果。
测试用例则是一方面具体到实际动作和数据，另一方面不一定需要完成用户通常使用软件整个过程。
例如：
对一个简单的文本编辑文件来说：
用户需求：
。。。
用户应当能够修改一个现有的文本文件。
用户应当能将文件另存为用户指定的文件名。
。。。
而脚本则是：
用户打开文本编辑器-〉打开硬盘上的文件-〉将光标移动到需要编辑的位置-〉键入新字符或删除旧字符-〉重复编辑动作若干次-〉浏览编辑好的文件-〉另存为用户指定的文件名-〉退出文本编辑器
测试用例则可以是：
将一个现有文件分别存为：
Short.txt, looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooog.txt
SpecialChar_!@#$%^*().txt
Multi.Dot.Doc.txt
中文字符.txt
。。。 最近比较困惑，各位高手们请给我点指引。我做了软件测试4个月了，刚进入这个职业的时候，只是了解测试的一些理论知识，比如说测试人员具备的素质啊，就是一些特基础的。现在也做了几个月了，稍微懂了些，我发现测试这东西，你书本上多再多都不如实际的工作上的体会深刻。我们公司做的是办公自动化软件和英语软件。我现在主要负责测试的是办公自动化软件，现在也还比较熟悉产品，但是还有些心有余而力不足的感觉。我写过测试记录，写过测试报告，还有帮助文件几手册等，但还觉得有些东西没完全了解。就这样的问题，希望各位给我些建议或者说一些经验，谢谢了！ 楼主我和你的遭遇差不错。我也想听听前辈的意见 我也觉得一篇好的测试用例最主要的就是对软件的所有功能的覆盖，详细的测试用例要精确到每个功能点，对于这个功能点能实现的不能实现的都要考虑到。:) minz32，你说的脚本和用例的执行步骤一样吗？ 关于测试用例
测试用例也应该考虑到异常情况。比如erp软件中的数据流，可输入负数，较大数等相对异常或极端的用例。
小弟拙见，请大侠指教～ 偶就是不怎么清楚測試用例的模板到底怎么寫﹖
應該寫那些內容﹐怎么排比較好呢﹖ 我对于scenario 和testcase 的理解和minz32略有些不同
拿minz32的那个例子来说,在我工作中一般这样来处理,
需求（requirement）由specification 来决定
对一个简单的文本编辑文件来说：
用户需求：
。。。
A. 用户应当能够修改一个现有的文本文件。
B. 用户应当能将文件另存为用户指定的文件名。
。。。
对于需求A,可以有很多个testcase,
每个testcase由很多scenario组成.
每个scenario是一个用户的动作
比如Testcase1 为测试能够将空文件另存为用户制定的文件名
scenario 1) 打开一个空文件
scenario 2) 随机产生一个合理的文件名,该文件名由操作系统所在的locale决定,比如在中文平台上要由中文字符组成.
scenario 3) 存储文件,验证文件内容为空,文件名正确
Testcase2 为测试能够将文件另存为特殊文件名是有合理的错误信息
scenario 1) 打开一个文件
scenario 2) 产生一个特殊文件名(COM1,COM2,PRN1等保留字,或者是含有非法字符: \ 等)
scenario 3) 存储文件,验证错误信息是否合理
每个testcase都详细到任何人都可以根据scenario手工执行,或者自动化执行.
就ting_yt2的问题,个人觉得从测试角度来看
需求应该是越细化越好,但是写需求的人往往假设了很多东西在文档里面没有阐述清楚,
写测试用例的人就是把这些假设弄清,然后写在文档里面,所以一般来说都回有一个需求要几十个testcase.
当然就象jzhao说的,这都应该根据具体情况分析. 其实在实际工作中，对于测试需求而言，要细化到什么程度，要写多少，是受到实际的环境和资源的限制的。例如在一个测试时间非常紧迫的项目中，通过简单的制定测试内容的框架和一个大方向，迅速的开展测试工作，要比花费太多的时间在整理测试需求和书写文档上要有效的多。毕竟，我们的首要目标是完成测试工作，而不是完成测试工作中的一个步骤。当然，上面的方式是建立在测试工作的参与者熟悉被测应用及实际业务的前提下的。 具体问题 测试需求和测试用例是1对多的关系.没有必要细化到1对1的关系.
页:
[1]
2
