一種提高軟件可測試性的診斷測試方法

文/屈曉光 胡玉露

在軟件的開發與測試過程中一直存在可測試性的問題，那么到底什么是軟件的可測試性，對于開發和測試人員來說針對具體的軟件版本要進行深入測試又存在怎樣的實際困難，需要我們認識清楚，以便把握問題實質。

先來看“軟件可測試性”的概念，什么是“可測試性”？按照業界的定義，軟件的可測試性是指軟件發現故障并隔離、定位其故障的能力特性，以及在一定的時間和成本前提下，進行測試設計、測試執行的能力。James Bach 這樣描述可測試性：軟件可測試性就是一個計算機程序能夠被測試的容易程度。

1 提高軟件可測試性時面臨的難題

以下是一個常見的軟件可測試性檢查表：

·簡單性-“需要測試的內容越少，測試的速度越快。”

·穩定性-“改變越少，對測試的破壞越小。”

·易理解性-“得到的信息越多，進行的測試越靈巧。

·可操作性-“運行地越好，被測試的效率越高。”

·可觀察性-“所看見的，就是所測試的。”

·可控制性-“對軟件的控制越好，測試越能夠被自動執行與優化。”

·可分解性-“通過控制測試范圍，能夠更好地分解問題，執行更靈巧的再測試。”

通過上述的描述可以對可測試性有一個定性的理解，但是仍然比較抽象，具體如何體現，還是不很清晰，即實現方法不明。

對于開發和測試人員所面臨的實際調測的問題比較分散，但是相對具體，總結了一下，可能并不全面，常見困難應該有所涉及：

1.1 測試人員熟悉代碼的程度比較弱，影響深入測試效果

圖1：異常測試系統運行模式圖

圖2：DTSDM 模塊探測點設計圖

測試人員中能熟練編程的不多，深入把握軟件代碼難度大，定位系統測試只是做黑盒，影響測試設計的進一步深入；

1.2 軟件運行過程中各種信息獲取不靈活

直接涉及軟件可測試性接口問題，常規是在代碼中加打印獲取，弊端較多。目前產品中已經做了不少有益實踐，如異常探針、DO LOG、CDT 等工具大大加強軟件信息的收集，不過專業性強，一般人員掌握難度大，還難以大范圍使用，影響效果；同時提取信息范圍相對確定，不能靈活變化

1.3 對軟件實施各種異常測試比較困難

軟件對各種異常處理往往存在大量缺陷，異常測試是進一步加強版本質量的關鍵，但是如何方便構造異常條件，運行眾多的異常用例難有系統化的方式，軟件從單元到模塊到系統規模越大越難展開

1.4 當系統出現異常時，各模塊間協同定位比較麻煩

當系統出現異常時，如何定位問題出現在哪里？往往根本原因隱藏較深，涉及眾多模塊交互運行，環環相扣直到最終才在某一模塊出現錯誤，即使周邊模塊只有少量信息需要跟蹤，也需要各模塊開發人員合作并下臨時版本來跟蹤追查，費時費力。當然測試人員更是難以出力。

2 解決難題的思路

上述問題在軟件開發與測試過程中各有側重，似乎難以綜合，但是仔細分析卻也具有一定相關性，根本約束有兩個：對軟件處理行為了解越多越有利測試，直接影響測試有效性；對軟件運行過程相關信息的收集乃至改變越容易越有利測試，即影響測試有效性也影響到高效性。

圖3：代碼統計圖

圖4：腳本編寫畫面

根據前面問題的總結，確定了如下研究目標：

（1）更系統地把握軟件行為；

（2）更方便地跟蹤定位故障；

（3）更直接的軟件異常測試。

研究的重點也是圍繞著兩個約束來進行，先來看第一個約束：對軟件處理行為了解越多越有利測試。這當然是一個望大的條件，但是面對超級復雜的產品軟件，要想完全把握每個模塊的每行代碼是不現實的。開發人員了解代碼多一些，也只限于所負責模塊和相關模塊，測試人員則更少。如果單純從代碼的角度來加強學習掌握，即走白盒路線是難有出路的，但是純黑盒也是不行的，于是走灰盒的路線進入視野，即我們看重的是軟件在實現什么功能，其處理行為是什么而不是具體的代碼行，如果找到一種適當的方式來使軟件行為得以顯現就達到目的，我們要做到的是“熟悉軟件行為，開展灰盒測試”，關鍵是要能降低應用門檻。

如何找到適合的做法呢，基本的想法就是在源代碼中插入探測點，對探測信息進行分級設計，使探測點在軟件代碼中進行合理分布，為此形成一個關鍵的想法：將流程圖標識在代碼中。詳細設計已經將模塊的功能分解至函數級，做出了詳細的工作流程圖，但是在實現代碼后代碼本身并沒有直接的體現，熟悉軟件的人必須對照詳細設計文檔來走讀代碼從而了解軟件行為，如果在設計實現代碼時就有手段將主要功能處理及邏輯關系于代碼中標識出來，就相當于給代碼做了個CT 掃描，形成一個灰盒模式的軟件事務處理圖，即體現了軟件代碼所做的主要工作又屏蔽掉了多余的實際代碼，去繁就簡，就如同探察人體，將血肉透視掉，看到經絡與穴位。

另一個約束：對軟件運行過程相關信息的收集乃至改變越容易越有利測試。這涉及對軟件運行進行診斷與測試，包括定位故障的過程和異常測試的過程。這個方面其實早已經有可用的技術，即利用IDT（Integrated Debug&Test Tool）進行代碼異常測試的方法。這里將主要的工作原理再說明一下。

軟件代碼異常測試系統的基本運行模式如圖1所示。

核心思路即在是源代碼中嵌入可定制的腳本來運行，即可讀取軟件相關信息也可改變相關信息，從而提供診斷與測試的途徑。

在第二個技術點的基礎上結合第一個技術點的設想，可以發現兩者有很好的融合，在軟件功能處理打點位置設計好后，利用技術點二中探測函數以宏的形式插入源代碼，即實現了本案中從可測試性設計到可測試性執行的轉換。在本案中提出構建IDTE 環境的構想，即Integrated Diagnos& Test Environment。

3 思路的實踐情況

3.1 可測試性設計

依據上述兩個主要的技術解決思路，結合相應測試工具給出測試項目的設計。

首先是可測試性設計的嘗試，即根據代碼業務處理功能分析進行探測點的布局，針對仿真模塊DTSDM、DTLACDP、DTTFDM 的代碼進行了研究，主要從業務處理的角度選擇相應的探測點位置，DTLACDP、DTTFDM 模塊相對簡單，復雜的是DTSDM模塊，如圖2示。

圖2為DTSDM 模塊代碼探測點設計，右側展開的樹為SDM 模塊處理中最為復雜的20ms 業務幀前反向處理功能實現，通過不同顏色來表示整個處理中功能分級展開，體現代碼處理行為，基本上五級已經足夠。右側展開的樹中未標識顏色的節點為不關心的代碼部分，由于是手工作圖，所以保留。顯然當代碼設計實現過程中逐步增加探測點后，需要有自動化的方式來生成類似的邏輯圖，才能有實用性，這個相關技術是存在的，就不在本文展開，留待后續分解。

代碼中探測點位置布局做好后，就可以結合技術點二的方式在實際代碼中進行打點宏插入了。應用代碼引用的IDTE 基本宏定義為

extern BYTE g_bAbProcFlag;

extern void IDT_AbProc(WORD wSignal,void * pBuffer,DWORD dwSize,DWORD dwAssistCode,VPID *ptSelfVPid,VPID *ptDestVPid);

#defineIDTEPROC(wSignal,pBuffer,dwSi ze,dwAssistCode,ptSelfVPid,ptDestVPid) if(g_bAbProcFlag==1){

IDT_AbProc(wSignal,pBuffer,dwSize,dwAssistCode,ptSelfVPid,ptDestVPid);}

以上面DTSDM 模塊處理20ms 業務幀時的處理步驟為例，消息EV_S_SignalOnFrameOffset 的處理由函數ProcessSignalOnFrameOffsetMsg 進行，其下一級打點的記錄為：

IDTEPROC(IDTE_ProcessSignalOnFrame OffsetMsg_RevFrmPreProcs,&(ptAbistDataBuf-＞tAbistComDataBuf),。。。);

IDTEPROC(IDTE_ProcessSignalOnFrame OffsetMsg_ProcsPreamble,NULL,0,0,NULL,NU LL);

IDTEPROC(IDTE_ProcessSignalOnFrame OffsetMsg_StopSendIdleFrm,NULL,0,0,NULL,NULL);

IDTEPROC(IDTE_ProcessSignalOnFrame OffsetMsg_AirLinkQualityDetect,NULL,0,0,NU LL,NULL);

IDTEPROC(IDTE_ProcessSignalOnFrame OffsetMsg_DemuxRevFrms,&tDemuxInputVar,si zeof(T_RevSlctedFrmInf),0,NULL,NULL);

IDTEPROC(IDTE_ProcessSignalOnFrame OffsetMsg_DispatchRevFrms,&tDemuxOutputVa r,sizeof(T_DemuxOutputPara),0,。。。);

IDTEPROC(IDTE_ProcessSignalOnFrame OffsetMsg_GetMuxConditon,NULL,0,0,NULL,NULL);

IDTEPROC(IDTE_ProcessSignalOnFrame OffsetMsg_GetMuxInf,NULL,0,0,NULL,NULL);

IDTEPROC(IDTE_ProcessSignalOnFrame OffsetMsg_MuxFwdFrm,NULL,0,0,NULL,NULL);

IDTEPROC(IDTE_ProcessSignalOnFrame OffsetMsg_SlowDownRate,NULL,0,0,NULL,N ULL);

IDTEPROC(IDTE_ProcessSignalOnFrame OffsetMsg_SetFwdPreProcsInputPara,&tMuxOut putVar,sizeof(T_MuxOutputPara),0,。。。);

IDTEPROC(IDTE_ProcessSignalOnFrame OffsetMsg_PreProcsAndSendFwdFrms,&tPrePro csInputPara,。。。);

IDTEPROC(IDTE_ProcessSignalOnFrame OffsetMsg_CapacityMeasuring,NULL,0,0,NULL,NULL);

針對函數DispatchRevFrms 其下一級的記錄為：

IDTEPROC(IDTE_DispatchRevFrms_Disp atchRevFDCHFrame,&(ptInputVar-＞atRevFCHT rafficTable[ucCircle]),。。。);

圖5：顯示結果圖

IDTEPROC(IDTE_DispatchRevFrms_Disp atchRevFDCHFrame2,&(ptInputVar-＞atRevDCC HTrafficTable[ucCircle]),。。。);

IDTEPROC(IDTE_DispatchRevFrms_SaveRlpRevBlock,。。。);

IDTEPROC(IDTE_DispatchRevFrms_Rev NoDataProcess,NULL,0,0,NULL,NULL);

IDTEPROC(IDTE_DispatchRevFrms_SDM SendRevFrmToRLP,ptSDMDataToRLP,sizeof(T_AsdrSDMDataToRLP),0,。。。);

所打點位置與邏輯圖中相一致，在具體布置探測點位置時有幾條準則可以依據，總結如下：

（1）要注意處理點是在主流程中還是進入了函數調用——打點級別歸屬關系，區分相對級別；代碼中調用函數是否打點分三種：內部無打點本身不打點（不用理會），內部有打點本身不打點（一級邏輯），內部有打點本身也需要打點（二級邏輯）。

