醫院軟件評測的實踐與體會

郭勇　　劉坤

[摘要] 在我國醫藥體制改革不斷深化、互聯網產業迅猛發展的今天，醫院信息系統是現代化醫院運營的必要技術支撐和基礎設施，實現醫院信息系統的目的就是為了以更現代化、科學化、規范化的手段來加強醫院的管理，提高醫院的工作效率，改進醫療質量，從而樹立現代醫院的新形象，這也是未來醫院發展的必然方向。作為信息系統開發或集成中的一個必要組成部分，如何有效的組織和管理軟件評測活動是格外重要的一環，本文將結合醫院系統的評測實踐經驗，從軟件評測的基礎理論出發，探求利用系統、全面、科學的評測設計和有效地評測組織實施，獨立、客觀、公正、定量地分析評估和報告被測系統的整體狀況，提交系統存在的缺陷，提出系統的改進建議，通過缺陷修改使系統達到一個穩定可靠的質量狀態。

[關鍵詞] 醫院信息系統；評測過程管理；軟件評測；黑盒評測法；思維導圖

[中圖分類號] R197 [文獻標識碼] C [文章編號] 1673-9701（2017）27-0127-05

Practice and experience of hospital software evaluation

GUO Yong1 LIU Kun2

1.Hospital Office，Daxing District Hospital of Integrated Chinese and Western Medicine in Beijing， Beijing 100076，China；2.Department of Information，Daxing District Hospital of Integrated Chinese and Western Medicine in Beijing， Beijing 100076， China

[Abstract] In the current era， with the continuous deepening of medical system reform， and rapid development of the Internet industry in China， hospital information system is the necessary technical support and infrastructure for the operation of modernized hospitals. The aim of achieving the hospital information system is to utilize more modernized， scientific and standardized means to strengthen the hospital management， improve the efficiency of the hospital， enhance the quality of medical care， so as to establish a new image of modernized hospitals. This is the inevitable direction of future hospital development. As an essential component of information system development or integration， how to effectively organize and manage software evaluation activities is a particularly important part. This article will combine the practical experience of evaluating hospital system， and explore the use of systematic， comprehensive and scientific evaluation design and effective evaluation organization and implementation from the basic theory of software evaluation， so as to independently， objectively， justly and quantitatively analyze， assess and report the overall situation of the evaluated system， submit the existing system defects， and put forward suggestions for system improvement， which enables the system to achieve a stable and reliable status through the correction of defects.

[Key words] Hospital information system； Evaluation process management； Software evaluation； Black-box evaluation method； Mind mapping

目前，醫院信息化建設正向著“數字化醫院”的方向迅速發展。那么，滿足人民對醫療保健服務的高品質、高效率、高服務的需求已成定局，因此，在推動醫院信息化建設的進程中，如何保障信息系統的安全、穩定、有效運行是即系統開發后所面臨的首要問題[1]。

軟件評測是一種用來促進鑒定軟件的正確性、完整性、安全性和質量的過程。軟件評測的經典定義是在規定的條件下對程序進行操作，以發現程序錯誤，衡量軟件質量，并對其是否能滿足設計要求進行評估的過程。作為信息系統開發或集成中的一個必要組成部分，如何有效的組織和管理軟件評測活動是格外重要的一環。本文將結合醫院系統的評測實踐經驗，從軟件評測的基礎理論出發，探求利用系統、全面、科學的評測設計和有效地評測組織實施，科學、客觀、公正、嚴謹地分析評估和報告被測系統的整體狀況，提交系統存在的缺陷，提出系統的改進建議，通過缺陷修改使系統達到一個穩定可靠的質量狀態。endprint

1 適用的評測方法是開端

醫院管理需要主動適應新一輪醫療改革，做到改革與改善同步，構筑醫院信息資源戰略，推動醫院信息系統建設規范化，需要加強醫院信息化建設的管理、監督、指導和評審[2]，軟件評測主要采用黑盒評測也稱功能評測，它是通過評測來檢測每個功能是否能正常使用。在評測中，將程序看作一個不能打開的黑盒子，在完全不考慮程序內部結構和內部特性的情況下，在程序接口進行評測，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數據而產生正確的輸出信息。黑盒評測是著眼于程序外部結構，不考慮內部邏輯結構，主要針對軟件界面和軟件功能進行評測[3]。

