1.××模块：如果把打开公文附件，而下点一下“关闭”按钮，然后再点“保存“，则页面条转到空白页面，并且无任何出错提示。

这个描述我在看时也如丈二和尚般迷茫了半天，仔细看看原来是里面的错别字在捣乱。如：“而下点一下关闭按钮”应为“而且点一下关闭按钮”；“则页面条转到空白页面”应为“则页面跳转到空白页面”；打开公文附件那句中多了个“把”字，这样以来再看看就明白是什么意思了。为什么会这样？因为测试人员在输入完后没有检查就提交了，为什么不检查呢，在我们强调开发人员加强自测的同时，自己也应对自己提交的Bug负责。

2.××模块：新增后，“合同金额”过大时不应用科学技术法来显示。

为了找到究竟是那里用了科学计数法显示数字，我分别在记录列表页面、浏览页面、修改页面进行了查看，最终定位在了修改页面而其余2处都没有这种错误，那么明明有具体位置为什么当初在描述中不写具体？如果每个Bug都要让修改者如此定位的话，是不是很耗时呢？另外“合同金额过大”，这个过大究竟是多少？输入的数字超过了几位就会出现这种现象，测试时输入的数据是多少这里都没有明确的说明。Bug描述不清晰，开发人员在修改时势必要找测试人员问个究竟，这样一来大家的时间不就都浪费了么？（这里面也有错别字：“科学技术”应为“科学计数”）。

那么该如何描述一个Bug呢？过去上学老师在教大家写议论文时都会强调论点、论据、论证三要素，只要这三样齐备了那么写出的文章总归是不差的。同样我们的Bug描述中同样也要包括以下三要素：位置、操作、现象。具体来说：

1.位置：首先应说明操作进行的位置，通常是系统中的某一模块。另外是具体的出错位置，可能是某一字段、某一页面...

2.操作：详细的、有次序的、每一步的操作步骤，包括输入的数据

3.现象：具体的错误描述，包括界面显示、错误信息

Bug的记录是测试人员工作的基本内容，也是测试和开发交流的基础，确保了Bug描述的有效性，即可提高Bug的修改速度，也可提高Bug的修改质量。而作为测试人员在Bug描述中出现错别字就如同开发人员在程序中出现界面上的Bug一样，完全是不细心造成的，对于测试人员来说是不应该出现的。

填写一份内容全面，条理清晰的问题单，使测试人员的基本功底。从论坛上很多人发帖的模糊标题就可以看出，在具体的工作中，bug报告单填写的也肯定不好。

写得很好

作为测试人员怎么能容忍自己写下错别字呢？

至于描述不清的问题可能很多人都遇到过 最初我写bug就比较模糊，后来经过指点（在此非常感谢那位给予指点的朋友），我在写bug的时候就比较注意了，当然现在仍需要不断地改进

然而，描述清楚的同时，我们又比较容易遇到另一个问题，就是冗长，开发者看到一堆文字就头大了 不愿意花时间去仔细读（自己回头再看也容易晕） 所以我们写bug描述一定要清晰明确且简明扼要 

这些应该是测试人员自己需要把握的基本的东西，就不需要主管来review吧

bug报表第一次写详细点其实是给自己节省时间。试想如果有20个模棱两可的bug描述，而这20个又对应若干个开发人员，这些开发人员不在一间屋子，又不可能同时看到bug，如果每个人都要问你一遍再演示一遍的话，测试人员一天就别干其他事情了。当然，估计一天的运动量也够了，呵呵。

如果再现bug需要的操作比较多，可能会造成冗长描述，我觉得可以有2种方法给出描述：

1. 用“->”表示经过的操作。

比如：打开用户登录页面->输入用户名密码XXX->选择VIP用户->点击“登录”按钮->选择“个人设定”->进行某项操作，出错...... 

2. 用列表的形式。还是上面的操作

1)在用户登录页面输入用户名密码XXX

2)选择VIP用户

3)登录后选择“个人设定”

4)进行某项操作，出错...... 

