软件测试-软件BUG及其管理

姿态

　　

       一、BUG产生的原因：
　　1、在编码前就有错误：作为软件开发依据的需求，在开发初期提供的不够准确，不能满足用户的实际需求或对用户的需求理解有误等。
　　2、在编码过程中出现的错误：开发人员的逻辑错误或开发人员没有按照一定的规范；开发人员的配合不够严密，约定不够明确等。
　　3、测试过程中可能产生的错误：测试人员操作不规范；开发人员对测试中的BUG进行修改以后，可能会产生新的BUG。
　　二、BUG的级别分类
　　1、low低级别：使操作者不方便或遇到麻烦，标题或信息不明确。
　　2、Medium中等级别：影响系统的基本功能或简单功能，比如执行速度缓慢。
　　3、High高级别：严重影响系统要求或基本功能的实现，但存在合理的更正办法，比如信息修改失败或不正确。
　　4、Very High严重级别：严重影响系统要求或基本功能的实现，且没有合理的办法来更正，比如遥测、遥控失败。
　　5、Urgent致命级别：不能执行正常软件功能或重要功能，使软件无法正常运行下去，比如系统崩溃，死机。
　　三、BUG的错误分类（从技术上分）
　　1、软件需求错误：需求制定的不合理，需求不完全，需求分析的文档有误
　　2、功能和性能错误：遗漏或重复了功能，为用户提供的信息有错或信息不明确
　　3、软件结构错误：程序控制流或控制顺序有误，处理过程有误等
　　4、数据错误：数据存取或数据操作有误等。
　　5、软件实现和编码错误：编码错或者按键错，违背编码标准或者编码风格的问题
　　6、软件集成错误：内部接口和外部接口有误，软件各部分在时间配合，数据吞吐量等方面不协调。
　　7、软件系统结构错误：操作系统调用错或使用错，恢复错误，诊断错误等
　　8、测试定义与测试执行错误：往往被人们所忽视，比如测试方案设计和测试实施过程中的错误，测试文档的问题和测试用例的不充分。
　　注意：软件结构错误；数据错误；功能和性能错误最重要而且出现的频率也要多。
　　四、BUG的解决优先级：
　　1、立即解决：BUG必须立即被解决
　　2、正常：BUG按照BUG等级排队解决
　　3、一般：BUG在有条件的情况下解决
　　4、推迟修改：BUG在后续版本中被解决，提交此类BUG时需描述BUG被推迟的原因以及预期被解决的版本/时间。
　　五、国际当中关于BUG的描述：
　　向用户提交软件进行验收时，对于软件中存在的BUG数量有如下的规定：
　　（1）程序中不存在未改的A、B级BUG；C级BUG的数量每千行源代码（KLOC）中不超过一个；D、E级BUG的数量每千行源代码中不超过两个；对与随机出现的BUG数量也必须考虑。
　　（2）在交付给用户的文档资料中，允许存在的BUG数量按以下方法计算：
　　用程序的千行源代码数量除以25，所得数加上3即为文档中允许存在的最大BUG数量。
　　例如：如果程序的千行源代码（KLOC）的数量为1000，即该程序有1000 000行源程序，则与该程序相关的文字资料中允许的最大BUG数就是（1000/25+3=43）个。
　　六、BUG的管理与跟踪
　　1、BUG的属性定义（1）基本属性（2）扩展属性（BUG定位后确认）
　　2、BUG的跟踪
　　3、Gompertz分析方法
　　4、四象限分析方法
　　5、Rayleigh分析方法（Myers定律——开发过程中的缺陷与显示的缺陷发现率成正比）
　　6、根本原因分析法：可以借助工具：鱼骨图，柏拉图等。