Question

软件测试——缺陷报告

Answer 1

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

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

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

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

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

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