上世紀(jì)九十年代，互聯(lián)網(wǎng)的極速發(fā)展讓通訊測試設(shè)備也得到了極大的發(fā)展。那個(gè)年代，能夠?qū)崿F(xiàn)某種測量的硬件是競爭的核心，軟件的目的僅僅是驅(qū)動(dòng)硬件運(yùn)行起來，再提供一個(gè)簡單的界面。所以，最初的產(chǎn)品的軟件結(jié)構(gòu)非常簡單，類似前面的城鐵門禁系統(tǒng)。

• 優(yōu)點(diǎn)：程序簡單明了的實(shí)現(xiàn)了用戶的需求，一個(gè)程序員就可以全部搞定。
• 缺點(diǎn)：完全沒有劃分模塊，底層上層耦合嚴(yán)重。

1. 數(shù)據(jù)處理

用戶要求能將測量結(jié)果保存下來，并可以重新打開。數(shù)據(jù)存儲(chǔ)模塊和界面被獨(dú)立出來。

依然保持上面的主邏輯，但是界面部分不僅可以顯示實(shí)時(shí)的數(shù)據(jù)，也可以從ResultManager中讀取數(shù)據(jù)來顯示。

• 優(yōu)點(diǎn)：數(shù)據(jù)和界面分離的雛形初步顯現(xiàn)
• 缺點(diǎn)：ResultManager只是作為一個(gè)工具存在，負(fù)責(zé)保存和裝載歷史數(shù)據(jù)。界面和數(shù)據(jù)的來源依然耦合的很緊。不同的界面需要的不同數(shù)據(jù)都是通過硬編碼判斷的。

2. 窗口管理

隨著功能不斷復(fù)雜，界面窗口越來越多，原來靠一個(gè)類來繪制各種界面的方式已經(jīng)不能承受。于是窗口的概念被引入。每個(gè)界面都被視為一個(gè)窗口，窗口中的元素為控件。窗口的打開，關(guān)閉，隱藏則由窗口管理器負(fù)責(zé)。

• 優(yōu)點(diǎn)：界面功能以窗口的單位分離，不再是一個(gè)超大的集合。
• 缺點(diǎn)：雖然有了窗口管理器，但是界面依然是直接和底層耦合的，依然是大循環(huán)結(jié)構(gòu)。

3. MVC模式

隨著規(guī)模進(jìn)一步擴(kuò)大，最初的大循環(huán)結(jié)構(gòu)終于無法滿足日益復(fù)雜的需求了。標(biāo)準(zhǔn)的MVC模式被引入，經(jīng)歷了一次大的重構(gòu)。

數(shù)據(jù)中心作為Model被獨(dú)立出來，保存著當(dāng)前最新的數(shù)據(jù)。View被放在了獨(dú)立的任務(wù)中執(zhí)行，定期從DataCenter輪詢數(shù)據(jù)。用戶的操作通過View發(fā)送給Controller，進(jìn)一步調(diào)用硬件驅(qū)動(dòng)執(zhí)行。硬件執(zhí)行的結(jié)果從驅(qū)動(dòng)到Controller更新到DataCenter中。界面，數(shù)據(jù)，命令三者基本解耦。ResultManager成為DataCenter的一個(gè)組件，View不再直接與其通訊。

MVC模式的引入，第一次讓這個(gè)產(chǎn)品了有真正意義上職責(zé)明晰，功能獨(dú)立的架構(gòu)。

4. 大量類似模塊，低效的復(fù)用

到上一步，作為一個(gè)單獨(dú)的嵌入式設(shè)備，其架構(gòu)基本可以滿足需求。但是隨著市場的擴(kuò)展，越來越多的設(shè)備被設(shè)計(jì)出來。這些設(shè)備雖然執(zhí)行的具體測量任務(wù)不同，但是他們都有著同樣的操作方式，類似的界面，更主要的是，它們面臨的問題領(lǐng)域是相同的。長期以來，復(fù)制和粘貼是唯一的復(fù)用方式，甚至類名變量名都來不及改。一個(gè)錯(cuò)誤在一個(gè)設(shè)備上被修正，同樣一段代碼的錯(cuò)誤在其他設(shè)備上卻來不及修改。而隨著團(tuán)隊(duì)規(guī)模的擴(kuò)大，甚至MVC的基本架構(gòu)在一些新設(shè)備上都沒能遵守。

最終框架被引入了這個(gè)系列的產(chǎn)品?？蚣艽_定了如下內(nèi)容：

• MVC模式的基本架構(gòu)
• 窗口管理器和組件布局算法
• 多國語言方案（字符串管理器）
• 日志系統(tǒng)
• 內(nèi)存分配器和內(nèi)存泄露檢測

5. 遠(yuǎn)程控制

客戶希望將設(shè)備固定安放在網(wǎng)絡(luò)的某個(gè)位置，作為“探針”使用，在辦公室通過遠(yuǎn)程控制來訪問這個(gè)設(shè)備。這對(duì)于原本是作為純手持設(shè)備設(shè)計(jì)的系統(tǒng)又是一個(gè)挑戰(zhàn)。幸運(yùn)的是，MVC架構(gòu)具有相當(dāng)?shù)膹椥?，早期的投入獲得了回報(bào)。

TL1 Server 對(duì)外提供基于Telnet的遠(yuǎn)程控制接口。在系統(tǒng)內(nèi)部，它的位置相當(dāng)于View，只和原有的Controller和DataCenter通訊。

6. 自動(dòng)化的TL1解釋器

由于TL1命令相當(dāng)多，而TL1又往往不是客戶的第一需求，很多設(shè)備的TL1命令開始不完整。究其原因，還是手寫TL1命令的解釋器太累。后來通過引入Bison和Flex，這個(gè)問題有所改善，但還是不足。自動(dòng)化代碼生成在這個(gè)階段被引入。通過以如下的格式定義TL1，工具可以自動(dòng)生成TL1的編碼和解碼器代碼。

CMD_NAME
{
  cmd = “SET-TIME-CONFIG::<ctag>::<year>,<month>,<day>,<hour>,<minute>,[<second>]”
  year = 1970..2100
  month = 1..12
  day = 1..31
  hour = 0..23
  minute = 0..59
  second = 0..59
}

7. 測試的難題

經(jīng)過數(shù)十年的積累，產(chǎn)品已經(jīng)成為一個(gè)系列，幾十種設(shè)備。大部分設(shè)備進(jìn)入了維護(hù)期，經(jīng)常有客戶提一些小的改進(jìn)，或者要求修正一下缺陷。繁重的手工回歸測試成為了噩夢(mèng)。

基于TL1的自動(dòng)化測試極大的解放了測試人員。通過在PC上運(yùn)行的測試腳本，回歸測試變得簡單而可靠。唯一不足的是界面部分無法驗(yàn)證。

基于Test Quest的自動(dòng)化工具需要在設(shè)備運(yùn)行的pSOS系統(tǒng)上開發(fā)一個(gè)類似遠(yuǎn)程桌面的軟件，而這在pSOS上并非易事。不過好消息是，由于框架固定了界面的風(fēng)格和布局算法，基于Test Quest的自動(dòng)化工具會(huì)有很高的識(shí)別效率。

8. 小結(jié)

從這個(gè)實(shí)際的嵌入式產(chǎn)品重構(gòu)的歷程可以看出，第三步引入MVC模式和第四步的框架化是非常關(guān)鍵的。成熟的MVC模式保證了后續(xù)一系列的可擴(kuò)充性，而框架則保證了這個(gè)架構(gòu)的在所有產(chǎn)品中的準(zhǔn)確重用。