关于如何描述Bug

      开发人员经常会遇到这样的问题：测试人员Bug提交上来之后，关于问题的描述，看得一头雾水，不知说云，然后不得不打电话给测试人员，询问Bug的细节，这样既浪费时间，而且当此Bug转给其他开发人员解决时，又会重现这样的情形。如何最大限度的避免此种情况，结合自己的经验认为一个“好”的Bug应该包括下列信息：

1.重现Bug的操作步骤（可以参照测试用例的操作步骤写）

2.错误的结果

3.预期的结果，或者期望的改动

4.附件（图片、文档说明等）