软件测试中什么是缺陷消除率呢？

这个度量称为缺陷消除率（DRE），其定义为： DRE=测试期间发现的BUG数量（测试期间发现的BUG数量+未发现的BUG数量） 上述公式中，未发现的BUG数量通常等于客户发现的BUG数量（尽管客户也不可能发现所有的BUG）。

所以，分母就是可能发现的BUG数量。

要成功地运用这种度量，还必须清楚许多问题： 必须考虑BUG的严重程度和分布状况。

（有些组织将所有的缺陷同等对待，也即根据各个严重程度等级的比率差不多是恒定的这一原理，不引入严重程度）。

如何才能知道客户什么时候会发现所有的BUG？通常需要观察客户在以前的项目或版本中报告的缺陷的走势，以确定客户发现“绝大多数的”BUG所需要的时间。

如果他们在一年之后还会偶尔发现一个BUG，考试，大提示这个BUG可能并不会对度量造成重大的影响。

在某些应用系统中，特别是拥有较多用户的应用系统中，在几天之内就能报告绝大多数的BUG。

而另外一些拥有较少用户的系统则可能需要花费几个月的时间才能初步确定已经报告了绝大多数的BUG。

软件测试缺陷报告规范有哪些呢？

1. 描述 （Description），简洁、准确，完整，揭示错误实质，记录缺陷或错误出现的位置 描述要准确反映错误的本质内容，简短明了。

为了便于在软件错误管理数据库中寻找制定的测试错误，包含错误发生时的用户界面（UI）是个良好的习惯。

例如记录对话框的标题、菜单、按钮等控件的名称。

2. 明确指明错误类型：布局、翻译、功能、双字节 根据错误的现象，总结判断错误的类型。

例如，即布局错误、翻译错误、功能错误、双字节错误，这是最常见的缺陷或错误类型，其他形式的缺陷或错误也从属于其中某种形式。

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

4. UI要加引号，可以单引号，推荐使用双引号 UI加引号，可以容易区分UI与普通文本，便于分辨、定位缺陷或错误。

5. 每一个步骤尽量只记录一个操作 保证简洁、条理井然，容易重复操作步骤。

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

7. 根据缺陷或错误类型，选择图象捕捉的方式

软件测试容易遗漏哪些隐藏的缺陷呢？

这些容易被忽略的缺陷包括： 1、安装缺陷 通常项目组完成代码后，发布时候安装打包是最后一个环节，而软件测试人员通常在测试的时候，没有仔细的测试这一部分，而把用例集中在其他功能上。

安装时候的缺陷通常通过拷贝而不是运行安装程序方式给测试人员安装软件，结果正式安装时候出现问题，引起例如控件没有注册，注册表没有导入等。

删除时候没有注意安装文件夹是否存在用户文件，造成数据丢失；使用绝对路径；安装顺序没有说明书。

2、配置文件 有些文件在ini等配置文件中写出了管理员口令密码等信息，而且是明文的！这是一个安全隐患。

另外，有些安装文件的 XML 文件，为了方便在数据库和中间层连接文件中写入了Admin 口令和密码。

作为一个合格的软件测试人员，必须检查这些可以用记事本打开的文件。

因为，一个稍有常识而且喜欢探索的用户，可能从中获取信息而成为不自觉的黑客。

所以，配置文件可能成为软件安全方面的一个缺陷。

3、网页安全缺陷 现在网站开发已经注意到：登陆网站进入其内部网页后，直接拷贝网址，然后粘贴到另一IE 窗口输入，可以绕过登陆直接访问。

也许商业网站很关注这个问题，但是很多行业软件却很容易忽略。

网页安全缺陷还可能存在于 IE 弹出的子窗口。

有些设计不严格的软件，在主页面关闭的时候子页面还可以运行，这是一个明显的漏洞，而且还大大增加了错误发生的几率。

4、判断顺序逻辑缺陷 对界面进行多个输入判断的时候，非常容易出现这种问题。

例如判断年月顺序，判断长度，判断非空等。

假如操作员仅仅满足单个条件，保存不能成功；而按界面从上之下顺序一一满足条件之后，保存是没有问题的。

但是，改变一下输入的次序，校验失效。

例如，一一满足条件之后，不保存，倒过来将上面的输入改成非法输入，然后保存，结果居然也能成功，这是因为原先的判断由于发生过，或者根据语句顺序只检查最后一个判断，所以没有报错。

这种错误尤其在 Java scīpt 脚本的页面中要注意。

能够保存不能保证数据正确，有可能引起系统崩溃或者后续数据错误。

所以，在测试的时候，不要按照正常的顺序输入，而是要打乱步骤，看看代码是否强健，是否在判断逻辑上没有错误。

良好的代码应该经得起折腾，至少保存时会再此全部进行判断，而不只是简简单单走到判断的最后一行。

5、调试语句和冗余信息 维护项目和升级改造的推广系统最容易潜伏这类缺陷。

典型表现在没有删除或者屏蔽调试语句。

弹出一个界面不友好的提示信息，会使不明真相的用户产生误以为系统发生了严重故障，从而引起对软件的不信任感。

页面中某个角落存在当前客户不需要的冗余按钮和功能也是一种缺陷。

多余的功能会使用户以为是额外附加部分而去使用，其结果可想而知；而多余的按钮会误导好奇心强的用户操作，产生不必要的错误。

同样值得关注的还有参数设置，由于没有实际数据，开发人员在调试或者单元测试的时候，习惯性的进行自我设定而忘了删除，软件测试人员可能会忽略掉了这部分测试，也可能导致在客户现场发生错误而影响系统发布和验收。

6、不可重现的故障 新参加软件测试的人员或者新来的开发人员总是要问，不可重现的缺陷是否需要记录，有必要吗？回答是肯定的。

测试必须如实的记录发生的问题，也许不能重现，或者使非软件系统本身问题，但是，可能这些偶然性背后是有规律的，不记录这些，就不可能发现这些规律。

7、多节点的逆向流转缺陷 当前软件不少喜欢使用工作流来驱动。

工作流的问题，就是可能出现多个流向分支。

测试容易忽略的部分，就是工作流多节点的逆向流转。

例如，通过不通过涉及两个分支，但是流程逆转的时候，有可能不是回到上一节点而是平级的另一个节点去了。

软件测试要格外注意这类用例的设计。

另外，有些时候默认分支在向前的时候是有默认值的，例如默认通过，那么保存的时候要提示用户是否通过，否则可能由于操作疲劳而走错了节点，引起回退。

8、输入框缺陷 试过往输入框粘贴数据而不是直接输入吗？可能这里会出现问题。

按 Ctl+V 的时候，输入框会根据长度大小自动截断输入长度。

但是用鼠标，截断可能会失效。

有一次测试人员就是用这种方法把一篇 Wod 文档输入进去了，保存的时候，数据库崩溃。

有些网站登陆的口令****可以拷贝下来的，只要放在剪贴板里面马上明文显示。

输入框可以说是问题最多的部分，能够引起的麻烦也很多。

日期、数字、文本等等，都需要耐心的测试一下。

9、界面布局缺陷 曾经有一次，项目经理回来向测试部反映一个问题，客户对界面不满意。

原因很简单，因为界面上删除按钮和保存按钮挨得很近。

结果有些操作不熟练的业务人员，很容易误按。

这个问题是测试人员没有意料到的，因此注意关闭、删除、退出按钮与保存、下一步等按钮的距离。

类似的按钮应按此规则排列分布。

界面布局还可能发生在窗口最大化和最小化上，有可能窗口缩小的时候没有下拉框或不匹配分辨率，对用户来讲，这个错误实在很低级。

有些用户由于操作习惯，非常不喜欢腾出手使用鼠标，尤其是大量输入的界面，因此，要注意设置键盘的快...

软件测试缺陷报告的屏幕截图处理有哪些呢？

图像在传递信息方面的优越性远远大于文字。

因此，在软件缺陷报告中，截取并附上表现缺陷的图像（Sceenshot），可以提供关于软件缺陷的更直观的信息，甚至有些缺陷仅看截取的缺陷图像，不用看缺陷的操作步骤就可以很容易地复现出来。

截取缺陷的图像可以使用Windows操作系统的快捷键，但是更多的是使用屏幕捕捉工具（Captuing Tools）。

