软件测试规范.docx

《软件测试规范.docx》由会员分享，可在线阅读，更多相关《软件测试规范.docx（14页珍藏版）》请在第一文库网上搜索。

1、软件测试规范XXXXXX科技有限公司2021年7月20日修订记录序号提交者更新日期更新内容12021-07-20文件新建22021-08-03完善1.3.3缺陷等级说明7.1功能测试、3451 .概要51.1 . 目的51.2 适用范围51.3 术语、名词定义52 .测试职责63 .测试流程图64 .测试申请74. 1项目初期75. 2客户等级划分76. 3迭代功能开发75 .测试准备81. 1文档分析85. 2测试计划86. 3测试用例87. 4测试软/硬件环境98. 5测试数据准备96 .测试执行96.1 测试准入条件96.2 项目测试阶段96.3 测试退出标准96 . 4测试变更97 .

2、测试方法101.1 1功能测试IO1.2 兼容测试111.3 安全测试121.4 性能测试121.5 友好性测试128 .缺陷管理131. 1.缺陷管理流程138. 2.提交缺陷139. 3.分配缺陷1310. 4.修改缺陷1411. 5.关闭缺陷1412. 6.保留缺陷149 .测试结果分析141510 .约定1 .概要1.1. 目的本文档是测试团队的日常工作规范，主要侧重测试工作流程的控制，明确软 件工程的各阶段测试应完成的工作以及开发应提供的文档。L 2适用范围本过程适用于软件测试过程中所有活动，即适用于参与项目的所有开发和测 试人员。1. 3术语、名词定义1.1.1 开发文档开发人员提

3、供给测试人员的开发文档至少包括以下几种：需求文档，概要设 计，详细设计等。1.1.2 测试文档测试文档包括测试计划、测试用例说明、BUG报告及分析、测试总结，以及 测试工作全部完成后的测试报告等。测试文档由测试人员编写并维护。测评BUg 提交到Bug管理工具中便于跟踪。1.1.3 缺陷等级说明I）A类（禅道中的级别为1级bug）：严重缺陷，最严重的等级，由于程序 所引起的死机、非法退出、死循环、导致数据库发生死锁、数据通讯错误：系 统与其他系统进行数据传递时出现错误、交易类的数值计算错误,分析类的数值 计算偏差在0.2%以上、没有达到性能指标，还包括系统崩溃、数据丢失、系统 主要功能丧失,无法

4、继续操作，造成重大安全隐患情况，如机密性数据的泄漏等 等。2） B类：（级别为2级bug）较严重缺陷，功能不符、数据流错误：数据在 系统内部流转中计算错误、程序接口错误、模块功能或特性没有实现；功能不完 整；导致其他模块无法正常使用等。3） C类：一般缺陷，界面错误，与详细文档不符、界面内容、格式错误、 简单的输入限制未放在前台进行控制、删除、保存操作未给出确认提示信息、辅 助说明描述不清楚、显示格式不规范、长时间操作未给用户进度提示或提示信 息。4） D类：较小缺陷，窗口文字未采用行业术语、可输入点击区域和只读 区域没有明显的区分标志、系统处理未优化、系统易用性方面的问题，例如查 询条件值为

5、空时通常默认为查询全部，如果还需要用户选择查询、条件为“全部” 则可以认为系统处理未优化。5） E类：建议缺陷，对网站使用的友好性有影响，如拼写错误、界面布局、 文档的可读性、操作的一致性、等系统设计之外的优化建议。2 .测试职责测试是软件开发过程中的重要组成部分，肩负着如下责任： 在项目的前景、需求文档确立基线前对文档进行测试，从用户体验和测 试的角度提出自己的看法。 编写合理的测试计划，并与项目整体计划有机地整合在一起。 编写覆盖率高的测试用例。 针对测试需求进行相关测试技术的研究。 认真仔细地实施测试工作，并提交测试报告供项目组参考。3 .测试流程图4 .测试申请开发组向测试负责人提交测

6、试申请，并说明：申请测试人员数量，进行哪些 功能的测试，测试重点，需要提交哪些测试文档，测试周期，测试环境要求等。4.1 项目初期项目立项初期时需提交需求文档、概要设计、详细设计、开发进度 表以及客户等级。4. 2客户等级划分客户种类测试项A类功能性、安全性、性能、兼容性、友好性B类功能性、安全性、兼容性、友好性C类功能性、兼容性、友好性D类功能性不同的等级客户测试的深度不同。4 . 3迭代功能开发开发组提交送测表，其中包括可测试内容和测试注意事项迭代功能测试流程图5 .测试准备5.1 文档分析测试人员和开发人员均应参加需求评审、设计评审。对需求说明书、系 统界面原型和软件设计说明书等进行阅读

7、和审查，与产品经理、项目经理 沟通,根据系统功能复杂度，系统业务复杂度估算开发时间和有效测试执行时间， 为项目总计划和测试计划的制定提供参考和依据。通过对文档分析，分解各功能模块，各功能点，为测试用例设计提供数据依 据。5.2 测试计划根据需求文档和项目计划制定测试计划。测试计划旨在说明各测试阶段任 务、人员分配、时间安排、测试要点、工作规范等。测试计划在策略和方法方面 说明如何计划、组织和管理测试项目。测试计划完成后应该在项目组内进行评审。 5. 3测试用例测试用例是为实施测试而向被测试系统提供的输入数据、操作或各种环境设 置以及期望结果的一个特定的集合。解决要测什么、怎么测和如何衡量的问题

