最近读Cem KanerJames Bach，Bret Pettichord合著的《软件测试报告的测试结论经验与教训》受益颇多因此根据文中的部份内容总结出来与大家共享，希望能达到知识交流与共享的目的如果感兴趣，吔可以阅读原书    测试报告的测试结论报告是产品部与技术部进行沟通的主要手段，测试报告的测试结论报告的好坏直接影响BUG的修改速度囷程序员的心情如果下苦功夫研究并写好报告，则所有阅读这些报告的人都会受益因此我整理并撰写此文，希望对于能修直产品部与技术部的桥梁有所帮助一、 缺陷报告的原则1、 有些错误永远也不会改正。测试报告的测试结论员的责任不是保证所有错误都得到改正洏是准确报告问题，使程序员能够理解问题的影响而深入研究并写出好的报告，常常对错误改正的可能性产生巨大的影响2、 及时报告缺陷。不要等到第二天或是下周才报告程序错误不要等到忘记了一些关键细节才报告。拖延的时间越长程序错误被解决的可能性就越尛。3、 每个程序错误都需要单独报告不要努力把不同的程序错误合并到同一份报告，来减轻项目经理或程序员对重复错误报告的不断抱怨如果多个程序错误写到一份报告中，有些错误就可能得不到修改4、 小缺陷也值得报告。小错误会使客户感到困惑并降低客户对产品其他部份的信心。被认为是很小的缺陷可能包括拼写错误、小的屏幕格式问题鼠标遗迹、小的计算错误，图形比例不准、在线帮助错誤、不适当的灰掉了的菜单选项、不起作用的快捷键、不正确的错误信息以及其它程序员认为不值得花精力去修改的缺陷。5、 努力使错誤报告有更高的价值由于有很多人都要阅读并依赖错误报告，因此要下功夫丰富每个错误报告的信息提高报告的可理解性。如：A、清楚列出错误报告的前置条件与实现的每一个步骤避免前后语言混乱，它应该只需要描述现象不要在产生错误的步骤中试图给出程序员嘚解决办法。这样会使错误报告看来冗长而难于理解如果有好的解决办法或建议可以附在错误报告描述之后。B、要始终保持中立语气C、不要开玩笑，否则有可能造成误解6、 永远都要报告不可重现的错误，这样的错误可能是时间炸弹不可重现的错误可能会是公司能够支付的最昂贵的缺陷。有时错误无法重现看到程序错误一次，但不知道如何使其再次出现如果产品交付客户还出现这种情况，会影响愙户对产品的信心如果技术支持人员需要很长时间评估客户的数据或环境，客户则会更加厌烦如果测试报告的测试结论员清晰地报告錯误征兆，程序员通过研究测试报告的测试结论员怎么得到特定消息或当测试报告的测试结论员查看对话框或点击特定控件时可能会出現的情况。从而能够跟踪代码相信程序员能够改正报告中“不可重现”缺陷中的20%。但在报告此类BUG时一定要明确说明自己不能重现这个程序错误。二、 缺陷报告的注意事项1、 引用别人的错误报告要小心如果没有得到错误报告的提交者的允许，可以补充评论但不能编辑別人的材料。对于其他测试报告的测试结论员的错误报告即使很糟糕也不要擅自修改任何时候需要在错误报告中做补充，都要注明自己嘚姓名和日期2、 看似极端的缺陷可能是潜在的安全漏洞。如在一个在预期接受一个1~99的字段中输入65536个9会导致程序崩溃。会有人真的这么幹吗是的，有人当然要这样做有人会认为“如果有人愚蠢到这样做，程序崩溃会教训他“而忽略该错误但实际上白痴不是惟一滥用程序的人。任何会产生严重后果的问题都应该解决不管其多么“不可能”发生，当熟练的攻击者利用程序中的缺陷得手后会写下这个消息并广为传播，使得其所有生手都可以使用脚本3、 立即对程序错误延迟决定上诉，如果决定据理力争就一定要赢。如果测试报告的測试结论员对某个BUG的处理有意见确实需要上诉，不要依赖自己最初错误报告中的语言和信息报告是不可更改的，但是测试报告的测试結论员需要列举更有效的例子测试报告的测试结论员需要与其他产品项目相关人员沟通，补充做一些后续测试报告的测试结论寻找该程序错误可能存在的更严重的错误。程序员所做的每个上诉都必须是有说服力的即使不能赢得所有上诉（当然不可能赢得所有上诉）也應该得到自己的所有上诉理应获胜的好名声。    至此上面罗列的条款都与我们实际工作有着密切的关联，希望能借助此篇文章让你能有興趣读完本书的全部内容,相信一定能让你获益匪浅。回复：如何写好测试报告的测试结论报告黄为东    是否具有客观的、认真的、尊重的（包括尊重自己和程序员）、执着的态度能够直接影响bug的生死。    因为程序员都是人不可避免受人的互动关系影响。回复：如何写好测试報告的测试结论报告曾盛开（技术部）    我看完了总是觉得程序员和测试报告的测试结论员之间在问题分歧上存在很多不同之处，其中包括个人专业知识的深度对软件理解的能力，对业务、程序的理解能力产品开发成本、周期与bug之间的协调。    诸多方面加起来使我的脾氣在沟通协调bug问题上变得很容易激昂，或者说发火头脑发热。程序员多少都有些自大不甘屈服的情绪，而且确实很多东西由于变得和鉯前写好、定好的需求有出入导致做好的东西可能又被推翻。。心里那种滋味很不好受的。毕竟每个地方和环节都是自己努力去想过的，有时候一个问题可能是花去几天时间确保那样做没有漏洞和正确    我感觉到两个部门之间协调缺少更多互动，比如产品部在测试報告的测试结论之前或者有空时候可以培训一下技术部一般会测试报告的测试结论哪些东西，如何测试报告的测试结论的这样子程序員心里多少有更多的底，在写程序的时候会有一种警惕性从而产品部也会轻松一些，双方有利应该是三方有利，公司最有利。产品蔀也要考虑如何帮助程序员快速有利地处理bug而不是一味为了bug而找bug，这根本背离了两个部门合作的基调；技术部也同样有责任去帮助产品蔀理解好系统运行的流程找出隐藏的bug 。   另外我想说的是在文档细节上面不要过分苛求，否则一方面是开发进度和成本另一方面是使Xp輕量级文档开发流程又变成重量级文档开发，程序员为了文档忙于疲命。我深有体会的文档花去的时间几乎占用了1/4－1/3。   我觉得在测试報告的测试结论的同事面前谈测试报告的测试结论有些班门弄斧，关公卖刀但有些话不得不说，那就开诚布公拿出来就算贻笑大方吔好吧~~~回复：回复：如何写好测试报告的测试结论报告李鹏（产品部）    文档花去的时间几乎占用了1/4－1/3：这个时间我不觉得多，我觉得不够花在需求定义，开发文档方面的时间应该是1/2以上    我觉得XP编程不适合我们理由有三：    1、我们的8.0项目跨度有近2年，可以说是个中型项目xp編程比较适合小项目（2-3个月）。    2、xp编程理论中基本上没有提到如何对程序进行系统的测试报告的测试结论而我们公司非常重视软件测试報告的测试结论，程序员和测试报告的测试结论员的比例近1：1    3、xp中对文档的定义是“够用就好”，而在众多的工程理论（rup、cmm）中都建议偠有详尽得需求和开发文档花在需求定义，开发文档方面的时间应该是1/2以上回复：回复：如何写好测试报告的测试结论报告黄为东    技術部和产品部的斗争性，有它的积极作用但确实存在两个部门目标不一致性的问题，既存在内部损耗又存在被共同忽视的中间地带。    夶胆设想一下假设把技术部和产品部合并为一个大部，每个小组都配2个测试报告的测试结论员是否会更好呢？这样测试报告的测试结論人员对本组开发人员的配合密切程度也许会更高问题是，测试报告的测试结论的专业性、分工性是否会下降    该怎么组织，是一个大問题回复：回复：如何写好测试报告的测试结论报告蒲冬梅（产品部）   产品只有足够人性化，用户才会乐意使用此功能而不是买回去僦将其束之高阁。文档只有足够详细化才能为产品部测试报告的测试结论提供准确的依据。因此就需要产品部与技术部能够有更多沟通更充分的文档准备，更大的耐心    因为最终目标我们只有一个，做出来的产品要对得起用户因此我们需要彼此体谅，理解与尊重    如果技术部有时间或是计划能够安排接受产品部的测试报告的测试结论培训，我想我们部门每个同事都会举双手双脚赞成的这样应该能减尐很大部份测试报告的测试结论的工作量。    关于为了找BUG而找BUG的说法我觉得是很有必要就此申明一两句的。现在产品部最终提交到技术部嘚BUG都是有人负责审核的（BUG的定位是否准确BUG的描述是否清晰等）。由于BUG的数量这项工作其实是相当费时与费力的，因此曾停过一段的时間但是为了提高BUG的质量和减少为了BUG而需要与产品部沟通的时间，这部份工作我们依然坚持在做但是难免会有部份BUG在产品部进行准确定位是很困难的，而如果改为由技术部来定位则仅仅只是几分钟的事情因此我们并未严格控制每个BUG都会精确定位，但是我们的目标是尽可能减少技术部为了BUG的描述或定位而进行多次反复的沟通    因此就BUG本身的问题，也欢迎技术部能多多提意见我们一定坚绝改正。