软件测试注意事项

在目前的国内环境下，我们几乎看不到完整准确详细的客户需求说明书，而且每一款软件的开发都需要一定的周期，在软件开发过程中客户的需求一般情况下都不会做到一成不变，尤其是复杂的、开发周期长的软件，这就导致追求完美的测试变得不太可能。因此作为一个优异的测试人员，追求软件质量的完美固然是我们的宗旨，但是明确软件测试现实与理想的差距，在软件测试中学会取舍和让步，对软件测试是有百益而无一弊的。

我们应该如何在软件测试的过程中尽可能多的发现问题呢？测试过程中我们应该注意什么呢？我想说，成败在于细节，大到整个系统的架构流程，小到页面上的一个字体或标点，都是我们需要注意的地方。

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的出现，面对这种似乎无休止的进行下去的测试工作，心里难免有些烦躁。但是烦躁归烦躁，切不可让自己的情绪过多的影响到自己的工作，时刻都要做到认真负责、脚踏实地，希望我自己也能够这样努力下去。