第8章 測試實踐課件

第8章測試實踐8.1被測試軟件項目介紹8.2測試計劃8.3HIS測試過程概述8.4測

試

用

例設計8.5缺

陷

報

告8.6測試結果總結分析8.7軟件測試自動化工具8.8文

檔

測

試第8章測試實踐

本章介紹的被測試軟件項目是醫(yī)院信息管理系統(tǒng)（HIS，HospitalInformationSystem）。HIS是一個集成度很高的項目，因為行業(yè)的關系其中有一些詞匯可能不被大家所了解，但這并不妨礙說清楚它的測試過程。第8章測試實踐

本章要重點描述的測試過程是HIS的集成測試，該階段的測試重點在功能測試上，也有必要的性能測試。后面依次給出了HIS集成測試階段的測試計劃、測試用例、缺陷（錯誤）報告、測試結果總結與分析等內容。測試用例將針對HIS的一個子系統(tǒng)——門診掛號管理子系統(tǒng)來設計。該子系統(tǒng)不但包含了對數(shù)據(jù)庫的應用，對系統(tǒng)的并發(fā)性、安全性、準確性、高效性都有很高的要求，可謂麻雀雖小，五臟俱全，適合將其進行剖析。第8章測試實踐8.1被測試軟件項目介紹8.1.1被測試項目軟件背景醫(yī)院信息管理系統(tǒng)（HIS）包含門診掛號、門診收費、診間醫(yī)令、病房管理、病案管理、藥房藥庫管理等二十余個子系統(tǒng)，用于管理醫(yī)院日常運作的整個過程。各子系統(tǒng)所處理的業(yè)務前后銜接，數(shù)據(jù)共享。醫(yī)院信息管理系統(tǒng)的系統(tǒng)結構如圖10-1所示。第8章測試實踐圖10-1HIS1.0系統(tǒng)結構圖第8章測試實踐8.2

測試計劃

測試計劃工作的提交成果是一份完整的測試計劃報告。下面給出醫(yī)院信息管理系統(tǒng)1.0版集成測試的測試計劃報告。第8章測試實踐8.2.1概述本測試項目擬對醫(yī)院信息管理系統(tǒng)（HIS）1.0進行測試。醫(yī)院信息管理系統(tǒng)包含門診掛號、門診收費、診間醫(yī)令、病房管理、病案管理、藥房藥庫管理等二十余個子系統(tǒng)，用于管理醫(yī)院日常運作的整個過程，各子系統(tǒng)所處理的業(yè)務前后銜接，數(shù)據(jù)共享。第8章測試實踐

測試的目標是要找出影響醫(yī)院信息管理系統(tǒng)正常運行的錯誤，分別在功能、性能、安全性等方面檢驗系統(tǒng)是否達到相關要求。本次集成測試采用黑盒和白盒測試技術（重點在黑盒測試）。測試手段為手工與自動測試相結合（主要依靠手工進行功能測試，依靠自動測試工具進行性能測試）。本測試計劃面向相關項目管理人員、測試人員和開發(fā)人員。第8章測試實踐8.2.2定義質量風險：被測試系統(tǒng)不能實現(xiàn)描述的產品需求或系統(tǒng)不能達到用戶的期望的行為，即系統(tǒng)可能存在的錯誤。測試用例：為了查找被測試軟件中的錯誤而設計的一系列的操作數(shù)據(jù)和執(zhí)行步驟，即一系列測試條件的組合。第8章測試實踐

測試工具：應用于測試用例的硬件/軟件系統(tǒng)，用于安裝或撤銷測試環(huán)境、創(chuàng)造測試條件，執(zhí)行測試，或者度量測試結果等工作。測試工具獨立于測試用例本身。進入標準：一套決策的指導方針，用于決定項目是否準備好進入特定的測試階段。在集成測試和系統(tǒng)測試階段，進入標準會很苛刻。第8章測試實踐

