51Testing软件测试论坛

标题: 测试用例设计的误区（原创） [打印本页]

作者: dennis_d 时间: 2004-12-21 10:57
标题: 测试用例设计的误区（原创）
参见我的个人主页：
http://sitwithwhom.51.net/index. ... d=a_20041221_104000

1、能发现到目前为止没有发现的缺陷的用例是好的用例：
首先要申明，其实这句话是十分有道理的，但我发现很多人都曲解了这句话的原意，一心要设计出发现“难于发现的缺陷”而陷入盲目的片面中去，忘记了测试的目的所在，这是十分可怕的。我倾向于将测试用例当作一个集合来认识，对它的评价也只能对测试用例的集合来进行，测试本身是一种“V&V”的活动，测试需要保证以下两点：

* 程序做了它应该做的事情
* 程序没有做它不该做的事情

因此，作为测试实施依据的测试用例，必须要能完整覆盖测试需求，而不应该针对单个的测试用例去评判好坏。

2、测试用例应该详细记录所有的操作信息，使一个没有接触过系统的人员也能进行测试；
   不知道国内有没有公司真正做到这点，或者说，不知道有国内没有公司能够将每个测试用例都写得如此详细。在我的测试经历中，对测试用例描述的详细和复杂程度也曾有过很多的彷徨。写得太简单吧，除了自己没人能够执行，写得太详细吧，消耗在测试用例维护（别忘了，测试用例是动态的，一旦测试环境、需求、设计、实现发生了变化，测试用例都需要相应发生变化）上的时间实在是太惊人，在目前国内大部分软件公司的测试资源都不足的情况下，恐怕很难实现。但我偏偏就能遇到一些这样的老总或者是项目负责人，甚至是测试工程师本身，全然不顾实际的资源情况，一定要写出“没有接触过系统的人员也能进行测试”的用例。
   在讨论这个问题之前，我们可以先考虑一下测试的目的。测试的目的是尽可能发现程序中存在的缺陷，测试活动本身也可以被看作是一个Project，也需要在给定的资源条件下尽可能达成目标，根据我个人的经验，大部分的国内软件公司在测试方面配备的资源都是不足够的，因此我们必须在测试计划阶段明确测试的目标，一切围绕测试的目标进行。
   除了资源上的约束外，测试用例的详细程度也需要根据需要确定。如果测试用例的执行者、测试用例设计者、测试活动相关人对系统了解都很深刻，那测试用例就没有必要太详细了，文档的作用本来就在于沟通，只要能达到沟通的目的就OK。
   在我担任测试经理的项目中，在测试计划阶段，一般给予测试设计30% - 40%左右的时间，测试设计工程师能够根据项目的需要自行确定用例的详细程度，在测试用例的评审阶段由参与评审的相关人对其把关。

3、测试用例设计是一劳永逸的事情；
   这句话摆在这里，我想没有一个人会认可，但在实际情况中，却经常能发现这种想法的影子。我曾经参与过一个项目，软件需求和设计已经变更了多次，但测试用例却没有任何修改。导致的直接结果是新加入的测试工程师在执行测试用例时不知所措，间接的后果是测试用例成了废纸一堆，开发人员在多次被无效的缺陷报告打扰后，对测试人员不屑一顾。
   这个例子可能有些极端，但测试用例与需求和设计不同步的情况在实际开发过程中确是屡见不鲜的，测试用例文档是“活的”文档，这一点应该被测试工程师牢记。

4、测试用例不应该包含实际的数据；
   测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具有指导性的意义，不具有可执行性。当然，测试用例中包含输入数据会带来维护、与测试环境同步之类的问题，关于这一点，《Effective Software Test》一书中提供了详细的测试用例、测试数据的维护方法，可以参考。

5、测试用例中不需要明显的验证手段；
   我见过很多测试工程师编写的测试用例中，“预期输出”仅描述为程序的可见行为，其实，“预期结果”的含义并不只是程序的可见行为。例如，对一个订货系统，输入订货数据，点击“确定”按钮后，系统提示“订货成功”，这样是不是一个完整的用例呢？是不是系统输出的“订货成功”就应该作为我们唯一的验证手段呢？显然不是。订货是否成功还需要查看相应的数据记录是否更新，因此，在这样的一个用例中，还应该包含对测试结果的显式的验证手段：在数据库中执行查询语句进行查询，看查询结果是否与预期的一致。

