1、软件质量保证和测试软件质量保证和测试 Bug管理姚砺内容nBug相关概念n判断Bug的规则nBug的生命周期n报告、跟踪、关闭BugnBug报告的内容nBug的统计什么是Bug?n功能没有实现或与规格说明不一致的问题是bug；n不能工作(死机、没反应)的部分是bug；n不兼容的部分是bug；n边界条件未做处理是bug；n界面、消息、提示、帮助不够准确是bug；n屏幕显示、打印结果不正确也是bug;n有时把尚未完成的工作也作为一个bug。什么是Bug?在IEEE 1983 of IEEE Standard 729中对软件缺陷下了一个标准的定义：（1）从产品内部看，软件缺陷是软件产品开发或维护过程
2、中所存在的错误、毛病等各种问题；（2）从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。Bug举例1文本文件保存错误：在WindowsXP桌面上新建一个文本文档，输入“联通”两个字，并保存退出。退出后再次打开这个文本文件时，刚才输入的内容变成了乱码。Bug举例2共享文件夹名超长时提示错误：Windows XP支持的最大共享文件夹名长度为80个英文字母或40个汉字，但设置共享文件夹名时可输入的范围是80个英文字符或80个汉字，如果共享文件夹名在4180个汉字之间，系统会提示“该共享名包含无效的字符”。其实真正的原因是共享文件夹名超长。Bug举例3替换字符串长度未作限定：Word2000中
3、，如果替换字符串长度过长，则会引起程序崩溃。软件问题报告（Bug报告）n软件问题（Bug）报告是软件测试过程中最重要的文档。它记录了Bug发生的环境，如各种资源的配置情况，Bug的再现步骤以及Bug性质的说明。n更重要的是它还记录着更重要的是它还记录着BugBug的处理过程和状态。的处理过程和状态。Bug的处理进程从一定角度反映了测试的进程和被测软件的质量状况以及改善过程。如果没有报告缺陷，后果？第第1 1份缺陷报告份缺陷报告判断Bug的规则n软件未达到产品规格说明书（需求）标明的功能。n软件出现了规格说明书指明不会出现的错误。n软件功能超出规格说明书指明的范围。n软件未达到规格说明书虽未指出
4、但应达到的目标（隐含需求）。n软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。n需要注意的是，测试人员报告Bug时，应当保证Bug是可以重现的。对于有时不可重现的Bug，应当反复测试，直到最终确定Bug的发生场景为止。报告Bug的基本原则n尽快报告Bugn修改成本小、修改风险小n避免报告同类缺陷n有效描述Bugn简单、明确、具体n每个缺陷一份报告n简化和优化操作步骤n保证重现缺陷n缺陷描述客观公正，不带评价和感情色彩n保证每个缺陷被报告和处理有效描述Bugn单一准确单一准确，每个报告只针对一个软件缺陷n可以再现可以再现，不要忽视或省略任何一项操作步骤，特别是关键性的操
5、作一定要描述清楚，确保开发人员按照所描述的步骤可以再现缺陷n完整统一完整统一，提供完整的软件缺陷描述信息n短小简练短小简练，如使用业务关键词n特定条件，特定条件，必须注明缺陷发生的特定条件n不做评价，不做评价，客观描述一个简单的缺陷报告缺陷报告的描述n缺陷的严重性和优先级n缺陷的类型和来源n缺陷附件n完整的缺陷信息列表缺陷的严重性和优先级n严重性严重性：缺陷对软件产品使用的影响程度n优先级优先级：缺陷必须被修复的紧急程度n缺陷越严重，越要优先得到修正，缺陷严重等级和缺陷优先级相关性很强 n 也有例外，如有些缺陷比较严重，但由于技术的限制或第3方产品的限制，暂时没法修正，其优先级就会低 缺陷的类
6、型和来源n缺陷类型可以分为业务逻辑、数据处理、接口、UI、性能、安全性、兼容性、配置、文档等n缺陷来源，如需求说明书、设计规格说明书、代码、用户手册等n缺陷关联的模块名，缺陷来自于产品的特定模块的名称n缺陷发生的阶段，例如需求、系统架构设计、详细设计、编码等缺陷附件n一张图片可能胜过千言万语 nLog filen工具捕捉的其它数据文件等完整的缺陷信息列表nIDn标题n前提n环境n操作步骤n期望结果n实际结果n频率v严重程度严重程度v优先级优先级v类型类型v缺陷提交人缺陷提交人v缺陷指定解缺陷指定解决人决人v来源来源v产生原因产生原因v构建包跟踪构建包跟踪v版本跟踪版本跟踪v提交时间提交时间v修
7、正时间修正时间v验证时间验证时间v所属项目所属项目/模块模块v产品信息产品信息v状态状态编写Bug摘要nBug的摘要是要用一句话的形式简明扼要地将Bug描述出来，要清晰指出Bug所在部位以及其错误类型，不能太笼统。n如“页面对非法输入有问题”可以修改为“流量信息查询页面对于非法输入没有进行校验”。有效描述Bug操作步骤：1.使用MappingBuilder对URL为“jdbc:mysql:/10.0.0.12/test”的数据库进行映射，虚拟数据库名称设置为“VMysql”。2.进入DataView主页面，在DAS List中点击“VMysql”右侧的“高级查询”链接。3.在高级查询页面底端的
8、输入框中，输入SQL语句“select*from empinfo”，点击查询按钮。4.在得到的查询结果页面中，点击“下一页”链接。5.翻页到下一页后，没有出现“保存当前页面的查询结果”链接，无法保存当前页面结果。有效的缺陷描述所带来的益处n容易再现所报告的问题容易再现所报告的问题，加快缺陷的修正加快缺陷的修正n提高工作效率提高工作效率n提高测试人员的信任度提高测试人员的信任度，有利于开发团队和测试团队之间的的沟通和合作n客观、准确的产品质量评估客观、准确的产品质量评估n预防缺陷预防缺陷分离和再现缺陷的技巧n记下每一个操作步骤和中间结果n逐步尝试并缩小侦察范围n查找时间依赖问题n查找资源依赖问题
9、n考虑软件和硬件配置不同的可能软件缺陷的处理和跟踪n软件缺陷生命周期软件缺陷生命周期n缺陷的跟踪处理缺陷的跟踪处理n缺陷状态报告缺陷状态报告发现发现 打开打开 修复修复 关闭关闭 缺陷状态软件缺陷生命周期 发现软件缺陷 软件缺陷移交到项目管理员 测试员找到并登记软件缺陷 软件缺陷被移交到程序员 程序员认为软件缺陷微不足道 软件缺陷移交到测试员 项目管理员认为软件缺陷不重要 测试员不同意，找出 通用失败案例 软件缺陷移交到项目管理员 软件缺陷移交到测试员 软件缺陷移交到程序员 测试员确认 软件缺陷得以修复 程序员修复软件缺陷 测试员关闭软件缺陷 项目管理员现在同意 软件缺陷需要修复 打开 打开
10、以不修复 形式解决 打开 打开 以修复 形式解决 关闭 复杂的软件缺陷生命周期缺陷的跟踪处理n密切跟踪缺陷状态的变化，及时处理缺陷，使项目按预定的计划进行 n动态报表，及时更新数据n自动邮件机制 缺陷分析缺陷分析n作用调整测试进度和项目进度调整测试策略和项目资源分配测试人员与开发人员考核n精心设计n谨慎使用度量软件质量、评估测试过程的效率、预期发布时间数据最能反映真实情况数据也最能制造假象缺陷分析缺陷分析n关注对象正在测试的软件哪个模块的问题最多？测试人员中谁报告的软件缺陷最多？测试人员中谁报告的软件缺陷准确率最高？各类缺陷所占的数量百分比分别是多少？开发人员能及时修正软件缺陷吗？开发人员一次
11、正确修正缺陷的百分比是多少？有多少重复报告的缺陷？正在开发的软件能否在计划的时间内正常发布？缺陷分析工具缺陷分析工具n实时趋势分析实时趋势分析n累积趋势分析累积趋势分析n缺陷分布分析缺陷分布分析实时趋势分析n实时数据，由每日或每周发生的数据构成的时间序列 n对随时间变化的趋势进行分析累积趋势分析n累积数据是将前面产生的数据不断累加起来所构成的时间序列 n累积曲线趋势特征更明显 借助趋势分析发现问题http:/ n产品的质量是否达到预定的标准 n缺陷修正的速度是否滞后n测试人员 验证缺陷是否及时n缺陷遗漏程度n回归缺陷数量n流程实例缺陷分布分析n缺陷分布分析，主要借助于圆饼图、直方图等工具进行分
12、析 n包括功能模块、来源分布、不同类型、开发团队等各种分布表 5-2 一个项目的缺陷分布情况 发 现 阶 段 缺陷造成阶段 需求 总体 设计 详细 设计 编码 单元 测试 集成 测试 系统 测试 验收 测试 试运行产品 发布 产品 缺陷总量 需求 0 8 4 1 0 0 5 6 2 1 27 总体设计 0 9 3 0 1 3 1 2 1 20 详细设计 0 15 3 4 0 0 1 8 31 编码 0 62 16 6 2 3 20 109 总计 0 8 13 19 65 21 14 9 8 30 187 直方图圆饼图综合n缺陷分析通常用以下三类形式的度量提供缺陷评测：缺陷发现率缺陷潜伏期缺陷密
13、度缺陷分析缺陷分析n缺陷发现率 缺陷发现率是将发现的缺陷数量作为时间的函数来评测，即创建缺陷趋势图，如下图所示。n缺陷潜伏期 测试有效性的另外一个有用的度量是缺陷潜伏期，通常也称为阶段潜伏期。缺陷潜伏期是一种特殊类型的缺陷分布度量。在实际测试工作中，发现缺陷的时间越晚，这个缺陷所带来的损害就越大，修复这个缺陷所耗费的成本就越多。表5-1显示了一个项目的缺陷潜伏期的度量。表 5-1 一个项目的缺陷潜伏期的度量 发 现 阶 段 缺陷造成阶段 需求 总体 设计 详细 设计 编码 单元 测试 集成 测试 系统 测试 验收 测试 试运行 产品 发布 产品 需求 0 1 2 3 4 5 6 7 8 9 总
14、体设计 0 1 2 3 4 5 6 7 8 详细设计 0 1 2 3 4 5 6 7 编码 0 1 2 3 4 5 6 总计 n 表5-2显示了一个项目的缺陷分布情况（按缺陷造成阶段和缺陷发现阶段）。表 5-2 一个项目的缺陷分布情况 发 现 阶 段 缺陷造成阶段 需求 总体 设计 详细 设计 编码 单元 测试 集成 测试 系统 测试 验收 测试 试运行产品 发布 产品 缺陷总量 需求 0 8 4 1 0 0 5 6 2 1 27 总体设计 0 9 3 0 1 3 1 2 1 20 详细设计 0 15 3 4 0 0 1 8 31 编码 0 62 16 6 2 3 20 109 总计 0 8
15、13 19 65 21 14 9 8 30 187 n缺陷密度 缺陷密度是一种以平均值估算法来计算出软件缺陷分布的密度值。程序代码通常是以千行为单位的，软件缺陷密度是用下面公式计算的：代码行或功能点的数量软件缺陷数量软件缺陷密度 n下图显示了一个项目的各个模块中每千行代码的缺陷密度。n 但是，在实际评测中，缺陷密度这种度量方法是极不完善的，度量本身是不充分的。这里边存在的主要问题是：所有的缺陷并不都是均等构造的。各个软件缺陷的恶劣程度，及其对产品和用户的影响的严重程度，以及修复缺陷的重要程度有很大差别，有必要对缺陷进行“分级、加权”处理，给出软件缺陷在各严重性级别或优先级上的分布作为补充度量，
16、这样将使这种评测更加充分，更有实际应用价值。n 因为在测试工作中，大多数的缺陷都记录了它的严重程度的等级和优先级，所以这个问题通常都能够很好解决。例如，下图所示的缺陷分布图表示软件缺陷在各优先级上所应体现的分布方式。各优先级上软件缺陷分布图各优先级上软件缺陷分布图 报告和管理缺陷报告和管理缺陷n缺陷报告管理系统（缺陷跟踪系统）过程强制权限控制质量记录文档管理信息共享度量和统计n不仅可以统一数据格式、完成数据校验，而且确保每一个缺陷不会被忽视，使开发人员的注意力保持在那些必须尽快修复的高优先级的缺陷上。n可以随时建立符合各种需求的查询条件，而且有利于建立各种动态的数据报表，用于项目状态报告和缺陷数据统计分析。n可以随时得到最新的缺陷状态，大家获得一致又准确的信息，掌握相同的实际情况，消除沟通上的障碍。n可以将缺陷和测试用例、需求等关联起来，可以完成更深度的分析，有利于产品的质量改进等。开源缺陷跟踪系统nMantis，http:/ nJIRA：http:/ nIBM ClearQuest：http:/ TrackRecord：http:/ nHP TestDirector：http:/ Pro：http:/ nDevTrack： Segue SilkCentral Issue Manager等。
