51Testing软件测试论坛

标题: 关于评价测试用例的好坏 [打印本页]

作者: jackei 时间: 2004-6-7 19:50
标题: 关于评价测试用例的好坏
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关于需求阶段测试工作的一段言论。希望大家都多多努力，共同提高我们的测试水平。

作者: skinapi 时间: 2004-6-7 20:40
非常同意jackei的说法
只要明确了测试需求，测试用例不过是利用各种白盒黑盒的方法对测试需求的进一步细化和具体化。

作者: jackei 时间: 2004-6-8 09:01
哈哈，见笑，希望您也可以谈一下您现在测试工作开展的情况如何，供大家学习、参考。谢谢。

作者: skinapi 时间: 2004-6-8 12:58
别老是您您的嘛，搞的好像我很老似的，呵呵。
我做测试也就一年出头，最大的优点也就是肯思考，总在思考：
1。如何提高自己测试的效率
包括如何更好的设计测试用例等
2。如何提高整个测试团队的测试效率
包括测试经验的共享还有测试知识的学习等
总之是觉得测试工作同其它的工作一样都有很大可以提高的地方，测试工作越有序越能贴近测试对象，就越能产生好的效果。
欢迎交流。

作者: 欣桐 时间: 2004-6-10 15:51
谢谢!看了之后感觉很有帮助,但是能不能讲讲怎么提高测试用例的效率的我正在写用例感觉烦死了

作者: jackei 时间: 2004-6-11 09:57
现在正在整理这方面的内容，估计很快可以拿出来供大家讨论。

作者: skinapi 时间: 2004-6-12 23:17
期待中！！！

作者: llaala 时间: 2004-6-21 16:19
标题: 索取！
现阶段的我总是不断的索取......我刚刚接触软件测试3天，所以.......
希望给大家做贡献！

作者: lifr 时间: 2004-7-2 18:04
用例和用例实现分开是一个很好的见解阿。多谢
同意测试用例是一个迭代的过程。但我感到在迭代过程中要注意保证各方面的同步（比如用例和脚步和spec），我就遇到过这样的问题，用例和脚本在两个系统中。最后合并是大伤脑筋。

我认为好用例的判断标准就是覆盖性，至于如何才能有好多覆盖性，这应该是知识，经验和思维方法共同决定的。这里也有分析，抽象的过程，好的用例集合应该是艺术品吧：）

作者: junjun_jiang 时间: 2004-7-16 18:09
本人觉得评价测试用例写的好坏的标准有：
1.预期结果要明确，不能存在二义性。
2.功能不能有遗漏。
3.整个测试用例设计顺序逻辑性强，以便测试人员执行起来方便。
4.功能描述要与软件需求规格书要一致。
5.每个用例的前提条件要明确。
6.用例设计过程中，不仅要设计输入正确的例，还要包括输入不正确的用例设计。
就想到这些，设计用例时，可以参考等价类划分、边界值分析，错误猜测法来设计用例的，具体的书中都在相关的介绍的。

作者: mdk 时间: 2004-7-18 00:25
答复：
我感觉测试用例没有什么好坏之分：）当初的那句话，能发现最多错误的，发现至今为止没有发现的bug的用例就是好的用例，我认为是错误的。

老板重视的是Bug量呀，没有办法，在好的测试用例，发现不了Bug，那就不是好的测试用例。

作者: 东方一华 时间: 2004-7-21 15:51
测试的目的不仅仅是发现bug
还要验证需求等等！
（测出软件没有达到的，已经达到的和超过的）

作者: 零 时间: 2004-7-22 18:01
现在很多公司对于在需求阶段的测试没有做起来，测试人员都是从需求分析员那里获得测试需求，是不是测试人员也应该参与需求的获取，与用户打交道？？

作者: jackei 时间: 2004-7-26 17:48
http://blog.csdn.net/jackei/archive/2004/07/20/45964.aspx

作者: mysel 时间: 2004-7-27 09:31
我是一个新手，做了差不多两个月的测试，昨天看了你的《RUP测试过程实践
之测试需求与测试用例》，很多地方都有同感。但我在测试中，有时好象觉得测试时的操作步骤也是有好多种的，因为要找出BUG，必须做一些随意性的、非常规的操作，比如在修改某个记录时，还没修改完，鼠标要去点其他的功能按钮什么的，这些操作是否也要写到用例的操作步骤里？如果要写，那就肯定很杂。但如果不写进去，能怎样处理，看看你的意见？