作者: jiping_xu 时间: 2004-12-21 16:13
标题: 千真万确
写的很好不错
本人受益非浅，我以前对测试用例的粗细程度总是迷茫
现在醍醐灌鼎

作者: atce 时间: 2004-12-21 16:35
2、测试用例应该详细记录所有的操作信息，使一个没有接触过系统的人员也能进行测试；

这个问题的关键在于区分测试分析和测试执行. 多数公司是不区分的,当然不用太详细拉.

作者: sunflowers 时间: 2004-12-22 10:01
楼主说的很不错，测试用例的好坏对测试过程有很多的影响，，怎么设计有效的测试用例也是测试过程中的一个难点，测试用例的编写不仅包括测试用例的输入，步骤，预期的输出结果，而且在设计测试用例的过程中还应设计相应的测试数据。预期的输出结果中还可能包含隐藏的输出结果。
所以，如果软件的需求了解的还不输入或者需求写的不是很明确的话，，设计一个有效的测试用例恐怕是很难的。

作者: 关河 时间: 2004-12-22 10:52
标题: 谢谢大家支持，最近我会写一系列关于软件测试的文章
包括测试计划、测试实施、测试人员如何处理与开发人员的关系、测试团队的组织等等

作者: 关河 时间: 2004-12-22 10:54
标题: 呵呵，忘了说明了
改了名字：）

决定不叫dennis_d，用关河的名字

作者: jackei 时间: 2004-12-22 16:20
已经加入精华贴，希望关河朋友可以为大家提供更多更好的文章^_^

作者: twinkestar 时间: 2005-1-1 17:59
写得不错，揭出了实际工作中的一些误区，很有参考价值

作者: xjtuzxq 时间: 2005-2-5 14:55
同意！

就我这段时间的工作经历来说

测试用例写的比较简单，很多连设计测试用例的思想在用例上面都没有得到体现

作者: alfra 时间: 2005-2-5 19:46
标题: ：）
全然不顾实际的资源情况，一定要写出“没有接触过系统的人员也能进行测试”的用例。

这也是没有办法的事情啊。

作者: xuerzj 时间: 2005-2-22 17:53
写的很好，有同感呀。我们的测试用例书写的一个要求就是不要写得太细，不要把一个个步骤都写下来，那样维护量会大的惊人，而且对操作很熟悉的人去读繁琐的操作步骤是一种煎熬。我们要求使用用例的人员是经过业务培训对软件功能熟悉的人。我们也要求对于复杂的业务功能测试用例中要写明验证某表某字段的数据，书写保存成功这样累似的校验点是没有意义的，因为是否真的正确没有验证到。

作者: awpfinal 时间: 2005-2-28 19:09
谢谢楼主
刚刚接触测试，感觉对测试用例的设计详细程度无法把握好，看了这片文章收获不小，以后要多向各位高手学习。

作者: 飘雪 时间: 2005-4-8 13:04
写的挺好，我在实际工作中也遇到了此类问题。

作者: 老牛 时间: 2005-5-7 09:22
测试用例若不用写那么详细的话，是否将测试用例定位为测试作业指导书，这样是否更合适一些。这样不要太多的精力去维护测试用例，因测试用例就算很详细，也不能包括测试的所用内容，所以还是将测试用列写成具有指导性的，这样测试用例就会有较大的灵活性

作者: 云层 时间: 2005-5-12 10:52
写到了一些点子上，对于新手可能一下明白不过来

作者: test_zh 时间: 2005-5-17 11:13
学习中体会

作者: zension 时间: 2005-5-17 11:58
受益非浅，第五点我是和作者不谋而合了，哈哈

作者: luckhj 时间: 2005-5-18 16:00
写的很好，支持

作者: 浪漫小站 时间: 2005-5-19 12:34
楼主说得很对，其实好的测试用例并不是真的那么容易写的。我在短短的工作也遇到过同样的问题

作者: gg 时间: 2005-5-31 09:10
测试用例应该是随着开发不断尔变的把

