----转载自CSDN（imlogic的专栏）----------http://blog.csdn.net/imlogic/

                                                   
前言

在99年的Quality week上的一次演讲中，微软的一个测试经理，Roger Sherman指出了由于“不可重现”导致bug关闭的主要原因。这是一个非常可惜的情况，因为这样的bug report浪费了紧张的开发计划中的宝贵时间，增加了对产品质量完全是无关紧要的事情，同时导致了在开发人员和测试之间的挫败感和差的感觉。有时，bug report是由于短暂的或随机的事件，测试和开发之间不一致的工具和配置，或者在测试的环境下对正确的行为的模糊定义而产生的，但是许多的由于不可重现而被关闭的测试报告是因为描述不清晰，被误解，或者只是文字的错误。

幸运的是，我学习到一些能够引起管理层注意，更清楚的和开发人员沟通并得到修复的编写优秀bug report的诀窍。这些技巧不仅仅提供了是在被修复的问题的比例方面得到了可靠的回报，而且在同开发人员和管理层的通过中也得到了回报。在我管理的项目中使用这种方法编写bug report，8份bug report中大约只有一个没有被修复。

这篇文章的思想只有当你的报告针对的测试执行过程是专业的质量工作才可以发挥作用。聪明地执行完整的测试包是产生可靠的测试状况信息的基础的其中一个因素。在许多的测试文献中广泛地介绍了多种多样的关于如何构建这样的测试包的方法。选择和你质量风险管理需求相一致的技术并且使之适应你的具体情况，敏捷地监督已计划的测试的执行过程，这样你就可以拥有可靠的测试执行过程。

另外一个关键的因素－bug report，却没有得到太多的关注。这是非常令人遗憾的，因为优秀的bug report对反映测试小组真实的和可理解的工作质量同测试本身一样都是非常重要的。试想一下：如果你不能用开发人员能够理解的术语和能够用于调试的方法给开发人员解释一个错误，他怎么能够修复问题呢？如果你不能够在bug report中提出象“保险杆标签”（bumper sticker）一样的错误总结来引起管理层的注意，你又如何让他们关心你们发现的问题呢？

Bug report的核心是对错误的描述。表格1中是一个关于好和差的错误描述的例子。编写好的bug report是一种好的艺术形式。采用以下的10条技巧可以帮助你的小组提高编写bug report的质量：

组织Structure：测试人员应该采用深思熟虑的，小心谨慎的方法执行测试，并且做详尽的记录。这样可以促使他们对测试下的系统有很好的认识。当错误发生的时候，一个有组织的测试人员能够知道最早出现问题的地方。

重现Reproduce：测试人员在编写bug report之前必须在检查问题是否可重现。如果错误不可再重现，仍然应该写下来，但是必须说明问题的偶然性。一个好的处理原则就是在编写bug report之前反复尝试3次。

隔离Isolate：在尝试编写bug report之前，必须试着隔离错误。可以采用改变一些变量的方法，如系统的配置，它可能可以改变错误的症状。这些信息可以为开发人员着手调试提供思路。

归纳Generalize：在测试人员发现了一个已隔离的，可重现的问题后，应该对问题进行归纳。同一个问题是否出现在其他的模块或其他的地方？同一个故障是否有更加严重的问题？

对比Compare：如果测试人员以前曾经验证过现在出错的测试用例，那么他就应该检查以前的测试结果以检查相同的条件是否通过以前的测试。如果是的话，那么这个问题就象是一个回归的错误。注意由于同一测试条件有可能出现在多个测试用例中，这个步骤就不仅仅只是检查一个测试用例在以前的多个结果。

总结Summarize：在bug report的第一行写上错误的总结是非常关键的。测试人员要花些时间思考已发现的错误对客户有何影响。这不仅仅要求测试人员编写的报告要能够吸引读者，使和管理层的沟通清晰，还要能够帮助设置错误修复的优先级别。

精简Condense：在bug report的初稿完成后，测试人员应该反复阅读它，集中剔除那些没有关系的步骤或词语。隐含的或模糊的说明和那些由于对没有任何关系的细节或者那些在重现错误过程中不需要的步骤而消磨报告欢迎程度的无穷唠叨都不是bug report的目标。

消除歧义Disambiguate：测试人员在精简空话的同时或其之后随即应该再仔细检查报告是否有会产生误解的地方。测试人员应该尽量避免使用模糊的，会产生歧义的和主观的词语。目标是使用能够表述事实，清楚的，不会产生争执的词语。

中立Neutralize：如文中所述，作为坏消息的传递人，和善地提交消息是一个挑战。如同所有的错误总结一样，独立的bug report在措辞方面应该保持公正。攻击开发人员，指责潜在的错误，企图诙谐或使用挖苦将引起开发人员的憎恶，并且使注意力从“提高产品质量”这个大的目标上转移开了。谨慎的测试人员只用Bug report来描述事实。

