软件测试——缺陷报告

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

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

         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、是不是所有已发现的缺陷，在发布时都会被修复？

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

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

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

软件缺陷和故障通常被称为缺陷。软件缺陷是计算机软件或程序中破坏其正常运行能力的问题、错误或隐藏的功能缺陷。

缺陷的存在会在一定程度上导致软件产品无法满足用户的需求。例如，一个登录界面，没有密衫戚码验证直接输入，这就是一个大bug。

软件测试是在软件投入运行之前，对软件需求分析、设计说明和编码实现的最终评审。它是软件质量保证的关键环节。软件测试通常有两种定义：

定义1：软件测试是执行程序以发现错误的过程。

定义2：软件测试是一个精心设计的一组测试用例基于规格说明和程序的内部结构在每个阶段的软件开发，和使用这些测试用例运行程序的过程和发现错误，执行升羡测试步骤。

基本问题解决：

1、测试是为了找出程序中的错误而执行程序的过程。

2、一个好的测试计划是最有可能发现到目前为止还没有发现的错误的计划。

3、成功的测试是能够发现到目前为止还没有发现的错误。

扩展资料：

软件测试的原则：

在对计算机软件进行测试之吵塌拍前，首先要遵循软件测试原则，即不完全原则。不完全原则是指如果测试不完整，且在测试过程中涉及豁免原则的部分较多，则对软件测试有帮助。

因为软件测试等因素有一定程度的免疫力，测试人员能做的测试及其免疫正比于内容，如果你想使软件测试更加流畅，测试结果是更有效的。

需要遵循这一原则，这些原则在整个开发过程中，不断的测试，而不是一次性的测试。

缺陷管理流程图

在 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）对当前功能点的影响

---