软件测试注意事项
在目前的国内环境下，我们几乎看不到完整准确详细的客户需求说明书，而且每一款软件的开发都需要一定的周期，在软件开发过程中客户的需求一般情况下都不会做到一成不变，尤其是复杂的、开发周期长的软件，这就导致追求完美的测试变得不太可能。因此作为一个优异的测试人员，追求软件质量的完美固然是我们的宗旨，但是明确软件测试现实与理想的差距，在软件测试中学会取舍和让步，对软件测试是有百益而无一弊的。
我们应该如何在软件测试的过程中尽可能多的发现问题呢？测试过程中我们应该注意什么呢？我想说，成败在于细节，大到整个系统的架构流程，小到页面上的一个字体或标点，都是我们需要注意的地方。
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） 如果编程人员需要问题重现，应尽量减少重现的步骤以达到用最少的步骤来重现问题;这对编程人员来说是很有帮助发现问题根源的。因为最少的步骤可以开发人员迅速、准确的锁定问题的根源。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。