【文章內(nèi)容簡介】 個步驟：分析程序規(guī)范的描述中哪些是原因，哪些是結(jié)果。原因常常是輸入條件或是輸入條件的等價類。結(jié)果是輸出條件。分析程序規(guī)范的描述中語義的內(nèi)容，并將其表示成連接各個原因與各個結(jié)果的“因果圖”。由于語法或環(huán)境的限制，有些原因和結(jié)果的組合情況是不可能出現(xiàn)的。為表明這些特定的情況，在因果圖上使用持殊的符號標(biāo)明約束條件。把因果圖轉(zhuǎn)換成判定表。把判定表的每一列寫成一個測試用例。猜錯法 猜錯法在很大程度上是憑經(jīng)驗進(jìn)行的，是憑人們對過去所作的測試工作結(jié)果的分析，對所揭示的缺陷的規(guī)律性作直覺的推測來發(fā)現(xiàn)缺陷的。一個采用兩分法的檢索程序，典型地可以列出下面幾種測試情況：被檢索的表只有一項或為空表；表的項數(shù)恰好是2的冪次；表的項數(shù)比2的冪次多1等。猜錯法充分發(fā)揮人的經(jīng)驗，在一個測試小組中集思廣益，方便實用，特別在軟件測試基礎(chǔ)較差的情況下，很好地組織測試小組 (也可以有外來人員)進(jìn)行錯誤猜測，是有效的測試方法。隨機(jī)數(shù)法即測試用例的參數(shù)是隨機(jī)數(shù)。它可以自動生成，因此自動化程度高。使用大量隨機(jī)測試用例測試通過的程序會提高用戶對程序的信心。但其關(guān)鍵在于隨機(jī)數(shù)的規(guī)律是否符合使用實際。. 第二條 測試用例操作步驟 在設(shè)計編寫測試用例時，首先要從測試用例庫中選擇相應(yīng)功能的測試用例，在原有測試用例的基礎(chǔ)上依據(jù)系統(tǒng)需求文檔對測試用例的進(jìn)行修改、更新，評審?fù)ㄟ^后將使用該測試用例測試被測系統(tǒng)。 在測試項目結(jié)束后，統(tǒng)計分析所使用過的測試用例，進(jìn)行分類放到相應(yīng)的測試用例庫中。為以后測試用例的設(shè)計編寫提供數(shù)據(jù)基礎(chǔ)。. 第三條 測試用例選擇準(zhǔn)則測試用例的代表性：能夠代表各種合理和不合理的、合法的和非法的、邊界和越界的,以及極限的輸入數(shù)據(jù)、操作和環(huán)境設(shè)置等；測試結(jié)果的可判定性：即測試執(zhí)行結(jié)果的正確性是可判定的或可評估的；測試結(jié)果的可再現(xiàn)性：即對同樣的測試用例,系統(tǒng)的執(zhí)行結(jié)果應(yīng)當(dāng)是相同的。. 第四條 測試軟/硬件環(huán)境根據(jù)需求文檔提供的內(nèi)容，和開發(fā)部溝通確定測試項目所需的軟硬件環(huán)境，完成對測試項目所需軟硬件資源的準(zhǔn)備工作，使軟硬件資源得到滿足。完成對軟硬件資源的配置后，要進(jìn)行對測試項目的軟硬件環(huán)境進(jìn)行評審，確認(rèn)對軟硬件資源配置的有效性。. 第五條 測試數(shù)據(jù)準(zhǔn)備完成對測試項目基本數(shù)據(jù)的準(zhǔn)備操作，包括數(shù)據(jù)庫連接、用戶信息、用戶角色權(quán)限、單位組織等信息和測試相關(guān)的測試數(shù)據(jù)。. 第六條 測試執(zhí)行過程績效考核為促進(jìn)測試人員積極主動做好測試執(zhí)行工作，對測試人員進(jìn)行測試執(zhí)行過程進(jìn)行考核。序號測試準(zhǔn)備內(nèi)容考核評分標(biāo)準(zhǔn)1測試組長工作安排待定2測試組長風(fēng)險評估待定3測試人員設(shè)計用例待定4測試人員執(zhí)行用例待定5開發(fā)組長配合度待定6開發(fā)人員回歸次數(shù)待定7開發(fā)人員處理問題情況待定以上統(tǒng)計數(shù)據(jù)由項目經(jīng)理提供給部長。第六章 測試執(zhí)行. 第一條 項目測試周期測試項目的測試周期可分為：單元測試、接收測試、集成測試、系統(tǒng)測試、回歸測試、性能測試等。. 第二條 項目測試啟動軟件項目測試活動的正式啟動，是在確認(rèn)軟件可測試性后展開的。開發(fā)人員需要對產(chǎn)品進(jìn)行單元測試，單元測試效果通過接收測試驗證。. 第三條 項目測試階段測試人員依據(jù)測試計劃和測試用例進(jìn)行測試活動。測試一般分為兩個階段：集成測試、系統(tǒng)測試階段：該階段測試人員每天提交缺陷，并跟蹤缺陷，驗證缺陷，直到提交的缺陷被關(guān)閉或被保留。開發(fā)人員周期性提交修改過缺陷的新版本，測試人員在新版本上驗證缺陷?；貧w測試階段：在集成測試、系統(tǒng)測試階段完成后，產(chǎn)品將進(jìn)入回歸測試階段。測試人員對修改后的產(chǎn)品進(jìn)行重新功能驗證，確保修改的正確性，驗證在修改缺陷的同時沒有引入新的問題。回歸缺陷是指開發(fā)人員標(biāo)示已修改的缺陷，經(jīng)測試后發(fā)現(xiàn)仍未修改正確，或引入其他缺陷，或在前一個版本中未發(fā)現(xiàn)的缺陷，在后一個版本中出現(xiàn)。如產(chǎn)品進(jìn)行性能測試，則需要在性能測試后，進(jìn)行一輪回歸測試，確保功能的正確性。. 第四條 項目測試結(jié)束項目測試結(jié)束時應(yīng)達(dá)到測試質(zhì)量目標(biāo)所規(guī)定的標(biāo)準(zhǔn)。通過評審后結(jié)束該項目測試。. 第五條 測試執(zhí)行過程績效考核為促進(jìn)開發(fā)人員積極主動做質(zhì)量工作，對開發(fā)人員進(jìn)行考核。序號開發(fā)人員考核內(nèi)容考核評分標(biāo)準(zhǔn)1開發(fā)人員提交的首個產(chǎn)品未通過單元測試標(biāo)準(zhǔn)待定開發(fā)組長 ￥502開發(fā)人員無故將【嚴(yán)重】、【非常嚴(yán)重】級別無爭議的缺陷延期3天修改。待定每個缺陷，對應(yīng)開發(fā)人員 ￥103開發(fā)人員未能正確修改缺陷，導(dǎo)致狀態(tài)為【已修改】的缺陷被【重新打開】，每天超過1個。待定對應(yīng)開發(fā)人員 ￥104開發(fā)人員千行缺陷代碼率在項目組中排名第一者待定對應(yīng)開發(fā)人員 +￥205一個項目中【延遲修改】或【已知問題】的缺陷數(shù)超過總?cè)毕輸?shù)的10%待定開發(fā)組長 ￥20以上統(tǒng)計數(shù)據(jù)由測試人員在項目交付后提供給部長。2. 第七章 測試變更當(dāng)需求變更，功能變化，測試人員根據(jù)變更情況，評估測試變更所需時間，提出變更風(fēng)險。如變更情況被項目組通過，測試組長要修改相應(yīng)的測試計劃，測試人員要從新設(shè)計測試用例。3. 第八章 缺陷管理. 缺陷管理流程. 提交缺陷測試人員將缺陷填寫到管理工具中，選擇指派人為開發(fā)組長或相應(yīng)的開發(fā)人員。. 分配缺陷開發(fā)人員分別對自己收到的缺陷進(jìn)行評審。評審后如果對提交的缺陷有疑問，可以與提交人協(xié)商。對未能達(dá)成一致的缺陷由項目經(jīng)理組織項目組成員評審。評審人員可以是項目組人員。如果缺陷初次分配的開發(fā)人員無法修改該缺陷，初次分配的開發(fā)人員可以將缺陷再次分配給其他開發(fā)人員。但為避免缺陷被多次分配，項目經(jīng)理應(yīng)跟蹤3天以上未修改的缺陷。. 修改缺陷開發(fā)人員對已確認(rèn)的缺陷進(jìn)行修改，填寫修改記錄，修改缺陷狀態(tài)為“已修改”或其他狀態(tài)。. 關(guān)閉缺陷測試人員對已修改的缺陷進(jìn)行驗證。如果已修改完成，測試人員將缺陷狀態(tài)設(shè)置為關(guān)閉。如果沒有修改或引起回歸問題，將修改缺陷狀態(tài)為“重新開啟”或新增缺陷，由開發(fā)工程師繼續(xù)修改。. 保留缺陷對于有爭議的缺陷進(jìn)行，將有項目經(jīng)理最終決定是否修改。如果缺陷是由于技術(shù)原因、版本原因不能修改，則保留該缺陷。缺陷管理第一節(jié) 缺陷缺陷的定義及其基本屬性缺陷是指在軟件開發(fā)過程中的針對軟件產(chǎn)品和開發(fā)過程中的問題，這些問題已經(jīng)影響或可能會影響軟件產(chǎn)品的質(zhì)量。缺陷應(yīng)該具備以下屬性，也就是往缺陷管理庫或者缺陷列表中提交的缺陷應(yīng)該具備以下屬性：屬性名稱描述缺陷標(biāo)識