检查Review：一旦测试人员感觉bug report是他能够编写的最好版本，他应该将报告再给一个或多个同行进行检查。他的同事们也应该给出一些建议，为了澄清问题不断地提问，如果适当的话，甚至可以挑战“错误成灾”的结论。在允许的时间里，测试小组应该尽可能提交最好的bug report。

以上10条技巧可以帮助你和你的小组提交准确简洁的，彻底校订的，精心构思的，高质量的技术文档。测试小组应该集中编写bug report的任务，测试组长和经理应该让测试组成员清楚地认识到编写优秀的bug report是一项首要的工作任务。衡量优秀的bug report的质量指标应该包括如下：
o        对管理层来说，是清晰明了的，特别是在概要这一级；
o        对于开发部门是有用的，主要是给出能够让开发人员高效地调试问题的相关信息
o        可以很快的将bug从“Opened”状态转变成“Closed”状态，减少为得到更多的信息从开发人员打回的差的bug report并导致测试人员返工的时间。

改进bug报告的流程是需要花费一些时间的，但是也给予了效果显著的回报。首先，简单的流程改进了测试小组和高层、平行管理层之间的沟通，增强小组的信任度，名望和鼓励管理层给测试投资更多的资源。第二，平稳地递交报告给开发人员促进了测试和开发人员之间积极的关系。第三，更短的bug生命周期是更加有效的，在时间上之前花费在编写优秀bug report上的时间和后期由于返工差的bug report花费的时间相抵消。这些回报帮助开发流程通过有效的沟通和高效率的流程获得更好的产品质量。

　　缺陷级别（Severity）：即上图中的5级别定义，一般大于等于III级的Bug被认为是严重的问题。

　　所属产品、项目：有的人需要同时处理很多产品、项目，这个属性可以用来筛选。

　　Bug名称：一个短句，此Bug的简单说明。

　　Bug描述：写成如下形式，“执行某操作，期望出现什么情况，实际出现什么情况”，还可以添加截图、文档等附件。

　　其实其他属性还有很多，不过我觉得非必须，经常不填，也就不说了。

　　我们的测试过程使用了Mercury Interactive公司的Quality Center来管理，它是一个基于 Web且支持测试管理的所有必要方面的应用程序，更小的团队，用Excel来管理Bug也未尝不可。作为PD，也是会经常提Bug的，PD做测试的时候主要是模拟用户的身份使用产品，而测试人员会更多的按照TC执行。当发现一个Bug以后，我们会提交给相应的开发工程师，如果认为是需求问题也会提交给对应的PD，这时候Bug的状态为Open，之后的状态改变，可以用下图表示。

Bug状态流转图（图中defer拼错了）

　　收到Open的Bug，确认并修复，状态变为Fixed；否认，也许提出者理解错了，也许不打算修改，状态改为Rejected；或者认为不是自己的问题，可以把Bug转交（Assign to）给别人。

　　测试验证状态为Fixed的Bug，没问题了就Closed，否则可以Reopened。看到Rejected的Bug，发现是自己理解错了，就可以Closed，仍然认为是Bug的可以Reopened。对于Deferred的Bug，意味着本项目中暂不修正，可能是因为技术做不到，时间不允许，性价比太低等，必须慎之又慎，通常由能负责的人，比如是测试经理、项目经理最终同意才Deferred。

　　整个过程中，Bug的每次状态改变都可以添加注释说明，我们更鼓励有争议叫上当事人面对面的交流，而不是在系统里不停的纠缠。

　　到了项目发布之时，我们要求所有Bug的状态必须是Closed或者Deferred，当然对I、II级的Bug，有时候并没有这么严格。

　　使用Quality Center比Excel的好处，在于每个Bug重要的状态转换点，系统都会有邮件通知到相关人员，防止遗漏；项目中每个人在系统里的角色不同，权限不同，防止误操作，甚至一些恶意行为，比如开发人员就不能把Bug状态改为Closed；所有操作都有记录，谁在何时做了什么，便于追溯。这些都有效的防止了人为因素导致的问题。

　　1 在windows xp比较流行的操作系统上是否可以识别（装了驱动后是否可以）

　　2 在电脑上显示的盘符是否正确

　　3 总空间，可用空间，已用空间是否显示正确

　　4 u盘中是否可以拷入各种格式的各类文件（图片，视频，文档，网页...）

　　5 是否可以拷入拷出大文件

　　6 正常操作拷入的文档等是否显示乱码

　　7 拷文件的过程中是否可以取消

　　8 拷文件的过程中拔掉u盘后，u盘是否损坏

　　9 拷文件的过程中电脑关机后，u盘是否损坏

　　10 u盘的开关是否起作用

　　12 正常操作，拷入的文件是否会丢失

