系统测试用例模板(共10页).doc

《系统测试用例模板(共10页).doc》由会员分享，可在线阅读，更多相关《系统测试用例模板(共10页).doc（10页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、精选优质文档-倾情为你奉上【系统名称】系统测试用例研发地点单击填写部门文档作者 系统测试用例项目名称:XXXXXXXXXXXXX项目阶段:测试阶段文档主题:XXXXXXXXXXXXX文档类型:测试文档分发对象:内部: 公司内部的相关机构 外部: 其他公司历史记录版本日期更改记录审核作者系统测试用例目 录1 概述1.1 系统简述系统名称：单击此处填写系统版本：单击此处填写系统功能描述：单击此处填写1.2 阅读对象1.3 参考文献编号资料名称简介作者日期出版单位12341.4 术语解释ST（System Testing）：系统测试。IT（Integration Testing）：集成测试。TS（T

2、est Scheme）：测试方案。TD（Test Data and Test Environment Design）：测试数据和测试环境设计。TC（Test Case）：测试用例。该部分主要填写待测系统涉及到的一些业务术语或者缩写的解释。2 测试范围、目的与方法2.1 测试范围此处说明在该系统测试中，需要测试哪些内容，以及不需要测试哪些内容。2.2 测试目标根据项目（管理）计划中的质量目标，确定功能、非功能等方面的测试目标。同时根据项目的测试目标说明系统可以接受的标准。2.3 测试用例覆盖根据测试目标确定测试用例覆盖率。需要说明该测试用例是根据什么标准进行覆盖，以及覆盖率是怎样的。对于产品需求

3、的覆盖：如果该项目已经提供了产品需求说明书/需求规格说明书，则测试用例要说明对于产品需求的覆盖情况，比如功能覆盖率达到多少，非功能覆盖率达到多少。计算方法：根据产品需求说明书/需求规格说明书中对于功能点非功能点的描述，设测试需求总数为T。编写测试用例的时候，每个用例都需要对应到具体的需求点，也就是说一个用例（编号）对应到一个多个需求（编号），或者一个或者多个用例对应一个需求，为此，在需求跟踪矩阵中可以建立需求和测试用例之间的对应关系，被用例覆盖的的需求数量为Tc（其中被覆盖的功能性需求为Tfc,被覆盖的非功能性需求为Tnfc,Tc=Tfc+Tnfc）。测试用例对需求的覆盖率=Tc/T功能性测试

4、用例对需求的覆盖率=Tfc/T非功能性测试用例对于需求的覆盖率=Tnfc/T对于业务需求的覆盖：如果该项目已经提供了业务需求说明书，则测试用例要说明对于业务需求的覆盖情况，比如功能用例覆盖率达到多少，非功能用例覆盖率达到多少。计算方法：产品需求和业务需求之间存在对应关系，通过对于需求的覆盖以及需求和用例之间对应关系就可以获取测试对于用例的覆盖。如果只有业务需求，则根据业务需求说明书中对于功能点非功能点的描述，设测试业务需求总数为TB。编写测试用例的时候，每个用例都需要对应到具体的需求点，也就是说一个用例（编号）对应到一个多个需求（编号），或者一个或者多个用例对应一个需求，为此，在需求跟踪矩阵中

5、可以建立需求和测试用例之间的对应关系，被用例覆盖的的需求数量为TBc（其中被覆盖的功能性需求为TBfc,被覆盖的非功能性需求为TBnfc,TBc=Tfc+Tnfc）。测试用例对需求的覆盖率=TBc/T功能性测试用例对需求的覆盖率=TBfc/T非功能性测试用例对于需求的覆盖率=TBnfc/T2.4 测试方法描述采用什么方法测试：白盒测试或者黑盒测试，或者借助一些测试工具。具体将如何进行测试？此处需要具体分析和描述。3 测试条件和工具3.1 测试环境在实际测试中，可能使用的开发环境或者实验室测试环境、现场环境，请根据实际情况分别列出这些环境的硬件条件和软件部署情况。对于没有使用的环境不需要在文档中

