软件测试——缺陷报告

软件测试——缺陷报告

         测试人员发现缺陷——>记录缺陷，并将缺陷告知开发人员

         缺陷报告是测试人员和开发人员沟通的重要渠道

         1、缺陷编号（defect id）

         2、缺陷标题（summary）

         3、缺陷的发现者（detected by）

         4、发现缺陷的日期（detected on date）

         5、发现缺陷的功能模块（subject）

         6、指派给（assigned to）

         7、发现缺陷的版本（detected in release）

              （1）说明：不仅指最后的发布版本，也指软件开发过程中出现的“临时版本”

              （2）回归测试：在新版本中对原来版本测试过的内容再重新测试一遍

                        原因：1、新功能对原有功能可能有影响

                                   2、缺陷修改后也有可能对原有功能产生影响

                        为了提高回归测试的效率，很多企业使用自动化工具做回归测试

         8、缺陷的状态（status）最常见的考试题**

              （1）说明：指明缺陷当前所需什么处理和缺陷当前处于什么处理状况

              （2）缺陷的处理过程：重点

                      步骤1：测试人员将缺陷报告提交给开发经理，

                                   将缺陷报告状态设置成：New（新的缺陷）

                      步骤2：开发经理验证缺陷：

                                   情况1：如果验证是缺陷，将缺陷指派给相应的开发人员，

                                               并将缺陷状态设置成open

                                                open：（打开的缺陷，被开发方承认的缺陷）

                                   情况2：如果验证不是缺陷，开发经理会拒绝此缺陷，将缺陷

                                                状态设置成：rejected。（一般要汇报给测试组长或

                                                测试经理，有时会邀请开发人员参加，开讨论会解决）

                     步骤3：开发人员要修改缺陷，修改完成后，将缺陷状态设置成：fixed

                                  fixed:（修改过的缺陷，即待返测的缺陷）

                     步骤4：测试人员返测开发人员更改过的缺陷

                                情况1：返测通过，将缺陷状态设置成：closed

                                             closed:（关闭的缺陷，可归档）

                                 情况2：返测没通过，将缺陷状态设置成：reopen

                                              reopen:（重新打开的缺陷）

                                              开发人员继续修改缺陷直到缺陷被返测成功为止。

         9、缺陷的严重程度（severity） 【说明缺陷有多糟糕或者对软件的影响有多大】

               严重程度的级别：

                     （1）urgent：造成死机，系统崩溃等致命问题

                     （2）very high：非常严重的问题

                     （3）high：严重的问题

                     （4）medium：中等程度的问题

                     （5）low：小问题

               发现问题：级别定义是泛泛的笼统的，容易引发争议，需要制定详细的标准

               注意：每个级别的含义，不同企业、不同项目组都可能不同，需要在专门的

                          文档中定义好细则，在缺陷报告中作为参考。

         10、缺陷的优先级（priority）

                希望程序员在什么时间内或者在程序的哪个版本中解决该缺陷（Bug）

                优先级的级别：

                      （1）urgent：立即修改，否则会影响开发或测试的进度

                      （2）very high：本版本中解决

                      （3）high： 下一版本中解决

                      （4）medium：发布之前解决

                      （5）low：尽量在发布之前解决

                 注意：对于每个级别的具体定义，不同公司不一定完全相同，

                            实际工作中要注意参考公司的文档。

                 影响优先级的因素：

                       （1）考虑缺陷的严重程度：一般是越严重，优先级别越高

                             （也不是绝对的，有时严重级别低，但优先级高，例如：界面错字）

                       （2）缺陷影响的范围：一般影响范围越大，优先级越高

                       （3）开发组的任务压力：进度压力越小，优先级越高

                       （4）解决缺陷的成本(时间)：成本越低，优先级越高 （例如:改错字）

         11、缺陷的描述（description）

                 描述缺陷产生的操作过程，使程序员能重现缺陷。（缺陷报告不是必须

                 要遵守什么写法和规则，只要程序员能看明白能重现缺陷就可以）

         1、缺陷报告的用途

             （1）记录缺陷（2）跟踪管理缺陷

             （3）可以对缺陷进行分类，并很容易实现对缺陷的总结，统计

         2、怎样识别缺陷？

             （1）参考测试用例的预期结果，如果实际执行结果与预期结果不一致就是缺陷

             （2）参考需求文档-----与需求不符就是bug

             （3）参考缺陷定义的五条

             （4）与开发人员、产品人员、客户沟通确定是否是缺陷

        3、写缺陷报告的注意事项

            （1）一个报告只提交一个缺陷

            （2）缺陷描述清晰、准确、易读，使用最少、必须的步骤，保证缺陷可以再现

            （3）对缺陷的严重性、优先级的划分准确、客观

            （4）在提交缺陷报告之前一定要认真审核，确保提交的缺陷是有效的，

                     而不是因为自己的疏忽或操作不正确早成的“假缺陷”

            （5）不要为了引起开发人员的重视而夸大缺陷

            （6）小的缺陷也要报告

            （7）及时报告缺陷

            （8）对于不可重现的缺陷也要报告

            （9）不做任何评价

         1、什么是随机缺陷：

              不可重现的缺陷也叫随机缺陷，按照指定的步骤执行时有时无。

              随机缺陷在提交时要明确说明这是不可重现的随机缺陷。

              尽量提供关于此缺陷的信息，包括提供截图、错误消息、还有缺陷所在模块

              如果确定不了所在模块，可以建议采用白盒测试确定。

         2、缺陷的严重程度和优先级是不是严格的正比关系？
               答：不一定严格成正比关系。

                       例如：界面错别字，严重级别低，但优先级别高

         3、缺陷的严重程度和优先级确定之后，还可以改吗？

                答：严重程度一般不改；优先级有时会改，一般是拖延处理

         4、是不是所有已发现的缺陷，在发布时都会被修复？

               答：在软件发布之前，不是所有已经发现的缺陷都被修复了；对于

                      不予修复的缺陷，要通过全组的缺陷讨论，权衡解决缺陷的

                      成本和不解决的风险。后期一般通过打补丁或升级的方式解决。

