下了，看看

看看，好好学学！

引用:

原帖由 迎风 于 2005-7-7 11:41 发表


嗯，的确有这个问题，所以要将这个用例驱动的机制真正建立起来，所有用例都是在软件整个生命期内不断维护或增加的，当然，也是可复用或重构的。这样的话，用例实施人员就不单单仅是执行，而且是执行的过程 ...

优化时很重要的
不然会累死人的

从大家参与的程度可以看出目前软件测试行业现状，我们公司的测试用例也是采用这模式写的，比这个还要详细，我们还常常抱怨项目设计人员设计不够清淅。尽管软件产品质量由多方面的因素决定，但测试用例与测试策略还是可以反应出公司对产品质量控制的水平。因为测试用例越是详细可以反应出以下几个问题：
1.用例设计人员对此项目有充分的理解，有些可以反应出你是否知道软件底层是怎么实现的，而不是仅仅是表面上的功能实现。
2.说明你们公司至少按照一定的流程运作。比如在某个软件阶段必需有相应文档出来，越是详细的测试用例对这个要求很高。尤其是多个项目在同时运作的时候。
3.有了详细测试用例，在项目后期测试及验收时不用花很多时间去想应怎么测试才能保证软件质量。只要按照测试用例跑一遍就可以了。如果是大项目，参与人员很多，时间相对长一些，到了后期如果没有详细的测试用例，我想在测试时会漏一些功能。

测试用例状况其实主导它的不是测试部门，而是公司的制度、文化、流程、项目组的人员等。
1.测试用例有些软件公司对它认识不足，公司高层只是口号的支持。并没有从流程和制度上对测试部门的支持。当出现问题时在大会宣布测试是如何重要，但是实行开发至上，项目一切都是围绕开发人员进行。
2.公司不愿意在前期大量投入人力、物力的支持。主要是因为公司没有建立一套行之有效成本评估预算控制制度。对公司来说前期大量投入的人力、物力资源不如投入到后期维护上。而经验表明后期投入时成本是前期几倍甚至几千倍。
3.公司高层及项目成员对软件质量认识有偏差，他们认为软件质量好坏是软件测试人员的问题。只要交给一个产品测试就可以了，没有提供必要的文档资料和支持。这也造成软件测试用例不够详细的原因。
4.测试人员对它认识不够。认为花大量的时间去设计测试用例不如直接花在测试软件产品上。最后可能的结果是：当项目结束时，测试人员也不清楚到底软件所有的功能都能不能正常使用。

[ 本帖最后由 oscarli 于 2007-4-16 16:23 编辑 ]

好好学习一下

xiexie

有没有关于注册的测试用例

如果有用例的话
  帮忙上传以下
   谢谢
  或者发到我邮箱
   zhangmirong@126.com

我们刚学完测试的几本书
  现在开始试着写测试用例
   不是太懂
  希望大家可以帮帮忙
  呵呵

还不错啊，

噢我们公司只有案例纪录表，模板连个编号都没有

借贵宝地攒点人品

软件测试(美)Ron Patton/机...




`

仔细看看 再说 谢谢~！

仔细看看 再说 谢谢~！~

谢谢 感动

太详细的测试用例做完比写程序还累人花的时间也多,有点不不实际啊

成本是不是太高拉

同意2楼的