全面软件BUG及管理介绍课件

软件和管理[本章要点]１.软件对软件质量的影响；２.常见的软件类型，重现软件的分析技术；３.软件的描述和管理。[本章目标]了解软件的影响和产生；掌握软件开发过程中产生的种类；掌握使重现的技术；了解软件报告单应该包括的主要内容以及软件的管理流程。软件概述在1983729中对软件缺陷下了一个标准的定义：（1）从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；（2）从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。软件缺陷有很多种，其中主要软件缺陷类型有：1.一些功能、特性没有实现或只实现了一部分；2.软件设计不合理，存在缺陷。实际运行结果和预期结果不一致；3.运行出错，包括运行中断、系统崩溃、界面混乱4.数据结果不正确、精度不够；5.用户不能接受的其他问题，如存取时间过长、界面不美观。的影响会给用户或使用者带来相当大的麻烦，会给集体或者国家带来很大的经济损失。如：千年虫问题。的产生的由来。对于软件而言，是程序编写错误而导致软件产生问题的缺陷。软件测试的目的就是找到软件程序代码内的，纠正它，叫做。产生的原因很多，具体有以下几点。1．程序编写错误的难以避免性。2．需求变更过于频繁

需求变更所造成的结果就是变更程序代码，程序代码只要稍做变更就必须经过测试来确保运行正常，所以这个影响是一个连锁反应或称为依存问题。3．软件的复杂度图形用户界面（）、B\S结构、面向对象设计、分布式运算、底层通信协议、超大型关系型数据库以及庞大的系统规模，都体现了软件复杂度大大高于以前，出现可能性就更高。4．交流不充分或者沟通出问题大部分项目人员在同客户进行交流时常常存在着各种各样的问题，究其原因，还是因为项目人员、参与人员和客户之间没有详细、充分、谨慎地进行交流。

5．测试人员的经验与技巧不足6．时间过于紧迫7．缺乏文档：贫乏或者差劲的文档使得代码维护和修改变得非常困难，结果会导致其他开发人员或客户有许多错误的理解。8．管理上的缺陷的种类是软件“与生俱来”的特征，不同的软件开发阶段会产生不同的，而不同的又会产生不同的后果，因此的属性也并非相同。需求阶段的这个阶段的是最难发现、最难修复的，而且值得注意的是需求阶段的如果没有及时发现等到实现阶段发现时，那么修复它的费用要比当初修复它要高15~75倍。主要的原因如下：1、模糊、不清晰的需求；2、被忽略的需求；3、相互冲突的需求；

分析设计阶段的设计中的比需求阶段产生的特征明显易于捕获，但是其维修代价很高，原因是设计已经作为一个整体影响着整个系统的实现。原因主要有3种途径。1、忽略设计；2、混乱的设计；3、模糊的设计；