北大青鸟java培训：软件测试人员容易遗漏的测试缺陷？

通常软件测试会暴露软件中的缺陷，经过修正后可以保证软件系统的功能满足需求并正确运行。
但是，在系统测试和确认测试中，测试人员容易遗漏一些隐藏的缺陷。
众所周知，软件测试不可能发现所有的缺陷，而软件开发周期各个阶段仍然存在注入缺陷的可能，但是，有一些缺陷是测试中容易忽略的，也就是说，通过测试方法和用例可以充分暴露这些缺陷，遗憾的是，它们往往被忽略或者某种原因忘记测试了，这就给软件留下了隐患或者危机。
电脑培训http://www.kmbdqn.cn/分享容易被忽略的缺陷包括：1、安装缺陷通常项目组完成代码后，发布时候安装打包是最后一个环节，而软件测试人员通常在测试的时候，没有仔细的测试这一部分，而把用例集中在其他功能上。
安装时候的缺陷通常通过拷贝而不是运行安装程序方式给测试人员安装软件，结果正式安装时候出现问题，引起例如控件没有注册，注册表没有导入等。
删除时候没有注意安装文件夹是否存在用户文件，造成数据丢失;使用绝对路径;安装顺序没有说明书。
2、配置文件有些文件在ini等配置文件中写出了管理员口令密码等信息，而且是明文的!这是一个安全隐患。
另外，有些安装文件的XML文件，为了方便在数据库和中间层连接文件中写入了Admin口令和密码。
作为一个合格的软件测试人员，必须检查这些可以用记事本打开的文件。
因为，一个稍有常识而且喜欢探索的用户，可能从中获取信息而成为不自觉的黑客。
所以，配置文件可能成为软件安全方面的一个缺陷。
3、网页安全缺陷现在网站开发已经注意到：登陆网站进入其内部网页后，直接拷贝网址，然后粘贴到另一IE窗口输入，可以绕过登陆直接访问。
也许商业网站很关注这个问题，但是很多行业软件却很容易忽略。
网页安全缺陷还可能存在于IE弹出的子窗口。
有些设计不严格的软件，在主页面关闭的时候子页面还可以运行，这是一个明显的漏洞，而且还大大增加了错误发生的几率。

软件测试行业中常见的问题有哪些？

随着企业对软件测试项目的重视，越来越多的零基础的人也开始加入到软件测试的求职浪潮之中。今天，我们就给大家简单分析了在软件测试行业中需要了解的一些常见问题。

1、测试负责人要进行严格的测试进度跟踪吗?

很多时候，由于人力资源的不足，测试项目负责人都是在执行测试，这样就使整个项目缺乏控制，一些问题(例如：有些成员的缺陷质量不够合格;开发人员修改不及时，系统某些功能发生严重问题导致部分功能无法测试。)得不到解决，耽误了进度。所以测试负责任必须全程监控项目，尽可能多的掌握信息。通常，测试负责人需要完成下面这些内容的管理工作：测试用例执行情况;每个测试员提交的缺陷情况;测试中是否发生突发问题。

