测试向开发反馈软件存在的问题，一般是以bug表的形式进行，不可否认，每一位开发人员手头都有很多代码，所以开发人员希望收到错误信息定位明确的bug表，而不是诸如“软件不好用”这样的无用信息。同样，作为测试人员，我们的工作也是尽量的定位问题，向技术支持方向靠拢。

    一份拙劣的bug报告也许是：

   在报告中说“不好用”;

   所报告内容毫无意义；

  在报告中用户没有提供足够的信息；

  在报告中提供了错误信息；

  所报告的问题是由于用户的过失而产生的；

   所报告的问题是由于其他程序的错误而产生的；

   所报告的问题是由于网络错误而产生的；

   所报告的问题是由于相应的环境没有配置好而产生的。

   报告Bug的目的是为了让开发人员看到程序的错误，当然您可以亲自给开发人员示范，当面交流，也可以在bug中给出导致程序出错的、详尽的操作步骤。这里我建议尽量用bug管理工具提出，这样做回归测试的时候，就能够有迹可循有据可依，同时也能够规范bug管理的过程。

   在一个bug表中，我们希望能够包含尽量完整的信息：

 1、提供测试环境及版本信息，最好包括软硬件，也许您遇到的问题并不是软件本身的问题，而是测试环境配置的问题，是开发人员在自测的时候用的环境与您使用的环境不同导致的，所以，请给他们提供详尽的信息，帮助他们定位问题所在。

 2、提供能让问题重现的详尽的操作步骤，最好附上操作截图，让开发人员知道问题是怎么产生的，您的操作与他们的操作有什么不一样。

 3、描述清楚您所遇到的问题，呈现事实，不要隐藏测试中的任何步骤任何可能，也许就是一个小小的空格或回车也会导致预期结果出错（这个我遇到多次，一个业务系统中导入数据时，在存储数据的txt文件中很自然的在最后一行按了下回车，结果导致数据导入总是出错，这种问题您可以选择规范自己的操作，但是用户不一定会这么规范，也可以强烈要求开发修改代码兼容回车空格等字符，这样就更通用）。

4、尽可能的提出自己的见解、猜测，为开发提供定位问题、解决问题的思路，一个好的测试人员一份好的测试报告一个优秀的技术支持人员是需要能够独立定位问题的，当开发人员看到您的bug报告，能够很快的修改问题的时候，他们会很感激您的，也会很乐意接受您提的bug,也许会主动请您协助测试呢。

 5、测试中您可能会发现很多问题，很恼火很心烦，这个时候请平心静气的对待，不要在bug报告中发泄您的情绪，不是每一个开发人员都能够提供零缺陷的代码的，要知道这是一个成长的过程，将心比心的对待。

6、对于自由软件，在提bug报告之前，请仔细阅读已有的bug列表，如果您发现的bug已经存在列表中，那就不必要报告了，如果您知道问题所在或者掌握的信息较多较全面，请联系软件开发人员，帮助他们尽快修改bug.

    其实最好的报告bug的形式是把您发现的错误演示给开发人员看，开发人员对自己负责的代码非常熟悉，对每一个操作步骤关系到的代码都心里有数，从您的演示过程演示细节中，也许他们能够立即知道错误所在。但是很多时候，您没有和开发人员面对面交流的机会，这个时候就需要把您操作的步骤以bug表的形式详细的告诉开发人员，比如您按了哪些按钮，以什么样的顺序执行的，需要上传的文件副本是什么，做了哪些边界操作等，如果是命令行形式，那么您先后使用了哪些命令。如果您在测试过程中发现了一些错误消息、错误消息号、无故的消息时延，记得一定要把这些信息告诉开发人员，也许在你看来没有用的信息，对开发修改错误却特别有用。

    总结下，一份bug报告中需要包括的内容有：测试环境描述、详细操作步骤、软件错误描述、猜测错误原因、提供解决方案。

    测试向开发反馈软件存在的问题，一般是以bug表的形式进行，不可否认，每一位开发人员手头都有很多代码，所以开发人员希望收到错误信息定位明确的bug表，而不是诸如“软件不好用”这样的无用信息。同样，作为测试人员，我们的工作也是尽量的定位问题，向技术支持方向靠拢。