作者: 山风寂寂 时间: 2005-6-4 16:10
4、测试用例不应该包含实际的数据；
测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具有指导性的意义，不具有可执行性。

对于这点在实际项目中的可操作性，我有很大的疑问。
就我自己目前测试的项目来说，每一个表单的操作都涉及到十几二十个的字段输入域，如果要对每一个输入域建立完整的测试数据用例，还有某些字段间的组合输入情况，那单单一个新建功能就会产生一个庞大的测试用例。而项目时间往往不允许这样做。
这是我一直以来的困惑，目前我们公司的实际做法就是类似于生成指导意义的测试用例，没有具体的测试数据，只关注主要逻辑。所以，在测试执行时，就在很大程度上依赖于执行人员的个人测试素养和经验，具有相当的风险。
书上的理论总看得人热血沸腾，但实际操作时却常常发现有心无力，如何理论实践结合是个难题，很想学习借鉴大家的做法。

作者: jackei 时间: 2005-6-7 08:50
一个完整的测试用例应当是由测试步骤和测试数量这两个不可分割的部分组成的。
在以往提到的测试用例中是否包含测试数据的话题中，可以明确的是在测试步骤中可以不包含测试数据，而将测试数据参数化，然后每个测试用例中应该包含另一个表格，其中对应到步骤中的各项数据。如果出现变更，应当同时维护。

作者: k0c0b0 时间: 2005-6-7 20:22
写的不错，一见地

作者: zibeikehappy 时间: 2005-6-8 14:45
学习学习

作者: Hellen_lyy 时间: 2005-6-11 09:09
标题: 也来凑个热闹！
我们公司目前在规范开发和测试工作，我在写测试用例的时候写的很详细，但在执行过程中，才发现，原来，花了很长时间完成的测试用例，有的甚至于花了几分中就执行完了。
楼主说的对，既然是对系统非常熟悉的测试人员执行测试用例，就没必要写得过于详细，写重点的就好。
感谢楼主！

作者: 木乃伊 时间: 2005-7-7 11:27
要覆盖需求真难！
有些需求上没写，但业务上要注意的问题，这就很麻烦！

作者: niceleafage 时间: 2005-7-20 15:03
to dennis_d:
把测试过程中测试用例设计所遇到的问题（或者说误区）写的非常客观，本人也是深有体会；对于编写测试用例有时的确很难把握：写的简单吧担心别人看不懂，写的详细吧，感觉比较琐碎，费时；所以想请dennis_d给出一个测试用例编写的比较好的方法，多谢！（如果其他人有好的编写测试用例的心得、经验、方法，请贴出来大家一起共同学习！）

作者: dolphin90 时间: 2005-8-4 15:34
最近想把公司的测试用例库建立起来
真正做的时候才发觉不是那么容易
把测试用例写好难
把测试用例管好更难

作者: dolphin90 时间: 2005-8-4 15:36
最近想把公司的测试用例库建立起来
真正做的时候才发觉不是那么容易
把测试用例写好难
把测试用例管好更难

作者: null2 时间: 2005-8-4 15:54
同感，测试用例不要写了太详细，要留给测试执行人员以发挥的空间。

作者: 测试有前途 时间: 2005-8-9 14:40
对第五点测试用例中不需要明显的验证手段；
照楼主说来，那测试用例中是不是要把预期结果写得很详细方方面面都要照顾到呢？

请楼主赐教

作者: secat 时间: 2005-8-11 15:15
刚写完测试用例，虽然不是很想写，但为了交差还是写完了。
很同意作者的看法，不应该有详细的测试数据，简单描述即可，否则写的太累、维护也太累了。至于验证我是尽可能的写的比较详细，当然不用把能验证的都写出来，把关键的写出来就可以了。例如新增数据，可以去数据库中查询，也可以到其他可以查询该记录的模块查看，能写到根本，可以验证其正确性就可以了。
但是我一直担心我的这种做法能不能得到上级肯定，要求我写，但发现没人理，郁闷啊！俺的口才不好，不知道等他们发现简单时会不会来找我麻烦，我可说不过他们：（

作者: jsfzdd 时间: 2005-9-5 11:19
4、测试用例不应该包含实际的数据；
5、测试用例中不需要明显的验证手段；