2、测试也有版本控制吗?

这里的版本主要是指测试对象的版本控制，也就是指对开发部提交的产品进行版本控制。在开发小组版本管理不规范的情况下，测试小组进行版本控制十分重要，要保证测试对象是可以控制的。建议开发和测试双方进行明确的约定，可以各自指定专门的测试版本负责人，制定提交原则，对提交情况进行详细的记录，这样基本避免了版本失控导致的测试失误或无效。

3、如何处理测试人员的流动问题?

人员流动不仅仅是测试部门，这是IT行业的普遍现象。从管理者角度，主管需要多多和团队内成员进行沟通，建立一个融洽的团队环境，及时掌握情况，可以早些进行相应的调整。但是只有企业建立好的用人制度，给员工提高广阔的发展空间和好的培训学习机会，才能从根本上解决这一问题。加强项目管理，强化文档管理并保证文档的有效性，可以大大减少由于人员流失带来的损失。同时，测试部门要建立培训机制，使新到员工接受直接或者间接的培训，快速适应工作。

4、为什么开发人员经常抱怨测试工程师提交的缺陷质量太差?

我们经常听开发人员说：“这不是缺陷!”，“这个缺陷没有，因为我的系统上运行正常!”。测试工程师本身就是做质量工作的，提交的成果本身就应该质量高些，为什么还会有这种现象?提交的缺陷引起争议是一种正常的现象，例如测试人员描述不清楚就会引起争议。减少甚至避免这种现象的方法是交叉测试，交叉测试是提高测试质量的一个有效手段，当然交叉测试会增加一定的测试成本投入。IT培训发现在测试任务完成后，测试工程师之间互相验证彼此提交的缺陷，就会避免了缺陷描述不清、因运行环境而产生的缺陷等一系列问题，从而大大降低了回归测试以及交流的成本，因而这种投入也是值得的，实际开发人员在单元测试阶段也会进行交叉测试，来提高开发质量。另外，测试人员一定要按照规范描述测试中发现的缺陷，一个缺陷至少描述清楚概要描述、详细描述、重现步骤三方面的内容，缺陷管理参考八章的内容。

软件测试中的累积缺陷趋势？

对于软件测试人员来说，缺陷趋势分析也是能够帮助解决许多潜在的威胁和问题的。今天，IT培训就简单了解一下，累积缺陷的统计以及对策等内容。

一.累积缺陷发现统计

1.1.累积发现缺陷曲线的理想情况:

累积缺陷发现曲线理想情况下遵循凹凸曲线的变化规律。在凹函数和凸函数的拐点处代表缺陷发现已经出现乏力，需要调整测试策略，使得缺陷的发现保持原有的节奏，这个和缺陷发现率的倒浴盆曲线对应(盆地阶段也代表需要不断调整测试策略让缺陷发现率保持在一个持续稳定的水准)。

1.2.累积发现曲线拐点出现的过早：

可能存在的问题：

-测试团队的人员变动，人力减少。

-版本出现阻塞问题，阻碍了缺陷的发现。

-当前的测试策略存在问题，使得测试并不能有效的发现缺陷。

二.缺陷是否收敛

2.1判断缺陷收敛的条件：

累积缺陷发现曲线转变为凸函数

累积缺陷发现曲线与累积缺陷解决曲线越来越靠近，后趋于一点。

2.2缺陷不收敛可能的情况：

2.2.1累积缺陷发现曲线与累积缺陷解决曲线越拉越开：对策:做好代码改动控制

-严格控制代码改动，非必要不改动。

-做好代码静态检查。

-做好代码改动相关的波及分析和自测。

-也有可能是当前测试策略不适合当前的开发阶段

(比如，项目初期测试人员为了缺陷和绩效就做了大量的异常测试)

2.2.2累积缺陷发现曲线还在凹函数阶段累积缺陷解决曲线已经与其靠拢。

对策

-加强测试执行力度。

-如果是因为测试策略导致问题未能有效暴露，及时调整测试策略。

-测试人员测试能力的提升。

bug？软件测试之缺陷管理流程

缺陷管理流程图

在 QC 中，缺陷的管理流程：

流程中的角色： 1、 测试人员：进行测试的人员，缺陷的发起者； 2、 开发人员：执行开发任务的人员，完成实际的设计和编码工作； 3、 评审委员会：对缺陷进行最终确认，在项目成员对缺陷达不成一致意见时，行使仲裁权力。

