<strike id="0k9r3"><p id="0k9r3"></p></strike>
  • <form id="0k9r3"></form>
    <nav id="0k9r3"></nav>
    <em id="0k9r3"><p id="0k9r3"></p></em>
  • <tr id="0k9r3"><source id="0k9r3"></source></tr>
    <form id="0k9r3"></form>
    <sub id="0k9r3"></sub>

      <sub id="0k9r3"><address id="0k9r3"></address></sub>
      1. <form id="0k9r3"></form>

        24小時聯系電話:18217114652、13661815404

        中文

        您當前的位置:
        首頁>
        電子資訊>
        技術專題>
        自動化硬件在環測試的...

        技術專題

        自動化硬件在環測試的低成本解決方案


        自動化硬件在環測試的低成本解決方案

        在當今快節奏的世界中,電子產品的迭代以閃電般的速度旋轉,我們經常忘記開發中最關鍵的方面之一:測試??偸呛苋菀缀雎詼y試,因為它是阻止我們發布產品的最后階段。在產品開發中,我們不斷發現自己處于足夠好經過詳盡測試的陣營中。這種情況通常會發生,因為我們沒有時間進行測試、重新測試,然后再進行更多測試。

        手動測試與自動測試

        在行業中,擁有自動化測試設置(主要用于生產級測試)是很常見的。然而,對于產品開發來說,這并不常見。如上所述,設置復雜的自動化測試設備的成本和開發時間需要高水平的努力。這種類型的成本和努力僅適用于具有非常復雜測試配置的大批量或小批量生產(例如,要進行多次環境測試的小批量航天器系統)。對于世界其他地方,我們求助于基本的、乏味的手動測試。這種測試可以包括ADC/DAC驗證、協議檢查、功耗測試等。不管測試類型如何,希望只需要做一兩次,然后就可以翻墻了到測試組。

        意外后果和自動化

        現實情況是,在我們的開發過程中,無論是在硬件設計/重新設計階段,還是在嵌入式軟件開發階段,我們都會無意中造成一些問題。一些示例可能是跨焊盤的焊橋或驅動程序代碼滲入其他驅動程序代碼可能導致某些內容損壞。不管結果如何,很明顯,測試不會只發生一次或兩次。問題出現了,在船上進行第十次返工后,詳盡的測試通常會太累而無法執行。這個問題的顯而易見的答案是讓自動化系統執行詳盡的回歸測試。但是對于沒有錢和時間來開發詳盡的自動化測試系統的嵌入式工程師來說,有什么解決方案呢?

        廉價的解決方案

        對于嵌入式系統,有一個低成本但非??蓴U展和實用的自動化測試解決方案。雖然它并不完美,但它將為設計工程師提供最高的投資回報。這個概念是使用一個簡單的設備來驅動模擬信號、讀取模擬信號、生成各種協議串行流和分析波形。

        運行示例

        讓我們考慮一個可以在此存儲庫中找到的真實示例。為簡單起見,我們的嵌入式目標將是Arduino Du o。以下是我們完整的測試設置:

        1:測試硬件配置

        2Analog Discovery 2 Arduino Duo 一起使用

        這里的想法是為了證明:

        主機命令 Analog Discovery 2 驅動模擬信號到 Arduino

        Arduino 讀取并存儲 ADC

        主機通過 UART (USB) 接收 ADC

        主機驗證通過 Analog Discovery 2 發送的內容與 Arduino 發送的遙測數據相匹配

        為什么我們要自動化這樣的事情?假設我們在 ADC 附近返工了一塊電路板,或者有人更改了與 ADC 接口的驅動程序。我們是否 100% 確信在電源上打開幾個旋鈕的簡單手動 ADC 讀數足以測試我們的硬件/軟件?如果沒有,為什么不讓自動化覆蓋每一個排列和每一個角落情況,這樣我們就不必這樣做了?只是為了更好的衡量,為什么不將同一件事運行 100 ……僅僅因為我們可以!這可能會變得更加復雜和復雜(例如,協議測試、ADC 過濾測試等),但本文將只介紹基礎知識。

        該測試紙條t是非?;镜?。假設您的 Arduino(即被測嵌入式設備)已加載了正確的編程文件并且一切都已正確連接,您將在您的計算機上運行測試腳本,如下所示:

        python -m pytest test_arduino_hil.py

        這將觸發 Analog Discovery 2 掃描 Arduino ADC 的電壓范圍,并驗證輸入電壓是否與從 ADC 讀取的輸出電壓相匹配。該腳本不是使用臺式電源手動清掃,而是通過一個命令為您完成。對于這樣一個簡單的例子,似乎沒有必要,但是當以類似回歸的方式組合測試時,這個過程會帶來好處。
        將其與我們的 CI/CD 系統相結合,我們可以看到以下階段正在運行和通過:

        3Gitlab 中的 CI/CD 階段

        上圖的階段是:

        docker_build:搭建環境。在這種情況下,我們在 Linux PC 和基于 ARM 的設備(例如 Raspberry Pis)上使用 docker 映像

        arduino_load_test:編譯并加載了Arduino的代碼和驗證一切工作。

        arduino_hil_test:在物理 Arduino 上運行硬件循環測試。

        如果我們仔細查看測試部分,我們可以看到這些測試是由 Gitlab 捕獲和解析的:

        4Gitlab 中的 CI/CD 測試

        5Gitlab 中的硬件在環測試結果

        我們現在有一個軟件設置,允許我們在本地和遠程(使用我們的 CI/CD 系統)測試我們的設計。這使設計工程師能夠繼續專注于設計而不是測試和調試。

        在本文中,我們回顧了使用自動化測試同時和事后驗證設計的概念。無論是小的返工還是重大的設計更改,在排除意外后果(即修復一件事,破壞另一件事)時,進行自動化回歸測試都會帶來好處。鼓勵的過程是在設計開發過程(類似于測試驅動開發)的同時編寫這些測試腳本。將這些自動化測試與 CI/CD 系統相結合增加了額外的好處,以證明我們的電路板正在遠程目標上工作,并且可以由任何人隨時隨地進行測試。

        請輸入搜索關鍵字

        確定
        国产在线视频在线