对于我们公司不太可能遵守，因为根本就没有正规的测试人员，随便从生产线上拉一批人就测试，对于实际的测试数据要他们自己发挥实在有些牵强，让他们到数据库中使用SQL语句查找更是不可能的了，所以说实践和理论总是有差距的。

作者: sara_li 时间: 2005-9-8 09:53
受益匪浅，谢谢

作者: littleqiang 时间: 2005-9-8 15:06
qiang

作者: SayeWang 时间: 2005-9-9 09:26
顶不错

作者: nanayulin 时间: 2005-9-9 16:35
我觉得测试用例没必要写那么详细，因为即使对系统不熟，但起码的测试经验还是有的，所以应该可以执行，这样可以减少很多工作量，因为很多项目都是很急的，容不得测试人员写的那么仔细，无奈之下的选择

作者: Amsure 时间: 2005-9-15 14:36
我前几天就遇到很麻烦的问题，我们写的测试脚本跑在自己开发的框架下，提高了测试的效率，但是上面说看不懂，要写文档，最后还补了大批的文档，唉～～～郁闷，其实文档只是个形式上的东西，我们最精髓的脚本没有人看。

作者: jtiger 时间: 2005-9-21 17:41
非常之赞同，接触测试一段时间了，用例的详尽程度是最困扰的事情。

作者: sogoc 时间: 2005-9-23 15:57
4、测试用例不应该包含实际的数据；
这个我觉得楼主有点问题，不应该有实际数据那应该有什么？没实际数据怎么对比BUG的存在呢？

作者: egg_ch 时间: 2005-9-26 11:13
标题: 受益匪浅
受益匪浅，顶。

作者: bigmeg 时间: 2005-10-12 10:13
谢谢,收到

作者: bigmeg 时间: 2005-10-14 16:41
确实不错

作者: vivianonion 时间: 2005-10-21 13:29

Originally posted by xuerzj at 2005-2-22 17:53:
写的很好，有同感呀。我们的测试用例书写的一个要求就是不要写得太细，不要把一个个步骤都写下来，那样维护量会大的惊人，而且对操作很熟悉的人去读繁琐的操作步骤是一种煎熬。我们要求使用用例的人员是经过业务 ...

同意楼主的看法！

作者: haiyan_1027 时间: 2005-10-21 15:06
又学到了不少

作者: cuijy 时间: 2005-10-31 22:08
同意楼主.
写用例跟写代码差不多,要写的别人看得懂才可以.步骤的繁简需要大家约定和项目经理要求.
如果写的太繁琐.不如直接写自动脚本了.

作者: mofan118 时间: 2005-11-3 10:16
呵呵..学习学习..

作者: mofan118 时间: 2005-11-3 10:20
我也是刚刚进入公司做测试的.我没有接触过.也没有经验.现在公司叫我写测试用例和测试计划.我之前一直都在看测试这方面的知识..也在网上看到一些测试用例的例子..现在我的脑海中一片乱..公司的开发人员说.每一块模块都要测试.那是不是每一块模块都要有自己的测试用例.或是进行一个复盖测试就行了?这样可以么?请教一下.

作者: cuijy 时间: 2005-11-13 22:58

原帖由 山风寂寂 于 2005-6-4 16:10 发表
4、测试用例不应该包含实际的数据；
测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具有指导性的意义，不具有可执行性。

对于这 ...

=================
既然数据之间有关联关系,就应该进行分析,变成一个新的用例. 一个成功新建功能从场景上是一个,但输入的不同对划分为不同的等价类,从而要用不同的用例来覆盖.

作者: 983221wy 时间: 2005-12-6 10:13
学习学习！！！

作者: harold_zou 时间: 2005-12-10 14:08
不错，值得反复学习，思考……

作者: 茶叶 时间: 2005-12-22 16:46
标题: 没别的谢了！
;)

作者: angel20041021mm 时间: 2006-1-4 09:10
测试需考虑的还有业务的理解程度，建立在了解系统的业务理解之后的测试，简单且要素具备的测试用例才能收到好的效果。否则，工作的进行还是会有阻碍。我认为，测试人员在需求阶段就参与可以事半功倍

