本次閱讀了第十三 軟體測試 十四章 質量保障
在軟體發布前基本沒有進行測試，直到上台講述的之前的一段時間才發現了一些問題，甚是著急
第十三章中excel計算1900閏年錯誤的例子給了我乙個全新的概念——要服務於最主要的功能.
傳說中的拐點
小飛： 我聽說在軟體專案中，有這樣乙個拐點存在——在這一點之前，新的bug產生的數量大於bug解決的數量；在這一點之後，bug的解決數量大於新的bug產生的數量。這樣bug的曲線就向下移動。我們移山專案的拐點到了麼？
阿超： 我也聽說過，不過這是在大型複雜專案中，測試人員和開發人員全部通過乙個系統管理bug才會出現的現象。我們不能等待拐點的到來，對於我們這樣的日期驅動型的小專案，拐點必須在發布日之前的若干時間發生，如果我們的bug數量還是繼續向上攀公升，則無法保證以後曲線會像懸崖一樣掉下來。我們就得主動讓拐點發生，例如推遲一些bug，砍掉一些功能，慢慢公升高「必須修復的小強」這個標桿，等等。
這個拐點至今還沒有深刻體會，不過在一段時間內完成超額或者超出預期任務的情況到是有發生。
今後會在大小bug無法取捨的情況下選擇有限解決影響主要功能的bug
由於專業的qa工作沒有深刻了解，暫時先不寫
構建之法閱讀筆記05
時隔多日，自己又重拾 構建之法 今天對需求分析這部分進行了閱讀。當我們程式設計師在編寫軟體之前要做的就是了解使用者的需求，準確而全面地找到需求主要有以下幾個步驟 1 獲取和引導需求 elicitation 我們需要找到軟體的利益相關者，了解和挖掘他們對軟體的需求，引導他們表達出對軟體的需求。很多時候...
構建之法閱讀筆記05
這是構建之法的最後一篇閱讀筆記 這幾天主要閱讀了it的創新這一章，創新在現代的社會中是乙個被說爛了的詞語，各行各業都在提倡創新，就連學校裡也在提倡什麼創新創業大賽 在 構建之法 的創新迷思一節，列舉出了七個迷思，接下來分別作出乙個簡要的概述。迷思之一 偉大的創新總是靈光一現。迷思之二 大家都喜歡創新...
《構建之法》閱讀筆記05
第五次寫閱讀筆記了。第十三章 軟體測試 這章講了各種測試方法和測試的設計方法。一些基本的名字解釋 bug 軟體的缺陷，可分為 症狀 程式錯誤 根本原因 test case 測試用例，描述完整的測試過程 test suite 測試用例集。按測試方法可分為黑箱和白箱 按測試目的可分為 功能測試 非功能測...