软件测试是为了发现错误而执行程序的过程。 QQ: 12585990 MSN:sunxy5291@hotmail.com

有效的用例编写规则

上一篇 / 下一篇  2007-05-22 16:11:44 / 个人分类:UML

d;A}(z j0第一章 什么是高质量的用例51Testing软件测试网 o:j:cz)D J K

1.1 为什么要使用用例51Testing软件测试网jU:c^P([%oL;b7D

用例提供了一种用于构建故事的半形式框架;

`}6z|*Wl"Y0

在每个用例和所有描述层次中,用例都描述了错误情况的系统需求;

9zK&OQ2?Qg0

虽然本质上是一种功能分解技术,但用例已经成为面向对象软件开发的一个流行元素;

NKK.NP0K f0

用例提供了可以在其上处理其他项目信息的骨架:

)KB\$W+V!yf&u0

项目经理根据用例进行估计和发布进度;51Testing软件测试网*p Z~%j~:nq

数据及业务规则制定人员可以把自己的需求和所需用例联系起来;51Testing软件测试网:vO[` j&v6eR

用户界面设计人员可以进行设计,并将其与相关用例联系起来;51Testing软件测试网3g+qo9|2xP|S

测试人员可以根据用例中描述的成功和失败情况构建测试场景(测试用例);

/i,V)x c[6pi0

1.2 编写用例容易出现的问题51Testing软件测试网&J8m3WYVg

用户界面太多,用户界面应属于设计范畴,鼠标、按键等内容不应出现在用例中;
\We?}~D0较低目标层次上的用例太多,无法展示系统将会给其最终用户提供什么功能;
/qN;sW!rYcB0使用用例表示非行为信息,性能需求、业务规则等不要在用例中描述;51Testing软件测试网"lah.x#@4Ka+H[
太冗长,最好在3~9步;
{v+}/rr;nn0目标实现不完整,尤其是错误处理;
G~'^q t;B0句子片断,主、谓、宾尽量完整;

1.3 为什么使用用例模式语言51Testing软件测试网{?!{-^BHO

描述了用例的质量标志及其编写过程,提供了能够经受时间考验的用例改进建议;在评审用例初稿和改进其质量的过程中,这个工具能起到很大作用。51Testing软件测试网zU+S W2Aj:n`

1.4 什么是模式51Testing软件测试网q y ?d&\1H

模式是质量标志和策略;51Testing软件测试网%\M}p[7S

1.5 使用模式语言时错误观念

B)bUS;q!Q+g0
模式提供了一个关于其自身和模式内容的完整方法;只起补充作用51Testing软件测试网F~c)W T]
使用模式肯定会成功;
B'?b.@w&p%i,z0模式为老问题提供了新的解决方案;只是经常出现的问题的通用可靠方案
_"\ S^l!| q4_0模式适用于所有情况;仅是处于某种上下文中的问题的解决方案

1.6 模式组织

^Ga@x[-O0
模式分类
子类

开发模式51Testing软件测试网0sHgT'Mwi)Jkw

团队组织:判断和改进用例团队组织方式的质量的模式;
过程:判断和改进团队用来创建用例的方法质量的模式;
编辑:随着潜在需求的变化和编写人员知识的增加,判断和改进单个用例的质量;

结构模式

t(g| F+r }Mp5H0
用例集:判断和改进用例集质量的模式;
用例:判断和改进单个用力质量的模式;
场景和步骤:判断和改进用力场景以及这些场景中的步骤质量的模式;
用例关系:判断和改进集合中用例之间的结构关系质量的模式;

1.7 用例的读者和编写者

!THB!C3I-s0
有两组不同的认阅读和使用用例:(1)最终用户或业务专家;(2)程序员。51Testing软件测试网ApO6q6es
用例编写组必须包括:
#^E'V*kNMX"K P p0至少一位具有编程背景的认,以获得描述所要求的准确性和精度;
t^9e`^n&S8M]0至少一位熟知业务规则的认;51Testing软件测试网8R j/uVw"A2{N
至少一位熟知在实际中如何使用系统的认;

第二章 团队51Testing软件测试网3f3pq^,]4i:tU

2.1 SmallWritingTeam51Testing软件测试网w|a*EM&v!C

原因:

*o6p8L| X,q&{7B0
用例要求具有不同观点和专业知识的人编写;
nv @&\ w C#W0将一大组人聚集在一起是困难的;51Testing软件测试网4c5sE h6y5p)w W
理论上,在用例上投入的人越多,就能越快的完成用例编写工作
,]J2b.w1G-ONK&G4j0大的团队会变得低效;
%}+[.x.U9_[O3Bg0大型编写团队可能会通过集体讨论的形式开发用例,添加许多不必要的特性;

所以:51Testing软件测试网d)?r,kq

一个由2人或3人组成的团队足够小,容易交流和达成一致;51Testing软件测试网7?7` |%R1m?Z

可以使用几个SmallWritingTeam,但应当制定一位用例设计师,以保证所有用例与愿景一致。
D;dUXoQK0最终目的是使过程保持在可管理状态,大的团队将在管理上投入更多的精力。

(BL Qjp}/R0

2.2 ParticipatingAudience

9p}PW2V]u0Z0

没有涉众提供的信息和反馈,就不能满足他们的需要;尽可能使客户和内部涉众积极参与用例开发过程。51Testing软件测试网Zca.|:?9[.|

2.3 BalancedTeam

{@e.L [q1z0o0

由一些个性相似、意见相同的个人组成的团队开发用例,可能会得到一组缺乏创见、范围狭窄的用例,这种用例不能满足每个人的需要。51Testing软件测试网7HBt&j0Ei*Y

因此,为小组配备具有不同专长的人员,以维护开发过程中涉众的利益,确保团队中包括开发人员和最终用户。51Testing软件测试网 ACRUbs:vu
最大好处是使编写人员在用例中使用常见的、可理解的术语。

A7cl!Rhl0HR0

第三章 过程51Testing软件测试网`DZnr'K`"q"p } z6U

编写好的用例是极其个性化的,每个人都有他自己的风格,每个组织都有根据自己的文化和业务需要做事情的方式,因此,没有创建用例的通用过程。51Testing软件测试网Nr2\qV`:?-A

3.1 BreadthBeforeDepth51Testing软件测试网.kH?-d3z/O

原因:51Testing软件测试网d4r$m,qKc c1{)J]K

需求收集是一个发现过程,用例编写是一个迭代过程;51Testing软件测试网S7NX|d Z
人们很早就开始编写用例的细节;
7?:w6KT{DcL0人们浪费了精力或陷入了太多的细节,通常都会失去重点,无法描述所有可能的扩展条件;
MRi"~(dv(d T0IB~0从早期获得概述是有益的;
2C6g)U%p!NEt C0最初编写的细节越多,在了解系统后必须进行的改变也就越多;

所以:51Testing软件测试网6OKY3l|@.^_:f

通过首先开发用例的概述来保存精力,然后逐步增加细节,并行开发一组相关用例。51Testing软件测试网/nxYl#A+M CD!W"t

完成概述用例后,随着对系统了解的增多,不断提高用例精度,避免突然开发完所有用例或一次只开发一个用例的倾向。

R7^xK Xf _0

3.2 SpiralDevelopment(螺旋式开发)

&xO2|"}/z;et0

原因:

ghq"h0}3E0
理解系统的行为可能会花掉大量时间,要求渐进式分析;
+l-M+_s1RExE,D0拖延是昂贵的。要尽快完成用例的编写;51Testing软件测试网 \V!gw!L0Ep5mI
对需求进行分析后,需求很可能会发生变化;
5Wh*^}2[7vFq0需求成本的错误是昂贵的;

所以:

8iRF,V7f8{/I0

以一种迭代的,宽度优先的方式开发用例,每次迭代都会提高用例集的准确性和精度。51Testing软件测试网ws.NA7pR%H

基本过程:51Testing软件测试网5G!w[v\r2FmJ)@

从简单的东西开始,如一个参与者/用例列表;51Testing软件测试网g W%m'cm
简要描述用力主场景,即高层用例,以包含用例的主要范围;
vD@'w'm K0扩展摘要的子集,并填充细节;
zR'u w/t0t&h#kqB0评审并调整;

3.3 MultipleForms51Testing软件测试网\_ ZW"[-Rk*f8J

不同的项目需要不同程度的形式化,每个人对模板都有不同的偏好,要求每个人都使用相同的用例模板只会起到相反的作用。

(^6n.P+M8~;Ln0

原因:51Testing软件测试网3aYO7pCA6Hs

每个人的个性、经验和经受的锻炼不同,每个开发组织都有其特有的人员、历史和文化;
Z%m&J` YB+MHz0不同的项目有不同的需要;
tw/]PL?1V0不同的编写团队需要不同程度的规范和严格度;51Testing软件测试网9JM zH:m\3D
在组织中使用公共的编写形式有助于交流;
j8T"n(G#x5U0在同一个项目上使用不同的模板不是一个好主意;

