总结项目中关于测试用例的问题

发表于:2008-9-16 14:51  作者:zhangtao   来源:51Testing软件测试博客

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 测试用例

  目前我们设计的测试用例只是表面上的呈现,对测试指导的作用不是很大,我们思想里也认为测试用例编写只是在熟悉系统的过程,在测试时测试用例会被我们撇在一边。个人总结一下原因和改进方法:

  1.  没有合适的规范:

  大家都是来自不通的公司,在编写测试用例时可能会带着以前的习惯,我们也没有在现在的项目中找到明确且合适的规范,于是只是根据自己以前的经验复制,但这些有时候并不适合我们目前的项目。比如在测试UUM时,个人自己就犯着以前不好的测试思维和习惯。

  改进方法:

  指定合理的规范,统一大家思维,有待讨论。

  2.  功能与业务分离:

  这个是在测试ES-iVision存在的问题,在测试系统时可能只关注了功能而没有整体业务的把握测试,只注重了某个功能表单上单一的测试,而整个业务可能才是我们测试的重点。

  改进方法:

  功能用例和业务用例分开组织编写。A)功能用例依据需求界面描述,根据等价类、边界值、错误推断编写,必要时建立数据库,存放测试数据,而这些测试用例都与业务无关。并且可以利用资源找到相关的测试用例,来补充我们设计的不足。B)业务测试用例关注的是表单的执行路径,执行后在系统上产生的一系列反应。这个可依据需求在开发前或与开发同时进行。但此业务功能必须是开发确认正确的。

  PS:以前我们在业务这块有场景测试用例。如发文流程中有多流程时,分场景测试流程。

  3. 测试跟不上变化:

  开发人员在开发时可能会对需求进行调整,这个问题是在测试UUM时系统管理角色需求就进行调整,所以我们被动的只能跑在开发的后面,我们也做了许多不必要的工作

  改进方法:

  有问题及时与开发讨论,走在开发前面调整我们测试用例,测试进度。

  4. 发布前轮询很多版本:

  某一产品在经过几轮测试后,在发布前可能会为一两个bug要轮询很多版本,在轮询时测试人员不可能再把所有功能、业务全部再过一遍,但是我们此时会对发布版本没有信心,而再走一遍浪费时间精力。

  改进方法:

  用用例标明测试优先级。这个是在oa1.9中用到的,但可能在后期执行时没有执行。所有在编写测试用时标示优先级,把系统的重点划分出来,在发布前多次轮询版本中只要检查优先级高的就可。

  5. 用例审核力度不够:

  编写的测试用例无人评审,这也是我们在编写测试用例的随意性、懒惰性滋生,草草了事,没有覆盖全部功能点、业务点。导致产品在发布后存在意想不到的缺陷。

  改进方法:

  测试用例编写完成后增强评审,先是小组里讨论,然后再外部评审。

  6. 易忽略问题:

  在执行设计测试用例执行测试,我们可能会忽略很多问题,如系统有安装包的安装测试、界面上一些细节什么的。

  改进方法:

  在网络上查找相关文档


本文出自51Testing软件测试博客,转载请注明出处:

http://www.51testing.com/?69074/action_viewspace_itemid_92813.html


评 论

  • 叶筱珊 (2008-10-08 10:06:03)

    很全面

  • 1qazse4 (2008-9-17 10:15:37)

    支持

  • 1qazse4 (2008-9-17 10:13:53)

    写得真好,真实际,我在工作中都碰到过这些问题
    尤其是:功能与业务分离;测试跟不上开发

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海瀛东律师事务所 张楠律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2020, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道