作者: Song 时间: 2006-1-4 16:51
标题: 继续学习
我们公司的产品通常一个界面有很多的字段需要录入数据，这样的情况，用例很不方便写的很细致，不知道哪位朋友可以指点我一二呢？

作者: chenlei9448 时间: 2006-1-4 19:58
真的很不错!好!

作者: Jerry.Wang 时间: 2006-1-5 12:46
标题: 回复 #1 dennis_d 的帖子
受益匪浅!!

作者: buchidonggua 时间: 2006-1-11 17:22
good

mark

作者: Ivan_wang 时间: 2006-1-23 13:20
楼主总结的非常精彩,但是我有不同的看法:
1.测试用例设计是一劳永逸的事情；
这句话不能说完全不可取,(我对移动嵌入式设备的系统测试比较熟)就拿NOKIA来说,它们的产品具有很多的共性.
简单说一下NOKIA的产品范围:主要分为CUI S30 , ISA S40 ,SYMBIAN S60 , N SERIES , E SERIERS , VIRTU .这些产品是根
据不同时期,不同客户的需求而产生技术与外观上升级得来的.而这些产品的CASES也是重最初的CASES框架搭建起来
所以我认为CASE的最初设计很重要,可以起到一劳永逸的作用.当然一尘不变是不可能.在产品设计与需求变更的情况下,CASE肯定要更新,但是改动不应该很大.不然会影响整个项目的进度.其实对一个管理先进的公司来说,他们的项目
划分的很细,也很清晰,除非有新开发的项目或是为了市场竞争而必须要重新定位产品,这些公司是不会轻易改变原有
的模式.楼主说的CASE就是这个框架的重要元素.它是TESTER判别产品的标准,所以我觉得一个好的CASE框架是一劳永逸.
2.测试用例不应该包含实际的数据
CASE也不能完全包含实际数据,我认为包含的实际数据是有一定特点的:
比如数据具有隐蔽性,测试人员很难TOUCH到 ,标准数据(这个很重要,它是判别产品是否按设计标准来开发的).这些是
CASE中应该要具备的,且不可缺少的.但是在MEMORY LEAK TEST中我们是不能限制TESTER具体输入什么数据,输入多少
次,这样做TESTER的IDEA会被BLOCK掉.限制了TESTER的思维对压力测试的效果会有很大的影响.这就是为什么会有
FREE TEST.所以CASE千万不能太过于限制.一个好的CASE既要有标准,还要灵活.

呵呵,就这些,其它的几点我也和楼主观点一样.

作者: shark_jr 时间: 2006-2-11 13:38
最近正在研究这问题，希望能多多交流。

作者: tuzi 时间: 2006-2-13 18:13
很想学习学习各位高手的测试用例的编制样板，新手刚来，请各位赐教！

作者: wangyang 时间: 2006-2-19 14:21
能给我一份详细的测试用例模板吗？我也是个新手，邮箱是wanghu344@sohu.com

作者: yorkiny 时间: 2006-2-20 16:10
确实不错

作者: oscar_wang0721 时间: 2006-2-22 15:37
很不错的帖子，支持楼主继续发这样的帖子啊

作者: 52test 时间: 2006-2-25 20:48
不错，看来楼主是有过亲身经历的呀。书上讲的是理论，这种从实践中来的经验往往更直接而且有效。谢谢楼主讲经验与大家分享

作者: fengs 时间: 2006-3-3 16:17
现在我个人觉得CASE的编写详细/简单是要根据情况而定的，如果要赶进度可能就会很简单

作者: shuimeng0409 时间: 2006-3-5 12:25
标题: 还好了
宋体
就是这样了，我是个新学生，这个对我来说用途不小的，谢谢了啊，希望可以在这里找到更多的好东西吧

作者: jhq2032 时间: 2006-3-6 22:09
有很好的指导作用，我现在在工作中写的用例都可以说不叫用例了，我只是把功能上的一些要实现的东西写出来了，说明要输入些什么样的类型的值，字段类型控制的长度等等，而没有把要输入的实际数据写入到测试用例中，因为公司小，只有我一个人测试，所以用例就没有按照一定要有测试数据写入到我的测试用例中去了，这样行吗？？如果真的要把测试数据写到用例中去，那怎么来判断这个用例是否是有效的测试用例呢？我真的很想看看具体的实例啊？
谢谢！！

