1. 如何保證軟體的質量
軟體質量保證（SQA）是一種應用於整個軟體過程的活動，它包含：
⒈一種質量管理方法
⒉有效的軟體工程技術（方法和工具）
⒊在整個軟體過程中採用的正式技術評審
⒋一種多層次的測試策略
⒌對軟體文檔及其修改的控制
⒍保證軟體遵從軟體開發標准
⒎度量和報告機制
SQA與兩種不同的參與者相關 —— 做技術工作的軟體工程師和負責質量保證的計劃、監督、記錄、分析及報告工作的SQA小組。
軟體工程師通過採用可靠的技術方法和措施，進行正式的技術評審，執行計劃周密的軟體測試來考慮質量問題，並完成軟體質量保證和質量控制活動。
SQA小組的職責是輔助軟體工程小組得到高質量的最終產品。SQA小組完成：
⑴為項目准備SQA計劃。該計劃在制定項目規定項目計劃時確定，由所有感興趣的相關部門評審。
·需要進行的審計和評審；
·項目可採用的標准；
·錯誤報告和跟蹤的規程；
·由SQA小組產生的文檔；
·向軟體項目組提供的反饋數量。
⑵參與開發項目的軟體過程描述。評審過程描述以保證該過程與組織政策，內部軟體標准，外界標准以及項目計劃的其他部分相符。
⑶評審各項軟體工程活動，對其是否符合定義好的軟體過程進行核實。記錄、跟蹤與過程的偏差。
⑷審計指定的軟體工作產品，對其是否符合事先定義好的需求進行核實。對產品進行評審，識別、記錄和跟蹤出現的偏差；對是否已經改正進行核實；定期將工作結果向項目管理者報告。
⑸確保軟體工作及產品中的偏差已記錄在案，並根據預定的規程進行處理。
⑹記錄所有不符合的部分並報告給高級領導者。
2. 軟體開發過程中,怎麼樣才能保證軟體質量
摘要
3. 如何做好軟體的質量管理
在實際的項目質量管理中，質量管理總是圍繞著質量保證(Quality?Assurance)過程和質量控制(Quality?Control)過程兩方面。這兩個過程相互作用，在實際應用中還可能會發生交叉。正如引言所述，關於軟體的質量，很難下一個非常明確的定義。本文主要針對軟體工程中的質量管理來進行討論。
1、做軟體「大餐」的工序
軟體質量保證（Software?Quality?Assurance，以下簡稱SQA）的目的是驗證在軟體開發過程中是否遵循了合適的過程和標准。軟體質量保證過程一般包含以下幾項活動：
首先是建立SQA組；其次是選擇和確定SQA活動，即選擇SQA組所要進行的質量保證活動，這些SQA活動將作為SQA計劃的輸入；然後是制定和維護SQA計劃，這個計劃明確了SQA活動與整個軟體開發生命周期中各個階段的關系；還有執行SQA計劃、對相關人員進行培訓、選擇與整個軟體工程環境相適應的質量保證工具；最後是不斷完善質量保證過程活動中存在的不足，改進項目的質量保證過程。
獨立的SQA組是衡量軟體開發活動優劣與否的尺度之一。SQA組的這一獨立性，使其享有一項關鍵權利――「越級上報」。當SQA組發現產品質量出現危機時，它有權向項目組的上級機構直接報告這一危機。這無疑對項目組起到相當的「威懾」作用，也可以看成是促使項目組重視軟體開發質量的一種激勵。這一形式使許多問題在組內得以解決，提高了軟體開發的質量和效率。
4. 軟體測試中如何保證軟體質量
軟體在沒有發布之前的開發過程主要分為需求分析、設計、編碼和驗證四個階段，最終的軟體質量與這四個階段的各自質量之間的關系如果用C語言來表達的話應當是： 最終的軟體質量 = 需求分析質量 && 設計質量 && 編碼質量 && 驗證質量 即，最終的質量來自於各階段質量之「與」，只要其中一個環節質量是差，則產品的整體質量都將是差，千萬不要認為是「或」的關系。由此看來每一個階段的質量都起著決定性的作用。 以上提及的四個階段的質量將引出以下幾個軟體質量保證的關鍵要素。 完備的需求分析 需求分析的目的是讓項目組明白要做什麼，是決定所開發出來的軟體應當是「長什麼樣的」，顯然完備的需求分析是高質量軟體的前提。如果所開發出來的軟體與用戶所希望的並不一致，那不可能讓用戶說「這個軟體的質量很好」 。如果方向不對，軟體開發得再「好」也沒有意義。需求分析失誤所帶來的開發成本是高昂的，這一點在《軟體工程》這類書籍中都會提及，因此，整個行業對於需求分析的重要性都具有足夠的認識。當然，知道其重要性與如何獲得完備的需求分析又是兩回事，至於如何做好需求分析請讀者參考相關書籍。 需求分析如果出現失誤的話有一個特點—— 它一定會暴露！只不過存在是暴露在軟體開發過程中還是在用戶手中之別。因此，需求分析所造成的問題盡管嚴重，但它能被發現進而能得到項目組的重視，從而也一定能被修復，只是不同階段發現這類問題所花費的成本將有所不同。 設計 設計階段是通過設計方法找出軟體實現更好的方法，注意這里是「更好」兩個字，而不是強調最好。 不良設計並不會象需求分析失誤那樣很容易暴露出其本質，相反，它所暴露出的更多是表象，比如邏輯復雜、維護時舉步為艱等等。如果參與者不具備一定的洞察力以發現隱藏在現象背後的不良設計本質，則很有可能身受其害卻不能自拔，還以為「本來就有那麼復雜」。 項目的開發是一個逐步演進的過程，項目組成員對於需求的理解也是逐步加深的，一開始合適的設計到後面看來很有可能就不夠全面或顯得力不從心，如果仍沿用以前的設計則自然將暴露出它的不足，進而會出現需要更高的維護成本。重構思想的提出，就是用於幫助項目演進設計的，當然，在運用重構方法時，應盡可能保證項目有足夠的單元測試用例，以預防重構時又引入新的缺陷。重構不只是一個詞，其核心應當是一個方法論，一個用於優化設計的方法論。 編程好習慣 設計階段輸出的結果就是藍圖，但好的藍圖並不能保證最後的質量一定就好。拿造房子打個比方，圖紙設計得再好，如果建造時用的材料不過關，那最終的房子一定好不了。那軟體開發中的「建築材料」又是什麼呢？就是程序員所編寫的代碼。如何保證其質量呢？這需要通過良好的編程習慣去保證。 在現實的項目中，設計有可能與編碼會有一定的揉合，即通過進行一定的編碼來輔助設計。這種實踐方式並不影響這里將設計與編碼分為兩個質量保證關鍵要素。 驗證 驗證很容易讓人想到質量保證的常用方法之一，即測試。但驗證應當包含更多的內涵，比如求證軟體需求是用戶所希望的就是其中的一種。 對於驗證的理解仍需要拿房屋的建造作為一個比方，以便加深理解。在房屋的建造過程中，當建築材料到了工地以後，需要對其進行檢驗，以保證它的質量是合格的，否則不能用於建造。對應於軟體開發，這個階段就是單元測試。當軟體工程師編寫了代碼以後如何保證代碼的行為是其所希望的呢？那隻能通過單元測試去驗證。房子建造好了以後，還得對房子進行整體的驗收以確保其最終是合格的。比如抽查牆壁所使用的水泥與沙的配比是合適的。雖然水泥和沙在進入工地時都經過了質檢且是合格的，但在建造的過程中需要按一定的比例混合它們以作建築粘合劑，而混合比例將確定粘合強度。在軟體開發過程中，軟體集成測試就如同房子在建造好了以後的驗收。 從上面的比方能得出幾個結論。第一，在軟體開發過程中單元測試是必不可少的。它的缺少如同將沒有檢驗過的建築材料用於建造一樣。第二，單元測試應當在集成測試之前完成。有的項目在一開始時並沒有單元測試流程，但後來發現需要增加這個環節，於是出現了集成測試完成了以後，再進行單元測試這種情形。這種情形還是有點怪怪的，這如同房子已造好了，再將牆打掉去檢查裡面的磚是否是好的一樣。「將牆打掉檢查磚」這種行為的勇氣雖然可佳，但是如果盡早地在項目中部署單元測試就能避免這種怪現象的發生。 集成（包括開發集成和系統集成）測試在軟體行業被廣泛採用以保證軟體質量，但單元測試對於軟體質量保證的重要性在整個行業還缺乏廣泛的、深刻的認識，其更多地被當作是負擔而不是一種有效的質量保證手段。
5. 測試人員如何保證軟體質量
2. 風險評估：這個能力非常重要，項目的每個階段都可能存在風險：需求不明確、系統設計或測試設計不完善、代碼編寫不安全、測試用例不充足、測試人員未完全測試、測試資源不足、回歸工作量估計不當、項目進度安排不妥、其他項目對本項目的影響等等，所以項目過程中要具有高度警惕性，尤其要做到開發和測試善始善終。 3. 缺陷預防：個人認為做到很好的缺陷預防是需要綜合素質的，如熟練的業務能力，最好能夠熟知各產品間的關聯，如果能夠知道產品實現方法及過程最好不過。能夠及時根據當前其他產品發布出現的問題預測對本項目的影響度並做好相關缺陷分析。 4. 溝通能力：往往測試和開發容易處於對立面，不和諧的團隊對項目的質量必然帶來一定的負面影響，畢竟人的情緒在工作中對工作效率的影響力是非常大的，軟體質量是靠開發測試一起保證的，記得在測試技術交流大會中郭芙老大說過開發人員的測試意識不是天生具有的，當遇到開發人員測試觀念不足時需要測試人員去指導開發人員，提高開發人員的測試意識。不能把開發人員測試意識不足當作產品質量不好的理由，所以在這個過程中溝通能力是一個很好的體現。 5. 時間管理：會管理時間的人往往離成功更近一步，如何利用時間解決緊急的項目問題、沖突問題、資源安排問題、測試用例的執行的先後順序等講究時間效率方法是保證質量的因素之一。
6. 如何提高軟體的質量
一、什麼是質量？ 作為軟體產品的銷售人員，市場人員或維護人員經常會受到客戶這樣那樣的指責或抱怨，客戶說：你們產品的質量太差，不穩定等等。那麼什麼是質量呢？我們該如何來衡量質量呢？ 質量具有三個維度： �6�1 符合目標。目標是客戶所定義的，符合目標即判斷我們是不是在做需要做的事情。 �6�1 符合需求。即產品是不是在做讓它做的事情。 �6�1 符合實際需求。實際的需求包括用戶明確說明的和隱含的需求。 ISO 關於質量的定義表示如下： 「 一個實體（產品或服務）的所有特性，基於這些特性可以滿足明顯的或隱含的需要。 」 注意，在這個定義中包含明顯的需求和隱含的需求。而往往我們會忽略隱含的需求。因此在控制一個產品的質量的過程中必須關注這些隱含的需求，並給予應有的驗證。 另一方面因為我們的產品是為客戶提供服務的，因此凡是不滿足客戶需求的，我們都認為是一個失效（ failure ）。所以我們的產品必須始終圍繞著客戶的需求進行開發和驗證。 這里我們談到客戶，其實在一個軟體的需求收集過程中需要關注客戶和用戶。而我們經常會忽略客戶與用戶之間的區別。那麼誰是客戶？誰是用戶呢？簡單的來說，客戶是真正能夠決定是否購買你軟體的人，而用戶是實際使用軟體的人。了解了這個區別，對於你在分析需求的重要性的時候就可以進行參考。同時在產品質量驗證的時候也可以做出不同的權衡。另一方面我們在考慮我們用戶需求的時候，往往只考慮了實際使用軟體的人員，而忽略了其它一些人員對軟體的要求或對軟體造成的潛在競爭，這包括維護人員的要求、系統管理人員的要求、軟體上下遊人員的要求、先前版本的情況、市場上競爭對手的軟體情況等。 每個人提到質量的時候，經常會遇到下列矛盾，在這些矛盾中隱含著對質量的承諾【 5 】： �6�1 質量需要一個承諾，尤其是高層管理者的承諾。但為了得到質量，高層管理者必須和其僱用的員工進行緊密合作； �6�1 許多人相信沒有缺陷的產品和服務是不可能的。但是控制在一定級別的缺陷數是正常並可接受的； �6�1 質量經常是和成本緊密聯系在一起，一個高質量的產品同時也意味著高投入。這是設計的質量和一致性質量的一個矛盾； �6�1 一個高的質量要求需求規格說明書足夠詳細，以便產品可以根據這些規格說明書進行定量的分析。然而許多組織沒有能力或者不願意產生如此詳細程度的規格說明書； �6�1 技術人員經常相信規范和標准會束縛他們的創造力，因此就不遵照標准做事。然而如果要得到高質量的產品，就必須遵循良好定義的標准和過程。 二、流程對質量的貢獻 好了，既然已經了解了什麼是質量，那麼怎麼才能改進軟體產品的質量呢？從一個企業的長遠發展來看，首先應當從流程抓起，規范軟體產品的開發過程。這是一個軟體企業從小作坊的生產方式向集成化、規范化的大公司邁進的必經之路，也是從根本上解決質量問題，提高工作效率的一個關鍵手段。 軟體產品的開發同其它產品（如汽車）的生產有著共同特性，即需要按一定的過程來進行生產。在工業界，流水線生產方式被證明是一種高效且能夠比較穩定地保證產品質量的一種方式。通過這種方式，不同的人員被安排在流程的不同位置，最終為著一個目標共同努力，這樣可以防止人員工作間的內耗，極大的提高工作效率。並且由於其過程來源於成功的實例，因此其最終的產品質量能夠滿足過程所設定的范圍要求。軟體工程在軟體的發展過程中吸取了這個經驗並把它應用到了軟體開發中，這就形成了軟體工程過程，簡單的說就是開發流程。 無論做什麼事情，都有一個循序漸進的過程，從計劃到策略再到實現。軟體流程就是按照這種思維來定義開發過程，它根據不同的產品特點和以往的成功經驗，定義了從需求到最終產品交付的一整套流程。流程告訴我們該怎麼一步一步去實現產品，可能會有那些風險，如何去避免風險等等。由於流程來源於成功的經驗，因此，按照流程進行開發可以使得我們少走彎路，並有效的提高產品質量，提高用戶的滿意度。 目前流行的流程方法有很多種，不同的過程模型適合於不同類型的項目。瀑布模型是應用的最為廣泛的一種模型，也是最容易理解和掌握的模型，然而它的缺陷也是顯而易見的。遺漏的需求或者不斷變更的需求會使得該模型無所適從。然而，對於那些容易理解但很復雜的項目，採用瀑布模型會是比較適合的，因為你可以按部就班的去處理復雜的問題。在質量要求高於成本和進度要求的時候，該模型表現的尤其突出。 螺旋模型是也是一個經典模型，它關注於發現和降低項目的風險【 8 】。螺旋型項目從小的規模開始，然後探測風險，制定風險控制計劃，接著確定下一步項目是否還要繼續，然後進行下一個螺旋的反復。該模型的最大優點就是隨著成本的增加，風險程度隨之降低。然而螺旋模型的缺點是比較復雜，且需要管理人員有責任心，專注以及有管理方面經驗。 RUP （ Rational Unified Process ）是 Rational 公司提出的一套開發過程模型，它是一個面向對象軟體工程的通用業務流程【 9 】。它描述了一系列相關的軟體工程流程，它們具有相同的結構，即相同的流程構架。 RUP 為在開發組織中分配任務和職責提供了一種規范方法，其目標是確保在可預計的時間安排和預算內開發出滿足最終用戶需求的高品質的軟體。 RUP 具有兩個軸，一個是時間軸，這是動態的。另一個是工作流軸，這是靜態的。在時間軸上， RUP 劃分了四個階段：初始階段、細化階段、構造階段和發布階段。每個階段都使用了迭代的概念。在工作流軸上， RUP 設計了六個核心工作流程和三個核心支撐工作流程，核心工作流軸包括：業務建模工作流、需求工作流、分析設計工作流、實現工作流、測試工作流和發布工作流。核心支撐工作流包括：環境工作流、項目管理工作流和配置與變更管理工作流。具體可以參考圖 1 。 RUP 匯集現代軟體開發中多方面的最佳經驗，並為適應各種項目及組織的需要提供了靈活的形式。作為一個商業模型，它具有非常詳細的過程指導和模板。但是同樣由於該模型比較復雜，因此在模型的掌握上需要花費比較大的成本。尤其對項目管理者提出了比較高的要求。 圖1 RUP 工作流程示意圖 IPD （ Integrated Proct Development ）流程是由 IBM 提出來的一套集成產品開發流程，非常適合於復雜的大型開發項目，尤其涉及到軟硬體結合的項目。 IPD 從整個產品角度出發，流程綜合考慮了從系統工程、研發（硬體、軟體、結構工業設計、測試、資料開發等）、製造、財務到市場、采購、技術支援等所有流程。是一個端到端的流程。在 IPD 流程中總共劃分了六個階段（概念階段、計劃階段、開發階段、驗證階段、發布階段和生命周期階段），四個個決策評審點（概念階段決策評審點、計劃階段決策評審點、可獲得性決策評審點和生命周期終止決策評審點）以及六個技術評審點，具體可以參考圖 2 。 IPD 流程是一個階段性模型，具有瀑布模型的影子。該模型通過使用全面而又復雜的流程來把一個龐大而又復雜的系統進行分解並降低風險。一定程度上，該模型是通過流程成本來提高整個產品的質量並獲得市場的佔有。由於該流程沒有定義如何進行流程回退的機制，因此對於需求經常變動的項目該流程就顯得不大適合了。並且對於一些小的項目，也不是非常適合使用該流程。 圖2 IPD 流程示意圖 三、流程與技術 流程和成功不是等價的。沒有流程就成功是不可能得到保證，但有了流程並不意味著肯定能夠成功。這恐怕是很多迷信於流程的人所不能接受的。但這的確是個事實。記得有個做了將近 30 多年的需求分析專家說過：即使是一個已經達到 CMM4 級的公司，也完全有可能做不好需求分析。為什麼？技術，技術是成功的另外一個必要條件。就好比現在你要從上海到北京去，流程給你指出了最短的路徑，技術提供給你最快的交通工具。兩者結合就是完美。 對於軟體開發來說，要保證軟體的質量，需要掌握多方面的技術，包括分析技術、設計技術、編碼技術和測試技術等等。在國內有一個普遍的非正常現象，就是大家覺得只有編程能力才是玩電腦的真正技能。就好像造一套房子，其它都不重要，只要磚瓦匠有高超的技能就行了。盡管這個比喻會打擊很多程序員的自尊心，但這的確是一個事實。我們缺少系統級的工程師，在分析和設計方面的工作做得很不扎實。 需求是一個項目的靈魂。模稜兩可的需求帶來不可避免的後果便是返工 —— 重做一些你認為已做好的事情。返工會耗費開發總費用的 4 0 % ，而 7 0 % ～ 8 5 % 的重做是由於需求方面的錯誤所導致的（ l e ff i n g w e l l1 9 9 7 ）【 10 】。想像一下如果你能減少一半的返工會是怎樣的情況？你能更快地開發出產品，在同樣的時間內開發更多、更好的產品，甚至能偶爾回家休息休息。在《軟體需求》一書中關於如何進行需求分析給出了比較詳細的介紹【 7 】， RUP 中關於需求的指導也是很實用的。 設計是最能體現一個工程師能力和水平的環節。一個好的設計基本上決定了產品的最終質量。設計是把需求轉換成系統的一個關鍵步驟，它需要從自然語言描述的需求中尋找出設計的基礎單元，構建出整個系統的構架。在 RUP 中關於系統構架師和設計師的定位是相當高的。關於設計方面的技能涉及面是很廣的，包括傳統的結構化設計到面向對象設計。設計人員需要掌握一定的建模技術。 UML 是國際上比較流行的一種建模語言【 11 】。在嵌入式方面， SDL 也是一種非常好的選擇。《設計模式》是在設計思想方面總結的非常出色的一本書【 6 】，作為一名設計人員（尤其是面向對象設計人員）必須要好好研究一下。但是對這些模式的應用應當講究一種自然的應用，千萬不要因為模式而去設計模式，否則會適得其反。 現在的程序員熱中於掌握多種編程語言，或者講究語言的過分技巧化，而往往忽略了編程語言的規范化。不規范的語言應用給程序的可理解性、可維護性以及可測試性帶來了大的傷害，進而損害了產品的質量。某公司曾對中國程序員和印度程序員做過一個測驗，這個測驗要求參加者對一組數進行排序。測試結果發現，印度程序員設計的程序使用的演算法並不是最優，但卻是最不容易出錯的，並且幾個程序員寫出來的代碼如出一轍。而幾個中國程序員寫出的代碼，有的非常漂亮，很精練，效率很高；有的卻很冗雜，還有錯誤。如果大家是在做研究性的項目或純粹興趣性的項目，那麼充分發揮自己的編程天才也無可厚非。然而，對於一個軟體公司，產品最終是要交給用戶的，需要遵循的是一個軟體產品的開發工程。因此這類軟體的開發需要遵循一定的編程規范，畢竟開發的軟體不是自己用，還需要和別人的集成，還需要給以後版本重用和維護。 測試的技術將在第五節進行闡述。總之流程很關鍵，技術也很重要，我的觀點是：魚和熊掌，兩者都不能放。 四、全面質量管理 自從 Deming 的全面質量管理（ TQM ）原則在日本工業界獲得了巨大成功之後，這個原則迅速被傳播到了世界各個地方，同樣，全面質量管理原則也被應用到了軟體開發當中。如前面提到的，軟體開發也是一個工程性的工作，因此必須提高整個工程的質量。產業界的大量研究（ TRW 、 Nippon Electric 和 Mitre Corp. 以及其它一些公司）表明設計活動引入的錯誤占軟體過程中出現所有錯誤（和最終的缺陷）數量的 50 ％到 65 ％。根據 IBM 的研究表明，假定在分析階段發現的錯誤其改正成本為 1 個單位的話，那麼在測試之前（設計編碼階段）發現一個錯誤的修改成本約為 6.5 個貨幣單位，在測試時（集成測試，系統測試和驗收測試）發現一個錯誤的修改成本約為 15 個貨幣單位，而在發布之後（已經交到用戶手上）發現一個錯誤的修改成本約為 60 到 100 個貨幣單位。同樣該比例也適用用於發現一個錯誤需要的時間。我們可以看下面兩條曲線圖： 圖3 缺陷代價曲線 為了提高產品質量，縮短產品開發進度，節約產品開發成本，必須盡早的進行產品質量控制。全面質量控制要求在過程的每個階段每個步驟上都要進行嚴格的驗證和確認活動。 什麼是驗證？ 驗證 就是要用數據證明我們是不是在正確的製造產品。注意這里強調的是過程的正確行【 12 】。 什麼是確認？ 確認 就是要用數據證明我們是不是製造了正確的產品。注意這里強調的是結果的正確性。 IEEE 給出的驗證和確認過程可以用下圖來表示。驗證和確認是一個廣泛的概念，感興趣的讀者可以參考 IEEE Std 1012-1998 。
圖4 驗證和確認模型 五、關注測試 軟體測試是軟體質量控制中的關鍵活動。業界的統計數據表明，測試的成本大約占軟體開發總成本的 50 ％左右。 軟體測試的目的是要發現軟體中的錯誤。一個好的測試是發現至今沒有被發現的錯誤。傳統的軟體測試專注於動態測試范疇，如：單元測試，集成測試和系統測試。而測試工程的發展已經進入到了全流程的測試，包括開發過程前期的靜態測試。 一般我們可以把測試分為白盒測試和黑盒測試。 白盒測試 ：顧名思義，白盒測試應當是透明的。的確，該類測試是根據程序代碼的內部邏輯結構來設計測試用例進行測試。那麼什麼是測試用例？ 一個 測試用例 就是一個文檔，描述輸入、動作、或者時間和一個期望的結果，其目的是確定應用程序的某個特性是否正常的工作。 黑盒測試 ：看了白盒測試的解釋，我想你很快就能猜出黑盒測試是不考慮程序內部結構情況的。事實上也是這樣。黑盒測試是根據規格說明書進行的測試。 規格說明書 記錄了用戶的需求。比如用戶希望在編輯器中增加查找功能，那麼我們把該需求寫入規格說明書，根據該項要求，直接調用應用程序的該項功能進行測試，而不管其內部是用什麼演算法實現的。 白盒和黑盒這兩類測試是從完全不同的出發點，並且是兩個完全對立點，反映了事物的兩個極端，兩種方法各有側重，不能替代。但是在現代測試理念中，這兩種測試往往不是決然分開的，一般在白盒測試中交叉使用黑盒測試的方法，在黑盒測試中交叉使用白盒測試的方法。 常見的白盒測試是單元測試。 單元測試 是測試中最小單位的測試。簡而言之，就是拿一個函數出來，加上驅動模塊，樁模塊，讓它能夠運行起來，然後設計一些用例測試其內部的控制點（如：條件判斷點，循環點，選擇分支點等）。 驅動模塊 是模擬調用被測函數的函數。 樁函數 是模擬當前測試函數所調用的函數。 常見的黑盒測試包括：集成測試，系統測試。 集成測試 是在單元測試的基礎上，將所有模塊按照設計要求（如根據結構圖）組裝成為子系統或系統，進行集成測試。實踐表明，一些模塊雖然能夠單獨地工作，但並不能保證連接起來也能正常的工作。程序在某些局部反映不出來的問題，在全局上很可能暴露出來，影響功能的實現。 系統測試 的目的在於通過與系統的需求定義作比較，發現軟體與系統定義不符合或與之矛盾的地方。系統測試的測試用例應根據需求分析說明書來設計，並在實際使用環境下來運行。系統測試的內容極其廣泛，包括功能測試、協議測試、性能測試、壓力測試、容量測試等等。有關測試方面的概念可以參考本人已出版的《軟體測試技術概論》。 軟體測試是產品最終交付到用戶之前的最後一道防線，有著舉足輕重的地位。然而，做好軟體測試卻是不容易的，一方面你需要同時掌握軟體開發的技能和軟體測試方面的技能；另一方面產品必須給予測試充分的獨立性和資源保證。 六、成功的鐵三角 在一個軟體企業中，如果能夠良性的發展，必須關注組織，流程和人三者之間的關系。組織是流程成功實施的保障，好的組織結構能夠有效的促進流程的實施；流程對於產品的成功有著關鍵的作用，一個適合於組織特點和產品特點的流程能夠極大的提高產品開發的效率和產品質量，反之則會拖延產品開發進度，並且質量也無法得到保證；對企業來說，人是最寶貴的財富，它們是技術的載體。對於一個軟體公司來說，無論是開發人員還是測試人員，都非常關心其今後的發展通道，如果有一條清晰的技術發展線為其指明今後的職業發展方向的話，這可以大大激勵員工的士氣和工作積極性。另外技術發展的方向應該與現在的開發流程和規范相結合，這樣有利於專業技能的提高。 總之，組織，流程和人這三者是一個企業成功的鐵三角，理想的情況下它們彼此促進，糟糕的情況下它們彼此制約。 七、國際上流行的質量標准 最早進入國內的質量標準是 ISO 系列。在軟體方面主要使用 ISO9000 系列標准。 ISO9000 是一個非常完整的標准，並且定義了供應商設計和交付一個有質量產品的能力所需要的所有元素。 ISO9002 涵蓋了對供應商控制設計和開發活動所認為重要的質量標准。 ISO9003 用於證明供應商在檢視和測試期間檢測和控制產品不一致性的能力。 ISO9004 描述和 ISO9001 、 ISO9002 和 ISO9003 相關的質量標准，並提供了一個完整的質量查檢表。 軟體能力成熟度模型是目前國內軟體企業中非常受歡迎的一個質量標准。並且該標准已經成為業界一個事實上的標准。 CMM 為軟體組織提供了一個指導性的管理框架。在這個框架的指導下： �6�1 軟體組織可以對其軟體開發、維護過程獲得控制。 �6�1 軟體組織可以推進其軟體工程更為科學、推進軟體過程管理更為卓越。 �6�1 CMM 通過確定當前軟體過程管理的成熟度，通過標識軟體的質量和過程改進中關鍵的、要害的問題，可以指導軟體組織選擇正確的軟體過程改進策略。 �6�1 CMM 將其焦點，聚焦在一系列具體的軟體過程活動上，並以侵略方式（ Aggressively ）達到這些活動。一個軟體組織就可以穩定地、持續地改進其整個軟體組織過程，使得其軟體過程管理能力取得持續地、持久地不斷爭長提高。 在 CMM 中，把軟體工廠分為五個等級：初始級、可重復級、已定義級、管理級和優化級。其中： 初始級 ：軟體過程是未加定義的隨意過程，項目的執行是隨意甚至是混亂的。也許，有些企業制定了一些軟體工程規范，但若這些規范未能覆蓋基本的關鍵過程要求，且執行沒有政策、資源等方面的保證時，那麼它仍然被視為初始級。 可重復級 ：人們根據多年的經驗和教訓，總結出軟體開發的首要問題不是技術問題而是管理問題。因此，第二級的焦點集中在軟體管理過程上。一個可管理的過程則是一個可重復的過程，可重復的過程才能逐漸改進和成熟。可重復級的管理過程包括了需求管理、項目管理、質量管理、配置管理和子合同管理五個方面；其中項目管理過程又分為計劃過程和跟蹤與監控過程。通過實施這些過程，從管理角度可以看到一個按計劃執行的且階段可控的軟體開發過程。 已定義級： 要求制定企業范圍的工程化標准，並將這些標准集成到企業軟體開發標准過程中去。所有開發的項目需根據這個標准過程裁剪出與項目適宜的過程，並且按照過程執行。過程的裁剪不是隨意的，在使用前必須經過企業有關人員的批准。 管理級 ：所有過程需建立相應的度量方式，所有產品的質量（包括工作產品和提交給用戶的最終產品）需要有明確的度量指標。這些度量應是詳盡的，且可用於理解和控制軟體過程和產品。量化控制將使軟體開發真正成為一種工業生產活動。 優化級： 的目標是達到一個持續改善的境界。所謂持續改善是指可以根據過程執行的反饋信息來改善下一步的執行過程，即優化執行步驟。如果企業達到了第五級，就表明該企業能夠根據實際的項目性質、技術等因素，不斷調整軟體生產過程以求達到最佳。 美國國防部規定，重要性級別高的軟體應該由質量級別高的企業承擔。不同等級的軟體公司提交的軟體，其軟體質量也相差很大，國外的一份統計資料如下： 表 1 、 CMM 級別與軟體質量關系表格 每千行軟體的缺陷數目
軟體過程成熟度等級
軟體准時提交的百分比
每人每月生產的程序行數
軟體需要返工的百分比
平均軟體失效時間（近似）
大於 10
初始級
<=50
Z
>=45
2 到 60 分鍾
小於 10
可重復級
90
1.5Z
20
1-160 小時
小於 1
已定義級
99
2.5Z
10
不確定
小於 0.1
管理級
降低開發時間到 1/2
5 Z
5
不確定
小於 0.01
優化級
降低開發時間到 1/4
10Z
<=2
近似完全可靠
對於很多已經推行或者准備推行 CMM 的公司來說， CMM 的起步是很難的，因此 Humphrey 又提出了 PSP （ Person Software Process ）和 TSP （ Team Software Process ）【 2 】【 3 】。 CMM 是過程改善的第一步，它提供了評價組織的能力、識別優先改善需求和追蹤改善進展的管理方式【 1 】。企業只有開始 CMM 改善後，才能接受需要規劃的事實，認識到質量的重要性，才能注重對員工經常進行培訓，合理分配項目人員，並且建立起有效的項目小組。然而，它實現的成功與否與組織內部有關人員的積極參加和創造性活動密不可分。 PSP 能夠指導軟體工程師如何保證自己的工作質量，估計和規劃自身的工作，度量和追蹤個人的表現，管理自身的軟體過程和產品質量。經過 PSP 學習和實踐的正規訓練，軟體工程師們能夠在他們參與的項目工作之中充分運用 PSP ，從而有助於 CMM 目標的實現。 TSP 結合了 CMM 的管理方法和 PSP 的工程技能，通過告訴軟體工程師如何將個體過程結合進小組軟體過程，並將後者與組織進而整個管理系統相聯系；通過告訴管理層如何支持和授權項目小組，堅持高質量的工作，並且依據數據進行項目的管理，向組織展示如何應用 CMM 的原則和 PSP 的技能去生產高質量的產品。 軟體的生產過程及其它的許多子過程、軟體的開發者和用戶、以及系統的使用中存在著巨大的變化和不同，要使一個軟體過程對軟體生產的改善真正有所幫助，其框架應是由 CMM 、 TSP 和 PSP 組成的一個完整體系，即從組織、群組和個人三個層次進行良好的軟體工程和管理實踐的指導和支持。總而言之，單純實施 CMM ，永遠不能真正做到能力成熟度的升級，只有將實施 CMM 與實施 PSP 和 TSP 有機地結合起來，才能發揮最大的效力。 八、如何起步？ 質量改進需要花費成本，因此改進的途徑需要視不同公司的規模、業務、財務狀況、人員技術水平等多方面綜合進行考慮。一般建議中型以上的較大的軟體公司實施 CMM 體系。而對於一些小型的軟體公司可以採取比較實際的，相對成本較少，且容易操作的方面進行，這些方面大致如下： �6�1 實施簡潔的開發過程體系，根據不同業務特點可以選擇瀑布模型，迭代模型等，並在這些模型上進行適當的變化以適應於短平快的產品開發特點。 �6�1 提高需求分析和設計方面的技術，例如：原型法技術，分析模式，設計模式，面向對象設計， UML 等； �6�1 加強文檔化工作。文檔是經驗的保留，對於一個企業要想獲得長期的發展，必須加強文檔化工作； �6�1 加強編程規范工作； �6�1 進行適當的測試工作，建議進行單元測試和系統測試； �6�1 實施配置管理工作，加強版本控制； �6�1 開展走讀、評審和檢視活動，尤其要加強代碼走讀，建議進行每日交叉走讀活動； �6�1 進行簡單的度量分析獲得；建議實施 PSP 活動；
7. 誰知道如何提高軟體質量
【摘要】 軟體質量是軟體產品的靈魂。本文全面介紹了質量的概念，提出了從流程、技術、組織管理、人員技能發展等多個角度提高軟體質量的重要性；並對目前國際上流行的 CMM 標准進行了介紹，提出了使用 PSP 和 TSP 來實現 CMM 的方法。本文最後還給出了中小型軟體公司在提高軟體質量方面的一個初步思路。【關鍵字】 質量管理，軟體開發過程模型，軟體分析和設計方法，軟體測試， CMM 如何提高軟體的質量已經不是一個純粹的技術問題，而是一個工程的問題。自從計算機誕生以來，相應的軟體開發就存在了。由於早期的計算機運行性能較低，軟體的可編程范圍也較狹窄，因此質量問題就沒有那麼突出。 50 年代後期到 60 年代，高級語言的相繼誕生並得到了廣泛的應用，隨之而來的是軟體規模也越來越龐大，越來越復雜。伴隨著軟體應用的越來越廣泛，軟體的質量問題就變得越來越突出。根據美國國家宇航局 NASA 的統計，在 80 年代初，軟體引起的故障與硬體引起的故障，其比率約為 1.1:1.0 ，到了 80 年代末，這一比率已達到 2.5:1.0 。因此如何提高軟體的質量成為軟體工程研究的一個重點。自從軟體危機產生以來，出現了很多提高產品質量的理論和方法，有的從技術角度出發，例如：面向對象技術的產生和推廣，第四代語言的誕生等等；有的從自動化工具入手，例如： CASE 工具、過程式控制制軟體、自動化管理平台等；有的從過程模型角度出發，例如：迭代模型、螺旋模型、 RUP 、 IPD 、凈室軟體工程等；也有從管理角度出發的，例如：團隊管理、績效管理、 PSP 、 TSP 等；也有從測試角度出發的，例如：加強全流程的測試等；一些相應的規范和標准也孕育而生，例如： ISO9000 系列、 CMM 、 QMS 等。然而每一種技術都不是絕對的，軟體質量的提高應該是一個綜合的因素，需要從每個方面進行改進，同時還需要兼顧成本和進度。一、什麼是質量？ 作為軟體產品的銷售人員，市場人員或維護人員經常會受到客戶這樣那樣的指責或抱怨，客戶說：你們產品的質量太差，不穩定等等。那麼什麼是質量呢？我們該如何來衡量質量呢？質量具有三個維度：" 符合目標。目標是客戶所定義的，符合目標即判斷我們是不是在做需要做的事情。" 符合需求。即產品是不是在做讓它做的事情。" 符合實際需求。實際的需求包括用戶明確說明的和隱含的需求。ISO 關於質量的定義表示如下：「 一個實體（產品或服務）的所有特性，基於這些特性可以滿足明顯的或隱含的需要。 」 注意，在這個定義中包含明顯的需求和隱含的需求。而往往我們會忽略隱含的需求。因此在控制一個產品的質量的過程中必須關注這些隱含的需求，並給予應有的驗證。 另一方面因為我們的產品是為客戶提供服務的，因此凡是不滿足客戶需求的，我們都認為是一個失效（ failure ）。所以我們的產品必須始終圍繞著客戶的需求進行開發和驗證。 這里我們談到客戶，其實在一個軟體的需求收集過程中需要關注客戶和用戶。而我們經常會忽略客戶與用戶之間的區別。那麼誰是客戶？誰是用戶呢？簡單的來說， 客戶是真正能夠決定是否購買你軟體的人，而用戶是實際使用軟體的人。了解了這個區別，對於你在分析需求的重要性的時候就可以進行參考。同時在產品質量驗證 的時候也可以做出不同的權衡。另一方面我們在考慮我們用戶需求的時候，往往只考慮了實際使用軟體的人員，而忽略了其它一些人員對軟體的要求或對軟體造成的 潛在競爭，這包括維護人員的要求、系統管理人員的要求、軟體上下遊人員的要求、先前版本的情況、市場上競爭對手的軟體情況等。 每個人提到質量的時候，經常會遇到下列矛盾，在這些矛盾中隱含著對質量的承諾【 5 】：" 質量需要一個承諾，尤其是高層管理者的承諾。但為了得到質量，高層管理者必須和其僱用的員工進行緊密合作；" 許多人相信沒有缺陷的產品和服務是不可能的。但是控制在一定級別的缺陷數是正常並可接受的；" 質量經常是和成本緊密聯系在一起，一個高質量的產品同時也意味著高投入。這是設計的質量和一致性質量的一個矛盾；" 一個高的質量要求需求規格說明書足夠詳細，以便產品可以根據這些規格說明書進行定量的分析。然而許多組織沒有能力或者不願意產生如此詳細程度的規格說明書；" 技術人員經常相信規范和標准會束縛他們的創造力，因此就不遵照標准做事。然而如果要得到高質量的產品，就必須遵循良好定義的標准和過程。二、流程對質量的貢獻 好了，既然已經了解了什麼是質量，那麼怎麼才能改進軟體產品的質量呢？從一個企業的長遠發展來看，首先應當從流程抓起，規范軟體產品的開發過程。這是一個 軟體企業從小作坊的生產方式向集成化、規范化的大公司邁進的必經之路，也是從根本上解決質量問題，提高工作效率的一個關鍵手段。 軟體產品的開發同其它產品（如汽車）的生產有著共同特性，即需要按一定的過程來進行生產。在工業界，流水線生產方式被證明是一種高效且能夠比較穩定地保證 產品質量的一種方式。通過這種方式，不同的人員被安排在流程的不同位置，最終為著一個目標共同努力，這樣可以防止人員工作間的內耗，極大的提高工作效率。 並且由於其過程來源於成功的實例，因此其最終的產品質量能夠滿足過程所設定的范圍要求。軟體工程在軟體的發展過程中吸取了這個經驗並把它應用到了軟體開發 中，這就形成了軟體工程過程，簡單的說就是開發流程。 無論做什麼事情，都有一個循序漸進的過程，從計劃到策略再到實現。軟體流程就是按照這種思維來定義開發過程，它根據不同的產品特點和以往的成功經驗，定義 了從需求到最終產品交付的一整套流程。流程告訴我們該怎麼一步一步去實現產品，可能會有那些風險，如何去避免風險等等。由於流程來源於成功的經驗，因此， 按照流程進行開發可以使得我們少走彎路，並有效的提高產品質量，提高用戶的滿意度。 目前流行的流程方法有很多種，不同的過程模型適合於不同類型的項目。瀑布模型是應用的最為廣泛的一種模型，也是最容易理解和掌握的模型，然而它的缺陷也是 顯而易見的。遺漏的需求或者不斷變更的需求會使得該模型無所適從。然而，對於那些容易理解但很復雜的項目，採用瀑布模型會是比較適合的，因為你可以按部就 班的去處理復雜的問題。在質量要求高於成本和進度要求的時候，該模型表現的尤其突出。螺旋模型是也是一個經典模型，它關注於發現和降低項目的風險【 8 】。螺旋型項目從小的規模開始，然後探測風險，制定風險控制計劃，接著確定下一步項目是否還要繼續，然後進行下一個螺旋的反復。該模型的最大優點就是隨著成本的增加，風險程度隨之降低。然而螺旋模型的缺點是比較復雜，且需要管理人員有責任心，專注以及有管理方面經驗。RUP （ Rational Unified Process ）是 Rational 公司提出的一套開發過程模型，它是一個面向對象軟體工程的通用業務流程【 9 】。它描述了一系列相關的軟體工程流程，它們具有相同的結構，即相同的流程構架。 RUP 為在開發組織中分配任務和職責提供了一種規范方法，其目標是確保在可預計的時間安排和預算內開發出滿足最終用戶需求的高品質的軟體。 RUP 具有兩個軸，一個是時間軸，這是動態的。另一個是工作流軸，這是靜態的。在時間軸上， RUP 劃分了四個階段：初始階段、細化階段、構造階段和發布階段。每個階段都使用了迭代的概念。在工作流軸上， RUP 設計了六個核心工作流程和三個核心支撐工作流程，核心工作流軸包括：業務建模工作流、需求工作流、分析設計工作流、實現工作流、測試工作流和發布工作流。核心支撐工作流包括：環境工作流、項目管理工作流和配置與變更管理工作流。具體可以參考圖 1 。 RUP 匯集現代軟體開發中多方面的最佳經驗，並為適應各種項目及組織的需要提供了靈活的形式。作為一個商業模型，它具有非常詳細的過程指導和模板。但是同樣由於該模型比較復雜，因此在模型的掌握上需要花費比較大的成本。尤其對項目管理者提出了比較高的要求。圖1 RUP 工作流程示意圖IPD （ Integrated Proct Development ）流程是由 IBM 提出來的一套集成產品開發流程，非常適合於復雜的大型開發項目，尤其涉及到軟硬體結合的項目。 IPD 從整個產品角度出發，流程綜合考慮了從系統工程、研發（硬體、軟體、結構工業設計、測試、資料開發等）、製造、財務到市場、采購、技術支援等所有流程。是 一個端到端的流程。在 IPD 流程中總共劃分了六個階段（概念階段、計劃階段、開發階段、驗證階段、發布階段和生命周期階段），四個個決策評審點（概念階段決策評審點、計劃階段決策評 審點、可獲得性決策評審點和生命周期終止決策評審點）以及六個技術評審點，具體可以參考圖 2 。 IPD 流程是一個階段性模型，具有瀑布模型的影子。該模型通過使用全面而又復雜的流程來把一個龐大而又復雜的系統進行分解並降低風險。一定程度上，該模型是通過 流程成本來提高整個產品的質量並獲得市場的佔有。由於該流程沒有定義如何進行流程回退的機制，因此對於需求經常變動的項目該流程就顯得不大適合了。並且對 於一些小的項目，也不是非常適合使用該流程。圖2 IPD 流程示意圖三、流程與技術 流程和成功不是等價的。沒有流程就成功是不可能得到保證，但有了流程並不意味著肯定能夠成功。這恐怕是很多迷信於流程的人所不能接受的。但這的確是個事實。記得有個做了將近 30 多年的需求分析專家說過：即使是一個已經達到 CMM4 級的公司，也完全有可能做不好需求分析。為什麼？技術，技術是成功的另外一個必要條件。就好比現在你要從上海到北京去，流程給你指出了最短的路徑，技術提供給你最快的交通工具。兩者結合就是完美。 對於軟體開發來說，要保證軟體的質量，需要掌握多方面的技術，包括分析技術、設計技術、編碼技術和測試技術等等。在國內有一個普遍的非正常現象，就是大家 覺得只有編程能力才是玩電腦的真正技能。就好像造一套房子，其它都不重要，只要磚瓦匠有高超的技能就行了。盡管這個比喻會打擊很多程序員的自尊心，但這的 確是一個事實。我們缺少系統級的工程師，在分析和設計方面的工作做得很不扎實。需求是一個項目的靈魂。模稜兩可的需求帶來不可避免的後果便是返工 —— 重做一些你認為已做好的事情。返工會耗費開發總費用的 4 0 % ，而 7 0 % ～ 8 5 % 的重做是由於需求方面的錯誤所導致的（ l e ff i n g w e l l1 9 9 7 ）【 10 】。想像一下如果你能減少一半的返工會是怎樣的情況？你能更快地開發出產品，在同樣的時間內開發更多、更好的產品，甚至能偶爾回家休息休息。在《軟體需求》一書中關於如何進行需求分析給出了比較詳細的介紹【 7 】， RUP 中關於需求的指導也是很實用的。 設計是最能體現一個工程師能力和水平的環節。一個好的設計基本上決定了產品的最終質量。設計是把需求轉換成系統的一個關鍵步驟，它需要從自然語言描述的需求中尋找出設計的基礎單元，構建出整個系統的構架。在 RUP 中關於系統構架師和設計師的定位是相當高的。關於設計方面的技能涉及面是很廣的，包括傳統的結構化設計到面向對象設計。設計人員需要掌握一定的建模技術。 UML 是國際上比較流行的一種建模語言【 11 】。在嵌入式方面， SDL 也是一種非常好的選擇。《設計模式》是在設計思想方面總結的非常出色的一本書【 6 】，作為一名設計人員（尤其是面向對象設計人員）必須要好好研究一下。但是對這些模式的應用應當講究一種自然的應用，千萬不要因為模式而去設計模式，否則會適得其反。 現在的程序員熱中於掌握多種編程語言，或者講究語言的過分技巧化，而往往忽略了編程語言的規范化。不規范的語言應用給程序的可理解性、可維護性以及可測試 性帶來了大的傷害，進而損害了產品的質量。某公司曾對中國程序員和印度程序員做過一個測驗，這個測驗要求參加者對一組數進行排序。測試結果發現，印度程序 員設計的程序使用的演算法並不是最優，但卻是最不容易出錯的，並且幾個程序員寫出來的代碼如出一轍。而幾個中國程序員寫出的代碼，有的非常漂亮，很精練，效 率很高；有的卻很冗雜，還有錯誤。如果大家是在做研究性的項目或純粹興趣性的項目，那麼充分發揮自己的編程天才也無可厚非。然而，對於一個軟體公司，產品 最終是要交給用戶的，需要遵循的是一個軟體產品的開發工程。因此這類軟體的開發需要遵循一定的編程規范，畢竟開發的軟體不是自己用，還需要和別人的集成， 還需要給以後版本重用和維護。 測試的技術將在第五節進行闡述。總之流程很關鍵，技術也很重要，我的觀點是：魚和熊掌，兩者都不能放。
8. 如何保證軟體開發的質量
CMM不是僅適合於外包公司。不同外包公司的情況還不一樣呢。確證的說：是好多外包公司不得不拿CMM來做項目招標的招牌。個人認為：CMM或者說CMMI的選擇，與企業的組織結構有很大關系。CMM/CMMI與是否外包沒有必然聯系。如果引入實施適當的話，CMM/CMMI對於自主研發企業，比外包企業有更大的益處。
9. 如何保證軟體測試質量
我認為高質量的軟體產品是一個軟體團隊所有成員都負責任的完成自己任務以後的必然產物。
首先說說團隊，這其中涉及的需求人員、設計人員、開發人員、測試人員都應該真切的視自己為團隊的必不可少的力量，都應該為了項目或產品的成功竭盡所能的去工作，只有團隊真正的擰成一股繩的時候才具備了產出高質量軟體的基本條件。這是我要說的第一點：團隊認同感、歸屬感。
高質量的需求調研文檔是軟體成功必不可少的條件，但是不同的人對同一句話的理解往往會有差異，因為立場不同。所以想要保證需求的質量，需求人員必須把自己置身到用戶的立場去感受、去調研、去理解目標用戶反饋的信息。對於不確認的信息要想盡辦法搞清楚。所以需求調研人員最好是行業專家。需求文檔整理出來後，必須經過客戶方代表和公司設計、開發、測試的共同評審才能最終定稿，並最終進入軟體設計流程。這是我要說的第二點：軟體需求必須用「心」去做，並且監督評審必須到位。
接下來就進入了軟體的生產流程，在設計階段，設計人員是主角，開發人員、測試人員、需求人員要可以及時獲得設計文檔。設計人員必須在實現需求的情況下，站在用戶的立場上去設計功能，實現最好的用戶體驗。在設計評審時，開發、測試、需求要從用戶的角度去評判設計，根據需求從用戶的角度去評審設計，這真的很重要。問題如果能在設計階段就發掘出來會極大的減少資源的浪費，縮短產品或項目周期。這是我要說的第三點：設計要注重用戶體驗，同時監督評審也必須到位。
軟體進入開發測試流程後，實際的開發人員應該站在用戶的角度上去開發每一個功能，如果有比設計更好的實現方法，應及時和設計、測試、需求人員溝通，共同確認是否更改設計。每一個功能完成後，必須進行完整的自測，然後及時送測給測試人員，測試人員也要在用戶的角度進行測試，發現問題或建議及時反饋、溝通和處理。還有很重要的一點，測試必須要有測試用例。測試開始前，測使用例必須經過評審，當然評審粒度根據公司資源確定。這是我要說的第四點：開發是軟體的製造者，測試是軟體質量的保證者，兩者相輔相成，榮辱與共。
高質量的軟體是一個軟體團隊共同努力的結果，任意一個環節出問題都可能造成團隊的災難。團隊領導者必須要想辦法、盡全力將自己的團隊凝結在一起，使大傢具有團隊榮譽感和使命感。軟體生命周期的各個階段都有工作重點，團隊領導必須把握好。團隊領導不能輕視任何一個環節的工作，否則高質量的軟體只能是一句空話。古人說「三人行，必有我師焉」。任何一個團隊，所有人的力量都發揮出來肯定比所謂幾個精英累死累活搞出來的結果要好。人們說的「兵熊熊一個，將熊熊一窩」也是說團隊領導的重要性。
呵呵，總結完了。最後再說一下自己的看法：高質量的軟體是軟體團隊共同努力的結果，用戶體驗是軟體質量很重要的方面，軟體的需求、設計、開發和測試都應該是從用戶的角度出發去工作。
10. 面試時，HR問我如何保證自己所寫軟體的質量
1局部代碼的邏輯嚴密，最起碼實現一個東西不能在邏輯上出問題。。
2局部代碼的健壯，能實現功能只是第一步，但要考慮各種運行時異常；比如用到的參數是整形，參數是外部輸入的，方法內在轉型前需要捕獲異常，如果不能保證拿到的參數就一定整形，必須做健壯性優化，這只是其中之一。。。。
3整體代碼的健壯性， 你參與的是公司的產品，你修改或新加一個功能，要確保你做的東西不會對系統原有的模塊產生負面影響，或者要確保如果與之前某功能邏輯上類似，則需要保證方法的邏輯統一。比如你做的新功能是向A表裡插數據。先前系統里有幾個口子可以往A表裡插，你就要看插入A時有沒有默認插入的參數，這張A表是不是還和B表有關聯，是不是原先其他程序插入A表時會默認帶一條B表記錄等等。總之你是在別人的系統上集成，肯定不可能以你開發為主
4 如果涉及到與資料庫連接（這個最重要），一定要在finally里寫連接池關閉，否則連接池一旦泄露，服務就會死，這個問題可以說比數據不對還要嚴重