退出標準：一套標準，用于決定項目是否可以退出當前的測試階段，或者進入下一個測試階段或者結束項目。同進入標準，測試過程的后幾個階段退出標準一般很苛刻。功能測試：集中于功能正確性方面的測試。功能測試必須和其他測試方法一起處理潛在的重要的質量風險，比如性能、負荷、容積和容量等。第8章測試實踐8.2.3質量風險摘要危險性：表示故障對系統(tǒng)影響的大小。5—致命；4—嚴重；3—一般；2—輕微；1—無。影響：5—一定影響所有用戶；4—可能影響一些用戶；3—對有些用戶可能的影響；2—對少數(shù)用戶有限的影響；1—在實際使用中難以覺察的影響。第8章測試實踐

優(yōu)先級：表示風險可以被接受的程度。5—很緊急，必須馬上糾正；4—不影響進一步測試，但必須修復；3—系統(tǒng)發(fā)布前必須修復；2—如果時間允許應該修復；1—最好修復。第8章測試實踐8.2.4測試進度計劃8.2.5進入標準（1）“測試小組”配置好軟硬件環(huán)境，并且可以正確訪問這些環(huán)境。（2）“開發(fā)小組”已完成所有特性和錯誤修復并完成修復后的單元測試。（3）“測試小組”完成“冒煙測試”，程序包能打開，隨機的測試操作正確完成。第8章測試實踐8.2.6退出標準（1）“開發(fā)小組”完成了所有必須修復的錯誤。（2）“測試小組”完成了所有計劃的測試。沒有優(yōu)先級為3以上的錯誤。優(yōu)先級為2以下的錯誤少于5個。（3）“項目管理小組”認為產品實現(xiàn)穩(wěn)定性和可靠性。第8章測試實踐8.2.7測試配置和環(huán)境服務器1臺：HPPentiumⅢ

550，1GB內存，8.4GB硬盤；軟件環(huán)境：WindowsNT，Oracle?？蛻魴C10臺：PentiumMMX166，1.2GB硬盤，32MB內存；軟件環(huán)境：Oracle客戶端。打印機1臺：PanasonicKX-P1131。地點：58號樓101室。第8章測試實踐8.2.8測試開發(fā)設計測試用例以進行手工測試。準備使用MILoadRunner，以檢測系統(tǒng)對并發(fā)性的控制和系統(tǒng)的強壯性。設計開發(fā)問題記錄及交互工具，包括問題存取控制系統(tǒng)及所對應的數(shù)據(jù)庫，以對測試結果做很好的記錄并提供相關測試和開發(fā)人員的交互平臺。第8章測試實踐8.2.9關鍵參與者測試經(jīng)理：宋欣欣（制定測試計劃及部署、監(jiān)督相關工作）。測試人員：蔡亮，邱實，崔進，赫北松，洪怡，武剛，沙盼盼，王軍妹（負責相關子系統(tǒng)測試）。開發(fā)人員：王鐵全，李云帆，夏淼，張鐵（及時解決影響測試進行的系統(tǒng)問題）。項目管理人員：王斌（跟蹤項目進展）。第8章測試實踐8.2.10預算8.2.11參考文檔第8章測試實踐8.3HIS測試過程概述HIS的測試按照一般測試過程，將其分為單元測試、集成測試、系統(tǒng)測試和驗收測試4個階段。第8章測試實踐8.3.1單元測試單元測試常常是動態(tài)測試和靜態(tài)測試兩種方式并舉的。動態(tài)測試可由開發(fā)人員去運行局部功能或模塊以發(fā)現(xiàn)系統(tǒng)潛藏的錯誤，也可以借助測試工具去測試。靜態(tài)測試即是代碼審查。審查的內容包括代碼規(guī)則和風格，程序設計和結構，業(yè)務邏輯等。第8章測試實踐HIS系統(tǒng)中涉及到許多的費用計算問題，邏輯性很強，需要程序結構也很復雜。面對復雜的業(yè)務流程，面對管理各異的用戶需求，沒有白盒測試是不可想像的。最簡單的例子：HIS中要處理很多類的患者，普通患者、醫(yī)?；颊?、內部職工、公費患者等，每類患者的費用處理流程和計算方法都不相同，開發(fā)人員就要嚴格地依照系統(tǒng)設計去檢查代碼的邏輯結構，選取有代表性的測試用例去測試相關的模塊。第8章測試實踐

