|
软件测试规范
版 本 号: v1.1
编制/日期: 2021/7/30
审核/日期:
批准/日期:
文件版本信息
版本号 主要修订内容 修订日期 修订者 说明
v1.0 创建 2021/7/15
V1.1 修改缺陷处理流程图、测试完成标准 2021/7/30
目录
- 目的 4
- 适用范围 4
- 职责 4
- 软件测试流程 4
4.1. 测试依据 4
4.2. 制定测试计划 4
4.3. 单元测试 5
4.4. API接口测试 5
4.5. 系统测试 5
4.6. 编写测试用例 6
4.6.1. 测试点 6
4.6.2. 输入数据 6
4.6.3. 测试描述 6
4.6.4. 预期输出数据 6
4.6.5. 实际输出 6
4.6.6. 正确与否 7
4.6.7. 测试结论 7 - 缺陷管理 7
5.1. 缺陷的定义及其基本属性 7
5.2. 缺陷等级定义 7
5.3. 缺陷优先级定义 8
5.4. 缺陷状态定义 8
5.5. 缺陷管理流程 8 - 处理机制 9
6.1. 退回机制 9
6.2. 异常情况处理机制 10
6.3. 报告机制 10 - 测试完成标准 10
7.1. 缺陷修复率标准 10
7.2. 测试准出标准 10
7.3. 测试结论及评价标准 10
7.4. 输出 11 - 其它约束 11
- 目的
确保软件产品质量，使产品能够顺利交付和通过验收的一项重要措施。 - 适用范围
适用于项目开发过程中的单元测试、API接口测试、系统测试。 - 职责
? 测试主管组织编制《测试计划》、《测试方案》，指导和督促测试人员完成各阶段的测试工作；
? 测试主管依照确认规程和准则对工作产品进行确认，提出对确认规程和准则的修改意见；
? 测试人员按照《测试计划》、《测试方案》完成所承担的测试任务设计执行测试用例，并按要求填写《测试跟踪记录表》；
? 测试主管与项目负责人组织测试环境的建立；
? 研发人员确认修改测试人员提交的缺陷；
? 测试主管根据《测试跟踪记录表》编写《测试报告》。 - 软件测试流程
无规矩不成方圆，做好项目就是做正确的事情，而正确地处理事情才能更好地提高效率。在接到一个新的项目后，测试部门需要按照以下六个流程逐步开展测试工作，该流程在实际的工作中，可根据实际情况进行补充和完善。
4.1. 测试依据
详细设计是所有测试的依据。因此设计人员应向测试人员提供《系统需求规格说明书》、《详细设计》、《概要设计》等有关资料。测试人员必须认真阅读，真正弄懂系统需求和详细设计。
4.2. 制定测试计划
在测试之前，由项目负责人根据设计的要求，组织人员编制相应的《测试计划》、《测试方案》，应包括以下内容：
? 测试目的
? 所需人员及相应培训要求
? 测试环境、测试工具和测试软件
? 测试用例、测试数据和预期结果
? 测试时间安排
4.3. 单元测试
项目开发实现过程中，每个程序单元（程序单元的划分视具体开发工具而定，一般定为函数或子程序级）编码调试通过后，要及时进行单元测试。
单元测试由单元开发者自己进行，使用白盒测试方法，根据程序单元的控制流程，争取代码覆盖率达到100%。对于交互式运行的产品，不便于进行自动测试的，可以采用功能测试的方法进行。
单元测试针对程序模块，从程序的内部结构出发设计测试用例。多个模块可以独立进行单元测试。
? 单元测试内容：包括模块API测试、局部数据结构测试、路径测试、错误处理测试等；
? 单元测试组织原则：一般是根据开发进度安排对已开发完成的单一模块进行测试；
? 单元测试停止标准：完成了所有规定单元模块的测试，单元测试中发现的缺陷均得到修改。
4.4. API接口测试
接口测试主要用于外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等，验证各功能模块是否能协调工作、参数传递及功能调用是否正常。
API接口测试由测试负责人组织策划并实施，测试过程中将问题记录在缺陷管理平台。
API接口测试一般可由测试人员根据API接口文档通过接口测试工具（Postman、JMeter）或接口自动化测试框架编写测试用例脚本，待接口开发完成后，可进行手工接口测试，进而进行接口自动化测试，并生成测试报告。
4.5. 系统测试
在项目开发完成之后，应对整个系统软件和硬件进行系统测试。对功能、性能、可靠性、健壮性、压力承受力等方面分别进行评价，以验证系统是否满足规定的需要。
系统测试由测试主管组织策划并实施，系统测试过程将问题记录在缺陷管理平台。
系统测试一般进行如下几种情况的测试：
功能逻辑测试：
? 正常测试
? 非正常测试
? 破坏性测试
? 边界情况
? 非法情况
? 强度测试
? 性能测试
? 兼容性测试
? 用户友好性测试
界面设计规范测试：
? 光标的初始位置
? 字体是否统一
? 字号是否符合规定
? 标题颜色
? 按钮的名称是否规范
? 界面布局是否合理，整体效果如何
输入值测试：
? 数据类型
? 数据长度
? 约束条件是否满足是否完成
? TAB和Enter键是否起作用
? 键盘操作能否全部代替鼠标操作
? 输入（光标）是否按顺序前进
异常情况测试：
? 在完成正常功能测试后，按正常处理的相同操作顺序，执行与正常处理不同的动作例如
? 正常处理中要求输入日期的字段，这时输入字符或数字
? 正常处理中输入字段有范围要求，这时输入超过范围的值
? 正常处理中用两个值限定范围，这时用一个值或不限定
? 正常处理中要求用“Tab”键，这时按“ Enter”键或其他键
? 使用不同于指定的按钮操作
4.6. 编写测试用例
4.6.1. 测试点
将测试模块分解成多个功能点，测试点应涵盖功能点，也涵盖了正常测试和异常测试。
4.6.2. 输入数据
输入数据包括界面输入数据、数据库的初始数据及其他外部输入数据。
4.6.3. 测试描述
描述测试步骤，包括：操作员所执行的动作（包括鼠标、键盘、加载外部数据等操作）；系统的反应，包括：光标定位、光标聚焦、显示字段值、按钮的封闭和放开、功能键的封闭和放开、系统提示和系统消息等。
4.6.4. 预期输出数据
按准备的输入数据和设计要求的处理过程，模块应输出的数据。
输出数据包括：屏幕输出数据、输出到数据库的数据、输出到其他外部介质上的数据，并指出断点结果或最终结果。
4.6.5. 实际输出
填写本测试点程序运行后的实际输出。
4.6.6. 正确与否
程序运行后,实际输出结果和预期输出结果一致时，为正常，否则为不正常。
4.6.7. 测试结论
填写本次测试的结论,是合格或不合格。若不合格时，应总结存在的问题，可以让修改者一目了然。 - 缺陷管理
5.1. 缺陷的定义及其基本属性
缺陷是指在软件开发过程中的针对软件产品和开发过程中的问题，这些问题已经影响或可能会影响软件产品的质量。缺陷应该具备以下属性，也就是往缺陷管理平台提交的缺陷应该具备以下属性：
属性名称 描述
缺陷标题 简单描述缺陷出现的步骤及现象
缺陷类型 根据缺陷的自然属性划分的缺陷种类
缺陷严重程度 因缺陷引起的故障对软件产品的影响程度
缺陷所处的模块或子系统 缺陷所处的模块或子系统
缺陷出现的几率 发现缺陷的几率
缺陷的重现步骤 重现步骤
附件 相关的截图、视频、日志等
备注 其它描述
5.2. 缺陷等级定义
缺陷的严重程度反映缺陷的发现现象可能造成的影响或后果来定义，分为以下五类:
等级 影响 说明
A类-致命 系统死机 系统、环境及应用崩溃死机
数据损坏 软件发生故障数据毁坏或丢失
功能失效 软件发生故障导致功能师表
异常退出 软件发生故障异常退出
B类-严重 功能缺少 用户需求未实现
功能错误 实际提供功能与用户需求不一致，流程或接口中，数据未做关联。
计算错误 结果计算错误
精度错误 精度与用户需求不一致
交互错误 与其它软件或系统交换数据出错，包括导出文件后内容丢失
性能缺陷 未达到需求说明书中所规定的性能指标，例如响应时间过长
C类-高 控制错误 输入未控制和未判断导致功能异常、信息缺失,或界面显示、提示信息异常等;如必输项、重复、数据约束、数据长度;删除未确认;屏蔽判定;正常逻辑错误。
D类-一般 显示错误 界面显示错误,页面刷新问题,提示信息不准确,错别字,打印内容格式错误。可修改字段与不可修改字段中字体颜色标示未区别
不易操作 界面风格不一致,术语不统对话框颜色不致,按钮大小不统提示信息不一致;未使用默认值,默认值使用不便或不正确。
E类-低 建议意见 需求说明书、用户手册中未说明,但影响用户对软件使用的方便性等
5.3. 缺陷优先级定义
缺陷优先级 描述
紧急 如果故障妨碍测试人员的进一步测试工作，应立即修复。
极高 必须修改，版本发布钱必须修正。
高 必须修改，不一定马上修改，但需确定在某个特定版本发布前修正。
中 缺陷需要正常排队等待修复或列入软件发布清单。
低 留到组后解决，如果项目的进度跟紧张可以在产品发布以前不解决。
5.4. 缺陷状态定义
缺陷状态 描述
New 测试人员提交一个新的缺陷，状态为New
Open 开发人员确认缺陷，将状态置为Open，还没有修改
Fixed 缺陷已经修改，等待测试人员回归验证
Close 缺陷经测试人员回归验证通过后状态置为Close
Reopen 缺陷经测试人员回归验证未通过后状态置为Reopen
Later 遗留，经项目经理组织评审后确认此缺陷在版本中不修改。
5.5. 缺陷管理流程
缺陷处理流程图：
流程描述：
- 测试人员发现缺陷提交给开发，状态置为New；
- 开发人员判断是否为缺陷，如果是缺陷，状态置为Open；。
- 开发人员进行修改，修改完成后更改缺陷状态为Fixed；
- 如果不是缺陷，退回给测试人员并描述退回原因；
- Fixed状态的缺陷由测试人员进行回归验证，确认回归通过，关闭缺陷状态置为Close；
- 验证未通过的缺陷重新打开，开发人员继续修改，直至验证通过，关闭缺陷。
- 测试人员需要对开发人员退回的缺陷进行确认，如有争议可与项目经理或产品经理沟通确认。
- 处理机制
6.1. 退回机制
若在测试过程中发生如下情况,将系统退回到开发部门
? 经过测试后，发现与需求说明规格说明书中定义的功能项存在较大的差异；
? 单一模块，测试过程中发现缺陷数量较多或者无法继续进行系统其它功能模块的测试，继续测试无意义；
? 测试过程中，频繁死机或系统崩溃；
? 业务流程出现断点，无法继续测试。
6.2. 异常情况处理机制
非正常情况下，需要进行特别处理的情形，此情况需要部门领导签字确认。
如：上线时间紧急的情况下，未经测试人员充分测试就需要发布版本。
6.3. 报告机制
若出现以下情况,需要及时向部门领导和项目经理汇报的情况：
? 测试后期出现重大逻辑错误,修改测试影响上线时间；
? 测试过程中用户需求出现重大变更；
? 测试负责人定期汇报测试情况。 - 测试完成标准
7.1. 缺陷修复率标准
各等级缺陷修复率标准：
? A类-致命缺陷：100%得到修改并且复测通过
? B类-严重缺陷：100%得到修改并且复测通过
? C类-高缺陷：95%得到修改并且复测通过
? D类-一般缺陷：90%得到修改并且复测通过
? E类-低缺陷：90%得到修改并且复测通过
7.2. 测试准出标准
? 被测项目满足软件需求说明书中的要求；
? 所有的测试用例都已成功执行验证；
? 系统测试中核心功能点覆盖率达到100%，基础功能点覆盖率达到90%；
? 所有发现的缺陷均记录在缺陷管理系统中；
? 各等级缺陷修复率均达到缺陷修复率标准。
7.3. 测试结论及评价标准
测试结论 评价标准
拒绝发布 遗留了A、B类缺陷
测试通过版本 不能遗留A、B类缺陷；
C类缺陷95%得到修复并且通过复测；
D、E类缺陷85%得到修复并且通过复测
质量优质版本 不能遗留A、B类缺陷；
C类缺陷97%得到修复并且通过复测；
D、E类缺陷90%得到修复并且通过复测
7.4. 输出
? 《阶段性测试报告》
? 《性能测试报告》
? 《测试总结报告》
? 《测试问题记录表》 - 其它约束
暂无
|