1、軟 件 描 述 文 檔 產品名稱公司名稱軟件基本信息產品名稱公司名稱1、產品標識：軟件標識：軟件名稱： 軟件型號及版本號： 制造商： 公司生產地址： 2、安全性級別是一種軟件，所以隨之而來的軟件安全性問題也極為重要。 (a)軟件是一種抽象的邏輯產品，其存在形式是虛擬和動態的.(b)軟件質量的測度十分困難，其質量的控制重點在軟件的需求分析和設計階段，開發過程中產生錯誤的難以追蹤；(c)硬件有老化現象，失效曲線似浴盆，硬件的維護可通過糾錯、修復或更換失效的系統重新恢復功能。而軟件的維護復雜，只有通過修改代碼來排錯。同時軟件可能在使用中隨著缺陷的發現和消除，而使性能提高。軟件的修改看似比硬件容易，卻

2、比硬件更難于控制。看上去無關緊要的軟件代碼修改會在軟件的其他地方引起無法預測的、十分關鍵的問題；(d)軟件的失效防護困難。對硬件可采用預防性維護技術預防故障，采用斷開失效部件的辦法診斷故障，而軟件則不能采用這些技術；但軟件的失效會毫無征兆的出現，會因執行一條未經驗證的路徑而出現故障；而同一軟件的冗余不能提高可靠性。(e)軟件的失效是系統性失效，其失效的條件有時比較復雜。因此，可能會無法清晰地洞察其原因，而誤歸結其為系統中硬件的隨機失效。導致無法及時排除軟件中的故障，造成隱患的長期存在。以上論述了軟件的復雜性，以及出現問題無法預測性和軟件的實效防護困難。軟件一旦出現問題則很可能導致患者或者對患者

3、造成嚴重的傷害，例如，軟件一旦在運行過程中失效，機器停止工作則很可能導致患者由于而變為，所以軟件安全性級別為級。3、功能結構上位機程序功能描述：下位機：a）功能模塊網絡：c）下位機程序框圖1） 上位機a）功能模塊網絡：b）上位機程序框圖：4、硬件關系5、運行環境5.1硬件配置：5.2軟件運行環境6、適應范圍6.1軟件組件整體的功能用途6.2醫療器械的適用范圍7、禁忌癥8、上市歷史軟件實現過程產品名稱公司名稱1、 開發綜述1.1 嵌入式開發平臺 1.1.1 單片機的開發平臺 1.2分析測控系統在進行單片機應用系統開發時，首先要對該測控系統進行可行性分析以及系統總統方案設計。1.2.1可行性分析可

4、行性分析主要是分析整個設計任務的可能性。 1.2.2系統總體方案設計當完成可行性分析后，便進入系統整體方案設計階段。這里，主要結合國內外相關產品的技術參數和功能特性、本系統的應用要求以及現有條件，來決定本設計所要實現的功能和技術指標。接著，制定合理的計劃，編寫設計任務書，從而完成該單片機應用系統的總體方案設計。 1.3器件選型 1.4硬件資源分配1.5程序設計1.6仿真測試1.7實際硬件測試2需求規格2.1編寫目的 1. 2. 2.2背景 1. 2. 用戶：醫務專業人員 3. 實現：公司 4. 構建平臺：2.3定義1. 2.3. 4. 5. 6. 2.4對功能的規定1 功能劃分 1. 2. 3

5、. 4. 5. 6. 7. 8. 2 功能描述 1.： 2. 短；3. 4. 5. 6. 7. 8. 2.5對性能的規定2.5.1精度2.5.2時間特性要求新一次。2.5.3輸入輸出要求2.5.4警示信息3.軟件的生存周期1.確定軟件開發的可行性與計劃此階段是軟件開發方與需求方共同討論，主要確定軟件的開發目標及其可行性。在軟件開發的可行性研究與計劃階段內，要確定該軟件的開發目標和總的要求，要進行可行性分析、投資一收益分析、制訂開發計劃。 這個階段我們需要編制項目開發計劃。到了編制項目開發計劃階段，我們要明白編制項目開發計劃的目的是用文件的形式，把對于在開發過程中各項工作的負責人員、開發進度、所

