2软件缺陷

null第2讲 软件缺陷*/52第2讲 软件缺陷软件缺陷的概念*/52软件缺陷的概念什么是缺陷 缺陷既指程序中存在的错误，例如语法错误、拼写错误或者是一个不正确的程序语句 缺陷也指可能出现在设计中，甚至在需求、规格说明或其他的文档中的种种错误软件缺陷的概念（续）*/52软件缺陷的概念（续）软件缺陷（Defect或Bug）是软件开发过程中的"副产品“ 缺陷会导致软件产品在某种程度上不能满足用户的需要 软件缺陷是对软件产品预期属性的偏离现象。包括 检测 工程第三方检测合同工程防雷检测合同植筋拉拔检测方案传感器技术课后答案检测机构通用要求培训 缺陷和残留缺陷 检测缺陷是指软件在进入用户使用之前被检测出的缺陷 残留缺陷是指软件发布后存在的缺陷，包括在用户安装前未被检测出的缺陷以及检测出但未被修复的缺陷 用户使用软件时，因残留缺陷引起的软件失效症状称软件故障null*/52缺陷带来的系统风险列举*/52缺陷带来的系统风险列举如果某部分产生了错误会导致的结果？ 未被验证的数据交换如果被接受 如果文件的完整性被破坏 系统是否能被安全恢复（完全恢复成备份时的状态） 是否能暂停系统的运行 进行维护工作时，系统性能是否会下降到不能接受的水平 系统的安全性是否有保证 系统的操作流程是否符合用户的组织策略和长远规划 系统是否可靠，稳定 系统是否易于使用 系统是否便于维护 是否易于与其它系统相连软件缺陷产生的原因*/52软件缺陷产生的原因导致软件产生缺陷的九类原因 需求的不完善定义 客户——开发者通信失败 对软件需求的故意偏离 逻辑设计错误 编码错误 不符合文档编制与编码规定 测试过程不足 规程错误 文档编制错误判断软件缺陷的规则*/52判断软件缺陷的规则软件未达到产品规格说明书（需求）标明的功能 软件出现了规格说明书指明不会出现的错误 软件功能超出规格说明书指明的范围 软件未达到规格说明书虽未指出但应达到的目标（隐含需求） 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好 需要注意的是，测试人员报告Bug时，应当保证Bug是可以重现的 对于有时不可重现的Bug，应当反复测试，直到最终确定Bug的发生场景为止很难找出缺陷的原因*/52很难找出缺陷的原因看不到，看到但是抓不到 典型的缺陷类型 需求解释有错误 用户定义错了需求 需求 记录 混凝土 养护记录下载土方回填监理旁站记录免费下载集备记录下载集备记录下载集备记录下载 错误 设计说明有误 编码说明有误 程序代码有误 数据输入有误 测试错误 问题修改不正确 正确的结果是由于其它的缺陷产生的软件缺陷跟踪管理*/52软件缺陷跟踪管理缺陷跟踪管理是测试工作的一个重要部分 测试的目的是为了尽早发现软件系统中的缺陷 对缺陷进行跟踪管理，确保每个被发现的缺陷都能够及时得到处理是测试工作的一项重要内容软件缺陷跟踪管理（续）*/52软件缺陷跟踪管理（续）缺陷跟踪管理的目标 缺陷能够引起软件运行时产生的一种不希望或不可接受的外部行为结果，软件测试过程简单说就是围绕缺陷进行的，对缺陷的跟踪管理一般而言需要达到以下的目标： 确保每个被发现的缺陷都能够被解决 收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段 收集缺陷数据并进行数据 分析 定性数据统计分析pdf销售业绩分析模板建筑结构震害分析销售进度分析表京东商城竞争战略分析 ，作为组织的过程财富 在一个运行良好的组织中，缺陷数据的收集和分析是很重要的，从缺陷数据中可以得到很多与软件质量相关的数据软件缺陷跟踪管理（续）*/52软件缺陷跟踪管理（续）缺陷管理的基本流程 对缺陷进行管理需要: 对缺陷进行描述 对缺陷进行分类 通过对缺陷进行分类，可以迅速找出哪一类缺陷的问题最大 然后集中精力预防和排除这一类缺陷 而这正是缺陷管理的关键，一旦这几类缺陷得到控制，再进一步找到新的容易引起问题的几类缺陷上缺陷的描述*/52缺陷的描述可追踪信息——缺陷ID(唯一的缺陷ID，可以根据该ID追踪缺陷) 缺陷基本信息 缺陷标题—描述缺陷的标题 缺陷的严重程度—描述缺陷的严重程度，一般分为“致命”、“严重”、“一般”、“建议”四种 缺陷的紧急程度—描述缺陷的紧急程度，从1－4，1是优先级最高的等级，4是优先级最低的等级 缺陷提交人—缺陷提交人的名字（邮件地址） 缺陷提交时间—缺陷提交的时间 缺陷所属项目/模块—缺陷所属的项目和模块，最好能较精确的定位至模块缺陷的描述（续）*/52缺陷的描述（续）缺陷基本信息（续） 缺陷指定解决人—缺陷指定的解决人，在缺陷“提交”状态为空，在缺陷“分发”状态下由项目经理指定相关开发人员修改 缺陷指定解决时间—项目经理指定的开发人员修改此缺陷的deadline 缺陷处理人—最终处理缺陷的处理人 缺陷处理结果描述—对处理结果的描述，如果对代码进行了修改，要求在此处体现出修改 缺陷处理时间—缺陷处理的时间 缺陷验证人—对被处理缺陷验证的验证人 缺陷验证结果描述—对验证结果的描述（通过、不通过） 缺陷验证时间—对缺陷验证的时间缺陷的描述（续）*/52缺陷的描述（续）缺陷的详细描述——对缺陷的详细描述 对缺陷描述的详细程度直接影响开发人员对缺陷的修改，描述应该尽可能详细 测试环境说明——对测试环境的描述 必要的附件——对于某些文字很难表达清楚的缺陷,使用图片等附件是必要的 从统计的角度出发，还可以添加上“缺陷引入阶段”、“缺陷修正工作量”等项目缺陷的分类*/52缺陷的分类软件缺陷分类 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 (用于同行评审和软件测试) 缺陷属性 属性名称描述 缺陷标识—标记某个缺陷的一组符号。每个缺陷必须有一个唯一的标识 缺陷类型—根据缺陷的自然属性划分的缺陷种类 缺陷严重程度—因缺陷引起的故障对软件产品的影响程度 缺陷优先级—缺陷必须被修复的紧急程度 缺陷状态—缺陷通过一个跟踪修复过程的进展情况 缺陷起源—缺陷引起的故障或事件第一次被检测到的阶段 缺陷来源—引起缺陷的起因 缺陷根源—发生错误的根本因素缺陷的分类（续）*/52缺陷的分类（续）缺陷类型——缺陷类型编号与描述 10 F-Function 影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构 并且设计文档需要正式的变更。如逻辑， 指针，循环，递归，功能等缺陷 20 A-Assignment 需要修改少量代码，如初始化或控制块。如声明、重复命名，范围、限定等缺陷 30 I-Interface 与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷 40 C-Checking 提示的错误信息，不适当的数据验证等缺陷缺陷的分类（续）*/52缺陷的分类（续）50 B-Build/package/merge 因配置库、变更管理或版本控制引起的错误 60 D-Documentation 影响发布和维护，包括注释 70 G-Algorithm 算法错误 80 U-User Interface 人机交互特性：屏幕格式， 确认用户输入，功能有效性，页面排版等方面的缺陷 90 P-Performance 不满足系统可测量的属性值，如：执行时间、事务处理速率等 100 N-Norms 不符合各种标准的要求，如编码标准、设计符号等缺陷的分类（续）*/52缺陷的分类（续）缺陷严重程度 软件测试错误的严重程度 1 Critical 不能执行正常工作功能或重要功能。或者危及人身安全 2 Major 严重地影响系统要求或基本功能的实现，且没有办法更正 3 Minor 严重地影响系统要求或基本功能的实现，但存在合理的更正办法 4 Cosmetic 使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能 5 Other 其它错误 同行评审错误的严重程度 Major 主要的，较大的缺陷 Minor 次要的，小的缺陷缺陷的分类（续）*/52缺陷的分类（续）缺陷优先级 Resolve Immediately 缺陷必须被立即解决 Normal Queue 缺陷需要正常排队等待修复或列入软件发布清单 Not Urgent 缺陷可以在方便时被纠正缺陷的分类（续）*/52缺陷的分类（续）缺陷状态 Submitted 已提交的缺陷 Open 确认“提交的缺陷”，等待处理 Rejected 拒绝“提交的缺陷”，不需要修复或不是缺陷 Resolved 缺陷被修复 Closed 确认被修复的缺陷，将其关闭缺陷的分类（续）*/52缺陷的分类（续）缺陷起源 Requirement 在需求阶段发现的缺陷 Architecture 在构架阶段发现的缺陷 Design 在设计阶段发现的缺陷 Code 在编码阶段发现的缺陷 Test 在测试阶段发现的缺陷缺陷的分类（续）*/52缺陷的分类（续）缺陷来源 Requirement 由于需求的问题引起的缺陷 Architecture 由于构架的问题引起的缺陷 Design 由于设计的问题引起的缺陷 Code 由于编码的问题引起的缺陷 Test 由于测试的问题引起的缺陷 Integration 由于集成的问题引起的缺陷缺陷的分类（续）*/52缺陷的分类（续）缺陷根源 目标—错误的范围，误解了目标，超越能力的目标等 过程，工具和方法—无效的需求收集过程，过时的风险管理过程，不适用的 项目管理 工程项目管理制度介绍工程项目管理课程设计政府投资项目管理意见建设工程项目管理合同工程项目管理培训总结 方法，没有估算规程，无效的变更控制过程等 人—项目团队职责交叉，缺乏培训。没有经验的项目团队，缺乏士气和动机不纯等 缺乏组织和通讯—缺乏用户参与,职责不明确,管理失败等 其它: 硬件如：处理器缺陷导致算术精度丢失，内存溢出等 软件如：OS错误导致无法释放资源，工具软件错误，编译器错误等 环境如：组织机构调整，预算改变，罢工，噪音，中断，工作环境缺陷的分类（续）*/52缺陷的分类（续）缺陷分类适用范围缺陷管理流程*/52缺陷管理流程了解缺陷 必须首先收集缺陷数据，然后才能了解这些缺陷，并且找出如何预防它们，同时也能领会到如何更好地发现，修复甚至预防仍在引入的缺陷 可以按照以下步骤收集关于缺陷的数据 为测试和同行评审中发现的每一个缺陷做一个记录 对每个缺陷要记录足够详细的信息,以便以后能更好地了解这个缺陷 分析这些数据以找出哪些缺陷类型引起大部分的问题 设计出发现和修复这些缺陷的方法（缺陷排除）缺陷管理流程（续）*/52缺陷管理流程（续）缺陷的一般管理流程*/52缺陷的一般管理流程缺陷管理流程中的各种角色*/52缺陷管理流程中的各种角色测试人员 进行测试的人员，缺陷的发现者 项目经理 对整个项目负责，对产品质量负责的人员 开发人员 执行开发任务的人员，完成实际的设计和编码工作 评审委员会 对缺陷进行最终确认，在项目成员对缺陷达不成一致意见时，行使仲裁权力缺陷所处的状态*/52缺陷所处的状态初始化： 缺陷的初始状态 待分配： 缺陷等待分配给相关开发人员处理 待修正： 缺陷等待开发人员修正 待验证： 开发人员已完成修正，等待测试人员验证 待评审： 开发人员拒绝修改缺陷，需要评审委员会评审 关闭： 缺陷已被处理完成软件缺陷流程管理的要点*/52软件缺陷流程管理的要点为了保证错误的正确性，需要: 有丰富测试经验的测试人员验证和确认发现的错误是否是真正的错误 测试步骤是否准确、简洁、可以重复 软件错误的确认并不总是轻而易举的事情 由于对软件设计具体要求的不了解，对测试报告的个别软件错误，可能无法确认是否属于真正的软件错误，本地化服务商需要与软件供应商交流并确认软件缺陷流程管理的要点（续）*/52软件缺陷流程管理的要点（续）每次对错误的处理都要保留处理信息 包括处理者姓名，时间，处理方法，处理步骤，错误状态，处理注释等 对错误的拒绝不能由程序员单方面决定，应该由项目经理，测试经理和设计经理共同决定 对错误延期处理不能由本地户服务商决定，应该由软件供应商决定 错误修复后必须由报告错误的测试人员验证后，确认已经修复，才能关闭错误缺陷数据统计*/52缺陷数据统计缺陷数据统计是缺陷跟踪管理的目标之一 一般而言，生成的缺陷数据统计图表包括缺陷趋势图、缺陷分布图、缺陷及时处理情况统计表等 按照缺陷严重程度及工作类型分布可以统计整个项目生命周期中所有同行评审的缺陷分布，也可以统计某一阶段所有同行评审的缺陷分布null*/52缺陷数据统计（续）*/52缺陷数据统计（续）按照缺陷类型分布 按照缺陷类型统计分布图，可是某一次评审的缺陷统计，也可以是某一类型工件评审的缺陷统计，可以是某一阶段所有同行评审的缺陷统计，也可以是整个项目周期内所有同行评审的缺陷统计 建议以某一类型工件和某一阶段来进行统计分布null*/52缺陷率分析*/52缺陷率分析多个项目的缺陷率缺陷趋势图null*/52缺陷跟踪系统*/52缺陷跟踪系统特别适用于大型软件测试项目集中管理测试缺陷的要求 这些测试项目一般测试周期长，测试范围广，存在较多软件缺陷 便于添加、修改、排序、查找、存储和跟踪软件测试错误 对于大型软件的测试，报告的错误可能成百上千个 便于跟踪和监控错误的处理过程和方法 方便地检查处理方法是否正确 确定处理者的姓名和处理时间，作为工作质量的统计和考核的参考 便于集中管理，提高效率 软件开发商、服务商和软件供应商共享同一个错误跟踪系统数据库，各自负责处理己方需要处理的软件错误 对于需要对方提供更多信息的错误，可以通过改变错误的当前信息（状态、处理者、处理建议等），使对方尽快处理 安全性高，通过权限设置，不同权限的用户能执行不同的操作，保证只有适当的人员才能执行正确的处理 保证处理顺序的正确性，根据当前错误状态，决定当前错误处理方法 便于项目结束后的存档软件缺陷报告*/52软件缺陷报告软件问题或缺陷报告是软件测试过程中最重要的文档 它记录了缺陷发生的环境，如各种资源的配置情况，缺陷的再现步骤以及缺陷性质的说明 更重要的是它还记录着缺陷的处理过程和状态 缺陷的处理进程从一定角度反映了测试的进程和被测软件的质量状况以及改善过程软件缺陷报告（续）*/52软件缺陷报告（续）在软件测试过程中，每发现一个软件错误都要记录该错误的特征和复现步骤等信息 以便分析、处理和管理测试发现的软件错误 通常要采用软件缺陷数据库 将每一个发现的错误输入到软件缺陷数据库中 软件缺陷数据库的每一条记录称为一个软件缺陷报告 准确、完整、简洁、一致的缺陷报告是体现软件开发、测试与管理的专业性、高质量的主要评价指标 每个软件问题报告只书写一个缺陷或错误 这样可以每次只处理一个确定的错误，定位明确，提高效率，也便于修复错误后方便的进行验证软件缺陷报告（续）*/52软件缺陷报告（续）报告缺陷的基本原则 尽快报告缺陷; 有效描述缺陷; 缺陷的生命周期 缺陷从开始提出到最后解决,并通过复查的过程 在这个过程中缺陷报告的状态不断发生着变化，记录着缺陷的处理进程软件缺陷报告（续）*/52软件缺陷报告（续）缺陷报告的读者对象 直接读者是软件开发人员和质量管理人员，来自市场和技术支持等部门的人也可能需要查看缺陷情况 读者最希望获得的信息包括： 易于搜索软件缺陷报告中的缺陷 报告的软件缺陷进行了必要的隔离，报告的缺陷信息更具体、准确 软件开发人员希望获得缺陷的本质特征和复现步骤 市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度软件缺陷报告（续）*/52软件缺陷报告（续）有效描述缺陷 短小：只解释事实和演示、描述缺陷必需的细节 单一：每一个报告中针对一个缺陷 步骤清晰：要清楚地描述出缺陷的发生场景，包括前置条件和操作的详细步骤 再现：按照预定步骤可以重现相同状况 在报告缺陷时只描述事实，不做评价，也不要有人身攻击 必要的时候可以添加注释（remarks） 可以上载屏幕抓图和其他附件软件缺陷报告（续）*/52软件缺陷报告（续）为书写更好的缺陷报告，需要遵守“5C”准则 Correct(准确) 每个组成部分的描述准确，不会引起误解 Clear(清晰) 每个组成部分的描述清晰，易于理解 Concise(简洁) 只包含必不可少的信息，不包括任何多余的内容 Complete(完整) 包含复现该缺陷的完整步骤和其他本质信息 Consistent(一致) 按照一致的格式书写全部缺陷报告软件缺陷报告（续）*/52软件缺陷报告（续）缺陷报告的组织结构 缺陷的标题与简单描述 缺陷的基本信息,包括： 测试软件名称、版本号、缺陷或错误类型、可重复性、测试平台、平台语言、缺陷或错误范围、严重程度及优先级 要求填写完整、准确 复现缺陷的操作步骤 描述该缺陷或错误出现的操作顺序，要求完整、简洁、准确。对命令、系统变量、选项要用大写字母，对控件名称等加双引号 缺陷的实际结果描述、期望的正确结果描述 注释文字和截取的缺陷图像 对缺陷或错误的附加描述，一般包括缺陷或错误现象的图像，包括其他建议或注释文字null*/52冗长混乱的错误报告null*/52含糊不清的错误报告 null*/52优秀的错误报告 软件缺陷管理工具*/52软件缺陷管理工具缺陷管理作为软件质量管理的重要组成部分,正在成为软件开发管理过程的又一亮点 国内外越来越多的公司对缺陷管理工具的需求逐渐增多而且更加明确 大家渴望能够得到物美价廉的可用版本(当然大多数都有免费的试用板)软件缺陷管理工具 （续）*/52软件缺陷管理工具 （续）商用工具 国外工具 Compuware公司的TrackRecord软件 IBM Rational公司的ClearQuese软件 国产工具 上海微创公司的BMS软件 北航的软件质量监控系统QAMonitor 共享软件 BugRat http://www.gjt.org/pkg/bugrat 开源代码Bugzilla,Buggit,Mantis等软件缺陷管理工具（续）*/52软件缺陷管理工具（续）使用开源系统的利弊 由于开源系统的代码是公开的，用户可自行维护和定制，大家也可以提交新特性和功能扩展要求 不受制于商业系统的制造商 开源系统与其他工具的集成比较差，不如商业系统提供整个软件开发生命周期的工具的集成 如项目管理、需求管理、建模、自动化测试、缺陷跟踪、配置管理等有机集成，实现整个开发流程的自动化作业*/52作业下载、安装共享的缺陷管理工具，并实际使用它们，说明它们的工作流程，比较它们的各自特点。 选做：下载和生成开源的缺陷管理工具，并实际使用它们，说明它们的工作流程