BUG管理
编写优秀Bug报告的艺术
发表于：2010-5-20 11:36 作者：不详 翻译:kik 来源：imlogic的专栏(CSDN)
在99年的Quality week上的一次演讲中，微软的一个测试经理，Roger Sherman指出了由于“不可重现”导致bug关闭的主要原因。这是一个非常可惜的情况，因为这样的bug report浪费了紧张的开发计划中的宝贵时间，增加了对产品质量完全是无关紧要的事情，同时导致了在开发人员和测试之间的挫败感和差的感觉。有时，bug report是由于短暂的或随机的事件，测试和开发之间不一致的工具和配置，或者在测试的环境下对正确的行为的模糊定义而产生的，但是许多的由于不可重现而被关闭的测试报告是因为描述不清晰，被误解，或者只是文字的错误。
幸运的是，我学习到一些能够引起管理层注意，更清楚的和开发人员沟通并得到修复的编写优秀bug report的诀窍。这些技巧不仅仅提供了是在被修复的问题的比例方面得到了可靠的回报，而且在同开发人员和管理层的通过中也得到了回报。在我管理的项目中使用这种方法编写bug report，8份bug report中大约只有一个没有被修复。
这篇文章的思想只有当你的报告针对的测试执行过程是专业的质量工作才可以发挥作用。聪明地执行完整的测试包是产生可靠的测试状况信息的基础的其中一个因素。在许多的测试文献中广泛地介绍了多种多样的关于如何构建这样的测试包的方法。选择和你质量风险管理需求相一致的技术并且使之适应你的具体情况，敏捷地监督已计划的测试的执行过程，这样你就可以拥有可靠的测试执行过程。
另外一个关键的因素－bug report，却没有得到太多的关注。这是非常令人遗憾的，因为优秀的bug report对反映测试小组真实的和可理解的工作质量同测试本身一样都是非常重要的。试想一下：如果你不能用开发人员能够理解的术语和能够用于调试的方法给开发人员解释一个错误，他怎么能够修复问题呢？如果你不能够在bug report中提出象“保险杆标签”（bumper sticker）一样的错误总结来引起管理层的注意，你又如何让他们关心你们发现的问题呢？
Bug report的核心是对错误的描述。表格1中是一个关于好和差的错误描述的例子。编写好的bug report是一种好的艺术形式。采用以下的10条技巧可以帮助你的小组提高编写bug report的质量：
组织Structure：测试人员应该采用深思熟虑的，小心谨慎的方法执行测试，并且做详尽的记录。这样可以促使他们对测试下的系统有很好的认识。当错误发生的时候，一个有组织的测试人员能够知道最早出现问题的地方。
重现Reproduce：测试人员在编写bug report之前必须在检查问题是否可重现。如果错误不可再重现，仍然应该写下来，但是必须说明问题的偶然性。一个好的处理原则就是在编写bug report之前反复尝试3次。
隔离Isolate：在尝试编写bug report之前，必须试着隔离错误。可以采用改变一些变量的方法，如系统的配置，它可能可以改变错误的症状。这些信息可以为开发人员着手调试提供思路。
归纳Generalize：在测试人员发现了一个已隔离的，可重现的问题后，应该对问题进行归纳。同一个问题是否出现在其他的模块或其他的地方？同一个故障是否有更加严重的问题？
对比Compare：如果测试人员以前曾经验证过现在出错的测试用例，那么他就应该检查以前的测试结果以检查相同的条件是否通过以前的测试。如果是的话，那么这个问题就象是一个回归的错误。注意由于同一测试条件有可能出现在多个测试用例中，这个步骤就不仅仅只是检查一个测试用例在以前的多个结果。
总结Summarize：在bug report的第一行写上错误的总结是非常关键的。测试人员要花些时间思考已发现的错误对客户有何影响。这不仅仅要求测试人员编写的报告要能够吸引读者，使和管理层的沟通清晰，还要能够帮助设置错误修复的优先级别。
精简Condense：在bug report的初稿完成后，测试人员应该反复阅读它，集中剔除那些没有关系的步骤或词语。隐含的或模糊的说明和那些由于对没有任何关系的细节或者那些在重现错误过程中不需要的步骤而消磨报告欢迎程度的无穷唠叨都不是bug report的目标。
消除歧义Disambiguate：测试人员在精简空话的同时或其之后随即应该再仔细检查报告是否有会产生误解的地方。测试人员应该尽量避免使用模糊的，会产生歧义的和主观的词语。目标是使用能够表述事实，清楚的，不会产生争执的词语。
中立Neutralize：如文中所述，作为坏消息的传递人，和善地提交消息是一个挑战。如同所有的错误总结一样，独立的bug report在措辞方面应该保持公正。攻击开发人员，指责潜在的错误，企图诙谐或使用挖苦将引起开发人员的憎恶，并且使注意力从“提高产品质量”这个大的目标上转移开了。谨慎的测试人员只用Bug report来描述事实。
检查Review：一旦测试人员感觉bug report是他能够编写的最好版本，他应该将报告再给一个或多个同行进行检查。他的同事们也应该给出一些建议，为了澄清问题不断地提问，如果适当的话，甚至可以挑战“错误成灾”的结论。在允许的时间里，测试小组应该尽可能提交最好的bug report。
以上10条技巧可以帮助你和你的小组提交准确简洁的，彻底校订的，精心构思的，高质量的技术文档。测试小组应该集中编写bug report的任务，测试组长和经理应该让测试组成员清楚地认识到编写优秀的bug report是一项首要的工作任务。衡量优秀的bug report的质量指标应该包括如下：
对管理层来说，是清晰明了的，特别是在概要这一级；
对于开发部门是有用的，主要是给出能够让开发人员高效地调试问题的相关信息
可以很快的将bug从“Opened”状态转变成“Closed”状态，减少为得到更多的信息从开发人员打回的差的bug report并导致测试人员返工的时间。
改进bug报告的流程是需要花费一些时间的，但是也给予了效果显著的回报。首先，简单的流程改进了测试小组和高层、平行管理层之间的沟通，增强小组的信任度，名望和鼓励管理层给测试投资更多的资源。第二，平稳地递交报告给开发人员促进了测试和开发人员之间积极的关系。第三，更短的bug生命周期是更加有效的，在时间上之前花费在编写优秀bug report上的时间和后期由于返工差的bug report花费的时间相抵消。这些回报帮助开发流程通过有效的沟通和高效率的流程获得更好的产品质量。
软件缺陷的种类划分
按照软件缺陷的产生原因，可以将其划分为不同的缺陷类别：
1、功能不正常
简单地说就是所应提供的功能，在使用上并不符合产品设计规格说明书中规定的要求，或是根本无法使用。这个错误常常会发生在测试过程的初期和中期，有许多在设计规格说明书中规定的功能无法运行，或是运行结果达不到预期设计。最明显的例子就是在用户接口上所提供的选项及动作，使用者操作后毫无反应。
2、软件在使用上感觉不方便
只要是不知如何使用或难以使用的软件，在产品设计上一定是出了问题。所谓好用的软件，就是使用上尽量方便，使用户易于操作。如微软推出的软件，在用户接口及使用操作上确实是下了一番功夫。有许多软件公司推出的软件产品，在彼此的接口上完全不同，这样其实只会增加使用者的学习难度，另一方面也凸显了这些软件公司的集成能力不足。
3、软件的结构未做良好规划
这里主要指软件是以自顶向下方式开发，还是以自底向上方式开发。如果是以自顶向下的结构或方法开发的软件，在功能的规划及组织上比较完整，相反以自底向上的组合式方法开发处的软件则功能较为分散，容易出现缺陷。
4、提供的功能不充分
这个问题与功能不正常不同，这里指的是软件提供的功能在运作上正常，但对于使用者而言却不完整。即使软件的功能运作结果符合设计规格的要求，系统测试人员在测试结果的判断上，也必须从使用者的角度进行思考，这就是所谓的“从用户体验出发”。
5、与软件操作者的互动不良
一个好的软件必须与操作者之间可以实现正常互动。在操作者使用软件的过程中，软件必须很好地响应。例如在浏览网页时，如果操作者在某一网页填写信息，但是输入的信息不足或有误。当点击“确定”按钮后，网页此时提示操作者输入信息有误，却并未指出错误的哪里，操作者只好回到上一页重新填写，或直接放弃离开。这个问题就是典型的在软件对操作互动方面未做完整的设计。
6、使用性能不佳
被测软件功能正常，但使用性能不佳，这也是一个问题。此类缺陷通常是由于开发人员采用了错误的解决方案，或使用了不恰当的算法导致的，在实际测试中有很多缺陷都是因为采用了错误的解决方法，需要加以注意！
7、为做好错误处理
软件除了避免出错之外，还要做好错误处理，许多软件之所以会产生错误，就是因为程序本身对于错误和异常处理的缺失。例如被测软件读取外部的信息文件并已做了一些分类整理，但刚好所读取的外部信息文件内容已被损毁。当程序读取这个损毁的信息文件时，程序发现问题，此时操作系统不知该如何处理这个情况，为保护系统自身只好中断程序。由此可见设立错误和异常处理机制的重要性！
8、边界错误
缓冲区溢出问题在这几年已成为网络攻击的常用方式，而这个缺陷就属于边界错误的一种。简单来说，程序本身无法处理超越边界所导致的错误。而这个问题，除了编程语言所提供的函数有问题之外，很多情况下是由于开发人员在声明变量或使用边界范围时不小心引起的。
9、计算错误
只要是计算机程序，就必定包括数学计算。软件之所以会出现计算错误，大部分出错的原因是由于采用了错误的数学运算工时或未将累加器初始化为0.
10、使用一段时间所产生的错误
这类问题是程序开始运行正常，但运行一段时间后却出现了故障。最典型的例子就是数据库的查找功能。某些软件在刚开始使用时，所提供的信息查找功能运作良好，但在使用一段时间后发现，进行信息查找所需的时间越来越长。经分析查明，程序采用的信息查找方式是顺序查找，随着数据库信息的增加，查找时间自然会变长。这就需要改变解决方案了！
11、控制流程的错误
控制流程的好坏，在于开发人员对软件开发的态度及程序设计是否严谨。软件在状态间的转变是否合理，要依据业务流程进行控制。例如，用软件安装程序解释这类问题最方便直观。用户在进行软件安装时，输入用户名和一些信息后，软件就直接进行了安装，未提示用户变更安装路径、目的地等。这就是软件控制流程不完整导致的错误问题。
12、在大数据量压力下所产生的错误
程序在处于大数据量状态下运行出现问题，就属于这类软件错误。大数据量压力测试对于Server级的软件是必须进行的一项测试，因为服务器级的软件对稳定性的要求远比其它软件要高。通常连续的大数据量压力测试是必须实施的，如让程序处理超过10万笔数据信息，再来观察程序运行的结果。
13、在不同硬件环境下产生的错误
这类问题的产生与硬件环境的不同相关。如果软件与硬件设备有直接关系，这样的问题就是数量相当多。例如有些软件在特殊品牌的服务器上运行就会出错，这是由于不同的Server内部硬件了不同的处理机制。
14、版本控制不良导致的错误
出现这样的问题属于项目管理的疏忽，当然测试人员未能尽忠职守也是原因之一。例如一个软件被反映有安全上的漏洞，后来软件公司也很快将修复版本提供给用户。但在一年后他们推出新版本时，却忘记将这个已解决的bug-fix加入到新版本中。所以对用户来说，原本的问题已经解决了，但想不到新版本升级之后，问题又出现了。这就是由于版本控制问题，导致不同基线的merge出现误差，使得产品质量也出现了偏差。
15、软件文档的错误
最后这类缺陷是软件文档错误。这里所提及的错误，除了软件所附带的使用手册、说明文档及其它相关的软件文档内容错误之外，还包括软件使用接口上的错误文字和错误用语、产品需求设计PD、UI Spec等的错误。错误的软件文档内容除了降低产品质量外，最主要的问题是会误导用户！
Bug定级示例
1级，系统崩溃
定义：严重阻碍测试和开发工作
对应优先级：最高
具体可分为：
1.功能完全没有实现
2.应用闪退/崩溃无法运行
3.应用必现安全模式，无法运行
4.其他导致功能无法测试的问题
2级，至关重要
定义：非阻碍用例执行的严重问题
对应优先级：高
具体可分为：
1.简单操作应用闪退/崩溃，卡死
2.数据丢失
3.严重影响系统，自身功能无法运行
4.严重数值计算错误
5.数据库损坏或无法保存配置
6.安全性问题（包括数据加密等）
3级，主要
定义：功能存在缺陷，但不影响应用和系统的稳定性
对应优先级：中
具体可分为：
1.内存泄露（长时间不用的对象需要被回收，不被回收占内存）
2.功能实现逻辑覆盖不全面
3.非必现，但复现概率超过50%的闪退/崩溃和安全模式
4级，一般
定义：对应用熟悉度高才能感知到的问题，对应用基本功能实现无影响
对应优先级：中
具体可分为：
1.轻微数值计算错误
2.功能实现有误，与产品文档不完全贴切
3.用户简单操作，即可明显感知的UI问题
5级，较小
定义：界面，性能缺陷
对应优先级：低
具体可分为：
1.操作界面错误（提示显示规则，刷新规则是否与文档一致）
2.边界条件显示错误
3.提示信息和界面效果展示错误（包括未给出信息、信息提示错误等）
4.复现率低于5%的闪退/崩溃和安全模式
5.插件兼容和性能未优化问题
6.非正常操作导致UI显示异常
6级，建议
定义：对于产品的意见或者建议
对应优先级：低
具体可分为：
1.对于产品设计方面的意见和建议
2.对于产品界面优化方面的意见和建议
3.对于产品需要优化增强用户体验方面的意见和建议
按照测试种类分
逻辑功能类，性能类，界面类，易用性类，安装，兼容性类
按照功能模块分
注册，登录，购物车，分类，订单，个人信息
一般包括：
1、计划与实际的偏差比较，比如工作量、Bug数
2、针对工作量统计，可以按照活动类型、人员分类统计
3、针对质量情况的统计分析，各模块Bug分布、各等级Bug分布、Bug的处理情况、Bug收敛情况。
4、经验教训等
5、遗漏、遗留Bug情况
主要内容是当日测试活动的概述，和明天测试活动的计划。测试日报的目的是让相关人员对当前测试活动的状态有一个确切的了解。测试日报应当简明扼要的反映出当日测试进度，成果及求助。
测试日报的主体应当包含以下三个内容：
1、当日测试进度的关键数据
a、测试进度 测试周期几天，当前执行到哪一天
b、发现问题数量及各种等级问题单的详细个数
c、待回归问题单数量，回归不通过问题数量
d、用例执行进度
2、风险与求助
a、测试活动中发现的在测试内部不能解决并对当前测试进度有风险的问题。
比如测试环境网络部稳定，阻塞性的测试执行的产品问题
b、测试活动中发送的测试人员不能解决的问题，需要得到哪一方面的帮助
3、明日计划
规划明日测试的目标，测试方向，测试策略等
可选项
1.当前版本发现问题详细清单
2.本轮测试策略，测试计划
3.今日测试明星（表现优秀的测试人员及事迹）
4.对当前测试活动有帮助的人员的感谢
5.测试技巧（对测试有帮助的技巧性文档，总结FAQ等）
6.测试工作中的不足以及改进计划
7.测试相关知识
周报：
阐述自己一周的工作情况。大概可以包括这个几点：
1、内容概要罗列以及花费时间列表
阐述本周自己主要的工作情况，譬如参与了哪几个项目的哪些相关测试，出席了几个公司会议，参加了几个公司内（或外）的相关培训课，阅读了什么工作相关的资料/书籍等，同时（推荐以表格的形式）列出每一项工作（或相关）内容所花费的时间（work hour）
2、执行的测试用例数目
按照项目分别列出，本周执行了多少测试用例，其中pass多少，fail多少，有多少用例被block了不能执行（需要另外列出具体的被block原因，如某个bug或者某项测试资源没有到位），还有多少已分配的测试用例没有完成。这些信息推荐以表格形式给出，参见下面的草图：
|
|
Pass
|
Fail
|
Blocked
|
Remaining
|
|
Project A
|
25
|
3
|
2
|
16
|
|
......
|
|
|
|
|
如果执行了ad-hoc或者exploration测试，可以考虑以表格形式列出测试内容。
3、提交的bug具体数目
体现测试人员绩效一个重要的方面是提交的bug数量和质量。所有在这里列出本周里在每个测试项目中你提交的有效bug数，无效bug数（重复的bug，不能复现的bug），验证的bug数（有效修复-fixed，无效修复-reject），这些信息同样推荐以表格形式给出，参见下面的草图：
|
|
Submitted-Valid
|
Submitted-Duplicated
|
Submitted-Unreproduciable
|
Verify-Fixed
|
Verify-Reject
|
|
Project A
|
5
|
2
|
0
|
8
|
3
|
|
......
|
|
|
|
|
|
4、其它
任何工作相关的其余内容。譬如你希望多一个测试平台，你需要某本专业书籍等等等等。
软件缺陷内部数据库的重要性
查看( 666 ) / 评论( 3 )
软件缺陷内部数据库的重要性－文章不错，共享给大家学习
一、概述
测试质量和效率是软件测试的重要内容，其中对软件测试过程发现的软件缺陷（Bug）的管理具有重要作用。
软件测试缺陷管理数据库是管理软件测试缺陷的专用数据库系统，可以高效率地完成软件缺陷的报告、验证、修改、查询、统计、存储等任务。尤其适用于大型多语言软件的测试管理。
实际测试项目实施之前，客户都提供通过因特网访问的项目公共数据库。由于通过因特网访问速度比较慢，客户只给项目中的少数人登录权限，所以，不能满足测试组每个成员都可以方便地访问数据库。更重要的，如果每个测试工程师都各自直接向项目公共数据库报告和修改软件测试发现的缺陷，由于每个人软件测试的经验背景不同，很难控制报告的缺陷质量，也不利于保持软件缺陷报告的一致性。所以，为了保证报告软件缺陷的质量和格式的一致性，需要测试小组内部指定具有测试经验的人员验证和审查小组内部报告的软件缺陷，然后再通过因特网，统一报到项目公共数据库中。
据调查，很多从事多年软件测试的公司，都有内部的软件测试缺陷管理数据库。这些内部数据库大部分是公司内部开发的，也有一些是直接从市场上购买的。公司内部开发的功能更符合实际要求、具有良好的扩展性。直接购买的数据库节约了开发成本，但是往往价格较高，很多功能根本用不上，造成经济上的浪费。
大型的软件测试项目，需要多人组成一个或多个测试小组，通过有效管理和内部交流才能保证测试项目的顺利实施。因此，如果再单纯采用内部电子邮件的方法管理测试的软件缺陷，将造成测试项目实施过程中，软件测试缺陷的交流效率低，缺陷的流程管理难以实时控制。
二、采用电子表格与电子邮件管理软件缺陷引起的问题
在没有引入公司内部软件缺陷管理数据库之前，对于测试发现的软件缺陷，测试小组内部采用发送内部电子邮件的方式。测试工程师发现的软件缺陷，先书写测试基本信息（软件名称、版本号、语言、测试环境、测试内部、缺陷类别，测试者姓名、测试日期），然后加入详细的测试步骤，和/或捕捉缺陷的图像。再发送给测试组内部的软件缺陷验证工程师，为了使内部其他测试工程师注意已经发现的缺陷，还要同时抄送邮件。负责向客户提供的项目数据库测试团对中的工程师，首先要检查测试工程师邮件中的软件缺陷是否正确和完整，包括格式、步骤，然后报告到客户提供的项目数据库。为了便于统计工作量、进度、缺陷类型和数量，通常创建电子表格文件，将缺陷类型、报告者、报告日期、缺陷状态等进行记录。
这种测试工作方式最大的不便之处在于：
1、测试效率不高
测试组每个成员在测试过程中要不断受到中断，需要随时阅读和回复这些邮件，工作效率很低。尤其当测试成员很多，测试的语言版本很多时，缺陷严重工程师的压力更大。内部缺陷验证工程师的工作量很大，不仅要验证缺陷的正确性，报告缺陷到客户的项目数据库，还要逐个向电子表格文件输入每个缺陷的处理情况。另外，如果报告的缺陷很多，很难分类查找某个或某种类型的缺陷。
2、测试质量难保证
由于个人的测试经验和习惯不同，每个人报告的软件缺陷的内容和格式很难保持一致，甚至往往遗漏关键内容。软件缺陷验证时，需要花费很多时间对其内容进行检查，对于检查中发现的问题还要发邮件或口头交流。如果缺陷被验证通过，再报告到客户提供的因特网测试缺陷管理数据库中，并且发送缺陷编号和标题等内容给测试工程师，并抄送给内部其他相关测试工程师，又一次造成测试中断和处理邮件。
3、实时管理难度大
测试过程中，经常需要迅速定位查找某个软件错误，由于没有内部数据库管理，只能从很多测试邮件和缺陷统计电子表格文件中寻找，或者从因特网的项目测试数据库查找，查找耗费大量的时间。另外，如果多个人同时测试不同语言的软件，由于发现的测试缺陷种类不同，缺陷验证工程师可能需要不断切换操作系统验证缺陷，效率很低。
三、引入软件测试缺陷管理内部数据库的重要性分析
以下从软件测试的流程管理的要求和大型多语言软件测试特征方面，论述引入内部软件测试缺陷管理系统的必要性。
1、提高软件缺陷的报告效率和质量
引入内部专用软件测试缺陷数据库具有以下优点：
第一、保持高效率的测试过程。由于测试缺陷数据库通过测试组内部局域网运行，因此打开和操作速度快。测试工程师随时向内部数据库添加新发现的缺陷，而且如果遗漏某项缺陷的内容，数据库系统将会及时给出提示，保证软件缺陷报告的完整性和一致性。软件缺陷验证工程师将主要精力验证数据库中新报告的缺陷，保证了效率。
第二、提高软件缺陷报告的质量。软件缺陷报告的一致性和正确性是衡量软件测试公司测试专业程度的指标之一。通过正确和完整填写软件缺陷数据库的各项内容，可以保证不同测试工程师的缺陷报告格式统一。为了提高报告的效率，缺陷数据库的很多字段内容可以直接选择，而不必每次都手工输入。
第三、实时管理，安全控制。软件缺陷查询、筛选、排序、添加、修改、保存、权限控制是数据库管理的基本功能和主要优势。通过方便的数据库查询和分类筛选，便于迅速定位缺陷和统计缺陷的类型。通过权限设置，保证只有适当权限的人才能修改或删除软件缺陷，保证了测试的质量。
阅读目录
什么是缺陷？
软件缺陷的定义
IEEE 1983 of IEEE Standard 729中对软件缺陷作了一个标准的定义：
- 从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题。
- 从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。
软件缺陷是指存在于软件（程序、数据、文档）中的那些不符合用户需求的问题。
- 软件未达到需求规格说明书表明的功能。（计算器说明书一般声称该计算器将准确无误地进行加、减、乘、除运算。如果测试人员或用户选定了两个数值后，随意按下了“+”号键，结果没有任何反应。）
- 软件出现了需求规格说明书指明不会出现的错误。（假如计算器说明书指明计算器不会出现崩溃、死锁或者停止反应，而在用户随意按、敲键盘后，计算器停止接受输入或没有了反应。）
- 软件的功能超出了需求规格说明书指明的范围。（若在进行测试时，发现除了规定的加、减、乘、除功能之外，还能够进行求平方根的运算，而这一功能并没有在说明书的功能中规定。）
- 软件未达到需求规格说明书虽未指明而应该达到的目标。（若在测试过程中发现，每当计算器重启后，计算值就出现偏差，但软件需求规格说明书未能指出在此情况下应如何进行处理。）
- 软件测试人员认为软件难以理解、不易使用、运行速度慢、或者最终用户认为不好。（测试人员或最终用户发现计算器某些地方不好用，比如，按键太小、显示屏在亮光下无法看清等。）
因此软件缺陷就是软件产品中所存在的问题，最终表现为用户所需要的功能没有完全实现，没有满足用户的需求。
所以，缺陷不仅仅是程序出了bug。缺陷>=bug。
软件缺陷的表现形式
- 功能、特性没有实现或部分实现。
- 设计不合理，功能特性不明确，逻辑不清楚或存在矛盾。
- 产品实际结果和所期望的结果不一致。
- 没有达到需求规格说明书所规定的性能指标等。
- 运行出错，包括运行中断、系统崩溃、界面混乱等。
- 数据不正确、精度不够、不完整或格式不统一。
- 用户不能接受的其他问题，如存取时间过长、界面不美观。
- 硬件或系统软件上存在的其他问题
软件缺陷产生的原因
软件缺陷产生是不可避免的，造成软件缺陷产生的原因主要归纳如下：
- 需求解释或者记录错误
- 用户需求定义错误
- 设计说明存在错误
- 编码说明、程序代码有误
- 硬件或者软件系统上存在错误
- 其他，如文档错误、内容不正确或拼写错误
需求说明书：需求说明书的错误或不清楚引起的错误，是缺陷第一大的来源；
设计文档：设计文档描述不准确、以及与需求说明书不一致，是缺陷的第二大来源；
编码：纯粹是由编码的问题引起；
其他：系统集成、测试等引起；
传话游戏
营长对值班军官:明晚大约八点钟左右,哈雷慧星将可能在这个地区看到,这种慧星每隔七十六年才能看见。命令所有士兵着野战服在操场上集合,我将向他们解释这一罕见的现象。如果下雨的话,就在礼堂里集合,我为他们放一部有关慧星的影片。 值班军官对连长:根据营长的命令,明晚八点哈雷慧星将在操场上空出现如果下雨的话,就让士兵穿着野战服列队前往礼堂,这一罕见的现象将在那里出现。 连长对排长:根据营长的命令,明晚八点,非凡的哈雷慧星将身穿野战服在礼堂中出现。如果操场上下雨的话,营长将下达另一个命令,这种命令每隔七十六年才会出现一次。 排长对班长:明晚八点,营长将带着哈雷慧星在礼堂中出现,这是每隔七十六年才会有的事。如果下雨的话,营长将命令慧星穿上野战服到操场上去。 班长对士兵:在明晚八点下雨的时候,著名的七十六岁的哈雷将军将在营长的陪同下身穿野战服开着他那辆"慧星"牌汽车经过操场前往礼堂。
软件缺陷的根源
缺陷根源：指造成缺陷的根本因素，以寻求软件开发流程的改进、管理水平的提高，软件缺陷根源如上。
- 交流不充分：客户与开发人员、开发人员与测试人员等，沟通太少。
- 软件的复杂性：功能复杂、开发复杂、测试复杂。
- 开发人员的错误：对需求的理解、开发压力、能力与经验。
- 需求的变化：需求说明书、设计文档、程序的变更。
- 进度压力：项目周期比较紧，比如由原定3周改为1周。
软件缺陷修复的费用
软件在从需求、设计、编码、测试一直到交付用户公开使用后的过程中，都有可能产生和发现缺陷。随着整个开发过程的时间推移，更正缺陷或修复问题的费用呈几何级数增长。
某些缺陷检测方法的成本比其他方法要高。最经济的方法应该是找出缺陷的成本最低，而在其他方面同别的方法并无二致。后一个条件很重要，因为查找缺陷的成本受到了很多因素的影响，例如特点的缺陷检测技术所能找到的缺陷总量，缺陷被发现时所处的开发阶段，以及经历因素之外的其他因素。
大部分研究都发现，检查比测试的成本更小。NASA软件工程实验室的一项研究发现，阅读代码每小时能够检测出的缺陷要比测试高出80%左右（Basili and Selby 1987），另一个组织则发现使用测试来检测缺陷的成本是检查的6倍（Ackerman，Buchwald and Lewski 1989）。后来，IBM的一项研究又发现，检查发现一个错误只需要3.5个工作时，而测试则需要花费15~25个工作时（Kaplan 1995）。
软件缺陷的信息
为了便于缺陷的定位、跟踪和修改，要对所发现的缺陷，按照缺陷的严重程度、优先级、发现阶段、修复阶段、缺陷的性质、所属功能模块、系统环境等方面进行分类和统计。
缺陷状态
|
编号
|
缺陷状态
|
描述
|
|
1
|
提交（submited）
|
已提交的缺陷
|
|
2
|
打开（open）
|
确认“提交缺陷”，等待处理
|
|
3
|
拒绝（rejected）
|
拒绝“提交缺陷”，不需要修复或不是缺陷、重复缺陷、无法重现
|
|
4
|
修复（resolved）
|
缺陷被修复
|
|
5
|
关闭（closed）
|
确认缺陷已修复，将其关闭
|
|
6
|
推迟（later）
|
可以在以后解决，但要确定修复日期或版本
|
软件缺陷的信息
|
编号
|
属性名称
|
描述
|
|
1
|
缺陷ID
|
唯一的缺陷ID，可以根据该ID追踪缺陷
|
|
2
|
缺陷状态
|
缺陷状态指缺陷通过一个跟踪修复过程的进展情况
|
|
3
|
缺陷标题
|
描述缺陷的标题
|
|
4
|
缺陷的严重程度
|
对软件产品的影响程度，分致命、较严重、严重、一般、低
|
|
5
|
缺陷的优先级
|
缺陷修复的先后顺序，即哪些缺陷优先修正，哪些稍后修正
|
|
6
|
缺陷所属模块
|
缺陷所属的项目和模块，要能较精确的定位至模块
|
|
7
|
缺陷记录者
|
提交缺陷的人员姓名
|
|
8
|
缺陷提交时间
|
缺陷提交的时间
|
|
9
|
缺陷处理人
|
处理缺陷的处理人
|
|
10
|
处理结果描述
|
对处理结果的描述，描述处理情况和代码修改说明
|
|
11
|
缺陷处理时间
|
缺陷处理的时间
|
|
12
|
缺陷验证人
|
对被处理缺陷验证的验证人（回测者）
|
|
13
|
验证结果描述
|
对验证结果的描述（通过、不通过）
|
|
14
|
缺陷详细描述
|
缺陷的重现步骤
|
|
15
|
缺陷环境说明
|
对测试环境的描述
|
|
16
|
必要的附件
|
如涉及到附件的或错误现象的图片等
|
为了便于缺陷的定位、跟踪和修改，要对所发现的缺陷，按照缺陷的严重程度、优先级、发现阶段、修复阶段、缺陷的性质、所属功能模块、系统环境等方面进行分类和统计。
缺陷分类（bug类型）
系统缺陷
- 由于程序所引起的司机，异常退出。
- 程序死循环。
- 程序错误，不能执行正常工作或重要功能，是系统崩溃或资源不足。
数据缺陷
- 数据计算错误。
- 数据约束错误。
- 数据输入、输出错误。
严重地影响系统要求或基本功能的实现，且没有办法更正（重新安装或者重启不属于更正的方法）。
数据库缺陷
- 数据库发生死锁。
- 数据库的表、缺省值为加约束条件。
- 数据库连接错误。
- 数据库中的表由过多的空字段。
接口缺陷
- 数据通信错误。
- 程序接口错误。
功能缺陷
- 功能无法实现。
- 功能实现错误。
严重地影响系统要求或基本功能的实现，且没有有合理的办法更正（重新安装或者重启不属于更正的方法）。
安全性缺陷
- 用户权限无法实现。
- 超时限制错误。
- 访问控制错误。
- 加密错误。
兼容性缺陷
- 与需求规定配置兼容性不符合。
性能缺陷
- 未达到预期的性能目标。
- 性能测试中出错，导致无法继续进行测试。
界面缺陷
- 操作界面错误。
- 打印内容、格式错误。
- 删除操作未给出提示。
- 长时间操作未给出提示。
- 界面不规范。
用户操作不方便或者遇到麻烦，但不影响执行工作功能的实现。
软件缺陷严重性与优先级
软件缺陷分类：严重性
|
严重等级
|
描述
|
|
5-Critical
|
系统瘫痪、异常退出、死循环、严重的计算错误等
|
|
4-VeryHigh
|
频繁的死机，系统大部分功能不可用
|
|
3-High
|
a.功能点没有实现，或不符合用户需求b.数据丢失
|
|
2-Medium
|
a.影响一个相对独立的功能 b.仅仅在特定条件上发生c.与产品需求定义不一致 d.断断续续的出现问题
|
|
1-Low
|
表面性错误（如错别字）
|
软件缺陷分类：优先级
|
优先级别
|
描述
|
|
5-Urgent
|
最高优先级。在这个错误影响下，系统几乎不可用。
|
|
4-VeryHigh
|
高优先级。错误对这套系统的能力产生严重的影响。
|
|
3-High
|
中优先级。如果这个错误存在与系统中，会制约开发和测试的活动的进行，如果先前没有修复它，那么需要在发布前修复它。
|
|
2-Medium
|
低优先级。不会延迟发布，但是会在以后修正这个错误。
|
|
1-Low
|
最低优先级。时间和资源允许时修正。
|
缺陷修改说明
再来聊聊缺陷修改中碰到的一些情况。
开发人员拒绝修改的缺陷
- 程序员无法重现或者现象难以捕捉
- 没有明确的报告以说明重现缺陷的步骤
- 程序员无法读懂的缺陷报告
- 用户很少使用或者不符合用户使用习惯的操作出错
- 由不受信任的测试人员提出
不是所有缺陷都会修改
- 市场的压力使得产品最终发行有时间限制
- 测试人员错误理解或者不正确操作引出的缺陷(FAQ)
- 错误的修改影响的模块较多，带来的风险较大(遗留)
- 修改性价比太低
- 缺陷报告中提出的问题很难重现
bug
说完了缺陷，让我们深入缺陷中，来聊聊bug。
什么是bug
- bug泛指软件程序的漏洞和缺陷。
- 测试工程师或用户发现与提出的，软件可以改进的细节部分、或者与需求文档存在功能偏差的实现。
- 测试工程师主要职责就是发现bug，提交bug信息给研发人员，研发人员修复bug。
案例
例如登录时，要求输入账号密码。
输入正确的账号密码:
结果提示：用户名/密码不存在
再三确认账号密码是否错误，可以重新再注册一个账号进行登录
如新账号也是账号不存在，此登录已经是bug了！
bug的类型
想要确定bug的类型，需要对产品有较深的理解。
禅道系统中对bug定义划分如下：
- 代码错误(研发代码有误，功能未实现)
- 设计缺陷
- 界面优化
- 性能问题
- 配置相关
- 安装部署
- 安全相关
- 标准规范
- 测试脚本
- 其他(功能类、界面类、性能类、易用性类、兼容性类、其他)
bug等级划分
根据bug等级划分为三级或四级。
等级越高，可能被修复的等级也越高，公司也会根据测试提交的bug数量以及bug等级作为绩效考核标准。
判断bug的等级，如下分类：
- 致命错误
- 常规操作缺引起系统崩溃、死机、死循环
- 造成数据库泄露的安全问题，如恶意攻击造成的账户私密信息泄露
- 涉及金钱隐患，金钱计算bug(如金额不足，还可以购买产品，对公司金额造成重大损失
- 严重错误
- 重要功能未实现，如点击注册无反应，无法登录
- 非常规操作（误操作）导致程序崩溃、死机、死循环
- UI界面的严重问题
- 密码明文显示，数据库泄露
- 普通错误
- 不影响产品运行，不会影响故障，但对产品外观界面影响较大，如删除了好友，好友却未消失
- 功能无法正常显示功能
- 操作界面错乱
- 查询数据错误
- 页面未做输入格式限制
- 删除错误未给与提示
缺陷报告
接下来，聊聊缺陷报告，那什么是缺陷报告？什么是报告缺陷呢？
报告缺陷的重要性
软件缺陷的描述是软件缺陷报告的基础部分，需要使用简单、准确、专业的术语来描述缺陷。否则，它就会含糊不清，可能会误导开发人员，影响开发人员的效率，也会影响测试人员自身的声誉，准确报告缺陷是非常重要的。
- 清晰准确的软件缺陷描述可以减少开发人员退回来的缺陷数量，可以节省开发人员和测试人员的时间。
- 提高软件缺陷修复的速度，使项目组能够有效地工作。
- 提高测试人员的可信任程度，可以得到开发人员对有效缺陷的及时响应。
- 加强开发人员、测试人员和管理人员的协同工作，让他们更好的工作。
报告缺陷注意事项
尽量确保缺陷可以重现。
- 如果提交的缺陷无法重现，会影响开发人员的工作效率。
简洁、准确、完整。
- 测试人员在提交缺陷报告时，要站在开发人员的角度上思考问题，要确保开发人员能迅速定位问题，而不会产生理解上的歧义。
一个缺陷一个报告，有的测试人员喜欢在一个缺陷报告里提交多个缺陷，这种习惯不提倡，原因有以下两点：
- 不便于分配，比如缺陷报告有2个缺陷，分别属于不同的开发人员，到底该分配给谁呢？
- 不便于验证，比如一个缺陷报告里面有2个缺陷，缺陷1已经解决，缺陷2还没有解决，那么这个缺陷报告该不该关闭呢？
缺陷报告书写规范
标题：应保持简短、准确，提供缺陷的本质信息。
- 尽量按缺陷发生的原因与结果的方式书写。
- 避免使用模糊不清的词语，例如：“功能中断，功能不正确，行为不起作用”等。应该使用具体文字说明缺陷的症状。
- 为了便于他人理解，避免使用俚语或过分具体的测试细节。
复现步骤：应包含如何使别人能够很容易的复现该缺陷的完整步骤。为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的。常见问题：
- 包含了过多的多余步骤，且句子结构混乱，可读性差，难以理解。
- 包含的信息过少，丢失了操作的必要步骤。
复现步骤的正确书写方式：
- 提供测试的环境信息。
- 简单地一步步引导复现该缺陷，一个步骤包含的操作不要多。
- 每个步骤前使用数字对步骤编号。
- 尽量使用短语或短句，避免复杂句型句式。
- 复现的步骤要完整、准确、简短。
- 将常见步骤合并为较少步骤。
- 按实际需要决定是否包含步骤执行后的结果。
实际结果：是执行复现步骤后软件的现象和产生的行为。
- 实际结果的描述应向标题信息那样，要列出具体的缺陷症状，而不是简单地指出“不正确”或“不起作用”。
期望结果：描述应与实际结果的描述方式相同。通常需要列出期望的结果是什么。
附件：对缺陷描述的补充说明，可以是以下一些类型：
- 缺陷症状的截图。
- 测试使用的数据文件，166 199 188
其它：
- 选择合适的缺陷严重性属性。
- 按相应的规定，填写相应的字段信息。
避免常见的错误：
- 避免使用我、你等人称代词，可以直接使用动词或必要时使用“用户”代替
- 避免使用情绪化的语言和强调符号；
- 避免使用诸如“似乎”、“看上去可能”等含义模糊的词汇，而需要报告确定的缺陷结果；
- 避免使用自认为比较幽默的语句，只需客观地描述缺陷的信息；
- 避免提交不确定的测试问题，自己至少需要重现一次再提交。
反面的示例：
- 上海人：哪能查询到的结果和查询条件不搭噶的。
- 北京人：哥们好不容易输入一堆个人详细信息后，点击保存后全瞎了。
缺陷处理流程
缺陷跟踪
新提交的缺陷为新建状态，确认有效后为打开状态，经开发人员修改后，缺陷变为已修复（待验证）状态。此时就需要测试人员对缺陷进行回归测试，验证问题是否修复。
- 如果问题仍然存在，则测试人员将该缺陷的状态修改为重新打开。
- 如果问题已经修复，则测试人员将该缺陷的状态置为关闭状态（验证通过），同时添加回测说明如“该缺陷已解决”。
还有一种情况：开发人员认为缺陷在当前版本可以暂不修改，而考虑在后续版本中再做修正，缺陷的对应状态为延期。对于这种情况，项目负责人应召集开发人员、测试人员和其他项目相关人员进行讨论，如果讨论结果为同意则延期，如果不同意，则重新打开缺陷。
缺陷统计
- 对软件问题的功能域分布进行分析，找出系统的薄弱环节。
- 要详细采集每个功能模块或系统构件的缺陷数据，并按功能、错误类型、严重程度等分类。
- 二八定理：80%的软件问题总是发生在大约20%的功能模块中。
- 对缺陷的注入阶段的分布进行分析，并与历史数据相比较。应按不同的开发阶段详细采集缺陷的数据。
- 应对软件缺陷类型进行分析，以便针对各自的特点，先修复严重缺陷。
- 应动态采集每个测试周期中发现的缺陷数，并有效地控制缺陷的修复率。
- 应密切观察缺陷的状态，并及时跟踪其状态的变化，以检查测试和开发人员的工作情况。
bug统计
缺陷按活动分布：
缺陷密度
基本的缺陷测量是以每千行代码的缺陷数(个/KLOC)来测量的。称为缺陷密度，其测量单位是defects／KLOC。可按照以下步骤来计算一个程序的缺陷密度：
- 累计开发过程中每个阶段发现的缺陷总数。
- 统计程序中新开发的和修改的代码行数。
- 计算每千行的缺陷数=1000*缺陷总数/代码行数。
例如：一个132.2万行的源程序总共有210个缺陷，那该程序的缺陷密度是：
缺陷密度 = 1000 * 210 / 1322000 = 0.15个/KLOC
PS：KLOC，千行代码
缺陷数据分析
- 缺陷数据分析关注的问题
- 缺陷数据分析的重要性
- 缺陷数据分析的数据指标
缺陷数据分析关注的问题
- 正在测试的软件哪个模块的问题最多
- 测试人员中谁报告的软件缺陷最多
- 各类缺陷所占的数量百分比分别是多少
- 开发人员能及时修复软件缺陷吗
- 开发人员一次正确修复缺陷的百分比是多少
- 正在开发的软件能否在计划的时间内正常发布
缺陷数据分析的重要性
- 统计未修复的缺陷数目（特别是严重性高的缺陷），预计软件是否可以如期发布。
- 分析缺陷的类型分布，发现存在较多缺陷的程序模块，找出原因，进行软件开发过程改进。
- 根据测试人员报告缺陷的数量和准确性，评估测试有效性和测试技能。
- 根据报告的缺陷修复是否及时，改进软件开发与测试的关系，使测试与开发更有机的配合。
缺陷数据分析的数据指标
- 每天/周报告的新缺陷数目。
- 每天/周修复的缺陷数。
- 累计报告的缺陷数目。
- 累计修复的缺陷数。
- 不同严重性类型的缺陷数。
- 程序模块与发现的缺陷的对应关系。
常用缺陷识别方法
- 通过技术文档识别缺陷
- 设计和分析文档
- 用户使用手册，帮助手册
- 通过行业标准规范识别缺陷
- 与专业人员来沟通识别缺陷
注意：不得站在自己主观意识去判断缺陷
来列举一些例子：
- 页面大小
- 在B/S结构的软件系统中，当一个页面元素太多，未作精简时，在打开该页面时可能需要较长的加载时间，这对于软件性能是一个不小的影响，既增加了服务器的压力，又容易引起用户的反感。例如：
- 图片未经压缩、格式不正确。比如采用BMP。
- 代码冗余，存在太多无用代码。
- 页面元素太多，太过复杂。
- 界面文字
- 页面信息描述不清楚，有语病，错别字。简单语言复杂化，描述不正确，不符合当前页面。错误的帮助信息，乱码等。
- 容错处理（功能缺陷）
- 容错处理在软件系统中占据十分重要的地位。所谓容错，就是容忍错误的能力。当用户在使用软件过程中发生错误后，软件应该能给出引导信息，指应用户进行正确的操作。例如：
- 用户输入错误，系统无提示，无响应，用户不能清晰知道系统不处理的原因。
- 给出信息提示，用户接受后无法继续操作，不给用户“改过自新”的机会。
- 用户输入不合法的信息后，系统给出提示，用户确定后，系统仍能处理错误的信息。
- 取消功能不能取消，比如删除，系统给出提示，是否确定删除，用户否认后仍执行了删除。
- 性能缺陷
- 这里所说的性能问题不需专业的工具就能发现的问题，这类问题在平常做黑盒测试的时候就能发现。例如：
- 打开文档，10秒应该可以完成的，却花了3分钟。
- 启动软件，CPU长时间100%，内存消耗过多。
- 5个用户可以正常使用，20个用户使用时系统崩溃。打开一个登录页面花了1分钟。
- 完成一个查询功能，花了2分钟。
接下来，就考验个人情商环节了，因为一不小心，可能面临挨打的风险！接下来的一些列举项，通常都由专业的人员完成，比如UI的设计师，DBA，人家是专业，你在人家的领域小心指手画脚啊，比如你跟UI说这个页面设计的真丑，那UI的小暴脾气上来，不用小拳锤胸口咋地！
你要是跟DBA说什么SQL有问题：
- 数据转换
- 软件中的功能主体一般由等组成。例如：增加、修改、删除、查询。
- 无法增加记录，比如点击新增，页面自动关闭。
- 增加记录后无显示，但提示增加成功。
- 增加记录后显示不正确，显示为乱码，信息显示不全。
- 增加记录后多出记录。
- 无法修改记录。修改后不能自动更新，需手工更新。
- 无法删除记录，无法全部删除。
- 删除不成功，但相应的记录已被删除。
- 无法查询、查询结果错误。
- UI用户界面
- 色彩：色彩的搭配无序、混乱是软件图形界面设计的大忌，图形界面应尽量设计得温和些。这类缺陷主观类强，个人美感占据主动，所提交的缺陷一般严重程度不可定得太高。例如：
- 整体页面色彩单调，无变化，仅使用一种色彩，且篇幅较大，可提交建议性的缺陷，即使是简单的界面，宁可采用无色，也不可使用鲜艳的单色，如红色，黄色、绿色等。
- 背景色与界面字体色彩相近，不能清晰区分，色彩搭配混乱、复杂，且不符合软件标准。
- 功能结构布局
- 功能结构布局主要从界面的功能区域划分来考虑。相同的、类似的功能应该放在邻近的区域。例如：
- 记录添加功能界面，添加按钮未放在醒目的位置。
- 导航功能位于界面的右则。
- 整体功能区域分布混乱。
- 图片
- 图片选用不合理，与当前软件类型不符，无法正确体现当前界面功能性含义。图片不规范、不清晰。例如：
- 图片色彩过于艳丽或黯淡，模糊不清。
- 图片变形。
- 图片不符合当前界面的主题，图片与描述性文字不符。
- 字体
- 字体在软件界面中尤其重要，字体的使用要符合软件开发规范。例如：
- 字体过大，与其他页面信息脱节，无法形成主体。
- 字体过小，无法看清楚。
- 字体不符合当前界面风格。
- 窗体大小
- 窗体的设计要有层次感，父窗口、子窗口应该有所区别。窗口不应该有太多空白处，功能区域充实。例如：
- 窗口太大，功能按钮分散，间隔太大。
- 窗口太小，功能按钮过于集中，间隔太小，或控件显示不全。
- 弹出窗口未能定于屏幕居中位置。
不同软件组织的缺陷管理过程
- 个体行为
- 处于CMM第一级（或称为初始级）的软件组织，对软件缺陷的管理无章可循。工程师们只是在发现缺陷后，修改相应的软件。通常，没有人会去记录自己发现的缺陷。也没有人知道在新的软件版本里，究竟纠正了哪些缺陷，还有哪些缺陷未被纠正。而且，只有在下一轮测试中才有可能知道那些所谓已被纠正了的缺陷是否真的被纠正了，更重要的是纠正过程是否引入了新的缺陷。
- 所以这样的软件组织的项目交货期（Release Date）表现出强烈的不可预测性。并且， 为了获得一个高质量的软件产品（如果能够的话），通常要在测试上花费大量的人力。
- 项目行为
- 在CMM第二级（或称为可重复级）的软件组织中，软件项目会从自身的需要出发，制定本项目的缺陷管理过程。一个完备软件缺陷管理过程通常会包括如下几个方面：
- 提交缺陷。
- 分析和定位缺陷。
- 提请修改相应的软件。
- 修改相应的软件。
- 验证修改。
- 项目组会完整地记录开发过程中的缺陷，监控缺陷的修改过程，并验证修改缺陷的结果。
- 组织行为
- CMM第三级（或称为已定义级）的软件组织会汇集组织内部以前项目的经验教训，制定组织级的缺陷管理过程。并且，要求项目根据组织级的缺陷管理过程定制本项目的缺陷管理过程。
- 从而，整个软件组织中的项目都遵循类似的过程来管理缺陷。好的缺陷管理实践成为所有项目的实践，而教训也为所有项目所了解。更重要的是，随着组织的不断发展完善，组织的过程会得到持续性的改进，所有项目的过程也都会相应的改进。
- 持续优化
- 与CMM第四级相比，CMM第五级（或称为持续优化级）更强调对组织的过程进行持续性改进，从而使过程能力得到不断的提升。
- 就缺陷管理而言，软件组织应当在量化理解其过程能力的基础上，持续地改进组织级的开发过程、缺陷发现过程，引入新方法、新工具，加强经验交流，从而实现缺陷预防（Defect Prevention）。
- 缺陷预防的着眼点在于缺陷的共性原因（Common Cause）。通过找寻、分析和处理缺陷的共性原因，实现缺陷预防。
