王 昊 陳伯慧 周文斌 郭 軍

1 中國聯(lián)通遼寧省分公司 沈陽 110041

2 東北大學信息科學與工程學院 沈陽 110819

引言

復雜業(yè)務(wù)系統(tǒng)的持續(xù)演進已經(jīng)成為中國聯(lián)通信息化建設(shè)的常態(tài)。中國電信業(yè)進入到了全業(yè)務(wù)運營時代[1-2]，聯(lián)通同時經(jīng)營移動、固定、數(shù)據(jù)網(wǎng)絡(luò)，全方位開展接入服務(wù)、通信業(yè)務(wù)、增值業(yè)務(wù)、內(nèi)容應(yīng)用等，用戶量和數(shù)據(jù)量非常龐大，這使得現(xiàn)有業(yè)務(wù)越發(fā)復雜。在這當中，聯(lián)通經(jīng)營業(yè)務(wù)不斷重組、2G、3G、4G多次升級，計費業(yè)務(wù)頻繁變更，系統(tǒng)融合和集中一體化持續(xù)推進等，使得對復雜業(yè)務(wù)系統(tǒng)進行更敏捷的在線演進、持續(xù)升級成為常態(tài)。

如何在業(yè)務(wù)系統(tǒng)演進過程中確保質(zhì)量，已經(jīng)成為聯(lián)通信息化建設(shè)中的關(guān)鍵問題。演進過程中常常出現(xiàn)功能失效、流程漏洞、性能較差等各種各樣的情況[3-4]，導致演進成本較高、開發(fā)周期較長、社會影響較大。

傳統(tǒng)的由開發(fā)商主導的測試過程不能滿足聯(lián)通業(yè)務(wù)持續(xù)演進的需求。首先，集成測試效果較差。遼寧聯(lián)通業(yè)務(wù)支撐系統(tǒng)由營業(yè)、計費、號線資源、服務(wù)開通、融合客服等20余套子系統(tǒng)構(gòu)成，分別由不同的開發(fā)商進行開發(fā)，開發(fā)商往往聚焦自己分包任務(wù)的質(zhì)量，而對集成后的效果分析和質(zhì)量問題關(guān)注較少，導致集成測試效率較低，一旦出現(xiàn)問題，常?；ハ嗤普?。其次，測試技術(shù)水平較低。開發(fā)商在測試技術(shù)方面不夠?qū)I(yè)，既缺少掌握測試標準、測試體系、專業(yè)技術(shù)的測試技術(shù)人員，也缺乏價格昂貴的測試工具，并且在可復用測試用例庫、大并發(fā)性能測試、運營性能優(yōu)化等聯(lián)通迫切需要的高端檢測技術(shù)方面能力不足。最后，質(zhì)量掌控能力較弱：對于聯(lián)通而言，開發(fā)商主導的測試過程如同灰盒一樣不透明，測試的完整性、可信度、完成度、缺陷等級等，都不能清晰掌握。

為解決上述問題，遼寧聯(lián)通在過去的幾年中，一直探索業(yè)務(wù)持續(xù)演進過程中多方驅(qū)動的全生命周期測試方法。

1 業(yè)務(wù)全生命周期測試過程

根據(jù)聯(lián)通業(yè)務(wù)演進特點，將各個復雜的質(zhì)量活動科學、合理、規(guī)范地管理起來是確保業(yè)務(wù)演進質(zhì)量的基礎(chǔ)。遼寧聯(lián)通參考IBM RUP(Rational Unify Process)的定義[5]，針對業(yè)務(wù)演進的迭代特點[6]，制定了業(yè)務(wù)全生命周期測試過程UUP(Unicom Unify Process)，如圖1所示。業(yè)務(wù)生命周期可以分為初始、精化、構(gòu)建、交付和運維等5個階段，每個階段都有各自的使命和里程碑，以及一系列的迭代。質(zhì)量活動包括測試策略制定、計劃評審、需求評審、風險控制、代碼審查、單元測試、集成測試、配置審計、缺陷跟蹤和分析、運行監(jiān)控、問題評估等，它們共同構(gòu)成了質(zhì)量活動集。每個質(zhì)量活動都相對獨立，并有明確的任務(wù)、流程和交付物。與質(zhì)量相關(guān)的活動可以貫穿整個生命周期，在不同的階段執(zhí)行不同的任務(wù)。

圖1 聯(lián)通業(yè)務(wù)全生命周期測試過程UUP

1) 初始階段。提升問題定義、可行性分析以及需求分析質(zhì)量。包括評審標書、概念文檔、可行性分析報告和需求文檔等，以縮短軟件開發(fā)項目的落地周期、降低落地風險。

2) 精化階段。提升軟件架構(gòu)質(zhì)量。包括確保理解用戶需求(可基于UML建立需求分析模型)；審查開發(fā)計劃；評估設(shè)計文檔，確保架構(gòu)的可靠性、可擴展性、可實施性和可理解性等；制定集成測試方案。

3) 構(gòu)建階段。提升實施質(zhì)量。包括從第三方的角度，和開發(fā)商實現(xiàn)迭代式的互動，發(fā)現(xiàn)軟件缺陷；識別開發(fā)過程中的風險；控制需求變更；控制實施進度，保證項目如期完成等。

4) 交付階段。提升上線質(zhì)量。包括對集成的系統(tǒng)進行功能、性能、安全等測試，以降低系統(tǒng)上線風險；對交付的開發(fā)文檔、用戶手冊、代碼、可執(zhí)行系統(tǒng)等進行審查。

5) 運營階段。提升運營質(zhì)量。包括對業(yè)務(wù)支撐系統(tǒng)進行持續(xù)的遠程監(jiān)控，偵測系統(tǒng)缺陷、老化狀態(tài)和安全漏洞，對問題、缺陷和新增需求進行收集和管理，分析原因并制定應(yīng)對策略，以確保系統(tǒng)穩(wěn)定、可靠并滿足業(yè)務(wù)發(fā)展的需要；在系統(tǒng)的演進過程中設(shè)計并執(zhí)行完整的、嚴謹?shù)臏y試方案，制定風險管理機制和應(yīng)急響應(yīng)策略，以確保系統(tǒng)演進效果。

為更有效地支持業(yè)務(wù)全生命周期測試過程，遼寧聯(lián)通建立“全流程需求變更和測試管理系統(tǒng)”，加強了對整個生命周期各個環(huán)節(jié)的管控，獲得良好的實踐應(yīng)用效果。

2 敏捷協(xié)作模式

如何將聯(lián)通業(yè)務(wù)演進過程的各參與方緊密組織在一起，為共同的產(chǎn)品質(zhì)量目標沖刺，以更快的速度達到更高的質(zhì)量，這是測試管理的關(guān)鍵問題。遼寧聯(lián)通從2009年起，引入第三方測試，即在開發(fā)商測試的基礎(chǔ)上，增加第三方測試環(huán)節(jié)。并且基于Scrum思想[7]，探索由聯(lián)通、開發(fā)團隊、第三方測試團隊共同組成的多方測試驅(qū)動的聯(lián)通業(yè)務(wù)系統(tǒng)持續(xù)演進的敏捷協(xié)作模式(如圖2所示)，三方形成了緊密互動關(guān)系。

1)三方都有迭代，每一輪迭代都有各自的任務(wù)。由于職責不同，任務(wù)也不同。2)三方以產(chǎn)品質(zhì)量目標為核心。聯(lián)通定義產(chǎn)品質(zhì)量目標，開發(fā)團隊實現(xiàn)這個目標，而第三方測試團隊則負責驗證和保障這一目標。3)聯(lián)通將需求文檔與需求變更交付給開發(fā)團隊，從開發(fā)團隊和第三方測試團隊活動項目狀態(tài)，并以此為參考對項目進行控制。4)開發(fā)團隊定期向聯(lián)通提交項目狀態(tài)，并在迭代過程中向第三方測試團隊持續(xù)交付待測模塊。5)第三方測試團隊以持續(xù)驗證為核心，將質(zhì)量問題快速反饋給開發(fā)團隊，配合開發(fā)團隊進行協(xié)同開發(fā)；同時將測試結(jié)果、建議以及項目狀態(tài)反饋給聯(lián)通。6)第三方測試團隊與開發(fā)團隊都對項目狀態(tài)進行反饋，其不同點在于：前者的反饋數(shù)據(jù)源于測試結(jié)果，并經(jīng)過統(tǒng)計分析，是客觀、公正、清晰、可度量和可信的；而后者的反饋則往往是主觀、避重就輕、模糊、不可度量和可信性較低的。

