【星雲精準測試】

第一章 精準測試誕生的背景

20年前（2000年），上網是一件很酷的事，叫做“網上衝浪”，主要是幾個入口網站佔據絕大多數注意力；20年後（2020年），我們已經全方位“浸泡”在軟體的海洋裡，很多大型軟體系統已經超過億行，架構模型越來越複雜。未來的20年（2020-2040年），隨著各種智慧應用的層出不窮，軟體系統內部邏輯會不可逆轉的越來越複雜，而外部操作會越來越“傻瓜”。使用者一個眼神或者一動腦，就能夠切換出不同的功能需求。同時中國的軟體產品化程式，近些年來正在蓬勃的進行，大量的公司開始研發自己的產品。伴隨著關鍵核心軟體的國產替代，使得原本應用級難度的開發正在向高複雜度和高質量的產品型研發轉型。這個轉型的過程，註定將產生對於高階測試工具的巨大需求。

軟體缺陷發現得越晚，其處理費用即呈幾何性激增，而不是線性增長。如何從龐大複雜的系統中迅速及時地找到故障所在，一直是行業的一大難點。無法對大型軟體進行有效的質量把控，就無法真正構建與維護大型軟體。目前國內軟體測試基本處於兩種狀態：一是絕大多數企業採用功能（黑盒）測試，二是小部分對軟體產品有高可靠性要求的軟體，企業會使用程式碼級的白盒測試工具。但這兩種傳統測試辦法在目前的軟體日趨智慧化複雜化下，弊端越來越明顯。

功能（黑盒）測試技術**，使墨菲定律在所難免。**由於無法獲知程式內部邏輯結構，這種測試辦法對軟體可靠性要求不高的應用來講問題不是很大，但是對於大型金融機構、智慧工業、航天軍工等關鍵系統，就意味著時刻攜帶隱形的巨大風險。為此，功能測試後期需要極高的人力投入才能完成複雜邏輯的用例分析和設計。然而對於黑盒測試來說，程式越大，殺蟲劑效應越明顯。而行業內當作銀彈的自動化測試，當自動化程式本身規模擴大以後，它的維護本身就存在了很嚴重的問題。低效的黑盒測試狀態，最終將影響和制約未來整體軟體發展。

程式碼級（白盒）測試工具一般重點應用在研發階段的單元測試上，滿足了客戶的部分高可靠性需求，但由於其價格高昂、技術老化，僅適合於小規模迭代瀑布式開發的軟體，無法完成複雜的系統級別的測試以及分散式基於雲的測試，更不適應敏捷迭代的開發模式。另外白盒測試工具基本都是國外產品，通常這些產品無法完成深度的定製化功能實現以及快速的使用者響應，程式碼安全更是一個較大的問題。

所有先進的科技都是具備前瞻性眼光的。隨著國內軍民各項大型核心軟體系統的上馬，研發一種面向高複雜度大型軟體、自主可控的高效能智慧精準測試平臺的必要性，逐漸凸顯。在這個時代背景下，2012年初，星雲測試團隊開始了篳路藍縷、心無旁騖的研發征程。精準測試是個交叉學科，裡面涉及到編譯器、測試分析、圖形技術、高效能通訊與儲存，軟體的研發等多項底層技術。

經歷無數個不眠之夜對技術難點突破的煎熬與最佳解決方案的反覆推敲，星雲精準測試產品在諸多方面率先實現了重大技術創新，成功突破了白盒測試使用難度大、價格高昂的桎梏，有效消弭了國外高階測試產品壟斷的壁壘。星雲精準測試產品更偏向於軟體測試業界的“灰盒測試”，即用簡單的黑盒操作辦法，可以同時得到單元級和系統級的精準測試資料。

“星雲精準測試”不負眾望，在眾多效能上大幅超越國外進口高階白盒測試工具產品，並在資料追溯、覆蓋率視覺化、智慧迴歸、智慧缺陷定位、分散式資料穿透與追蹤等特性上有突出貢獻。星雲精準測試，既繼承了傳統功能測試前期的高效率執行區間，又能在後期透過系統的資料，讓開發、測試充分協同，完成全程高效的測試與資料分析。

（1）將測試團隊的價值放大，能夠將開發與測試更加緊密的連線起來，互為支撐。

（2）採用精準、可信的測試技術，測試管理的難度大幅度降低。

（3）降低企業對人員的過度依賴，透過系統適應人員的變更。

（4）為企業實現測試資料資產的有效積累和分析，打下堅實基礎。

“星雲精準測試VIP大企業離線版雲平臺”在整體測試功能上的優異特性，成功獲得了一批重要大型企業的高度認可及產品採購。

星雲測試的首發版本為：穿線測試 ThreadingTest，2014年6月6日上線，側重於系統級白盒測試技術，測試用例和程式碼邏輯的雙向追溯技術，測試示波器技術，覆蓋率視覺化技術。

2015年8月6日，“穿線測試”正式更名為“星雲測試”。在繼承穿線測試整體技術上，星雲精準測試增強了迴歸測試用例的自動選取技術，缺陷最後執行時序分析、智慧缺陷定位、敏捷環境下多版本白盒測試資料的聚合、聚類分析、結合程式碼結構與動態資料的測試漏洞檢出、程式碼安全特性，全面的測試管理特性等幾十種優秀功能。

目前有“星雲精準測試VIP大企業離線版雲平臺”、“星雲精準測試PASS線上雲平臺 ”、“全自動測試用例驅動生成系統Wings”等多種工具產品。

星雲精準測試旗下產品平臺有Horn、Paw、Shell、Wings等系列產品。適用語言和平臺暫為：

為響應廣大使用者的需求，目前正在進一步擴充套件適應的語言和平臺覆蓋面。

圖1-1 精準測試在大型系統的效率執行分析

星雲精準測試，既保證了傳統功能測試前期的高效率執行區間，又能在後期透過系統的資料，讓開發、測試充分協同，完成全程高效的自動化精準測試。

第一章 精準測試技術體系對軟體測試技術的升級解析

精準測試技術體系經過近6年的商業專案實踐日臻成熟，大量商業應用案例的正面積極反饋，表明它已經成為新的軟體測試技術方向體系。星雲精準測試靈巧詳細的功能設計和高度可靠的產品核心得到了市場的廣泛認可，對於國際上原有的白盒測試工具來講，是一種質的飛躍。

2012年，精準測試的商用工具正式進入設計和研發階段。與引進國外技術不一樣，精準測試的核心技術體系是星雲測試團隊在國內的原創設計和研發。產品經過3年的悉心研發、反覆內測、不斷最佳化後，2014年精準測試在CSTQB會議上，釋出了第一個商用版本ThreadingTest，引起了很大反響。6年前，行業上還全面沉浸在黑盒測試的大氛圍中，從未見過精準測試的超前的執行方法和提供的強大智慧的功能，由於理念與設計過於超前，早期有一些業內質疑的聲音。但由於產品獨到的優秀特點和巨大的潛在價值，諸多伯樂開始試用，給了產品在實際場景中不斷最佳化、強化的寶貴機會。經過不同領域、不同客戶的各種高複雜度大型系統的百般錘鍊、驗證後，自2016年開始，精準測試開始贏得全行業的重視和響應。

優秀的商用落地性是精準測試技術流行的一個重要因素。由於精準測試把準了黑盒測試無法解決的難題和固有瓶頸，踏準了測試技術發展大的程式，並從設計一開始就特意注重了商業場景下使用要求複雜性，因此它從誕生之日起就不僅僅是一套理論，而是有著非常強的實用性基因和可擴充套件架構，多場景應用成果卓然。

精準測試最底層的核心技術：“一種基於用例與原始碼雙向追溯的測試裝置及方法”，類似在重建量子糾纏的場景和資料。它成功的將功能用例和對應的程式碼二者之間的追溯路線，實現了精準無誤的視覺化。這徹底解決了在黑盒的狀態下，軟體工程師們無法獲知程式內部執行軌跡的難題。自此開始，計算機處理海量測試資料的強大分析能力開始展現。

我們知道，所有的黑盒測試都是人工進行的，它依賴的是人的算力，而軟體正確性驗證的工作量，主要是組合路徑膨脹的問題，人的算力是遠遠跟不上的。那麼精準測試如何從測試的角度對業務進行深度的測試輔助分析呢？我們用量子糾纏的形象類比來說明這個問題。量子糾纏理論我們可以簡單理解為兩個處在糾纏態的粒子一旦分開，不論分開多遠，如果對其中一個粒子作用，另一個粒子會立即發生變化，且是瞬時變化。“一個粒子”會與“另一個粒子”產生相互作用，兩個表面互相不關聯的粒子，互相作用互相影響，他們對外是一個整體，無法單獨描述“單個粒子”的性質，只能描述這“兩個粒子”的整體性質，這就叫做“量子糾纏”。類比到軟體測試上，我們的被測試軟體中常見的軟體介面和功能輸入輸出以及渲染它的複雜程式碼，他們之間就和兩個糾纏在一起的粒子一樣，具備強關聯性。一個發生了變化，另一個必定發生變化。

精準測試的另一核心功能是：“迴歸測試用例的自動選取”，就是基於用例和程式碼的追溯（量子糾纏）關係在進行運算之後全自動得出的。用例和程式碼精準的追溯機制，使資料開始可以實施大量的智慧測試演算法。在軟體測試理論界，大量論文演算法的基礎都是預設建立在用例和程式碼的關係上進行分析的，但因其追溯機制工業實現難度極大，所以一直停留在學術理論階段。星雲測試引領的精準測試方法體系，落地在精確便捷的商用產品和大型解決方案中，讓大量先進的測試分析方法和理論，得以實實在在的驗證。

精準測試首次明確的提出了：如何採集和應用雙向追溯資料，進行測試輔助分析系統的構建。不管是純軟體系統還是執行在裝置中的軟體系統，用例與程式碼精準的資料可追溯性，都是基礎性的強需求。比如金融轉賬業務、用手機拍照、機器人控制器的動作控制指令等，每個操作都有與之對應的程式碼。星雲精準測試產品的強大之處在於：所有的分析演算法不需要和被測系統的業務功能做特定的適配，因此可以應用於任意軟體系統的測試輔助分析。而傳統的白盒在產品實現上以採集和分析總體覆蓋率為主，沒有能力將覆蓋細化到用例層級，因此傳統的白盒測試囿於覆蓋率的概念中，無法實現更高層次的測試輔助分析需求。

星雲測試產品的技術優越性及應用的易用性，使它成為新一代軟體測試技術流的中堅力量。星雲精準測試在企業應用場景中，為了方便客戶還設計了完全靜默的“傻瓜”執行模式，客戶基本無需增加額外的學習成本。比如測試工程師開啟測試用例的excel表格，當他準備執行某個用例的時候，只需點選這一項測試用例。隨後透過VBA技術，直接呼叫星雲精準測試的後臺介面，再附加一整套深入應用後臺執行執行緒的使用者標籤技術，就可以將用例和程式碼關聯和分離出來（這裡說的分離是指類似於J2EE服務端後臺應用）。在對外提供多使用者併發訪問的情況下，可分離出每個使用者執行的用例所對應的相應程式碼。

