什么是可測試性需求(DFT)?


深圳市共創力資深顧問 楊學明/文

     由於市場及產品用戶對產品質量的要求越來越高,  各大企業加強了對產品可測試性需求的收集和控制,本文用於指導TSE及系統設計人員進行可測試性需求分析活動。

     目前可測性需求一般有以下幾方面的考慮:

1、面向產品的可測性需求,是為了提高產品的故障檢測定位和隔離能力而考慮的可測性需求,直接影響產品問題故障檢測定位和隔離的難易程度。面向產品的可測性需求在評審通過后將作為產品本身的規格特性。

2、面向軟件驗證測試的可測性需求,是為了方便軟件驗證測試而提出的可測性需求,直接影響測試開發和測試執行的難易程度。

3、面向硬件驗證測試的可測性需求,是為了方便硬件驗證測試而提出的可測性需求,直接影響測試開發和測試執行的難易程度。

4、面向生產測試的可測性需求,是為了方便生產測試,提高生產測試效率而提出的可測性需求。面向生產測試的可測性需求參見《概念階段確定可制造性需求指南》相應內容。


                                      如何提出可測試性需求?


       目前很多公司已經發布了各產品線的可測性需求基線(工程特性需求基線之可測性部分),該需求基線是公司多年來已有可測性經驗總結提煉的成果,而且還將不斷優化和完善,所以需求基線可以覆蓋產品的大部分可測性需求。因此具體產品開發時可測性需求的提出一般按以下操作:

1、產品在提可測性需求時首先參照相應可測性需求基線剪裁得到具體產品的需求基線。相應的要求參見可測性需求基線實施規定。

2、結合具體產品的特點,充分考慮產品各階段測試的可能遇到的問題和困難,提出相應的可測性需求。

3、參考相關產品的可測性方面的經驗案例,提出相應的可測性需求。

4、分析參考業界同類產品的可測性設計特點,提出相應的可測性需求。


                                  可測試性需求提出的步驟


1、產品測試需求和策略初步考慮

哪些測試是手動測試、哪些是自動測試?

測試數據源是內置在系統中,還是外部提供?

測試數據的采集和處理是內置,還是外置?

測試數據采集裝置的控制是內置,還是外置?

測試數據源的控制是內置,還是外置?

測試數據的處理是內置,還是外置?

2、產品測試各階段的可測試性需求

根據測試需求和策略(如具有內置要求的測試),通過對具體產品特點的分析、內部訪談、參考公司內部經驗案例並分析調研業界同類產品,提出可測試性需求。

產品各階段的可測性需求內容應該包括以下幾個方面的內容:

  •     硬件模塊和部件調試和測試的可測性需求

關注點在於能否提供方便的調試手段和支持調試測試的工具接口,支持模塊和部件的單獨調試和測試,主要考慮以下幾個方面

(1)提供支持模塊獨立運行必要的信號輸入和輸出接口數據。

(2)提供信號和數據流的自環和自給設計

(3)提供模塊和部件的離線加載功能

(4)提供模塊和部件的自測試設計

(5)提供測試儀器和工具的測試接口或兼容性設計。

(6)提供直觀的調試結果信息上報監控  

      例如:產品設計了一塊業務板,但需要時鍾板提供時鍾才能正常工作,而提供時鍾的單板也要調試,無法支持本單板的調試,這樣為了調試這塊單板就需要考慮時鍾源的設計,可能我們需要在板內提供一個晶振,或者利用鎖相環的壓控晶振分壓設置提供時鍾,以支持單板的獨立調試。另外為了調試單板業務是否正常,必要的環回必須要支持,數據源需要有相應的設計考慮,

  • 軟件模塊的調試和測試中的可測性需求

     關注點主要在於按設置測試控制序列、狀態觀測點和輸入輸出機制的需求,主要考慮以下幾個方面的內容:

(1)提供軟件模塊調試測試的能控性設計,能通過輸入設定的測試序列使系統處於某種特定的狀態或滿足某種特定條件的狀態。主要考慮軟件模塊的調試測試控制點的選擇和測試序列導入機制的設計。

(2)提供軟件模塊調試測試的能觀性設計,能夠通過系統的輸出數據判定系統是否處於某種特定的狀態或滿足某種特定條件的狀態。主要考慮軟件模塊的調試測試觀察點的選擇和觀察裝置的設計。

(3)軟件可測試性需求分為內建、公共、產品特性等三類,內建測試能力與公共可測試性需求合入產品包需求,在確定設計需求時,對具體產品特性需求分析的基礎上,提出相應的特性可測試性需求。三類需求分別說明如下:

      特性可測試性需求。針對產品具體特性測試的方便性提出的需求,它們與特性緊密相關,以特性樹的方式組織;

      公共可測試性需求,例如:OS中內存管理這些更具有公共性的部分。它們叫做公共可測試性需求。也是以特性樹的方式組織。例如:內存管理特性、隊列特性等等;

      內建測試能力需求。它是最具有公用性的部分它們叫做內建測試能力可測試性需求。它描述了產品應該具有的支持測試能力的需求。如:跟蹤機制需求、測試接口需求等。這些需求的被實現,可以有力的支持前兩類需求的實現。例如:我們實現了跟蹤機制,就能更好的實現第一類和第二類中的哪些跟蹤需求。它們都需要調用這里提供的機制來真正的完成跟蹤。

     本部分需求主要來源於測試策略、經驗總結以及內部訪談和調研分析。軟件可測試性需求的分析詳細過程與方法,參見測試部相關支撐流程。

  • 系統聯調中的可測性需求

需求的關注點主要是能夠提供一些手段,這些手段是可以暴露問題、發現問題、定位問題產生原因,解決問題、以及驗證解決效果的測試手段,主要考慮以下幾個方面的內容

(1)測試數據源設計

(2)業務和控制數據流的監控和變更設計

(3)子系統和模塊的故障分段環回及定位設計

(4)子系統和模塊的自測試設計

(5)測試儀器和工具的測試接口或兼容性設計

(6)測試結果的記錄、分析和結果上報設計

例如:系統聯調中如何區分不同單板、不同模塊之間的故障,出了故障后問題是出在這個單板/模塊還是出在與之接口的那個單板/模塊,是我們經常遇到的一個問題。需要考慮相應設計支持問題的分段/分層定位。

  • 系統驗證測試中的可測性需求

     系統驗證測試是驗證產品各種指標性能是否達到設計要求,在不同環境下的指標容限如何,包括指標/接口層測試、功能/性能層測試、子系統/模塊層測試、應用層測試、用戶層測試,其關注點主要在於系統驗證測試各種測試項目能否實現、實現是否方便、出現問題是否可以定位。主要考慮以下幾個方面的內容:

(1)系統業務功能測試的可實現性和方便性

(2)性能指標測試與瓶頸定位的可實現性和方便性

(3)系統告警功能驗證測試的可實現性和方便性

(4)系統容限/容錯/極限性能測試的可實現性和方便性

(5)協議跟蹤與驗證測試的可實現性和方便性。

例如:針對系統驗證測試中測試工作量比較大、重復次數較多的問題,往往需要考慮對自動測試的支持,提供自動統計功能或者相應的函數接口,便於自動測試設計和執行。對於異常容錯測試往往需要考慮相應的硬件接口或函數接口支持。有時候接口指標測試時需要考慮測試儀器輔助信號的設計,提供測試儀器所需要的時鍾等信號接口供測試儀器使用。

  • 整機安裝后的上電自測試可測性需求

     整機安裝后的上電自測試主要是用於驗證整機系統的配置正確性、子系統和部件的有效性,以及驗證系統的完備性、數據配置的正確性,這里的可測性需求關注點在於如何提高測試自動化程度、縮短測試時間、如何提高測試的故障覆蓋率、減少漏測率。主要考慮以下幾個方面的內容:

