51Testing软件测试论坛

标题: 测试用例可以不写吗? [打印本页]

作者: xzl 时间: 2006-3-22 17:10
标题: 测试用例可以不写吗?
我做的测试主要是基于WEB测试.在公司因为从事测试的人很少,或者说就是我一个.为了速度,我通常不写测试用例,这样可以多有时间去学别的东西.我们领导也没有要求我写测试用例,或许他们在这方面也不太懂.所以测试的事完全是我一人说了算,他们也不过问.BUG当然要写的,就是这种情形,公司没有出现什么大问题,而且每次也能发现很多BUG.我现在就想写下,可以扩展自已的能力.要是让我写,我肯定也能写出用例来,现在情况是没有写用例的必要.要是坚决要写的话,那肯定就是累我一个人了,而且有时不能保证速度.这种情境下需不需要写用例.需要说明的是,我对这些板块比较了解,而且自已以前也做个开发这方面的.但是不写,总觉得少了点东西,当然测试报告也不用写.所以说,大家说说,这样的情况要不要写测试用例和测试报告呢?

作者: 慢慢变胖 时间: 2006-3-23 09:20
这只是做事的方式方法问题，如果你觉得自己能够不写test case也能够做好测试，为什么要写呢？
这时候即使你去写，也许只是面子工程而已，不能够带给人或者自己任何好处

作者: baitest 时间: 2006-3-25 22:52
测试用例作为软件生命周期的文档，和需求、设计文档并重。有些公司已经将此作为里程碑的产物，不是可有、可无。我们不要忘记：软件产品是给别人使用和维护的对象，是给客户交付的物理产物。

作者: 慢慢变胖 时间: 2006-3-27 10:17
什么是软件生命周期，现实之中没有文档的软件产品我想是大把，为什么存在（存在即是合理），为什么我们要用同一把尺子来度量？
不要忘了，在楼主的这个阶段，测试文档其实毫无用处

作者: edwin_chen 时间: 2006-3-27 18:50
其实怎么说呢，如果你想做好，那么就设计测试用例。如果只要一般就好了，那么当然也没有必要。
当然，个人觉得设计用例是很happy的事情。
从你“测试用例可以不写吗?”这句话中用的这个 “写”字，就知道你做测试不专业。

作者: xzl 时间: 2006-3-29 21:47
我知道是设计测试用例,但我觉得写没什么不对,在我的意思中这是相同的表达.本人测试还是新手,也许连新手都算不上,所以最近参加了一个为期六个月的带薪脱产培训班,希望自已以后能把测试做的更好.

作者: youshayun 时间: 2006-3-30 16:21
个人觉得测试用例一定要写，而且测试用例其实也是对一个测试项目的总结

作者: 婧颦 时间: 2006-3-31 09:50
其实，我觉得，测试用例可以不写，但是前提条件是你脑中已经想好了测试的流程和目的。我就经常是把想法放在脑子里，测试用例只是最简单的一部分思路。因为在现在的开发流程里，将你所有的想法写出来后，动手时间就少很多了。

作者: 婧颦 时间: 2006-3-31 09:53
以前测试时一个新版本有大概三个月的时间，我总是感觉不够用，现在的公司一个新项目包括所有用例编写只有一个月时间，还要写很多总结，所以，有的时候，还是要因地制宜的想策略。

作者: iMaC 时间: 2006-3-31 20:42
精辟！
不要太拘束了，毕竟理论只是纯理想化的，现实跟理想化还是有很大的差距，能结合实际就是最好
较少的聪明的人就是，能创造出好的方法让自己能轻松出色地完成工作

作者: edwin_chen 时间: 2006-3-31 22:28
前面几位说的太有道理了，学习中

作者: xiaduo 时间: 2006-4-1 17:41
hehe 楼主，如果你能在这个阶段这种情况下将测试的文档管理体系建立起来的话，那么你以后就不是简简单单一个做web测试的小员工了。这个就是潜在机会，很多时候，机会是要自己创造的，设想该公司的测试体系，标准全部都由你来订制，那么你对于公司的价值就不是那么简单了，当然了，看清楚公司的发展潜力也是十分重要的

作者: xzl 时间: 2006-4-1 20:54
现在可能没有时间去测试体系吧,因为一直没空.星期一到星期五都要去培训.几个月培训完成后,以后会慢慢让它走上正轨的.这急也急不来,只有让时间去解决了.

作者: xiaduo 时间: 2006-4-1 21:09

原帖由 xzl 于 2006-4-1 20:54 发表
现在可能没有时间去测试体系吧,因为一直没空.星期一到星期五都要去培训.几个月培训完成后,以后会慢慢让它走上正轨的.这急也急不来,只有让时间去解决了.

恩。培训完了之后应该能够更加系统的管理自己的测试文档。一定要文档化正规化阿

作者: huangsh2004 时间: 2006-4-4 20:10
想做得专业一点呢，就尝试写写测试用例吧，那样你的测试设计能力会慢慢提高的。我们现在是测试需求、测试用例、以及测试流程都得考虑。

