故意学习，故意生活，故意活的像个人！

如何写测试用例

上一篇 / 下一篇 2007-01-18 11:58:14 / 个人分类：测试用例

51Testing软件测试网}O W/qz4XNl
功能性测试用例
\g8I"k%uY4{~g0
*C glE,|01. 测试的来源，即测试的需求
~ F crjlP0
%w7m F,zu-K`R0 测试用例的主要来源有：
R(J_6W}(z01）需求说明”及相关文档
ueHAe'M'L:u02）相关的设计说明（概要设计，详细设计等）51Testing软件测试网9m;Lt4zz
3）与开发组交流对需求理解的记录（可以是开发人员的一个解释）
1ux @ ut*]%L0 4）已经基本成型的UI（可以有针对性地补充一些用例）51Testing软件测试网 pJ5H j],H
       简而言之，所有你能得到的项目文档，都尽量拿到。从所得到的资料中，分解出若干小的“功能点”，理解“功能点”，编写相应的测试用例。
9I0?]htK0T)m051Testing软件测试网*TKo@:C#M
2. 用例的组织方式51Testing软件测试网9Hs1JXe:i
o5Z2V%V}Hz0不同的公司有不同的做法，原则上，只要方便管理和跟踪，怎么组织都可以的。
$E8uX ?*aUj/[0用例可以按大的功能块组织，如查询功能模块的用例，可以组织在一起，打印模块的测试用例，可以另外组织在一起。51Testing软件测试网9P d HzN*t#f
     在没有专门的测试用例管理工具的情况下，用例执行后会产生2种状态：“通过”、“失败”——这样加上“未执行”的用例的状态，共3种状态。51Testing软件测试网0_-zOV? PR+e
    即从“未执行”用例中执行一个用例后，该用例状态应为“失败”或“通过”。将同一状态的用例组织在一起。51Testing软件测试网UNRdm
至于用例文件格式，可以是.DOC或.XLS（如果有专门的测试用例管理工具另当别论）。
_^(SXj"_0
?$z @/d5tU03. 用例与其他材料的关联方式，即如何解决用例跟踪的问题
)Q*S#WZ~O0
I gM$Y/@6~%w.a0测试用例面临的比较大的风险有：需求的变更、设计的修改、需求的错误和遗漏等等。
R9I[:U9p@U%bn0由于用例的主要来源是需求和设计的说明，所以对用例的跟踪其实就是对需求和设计的跟踪，需求和设计的变更势必引起测试用例的变更。
*\[cU(b3s0 如前所说，将分解的功能点编号，与相应的用例联系起来。例如，你可以列一个表格，列出各个（编号的）功能点和测试用例间的关联关系。
L:?@@H[0 这样，当需求和设计发生变化时，你只需要跟踪“功能点”是否变化，是否增加了新的功能点。51Testing软件测试网0Y"o8j-QG d
4. 一个好的用例的表述要点，即用例中应当包含的信息51Testing软件测试网%F&YsNEK
51Testing软件测试网q9hy I-I
一个优秀的测试用例，应该包含以下信息：
|.Q!QG9d)s6r01）软件或项目的名称
2）软件或项目的版本（内部版本号）51Testing软件测试网Z {Mj(t:z2f
3）功能模块名
#Y E5Q;ZXe0h_0 4）测试用例的简单描述，即该用例执行的目的或方法
5）测试用例的参考信息（便于跟踪和参考）
ms!qw M6M0 6）本测试用例与其他测试用例间的依赖关系
7）本用例的前置条件，即执行本用例必须要满足的条件，如对数据库的访问权限
8）用例的编号（ID），如可以是软件名称简写-功能块简写-NO.。
zh,t%T&xnO!R09）步骤号、操作步骤描述、测试数据描述
ClG!]s2?010）预期结果（这是最重要的）和实际结果（如果有BUG管理工具，这条可以省略）
11）开发人员（必须有）和测试人员（可有可无）51Testing软件测试网.w lh$cTf6X
12）测试执行日期51Testing软件测试网Q}Z ?+N2@
7E at9E+E1Q6b,f05. 给出一个测试用例的例子该范例已经包含一个测试用例的模板。
E8L0zu R e ^0
51Testing软件测试网8N ^-Wh2e i
备注：本用例未考虑“企业代码”的输入情况；测试用例并未涵盖所有的非法输入，如非法输入中可能会有 “user=*,pw=*”的组合，对回车的默认操作，空格输入，对输入上溢的处理的处理（可能会跳过身份验证）等等。
K j9V!VN&ni @*\W0 如果你有兴趣，至少可以再补充5-10条左右的输入组合（当然，如果步骤超过15步，用例的易操作性就降低，你可以再创建一个测试用例如TC-TEP_Login_2）
fD-LUR{ b2M'as051Testing软件测试网{s"^0~gTE
51Testing软件测试网\8s h:D aS'?