軟件的質量一直是各企業比較頭疼的問題。在這里，我將結合我自己的實踐經驗，來說說如何在開發過程中把好每個關口，以得到高質量的最終產品。希望能與廣大關注軟件質量的同仁分享! 軟件的質量保證活動是確保軟件產品從誕生到消亡為止的所有階段的質量的活動，即是為了確定、達到和維護需要的軟件質量而進行的所有有計劃、有系統的管理活動。如果象很多軟件企業那樣，僅僅到了產品后期進行簡單的測試，是遠遠不夠的。質量保證要做好，就要在越早發現軟件中的問題，就要在過程和軟件本身兩方面把好質量關。具體的講，就是步步為營，每項工作都必須審核，審核通過后才能開始下游工作。
軟件質量保證的主要手段是檢驗，檢驗有兩種方式：
Quality review，檢查階段產品是否與要求一致，防止軟件差錯到下個過程被放大。一般在各階段的中途或向下一階段移交時進行的檢查。因為這時候還沒有結果產品，所有的檢查都是通過評審的形式實現的。(Verification)
測試，檢驗開發出來的軟件的特性是否與需求相符，確保所有的軟件功能需求都能得到滿足，所有的軟件性能需求都能達到，所有的文檔都是正確的且便于使用。檢查方式是由測試人員對產品結果進行正式全面的測試。(Validation)
根據上面這條思路，我們采取下面具體措施來把握軟件的質量： Quality review，編碼規范， Code review，單元測試，功能測試，性能測試，UAT測試。將他們具體到軟件開發周期的各個階段，如下圖所示：
QR：Quality Review
CR：Code Review
一、Quality review
有些中文的資料中將其成為審核，他的目的是確保開發的過程結果的質量。根據內容和正式性上我們可將其分為兩類，
一類是在開發周期中在每個階段的內部做的小范圍的審核。它是在本模塊內進行的審核，目的是確保被審核內容與它的上游工作產品一致，并能夠順利開展下游工作。一般要求與本內容有關的上游人員，下游人員，以及在本內容上有技術權威的人參加。時間根據內容的多少而定，一般半個小時到2個小時。
另一類是開發周期中在每個階段末對本階段所有產品的審核。它是全組性的審核，較正式一些。一般由項目經理或本開發組負責人來發起和主持，并要求他們提前將會議邀請發給需要參加會議的人，以及將需要將會議的內容大體介紹給大家，以便大家做好準備。團隊中與本技術有關的所有人員都要求參加，必要的話，還邀請的項目組之外的其他人員，一般會邀請有關領域的專家。會議上，會按照一定的邏輯順序一一審核本階段提交的所有產品。
不論是哪類審核，他們的討論內容都是一致的。大致有下面幾點：
1、 討論被審核對象的有關問題
2、 深入地審核系統的體系架構和所使用的技術
3、 確認技術過程(Build/Release，源碼控制，等)
即便是會議，它的記錄和問題跟蹤就很重要。每次審核都要求由主持人或由他指定他人在當天將會議的內容整理出來并置于配置管理之下。我們稱之為review notes，它的內容包括：參加人，時間，議題，發現的問題，下一步要做的工作，風險，下次會議的時間(如果安排有第二次審核的話)，等。這里要強調的是，對每項工作都必須當場指定一個負責人，以便責任到人。在第二次審核的時候，需要將第一次所有記錄的問題全部檢查一遍。
為了使審核能夠更有效地開展，并真正起到提高軟件質量的作用，請認真遵守如下有幾條原則：
1、 某階段未通過階段評審不得進入下一個軟件研制階段;
2、 評審時對事不對人，評審的是產品，而不是評審生產者;
3、 評審就要挑刺，找問題、缺陷和隱患;
4、 評審組的人員面越廣越好;
5、 評審組不作無休止的爭論和辯駁，將爭論點記錄下來，供以后甄別;
6、 評審只是提出問題，沒有解決問題的任務;
為了確保Quality review的質量，需要列出軟件開發不同階段上的Review內容。利用這個Checklist，主持人根據項目的具體內容安排合適的Quality review。由于各個公司的開發模式不同，checklist的內容也會千差萬別。公司可根據自己的情況慢慢地建立一套適合自己Checklist，用來指導Quality review，也可以用來跟蹤Quality review的執行。
二、編碼規范
在多個開發人員 共同寫作的情況下，必需建立一個合適的編碼規范。這不僅僅是為了開發效率來考慮，而且也是為了后期維護考慮。定義規范的目的是讓項目中所有的文檔都看起來像一個人寫的，增加可讀性，減少項目組中因為換人而帶來的損失。
為了保證程序源代碼的可維護性，建議公司建立一套嚴格而合適的編碼規范以約束程序員的編碼習慣。目前有很多編碼規范的工具，他們大多都可以很好地與開發平臺兼容，設置和使用都很方便。
三、Code Review
Code Review，就是審查代碼的質量。根據形式分為兩種，一種是交叉代碼審查，就是自己的代碼由他人來檢查，就象檢查作業一樣;另一種是代碼會審，就是以會議的形式，大家共同審核代碼的質量。
Code review過程如下：
1、 代碼完成并提交。
2、 項目負責人決定哪些代碼需要審查，并指派審核人。審查人對被審查文件必須填寫code review report。
3、 通過后，源碼作者在代碼文件的題頭信息中給出審查人和審查通過的信息，格式為：Cross review passed by XXX on year/month/day。若沒有通過，則只填寫code review report即可。
4、 根據交叉代碼審查的結果，項目負責人決定哪些代碼需要代碼會審。一般需要對有問題爭議的代碼進行會審。
5、 代碼會審。會審針對爭議進行，在交叉審查中已檢查過的內容可忽略。會后由項目負責人親自或指派他人針對此次代碼會審填寫code review report。
6、 代碼會審通過后，源碼作者在代碼文件的題頭信息中給出通過代碼會審的信息，格式為：Meeting review passed on year/month/day。
7、 將修訂后的代碼提交配置管理庫。
Code review report的內容包括：模塊名稱，日期，被審核者，審核者，審核的文件名，審核的內容，參考和依據，結論，發現的問題，提出的建議，等內容
交叉代碼審查安排的原則：
1、 安排的審查人一定是功能相關的人，越相關越好。這樣可以節省熟悉模塊功能的時間;
2、 審核的人必須對被審核的文件掌握相關領域的知識，最好是同級或上級，以便能夠很快理解他人的代碼;
四、單元測試
單元測試集中檢驗軟件設計的最小單元----模塊。測試之前必須先通過編譯程序檢查并改正所有語法錯誤，然后用詳細設計描述做指南，對重要的執行通路進行測試，以便發現模塊內部的錯誤。
單元測試要求開發人員來編寫測試用例并執行測試。單元測試的設計，編碼，和實施可能會給開發人員無形中增加很多工作量，但事實證明，好的單元測試可以發現在后期測試中60%以上的Bug。值得慶幸的是，目前有很多免費的單元測試工具，多少可以給廣大的開發人員帶來一些方便。
五、功能測試
為了保證軟件能滿足功能要求而做的測試。測試的內容就是軟件的所有功能，它是測試中最重要的一部分。需要制定測試計劃，規定要做測試的范圍，要求，方法等。還需要制定一組測試步驟，描述具體的測試用例，旨在說明軟件與需求是否一致。
功能必然涉及到邏輯，所以需要測試方案。測試方案包括預定要測試的功能，應該輸入的測試數據和預期的結果。設計測試方案的目標是，確定一組最可能發現某個錯誤或某類錯誤的測試數據。
幾種主要的黑盒測試的設計技術有：
1、等價類劃分。將所有可能的輸入數據，即程序的輸入域劃分為若干部分，然后從每一部分中選取少數。不光考慮輸入等價類，有時還需要考慮輸出等價類。
2、邊界值分析。對等價類劃分的補充，不是從等價類中隨便選一個數據作為代表，而是選幾個特定值，如等于、剛剛大于、剛剛小于邊界值。
說到測試，就不得不提到回歸測試。當軟件經過測試發現錯誤，程序員對一個錯誤的修改可能會引起另外的錯誤出現，所以，在修改之后還要進行測試，這種測試就叫回歸測試。
在整個產品提交之前要進行正式的回歸測試，有必要給出回歸測試的要求：
3、每次測試需要將所有的功能都走一遍;
4、對不同狀態的bugs要求check一遍，重新定他們的狀態，特別關注狀態改變的bugs。
5、check Bugs時，注意走一下與此Bug 有關聯的功能，以及與此Bug相類似的功能。
六、性能測試
為了保證軟件能滿足性能要求而做的測試。要求設計測試用例，模擬錯誤數據和軟件界面可能發生的錯誤，測試各項性能是否達到預期的指標。如果是基于Web的系統，請注重下面三方面的測試：
1、安全測試：安全性測試是要檢驗在系統中已經存在的系統安全性、保密性措施是否發揮作用，有無漏洞。
2、負載測試：通過模擬大批量用戶的并發請求，給系統施加較大的負載，這時檢測整個系統處理交易的能力。
3、壓力測試：在反常數量或資源(使用的容量達到規定的極限)的情況下執行應用程序，檢測中間件系統在長時間、高負載情況下的運行處理能力，從而檢驗系統的穩定性。例如，①當中斷的正常頻率為每秒一至兩個時，運行每秒產生十個中斷的測試用例;②定量地增長數據輸入率，檢查輸入子功能的反映能力;③運行需要最大存儲空間(或其他資源)的測試用例;④運行可能導致虛存操作系統崩潰或磁盤數據劇烈抖動的測試用例，等等。使用Jmeter工具能夠方便地測試系統的負載。
作者小傳：
夏清風，學士，軟件工程專家網技術支持組成員。一直從事軟件測試和負責質量保證工作，現在主要負責CMM項目。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