圖2 聯(lián)通質(zhì)量保證敏捷協(xié)作模式

遼寧聯(lián)通通過“全流程需求變更和測試管理系統(tǒng)”，將聯(lián)通、開發(fā)商和第三方測試機構(gòu)緊密組織在一起，有效提升需求透明度、并行開發(fā)效率、集成測試質(zhì)量，提高了遼寧聯(lián)通的進度掌控能力、系統(tǒng)需求變更管理能力。

3 可復用測試資產(chǎn)

多年來，聯(lián)通龐雜的業(yè)務(wù)知識和測試經(jīng)驗都集中在專業(yè)人員的大腦當中，或者復雜、無規(guī)范和厚重的文檔里。如何在業(yè)務(wù)演進過程中梳理、提煉、積累并有效地繼承和復用測試資產(chǎn)，以達到更快的測試響應(yīng)、更低的測試成本和更成熟的測試方案，這是聯(lián)通在測試技術(shù)上面臨的重要問題。遼寧聯(lián)通在長期業(yè)務(wù)演進過程中，逐步積累起來的可復用測試資產(chǎn)，包括業(yè)務(wù)模型庫和測試用例庫，它們是高效率測試的重要基礎(chǔ)。

1) 業(yè)務(wù)模型庫。業(yè)務(wù)模型是對聯(lián)通業(yè)務(wù)對象、業(yè)務(wù)流程的可視化表示。它專注于分析業(yè)務(wù)領(lǐng)域本身，發(fā)掘重要的業(yè)務(wù)領(lǐng)域概念，并建立業(yè)務(wù)領(lǐng)域概念之間的關(guān)系。

在特定領(lǐng)域里，面向業(yè)務(wù)流程的聯(lián)通深度應(yīng)用和面向業(yè)務(wù)活動的作業(yè)處理成為系統(tǒng)核心，系統(tǒng)中領(lǐng)域知識的廣度和復雜度也隨之成幾何級數(shù)增長，對于測評人員而言，軟件復雜度、彈性、可靠性和效率等都受到前所未有的挑戰(zhàn)。即測評人員僅從某個單獨的應(yīng)用軟件理解業(yè)務(wù)，通常存在理解不完整、理解歧義，甚至理解錯誤等情況，并且分析業(yè)務(wù)所需要的時間較長。然而，特定領(lǐng)域中的軟件產(chǎn)品存在共性需求，將其業(yè)務(wù)流程抽象出來，可以復用各領(lǐng)域業(yè)務(wù)經(jīng)驗，減少業(yè)務(wù)理解的偏差，提高測試效率。

遼寧聯(lián)通基于UML(Unif i ed Modeling Language，統(tǒng)一建模語言)，主要采用部署圖、用例圖、活動圖和時序圖等構(gòu)建ESS、BSS等核心業(yè)務(wù)的模型庫，形成重要的可復用資產(chǎn)。目前，已經(jīng)形成業(yè)務(wù)模型1256個。

2) 測試用例庫。測試用例的復用可以有效提高軟件系統(tǒng)的維護效率并降低維護的成本[8]。遼寧聯(lián)通建立軟件測試用例庫的目的是為了通過復用測試經(jīng)驗、加快業(yè)務(wù)演進的驗證速度。在功能測試實施過程中，直接復用成熟的測試用例所付出的代價要遠遠小于重新開發(fā)測試用例，因此，測試用例的可復用程度直接關(guān)系到回歸測試的實施效率。復用和共享軟件測試過程中最重要的知識資產(chǎn)——測試用例，是降低軟件測試費用的一個重要途徑。

遼寧聯(lián)通參考UML類圖的建模思想[9]，創(chuàng)新性地提出測試用例建模方法，如圖3所示。

圖3 測試用例模型圖(登錄)

①每個類是一個測試用例套，用例套中的屬性是測試數(shù)據(jù)集的抽象表示，方法則是測試用例的抽象表示。前綴F、S、P分別表示功能、安全和性能類的測試用例。②所有測試用例套都包含在某個用例庫里。③子測試用例套可以繼承父測試用例套中的所有測試用例和測試數(shù)據(jù)集。④每個測試用例都有一份測試用例文檔與之配套。⑤測試用例庫分為可復用測試用例庫和領(lǐng)域業(yè)務(wù)測試用例庫。

4 性能監(jiān)測預警平臺

近年來，隨著聯(lián)通業(yè)務(wù)的迅速發(fā)展，保證業(yè)務(wù)系統(tǒng)在運營過程中的性能穩(wěn)定性和可靠性已經(jīng)成為信息化建設(shè)亟需解決的主要共性問題之一。特別是隨著中國聯(lián)通系統(tǒng)融合和集中一體化的推進，各省聯(lián)通在性能測試方面，由傳統(tǒng)的負載能力測試，逐步轉(zhuǎn)為以客戶感知為主要目標的性能測試。在系統(tǒng)上線前進行軟件性能測試的傳統(tǒng)方法已經(jīng)無法保證系統(tǒng)運營時的可靠性和穩(wěn)定性，這是由于：①用戶行為難以預知；②軟件老化造成系統(tǒng)性能下降；③部署環(huán)境動態(tài)伸縮隨需而變；④業(yè)務(wù)系統(tǒng)常常在線演進；⑤系統(tǒng)缺陷幾乎無法窮盡。變化和缺陷是系統(tǒng)運營過程中的常態(tài)，而傳統(tǒng)的上線前測試不能模擬系統(tǒng)運營過程中各種變化，并無法發(fā)現(xiàn)系統(tǒng)的所有缺陷。

在系統(tǒng)運營過程中進行性能監(jiān)控和預測、提出性能調(diào)優(yōu)建議是解決這些問題的可行之道。遼寧聯(lián)通與遼寧北方實驗室有限公司和東北大學進行產(chǎn)學研合作，研究在線業(yè)務(wù)性能監(jiān)測和預警平臺，通過持續(xù)監(jiān)測業(yè)務(wù)狀態(tài)，預測可能發(fā)生的并發(fā)情況；通過評估系統(tǒng)的負載能力，判斷系統(tǒng)性能衰減趨勢；通過分析性能指標，指導部署環(huán)境的配置策略；通過自動執(zhí)行測試用例，支持系統(tǒng)在線演進；通過分析性能瓶頸，發(fā)現(xiàn)系統(tǒng)深層缺陷。

平臺部署在云計算環(huán)境下，邏輯架構(gòu)如圖4所示，主要包括5個功能。1)并發(fā)模擬器。面向多應(yīng)用多業(yè)務(wù)，模擬用戶行為持續(xù)發(fā)出并發(fā)請求。2)并發(fā)控制器。制定并發(fā)測試策略，分發(fā)測試腳本，分解并發(fā)請求任務(wù)，控制各虛擬機時間同步，控制并發(fā)過程。3)監(jiān)控數(shù)據(jù)收集器。收集用戶請求訪問日志，分析用戶訪問行為，形成性能狀態(tài)數(shù)據(jù)庫。4)性能分析和預警模塊。采用多種算法分析系統(tǒng)性能狀態(tài)、運行趨勢，在必要時發(fā)出預警信號；5)性能狀態(tài)和趨勢可視化界面。采用多種圖表動態(tài)呈現(xiàn)業(yè)務(wù)系統(tǒng)性能狀態(tài)和趨勢，以及可能的瓶頸位置。

5 測試實踐

遼寧聯(lián)通在長期的業(yè)務(wù)運營實踐當中，不斷探索業(yè)務(wù)演進過程中的全生命周期測試方法?！吧驌徼F升位并網(wǎng)項”是一個典型的實踐案例。

2010年5月，遼寧省通信管理局組織召開了沈撫鐵本地網(wǎng)共用024升位并網(wǎng)工作啟動會，要求于2011年8月完成項目。這個項目要改造的系統(tǒng)較多，業(yè)務(wù)功能覆蓋面很大，系統(tǒng)間關(guān)聯(lián)關(guān)系密切，涉及多個部門，溝通、協(xié)調(diào)復雜度高，存在信息不對稱和不確定性等風險。這些情況對軟件測試工作提出了非常高的要求。遼寧聯(lián)通按照業(yè)務(wù)持續(xù)演進過程中全生命周期測試方法，對該項目測試工作的組織和實施如下。

圖4 遼寧聯(lián)通業(yè)務(wù)系統(tǒng)性能監(jiān)測和預警平臺邏輯架構(gòu)

1) 在過程方面，按照項目全生命周期測試過程來組織。明確內(nèi)部各個相關(guān)部門、外部各個開發(fā)分包商以及第三方測試機構(gòu)的迭代計劃、任務(wù)、里程碑，確定了集成測試的組織者、責任人，提出并網(wǎng)后運營過程中的各種風險應(yīng)對預案，包括在線演進過程中的應(yīng)急響應(yīng)、測試準備、方案評審、入場時機、執(zhí)行單位、問題發(fā)布、缺陷管理、回歸測試等管理機制。這些工作使得測試過程變得有條不紊、秩序井然，項目控制能力迅速提升，保證了項目的順利實施。

2) 在管理方面，運用敏捷協(xié)作模式。各個參與方的工作包括：①遼寧聯(lián)通負責向開發(fā)商提出業(yè)務(wù)需求，向第三方測試機構(gòu)提出測試需求。②開發(fā)商負責產(chǎn)品開發(fā)并向運營商通報開發(fā)風險與進度，向第三方測試分別提供待測系統(tǒng)的測試案例。③第三方測試機構(gòu)負責測試工作并向開發(fā)商提供測試缺陷、測試案例整改意見、缺陷跟蹤情況，向運營商提供測試業(yè)務(wù)模型、第三方測試用例、測試總結(jié)與分析、開發(fā)商測試案例評價、測試日報、周報、月報。④考慮到這個項目的復雜性，省公司又抽調(diào)各市公司業(yè)務(wù)骨干到測試現(xiàn)場執(zhí)行測試，盡可能地保證測試質(zhì)量、降低演進風險。

每天早上，遼寧聯(lián)通都組織“測試站會”，由測試工作的各個參與方匯報進展和當日計劃，及時溝通協(xié)作內(nèi)容。在每個迭代(大約每半個月為一個演進迭代周期)中，遼寧聯(lián)通聯(lián)合各個測試參與方召開“沖刺規(guī)劃會議”，制定迭代計劃，確定本輪迭代的測試任務(wù)列表、優(yōu)先級、執(zhí)行單位、執(zhí)行時間等。在迭代結(jié)束時，召開“沖刺回顧會議”，總結(jié)測試任務(wù)的完成情況。運用敏捷協(xié)作模式，使得測試工作變得非常高效，縮短了測試周期。

3) 在技術(shù)方面，積累和使用可復用測試資產(chǎn)。在沈撫鐵024并網(wǎng)測試項目中，面對復雜、龐大的業(yè)務(wù)內(nèi)容以及來自聯(lián)通、開發(fā)商和第三方測試機構(gòu)的業(yè)務(wù)掌握能力和技術(shù)水平參差不齊的測試人員，遼寧聯(lián)通提出必須通過建立業(yè)務(wù)模型庫和測試用例庫，充分整合業(yè)務(wù)人員和測試人員的經(jīng)驗與知識，以提高測試的科學性、完整性，并通過復用測試用例提高測試效率。在該項目中共積累測試業(yè)務(wù)模型205套，積累可復用測試用例1 245個。根據(jù)第三方測試機構(gòu)統(tǒng)計，基于業(yè)務(wù)模型庫和測試用例庫，測試人員平均測試效率由過去的每人每天執(zhí)行125個測試用例，提高到256個。積累和使用可復用測試資產(chǎn)，在業(yè)務(wù)演進過程中大幅提高了測試效率。

4) 在工具方面，采用性能在線監(jiān)測和預警平臺。性能是沈撫鐵024并網(wǎng)項目測試的一個關(guān)注重點。遼寧聯(lián)通除在上線前進行周密的性能測試外，還首次在該項目中使用性能在線監(jiān)測和預警平臺。①性能監(jiān)測。技術(shù)人員根據(jù)聯(lián)通業(yè)務(wù)性能需求，設(shè)計自動化性能監(jiān)測腳本，然后部署到云平臺上并啟動監(jiān)測程序，定期向業(yè)務(wù)系統(tǒng)發(fā)出多個請求；根據(jù)系統(tǒng)反饋回來的響應(yīng)時間、失敗事務(wù)數(shù)等指標、平臺分析性能狀態(tài)，并根據(jù)分析結(jié)果以可視化的方式呈現(xiàn)。②性能預警。平臺不斷獲取業(yè)務(wù)系統(tǒng)的性能數(shù)據(jù)，根據(jù)相關(guān)的性能預測模型，判斷業(yè)務(wù)系統(tǒng)在未來一段時間可能存在的性能風險；如存在風險，平臺將在監(jiān)控界面上閃爍并發(fā)聲報警，同時，向各個相關(guān)方發(fā)出Email報警消息，提醒相關(guān)方盡快采取措施解決問題。

在沈撫鐵升位并網(wǎng)項目中，性能在線監(jiān)測和預警平臺通過實時性能監(jiān)控與預測來預知性能趨勢，共發(fā)出32次預警通知，使開發(fā)方和遼寧聯(lián)通在性能瓶頸發(fā)生之前能夠有盡量多的時間進行調(diào)整、優(yōu)化，從而大幅降低了項目的運營風險。

6 展望

隨著聯(lián)通信息化建設(shè)的飛速發(fā)展，聯(lián)通的測試管理、過程組織、技術(shù)方法和工具平臺也在不斷演進?？v觀歷史，展望未來，可將聯(lián)通的測試能力歸納為3個階段。1)第1階段：開發(fā)商主導的測試。對于聯(lián)通而言，測試過程為灰盒，測試質(zhì)量較低，存在問題較多。2)第2階段：多方共同驅(qū)動的業(yè)務(wù)全生命周期測試。聯(lián)通、開發(fā)團隊和第三方測試團隊敏捷協(xié)作，能夠建立可復用的測試資產(chǎn)，能夠研發(fā)適用的測試工具提高效率和效果。這一階段測試過程為準白盒，測試質(zhì)量較高，存在問題較少。3)第3階段：自主的自動化的測試。隨著業(yè)務(wù)知識和測試經(jīng)驗不斷被提煉，可復用測試資產(chǎn)日趨豐富和完善，并且由自動化測試工具執(zhí)行的比例不斷加大，聯(lián)通不再過度依賴開發(fā)商或第三方測試機構(gòu)提供的測試服務(wù)。同時，面對聯(lián)通的大數(shù)據(jù)和云計算趨勢，將使用更多的自動化測試和自優(yōu)化技術(shù)，如超大并發(fā)性能測試工具、性能自適應(yīng)優(yōu)化平臺等。這一階段測試過程為白盒，測試質(zhì)量和效率極高，測試成本極低，存在問題極少。

遼寧聯(lián)通目前處于第2階段水平。未來，將朝著第3階段的目標持續(xù)演進。

參考文獻

[1]Fei Kang,Janice A.Hauge,Ting-Jie Lu.Competition and mobile network investment in China's telecommunications industry[J].Telecommunications Policy.2012,36(11):901-913

[2]Yongwoon Shim,Dong-Hee Shin.Analyzing the development of 4th generation mobile network in China:actor network theory perspective[J].Info.2015,17(1):22-38

[3]Norman Wilde,SikhaBagui,John Coffey,et al.Interoperable Systems and Software Evolution:Issues and Approaches[J].Digital Enterprise Design and Management.Springer Berlin Heidelberg,2013,205:45-56

[4]Thomas Stephen W,Adams Bram,Hassan Ahmed E,et al.Studying software evolution using topic models[J].Science of Computer Programming.Part B,2014,80:457-479

[5]PhilippeKruchten.The rational unified process:an introduction[M].Boston,MA,USA:Addison-Wesley Longman Publishing Co.,Inc.,2003

[6]Daniel Stahla,Jan Boschb. Modeling continuous integration practice differences in industry software development [J].Journal of Systems and Software.2014,87:48-59

[7]Ken Schwaber.Agile Project Management with Scrum[M].Microsoft Press,2004

[8]GuoShaojie,Tong Weiqin,Zhang Juan,et al.An application of ontology to test case reuse[C]//Mechatronic Science, Electric Engineering and Computer (MEC),2011 International Conference on,2011:775 - 778

[9]Soh Z,Sharafi Z,Van Den Plas B,et al.Professional status and expertise for UML class diagram comprehension:An empirical study[C]//Program Comprehension(ICPC),2012 IEEE 20th International Conference on,2012:163-172