（一）测试用例模板（Test Case Template）
┏━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃用例编号 │ ┃
┠──────┼───────────────────────────┨
┃测试优先级 │ ┃
┠──────┼───────────────────────────┨
┃用例摘要 │ ┃
┠──────┼───────────────────────────┨
┃测试类型 │ ┃
┠──────┼───────────────────────────┨
┃用例类型 │ ┃
┠──────┼───────────────────────────┨
┃用例设计者 │ ┃
┠──────┼───────────────────────────┨
┃设计日期 │ ┃
┠──────┼───────────────────────────┨
┃对应需求编号│ ┃
┠──────┼───────────────────────────┨
┃对应UI │ ┃
┠──────┼───────────────────────────┨
┃对应UC │ ┃
┠──────┼───────────────────────────┨
┃版本号 │ ┃
┠──────┼───────────────────────────┨
┃对应开发人员│ ┃
┠──────┼───────────────────────────┨
┃前置条件 │ ┃
┠──────┼───────────────────────────┨
┃测试方法 │ ┃
┠──────┼───────────────────────────┨
┃输入数据 │ ┃
┠──────┼───────────────────────────┨
┃执行步骤 │ ┃
┃ │ ┃
┃ │ ┃
┃ │ ┃
┃ │ ┃
┃ │ ┃
┃ │ ┃
┃ │ ┃
┃ │ ┃
┃ │ ┃
┃ │ ┃
┠──────┼───────────────────────────┨
┃预期输出 │ ┃
┠──────┼───────────────────────────┨
┃实际结果 │ ┃
┠──────┼───────────────────────────┨
┃测试日期 │ ┃
┠──────┼───────────────────────────┨
┃结论 │ ┃
┗━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
Dome
┏━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃用例编号 │BOSS_ FS_ MARKETING_NEW_01P ┃
┠──────┼───────────────────────────┨
┃测试优先级 │高（还有“较高、中、较低、低”几个等级） ┃
┠──────┼───────────────────────────┨
┃用例摘要 │新增营销记录 ┃
┠──────┼───────────────────────────┨
┃测试类型 │功能性测试（对应还有“安全性测试”等） ┃
┠──────┼───────────────────────────┨
┃用例类型 │基本事件（对应还有“备选事件”、“异常事件”） ┃
┠──────┼───────────────────────────┨
┃用例设计者 │songfun ┃
┠──────┼───────────────────────────┨
┃设计日期 │2005-04-25 ┃
┠──────┼───────────────────────────┨
┃对应需求编号│REQ_ MARKETING_NEW_01 ┃
┠──────┼───────────────────────────┨
┃对应UI │Marketing.htm ┃
┠──────┼───────────────────────────┨
┃对应UC │UC_ MARKETING_NEW_01 ┃
┠──────┼───────────────────────────┨
┃版本号 │Build v0.1 ┃
┠──────┼───────────────────────────┨
┃对应开发人员│Frank ┃
┠──────┼───────────────────────────┨
┃前置条件 │操作员登录营销管理系统 ┃
┠──────┼───────────────────────────┨
┃测试方法 │等价类划分（对应还有“错误猜测法”、“边界值分析”等）┃
┠──────┼───────────────────────────┨
┃输入数据 │用户名：51testing 性别：男 金额：10元 描述：aaaaaaa ┃
┠──────┼───────────────────────────┨
┃执行步骤 │①.进入【营销下发】页面； ┃
┃ │②.点击『增加』按钮； ┃
┃ │③.输入相应数据； ┃
┃ │④.点击『确定』按钮； ┃
┃ │⑤.在后台数据库(test/test@testDB)输入查询语句验证： ┃
┃ │ select * from MarketingTab where ID=\'1001\' ┃
┃ │ ┃
┠──────┼───────────────────────────┨
┃预期输出 │㈠.执行步骤④后，页面弹出添加成功提示信息框； ┃
┃ │㈡.执行步骤⑤后查询数据库，记录确实添加成功且数据无误 ┃
┃ │ ┃
┠──────┼───────────────────────────┨
┃实际结果 │符合预期 ┃
┠──────┼───────────────────────────┨
┃测试日期 │2005-05-01 ┃
┠──────┼───────────────────────────┨
┃结论 │ ┃
┗━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
(二) 测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地
估计测试周期各连续阶段的时间安排。
测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件
或经由产品的事件流，因而，随着测试用例数量的增加，您对产品质量和测试流程也就
越有信心。
判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施
和/或执行的测试用例的数量为依据的。
（三）最佳方案是为每个测试需求至少编制两个测试用例：
一个测试用例用于证明该需求已经满足，通常称作正面测试用例；
另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所
需条件下才能够满足该需求，这个测试用例称作负面测试用例。
（四）流程图
例如，下图中经过用例的每条不同路径都反映了基本流和备选流，都用箭头来表
示。基本流用直黑线来表示，是经过用例的最简单的路径。每个备选流自基本流
开始，之后，备选流会在某个特定条件下执行。备选流可能会重新加入基本流中
（备选流1 和3），还可能起源于另一个备选流（备选流2），或者终止用例
而不再重新加入某个流（备选流2 和4）。
用例的事件流示例
遵循上图中每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，
再将基本流和备选流结合起来，可以确定以下用例场景：
场景1 基本流
场景2 基本流 备选流1
场景3 基本流 备选流1 备选流2
场景4 基本流 备选流3
场景5 基本流 备选流3 备选流1
场景6 基本流 备选流3 备选流1 备选流2
场景7 基本流 备选流4
场景8 基本流 备选流3 备选流4
注：为方便起见，场景5、6 和8 只描述了备选流3 指示的循环执行一次的情
况。
可以以ATM 机的测试用例为例。