黑盒評測法注重于評測軟件的功能需求，主要試圖發現下列幾類錯誤：功能不正確或遺漏，界面錯誤，數據庫訪問錯誤，初始化和終止錯誤等。

從理論上講，黑盒評測只有采用窮舉輸入評測，將所有可能的輸入均作為評測情況考慮，才能查出程序中所有的錯誤。實際上評測情況有無窮多個，人們不僅要評測所有合法的輸入，而且還要對那些不合法但可能的輸入進行評測。這樣看來，完全評測是不可能的，所以我們要進行有針對性的評測，通過制定評測方案指導評測的實施，保證軟件評測有組織、按步驟有計劃地進行。黑盒評測行為必須能夠加以量化，才能真正保證軟件質量，而評測用例就是將評測行為具體量化的方法之一。具體的黑盒評測用例設計方法包括等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、判定表驅動法、正交試驗設計法、功能圖法等[4]。

2 嚴謹的過程設計是枝干

軟件評測過程是一種抽象的模型，用于定義軟件評測的流程和方法。眾所周知，開發過程的質量決定了軟件的質量，同樣地，評測過程的質量將直接影響評測結果的準確性和有效性。軟件評測過程和軟件開發過程一樣均遵循軟件工程原理，遵循管理學原理[5]。通過對測試目的、理論依據、測試策略、測試方法的詳細描述，勾畫出對醫院信息系統測試的全過程。在指標數據采集方面，通過用戶自述、表格填寫、選擇填空、自動記錄、人工測試等多途徑獲取，讓評價建立在客觀依據的基礎上。針對軟件質量評價正確性、可維護性、可移植性、可測試性、可靠性、有效性等具體要求，建立測試指標體系和管理辦法，以闡明測試目的、內容、對象、步驟、安排、實施、評價。針對不同的評測類型，按照以下評測流程對不同評測類型進行評測項目實施，具體評測流程見下圖所示（圖1）。

這是整個評測過程的主脈絡，可以直觀的控制各節點的進展和建立問題流向的解決機制。

3穩定的評測小組是關鍵

評測小組的組建主要取決于項目規模和對質量保證的理解，如果要保障評測工作的正常、有序進行，必須組建一支穩定的評測小組，基于此，需要醫院管理層與技術人員參與到評測小組[6]。評測管理小組醫院信息部門和項目方經共同組成。將醫院信息系統視為一個完整的系統工程，在測試指標確定過程中，從個體、組織與社會多角度去綜合考察分析；從單純業務應用提高到含應用、控制、管理、利用為一體的綜合功能理念出發；從單一技術因素轉向包含使用這些技術的組織與人的非技術因素綜合結果；從系統本身轉向系統與組織、環境的交互作用。跟蹤國際上現行的軟件評測理論、技術和方法，參照國家、國際有關標準規范，指導測評工作。

評測小組成員主要包含項目管理、評測經理，評測工程師及QA相關人員。項目管理主要負責評審和批準評測計劃及有關報告、組織并確保小組工作、控制項目進度、與各方進行溝通和協調。評測經理主要職責包括編制并評審評測計劃及有關報告、協調實施項目計劃中相關活動、溝通協調相關研發團隊、識別評測環境需求、為其他人員提供評測技術支持、進行詳細的評測結果分析。見表1。

4 明確的評測核心是焦點

軟件評測是發現軟件問題、確保軟件質量地有效手段[7]。評測小組團隊的需求分析主要包括“兩圖一文檔”。即兩圖：業務流程圖，思維導圖；一文檔：需求分析文檔。

業務流程圖是對于需求從流程（整體）去理解。思維導圖是對需求所包含的各項功能點去理解。需求分析文檔是對思維導圖中的功能點去發散成為評測點。我們通過這種方式，每個需求所表達的內容基本不會漏掉。

而更高層次的隱性需求，就需要對業務有著很深的理解，安排子系統廠商技術人員分批次對評測小組進行業務培訓以快速掌握系統，對比需求文檔。期間結合各相關科室的實際操作以搜集更過關于易用性等質量參數的相關意見，達到全面分析需求，把控重點環節的作用[8]。

5有效的資源控制是力量

軟件評測中，軟件管理者首先應對資源進行有效分配。當前，評測資源分配主要應用在構件軟件的模塊評測中，評測資源控制用以對所分配資源的消耗過程進行優化控制，提高評測效率。

