测试规范

Posted 2021-02-08 bzdmz

1. 软件测试准入和准出标准

1.1测试准入标准
1.开发人员编码结束，并已完成单元测试
2.需求说明书规定的功能或开发人员提交的功能说明书的功能均已实现
3.提交测试范围内的各菜单项、按钮功能均已功能无异常，关联页面调用、跳转正常
4.系统或组件内基本流程可以正常流转
5.开发人员提交被测系统的最新版本，安装测试通过。
5.开发人员向测试部提交配置文件和程序包

1.2软件测试暂停、停止标准
1.被测系统在进行系统测试时，发现程序存在重大bug或bug过多时，测试无法正常进行，可以暂停测试返回开发。
2.被测项目需暂停以进行调整时，测试应随之暂停，并备份暂停点数据。
3.被测项目在其开发生命周期内出现重大估算、进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份暂停或终止点数据归档。
4.被测系统经过系统测试，达到系统测试准出标准，可以停止测试。
5.被测系统经过系统测试，并已产出系统测试总结报告，可以停止测试。

1.3软件测试恢复标准
1.重大bug被解决或程序通过重新修正；
2.软件项目被调整后重新启动，测试任务应随之启动；

 

1.4 测试准出标准

序号 准出标准 是 否 日期
1 被测项目满足软件需求说明书的要求？ xxxx年xx月xx日
2 所有的测试用例都已通过评审？
3 达到了测试计划中关于系统测试所规定的覆盖率的要求。（测试覆盖率达到100%）
4 所有的测试用例都已成功执行？
5 所有发现的缺陷都已成功记录在禅道缺陷管理系统中？
6 一二级错误修复率达到100%？
7 三四级错误修复率达到95%以上？

2. 缺陷描述以及缺陷等级划分
2.1 缺陷组织结构
一个完整的缺陷通常由下列几部分组成：
1. 缺陷的基本信息；
2. 测试的软件和硬件环境；
3. 测试的软件版本；
4. 缺陷的类型；
5. 缺陷的严重程度；
6. 缺陷的优先级别；
7. 重现缺陷的操作步骤；
8. 缺陷的实际结果描述；
9. 期望的正确结果描述；
10. 注释文字和截取的缺陷图像。

2.2缺陷内容约定
目前使用禅道管理缺陷，现主要对提交缺陷页面上的主题、描述、备注作统一约定。
2.2.1 主题
主题相当于缺陷的标题，应保持简短、准确，提供缺陷的本质信息，并且便于读者搜索查寻。良好的缺陷标题应该按照下列方式书写：
1) 尽量以简练的语言概括出缺陷所在的位置及产生什么样的现象（如：在某处出现什么问题）。
功能缺陷统一以：客户端名称+缺陷简述来描述，模块入口以“【】”符号标识；
2) 为了方便搜索和查询，请尽量使用关键字；
3) 为了便于他人理解，避免使用术语、俚语或过分具体过长的测试细节。

2.2.2 描述
在描述中应将缺陷产生的位置、操作、现象以简练的语言描述清楚，使程序员能准确地重现出缺陷，找出问题所在。
描述的格式约定如下：
1) 问题描述：位置/操作入口+重现操作步骤+实际输出结果；
2) 建议/注释（可选项）：
2.2.2.1问题描述
问题描述主要包括：缺陷产生的位置/操作入口、重现的操作步骤、实际输出结果，期望结果
位置/操作入口
采用“A模块/A1子模块/A11子页面……”主从关系的形式来描述缺陷所在的具体位置。如：若用例只能定位到A模块位置上，此时操作入口可以从“A1子模块/A11子页面……”定位。
重现的操作步骤
重现的操作步骤应包含如何使程序开发人员能够很容易的重现该缺陷的完整步骤。为了达到这个要求，重现步骤的信息必须是完整的、准确的、简明的、可重现的，将具体的操作过程简练、清晰地、一步一步地表述出，使程序员能准确地重现出缺陷。

 

实际输出结果
实际输出结果是执行重现步骤后软件的现象和产生的行为。实际结果的描述很像缺陷的标题，是标题信息的再次强调，根据出错的内容和格式，把能反应问题所在的核心内容列出，而不是简单的指出“不正确”或“不起作用”