虽然截取并附上缺陷图像不太复杂，但是关于截图的类型、工具、编辑、存储格式、命名规则，有不少值得注意的事项，为了准确、有效地截取和编辑缺陷图像，需要测试工程师遵守相同的处理规则。

1. 截图的类型 截取缺陷的图像，通常分为截取全屏幕、当前活动窗口、局部图像三种形式。

实际测试过程中，根据下列两条原则选择合适的类型： * 可以最大程度地表现缺陷的特征 * 尽可能减小图像的大小，以便于传输和查看 最常见的是截取当前活动窗口，例如包含缺陷的对话框。

截取全屏幕用的较少，而且消耗很多的文件存储空间。

2. 截图的工具 如果截图运行在Windows操作系统下的软件缺陷，可以使用Windows操作系统自带的快捷键，但是最经常使用的是利用各种截图工具直接截取。

下面分别较少这两种方法。

2.1 Windows操作系统快捷键截图 截图类型截图快捷键说明全屏幕PintSceen键当前活动窗口ALT + PintSceen键按住Alt键，然后按下PintSceen键局部图像不支持可以先借全屏或活动窗口，然后使用图像编辑软件编辑。

利用Windows操作系统自带的快捷键截取图像后，截取的图像信息存放在系统的剪贴板上，可以使用 Windows系统自带的附件中的“画图”工具，粘贴到“画图”工具中创建的图像中，然后编辑和存储。

这种截图方法，适用于计算机上没有安装任何其他截图工具的场合，缺点是截图后不能直接编辑，而且不支持截取局部图像的类型。

2.2 专用截图工具 截图工具有很多种，截图静态图像最常使用的是HypeSnap，它的优点是支持各种截图类型，而且截图后可以在HypeSnap中直接编辑。

HypeSnap中对各种截图方法设定了默认的快捷键，用户可以定制这些快捷键，现在以默认的截图快捷键为例，说明使用方法。

* 通常截图时不要包含鼠标指针，可以在HypeSnap中选择“Captue” “Captue Settings”菜单进行设置。

* 可以使用左边的操作工具面板设置编辑线条的颜色和粗细 * 可以使用“Edit Text”对话框设置编辑文本的颜色和背景颜色

使用bugzilla缺陷管理工具对软件缺陷跟踪的管理流程是什么

TESTLINK4.bugfree5.Jira书籍有：软件测试的艺术，我觉得这本书不错。

。

.自动化测试：1这些工具都是现在比较流行且容易上手的测试工具有（这个自动化就是尽量减少人工重复劳动的回归测试：QTP.TD3。

。

、RPT……3.web前端分析：yslow、httpwatch缺陷管理工具有（说白了这就是用来记录bug的，程序员与测试员之间通过这个来修复bug）、JMETER……2.性能测试：LOADRUNNER，性能就是找出软件的瓶颈）1.QC2，对新手来说精通自动化测试LOADRUNNER测试还需要懂写脚本语言java c vbs等这些都可以用来写测试脚本的暂时先就说这些...

软件测试中,测试报告和缺陷报告区别在哪？有模板吗？

软件测试报告是一个全面性的报告，而缺陷报告只是软件测试报告中有关缺陷部分的报告。

软件测试是软件开发过程中的一个重要组成部分，是贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程。

而测试报告就是把测试的过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。

测试报告应包括：引言（测试目的、测试背景、参与人员、参考文献等）、测试实施概要（测试的环境、测试用例、范围等）、测试结果以及缺陷分析、测试结论等。

...

使用bugzilla缺陷管理工具对软件缺陷跟踪的管理流程是什么

我本来不想回答，但是避免你被别的答案误导还是说一下。

所谓的重现缺现和再现缺陷基本是一个意思。

当你无意或按照用例发现一个缺陷的时候。

你要把这个中间的步骤记录下来，用于其它人看到了可以依据这个步骤将这个缺陷再演示出来。

这个就是重现。

优化缺陷是指。

将你重现的步骤中，可以展示缺陷的必要步骤写明。

尽量不要有多余的操作。

这个叫优化。

优化的过程中，你需要先猜测看之前的步骤减少哪些，会不会仍然展现刚才的BUG，并加以测试。

尽可能的减少步骤重现缺陷，就叫优化缺陷