育才学习网1.关于怎样写report的问题
我们是否经常看到开发人员针对我们归档的bug report要求提供更多的信息？我们是否经常需要在bug report归档后花更多的时间去研究那个问题？我们是否经常从开发人员那里听到在他们那边难以重现bug并且需要即刻提供可重现的步骤？广义上来说，我们与其花更多的时间在这些问题上还不如投资更多的时间来测试系统。
问题出在bug report的质量上。这里介绍一些如何改进并达到完美bug report的建议。
Bug report的目的 当我们发现一个缺陷时，我们需要把它告诉给开发人员。Bug report就是这种沟通的媒介物。
Bug report的主要目的是让开发人员亲眼看到这个错误。如果你不能和他一起以在他面前制造出那个失败，那么就需要给他们足够多的指引以便他们能够自己制造出那个失败。
Bug report就是解释在期望结果和实际结果之间的差距并且详细的说明如何重现那个场景。 在发现缺陷之后 · 只有当你确信你已经发现一个bug的时候开始起草bug report，不要在测试结束或每天结束之后。
那样，你可能会遗忘掉一些东西。更糟的情况是，我们可能会忘掉那个bug。
· 花一些时间去诊断你正在报告的缺陷。想想可能存在的原因。
可能到最后你会发现更多的缺陷。在你的bug report中说说你的发现。
开发人员将不仅仅对你使他们的工作变得轻松而感到高兴。 · 在开始读你的bug report之前抽出一些时间来。
你可能会感觉到象重新编写报告一样。摘要Bug report的摘要是你bug report给读者的第一印象。
你提交的bug的命运很大程度依赖于你的bug report能否吸引读者。原则就是每个bug应该有一个简单有趣的摘要。
它可能会听上去象编写一个优秀的勾起注意的广告活动。但是随后，没有什么意外。
一个好的摘要应该不超过50到60个字符。而且一个好的摘要不应该承载任何对bug主观的表达。
语言· 不要在bug report中夸大缺陷。同样，也不要太轻描淡写了。
· 不管bug是多么的令人讨厌，别忘了是bug令人讨厌，而不是开发人员。永远不要冒犯开发人员的努力。
使用委婉些的说法。混乱的UI可以被温和些改为不正确的UI。
这样开发人员的努力将会得到尊重。 · 保持简单诚实。
你不是在写散文或文章，因此使用简单的语言 · 在编写bug report的时候记住你的目标读者。他们可能是开发人员，其他的测试人员，经理，或者在一些情况下，甚至是客户。
Bug report应该可以被所有的人理解。 可重现的步骤 · 可重现的步骤的流程应该是合乎逻辑的。
· 清楚的列出前提条件 · 写下平常的步骤。例如，如果一个步骤要求用户创建文件并且为它命名，不要要求用户命名为Mihir's file。
最好命名为好像Test File一样的文件名。 · 在一个干净的系统里测试你的可重现的步骤。
你可能会发现有些步骤被遗漏或是毫无关系的。测试数据尽力编写普通的bug report，开发人员可能没有权限访问你的测试数据。
如果bug是和一组特定的测试数据相关，在你的bug report上附带上它。截屏截屏是bug report中一个十分必要的部分。
一个图片胜过一千句话。但是不要把在每个bug report里附带没有必要的截屏变成一个习惯。
理想的来说，你的bug report应该是足够有效的使开发人员重现问题。截屏应该只是验证的一种方法。
· 如果你要在bug report里附带截屏，要确保那些图片不是太大的，使用jpg或gif的格式，而不是bmp格式 · 在截屏上写上注释以指出问题所在。这将帮助开发人员一眼就可以马上定位问题。
严重程序/优先级别 · 在设置bug report的严重程序之前应该全面的分析缺陷的影响程序。如果你认为你的bug具有很高的优先级应该被修复，在bug report中证明这点。
应该在bug report的描述部分指出这个理由。 · 如果bug是来自上个内部小版本或版本回归的结果，那么发出警报。
象这种bug的严重程序可能是低的，但是优先级别应该是高。日志在bug report里附上日志或日志的摘录片断。
这将帮助开发人员轻松地分析且调试系统。多数情况下，如果不附上日志而且在开发人员那边又很难重现问题的话，他们将会把bug report打回给你并要求附带日志文件。
如果日志文件不太大的话，举个例子，大约20到25行，你就可以把它贴在bug report里。但是如果它比较大的话，把它做为附件贴在bug report里，否则你的bug report会看上去象个日志。
其他信息· 如果你的bug是随机出现的，只需在你的bug report中说一下就可以了。但是不要忘记归档它。
你总是能够在你发现它们之后的任何时间里增加准确的步骤。这也将在其他人提交这个问题时解救你，特别是当那个问题比较严重时。
· 在bug report中写下错误信息，特别是当错误信息有编号的时候。例如，来自数据库中的错误信息。
· 在bug report中写下版本编号和内部小版本编号 · 写下问题可以被重现的平台。准确的说明问题不可重现的平台。
同样也要理解问题在特定平台上不可重现和没有在某个平台上测试之间的分别。这个可能会造成混淆。
· 如果你遇到几个问题却有一样的结果，只需写一个bug report。问题的修复可能只是一个。
同样，如果你在不同的地方遇到相似的问题，且要求同一种修复方法，但是在不同的地方，那么就要为每一个问题书写单独的b。
2.如何写一个强大的bug测试报告
在报告中说“不好用”；所报告内容毫无意义；在报告中用户没有提供足够的信息；在报告中提供了错误信息；所报告的问题是由于用户的过失而产生的；所报告的问题是由于其他程序的错误而产生的；所报告的问题是由于网络错误而产生的；简单地说，报告bug的目的是为了让程序员看到程序的错误。
您可以亲自示范，也可以给出能导致程序出错的、详尽的操作步骤。如果程序出错了，程序员会收集额外的信息直到找到错误的原因；如果程序没有出错，那么他们会请您继续关注这个问题，收集相关的信息。
当您报告bug的时候（既然您已经这么做了），一定是希望bug得到及时修正。所以此时针对程序员的任何过激或亵渎的言语（甚至谩骂）都是与事无补的——因为这可能是程序员的错误，也有可能是您的错误，也许您有权对他们发火，但是如果您能多提供一些有用的信息（而不是激愤之词）或许bug会被更快的修正。
除此以外，请记住：如果是，作者提供给我们已经是出于好心，所以要是太多的人对他们无礼，他们可能就要“收起”这份好心了。“程序不好用”程序员不是弱智：如果程序一点都不好用，他们不可能不知道。
他们不知道一定是因为程序在他们看来工作得很正常。所以，或者是您作过一些与他们不同的操作，或者是您的环境与他们不同。
他们需要信息，报告bug也是为了提供信息。信息总是越多越好。
本文中提到的都是一些指导方针，没有哪一条是必须恪守的准则。不同的程序员会喜欢不同形式的bug报告。
如果程序附带了一套报告bug的准则，一定要读。如果它与本文中提到的规则相抵触，那么请以它为准。
如果您不是报告bug，而是寻求帮助，您应该说明您曾经到哪里找过答案，（例如：我看了第四章和第五章的第二节，但我找不到解决的办法。）这会使程序员了解用户喜欢到哪里去找答案，从而使程序员把帮助文档做得更容易使用。
“演示给我看”这些可能还不够。也许他们觉得还需要更多的信息，会请您重复刚才的操作。
他们可能在这期间需要与您交流一下，以便在他们需要的时候让bug重新出现。他们可能会改变一些操作，看看这个错误的产生是个别问题还是相关的一类问题。
如果您不走运，他们可能需要坐下来，拿出一堆开发工具，花上几个小时来好好地研究一下。但是最重要的是在程序出错的时候让程序员在电脑旁。
一旦他们看到了问题，他们通常会找到原因并开始试着修改。如果您必须报告bug，而此时程序员又不在您身边，那么您就要想办法让bug重现在他们面前。
当他们亲眼看到错误时，就能够进行处理了。“哪儿出错了？在我看来一切正常哦！”如果您给了程序员一长串输入和指令，他们执行以后没有出现错误，那是因为您没有给他们足够的信息，可能错误不是在每台计算机上都出现，您的系统可能和他们的在某些地方不一样。
有时候程序的行为可能和您预想的不一样，这也许是误会，但是您会认为程序出错了，程序员却认为这是对的。特殊情况下，如果有错误消息号，一定要把这些号码告诉程序员。
不要以为您看不出任何意义，它就没有意义。错误消息号包含了能被程序员读懂的各种信息，并且很有可能包含重要的线索。
给错误消息编号是因为用语言描述计算机错误常常令人费解。用这种方式告诉您错误的所在是一个最好的办法。
如果您使用UNIX系统，程序可能会产生一个内核输出（coredump）。内核输出是特别有用的线索来源，别扔了它们。
另一方面，大多数程序员不喜欢收到含有大量内核输出文件的EMAIL，所以在发之前最好先问一下。还有一点要注意：内核输出文件记录了完整的程序状态，也就是说任何秘密（可能当时程序正在处理一些私人信息或秘密数据）都可能包含在内核输出文件里。
3.软件测试 项目总结怎么写啊
在百度文库中搜索一下，找找类似的文档。百
这种东西没有特别的定式，但是内容符合你所参与项目的要求就行。
另外，测试是件很客观度的工作，因此它的报告也应该尽量客观。
通常可以包含以下内容：
对测试目标的总体评价，印象，测试基线等；
项目目的、意义，测试专规划，参与人员与配套属资源，方法选择，测试覆盖率；
测试发现的问题数，修复情况，严重问题的比例，测试周期情况；
强烈建议填写风险评估，根据测试结果分析测试目标可能还存在的问题。
转载请注明出处育才学习网 » bugreport怎么写