总结项目中关于测试用例的问题
2011-08-05 10:03
549 查看
1. 没有合适的规范:
大家都是来自不通的公司,在编写测试用例时可能会带着以前的习惯,我们也没有在现在的项目中找到明确且合适的规范,于是只是根据自己以前的经验复制,但这些有时候并不适合我们目前的项目。比如在测试UUM时,个人自己就犯着以前不好的测试思维和习惯。
改进方法:
指定合理的规范,统一大家思维,有待讨论。
2. 功能与业务分离:
这个是在测试ES-iVision存在的问题,在测试系统时可能只关注了功能而没有整体业务的把握测试,只注重了某个功能表单上单一的测试,而整个业务可能才是我们测试的重点。
改进方法:
功能用例和业务用例分开组织编写。A)功能用例依据需求界面描述,根据等价类、边界值、错误推断编写,必要时建立数据库,存放测试数据,而这些测试用例都与业务无关。并且可以利用资源找到相关的测试用例,来补充我们设计的不足。B)业务测试用例关注的是表单的执行路径,执行后在系统上产生的一系列反应。这个可依据需求在开发前或与开发同时进行。但此业务功能必须是开发确认正确的。
PS:以前我们在业务这块有场景测试用例。如发文流程中有多流程时,分场景测试流程。
3. 测试跟不上变化:
开发人员在开发时可能会对需求进行调整,这个问题是在测试UUM时系统管理角色需求就进行调整,所以我们被动的只能跑在开发的后面,我们也做了许多不必要的工作。
改进方法:
有问题及时与开发讨论,走在开发前面调整我们测试用例,测试进度。
4. 发布前轮询很多版本:
某一产品在经过几轮测试后,在发布前可能会为一两个bug要轮询很多版本,在轮询时测试人员不可能再把所有功能、业务全部再过一遍,但是我们此时会对发布版本没有信心,而再走一遍浪费时间精力。
改进方法:
用用例标明测试优先级。这个是在oa1.9中用到的,但可能在后期执行时没有执行。所有在编写测试用时标示优先级,把系统的重点划分出来,在发布前多次轮询版本中只要检查优先级高的就可。
5. 用例审核力度不够:
编写的测试用例无人评审,这也是我们在编写测试用例的随意性、懒惰性滋生,草草了事,没有覆盖全部功能点、业务点。导致产品在发布后存在意想不到的缺陷。
改进方法:
测试用例编写完成后增强评审,先是小组里讨论,然后再外部评审。
6. 易忽略问题:
在执行设计测试用例执行测试,我们可能会忽略很多问题,如系统有安装包的安装测试、界面上一些细节什么的。
改进方法:
在网络上查找相关文档
相关文章推荐
- 关于升级Xcode7后真机测试项目遇到的问题总结
- 【Tomcat】Linux下关于Tomcat部署项目的问题总结
- [总结]关于VS2002下的项目迁移到VS2005下相关问题总结
- .Net程序员关于微信公众平台测试账户配置 项目总结
- 关于Jenkins使用Gradle对android项目打包遇到的问题总结
- 关于audio元素在实际项目中遇到的问题总结
- 关于用户登录界面测试用例总结
- Java+Mysql做web项目中关于编码问题的总结
- 关于LinkedList和ArrayList的执行效率的问题的区别(测试用例)
- 项目q总结:关于Linux性能问题的一些思考
- 关于junit测试用例数据不回滚的问题
- 关于用户注册界面测试用例总结
- 关于软件测试用例生成技术相关研究总结
- java学习之路----项目经验----关于TOMCAT中文乱码问题的总结
- [项目总结]关于调用系统照相机Activity被销毁问题解决
- 关于TFS2010 远程无法创建团队项目的若干问题总结
- 关于TFS2010 远程无法创建团队项目的若干问题总结
- 针对接口测试用例设计,我在项目中(搜狗测试)总结
- 【tool】三角形问题测试用例设计之总结
- 关于用户注册界面测试用例总结(转)