功能测试用例的书写方式(适于新手学习)

　　功能性测试用例

　　1. 测试的来源，即测试的需求

　　测试用例的主要来源有：

　　1) 需求说明”及相关文档

　　2)相关的设计说明(概要设计，详细设计等)

　　3)与开发组交流对需求理解的 记录(可以是开发人员的一个解释)

　　4)已经基本成型的UI(可以有针对性地补充一些用例)

　　简而言之，所有你能得到的项目文档，都尽量拿到。 从所得到的资料中，分解出若干小的“功能点”，理解“功能点”，编写相应的测试用例。

　　2. 用例的组织方式

　　不同的公司有不同的做法，原则上，只要方便管理和跟踪，怎么组织都可以的。

　　用例可以按大的功能块组织，如查询功能模块的用例，可以组织在一起，打印模块的测试用例，可以另外组织在一起。

　　在没有专门的测试用例管理工具的情况下，用例执行后会产生2种状态：“通过”、“失败”——这样加上“未 执行”的用例的状态，共3种状态。

　　即从“未执行”用例中执行一个用例后，该用例状态应为“失败”或“通 过”。将同一状态的用例组织在一起。

　　至于用例文件格式，可以是.DOC或.XLS(如果有专门的测试用例管理工具另当别论)。

　　3. 用例与其他材料的关联方式，即如何解决用例跟踪的问题

　　测试用例面临的比较大的风险有：需求的变更、设计的修改、需求的错误和遗漏等等。

　　由于用例的主要来源是需求和设计的说明，所以对用例的跟踪其实就是对需求和设计的跟踪，需求和设计的 变更势必引起测试用例的变更。

　　如前所说，将分解的功能点编号，与相应的用例联系起来。例如，你可以列一个表格，列出各个(编号的)功 能点和测试用例间的关联关系。

　　这样，当需求和设计发生变化时，你只需要跟踪“功能点”是否变化，是否增加了新的功能点。

　　4. 一个好的用例的表述要点，即用例中应当包含的信息

　　一个优秀的测试用例，应该包含以下信息：

　　1) 软件或项目的名称

　　2) 软件或项目的版本(内部版本号)

　　3) 功能模块名

　　4) 测试用例的简单描述，即该用例执行的目的或方法

　　5) 测试用例的参考信息(便于跟踪和参考)

　　6) 本测试用例与其他测试用例间的依赖关系

　　7) 本用例的前置条件，即执行本用例必须要满足的条件，如对数据库的访问权限

　　8) 用例的编号(ID)，如可以是 软件名称简写-功能块简写-NO.。

　　9) 步骤号、操作步骤描述、测试数据描述

　　10)预期结果(这是最重要的)和实际结果(如果有BUG管理工具，这条可以省略)

　　11)开发人员(必须有)和测试人员(可有可无)

　　12)测试执行日期

　　5. 给出一个测试用例的例子该范例已经包含一个测试用例的模板。

　　备注：本用例未考虑“企业代码”的输入情况;测试用例并未涵盖所有的非法输入，如非法输入中可能会有 “user=*,pw=*”的组合，对回车的默认操作，空格输入，对输入上溢的处理的处理(可能会跳过身份验证) 等等。

　　如果你有兴趣，至少可以再补充5-10条左右的输入组合(当然，如果步骤超过15步，用例的易操作 性就降低，你可以再创建一个测试用例如TC-TEP_Login_2)

原文转自：http://www.ltesting.net