作者: jackei 时间: 2004-7-27 11:15
我个人的看法还是希望可以在执行测试之前有准备的尽量充分一些，但是如果出现一些意料之外的问题，还是应该把这个问题出现的原因或者操作过程记录下来并且添加到测试用例中去。因为根据经验，缺陷的出现是有聚集性的，类似的问题可能会在多个地方出现，也可能会在今后的版本中出现。如果您觉得写的很杂很乱，个人认为应该考虑一下测试用例的管理，比如把这部分用例同相同功能的用例放到一起，或者专门开一个目录，把执行阶段添加的用例都放进去，等到一次迭代结束时重新整理到用例集中去。
当然，个人认为这部分问题还是每个问题使用一个测试用例记录的好，不过应该考虑抽时间出来对这些测试用例进行整理，重新归纳管理。
不知道上面这些是否对您有所帮助。

作者: mysel 时间: 2004-7-29 08:14

Originally posted by jackei at 2004-7-27 11:15:
我个人的看法还是希望可以在执行测试之前有准备的尽量充分一些，但是如果出现一些意料之外的问题，还是应该把这个问题出现的原因或者操作过程记录下来并且添加到测试用例中去。因为根据经验，缺陷的出现是有聚集性 ...

谢谢你的答复。因为刚入门，所以对用例的管理还是没有怎样想过。你说到对用例进行整理，可不可以说一下整理的一些细节问题、或技巧、或经验，或者用个案例说明一下？

作者: babybear315 时间: 2004-9-22 09:45
我觉得测试用例的好坏关键在于其目的性，首先，要确定需求，通过对需求的明确来明确测试的测试点。当确定测试点后，再设计测试用例，一个测试用例是要专门用于测试这些测试点中的一个或者几个的，目的性要强，只有这样，当你设计了一堆的测试用例后，你就能检查你设计的这些测试用例是否达到了测试的范围覆盖率，是否每个点都测到了，测试强度也达到了。

作者: jackei 时间: 2004-9-30 09:59
非常同意babybear315朋友的说法。

作者: cwliang 时间: 2005-7-8 11:17
没得说了,这里高手真不少,

作者: yujia 时间: 2005-9-5 19:22
我也是刚刚跨入软件测试这个行业的。希望大家多多交流，从此可以提高我们的水平。
请教各位：是不是最初的测试用例只是对软件的功能实现方面的测试呢？还是要把算法和一些实际输出考虑进去呢？

作者: yujia 时间: 2005-9-5 19:37
我也是刚刚跨入软件测试这个行业的。希望大家多多交流，从此可以提高我们的水平。
请教各位：是不是最初的测试用例只是对软件的功能实现方面的测试呢？还是要把算法和一些实际输出考虑进去呢？

作者: yujia 时间: 2005-9-5 19:47
我也是刚刚跨入软件测试这个行业的。希望大家多多交流，从此可以提高我们的水平。
请教各位：是不是最初的测试用例只是对软件的功能实现方面的测试呢？还是要把算法和一些实际输出考虑进去呢？

作者: jzj 时间: 2005-10-13 01:33
嗯！我也觉得好多领导都重视bug的量，没办法，我们老板就是的，还说日本人总是比我们速度快，bug多。其实我觉得好多给的测试时间不够，有些人员上也不够。写了好的用例，也不能很好的执行啊！

作者: jtiger 时间: 2005-11-18 09:38
同意楼上的，足够的时间和不受干扰地完成整个测试过程非常重要。但往往留给测试的时间都不够。

作者: eastsurfer 时间: 2005-11-19 23:47
我的一些看法,设计测试用例,首先,要考虑的是测试需求,明确测试的对象和范围. 不管是白盒还是黑盒,都是穷举法,所以测试用例的覆盖率不可能达到100%,这个比率的设定与软件生产周期密切相关.
还有一点,对于测试用例整体而言,要看重其覆盖率,对于单个Case或部分来说,还要考虑其重用性.

作者: 983221wy 时间: 2005-12-6 10:14
谢谢了！！！！

作者: harold_zou 时间: 2005-12-6 11:10
我要把它收藏起来，好好体会，慢慢消化……~~

作者: jhq2032 时间: 2006-3-6 23:05
标题: 测试的步骤
因为公司就本人一个人测试，所以我的测试用例都只写了些要实现的功能和一些字段的有效值和无效值等的输入，而对测试用例写执行哪个，后执行哪个并没有详细说明，这个执行步骤只有在我实际的测试过程中遇到了BUG时，才把步骤记录的详细，反映给开发人员，请问，那我该怎么样改进下我的测试用例呢？？？

