【文章內容簡介】 030_CN_過程監(jiān)控與質量保證規(guī)程項目_PPQA報告PPQA的審核報告，分為階段審核報告和周期審核報告。60030_CN_過程監(jiān)控與質量保證規(guī)程_項_PPQA計劃. 開發(fā)品質標準為確保項目開發(fā)的質量，公司對提出了下列基本度量指標。根據(jù)項目的具體情況，標準與度量可以派生出更多的度量控制KPI，以保證本項目的實施。. 測試密度與bug檢出率工程要素下限目標上限單元測試試驗密度65105170Bug檢出密度369結合測試1試驗密度163992Bug檢出密度結合測試2試驗密度41550Bug檢出密度說明：252。 測試密度(測試密度是用來衡量測試用例的覆蓋度的指標) 252。 有效源代碼：項目程序中除注釋和空白行之外的源代碼，以文件為單位按物理行計算。包含新規(guī)源代碼、修改的源代碼和自動生成的源代碼。252。 正規(guī)化源代碼行數(shù) 252。 新規(guī)源代碼手工新制作的程序源代碼，不包括測試代碼。252。 自動生成源代碼由編程工具自動生成的代碼。. 問題處置能力標準n 聯(lián)絡應對標準計算公式：響應日時收到日時。聯(lián)絡：包括客戶提出的式樣聯(lián)絡、BUG票、和要求變更。聯(lián)絡響應期間：1個工作日內。n BUG票應對標準n QA缺陷(NC)票應對標準. 評審能力標準以下時間均指初次評審所必需的經(jīng)過時間，如需要再次評審，追加投入的時間可遞減。但總合計值不應超過2倍。1) 設計文檔評審時間標準單位為(分鐘/P)。2) 源代碼評審時間標準單位為(分鐘/KL)。3) Case評審時間標準單位為(分鐘/個(Case個數(shù)))文檔類型審查小組評審走查桌查BDSPEC5～73～53～55～6DDSPEC5～73～53～55～6PGSOURCE①40～6030～4030～5040～60PGSOURCE②600～720450～570600～720SI1CASE10～158～108～1210～15SI2CASE15～2010～1310～1515～20說明1：審查和小組評審的會議前準備時間未計在內。說明2：PGSOURCE①指側重于程序結構、規(guī)范性的代碼評審。PGSOURCE②指側重于查找程序邏輯缺陷的代碼評審。. 任務完成度的進度率標準比率BD/DDPGUTSI1/SI210%理解完理解完了理解完了25%正在制作設計書編碼框架設計完成白盒測試CASE設計完成(評審通過)測試CASE和數(shù)據(jù)制作中50%符合模板要求的設計書完成按照Coding規(guī)約編碼完畢(編譯通過)一個回合的測試完畢，達到預定的覆蓋率CASE及數(shù)據(jù)設計完成(評審通過)75%內部評審完畢，正在解決評審問題DEBUG+源代碼評審完畢，正在解決評審問題BUG對應及復測中一個回合測試完畢，BUG對應中95%評審發(fā)現(xiàn)的問題全部解決評審發(fā)現(xiàn)的問題全部解決BUG全部對應且新版本確認完畢BUG全部對應且新版本確認完畢100%直接管理者承認直接管理者承認直接管理者承認直接管理者承認說明：該指標規(guī)定了實施計劃中任務的完成度和進度率的對應關系。無相關對應任務時可跳過該進度率。. 正規(guī)化編程生產(chǎn)性標準Java類型項目：n 詳細設計SI1：1200行/人月。n CD+UT：2000行/人月。. 系統(tǒng)交付與用戶測試 有系統(tǒng)用戶對系統(tǒng)進行測試，根據(jù)測試情況，對系統(tǒng)進行完善和調試，項目組安排工程師對系統(tǒng)進行調整。用戶工作組開發(fā)商q 提供安裝場地及必要設施q 指派人員點收軟硬件設備及文件，并進行安裝后測試q 確認“系統(tǒng)測試計劃”q 指派專人協(xié)調配合測試q 依據(jù)“系統(tǒng)測試報告”確認系統(tǒng)結合測試結果q 申請交付(包括階段性的交付時間點與最終交付日期)q 準備交付用戶測試252。 確認《交付清單》(一般由客戶提供)252。 確定當前可交付工作產(chǎn)品版本號，分模塊制定《020_CN_項目驗收及交付規(guī)程_納品管理表》，提出明確的交付內容、提交條件和完成標準。252。 并標記尚未解決的缺陷和尚未實現(xiàn)的機能252。 打包交付的工作產(chǎn)品，并測試打包后的產(chǎn)品的可操作性q 提供場地及機房設備之安裝建議q 進行現(xiàn)場系統(tǒng)安裝q 撰寫“系統(tǒng)測試計劃”及進行系統(tǒng)測試內容步驟的設計q 依“系統(tǒng)測試計劃”和測試要求進行系統(tǒng)測試，并撰寫測試報告 系統(tǒng)整體測試方案. 概述系統(tǒng)測試是關注系統(tǒng)的外部特性。它的主要對象是進行系統(tǒng)測試的測試工程師。該方案所包含的測試用例范圍包括MicroMOe系統(tǒng)的所有功能測試用例、環(huán)境測試用例、性能測試用例以及UI測試用例等。. 測試資源和環(huán)境. 硬件配置關鍵項數(shù)量性能要求期望到位階段測試PC機4P4，硬盤300G，內存2G，此配置是實際用機需求分析階段數(shù)據(jù)庫服務器1P4，硬盤300G，內存2G，此配置是實際用機需求分析階段. 軟件配置資源名稱/類型配置數(shù)據(jù)庫管理系統(tǒng)Oracle、操作系統(tǒng)Centos服務器版64位客戶端前端展示負載性能測試工具Vs2008；功能性測試工具MANUAL. 需求分析需求分析期間，測試的主要工作為：審核需求分析報告：需求中是否存在不合理現(xiàn)象；需求是否可以被實現(xiàn)召開需求評審會議：評審會議項目經(jīng)理，系統(tǒng)分析師，用戶代表，客戶，測試設計師參加書寫驗收測試計劃。. 概要設計概要設計期間，測試的主要工作為：審核概要設計報告：概要設計是否符合全部需求，概要設計是否存在問題召開概要設計評審會議：由項目經(jīng)理，系統(tǒng)分析師，系統(tǒng)設計師，設計師，測試設計師,技術專家參加。書寫系統(tǒng)測試計劃。. 詳細設計詳細設計期間，測試的主要工作為審核詳細設計報告：詳細設計是否符合全部需求，詳細設計是否存在問題召開詳細設計評審會議：由項目經(jīng)理，系統(tǒng)設計師，設計師，編碼人員，測試設計師參加書寫集成測試計劃。 . 開發(fā)開發(fā)期間測試主要工作為召開開發(fā)指南評審會議：由項目經(jīng)理，設計師，開發(fā)員參加書寫個階段測試用例。召開測試用例評審會議：由項目經(jīng)理，測試設計師，測試工程師參加設計（由測試設計師設計）并書寫測試腳本（由開發(fā)人員書寫）。開發(fā)后期，由開發(fā)人員對開發(fā)的模塊進行單元測試。. 集成測試按照模塊上下集關系，進行從上到下或者從下到上的集成測試方法進行集成測試，單元測試與集成測試主要考慮功能性測試。同時也要對模個模塊或者集成模塊進行非功能性的抽樣測試。. 系統(tǒng)測試 對整合系統(tǒng)進行整合測試，這時的測試主要測試系統(tǒng)的整體功能和全部非功能性的需求。. 驗收測試 驗收測試首先進行正規(guī)性的測試，即由技術人員模擬各戶環(huán)境，以用戶的身份進行安裝和測試工作。然后進行非正規(guī)測試alpha測試和bate測試。. Alpha測試由公司內部開發(fā)人員模擬用戶進行測試，這個時候還允許對需求做些修改工作. Bate測試alpha測試后將產(chǎn)品提交給某些特定用戶，進行測試，注意這是的軟件一定要有使用時間限制 ，這時候凍結系統(tǒng)需求. 開發(fā)周期所需要產(chǎn)生的文檔階段開發(fā)文檔測試文檔立項前期項目合同可行性分析報告項目計劃書需求分析期需求規(guī)格說明書需求規(guī)格審核報告需求規(guī)格評審報告驗收測試計劃書概要設計期概要設計書概要設計審核報告概要設計評審報告系統(tǒng)測試計劃書詳細設計期數(shù)據(jù)庫設計詳細設計書詳細設計審核報告詳細設計評審報告集成測試計劃書編碼前期編碼規(guī)范編碼測試腳本測試用例測試腳本設計書編碼后期單元測試報告集成測試期集成測試報告系統(tǒng)測試期系統(tǒng)測試報告驗收測試期驗收測試報告后期使用手冊配置指南廣告材料測試總結報告（決定產(chǎn)品是否可以發(fā)布）藍色為可選項. 軟件測試類型 軟件測試是指使用人工或者自動的手段來運行或測定某個軟件產(chǎn)品系統(tǒng)的過程，其目的是在于檢驗是否滿足規(guī)定的需求或者弄清預期的結果與實際結果的區(qū)別。本文主要描述軟件測試的一些類型。. 白盒測試 白盒測試是基于代碼的測試，測試人員通過閱讀程序代碼或者通過使用開發(fā)工具中的單步調試來判斷軟件的質量，一般白盒測試由項目經(jīng)理在程序員開發(fā)中來實現(xiàn)。白盒測試分為動態(tài)白盒測試和靜態(tài)白盒測試. 靜態(tài)白盒測試 利用眼睛，瀏覽代碼，憑借經(jīng)驗，找出代碼中的錯誤或者代碼中不符合書寫規(guī)范的地方。比如，代碼規(guī)范中規(guī)定，函數(shù)必須為動賓結構。而黑盒測試發(fā)現(xiàn)一個函數(shù)定義如下：Function NameGet(){….}這是屬于不符合開發(fā)規(guī)范的。有這樣一段代碼:if ((i0) amp。 (i=0))…這段代碼交集為整個數(shù)軸，IF語句沒有必要I=0。while(I100){J=J+100。T=J*PI。}在循環(huán)體內沒有I的增加, 錯誤產(chǎn)生。. 動態(tài)白盒測試 利用開發(fā)工具中的調式工具進行測試。比如一段代碼有4個分支，輸入4組不同的測試數(shù)據(jù)使4組分支都可以走通而且結果必須正確。if(I0){P1}else{P2}在調試中輸入I=1,測試P1程序段通過。 再輸入I=1, 測試P2程序段，這樣的測試屬于動態(tài)白盒測試的缺陷。白盒測試通常在單元測試的時候進行。. 功能測試 功能測試指測試軟件各個功能模塊是否正確，邏輯是否正確。對測試對象的功能測試應側重于所有可直接追蹤到用例或業(yè)務功能和業(yè)務規(guī)則的測試需求。這種測試的目標是核實數(shù)據(jù)的接受、處理和檢索是否正確，以及業(yè)務規(guī)則的實施是否恰當。此類測試基于黑盒技術，該技術通過圖形用戶界面 (GUI)或者測試腳本與應用程序進行交互，并對交互的輸出或結果進行分析，以此來核實應用程序及其內部進程。功能測試的主要參考為類似于功能說明書之類的文檔。. UI測試 UI測試指測試用戶界面的風格是否滿足客戶要求，文字是否正確，頁面美工是否好看，文字，圖片組合是否完美，背景是否美觀，操作是否友好等等用戶界面 (UI) 測試用于核實用戶與軟件之間的交互。UI 測試的目標是確保用戶界面會通過測試對象的功能來為用戶提供相應的訪問或瀏覽功能。另外，UI 測試還可確保 UI 中的對象按照預期的方式運行，并符合公司或行業(yè)的標準。包括用戶友好性，人性化，易操作性測試。UI測試比較主觀，與測試人員的喜好有關。 比如：頁面基調顏色刺眼；文字中出現(xiàn)錯別字；頁面顯示范圍超過屏幕范圍等都屬于UI測試中的缺陷。. 性能測試 性能測試主要測試軟件測試的性能，包括負載測試，強度測試，容量測試，基準測試以及基準測試. 負載測試 負載測試是一種性能測試指數(shù)據(jù)在超負荷環(huán)境中運行，程序是否能夠承擔。 在這種測試中，將使測試對象承擔不同的工作量，以評測和評估測試對象在不同工作量條件下的性能行為，以及持續(xù)正常運行的能力。負載測試的目標是確定并確保系統(tǒng)在超出最大預期工作量的情況下仍能正常運行。此外，負載測試還要評估性能特征，例如，響應時間、事務處理速率和其他與時間相關的方面。 比如，用戶并發(fā)量測試就是屬于負載測試的用戶，可以使用測試工具，模擬上百人客戶同時訪問，看系統(tǒng)響應時間，處理速度如何？. 強度測試 強度測試是一種性能測試，他在系統(tǒng)資源特別低的情況下軟件系統(tǒng)運行情況。這類測試往往可以書寫系統(tǒng)要求的軟硬件水平要求。主要測試對象為低CPU主頻，低存儲空間（內存或外存），低連接速度。 實施和執(zhí)行此類測試的目的是找出因資源不足或資源爭用而導致的錯誤。如果內存或磁盤空間不足，測試對象就可能會表現(xiàn)出一些在正常條件下并不明顯的缺陷。而其他缺陷則可能由于爭用共享資源（如數(shù)據(jù)庫鎖或網(wǎng)絡帶寬）而造成的。強度測試還可用于確定測試對象能夠處理的最大工作量。 比如：一個系統(tǒng)在內存366M下可以正常運行，但是降低到258M下不可以運行，告訴內存不足，這個系統(tǒng)對內存的要求就是366M。. 容量測試 容量測試指通過代碼往存儲空間中插入一定數(shù)量的數(shù)據(jù)，看看相關程序是否能夠正常運行。 容量測試使測試對象處理大量的數(shù)據(jù)，以確定是否達到了將使軟件發(fā)生故障的極限。容量測試還將確定測試對象在給定時間內能夠持續(xù)處理的最大負載或工作量。例如，通過編寫代碼項存貯空間輸入一定數(shù)量的記錄，然后運行需要使用這個存儲空間的程序，判斷程序是否運行正常。. 系統(tǒng)資源競爭測試 軟件競爭使用各種資源（數(shù)據(jù)紀錄，內存等），看他與其他相關系統(tǒng)對資源的爭奪能力。比如：一臺機器上即安裝您的財務系統(tǒng)，又安裝用友財務系統(tǒng)。當CPU占有率下降后，看看是否能夠強過用友財務系統(tǒng)，而是自己的系統(tǒng)能夠正常運行？. 安全性和訪問控制測試安全性和訪問控制測試側重于安全性的兩個關鍵方面：應用程序級別的安全性，包括對數(shù)據(jù)或業(yè)務功能的訪問系統(tǒng)級別的安全性，包括對系統(tǒng)的登錄或遠程訪問。. 應用程序級別的安全性 可確保：在預期的安全性