6、需經費預算、所需軟、硬件條件等問題作出的安排記載下來，以便根據本計劃開展和檢查本項目的開發工作。2.對所開發的軟件需求進行分析 在確定軟件開發可行的情況下，對軟件需要實現的各個功能進行詳細分析。需求分析階段是一個很重要的階段，這一階段做得好，將為整個軟件開發項目的成功打下良好的基礎。”唯一不變的是變化本身。”，同樣需求也是在整個軟件開發過程中不斷變化和深人的，因此我們必須制定需求變更計劃來應付這種變化，以保護整個項目的順利進行。 這個階段我們需要編寫軟件需求說明書和數據要求說明書。編制軟件需求說明書是為了使用戶和軟件開發者雙方對該軟件的初始規定有一個共同的理解，使之成為整個開發工作的基礎。內容

7、包括對功能的規定對性能的規定等。這個階段，我們可以通過編制數據要求說明書，來向整個開發時期提供關于被處理數據的描述和數據采集要求的技術信息。3.軟件開發的設計階段 此階段主要根據需求分析的結果，對整個軟件系統進行設計，如系統框架設計，數據庫設計等等。軟件設計一般分為總體設計和詳細設計。好的軟件設計將為軟件程序編寫打下良好的基礎。這個結算我們需要編寫概要設計說明書、詳細設計說明書、數據庫設計說明書和測試計劃初稿。概要設計說明書:概要設計說明書又可稱系統設計說明書，這里所說的系統是指程序系統。編制的目的是說明對程序系統的設計考慮，包括程序系統的基本處理流程、程序系統的組織結構、模塊劃分、功能分配、

8、接口設計。運行設計、數據結構設計和出錯處理設計等，為程序的詳細設計提供基礎。詳細設計說明書:詳細設計說明書又可稱程序設計說明書。編制目的是說明一個軟件系統各個層次中的每一個程序(每個模塊或子程序)的設計考慮，如果一個軟件系統比較簡單，層次很少，本文件可以不單獨編寫，有關內容合并人概要設計說明書。數據庫設計說明書:數據庫設計說明書的編制目的是對于設計中的數據庫的所有標識、邏輯結構和物理結構作出具體的設計規定。測試計劃初稿:這里所說的測試，主要是指整個程序系統的組裝測試和確認測試。本文件的編制是為了提供一個對該軟件的測試計劃，包括對每項測試活動的內容、進度安排、設計考慮、測試數據的整理方法及評價準

9、則。4.實現階段 此階段是將軟件設計的結果轉換成計算機可運行的程序代碼。在程序編碼中必須要制定統一，符合標準的編寫規范。以保證程序的可讀性，易維護性，提高程序的運行效率。這個階段我們需要編寫模塊開發卷宗和用戶手冊完工操作手冊。模塊開發卷宗(開始編寫):模塊開發卷宗是在模塊開發過程中逐步編寫出來的，每完成一個模塊或一組密切相關的模塊的復審時編寫一份，應該把所有的模塊開發卷宗匯集在一起。編寫的目的是記錄和匯總低層次開發的進度和結果，以便于對整個模塊開發工作的管理和復審，并為將來的維護提供非常有用的技術信息。用戶手冊完工操作手冊:操作手冊的編制是為了向操作人員提供該軟件每一個運行的具體過程和有關知識

10、，包括操作方法的細節。5.測試階段 在軟件設計完成后要經過嚴密的測試，以發現軟件在整個設計過程中存在的問題并加以糾正。整個測試過程分單元測試、組裝測試以及系統測試三個階段進行。測試的方法主要有白盒測試和黑盒測試兩種。在測試過程中需要建立詳細的測試計劃并嚴格按照測試計劃進行測試，以減少測試的隨意性。這個階段我們需要編寫模塊開發卷宗和項目開發總結報告。 模塊開發卷宗(此階段內必須完成)測試分析報告:測試分析報告的編寫是為了把組裝測試和確認測試的結果、發現及分析寫成文件加以記載。項目開發總結報告:項目開發總結報告的編制是為了總結本項目開發工作的經驗，說明實際取得的開發結果以及對整個開發工作的各個方面

11、的評價。6.運行與維護階段 軟件維護是軟件生命周期中持續時間最長的階段。在軟件開發完成并投人使用后，由于多方面的原因，軟件不能繼續適應用戶的要求。要延續軟件的使用壽命，就必須對軟件進行維護。軟件的維護包括糾錯性維護和改進性維護兩個方面。總之，失敗的軟件項目各有其失敗，而成功的軟件項目都一樣:離不開規范的軟件開發過程。想要設計出優秀的，適合實際需要的軟件作品，科學規范的軟件開發流程是必須遵守的。當然，軟件開發工作也需要與時俱進，這一套軟件開發六部曲也并不是永遠適用的。我們需要在平時的工作中多多總結，才能做到與時俱進，才能一直保持，實現科學的軟件開發。4.軟件的驗證和確認軟件測試工作量往往占軟件開

