敏捷测试用例设计

敏捷宣言：51Testing软件测试网)U^9j$u4Yq

g%Gn:]](]7i0个体和交互比过程和工具更有价值；51Testing软件测试网K b9^%}2Y)P

Z4\*c6{\O.h0能工作的软件比全面的文档更有价值；

}R%h.Z2jB-B{6h M9a0顾客的协作比合同谈判更有价值；

及时响应变更比遵循计划更有价值。51Testing软件测试网^%_i mg"a/Y&j

-www.agilemanifesto.org51Testing软件测试网Vdu7X9@lQ'G]%D

'wpx7v-`+p3m0 

%fe zeiY5P0并非每个企业都能严格按敏捷的相关开发方法进行项目管理，例如测试驱动、XP、SCRUM等。也并非都需要按这些方式管理才能实现敏捷。只要我们理解了敏捷的原则和精髓，我认为很多方法、很多地方都可以应用敏捷的思想，实现敏捷的管理。51Testing软件测试网Z*V:k ku$n M`'j9P

oK4YKr\wi)qs0 51Testing软件测试网1iR P XLT8b

;@Um bA0测试用例的设计是其中一项。51Testing软件测试网^ LV:|G2A&M4_

 51Testing软件测试网6j;o#r)q-s?3IX

测试用例的粒度51Testing软件测试网+c*T1r*G&T r7N^t3g

测试用例可以写得很简单，也可以写得很复杂。最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试（Exploratory Testing）中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样，会指定输入的每项数据，期待的结果及检验的方法，具体到界面元素的操作步骤，指定测试的方法和工具等等。51Testing软件测试网ZZP7Fp'Dgl!L
L4x h

 51Testing软件测试网y#['Fo6xEyD

测试用例写得过于复杂或过于详细，会带来两个问题：一个是效率问题，一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。

;rg/Y4vE}0^ k-z0 

-qo-@5VU)[0测试用例写得过于简单，则可能失去了测试用例的意义。过于简单的测试用例设计其实并没有进行“设计”，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。

(N6m+~+H G3a!`T r0 

h8_8l(D,mC8hnf0大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键，也将影响测试用例设计的效率和效果。我们应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。

+{ni_/}0 51Testing软件测试网 FI+^rs/_x#OS

jn:f-J XC"WI8`i0软件是开发人员需要去努力实现敏捷化的对象，而测试用例则是测试人员需要去努力实现敏捷化的对象。要想在测试用例的设计方面应用“能工作的软件比全面的文档更有价值”这一敏捷原则，则关键是考虑怎样使设计出来的测试用例是能有效工作的。

] q*P+[m5Hi1y3k8b0基于需求的测试用例设计51Testing软件测试网?g
^"|Z9Ae

基于需求的用例场景来设计测试用例是最直接有效的方法，因为它直接覆盖了需求，而需求是软件的根本，验证对需求的覆盖是软件测试的根本目的。51Testing软件测试网I!{} u V6D;J$w

要把测试用例当成“活”的文档（Effective Software Testing : 50 Specific Ways to Improve Your Testing – Elfriede Dustin），因为需求是“活”的、善变的。因此在设计测试用例方面应该把敏捷的“及时响应变更比遵循计划更有价值”这一原则。51Testing软件测试网)iG gMLDD

/Q7fd2KR]0 

T.i J
k([9P"q%\#mI0不要认为测试用例的设计是一个阶段，测试用例的设计也需要迭代，在软件开发的不同的阶段都要回来重新审视和完善测试用例。51Testing软件测试网G@
p3O4T#v5}@

!G;P7y!yp"k0 

:UB%N(}u;R]0测试用例的评价

测试用例设计出来了，质量如何，如何提高测试用例设计的质量？就像软件产品需要通过各种手段来保证质量一样，测试用例的质量保证也需要综合使用各种手段和方法。51Testing软件测试网/G$i{q3Js8N|

测试用例的检查可以有多种方式，但是最敏捷的应当属临时的同行评审。我认为同行评审，尤其是临时的同行评审，应该演变成类似结对编程一样的方式。从而体现敏捷的“个体和交互比过程和工具更有价值”，要强调测试用例设计者之间的思想碰撞，通过讨论、协作来完成测试用例的设计，原因很简单，测试用例的目的是尽可能全面地覆盖需求，而测试人员总会存在某方面的思维缺陷，一个人的思维总是存在局限性。因此需要一起设计测试用例。51Testing软件测试网Fs.b9C_-Bua~

HI}{5J0I0 51Testing软件测试网8n/^ Y M;t F

除了同行评审，还应该尽量引入用户参与到测试用例的设计中来，让他们参与评审，从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛，关键在于你怎样定义测试，如果测试是对产品的批判，则顾客应该指最终用户或顾客代表（在内部可以是市场人员或领域专家）；如果测试是指对开发提供帮助和支持，那么顾客显然就是程序员了。

/vI i4ZG+^c9Z
b@0 51Testing软件测试网/]gw6|gT

因此，参与到测试用例设计和评审中来的人除了测试人员自己和管理层外，还应该包括最终用户或顾客代表，还有开发人员。

 51Testing软件测试网'J?+S1G6_&r7S

测试用例数据生成的自动化

在测试用例设计方面最有希望实现自动化的，要当属测试用例数据生成的自动化了。因为设计方面的自动化在可想象的将来估计都很难实现，但是数据则不同，数据的组合、数据的过滤筛选、大批量数据的生成等都是计算机擅长的工作。51Testing软件测试网O6I4@1hsa

 51Testing软件测试网;V;k5sJa.\

很多时候，测试用例的输入参数有不同的类型、有不同的取值范围，我们需要得到测试用例的输入参数的不同组合，以便全面地覆盖各种可能的取值情况。但是全覆盖的值域可能会不可思议地广泛，我们又需要科学地筛选出一些有代表性的数据，以便减轻测试的工作量。在这方面可利用正交表设计数据或成对组合法设计数据。51Testing软件测试网HALgSB;{

 51Testing软件测试网a[OSS3x'E-O

可利用一些工具，例如TConfig、PICT等来产生这些数据。51Testing软件测试网U,G ^~st

pQ/fwI.kzAx+e,G0 51Testing软件测试网FD'\Ee(R/f

1tOR r:R&Q0在性能测试、容量测试方面，除了设计好测试用例考虑如何测试外，还要准备好大量的数据。大量数据的准备可以使用多种方式：编程生成、SQL语句生成（基于数据库的数据）、利用工具生成。51Testing软件测试网!H2B)xNK
?!V

{!c/Jd_p;vJ0 

工具未必能生成所有满足要求的数据，但是却是最快速的，编程能生成所有需要的数据，但是可能是最复杂、最慢的方式。所以应该尽量考虑使用一些简单实用的工具，例如DataFactory等。51Testing软件测试网)nf1| glF3u+s8v6u*c

$s+E-\i?X&p0 51Testing软件测试网)nc(f `(M
t(?:t

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/Testing_is_believing/archive/2007/09/25/1800597.aspx51Testing软件测试网P]%m:H]Xa