缺陷的状态 1、 New：缺陷的初始状态； 2、 Open：开发人员开始修改缺陷； 3、 Fixed：开发人员修改缺陷完毕； 4、 Closed：回归测试通过，关闭缺陷； 5、 Reopen：回归测试失败； 6、 postpone：推迟修改； 7、 Rejected：开发人员拒绝缺陷； 8、 Duplicate：已提交的Defect重复； 9、 Abandon：放弃

Bug****严重级别(Severity，Bug级别) ：是指因缺陷引起的故障对软件产品的影响程度，由测试人员指定。

| A-Crash | 造成系统或应用程序崩溃、死机、系统挂起，或造成数据丢失 |
| B-Major | 系统的主要功能部分丧失、数据不能保存，单个功能失效导致多个相关功能均失效 |
| C-Minor | 次要功能没有完全实现但不影响使用 |
| D-Trivial | 使操作者不方便或遇到麻烦，但它不影响功能的操作和执行 |
| E-Nice to Have（建议） | 建设性的意见或建议 |

Bug的严重等级定义：

1）使用频率

2）影响程度

3）出现概率

****Bug的优先级定义：****

1）对其他模块的影响

2）对自身模块的影响

3）对当前功能点的影响

软件缺陷管理

The First “Computer Bug” | 首个“计算机Bug”

1947年9月9日，哈佛大学测试马克II型艾肯中继器计算机，操作员在电板编号为70的中继器触点旁发现了一只飞蛾。然后操作员把飞蛾贴在计算机日志上了，并写下了“首个发现bug的实际案例”。他们提出了一个词，“debug（调试）”了机器，从而引入新术语“debugging a computer program（调试计算机程序）”。

In 1988,the log,with the moth still taped by the entry,was in the Naval Surface Warfare Center Computer Museum at Dahlgren,Virginia.

1988年，这个仍然贴着飞蛾的日志，保存于弗吉尼亚州达尔格伦的海军水面作战中心计算机博物馆。

以下的两句话明确了缺陷的产生。

软件缺陷的产生主要有软件产品的特点和开发过程决定的。比如需求不够清晰，频繁变更等；或者软件由于竞争非常激烈，技术日新月异，使用新技术也容易产生问题。大致有以下几种主要原因：

软件测试就是为了更早、更快的发现缺陷。换句话说，缺陷的发现可以看作是测试工作的主要成果之一。软件缺陷管理的实施，至少有如下三个基本目的：

软件缺陷（Defect），常常又被叫做Bug。所谓软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。

bug 和 defect

飞蛾或者虫子爬进主机引起短路，造成计算机失效的事件中，我们可以看到bug就是虫子或者是虫子引发失效这样的事件。那么defect又是什么呢？

真正的Defect是计算机维护工程师提出来的那个问题：在主机的散热孔那里可以加装一层更加细密的金属网，即不影响散热，又可以防止虫子爬到主机里。这是计算机设计人员疏忽的地方，是产品真正的Defect。而虫子引发的那个故障只是这个Defect导致的故障的其中一种表现形式。也就是说，Bug是Defect的一种表现形式，而一个Defect是可以引起多种Bug的。

软件测试使用各种术语描述软件出现的问题，通用的术语如下：

在可以预见的时期内，软件仍将由人来开发。在整个软件生存期的各个阶段，都贯穿者人的直接或间接的干预。然而，人难免犯错误，这必然给软件留下不良的痕迹。软件错误是指在软件生存期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生。可见，软件错误是一种人为过程，相对于软件本身，是一种外部行为。

软件缺陷是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差，如少一个逗号、多一语句等。其结果是软件运行于某一特定条件时出现软件故障，这时称软件缺陷被激活。

软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态。譬如，软件处于执行一个多余循环过程时，我们说软件出现故障。此时若无时当的措施（容错）加以及时处理，便产生软件失效。显然，软件故障是一种动态行为。

软件失效是指软件运行时产生 的一种不希望或不可接受的外部行为结果。失效是指功能部件执行其规定功能的能力丧失。软件失效是指软件运行时产生的一种不希望或不可接受的外部行为。

软件错误是一种人为错误。一个软件错误必定产生一个或多个软件缺陷。当一个软件缺陷被激活时，便产生一个软件故障；同一个软件缺陷在不同条件下被激活，可能产生不同的软件故障。软件故障如果没有集市的容错措施加以处理，便不可避免地导致软件失效；同一个软件故障在不同条件下可能产生不同的软件失效。

