软件测试规范说明书

1、文号：软（2014）第0305号文号软（2014）第0305号日期2014-03-25 *系统软件测试规范说明书作者：黄颖 日期：2014-03-25 变更记录版本号版本日期变更类型版本描述人员0.12014-03-25新建黄颖0.12014-04-09修改修改要点：1. 调整排版唐朝强审核通过目录变更记录1目录21前言31.1目的32测试输出物32.1测试计划32.2测试报告42.3测试用例43测试计划编写规范43.1内容编写规范43.1.1确定测试进度43.1.2确定测试资源43.1.3给出项目背景43.1.4确定测试范围53.1.5确定测试策略53.1.6风险评估53.2书写格式要求54

2、测试报告编写规范54.1内容书写要求54.2格式书写要求65测试用例65.1用例设计原则65.2 用例的书写规范65.2用例设计完成标准75.3用例执行的规范75.4用例的覆盖标准75.4.1正确性测试：75.4.2容错性测试：75.4.3安全性和访问控制测试：75.4.4接口测试：75.4.5数据库测试：85.4.6边界值分析法：85.4.7等价划分：85.4.8错误推测：85.4.9性能评估测试：85.4.10负载测试：85.4.11强度测试：85.4.12用户界面测试：96BUG规范96.1缺陷录入规范96.2缺陷等级划分规范106.3优先级划分116.4缺陷状态修改规范116.5缺陷统

3、计规范117项目总结118需求/代码变更129版本发布标准121 前言1.1 目的找到适合本公司测试流程及规范2 测试输出物2.1 测试计划目的：使项目组成员对项目的计划有一个总体的认识，以便于项目的管理输出时间：需求评审通过后2天内具体模板请查看：文档规范测试计划模板2.2 测试报告目的：对每个阶段的执行结果，进行输出，使大家对项目的每个阶段有一个把控输出时间：每个阶段测试完成有有一次输出具体模板请查看文档规范测试报告模板2.3 测试用例输出时间：研发提测之前详见：文档规范测试用例模板3 测试计划编写规范模板详见：文档规范-测试计划模板3.1 内容编写规范3.1.1 确定测试进度对每一个阶段

4、，每个人需要做什么给出开始/结束时间3.1.2 确定测试资源1. 测试环境资源暂为可选项2. 人力资源3.1.3 给出项目背景对因为什么原因而进行本次项目的原因和目的进行简要说明。注：暂为可选项3.1.4 确定测试范围对于本次需要测试的范围给予相关说明注：暂为可选项3.1.5 确定测试策略对每个功能的测试需要采用哪些测试手段给予说明注：暂为可选项3.1.6 风险评估对项目存在的环境资源，人力资源，需求变更，业务复杂度给予评估注：暂为可选项3.2 书写格式要求1. 标题须加粗显示，字体为宋体，字体大小为20，文字对齐方式选择“居中”，单元文本框对齐方式选择“垂直居中”2. 列名须加粗显示，字体为

5、宋体，字体大小为11，文字对齐方式选择“居中”，单元文本框对齐方式选择“垂直居中”3. 目录的模块名称须用链接跳转到相应模块4. 除标题和列明的对齐方式外，其他均选择“文本左对齐”，字体为宋体，字体大小为11。5. 单元格式设置为：外边框加内边框6. 行高277. 当填写内容较多时选择“自动换行”8. 版本号以0001+系统名称+新增/修改功能点（如一个功能须分期完成则命名为一期/二期）4 测试报告编写规范4.1 内容书写要求根据测试的结果，编写测试总结报告（主要包含以下几点1. 测试资源概述（多少人，多少时间）2. 测试结果摘要（分别描述各个测试阶段的测试结果，那些功能实现了，那些没有）3.

6、 缺陷分析（按照缺陷的属性进行分析）4. 测试需求覆盖率（可能一部分测试需求因为资源和优先级的因素没有进行测试，那么在这里要进行说明）5. 测试评估（从总体对项目的质量进行评估）6. 测试组建议（测试组人员根据项目的测试情况给出工作改进建议）4.2 格式书写要求文档格式参见具体的模板，其中统一了封面、变更历史、页眉、页脚、目录、文档多级目录等格式。最简便的方法是新建文档时直接复制模板文档，改为需要的文档名、文号、日期等。下面对有几点格式重点说明：1. 编号：必须采用Word所带的多级编号，不得人工编号，其好处时，增删时编号自动修改，且新增标题时只需用格式刷复制任何地方的同级标题格式即可自动编号

7、。2. 大纲：必须建立文档大纲结构。如果采用模板中的标题示范格式，则已包括文档大纲结构的定义，直接用格式刷复制相应级别的标题即可。这样好处是：打开视图中的“文档结构图”时，左边将显示树型的目录结构，方便导航。同时，有文档结构才能自动生成目录。3. 目录：必须采用自动目录生成文档目录。模板中也已有示例。4. 变更历史：所有修改、审核等过程均在此记录，修改记录要详细说明修改的具体地方和要点。5. 表格列名：字体为宋体，大小116. 单元格字体，表格单元格字体为宋体，大小 小五5 测试用例5.1 用例设计原则1. 具有代表性，典型性2. 正确，错误或异常的输入3. 多考虑用户实际使用场景4. 避免含

8、糊的测试用例5. 尽量将据有相同功能的测试用例归类6. 避免冗长和复杂的测试5.2 用例的书写规范1. 用例模板须包含：系统模块，功能点，用例编号，用例说明，输入标准，预期结果，测试结果2. 用例的分布根据功能点来进行划分3. 一个用例只能有一个输出结果4. 如需求在测试过程中发生变更，则需同时更新用例5. 字体大小为：宋体，大小11 （注：暂定）6. 列名须加粗显示，字体为宋体，字体大小为11，文字对齐方式选择“居中”，单元文本框对齐方式选择“垂直居中”5.2 用例设计完成标准1. 测试用例须覆盖所有的测试需求2. 符合测试策略的设计3. 测试用例评审通过5.3 用例执行的规范1. 执行通过