作者: jhq2032 时间: 2006-3-6 22:23
标题: 测试用例设计方法讨论
有一个问题想和大家讨论，你们在写测试用例的过程中，真正的会用到那些写黑合测试用例的方法吗？比如等价类，边界值，因果图法等等呢？？（因为我公司只有我一个人测试，我写的测试用例对我自己只起到指导作用。）一般情况下，我只用到了等价类和边界值，因果图这个方法我一直都不怎么会用，还有一个是根据场景来写测试用例我也不是很清楚，虽然看过写简单的例子，但是我总觉得运用到实际的工作中就有问题，希望大家一起讨论，学习，共同进步，帮帮我吧！先谢谢你们了！！！！

作者: 粉色的小猪 时间: 2006-3-9 17:45
up

作者: jhq2032 时间: 2006-3-9 21:53
赞同楼上的观点！

作者: songhongli_cong 时间: 2006-3-15 17:32
今天算是寻到宝了，刚入门的我在这里找到了我需要的东西，谢谢

作者: leikj 时间: 2006-3-17 16:55
顶顶顶顶

作者: qingshui47 时间: 2006-3-31 20:07
谢谢啊,写的挺好,以后有机会一定向你请教,请多多指教.

作者: aricone 时间: 2006-4-3 17:49
标题: 多数公司存在这种情况
这种误区是不是由于一些相关人员对测试的理解不足？或者本身就没明白什么是测试？
现在的情况是，测试方面的基础知识越来越不扎实，往往懂的似是而非，就想向更高层次跨步。

作者: tester-dd 时间: 2006-4-6 13:24
楼住的帖子很好。多谢了。
对于测试用例是具有可执行性还是指导性的问题，我一直都有些困惑。写的很细致不大可能，比如输入什么，怎么执行，然后输出什么。这样虽然可执行，但是对测试也是一种限制。
另一方面，我要是写输入一个数据，如何执行，得到一个结果。这样的用例，不同的人执行出来不一样，有些能发现问题，有些则不行。
所以，写测试用例时候的这个详细度不是很好把握。

作者: cheshizxq 时间: 2006-4-17 20:53
写的不错。
我觉得测试用例中的数据是可变的。只要符合条件就可以了。如果给的过于详细，就使测试人员只使用这些数据了。如果设计测试用例的人出错了，就导致其他使用这测试用例的人也发现不了错误。

作者: killall 时间: 2006-5-11 14:47
我带了好几个项目，并且每个项目都编写了测试用例，但是没有哪个项目真正按照那个用例来执行的，尽管每个项目结束后总结并不断的改进测试用例的编写方式，但到目前为止，相对前期的几个项目我们编写的测试用例已经相对比较简短，起到的唯一作用就是让新来的测试工程通过阅读测试用例快速的对系统有个大概了解，而实际测试过程中我并不主张项测试工程按照测试用例来测试，因为很多逻辑性的也就是比较严重的问题按照我们当前的用例是测试不出来的，只能束缚测试工程师的思路。
所以想请教大家以下几个问题：
1、怎么样才能将逻辑性测试的用例写到测试用例文档中；
2、在项目组提供的需求描述很模糊的情况下，怎么样才能提炼并设计正确的测试用例？

作者: jotun 时间: 2006-5-15 16:50
谢谢····不错！有收获，正在为怎么设计好的测试用例发愁呢。

作者: CONNIE06 时间: 2006-5-18 11:40
楼主说得很好! 用例太详细对测试人员反而不好,因为那会太依赖于测试用例,没有根据业务去多考虑问题

作者: 鲁西西 时间: 2006-5-18 16:06
同感!同感!原来的同行的困惑是同样的!说说我的困惑吧:
我们所以公司在做案例时也花了大量的心血，开始只是将简单的功能点列出来，测试过程中，发现这个案例没有指导意义，对于功能测试的把握靠测试员的责任心和测试技巧。后来呢，又走了另外一个极端，写的很详细，依据界面把所有能想到的功能点都写出来，案例数量惊人，从写完的那天开始，一直无人使用，也没法进行下一步维护，现在呢想修改，又不知如何下手，希望各位同行多多，多多提意见。
对于案例在测试过程的究竟起什么样的作用？不知大家的高见如何。