相對于軟件評測來說，其按著功能劃分有白盒和黑盒之分，從開發的過程來分主要有單元評測、集成評測、確認評測、系統評測四個部分，如果按測試方法來分類，可以分為靜態評測和動態評測，這也是現在主要的檢驗手段。

除了缺少時間外，通常在取得執行必要的評測所需的合適資源方面也面臨困難，資源可能被其他工作或項目分享。雖然評測的硬件資源會帶來延遲和困難，但是人力資源的缺乏可能更加難以解決。在評測管理中這種障礙的影響和時間缺乏造成的影響大致相同[10]。

評測小組對現有資源（人、設備、工具等）進行自評估并就醫院現有資源進行初步盤點，在制定評測計劃時即已做好調度準備，以備不時之需。故此，在實施環節出現設備不足時，立即補充相應設備投入，保障了階段性任務的準時完成。

5.1評測交互方式

評測嚴格按照確認的評測方案、委托評測申請單執行，依據方案規定的評測范圍進行試點評測。針對評測方案規定的評測策略，在評測執行中都有體現，評測過程中依據系統需求說明書，對被測對象評測，評測各個階段在評測管理平臺中進行嚴格追蹤和管理，實行交叉隨機評測。endprint

5.2基線管理

評測執行過程中，為避免評測過程版本的混亂，應建立基線管理機制，在每次評測完成之后建立版本基線，保留上一個評測版本環境，這樣在評測過程中可以追根溯源，尤其是在進行第二輪、第三輪評測的時候可以驗證是研發人員修改裂化的缺陷還是原本系統就存在而評測人員未發現的缺陷，如果是裂化的缺陷，那在回歸評測時注意該條業務線上其他功能是否都受到影響，如果是原本就存在的缺陷而評測人員未發現則要考慮是否評測用例設計不夠完善，這對問題的排查和評測方向都有很重要的指導意義。

5.3分配原則

重點在于從缺陷產生的概率和開發進行修復的難易程度來進行安排，缺陷如果發生的概率越大，或者是這類缺陷被修改的難度越高，那么執行測試的時候就要越靠前，根據測試用例的優先級，這是項目執行測試的重要原則：①首先安排用例級別較高的功能場景先測試，后根據用例級別高低依次安排。②先對主要功能和流程進行測試，然后對非主要功能和流程進行測試。③先對功能和邏輯進行測試，然后在對界面進行測試；④進行定量的隨機猜測性測試，以便更好的發現隱藏在程序內部不易被發現的缺陷；⑤在每輪測試結束之后均進行交叉測試，以便更好的發現熟悉模塊不能發現的缺陷。

6 有效的評測用例是方法的展現

6.1用例設計的規程

在設計評測用例時尤其要關注模塊之間業務邏輯及數據流關系，評測策略的設計主要采用黑盒評測的方法，依據需求規格說明書和用戶手冊，直接輸入數據來驅動功能模塊的運行并得到最后的輸出結果，以此來驗證程序接口和用戶界面是否都能夠滿足用戶的需求并且保證數據及文件的完備性[11]。在進行功能評測設計的時候，主要遵循如下操作規程：①根據系統模塊的架構進行層次劃分，有效確認評測點的優先級；②設計評測用例時采用由上及下的原則，逐層推進；③與開發和科室人員及時進行業務上的溝通，不斷加強對項目的理解程度；④借助相關工具和數據流圖，積極推進評測工作的進展。

6.2常用方法的引用

項目用到最多的是等價類劃分法和邊界值法，在設計用例時，通常需要提高單條用例覆蓋的有效等價類的數量，并保證一對一的覆蓋無效等價類。但是在實際的軟件開發和設計過程中，開發人員往往忽視數據邊界情況，因此在評測時發現的問題也大部分都集中在邊界的處理上[12-13]。所以在評測數據設計的時候根據條件重點考慮邊界值，對于提高整個評測的效率上是有很大的幫助的。從另一個層面來說，邊界值分析法也可以說是等價類方法的一個補充，評測的過程當中，兩者往往結合起來共同進行用例的設計，這樣才能夠最大限度的覆蓋評測需求。如個別系統需要進行導入數據大小不超過2M其實就需要2M的邊界情況，在用例設計時，本項目不僅考慮取邊界值作為輸入數據，而且還把邊界值兩側的情況考慮在內，即X小于2M、等于2M及大于2M也作為輸入數據，以此構成整個評測數據的規劃。見圖2。