前面我們提到功能和程式碼這兩個量子資料的重建，以前主要出現在研發/開發人員相對比較零散的執行單步除錯功能的時候（即單元測試），無法儲存。國外白盒工具因其設計基因的限制，無法支撐超大型、高複雜度的系統級測試需求。在星雲精準測試體系中，只要測試工程師執行測試用例，幾乎不需要額外付出，在建立測試用例與資料的對應關係的同時，瞬間即可將海量資料實時採集並儲存起來，用於後續測試大資料的分析和運算上。它的核心設計，使之可以輕鬆應用在數億行的超大型應用上，實時採集、儲存測試資料，而對原有系統的響應效能不產生干擾。

星雲精準測試對軟體測試體系是重大的技術革新，它從以下幾個層面改變並提升了測試：

1. 對軟體測試的深度進行了大幅度的拓寬，讓計算機有能力直接對測試用例進行輔助分析，給出更深入的測試決策分析依據。傳統測試主要透過人工業務測試發現缺陷，定位缺陷必須由開發人員進行，二者資訊沒有精確的資料互動。精準測試主要基於測試人員標識的用例狀態，以及自動記錄的用例對應的程式碼路徑進行頻譜分析。它可以自動計算缺陷產生的程式碼位置，在發現缺陷的同時，同步產生缺陷定位的結果資料。精準測試提供的測試用例的聚類分析，是基於測試用例的路徑空間距離進行聚類，聚類的結果可以直接對用例執行正確性進行稽核，對用例進行等價類劃分、分析缺陷密集區以及對用例執行分佈進行評估等。精準測試提供的迴歸用例選取結果，經由海量的計算精準推薦而來，總體演算法思路與人工分析的思路是類似的，採用人工智慧演算法模式把大量的計算完全交由計算機去總結分析，精準、穩定、可靠、高速。這個功能相當於解放了測試和開發團隊大量的人力資源，徹底解決因團隊成員變更而引入的未知風險。

2. 精準測試開闢的測試方法新體系，支撐了黑盒測試快速提升測試效能比的剛需。精準測試對於企業來講，相對於比需要人工編寫、維護龐大自動化指令碼的自動化測試，工作量是低很多的。精準測試和自動化測試是並行的技術方向，企業應用可以根據各自團隊的特點來選擇，並沒有絕對的應用時序依賴關係。自動化測試近些年的應用遇到一個廣泛的批評就是：讓測試團隊疲於應付用例的編寫而不是測試用例設計等測試核心技術。精準測試屬於測試分析系統，著眼點和立意相對較高，在測試理論、方法和商業應用落地驗證與成果上，形成較好的整體閉環。它把測試需要關注的核心，引領到一個正確方向上來。

3. 精準測試在技術特性上解決了測試結果可信性的問題。在精準測試之前，我們所見到的所有測試資料都是易偽造、易篡改的。例如我們通常使用的測試管理系統，一個用例是否被有效執行，絕大部分是在測試管理系統中被人工錄入的。精準測試是在用例動態執行過程中，由計算機內部演算法真實記錄對應的程式執行邏輯，然後形成後面對測試資料進行精確分析的資料來源基礎。所以其底層程式執行的資料是沒有辦法也絕對不允許進行偽造和篡改的。精準測試果斷去除了阻礙測試行業發展的重要障礙，讓測試的結果精準化、可量化、可衡量化、可信化。此舉，將大幅減低測試行業本身的管理成本，有效推動測試行業的快速、健康發展。

4. 精準測試大幅提升了開發和測試部門的協作效能。前面提到全景偵錯程式，測試工程師執行完用例，即時產生程式碼層級的全景除錯資料；測試完成後一旦用例存在缺陷，那麼基於這個全景除錯圖以及高度視覺化的資料路徑追溯，開發人員可以直接對缺陷進行定位，不需要在開發環境下重現缺陷，再單步除錯以解決問題。實施精準測試之前，開發人員苦於很難有效參與對測試用例進行稽核；實施精準測試後，用例的執行結果都對映到了程式碼層，開發人員透過程式碼的覆蓋檢視很容易就可以協助測試人員補充和確認用例，開發和測試的協作變得非常簡單和直接有效。

不可否認，在精準測試之前，開發和測試存在溝通不暢的問題。透過精準測試在專案中的有效實施我們會發現，精準測試可以幫助開發提供非常有價值的資料：例如程式碼和用例的反向追溯可以幫助開發人員修改程式碼做參考，精準測試自動計算迴歸範圍減輕了開發人員必須協助測試進行分析的工作量，因此，精準測試對開發和測試來講，是一舉兩得、相得益彰的。

1. 星雲精準測試發明了多個全新的、適應敏捷迭代開發模型下的覆蓋率計算方法。覆蓋率是白盒測試最基本的技術，但是隨著敏捷迭代的開發模式，即使最高階的白盒測試工具已經幾乎沒有用武之地，原因就在於由於迭代很快，在某個版本上通常只能採集少量的覆蓋率後新版本就釋出了。本應在一個版本上分析的覆蓋資料，分佈到了數個程式碼結構不一樣的程式版本上，因此原有的統計方法和參考意義基本上都失效了。精準測試提供了累計覆蓋率，能夠將多個版本的覆蓋率以最新版本的程式碼結構進行投影，在控制流上進行累加。這樣測試團隊無需關注每個版本的覆蓋情況，即可關注一個完整測試周期內所有版本的累積覆蓋率。另外，考慮到敏捷迭代每個版本的測試需求，即：針對特定模組和功能範圍進行測試（並不是全量測試），精準測試提供了相關覆蓋率的計算方法。它可以自動圈定某個用例和用例集有關的程式碼範圍（這些也是基於用例和程式碼的關係分析基礎上動態計算的），在執行少量用例或者某個功能模組的情況下，它可以自動確定相關程式碼，把不相關的程式碼從覆蓋率的分母中過濾掉。這樣相關覆蓋率在僅僅執行部分少量用例的情況下，依然具有很強的統計和參照意義。

第三章 精準測試的定義

精準測試定義：由中國團隊發起並原創完成測試理念設計和商用產品研發的全新測試技術。旨在測試用例執行過程中，全自動建立任意執行模式的軟體系統的功能點與原始碼之間高度的視覺化追溯機制，獲取功能點相關的程式碼覆蓋率並進行精準迴歸等測試用例深度輔助分析演算法的應用。精準測試是測試理論界首次同時使用測試用例及其相關程式碼兩個關鍵因子，進行質量綜合考量和分析的創新測試方法體系。

3.1 基本定義

星雲精準測試在測試用例執行過程中，可以同步全自動建立任意執行模式的軟體系統功能點與原始碼之間的高度視覺化追溯機制，即透過內部演算法能夠將缺陷對應的程式碼出錯位置直接定位出來；能夠獲取功能點相關的程式碼覆蓋率並進行精準迴歸等，使測試用例深度輔助分析演算法得以強化應用。這是軟體測試首次同時使用測試用例及其相關程式碼兩個關鍵因子，進行質量綜合考量和分析的創新測試理論方法體系。這種有效的資料追溯與“量子聯動”的突破性技術特性，大大增強了測試的深度與廣度，打破了測試部門的成長天花板，為測試過程本身的價值挖掘和測試資料資產的增值，提供了必要而充分的條件。

3.2 關鍵技術

精準測試體系貫穿整個軟體測試生命週期。精準測試主要側重於系統級測試，在單元測試、整合測試、系統測試、驗收測試、迴歸測試中，均能賦予測試資料強大的追溯能力。關鍵核心技術有：測試用例和程式碼邏輯的雙向追溯，測試示波器、覆蓋率視覺化、迴歸測試用例的自動選取、缺陷最後執行時序分析、智慧缺陷定位、敏捷環境下多版本白盒測試資料的聚合、聚類分析、結合程式碼結構與動態資料的測試漏洞檢出等。

精準測試在測試用例執行過程中，為使用者從底層自動建立任意執行模式的軟體系統功能點與原始碼之間的視覺化追溯機制，使使用者獲取用例級的程式碼覆蓋率等多種高階測試資料。這一突破性的創新智慧演算法，有力的打破了軟體開發、測試、維護及管理人員等之間的資料孤島狀態，實現了軟體測試過程和結果的高度精準視覺化，在軟體高可靠性和高可信度方面，提供了全面而有力的資料支撐。精準測試執行模式是灰盒模式，即：可以在黑盒功能測試的時候，同步完成資料採集和分析計算，讓“點測”團隊也可輕易切入到精準測試模式，無需改變現有測試形式與流程，不增加額外的技術學習與轉換成本。

3.3 應用範圍

精準測試適用於任何形態的軟體系統。星雲精準測試可應用於各種軟體包括嵌入式系統、分散式系統、web應用系統、單機軟體系統等各類軟體的測試，並且完全不受限於被測試軟體本身的業務需求。

3.4 使用者收益

1. 實現從發現缺陷到預防缺陷的轉型。減少因為缺陷而對整個研發運維流程造成的返工成本。使發現缺陷前移，減少因專案後期的嚴重缺陷而導致產品交付延期、成本增高，影響交付質量。

2. 建立跨需求、開發、測試等部門的測試協同平臺。實現業務資料可追溯化和路徑視覺化。

3. 最佳化技術與業務方案。根據不同的質量要求，優先順序順序、技術實現手段等，實現智慧靈活的技術方案推薦、交付和應變機制。減少無資料支撐造成的內耗。

4. 企業“精準眾測”平臺，支撐千人團隊同時線上。測試資料可以根據管理需要做分析，為企業內的成本管控提供選型參考。實現跨地區，跨部門的業務人員，開發人員和測試人員的測試協同，即使不在同一辦公地點的人員，也可針對測試需求，測試任務，測試用例和測試缺陷等方面進行遠端溝通和實時協同作用，最終完成整個測試過程的實施。

5. 支援敏捷開發與測試模式。關注新功能的增量測試，支援自動化迴歸測試，實現高效的IT交付。

第四章 精準測試的基礎架構介紹

4.1 精準測試的技術架構

精準測試從某些層面來講，賦予了測試用例真正的生命力。測試用例是測試資料的一種，當測試資料實現路線可追溯視覺化的時候，一些高階演算法的強大能力就可以顯示出來。我們從精準測試的整體架構圖中可以做一具體分析。

圖4.1-1 精準測試的總體架構圖

第一層：利用先進的前置編譯器，為客戶做原始碼靜態結構分析（在客戶的實際環境中，根據客戶的需求進行相關的技術配合）；

第二層：將處理好的系統程式放入測試環境執行，測試工程師透過人工或程式自動化的形式，開始執行用例（人工執行用例可以和測試管理平臺或者Excel表格方式進行對接)，精準測試的 “軟體示波器”採集執行資料並進行高速智慧運算，獲取精確的測試資料；

第三層：根據採集的程式碼與對應的測試用例，在星雲精準測試平臺中實現用例與原始碼的互相追溯；

第四層：透過精準測試的分析平臺，可以對測試資料進行缺陷定位、用例聚類分析、迴歸測試用例和最小測試用例集等功能的計算，使用者還可以根據需求，批次生成相應的測試報告，或進行測試資料高階分析。

圖4.1-2 精準測試的用例魔方

在總體業務架構圖的左上角區域，我們可以看到“用例魔方”幾個字。大家可能會比較好奇“用例魔方”的涵義，它是精準測試中非常核心的高階迴歸功能之一。所謂“魔”是精準測試核心演算法所賦予的超能力，所謂“方”實際上是代表測試用例的集合，每個測試用例用一個小方塊標識，所有測試用例的集合用一個大方塊。當我們把精準測試的和用例分析相關的功能畫成架構圖形表示的時候，它自然而然地看起來就像魔方。

精準測試體系中，測試用例對應的程式碼邏輯精確而完整的實現了全自動化的追溯和儲存，因此賦予了測試用例深入分析的基礎能力。在精準測試的用例魔方中，目前存在三個面（隨著後續功能的增加，將增加分析的面）：即迴歸測試用例選取、測試用例聚類分析、測試用例最小化，同時輔之以智慧缺陷定位技術。當測試用例與程式碼的追溯關係建立的時候，測試魔方的核心功能區即同步構建出來。為資料的多角度分析，提供了豐富的資源素材庫。

4.2 軟體示波器

軟體示波器是星雲精準測試獨有的功能，它如同軟體的質量執行情況“追溯穿行器”一樣，在測試工程師按下啟動鍵的同時，即時開始建立用例與程式碼的自動關聯。示波器把採集到的測試資料透過視覺化的視窗介面進行實時展示，內容涵蓋採集到的塊、條件和函式資訊。藍色波形代表寫入的數值，黃色波形表示讀取的數值，使用者可以清晰的看到被測系統的資料變化。它如同心跳監控儀一樣，如果被測試程式發生了崩潰，軟體示波器就像人的心臟停止跳動一樣，一根橫線拉直向使用者報警。如果正常採集到資料，會有持續的波形展示出來，高效而精準地監控程式細微的執行狀況。示波器精密捕獲每個軟體單元任何微小的執行波動和行為改變，支援多次執行資料的比對。它可以根據需要記錄崩潰前的至少50個塊，使“崩潰重現”變得輕鬆簡單。

軟體示波器中的測試用例可以從現有的測試管理系統匯入進來，先選中用例點選開始，驅動被測試系統執行後，軟體示波器就會採集到程式內部執行邏輯對應的波形資訊。用例執行結束後，點選停止。這個用例執行階段的資料，透過開始和結束的點選，邊界就記錄下來了。

圖4.2-1 軟體示波器

皮膚的正下方可以展示函式的各種呼叫資訊。包括類、函式，引數型別等。清晰的列示出引數列表、類執行情況、記憶體檢測資料、資料庫攔截等多角度的資料分析追溯情況資訊。

示波器觀測的維度較多，用例與程式碼的追溯是精準測試的基礎功能，後面的高階演算法都在這個基礎上展開。用例和程式碼的追溯就像一個全景的偵錯程式，只要功能由測試人員執行，所有的內部程式碼執行邏輯瞬間就可以展示出來。透過測試資料的反向追溯分析，開發人員可進行一致性修改，避免修改引入新的缺陷，透過正向追溯結果，開發可對用例的執行進行全面掌握，可用於快速修復缺陷和詳細實現確認。

同時軟體示波器也提供一個輔助的等價類劃分的功能，它將一個用例從開始到結束所執行的路徑資訊終值，完整記錄下來。如果兩個用例終值不一樣，就可以確定為不是等價類。對於很多從功能表面很難界定是否等價類的測試用例，軟體示波器可以給出精確結果。

因此軟體示波器的價值與意義在於：

（1）只要測試開始執行，即可以透明方式高速採集功能執行過程中對應程式的執行邏輯。

（2）在系統高速運轉下采集，可保證對原有應用無干擾，超過1500w/s的採集速率。

（3）可採集程式的條件，執行路徑，執行引數，記憶體使用等動態執行資料。

為了方便客戶在執行專案測試時，一邊對被測系統做實時資料監測，一邊同步觀察到示波器裡面資料寫入和讀取的波形，星雲做出了實時資料監測的懸浮窗縮圖，減少了切換帶來的工作量。它不影響原有被測系統的介面，以半透明懸浮的方式展示在被測試應用介面的前面。

圖4.2-2 軟體示波器懸浮窗

4.3精準測試的雙向追溯

精準測試的測試用例和程式碼的雙向追溯功能，是精準測試核心技術之一。如同前文的“量子糾纏”，即執行測試用例的同時，精準測試可以透過程式自動的記錄並追溯到這個測試用例相應執行的程式碼。如果測試人員關注某一些程式碼行，它可以追溯出哪些測試用例在執行過程中執行過這段程式碼。透過這個技術特性，測試工程師的每個測試用例都可以進行量化分析和統計，提供了開發人員和測試人員之間精準的數字化交流依據， 增加測試和開發的交流效率。

雙向追溯技術記錄了每個測試用例對應的程式內部的執行細節，細緻到每個條件、分支、語句塊的執行情況。開發人員亦可透過雙向追溯的結果去理解程式邏輯，進行軟體維護以及進行可一致性的修改。

4.3.1 雙向追溯技術正向追溯

1. 將測試用例和程式碼執行資訊自動關聯，可追溯到函式級別及程式碼塊級別；

2. 透過正向追溯可直接把BUG定位到故障和缺陷邏輯相應的程式碼，並提供最後執行的時序資料；

3. 透過正向追溯自動記錄產生功能對應的詳細設計實現，輔助軟體解耦和架構分析。

圖4.3.1-1 雙向追溯(正向)-測試用例追溯到程式碼

圖4.3.1-2 雙向追溯(正向)-測試用例追溯到程式碼

4.3.2 雙向追溯技術反向追溯

1. 將程式碼執行、函式、程式碼塊級別和測試用例執行資訊自動關聯；

2. 透過反向追溯可直接觀察程式碼變動所影響的測試範圍；

3. 協助開發，進行程式碼修改後影響功能的範圍評估；

4. 協助測試人員對程式碼修改部分所影響的測試用例進行評估。

圖4.3.2-1 雙向追溯(反向)-程式碼追溯到測試用例

圖4.3.2-2 雙向追溯(反向)-程式碼追溯到測試用例

4.3.3 資料追溯技術-追溯測試用例的全景呼叫

精準測試透過正向追溯把測試用例執行的程式碼執行進行了全景繪製，在全景圖中，測試人員可以有效的觀察到函式之間的整體的呼叫與走向，觀察出被測模組與上層之間的呼叫關係。

圖4.3.3 測試用例執行的程式碼整體呼叫

第五章 精準測試的核心元件與功能

精準測試的核心元件與功能：軟體測試示波器、用例和程式碼的雙向追溯、智慧迴歸測試用例選取、覆蓋率分析、缺陷定位、測試用例聚類分析、測試用例自動生成系統等，完整的構成了精準測試技術體系。

精準測試系統本質是一套強大的計算機開發與測試系統，實現了資料的視覺化聯動，以及開發輔助分析。它的關鍵技術賦予了測試用例和程式碼強大的相互追溯能力，隨後衍生實現了很多高階測試功能與演算法。精準測試系統將用例深入到程式碼層分析後，可以大幅改進人工測試所產生的各種問題。

接下來將從風險控制、工作協同、敏捷迭代方面詳細解析精準測試的核心功能和實際收益。

5.1 風險控制

5.1.1 七種測試覆蓋率

星雲精準測試提供7種測試覆蓋率：分別為：SC0語句塊覆蓋率、True覆蓋率、Both覆蓋率、CDC覆蓋率、Branch覆蓋率、MC/DC覆蓋率。

使用者首先選擇分析覆蓋率的維度，例如選擇了“SCO語句塊”維度，那麼系統就會將被測試程式的所有語句塊結構展示出來，並且用顏色表達覆蓋情況，綠色代表覆蓋，深藍色代表未覆蓋。同時告知覆蓋率的分子和分母都是哪些，非常清晰的展示覆蓋率視覺化結果。精準測試在前期已經對程式的靜態結構進行了深度的分析，因此使用者在覆蓋率視覺化介面，根據選擇的維度在程式碼層面上把需要展示的結構單元都結構化的展示出來。例如圖5.1.1-1 七種測試覆蓋率中的第二張圖

圖5.1.1-1 七種測試覆蓋率

MC/DC覆蓋率視覺化

MC/DC覆蓋率，即修正判定條件覆蓋，該覆蓋率資料 MC/DC是DO-178B/C Level A認證標準中規定的、歐美民用航空器強制要求遵守的覆蓋率標準。MC/DC覆蓋率可以基本保證被測試軟體無缺陷，對於大型系統的可靠性要求很高的一些關鍵模組，建議採用這個覆蓋率標準。MC/DC覆蓋簡單來說，就是追蹤複合條件中每個子條件的真假翻轉，在其子條件不變前提下，是否都獨立的影響了整個條件的真假值。星雲精準測試系統會自動的把各種組合都列好，透過顏色表達哪些子條件已經滿足，以及對應滿足情況時其他獨立子條件的組織情況。

圖5.1.1-2 MC/DC覆蓋率視覺化

條件組合視覺化展示

精準測試對於多條件組合的程式碼，採用了最新研發的條件組合視覺化檢視進行展示。檢視中，使用者可以觀察到每個條件的真假執行情況，以及條件與條件的組合執行情況。對於測試人員來說，當全部條件組合之間的T與F都完全滿足時，即可實現程式碼全路徑覆蓋。

圖5.1.1-3條件組合視覺化展示

5.1.2 新增程式碼覆蓋率

敏捷模式下，因迭代頻繁其存量的程式碼量很大，通常更關注增量覆蓋度量。精準測試可以在程式新版本釋出後，自動計算新增（變更）程式碼的範圍，給出新增程式碼的覆蓋率。覆蓋率的分母中的函式都是變更和新增的函式。與此同時，基於反向追溯的功能，我們還可以給出新增程式碼對應的測試用例名稱。當某個新增函式沒有達到很高覆蓋率的時候，我們透過反向追溯的用例，可以判定因為哪些功能範圍的用例設計不充分，導致了新增程式碼覆蓋率不高。

圖5.1.2 新增程式碼覆蓋率

5.1.3 測試覆蓋率範圍篩選與再統計

在做精準測試或統計覆蓋率時，往往測試管理者、開發人員、測試人員為了保證測試覆蓋率的正確性，會對某個方法、類進行檢視或在統計中把程式碼中一些廢棄的函式、某些特殊情況下無法測試到的程式碼進行移除（至少是做相應備註），從而讓測試程式碼覆蓋統計率達到更加準確。星雲精準測試在設計中，透過多種搜尋、方法、類、模組過濾等功能，把需要統計的範圍進行縮小、不需要統計的去除。根據使用者的選擇，進行覆蓋率再統計展示。

圖5.1.3 測試覆蓋率範圍篩選與再統計

5.2 工作協同

5.2.1 打通開發與測試的隔閡

精準測試打通開發與測試的協同工作通道，使得開發與測試能夠更好的溝通，提高工作效率。傳統模式下，開發人員關注的是程式碼，測試人員關注的是業務角度的測試用例，彼此的直接關聯相對較弱。開發和測試的溝通，基本就是採用自然語言、Excel表格、內部系統等，存在交流資訊不夠嚴謹的問題。例如測試工程師發現一個缺陷，提交到缺陷系統，開發需要花費大量時間再行理解、準備資料、復現、除錯，直到最後的修正。因為業務上的功能執行和程式碼並沒有明確的關係，通常測試工程師執行完功能測試用例後，讓開發人員幫助評審也非常困難。

若測試工程師提供的測試結果都是比較模糊的功能邏輯描述，重現缺陷需要花費大量的時間。開發人員修改程式碼後，對於變更描述，以及變更引起的關聯問題描述通常也都很模糊，導致測試又出現新問題。

企業採用精準測試技術後，透過執行用例可以直接追溯到對應執行的程式程式碼塊，這樣的資料化溝通，將使開發人員和測試人員之間的協同工作效率大大提高。

圖5.2.1  協同模式

5.2.2 原始碼動靜態資料的統一

星雲精準測試透過插裝得到的專案靜態結構資訊，結合測試後採集到的測試資料，能夠精準記錄測試的過程，透過這些靜態資料和動態資料檢視，便於開發人員基於圖形化結果進行快速分析。

對於不懂開發的測試工程師，透過程式控制流程圖的圖形以及透過顏色表示的覆蓋資訊，可以直接看到程式內部漏測的邏輯是什麼，也可以透過這些結果直接與開發溝通，進行輔助用例和邏輯的補充。

因為內部邏輯的強追溯性並且能夠圖形化的開啟，可以有力保證黑盒測試後期開發快速理解並解決瓶頸問題，保持全程測試的高效執行。

圖5.2.2-1 原始碼靜態結構與動態測試資料統一圖（函式呼叫圖）

圖5.2.2-2 原始碼靜態結構與動態測試資料統一圖（控制流程圖）

精準測試在程式靜態分析的基礎上，可以對程式繪製視覺化的圖形，同時將動態執行的覆蓋資訊染色到這些檢視上。對於不懂開發的測試人員也可以很清晰的看到程式的哪些結構節點沒有被覆蓋到。例如圖形中藍色的節點是未覆蓋的節點，綠色的是覆蓋的，因為控制流程圖本身有分支，巢狀等各種關係，測試工程師可以很容易判斷出覆蓋的範圍大致是哪些。而如果有開發人員介入，可以更清晰地分析測試工程師執行的用例所遺漏的程式邏輯。

圖 5.2.2-3原始碼靜態結構與動態測試資料統一檢視

5.2.3 缺陷最後執行時序分析

星雲測試可自動捕獲缺陷或崩潰發生時，程式最後執行的詳細路徑資訊。缺陷發生後，開發人員能夠直接看到缺陷出現時，程式碼執行的時序和路徑資訊，直接定位缺陷並排查問題，節省大量的溝通、復現和除錯的時間成本。

當功能執行發現缺陷後，在軟體示波器上可以立即按下“停止”鍵，那麼最後執行的程式碼序列就可以被抓取到，開發人員可快速定位缺陷最後執行的50個程式碼塊、條件、判斷的各種執行資訊。

在下面檢視中，我們可以根據標號（從1到50），看到程式碼最後的執行時序，在圖形裡面的每一個綠色小方塊為一個程式碼語句塊或者一個條件、判定，在一個大方框下的綠色方塊代表一個函式內部的程式碼塊。經過佈局演算法後產生下述圖形。

圖5.2.3 缺陷最後執行時序分析

5.2.4 智慧缺陷定位

通常測試工程師只是負責發現缺陷，缺陷的具體定位只能交由開發人員來執行。精準測試打破了測試部門的天花板，即透過內部演算法能夠將缺陷對應的程式碼出錯位置直接定位出來。這相當於增加了測試深度，同時體現了測試資料和測試過程本身的價值。

對於測試工程師來說，只要發現用例相似而程式在輸出上有對錯區分，就可以使用精準測試的智慧缺陷定位功能。精準測試平臺透過測試人員在功能測試階段標記的用例執行狀態，以及軟體示波器自動記錄的程式執行頻譜，自動分析缺陷的出現的程式碼塊。因精準測試平臺可以獲取每個用例執行時詳細的路徑追溯資訊，測試工程師只要告知系統用例的狀態，例如是否透過是否正確，那麼精準測試內部演算法就會去根據正確和失敗的路徑差異進行計算，給出缺陷出現具體位置的可疑度排名。

這個功能可以大大增強測試在整個開發流程的參與度和測試資料價值，也讓開發人員減少了自己去模擬場景的時間，快速提高開發和測試的協同和配合的效率。

1. 對於同類測試用例，經過多組測試可給出非常有效的結果。

2. 列出的可疑程式碼，可直接透過測試過程給出，提升測試的價值及產出。

圖5.2.4-1 透過功能測試頻譜法分析進行智慧缺陷定位

選擇可疑度演算法、得到可疑度高的程式碼塊，關聯原始碼後，可根據程式碼視覺化檢視具體位置。可疑度計算有一個公式，並不複雜，通常每個程式碼塊有2個變數，四種狀態值。分別是：是否執行、是否透過，這樣每程式碼塊都有一個可疑度值。

星雲精準測試提供3種常用計算公式，供大家參考。

aep表示透過且覆蓋到該塊的測試用例的個數、anp表示透過且未覆蓋到該塊的測試用例的個數、aef表示未透過且覆蓋到該塊的測試用例的個數、anf表示未透過且覆蓋到該塊的測試用例的個數。結果表示該塊的可疑度。

圖5.2.4-2 智慧缺陷定位展示

5.3 精準測試對敏捷迭代的支援

5.3.1 敏捷迭代下多版本白盒測試資料的聚合

在敏捷環境下由於版本迭代速度很快，每個不用的程式碼版本上通常只能採集到少量的覆蓋率。一旦釋出新版本，就意味著程式碼發生了變化，覆蓋率資料就需要重新採集，但是每個版本採集的少量覆蓋率，從分析層面上並沒有多大的意義。

針對以上問題，精準測試給出了“**累計覆蓋率”**的計算方法。它將一系列迭代版本的覆蓋率，在最新的程式版本上進行投影累加。使用者可將一個階段各個版本的覆蓋率累加起來進行分析。演算法的思路是以最新版本程式碼為基礎，以某個函式為單位，一直往前累加。直到這個函式在之前的某個版本程式碼發生了變化，就停止累加。例如下圖函式A的4個版本的覆蓋都可以累加，是因為這個函式在4個版本中都沒有發生變化。而紅色的函式B只累加了3個版本，是因為從版本v2.0-2後這個函式發生了程式碼變更。之前的程式碼覆蓋就不能累加了。

星雲精準測試-敏捷環境下多版本白盒測試資料的聚合如圖所示。

圖5.3.1-1敏捷環境下多版本白盒測試資料的聚合

這種累加是在確保函式程式碼沒有發生變化的情況下，在控制流上對相應節點的覆蓋率進行累加。例如下圖中3個版本，覆蓋率不同的分支和控制流，資料累加後可以看到所有分支都覆蓋到了。

圖5.3.1-2敏捷環境下多版本白盒測試資料的合併分析

5.3.2 聚類分析

星雲精準測試提供的聚類分析功能，根據測試用例的函式執行剖面的向量化資訊，對測試用例進行精確的空間距離計算後執行聚類分析。聚類結果可以分析被錯誤執行的用例，例如不相關的功能點聚類到一起，則說明其測試執行可能存在錯誤。

精準測試提供的聚類分析功能，也可以輔助找到缺陷分佈的密集區域。大部分情況下，缺陷分佈會呈現2/8的聚集特性。在時間緊張的情況下，我們可以透過聚類結果，每個類選取中心點以及周邊幾個用例。如果沒有問題，就可以去測試其他聚類，如果發現一個類缺陷機率高，那麼這個類就需要進行重點測試。透過聚類結果可以分析測試用例的分佈密度等資訊，輔助進行測試決策。

圖5.3.2-1 測試密度

下圖中測試用例分類都有一個名字，這個名字是聚類結果中每個類中心點的測試用例名字，它基本標定了這個類的功能點範圍。

聚類的大小代表了某個功能範圍測試是否足夠充分。例如一些應該重點測試的功能，聚類結果中的用例數應該很多；一些小眾的功能，聚類中用例數應該比較少。一個類中用例數越多，這個類圓圈比例越大，反之則越小。在聚類的基礎上，我們也可以對一個類中的等價類用例進行分析。是等價類的用例，會分成一組專門展示。

圖5.3.2-2 聚類分析

5.3.3 覆蓋率漏洞檢出

在敏捷迭代過程中，通常沒有充分的時間將所有函式的覆蓋率都達到一個很高的層級（Level）。精準測試結合程式碼結構和動態資料綜合分析，透過計算直接篩選出潛在的高危測試漏洞，可以在短期內確定高危漏測模組並針對性的解決，幫助使用者快速找到嚴重缺陷。

1. 當測試時間不充分的時候，執行完黑盒測試以後，先看測試漏洞列表，裡面顯示了透過靜態資訊和動態資訊計算，得到的最高風險的漏測點模組。

2. 我們可以透過複雜度進行計算，因為複雜度高的模組一般來講，它是相對重要的模組並且邏輯複雜，如果動態覆蓋比較低，我們會優先篩選出來進行排序。

3. 處於呼叫和被呼叫中間的模組，因為屬於中間關鍵模組，我們也會計算它的扇入扇出，和動態覆蓋率資訊。如果它的比率很高，將被認為是高風險模組，被篩選出來進行排序。迴歸時，應優先測試風險指數高的高危模組，補充他們的覆蓋率。

圖5.3.3漏洞檢測列表

5.3.4 最小測試用例集

精準測試也可以對用例集進行最佳化。比如使用者有大量用例的情況下，尤其是自動化用例集含有長期維護的冗餘用例。精準測試平臺可以對很多重複用例的邏輯進行篩選和過濾，最佳化出滿足當前總體覆蓋的最小用例集。