实现阶段的就是软件系统中最普通、最一般的“常规”。可以将实现阶段出现的分为下面几类：1、消息错误2、用户界面错误3、遗漏的功能4、内存溢出或者程序崩溃5、其他实现错误第一类型说明了软件系统向用户发送了出错的消息，可能消息是合理的或者表现为某种中断机制，但是用户认为这是一个。如下图：第二类型就是用户界面错误，可归纳为错误。可能是由于制作不标准而导致用户不能正确地工作。第三种类型为遗漏的功能(以输入框输入信息错误，程序抛出未异常为典型)第四种类型为内存溢出或者程序崩溃，表现为程序挂起、系统崩溃，属于一种比较严重的软件类型。（详见教材的药房药品进存销的软件测试）配置阶段的配置阶段的出现的原因是复杂的，比较典型的是旧的代码覆盖了新的代码，或者测试服务器上的代码和实现人员本机最新代码版本不一致。可能是实现人员操作配置管理工具不正确引起的；还可能体现了测试人员或者最终用户操作不正确。短视将来的“千年虫”问题就是当初的设计人员为了节省一点硬件成本给全球造成了难以估量的损失。作者曾经为一家大药房开发了一套药品管理的进销存软件，由于最初的时候对业务流程并不是很熟悉，所以在定义药品编码的时候把许多药品的号定义为了整型变量（），开始作者认为这些足以定义所有的药品名称了，没想到一年以后，由于药房的业务量急增，药品的也就不够了，由于整套系统是由编写，整型变量的最大值只有32767，因此程序经常由于数据溢出而出现问题，所以作者被迫用了近一个星期的时间来修改原来的程序。静态文档的文档的定义很简单，即说明模糊、描述不完整和过期的都属于文档。说明模糊特指无充分的信息判断如何正确地处理事情；描述不完整特指文档信息不足以支持用户完成某项工作；过期的文档是没有及时更新过的、错误的文档。报告单的内容报告单也叫缺陷报告单或者问题报告单。问题报告单所需的基本信息类型是大同小异的，不同的只是组织和标志。介绍一下字段：（1）问题报告编号（2）程序名（3）版本标识：发布号和版本号。是用来识别被测的代码。例如：某个版本号可能是1.01m，发布号是1.01，“m”指1.01版本的第13稿。（4）报告类型：描述了发现的问题类型。包括：编码错误、设计问题、建议、文档、硬件、质疑。（5）严重性：为问题严重程度评分。包含三个等级：三个等级：轻微的、严重的和致命的。（6）附件存有测试数据的软盘、键盘捕获记录或一组可产生测试用例的宏、程序的打印输出、内存或一份注释，里面详细描述了你所做的操作，以及你认为该问题很重要的原因。（7）问题概要：对问题进行描述，有助于评审突出的问题，并找到相应的问题报告。（8）问题能否重现。要多次测试看能否再次出现。（9）问题描述及如何重现。描述所有的步骤和现象，包括错误信息。一定要提交报告。（10）建议的改正措施（11）报告人（12）日期：指的是报告人员发现问题的日期。（13）功能域：对问题进行大体分类。（14）承办人（15）注释：程序员在这里简短地说明为什么要推迟处理，或说明是如何改正问题的。（16）状态。三个状态码：开放、关闭和已解决。（17）优先级。只由项目经理设置。（18）处理状态与处理版本处理状态定义了问题的当前状态：<1>未解决：初始化状态或仍有冲突状态。<2>已改正<3>不能重现<4>暂缓：对存在的问题在下个版本改正。<5>符合设计<6>由报告人撤回<7>需要进一步信息<8>不同意建议<9>重复:关闭重复上报的缺陷。（19）签名:签署以表明已经对改动进行了测试，对结果表示满意。（20）暂缓处理：对缺陷的推迟处理。图-3、图-4整合起来即为一张完整的报告单。图-3报告单(1)图-4报告单(2)报告的特点一份好的问题报告应是书面的、已编号的、简单的、易于理解的、可重现的、易读的和不做判断的。1)书面的一份书面的报告是必要的，供日后对修改后的程序进行测试时使用；让管理层、销售人员和产品支持人员检查。2)已编号的依据惟一的编号跟踪问题报告。3)简单的一份报告应只描述一个问题，不要在一份报告中记录多个缺陷。 4)可重现的一定要强调的可重现性。5)不做判断的对程序员的评价要三思而后行，本着合作的精神，作出合理的判断。重现的分析和方法本节重点是报告编码错误，而非报告设计问题。一、重现的分析“可重现”隐含了下列定义：我们能够描述如何让程序进入某个已知的状态。任何熟悉程序的人都能够依照我们的描述使程序进入该状态。从那个状态出发，我们确定出精确的一组步骤来暴露出问题。为使报告更有效，我们应该对问题进一步分析，目的在于：1）找出问题最严重的后果。找出某个导致的最严重的后果，这样可以激发人们改正它的兴趣。一个看来很轻微的问题往往更有可能被暂缓处理。例如：假设有个在屏幕角落显示了一个无用的字符，这个问题很轻微，但是是可以报告的。有些时候，屏幕上显示出无用信息只是一个孤立的问题（因此对它置之不理的决定可能是明智的，尤其是程序快要交付的时候）。但是如果继续运行这个程序，可能会出现一旦显示无用信息之后，程序几乎会马上崩溃最严重的后果。2）找出最简单、最直接和最常见的触发条件。如果理解和改正问题仅需要很小的工作量，那么就会修复它。如果问题的解决需要（或看起来需要）很长的时间和精力，程序员会不太情愿改正它。如果问题会在程序日常使用的过程中发生，管理层对问题的关注会增加。如果问题的出现几乎无人知晓，关注程度会很低。3）找出产生相同问题的其他路径。有时不止一种方法可以触发一个错误，若有两条不同的路径通往同一个，比起仅有一条路径来势更有力的危险信号。即使每条路径都包含着很复杂的步骤序列，存在两条路径也意味着代码中含有严重的错误。要充分展示各条路径的差异，不能让程序员把多条路径视为对同一个的相似描述。4）找出相关的问题。根据积累的经验，仿照以前发现的方法，查找程序中其他可能的位置，能有相当的机会在新的代码中找出类似的问题。二、可重现的分析技术1）寻找最关键的步骤根据查找代码中的错误，不要忽略任何细微的有关错误的线索。应该查找下列的问题：1.错误信息；2.处理延时；3.屏幕闪烁；4.光标跳跃；5.文本错误；6.工作指示灯在设备未使用时亮起。2）最大程度地提高程序运行的可见性将程序运行的越多方面变的可见，就越能看到更多的出错情况，也就越有可能明确关键的步骤。用调试工具可以报告出当前活动的进程、程序占用的内存或其他资源的数量、正在使用的堆栈的数量以及其他的内部信息。1.监测堆栈中的遗留数据的多少2.监侧进程的收发消息，内存的占用情况。另一条途径是将屏幕显示的所有内容和磁盘文件的所有变更统统都打印出来，然后进行分析。3）多尝试一些结果将程序的事件进行组合的执行。4）查找后续错误一旦发现了某个错误，也应该再坚持运行程序一段时间，看看是否会有其他的错误出现。我们要认真细致地做这件事，最初出现的问题可能会诱发一系列后续问题。5）渐进地省略或改变步骤问题复杂的时候可以跳过一些步骤，但对每个要省略的步骤进行测试，看看它是否是重现的必要环节。至于改变步骤，可以在每个步骤中查找是否存在边界条件，对边界条件的敏感程度，是一个测试人员技术成熟与否的标志之一。6）在程序以前的版本中查找错误7）查找配置依赖三、让可重现如何触发?将我们记得的有关第一次操作的所有事情都记下来，进行一步一步的问题回溯。倘若没有效果，可能是没有满足确切的条件，没有显现出来。下面列举了几种应该考虑到的情况:1）竞争条件2）被遗忘的细节3）造成的影响会导致其无法重现4）是依赖于内存的5）仅会在初次运行时出现的6）因数据错误导致的7）由于一些其他问题附带引起的8）间断性硬件故障9）依赖于时间10）依赖与资源11）由长期积累形成管理流程对的跟踪管理是测试工作的一个重要部分，测试的目的是为了尽早发现软件系统中的缺陷，因此，对进行跟踪管理，确保每个被发现的缺陷都能及时得到处理。管理流程是一套复杂的处理过程，涉及到测试员（复审员）、项目数据库管理员、实施员（设计员）三方的交互，图-4所示的管理流转图详细描述了三方关联关系（同样适合正式技术复审问题处理流程）。图-4管理流转图跟踪管理的起始动作是测试员（复审员）选择一个测试用例开始测试，当测试员（复审员）发现程序实际输出值和程序期望值不符的时候，他就发现了一个，并执行流程第二个动作“填写测试的实际结果”。当测试员（复审员）向跟踪管理系统递交该时，系统将该保存至“项目数据库”中，并且同步发送一个消息至“”（可以是一个程序），由它向该的最终负责者实施员（设计员）发送一份“”。实施员（设计员）会及时接受到这样的报告，并且根据报告中包含的唯一序号向“项目数据库”查询该的详细信息。当实施员（设计员）对跟踪的修复动作完成后，就会在“项目数据库”中将该的状态转换为“”，跟踪管理系统接收到这样的“”动作，就会自动向的测试员（复审员）发送已经修复的消息，测试员（复审员）对进行确认测试，如果该正确修复则关闭它，如果该依然存在问题，整个动作回复到跟踪管理的起始处。1、如何提交系统中的不要在同一封邮件或者同一个错误输入框中报告多个（尤其在不同软件包之中的）错误。2、使用自动报告工具使用成熟的管理工具实现全程管理，可以有效避免被大量的测试数据所淹没而引发一系列问题。有如下一些优点：①管理工具安装简单、运行方便、管理安全。②管理工具有利于的清楚传递，由于使用了后台数据库进行管理，提供全面详尽的报告输入项，可产生标准化的报告。③管理工具提供大量的分析选项和强大的查询匹配能力，能根据各种条件组合进行统计。当在它的生命周期中变化时，开发人员、测试人员、及项目管理人员将及时获得动态的变化信息。④管理人员允许你获取历史记录，并在检查的状态时参考这一记录。⑤管理工具可针对软件产品设定不同的模块，并针对不同的模块设定相关的责任人员，这样可以实现提交报告时自动发给指定的责任人。⑥管理工具支持权限，设定不同的用户对记录的操作权限不同，可有效控制进程管理。⑦管理工具设定不同的严重程度和优先级，从最初的报告到最后的解决，确保了错误不会被忽略，同时可以使注意力集中在优先级和严重程度高的错误上。⑧管理工具自动发送邮件通知相关责任人员，并且根据设定的不同责任人，自动发送最新的动态信息，有效地帮助测试人员和开发人员进行沟通。3、通过电子邮件发送报告描述主题是要清楚而简洁地描述。邮件内容第一行的格式为：:<>,<>指要报告的包含错误的包名称。邮件内容的第二行格式为：:<>，<>指该软件包的版本。其他内容应该注意以下几点：①确切而完整的错误信息（这非常重要）。②您做了或输入了些什么，以便重现该问题。③错误行为的描述：您预期应该有什么样的行为，而您看到的是如何。④您建议如何改正，或甚至您自己做的修补程序。⑤详细解释您如何设置该程序，包含完整的设置文件属性。⑥任何其他依赖于这个问题软件包的软件包版本。4、详细内容信息如表-1所示。5、轻微的报告轻微的报告应该和重要的报告分开发送。描述信息类别可追踪标志基本描述所属项目\子系统\模块所属的项目\子系统\模块，最好能较精确的定位至模块标题简明描述流转状态流转状态，可分为、、、、、、、、、严重等级严重等级,可分为、、、、、、、解决关键字解决关键字,可分为、、、、、、、、提交人提交人的名字(邮件地址)提交时间提交的时间，例如2003-1-2314：00表-1详细内容描述(1)过程描述指定解决人由测试人员确定，如果该的流转状态从变为指定解决时间由测试人员确定，如果该超过指定修复时间而未修复，则系统自动发送报警邮件。处理描述如果实现人员对代码进行了修改，要求在此处体现出修改内容，如果代码行数很多则缩略书写处理时间记录处理时间确认测试人员验证该被正确的修复了确认描述确认修复内容确认时间确认修复时间详细描述对的详细描述，对描述的详细程度直接影响实现人员对该的修复效果，描述应该尽可能详细环境说明对测试环境的描述，避免实现人员和测试人员环境的不同造成异议附带附件附件包括对现场出错快照(图片)，错误输出文件信息等，加强该的表现力表-1详细内容描述(2)6、不知道归属的设置默认的修复人员，防止意外的丢失了负责人的信息。7、关闭报告提出的被修正后，通过测试人员确认、测试通过才可以关闭。的提出和关闭都是只能由测试人员执行。将所有不能被修复的收集起来标记为“”，统一递交给代码评审委员会。8、接续的讨论信息的管理系统的流转过程中，会有针对该的新的描述信息加入，例如实现人员或者测试人员加上的对处理自己的理解和曾经使用过的解决方案等。对于新的描述信息，请遵循以下规则：①新的描述信息和旧的描述信息之间应该增加醒目的隔离条。②新的信息描述应该包括提供者的名称和电子邮件地址。③新的描述信息应该包括信息的新增时间。

④新的描述信息如果是建议修改意见，应该在该信息的开头加上关键字“建议解决方案”。⑤新的描述信息如果是某些疑问，应该在该信息的开头加上关键字“疑问”。