給大家30秒的時間，一起來思考這是什麼？
這是某系統登陸模塊功能的初始類圖。
隨着現代軟件的不斷複雜化，代碼圖（Code Graphs）爲測試人員提供了一種直觀的方法，讓複雜的代碼邏輯易於理解。本文將深入探討代碼圖，通過挖掘到的真實場景和實際示例，展示可視化代碼圖如何增強軟件測試人員的能力以及如何開展測試工作。
一、什麼是代碼圖
代碼圖指的式用於表示代碼結構、類之間關係或代碼元素之間交互的圖形化工具，常見類型包括類圖、時序圖、活動圖、組件圖等多。
代碼圖由以下兩個部分組成：
- 節點（Nodes）表示代碼元素，如類、對象、活動；
- 邊（Edges）表示節點之間的關係，如關聯、繼承、依賴。
以組合關係的類圖爲例：
二、代碼可視化的好處
代碼可視化通過圖形化展示代碼結構和關係，團隊成員在軟件測試過程中使用代碼圖有着諸多好處，如改善彼此之間的溝通和協作、提高效率和專注度等。這有助軟件測試人員更快速迪理解代碼邏輯和關係，減少閱讀和理解代碼的時間成本。
1 改善溝通與協作
代碼圖的重要作用在於有助於縮小技術和非技術人員之間的差距。測試人員可以輕鬆地向經理、客戶或對代碼不熟悉的成員解釋代碼流程。
曾擔任西門子軟件工程師的Stelios Manioudakis以自身爲例，充分說明了代碼圖改善溝通與協作的作用。
在早期做軟件測試時，他曾參與了一個開發新健身追蹤器應用的項目。他們通過睡眠追蹤算法分析傳感器數據，來確定睡眠階段（淺睡眠、深睡眠）並生成睡眠報告。但在測試算法過程中，他們遇到了不少的困難，因爲非技術人員很難僅通過代碼來理解算法邏輯。
這時候，代碼圖就派上用場了。他們採用可視化算法流程以及不同傳感器讀數和睡眠模式計算的決策點，讓產品經理和UI設計通過代碼圖瞭解需要測試的潛在場景，例如不安穩的睡眠模式或缺失的傳感器數據。
除此之外，代碼圖還促進了與開發人員的協作。在代碼審查期間，測試人員和開發人員參考代碼圖可以更好識別預期邏輯和實際實現之間的潛在差異。最終，健身追蹤應用中的睡眠追蹤算法成功通過測試，代碼圖功不可沒。
2 提高效率和專注度
測試人員通過代碼圖能夠更高效地規劃、編寫和執行測試，減少重複性工作，從而提高測試覆蓋率和質量。
以新聞推送算法爲例，該算法根據用戶的興趣和互動情況，對用戶進行個性化推薦。最初，測試人員需要仔細逐行檢查代碼，這種既耗時又費力的方法很難確定所有潛在的測試場景。但代碼圖以一種直觀的方式將各個影響因素展示出來，例如用戶偏好、帖子互動和內容新鮮度。不僅如此，代碼圖還提供了清晰的決策點和分支路徑。
- 熱門話題：專注於測試在信息流中優先顯示熱門話題的場景，確保用戶不會錯過熱門內容。
- 個性化推薦：優先測試具有不同興趣和互動的不同用戶資料，以驗證算法是否準確推薦相關內容。
- 邊緣情況：突出顯示了潛在的邊緣情況，例如不活躍的用戶或互動有限的用戶。測試人員可以設計特定的測試用例，以確保算法不會在這些情況下發生故障。
顯而易見，使用代碼圖比逐行檢查代碼的方法快得多。這使測試人員能夠優先考慮算法的關鍵領域，確保全面測試，併爲用戶提供更可靠、更個性化的新聞推送體驗。
3 增強文檔可維護性
在代碼重構後或團隊新成員需要查看代碼時，文檔能夠幫助團隊成員更快地理解程序流程和潛在的測試要點。
舉個例子：某個電子商務平臺的庫存管理系統是多年前建立，如今維護變得越來越複雜，新功能也越來越難實現。在系統調整過程中，面對複雜的庫存管理邏輯，代碼圖將從產品添加、更新到訂單處理、庫存水平管理直觀地展示出來。
由此，測試人員能夠確保調整後的庫存管理系統得到高效維護，代碼圖其中的作用不言而喻。
- 溝通更清晰：使用代碼圖向團隊新成員解釋系統的功能。這些圖表與代碼註釋一起提供了清晰簡潔的概述，使其更快地掌握系統的邏輯和測試注意事項。
- 高效的代碼審查：在代碼審查期間，參考代碼圖和代碼註釋有助於儘早發現潛在問題。通過可視化更改對整體流程的影響，團隊可以確保修改不會對系統的其他部分產生意外的副作用。
- 面向未來的維護：隨着系統的發展和新功能的添加，代碼圖可作爲寶貴的參考點。即便是未參與過該項目的測試人員也可以輕鬆瞭解現有邏輯和潛在影響區域，從而實現更高效、更有針對性的測試工作。
4 及早發現問題
代碼圖能夠揭示純文本代碼審查中可能遺漏的問題，因爲越混亂的代碼圖表示代碼越複雜，這越容易出錯。
舉個例子，醫院的預約安排系統在更新過程中引入了一項新功能：允許患者在線重新安排預約。新功能在經過代碼審查和測試用例設計後，如果沒有發現重大問題即可投入使用。
然而，鑑於涉及處理衝突預約特定部分的複雜性，測試人員決定採用代碼圖進行進一步檢查和驗證。代碼圖展示了純文本審查中可能忽略的潛在問題：
- 多個決策點：基於各種因素（如現有預約、醫生空閒時間以及時間限制）的衆多決策點，由於測試期間難以考慮所有可能的情況，這種複雜的分支結構意味着更高的錯誤風險。
- 隱藏邏輯：圖表的複雜性質使得從視覺上理解代碼邏輯變得非常困難。這引發了人們對代碼中可能存在的隱藏條件或意外行爲的擔憂。
於是，測試人員根據代碼圖對新功能進行了重新調整：
- 優先測試：優先測試涉及衝突約會的場景。專注於可能暴露覆雜邏輯中潛在錯誤的邊緣情況和組合。
- 與開發人員協作：藉助可視化表示，測試人員與開發人員討論已發現的複雜性。此次協作促成了代碼重構工作，簡化了邏輯並降低了圈複雜度。
測試人員利用代碼圖能主動識別潛在問題，並與開發人員合作解決這些問題。由此，這能夠確保醫院預約安排系統的完善性與可靠性。
5 結構化編程連接
代碼圖與結構化編程的原則（序列、選擇和重複）無縫契合。這些基本結構直接映射到特定的圖形模式，從而簡化了對這些常見結構的測試。
（1） 簡化的測試設計： 結構化編程強調明確定義的結構，如序列、選擇（if-else）和重複（循環）。代碼圖將這些結構直接映射到特定模式：
- 序列：一條直線節點，表示一個語句接着另一個語句
- 選擇：具有單個入口節點、條件節點和兩個傳出邊（一個表示真，一個表示假）的分支結構，可導致單獨的語句序列
- 重複：具有入口節點、條件節點、返回條件節點的邊以及指向循環主體（語句序列）的邊的循環模式
（2） 更輕鬆地實現測試用例可視化：通過識別代碼圖中這些熟悉的模式，測試人員可以快速瞭解程序的流程和相應的測試用例。例如，圖中的循環模式表示需要測試用例覆蓋循環的各種迭代，包括邊界條件和預期行爲。
6 更多關於複雜性測量
循環數是基於代碼圖複雜度的度量，有助於評估程序測試的難度。複雜度越高（路徑越多），測試就越徹底。但讓我們深入瞭解更多細節。
- 循環數：該指標源自代碼圖的結構，用於估計程序中獨立執行路徑的數量。循環數越高，複雜度越高，這通常是由於嵌套循環、多個決策點或 GOTO 語句等因素造成的。
- 明智的測試規劃：循環數可作爲測試人員的指南，表明全面測試所需的工作量。與循環數較低的程序相比，循環數較高的程序需要更多測試用例來覆蓋所有潛在執行路徑。這有助於測試人員優先考慮工作，並確保全面覆蓋複雜部分。
這裏有一個簡單的例子，考慮一個具有兩個連續的 if-else 語句的簡單程序：
if condition1:
# statements for if condition1 is true
else:
if condition2:
# statements for if condition2 is true
else:
# statements for both conditions false
節點：
- 節點1：程序的起點，代表代碼執行的開始。
- 節點 2：決策節點condition1。此節點評估條件並根據結果（真或假）確定執行流程。
- 節點 3：如果爲真則執行的語句塊condition1。此節點表示 的“if”塊內的所有代碼condition1。
- 節點 4：與condition1相關聯的 "else "節點。該節點表示在不檢查condition2的情況下（即condition1爲假）的替代路徑。
- 節點 5：condition2的決策節點。此節點對條件進行評估，並根據結果（真或假）決定執行流程。
- 節點 6：condition2爲真時執行的語句塊。該節點表示condition2的 "if "代碼塊中的所有代碼。
- 節點 7：與之關聯的“else”節點condition2- 此節點表示程序的終點，表示如果condition1和condition2均爲假時執行的代碼。
邊：
- 邊 1：連接節點 1 和節點 2，表示從起點到第一個決策點的初始流
- 邊 2（真）：condition1連接節點 2 和節點 3，表示如果爲真則執行的流程
- 邊 3（假）：condition1連接節點 2 和節點 4，表示如果爲假則採用替代流
- 邊 4：連接節點 4 和節點 5，表示從“else”塊流向condition1第二個決策點
- 邊 5（真）：condition2連接節點 5 和節點 6，表示如果爲真則執行的流程
- 邊 6（假）：condition2連接節點 5 和節點 7，表示爲假時的端點
相應的代碼圖將具有包含三個決策點和多個執行路徑的分支結構。此圖的循環數爲 4（節點 - 邊 + 2）。與結構更簡單的程序相比，這表明邏輯可能更復雜，並且需要更多測試用例。
通過了解這些好處，軟件測試人員可以利用代碼圖來有效地導航程序邏輯，設計有效的測試用例，並有助於交付高質量的軟件。
讓我們詳細解釋一下如何得出圈數 4。
- 循環複雜度告訴我們程序中有多少條獨立路徑。路徑越多，測試就越複雜。
- 在此代碼中，我們有兩個決策（檢查condition1和condition2）。每個決策都會在路徑中創建一個潛在的分叉（真或假）。
- 但是，由於else的區塊condition1直接指向 的決策condition2，因此那裏沒有真正的分支。它就像一條通往另一個決策點的單行道。
- 因此，我們只計算獨立的決策點：初始點、condition1（對或錯）、condition2（對或錯）。
由於我們有 3 個決策點，但由於起點而加 1 是計算循環複雜度的常用方法，因此最終的數字是 3 + 1 = 4。
記住：
- 較高的圈複雜度並不一定意味着代碼不好，但它表明可能需要考慮更多測試場景。
- 由於複雜度爲 4，此代碼片段並不太複雜，但隨着判定數量和條件嵌套的增加，圈複雜度和測試工作量會顯著增加。
三、代碼圖的侷限性
雖然代碼圖具有改善溝通與協作、提高效率與專注度等優點，但測試人員還要需要注意以下事項：
1 無法執行元素
- 忽略註釋和聲明：代碼圖主要關注程序內的控制流，由可執行語句表示。註釋和數據聲明等無法執行元素通常會被忽略，因爲它們不會直接影響代碼執行。
- 可能造成誤解：雖然忽略這些元素可以簡化圖表，但可能會造成一些誤解。測試人員需要注意這些忽略掉的元素，並確保在測試過程考慮到它們，以避免忽略與數據初始化、邏輯註釋或其他不可執行代碼部分相關的潛在問題。
2 區分路徑可行性
- 識別有意義路徑的挑戰：代碼圖中的所有路徑並非都代表有效或有意義的執行序列。根據圖結構，某些路徑在技術上是可行的（拓撲上可行），但在程序邏輯的背景下是不合邏輯或無意義的（語義上不可行）。
- 增加測試工作量：確定並優先考慮可行的測試路徑可能具有挑戰性，需要測試人員付出更多努力。他們需要分析程序邏輯和上下文以區分有效路徑和無效路徑，這可能會導致額外的測試用例設計和執行時間。
3 緩解這些限制
- 與其他測試技術相結合：代碼圖與其他測試技術（如代碼審查或數據流分析）相結合時效果最佳。這些技術可以幫助識別不可執行元素及其潛在影響，同時還有助於理解程序的邏輯，從而更好地評估路徑的可行性。
- 關注關鍵路徑：測試人員可以優先測試代碼圖中的高風險或關鍵路徑。這涉及考慮循環條件、預期用戶輸入和潛在錯誤場景等因素，以確定對測試影響最大的路徑。
通過理解和解決這些限制，測試人員可以有效地利用代碼圖。在承認其固有的侷限性以及將其與其他測試方法相結合的必要性的同時，可以進行全面而高效的測試。
四、寫在最後
禪道軟件團隊自主研發的企業IM軟件中集成了開源應用draw.oi，將聊天和協同有機結合在一起，文中所有代碼圖均用此功能完成。通過利用代碼圖，軟件測試人員可以更深入地瞭解程序邏輯。他們可以設計更有效的測試用例，併爲交付高質量的軟件做出貢獻。
我們必須承認一點，隨着軟件格局的不斷髮展，代碼圖將繼續成爲確保應用程序的可靠性和穩健性的重要工具。
*參考資料：Stelios Maniooudakis 的 Code Graphs: A Guide for Testers