13.2.9 软件缺陷
缺陷也叫BUG，是一个计算机程序中的错误，现已将其延伸为漏洞。在软件测试中定义的比较宽泛，包含更多层面内容，例如不符合需求规定、与用户行为习惯相反等可以改善的要求都称为缺陷。缺陷在提交时，有效且描述清晰简单，可以迅速帮助开发人员进行缺陷定位、错误重现。如果描述得模糊，则可能导致开发人员需要花费很长时间去理解此缺陷的本意，不利于工作的开展。这也是面试官喜欢提问缺陷的一个原因。
示例1：缺陷报告包括哪些内容？
此题考察面试者对缺陷报告内容的掌握，虽然不同的公司对缺陷报告的内容有些差异，但重要的一些点是相同的。面试者只要答出重要内容即可。
解答：提交者（缺陷报告发起者）、被测系统的版本号、测试环境、缺陷编号（一般由缺陷管理工具自动生成）、缺陷标题、缺陷等级、产生的模块（产生的模块中也可以添加影响的模块）、缺陷描述（问题描述和复现的操作步骤）、预期结果、实际结果、附件（如果需要则添加附件，包括错误页面截图、错误日志）等。
示例2：请简述缺陷的生命周期。
对于能用流程图表示的尽量画出流程图，有助于在分步说明时捋顺思路，也可以使面试官了解到自己的思维清晰、逻辑严密。
解答：测试工程师在执行测试时发现一个缺陷则新建缺陷报告，此时是新建状态；缺陷提交后由测试组负责人将其修改为打开状态，提交开发人员进行修改；开发人员拿到缺陷后进行确认，如果不是缺陷则将缺陷打回，如果是缺陷则进行下一步修改；开发人员将缺陷修改完成后，状态修改为已修复；测试人员在下一版本对已经修复的缺陷进行回归验证，如果回归验证不通过则将缺陷重新打开，如果缺陷回归测试通过则关闭缺陷，该缺陷的生命周期结束。详细流程图如图13-4所示。
图13-4 缺陷测试流程图
示例3：缺陷等级分为哪些？举例说明。
解答：缺陷的等级是根据缺陷对系统造成的影响进行划分的，可分为致命、严重、一般和建议。致命级别缺陷指的是影响程序基本流程运行的错误，例如程序主要功能错误、程序或服务器崩溃、数据丢失的缺陷；严重级别缺陷指的是功能实现错误或内部计算错误，例如影响程序功能和性能的一些缺陷；一般级别缺陷指的是操作界面错误、格式错误、删除操作未做提示等，例如程序在删除数据时未给出提示；建议级别缺陷指界面不规范，说明文言不清晰，帮助文档含有错别字等，例如某些文言描述不准确、对程序质量影响非常轻微的缺陷。
示例4：测试过程中遇到很难重现的BUG怎么办？
解答：只要是BUG，就提交问题单，做出记录。然后尽可能从环境、操作步骤、数据等方面查找引起的原因，或者与开发进行交流，考虑哪些方面会引起。也可以进行版本回退，尝试查找原因。如果最终还是无法重现，可以暂时将此BUG进行保留，再跟踪几个版本，如果还是无法重现，那么可以将BUG进行结束处理。
示例5：发现的缺陷越多，说明软件缺陷越多吗？
解答：不一定，缺陷多一般有以下两种情况。
软件缺陷存在群集现象，一般系统里面重要和主要的业务模块发现问题会多，这属于正常现象，并且80%的缺陷集中在这些主要模块中。
以功能测试为例，软件进入正式测试阶段，在测试初期随着测试模块和用例覆盖面逐渐增加，发现缺陷的数量会越来越多，缺陷曲线图呈现波峰状态；测试中后期随着缺陷修复和测试用例数的减少，发现缺陷数量慢慢减少，缺陷曲线图开始呈现下降趋势。
所以，发现的缺陷越多，不一定是软件缺陷多，可能只是某一个模块缺陷多或某一个阶段缺陷多，具体情况还需要具体分析才可以得出最终结论。
示例6：程序中发现的所有缺陷都能修复吗？都必须修复吗？
理论上来说都是能够修复的，但是在现实中软件需要投入使用，产生相应的价值，如果对一些不重要的缺陷花费大量的时间来修复是不值得的，越早将软件投入使用也就意味着越早产生价值，为企业带来利益。
解答：从技术上讲，软件中所有的缺陷都是能够修复的，但是没有必要全部修复。作为测试人员，不仅要对软件质量进行把控，也要考虑投入与产出比。在产品研发中，对于缺陷要做一个正确的判断，根据风险、价值、时间等因素决定是否需要修复。通常来说，出现以下情况会对某些缺陷不进行修复或者在下一个版本进行修复：
时间紧张、人力资源不足。在接近发布之前，开发人员和测试人员紧张，此时对某些不重要的或边沿缺陷不进行修复。因为修复完成后没有足够的人力进行回归测试，也有可能引入新的缺陷，因此可以将这些缺陷放在下个版本进行修复。
特殊情况下出现的缺陷。这些缺陷用户不会使用到，也处于商业利益的考虑，在以后版本中如果可以再考虑修复。
偶现的，倒退版本也不能重现的缺陷。这样的缺陷很难再次重现，所以找到它发生的原因是特别困难的，考虑到成本问题，所以暂时不做处理，在以后的使用中如果再次发生再进行修复。
总的来说，缺陷是否修复需要开发人员、测试人员、产品经理等相关人员共同讨论决定，以便作出正确的、最有利的决定。
示例7：软件问题可以分几类？
解答：软件问题可以分为软件错误、软件缺陷、软件故障、软件失效。
软件错误：在软件生存周期内不希望或不可接受的人为错误。
软件缺陷：存在于软件（文件、程序、数据）之中的不希望或不可接受的偏差。
软件故障：软件运行过程中出现的一种不希望或不可接受的内部状态。
软件失效：软件运行时产生的一种不希望或不可接受的外部行为。
示例8：如果想进行BUG的测评，怎么去评测？
解答：BUG的priority()和severity()是两个重要属性，通常人员在提交BUG的时候只定义severity，而将priority交给leader定义。通常BUG管理中，severity分为四个等级（blocker、critical、major、minor/trivial），而priority分为五个等级（immediate、urgent、high、normal、low）。
Serverity（严重程度）
①blocker（崩溃）：阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失、与数据库连接错误、主要功能丧失、基本模块缺失等问题。例如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等。
②critical（严重）：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。例如：软件中数据保存后数据库中显示错误、用户所要求的功能缺失、程序接口错误、数值计算统计错误等。
③major（一般、界面、性能缺陷、兼容性）：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统的稳定性。例如：操作时间长、查询时间长、格式错误、边界条件错误、删除没有确认框、数据库表中字段过多等。
④minor/trivial（次要、易用性及建议性问题）：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。例如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等。
Priority（优先级）
① immediate：表示问题必须马上解决，否则系统根本无法达到预定的需求。
② urgent：表示问题的修复很紧要，很急迫，关系到系统的主要功能模块能否正常。
③ high：表示有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实现。
④ normal：进入个人计划解决，表示问题不影响需求的实现，但是影响其他使用方面，比如页面调用出错。
⑤ low：问题在系统发布以前必须确认解决或确认可以不予解决。
版权声明：51Testing软件测试网获得作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
