计算器软件缺陷定义的5个方面

软件缺陷定义的5个方面如下：

缺陷属性1、缺陷标识（dentifier)：缺陷标识是标记某个缺陷的一组符号。每个缺陷必须有一个唯一的标识。

2、缺陷类型（Type)：缺陷类型是根据缺陷的自然属性划分的缺陷种类。

3、缺陷严重程度（Severity)：缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。

4、缺陷优先级（Priority）：缺陷的优先级指缺陷必须被修复的紧急程度。

5、缺陷状态（Status)：缺陷状态指缺陷通过一个跟踪修复过程的进展情况。

你好：

1) 通用UI要统一、准确

缺陷报告的UI要与测试的软件UI保持一致，便于查找定位。

2) 尽量使用业界惯用的表达术语和表达方法

使用业界惯用的表达术语和表达方法，保证表达准确，体现专业化。

3) 每条缺陷报告只包括一个缺陷

每条缺陷报告只包括一个缺陷，可以使缺陷修正者迅速定位一个缺陷，集中精力每次只修正一个缺陷。校验者每次只校验一个缺陷是否已经正确修正。

4) 不可重现的缺陷也要报告

首先缺陷报告必须展示重现缺陷的能力。不可重现的缺陷要尽力重现，若尽力之后仍不能重现，仍然要报告此缺陷，但在报告中要注明无法再现，缺陷出现的频率。

5) 明确指明缺陷类型

根据缺陷的现象，总结判断缺陷的类型。例如，即功能缺陷、界面缺陷、数据缺陷，合理化建议这是最常见的缺陷或缺陷类型，其他形式的缺陷或缺陷也从属于其中某种形式。

6) 明确指明缺陷严重等级和优先等级

时刻明确严重等级和优先等级之间的差别。高严重问题可能不值得解决，小装饰性问题可能被当作高优先级。

7) 描述 (Description) ，简洁、准确，完整，揭示缺陷实质，记录缺陷或缺陷出现的位置

描述要准确反映缺陷的本质内容，简短明了。为了便于在软件缺陷管理数据库中寻找制定的测试缺陷，包含缺陷发生时的用户界面（UI）是个良好的习惯。例如记录对话框的标题、菜单、按钮等控件的名称。

8) 短行之间使用自动数字序号，使用相同的字体、字号、行间距

短行之间使用自动数字序号，使用相同的字体、字号、行间距，可以保证各条记录格式一致，做到规范专业。

9) 每一个步骤尽量只记录一个 *** 作

保证简洁、条理井然，容易重复 *** 作步骤。

10) 确认步骤完整，准确，简短

保证快速准确的重复缺陷，“完整”即没有缺漏，“准确”即步骤正确，“简短”即没有多余的步骤。

11) 根据缺陷，可选择是否进行图象捕捉

为了直观的观察缺陷或缺陷现象，通常需要附加缺陷或缺陷出现的界面，以的形式作为附件附着在记录的“附件”部分。为了节省空间，又能真实反映缺陷或缺陷本质，可以捕捉缺陷或缺陷产生时的全屏幕，活动窗口和局部区域。为了迅速定位、修正缺陷或缺陷位置，通常要求附加中文对照图。

 附加必要的特殊文档和个人建议和注解

如果打开某个特殊的文档而产生的缺陷或缺陷，则必须附加该文档，从而可以迅速再现缺陷或缺陷。有时，为了使缺陷或缺陷修正者进一步明确缺陷或缺陷的表现，可以附加个人的修改建议或注解。

12) 检查拼写和语法缺陷

在提交每条缺陷或缺陷之前，检查拼写和语法，确保内容正确，正确的描述缺陷。

13) 尽量使用短语和短句，避免复杂句型句式

软件缺陷管理数据库的目的是便于定位缺陷，因此，要求客观的描述 *** 作步骤，不需要修饰性的词汇和复杂的句型，增强可读性。

以上概括了报告测试缺陷的规范要求，随着软件的测试要求不同，测试者经过长期测试，积累了相应的测试经验，将会逐渐养成良好的专业习惯，不断补充新的规范书写要求。此外，经常阅读、学习其他测试工程师的测试缺陷报告，结合自己以前的测试缺陷报告进行对比和思考，可以不断提高技巧。

14) 缺陷描述内容

缺陷描述的内容可以包含缺陷 *** 作步骤，实际结果和期望结果。 *** 作步骤可以方便开发人员再现缺陷进行修正，有些开发的再现缺陷能力很差，虽然他明白你所指的缺陷，但就是无法再现特别是对系统不熟悉的新加入开发人员，介绍步骤可以方便他们再现。实际结果可以让开发明白错误是什么，期望结果可以让开发了解正确的结果应该是如何。

希望楼主采纳 ，谢谢！

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

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

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

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

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

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