圖5.3.4星雲測試最小測試用例集

第六章 精準測試支援不同剖面的分析報告

在時間有限，經費有限，資源有限的情況下，我們既要考慮測試是否充分，也要顧及時間、人員、裝置配置等限制條件。精準測試可以支援企業不同剖面的軟體質量分析需求。

6.1 詳細的測試總結報告內容

1. 測試資源分析：多少人，多長時間、整體測試有效率及執行率

2. 測試結果分析：描述需求的測試結果，系統實現了哪些功能點，哪些還沒有實現

3. 缺陷情況分析：缺陷復現、缺陷處理、缺陷數量、屬性、狀態分佈，缺陷預防、缺陷收斂度

4. 度量指標分析：測試覆蓋率、測試執行率、測試執行透過率、測試缺陷解決率

5. 效率指標分析：進度偏離度、缺陷發現率、用例執行效率和質量等

6. 高風險識別與排序：註明當前專案中面臨的最嚴重、最優先的問題

7. 整體評估：哪些功能已經實現，哪些功能還未實現，還遺留哪些問題，遺留缺陷分析

8. 最佳化建議：測試過程最佳化，從測試組的角度為測試工作提出建議

圖6.1 星雲測試的差異報告分析

6.2 高階迴歸測試報告

對前期測試執行階段發現的問題、缺陷集中的功能，業務比較重要且使用頻繁的功能進行再次測試，確保系統上線後，已被修復的問題不會重新出現，重要的、高優先順序的業務不會發生錯誤。

圖6.2智慧迴歸測試用例選取

6.3 測試用例庫評估報告

軟體測試的主要工作，是把軟體需求對映為軟體測試。測試用例是軟體測試全過程的核心，也是測試執行環節的基本依據。精準測試充分滿足軟體測試執行過程中的各種指標：

1. 測試用例執行進度

2. 測試用例透過率

3. 測試用例顆粒度分析

4. 識別無用的測試用例

5. 識別冗餘的測試用例

6. 從側面提供增添新測試用例的依據

7. 從側面提供調整測試用例庫結構的依據

圖6.3 測試用例最小集

6.4 精準測試的VIP企業內網私有云可信化報表

星雲精準測試提供多個剖面的高可靠性測試質量進度追蹤報表。當客戶端錄入測試用例並採集資料後，使用者內網web端將產生實時、詳實的測試資料分析報表。

該報表與普通的測試管理系統不同：普通的測試管理系統人為錄入資料的情況比較多，使得資料狀態的真實性沒辦法確切保證。精準測試提供的報表，底層資料來自於執行測試用例時候程式碼資料的採集，透過專用底層介面上傳，完全無法進行資料調整或者篡改和偽造。

1. 透過瀏覽器登入測試系統，選擇需要跟蹤的專案，就可以實時對整個測試的質量、進度、人員進行精準的分析和管理。

2. 企業內網雲端管理系統展示的資料基於精準測試資料的分析，所有資料原生精確，支援移動測試+本地測試。

3. 測試團隊、開發團隊、甲方負責人等多種角色都可以登入系統，從各個層面對測試、軟體質量進行分析。

圖6.4專案彙總展示

6.4.1 精準測試的VIP企業內網私有云-測試效率的直觀展示

精準測試報告可直觀分析每天的測試效率，透過程式碼模組和複雜度關係圖，看到函式群落測試情況分佈及趨勢，可直觀精準識別系統測試所處階段。

每日增長覆蓋率報表：管理者可以清晰的看到整個團隊的效率趨勢變化，比如剛開始測試的時候覆蓋率增長快，到了黑盒測試瓶頸點上升就很慢了。這時候精準測試技術就開始發力，可以清晰地看到它在彌補效率損失方面的優勢。

覆蓋率和複雜度報表：可以很直觀地看到測試的質量深度，例如在測試不充分的時候，複雜度高的模組通常覆蓋率都比較低，統計點分佈自一個左上角的區域（表示高複雜度+低覆蓋率），而當測試深入進行，這些點就會向右側移動。管理者可以非常直觀的看到系統測試的充分程度和上線的質量把握。

圖6.4.1-1 覆蓋率每日增長趨勢圖與黑盒測試瓶頸

圖6.4.1-2 測試效率換檔點與測試深度趨勢觀察表

6.4.2 精準測試的VIP企業內網私有云-測試用例排行圖

**測試用例排行分析報表：**可直觀展示參與測試工程師所執行的用例數、透過率和缺陷率，真實記錄並分析每個測試用例的實效性。星雲精準測試-測試工程師實效精準分析系統，將參與的測試工程師所執行的用例從邏輯覆蓋對映到程式碼覆蓋，真實記錄並分析每個測試參與者的工作實效。以邏輯覆蓋為基準的而不是用例數量為考核標準。

圖6.4.2 測試用例排行圖

6.4.3 精準測試的VIP企業私有云-測試用例雙向追溯與覆蓋率視覺化

透過使用者的內網精準測試web報表，可以追蹤每個測試用例執行的覆蓋率和執行的函式路徑資訊，那些沒有真正執行的用例，將無法偽造其對應的覆蓋率資訊。

圖6.4.3-1測試用例雙向追溯

追蹤每個用例執行的函式資訊以及具體的程式碼覆蓋資訊，在web端展示程式碼覆蓋率檢視，更具體的分析用例的執行情況。

圖6.4.3-1覆蓋率視覺化

6.5 精準測試在數字化轉型中的作用

1、  完成數字化轉型。提高軟體交付質效、實現快速迭代持續交付，有效呈現測試價值。

2、  培養業務和測試的“兩棲專家”。從不同角度提供有價值的資料依據，使測試團隊既能熟悉業務知識、業務場景，又具備較強的業務分析評估和整合創新的能力。

3、  資料化交付。實現企業內部雲平臺建設、明確各工程活動環節的交付物和交付標準，並將質量驗證標準、驗證手段和監控工具嵌入流水線，保證各環節的有效性，對質量趨勢進行提示和預警，及早發現缺陷，實現質量可視、過程可追溯、可審計。

4、  建立測試資料資源池，整合測試資產。利用大資料、人工智慧等技術建立質量智慧分析模型等，為“產品質量智慧分析平臺”提供有效資料。

5、  減少因人員變動而產生的成本影響。一般外包人員的流失率普遍為20-40%左右，重新招聘和培養，將對專案進度及成本進度，造成很大影響。

第七章 精準測試企業級方案

7.1 DevOps微服務架構下具有程式碼級穿透能力的精準測試

微服務是DevOps場景下熱門的開發框架，在大型專案中被廣泛採用。它把一個大型的單個應用程式和服務拆分為數十個的支援微服務，獨立部署、互相隔離，透過擴充套件元件來處理功能瓶頸問題，比傳統的應用程式更能有效利用計算資源。微服務之間無需關心對方的模型，它透過事先約定好的介面進行資料流轉，使業務可以高效響應市場變化。

微服務一個明顯的表象就是隨著服務的增多，傳統測試模式受到很大制約，無法有效進行下去，威脅到整體系統質量。所有 J2EE 程式碼層白盒採集工具都無法區分覆蓋和具體功能的對應關係，只能以後臺模式“籠統”的採集一個階段的總的覆蓋，無法滿足對於DevOps下對於故障定位、深度測試分析以及敏捷釋出演算法的要求。星雲測試的分散式微服務精準測試解決方案，是目前市場上唯一可達到在複雜分散式系統中，跨多個伺服器進行程式碼白盒級分析、實現請求分散式追蹤的測試平臺。

精準測試透過分散式追蹤系統支援分散式系統的用例和程式碼的關聯，首先在瀏覽器的請求端注入一個使用者標籤，通常這個使用者標籤和精準測試客戶端的登入使用者是一致的。這個使用者標籤會一直帶到實際請求的執行執行緒裡面，然後這個執行執行緒裡面配合插裝的程式碼，發出來的資訊就知道是哪個使用者對應的哪個用例執行的程式碼了。同時分散式系統的話，如果有後續節點的呼叫這個標籤會繼續根據支援的協議附加使用者標籤資訊往後傳遞。

我們目前支援的協議包括httpclient、dubbo、spring cloud、web service以及訊息佇列也支援執行緒池內部不同執行緒的傳遞等等，對於我們附加的標籤，可以在這些協議上繼續往後傳遞，通常是在協議上附加我們的使用者標籤資訊來實現。對於使用者自定義的協議或者小眾的開發協議，使用者可以基於我們的介面自定義。

圖7.1-1 微服務穿透方案

圖7.1-2 微服務模組呼叫關係圖

7.2 “靜默式”精準測試，讓企業無縫完成黑盒測試的升級對接

精準測試最核心的技術關鍵就是：用例和相關執行程式碼之間有很強的對應和追溯關係。這個強追溯關係的建立，透過精準測試專屬客戶端上的“軟體示波器“，用人工點選開始和結束按鈕來標記測試用例的執行，進而確定對應程式碼執行路徑的邊界。

目前很多公司內部都有開發測試管理系統或者類似於JIRA這樣的通用產品來管理和執行用例，如果同步使用精準測試客戶端，則有指令重複之嫌。因此，星雲精準測試做了具有深遠意義的客戶化改進-“靜默式”精準測試。

大部分的測試管理系統，測試過程中會點選開始和結束按鈕用於界定測試用例的邊界，這和精準測試中的示波器操作是一致的。我們做了一個介面，使測試人員在“用例管理系統”中選擇某個用例執行到切換到另外一個用例的過程，和精準測試示波器進行無感對接，測試工程師不用登入到精準測試客戶端，即可實現“靜默式”精準測試的資料採集。“測試管理系統”的用例會透過這個內部介面，自動的和精準測試平臺建立連線。

圖 7.2中是一個基於excel用例管理的對接的方案，測試工程師只要在用例的表格上用滑鼠點一下當前要執行的用例條目，透過VBA介面就可以通知示波器當前某個用例即將開始測試，使用起來非常簡單。

精準測試也可以為JIRA這種企業級的管理平臺提供外掛進行對接。如果是使用者自己開發的測試管理系統，也可以根據精準測試提供的介面文件做相應的平滑對接。

圖7.2 與excel表格對接

7.3 為自動化測試裝上精準測試的“翅膀”

現代的專業軟體測試中心，隨著專案迭代，通常針對每個系統構建了大量的自動化測試用例集，而啟動一次全量的自動化測試以CI級觸發，使之大比率透過，非常困難。測試工程師們常常需要投入很高的成本，把大量精力花在自動化用例失敗排查上面，然而有效發現BUG的機率依然很低。在反覆排查無果、心神俱疲的情況下，很多單位幾乎對自動化產生絕望之心，視之為雞肋，用之無用，棄之可惜，讓測試中心極為頭疼。

如何讓自動化用例發揮它們應有的效用，讓QA工作不那麼沉重呢？星雲測試針對這一難題，進行了精準測試與自動化測試無縫對接的技術方案研發。經過大量企業實施與驗證，精準測試的資料流最終可以“無感”對接到自動化測試中，極大擴充套件了自動化測試的優勢，徹底改進了自動化測試變更管理難的短板。

這一技術方案的推出，就像給自動化測試裝上“精準測試”的眼睛和翅膀，瞬間就具備了多種飛躍性功能。比如：

1. 自動化測試用例與原始碼自動建立關聯

2. 同步進行智慧迴歸用例選取

3. 有效縮小自動化測試執行範圍

4. 即時分析需要進行維護的測試用例集合

5. 全自動追蹤每個測試用例的執行程式碼路徑

6. 當自動化執行結束後可輔助直接定位自動化用例的程式碼出錯點

7. 對自動化測試用例集進行分析，例如聚類分析，以及最小用例集合分析等

8. 對測試用例集的最佳化給出指導意見

9. 給出測試用例集執行的總體覆蓋率資訊

10. 協助有效的對用例集進行增補

11. 增量程式碼覆蓋率分析等等。

精準測試系統提供標準介面，可以很容易的與企業原有的自動化平臺進行對接，當執行完自動化測試後，可以得到每個自動化用例對應的程式碼邏輯資訊、相應功能模組等，為自動化測試提供有效的價值疊加與放大。

7.3.1 精準測試提供HTTP請求中轉檯直連對接模式方案

精準測試提供HTTP請求介面給自動化或測試管理平臺，透過HTTP請求將測試用例的建立、執行、結束與檢視測試用例的覆蓋情況命令，發給星雲精準測試自動化平臺的相應介面，進行測試用例的建立錄入與停止功能，並透過該介面進行覆蓋率資訊返回。

圖7.3.1-1 精準測試HTTP介面請求中轉檯直連對接模式

圖7.3.1-2 精準測試與自動化對接後推薦自動化用例場景

7.3.2 實現“手自一體”的高效解決方案

1. 精準測試將自動化測試指令碼與“業務全景圖”和測試用例庫建立關聯。

2. 在測試設計、測試執行、管理和質量監控等環節實現了“手自一體”的一體化管理理念。

3. 構建測試資料庫，實現測試資料統籌分配和複用。

4. 組建“精準自動化測試執行雲平臺”，實現24小時測試目標。

7.4 星雲測試插樁編譯流程與CI整合

對於精準測試的插樁程式碼是直接靜態植入了釋出包，只能供測試使用，不能使用者生產釋出。通常精準測試與CI對接，每釋出一個版本會產生兩個分支一個是釋出生產的分支，一個是釋出給測試環境的分支，他們的程式碼基線是一致的，就是一個透過精準測試做了插樁，另一個沒有做插樁，他們的功能和版本都是一致的。插樁後的程式碼執行後關聯程式碼也是關聯同樣基線版本的程式碼就可以了。

圖7.4 精準測試與CI對接方案

第八章 知識庫累積

8.1 精準測試資料的價值

星雲測試採集的測試資料和插裝後分析到的靜態結構資訊，將作為大型企業系統大資料分析的基礎資料。

星雲精準測試-測試資料價值

（1）程式碼級的程式靜態資訊以及測試用例對應的海量動態測試的資料，這些多維度資料將作為大型企業系統大資料分析的基礎資料。

（2）對本企業大量軟體質量資料進行挖掘和分析，找到相關質量技術標準衡量的合理區間，避免常規錯誤。

（3）透過資料分析確定優異的開發方法和技術構件。

（4）透過質量大資料的分析結果，選擇更加合理的技術方法，在設計階段避免已知的缺陷。

8.2 精準測試智慧迴歸測試用例智慧選取

在大型軟體的迭代過程中，測試最大的壓力來自於迴歸測試，因為對於大型系統很難說得清楚新的變更可能會意外的影響那些其它功能。國際上有相關統計：每修改6行程式碼就會引入一個未知的缺陷。而要對迴歸範圍進行分析通常必須是對系統很瞭解的架構師、高階開發人員或高階業務人員才能夠分析，因為程式的功能和它的實現就像是一張蜘蛛網錯綜複雜，即使高階人員也很難分析的非常清楚。精準測試在記錄了所有用例對應的程式碼邏輯的基礎上，在新版本釋出的時候透過分析用例執行的程式碼路徑的變更範圍，就可以自動計算出來迴歸用例的範圍。它的演算法邏輯和人的分析非常相似，但可以進一步提供非常高效率、海量資料的穩定分析輸出，相當於把人的腦力算力轉換成了計算機算力。

圖8.2-1 精準測試智慧迴歸測試用例的選取

（1）適應快速的版本迭代週期，適應龐大的工程專案。

（1）（2）在迴歸測試時，自動篩選測試用例，大大減少了迴歸測試的時間以及風險。

（1）（3）降低了傳統人工迴歸分析產生的測試盲點。

（1）（4）精確計算迴歸用例的權重，測試人員在時間有限的情況下可以重點回歸受改動影響最大的用例。

圖8.2-2 迴歸測試用例選取介面

8.3 精準測試在迴歸測試中的效能評估

迴歸效能，通常一般迴歸都是基於人對於系統的判斷來做的。由人來進行迴歸用例集的判斷，隨著時間的延續，記憶將不可逆轉地發生損耗並丟失，加之原團隊人員的不斷變更，老的系統維護越來越難，修改引入新的缺陷要越來越難風險。

透過星雲精準測試企業離線平臺，內建程式將持續、高效地全自動記錄本企業自有的各系統測試用例和程式碼的關係資料，不用人工干預和記錄。使用一段時間後，企業會得到越來越精確的資料，若加以有效利用，將發揮相關後設資料及大資料的爆發性的價值。

圖8.3 智慧迴歸測試用例選取的效能評估

8.4 精準測試形成的測試資產

測試資產：即與測試相關的技術、文件、資料、指令碼、管理、成本、進度、可用資源等。測試資產是測試工作過程中的產出，是專案的工作成果。建立測試資產庫是測試資產複用的重要前提條件。

1、  經過實際驗證，高效甄別出可複用的大量的測試用例和測試資料，可大幅縮短評審時間。新專案在測試過程中，如果需要測試用例或者測試資料，可直接在測試資產庫獲取，不必再花費大量的時間和人力重新編寫。

2、  測試資產庫適用於維護型的專案。功能點經過修改後，透過測試資產的複用，只需要更新經過變動的功能點測試用例，其它的未經更改的功能點測試用例就可以直接使用。透過這樣的測試資產的複用，可以大幅提高測試效率和測試質量，節約測試成本。

3、  測試資產庫的建立有助於保護測試專案的勞動成果。透過統一的途徑收集和整理測試資產，既便於回溯本次專案的測試過程，又可以為其它專案提供參考和幫助，是測試資產複用的前提和保障。測試資產庫在任何時候都處於最新和有效狀態。

4、  在測試可追溯的基礎上，降低了跨業務、跨部門業務分析的複雜程度。視覺化的動態業務全景圖，為決策者、業務部門、技術人員的測試設計、執行和質量評估提供核心依據。

5、  建立有效測試質量指標評價體系，實現智慧化測試方案設計。積累自動分析用例集覆蓋率、冗餘度、迴歸權重等有效資料資產，實現“以最優用例，覆蓋最全面功能”的目標。

6、  透過對歷史資料的挖掘與分析，歸納出影響測試資源分配的關鍵因素。透過對業務系統歷史測試資料的挖掘和分析，歸納出被測系統的缺陷特徵和識別趨勢以及與之相關的關鍵因素，未來作為測試准入、準出判斷的參考依據，為識別待測系統的投產風險提供依據，為實測系統上線決策和風險應對提供支援。

7、  具備成為“測試中臺”的核心元件的條件。星雲測試旗下產品具有高度自研創新能力，星雲可以根據使用者的創新需求，做更為具體的行業整體解決方案。

下篇【 Wings–企業級單元測試自動編碼引擎】

（ 附Wings免費下載和白皮書pdf下載）

第一章 Wings企業級單元測試自動編碼引擎誕生的背景

隨著科技的飛速發展，軟體系統越來越複雜，在系統測試階段不斷遇到的瓶頸，迫使行業逐步追根溯源到了單元測試階段。軟體缺陷發現得越晚，其處理費用就越呈幾何激增，因此測試左移概念已經成為趨勢。

單元測試面臨的最大問題是單元測試用例編寫工作量巨大，極端情況下與開發工作量比達到1：1，甚至更高，這使大部分開發團隊要麼主動忽視單元測試，要麼象徵性的走個流程。

如果可以讓計算機先對被測試程式進行全域性分析和深度理解，再由計算機進行全自動的完成單元測試編碼，同時還能確保自動編寫的程式碼無語法、語義錯誤的直接執行起來，這種用計算機智慧演算法全自動產生的測試編碼去驗證開發人員編寫的原始碼邏輯輸入輸出對錯的高階測試模式，無疑是未來軟體測試領域最為璀璨的“明珠”技術。

國外軟體諸如c++ test完成了這個領域的初步技術探索，星雲測試研發的Wings（目前商用產品支援c/c++程式）產品，則大踏步完成了整體技術跨越和多方商用落地驗證。

Wings可以對程式引數進行深度解析，比如c++類、模板類、陣列、結構體、指標、連結串列以及任意複雜結構的層級巢狀，同時對於物件導向的程式特性以及常用的容器庫，能夠完美識別和支援。對於一些void*、函式指標、模板類等無法直接靜態分析進行型別確定的特殊情況，均有基於人工智慧的程式分析輔助進行型別確定。

Wings在基於深度引數解析的基礎上，對於全域性範圍的程式進行理解分析後，第一步 按照內建規則，自動化構建被測程式的輸入用例程式碼；第二步 構建測試程式碼用於呼叫被測程式的原始碼；第三步 構建被測程式輸出斷言，完成呼叫被測試程式單元的全部環境準備。這個構建速度非常快，可以達到每分鐘100萬行左右的生成速度，編寫的程式碼比程式開發人員手工編寫的規範度高出一截，並確保100% 的語法語義正確，免去大量的除錯時間。

在驅動資料上，Wings實現了驅動程式碼和資料的分離。Wings基於深度引數解析基礎上，可以根據引數的結構自動生成層級巢狀的測試資料結構，用圖形介面視覺化的展示給使用者。使用者只需要根據Wings提供的介面嚮導對測試資料進行填充即可，驅動程式會自動識別並讀取這些資料，完成對被測試程式的呼叫。

Wings還可以全自動生成引數捕獲程式，並自動插裝在被測試程式中。當被測試程式執行後，可以透過專用軟體捕獲程式中每個函式模組執行的具體引數值。Wings的測試程式碼驅動自動生成和引數捕獲，相當於完成了一種全智慧的閉環測試驗證體系。Wings使測試資料不需要人工準備，只需要在前序輪次中透過引數捕獲自動儲存。若前序測試用例執行正常，那麼這些資料都可以作為後續測試輸入和進行校驗的基礎資料。

