time 
设为首页】【收藏本站
当前位置: 主页 > 软件工程 > 分析与建模 > 谈用例驱动可能出现的问题及解决方法

谈用例驱动可能出现的问题及解决方法

时间:2009-12-01 20:27 点击:750次 字体:[ ]




  就像小说里那些早慧的少年,很早就尝试过用例驱动的需求文案,结果与客户,一个愁默默,一个恨绵绵。 

  最狂热的用例编写者也承认,用例对客户与需求人员都是一种heavy的相互折磨。

  客户看用例时总要收摄心神来阅读整个交互的流程,还有那些该死的扩展流异常流,没经过程序员专业抽象训练的客户,对着这些伪代码一般的情景脚本,刚开始的一两个还好,看多了,就是白天也能睡去。客户只是看都如此了,负责写的人当然也不会好过。

  但heavy的工作总有heavy的好处,否则早被唾弃于舞台的背面。
  在用户的角度,用例比模棱两可的功能点描述要清晰,也更直白于系统的价值。
  在开发团队角度,RUP的核心方法论之一---用例驱动的口号,明白人自然明白它的妙用。
  设计人员的新设计手段:“用时序图分析用例的实现,在描述过程中确定构件或类,分配它们的职责和方法”,通过对用例覆盖率的追踪,需求与设计之间的信息损耗这个famous problem大大降低。
  测试人员和文档人员,更可以直接把系统用例笑纳为《测试用例》和《用户手册》。

  来到亿迅后,被这里的用例文明给震住了,每个项目的软件规格说明都是屯门清一色的几百页的前景,用例规约,业务规则,词汇表,补充规约组成.......难得有情郎啊。

  昨天又看到了一批新的用例诞生,但实在有好些明显的不足啊,忍不住旧事重提的记下一批经典的错误。不过.....只要能和客户达成需求共识,就是一份好的用例了,也不用花太多时间在学术性的讨论上。

  1.客户没有能力阅读用例
  如果客户实在没办法撑住困意看完用例的细节,即使草草签了名,得不到用户真正确认的用例,依然无法用来驱动设计和测试。
  解决方法:放弃编写用例,改回用户容易看的传统方式。

  2.团队没有能力实现用例驱动
  如果开发团队在设计与测试时,根本不依照用例细节驱动,那用例对开发团队就只是个摆设,花瓶。
  解决方法:对设计、测试人员进行用例驱动的培训,如果事不可为就干脆放弃,怎么省事怎么做。

  3.在用例中描述系统内部工作
  经典错误,开发人员把用例当作设计文档来写,如“系统将销售信息写入数据库”,实际上应该写的是“系统记录销售”。
  解决方法:站在客户的角度,把系统视为黑盒,删除所有内部设计描述。

  4.在用例中描述界面
  另一个经典错误,不说了,如果在意用户信息包括了姓名和密码,可以在词汇表里记录,而用例写成--显示<用户信息>。

  5.在用例中越出系统边界描述整个业务流程
  要建立的系统只是整个业务流程里的一部,善良的需求人员为了大家清楚来龙去脉,将系统外的处理步骤也写进了用例的情景。
  如:
      1.用户去营业厅开户
      2.用户拨号接入
      实际上去营业厅开户不属于宽带接入认证系统的职责。
      解决方法:开户的描述应该放到用例的前置条件中。前置与后置条件是说明系统边界外的业务流程的好地方。 



本文地址 : http://www.fengfly.com/plus/view-158740-1.html
标签: 驱动 方法 问题 可能 出现
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
验证码: