摘 要： 分析了當前本地化版本驗證測試BV中存在的問題，提出了PM。相比當前的BV測試，PM機制實現(xiàn)了所有測試結(jié)點、測試報告有機統(tǒng)一的管理。PM機制有助于提高整個BV測試系統(tǒng)的管理能力、擴展能力和測試性能。
??? 關鍵詞： 版本驗證；策略模型；配置匹配服務器，配置匹配客戶端

?

?? 隨著測試工具的不斷完善，使得企業(yè)追求最優(yōu)的質(zhì)量成本成為可能。目前在軟件開發(fā)過程中，更多的會采用迭代式的開發(fā)過程。在開發(fā)過程中強調(diào)在較短的時間間隔中產(chǎn)生多個可執(zhí)行、可測試的軟件版本。軟件的本地化過程更是如此：會頻繁地生成多個所有要支持的語言版本。一般來說，公司會根據(jù)市場需求決定語言數(shù)量。但是軟件本地化是軟件重要的競爭因素之一。所以為了將來占有更多的市場，公司都會更大范圍地執(zhí)行軟件本地化。一些特殊的軟件，例如：微軟的Windows和Office軟件，需要支持幾百種語言。在多個語言版本的產(chǎn)生過程中，由于軟件設計的不全面或者更多其他原因，例如：軟件設計過程中沒有考慮雙字節(jié)字符的支持和字符長度處理問題或者軟件周期短，都不可避免地導致出現(xiàn)一些壞的語言版本。特別是一些重大的錯誤存在于軟件的安裝、卸載過程中或者一些重要功能模塊的基本操作中。如果壞的語言版本比較多或者某個語言壞得版本太多，都會大大延誤測試進度，測試成本提高。
??? 目前大多數(shù)公司都會在所有測試人員介入之前，對軟件作版本驗證BV測試(Build Validation)，保證版本的質(zhì)量，以便可以更好地控制測試進度^[4]。目前的BV測試存在的問題：
??? (1)測試系統(tǒng)對測試結(jié)點不做任何管理。當某個測試機發(fā)生故障，無法自動察覺。
??? (2)測試系統(tǒng)對測試數(shù)據(jù)不做任何管理和分析。只簡單保存，無法挖掘更有用的信息。
??? (3)測試系統(tǒng)總是選擇重要的語言進行測試。某些語言長期被疏忽，一些重大問題無法及時發(fā)現(xiàn)。
??? (4)系統(tǒng)擴展性、自動性差。當測試結(jié)點達到一定數(shù)量，需要更多的人工干預。
??? 下面將介紹目前本地化軟件BV測試的結(jié)構(gòu)存在的問題以及引入PM機制后的BV測試。
1 本地化軟件的BV測試
??? 目前，大多數(shù)公司都要求寫自動化測試腳本，以便在新的版本生成后通過運行腳本達到版本檢驗的目的。軟件本地化過程中，對本地化版本的BV測試與英文的BV測試的區(qū)別在于需要運行的語言平臺數(shù)量不同。 英文的BV測試只在英文平臺上運行，而本地化的測試在理想狀態(tài)下需要在所有支持的語言平臺上運行。由于產(chǎn)品市場的影響，對于所有要支持的語言的重要程度和優(yōu)先級別是不同的。同時，受到測試周期和預算的限制，一般不會對所有的語言都進行BV測試，而只選擇重要的語言。
??? 在目前的BV測試中，多個語言平臺的架構(gòu)可以是多個獨立的PC，也可以使用VMWare。如圖1所示。

