他们不知道一定是因为程序在他们看来工作得很正常 。所以 ， 或者是您作过一些与他们不同的操作 ， 或者是您的环境与他们不同 。
他们需要信息 ， 报告bug也是为了提供信息 。信息总是越多越好 。
本文中提到的都是一些指导方针 ， 没有哪一条是必须恪守的准则 。不同的程序员会喜欢不同形式的bug报告 。
如果程序附带了一套报告bug的准则 ， 一定要读 。如果它与本文中提到的规则相抵触 ， 那么请以它为准 。
如果您不是报告bug ， 而是寻求帮助 ， 您应该说明您曾经到哪里找过答案 ， （例如：我看了第四章和第五章的第二节 ， 但我找不到解决的办法 。）这会使程序员了解用户喜欢到哪里去找答案 ， 从而使程序员把帮助文档做得更容易使用 。
“演示给我看”这些可能还不够 。也许他们觉得还需要更多的信息 ， 会请您重复刚才的操作 。
他们可能在这期间需要与您交流一下 ， 以便在他们需要的时候让bug重新出现 。他们可能会改变一些操作 ， 看看这个错误的产生是个别问题还是相关的一类问题 。
如果您不走运 ， 他们可能需要坐下来 ， 拿出一堆开发工具 ， 花上几个小时来好好地研究一下 。但是最重要的是在程序出错的时候让程序员在电脑旁 。
一旦他们看到了问题 ， 他们通常会找到原因并开始试着修改 。如果您必须报告bug ， 而此时程序员又不在您身边 ， 那么您就要想办法让bug重现在他们面前 。
当他们亲眼看到错误时 ， 就能够进行处理了 。“哪儿出错了？在我看来一切正常哦！”如果您给了程序员一长串输入和指令 ， 他们执行以后没有出现错误 ， 那是因为您没有给他们足够的信息 ， 可能错误不是在每台计算机上都出现 ， 您的系统可能和他们的在某些地方不一样 。
有时候程序的行为可能和您预想的不一样 ， 这也许是误会 ， 但是您会认为程序出错了 ， 程序员却认为这是对的 。特殊情况下 ， 如果有错误消息号 ， 一定要把这些号码告诉程序员 。
不要以为您看不出任何意义 ， 它就没有意义 。错误消息号包含了能被程序员读懂的各种信息 ， 并且很有可能包含重要的线索 。
给错误消息编号是因为用语言描述计算机错误常常令人费解 。用这种方式告诉您错误的所在是一个最好的办法 。
如果您使用UNIX系统 ， 程序可能会产生一个内核输出（coredump） 。内核输出是特别有用的线索来源 ， 别扔了它们 。
另一方面 ， 大多数程序员不喜欢收到含有大量内核输出文件的EMAIL ， 所以在发之前最好先问一下 。还有一点要注意：内核输出文件记录了完整的程序状态 ， 也就是说任何秘密（可能当时程序正在处理一些私人信息或秘密数据）都可能包含在内核输出文件里 。
3.软件测试 项目总结怎么写啊在百度文库中搜索一下 ， 找找类似的文档 。百
这种东西没有特别的定式 ， 但是内容符合你所参与项目的要求就行 。
另外 ， 测试是件很客观度的工作 ， 因此它的报告也应该尽量客观 。
通常可以包含以下内容：
对测试目标的总体评价 ， 印象 ， 测试基线等；
项目目的、意义 ， 测试专规划 ， 参与人员与配套属资源 ， 方法选择 ， 测试覆盖率；