從開發的角度看待bug
在工作中，經常有同事問到某個問題是不是bug，該不該提交，而且疑惑為什麼會引起這樣的bug，尤其是剛進入測試行業的同事。這個問題最好的答案就是提交。我基本上碰到這種問題就是鼓勵他們提交他們所疑惑和懷疑的問題，即使後來發現不是問題，留在bug庫中對後來的同事都是一種學習（在此建議給於新同事先看看bug庫中的bug，如果時間不夠也要盡可能的看看非正常結束的bug，如won't fix,not a bug之類的bug，一般對bug的界定有疑惑也就是大家對預期的結果不明確的）。
一般來說，明顯的錯誤（如程式不能繼續執行，出現明顯的錯誤提示框，資料儲存錯誤等）大家都知道肯定是bug，經常有疑問的是對於期望結果模糊，gui（介面，操作模式等）不友好，對比其他的軟體的問題。
由於工作的原因，參與了專案的一些開發過程，發現其實如果從開發的角度看看問題，就更容易下定提交bug的決心的。根據bug的**，以下是我的一些總結：
1。由於**引起的bug
所有的程式都會有bug,而且所有的程式設計師都會製造bug.這個道理如同bug是不可能被完全消滅一樣.對於一般的開發人員，經常出現的問題是由於沒有良好的程式設計習慣和技術能力。每個人從新手到高手都是有個階段的，成長的過程總是充滿錯誤的。開發人員多少會在修改bug的過程中成長。有些可能他們認為無法實現的操作是有可能實現的。所以這種情況要提交bug，即使不能修復，開發人員也會在bug裡填寫理由，這樣對測試人員和開發人員都是有利的。
那麼對於高階的開發人員，低階錯誤的發生概率相對來說少很多，大多的bug是由於功能定義不清晰,完善或是架構，語言的侷限引起的。有些嚴重的問題大家可以一起商量解決的.
2。專案時間緊迫造成的bug
基本上每個專案都有加班的時候，開發人員在緊迫的時間裡能做的就是盡可能的完成功能需要要求的功能，主要的功能。然後有時間再去通過修復bug來完善**。所以測試人員也不要詫異為什麼會有那麼多的bug，要作的就是盡可能的提交你所發現的bug。
在我參與的開發中，專案經理經常會詢問開發人員的進度，如果他發現你已經實現了某乙個模組功能需求的功能後不是馬上開始下乙個模組的開發，而在花時間在竭力地憑著自己的猜想去完善模組時，專案經理一定會要求你把模組提交給測試人員測試，並馬上開始下乙個模組的開發。
3。專案定義模糊造成的問題
有些專案在開始編碼時可能只是乙個大概的專案定義，甚至連具體功能的定義都不是很清楚.有時客戶對產品的最終結果都不清晰，需要乙個有形的東西讓自己不斷的開發出自己的需求。那麼這時開發人員大多都是根據自己的經驗或常識來實現**。
還有就是大多數地需求和設計文件不是面面俱到,只是描述了主要的業務定義.對於一些非主流或異常的處理並沒有詳細的定義.很多情況下程式在負面的操作時就會出現錯誤.
測試人員可能就會發現很多不合理或和其他軟體不同造成的使用者介面的問題，或者有時更會發現負責**實現的開發人員誤解了需求定義人員對功能的解釋，甚至從從源頭上需求定義人員對功能就存在誤解。
雖然有很多原因會引發bug,但是不管什麼原因測試人員都要提交自己認為是問題的問題,即使後來發現bug是由於某種侷限造成的，但對於自己乃至整個專案組都是乙個財富。
只是在bug提交的時候要切記中立客觀,對事不對人.即便開發人員拒絕修改bug,都應該不卑不亢的詢問原因.如果還有問題就讓你們的上級決定,他們會本著對專案考慮的原則從大局上把握好問題的.
以上的我在開發過程中的一些總結。工作這麼長時間，角色也不斷在轉變，發現自己剛進測試這一行業的有些想法是錯誤的。而且體會最深的就是在從別人的角度多去思考問題，這樣有些問題根本就不是問題。
開發和測試的關係永遠都應該是水**融的，互相促進的。建議大家在出現問題的時候多想想為什麼會出現從這樣的問題，問題最終是如何解決的，這樣才不失為經驗積累的好方法。
從scanf角度看待輸入
c primer plus中對scanf進行了一番詳解 假定使用了 d說明符來讀取乙個整數。scanf 函式開始試圖讀取乙個輸入字元，它跳過空白字元直到遇到乙個非空白字元，當碰到整數或者 或者 時，它就儲存並讀取下乙個字元 如果接下來的字元是乙個數字，它就儲存，並讀取下乙個字元直到遇到乙個非數字的字...
從資訊的角度來看待軟體開發
個人感覺，程式開發，是乙個處理資訊的過程。一開始，我們什麼都不知道，需求也是模糊的。在需求分析過程中，我們漸漸能夠看清到底需要完成什麼功能。但是如何實現這樣的功能，我們還是不了解。在設計階段，我們根據需求的內容，嘗試乙個個原型，直至找到合適的，或者根據需求 創造出乙個。事實上，需求的資訊量如此之大，...
從開發人員角度看待效能基準測試
對乙個開發人員來說，除了保質保量按時完成功能需求外，非功能也不可忽視。決定乙個軟體的成敗往往是非功能性需求比如效能，若是使用者體驗不好那麼必定是個失敗的作品。那麼乙個開發人員如何去做關於自己模組又或者整體的基準效能測試呢？以下將從測試的切入點和具體測試的指標來說明。切入點 通常，基準效能測試有兩個切...