??? 當服務器接受到新版本生成信息，就向所有測試機發(fā)出“測試指令”， 每個語言測試平臺開始獨立進行測試，測試結(jié)束后產(chǎn)生測試報告并發(fā)送到服務器。服務器對各個語言平臺的測試機除了發(fā)送測試開始指令外，不進行任何其他管理。如果某個測試機出現(xiàn)故障，無法正常工作，服務器無法感知并通知管理人員。每個測試平臺直到測試結(jié)束后才向服務器發(fā)送測試報告。而且每個測試報告都是獨立的，不利于對測試結(jié)果進行綜合分析，產(chǎn)生更加有意義的信息。所有這些都使得BV測試不夠完善。
2 策略模型PM(Policy Model)機制^[1-3]
2．1 PM機制的結(jié)構(gòu)和流程
??? PM機制的具體實現(xiàn)、采用了PM機制后的BV測試架構(gòu)，集中統(tǒng)一管理BV測試結(jié)構(gòu)中的所有測試結(jié)點，把BV測試過程中的所有數(shù)據(jù)信息集中統(tǒng)一管理并生成內(nèi)容豐富的報表。
2.1.1 PM機制的結(jié)構(gòu)
??? 在PM機制中主要包括兩種對象：一個DMS(Deployment Map Server)和多個DMA(Deployment Map Agent)。
??? DMS是整個PM機制的核心，DMS在開始測試前主動地發(fā)現(xiàn)并收集每個測試結(jié)點信息。并保存最新的測試結(jié)構(gòu)信息和測試結(jié)構(gòu)中每個測試結(jié)點的策略信息和測試結(jié)果。其中測試結(jié)構(gòu)信息不僅包括了每個結(jié)點的硬件信息和軟件信息，還包括網(wǎng)絡連接狀態(tài)和層次結(jié)構(gòu)。
??? DMA是客戶端，會自動向DMS發(fā)送結(jié)點的最新狀態(tài)，包括是否正常啟動、層次結(jié)構(gòu)信息、測試的結(jié)果、策略狀態(tài)信息等等。當結(jié)點有任何內(nèi)容更改，DMA會自動通知DMS更新信息。當DMS無法訪問時，DMA會暫時保存信息，并不斷嘗試訪問DMS，直到把信息發(fā)送給DMS。所以只要在要測試的機器上安裝DMA，此結(jié)點的所有物理信息以及所有測試過程中的動態(tài)信息會自動發(fā)送到DMS，保證了DMS中信息的正確性和及時性。
??? 在PM機制中，要實現(xiàn)對所有測試結(jié)點和數(shù)據(jù)信息的集中統(tǒng)一管理。
??? (1)實現(xiàn)對所有測試結(jié)點的統(tǒng)一管理，PM機制主要通過由DMS向測試結(jié)構(gòu)中的所有結(jié)點配置同一測試策略來實現(xiàn)。策略主要分為以下3種：
??? 配置策略(Configuration Policy)：實現(xiàn)所有測試結(jié)點的統(tǒng)一系統(tǒng)和軟件配置。
??? 任務策略(Job Policy)：實現(xiàn)所有測試結(jié)點的統(tǒng)一操作和管理。
??? BV測試策略：實現(xiàn)所有測試結(jié)點正確實施BV測試。當一個新的版本生成后，DMS自動生成一個相應的軟件測試包，并根據(jù)用戶定義生成一個對應的測試策略。策略一經(jīng)生成，整個測試將完全按照策略定制的信息在整個測試結(jié)構(gòu)中的所有結(jié)點實施。
??? (2)實現(xiàn)數(shù)據(jù)信息的統(tǒng)一管理，PM機制主要通過DMS的主動收集和DMA的自動更新實現(xiàn)信息的自動同步和管理。
2.1.2 PM機制的工作流程
??? PM機制的工作流程如圖2所示：

??? 通過PM機制，實現(xiàn)了對BV測試中所有測試結(jié)點以及所有測試結(jié)點的測試信息的集中統(tǒng)一管理。
2．2 PM機制中如何實現(xiàn)信息的自動收集和同步^[5]
??? PM機制中信息的自動收集和同步是整個機制的核心功能。在PM機制中，整個測試結(jié)構(gòu)中的所有結(jié)點都是相通的，呈樹型結(jié)構(gòu)。除了根結(jié)點DMS外都有父結(jié)點，除了葉子結(jié)點外都有子結(jié)點。這種父子關系是通過PARENT屬性定義的，PARENT關系網(wǎng)絡連結(jié)了測試結(jié)構(gòu)中所有的結(jié)點，形成一個測試整體。
??? PM機制中任何一個DMS、DMA都有一個相應的對象是PMDB(Policy Model Database)。PMDB的定義類似數(shù)據(jù)庫包括可以訪問的用戶、組、對象以及訪問策略。 此外，還包含了一個SUBSCRIBER列表。SUBSCRIBER可以定義為任何一個PMDB。能夠更新某個SUBSCRIBER的PMDB稱作該SUBSCRIBER的父親。子SUBSCRIBER的任何更新會自動上傳到父SUBSCRIBER中。其中主機(Host)作為一個特殊對象，可以定義任何一個PMDB為其父SUBSCRIBER。
??? 一般來說，創(chuàng)建PMDB時需指定授權(quán)可訪問的用戶/組、父結(jié)點，還要指定可訪問的終端對象，即SUBSCRIBER。整個測試結(jié)構(gòu)結(jié)點間的SUBSCRIBER關系實際上是結(jié)點中PMDB之間的SUBSCRIBER關系。
??? 圖3所示為PMDB的層次結(jié)構(gòu)一般定義。