（2）注意局部位置上不同分支處理的表示關系——if/else if/else 的分支打點。

（3）反映功能覆蓋的處理點選擇打點——入口、出口，中間處理點盡量減少同一分支的打點個數，即同一大分支中只選擇一個重要節點即可（一般是最后一個）。

（4）除了反映軟件功能覆蓋的功能處理點要打點外（入口、出口、中間重要處理點），其它處理點打點選擇——異常測試點、信息統計點。

上述（1）中所指的一級邏輯即某函數本身不打點而其內部有打點其實有很大用處，本例中體現在與異常探針的結合，原有代碼中已經將異常探針進行了大規模的布局，處理中的各種異常位置都有分布，利用這個成果，在進行IDTE 探測點布局時可大大減少對異常位置的打點，表現為：

其中函數ProcessSignalOnFrameOffsetMsg為二級邏輯，而函數ExcpReport 為一級邏輯，這種情況出現時其內部的探測點等同地出現于ExcpReport 所在位置。

在代碼中統一布局探測點整體效果是否有效尚有兩個疑問，一個是探測點的數量規模，一個是事先從業務角度選擇好的探測點在測試應用中是否夠用，這兩方面還需要通過實際應用來檢驗。

根據對DTSDM 源代碼進行探測點實現，目前的結果統計如下：

源代碼行數如圖3所示。

所有IDTEPROC 宏打點位置為225 處，基本是百行代碼打一個點，由于是對老模塊代碼進行設計，同時按集成和系統測試的角度進行功能分解，大致是這樣規模，如果是新設計模塊從單元測試開始可能會增加探測點數目。

3.2 可測試性執行

當代碼中已經加入了對詳細功能處理進行布點的探測點之后，對測試有何種好處呢，那就結合案例進行一些具體的介紹，體現其使用優勢。

首先是異常測試的進行，在探測點相對完整的布局下則可發揮特長。在選擇的探測點位置通過腳本可以進行異常變量/異常流程的設定，方便產生異常條件進行異常測試。下例進行一個簡單說明：

信令模塊會向SDM 模塊發送EV_S_AbafActivateSDM 消息，其中帶有所分配資源的幀偏置信息ucSDMFrameOffset，一個字節有效取值為0-15，如果取值不對則報異常并結束對此消息的處理，相應的定制腳本如圖4所示。

紅色標識處即為進行異常取值的設定，將消息中的這個字段改為非法值，代碼繼續處理后會發生相應異常，異常探針的信息如前述也通過相應探測點由腳本捕捉，進行顯示，結果如圖5所示。

順帶注意一下定制信息中IDTE_EntityEntry_normal 這個打印，在源代碼中這個探測點位于進程入口處

這是一個可有多種業務輸入消息的探測點，用處也很大。

4 結束語

結合文章開始所描述的測試問題及設定的研究目標，看一下效果的可行性及可以進一步研究完善的內容。上述方案的實施對于非代碼開發人員快速掌握軟件代碼功能，了解軟件行為具有去繁就簡的效果，當然需要提供自動掃描代碼生成邏輯圖的能力，這在探測點信息定義上還需要隨之做完善。

實現了探測點插入的軟件版本在運行中進行異常測試與跟蹤定位將有很大幫助，案例只體現了一部分應用特點，其它如進行流程自測、定制打印顯示、信令跟蹤等功能都可充分利用，此外一些更好優點可隨實際應用而擴展，如對軟件邏輯運行跟蹤回放、基于功能點的覆蓋率統計分析等。由于驗證內容與源代碼是有效隔離的，在實際調試測試過程中，始終可以保持代碼的“干凈”，對程序可維護性也有一定幫助。后續希望在軟件模塊設計編碼環節也增加作用。

本文所介紹的軟件可測試性設計及執行方法具有較大通用性，尤其是針對前臺嵌入式軟件而實現了系統架構，對于增強軟件診斷測試手段有一定作用。