Designing Test Architecture and Framework


淺談軟體測試的階段與策略 提到過去因為需要自動化 Regression Test,然後設計、開發 Test Framework / Architecture 的經驗。最近也有人在問我怎麼做這件事情,重新整理一下這段經歷的分享,補充了一些資料。


Designing Test Architecture and Framework

單一的自動化測試難度不高,但是如果大量且要能夠團隊合作的 Test Architecture / Framework 複雜度就很高,我當時設計的 Test Framework 考慮以下面向:

角色 (Roles)

定義 SQA 團隊裡有哪一些角色:

  • Tester:負責手動釐清、驗證問題,確認問題的程序
  • Automation Developer:
    • 寫 Test Case 的人,負責這個 Test Case 本身的設計、開發、與測試
    • 也可以是 QA / QE
  • Automation Runner: 跑大量 Test Case 的人
    1. 架構部署與環境維護
    2. 測試環境準備、資源分配、準備 Config
    3. 負責每天跑大量的測試,通常是晚上跑,稱為 overnight
    4. 負責調整 overnight 所需要的配置與資源。
    5. Review 報表
  • SDET: 開發、維護 Test Framework and Test Libraries 的人
    • 架構設計與開發
    • Framework 開發與測試
    • 共用 Library 開發
    • 報表產生器
    • 資源管理
    • 環境建置

實務上,因為資源的限制或者現場的狀況, Tester / QA / QE 可能是同一個人,Runner / SDET 是同一個人。

測試架構 - SDET

底下這張圖是當時在自己家裡的白板手繪的概念圖,現在看起來有些東西表達詞不達意,但是概念是可行的 XD

圖中概念說明:

  • Box:待測產品,那時候測的是 Firewall 產品的 Firmware
  • LabPC:執行測試程式的機器
  • Backend: 產品本身需要跟很多 Backend 整合才能用,像是 DB2、MQ、WAS (Websphere Application Server)
  • SMGR: 負責管理、分配測試資源的節點

測試程式的開發與測試 - Automation Developer

  • 單一 Test case 的開發流程與流程控制: tester 寫 test case 如何在自己的環境開發與測試
  • Test Suite 的管理與結構: 如何跑整個 test suites,test suites 本身的設定檔
  • 如何 Debug 自己開發出來的測試程式?然後如何整合到每天要跑的環境?
  • 模擬程式的設計:有些測試程式需要製造一些特殊條件,像是 disk 滿了、CPU 80%、memory 沒了之類的 …
    • 我設計由 Framework 提供這些功能,tester 只要透過參數就可以達到想要的功能即可。

部署與環境 - Automation Runner

每次跑大量測試之前,都要先 Allocate 對應資源,確認環境是否乾淨。

  • 環境建置準備:
    • 把環境弄到最乾淨,以 AWS 來說就是起一個乾淨的 Instance
    • 用 Container 相關技術,像是 Docker-Compose、K8s …
  • 測試資料準備:
    • 每個 test case 都會有個別的測試資料,用來製造測試情境
    • 測試資料的分類
  • 待測程式的部署或者安裝:
    • 這些東西統稱 artifacts, 建議包含以下資訊:Version Number, Change ID (hash code, serial no), BuildID (通常是時間, 像是 YYYYmmDD-HHMM), branch …
    • 從 build machine or S3 抓下最新的 build,安裝好後,把 test case 需要用的設定檔設定好

相關參閱:

每天晚上跑大量的測試 - Automation Runner

