软件测试注意事项.docVIP

在目前的国内环境下，我们几乎看不到完整准确的客户需求说明书，客户的需求，追求完美的测试变得不太可能。因此作为一个优异的测试人员，追求软件质量的完美固然是我们的宗旨，但是明确软件测试现实与理想的差距，在软件测试中学会取舍和让步，对软件测试是有百益而无一弊的。DropDownList） 下拉列表的作用和单选按钮的功能有些相似，从列表中选择一条自己需要的信息。很多时候，列表的选项中有一条是使用频率最多的，即使用户没有做特殊要求，系统最好把使用频率最多的那一项设置为默认选项，这样可省去用户的一次操作步骤(不仅是这里，要注意整个系统中对默认选项的设置，软件就是应该最大程度的方便用户)。而且还要注意下拉列表的宽度是否合适，列表信息是否显示完全了。 按钮（Button/Submit） 我们要注意Button和submit两种按钮的不同之处，Button主要是用来实现相应的方法函数，submit是用来提交相应的表单到相应的action处。这里有一点就是，当单击执行一个删除类的按钮时，一定要加上提示信息，而且提示信息上要有确定和取消功能，以防用户不小心删错信息。 现在的软件系统不再像以前那样单调，软件中实现了很多特效。举一个简单的例子来说明一下，比如对一个按钮，当光标放到上面的时候，它是一种效果，当光标离开之后，它又是另一种效果。也要注意光标的变化，当光标在可输入的文本框上面时是“I”形状的，在一般的按钮上是弯曲三个手指的小手形状的。我们要注意特效的统一性，而且特效也不是用的越多越好。效果的实现使系统变得更加的多彩，用户也会更加愉快的使用软件。 每一个稍微复杂一点的系统一般都是由多个页面组成的，而不会只使用一个单调的页面，这时我们就要注意界面显示的色调风格是否统一、字体大小从标题到具体内容是否体现出层级，同类、同层次的风格设置是否统一。虽说系统可以由多个界面组成，但是我们也不希望看到冗余的界面。也许有的需求中并没有对界面作出特殊的要求，但是我认为高质量的界面也是一款高质量的软件不可或缺的组成部分。 测试软件时，一定不要漫无目的的测来测去。这样不仅会增大工作量，而且也不能对系统作出彻底的测试，。我们要有计划有目的的进行测试工作。要是担心忘记某些功能点，“地毯式”测试也是行得通的，从页面的第一个功能点到最后一个进行地毯式的搜索测试。 注意界面上的分页和滚动条等小问题，有的地方信息很少，一页足可以显示完，就不需要分页功能了；有的窗口会看到滚动条，如果再把窗口设置的大一点，就可以全部显示了，那就最好把滚动条去掉，我想每个用户都希望一眼就看到所有的信息，而不想拉来拉去的。还有就是该有时间的地方，一定要有时间信息，尤其是涉及到打印报表的地方。 一般的系统都需要使用用户名和密码登陆，而且会为不同的用户分配不同的权限。不要总是使用正确的用户和密码在相应的权限范围内进行测试工作，从打开登陆窗口的那一刻就要意识到测试工作已经开始了。在测试过程中不要按部就班的操作程序，你也不知道用户在使用过程中会怎样操作程序，有时候就要反其道而行之，要知道测试是具有破坏性的。 用户使用软件的环境和软件开发时的环境不可能完全一样。我们可以考虑并验证以下这几个问题： 其他的浏览器是否有相同的问题? 其他的软硬件配置是否有相同的问题? 不同的安排设置是否有相同的问题? 以前的版本否有相同的问题?发现一个问题时，不必急着提交，可以先做验证(包括复现、对比测试等)进行证实，看是概率性问题还是每次必现的问题，需要时也应使用不同版本不同机器做对比验证，当然，如果已经很确信是一个bug了，也就不用浪费时间去对比验证了。描述要清晰、准确不要使用含糊的词语(例如，好像，似乎)来描述发现的现象。关于这点，如测试时，提交一个bug描述为“帮助说明中有错别字”，并没有说出哪一页哪一行以及具体哪个字错了，应该修改成什么样的。因此就不能说是个好的描述。要考虑开发人员的感受，有些问题尤其是有些主观性比较强的问题，在问题描述中一般不要出现带强烈感情色彩的词语标点符号，如“要求”、“必须”和感叹号等(特殊情况除外)。在提交此类问题时可以使用一些诸如“建议……”、“希望……”、“请……”之类比较委婉些的词语。不能确认一个现象是不是一个bug的时候可以向其他人或者开发人员进行确认，然后再去提交概率性的问题，测试过程中难免遇到一些概率性问题，很难找出其产生的规律，甚至该问题在测试过程中只出现一次，对于此类问题也一定要提交，并补充说明无法复现或者无规律描述问题时，要实事求是，不要夸大，比如概率性问题，本来出现的概率只有10%，你把它写成50%都是不应该的提交bug时，应该在描述清楚问题点的时候把正确的预期输出结果写明，即正确的结果应该是什么样的，这点很重要。现在我们提交的bug中有些测试和开发双方都知道该修改成什么样子了，