测试执行过程中，发现软件失效后，提出书面的报告，提供给开发人员或者其他负责人员作为定位缺陷的依据，也作为日后缺陷度量的数据依据。

软件缺陷的描述是软件缺陷报告的基础部分，也是测试人员就一个软件问题与开发小组交流的最初并且最好的机会。一个好的描述，需要使用简单、准确、专业的语言来抓住缺陷的本质。否则，它就会使信息含糊不清，可能会误导开发人员。因此，准确的报告软件缺陷是非常重要的。

软件缺陷的属性从大的方面包括以下几部分：

综上所述，一个完整的缺陷报告需要包括以下内容。

| 缺陷的状态 | 描述 |

| ---------------------------- | ----------------------- |

| 激活的或打开的（Active or Open） | 缺陷的起始状态，问题还没有解决，等待修复 |

| 已修正的或已修复的（Fixed or Resolved） | 已被开发人员检查和修复，等待验证人员验证 |

| 关闭的或非激活的（Close or Inactive） | 验证通过，确认缺陷已经可以关闭 |

| 重新打开 （Reopen） | 验证不通过，需要 |

| 推迟 （Deferred） | 缺陷不严重，在下一个版本中解决 |

| 保留 （On hold） | 由于技术原因或者其他原因，暂时无法解决 |

| 功能增强 | 发现的缺陷符合当前说明书。是一个有待改进的问题 |

| 不是缺陷 | |

| 不能重现 | |

| 需要更多信息 | |

| 缺陷的严重级别 | 描述 |

| ------------ | -------------------------------- |

| 致命（Fatal） | 系统的主要功能完全失效，用户利益受到损失、系统崩溃、死机等 |

| 严重（Critical） | 系统的主要功能部分失效，数据无法保存、提供的服务受到影响 |

| 一般（Major） | 系统的次要功能没有完全实现，不影响用户的正常使用，如提示不准确等 |

| 较小（Minor） | 用户体验不好，不影响功能实现 |

| 缺陷的优先级 | 描述 |

| -------- | ----------------------- |

| 立即解决（P1） | 缺陷导致系统不可使用，无法测试或者测试无法继续 |

| 高优先级（P2） | 缺陷严重，影响测试，需要优先考虑 |

| 正常排队（P3） | 缺陷需要正常排队等待修复 |

| 低优先级（P4） | 缺陷可以在开发人员有时间的时候被修正 |

缺陷的严重性和优先级是含义不同但相互联系密切的两个概念。它们都从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程度和处理方式。

一般地，严重性程度高的软件缺陷具有较高的优先级。严重性高说明缺陷对软件造成的质量危害性大，需要优先处理，而严重性低的缺陷可能只是软件不太尽善尽美，可以稍后处理。

但是，严重性和优先级并不总是一一对应。有时候严重性高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重性低的缺陷却需要及时处理，具有较高的优先级。

生命周期的概念是从诞生到消亡所经历的过程。软件缺陷经历了从被发现、报告、到其被修复、验证、直至最后关闭的过程。为了完整的描述这个过程，设定了不同阶段的缺陷状态来体现缺陷不同的生命阶段。对于测试人员来说，需要关注软件缺陷状态的变化，并和开发人员保持良好的沟通，使缺陷能够及时得到处理和修正。

缺陷状态的跟踪

缺陷趋势的分析

缺陷分布分析

累计缺陷趋势分析

单元测试能发现约80%的软件缺陷

单元测试能发现约80%的软件缺陷。请判断这句话的正确与否。是对的。

单元测试（unit testing)：是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义

一般来说，要根据实际情况去判定其具体含义，如c语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。

总的来说，单元就是人为规定的最小的被测功能模块。

单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

这是软件工程长期的历史数据统计和测试经验总结得来的。

当然要发现这80%的缺陷也是要依靠设计出良好的测试用例。

另外顺便提下，软件测试行业有个二八原则，就是软件80%的缺陷存在与20%的代码中。

软件测试中软件缺陷有哪些表现

缺陷表现如下：
软件没有做需求中要求它做的事情；
软件做了需求中要求它不应该做的事情；
软件做了需求中没有提到过的事情；
软件没有做需求中没有提到但是它应该做的事情；
软件难于理解和使用，运行缓慢，或者从软件测试人员的角度来说，软件对于最终用户是明显的不健全（不正确）的。

好了，这就是小编给大家分享的软件测试——缺陷报告全部内容，希望大家看完这篇由小编精心收集的内容后，能解决你的困惑。（本文共13603字）