作者: 慢慢变胖 时间: 2006-4-6 09:09
不同的项目各有不同，不能拘泥于我们认为所谓的必须要有的咚咚
应该从自己的测试计划来看，你是怎么定义你的整个测试周期的，如果你有一个专门的spec的阶段，
每个阶段有自己完成的标志，那么你应该提交你的spec.也就是test case了，
如果你的整个周期只是一个阶段，就是完成测试，其实你的完成标志是你测试的出口
比如完成所有已经计划的测试（并不一定非要case才能做测试），或者已时间作为标志

作者: JPeanut 时间: 2006-4-10 15:53
感觉首先一点，测试用例文档的编写是设计测试，整理思路的过程，不经过用例文档的测试，除非是小项目，否则，很多把测试做的全面。
其实,文档可以作为测试人员工作的表现.

作者: RP☆玲 时间: 2006-4-10 22:40
咳！
没有测试用例的测试不是正规的测试。。。
不过能够体谅在公司里就一个人做测试是很辛苦的。。。

作者: yongjun4 时间: 2006-4-11 10:55

原帖由 慢慢变胖 于 2006-4-6 09:09 发表
不同的项目各有不同，不能拘泥于我们认为所谓的必须要有的咚咚
应该从自己的测试计划来看，你是怎么定义你的整个测试周期的，如果你有一个专门的spec的阶段，
每个阶段有自己完成的标志，那么你应该提交你的spe ...

恩，我觉得理论固然重要，但是也要结合实际

作者: xzl 时间: 2006-4-11 21:35
测试越早介入越好,而我一般这个小项目刚完成,那个项目又完成了.这样,搞的人都是在救火,根本没有时间让你去设计测试用例什么的,有时实在忙不过来,只能从服务部抽调一个人过来应付.但总是谢天谢地没有出现什么大问题.现在正在考虑招人,因为我每天现在只有晚上加点班,那更是可想而知的压力了.但我们的优势是跟开发人员有很好的沟通,自已以前做过开发,跟他们混的很熟,他们也经常替我着想,尽量减少BUG,还有一个经验就是,不论怎么忙,但是客户谈需求的时候或是开需求讨论会的时候我一定会在场.不在的时候,我也会问技术总监或是项目负责人那里拿需求,或是听他们解释下需求.其实现在我的观点倾向于测试用例有条件写的时候尽量写,实在没办法的时候,那只能望而兴叹了.

作者: slide 时间: 2006-4-11 21:56
以现在的条件来说，你做的非常好了。对你来说，写测试用例的意义并不是很大，目前来看是弊大于利。
但以后呢，有没有想过？

如果新来了员工，怎么分享你的测试经验？
回顾从前测试时，怎么能够复现当初测试的细节？
该怎么针对那些仅仅存在于你思想中的用例进行整理和改进？

相信当你们项目的规模慢慢扩大，任务越来越多的时候，你会发现，测试用例的必要性。
当你感觉有了必要的时候，再写不迟，现在，有时间的话，不妨先想想，怎么写测试用例才更好呢？

欣赏楼主这种多思考、多实践的精神，工作的时候必须要根据自己实际的情况来选择合适的方法，而不是人云亦云。

我觉得首先要解决好手头的问题，才能考虑到下一步的发展，这是一个基本的工作原则，好高骛远是要不得的，当然，埋头工作的时候，不妨抬头看看，多想想未来，这样，真正到了合适的时机，很快就能上一个台阶。

作者: xzl 时间: 2006-4-12 20:04
经典,学习中,受益!

作者: yuhuawang 时间: 2006-4-14 11:12

原帖由 slide 于 2006-4-11 21:56 发表
以现在的条件来说，你做的非常好了。对你来说，写测试用例的意义并不是很大，目前来看是弊大于利。
但以后呢，有没有想过？

如果新来了员工，怎么分享你的测试经验？
回顾从前测试时，怎么能够复现当初测试的 ...

说的不错，学习

作者: xiaoyu 时间: 2006-4-17 10:38

原帖由 slide 于 2006-4-11 21:56 发表
以现在的条件来说，你做的非常好了。对你来说，写测试用例的意义并不是很大，目前来看是弊大于利。
但以后呢，有没有想过？

如果新来了员工，怎么分享你的测试经验？
回顾从前测试时，怎么能够复现当初测试的 ...

非常有道理，谢谢～～

作者: 美丽现代人 时间: 2006-4-21 13:13
标题: 请问楼主在哪里培训呀，我也想去
多少学费，多长时间，谢谢

作者: hcf8319 时间: 2006-4-21 17:07
测试用例可以方便测试，节省时间精力

作者: rockday 时间: 2006-4-25 22:03
可以看情况挑一个主要的写一写也不会花太多时间
你现在的情况是不用写
以后呢？你能说你做测试这行一直不用写测试用例么

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