功能测试用例的书写方式 软件测试
功能性测试用例
1. 测试的来源，即测试的需求
测试用例的主要来源有：
1) 需求说明”及相关文档2)相关的设计说明(概要设计，详细设计等)3)与开发组交流对需求理解的
记录(可以是开发人员的一个解释)4)已经基本成型的UI(可以有针对性地补充一些用例)
简而言之，所有你能得到的项目文档，都尽量拿到。
从所得到的资料中，分解出若干小的“功能点”，理解“功能点”，编写相应的测试用例。
2. 用例的组织方式
不同的公司有不同的做法，原则上，只要方便管理和跟踪，怎么组织都可以的。
用例可以按大的功能块组织，如查询功能模块的用例，可以组织在一起，打印模块的测试用例，可以另外组
织在一起。
在没有专门的测试用例管理工具的情况下，用例执行后会产生2种状态：“通过”、“失败”——这样加上“未
执行”的用例的状态，共3种状态。即从“未执行”用例中执行一个用例后，该用例状态应为“失败”或“通
过”。将同一状态的用例组织在一起。
至于用例文件格式，可以是.DOC或.XLS(如果有专门的测试用例管理工具另当别论)。
3. 用例与其他材料的关联方式，即如何解决用例跟踪的问题
测试用例面临的比较大的风险有：需求的变更、设计的修改、需求的错误和遗漏等等。
由于用例的主要来源是需求和设计的说明，所以对用例的跟踪其实就是对需求和设计的跟踪，需求和设计的
变更势必引起测试用例的变更。
如前所说，将分解的功能点编号，与相应的用例联系起来。例如，你可以列一个表格，列出各个(编号的)功
能点和测试用例间的关联关系。这样，当需求和设计发生变化时，你只需要跟踪“功能点”是否变化，是否增
加了新的功能点。
文章来源于领测软件测试网 https://www.ltesting.net/
