如何測試Android醫療設備
加入技術(shù)交流群
近三年來(lái)，Android作為移動(dòng)設備平臺取得了重大進(jìn)展。實(shí)事上，在美國目前有一半以上的智能手機采用Android操作系統，Android操作系統是美國智能手機市場(chǎng)的老大。Android操作系統由Google領(lǐng)導的開(kāi)放手持設備聯(lián)盟開(kāi)發(fā)。Android已被大多數手機運營(yíng)商和眾多手機制造商采用，其中包括摩托羅拉、索尼愛(ài)立信、三星、LG和HTC。
與此同時(shí)，對于很多OEM、運營(yíng)商和設備制造商而言，要推出基于A(yíng)ndroid平臺的設備，仍是一個(gè)有待克服的挑戰。Android平臺的版本繁多、具有很強的靈活性和可配置性（即便是終端用戶(hù)也可以對其進(jìn)行靈活配置），這些因素使得Android成為一個(gè)難設計、測試和推出的平臺。
如何測試Android設備
要部署一個(gè)完整而高效的設備測試項目，測試團隊需要開(kāi)發(fā)必須的測試用例，在每個(gè)測試用例中，必須對待測設備的正確行為進(jìn)行描述。如果所開(kāi)發(fā)的測試用例有錯誤，要求缺失或不完整，從而導致測試過(guò)程中出現錯誤，那么測試項目將不能成功地實(shí)現其目標---鎖定被測設備存在的缺陷。
編寫(xiě)相關(guān)測試用例的第一步是收集設備在所有使用案例和使用場(chǎng)景下的全部預期行為，這些資料應該早已存于技術(shù)和測試要求文檔之中。
技術(shù)和測試要求的制定是成功推出設備的重要步驟。對于基于A(yíng)ndroid平臺的設備而言更是如此，因為這些平臺很容易配置，設備OEM廠(chǎng)商在各自的Android設備中采用了一系列不同的外形參數、用戶(hù)界面和軟件配置。
若未能適當、充分地挖掘和制定測試要求，那么測試用例就不能反映它原本應該反映的設備的預期行為，而是基于被測試設備所展現的行為，這些行為就不一定準確。
為了開(kāi)發(fā)出足夠完善的技術(shù)和測試要求，設備發(fā)布小組必須參考圖1中所示的不同來(lái)源，來(lái)創(chuàng )建一組完善的要求。測試小組通常會(huì )跳過(guò)這一步，他們會(huì )直接跳到開(kāi)發(fā)測試用例，然后進(jìn)行則試。依據以往經(jīng)驗表明，如果執行這一步，會(huì )使得所開(kāi)發(fā)的測試用例更加精確、有效和快速，并且縮短開(kāi)發(fā)時(shí)間。
圖1中的文字內容：
Sources for Test Requirements document：測試要求文檔的來(lái)源
Design Team: Requirements including UI, preloaded Apps,settings etc.
設計小組：要求包括用戶(hù)界面、預先加載應用、設置等
■Functional behavior for each use case and sub-use cases
■Android’s software configuration and settings
■UI and usability requirements
■每個(gè)使用案例和子使用案例的功能性行為
■Android的軟件的配置和設定
■UI和可用性要求
Google Android specificaitnos, tools and licensing requirements
Google Android規范、工具和授權要求
■system requirements for the specific version of Android on the device
■google provided tools to test Android platform and applications e.g. Android Monkey
■Google HW and licensing requirements
■設備所使用的具體版本的Android系統的系統要求
■Google提供用于測試Android平臺和應用的工具，例如，Android Monkey
■Google 硬件和授權要求
如圖所示，測試要求應考慮多個(gè)方面
如何開(kāi)發(fā)Android測試計劃
鑒于A(yíng)ndroid平臺所具備的高級可配置性，要開(kāi)發(fā)一個(gè)涵蓋設備各方面功能、完善且易于理解的測試計劃并不是一件容易的事。與其它大多數平臺不同，Google很頻繁地推出新版本的Android平臺，并且各個(gè)版本的Android系統對操作系統的不同層做了修改，特別是用戶(hù)界面層。與此同時(shí)，設備OEM廠(chǎng)商常常會(huì )自行設計專(zhuān)利的用戶(hù)界面或皮膚，以滿(mǎn)足某些特殊應用，例如將Android用于醫療設備。因此，在測試Android設備的時(shí)候，測試計劃必須包括功能方面以及需要進(jìn)行則試的用戶(hù)界面和使用特性。對于由電池供電的設備，還必須對電池壽命和功耗進(jìn)行測試。圖2所示為Android測試計劃必須包括的幾類(lèi)測試用例。
圖片中的文字內容
Android test cases: Android測試用例
Functional test cases: 功能性測試用例
Hardware,setup and Accessories 硬件、安裝和附件
Applications 應用
Google features(if any utilized) Google特性（如果有用到）
Stress and Compliance test caese(e.g.FDA) 應力和兼容測試用例（如FDA）
Usability Test cases: 可用性測試用例
Battery life test cases: 電池壽命測試用例
2.圖中所示為必須包括的幾類(lèi)測試用例
功能測試
功能測試用例直截了當，并且是根據特性要求定義和設計文檔來(lái)編寫(xiě)的。技術(shù)設計要求和測試要求可被用作指導性文檔，指導定義和創(chuàng )建用于測試和檢驗設備的性能、特性和功能的測試用例。
一直以來(lái)，Google每年都會(huì )推出幾款新版Android系統，為了跟進(jìn)每個(gè)新版本的Android系統，測試用例也必須要做更新。Google最近宣布，今后每年將僅推出一款新版Android系統。
可用性測試
用戶(hù)接口若設計恰當，可以大大地減少用戶(hù)出錯以及提高設備的可用性。在發(fā)布設備之前對其進(jìn)行可用性測試十分重要。為了測試設備的可用性，首先要開(kāi)發(fā)測試用例。常見(jiàn)的方案是在任務(wù)層開(kāi)發(fā)多個(gè)可用性測試用例，然后將每個(gè)任務(wù)層測試用例關(guān)聯(lián)到被測設備完成這一任務(wù)所需要的各個(gè)步驟。
可用性測試對于醫療設備而言極其重要，因為用戶(hù)出錯導致的后果可能是災難性的，必須予以高度的重視。FDA將用戶(hù)出錯視作導致醫療設備風(fēng)險的一個(gè)極嚴重的源頭，有很多醫療設備被召回的例子都與用戶(hù)出錯和設計問(wèn)題有關(guān)。為了將用戶(hù)出錯降低到最小程度，FDA還提供了具體的醫療設備設計和測試指導文件。其中部分指導文件和標準是針對可用性的，所有這些指導文件和標準都可在fda.gov網(wǎng)站上查到：
1.軟件驗證的總體原則；行業(yè)和FDA人員至高指南
2.面向醫療設備制造商的設計控制指南，參考DA 21 CFR 820.30和ISO 9001的子條款4.4。
3.醫療設備中人為因素的介紹，作者：Dick Sawyer。
有關(guān)醫療設備可用性的國際標準和指導文件：
1.風(fēng)險管理：ISO14971
2.軟件生命周期：IEC 62304
3.人為因素：IEC 60601-1-6、ANSI/AAMI HE74、ANSI/AAMI HE74
4.基本安全：IEC-60601-1和IEC60601-1-x系列標準
怎樣對可用性進(jìn)行評估和測試？一個(gè)方案是，由試驗測試人員進(jìn)行模擬使用。這樣可以深入了解設備在用戶(hù)手中的運行情況；另一個(gè)可能更有效的方案是，利用工程學(xué)方法來(lái)測試可用性?；谛睦韺W(xué)和人為因素的科學(xué)研究成果，可用性專(zhuān)家形成了用于測試可用性的方法論。在這種方案中，通過(guò)度量設備在使用過(guò)程會(huì )影響用戶(hù)的指標參數，對設備的可用性進(jìn)行評估和測試，這些參數包括效率、可訪(fǎng)問(wèn)性、可視性、反饋和響應，等等。
電池壽命的測試
若被測設備采用電池供電，則功耗和電池壽命是設備設計和測試的一個(gè)重要組成部分。時(shí)尚的、手持式電池供電設備擁有更大的屏幕、更快速的CPU和更快速的網(wǎng)絡(luò )連接，所有這些特性給電池帶來(lái)非常大的負擔。
對采用電池供電的移動(dòng)設備而言，有兩個(gè)方案可用來(lái)測試功耗和電池的預期壽命。第一個(gè)方案是元器件級別的，即對每個(gè)子系統的功耗分別進(jìn)行測量。第二個(gè)方案，是把該設備當做一個(gè)整體來(lái)測量其功耗。每個(gè)方案各自有其優(yōu)、缺點(diǎn)。
若使用元器件級別的方案，則被測設備的功耗為其每個(gè)元器件功耗測量值的總和。分別測量每個(gè)元器件的功耗與將設備作為一個(gè)整體測量其功耗相比，前者更加精確，并且結果可以重復再現，但需要的工作量更大，所以成本更貴。此外，若分別測量各個(gè)元器件的功耗，還需要查找詳細的設備硬件文檔，以便找出每個(gè)元器件在PCB板上的供電點(diǎn)。
若采用設備級別的方案，則是通過(guò)測量電池連接匯總點(diǎn)來(lái)求得設備的功率。每個(gè)設備使用案例都會(huì )用到功耗測量。相比元器件級別的功耗測量，本方案更為簡(jiǎn)單、更加靈活。但因為使用案例通常由人工測試人員執行，所以每次測得的結果可能各不相同，因此有必要進(jìn)行多數重復測試，以獲得穩定的統計數據。
為了延長(cháng)電池使用時(shí)間，大多數時(shí)尚的電池供電設備采用了多種電源管理方針，并且會(huì )在設備一段時(shí)間內未被使用的情況改變設備的狀態(tài)。在這樣的情況下，為了得到設備的所有功耗行為和很好地評估電池的壽命，必須測試設備在不同狀態(tài)下的功耗，設備的狀態(tài)通常包括暫停狀態(tài)、空閑狀態(tài)和工作狀態(tài)。
執行用戶(hù)案例
一旦寫(xiě)好了測試用例，測試工程師們將執行這些用戶(hù)案例，以便找出設備缺陷和決定設備和/或特性是否已經(jīng)能夠出貨。在執行測試用例時(shí)，遵循以下幾條經(jīng)驗法則，可以加快測試過(guò)程和降低出錯的可能：
•為了保證由不同測試人員執行的測試用例的一致性，應針對如何運行測試和腳本，如何從結果中收集數據以及如何分析和處理結果對測試人員進(jìn)行培訓。
•指示測試工程師們遵從測試計劃和要求以及測試用例中提供的詳細內容。
•檢查每個(gè)測試的設置（如，測試前的準備、輸入參數、被測設備的狀態(tài)）以及在執行過(guò)程中監控測試
•檢驗和捕捉每個(gè)測試用例或腳本的運行時(shí)間。這樣可以方便計劃和制定下一步測試的運行以及其它項目
•如果使用測試腳本，要用不同的數據進(jìn)行測試，不要用在運行腳本過(guò)程中使用過(guò)的數據
•必需針對每個(gè)測試和校準所得到的結果，給出準確、清楚和有針對性的報告，并且要符合測試用例或校準方法中的所有具體指令。為了做到這一點(diǎn)，測試用例應包括以下指導方針：遵從測試計劃，精確地記錄結果；記錄參數（輸入、日期、影響測試/腳本的項目）；記錄測試執行的運行時(shí)間以及與預期運行時(shí)間的差異；記錄失敗日志和關(guān)聯(lián)的響應。
下表給出一個(gè)測試用例的例子，該測試用例用于測試一款Android設備的觸摸屏數據輸入的精確度?！?/div>
助聽(tīng)器原理相關(guān)文章:助聽(tīng)器原理
相關(guān)推薦
-
-
-
-
-
mgraphic | 2009-04-25
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
meigd | 2005-11-18
-
-
dylhz | 2008-12-05
-
-
android123 | 2009-05-05
-
-
timllomap | 2009-04-23
-
技術(shù)專(zhuān)區
- FPGA
- DSP
- MCU
- 示波器
- 步進(jìn)電機
- Zigbee
- LabVIEW
- Arduino
- RFID
- NFC
- STM32
- Protel
- GPS
- MSP430
- Multisim
- 濾波器
- CAN總線(xiàn)
- 開(kāi)關(guān)電源
- 單片機
- PCB
- USB
- ARM
- CPLD
- 連接器
- MEMS
- CMOS
- MIPS
- EMC
- EDA
- ROM
- 陀螺儀
- VHDL
- 比較器
- Verilog
- 穩壓電源
- RAM
- AVR
- 傳感器
- 可控硅
- IGBT
- 嵌入式開(kāi)發(fā)
- 逆變器
- Quartus
- RS-232
- Cyclone
- 電位器
- 電機控制
- 藍牙
- PLC
- PWM
- 汽車(chē)電子
- 轉換器
- 電源管理
- 信號放大器
評論