软件缺陷相关的标准-V1.0

目录
1前言 (2)
2文档范围 (2)
3文档对象 (2)
4.用例级别 (2)
5.BUG等级划分 (3)
6.BUG发生率 (4)
7.Bug修改优先级 (5)
8.BUG修改优先级与BUG严重性的分别 (7)
1前言
为了使技术平台开发的软件测试更加规范，STE组制定了一系列和缺陷相关的标准。

制定此标准的另一目的是便于平台和产品的相关人员对STE在平台中提出的软件缺陷的等级
和修改优先级达成共识。

2文档范围
描述了技术平台开发中和软件缺陷相关的内容。

内容包括：用例级别、Bug等级、Bug
发生率、Bug修改优先级。

3文档对象
技术开发全体软件成员及其他组的相关人员。

4.用例级别
用例级别表明该用例的重要程度。

用例的重要性并不对应用例可能造成的后果，而是对应用例的基本程度，一个可能导致死机的用例未必是高级别的，因为其触发条件可能相当生僻。

测试用例的级别分4级，如下表。

下面是用例级别的具体分类和内容：
Level 1-级别“1”：基本
该类用例涉及系统正常的基本功能。

该用例执行的失败会导致多处重要功能无法运行的。

如果不能访问每一个功能区域或执行其他测试用例依赖的基本操作，那么在执行这个优先的测试用例之前，试图做其他任何的测试都是没有意义的，因为他们大多数肯定要失败。

此级别用例用于版本提交时作为“版本冒烟测试通过准则”。

如存在不通过的项目时可考虑重新提交版本，例如“申请书不能添加成功”或者“WIFI不能连接”等。

1级用例的数量应受到控制。

Level 2-级别“2”：重要
该类测试用例涉及系统的重要功能。

主要包括一些功能交互相关、各种应用场景、使用频率较高的正常功能测试用例。

该类用例最常执行以保证功能是稳定的，目标的行为和能力可以正常的工作，和重要的错误和边界被测试的测试用例的集合。

该类测试用例在非回归的系统测试版本（即在新Feature和TPM版本计划中的正式版本）中基本上都需要进行验证，以保证系统所有的重要功能都能够正常实现。

在测试过程中可以根据版本当前的具体情况进行安排是否进行测试。

Level 3-级别“3”：详细。

该类测试用例仅影响某单项功能的某一细节方面。

例如某新业务的登记和使用正常，但和另一个新业务发生不应有的冲突。

有关性能、极限（大容量）、数据库中断等方面的测试可归入3级用例。

有关用户界面的基本规范等方面的测试可归入3级用例。

该类测试用例在非回归的系统测试版本（即在新Feature和TPM版本计划中的正式版本）中基本上都需要进行验证，以保证系统所有的重要功能都能够正常实现。

在测试过程中可以根据版本当前的具体情况进行安排是否进行测试。

Level 4-级别“4”：生僻。

这是通常最少被执行的测试用例。

但这并不意味着这些测试都不重要，只是说他们在项目的生命期间里不是常常被运行。

该类用例对应较生僻的预置条件和数据设置。

虽然某些测试用例发现过较严重的错误，但是那些用例的触发条件非常特殊，仍然应该被置入4级用例中。

有关用户界面的优化等方面的测试可归入4级用例。

5.BUG等级划分
Bug为什么需要分级？即为什么会有BUG严重性类别？
将一个Bug作等级分类，是对有关部门在协调方面的一个基本指标，是非常必要的，因为有了等级分类才能调整处理事务的排程。

测试人员、开发人员和项目经理需要知道缺陷发生时对交货期的影响；测试人员亦需要知道平台软件目前的品质状况。

按照CMM5中定义的规范，缺陷（Bug）等级一般分3-5个等级。

由于我司开发部的Bug 管理系统采用的是Imis系统，Imis系统的缺陷等级已分成3个等级，所以技术开发平台的缺陷等级也划分成3个等级。

如后续Imis系统需升级，强烈建议把BUG分成四个等级。

3个等级类别如下：
A类：致命（一级BUG）
通常表现为:主流程无法跑通，系统无法运行，崩溃或严重资源不足，应用模块无法启动或异常退出，主要功能模块无法使用,造成人身安全等。

比如：1.内存泄漏；2.系统容易崩溃；3.功能设计与需求严重不符；4.系统无法登陆；
5.循环报错，无法正常退出等6、软件存在人身安全隐患。

B类：严重（二级BUG）
通常表现为：影响系统功能或操作，主要功能存在严重缺陷，性能严重不达标，但不会影响到系统稳定性。

