51Testing软件测试论坛

标题: 测试用例编写的最佳时间是什么时候呢 [打印本页]

作者: 咕嘟咕嘟 时间: 2004-12-9 21:18
标题: 测试用例编写的最佳时间是什么时候呢
希望各位前辈指点,在公司一般都是开发人员把成型的软件叫给测试组，才开始着手写测试计划和测试用例,这样一部分测试员就闲置下来，或是先行进行测试，但是这样写完的用例好象就不能准确起到什么作用了，不知道各位同仁的建议是什么呢，我觉得是不是应该在开发的末期,我们测试人员就应该介入软件的测试工作呀，比如按照用户说明书,编写计划和用例呢

作者: 肚皮 时间: 2004-12-9 22:59
最好的时间就是你测试还没开始的时候

作者: 肚皮 时间: 2004-12-9 23:01
至于你觉得在项目开发初期就开始的写的话，如果你写的出来就开始写吧

作者: someone5 时间: 2004-12-10 08:14
我们一般是在需求评审通过之后就开始编写测试用例。然后在设计说明会之后开测试用例说明会；之后再在设计评审之后进行测试用例的评审

作者: 丁琳 时间: 2004-12-10 09:13
楼上的高手，请问测试用例如何下手啊，5555晕！

作者: Lighthouse 时间: 2004-12-10 09:25
系统测试计划－－－－软件需求分析
集成测试计划－－－－子系统概要设计
单元测试计划－－－－模块详细设计
单元测试用例完成＝＝模块code结束
集成测试用例完成＝＝单元测试执行结束
系统测试用例完成＝＝集成测试执行结束

至于什么时候开始，就开工作量和人力的大小往前推。

作者: 咕嘟咕嘟 时间: 2004-12-10 09:53
谢谢大家
我们公司就3个测试员，我写用例，所以觉得应该在完全测试开始前就应该着手写了，但是没有需求说明书，只有一些用户手册，是不是应该根据手册来写用例呢，毕竟软件还没有到我们测试组

作者: mouse 时间: 2004-12-15 13:27
等软件到你受上再写用例不是太晚了吗，根据手册来写用例也写不完全，最好是从开发人员那里得到FD，根据FD来写用例^_^

作者: fly-bird 时间: 2004-12-15 15:29
标题: 说到测试用例
为什么我们从来不写什么测试用例呢？整个测试过程就一个模块，一段时间乱点一通，一份出错报告，over了，然后发给研发，然后发回来再这样测

作者: small 时间: 2004-12-16 17:54
标题: 我们也是的
我们也是的

作者: mouse 时间: 2004-12-21 10:29
如果是这样的话，真的很不规范啊，质量也很难保证啊！

作者: zwh_rxx 时间: 2004-12-21 14:36
我觉得测试用例这个问题，应该是从项目的概要设计出来之后，就要开始写了吧。不能到详细设计阶段！不过具体项目不一样，也有不同的情况。。。。。

作者: zwh_rxx 时间: 2004-12-21 17:00
其实有时候这个东西，得看具体情况的。。。。。

作者: 陈小红 时间: 2004-12-21 19:13
系统测试计划-系统测试方案-系统测试用例---需求分析文档
集成测试计划-集成测试方案-集成测试用例---需求分析文档/概要设计说明书
单元测试计划-单元测试方案-单元测试用例---需求分析文档/概要设计说明书/详细设计说明书
单元测试用例执行-测试报告-集成测试用例执行-测试报告-系统测试用例执行-测试报告

^_^我也没有按这个来做,努力方向.一般都是开发人员在开发时候开始写用例,写完了和开发人员一起评审,流程也不是很规范的.

作者: bugrobot 时间: 2004-12-28 11:35
标题: 请问楼上的什么叫fd?

作者: sunflowers 时间: 2004-12-28 15:41
需求评审完之后，就可以编写10％－25％的系统测试用例，每个测试阶段编写的测试用例也是不相同的。

作者: 迷路的小猫 时间: 2004-12-29 10:45
我们公司从来不作测试用例的评审，看来有待改进呀
测试用例是不是应该根据软件需求分析来写呀

作者: jakedd 时间: 2004-12-29 15:51
产品说明书compelte就开始写，开发code complete就写完开始正式测试！

作者: hxb1118 时间: 2004-12-29 16:17
和coding同步

作者: kpxl 时间: 2004-12-29 17:04
在需求确定之后就可以设计了，但是一直到你测试完毕都要不断的完善，以备以后之需。

作者: Nio 时间: 2004-12-30 10:14
规范是人定的，只要是人规定的就可以改。根据不同的情况，只要能完成测试任务，不必在意用例何时编写。

