1、單元測試 XXXX作為一個新項目，和其他所有項目一樣，在開發(fā)工作進行之初就在考慮如何保證代碼開發(fā)的質(zhì)量。答案很容易找到：充分的單元測試。但是以前真正做得好得項目卻不多。
經(jīng)過分析，總結(jié)了一下做好單元測試工作的四個要素：
――思想上的重視
――計劃上保證
――測試手段保證
――測試效果的可驗證
1.1 思想上重視
從以往的開發(fā)過程總結(jié)了一些教訓(xùn)：
――開發(fā)人員模塊在交付聯(lián)調(diào)前，測試不充分，導(dǎo)致聯(lián)調(diào)周期較長
――代碼進入維護期后，修改代碼往往引起不可預(yù)期的錯誤。導(dǎo)致開發(fā)人員比較害怕在相對穩(wěn)定的代碼上進行修改。
由于有這些教訓(xùn)，所以在編碼之前，項目從領(lǐng)導(dǎo)到員工都很重視單元測試工作。
1.2 計劃上保證
計劃制定經(jīng)過了XXXX的分解流程，XXXX分解小組成員討論時充分意識到了單元測試工作的必要性，也意識到了為之要付出的代價。最終確定了單元測試和代碼開發(fā)的比重為2：1左右。以操作維護的配置模塊為例，最終制定的計劃如下：
從計劃中可以看出，花在單元測試上的時間和代碼開發(fā)的時間的比重甚至超過了2：1。
附：表方法測試代碼和被測代碼的行數(shù)統(tǒng)計數(shù)據(jù)（該部分測試覆蓋率已達(dá)95%以上）
從數(shù)據(jù)看來，我們當(dāng)初的估計是對的。測試代碼行數(shù)和被測代碼行數(shù)的比值大致是2：1
1.3 測試手段保證
1.3.1 測試框架
對于一個系統(tǒng)工程來說，一個好的框架是至關(guān)重要的。一個好的框架應(yīng)該有如下一些特點：
――結(jié)構(gòu)清晰。不同的粒度層次在框架中一目了然
――可擴展性良好。
我們選擇單元測試工具就是為了滿足能基于該工具搭建一個好的單元測試框架，另外還有以下幾個方面的考慮：
――整個開發(fā)組負(fù)責(zé)三個模塊：數(shù)據(jù)庫，操作維護，傳輸。每個模塊由不同的開發(fā)人員負(fù)責(zé)。從測試代碼的可維護性考慮，需要統(tǒng)一各人編寫測試代碼的框架以及風(fēng)格
――前臺代碼是由C語言編寫的
――單元測試應(yīng)該是可回歸的，自動化的
最終我們選擇了Cunit，因為Cunit完全符合我們的要求。
Cunit是一種針對于C語言代碼的單元測試框架，具有以下優(yōu)點：
–提供很多實用的接口函數(shù)（比如：各種斷言、信息匯總、打印等）
–簡單、安全、方便
–可添加任意多個測試單元
–逐步添加，匯總成套，全面回歸測試
–完全免費
測試框架選定以后，在組內(nèi)進行了相應(yīng)的培訓(xùn)，使得每個人的認(rèn)識達(dá)到相同的水平，盡可能保證以后測試風(fēng)格的一致。
1.3.2 測試方案和測試規(guī)程
單元測試是一個系統(tǒng)的工作，在進行之前需要一個總體的規(guī)劃。這個工作在單元測試方案中得到體現(xiàn)；測試規(guī)程是對測試方案的細(xì)化，是單元測試的指導(dǎo)。測試規(guī)程可以在notes的測試管理平臺中錄入。
1.3.3 自動化測試的考慮
一個單元測試是由許多測試用例構(gòu)成的，要實現(xiàn)可回歸，自動化的測試，每個測試用例都應(yīng)該可以按照一定的順序連續(xù)的執(zhí)行。要達(dá)到這個目標(biāo)，就要求對整個單元測試做一個很好的規(guī)劃。以數(shù)據(jù)庫模塊為例，我們做了如下的規(guī)劃：
● 數(shù)據(jù)環(huán)境的建立
數(shù)據(jù)庫的測試依賴于一套數(shù)據(jù)表。單元測試一開始就需要在表中插入數(shù)據(jù)，以建立后續(xù)測試用例依賴的數(shù)據(jù)環(huán)境
● 測試粒度合理的劃分
我們把被測對象分為表方法、查詢接口和修改接口。
注：測試用例套（TestSuite）是Cunit的一個概念，用于封裝測試用例套或者測試用例（TestCase）
● 在某種粒度上面保證數(shù)據(jù)環(huán)境的松耦合
所有的測試用例基于數(shù)據(jù)環(huán)境編寫，數(shù)據(jù)環(huán)境對于數(shù)據(jù)庫的單元測試是及其重要的。每個測試用例從前一個用例繼承數(shù)據(jù)環(huán) 境，又將本測試用例修改后的數(shù)據(jù)環(huán)境移交給下一個測試用例。從這個過程可以看出，數(shù)據(jù)環(huán)境在測試用例間是緊耦合的。如果測試用例一多，數(shù)據(jù)環(huán)境就會變得難 以控制，用例的編寫將變得非常麻煩。尤其是多人分工合作的情況下，簡直變成了不可能的任務(wù)。
幸好我們有測試套！
以表方法的測試套為例，在第二級粒度上，一個套就是一張表所有表方法測試用例的集合。這個套包含的測試用例大致在 4、5個左右。我們的策略是：二級粒度測試套內(nèi)部的測試用例緊耦合數(shù)據(jù)環(huán)境，而二級粒度套之間的數(shù)據(jù)環(huán)境為松耦合。這通過在每個二級粒度套內(nèi)加入一個數(shù)據(jù) 環(huán)境恢復(fù)用例來實現(xiàn)。
這樣一來，我們可以按照二級粒度的測試套來分工編寫測試代碼。
● 樁函數(shù)的考慮
單元測試是不依賴其他模塊的測試。但是實際代碼中存在對其他模塊函數(shù)的調(diào)用。為了消除這種依賴關(guān)系，就需要編寫樁函數(shù)來替代對外部模塊函數(shù)的調(diào)用。
為了清晰起見，我們的樁函數(shù)集中在一個文件中。
樁函數(shù)只是一個實現(xiàn)，至于原形定義，還是要引用其他模塊的頭文件，這樣可以跟蹤其他模塊函數(shù)接口最新的改動。
● 單元測試工程的規(guī)劃
一個清晰合理的單元測試工程規(guī)劃是必要的，這樣有利于對象的查找和維護。
以DBS模塊的單元測試為例，我們的工程結(jié)構(gòu)如下圖所示。
1.3.4 測試效果的可驗證
如何來量化單元測試的效果？
覆蓋率是一個最直觀的指標(biāo)。我們采用了Rational公司的Pure Coverage工具來獲取覆蓋率。這也是公司推薦的一個簡單易上手的工具。我們要求測試覆蓋率達(dá)到90%以上。
2、自動測試
2.1 每日構(gòu)造
每日構(gòu)造是公司推行的一個最佳實踐。它有一下一些功能：
● 開發(fā)人員及時把最新代碼放入代碼庫，及時check out和check in，避免積累大量代碼
● 及時進行模塊間的整合，及時發(fā)現(xiàn)問題
● 對部分功能進行測試，無需等待
● 使用測試用例工具，對功能進行完整和重復(fù)的檢驗
● 記錄所有程序問題
● 實現(xiàn)解決Bug的自動流程
● 提高正式版本提交的質(zhì)量和速度
● XXXX在軟件上開始推行每日構(gòu)造。
2.2 冒煙測試
如果在每日構(gòu)造的同時進行“冒煙測試”，能最早發(fā)現(xiàn)版本的問題。“冒煙測試”是微軟提出的名詞。其
對象是每一個新編譯的需要正式測試的軟件版本，目的是確認(rèn)軟件基本功能正常，可以進行后續(xù)的正式測試工作。“冒煙測試“的執(zhí)行者是版本編譯人員。
ZXWR-RNS網(wǎng)管項目已有用Robot在網(wǎng)管產(chǎn)品進行冒煙測試的實踐。但是對于前臺軟件，公司內(nèi)部尚未有這方面的嘗試。
2.3 自動測試
基于前期模塊的單元測試工作，一個自然的想法就是在每日構(gòu)造的框架上運行模塊的單元測試代碼，實現(xiàn)前臺軟件的每日自動化測試。這是比“冒煙測試”更全面，更徹底的一個測試。
2.3.1 單板軟件
模塊1
模塊2
模塊n
模擬測試工具
XXXX軟件的架構(gòu)
2.3.2 自動測試的規(guī)劃
2.3.2.1 自動測試的級別
從軟件的構(gòu)成來考慮，分三級構(gòu)造測試工程：
● 模塊單元級：基本的軟件單元
● 板級：由多模塊組成的單板軟件
● 系統(tǒng)集成級：由模擬測試軟件和單板軟件組成
這三個級別的測試是互相補充的關(guān)系。每日構(gòu)造進行三個級別的測試，這樣就比較完整了。
2.3.2.2 測試代碼的管理
要實現(xiàn)每日構(gòu)造并進行自動測試，必須將測試代碼也提升到被測代碼同等的地位，納入CC的管理。在CC上的目錄結(jié)構(gòu)如下所示：
BoardSWS
-BoardTest \\板級測試工程目錄，包含測試用例代碼以及板級測試工程
-SystemTest \\系統(tǒng)集成級工程目錄，不含測試用例，僅含工程
-SCMM
-UnitTest \\模塊單元級測試目錄，包含該級測試用例以及測試工程
-SCMM源碼
-Cunit \\模塊單元級測試用Cunit文件
-其他模塊
-Cunit \\板級測試用Cunit文件
SimuRNC
-SystemTest \\系統(tǒng)集成級測試工程目錄，包含測試工程和測試用例
-SimuRNC源碼
-Cunit
基于這樣的目錄結(jié)構(gòu)，發(fā)布代碼和測試代碼在CC中納入同一個VOB管理比較方便。這樣一來，測試代碼和發(fā)布代碼執(zhí)行相同的CC－CQ關(guān)聯(lián)策略。也就是說，修改測試代碼也需要和CQ關(guān)聯(lián)。
2.3.3 自動測試的執(zhí)行
自動測試由版本室完成。自動測試執(zhí)行分為四個步驟：
● 同步CC的文件到本地
● 編譯各測試工程（VC環(huán)境），輸出編譯結(jié)果文件
● 執(zhí)行編譯結(jié)果，輸出測試執(zhí)行結(jié)果文件
● 將編譯結(jié)果導(dǎo)入
notes
上述步驟都是通過編寫一個BAT文件掛在WINDOWS的“任務(wù)計劃”中每日自動完成。
附：
BAT文件（DBS模塊）
編譯結(jié)果 （DBS模塊）
測試執(zhí)行結(jié)果（DBS模塊）
2.3.4 自動測試的目標(biāo)
依附于每日構(gòu)造機制，自動依序運行三個級別的自動測試，測試產(chǎn)生的結(jié)果輸出到文本文件。然后通過自動分析腳本提取該文件中沒有通過的用例信息，發(fā)送郵件通知相關(guān)責(zé)任人進行分析處理。如此做到“日事日畢”，將故障扼殺在萌芽狀態(tài)，保證代碼質(zhì)量的穩(wěn)定。