6.3软件缺陷的报告

软件测试缺陷管理软件缺陷的报告赵聚雪理解软件缺陷的属性能够准确判断缺陷的优先级和严重性能够编写规范的缺陷报告2学习目标软件缺陷的属性为了方便引用、理解、解决、测试、回归，跟踪、分析软件缺陷，软件缺陷有很多属性，比如编号ID，解决人，测试人、状态、所属功能模块、严重程度等等。这些属性并不是在缺陷录入的时候就全部指定的，而是随着软件缺陷的流转根据需要不断完善的。一个完整的缺陷报告应该清楚的描述BUG的症状和其他基本信息。不同的团队根据缺陷管理的需要使用的缺陷属性不同。软件缺陷的属性5一个完整的BUG报告应该包含的内容序号属性项是否必须说明1标题是Bug的标题，应该尽量精炼。2关键字否识别这个缺陷的几个关键字，用于搜索、消重等3功能模块是Bug的功能性分类，要结合具体的产品特性来定义,一般按照功能模块划分。比如:安装卸载问题、帮助文档问题、打印问题、功能模块1问题……4缺陷状态是用于缺陷的跟踪，描述缺陷的状态，比如新建、解决待测、测试通过、测试失败、已解决等。5问题复现步骤是复现问题的具体步骤，包括缺陷复现的特殊环境6期望结果是操作的正确结果（期望结果）7实际结果是操作的实际结果8附件否附加的文件、图片和录制的可播放文件9版本号是发现bug时的产品版本号(大部分产品都是不断升级维护的，而且是不同版本使用同一个bug库)10优先级是问题解决的优先级,处理和修正软件缺陷的先后顺序的指标11严重性是问题的严重性12分类否Bug的特征分类，可以根据团队需要特别关注的类别划分，比如效率问题、死机问题、易用性问题、兼容性问题等。13客户信息否列出反馈该问题的一个或多个客户的相关信息，方便对客户进行支持14报告人是报告缺陷的人员，一般缺陷系统自动根据账号生成15报告时间是报告提交的时间，一般系统自动生成软件缺陷属性以上所列属性主要是缺陷录入时的属性随着对缺陷的处理会有更多的属性，比如解决人、解决方案、解决时间等等更多属性缺陷的优先级和严重性优先级和严重性是缺陷的两个重要字段对后续缺陷的解决以及缺陷分析都有重要的意义，在报告缺陷的时候要给出正确的选项。严重性和优先级优先级是问题解决的优先级，处理和修正软件缺陷的先后顺序的指标严重性是问题的严重性优先级是处理和修正软件缺陷的先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。缺陷的优先级