2.2.2.2 建议/注释（可选项）
有时测试人员可能会有对此缺陷的一些个人建议，或者对此缺陷的一些业务上的分析信息给程序开发人员，在问题描述完后可补充建议信息。
2.2.2.3 总结
根据缺陷路径的深浅及缺陷的重复性，可以有三种形式来描述缺陷：
? 若重现缺陷的路径较简单，可直接使用问题描述（位置/操作入口+重现操作步骤+实际输出结果）组织缺陷描述；
? 若重现缺陷的路径较复杂，有先后关系、有前提条件等等，可使用分条目的形式（1、2、3……）来组织缺陷描述，每个条目点同样按照位置/照操作入口+重现操作步骤+实际输出结果来描述，根据具体情况而定。不一定要按编号来写，只要能描述清楚即可；
? 若缺陷出现重复情况，可汇总整理成一条提交给相应的开发人员。出现重复缺陷的情况可能有：①有几个模块同时调用同个类，类出现缺陷导致调用模块都出现缺陷，此时可统一整理成一条缺陷提交；②不同的模块中出现同样的问题（不是由于调用同个类而导致），将缺陷整理后分别分配给各自负责的开发人员。
另外，如果对测试软件的某个现象不确定是否是软件缺陷，可以通过电子邮件、QQ、口头交流方式与程序开发人员交流，确认是缺陷后再报告到禅道中。避免查询和统计结果的不准确性。
注意：尽量用最简洁的语言将缺陷描述清晰。

 

2.2.3 备注
备注作用有三个：
? 状态改变时说明其状态改变原因；
? 验证修改后缺陷的结果；
? 更详细的缺陷的注释信息。
测试人员备注信息包含：测试环境、测试要点、测试步骤、测试结果。
开发人员备注信息包含：修复结果，修复原因，建议等

2.3缺陷描述注意事项
自我检查内容
1. 明确缺陷报告的读者对象，知道读者最希望从缺陷描述中获取什么样的信息；
2. 缺陷报告包含完整、准确、必要的信息，书写清晰、完整的缺陷报告是保证缺陷正确处理的最佳手段；
3. 一个缺陷报告应尽量只包含一个缺陷；
4. 缺陷标题按照位置、产生的问题描述
5. 重现操作步骤清晰、步骤完整，程序员能准确定位
6. 实际输出结果（指实际展现出来的情况，不是实际数据）表述清楚，不引起歧义
7. 提交之前先搜索一下，是否已经提交过，避免重复
8. 人称口气、情绪化的语言不要出现，‘！’、‘？’不要出现在缺陷描述中，要客观的提意见，不要做评价。

注意表述
1. 在缺陷报告中不出现人称代词，可直接使用动词或必要时以用户代替；
2. 不出现情绪化的语言和强调符号，只要客观地反映出缺陷的现象和完整信息即可，不要对软件的质量优劣做任何主观性强烈的批评、嘲讽；
3. 避免含义模糊的词汇，而需要报告确定的缺陷结果；
4. 避免在缺陷描述中出现疑问的语气和问号，提交的缺陷应该是确定的；
5. 一个缺陷再引发另一个问题时，则另外提交一个缺陷，而不是将旧缺陷重打开。

 

2.4缺陷严重等级规范与说明
缺陷单的严重等级作为公司质量考核指标的系数，对于提交部门的考核结果影响较大。拟定缺陷等级约定，具体约定如下：

严重等级 说明
致命 说明：
（1）系统无法运行，崩溃或严重资源不足，应用模块无法启动或异常退出，主要功能模块无法使用。
比如：1.内存泄漏；2.系统容易崩溃；3.功能设计与需求严重不符；4.系统无法登陆；5.循坏报错，无法正常退出；6.打开APP闪退，无法进行下一步操作
严重 说明：
（1）核心模块的核心功能出错；如：不能进行收款，不能支付
（2）数据类错误：数据字段值保存错误、数据状态值保存错误；如：数据库填写时status应该填 ‘1’，却填写成‘0’
（3）开发能够经过简单自测发现的问题；如：选择2013年，查询出来的数据却是2014年的；
(4)导致数据无法流转，比如定时汇总任务出现问题，导致数据无法汇总
一般 说明：除非常严重、严重、建议外的缺陷
比如：1.界面出现错别字 2.内容被遮挡显示不全 等
建议 说明：
（1）界面美观度不够；（2）功能已满足，但易用性不好；