(1)測試數據源設計

(2)業務通路用外部程序控制的設計

(3)業務通路的環回及故障定位設計

(4)各單板自檢測試設計

(5)數據自動配置工具設計

(6)運行狀態監控及測試結果的記錄、分析和上報設計

例如:整機測試的自動化對生產效率提高非常重要,所以一般需要提供整機安裝后自測試功能,包括提供各單板的自檢測試,系統業務通路的遍歷自測試設計支持等等,自測試的問題定位應該盡量定位到板級,而且測試用的數據源應該盡量采用內置設計,避免試用昂貴的外部儀器。

本部分其可測性需求主要來源於測試策略、經驗總結以及內部訪談和調研分析。

  • 在線例行測試的可測性需求

      在線例測用於實現定時對系統的功能和關鍵性能進行檢測,確保系統和部件運行的正確性。單板更換、軟件升級與配置數據變更之后進行系統功能性能的測試,驗證變更后系統的正確性。

主要考慮以下幾個方面的內容:

(1)測試數據源設計

(2)通道的分層逐段環回設計+

(3)單板硬件(芯片)的在線測試設計

(4)測試監控及測試結果的記錄、分析和上報設計

例如:提供例測命令,實現對設備的全面在線測試,包括例測啟動設置、例測模式范圍選擇、例測結果記錄上報、例測故障診斷定位等。

本部分可測性需求主要來源於測試策略、經驗總結以及內部訪談和調研分析。

  • 單板和部件故障診斷測試的可測性需求

   單板和部件的故障診斷測試關注點主要是如何提高故障定位的有效性、准確性,方便性。主要考慮以下幾個方面的內容:

(1)單板和部件的獨立運行設計

(2)通道的分層自環與環回診斷設計

(3)單板硬件初始化及自檢診斷設計

(4)測試儀器和測試工具的兼容性設計

(5)故障診斷樹及故障定位到芯片級的診斷設計考慮

(6)診斷測試監控及測試結果的記錄、分析和上報設計

例如:在現場定位時我們系統的故障怎么定位到一塊單板,在維修測試怎么定位到一個芯片是我們經常面對的一個問題,需要我們在設計初期進行充分的可測性分析,並提供足夠的可測性設計支持,以及考慮提供故障自動診斷設計。

本部分其可測性需求主要來源於測試策略、經驗總結以及內部訪談和調研分析。

     對以上各方面的可測性設計需求進行統計和總結,完成以下可測性需求列表,該過程中主要完成重復需求的合並,並結合業界先進和歷史經驗對需求列表進行分析,對優先級別高的需求重點說明,給出需求的排序。


                          誰來主導可測試性需求分析?


      TSE(測試系統工程師)是可測試性需求分析的主要責任人,其它各個模塊的測試組長協助TSE建立可測試性需求基線(如軟件、硬件、結構等)。如果需要了解TSE的角色與職責,請參考另一篇文章。

      什么是測試系統工程師(TSE)? https://www.cnblogs.com/mikeyond/p/11604611.html

作者簡介:

楊學明  清華大學MBA,深圳市共創力企業管理咨詢有限公司總經理,深圳市匯成研發管理咨詢有限公司董事長,資深研發管理專家,國內首席研發管理專家,曾服務於華為,阿里巴巴等知名企業,楊老師先后在國內開設研發類公開課100多場,服務內訓客戶1000多家,為數百家企業提供了研發咨詢服務,典型的客戶如深圳邁瑞、華立儀表、步步高、英威騰、雷賽智能、埃斯頓、華工科技、中國科學院、電力科學研究院、中國工商銀行、重郵信科、從興電子、浙大網新、聯迪商用等。近兩年服務的客戶如中電海康、網易、蘇寧雲商、烽火科技、29所、華為技術、中興通訊、廣聯達、大唐電力、招商局、京信通信、航盛電子、國電南瑞、中航工業、維力醫療、寒武紀科技、海南郵政、京儀股份、海爾集團等。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM