摘要：软件测试的测试工具的特点是什么？ 1 描述 （Desciption），简洁、准确，完整，揭示错误实质，记录缺陷或错误出现的位置 描述要准确反映错误的本质内容，简短明了。为了便于在软件错误管理数据库中...

软件测试的测试工具的特点是什么？

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

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

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

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

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

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

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

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

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

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

软件测试工具都有些什么特点呢？

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

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

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

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

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

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

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

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

软件测试过程中有哪些风险

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

软件测试 缺陷报告都要包括什么内容

怎么感觉混淆了发现率和复现率的区别？如果从字面上理解发现，应当是缺陷的各个分布。

例如，缺陷的模块分布，测试人员分布，开发人员分布，时间分布，阶段分布，用例与随机测试分布，千行代码缺陷率等等。

这些分布有助于评估产品质量和测试过程质量。

例如，依据缺陷的开发人员分布，千行代码缺陷率和开发任务的技术复杂度，可以评估出开发人员开发出的代码质量。

从时间分布可以评估指导当前测试策略调整，是否执行退出；从阶段分布可以看出缺陷遗漏率；从用例和随机测试分布可以看出用例编写质量等等。

...

在软件测试中,什么是重现缺陷,再现缺陷,优化缺陷？

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

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

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

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

这个就是重现。

优化缺陷是指。

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

尽量不要有多余的操作。

这个叫优化。

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

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