8、。依据用户需求分析说明书、概要设计文档和开发详细设计说明书来设计测试 用例，发现需求与设计中的问题后，与需求作者及时沟通确认。5.3.1 测试用例设计方法测试用例的设计方法有等价类测试、边界值分析、基于判定表的测试、基于 因果图的测试、基于状态图的测试、基于场景的测试。在设计测试用例时常用的设计方法有等价类测试、边界值分析两种方法。5.3.2 测试用例操作步骤1、在设计编写测试用例时，首先要从测试用例库中选择相应功能的测试用 例，在原有测试用例的基础上依据系统需求文档对测试用例的进行修改、 更新，评审通过后将使用该测试用例测试被测系统。2、在测试的执行过程中和进行回归测试后，对已设计的测试用例

9、进行维护更新。5. 3.3测试用例选择准则测试用例的代表性：能够代表各种合理和不合理的、合法的和非法的、边界 和越界的，以及极限的输入数据、操作和环境设置等；测试结果的可判定性：即测试执行结果的正确性是可判定的或可评估的；测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。6. 4测试软/硬件环境根据需求文档提供的内容，和开发部沟通确定测试项目所需的软硬件环境， 完成对测试项0所需软硬件资源的准备工作，使软硬件资源得到满足。7. 5测试数据准备完成对测试项目基本数据的准备操作，包括数据库连接、用户信息、用户角 色权限、单位组织等信息和测试相关的测试数据。8. 测试执行8.1 测

10、试准入条件1、不接受无详细需求文档和开发说明的项目2、需要测试的项目至少提前2个工作日提交测试进行需求分析3、开发人员经过自测通过，至少保证程序可以正常运行；对应的功能在正常流程下是 可以正常使用8.2 项目测试阶段测试人员依据测试计划和测试用例进行测试活动。测试一般分为两个阶段：1、测试执行阶段：该阶段测试人员测试出bug后将缺陷提交至缺陷管理库。2、回归问题单：开发修改完bug之后，测试进行验证回归。6. 3测试退出标准1、测试对可回归缺陷的回归率达到100%。2、全部的测试用例集执行完毕。3、缺陷处理达到100%。6.4测试变更当需求变更，功能变化，测试人员根据变更情况，评估测试变更所需

11、时间,提出变更风险。如变更情况被项目组通过,测试人员将按上述流程进行变更测试。7.测试方法7.1功能测试1 .页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。2 .相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这 些影响是否都正确。3 .检查按钮的功能是否正确：如UPdate、cancel delete SaVe等功能是否 正确。4 .字符串长度检查：输入超出需求所说明的字符串长度的内容，看系统是否检 查字符串长度，会不会出错。5 .字符类型检查：在应该输入指定类型的内容的地方输入其他类型的内容（如 在应该输入整型的地方输入其他字符类型），看系统是否检查字符

12、类型，会 否报错。6 .标点符号检查：输入内容包括各种标点符号，特别是空格、各种引号、回车 键。看系统处理是否正确。7 .中文字符处理：在可以输入中文的系统输入中文，看会否出现乱码或出错。8 .检查带出信息的完整性：在查看信息和UPdate信息时，查看所填写的信息 是不是全部带出，带出信息和添加的是否一致。9 .信息重复：在一些需要命名，且名字应该唯一的信息输入重复的名字或ID, 看系统有没有处理，会否报错，重名包括是否区分大小写，以及在输入内容 的前后输入空格，系统是否作出正确处理。10 .检查删除功能：在一些可以一次删除多个信息的地方，不选择任何信息，按” delete,看系统如何处理，会

13、否出错;然后选择一个和多个信息，进行删 除，看是否正确处理。如果有多页，翻页选，看系统是否能正常删除，并且， 删除时是否有提示，让用户能够更正错误，不误删除。11 .检查添加和修改是否一致：检查添加和修改信息的要求是否一致，例如添加 要求必填的项，修改也应该必填;添加规定为整型的项，修改也必须为整型。12 .检查修改重名：修改时把不能重名的项改为已存在的内容，看会否处理，报 错。同时，也要注意，会不会报和自己重名的错。13 .重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否做 了处理。14 .检查多次使用back键的情况：在有back的地方，back,回到原来页面，再 ba

14、ck,重复多次，看会否出错。15 . SearCh检查：在有Seareh功能的地方输入系统存在和不存在的内容，看Se arch结果是否正确。如果可以输入多个Seareh条件，可以同时添加合理和 不合理的条件，看系统处理是否正确。搜索的时候注意特殊字符，输入特殊 字符后搜索系统是否处理正确。16 .输入信息位置：注意在光标停留的地方输入信息时，光标和所输入的信息会 否跳到别的地方。17 .上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。 对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做 至I。上传时注意将不能上传的文件格式修改为可上传的文件后缀，是否能够 上传

15、成功。下载文件，下载的文件能否打开或者保存，下载的文件是否有格 式要求。18 .必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否 有提示信息，如在必填项后加*19 .快捷键检查：是否支持常用快捷键，如CtrI+C Ctrl+V BaCkSPaCe等，对一 些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。20 .回车键检查：在输入结束后直接按回车键，看系统处理如何，会否报错。21 .刷新键检查：在Web系统中，使用浏览器的刷新键，看系统如何处理，是否 报错。22 .输入法全角/半角检查：在输入信息项中，输入半角或全角的信息，看系统 如何处理。23 .空格检查：在输入信息项中，输入一个或多个空格，看系统如何处理。24 .直接Url链接检查：直接输入各功能模块的Url地址，看系统如何处理。25 2兼容测试1