软件测试之注意事项

1． 查找bug时的注意事项

（1）软件系统的实现过程就是一组控件实现自己的功能逻辑的过程。我们通过几个常用的web控件，来说明一下我们需要注意的地方。

  文本框（TextBox）

文本框更多的情况下是用来输入信息的。文本框都一样，可是不同地方的文本框需要输入的信息就不会都一样了，比如说，有的是用来输入时间日期的，有的是用来输入文字的。首先我们要结合需求，确定文本框的具体作用，要是用来输入日期时间的，就要注意可以输入几种格式的日期时间，是只读的，还是可进行手动修改的，是否对汉字、特殊符号等做了输入限制（很多时候，录入不匹配的信息，系统会出现错误）。要是用来输入文字的，验证是否对录入的文字长度做了限制（如果超出数据库设置的最大值，会出错）还要注意文本框设置的可视长度，和录入的信息以及页面的整体风格是否和谐。

  标签（label）

标签，基本上不用实现什么逻辑功能，只是起到显示标记的作用。对于标签，我们注意的就是不要出现错别字（当然，任何地方都不能有错别字这样低级的错误），当标签和其它控件联合使用的时候，我们要结合页面的整体风格，确认它的设置是否合适，如label与其他控件之间的距离、标签的字体样式及颜色是否合适等。

  单选按钮（RadioButton）

单选按钮，顾名思义，就是只能选择一个。一般情况下，单选按钮都是以组出现的。如录入性别信息时，有“男”和“女”两个选项，我们要确认只能选择其中的一种，不允许两项都可以选择，而且提交的是选择的信息。

  复选框（CheckBox）

可以这样说，复选框和单选按钮的作用是相对的。使用复选框的地方，一定是要求可以进行多选的，自然就要验证是否实现了多选功能。这里我举这样一个例子：有

A、B、C三个查询条件，是用复选框的形式实现的。当验证完每一个查询条件后，最好再进行组合验证，就是说当只选择A和C或B和C时进行查询。也许有时候bug是由后台查询语句出错导致的，并不是复选框本身的错误。我想说的是不要忘记进行这样的测试验证。

 下拉列表（DropDownList）

下拉列表的作用和单选按钮的功能有些相似，从列表中选择一条自己需要的信息。很多时候，列表的选项中有一条是使用频率最多的，即使用户没有做特殊要求，系统最好把使用频率最多的那一项设置为默认选项，这样可省去用户的一次操作步骤(不仅是这里，要注意整个系统中对默认选项的设置，软件就是应该最大程度的方便用户)。而且还要注意下拉列表的宽度是否合适，列表信息是否显示完全了。

 按钮（Button/Submit）

我们要注意Button和submit两种按钮的不同之处，Button主要是用来实现相应的方法函数，submit是用来提交相应的表单到相应的action处。这里有一点就是，当单击执行一个删除类的按钮时，一定要加上提示信息，而且提示信息上要有确定和取消功能，以防用户不小心删错信息。

（2） 现在的软件系统不再像以前那样单调，软件中实现了很多特效。举一个简单的例

子来说明一下，比如对一个按钮，当光标放到上面的时候，它是一种效果，当光标离开之后，它又是另一种效果。也要注意光标的变化，当光标在可输入的文本框上面时是“I”形状的，在一般的按钮上是弯曲三个手指的小手形状的。我们要注意特效的统一性，而且特效也不是用的越多越好。效果的实现使系统变得更加的多彩，用户也会更加愉快的使用软件。

（3） 每一个稍微复杂一点的系统一般都是由多个页面组成的，而不会只使用一个单调

的页面，这时我们就要注意界面显示的色调风格是否统一、字体大小从标题到具体内容是否体现出层级，同类、同层次的风格设置是否统一。虽说系统可以由多个界面组成，但是我们也不希望看到冗余的界面。也许有的需求中并没有对界面作出特殊的要求，但是我认为高质量的界面也是一款高质量的软件不可或缺的组成部分。

（4） 测试软件时，一定不要漫无目的的测来测去。这样不仅会增大工作量，而且也不

能对系统作出彻底的测试，。我们要有计划有目的的进行测试工作。要是担心忘记某些功能点，“地毯式”测试也是行得通的，从页面的第一个功能点到最后一个进行地毯式的搜索测试。

（5） 注意界面上的分页和滚动条等小问题，有的地方信息很少，一页足可以显示完，

就不需要分页功能了；有的窗口会看到滚动条，如果再把窗口设置的大一点，就可以全部显示了，那就最好把滚动条去掉，我想每个用户都希望一眼就看到所有的信息，而不想拉来拉去的。还有就是该有时间的地方，一定要有时间信息，尤其是涉及到打印报表的地方。

（6） 一般的系统都需要使用用户名和密码登陆，而且会为不同的用户分配不同的权限。

不要总是使用正确的用户和密码在相应的权限范围内进行测试工作，从打开登陆窗口的那一刻就要意识到测试工作已经开始了。在测试过程中不要按部就班的操作程序，你也不知道用户在使用过程中会怎样操作程序，有时候就要反其道而行之，要知道测试是具有破坏性的。

（7） 用户使用软件的环境和软件开发时的环境不可能完全一样。我们可以考虑并验证

以下这几个问题：

   其他的浏览器是否有相同的问题?

   其他的软硬件配置是否有相同的问题?

   不同的安排设置是否有相同的问题?  

    以前的版本否有相同的问题?

2． 提交bug时的注意事项

（1） 发现一个问题时，不必急着提交，可以先做验证(包括复现、对比测试等)进行证实，

