首先想好：

问题要确定、详细

• 是什么东西不工作了？
• 现象和结果是什么？
• 出什么样的错误？
• 详细的情况是如何的？
• 问别人之前先问自己一遍，把这些想清楚了再问别人，节省大家的时间。

提问之前自己先研究调查一下

• 问别人之前最好自己先找找答案。
• 对于显而易见的问题，不调查一下就随便去问非常招人讨厌，尤其是在一些论坛里。
• 至少你应该先看看用户手冊，搜一搜google再去麻烦别人。
• 搜不到再去问别人，能够告诉别人“我查过手冊，可是没有”或者“我搜了google，可是没有找到”，至少你努力过，别人帮助你的几率也会大非常多。

问正确的人

• 有时候抓到一个人恨不得什么问题都问他，就好像在论坛里乱发帖子问问题，对别人有时候也是一种困扰。
• 找到正确的人，去正确的地方，你的问题才有可能得到回答，放过其它可怜的群众吧。

让被问的人认为值得回答你的问题

“你做的这个软件根本不工作！我都快疯了！立即帮我解决问题！”

• 你可能是快疯了，但是假设把你的这样的情绪传达给别人，未必有什么正面影响。
  “你好，我对你的软件非常有兴趣，正准备在我的blog里宣传一下，但是我碰到了一些问题！”
• 这样别人多半有兴趣帮你解决问题，而且非常愿意和你这样一个热心的測试人员合作。

谨慎明确的描述症状

• 提供问题发生的环境（机器配置、操作系统、应用程序以及别的什么）
• 说明你在提问前是怎样去研究和理解这个问题的
• 说明你在提问前采取了什么步骤去解决它
• 罗列最近做过什么可能有影响的硬件、软件变更
• 尽量想象一个程序员会怎样反问你，在提问的时候预先给他答案
• 你需要提供精确有效的信息。这并不是要求你简单的把成吨的出错代码或者数据完全转储摘录到你的提问中。如果你有庞大而复杂的测试条件，尽量把它剪裁得越小越好。
  这样做的用处至少有三点。
  第一，表现出你为简化问题付出了努力，这可以使你得到回答的机会增加；
  第二，简化问题使你得到有用答案的机会增加；
  第三，在提炼你的bug报告的过程中，也许你自己就能找出问题所在或作出更正。