因此:根据项目相关的风险性、项目特点,和所涉及到的人员选择用例的编写格式,并在该项目的开发过程中的组织内部使用。51Testing软件测试网iJ2oG'p-E%k

3.4 TowTireReview(评审)

7}f!ug1H/q'Og0U0

许多人都可能需要评审用例,这是一件昂贵耗时的事情。51Testing软件测试网8?$mi*~x

原因:

K$[GD7t1zC0
对于验证和确认编写及内容来说,评审是必要的;51Testing软件测试网F ]k7H1W0F&z8^S;Z
涉众在用例上有一种既得利益;51Testing软件测试网JEZ3Y$Z Bq t|2[e/z
使每个人参与编写过程非常昂贵、麻烦并且缓慢;51Testing软件测试网:c DI(Y;S
如果仅由一个小的编写组进行评审,就不会考虑所有涉众的利益;51Testing软件测试网7KW.I[?z
评审可能是昂贵的、乏味的、耗时的。

所以:

T&X5l q e G3v0

进行两种类型的评审:第一种是由较小的内部小组进行的评审,可能要重复进行很多次;第二种是由整个团队进行的评审,可能只进行一次。51Testing软件测试网 wX R\6b

3.5 QuittingTime

开发一个超出了涉众和开发人员需要的用例模型不仅浪费资源,而且会拖延项目进度。

原因:

忽视重要需求的巨大恐惧使构建人员和涉众延长了需求收集活动;51Testing软件测试网pQ3on2{ ^'y@
大多数人可以用一种合理的模糊性工作,即不言自明;
c:w o]'O5gZY-c_0详细讲述谎言并不能使他们更为精确;

所以:

在用例完整并且符合参与者的需要后,停止开发用例;
TO+_Asq_0用例模型完整性的检验:完整、可读、逻辑上正确、对开发人员足够详细。51Testing软件测试网)xF'|+_?
是否识别了所有的参与者和目标并将其编成了文档?
4s-yA ~#MfSee0客户及其代表是否承认用例集是完整的,而且每个用例都是可读的和正确的?51Testing软件测试网3D!Q;H;e i]
设计人员是否能够实现这些用例?

3.6 WriterLicense

小的格式差别并不重要,解决了所有系统问题后,及时还存在一些格式问题,也可以停止编写;51Testing软件测试网n;kL+\3N+JV


相关阅读:

TAG: UML

 

评分:0

我来说两句

我的栏目

日历

« 2024-05-14  
   1234
567891011
12131415161718
19202122232425
262728293031 

数据统计

  • 访问量: 42856
  • 日志数: 49
  • 图片数: 2
  • 建立时间: 2006-12-26
  • 更新时间: 2014-05-06

RSS订阅

Open Toolbar