最近在工作中注意到了这样一个现象，我们测试小组的人员经常会去给开发人员解释自己写的Bug是什么意思，一个Bug来来回回的改了好几遍，于是我大致的浏览了一下测试人员添加的一些Bug，发现了一些比较有意思的描述，现列出几个：
1.××模块：如果把打开公文附件，而下点一下“关闭”按钮，然后再点“保存“，则页面条转到空白页面，并且无任何出错提示。
这个描述我在看时也如丈二和尚般迷茫了半天，仔细看看原来是里面的错别字在捣乱。如：“而下点一下关闭按钮”应为“而且点一下关闭按钮”；“则页面条转到空白页面”应为“则页面跳转到空白页面”；打开公文附件那句中多了个“把”字，这样以来再看看就明白是什么意思了。为什么会这样？因为测试人员在输入完后没有检查就提交了，为什么不检查呢，在我们强调开发人员加强自测的同时，自己也应对自己提交的Bug负责。
2.××模块：新增后，“合同金额”过大时不应用科学技术法来显示。
为了找到究竟是那里用了科学计数法显示数字，我分别在记录列表页面、浏览页面、修改页面进行了查看，最终定位在了修改页面而其余2处都没有这种错误，那么明明有具体位置为什么当初在描述中不写具体？如果每个Bug都要让修改者如此定位的话，是不是很耗时呢？另外“合同金额过大”，这个过大究竟是多少？输入的数字超过了几位就会出现这种现象，测试时输入的数据是多少这里都没有明确的说明。Bug描述不清晰，开发人员在修改时势必要找测试人员问个究竟，这样一来大家的时间不就都浪费了么？（这里面也有错别字：“科学技术”应为“科学计数”）。
那么该如何描述一个Bug呢？过去上学老师在教大家写议论文时都会强调论点、论据、论证三要素，只要这三样齐备了那么写出的文章总归是不差的。同样我们的Bug描述中同样也要包括以下三要素：位置、操作、现象。具体来说：
1.位置：首先应说明操作进行的位置，通常是系统中的某一模块。另外是具体的出错位置，可能是某一字段、某一页面...
2.操作：详细的、有次序的、每一步的操作步骤，包括输入的数据
3.现象：具体的错误描述，包括界面显示、错误信息
Bug记录是测试人员工作的基本内容，也是测试和开发交流的基础，确保了Bug描述的有效性，即可提高Bug的修改速度，也可提高Bug的修改质量。而作为测试人员在Bug描述中出现错别字就如同开发人员在程序中出现界面上的Bug一样，完全是不细心造成的，对于测试人员来说是不应该出现的。
