功能测试用例的书写方式（zz）

能性测试用例51Testing软件测试网5S9@|:ky I#D~[q

K&A2f4j6}e @2W01. 测试的来源，即测试的需求

  测试用例的主要来源有：51Testing软件测试网0dAI#T'm-Z4F
1） 需求说明”及相关文档51Testing软件测试网Gm&M(c jq;CR9p
2）相关的设计说明（概要设计，详细设计等）
VN |5e Tr03）与开发组交流对需求理解的 记录（可以是开发人员的一个解释）
tx?*@oh4k0 4）已经基本成型的UI（可以有针对性地补充一些用例）
^1o;@/y$bY&qx0       简而言之，所有你能得到的项目文档，都尽量拿到。 从所得到的资料中，分解出若干小的“功能点”，理解“功能点”，编写相应的测试用例。51Testing软件测试网)D]_n.I

z/P5^j1TQ4m02. 用例的组织方式

不同的公司有不同的做法，原则上，只要方便管理和跟踪，怎么组织都可以的。51Testing软件测试网2x4P8{q-NH&W%U(h
用例可以按大的功能块组织，如查询功能模块的用例，可以组织在一起，打印模块的测试用例，可以另外组织在一起。51Testing软件测试网N\!kEZ8W Z6J
     在没有专门的测试用例管理工具的情况下，用例执行后会产生2种状态：“通过”、“失败”——这样加上“未 执行”的用例的状态，共3种状态。51Testing软件测试网to0IeJ;v%dF
    即从“未执行”用例中执行一个用例后，该用例状态应为“失败”或“通 过”。将同一状态的用例组织在一起。51Testing软件测试网RuDh(n)L+Fx.r{
  至于用例文件格式，可以是.DOC或.XLS（如果有专门的测试用例管理工具另当别论）。

3. 用例与其他材料的关联方式，即如何解决用例跟踪的问题51Testing软件测试网Q+Jdj LD"@

测试用例面临的比较大的风险有：需求的变更、设计的修改、需求的错误和遗漏等等。51Testing软件测试网K7mFv _5o8`w+G f
由于用例的主要来源是需求和设计的说明，所以对用例的跟踪其实就是对需求和设计的跟踪，需求和设计的 变更势必引起测试用例的变更。
9_V
QsNK7w/a0  如前所说，将分解的功能点编号，与相应的用例联系起来。例如，你可以列一个表格，列出各个（编号的）功 能点和测试用例间的关联关系。
&bx%A
~R+F1dn0 这样，当需求和设计发生变化时，你只需要跟踪“功能点”是否变化，是否增加了新的功能点。
/jr]
qo-B)Q}Z4g0  4. 一个好的用例的表述要点，即用例中应当包含的信息

%RoE
st0一个优秀的测试用例，应该包含以下信息：51Testing软件测试网8vu[|!XwU;y
1） 软件或项目的名称
u"]
S|1Eu
I;PL ES0G02） 软件或项目的版本（内部版本号）
3` b*jPC-iT)S Y0 3） 功能模块名
*AM,O]%^6Y|0j0 4） 测试用例的简单描述，即该用例执行的目的或方法
QH-V\0~#yQ9j0J0 5） 测试用例的参考信息（便于跟踪和参考）
0]Y)@SE^.P [0 6） 本测试用例与其他测试用例间的依赖关系
|9K3D&Fl!{0 7） 本用例的前置条件，即执行本用例必须要满足的条件，如对数据库的访问权限
2^};i#z&P+w8?#j8_hX08） 用例的编号（ID），如可以是 软件名称简写-功能块简写-NO.。51Testing软件测试网 ^9y
U6U4o s6d
9） 步骤号、操作步骤描述、测试数据描述51Testing软件测试网j M _0N.H7W,Ng
10）预期结果（这是最重要的）和实际结果（如果有BUG管理工具，这条可以省略）
D&uIe-td!Y011）开发人员（必须有）和测试人员（可有可无）
5G
T ~C*W:e b012）测试执行日期51Testing软件测试网E!EH8h:z1}4@