??? 整個BV測試層次結(jié)構(gòu)的定義過程也就是PARENT關系網(wǎng)絡的定義過程，同時也是PMDB層次結(jié)構(gòu)的定義過程。而SUBSCRIBER關系網(wǎng)絡定義卻不同，SUBSCRIBER關系網(wǎng)絡可以和PARENT關系網(wǎng)絡保持一致，但有時為了提高可訪問性，每個PMDB要建立多個SUBSCRIBER關系。主PMDB通過比較更新信息的時間戳來確定是否接受新的更新。
??? 在圖4所示PM機制的工作流程圖中可以看到2種信息流。一種是策略(POLICY)；另一種是通知(NOTIFICATION)?！安呗浴笔茄刂鴾y試結(jié)構(gòu)中結(jié)點的PARENT網(wǎng)絡流動。而“通知”是沿著測試結(jié)構(gòu)中SUBSCRIBER網(wǎng)絡流動。

?

??? 在PM機制中，通過定義結(jié)點間的PARENT和SUBSCRIBER兩種關系，使測試結(jié)構(gòu)中所有結(jié)點成為一個整體。通過POLICY和NOTIFICATION兩種信息流，實現(xiàn)了所有結(jié)點和結(jié)點信息的集中統(tǒng)一管理。
2．3 信息存儲及測試報告
2．3．1 信息存儲
??? 采用PM機制后，DMS結(jié)點存儲了大量的測試信息，占用很大的存儲空間。如何有效地存儲并管理這些數(shù)據(jù)是必須考慮的問題。在PM機制中采用了按照時間合并數(shù)據(jù)的方法。PM機制會保留最近的5個工作日的單個測試詳細信息。用戶可以查看當天或者過去4天詳細的所有語言平臺測試信息。當測試信息早于5天前，PM 機制定期的合并信息形成每天、每星期、每月的數(shù)據(jù)。這個過程類似數(shù)據(jù)庫Rollup。圖5所示為用戶可以根據(jù)具體項目測試信息定義數(shù)據(jù)合并過程的時間表，保留多少天的詳細數(shù)據(jù)和合并數(shù)據(jù)的規(guī)則。

2．3．2 測試報告
??? DMS結(jié)點存儲了所有的測試信息。從信息存儲策略可以看出PM 機制可以很容易地形成各種測試報告，并且可以通過對不同語言平臺測試信息的對比，挖掘出更加有意義的信息。例如：如果某個語言平臺測試結(jié)果總是正常，說明本地化過程對此語言比較規(guī)范，就可以考慮更換其他語言。因為對于某些重要的語言，設計人員和測試人員都會重視并提前考慮很多。相對來說，對于比較偏的語言會考慮的少一些。雖然首先需要保證重要語言平臺的正確性，但事實上比較偏的語言由于缺少重視出錯的機率更大。
??? 對大量歷史數(shù)據(jù)分析的測試報告可以對此產(chǎn)品的開發(fā)設計有一定指導性的意義。
2．4 實驗數(shù)據(jù)和性能比較
??? 采用PM模型前和采用之后的對比如表1所示。隨著結(jié)點的增加，測試系統(tǒng)性能對比會非常明顯。

?

3 PM機制的優(yōu)化
??? 目前， 在PM機制的設計中DMA的層次結(jié)果可以給出很靈活的定義，但是整個PM機制只能有一個DMS結(jié)點。目前的PM機制不適合測試結(jié)點分布比較廣的BV測試。并且整個測試架構(gòu)中只有一個DMS結(jié)點對測試的高訪問性具有一定的風險，今后的設計中需要加強DMS層的管理。
??? BV測試中采用PM機制，實現(xiàn)了對所有測試結(jié)點、測試過程中各個動態(tài)測試信息的集中統(tǒng)一管理，通過對測試數(shù)據(jù)的合并和分析，可以做到更有效地管理測試數(shù)據(jù)并挖掘出更有價值的信息，使得BV測試更加完善。

參考文獻
[1] 張茂林.軟件自動測試的研究與程序?qū)崿F(xiàn)[J].北京航空航天大學學報，1997，23(1)：74-80.
[2] 趙暉，王剛.軟件自動測試方法淺談[J].雷達與對抗，1997(3)：68-72.
[3] 凌永發(fā)，張云生，郭秀萍.軟件測試自動化的腳本技術[J].云南民族學院學報(自然科學版)，2002，11(1)：544-548.
[4] 王華偉，崔啟亮.軟件本地化——本地化行業(yè)透視與實務指南[M].北京：電子工業(yè)出版社，2005.
[5] 候俊杰.深入淺出MFC(第2版)[M].武漢：華中科技大學出版社，2005.