又如醫(yī)囑分解，藥房擺藥等，必須知道系統(tǒng)的詳細設計和程序的邏輯結構才能設計好測試用例。第8章測試實踐8.3.2集成測試集成測試（有時被分為集成測試和確認測試兩個階段）是指將各模塊組裝起來進行測試，以檢查與設計相關的軟件體系結構的有關問題，并確認軟件是否滿足需求規(guī)格說明書中確定的各種需求。

HIS系統(tǒng)的集成測試是指開發(fā)人員完成了所有系統(tǒng)模塊的開發(fā)并通過了單元測試后，將編譯好的軟件交付給測試部門進行測試的過程。第8章測試實踐

這個階段的測試需要一個完備的測試管理過程。集成測試過程可以分為測試準備、測試計劃、測試設計、測試執(zhí)行和測試總結5個階段。測試準備階段是指測試人員準備測試資源，熟悉系統(tǒng)的過程。第8章測試實踐

測試計劃階段包含制定測試策略、資源分配、風險預警和進度安排等內容，此項工作由測試負責人來做。8.2節(jié)中給出了HIS集成測試的測試計劃。測試計劃的模板各不相同，這個取決于軟件的特殊性和管理的規(guī)范性。第8章測試實踐

測試設計階段包括設計測試用例及相關管理工具的設計。8.4節(jié)將給出HIS集成測試過程中掛號管理子系統(tǒng)部分的主要測試用例，側重于系統(tǒng)的功能和性能測試。測試用例設計之前一般要有一個測試用例的設計大綱。完成測試設計工作后，就開始執(zhí)行實際的測試工作了。第8章測試實踐

測試時另外一項非常重要的工作就是做好系統(tǒng)缺陷記錄。本章8.5節(jié)將給出系統(tǒng)生成缺陷報告的注意事項以及缺陷報告的實例，另外還設計了一個問題記錄數(shù)據(jù)庫表。用數(shù)據(jù)庫記錄缺陷的好處是測試人員和開發(fā)人員能夠通過動態(tài)的信息發(fā)布和獲取進行更好的交互，提高測試和修改的工作效率。經(jīng)過修改后的系統(tǒng)再次經(jīng)過測試即是回歸測試。第8章測試實踐

測試結束后要及時總結分析測試結果。測試結果的總結與分析一方面是提供一個系統(tǒng)功能、性能和穩(wěn)定性等方面的完整的分析和結論，另外要對測試過程本身做出總結，總結成功的經(jīng)驗和失敗的教訓，以使日后的工作開展得更順利。具體的測試總結詳見8.6節(jié)。第8章測試實踐8.3.3系統(tǒng)測試系統(tǒng)測試是在真實或模擬系統(tǒng)運行的環(huán)境下，檢查完整的程序系統(tǒng)能否和系統(tǒng)（包括硬件、外設、網(wǎng)絡和系統(tǒng)軟件、支持平臺等）正確配置、連接，并滿足用戶需求。第8章測試實踐

系統(tǒng)測試也應該經(jīng)過測試準備、測試計劃、測試設計、測試執(zhí)行和測試總結5個階段，每個階段所做工作內容與集成測試很相似，只是關注點有所不同。在HIS系統(tǒng)的系統(tǒng)測試中，要搭建更真實的運行環(huán)境，另外還要在不同的操作系統(tǒng)下進行測試，如數(shù)據(jù)庫服務器分別搭建在UNIX環(huán)境和WINNT環(huán)境下長時間多客戶端并發(fā)運行系統(tǒng)的各項功能，并觀測服務器的承受能力（系統(tǒng)的反應時間，服務器的資源占用情況等）。第8章測試實踐8.3.4驗收測試驗收測試是指在用戶對軟件系統(tǒng)驗收之前組織的系統(tǒng)測試。測試人員都是真正的用戶，在盡可能真實的環(huán)境下進行操作，并將測試結果進行匯總，由相關管理人員對軟件做出評價以及是否驗收的決定。第8章測試實踐HIS系統(tǒng)一般在用戶驗收之前都需要對系統(tǒng)進行一段時間的試運行，因此可以說HIS的驗收測試就是實際的使用（但用戶一般要參與軟件的系統(tǒng)測試，即所謂的