上面的例子里的操作步骤不是太长，我只是抛砖引玉觉得用这2种方法来描述问题会比较直观，让开发人员不会因为步骤复杂产生排斥心理。而且还有一个作用就是自己看起来也很清楚，碰上需要看自己很久以前写的bug报告也不会一头雾水琢磨半天。

啰嗦了这么多，就是一个意思，既然文档是用来交流的，让人不容易看懂的文档就不是好文档。

呵呵。

我平常就要求测试人员描述时要按错误产生的步骤，及错误现象，简洁清楚的描述下来，反对将一个错误没有条理的写三四行，让人摸不着头脑

如：

步骤:

1.....

2.....

3....

   此时产生错误,系统提示........, 如附件所示

同意楼主的意见，写缺陷最主要写明模块入口，描述扼要，结构清晰。否则，别人是看不懂的。

“位置，操作，对象”------楼主提出的这3要素记下了！非常有帮助的，对我来说。

也许做测试最可悲的就是发现了bug，却又说不清楚到底是什么bug。害得大家费了很大劲去搞清。你做的发现bug的测试用例可能要重测了！

正好问一下大家，此类发现bug 的测试用例是不是要重测好几遍才能提交？（1确定范围，2确定确实是这个问题，3确定描述问题时的准确性；1 2 3里选哪个，还是都要，都不要？？）

报bug主要是要写好重现步骤：

首先注明需要哪些必备的环境，

接着是执行操作的步骤，

指明什么地方出错，

期望应当是什么结果，

添加必要的附件作为补充。

BUG的要素

作者提到BUG三要素:位置\操作\现象,是很基本的.我也做了几年测试,凭我的经验我觉得一个好的BUG还要应具备以下要素:预期的结果\实际的结果\问题分析

要写出预期结果就要熟悉了解被测东东的需求,了解客户的需求，或者对产品多年的积累.

要写出实际结果就比较容易了,包括出错的现象,还有问题所在

要分析问题就比较有挑战了,这也是衡量测试人员水平的要素.分析错误大概出在哪里.从两个方面来分析,技术上分析:使程序员更容易定位问题.业务上分析:因为有的程序员没有经验,他只知道一个模块,有深度,但是没有广度,他不知道整个项目的需求,更不知道客户的要求.他很有可能不知道要如何去修改这个BUG,如果你给他思路他会很感激的.

所以测试人员需要了解的东西需要比较广泛最好做过程序员,另外业务知识很重要,对于做项目测试尤其明显.业务知识的积累有很多途径,如去项目现场参观.

写出自己填写BUG 票的步骤,给大家参考!

填写BUG 票可以参考以下步骤:

1.测试的日期,版本,工具等填写完整.

2.要对BUG进行概括性的总结-----描述问题所在.

3.将测试手顺(测试的顺序)描述清楚.可以采用1.2.3....等罗列出来.

4.列出测试出现的错误概率.

软件缺陷的详细整理

认识软件缺陷，首先要了解软件缺陷的概念，其次是了解软件缺陷的详细特征，最后就是它的属性了，再高一个层次就是学习利用管理软件缺陷的工具了。

1、首先介绍软件缺陷的概念

软件缺陷是指系统或系统部件中那些导致系统或部件不能实现其功能的缺陷。

2、软件缺陷的详细特征

a、单一准确

b、可以再现（要求软件缺陷具有精确的步骤）

c、完整统一

d、短小简练

e、特定条件

f、补充完整

g、不做评价

3、软件缺陷的属性

软件缺陷的属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷产生可能性、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷原因。

下面详细介绍一下以上这些属性：

a、缺陷标识：是标记某个缺陷的唯一标识，可以用数字序号表示；

b、缺陷类型：功能、用户界面、文档、软件包、性能、系统\模块接口

     功能：影响了各种系统功能、逻辑的缺陷；

     用户界面：影响了用户界面、人机交互特性，包括屏幕格式、用户输入灵活性、结果输入格式等方面的缺陷；

     文档：影响发布和维护，包括注释、用户手册、设计文档；

     软件包：由于软件配置库、变更管理或版本控制引起的错误；

     性能：不满足系统可测量的属性值，如执行时间、事务处理速率等；

     系统\模块接口：与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表等不匹配、冲突。

