• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

软件测试之编写有效的用例规则

发布: 2009-3-17 11:26 | 作者: 不详 | 来源: 测试时代采编 | 查看: 70次 | 进入软件测试论坛讨论

领测软件测试网

3.1 BreadthBeforeDepth
原因:
需求收集是一个发现过程,用例编写是一个迭代过程;
人们很早就开始编写用例的细节;
人们浪费了精力或陷入了太多的细节,通常都会失去重点,无法描述所有可能的扩展条件;

从早期获得概述是有益的;
最初编写的细节越多,在了解系统后必须进行的改变也就越多;
所以:
通过首先开发用例的概述来保存精力,然后逐步增加细节,并行开发一组相关用例。

完成概述用例后,随着对系统了解的增多,不断提高用例精度,避免突然开发完所有用例或一次只开发一个用例的倾向。
3.2 SpiralDevelopment(螺旋式开发)
原因:
理解系统的行为可能会花掉大量时间,要求渐进式分析;
拖延是昂贵的。要尽快完成用例的编写;
对需求进行分析后,需求很可能会发生变化;
需求成本的错误是昂贵的;
所以:
以一种迭代的,宽度优先的方式开发用例,每次迭代都会提高用例集的准确性和精度。
基本过程:
从简单的东西开始,如一个参与者/用例列表;
简要描述用力主场景,即高层用例,以包含用例的主要范围;
扩展摘要的子集,并填充细节;
评审并调整;
3.3 MultipleForms
不同的项目需要不同程度的形式化,每个人对模板都有不同的偏好,要求每个人都使用相同的用例模板只会起到相反的作用。
原因:
每个人的个性、经验和经受的锻炼不同,每个开发组织都有其特有的人员、历史和文化;
不同的项目有不同的需要;
不同的编写团队需要不同程度的规范和严格度;
在组织中使用公共的编写形式有助于交流;
在同一个项目上使用不同的模板不是一个好主意;
因此:根据项目相关的风险性、项目特点,和所涉及到的人员选择用例的编写格式,并在该项目的开发过程中的组织内部使用。
3.4 TowTireReview(评审)

许多人都可能需要评审用例,这是一件昂贵耗时的事情。
原因:
对于验证和确认编写及内容来说,评审是必要的;
涉众在用例上有一种既得利益;
使每个人参与编写过程非常昂贵、麻烦并且缓慢;
如果仅由一个小的编写组进行评审,就不会考虑所有涉众的利益;
评审可能是昂贵的、乏味的、耗时的。
所以:

进行两种类型的评审:第一种是由较小的内部小组进行的评审,可能要重复进行很多次;第二种是由整个团队进行的评审,可能只进行一次。

3.5 QuittingTime
开发一个超出了涉众和开发人员需要的用例模型不仅浪费资源,而且会拖延项目进度。
原因:
忽视重要需求的巨大恐惧使构建人员和涉众延长了需求收集活动;
大多数人可以用一种合理的模糊性工作,即不言自明;
详细讲述谎言并不能使他们更为精确;
所以:
在用例完整并且符合参与者的需要后,停止开发用例;
用例模型完整性的检验:完整、可读、逻辑上正确、对开发人员足够详细。
是否识别了所有的参与者和目标并将其编成了文档?
客户及其代表是否承认用例集是完整的,而且每个用例都是可读的和正确的?
设计人员是否能够实现这些用例?
3.6 WriterLicense
小的格式差别并不重要,解决了所有系统问题后,及时还存在一些格式问题,也可以停止编写;

文章来源于领测软件测试网 https://www.ltesting.net/

33/3<123

关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备2023014753号-2
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网