測試，不然用戶是不會放心讓系統(tǒng)試運行的）。因為驗收測試由用戶完成，不同軟件實際應用的差異性又很大，這里就不對其詳加論述了。第8章測試實踐8.4測

試

用例設計

測試用例應由測試人員在充分了解系統(tǒng)的基礎上在測試之前設計好，測試用例的設計是測試系統(tǒng)開發(fā)中一項非常重要的內容。集成測試階段測試用例的設計依據(jù)為系統(tǒng)需求分析、系統(tǒng)用戶手冊和系統(tǒng)設計報告等相關資料的內容，而且測試人員要與開發(fā)人員充分交互。另外有一些內容由測試人員的相關背景知識、經(jīng)驗、直覺等產生。第8章測試實踐

測試用例的設計需要考慮很周全。在測試系統(tǒng)功能的同時，還要檢查系統(tǒng)對輸入數(shù)據(jù)（合法值、非法值和邊界值）的反應，要檢查合法的操作和非法的操作，檢查系統(tǒng)對條件組合的反應等。好的測試用例讓其他人能夠很好地執(zhí)行測試，能夠快速地遍歷所測試的功能，能夠發(fā)現(xiàn)至今沒有發(fā)現(xiàn)的錯誤。所以測試用例應該由經(jīng)驗豐富的系統(tǒng)測試人員來編寫，對于新手來說，應該多閱讀一些好的測試用例，并且在測試實踐中用心去體會。第8章測試實踐

在編寫測試用例之前，應該給出測試大綱，大綱基本上是測試思路的整理，以保證測試用例的設計能夠清晰、完整而不是顧此失彼。測試大綱可以按照模塊、功能點、菜單和業(yè)務流程這樣的思路來策劃。本節(jié)給出“醫(yī)院信息管理系統(tǒng)1.0”的“門診掛號管理子系統(tǒng)”的測試大綱和測試用例的主體部分。第8章測試實踐8.4.1掛號管理子系統(tǒng)測試大綱8.4.2其他可用性測試檢查標準軟件產品的可用性是指軟件產品能否讓用戶更快更容易地完成工作，即軟件是否易學、易用，并使用戶感到滿意。軟件產品的可用性主要反映在軟件產品的用戶界面及操作過程上減少錯誤出現(xiàn)，提高用戶工作效率，增加用戶滿意度。第8章測試實踐

對于開發(fā)商而言可以縮減服務和培訓費用，提高用戶滿意度。軟件可用性已經(jīng)越來越引起用戶和開發(fā)商的關注?？捎眯詼y試對所有功能模塊來說，檢測標準是相同的，而這些檢測在功能測試的同時即可檢驗，所以不再設計單獨的測試用例。第8章測試實踐8.4.3功能測試用例1．普通掛號，要病歷本的測試用例2．預約掛號，老患者，不要病歷本的測試用例3．預約掛號，不要病歷本，無掛號費有診察費的測試用例第8章測試實踐4．有掛號費無診察費，要病歷本的測試用例5．退號，不退病歷本的測試用例6．退號測試用例，包括病歷本的測試用例7．掛號員結算的測試用例8．掛號員結算補打的測試用例

第8章測試實踐8.4.4性能測試用例第8章測試實踐8.5缺

陷

報

告

這里給出一個利用數(shù)據(jù)作缺陷記錄報告的實例。錯誤跟蹤數(shù)據(jù)庫可以自己開發(fā)，也可以購買現(xiàn)成的產品。第8章測試實踐8.5.1建立缺陷報告數(shù)據(jù)庫缺陷報告數(shù)據(jù)庫應該在測試工作的準備配置階段就建立起來，測試執(zhí)行階段，測試人員、開發(fā)人員和項目管理評估人員可以采用各種方式通過缺陷報告數(shù)據(jù)庫進行交互，而可以自行開發(fā)一個小系統(tǒng)，使得數(shù)據(jù)庫能夠記錄下人們訪問數(shù)據(jù)庫的一切活動。先設計一個缺陷記錄的數(shù)據(jù)表結構。第8章測試實踐8.5.2編寫缺陷報告關于測試人員、系統(tǒng)開發(fā)人員和相關問題評審人員打開、讀取和寫入缺陷報告數(shù)據(jù)庫，以何種形式并不重要，重要的是對于問題的描述應該是完整的、嚴謹?shù)摹⒑啙嵉?、清晰的和準確的。第8章測試實踐

下面列出編寫好的錯誤報告的幾個要點（也是測試執(zhí)行應該遵循的一些原則）。（1）再現(xiàn)：盡量三次再現(xiàn)故障。如果問題是間斷的，那要報告問題發(fā)生頻率。（2）隔離：確定可能影響再現(xiàn)的變量，例如配置變化、工作流、數(shù)據(jù)集，這些都可能改變錯誤的特征。第8章測試實踐

（3）推廣：確定系統(tǒng)其他部分是否可能出現(xiàn)這種錯誤，特別是那些可能存在更加嚴重特征的部分。（4）壓縮：精簡任何不必要的信息，特別是冗余的測試步驟。（5）去除歧義：使用清晰的語言，尤其要避免使用那些有多個不同或相反含義的詞匯。第8章測試實踐

（6）中立：公正表達自己的意思，對錯誤及其特征的事實進行陳述，避免夸張、幽默或諷刺。（7）評審：至少有一個同行，最好是一個有豐富經(jīng)驗的測試工程師或測試經(jīng)理，在你遞交錯誤報告之前先讀一遍。為了說明一個基本的測試缺陷報告應該具有的內容，截取了本章所介紹案例HIS1.0中掛號管理子系統(tǒng)集成測試缺陷報告中的一頁，如圖8-5所示。第8章測試實踐圖8-5測試缺陷報告示例第8章測試實踐8.6測試結果總結分析8.6.1測試總結報告圖8-6所示的是測試總結報告的一個模板，各行業(yè)、各階段的軟件測試會有具體不同的總結報告，但基本上應該有本模板所展示的項目。第8章測試實踐圖8-6測試總結報告的一個模板第8章測試實踐8.6.2測試用例分析對工作的及時總結，會及時調整方向，大大提高工作效率。測試工作的效果要直接依賴測試用例的編寫和執(zhí)行狀況，所以在測試過程中和測試結束后都要對關于測試用例的一些重要值進行度量。第8章測試實踐

關于測試用例的分析，通常包括以下的內容：計劃了多少個測試用例，實際運行了多少？有多少測試用例失敗了？在這些失敗的測試用例中，有多少個在錯誤得到修改后最終運行成功了？這些測試平均占用的運行時間比預期的長還是短？第8章測試實踐

有沒有跳過一些測試？如果有，為什么？測試覆蓋了所有影響系統(tǒng)性能的重要事件嗎？等等。這些問題都可以從相關的測試用例的設計和測試問題記錄中找到相應的答案。當然，如果使用了數(shù)據(jù)庫，這些問題就更能輕松地被解答了。測試用例的分析報告可以以多種形式體現(xiàn)出來：文字描述、表、圖等。第8章測試實踐8.6.3軟件測試結果統(tǒng)計分析軟件問題統(tǒng)計與分析，在對軟件產品測試過程中發(fā)現(xiàn)的問題進行充分分析、歸納和總結的基礎上，由全體參與測試的人員完成“軟件問題傾向分析表”，對該軟件或該類型系統(tǒng)軟件產品在模塊、功能及操作等方面出錯傾向及其主要原因進行分析。軟件問題傾向分析表將為以后開發(fā)工作提供一個參考，使開發(fā)人員根據(jù)軟件問題傾向分析表明確在開發(fā)過程中應注意和回避的問題。該表也可為以后的測試工作明確測試重點提供依據(jù)。第8章測試實踐

圖8-7表達的是軟件的不同版本在測試時檢測出的缺陷(Bug)數(shù)的對應關系。這里的版本指的是同一軟件經(jīng)過不同的測試階段并修復Bug及作必要的調整后所產生的軟件產品。顯然，該圖所表達的測試結果的變化是非常理想的。第8章測試實踐圖8-7按版本統(tǒng)計結果示例第8章測試實踐

圖8-8表達的是在一個測試階段所發(fā)現(xiàn)的缺陷數(shù)與測試日期之間的對應關系。測試過程中所發(fā)現(xiàn)的缺陷是隨著時間的推移而增多的，但一段時間后，測試所發(fā)現(xiàn)的缺陷增加會漸緩，甚至沒有增加，如果測試還在進行，那么表明，在現(xiàn)有測試用例、軟硬件環(huán)境及相關條件下已經(jīng)很難再發(fā)現(xiàn)新的缺陷了（雖然可以肯定系統(tǒng)中仍然存在缺陷），那么這個測試階段應該考慮停止了。第8章測試實踐圖8-8按日期統(tǒng)計結果示例第8章測試實踐

圖8-9表達的是測試中所發(fā)現(xiàn)的不同等級的缺陷的數(shù)目。關于A、B、C、D等級（或者還有E、F、G、…）所表達的不同含義由相關測試和開發(fā)人員來制定，而這種按等級的統(tǒng)計結果可以清楚地反映開發(fā)工作中的薄弱之處。第8章測試實踐圖8-9按等級統(tǒng)計結果示例第8章測試實踐

圖8-10表達的是測試所發(fā)現(xiàn)的缺陷數(shù)目與究其原因缺陷所屬的軟件工程的不同階段之間的關系。這個圖表會又一次驗證軟件工程的任何階段都會有導致程序中產生錯誤的因素，只是程度和數(shù)目不同而已。通過該圖表的分析，可以清楚地看到，軟件工程中的哪個階段更應該加強控制。第8章測試實踐圖8-10按原因統(tǒng)計結果示例第8章測試實踐

圖8-11表達的是程序的不同模塊與在其中所發(fā)現(xiàn)的缺陷數(shù)目之間的關系。缺陷的產生有多方面的原因，但也可以從該圖中反映出哪些程序員所開發(fā)的模塊中Bug很多，而另一些程序員的則很少，那么在相同的系統(tǒng)設計和工作條件下，這也反映了程序員的工作能力或者責任感的不同。第8章測試實踐圖8-11按模塊統(tǒng)計結果示例第8章測試實踐

圖8-12表達的是在測試過程中每日發(fā)現(xiàn)的錯誤報告公開、關閉的對應關系圖。公開是指錯誤被發(fā)現(xiàn)并被公告，關閉則指錯誤已被處理完畢的狀況。圖中中間兩條粗線反映的是錯誤累計公開和累計關閉的實際狀況。隨著時間的推移，累計公開和累計關閉的錯誤數(shù)目都是漸增的，但到某個時間點，兩條曲線會會合，即累計公開的數(shù)目等于累計關閉的數(shù)目，那就是說所有發(fā)現(xiàn)的錯誤都得到了處理。第8章測試實踐圖8-12按公開/關閉日期統(tǒng)計圖表第8章測試實踐

圖8-13表達的是錯誤原因分析，其中縱軸表達的是每類測試發(fā)現(xiàn)錯誤占所有錯誤的百分比。可以看出，只有每個錯誤都被明確細致地歸類后才能得到這樣的分析圖表，也才能知道該從哪里去控制以減少錯誤的產生。第8章測試實踐圖8-13錯誤原因分析第8章測試實踐

圖8-14表達的是對系統(tǒng)性能測試所產生的分析數(shù)據(jù)、圖和簡單的結論。這種分析是在系統(tǒng)經(jīng)過性能測試后所必不可少的。性能測試的分析一般從并發(fā)用戶數(shù)、系統(tǒng)響應時間以及CPU的利用率幾方面來表述。第8章測試實踐圖8-14系統(tǒng)響應時間與用戶數(shù)對比分析（性能測試結