作者: Ronn 时间: 2006-5-18 22:25
《Effective Software Test》在哪儿有下呀？

作者: Timmy_love 时间: 2006-5-19 14:08
测试用例一直以来都将是测试过程中的重点.............

作者: Joy_z 时间: 2006-6-7 20:33
好贴，顶一下。。。

作者: ihwks 时间: 2006-6-9 15:19
标题: 晕了
文章要看就看仔细点，走马观花会害人的。

LZ的每项的第一句话，正是他要反驳或者是要分析的，可不一定是他所持的观点,别给搞错了，自己误导自己.

作者: JPeanut 时间: 2006-6-11 15:04
^_^,,原来是我大哥来法帖了,,顶一个先

作者: liulanjiao 时间: 2006-6-11 15:59
学习学习
覆盖率既然是个率那只能说去慢慢提高呢，不可能完全达到的。至少以我的能力是不能的。呵呵
谢谢楼主

作者: 枫飞林 时间: 2006-6-23 16:30
写的非常好，可是中国的软件公司啊！不知道什么什么好啊！要不就是不给我们测试人员需求，要不就不给设计，他们大都不会给你数据库的，你就根本不知道到底什么数据存在什么表里面，什么时候什么字段置位

作者: letutu1227 时间: 2006-6-24 17:01

原帖由 Amsure 于 2005-9-15 14:36 发表
我前几天就遇到很麻烦的问题，我们写的测试脚本跑在自己开发的框架下，提高了测试的效率，但是上面说看不懂，要写文档，最后还补了大批的文档，唉～～～郁闷，其实文档只是个形式上的东西，我们最精髓的脚本没有 ...

不认同楼上的观点，一个软件，脚本，代码好不好不单单取决它的执行效率，它的可移植性，可读性，文档都是非常重要，一个程序再好，移植性不好，语句晦涩难懂。也难以生存下去。而文档（注释）就是对其最好的补充。缺少了文档的产品就不是一个完整的东西。如同一个人失去对声音大小以及颜色的辨别。

作者: godn_1981 时间: 2006-6-29 11:26
标题: 不错
sdlkfj3，楼主说的蛮好。

作者: jiessiemao 时间: 2006-6-29 17:15
标题: 看了之后有点感受
如题

作者: philex 时间: 2006-7-7 13:44
写的的确不错！从中也学习了点点！加了你的GMAIL有机会聊下啊！

作者: bosom_friend 时间: 2006-7-7 15:56
挺好的。

作者: jiangxinlu 时间: 2006-7-12 15:27
我觉得在设计测试数据时，我们只是需要总结对于某个功能点的数据集合类，不需要把它写的非常详细，这样测试用的可重用性太差

作者: llmm0409 时间: 2006-7-20 16:19
4、测试用例不应该包含实际的数据；

有实际数据，会使用例的维护很困难。但我认为如果没有发生需求点的变动的话，这个是让不懂系统的人最好上手的一种方式。

没有实际数据的话，用逻辑语言描述的话，我认为是对spec 的一种分化表述，同样存在需求点变化导致该用例的生命周期的问题。

作者: guanweirong 时间: 2006-7-21 23:42
我想请问一下,什么才是写的很详细的测试用例,什么是写的简单的测试用例?

作者: 王娇龙 时间: 2006-8-4 08:21
“用例还应该包含对测试结果的显式的验证手段：在数据库中执行查询语句进行查询，看查询结果是否与预期的一致。
“非常赞同！

作者: lingchen2008 时间: 2006-8-7 15:53
标题: 实际的测试数据也是很不错的

原帖由 sogoc 于 2005-9-23 15:57 发表
4、测试用例不应该包含实际的数据；
这个我觉得楼主有点问题，不应该有实际数据那应该有什么？没实际数据怎么对比BUG的存在呢？

个人认为：实际的测试数据也是很不错的；

作者: 11034 时间: 2006-8-7 18:16
不熟悉业务,写不错好的用例的.

作者: jeloss 时间: 2006-8-17 15:54
不错的文章，可也有一点偏颇

作者: 杀手太冷 时间: 2006-9-7 17:04
爽哈！！又学到了东西了！！

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