作者: wmzhcx 时间: 2006-3-27 22:40
今天看了好多帖子了，真想一口气把他们看完，可是真的太多了，在这里谢谢jackey

作者: rockday 时间: 2006-4-26 15:20
看了这个帖子很有启发啊
谢谢大家了

作者: 天生我才 时间: 2006-5-8 08:27
同意

作者: dengwang 时间: 2006-5-10 12:08
希望有一天，我也可以写出这么好的心得来。先从读贴回贴做起！！！

作者: LLBB 时间: 2006-5-22 14:43
标题: 请教jackei
看了你的文章，知道你在这方面是高手，但不知道你所说的测试需求是一个抽象理论的概念呢，还是具体在项目开发过程中一个实际存在的文档，因为一般测试用例是根据需求文档而编辑的，那现在这个测试需求文档是何东东？还有有模板吗？盼回复！谢谢！

作者: sanjieyu 时间: 2006-7-6 12:28

原帖由 mysel 于 2004-7-27 09:31 发表
我是一个新手，做了差不多两个月的测试，昨天看了你的《RUP测试过程实践
之测试需求与测试用例》，很多地方都有同感。但我在测试中，有时好象觉得测试时的操作步骤也是有好多种的，因为要找出BUG，必须做一些随意 ...

是的，你提的问题也是比较普遍的问题，属于ad hoc的测试方法，也就是我们所说得free test，这些是test case所不包括的
如果通过ad hoc测试发现bug，这时候重要的是要及时的update case。
test case对于每个project来说，都是很宝贵的资料。
我们会在submit new bug的时候，给出相应的case number，确保一个bug有一个test case对应，如果是因为ad hoc产生的bug，那会及时的添加一个新的test case for 这个new bug，保证test case的时刻更新。

这样也可以慢慢的提高case的 coverage。

作者: sanjieyu 时间: 2006-7-6 12:35

原帖由 jzj 于 2005-10-13 01:33 发表
嗯！我也觉得好多领导都重视bug的量，没办法，我们老板就是的，还说日本人总是比我们速度快，bug多。其实我觉得好多给的测试时间不够，有些人员上也不够。写了好的用例，也不能很好的执行啊！

呵呵，我们和你相反，是日本人比我们速度慢，bug number也比我们少，但是他们在QA方面的technique是蛮好的

其实有时候去评价一个QA，不是单纯的靠bug的数量，这个只是一个小方面而已

bug多，但是都是一些小bug或者是suggestion，那他们的价值也不是很大。
另外一点就是，QA不但要找出bug，更重要的是要push 和帮助Dev去fix bug，否则一堆open的bug放在那里而没有fix掉，对project而言，也不是好事的。

作者: huangfei 时间: 2006-7-18 16:30
要是有具体示例就好了

作者: kitty_wangxin 时间: 2006-7-19 15:16
想问一下,关于一个业务流程的测试,写到一个用例里面感觉用例的粒度就太大了,但是分开写就体现不料一个业务的流程了,这一点我不知道怎么能很好的解决.谢谢指教!!

作者: llmm0409 时间: 2006-7-20 15:43
to jackei ：说的很有实践意义，但在编写测试用例中如何应用等价类划分，边界值分析法，错误推测法。我比较困惑，感觉大部分是根据spec的逻辑和自我经验确定一组用例来验证一个需求点。但是总体上觉得缺乏数学逻辑模型上的抽象，所以对于自己的用例，大部分上是逻辑分支上的覆盖。很难做到用少的用例达到最大的逻辑覆盖率。希望给与一定的建议，谢谢！

to sanjieyu : 感觉上你们的test case 管理很规范，你们公司在需求点变动所引起的test case 的变化，是用工具实现的吗？什么工具？还是人工的维护。

作者: qrz2000 时间: 2006-8-25 14:48
我们原先都是使用TD来管理的.每添加一个新的BUG都必须有一个对应的用例的.
但有时候也会出现测试人员增加了BUG,但没有同时去添加用例了.

作者: walker_lai 时间: 2006-9-3 13:36
不少高手啊！

作者: 白菜叶子 时间: 2006-9-5 16:48
我觉得
1、测试用例的覆盖率，一个测试用例至少要覆盖到几个测试的重点；
2、测试用例的描述是否明白，一个好的测试用例，可以让他其他测试人员作为测试执行的依据；
3、预期输出明确，不存在歧义；

作者: hongmei 时间: 2006-9-25 16:47
标题: 根据什么进行测试执行？
jackei,我是刚刚转做测试的，希望您能赐教，谢谢

