缺陷管理的分级（二）

引言

当时间敌人不断冲锋时，我们是无序的去抵抗，还是坐等被收割。

基于需求的测试，当需求不明确时，我们该如何做。

当人手不足，缺陷量无法达到要求时

请不停的变更流程吧。

如何理解缺陷的级别

回述下第一章的内容，缺陷的级别分为：缺陷级别和处理优先级别。

缺陷的级别时为了处理优先级别而定的。

2.1不同阶段的版本

下图表主要讲的是大方向的问题：

项目的阶段性	缺陷生产量	缺陷权级	里程碑
Alpha	缺陷高产		可能存在1-2个
Beta	缺陷高产	提权	可能存在2-3个
Debug	缺陷中产	提权	可能存在1个
Release	控制缺陷	降权	可能存在1个
goldRelease	处理剩余缺陷

最后项的里程碑：打包版本、测试自定义、雷区、博物馆(里程碑是什么意思？)

里程碑：代表不同阶段的版本。大的里程碑，demo阶段，正式研发，a测试阶段，b测试阶段。小的包含小版本的分支，通常有重要调整和变革时称为里程碑。在里程碑阶段需要对delete的部分做记录。（后续说明）

其中打包版本是必然存在的，一般按月或者按项目的完成度来划分。

雷区的定义：难以重现或者存在缺陷修复的反复性

博物馆：暂时无法处理或者不计算缺陷统计的

在不同的版本缺陷的处理方式都不一样。

Alpha阶段：缺陷高产（会存在测试自定义和雷区的版本）

Alpha阶段会比较关注当前版本新推出的内容产生的缺陷。

Beta阶段：缺陷高产（会存在雷区，会存在自定义版本）

Beta阶段会比较关注整体已经开发结束版本所产生的缺陷。尽量用条件路径的方式避免缺陷的漏测和遗忘。

Debug版本：缺陷中产（会存在博物馆和雷区）

Debug阶段和Beta阶段类似，将慢慢提升缺陷的产出，研发组修复缺陷力度获得对应的提升。将对一些bug进行提权的操作。

Release版本：控制缺陷为主（不应该存在雷区，会存在自定义版本）↑

Release版本，排除开发新功能，缺陷将控制在一个小范围内。合理情况下集中在指定的模块中。而我们需要记录这些模块。将对一些bug进行提权的操作。

Gold Release版本：处理缺陷和优化为主（存在雷区和少量的自定义版本）↓

GoldRelease版本，用心好好维护吧，不要出纰漏了。将对一些bug进行降权的操作。

2.2该记录哪些

缺陷管理中，除了记录主要以上的Bug外，我们还需要记录哪些？

◇常规做法：

※记录B类及B类以上的缺陷为主要问题。

※记录C类和D类的缺陷为次要问题。

※当bug数量达到一个数量级别时，我们可以停止测试。

※A类获得4分，B类获得3分，C,D2类获得2分。

由于C类和D类比较容易混淆，在项目的开发阶段，所以获得分均等。权限对于优先处理的在《xxxx-基于缺陷管理分级（一）》中讲到。相反CD级别在goldRelease版本中相对重要。这个是为什么？

根据不同的阶段，部分的bug可能会提权。

这个是一个值得思考的问题，除了里程碑时一些特殊的bug外，是不是所有重要的bug都要记录呢？

2.3避免“漏测”

各种Bug提交到缺陷的管理软件中，缺陷的管理者及跟踪者可以根据整个团队的bug寻找方向获得一次数据挖掘的追踪。集合一个产品经理的技能，这个也是唯一可以超越上下文驱动测试的办法。

分为二个维度的去探究缺陷管理：

一个项目有众多的功能点，功能点按单纯性划分，分为独立功能点和存在交集的功能点。

2.3.1单纯性划分：

单纯性的技术，用于游戏产业的业务员尚早，需要环境配置的一些支持，不过你也可以理解成非单纯性，即复杂性。标题依然用单纯性划分：

“功能点复杂性”，在缺陷表中统计为A：（这里的A和缺陷等级A有什么关联？）

用上下文驱动的方式根据变量和业务的复杂性进行划分的梳理。

F1 = 单纯级别最高的，较单一的功能。

F2 = 有一定复杂性和量的功能。

F3 = 较复杂的功能。

所以管理者也需要比较理解游戏的功能。

然后根据功能点的复杂性来评估“当前缺陷类型”是否达到覆盖较高。

通过下面的统计方式可以很好的看明白，测试方向的遗漏。

按功能点来统计，在缺陷表中统计为B：

接下来简称独立功能点为当单方面的用户静止行为时不产生其他数据关联的：

独立功能点：系统设置等

存在交集的功能点：

邮件=>好友=>平台=>系统装备=>人物属性攻城=>对应角色数据等

统计项目缺陷类型，在缺陷表中统计为C：

根据项目的类型不一样，统计的缺陷类型也会有差别。

最常见的是比如任务的权重还是战斗的权重，需要去仔细思考的。

2.3.2假设项目A的“当前缺陷类型”分为：（这部分类型最好能把每个类型的解释写详细点，我实在是不知道怎么区分，只有少部分能区分）

最好是使用缩写，因为用了，程序也可能有误会。另外注意缩写时的重复和易读性。例如数据表和数据读取（dbf,dbi/o）这样区分较好，尽量小写。

比重划分最高一般是功能逻辑

ˇ功能逻辑ß非功能外观的，需要加深走查的

ˇUi：Ui层级,Ui显示ß功能外观和界面部分，可以只写UI往大的划分。

ˇ数据表 <-策划用，常见为填表错误或者是数据表显示（后续章节有范例）

ˇ差值 <-数字上除法和公式所导致的，对应策划和程序

ˇ客户端资源<-资源工具排除出来的大小写问题，平常之一模型的关系解压失败

ˇ性能 <-内存泄露和lag机

ˇ客户端崩溃<-flashdebug版本的客户端抛错，unity的客户端崩溃等

ˇ服务端<-因为某些行为导致服务端问题

ˇ数据读取 ß数据存储，或者创建帐号失败，读取表错误，属于典型的程序问题，和数据库操作相关的（后续章节有范例）

ˇ数据表<-属于重复的

ˇ客户端刷新<-例如钢魂房间号销毁的问题和指定行为有关系，和程序及制定规则的人相关联（后续章节有范例）

.......

划分不宜过细，统计为目的。ß统计大的，主要是把控测试的重心

2.3.3如何去划分

基本上以字面的意思都可以了解，不用花什么笔墨去描述这段。

那么讲点对系统的一些特殊分类吧。

逻辑特殊性：

例如这条缺陷F2_Z-战斗：使用“快速战斗”结束该场战斗，聊天框上没有获得刚才战斗所获得战功和物品。

这个就不属于客户端，属于服务端。可以确定是服务端没有通知客户端。深究下去的话，就需要检查背包。

例如这条缺陷F1_Z-战斗：战斗中，玩家武将的名字显示不全。

这个就不属于功能逻辑或者文本显示的错误，文本显示的错误属于语言包类型的，这个就属于UI显示，或者直接划分到UI。

再次强调请遵守一个原则：尽量划分清晰的“当前缺陷类型”