　　13 空间已满是否有提示信息

　　14 是否支持格式化

　　15 u盘在各个状态时是否有相应的led灯提醒

　　兼容性测试：

　　1 在windows 98,windows 2000,windows me,windows 2000 server,windows 2003 server,windows xp,windows vista...是否可以识别

　　2 在usb1.0,usb2.0上是否能够识别

　　3 在笔记本上，台式电脑，服务器上是否可以识别

　　性能测试：

　　1 一次性拷贝删除多个文件，u盘是否正常

　　2 u盘连续使用比较长的时间，u盘是否正常

　　3 u盘摔地上多次后，是否正常

　　界面测试：

　　1 设计是否美观大方

　　2 图案，log是否正确显示

　　注：在该文章的基础上总结了一下，对此表示感谢，http://www.51testing.com/?161964/action_viewspace_itemid_99925.html

1.引言

　软件开发过程中，经常遇到这个问题，所以转载下：　
    需求变更对软件开发项目成败有重要影响，既不能一概拒绝客户的变更要求，也不能一味地迁就客户，所以实施需求变更之前必须做好控制。需求变更控制的目的不是控制变更的发生，而是对变更进行管理，确保变更有序进行。
　　
　　（1）明确合同约束，建立需求基线
　　需求变更给软件开发带来的影响有目共睹，所以在与客户签订合同时，可以增加一些相关条款，如限定客户提出需求变更的时间，规定何种情况的变更可以接受、拒绝或部分接受，还可以规定发生需求变更时必须执行变更管理流程。虽然软件开发合同很难在签订之初就能够精确定义每项需求，单靠合同是帮不上忙的，但也不能忽视合同的约束力。
　　
　　明确和树立需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后（客户参与评审），建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线，做到小需求可以变更，但大方向要力保不频繁变更。例如，对于项目中的需求，可以实行分级管理，以达到对需求变更的控制和管理。
　　
　　（2）建立变更审批流程

　　在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低开发效率，浪费时间。正是这种观念才使需求变更变得不可控，最终导致项目的失败。因此，小的需求变更也要经过正规的需求管理流程，否则会积少成多，积重难返。
　　
　　明确需求变更审批环节、审批人员、审批事项、审批流程。这么做的目的有两个：一是将客户下达变更的流程尽可能地规范化，减少张嘴就来的非必要、非紧急、非合理、非高层领导意图的无效变更。二是留下书面依据，为今后可能的成本变更和索赔准备好“变更账”。凡未履行审批程序的“变更”，一律是无效变更不予受理。
　　
　　（3）分级管理变更，定时批量处理

　　软件开发项目中，“客户永远是对的”和“客户是上帝”并不完全正确，因为在已经签定的项目合同中，任何新需求的变更和增加除了影响项目的正常进行以外，还影响到客户的成本投入收益。因此，用户不断提出对项目进度有重大影响的需求对双赢也并不是好事。
　　
　　当遇到客户提出需求，不及时处理可能会使项目不能验收通过时，也不能一味拒绝不予开发。因此，当客户坚持变更新需求时，可以建议客户将新需求按重要和紧迫程度划分档次，作为需求变更评估的一项依据。例如，每周或每两周甚至每月召开一次需求变更专题会议，集中研究处理这些零碎变更事项，主动控制好工作节奏，尽量避免由于处理零碎变更而影响项目进度。针对会议结果可向客户正式提交一份需求变更计划，注明变更引起的时间、成本、工期代价和增加工作量等。要求客户配合需求变更计划，确定变更时限，控制变更规模，过时变更不候，离谱变更不做，保大局弃小变。
　　
　　（4）安排专职人员负责变更管理

　　有时开发任务较重，开发人员容易陷入开发工作中而忽略了与客户的随时沟通。因此，需要安排一名专职的需求变更联络人员，负责与客户及时交流，跟踪和汇报需求变更完成进度和情况。同时，可以成立项目变更控制小组，负责裁定接受哪些变更，小组由项目所涉及的多方人员共同组成，应该包括客户方和开发方的决策人员在内。
　　
　　（5）确认客户是否接受变更的代价

　　要让客户认识到变更都是有代价的，要和客户一起判断需求变更是否依然进行。例如，变更是没有问题的，但是要明确客户能否接受由此引起的如进度延迟、费用增加、效率下降等问题。一般来说，如果客户认为该变更是必须的（不是其上级领导拍脑袋提出的）就会接受这些后果。通过与客户协商，这样开发团队即使没有回报，也不会招致公司和客户双方的埋怨。
　　
　　如果客户认为该变更虽然有必要但是可以暂缓，双方签署备忘录后留待以后解决。如果客户认为该变更可有可无，多数情况下会取消变更。这样即可防止频繁变更，也让客户认识到不是所有的需求都需要变更。