测试操作一个敏捷连贯的设计与测试蓝图 (3)
頁數 1如需聯絡我們,請上網查詢 白皮書 TestOps 宣言 互連和敏捷設計與測試的藍圖 在 2001 年,17 名軟體工程師聚集在美國猶他州的雪鳥渡假村。那一天,他們共同 起草了敏捷軟體開發宣言,並從此顛覆軟體的開發方式。二十年後,電子設計和測 試正在經歷類似的轉變。這帶來的好處很深遠。採用 DevOps 工作流程的企業證實, 工程師的生產效率獲得 29 的提升。TestOps 是 DevOps 針對設計與測試方面的 應用,自然保有同樣的優點。 互連和敏捷設計與測試 互連和敏捷設計與測試,是電子系統開發方法的轉型。它結合了新軟體、新的工作 流程和強大的自動化工具,藉此改變傳統開發流程,大幅提高生產率和設備利用 率。此方法將從各公司彼此孤立的設計和測試步驟,轉變成敏捷且相互連結的工 作流程。這正反映了敏捷軟體設計和 DevOps 的優點加速裝置設計,將設計參數 轉變為測試要求,迅速執行測試並獲取結果與進行驗證。與自動化相結合後,全新 的開發文化 TestOps 於焉誕生。 在本 TestOps 宣言中, 我們會介紹 TestOps 的 願景,探討如何改進設 計和測試工作流程,並 歸納出互連和敏捷設計 與測試的五個重要原 則。掌握這些資訊,是 有效實現這個全新方法 的潛力和優勢的首要關 鍵。 頁數 2如需聯絡我們,請上網查詢 在本 TestOps 宣言中,我們會介紹 TestOps 的願景,探討如何改進設計和測試工作流 程,並歸納出互連和敏捷設計與測試的五個重要原則。掌握這些資訊,是有效實現這個全 新方法的潛力和優勢的首要關鍵。 TestOps 願景相互連結的工作流程 電子設計在過去的 30 年出現數次的飛躍式進展。第一代電子設計自動化(EDA)軟體, 與手動電路模擬和單晶電路設計基元(primitive)相結合。如今它已被多層設計軟體、虛 擬原型設計和模擬,及可複用的模組化電路元件所取代。這類似於敏捷軟體設計方法所 實現的技術改進。 但是,有別於現代軟體工作流程,現代硬體的建構、測試和部署階段,絕大部分是和設 計階段分開進行。事實上,許多工程師認為設計和測試之間的脫節,是影響專案延遲和產 品交期的最大因素。 這些延誤最常見的原因,是由於孤立的工具集和工作流程所致。後期設計階段通常是在不 同的實驗室進行,彼此之間跨越好幾個時區。這些工具是互相獨立的,只能靠手動流程、 實驗室筆記、Excel 工作表和人工中介軟體(human middleware)來建立連結。因而也容 易發生人為失誤。 尋找更好的方式 顯然地,工程師必須找尋更為理想的現代電子系統開發流程。 幸好,TestOps 提供了解 決方案。有鑑於此,敏捷宣言提出的第一項重要原則是,我們的首要任務,是透過 早期與持續交付有價值的軟體來滿足客戶要求。TestOps 宣言的第一個原則也類似 於此我們的首要任務是透過敏捷和最佳化的設計與測試方法,盡快提供高品質的產 品。 需要說明的是,TestOps 並不是一項新技術,而是一種新的工作方式。它需要全新並持續 更新的軟體、新的工作流程及將這些工作流程自動化的適當工具,同時支援即時的數位資 訊交換。這些工具是實現互連和自動化流程的基礎,可促進各產品開發階段的資料交換, 最終達成高速有效的敏捷軟體開發。 頁數 3如需聯絡我們,請上網查詢 TestOps用於設計和測試的自動化 DevOps 敏捷宣言的第二項原則是非常歡迎不斷變化的要求,即便是在開發階段的後期。敏捷 流程利用變化來保持客戶的競爭優勢。TestOps 宣言的第二個原則也很類似採用敏 捷開發方法,縮短產品上市時間,達成整個研發生命週期中的競爭優勢。 熟悉 EDA 軟體歷史和發展的人,非常了解電路設計工具所提供的功能,對於敏捷硬體設 計的重要性。現在,我們已能將原始設計完整連結到設計與測試的後期階段,並從原型設 計連結到製造生產。 敏捷軟體開發的概念在 2001 年就被提出,但一直到 2009 年 DevOps 才正式問世。兩名 Flickr 員工 John Allspaw 和 Paul Hammond 提出 DevOps 的想法。透過這個環境,將敏 捷軟體開發和維運,導入無縫、透明、完全整合的工作流程之中。TestOps 宣言進一步提 出,將眾所周知的 DevOps 策略延伸到工程設計和測試工作流程。 要實現 TestOps 環境,便必須改變開發流程、工具和文化。利用適當的工具和流程,可在 三個關鍵領域獲得長足進步 縮短工程開發時間減少建立和校驗開發與生產測試指令程式所花費的時間。 增進設備利用率加快配置修改速度,增加測試指令程式的可複用性,並透過測試序 列資料分析結果進行程式改進,藉此提高設備利用率。 增進量測速率透過高速資料擷取、資料處理和邊限分析來提高量測速率。 測試合作 頁數 4如需聯絡我們,請上網查詢 互連和敏捷設計與測試的原則 實現互連和敏捷設計與測試,有五項重要的原則。這些包括 1. 通用資料交換和資料管理 TestOps 工作流程的基礎,是一種在工作流程中和不同工具和人員之間擷取並交換資 料的方法。內容可能包含模擬波形檔、測試指令程式和參數、配置資訊、目標設計 性能參數等,當然還有測試結果,以及通過/不通過條件的邊限和臨界值分析。 工作流程工具需能夠開放並讀取這些工具,以使測試設備和終端使用者之間產生有 意義的交互作用。理想情況下,這些工具還可將傳統的類比人類行為(例如手動轉 移筆記)轉換成該操作員的數位工作流程。這包括指令程式修訂註釋、測試演算法 或測試過程假設等細節,以及與測試方法和操作相關的觀察細節資訊。 有效的資料交換,對於縮短設計週期也至為關鍵。在 TestOps 的工作流程中,具 備以軟體執行本地交換和建立資料關聯性的能力,將可使整體設計時間大幅縮短。 2. 開放 API 和開源自動化工具 通用資料交換和資料管理從一組應用軟體程控介面(API)開始,這些介面支援多個 軟體元件(包括供應商提供和自家軟體)之間的資料交換。用於資料交換的開放式、 可延伸格式(例如 XML 或 JSON)可在測試和工具出現時執行快速自調適。 透過開源的方式,可提供快速原型設計和最佳化的機會,同時也能利用生態系統中 各個產業合作夥伴所提供的最佳元件。公司可藉由採用基於標準的開放式測試和量 測程式庫來改造自家的傳統測試套件。藉此,他們可獲得頂尖的量測科學,世界級 的測試程式庫,和可擴展的雲端軟體架構。 3. 頂尖的量測科學 每部電子裝置都必須通過若干相符性和電磁干擾(EMI)測試。大多數裝置都需通過 更嚴格的標準相符性測試,來保證其互通性。從記憶體和處理器匯流排,到無線通 訊和汽車網路,幾乎每個裝置都必須通過一個或多個產業標準規範的相符性測試。 產業標準會持續不斷地演進和發展。為了提供頂尖的量測科學,測試環境需能支援 並實施最新標準。此環境應能在適當的測試硬體上 根據是德科技最近的一 項調查1顯示,10 間公 司中有 9 家透露手動建 立資料關聯性需花費數 個月不等的時間。 今天,企業每週平均 花 2 小時以上開發編碼 解決方案,以確保測試 流程的穩定運作和資料 流。 1 若使用開放和可 複用的元件,這些時間 便能用來執行測試效率 最佳化。 頁數 5如需聯絡我們,請上網查詢 無縫部署這些測試套件。同樣重要的是,測試結果應在儲存時記錄其根據的是哪個特 定版本的標準。這可確保測試的準確性,特別是在產業標準尚未完成,還在快速變 化,又需要搶先入市的早期階段。 透過在設計、模擬和測試階段各步驟重複使用相同的最佳化演算法,可減少建立資料 關聯所需的時間,並進一步縮減將手動確認移動到自動化工作流程中的時間。了解用 於建立測試波形和模擬的演算法,有助於與真實世界的量測結果自動產生關聯性。只 有在測試和量測平台共享共同的量測科學時,才能實現這種程度的整合。 透過這樣的整合平台,建立更高效的工作流程,並將正確的工具結合在一起。在設 計、模擬和驗證階段之間保持一致、準確且整合的量測科學對於加速產品設計至關 重要。 4. 可擴展的隨處運行架構 隨著設計複雜性的提升,設計週期中的各階段所需的時間也會增加。要建立出第一個 原型,需花數百甚至數千個小時的模擬,才能進入產品設計階段。隨著製造商將更多 技術整合到每個裝置中,需要的協定相符性和共存性測試案例變得更多,因此用於原 型