12、發總工作量的40%以上。軟件測試之所以在軟件生命周期占有如此重要地位，是因為它貫穿了軟件定義與開發的整個生命周期，是軟件質量保證的重要手段。需求分析、概要設計、詳細設計以及源程序，都應成為軟件測試的對象。與開發過程類似，測試過程也需要分步驟進行，后一個步驟在邏輯上是前一個步驟的繼續。在眾多測試中，確認測試檢查軟件能否按合同要求進行工作，即是否滿足軟件需求說明書中的確認標準，是軟件發布之前不可或缺的重要測試之一。軟件測試階段的劃分模型單元測試，是在程序編碼階段對各單元模塊進行單獨的測試，旨在及時發現并糾正程序單元中暗藏的缺陷。集成測試主要是考察模塊的集成，包括這些模塊組成的 (子)系 統的功能、

13、性能及其外部接口等質量特性。確認測試，是根據軟件需求規格說明中對功能性需求和非功能性需求的描述,考察軟件各項特征是否符合要求。系統測試，則是測試由軟件和硬件集成的完整系統，以檢查其 是否符合需求 。4.1測試方法我們采用了以下兩種方法來測試軟件：(1)等價類劃分：把程序的輸入域劃分成數據類，據此可以導出測試用例，一個理想的測試用例能獨自發現一類錯誤。(2)邊值分析：確定程序處理的邊界情況，設計使程序運行在邊界情況附近的測試方案。諸如：下標、純量、數據結構和循環等邊界附近 。4.2系統測試計劃見附件4.3用戶測試計劃見附件5.核心算法1）上位機程序核心算法：數字濾波無需其他的硬件成本，只用一個計

14、算過程，可靠性高，不存在阻抗匹配問題。尤其是數字濾波可以對頻率很低的信號進行濾波，這是模擬濾波器做不到的。數字濾波使用軟件算法實現，多輸入通道可共用一個濾波程序，降低系統開支。只要適當改變濾波器的濾波程序或運算，就能方便地改變其濾波特性，這對于濾除低頻干擾和隨機信號會有較大的效果。本程序是采用的是數字濾波算法中的算術平均濾波算法，該算法的基本原理很簡單，就是連續取N次采樣值后進行算術平均。說明：算術平均濾波算法適用于對具有隨機干擾的信號進行濾波。這種信號的特點是有一個平均值，信號在某一數值附近上下波動。信號的平均平滑程度完全到決于N值。當N較大時，平滑度高，靈敏度低；當N較小時，平滑度低，但靈

15、敏度高。為了方便求平均值，N一般取4、8、16、32之類的2的整數冪，以便在程序中用移位操作來代替除法。波形從左走到右，需要18s；縱坐標一共140點，20個點代表1kPa。選擇20個點作為1kPa，每次刷新波形時候，先把壓力軸從上到下清除（即用屏幕底色填充），在把當前壓力值換算到縱坐標上，從當前點畫藍色線一直到時間軸上。隨著時間的推移，便產生了藍色的填充的壓力波形。當時間軸到了最大值時，回到最小值。壓力軸范圍為-1到6kPa，壓力數值超出了上下限范圍后，就強制把波形置為-1或6kPa。流速波形也是采用的數字濾波中的算術平均算法，波形縱坐標代表流速值，橫坐標代表時間。時間軸每50ms更新一次，

16、一共360點，波形從左走到右，需要18s；縱坐標一共140點，分為上下半軸，各占70個點，上半軸為吸氣波形，下半軸為呼氣波形。每次刷新波形時候，先把流速軸從上到下清除（即用屏幕底色填充），每隔50ms采集一次流速值，即50ms之內累加的脈沖數換算為流速值，在根據當前是吸氣還是呼氣狀態，把流速值換算到縱坐標上，從當前點畫淺藍色線一直到時間軸上。隨著時間的推移，便產生了淺藍色的填充的流速波形。當時間軸到了最大值時，回到最小值。流速軸范圍為0-70，流速數值超出了上下限范圍后，就強制把波形置為70。2）下位機程序核心算法下位機潮氣量的算法：由于打氣的氣流不是一個恒定的流速，所以采用了積分的算法，即氣

17、流流速的積分等于潮氣量。上圖曲線為潮氣量流速波形，x代表時間，y代表流速。潮氣量則為陰影部分的面積，采用積分算法在【a，b】內插入若干個分點 a=x0x1x2x3xn-1xn =b1.把【a，b】分成n個小區間【xi-1 ,xi】長度為xi =xi -xi-1；2.近似替代：在每個【xi-1 ,xi】上任取一點i，以【xi-1 ,xi】為底，f（i）為速度的小矩形面積為A= f（i）xi3.求和：面積的近似值為Ani=1 f（i）xi4.取極限：當分割無線加細，即小區間的最大長度=maxx1，x2，x3，xn 0時，有小矩形面積和ni=1 f（i）xi A，即可達到積分計算公式也就是潮氣量計算

18、公式0A=limni=1 f（i）xi軟 件風 險 管 理 報 告 產品名稱公司1.概要：軟件風險概述： 使軟件項目的實施受到影響和損失、甚至導致失敗的、可能會發生的事件 例如，人員的臨時流失，計劃過于樂觀，設計的低劣軟件風險的特點 事先難以確定 帶來損失，影響項目實施，甚至會導致項目失敗風險管理的組成風險評估 風險識別：識別風險，形成風險列表 風險分析：判定每一個風險出現的概率、產生的影響及其重要性 風險優先級：按照每個風險的重要性排出一個風險優先級風險評估是風險控制的基礎風險控制 風險管理計劃：針對各個重要風險制定風險管理計劃，確保各個單獨的風險管理計劃之間以及它們與相互計劃之間的一致性

19、風險化解：執行風險管理計劃，以緩解或消除風險 風險監控：監控風險化解的過程，可能會識別出新的風險2.風險評估2.1風險識別n 風險的類別 計劃編制 組織和管理 開發環境 最終用戶 客戶 需求 產品外部環境 人員 設計和實現 過程2.1.1計劃編制風險n 計劃、資源和產品的定義完全由客戶或上層領導決定，忽略了項目組的意見，并且這些決定不完全一致n 計劃忽略了必要的任務和活動n 計劃不切實際n 計劃基于特定小組成員，而這樣的小組成員根本得不到n 產品規模估算過于樂觀n 工作量估算過于樂觀n 進度的壓力造成生產率的下降n 目標日期提前，但沒有相應地調整產品范圍和可用資源n 一個關鍵任務的延遲導致其他

20、相關任務的連鎖反應2.1.2組織和管理風險n 缺乏強有力、有凝聚力的領導(項目組、企業)n 解雇員工導致項目小組能力下降n 削減預算打亂項目計劃n 僅由管理層和市場人員進行技術決策，導致進度延長n 低效的項目組組織結構降低生產率n 管理層審查/決策的周期比預期時間長n 管理層作出了打擊項目組積極性的決定n 非技術的第三方的工作比預期要長(如, 采購硬件設備)n 計劃性太差，無法適應期望的開發速度n 項目計劃由于壓力而放棄，導致開發混亂n 管理方面的英雄主義，忽視客觀確切的狀態報告，降低發現和改正問題的能力2.1.3開發環境風險n 設施不能及時到位n 設施到位，但不配套n 開發工具未能及時到位n

21、 開發工具不如期望的那樣有效，開發人員需要更多的時間，或者更換工具n 開發工具的學習期比預期的要長n 開發工具的選擇不是基于技術需求，不能提供計劃要求的功能2.1.4最終用戶風險n 最終用戶堅持新的需求n 最終用戶對最后交付的產品不滿意，要求重新設計和重做n 最終用戶不買進項目產品，無法提供后續支持n 最終用戶的意見未被采納，造成產品最終無法滿足用戶要求2.1.5客戶風險n 客戶堅持新的需求n 客戶對規劃、原型和規格的審核/決策超出預期n 客戶沒有參與規劃、原型和規格的審核，導致需求不穩定，以及長時間的變更n 客戶答復的時間比預期的要長n 客戶堅持技術決策而導致計劃延長n 客戶對開發進度管理過

22、細，導致實際進度變慢n 客戶提供的組件無法與開發的產品匹配，導致需要額外的設計和集成工作n 客戶提供的組件質量欠佳，導致額外的測試、設計或者功能不完善n 客戶要求的支持工具與環境不兼容，性能差或者不完善，導致生產率降低n 客戶不接受交付的軟件，盡管它滿足了所有的規格n 客戶期望的開發速度是開發人員所無法達到的2.1.6需求風險n 需求已經成為項目基準，但仍在變化n 需求定義欠佳：不清晰、不準確、不一致n 增加額外的需求2.1.7產品風險n 錯誤發生率高的模塊，需要更多的時間對它進行測試、設計和實現n 矯正質量低下的不可接受的產品需要更多的時間對它進行測試、設計和實現n 由于功能錯誤，導致需要重

23、新進行設計和實現n 開發額外不需要的功能延長了進度n 要滿足產品規模和速度要求，需要更多的時間n 嚴格要求與現有系統兼容，需要更多的時間n 要求軟件重用，需要更多的時間2.1.8外邊環境風險n 產品依賴政府規章，而規章的改變不可預期n 產品依賴草擬中的技術標準，而最后的標準不可預期2.1.9人員風險n 招聘人員所需的時間比預期要長n 作為人員參與工作的先決條件(如培訓、其他項目的完成等)不能按時完成n 開發人員與管理層關系不佳導致決策遲緩、影響全局n 項目組成員沒有全身心地投入到項目中，因而無法達到所需的產品功能和性能需求n 缺乏激勵措施、士氣低下，降低生產能力n 缺乏必要的規范，增加工作失誤

24、，重復工作，降低工作質量n 缺乏工作基礎(語言、經驗、工具等)n 項目結束前，項目組成員離開項目組n 項目后期，加入新的開發人員，額外的培訓和溝通降低了項目組成員的開發效率n 項目組成員不能有效的在一起工作n 由于項目組成員之間的沖突，導致溝通不暢，設計欠佳，接口錯誤和額外重復的工作n 有問題的項目組成員沒有調離項目組，影響其他成員的積極性n 項目組的最佳人選沒有加入項目組，或者加入項目組但沒有合理使用n 關鍵任務只能兼職參與n 項目人員不足n 任務的分配和人員的技能不匹配n 人員工作的進展比預期的要慢n 項目管理人員怠工導致計劃和進度失效n 技術人員怠工導致工作遺漏、質量低下，工作需要重做2

25、.1.10設計和實現風險n 設計過于簡單，考慮不仔細、不全面，導致重新設計和實現n 設計過于復雜，導致一些不必要的工作，影響效率n 設計質量低下，導致重新設計和實現n 使用不熟悉的方法，導致需要額外的培訓時間n 產品使用低級語言編寫，導致效率較低n 分別開發的模塊無法有效集成，需要重新設計和實現2.1.11過程風險n 跟蹤不準確，導致無法預知項目進展是否落后于計劃n 前期的質量保證行為不真實，導致后期的重復工作n 質量跟蹤不準確，導致無法得知影響進度的質量問題n 不能有效遵循標準，導致溝通不足，質量問題和重復工作n 風險管理粗心，導致沒有發現重大的項目風險3.風險列表編號風險名稱1計劃過于樂觀

26、2由于要完全支持自動從主機更新數據而照成額外的需求3由于市場變化而需額外的需求4圖形格式子系統接口不穩定5設計欠佳，需要重新設計4.風險分析4.1評估風險發生的概率n 主觀性較強，采用方法 熟悉系統、有經驗的人參與評估 多人獨立評估，綜合折中 采用分類：非常可能(0.8-1.0), 很可能(0.6-0.8)，或許(0.40.6)，不太可能(0.2-0.4)，不可能(0-0.2)編號風險名稱概率1計劃過于樂觀50%2由于要完全支持自動從主機更新數據而照成額外的需求5%3由于市場變化而需額外的需求35%4圖形格式子系統接口不穩定25%5設計欠佳，需要重新設計15%4.2評估風險發生造成的損失n 可

27、以基于“進度”，“成本”或者“工作量”來進行估算編號風險名稱概率損失（人周）1計劃過于樂觀50%52由于要完全支持自動從主機更新數據而照成額外的需求5%203由于市場變化而需額外的需求35%84圖形格式子系統接口不穩定25%45設計欠佳，需要重新設計15%154.3計算風險危險度風險危險度 = 風險概率 風險損失編號風險名稱概率損失（人周）危險度1計劃過于樂觀50%52.52由于要完全支持自動從主機更新數據而照成額外的需求5%201.03由于市場變化而需額外的需求35%82.84圖形格式子系統接口不穩定25%41.05設計欠佳，需要重新設計15%152.254.4風險優先級n 統計表明，項目8

28、0%成本用于解決20%的問題n 風險管理重點關注20重要的部分n 根據風險的危險度確定風險的重要性，忽略其他的部分編號風險名稱概率損失（人周）危險度3由于市場變化而需額外的需求35%82.81計劃過于樂觀50%52.55設計欠佳，需要重新設計15%152.252由于要完全支持自動從主機更新數據而照成額外的需求5%201.04圖形格式子系統接口不穩定25%41.05.風險監控n 檢查風險的化解程度及其變化(概率、損失)n 風險監控的方式 監控和跟蹤重要的(前10個)風險，記錄風險危險度的變化以及風險化解的進展 中間審查，在每個里程碑后進行小規模的走查 任命風險官員(適合于大項目)，警告項目風險，

