关于评价测试用例的好坏
leveret：现在大家在写测试用例的时候每个人都有自己的特点，但是什么样的一个测试用例才是一个比较好的用例，这是一个比较真实的现象，有这样几个问题大家可以交流一下自己的心得（如果愿意交流的朋友）：系统测试的用例要如何设计才能验证需求？有时候不知道结果的情况下如何预测结果，测试用例应该在不同的阶段下实施的时候应该是独立的。一般在设计测试用例的时候要包括合理输入，不合理输入，预测结果，一般常用的测试用例的设计主要用到：等价类划分，边界值分析法，错误推测法，但是这些都是理论方面的概念，我们在实际设计当中往往并不是按照这些去做的。大家在设计测试用例的时候应该都有自己的心得，如果愿意，可以把自己的观点分享出来大家来讨论。
seanhe：
我感觉测试用例没有什么好坏之分：）当初的那句话，能发现最多错误的，发现至今为止没有发现的bug的用例就是好的用例，我认为是错误的。
因为，测试不是解决问题，测试用例的好坏不是指单个的用例，而是用例的覆盖度，单个用例再好，所有用例的覆盖度不够，那测试工作还是失败的。所以测试的关键不是用例设计，而是测试范围的圈定，使用的方法，用例的设计只是自然而然的事情。
再说说一开始的用例怎么写，开始肯定有很多不清楚所以用例中很多的内容无法填写，所以我们应该默认用例的书写是个迭代的过程，不同阶段完成不同的内容，执行之前全部完成就可以了。
leveret：
用例的覆盖率也应该是从单个开始的，而且很多时候发现用例在很多输入输出方面的设计基本都是雷同的，至于测试范围的圈定，在系统设计阶段我们能考虑周全吗？考虑的出发点呢？根据测试的类别来考虑还是根据需求方面呢？不过对你所说的用例的书写的迭代过程比较赞同，我们一般测试正式开始之前会对用例有一个评审过程，明白了这个道理之后我想应该会比较轻松的。对设计测试用例的同行来说。欢迎大家分享自己的观点
jackei：
下面列举了我的一些看法：
01.对于“有时候不知道结果的情况下如何预测结果”，个人觉得这个问题比较明确，如果需求无法明确，或者说需求不够明确，则对于该需求的测试用例设计应该推迟，并及时同需求人员进行交流，尽快将需求准确的定义下来。
02.一般在系统测试阶段考虑的测试方法是黑盒测试，这时对于测试用例的设计如何使用那几种方法呢？个人认为可以先使用等价划分的方法划分出等价类，然后使用边界分析法确定下测试数据，最后通过自己以往的测试经验或者其他的经验来进行错误推测，增补一部分用例。对于这个问题，个人对于现在市面上的很多测试书籍都有负面的看法，很多书提到的一些用例设计的例子都是用windows计算器或者其他单纯用几个数字来作为例子——比如输入域是0-100，让你设计用例。很多时候我们在进行用例设计时看到的并不是很明显的数字，这些东西都是隐含在业务规则中的，感觉我们现在很多初学测试的朋友这种分析业务规则的能力还是比较欠缺，看不到深层的测试需求。当然这些方法也就应用的很有限了。
03.对于“测试用例应该在不同的阶段下实施的时候应该是独立的”，我也比较赞成。个人认为关键要搞清楚测试用例的作用。作为开发过程，是先有需求人员进行需求的收集，然后是系统分析员对需求整理分析，形成用例或者软件需求规格说明书，之后由系统架构人员进行架构设计，开发人员完成详细设计和编码工作——当然这也未必是一成不变的，但是大体的任务都是这么多。同样，我们看一下RUP中对于测试工作的流程介绍，为什么要把测试设计同测试实现以及测试执行明确的区分开来呢？因为测试工作现在同开发工作已经越来越相似，包括测试需求的整理、测试用例的设计以及测试用例的实现。我们现在很多同行所在的公司可能从人力资源或者从公司的流程上无法保证完全按照这个规范来操作，但是我们可以从RUP中明确测试用例的作用。用例本身就是用来指导实现的，用例实现的时候可以是自动化脚本也可以是手工操作的具体步骤。测试用例是可以同具体的应用程序实现完全独立的，可以不受应用程序具体实现变动的影响。至于为什么我将在下面说明。
04.对于“很多时候发现用例在很多输入输出方面的设计基本都是雷同的”，我觉得这个就可以考虑测试用例的“复用”。其实雷同也是正常的。
05.下面将阐述我个人对于测试用例设计工作的一些看法。
我很赞成 seanhe 对于测试用例迭代开发的观点，现实中我们也是这样考虑的。
测试用例不会平白无故的被设计出来，它是有目的和前提的。个人认为测试用例是用来指导具体测试实现的，包括自动化脚本的实现和手工测试步骤的实现。对于测试用例对测试需求的覆盖，个人认为不是测试用例编写的目的，而是对测试工作的要求——是要求测试用例设计人员的阶段性工作的结果必须符合一定的要求的。测试用例本身是无法保证覆盖需求的。
那么说到了测试需求，这里顺便说说测试需求的确定。leveret 也问到了这个问题——“至于测试范围的圈定，在系统设计阶段我们能考虑周全吗？考虑的出发点呢？”个人认为测试范围的圈定也就是测试需求的确定。
对于一个产品来说，它的开发和测试都不是一次性的，随着开发版本的迭代，测试工作也将继续进行下去，同时，我们对每个版本的测试范围都是不同的。注意，这里有一个关键，也就是测试范围圈定的出发点——软件需求的确定。那么怎样来明确软件的需求呢？——版本。如果希望工作的进度和内容可以明确的定义下来，就首先要考虑版本的确定——软件需求的版本确定。
通过软件需求的版本控制，可以明确每个不同版本的产品中所实现的特性，哪些特性将在以后的版本中实现。这里重点提到的是对于需求也需要使用版本的概念来进行管理。
既然某个版本的软件需求已经确定，那么接下来的开发工作就可以在这个需求版本划定的范围内开展。
测试需求是什么呢？个人认为就是需要测试的内容，它的来源有很多方面。
1.在需求阶段，软件需求规格说明书和用例中对于软件的描述、业务规则的描述就可以整理出我们最早的测试需求，这部分测试需求将完全来源于软件需求，是当前阶段测试工作的一个基础。
不过大家要看到，我们的测试工作从现在开始。
这个时期我们有一个非常非常重要的工作，我们将尝试着进行需求文档的检查。
这里，对于需求文档的检查主要是两个方面：
（1）检查需求文档描述的正确性，愚以为测试人员要对于真实的系统所涉及的业务非常熟悉，比如一个简单的财务软件，那么测试人员本身就要对会计工作熟悉，财务制度熟悉，在检查需求文档的时候不要迷信所谓的“都是用户真实的需求”，这里存在两个问题，一是用户是否真的能正确地描述自己的需求，二是需求人员是否真的能正确地理解需求。另外，还有一个用户的需求是否符合行业规范的问题，如果不符
合，那么是否要确认——这里存在一个隐患，用户可能会在开发的后期突然要求他们自己要走行业规范，让你的需求变动，所以要事先明确好。
（2）检查需求文档描述的准确性。主要是考虑文档中是否存在描述的模糊的地方，对于自己不清楚的问题一定要明确。这个时候是要保证需求的可测试性——我得意思是说保证需求是可以完全为测试工作服务的。再说的具体一点，要保证所有的软件需求都是可以用某种方法来明确的判断是否符合要求的。如果对于某个需求，无法获得一个明确的判断标准，则应该请需求人员对需求进行修改或补充——一个缺乏准确定义的需求，我们可以认为开发人员也无法准确的实现或者实现一个错误的需求，如果在应用程序交付测试时才发现这个问题，带来的后果就因项目而异了。
2.随着开发工作的开展，开发部门的架构设计以及详细设计也将陆续提交，这时候，我们可以根据设计文档来对原来的需求进行增补。注意，这里我们对于设计文档中提到的内容要有选择的采用，只有符合软件需求规格说明书或用例中已经定义的部分才可以用来调整我们的测试需求。而同软件需求不相符的部分，则需要同设计人员和需求人员一起讨论，确定下以哪一个为准，然后调整测试需求。这部分工作其实已经包含了对设计的检查，我们将继续努力尽早的发现缺陷出现的征兆。
3.在应用程序交付后，测试部门开始执行测试。这时很有可能通过一些我们根据测试需求设计的测试用例所没有包含的方法会找到一些缺陷，那么，这部分方法我们也应该整理到测试需求中。
OK，相信说到这里，各位看客也应该可以理解了我的观点。对于一个持续发展的公司或者持续开发的产品，它的所有东西都是要不断积累的。对于测试需求，不仅仅是在一个版本的开发过程中，在不同的阶段进行迭代，在产品的整个生命周期中的不同版本间也是不断迭代的。
既然明确了测试需求，测试用例的考虑也就变成 seanhe 所说的那种自然而然的事情了。我们可以根据不同阶段已经确定下来的那些测试需求来进行测试用例的设计，然后随着开发过程的继续，在测试需求增补或修改后不断的调整测试用例。如果我们从产品的整个生命周期来看，就会发现其实根本没有测试工作终结而测试需求和测试用例维护结束的时候，因为一个版本的结束就是下一个版本的开始。从这个大的范围来看，我们的测试需求和测试用例将永远的不断迭代下去。
啊，今天心情好，比原来那个回复又多写了很多，希望对所有的朋友多可以有些帮助。不过好像有些跑题，本来题目是“关于评价测试用例的好坏”，我还是要给出答案的：个人认为测试用例的好坏可以有几个方面。第一，是否独立于具体的实现；第二，是否可以比较方便的指导实现工作；第三，是否比较容易维护。而其他方面，个人认为则可以看做是“关于评价测试用例设计人员工作的好坏”的一些标准。
以上均为个人看法，仅供参考。如果朋友们希望就这些问题展开讨论，可以发送email到我的邮箱：jackei_chan@hotmail.com 。
另外，大家如果有兴趣，可以对我的另外两篇帖子发表评论——【原创】关于计划测试 和 【转贴】本人在51CMM关于需求阶段测试工作的一段言论 。希望大家都多多努力，共同提高我们的测试水平。 非常同意jackei的说法
只要明确了测试需求，测试用例不过是利用各种白盒黑盒的方法对测试需求的进一步细化和具体化。 哈哈，见笑，希望您也可以谈一下您现在测试工作开展的情况如何，供大家学习、参考。谢谢。 别老是您您的嘛，搞的好像我很老似的，呵呵。
我做测试也就一年出头，最大的优点也就是肯思考，总在思考：
1。如何提高自己测试的效率
包括如何更好的设计测试用例等
2。如何提高整个测试团队的测试效率
包括测试经验的共享还有测试知识的学习等
总之是觉得测试工作同其它的工作一样都有很大可以提高的地方，测试工作越有序越能贴近测试对象，就越能产生好的效果。
欢迎交流。 谢谢!看了之后感觉很有帮助,但是能不能讲讲怎么提高测试用例的效率的 我正在写用例 感觉烦死了 现在正在整理这方面的内容，估计很快可以拿出来供大家讨论。 期待中！！！
索取！
现阶段的我总是不断的索取......我刚刚接触软件测试3天，所以.......希望给大家做贡献！:):) 用例和用例实现分开是一个很好的见解阿。多谢
同意测试用例是一个迭代的过程。但我感到在迭代过程中要注意保证各方面的同步（比如用例和脚步和spec），我就遇到过这样的问题，用例和脚本在两个系统中。最后合并是大伤脑筋。
我认为好用例的判断标准就是覆盖性，至于如何才能有好多覆盖性，这应该是知识，经验和思维方法共同决定的。这里也有分析，抽象的过程，好的用例集合应该是艺术品吧 ：） 本人觉得评价测试用例写的好坏的标准有：
1.预期结果要明确，不能存在二义性。
2.功能不能有遗漏。
3.整个测试用例设计顺序逻辑性强，以便测试人员执行起来方便。
4.功能描述要与软件需求规格书要一致。
5.每个用例的前提条件要明确。
6.用例设计过程中，不仅要设计输入正确的例，还要包括输入不正确的用例设计。
就想到这些，设计用例时，可以参考等价类划分、边界值分析，错误猜测法来设计用例的，具体的书中都在相关的介绍的。 答复：
我感觉测试用例没有什么好坏之分：）当初的那句话，能发现最多错误的，发现至今为止没有发现的bug的用例就是好的用例，我认为是错误的。
老板重视的是Bug量呀，没有办法，在好的测试用例，发现不了Bug，那就不是好的测试用例。 测试的目的不仅仅是发现bug
还要验证需求等等！
（测出软件没有达到的，已经达到的和超过的） 现在很多公司对于在需求阶段的测试没有做起来，测试人员都是从需求分析员那里获得测试需求，是不是测试人员也应该参与需求的获取，与用户打交道？？ http://blog.csdn.net/jackei/archive/2004/07/20/45964.aspx 我是一个新手，做了差不多两个月的测试，昨天看了你的《RUP测试过程实践
之测试需求与测试用例》，很多地方都有同感。但我在测试中，有时好象觉得测试时的操作步骤也是有好多种的，因为要找出BUG，必须做一些随意性的、非常规的操作，比如在修改某个记录时，还没修改完，鼠标要去点其他的功能按钮什么的，这些操作是否也要写到用例的操作步骤里？如果要写，那就肯定很杂。但如果不写进去，能怎样处理，看看你的意见？ 我个人的看法还是希望可以在执行测试之前有准备的尽量充分一些，但是如果出现一些意料之外的问题，还是应该把这个问题出现的原因或者操作过程记录下来并且添加到测试用例中去。因为根据经验，缺陷的出现是有聚集性的，类似的问题可能会在多个地方出现，也可能会在今后的版本中出现。如果您觉得写的很杂很乱，个人认为应该考虑一下测试用例的管理，比如把这部分用例同相同功能的用例放到一起，或者专门开一个目录，把执行阶段添加的用例都放进去，等到一次迭代结束时重新整理到用例集中去。
当然，个人认为这部分问题还是每个问题使用一个测试用例记录的好，不过应该考虑抽时间出来对这些测试用例进行整理，重新归纳管理。
不知道上面这些是否对您有所帮助。 Originally posted by jackei at 2004-7-27 11:15:
我个人的看法还是希望可以在执行测试之前有准备的尽量充分一些，但是如果出现一些意料之外的问题，还是应该把这个问题出现的原因或者操作过程记录下来并且添加到测试用例中去。因为根据经验，缺陷的出现是有聚集性 ...
谢谢你的答复。因为刚入门，所以对用例的管理还是没有怎样想过。你说到对用例进行整理，可不可以说一下整理的一些细节问题、或技巧、或经验，或者用个案例说明一下？ 我觉得测试用例的好坏关键在于其目的性，首先，要确定需求，通过对需求的明确来明确测试的测试点。当确定测试点后，再设计测试用例，一个测试用例是要专门用于测试这些测试点中的一个或者几个的，目的性要强，只有这样，当你设计了一堆的测试用例后，你就能检查你设计的这些测试用例是否达到了测试的范围覆盖率，是否每个点都测到了，测试强度也达到了。 非常同意babybear315朋友的说法。 没得说了,这里高手真不少,