6、列出。3.1.1 开发环境（如果没有使用该环境作为测试，则删除该节）硬件环境：软件环境：网络环境：3.1.2 实验室测试环境硬件环境：软件环境：网络环境：3.1.3 现场环境（如果没有使用该环境作为测试，则删除该节）硬件环境：软件环境：网络环境：3.2 测试工具对将在测试中采用的测试工具进行描述。4 测试用例测试用例编写：当项目提供了产品需求说明文档时，优先根据产品需求说明文档编写测试用例，此时需求编号就是产品需求编号。当项目没有提供需求说明文档，但是提供了业务需求说明文档，则根据业务需求编写测试用例，此时需求编号就是业务需求编号。4.1 功能测试4.1.1 功能模块14.1.1.1 功能点1

7、4.1.1.1.1 子功能点1测试用例编号项目缩写-功能模块名缩写-编号需求编号/需求编号用例目标/简要描述测试目的需求描述前提条件/描述执行测试用例的前提条件步骤操作输入数据预期结果1/描述执行测试时进行的操作/描述操作时输入的数据，一般情况下要求给出具体输入值。/描述预期的返回值或界面呈现的内容23456备注4.1.1.1.2 子功能点24.1.1.1.3 子功能点n4.1.1.2 功能点2。4.1.1.3 功能点n4.1.2 功能模块24.1.3 功能模块n4.2 非功能测试必要时将需求规范说明书中的非功能要求进行分解，得到子性能项。由于非功能性涉及到的面比较广，可以根据实际情况单独形成

8、一份系统的非功能测试用例。以下列出的非功能项作为编写测试用例的参考。4.2.1 并发性测试如：多用户并发操作时，系统应具备的性能（CPU、内存占用情况、数据库性能、实时刷新能力等）。4.2.2 可靠性测试如：系统能够满负荷正常运行一段时间（一个月或以上）。采用上述表格方式描述。4.2.3 实时性测试如：执行特定操作的系统响应时间（依据需求而定）、界面刷新能力、对鼠标的响应能力、当系统数据量很大时、多用户并发操作时，系统响应时间是否在许可的范围内。采用上述表格方式描述。4.2.4 压力测试如：系统承受大用户量并发访问的能力、系统所需资源几乎完全耗尽时，系统正常运行的能力采用上述表格方式描述。4.

9、2.5 安全性测试如：系统的权限控制、是否存在安全方面的漏洞。采用上述表格方式描述。4.2.6 安装/反安装测试如：安装/反安装程序是否正常，反安装时应该清除所有安装内容。采用上述表格方式描述。4.2.7 兼容性测试如：能否与其它软件同时正常工作，不会引起兼容性问题。以及自身的向上向下兼容性。采用上述表格方式描述。4.2.8 移植性测试如：移植到其它操作系统平台下能否正常工作。采用上述表格方式描述。4.2.9 扩展性测试如：系统是否留出了可扩展的接口，其它程序可以方便的调用。采用上述表格方式描述。4.3 用户界面测试测试用户界面的友好性，操作菜单、操作按钮、列表、对话框、文本输入框等的通用性。

10、包括以下测试特性：1、窗口切换、移动、改变大小是否正常；2、各种界面元素的文字，如标题、提示等是否合乎约定；3、各种界面元素的状态，如有效、无效、选中等状态是否正确；4、各种界面元素是否支持键盘操作；5、各种界面元素是否支持鼠标操作；6、对话框的缺省焦点是否正确；7、数据项的回显是否正确；8、对于常用的功能，是否不必查阅操作手册即可使用；9、对有风险的操作，是否有“确认”、“放弃”等提示；10、命令的执行顺序是否合理；11、联机帮助是否可行有效;12、界面元素的布局是否合乎统一的约定；13、界面元素的形状是否合乎统一的约定；14、界面上的字体是否符合统一约定；15、图标是否合乎统一的约定。16、其他。同样要采用上述表格方式描述。5 业务需求产品需求用例对应表需求文档名称/需求跟踪矩阵名称业务需求编号业务需求描述产品需求编号需求描述用例编号用例描述【说明】：项目已经提供了业务需求说明文档时，需要提供业务用例相关信息；没有提供业务需求说明文档时，可以不提供业务用例信息。项目已经提供了产品需求规格说明文档时，需要提供产品需求相关信息；没有产品需求文档时，可以不提供需求信息。专心-专注-专业