c、缺陷严重程度：致命（Fatal）、严重（Ceritical）、一般（Major）、较小（Minor）

    致命：系统任何一个主要功能完全丧失，用户数据受到破坏，系统崩溃、悬挂、死机或者危机人身安全；

    严重：系统的主要功能部分丧失，数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响；

    一般：系统的次要功能没有完全实现，但不影响用户的正常使用。例如：提示信息不太准确或用户界面差、操作时间长等一些问题；

    较小：使操作者不方便或遇到麻烦，但它不影响功能过的操作和执行，如个别不影响产品理解的错别字、文字排列不整齐等一些小问题

d、缺陷产生可能性：总是、通常、有时、很少

     总是：总是产生这个软件缺陷，其产生的频率是100%；

     通常：按照测试用例，通常情况下会产生这个软件缺陷，其产生的频率大概是80%—90%；

     有时：按照测试用例，有时候产生这个软件缺陷，其产生的频率大概是30%—50%；

     很少：按照测试用例，很少产生这个软件缺陷，其产生的频率大概是1%—5%.

e、缺陷的优先级：立即解决、高优先级、正常排队、低优先级

     立即解决：缺陷导致系统几乎不能使用或者测试不能继续，需立即修复；

     高优先级：缺陷严重，影响测试，需要优先考虑；

     正常排队：缺陷需要正常排队等待修复；

     低优先级：缺陷可以再开发人员有时间的时候被纠正。

f、缺陷状态：激活或打开、已修正或修复、关闭或非激活、重新打开、推迟、保留、不能重现、需要更多信息

    激活或打开：问题还没有解决，存在源代码中，确认”提交的缺陷”，等待处理，如新报的缺陷；

    已修正或修复：已被开发人员检查、修复过的缺陷，通过单元测试，认为已经解决但还没有被测试人员验证；

    关闭或非激活：测试人员验证后，确认缺陷不存在之后的状态；

    重新打开：测试人员验证后，确认缺陷不存在之后的状态；

    推迟：这个软件缺陷可以在下一个版本中解决；

    保留：由于技术原因或第三者软件的缺陷，开发人员不能修复的缺陷；

    不能重现：开发不能再现这个软件缺陷，需要测试人员检查缺陷再现的步骤；

     需要更多信息：开发能再现这个软件缺陷，但开发人员需要一些信息，例如缺陷的日志文件、图片等。

g、软件缺陷的起源：需求、构架、设计、编码、测试、用户

     在团建生命周期中软件缺陷占的比例：需求和构架设计阶段占54%、设计阶段占25%、编码阶段占15%、其他占6%.

h、软件缺陷的来源：需求说明书、设计文档、系统集成接口、数据流（库）、程序代码

    需求说明书：需求说明书的错误或不清楚引起的问题；

    设计文档：设计文档描述不准确。和需求说明书不一致的问题；

    系统集成接口：系统个模块参数不匹配、开发组之间缺乏协调引起的缺陷；

    数据流（库）：由于数据字典、数据库中的错误引起的缺陷；

    程序代码：纯粹在编码中的问题所引起的缺陷。

i、缺陷根源：测试策略，过程、工具和方法，团队\人，缺乏组织和通讯，硬件，软件，工作环境

   测试策略：错误的测试范围，误解测试目标，超越测试能力等；

   过程、工具和方法：无效的需求收集过程，果实的风险管理过程，不使用的项目管理方法，没有估算规程，无效的变更控制过程等；

   团队\人：项目团队职责交叉，缺乏培训。没有经验的项目团队，缺乏士气和动机不纯等；

   缺乏组织和通讯：缺乏用户参与，职责不明确、管理失败等；

   硬件：硬件配置不对、缺乏、或处理器缺陷导致算术精度丢失，内存溢出等；

   软件：软件设置不对、缺乏，或操作系统错误导致无法释放资源，工具软件的错误，编译器的错误，千年虫问题等；

   工作环境：组织机构调整，预算改变，工作环境恶劣，如噪音过大。

4、学会利用管理缺陷的工具

例如TD、bugfree、bugzille等下载本文