6.3用戶文檔審查

文檔本身也是軟件產品的組成部分，根據項目實際情況和文檔審查范圍，用戶文檔集審查分兩個階段，第一階段為過程審查，在項目建設過程中，對文檔進行定期審查，保證項目所需要的各種文檔持續符合要求；第二階段為文檔驗收審查，系統開發項目文檔清單中變更類、需求類、設計類等相關系統文檔產出物進行正向和逆向追蹤審查，對文檔中系統信息驗收，要求文檔資料對系統實現功能和用戶最終調用的功能應有盡可能詳細的語言描述或圖示；文檔對使用系統的限制條件和約束應有足夠的說明；各文檔內容信息應正確無誤，相互一致，沒有歧義，并且易理解和易學習[14]。

6.4 缺陷的跟蹤與管理

對缺陷的跟蹤和管理需要達到以下兩個目標：一是確保每個被發現的缺陷都能夠被解決，二是收集缺陷數據并根據缺陷趨勢曲線識別和預防缺陷的頻繁發生。在缺陷管理時，不能只考慮如何修正缺陷，而忽視對根據缺陷分析進行有效預防。其實，通過對缺陷數據的收集和分析也很重要，從缺陷數據中可以得到很多與軟件質量相關地數據。

缺陷最重要的是清晰明了的說明問題，重現步驟及如何解決。其實每一個缺陷都是一個優秀的用例，需要維護到評測用例中去，下次執行時，就多預防一個點[15]。

通過軟件評測，一方面，可以讓醫院確實了解本院所建立的信息系統其質量等級，尚需要哪些改進措施，系統應該在醫院正常業務運行中發揮什么作用；同時軟件測評也是對醫院投入的一種回報認可。另一方面，對開發單位的技術實力作一個客觀評價，并對應用系統提出具體改進建議，同時也幫助開發單位熟悉了解醫院的業務流程及需求，從而提高開發單位的產品水平和市場競爭力。

[參考文獻]

[1] 李書章，劉國祥，吳昊，等. 數字化醫院建設思路與實踐[J]. 解放軍醫院管理雜志，2004，11（2）：108-110.

[2] 范啟勇，沈樹春，張佳茂，等.建立科學、合理、全面的醫院信息系統評測標準[J].中國醫院管理，2002，22（8）：23-24.

[3] 向潤. 黑盒測試方法探討[J]. 軟件導刊，2009，8（1）：33-35.

[4] 孟祥豐. 軟件的黑盒測試方法解析與優化[J]. 物聯網技術，2011，1（8）：69-71.

[5] 張春霞，蘇秦. 軟件測試過程分析[J]. 計算機應用研究，2004，21（5）：46-48.

[6] 李超峰，干峰，何榮，等. 醫院信息系統用戶測試工作的組織和管理[J]. 醫學信息，2009，22（4）：465-467.

[7] 閆國英，陳青.軟件評測過程管理方法研究與實現[J].飛行器測控學報，2009，28（4）：8-12.

[8] 吳秋月. 談應用軟件開發過程中的一個瓶頸問題——需求分析[J]. 安徽教育學院學報：自然科學版，1998，（1）：66-67.

[9] 徐進. 軟件評測技術的研究與實踐[J]. 信息技術，2012， （1）：182-183.

[10] 張策，崔剛，劉宏偉，等.軟件測試資源與成本管控和最優發布策略[J].哈爾濱工業大學學報，2014，46（5）：51-58.

[11] 趙瑋，楊莉. 軟件模塊測試中的動態資源分配問題[J]. 運籌學學報， 2000，4（3）：88-94.

[12] 徐強. 加強軟件測試能力提高測試用例設計水平[J]. 神華科技，2010，8（4）：7-10.

[13] 馮玉芬，楊天棟.價類劃分測試用例設計[J]. 株洲師范高等專科學校學報，2007，12（5）：43-45.

[14] 楊萬君，伍濱. 軟件文檔審查的基本要求[J]. 中國軍轉民，2013，（2）：49-50.

[15] 潘江波，馮蘭萍，印斌. 基于軟件測試的缺陷管理系統的研究[J]. 現代圖書情報技術，2005，21（1）：26-28.

（收稿日期：2017-07-17）endprint