第二章 單元測試自動生成技術

2.1 測試左移後單元測試面臨的問題

測試左移後，傳統的單元測試一般面臨很多問題，主要如下：

(1) 傳統程式級測試用例的編寫會耗費開發人員大量的工時，比如TDD測試驅動開發裡面的單元測試無法有效實施，導致所有測試幾乎全部依賴於系統級黑盒測試。程式級測試用例的開發成本是功能實現程式碼本身時間至少為1：1，絕大部分企業選擇放棄開發程式級測試，而採用系統級測試方法。

(2) 需求發生變化導致程式實現發生變化後，程式集用例也需要發生變化，和自動化面臨的問題一樣，單元測試本身的可維護性問題導致投入是持續的而不是一次性的，會打消其企業應用的熱情。

(3) 很多單元在未組裝成系統的時候切入，如果需要進行測試需要進行大量的mock操作或者樁模擬，這個過程會造成單元測試的不精確性。

(4) 程式集測試資料量很大，全部需要使用者來進行準備無法全自動從前序系統測試過程中獲取。

針對以上問題，很多業內人士提出了很多辦法，例如自動生成測試用例、自動構建測試驅動、模糊測試方法等諸多方式，但是實際開發中程式輸入引數十分複雜，簡單的輸入已經不能滿足，如何能夠構建複雜的引數輸入，是要解決的重要問題。因此，星雲測試研發了Wings產品–單元級的自動編碼引擎，它不僅能夠自動構建測試驅動，還能處理十分複雜的大型程式引數，幫助企業能夠更好的進行單元測試。

2.2 完成單元測試要素

構成單元測試的要素如下：

a. 測試資料

b. 測試驅動程式碼

例如針對以下程式，需要準備的測試輸入以及測試程式碼

①　全域性變數：c

②　引數：a、b

③　預期輸出：320 30

int c = 100;int sum(int a, int b){
	return a + b + c;}int driver_sum(){
	int a = 100, b = 20;
	c = 200;
	return sum(a, b);}TEST(test, driver_sum){
	EXPECT_EQ(320, driver_sum);
	EXPECT_EQ(30, driver_sum);}12345678910111213141516

2.3構建測試資料和測試程式碼遇到的技術瓶頸

編寫測試程式碼比較繁瑣

開發編寫驅動不難，但是浪費大量的時間，並且沒有創造性。

編寫程式碼是否有良好的程式碼規範

單元測試也需要一些規範支援，例如程式碼規範，註釋規範等，有了這些規範能夠為測試人員提供很好的功能測試用例設計的邏輯思考，也為其他開發熟悉程式碼提供極大的便利。

資料型別比較複雜

通常情況下，輸入引數比較複雜，巢狀層析結構比較深入，例如類包含其他類等。

能否支援多組測試資料

一般程式碼中每個迴圈、分支判斷以及輸入輸出都有可能產生缺陷。因此單元測試需要很多用例，滿足不同的條件分支，達到滿足覆蓋率。

第三章 Wings的基本架構介紹

3.1 Wings測試用例驅動自動生成技術的特性

（1）Wings是智慧的全自動測試用例驅動構建系統，能夠在很短時間內完成對大型複雜程式的自動解析、構建。每分鐘達到100萬行程式碼的生成速率。

（2）可以將任意複雜型別逐步分解為基本資料型別，例如結構體巢狀，複雜類物件，c++標準容器，自定義模板類等。

（3）支援多層次的視覺化的資料表格來對變數型別進行賦值，無需關注驅動程式本身。資料表格可以表達任意深度和多層次的資料關係，使用者只需要關注表格資料，完成對輸入資料的校對。

（4）能夠區分系統資料型別和使用者自定義型別，對於複雜的約定俗成系統型別可由使用者自定義扁平式賦值模板，例如std::vector型別等，內部整合常用系統型別的模板。

3.2 Wings的技術架構介紹

Wings的技術架構：首先Wings利用程式碼靜態分析技術，提取被測程式的主幹資訊並儲存到Program Structure Description（PSD）結構中，PSD結構中主要儲存函式的引數、全域性變數以及返回值的資訊，類的成員變數，成員函式，以及訪問許可權等資訊。利用儲存的資訊，依據一定的編寫規則，自動構建測試驅動、googletest 期望斷言、測試輸入、引數捕獲等程式碼和值。

圖 3.2 Wings總體架構圖

上述Wings的總體架構圖，說明了Wings構建程式碼與測試輸入的具體過程，整個核心技術是透過編譯底層技術獲取程式的資訊，然後按照一定的規則構建需要的資料。

第四章 程式結構資訊描述

程式結構資訊（Program Structure Description）是指對源程式進行提取後的描述資訊，主要包括類名、名稱空間、類的成員變數資訊、類的函式資訊，以及各種型別資訊等（程式結構資訊，下文簡稱“PSD”）。描述資訊的儲存C語言是以一個檔案為單元儲存，C++提取所有的類資訊儲存在一個檔案中。

Wings的主要特性是能夠對複雜的型別（結構體、類、模板類等）進行逐層展開

分解到最基本資料型別（char、int、string等）。

PSD結構儲存在XML檔案中，不同的XML檔案儲存不同的描述資訊。Wings提取的程式結果都儲存在Wingsprojects檔案下的funxml與globalxml資料夾中，其中funxml檔案中主要儲存的檔案以及作用如下：

RecordDecl.xml: 結構體，聯合體與類描述資訊。

ClassTemplateDecl.xml:模板類描述資訊

EnumDecl.xml:列舉描述資訊

funcPoint.txt： 儲存函式引數為函式指標的分析結果。

funcCount.txt: 儲存分析到的全部函式，引數個數，引數型別資訊。

void.txt: 儲存函式引數為void*的分析結果。

filename.xml：儲存c語言檔案的資訊。

注：具體檔案的描述資訊，參看附錄A。

針對複雜型別，例如結構體型別location_s，成員變數中除了基本資料型別之外，還存在包含結構體型別的情況，如下所示的程式碼中，location_s中包含coordinate_s結構體，以及FILE等型別的資訊，針對不同的型別進行標記區分。

原始碼如下：

typedef struct coordinate_s{
    void(*setx)(double, int);
    int mInt;
    char *mPoi;
    int mArr[2][3];
    void *vo;} coordinate;typedef struct location_s {
    int **mPoi;
    coordinate *coor;
    FILE *pf;
    struct location_s *next;}location;coordinate *coordinate_create(void);int coordinate_destroy(location *loc,size_t length,char *ch);void func_point(double param1, int param2);1234567891011121314151617181920

生成對應的PSD結構資訊如下圖4：

圖4：PSD描述資訊

C++的主要表示型別是類，因此測試是C++以一個類為單元做測試，類主要包括類的成員變數名以及型別資訊，成員變數的訪問許可權資訊。類的成員函式分為建構函式、行內函數、虛擬函式等，成員函式的引數資訊以及型別資訊等。具體描述資訊可以登陸下載Wings試用版本進行學習。

第五章 Wings構建程式描述

Wings透過獲取到的儲存資訊，依據一定的編碼規則，構建不同的程式碼程式，如驅動程式、期望斷言程式、引數捕獲程式等。

5.1 驅動程式構建

驅動程式指單元測試程式碼，Wings針對函式引數的型別，自動完成單元測試程式碼的編寫。為了更詳細的說明驅動程式，以一個C++類作為具體的例子說明。

類的宣告如下：

class BlockBuilder {public:
    explicit BlockBuilder(const Options* options);
    BlockBuilder(const BlockBuilder&) = delete;
    BlockBuilder& operator=(const BlockBuilder&) = delete;
    void Reset();
    void Add(const Slice& key, std::string & value);
    Slice Finish();
    size_t CurrentSizeEstimate() const;private:
    const Options* options_;
    std::string buffer_;
    int counter_;
    bool finished_;};12345678910111213141516

針對如上BlockBuilder 類，構建一個對應的驅動類DriverBlockBuilder，驅動類中主要包含建構函式、解構函式、每個成員函式的驅動函式以及返回值函式。為了避免類中重名函式，對寫入PSD需要對應生成驅動的函式進行順序編號。

驅動類宣告：

class DriverBlockBuilder {public:
    DriverBlockBuilder(Json::Value Root, int times);
    ~DriverBlockBuilder();
    int DriverBlockBuilderReset1(int times);
    int Reset1Times;
    int DriverBlockBuilderAdd2(int times);
    int Add2Times;
    int DriverBlockBuilderFinish3(int times);
    void ReturnDriver_Finish3(class Wings::Slice returnType);
    int Finish3Times;
    int DriverBlockBuilderCurrentSizeEstimate4(int times);
    void ReturnDriver_CurrentSizeEstimate4(size_t returnType);
    int CurrentSizeEstimate4Times;private:
    Wings::BlockBuilder* _BlockBuilder;};1234567891011121314151617

在上述驅動類中，建構函式的作用是構造BlockBuilder的物件，用構造的物件，呼叫測試BlockBuilder中的成員函式。解構函式的作用是釋放構建的物件。

建構函式與解構函式：

DriverBlockBuilder::DriverBlockBuilder(Json::Value Root, int times){
  Json::Value _BlockBuilder_Root = Root["BlockBuilder" + std::to_string(times)];
  /* options_ */
  Json::Value _options__Root = _BlockBuilder_Root["options_"];
  int _options__len = _options__Root.size();
  Wings::Options* _options_ = DriverstructOptionsPoint(_options__Root, _options__len);
  /* buffer_ */
  std::string _buffer_= _BlockBuilder_Root["buffer_"].asString();
  /* counter_ */
  int _counter_ = _BlockBuilder_Root["counter_"].asInt();
  /* finished_ */
  bool _finished_;
  int _finished__value_ = _BlockBuilder_Root["finished_"].asInt();
  if (_finished__value_ == 0) {
    _finished_ = true;
   }
  else {
    _finished_ = false;
  }
  _BlockBuilder = new Wings::BlockBuilder(_options_, _buffer_, _counter_, _finished_, false);}DriverBlockBuilder::~DriverBlockBuilder(){
    if (_BlockBuilder != nullptr) {
        delete _BlockBuilder;}}12345678910111213141516171819202122232425262728

每個成員函式對應生成自己的驅動函式。類中的Add函式對應的驅動函式如下。

Add驅動函式：