作者: little_student 时间: 2004-12-30 10:24
时间定在什么时候我不能说得很准，但是至少要在明白了整个项目系统的流程之后才有可能编写出来！

作者: jackei 时间: 2004-12-30 11:51
不知道咕嘟咕嘟朋友现在有没有找到答案，如果没有，我就说说我的看法，其他朋友如果有兴趣也可以参考。
等到产品已经基本完成时才让测试部门介入，恐怕也是现在相当一部分企业——特别是中小企业的做法，首先我们要明确，这种做法是不利于开展测试工作的。理想中的情况当然是在需求评审通过，并版本化以后，测试人员就开始整理测试需求并制定测试计划，之后可以开始测试用例的设计。（如果对这部分内容有兴趣，可以参考“[url=http://blog.csdn.net/jackei/archive/2004/07/20/45964.aspx][color=Red]测试需求与测试用例[/color][/url]一文”）
现在咕嘟咕嘟朋友的这种情况，现实已经是如此了，我个人认为还是优先考虑如何把测试工作开展起来，如果对系统业务不熟悉，那就要先学习需求，然后还需要有一段时间来运行已经实现的系统，来加深理解和认识，接下来在测试工作中，建议一边做测试，一边记录和整理所做过和想到的测试思路和方法，不要再去区分测试需求还是测试用例，也不要太关注于格式，而是要把思想保留下来。实际情况如此，就无法奢求太多，希望这些记录下来的东西可以对下一个版本的测试产生积极的意义吧。

[[i] Last edited by jackei on 2004-12-30 at 11:52 [/i]]

作者: wintersea 时间: 2005-3-14 14:23
jackei的观点很正确呀。
其实何时开始编写测试用例是取决于公司开发的流程的，如公司开发流程正规，
则就像jackei所说，在需求评审通过就可以开始整理测试需求并制定测试计划，之后可以开始测试用例的设计了。但各个公司的情况是不一样的，那么就要根据自己公司的实际情况来开展测试，但找到适应方法的同时，我想我们是有责任来提出建议使公司有正规的开发流程和测试流程。

作者: archonwang 时间: 2005-4-10 16:50
理想状态是：需求文档出现的那一刻，就是编写测试用例的开始。

作者: ecust 时间: 2005-4-10 17:28
开发和测试的顺序是相反的，你可以看看双V模型。
SRS评审结束以后就可以做ST用例了。

作者: 云层 时间: 2005-4-12 10:47
需求确认，尽可能早

作者: billhy 时间: 2005-4-13 11:22
在确定功能需求之后就可以开始了吧。
个人认为开发与测试不应该割断联系，
只要开发人员确定了需求及各模块的功能，
就可以开始设计测试用例了~~~~~~~~~

作者: aidaliu 时间: 2005-4-18 23:05
用例在测试过程种也会不停添加的

作者: walker_lai 时间: 2006-8-27 17:06
标题: 回复 #11 mouse 的帖子
收藏了！

作者: maoshan 时间: 2007-1-24 13:47
严格来说,需求规格说明书评审基线化后,就可以进行系统测试用例的设计编写了;现在国内的公司一般不做集成测试,单元测试也是在详细设计说明书基线化后,根据详细设计说明书进行单元测试用例的设计编写.
我是这么认为的sdlkfj2

作者: wentao_xiang 时间: 2007-1-24 18:06
测试用例是根据需求写的，而不是根据软件来写的，我认为只要需求通过评审，测试组就可能进行测试用例的写作与设计了，不是等到开发做完再按软件来写的，不知道我的理解是否正确！

作者: 寂寞圣贤 时间: 2007-3-20 22:16
标题: 感想
现在不是有一种叫ＴＤＤ吗？叫做测试驱动开发，那测试不就在开发初期进行编写了！

作者: chenxiao123 时间: 2007-3-28 21:08
标题: 回复 #1 咕嘟咕嘟的帖子
刚开始搞需求,设计时,测试人员就可以开始写测试计划了,针对于用户的需求规格说明书 .等到他们的设计完成阶段. 此时,你头脑中已经有了一个大致的框架你今后的测试工作如何进行! 在编码阶段时,时常和开发人员进行沟通,了解他的思路是否和用户的需求保持一致同时针对他写的那部分模块,编写测试用例 . 很希望和各位进行交流加我QQ哟 624603852

作者: guoxing0865 时间: 2007-4-3 15:01
做个记号

作者: wujp_652 时间: 2007-4-11 17:32
标题: 624603852
始搞需求,设计时,测试人员就可以开始写测试计划了,针对于用户的需求规格说明书 .等到他们的设计完

作者: applejuzi 时间: 2007-7-13 20:20
学习了

作者: 119139107 时间: 2007-7-16 16:10
领悟中。。。。。。。。

作者: syang0517 时间: 2007-7-17 09:04
8错顶一下

作者: qzai 时间: 2007-8-22 16:44
学习了

作者: dealeasy 时间: 2007-8-22 17:33
标题: aiit
作为新手，真的很幸运，遇到这么好的资料！！！

作者: guobinlv 时间: 2007-8-22 17:35
标题: 回复 #2 肚皮的帖子
应该是需求分析出来以后,这样应该会好点.

作者: ieee 时间: 2007-8-23 12:54
全新版本我们还是会在版本出来之前就写测试用例，但对于新增需求，通常都是版本出来以后才开始写，那时候测试任务才下来，这也是原因之一，后面看看能否与se商量一下，提前用例的编写。
有些流程普通测试人员也控制不了啊：）

作者: 泡泡糖 时间: 2007-8-27 11:05
根据双V模型,测试在SRS完成,评审,基线化了以后就可以介入,进行系统测试的计划,方案的编写,用例的设计.当概设完成,评审完,HLD基线化了以后进行的是集成测试的计划,方案的编写,用例的设计,依次类推...这样的好处是,当系统用例编写好以后,有足够长的时间可以进行补充,修改,只要在集成测试执行完毕前基线化了就行了.

  测试的计划,用例的设计这些都属于测试的准备活动,应该和开发环节结合和在一起并行的.等到开发讲代码完成,通过代码评审之后,便能直接进行单元测试(执行部分),集成测试(执行部分),和系统测试(执行部分).

  这些都是根据模型得出来的,但是模型毕竟是模型,它主要传达的思想无非就是测试应该全过程的参与,并且尽早的准备,才能尽早地执行.

  看来每个公司都有每个公司的流程啊,有的公司甚至还....~~看到前面的回复,我终于体会到了呢...既来之,则安之,进了公司要快速适应公司的流程,再结合自己,思考自己的测试工作如何能开展得更好,但是心里还是应该清楚真正的好的流程标准应该是咋样地,这样至少心里有个前进的目标.呵呵这是我看了这片帖子的小小感想~~

作者: lp1109ab 时间: 2007-8-28 17:08
标题: 需求完成就该写了
应该越早越好，根据需求，设计来写相应的用例吧

作者: owenyuan 时间: 2007-8-29 09:41
还不知道测试用例是个什么东西，瞎混，不知道公司要不要写，要编程吗，那就不好玩了

作者: yangbohustwb 时间: 2007-9-16 23:06
是的，看了大家的观点我个人认为测试用例是有必要写的，不然软件质量就无法保证。

作者: zzytion 时间: 2007-10-3 21:39
看了有启发

作者: icyfire 时间: 2007-10-13 13:10
一般是在需求分析之后就可以写测试用例了~

作者: guowei_3000 时间: 2007-10-14 16:32
根据书上的理论呢，应该在需求评审结束后，就着手编写测试用例了，但我们公司就从来不是这样的，都是说可以测试了，才来做这些的。

作者: cher_chiang 时间: 2007-12-24 10:56
领悟中。。。。。。。。

作者: AJMIAO 时间: 2007-12-25 17:44
现实中，许多公司存在这样问题，特别是小公司。

作者: melanqy 时间: 2007-12-26 13:23
新手，学习了

作者: ivyhuan 时间: 2008-1-2 18:09
只要需求有了，就可以根据需求来写测试用例了，这个时候开发人员也根据需求来编程，等开发人员编程完成了，发布了版本就可以将写好的测试用例来执行用例测试发布的版本。

作者: duhongze 时间: 2008-1-7 23:10
规范的流程如下：
在SRS基线化后，开始系统测试计划；
在概要设计基线化后，开始集成测试计划，系统测试方案，系统测试用例；
在详细设计基线化后，开始单元测试计划，集成测试方案，集成测试用例；
在编码走读后，开始单元测试方案，单元测试用例；

作者: duhongze 时间: 2008-1-7 23:11
规范的流程如下：
在SRS基线化后，开始系统测试计划；
在概要设计基线化后，开始集成测试计划，系统测试方案，系统测试用例；
在详细设计基线化后，开始单元测试计划，集成测试方案，集成测试用例；
在编码走读后，开始单元测试方案，单元测试用例；

作者: ivyhuan 时间: 2008-1-20 16:17
用例的编写最好是在开发部门拿到需求的时候，这个时候测试部门应该也有一份需求的，这个需求是经过评审后，开发部已经Accepted，测试部门也可以根据需求写用例了，等开发部门软件开发完成，那么这些用例就可以拿来执行了

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