測試程式一多,就需要管理、跑的時候要有彈性,所以 Test Runner 的設計有以下要考慮:

  • 跑單一 testcase, 跟跑數個 suites 的設定檔, 然後可以個別指定設定檔, 或者 overwrite 每個 testcase 的設定檔
  • 測試排程控制 (分散式):
    • 如何同時跑多個 test case?
    • 排隊或者平行?
    • test case runtime 在哪一台機器跑?
    • 如果 test case 跑太久怎麼辦?這裡我設計了 duration 機制,也就是 tester 必須指定每個 test case 最長的執行時間,超過 test runner 就會把 thread 砍掉,並且執行 cleanup,把環境還原,把測試標記失敗。
  • 額外的測試條件 Callback: 跑大量 test suite 時,可以同時跑其他的東西製造測試情境
  • 測試結果的 Log 與報表
    • Log 分成給 tester 看得、Framework Library Design 看的,還有 Framework Developer 看得。
    • 每個 testcase 都有 owner, 報表每天會自動寄給 owner
  • Rerun 機制
    • 每次跑大量的 test suites 產生報表的同時,會同時產生另一個 runner 的設定檔,只要 reviewer 看過覺得需要重跑,按下 rerun 就可以自動化重跑
  • 資源監視與管理
    • 待側機器的資源狀況,主要有 CPU / Memory / Disk 狀況
    • 哪一些資源現在已經被使用,可能是人、也可能是被機器要走了

Test “Test Framework” - SDET

整個 Test Framework 自己的 Unit Test 以及 Libraries 都是透過自己測自己的方式實作,也就是自己的 Libraries 也會產生測試報表,每次加功能之前,都會用自己測自己 (當時我還不知道那叫 TDD)。

這樣的想法是以前學 Java 時,聽學校老師說 Java Compiler 用什麼寫?當然是用 Java 寫囉!當時還不懂,後來就懂了。

Dynamic Config - SDET

為了讓測試流程更有彈性,所以參考物件導向的概念,設計了類似繼承、Annotiation 概念的配置檔,這也是整個 Framework 的核心架構,相關設計隨筆參考:Talk about compiler and parser


老人談當年勇

下面是以前我設計 Test Framework for Regression 時規劃的流程與設計 (System Level Design),摘錄一些當時簡報的圖檔與心得。

這一整套 Test Framework 是設計給一個團隊使用,裡面包含了協作、資源系統、報告、教育訓練、完整的文件手冊、範例程式碼、設計文件 … 等,當時一直想把他商品化,可惜並沒有機會。 (老了,要開始提當年勇了 XD)

Workflow / Architecture

這張圖是大的測試流程圖,包含準備、自動更新 Firmware、Sequence / Parallel 的 Test Case 執行程序、以及 Log and Report。

說明如下:

  • 橘色:準備工作,確認待測項目與資源是否足夠。這裡有一段演算法是要先計算待測 Suites 總共需要哪一些資源,然後跟 Resource Management 詢問現在有多少資源,能否執行。
  • 藍色:待測目標,可以想像成部署概念,也就是測試都會自動重新部署帶測版本,這也就是 導入 CI/CD 的第一步 提到的概念。
  • 紅色:各個不同的 Compoments 的測試案例集合 (Test Suites),執行方式有循序 (Sequence) 或者平行 (Parallel)
  • 綠色:執行結果產生報表,包含每個測試的執行資訊、負責人、Log,Rerun 的方式等。

Test Case Management

Test Cases / Test Suites 的目錄結構設計,參考 Java package 概念。而且 Suites 和 Test case 的設定檔具有繼承、annotation、branch 概念。branch 概念就是說屬於特定版本的設定,可以建立新的 設定檔,附加版本號碼,Framework 只要找到這樣的檔案,就會自動 overwrite 相關設定。

Test Case 的目錄結構設計,參考 Java package 概念。

核心概念有兩個:

  • Testcase 的 Config Management:有 Global、Suite Level、Testcase Level、Version Level 四個層級,這四個層級是繼承架構
  • Testcase 的 Package Management:類似於 Java Package 的設計,執行 Runner 支援 wildcard 指定特地的 Package 全部,或者 exclude 特定的 Testcases.
  • 類似 Branch 的概念,在 Ansible 裡也有。
  • 這裡我實作了一個簡單的 parser,parse 每個 testcase 設定檔的相關需求,包含繼承、annotation、branch 等概念,實作內容包含基本的 syntax check、abstract structure tree (AST) 等,如果 syntax error 會吐出 error code, 同時指出哪一行錯誤。最後在 runtime 變成一個 data model 給 test runner 使用。在 Talk about compiler and parser 有簡單的描述。