29、防止項目經理和開發人員忽略計劃中的風險管理軟 件 集 成 測 試 計 劃 產品名稱公司1 目的軟件集成測試計劃用于明確軟件產品確認測試過程中測試設計、測試執行及測試總結工作的具體任務分解、人員安排、進度及輸出結果。以使整個測試工作有計劃地順利進行。本文規定了測試的編寫格式及要求。2適用范圍本規范適用于軟件項目與軟件產品的集成測試活動。3職責3.1 項目負責人：負責集成測試計劃的審批。3.2 開發人員： 負責編制集成測試計劃。4集成測試計劃規范4.1集成測試一般集中于各個模塊接口間的測試。集成測試界于單元測試和系統測試之間。集成測試內容必須源于系統設計報告。集成測試著重于集成版本的外部接口的行為

30、。因此，測試需求須具有可觀測、可測評性。4.2 集成測試計劃制定的時間 在系統設計報告完成之后，依據系統設計報告制定集成測試計劃。類別遞交時間制定者審批者集成測試計劃在系統設計階段就可以起草，最遲可在實現階段之初遞交。開發人員項目負責人4.3 集成測試計劃內容：1）明確測試所需要的資源（人員、人員的任務分派、各小組的聯系人、時間進度、team里面的各種server、Lab環境等等），各種支持資源由誰負責維護等。2）明確測試策略。就是什么測，什么不測。測的東西，測到什么程度，是不是用自動化，等等。若有本次測試不涉及的地方，需在測試計劃里注明：哪些內容不測、不測的原因是什么。3）必須列明產品通過的

31、準則。4）指明測試中可能遇到的問題與對策 4.4 集成測試計劃制定后，需經過項目相關人員的評審。系 統 測 試 計 劃 產品名稱公司目 錄1目的12適用范圍13圖例說明14規程文檔結構15規程25.1進入準則25.2測試策劃25.2.1流程圖25.2.2活動描述35.3測試設計35.3.1流程圖35.3.2活動描述45.4測試執行45.4.1流程圖45.4.2活動描述55.5缺陷管理65.5.1流程圖65.5.2活動描述75.5.3缺陷等級85.5.4缺陷狀態85.6變更管理95.7退出準則95.8規程接口96文件清單97圖表索引10公司目的使軟件系統測試活動是規范和有計劃的及時對軟件產品進行

32、系統測試，驗證系統是否滿足需求規格的定義，找出與需求規格不相符合或與之矛盾的地方測試中發現的缺陷保證被記錄、跟蹤直到關閉；對項目的缺陷數據進行量化的分析適用范圍本規程適用于以下人員項目經理軟件測試組軟件項目組配置管理工程師圖例說明在本文中用到了以下圖例，特此說明：過程：用于描述要執行的活動和過程； 判定點：用于描述流程中是否滿足某個條件后的分流點； 接口：用于描述引用的接口規程； 文檔：用于描述輸入、輸出的文檔； 開始節點：用于表示流程的入口； 結束節點：用于表示流程的結束；規程文檔結構圖表1：規程文件結構文檔結構圖說明：1系統測試計劃是根據項目的規模和重要性來確定，是可裁減的。一般來說，系統

33、測試進度計劃是必須的。但對于公司認定的小項目，可以沒有系統測試進度計劃，具體要求按照公司的相關規定小項目軟件過程管理指南執行；2系統測試用例在測試管理工具TestDirector中進行編寫和管理，可以根據需要導出到Word；3項目組可根據系統的實際需要，通過提交功能或兼容性或性能測試任務單來啟動相應的測試任務，后二者的測試一般都需要在完成功能測試的基礎上才可執行；4缺陷記錄跟蹤表是指從TestDirector里導出缺陷記錄到Excel時的文件格式，測試中發現的缺陷都將使用TestDirector來進行記錄、跟蹤和管理；規程進入準則項目啟動，并由項目經理與部門（高級）經理、測試組組長商量，確定此