int DriverBlockBuilder::DriverBlockBuilderAdd2(int times){
    Add2Times = times;
    const char* jsonFilePath = "drivervalue/BlockBuilder/Add2.json";
    Json::Value Root;
    Json::Reader _reader;
    std::ifstream _ifs(jsonFilePath);
    _reader.parse(_ifs, Root);
    Json::Value _Add2_Root = Root["Add2" + std::to_string(times)];
    /*It is the 1 global variable: count    Add */
    int _count = _Add2_Root["count"].asInt();
    count = _count;
    /*It is the 1 parameter: key Add2
     * Parameters of the prototype:const Wings::Slice &key */
    Json::Value _keykey_Root = _Add2_Root["key"];
    /* data_ */
    char* _keydata_;
    {
        std::string _keydata__str = _keykey_Root["data_"].asString();
        _keydata_ = new char[_keydata__str.size()];
        memcpy(_keydata_, _keydata__str.c_str(), _keydata__str.size());
    }
    /* size_ */
    unsigned int _keysize_ = _keykey_Root["size_"].asUInt();
    Wings::Slice _key(_keydata_, _keysize_, false);
    /*It is the 2 parameter: value    Add2
     * Parameters of the prototype:const std::string &value  */
    string _value = _Add2_Root["value"].asString();
    //The Function of Class    Call
    _BlockBuilder->Add(_key, _value);
    return 0;}123456789101112131415161718192021222324252627282930313233

構成以上驅動函式的主要包括全域性變數、引數、呼叫被測函式的構建。

以上是針對BlockBuilder類的驅動類的主要資訊，而構建的程式遵守google的編碼規範。一些命名規則如下：

Wings生成的驅動程式碼，儲存在drivercode資料夾中。

（1）driver.cc與driver.h，針對程式中使用到的一些公共函式以及標頭檔案。

（2）同一個結構體或者聯合體，可能會作為多個函式的引數使用，為了避免程式碼的重複，Wings針對所有的結構體和聯合體的不同型別，封裝成不同的驅動函式或者引數捕獲函式。driver_structorunion.cc 儲存結構體驅動函式的代driver_structorunion.h 對應的標頭檔案。

結構體實現函式的命名規則為：DriverStruct+結構體名字+型別，其中Point代表一級指標或者一維陣列，PointPoint代表二級指標或者二維陣列使用。

原始檔的命名規則為：driver_+原始檔名/類名+.cc

例如：driver_nginx.cc 或 driverBlockBuilder.cc

驅動函式的命名規則：Driver_+函式名+（編號）

例如：Driver_ngx_show_version_info(void);

DriverBlockBuilderAdd2(int times)

（3）返回值的列印輸出

返回值的列印輸出函式命名規則：Driver+Return+Print_+函式名。

例如：DriverReturnPrint_ngx_show_version_info();

（4）使用者原始碼中的main函式自動進行註釋，重新生成一個main函式檔案，來進行測試。Wings會生成驅動main的主函式檔案為:gtest_auto_main.cc

Wings主要針對引數進行逐層展開，解析到最底層為基本型別進行處理。驅動的賦值部分，主要就是針對基本型別進行處理。（注：特殊型別，比如FILE等，後面會詳細講解如何賦值）

以int型別舉例，一般程式構成int的主要組成大概包括以下情況：

int p; int *p; int **p; int ***p;

int p[1]; int p[2][3]; int p[1][2][3];

int(*p)[]; int(*p)[][3]; int *(*p)[]; int (**p)[];

int *a[]; int **a[]; int *a[][3]; int (*a[])[];

Wings會針對基本型別的以上15種型別，進行不同的賦值。

構建完驅動程式之後，要對驅動程式進行執行，Wings構建googletest的框架，來進行測試。下面我們將針對期望斷言的googletest程式進行構建。

5.2 googletest程式的構建

在構建完單元測試驅動程式之後，Wings將呼叫googletest的框架，完成對返回值的期望值驗證程式碼，並且輸出測試結果。

Wings執行單元測試過程中，會構建返回值的儲存程式碼，將程式的返回值結果進行儲存，然後讀取使用者輸入的預期值，進行結果對比，判斷是否透過。

針對具體的類，對應生成gtest類，每個gtest類中對每個函式構建期望程式碼。例如針對BlockBuilder類，生成的gtest類為 GtestBlockBuilder。

GtestBlockBuilder類的宣告：

class GtestBlockBuilder : public testing::Test {protected:
    virtual void SetUp()
    {
        const char* jsonFilePath = "../drivervalue/RecordDecl.json";
        Json::Value Root;
        Json::Reader _reader;
        std::ifstream _ifs(jsonFilePath);
        _reader.parse(_ifs, Root);
        driverBlockBuilder = new DriverBlockBuilder(Root, 0);
    }
    virtual void TearDown()
    {
        delete driverBlockBuilder;
    }
    DriverBlockBuilder* driverBlockBuilder;};12345678910111213141516171819

BlockBuilder類中的每個函式對應一個gtest函式，每個函式負責呼叫DriverBlockBuilder編寫的驅動函式，對於包含返回值資訊的函式，則對應生成具體的期望值對比。

期望對比函式CurrentSizeEstimate：

TEST_F(GtestBlockBuilder, DriverBlockBuilderCurrentSizeEstimate4){
    const char* jsonFilePath = "drivervalue/BlockBuilder/CurrentSizeEstimate4.json";
    Json::Value Root;
    Json::Reader _reader;
    std::ifstream _ifs(jsonFilePath);
    _reader.parse(_ifs, Root);
    for (int i = 0; i < BLOCKBUILDER_CURRENTSIZEESTIMATE4_TIMES; i++) {
        driverBlockBuilder->DriverBlockBuilderCurrentSizeEstimate4(i);
        Json::Value _CurrentSizeEstimate4_Root = Root["CurrentSizeEstimate4" + std::to_string(i)];
        /* return */
        unsigned int _return_actual = _CurrentSizeEstimate4_Root["return"].asUInt();
        /* return */
        unsigned int _return_expected = _CurrentSizeEstimate4_Root["return"].asUInt();
        /* return_expected */
        EXPECT_EQ(_return_expected, _return_actual);
    }}12345678910111213141516171819

最後呼叫自動構建的main函式執行整個單元測試過程。

5.3 引數捕獲程式構建

引數捕獲是指在程式執行過程中獲取程式的變數資訊，主要包括函式的引數、全域性變數、返回值等。Wings自動構建獲取引數的程式，利用插裝技術，將構建的捕獲函式插入原始碼中對應的位置，將獲取的具體資訊，寫入值檔案，可以將獲取的資料作為單元測試的輸入，在程式碼發生變更後，利用相同的輸入判斷是否得到相同的輸出，進行迴歸測試。

Wings的引數捕獲程式碼儲存在paramcaputrecode資料夾中。其中命名規則同驅動格式一樣，將所有的driver替換為param即可。Wings針對每個類生成一個對應的引數捕獲類，而引數捕獲類中針對每個函式生成對應的捕獲引數、全域性變數以及返回值的函式。c++ 中類的成員變數是私有，無法從外部獲取，Wings利用插樁技術，對每個類插入一個捕獲函式，來獲取類的私有成員變數。

引數捕獲類ParamCaptureBlockBuilder：

class ParamCaptureBlockBuilder{public:
  ParamCaptureBlockBuilder();
  ~ParamCaptureBlockBuilder();
  void ParamCapture_Reset1();
  void GlobalCapture_Reset1();
  void ReturnCapture_Reset1();
  void ParamCapture_Add2(const Wings::Slice &key, const std::string &value);
  void GlobalCapture_Add2();
  void ReturnCapture_Add2();
  void ParamCapture_Finish3();
  void GlobalCapture_Finish3();
  void ReturnCapture_Finish3(class Wings::Slice returnType);
  void ParamCapture_CurrentSizeEstimate4();
  void GlobalCapture_CurrentSizeEstimate4();
  void ReturnCapture_CurrentSizeEstimate4(size_t returnType);};12345678910111213141516171819

具體的捕獲函式不再詳細說明，具體資訊可以在Wings官網下載試用版本檢視。

第六章 Wings型別以及物件導向語法特性的支援

Wings能夠支援任意的型別以及物件導向的語法特性。

型別支援：

• 基本型別，int、double、float、std::string等

• 任意複雜的結構型別，結構體、聯合體、列舉、連結串列、多級指標、陣列、樹、圖等

• 任意複雜的類物件，標準庫容器、自定義模板類

特殊模板：

• 區分使用者自定義的型別與系統變數型別（標準庫標頭檔案中包含的型別）

• 類的運算子過載函式

• void *與函式指標

• 識別類中包含delete與default關鍵字的函式進行特殊處理

語法支援：

• 處理static函式、保護和私有函式

• 類中定義私有結構體

• 類中包含delete與default關鍵字的函式進行特殊處理

• 多型與複雜的類繼承

6.1連結串列

針對連結串列型別，採用比較靈活的賦值方式，考慮到實際應用中的一些因素，針對連結串列型別，預設賦值兩層結構，在實際測試過程中，使用者可依據需要自動新增節點。

6.2 標準庫容器

Wings能夠支援c++的標準庫容器，能夠對容器進行逐層展開，利用不同容器的標準賦值函式進行賦值以取值。

其他類似的容器例如QT中的容器以及boost庫中的相關容器，我們在繼續支援。

6.3 自定義模板類

一些使用者自定義的模板類型別，Wings能夠識別是使用者自定義的模板類，Wings依據實際程式中的賦值型別，進行處理。

6.4 void*與函式指標

Void*與函式指標在實際程式中可以作為函式引數或者結構體與類的成員變數，針對不確定的賦值型別，Wings提供了具體的解決辦法：

①　利用編譯底層技術，對源程式靜態分析，獲取真實型別，對真實型別進行賦值

②　由使用者在資料表格介面配置實際型別

6.5 特殊模板

在實際的程式碼程式中，會存在一些型別無法使用通用的模式全部展開,如一些系統變數（FILE、iostream）、第三方庫以及一些使用者需要特殊賦值。

Wings是如何針對以上特殊型別進行賦值，舉例如下：

struct sockaddr_in {
        short   sin_family;
        u_short sin_port;
        struct  in_addr sin_addr;
        char    sin_zero[8];};123456

步驟如下：

a. 識別sockaddr_in為系統變數型別，特殊標記

b. 檢測程式中的所有系統變數型別，顯示在模板介面

c. 使用者配置特殊變數，如sin_family

d. 構建sockaddr_in物件

e. 呼叫模板，生成驅動

模板配置如下：

圖：6.5模板配置

第七章 資料表格

Wings目前測試用例資料採用隨機生成的方式，支援int、char、double、float、bool、char*型別。資料表格可以任意編輯以上型別的數值。

(1)Wings資料表格將會針對引數進行展開，假如引數型別為結構型別，資料表格將分層展開結構的型別，到基本型別。

(2) 針對基本型別的指標型別，例如int *p;Wings處理為不定長度的一維陣列型別，int **p;處理為不定長度的二維陣列型別，預設長度為3，資料表格介面可以點選進行新增和刪除資料。

(3) 針對不定長度的陣列作為函式引數，例如int p[];Wings預設長度為1，使用者依據需求，在資料表格介面進行任意新增和修改即可。

圖7-1資料表格展示

附錄A
表一：type屬性

表二：basetype屬性

表三：其他屬性