系统测试用例模板文档格式.docx
《系统测试用例模板文档格式.docx》由会员分享,可在线阅读,更多相关《系统测试用例模板文档格式.docx(9页珍藏版)》请在冰豆网上搜索。
版本
日期
更改记录
审核
作者
1概述
1.1系统简述
系统名称:
系统版本:
系统功能描述:
1.2阅读对象
1.3参考文献
编号
资料名称
简介
出版单位
1
2
3
4
1.4术语解释
ST(SystemTesting):
系统测试。
IT(IntegrationTesting):
集成测试。
TS(TestScheme):
测试方案。
TD(TestDataandTestEnvironmentDesign):
测试数据和测试环境设计。
TC(TestCase):
测试用例。
该部分主要填写待测系统涉及到的一些业务术语或者缩写的解释。
2测试范围、目的与方法
2.1测试范围
此处说明在该系统测试中,需要测试哪些内容,以及不需要测试哪些内容。
2.2测试目标
根据项目(管理)计划中的质量目标,确定功能、非功能等方面的测试目标。
同时根据项目的测试目标说明系统可以接受的标准。
2.3测试用例覆盖
根据测试目标确定测试用例覆盖率。
需要说明该测试用例是根据什么标准进行覆盖,以及覆盖率是怎样的。
对于产品需求的覆盖:
如果该项目已经提供了产品需求说明书/需求规格说明书,则测试用例要说明对于产品需求的覆盖情况,比如功能覆盖率达到多少,非功能覆盖率达到多少。
计算方法:
根据产品需求说明书/需求规格说明书中对于功能点非功能点的描述,设测试需求总数为T。
编写测试用例的时候,每个用例都需要对应到具体的需求点,也就是说一个用例(编号)对应到一个多个需求(编号),或者一个或者多个用例对应一个需求,为此,在需求跟踪矩阵中可以建立需求和测试用例之间的对应关系,被用例覆盖的的需求数量为Tc(其中被覆盖的功能性需求为Tfc,被覆盖的非功能性需求为Tnfc,Tc=Tfc+Tnfc)。
测试用例对需求的覆盖率=Tc/T
功能性测试用例对需求的覆盖率=Tfc/T
非功能性测试用例对于需求的覆盖率=Tnfc/T
对于业务需求的覆盖:
如果该项目已经提供了业务需求说明书,则测试用例要说明对于业务需求的覆盖情况,比如功能用例覆盖率达到多少,非功能用例覆盖率达到多少。
产品需求和业务需求之间存在对应关系,通过对于需求的覆盖以及需求和用例之间对应关系就可以获取测试对于用例的覆盖。
如果只有业务需求,则
根据业务需求说明书中对于功能点非功能点的描述,设测试业务需求总数为TB。
编写测试用例的时候,每个用例都需要对应到具体的需求点,也就是说一个用例(编号)对应到一个多个需求(编号),或者一个或者多个用例对应一个需求,为此,在需求跟踪矩阵中可以建立需求和测试用例之间的对应关系,被用例覆盖的的需求数量为TBc(其中被覆盖的功能性需求为TBfc,被覆盖的非功能性需求为TBnfc,TBc=Tfc+Tnfc)。
测试用例对需求的覆盖率=TBc/T
功能性测试用例对需求的覆盖率=TBfc/T
非功能性测试用例对于需求的覆盖率=TBnfc/T
2.4测试方法
描述采用什么方法测试:
白盒测试或者黑盒测试,或者借助一些测试工具。
具体将如何进行测试?
此处需要具体分析和描述。
3测试条件和工具
3.1测试环境
在实际测试中,可能使用的开发环境或者实验室测试环境、现场环境,请根据实际情况分别列出这些环境的硬件条件和软件部署情况。
对于没有使用的环境不需要在文档中列出。
开发环境(如果没有使用该环境作为测试,则删除该节)
硬件环境:
软件环境:
网络环境:
实验室测试环境
现场环境(如果没有使用该环境作为测试,则删除该节)
3.2测试工具
对将在测试中采用的测试工具进行描述。
4测试用例
测试用例编写:
当项目提供了产品需求说明文档时,优先根据产品需求说明文档编写测试用例,此时需求编号就是产品需求编号。
当项目没有提供需求说明文档,但是提供了业务需求说明文档,则根据业务需求编写测试用例,此时需求编号就是业务需求编号。
4.1功能测试
功能模块1
4.1.1.1功能点1
4.1.1.1.1子功能点1
测试用例编号
『项目缩写』-『功能模块名缩写』-『编号』
需求编号
//需求编号
用例目标
//简要描述测试目的
需求描述
前提条件
//描述执行测试用例的前提条件
步骤
操作
输入数据
预期结果
1
//描述执行测试时进行的操作
//描述操作时输入的数据,一般情况下要求给出具体输入值。
//描述预期的返回值或界面呈现的内容
2
3
4
5
6
备注
4.1.1.1.2子功能点2
4.1.1.1.3子功能点n
4.1.1.2功能点2
。
4.1.1.3功能点n
功能模块2
功能模块n
4.2非功能测试
必要时将需求规范说明书中的非功能要求进行分解,得到子性能项。
由于非功能性涉及到的面比较广,可以根据实际情况单独形成一份系统的非功能测试用例。
以下列出的非功能项作为编写测试用例的参考。
并发性测试
如:
多用户并发操作时,系统应具备的性能(CPU、内存占用情况、数据库性能、实时刷新能力等)。
可靠性测试
系统能够满负荷正常运行一段时间(一个月或以上)。
采用上述表格方式描述。
实时性测试
执行特定操作的系统响应时间(依据需求而定)、界面刷新能力、对鼠标的响应能力、当系统数据量很大时、多用户并发操作时,系统响应时间是否在许可的范围内。
压力测试
系统承受大用户量并发访问的能力、系统所需资源几乎完全耗尽时,系统正常运行的能力
安全性测试
系统的权限控制、是否存在安全方面的漏洞。
安装/反安装测试
安装/反安装程序是否正常,反安装时应该清除所有安装内容。
兼容性测试
能否与其它软件同时正常工作,不会引起兼容性问题。
以及自身的向上向下兼容性。
移植性测试
移植到其它操作系统平台下能否正常工作。
扩展性测试
系统是否留出了可扩展的接口,其它程序可以方便的调用。
4.3用户界面测试
测试用户界面的友好性,操作菜单、操作按钮、列表、对话框、文本输入框等的通用性。
包括以下测试特性:
1、窗口切换、移动、改变大小是否正常;
2、各种界面元素的文字,如标题、提示等是否合乎约定;
3、各种界面元素的状态,如有效、无效、选中等状态是否正确;
4、各种界面元素是否支持键盘操作;
5、各种界面元素是否支持鼠标操作;
6、对话框的缺省焦点是否正确;
7、数据项的回显是否正确;
8、对于常用的功能,是否不必查阅操作手册即可使用;
9、对有风险的操作,是否有“确认”、“放弃”等提示;
10、命令的执行顺序是否合理;
11、联机帮助是否可行有效;
12、界面元素的布局是否合乎统一的约定;
13、界面元素的形状是否合乎统一的约定;
14、界面上的字体是否符合统一约定;
15、图标是否合乎统一的约定。
16、其他。
同样要采用上述表格方式描述。
5业务需求-产品需求-用例对应表
需求文档名称
//需求跟踪矩阵名称
业务需求编号
业务需求描述
产品需求编号
用例编号
用例描述
【说明】:
项目已经提供了业务需求说明文档时,需要提供业务用例相关信息;
没有提供业务需求说明文档时,可以不提供业务用例信息。
项目已经提供了产品需求规格说明文档时,需要提供产品需求相关信息;
没有产品需求文档时,可以不提供需求信息。
欢迎您的下载,
资料仅供参考!
致力为企业和个人提供合同协议,策划案计划书,学习资料等等
打造全网一站式需求