34、項目需要安排獨立的測試人員加入。測試策劃流程圖 圖表2：測試策劃流程活動描述系統測試計劃或系統測試進度計劃都需要項目組提供相關的項目文檔作為主要編寫依據；系統測試計劃是可裁剪的，系統測試進度計劃是必須的（小項目除外）；不管有沒有編寫系統測試計劃，都需要對系統測試進度計劃進行評審，以確保時間上能與開發進度相一致，并且保證整個軟件測試活動是有序的；系統測試計劃的評審需要軟件工程組各類成員的代表共同參與（限于篇幅在圖中沒有表達出來，特在此說明），評審的具體形式可根據項目開發計劃中的要求進行；對系統測試進度計劃的評審形式一般為走查；測試設計流程圖圖表3：測試設計流程活動描述系統測試用例的評審需要軟件工

35、程組各類成員的代表共同參與，特別是熟悉需求和設計的代表必須參加，評審的具體形式可根據項目開發計劃中的要求進行；編寫系統測試用例的時候，需要遵循系統測試用例編寫規范上的具體要求。應以系統需求規格說明書作為主要的依據，設計文檔、實際可運行的程序雛形都可作為編寫的輔助材料。在編寫過程中，應多與分析、設計人員溝通，不明確的地方以項目經理的答案作為衡量標準；根據公司的實際情況，測試用例的編寫和評審都將采取迭代的方式進行，逐步完善；在整個設計過程中，可以階段性的部分評審，但在正式測試前應至少完成一次整體性的評審；系統測試用例評審時，測試人員應講解測試用例的編寫思路，主要的關鍵點，并提出不能確定的問題，由熟

36、悉需求和設計的人員進行確認和補充，以達到確保系統測試用例有效覆蓋系統需求的目的；測試組內部走查的時候，需要使用系統測試用例檢查表。測試執行流程圖圖表4：測試執行流程活動描述項目組在單元測試完成后，可提交系統測試的任務。項目經理應在演示前提交系統功能測試任務單，任務單上應列出該版本修改了哪些特征項，以及指明測試的要點和時間要求；測試評估是指，由項目經理或指定人員把系統功能測試任務單上的本次測試的范圍在測試系統中進行功能演示，在演示的同時進行業務重點的講解。在對系統進行第一次演示時，項目組需要結合需求說明的PPT文檔，先對測試人員介紹系統需求以及業務邏輯關系，然后再開始系統的操作演示。雙方對系統的

37、可測試性達成一致后，即可開始測試；如果雙方對可測試性無法達成一致時，則應及時向高級經理反映，并相互協商解決問題；系統提交測試時，一般都需要演示，如果項目組認為不需要演示，則必須經過測試組組長的同意演示任務必須在測試環境中執行，項目組需要將程序發布到測試組的服務器上，在一次測試當中程序不允許更新，具體可參見系統測試環境發布流程。測試組接收測試任務前系統演示要達到的要求：1）演示時沒有任何明顯的錯誤；2）上次測試發現的缺陷都已修改。項目組給測試組系統測試計劃預留時間至少為2天。一輪測試結束后，測試人員應及時將測試結果及主要情況、缺陷統計反饋填寫在系統功能測試任務單上，并提交給項目經理審核。在一個項

38、目中進行多次測試時，每次測試的結果都反饋在系統功能測試任務單上，在整個項目的測試工作完成后，應編寫系統測試總結報告；在項目開里程碑會議的時候，需要提交階段性的系統測試總結報告；測試組組長應對各個項目的系統測試總結報告進行審核，項目組也應對各類測試報告進行走查；測試人員應嚴格按照測試進度計劃的安排，進行測試工作，如果根據項目的實際情況，時間上有差異的，則應盡力配合項目組方面的時間安排，有需要時應主動采取加班等方式來保證按時按質地完成測試任務，必要時可向測試組組長申請加派人手增援；測試人員應嚴格按照測試用例執行測試，并在測試中不斷對測試用例進行完善和補充；項目組可根據系統的實際需要，向測試組提出功

39、能測試以外的測試請求，比如：兼容性測試和性能測試，需要提交相應的兼容性測試任務單或性能測試任務單，這兩種類型的測試不需要演示，只要具備測試條件（一般在完成功能測試的前提下）即可進行。執行性能測試前需要編寫性能測試計劃，跟項目經理或主要開發人員確定性能測試的范圍和各項性能預期指標，編寫性能測試腳本，組織和執行性能測試，并作好觀察和記錄。性能測試一般需要2天的準備時間，所以項目組有性能測試需求時，可盡量提前一些通知測試組，以方便做準備工作。缺陷管理流程圖圖表5：缺陷管理流程活動描述在TD的缺陷庫中新增一個缺陷之前，應先檢查有沒有類似的缺陷已經存在，避免重復。缺陷填寫的詳細要求請參照缺陷填寫規范；在