Test Case 標準程序

每一個 Test Case 都有這樣的標準程序,分成五個:

  1. Pre-Procedure: 由 Framework 控制,通常是環境檢查,像是檢查 Config 合法性、 HTTP / Storage Server 等共用資源
  2. Setup: 測試準備工作,通常是初始化資料,由 Tester 自行設計
  3. Test: 主要的測試程序在這裡
  4. Cleanup: 清理測試資料與環境,由 Tester 自行設計
  5. Post-Procedure: 由 Framework 控制,自動處理後續不必要的程序,或者是從待測目標下載所有 Log / backtrace。

從上述中提及分成 Framework Level 和 User Level:

  • Framework Level 根產品的特殊性有關係,產品相關的共用程序都封裝在 Framework 層,這層由 SDET 負責
  • User Level 則是給 SQA 開發 Test Case 使用。

程序的設計,有 Framework Level 和 User Level

中間有一些 function,像是 Raise CPU, Memory Up,是由 Framework 控制。Tester 在開發 Test Case 時,只要透過開關開啟就可以了。

Test Case Lifecycle Controller

每個 Testcase 都有自己的 Config,有一些生命週期有關的設定,像是:

  • 每個 Testcase 再跑時,只能跑多久?
  • 每個 Testcase 是否有特殊需求?例如只能跑在哪一些硬體機型?
  • 如果失敗了要重跑?

執行報表

這是執行後給 Testcase owner 的測試報告,列出 owner 每個 test case 的執行結果與 Log.

這個報表內容主要是給負責 Testcase 的人,包含跑在哪一個環境、測試的 版本資訊、相關的 Testsuites / Testcases 、每個測試執行的時間、跑在哪、成功率、Log … 等。

資源管理 (Admin Console)

這個 Framework 是分散式架構,所有很多機器要管 (大概兩櫃) 的機器要管理,測試時必須要去配製這些資源。這張圖是測試資源的管理,Framework 會依據資源狀況,自動分配 Job。用 ZK 實作的。

待測機器管理
Backend Servers 管理

這個 Console 呈現這些資訊:

  • 每台機器是誰在使用:團隊很多人,所以避免資源競爭。
  • 待測資源資訊:包含 FW 版本、CPU、Memory、IP … 等
  • 執行測試 Node 資訊:包含 FW 版本、CPU、Memory、IP、OS … 等
  • Build: 每天自動從米國 Mirror 回來的 Artifacts

我在 軟體自動化測試常見的問題 中問題到的描述,就是這段實作過程的經歷。

實作技術

整套系統大概使用以下技術實作:

  • Server: RedHat (RHEL), Ubuntu, Windows Server 2003
  • Programming Language: Java, Python (jython), Bash,
  • Auto Test Infrastructure: STAF, STAX
  • ZK: Web Framework
  • Database: MySQL

結論

這個架構的設計包含以下概念:

  1. 訊息佇列 (Message Queue):儲存工作進度與佇列
  2. 工作流程 (Workflow): 主要的流程控制器、輸出輸入處理、異常處理、執行單元 (Testcase Runner) … 等
  3. 批次工作 (BatchJob):負責執行運算的運算單元。
  4. 資源分配策略: 為了讓資源更有效地利用,所需要的資源分配策略。

這段設計,算是我個人成長最多的時間,也是思考最多的架構設計的,即使已經十年了,還是記憶深刻。


延伸閱讀 (站內)



Comments

2018/05/12 11:08:00





  • 全站索引
  • 關於這裏
  • 關於作者
  • 學習法則
  • 思考本質
  • 一些領悟
  • 分類哲學
  • ▲ TOP ▲