從**源頭控制好質量，
團隊中有一人負責整個產品的質量和**審核，對於狗屎**要給予嚴厲的批評。不定期的經常舉行內部培訓，發布後bug彙總總結分析，不斷提高開發團隊技術 水平。發布後出現bug和開發者掛鉤，除了不能解決的，嚴重bug必須在2個工作日內解決，對於不能解決的bug要給出原因：是先期設計導致的？別人的配 合**導致的？還是其他原因。這樣做目的：出了問題，找出原因，避免不再重犯。
軟體測試
軟體測試是控制質量的關鍵。開發者不能完全依靠測試人員（如果存在的話），老一輩的程式設計師已經證明了這點。對於開發和測試之間，測試圍繞開發，而不是以測試為主。如果可能，盡可能的做低成本的自動化測試。
輔助工具
這點有點寬泛，這裡講的是自動化構建、自動化測試、健壯的公用庫及內部輔助工具等等。如果你是個注重短期利益的，這些對你是沒用的，這些並不能給你帶來直 接經濟效益，而是帶來長期效應的基礎。自古以來，將複雜事情變簡單的法子都回歸到模組化和層次化，比如c++語言的發明、iso標準的制訂等等，模組化解 決了同層間的抽象，層次化解決了不同層間的抽象（廢話），乙個橫向的抽象，乙個縱向的抽象。每次看到別人封裝的複雜無比易出錯的c++庫就想罵街，如果 c++讓整個事情變得更複雜了，何必多次一舉去玩封裝呢？好的自動化構建工具從專案的層次對整個原始碼樹進行抽象，把整個複雜的軟體構建流程規範清晰起來， 降低構建對特殊的某個人的依賴，降低因為構建而導致的低階錯誤（比如不好意思這個模組我忘記更新，不好意思我給你的是debug版本的，不好意思我忘記提 交了，不好意思我的編譯引數不對）。 健壯的公用庫也是非常有必要的，比如列舉目錄及子目錄下的檔案、zip檔案的操作、ado的操作、xml檔案操作等等，當然很多都有開源版本，完全依賴開 源自己不去吃透是不靠譜的，**最新和最好是兩回事。
好了，昨天改了一天bug終於修復了乙個藍屏，累的9點不自覺的睡著，然後早上5點不自覺的醒來，然後就有個這篇blog。
軟體開發質量控制研究
軟體質量是指開發出來的軟體不僅可以滿足客戶明確提出來的要求還要滿足某些沒有明確提出來的要求，軟體質量越高，客戶需求滿足度就越高。軟體專案質量控 制不僅僅是控制軟體設計的最終結果，它其實要求貫穿於軟體設計專案的全過程，從軟體開發初期的客戶需求調查，到最終的軟體交付評審，每個階段都要進行仔細 的控制，才...
實用軟體質量控制課程大綱
實用軟體質量控制課程大綱 物件導向 qa 測試工程師 開發工程師 質量經理 專案經理 授課方式 案例分析 工具應用 專案演練 大綱 需求管理與變更控制。需求分析質量控制與需求評審。需求評審演練。規範 質量控制。評審及其自動化。評審工具的應用。單元測試設計。單元測試覆蓋率度量。單元測試工具與框架的應用...
Read alignment後的質量控制
drop low quality alignments each alignment is given a quality score mapq which is equivalent to phred scores with respect to determining relative qual...