软件缺陷
软件缺陷的定义
IEEE 1983 of IEEE Standard 729中对软件缺陷作了一个标准的定义：从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。因此软件缺陷就是软件产品中所存在的问题，最终表现为用户所需要的功能没有完全实现，没有满足用户的需求。
软件缺陷是指存在于**软件（程序、数据、文档）**中的那些不符合用户需求的问题
软件未达到需求规格说明书表明的功能
软件出现了需求规格说明书指明不会出现的错误
软件的功能超出了需求规格说明书指明的范围
软件未达到需求规格说明书虽未指明而应该达到的目标
软件测试人员认为软件难以理解、不易使用、运行速度慢、或者最终用户认为不好
补充: 软件缺陷(Defect)，常常又被叫做Bug
软件缺陷示例
计算器说明书一般声称该计算器将准确无误地进行加、减、乘、除运算。如果测试人员或用户选定了两个数值后，随意按下了“+”号键，结果没有任何反应。——>软件未达到软件需求规格说明书表明的功能
若在进行测试时，发现除了规定的加、减、乘、除功能之外，还能够进行求平方根的运算，而这一功能并没有在说明书的功能中规定。——>软件的功能超出了软件需求规格说明书指明的范围
若在测试过程中发现，因为电池没电而导致了计算不正确，但软件需求规格说明书未能指出在此情况下应如何进行处理。——>软件未达到软件需求规格说明书未指明而应该达到的目标
假如计算器说明书指明计算器不会出现崩溃、死锁或者停止反应，而在用户随意按、敲键盘后，计算器停止接受输入或没有了反应。——>软件出现了软件需求规格说明书指明不会出现的错误
测试人员或最终用户发现计算器某些地方不好用，比如，按键太小、显示屏在亮光下无法看清等。——>软件测试人员认为软件难以理解、不易使用、运行速度慢，或者最终用户认为不好
软件缺陷的表现形式
功能、特性没有实现或部分实现。
设计不合理，功能特性不明确，逻辑不清楚或存在矛盾。
产品实际结果和所期望的结果不一致。
没有达到需求规格说明书所规定的性能指标等。
运行出错，包括运行中断、系统崩溃、界面混乱等。
数据不正确、精度不够、不完整或格式不统一。
用户不能接受的其他问题，如存取时间过长、界面不美观。
硬件或系统软件上存在的其他问题
软件缺陷的产生原因
软件缺陷产生是不可避免的，造成软件缺陷产生的原因主要归纳如下:
需求解释或者记录错误
用户需求定义错误
设计说明存在错误
编码说明、程序代码有误
硬件或者软件系统上存在错误
其他，如文档错误、内容不正确或拼写错误
软件缺陷的根源
交流不充分
客户与开发人员、开发人员与测试人员等
软件的复杂性
功能复杂、开发复杂、测试复杂
开发人员的错误
对需求的理解、开发压力、能力与经验
需求的变化
需求说明书、设计文档、程序的变更
进度压力
项目周期比较紧
软件缺陷的信息 ：
为了便于缺陷的定位、跟踪和修改，要对所发现的缺陷，按照缺陷的严重程度、优先级、发现阶段、修复阶段、缺陷的性质、所属功能模块、系统环境等方面进行分类和统计
软件缺陷分类——缺陷状态
|
软件缺陷的信息
软件缺陷分类——缺陷所属模块（BUG类型）
软件缺陷分类——严重程度
软件缺陷分类——优先级
开发人员拒绝修改的缺陷
程序员无法重现或者现象难以捕捉
没有明确的报告以说明重现缺陷的步骤
程序员无法读懂的缺陷报告
用户很少使用或者不符合用户使用习惯的操作出错
由不受信任的测试人员提出
缺陷修改说明
不是所有缺陷都会修改
a) 市场的压力使得产品最终发行有时间限制
b) 测试人员错误理解或者不正确操作引出的缺陷(FAQ)
c) 错误的修改影响的模块较多，带来的风险较大(遗留)
d) 修改性价比太低
e) 缺陷报告中提出的问题很难重现
报告缺陷的重要性
软件缺陷的描述是软件缺陷报告的基础部分，需要使用简单、准确、专业的术语来描述缺陷。否则，它就会含糊不清，可能会误导开发人员，影响开发人员的效率，也会影响测试人员自身的声誉，准确报告缺陷是非常重要的
清晰准确的软件缺陷描述可以减少开发人员退回来的缺陷数量，可以节省开发人员和测试人员的时间
提高软件缺陷修复的速度，使项目组能够有效地工作
提高测试人员的可信任程度，可以得到开发人员对有效缺陷的及时响应
加强开发人员、测试人员和管理人员的协同工作，让他们更好的工作
报告缺陷的注意事项
尽量确保缺陷可以重现
- 如果提交的缺陷无法重现，会影响开发人员的工作效率
简洁、准确、完整
-测试人员在提交缺陷报告时，要站在开发人员的角度上思考问题，要确保开发人员能迅速定位问题，而不会产生理解上的歧义。
一个缺陷一个报告
- 有的测试人员喜欢在一个缺陷报告里提交多个缺陷，这种习惯不提倡，原因有以下两点：
–不便于分配
–不便于验证
缺陷的书写规范
标题：应保持简短、准确，提供缺陷的本质信息
尽量按缺陷发生的原因与结果的方式书写
避免使用模糊不清的词语，
例如：“功能中断，功能不正确，行为不起作用”等。
应该使用具体文字说明缺陷的症状
为了便于他人理解，避免使用俚语或过分具体的测试细节
复现步骤：应包含如何使别人能够很容易的复现该缺陷的完整步骤
为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的
常见问题：
-包含了过多的多余步骤，且句子结构混乱，可读性差，难以理解
-包含的信息过少，丢失了操作的必要步骤
复现步骤的正确书写方式：
-提供测试的环境信息
-简单地一步步引导复现该缺陷，一个步骤包含的操作不要多
-每个步骤前使用数字对步骤编号
-尽量使用短语或短句，避免复杂句型句式
-复现的步骤要完整、准确、简短
-将常见步骤合并为较少步骤
-按实际需要决定是否包含步骤执行后的结果
实际结果：
-是执行复现步骤后软件的现象和产生的行为
-实际结果的描述应向标题信息那样，要列出具体的缺陷症状，而不是简单地指出“不正确”或“不起作用”
避免常见的错误：
-避免使用我、你等人称代词，可以直接使用动词或使用“用户”代替
-避免使用情绪化的语言和强调符号
-避免使用诸如“似乎”、“看上去可能”等含义模糊的词汇，而需要报告确定的缺陷结果
-避免使用自认为比较幽默的语句，只需客观地描述缺陷的信息
-避免提交不确定的测试问题，自己至少需要重现一次再提交
缺陷报告
缺陷处理流程
缺陷跟踪
-新提交的缺陷为新建状态，确认有效后为打开状态，经开发人员修改后，缺陷变为已修复（待验证）状态。此时就需要测试人员对缺陷进行回归测试，验证问题是否修复
-如果问题仍然存在，则测试人员将该缺陷的状态修改为重新打开
-如果问题已经修复，则测试人员将该缺陷的状态置为关闭状态（验证通过），同时添加回测说明如“该缺陷已解决”
-还有一种情况：开发人员认为缺陷在当前版本可以暂不修改，而考虑在后续版本中再做修正，缺陷的对应状态为延期
对于这种情况，项目负责人应召集开发人员、测试人员和其他项目相关人员进行讨论，如果讨论结果为同意则延期，如果不同意，则重新打开缺陷
缺陷统计
-对软件问题的功能域分布进行分析，找出系统的薄弱环节
-要详细采集每个功能模块或系统构件的缺陷数据，并按功能、错误类型、严重程度等分类。
-二八定理：80%的软件问题总是发生在大约20%的功能模块中
-对缺陷的注入阶段的分布进行分析，并与历史数据相比较。应按不同的开发阶段详细采集缺陷的数据
-应对软件缺陷类型进行分析，以便针对各自的特点，先修复严重缺陷
-应动态采集每个测试周期中发现的缺陷数，并有效地控制缺陷的修复率
-应密切观察缺陷的状态，并及时跟踪其状态的变化，以检查测试和开发人员的工作情况
bug统计
缺陷按活动分布
缺陷按照严重程度分布
缺陷按照引入源分布
缺陷密度
基本的缺陷测量是以每千行代码的缺陷数(个/KLOC)来测量的。称为缺陷密度，其测量单位是defects／KLOC。可按照以下步骤来计算一个程序的缺陷密度：
-累计开发过程中每个阶段发现的缺陷总数
-统计程序中新开发的和修改的代码行数
-计算每千行的缺陷数=1000*缺陷总数/代码行数
缺陷分析
缺陷数据分析关注的问题
缺陷数据分析的重要性
缺陷数据分析的数据指标
缺陷数据分析关注的问题
-正在测试的软件哪个模块的问题最多
-测试人员中谁报告的软件缺陷最多
-各类缺陷所占的数量百分比分别是多少
-开发人员能及时修复软件缺陷吗
-开发人员一次正确修复缺陷的百分比是多少
-正在开发的软件能否在计划的时间内正常发布
缺陷数据分析的重要性
-统计未修复的缺陷数目（特别是严重性高的缺陷），预计软件是否可以如期发布
-分析缺陷的类型分布，发现存在较多缺陷的程序模块，找出原因，进行软件开发过程改进
-根据测试人员报告缺陷的数量和准确性，评估测试有效性和测试技能
-根据报告的缺陷修复是否及时，改进软件开发与测试的关系，使测试与开发更有机的配合
缺陷数据分析的数据指标
-每天/周报告的新缺陷数目
-每天/周修复的缺陷数
-累计报告的缺陷数目
-累计修复的缺陷数
-不同严重性类型的缺陷数
-程序模块与发现的缺陷的对应关系
常用的寻找缺陷的方法
UI界面
色彩：
-彩的搭配无序、混乱是软件图形界面设计的大忌，图形界面应尽量设计得温和些。这类缺陷主观类强，个人美感占据主动，所提交的缺陷一般严重程度不可定得太高
功能结构布局
-功能结构布局主要从界面的功能区域划分来考虑。相同的、类似的功能应该放在邻近的区域
图片
图片选用不合理，与当前软件类型不符，无法正确体现当前界面功能性含义。图片不规范、不清晰
页面大小
在B/S结构的软件系统中，当一个页面元素太多，未作精简时，在打开该页面时可能需要较长的加载时间，这对于软件性能是一个不小的影响，既增加了服务器的压力，又容易引起用户的反感
字体
字体在软件界面中尤其重要，字体的使用要符合软件开发规范
窗体大小
窗体的设计要有层次感，父窗口、子窗口应该有所区别。窗口不应该有太多空白处，功能区域充实
界面文字
页面信息描述不清楚，有语病，错别字。简单语言复杂化，描述不正确，不符合当前页面。错误的帮助信息，乱码等
容错处理(功能缺陷)
容错处理在软件系统中占据十分重要的地位。所谓容错，就是容忍错误的能力。当用户在使用软件过程中发生错误后，软件应该能给出引导信息，指应用户进行正确的操作
数据转换
软件中的功能主体一般由等组成
性能缺陷
这里所说的性能问题不需专业的工具就能发现的问题，这类问题在平常做黑盒测试的时候就能发现
个体行为
-处于CMM第一级（或称为初始级）的软件组织，对软件缺陷的管理无章可循。工程师们只是在发现缺陷后，修改相应的软件。通常，没有人会去记录自己发现的缺陷。也没有人知道在新的软件版本里，究竟纠正了哪些缺陷，还有哪些缺陷未被纠正。而且，只有在下一轮测试中才有可能知道那些所谓已被纠正了的缺陷是否真的被纠正了，更重要的是纠正过程是否引入了新的缺陷
-所以这样的软件组织的项目交货期（Release Date）表现出强烈的不可预测性。并且， 为了获得一个高质量的软件产品（如果能够的话），通常要在测试上花费大量的人力
项目行为
在CMM第二级（或称为可重复级）的软件组织中，软件项目会从自身的需要出发，制定本项目的缺陷管理过程。一个完备软件缺陷管理过程通常会包括如下几个方面：
1）提交缺陷
2）分析和定位缺陷
3）提请修改相应的软件
4）修改相应的软件
5）验证修改
项目组会完整地记录开发过程中的缺陷，监控缺陷的修改过程，并验证修改缺陷的结果
组织行为
-CMM第三级（或称为已定义级）的软件组织会汇集组织内部以前项目的经验教训，制定组织级的缺陷管理过程。并且，要求项目根据组织级的缺陷管理过程定制本项目的缺陷管理过程
-从而，整个软件组织中的项目都遵循类似的过程来管理缺陷。好的缺陷管理实践成为所有项目的实践，而教训也为所有项目所了解。更重要的是，随着组织的不断发展完善，组织的过程会得到持续性的改进，所有项目的过程也都会相应的改进。
持续优化
-与CMM第四级相比，CMM第五级（或称为持续优化级）更强调对组织的过程进行持续性改进，从而使过程能力得到不断的提升
-就缺陷管理而言，软件组织应当在量化理解其过程能力的基础上，持续地改进组织级的开发过程、缺陷发现过程，引入新方法、新工具，加强经验交流，从而实现缺陷预防（Defect Prevention）
-缺陷预防的着眼点在于缺陷的共性原因（Common Cause）。通过找寻、分析和处理缺陷的共性原因，实现缺陷预防
SVN使用指南
问题与案例
电脑发生故障，文件没有备份而丢失了
由于人员离职，导致某些资料丢失了
我怎么知道手头的公共资料是不是最新版呢？
想要追溯几个月前的某个状态，却发现那个版本的文件已经被当作垃圾删除了
每天要花费很多时间来向别人提供需要共享的资料
相似的应用系统，每次都重复开发，难以复用
一个软件被用于多个项目，发现其中存在一个BUG，所有这些项目都要进行修复
人员分布在两地开发，版本如何同步
甲乙两人为不同目的修改了同一份文件，乙的提交在甲提交之后，导致甲修改的内容丢失了
SVN简介
- 一个开源的版本管理软件
-可架设在Apache上，最常用的客户端为TortoiseSVN（简称TSVN）
应用环境
- 服务器端：CollabNet的SVN服务器端安装包（内含Apache2.2）
-推荐使用TortoiseSVN（以下简称TSVN）
-可通过TSVN进行读、写操作
-可通过IE浏览器进行读操作
-可通过各种插件与开发工具集成