首先想好:
問題要肯定、詳細
- 是什麼東西不工做了?
- 現象和結果是什麼?
- 出什麼樣的錯誤?
- 詳細的狀況是如何的?
- 問別人以前先問本身一遍,把這些想清楚了再問別人,節省你們的時間。
提問以前本身先研究調查一下
- 問別人以前最好本身先找找答案。
- 對於顯而易見的問題,不調查一下就隨便去問很是招人討厭,尤爲是在一些論壇裏。
- 至少你應該先看看用戶手冊,搜一搜google再去麻煩別人。
- 搜不到再去問別人,可以告訴別人「我查過手冊,但是沒有」或者「我搜了google,但是沒有找到」,至少你努力過,別人幫助你的概率也會大很是多。
問正確的人
- 有時候抓到一我的巴不得什麼問題都問他,就好像在論壇裏亂髮帖子問問題,對別人有時候也是一種困擾。
- 找到正確的人,去正確的地方,你的問題纔有可能獲得回答,放過其它可憐的羣衆吧。
讓被問的人認爲值得回答你的問題
「你作的這個軟件根本不工做!我都快瘋了!當即幫我解決問題!」程序員
- 你多是快瘋了,可是假設把你的這樣的情緒傳達給別人,未必有什麼正面影響。
「你好,我對你的軟件很是有興趣,正準備在個人blog裏宣傳一下,可是我碰到了一些問題!」
- 這樣別人多半有興趣幫你解決問題,並且很是願意和你這樣一個熱心的測試人員合做。
謹慎明確的描述症狀
- 提供問題發生的環境(機器配置、操做系統、應用程序以及別的什麼)
- 說明你在提問前是怎樣去研究和理解這個問題的
- 說明你在提問前採起了什麼步驟去解決它
- 羅列最近作過什麼可能有影響的硬件、軟件變動
- 儘可能想象一個程序員會怎樣反問你,在提問的時候預先給他答案
- 你須要提供精確有效的信息。這並非要求你簡單的把成噸的出錯代碼或者數據徹底轉儲摘錄到你的提問中。若是你有龐大而複雜的測試條件,儘可能把它剪裁得越小越好。 這樣作的用處至少有三點。 第一,表現出你爲簡化問題付出了努力,這可使你獲得回答的機會增長; 第二,簡化問題使你獲得有用答案的機會增長; 第三,在提煉你的bug報告的過程當中,也許你本身就能找出問題所在或做出更正。