测试执行人员只根据测试用例执行测试吗？

测试用例反映的是思路和方法，但象用户注册功能，注册表单有很多项，如姓名、工作、爱好等，注册需要的项，只在需求中进行了明确，而程序员可能会漏项，作为测试人员不需要根据软件需求测试注册表单里的项是否正确、完备吗？，如果这样的话我觉得测试需求也要写对注册项的完备进行测试，不知道我的理解对不对？

作者: hjjlearning 时间: 2006-10-12 16:43
哎，看到各位大虾说的，感觉真是汗颜！
我也是刚刚进入测试行业的，做网站测试
其实我在写测试用例的时候就是一个功能一个功能单独的写，测试出功能正确

本没有考虑到功能与功能之间的关联测试，因为感觉那样全部写出来的话

会有很多很多，真是迷茫啊

作者: Joan2005 时间: 2006-10-12 21:09
感觉每添加一个新的BUG都必须有一个对应的测试用例,是很好的完善测试用例的方法.
1.测试需求,其实就是根据需求文档整理出来的测试内容,即按功能模块划分,再细分出很小的功能模块，整理出测试需求点.不知道这样理解对不对.
2.按1中整理出来的最小的功能点,即测试点,设计测试用例.在这里执行步骤已经确定,主要是设计测试输入数据(合法和不合法的数据),一种测试数据对应一个测试用例.
3.对于业务流程的测试用例该如何来设计呢?违反业务流程的操作要不要设计进来?
也有很多疑惑,希望跟大家一起讨论.一起成长

作者: Joan2005 时间: 2006-10-12 21:14
还有一点.我们现在所有工作的开展只靠一份需求规格说明书(不是很详细).那么我们按此写的应该是系统测试用例.那么单元测试用例根据什么来写呢?它与系统测试用例在设计上有什么不同呢?

作者: foxspirit 时间: 2006-10-13 14:18
文章写得很好，其实每个领域，每个公司的实际情况是不一样的，难点就是怎样将理论和你们的实际需求联系起来，如果你做到了这点，那么如何用这些方法去设计测试用例的问题就迎刃而解了。别人再怎么说都无用，许多东西都是要靠自己去慢慢的体会。

作者: 刘洪鹏 时间: 2007-7-4 15:59
睡醒了顶一下

作者: helina168 时间: 2009-7-1 21:33
每天来这充下电真的受益不少，感觉自己懂的太少，要向各位学习了！

作者: 彦羽de心 时间: 2009-8-18 15:22
这么多高手，学习了~~

作者: hlm4540331 时间: 2009-11-17 22:52
这篇帖子提出了很多测试人员的心声。个人在实践过程中，觉得：在测试初期阶段，可以按照预先写好的测试用例进行执行以及需求重点，
保证基本测试点以及基本功能正常。在时间充足的情况下，多进行一些附和实际应用场景的非常规性性的操作测试。比如重复
操作几次，就会出现某个bug。

作者: 丢了朵朵 时间: 2010-12-22 18:20
谢谢分享！

作者: luhli520 时间: 2011-3-21 14:06
感觉平时测试都很零散，每隔段时间就需要总结一下

作者: yimao1029 时间: 2011-6-23 17:36
谢谢分享，看了受益不少。。。学习了。。。

作者: jiangboyang222 时间: 2012-7-17 21:19
好多字呀，都是高手，我只有顶礼膜拜的份儿~~~哈哈，学习了...

作者: zengli_ming 时间: 2012-10-23 16:00
很好呀，看了大家自己的想法，学到了

作者: paomo3360 时间: 2012-12-11 16:47
学习中。。。。

作者: Jesseli 时间: 2012-12-28 17:09
每添加一个新的BUG都必须有一个对应的测试用例,是很好的完善测试用例的方法记住了这个

作者: 1114078345 时间: 2013-3-29 14:02
昨天看的一篇文章总结一下测试用例设计方法：归类法；拿来法；加强评审；定义测试用例的执行顺序

作者: jigang.c 时间: 2013-9-7 13:17
从单个测试用例来讲，我认为一个好的测试用例就是能发现软件的错误，但没发现软件错误的用例不能说是不好的测试用例；不好的测试用例我认为是设计时没有覆盖测试需求，前置条件不明确，操作步骤可操作性不强，预期结果不好验证。

作者: 傻Leing 时间: 2013-9-23 11:02
初步学习下。很是受用

作者: cindyker 时间: 2014-5-31 17:32
分析非常到位，共享了。谢谢

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)