比如：1.次要功能未实现；2.功能存在报错（如：存在严重的数值计算错误）；3.大数据下容易无响应或者响应速度非常慢；4.功能实现了但是影响用户使用。

C类：一般（三级BUG）
通常表现为：功能实现不完善、性能有轻微缺陷、界面、易用性及建议性问题。

比如：1.边界条件下错误；2.容错性不好；3.数值轻微的计算错误等；4.大数据操作时，没有提供进度条等。

给客户和领导演示等过程中客户和领导重点指出的严重级别不是很高的BUG,建议STE 把此BUG的级别定义为非常高。

注意：对于结构及硬件问题，由于STE仅是进行辅助测试，碰到此类问题时，也要将问题提交到Imis上。

具体BUG等级由TPM转给结构及硬件部门相关人员确认。

6.BUG发生率
目前通用的对缺陷（BUG）发生率的划分主要有两种划分方法：一种是测试发生率：即按照特定步骤执行多次的BUG重现率；另外一种是用户使用发生率：即模拟用户在使用产品发生此问题的概率。

第一种方法计量精确简单，可操作性高。

第二种方法，则需要推断用户使用某一业务的频率，因此计量相对没有第一种精确，操作性高，但比较符合产品的实际使用情况。

由于我们负责测试技术平台开发的系统和应用，平台中的所有的软件模块都需详细测试。

因此STE测试的BUG发生率采用第一种方法——即测试发生率。

填写BUG时需要填写BUG测试发生率，原因是测试人员会依据测试发生率定义BUG修改优先级。

测试发生率为按照特定步骤执行多次的BUG重现率。

一般情况下每条测试用例的测试次数为5次，最多为10次。

测试发生率=BUG重现次数/按照特定步骤执行的总次数。

如果每条用例连续执行3次都出现BUG，则BUG发生率为100%。

如果连续测试5次，出现4次BUG，直接计算BUG发生率。

如果连续测试5次出现1-3次BUG，则再测试5次后计算BUG的发生率。

如果连续测试5次都没BUG产生，则表示这条测试用例测试通过。

BUG发生率划分如下：
由于终端软件（嵌入式平台的软件和Mobile_App的软件）的某些功能的特殊性，做专项测试和重现低概率的问题时除了提高测试用例的覆盖度，还需考虑用多个机台（如5-10台）测试。

对于稳定性测试、兼容性等专项测试的规格后续会输出。

7.Bug修改优先级
Bug的修改是需指定先后顺序。

由于Imis系统的BUG修改优先级已划分成3个等级，所以技术平台开发定义的BUG的修改优先级也分成3个等级。

这三个等级分别是H、M、L。

BUG修改优先级描述如下：
高（H）：Bug必须立即修复或在下个版本中修复（有些很难立即解决的BUG，则由TPM 确定此BUG的修改优先级）。

中（M）：Bug必须修复，不一定在下个版本修复，但是必须在某个特定的里程碑结束前修复。

低（L）：Bug在时间允许的情况下修改，不紧急。

有些BUG可以不解决。

BUG等级、BUG发生率和BUG修改优先级的对应关系如下表：
Vx阶段不同类型的软件版本的BUG修复要求如下：
Bug修改优先级顺序如下：
STE需对概率性A(M)、B（M）和C（M）问题做专项测试。

用探索式软件测试方法加大测试次数和机台数找出问题的重现步骤。

如果STE仍无法重现此问题，则需TPM组织SDE、RD、STE等相关人员和相关领导给出此类问题的解决方案。

建议方案为：先把BUG降一级，
然后在TPM的版本计划中STE验证此问题，如果仍无法重现此问题，且移交到产品后产品中也未发现此问题，则建议关闭此问题。

如果在测试过程中出现较严重的必现BUG，但是此BUG在普通条件下不会发生（即在很极端的条件下才能重现），且解决此BUG需花费大量的人力和时间。

则需TPM组织SDE、RD、STE等相关人员和相关领导给出此类问题的解决方案。

8.BUG修改优先级与BUG严重性的分别
从根本上，BUG修改优先级是从项目管理和时间管理的观点来定高低，而BUG严重性是从质量管理的观点来思考的。

处理问题的严重性，以质量作为出发点，应针对所产生的问题是否会对产品造成严重的缺憾来决定等级的；其决定权，通常掌握在测试人员手中。

处理问题的优先级，以整体项目的进度、质量、市场，以及需求所造成的影响作为出发点，决定应对的措施；其决定权，可以分散至负责对应项目的相关单位和人，而最终决定权通常掌握在项目经理手中。