40、任何情況下，“拒絕”、“暫緩”和“凍結”缺陷的時候，都需要在TD的備注中填寫“拒絕”、“暫緩”或“凍結”的原因；并與測試人員當面溝通，避免因為理解上的偏差或系統版本的偏差等原因而隨意地放過一個缺陷；暫緩缺陷和凍結缺陷，需要經過評審，由產品經理對缺陷定位和解決.在缺陷管理中只有產品經理有權限對缺陷進行“凍結”。對”拒絕”和”暫緩”的缺陷有爭議，測試組可以在系統演示時向項目組提出。對于每條暫緩的缺陷，項目組與測試組協商確定是否需要再測試此類缺陷。原來暫緩和拒絕的缺陷，如果缺陷不存在了，由測試組關閉。測試組每兩個月進行批量關閉。在項目組中只有項目經理具有“Rejected”缺陷的權限；對每一條缺陷需

41、要填寫“原因分析”；當測試人員對項目經理“拒絕”的缺陷有爭議并無法達成一致的時候，可向評審委員會提出申請。評審委員會，是指由高級經理、項目經理、開發、測試以及其他相關的專家組成的評審小組，對有爭議的缺陷進行最終的確認。（評審委員會的成員并不是固定的，而是根據實際情況的需要組成）；從上面的流程圖可以看出，對缺陷的管理實際上就是通過TestDirector來對缺陷的狀態進行變化；也就是說缺陷從產生到關閉都是在TD里進行的，如果需要將缺陷記錄形成文件，可以通過TD來導出到Excel或其他格式的文件；缺陷等級嚴重程度名稱缺陷等級英文名稱描 述建議4Suggestion測試人員對系統的一些建議，不影響系

42、統的使用功能，開發人員可根據實際情況選擇是否修改。高3High功能不能使用或在使用中出現的問題影響了系統的穩定性、造成數據存儲錯誤或將錯誤數據帶入下一環節、一些重要特性或性能不能達到指定的要求等。中等2Medium功能可以使用、在出錯后做出一定處理，操作能夠繼續進行或功能實現有誤，但問題的出現應不影響本功能或其他功能的實質性使用。低1Low用戶界面顯示、對齊、文字錯誤等。具體的缺陷等級示例可以參考“缺陷填寫規范”。圖表6：缺陷等級缺陷狀態狀態名稱英文名稱描 述新發現New是指當測試工程師在執行測試時新發現一個問題的時候的狀態打開Open是指當項目經理把新發現的問題分配給某位開發工程師以后的狀態

43、已修改Fixed是指開發工程師完成被分配問題的修改后的狀態被拒絕Rejected是指項目經理在評審新發現的問題時認為該問題與其他問題重復或者不是一個缺陷的時候，才可以標識為該狀態，并需要說明理由。只要是缺陷都不應被標識為拒絕。重新打開Reopen是指測試工程師對已修改的問題進行驗證時發現該問題仍然存在，則將此問題標識為該狀態已關閉Closed是指測試工程是對已修改的問題進行驗證以后，認為該問題已經修正。暫緩Respite是指項目經理認為需要修改，但因為特殊原因暫緩修改的。該類缺陷需經過評審,，產品經理同意暫緩的缺陷，需寫明原因及修改時間。未修改的暫緩缺陷在項目收尾階段分析、整理后提交到維護組。

44、凍結frozen是指項目組因技術或其它原因而沒法修改并確定不修改的缺陷，該類嚴缺陷需經過評審，同意凍結的，由產品經理標識為該狀態。圖表7：缺陷狀態變更管理在項目的開發過程中，當有影響到測試的變更（如需求變更、開發進度變更）發生的時候，項目經理應及時通知相關的測試人員，測試人員接到變更通知后，應對該次變更情況作出分析，然后根據分析結果，對測試進度計劃或系統測試用例等測試資源進行修改或補充（即將變更部分重新走測試策劃、設計、執行的流程），并采取走查方式跟相關的開發人員進行確認；項目上線后一個月集中以會議形式給測試組演示需求/功能上的變更，在演示后，測試人員根據演示情況更新測試用例。退出準則系統測試用例通過了評審，測試用例達到了有效覆蓋系統所有可測試的需求（功能/特征項）；按照系統測試進度計劃完成了系統測試；測試結果，系統滿足需求規格說明書的要求；在系統測試中發現的缺陷都已經得到合理地處理（理論上只要不是“Rejected”和“frozen”的缺陷都應該被“Closed”）圖表索引圖表1：規程文件結構2圖表2：測試策劃流程3圖表3：測