测试需求与测试用例
http://blog.csdn.net/jackei/archive/2004/07/20/45964.aspx 关于测试工作范围的确定测试需求的整理
测试用例的粒度
测试用例是否该包含细节
测试用例是否需要任何人都可以随时拿来执行？
这篇东西最早是在5月底写完的，后来因为登《程序员》，又写了第三稿，所以一直到现在才拿出来供大家批判，希望大家少一些争论，多一些讨论，所有的方法都是要通过实践来检验的，也不可能通过一种方法完成所有的工作。大家一起努力吧。 顶一下！看过了再发表自己的看法：）
才发现你的blog，帮你宣传一下
http://blog.csdn.net/jackei/
有不少文章都不错呀！
很精点，很精典／
看是看了，对于我来说赋予实践还是需要一定的能力． 楼主，我怎么打开你上面的连接，页面提示错误呢？“/”应用程序中的服务器错误 已经下载下来了，有时间一定好好看看。 版主您好，阅读完您的大作后，觉得解决心中甚多疑惑，是篇极好的文章，但有数个疑问想请教：1. 在”如何整理测试需求”段落中，提到”修复的代价都会比在前一个阶段修复的代价提高10倍(参见下图)", 可是看不见图.
2. 在”如何整理测试需求”段落中，您有提到” 一是对软件需求正确性的检查”, “二是要保证软件需求的可测试性”, 但在”测试用例是否应该包含所有的细节”段落中出现的例子，
--------------
需求名称：用户登录安全验证
需 求描述：用户登录安全验证是为了保证所有登录到系统中的用户，都是由系统管理员预先在系统中设定的。使用系统中不存在的用户名，或者用户名输入正确，但密 码输入错误情况，都无法登录到系统中。当用户使用了不存在的用户名或错误的密码时，系统应分别给出适当的提示。如果用户连续三次无法使用正确的用户名和密 码登录到系统，则系统应给出适当的提示，并退出当前程序。如果用户使用正确的用户名和密码登录到系统，则退出界面，转到系统主界面。对于用户登录界面和程 序主界面，请参考相应的UI设计文档。
测试需求：
01. 检查能否使用正确的用户名和密码登录到系统；
02. 检查能否使用错误的用户名或密码登录到系统；
03. 检查使用错误的用户名和密码登录失败超过三次，是否会自动退出当前程序。
---------------
却看不出软件需求的可测试性。软件需求无论名称或是描述，似乎都不可测试；唯独测试需求每一条都是明确可测试的。
所以：请问上述例子的软件需求为何？软件需求就是测试需求吗?
3. 在”测试用例是否应该包含所有的细节”段落中，您主张不要包含所有细节，写出测试思想即可，但如此就有两个疑问:
甲、 关于Test Case, 您有提到”等价”和”边界值”法，假设有一个成绩计算的function, 我们知道要输入成绩的边界值-1, 101,和90, 那请问这些我们所盘算出的测试值要写下来吗？那是否就是过于详细呢？因为”等价”和”边界值”是在设计Case时会用到的方法，但您又主张Case只要记下测试思路, 这是否有些矛盾呢?
乙、 您在工作中是否有运用到自动测试工具, 如功能测试的Rational Robot之类的？因为测试员在操作Robot时，所有Detail数据都必须出来，但Test Case中只有测试思路而已；所以是否可以说:我们测试剧本(包含详细的Detail数据)是以Rational Robot所用的Script语言形式存在的？CMMI在做测量与分析时，因为Test Case本身不含细节，所以连Robot的Script也必需纳入考虑才完整?
不好意思一口气问了这么多问题，
谢谢您的不吝赐教! 我目前在外地出差，就是做软件需求，但是原先没有过经验，所以在调研时候还是觉得不少地方不能正确的引导客户，希望能够给出一个好的方法，如何与客户交流，使得我们双方对软件的需求都满意？ 软件的成败与否，需求真的很重要。小弟亲身的经历，真的太惨痛啦。一开始就是需求没有控制好，最后真的受气还一回事，最终还做不好项目啊。
我觉得在项目开始之前应该要很详细很清楚的搞好需求，特别是要跟client坐下来慢慢的谈，而且要达到对方的要求，直到client签名同意为止。在此过程当中，要主要分析client的要求是否可行，切忌client说什么都答应啦，最后完成不了，那就很麻烦啦。所以做需求的人一般都很有经验啦，特别是对软件工程，需求分析方面的知识啦。
当意见跟client有冲突的话，千万不可以跟对方吵，一吵就会陷入僵局啦，记住：第一，client永远都是对的；第二，如果client真的错了，请参照第一条。
但也不是人家说什么，我们就要听什么啦，如果他提出很“太空”的想法时，你可以详细的向其分析解释其不可行性，并且给予建议啦，不要一句“我们做不了”就ok啦，这样你的生意也会over啦。 statlight朋友，抱歉，最近这段时间忙于工作和一些其他的琐事，在论坛上正儿八经回答大家问题的次数少了很多，还请见谅。
对于您提出的问题，我尝试着逐一回答一下吧。
01.上次发布在csdn的时候，blog对于图片的支持不是太好，如果您需要一个完整的版本，请留下您的email，我可以发送一份给您。
02.对于软件需求可测试性的检查的含义，在小可Blog中的那篇文章是如下描述：对于一条软件需求或者一个需要实现的特性，必须存在一个可以明确预知的结果，并且可以通过设计一个可以重复的过程来对这个明确的结果进行验证。说的具体一点，就是要保证所有的需要实现的需求都是可以用某种方法来明确的判断是否符合需求文档中的描述。如果对于某条需求或某个特性，无法通过一个明确的方法来进行验证，或者无法预知它的结果，那么就意味着这条需求的描述存在缺陷。
举个例子，假如我将您说的那部分需求定义为：系统应为用户提供一个登录界面，并对用户输入的密码和用户名进行验证。那么您觉得这条需求是否已经描述的充分，并且可以供您完成测试呢？或者我们可以想一下，应该如何来判断系统是否正确的实现了验证用户输入的用户名和密码的功能呢？要怎样对用户名和密码进行验证呢？
我们再来看一个性能需求的例子：系统应当保证用户在查询汇总数据时，用尽可能短的时间来返回数据。那么系统的查询汇总功能的性能会受到历史数据量的影响，会受到查询条件的影响，也会受到同时并发的类似查询的影响，这里却并没有列出更加具体的条件，我们该如何来判定这条需求是否正确的实现了呢？
03.对于您的这个问题，我觉得还是有必要分清测试用例、测试脚本、测试数据的概念——当然，这也可能只是我个人的一种定义方法。首先，从您说的这个函数来看，测试用例只有两个，一是输入正确的数据应该得到正确的结果，二是输入错误的数据应该获得相应的提示并被程序拒绝处理。而您所准备的这些数据，则是同相应的测试用例相关的测试数据。我并不是说应该只作测试用例设计而不管测试数据的设计，而是建立将两者分开，避免将测试数据使用硬编码的形式保存在测试用例中——在我的Blog中您也可以看到一个关于测试用例的表格，也许更加容易理解。既然您说到了自动化测试脚本，我们就再来看看测试用例同测试脚本的关系。我个人的理解，测试用例在软件开发过程中对应的是用例（use case），而测试脚本则对应的是编码。如果我们只写一个实现10以下数据的正整数加法的函数，也许不需要完整的需求、设计文档，但是如果我们设计的是一个真实的业务系统，则这些东西都是必须的。而对于测试用例，在实现测试逻辑与测试数据的剥离后，如果将来需要实现自动化测试，那么测试用例就可以很容易的转化到测试脚本中的逻辑部分，而测试数据可以依旧保存在外部数据表中（无论使用文本文档还是excel或者其他数据库工具），不用作任何变化，而通过脚本中的逻辑部分来提取数据并进行处理。这一点也是符合ROBOT自动化测试框架的设计原则和思路的。如果说在手工测试阶段，把测试数据包含到测试用例中带来的仅仅是文档维护的巨大困难，那么当进行自动化测试的实施时，如果仍然将测试数据采用硬编码的方式包含到自动化测试脚本中，那么后果将不堪设想。我甚至可以偏激的说，如果那样，自动化测试就基本上失去了实施的意义，企业投入巨大资源却带来不了相应的效益。
04.对于您说的CMMI的问题，很抱歉，这部分内容我一直以来涉猎甚少，不过我会尽快研究一下，给您一个答复，大家可以就这些问题继续讨论。
一家之见，还望大家多多批评指正，提出宝贵意见和建议，也希望大家可以把自己在实践中的宝贵经验整理出来，供大家一起借鉴、分享、讨论，共同提高测试水平。谢谢。
另外，我最近一段时间上MSN和论坛不是太方便，如果可以，非常希望能够通过email的方式同大家联系，互相交流。我的email是：jackei_chan@hotmail.com 大家如果有兴趣，也可以参照一下《程序员》2004第8期的本文第三稿，个人感觉比这个版本好读一些。
另外，《程序员》2004年第9期已经刊登“软件测试实践之测试计划”，因为版权问题不能贴在网上，还请索要该文电子版的朋友们见谅。
to greenhouse
如果的确能帮助到您，我将非常高兴。对于验证需求，最需要的是对于专业知识的掌握，比如测试财务软件必须对财务工作非常熟悉才行。有其他问题，非常高兴可以同大家一起讨论，在blog留言或者email联系都可以。来信必复。^_^ 我下载来看了,确实不错.支持楼主,希望楼主有更多类似这样的东东,我一定拜读.:) 谢谢大家的支持，我会尽量把自己的经验和平时的思考整理成文字放上来的，还请大家多多批评指正。 看了版主和楼上的人讨论，我感觉，让我这个后来者也了解了不少的东东，我也非常认同同志们的看法。真是说的太好了。对新手是一个指导，对高手是个提示。。不错错。。。。。。。初来宝地，见识不少。版主真是好人啊。
能给我也发一份吗？谢谢jackei。我的email是bilifang@126.com 楼主我也要一份啊，bangtianyang@yahoo.com.cn文章是很好的，受益肤浅
斑竹能不能将描述登录用例换个更复杂一点儿的来说明具体用例的可维护性其实想让你再设计一个用例（需求名称、需求描述、测试需求、测试用例）
非常感谢
版主你的文章能不能发一份给我,我看了你缺陷跟踪的文章感觉很好,xiao211tao@tom.com
我的email:hlwat@163.com