看是概率性问题还是每次必现的问题，需要时也应使用不同版本不同机器做对比验证，当然，如果已经很确信是一个bug了，也就不用浪费时间去对比验证了。

（2） 描述要清晰、准确，不要使用含糊的词语(例如，好像，似乎)来描述发现的现象。

关于这点，如测试某款软件时，提交一个bug描述为“软件帮助说明中好像有错别字”，并没有说出哪一页哪一行以及具体哪个字错了，应该修改成什么样的。因此就不能说是个好的描述。

（3） 要考虑开发人员的感受，有些问题尤其是有些主观性比较强的问题，在问题描述

中一般不要出现带强烈感情色彩的词语标点符号，如“要求”、“必须”和感叹号等(特殊情况除外)。在提交此类问题时可以使用一些诸如“建议……”、“希望……”、“请……”之类比较委婉些的词语。

（4） 不能确认一个现象是不是一个bug的时候可以向其他人或者开发人员进行确认，

然后再去提交。

（5） 概率性的问题，测试过程中难免遇到一些概率性问题，很难找出其产生的规律，

甚至该问题在测试过程中只出现一次，对于此类问题也一定要提交，并补充说明无法复现或者无规律。

（6） 描述问题时，要实事求是，不要夸大，比如概率性问题，本来出现的概率只有10%，

你把它写成50%都是不应该的。

（7） 提交bug时，应该在描述清楚问题点的时候把正确的预期输出结果写明，即正确

的结果应该是什么样的，这点很重要。现在我们提交的bug中有些测试和开发双方都知道该修改成什么样子了，而在bug描述中未写出修改成什么样子的，如“来电时按挂机键不能拒接来电”这样描述一个bug，并没有写明该如何修改，一般这样描述大家一看就知道该如何修改，所以写不写预期正确结果大家都可以接受。但对于有些bug的描述一定要把预期的正确结果给写进去，否则开发人员会无所适从，不知道该修改成什么样子的。

（8） 很多时候，提交的bug都需要重现，而有的bug是在测试过程中偶然间发现的，

时间一长，会对发现bug时的特定数据或环境模糊，导致不能重现bug。所以提交bug时描述的越详细越好。如果语言文字难以清楚的描述出发现的问题，最好能附件图片或者log记录等做辅助说明。

（9） 提交测试bug的时候，如果该问题在某一特定环境下才能出现，一定要将该问题

产生的环境(硬件、软件)描述清楚。

（10） 提交问题前要清楚的知道软件需求、规格定义。相信很多人都遇到过这样的尴尬

情况，提交了一个重要问题后，却被告知其实那并不是一个问题，软件就是那样设计的或者需求就要求那样处理的。

（11） 有些问题出现了，不一定就是我们测试软件本身的问题，也可能是其他一些问题

导致的，如“手机通话时自动掉线”问题，这有可能是信道切换失败导致的，是网络的问题，不是我们手机软件本身的问题。类似情况还会很多，这都我们有着丰富的产品背景知识。

（12） 编写bug report没有什么定式，没有绝对的范本，最基本的是能够让客户或目标修

改，浏览bug report人员看懂，而且在短时间内，而不需反复思考的。其他有时要考虑目标读者的一些喜欢。例如有些类似的bug到底是合并还是单独提交，bug的步骤划分(到底是每一步都为一点，还是有些点可以合并)。在这一点上我觉得“灵活和适应”是很关键的。

（13） 在发现一个Bug并填写完bug report之后，在review的时候，需要特别注意的一

点是：这个bug report会不会让其他人还有联想或发挥的空间。一个好的bug report是不可以细分的, 换句话说就是这个bug是不会让他人觉得你还有些地方需要在测试一下，或许还有其他的问题。例如，有个测试人员发现在输入16这个数字(允许范围内)且提交时系统会返回一个错误：不能输入48以下的数字。这确实是一个错误，但是如果就只按现在的步骤提交，另一个可能会有这样的想法：是不是输入48以下的数字都会有这样的问题呢?这样他有可能要求你在测试其他的数据。这样就延长了这个bug的生命期，而且浪费了大家的时间。

（14） Bug提交完毕后，并不是就万事大吉了，后续跟踪验证等还多着呢。

3． Bug提交之后需要注意的事项

（1） 如果编程人员需要问题重现，应尽量减少重现的步骤以达到用最少的步骤来重现

问题;这对编程人员来说是很有帮助发现问题根源的。因为最少的步骤可以开发人员迅速、准确的锁定问题的根源。

（2） 最好由报bug的人验证bug是否可以关闭。任何人都可以修复bug，但只有那个发

现bug的人才能够确信bug是否真正的已被修复。

（3） 当你的bug报告以“not repro(不可重现)”打回给你时，先检查一个步骤是否有遗漏

或清晰，再去找编程人员。编程人员通常是在无法用bug报告中的步骤重现bug时才选择这个选项。

（4） 要对提交的bug时刻进行跟踪，要保持和编程人员的沟通交流，是bug及时得到

解决，以免影响项目的整体进度。

 

我想，作为一名软件测试人员，即便再优秀、再喜欢这份工作，也会感觉到测试过程的枯燥乏味。有时候改掉一个bug，又会导致另一个或更多bug的出现，面对这种似乎无休止的进行下去的测试工作，心里难免有些烦躁。但是烦躁归烦躁，切不可让自己的情绪过多的影响到自己的工作，时刻都要做到认真负责、脚踏实地，希望我自己也能够这样努力下去。

转载于:https://www.cnblogs.com/li1002/p/4474985.html