软件缺陷优先级的四级划分级别描述1—最高优先级主要指软件的核心功能错误或者造成软件崩溃，数据丢失的缺陷2—较高优先级影响软件功能和性能的一般缺陷3—中等优先级对客户影响不大的缺陷4—低优先级对软件的质量影响非常轻微或出现几率很低的缺陷；理论上来说，确定软件缺陷优先级，更多的是站在软件开发工程师的角度考虑问题，因为缺陷的修复是个复杂的过程，有些不是纯粹技术问题，而且开发人员更熟悉软件代码，能够比测试工程师更清楚修复缺陷的难度和风险。但是实际上，企业在确定缺陷优先级并不只站在开发工程师角度，而是对解决的难度、缺陷对产品销售的影响、客户的重要性等方面综合考虑确定的。软件缺陷的优先级严重性(Severity)是软件缺陷对软件质量的破坏程度，即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。在软件测试中，软件缺陷的严重性的判断应该从软件最终用户的观点做出判断，即判断缺陷的严重性要为用户考虑，考虑缺陷对用户造成的后果的严重性。软件缺陷的严重性13软件缺陷严重性的一般划分级别描述轻微(Trivial)软件产品的小缺陷，比如词语拼写错误、控件没有对齐、控件相互遮挡等，不影响用户完成工作。中等(Medium)重要但是不会导致用户不能完成功能，可以绕过或影响效率。重要(Major)核心功能缺失或不能正常工作，导致客户无法完成工作严重(Critical)导致死机、无反应、数据丢失、严重的内存泄漏等问题。感觉很相似严重性和优先级的关系？都从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程度和处理方式一般来说，严重性高的软件缺陷具有较高的优先级严重性和优先级并不总是一一对应严重性和优先级的关系含义不同联系密切一般来说，严重性高的软件缺陷具有较高的优先级有时候严重性高的软件缺陷，优先级不一定高，甚至不需要处理，比如：一个很少人使用的产品边缘功能有问题，但是解决起来成本又很高，可能优先级就会低一些严重性低的缺陷却需要及时处理，具有较高的优先级：比如一个关键客户提出的不严重的缺陷，为了业务成交，可能优先级很高严重性和优先级并不总是对应缺陷报告的模板团队在开展测试工作时会根据团队管理和产品的实际需要定义缺陷的字段，少则六七个字段，多则可达十几二十个。缺陷报告模板缺陷报告模板-Excel注意一般缺陷管理工具中，由于每个产品的功能模块不同，可以自行配置“功能模块”字段。ALM缺陷报告提交模板如何撰写一个好的缺陷报告为什么给我讲这个？问题Areyoueverhadabugreturnedtoyouformoreinformation?作为一名测试工程师，我们经常遇到的问题是：经常有人来询问你关于你曾经提交的缺陷，随着你提交的缺陷增多，询问量增加，而且这会严重影响你目前的工作进度。需要关注缺陷报告的质量问题不能提炼出缺陷的本质内容不是你看到的直接现象，根据需求找到缺陷的本质不能准确的描述缺陷标题精炼、内容清晰、只包含所有必要信息提交缺陷报告的两个问题需求缺陷现象：设计了一个测试用例，遥控器设置温度为31，空调显示温度为31.举例：提炼缺陷的本质内容学生提交的缺陷标题如图相对来说IP为13的同学标题比较好存在的问题：Ip=8的同学：没有找到缺陷本质，是不是还可以提交一个“温度为32时显示错误”的缺陷呢？Ip=9的同学：两边都没有截断吗？Ip=17的同学：你的标题更适合作为用例的标题Ip=41的同学：根据需求用术语“截断”举例：提炼缺陷的本质内容(cont.)明确缺陷的阅读者缺陷解决者缺陷决策者缺陷测试者缺陷统计分析者查找用户手册\帮助文档等确定你的问题是不是已经有说明用最新产品版本确认bug是否已经解决检查bug库中是否已经存在这个问题报告提交之前，注意消除重复注意消除重复Correct（准确）-每个组成部分的描述准确，不会引起误解Clear（清晰）-每个组成部分的描述清晰，易于理解Concise（简洁）-只包含必不可少的信息,不包括任何多余的内容Complete（完整）-包含复现该缺陷的完整步骤和其他本质信息Consistent（一致）-按照一致的格式书写全部缺陷报告缺陷报告的5个准则用词贴切，语法正确拼写无误使用规范术语(规范的术语参考需求、产品说明书等)一个问题一个报告基本要求基本信息通常比较固定，也很容易描述如果团队有Bug规范最好细细研读容易出现问题的是：标题复现步骤实际结果和期望结果一个完整的Bug报告标题的提炼-简炼、精确、表达重点使用陈述句，避免疑问句\感叹句\“名词”句为bug选一个好标题4425-bedit:动态块功能

5310-打印纸张纵-横向问题5848-Plot:打印慢4762-字体问题5223-打印-软件自动退出为bug选一个好标题显然这些都不是好的标题，看了这些标题有很多的疑问具体是什么问题？不显示？乱码？少显示？多显示？颜色不对？引用的字体样式存在吗？建议：在字体样式存在的情况下文字显示乱码事实描述：因为网络故障，客户端与网络服务套件断开后，保存图纸，从“文件”菜单退出软件，软件死机。如果没有保存图纸直接从文件退出则不会死机。同一个问题，不同技术人员提交的缺陷标题：1.客户端掉授权后，退出软件时死机2.客户端掉授权后，保存图纸再通过“文件”菜单退出软件，软件死机(相对比较好)3.软件死机(太笼统)4.客户端掉授权后的问题(太笼统)5.客户端掉授权后软件死机6.客户端掉授权后，软件应该能关闭7.客户端掉授权后，软件起码不应该死机(不要表达感情)8.客户端掉授权后软件死机，可能是因为掉授权后的保存模块有问题9.客户端掉授权后，竟然死机(不要表达感情)企业案例：为Bug选一个好标题开发人员心理活动：你觉得我水平很差吗？你根本不懂，这个用到的技术很复杂写清楚bug的主体部分和结果说明特殊环境说明复现步骤实际结果期望结果(正确结果)其它信息Bug主体部分撰写-清晰、必要善于利用图片、视频对问题进行辅助描述一些不易描述的缺陷可以借助图片、视频进行描述为了方便对比，可以将正确结果的图片和错误结果的图片放在一起对比比如你测试产品中阿拉伯文字显示的正确性，由于我们自己不理解阿拉伯文字应该显示成怎样，我们就可以与word做对比，如果与word显示不同认为是缺陷，将产品中的显示与word中的显示分别截图提交到缺陷中展示给开发人员。视频文件比较大，播放比较慢，不是特别不易说明的缺陷，建议不要过多使用视频利用图片、视频进行辅助描述尽量使用简短的陈述句。一些“不要”：只说症状，不说猜想（或者明确将二者隔开）不要用疑问句和质问句不要用冗长难懂的句子Bug主体部分撰写-清晰、必要缺陷主体描述举例描述一：1.启动客户端应用程序2.新建图纸，任意画一个对象3.修改任意对象的颜色，但是不要保存4.关闭网络链接5.保存刚才编辑的图纸6.软件提示“保存错误！”7.退出应用程序，软件死机描述二：

(太粗略)关闭网络链接，保存，死机描述三：(有非必要步骤)1.启动客户端应用程序