没有合适的资源?快使用搜索试试~ 我知道了~
如何编写好测试用例,测试用例来源于需求,要根据需求对每个功能模块进行编写。
资源推荐
资源详情
资源评论
功能测试用例的书写方式
功能性测试用例
1. 测试的来源,即测试的需求
测试用例的主要来源有: 1
)
需求说明 “ 及相关文档 2 )相关的设计说明(概要设计,详细 设
计等)
3 )与开发组交流对需求理解的 记录(可以是开发人员的一个解释)
4 )已经基本成型的 UI (可以有针对性地补充一些用例)
简而言之, 所有你能得到的项目文档, 都尽量拿到。 从所得到的资料中, 分解出若干小的 “ 功
能点 ” ,理解 “ 功能点 ” ,编写相应的测试用例。
2. 用例的组织方式
不同的公司有不同的做法,原则上,只要方便管理和跟踪,怎么组织都可以的。
用例可以按大的功能块组织,如查询功能模块的用例, 可以组织在一起, 打印模块的测试 用
例,可以另外组织在一起。
在没有专门的测试用例管理工具的情况下, 用例执行后会产生 2
种状态:
“ 通过 ”
、
“ 失败 ”— —
这样加上 “ 未 执行 ” 的用例的状态,共 3 种状态。
即从 “ 未执行 ” 用例中执行一个用例后,该用例状态应为 “ 失败 ” 或 “ 通 过 ” 。将同一状态的用
例组织在一起。
至于用例文件格式,可以是。 DOC 或。 XLS (如果有专门的测试用例管理工具另当别论) 。
3. 用例与其他材料的关联方式,即如何解决用例跟踪的问题
测试用例面临的比较大的风险有:需求的变更、设计的修改、需求的错误和遗漏等等。
由于用例的主要来源是需求和设计的说明,所以对用例的跟踪其实就是对需求和设计的跟
踪,需求和设计的 变更势必引起测试用例的变更。
如前所说,将分解的功能点编号,与相应的用例联系起来。例如,你可以列一个表格,列 出
各个(编号的)功 能点和测试用例间的关联关系。
这样, 当需求和设计发生变化时, 你只需要跟踪 “ 功能点 ” 是否变化, 是否增加了新的功能
点。
4. 一个好的用例的表述要点,即用例中应当包含的信息
一个优秀的测试用例, 应该包含以下信息: 1
)
软件或项目的名称 2
)
软件或项目的版本 (内
部版本号)
3
)
功能模块名 4
)
测试用例的简单描述,即该用例执行的目的或方法 5
)
测试用例的参 考
信息(便于跟踪和参考)
6
)
本测试用例与其他测试用例间的依赖关系 7
)
本用例的前置条件,即执行本用例必须 要
满足的条件,如对数据库的访问权限 8
)
用例的编号( ID
) ,如可以是
软件名称简写 - 功能块 简
写 -NO. 。
资源评论
xianghu_yue
- 粉丝: 0
- 资源: 13
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功