9、或未通过的用例必须变其用例状态（pass/fail）2. 改变用例状态的时间必须是用例执行的当天时间3. 分配给每个人的用例必须全部执行完成，并记录测试情况注意：如用excel管理只需修改测试结果状态即可5.4 用例的覆盖标准5.4.1 正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用 例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。5.4.2 容错性测试：程序能够接收正确数据输入并且产生正确（预期）的输出， 输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示 并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行

10、任意操作。5.4.3 安全性和访问控制测试：安全性和访问控制测试侧重于安全性的两个关键方面：1. 应用程序级别的安全性，包括对数据或业务功能的访问。2. 系统级别的安全性，包括对系统的登录或远程访问5.4.4 接口测试：确保接口调用的正确性，测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。5.4.5 数据库测试：确保数据库访问方法和进程正常运行，数据不会遭到损坏，依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。5.4.6 边界值分析法：确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在测试过程中主要输入一些合法数据

11、/非法数据，主要在边界值附近选取。5.4.7 等价划分：将所有可能的输入数据（有效的和无效的）划分成若干个等价类。5.4.8 错误推测：主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。5.4.9 性能评估测试：性能评测是一种性能测试，他对响应时间，事物处理速率和其他与时间相关的需求进行评测和评估。性能测试的目的是核实性能需求是否都已满足。a) 测试目标：核实所指定的事物或业务功能在以下情况下的性能行为：i. 正常的预期工作量ii. 预期的最繁重工作量5.4.10 负载测试：负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响

12、应时间、事务处理速率和其他与时间相关的方面。a) 测试目标：核实所指定的事物在不同的工作条件下的性能时间5.4.11 强度测试：强度测试是一种性能测试，实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。a) 测试目标：核实测试对象能够在以下强度条件下正常运行，不会出现任何错误：1. 服务器上几乎没有或根本没有可用的内存2. 连接或模拟了最大实际（实际允许）数量的客户机3. 多个用户对相同的数据执行相同的事务4. 最繁重的事务量或最差的事务组合（请参见上面的“性能测试”）。注：强度测试的目标可表述为确定和记录那些使系统无法继续正常运行的情况或条件。5.4.12 用户界面测试：用户界

13、面（UI）测试用于核实用户与软件之间的交互。UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。a) 测试目标：通过测试进行的浏览可正确反映业务的功能和需求，这种浏览包括窗口与窗口之间，字段与字段之间的浏览以及各种访问方法（Tab建，鼠标移动，快捷键）的使用，窗口的对象和特征（如：菜单，大小，位置，状态）都符合标准。6 Bug规范6.1 缺陷录入规范必须输入以下内容：1. Bug标题（按功能名称进行命名：【登录】用户名为空登录有误）2. 项目名称（学生管理系统）3. 模块路径（系统管理/用户管理）4. 严重程度（详见缺陷等级划分）5. 优先级（详见优先级划分）6.

14、 Bug类型（代码缺陷，需求缺陷，设计缺陷）7. 创建人8. 指派给谁9. 如何发现（功能测试，性能测试等）10. 复现步骤11. 预期结果12. 实际结果13. 注释14. 有截图最好上传截图6.2 缺陷等级划分规范 有了缺陷严重等级的划分规范，测试人员、开发人员和其它项目组成员，对于测试缺陷就有了统一的标准，也不会因为某个缺陷由于严重等级的问题项目组成员争论半天，提高了测试效率。等级描述说明5-紧急发现可重复出现的致命问题导致系统崩溃；导致程序模块丢失；主业务流程出现断点；内存泄漏；导致死机4-非常高发现可重复出现的严重问题被测功能不能正确实现；软件错误导致数据丢失；被测数据处理

15、错误；用户需求未实现。3-高一般性的错误或功能实现有不完美处操作界面错误；打印内容、格式错误；简单的输入限制未放在前台进行控制；删除操作未给出提示。2-中细小的错误界面不规范；辅助说明描述不清楚；输入输出不规范；长操作未给用户提示；提示窗口文字未采用行业术语。1-低建议类错误需求说明书、用户手册中未说明，但影响用户对软件使用的方便性等6.3 优先级划分Bug处理的优先级。由Bug的处理人员按照当前业务需求、开发计划和资源状态指定，其中1的优先级最高，4的优先级最低。详细划分如下：1 一般1级为需要立即解决的问题；2 2级为需要在指定时间内解决的问题；3 3级为项目开发计划内解决的问题；4 4级

16、为资源充沛时解决的问题6.4 缺陷状态修改规范 要求测试管理系统的管理人员，根据不同的项目角色，准确分配缺陷管理系统的使用权限。目的：测试人员在项目中提交的bug在未修复或未验证通过的情况下，研发人员不得私自关闭该bug状态。6.5 缺陷统计规范1. 在项目的测试每个阶段都要对问题单进行统计2. 按严重程度和bug类型分别进行统计3. 先按项目统计，在按照个人bug统计4. 项目完成后每周对问题单进行统计一次，以便项目组成制定自己在前面版本还有多少问题单尚未修复7 项目总结在每个版本完成过后须对项目进行项目总结，主要针对以下方面进行：1. 项目中遇到的问题有那些2. 有什么地方是做得比较好的3. 有什么地方做得不够好的4. 把项目中遇到问题的解决办法总结出来，以免下次再出现类似问题8