XXX系統(tǒng)測試總結(jié)報告

XX系統(tǒng)

(XXV1.0)測試總結(jié)報告文件編號文件版本V1.0編寫單位編寫人編寫日期審核人審核日期批準人批準日期文件修訂記錄1引言編寫目的XXX系統(tǒng)測試總結(jié)報告編寫的目的在于總結(jié)測試階段的測試以及分析測試結(jié)果，描述系統(tǒng)是否符合客戶的需求。預(yù)期參考人員包括用戶、測試人員、開發(fā)人員、項目管理者、其他質(zhì)量管理人員和需要閱讀本報告的高層領(lǐng)導(dǎo)。系統(tǒng)簡介“XXX系統(tǒng)”旨在采用先進的軟件技術(shù)、數(shù)據(jù)庫技術(shù)。。。。。系統(tǒng)功能包括。。。。。。本系統(tǒng)致力于通過計算機技術(shù)和XXX業(yè)務(wù)的結(jié)合，充分發(fā)揮信息化優(yōu)勢，提高業(yè)務(wù)人員的辦公效率和業(yè)務(wù)質(zhì)量，便于。。。。，以快速把握。。。。。。，提高對。。。的科學(xué)管理水平和信息化水平。系統(tǒng)架構(gòu)圖1系統(tǒng)架構(gòu)技術(shù)架構(gòu)圖2技術(shù)架構(gòu)功能列表

術(shù)語、縮略語解 釋XXXXXX系統(tǒng)（）1.4參考資料《XXX系統(tǒng)軟件需求規(guī)格說明書》《XXX系統(tǒng)軟件高層設(shè)計說明書》《XXX系統(tǒng)測試用例說明書》2測試概要2.1測試用例設(shè)計測試用例廣義地可以分為兩類:黑盒測試白盒測試其他技術(shù)使用單元接口和功能描述，不需了解被測單元的內(nèi)部結(jié)構(gòu)使用被測單元內(nèi)部如何工作的信息白盒測試用例設(shè)計：使用程序設(shè)計的控制結(jié)構(gòu)導(dǎo)出測試用例。采用白盒測試的目的主要是：1.保證一個模塊中的所有獨立路徑至少被執(zhí)行一次；2.對所有的邏輯值均需要測試真、假兩個分支；.在上下邊界及可操作范圍內(nèi)運行所有循環(huán)；.檢查內(nèi)部數(shù)據(jù)結(jié)構(gòu)以確保其有效性。黑盒測試用例設(shè)計：使用詳細設(shè)計導(dǎo)出測試用例。采用黑盒測試的目的主要是：.檢查功能是否實現(xiàn)或遺漏；.檢查人機交互是否錯誤；.數(shù)據(jù)結(jié)構(gòu)或外部數(shù)據(jù)庫訪問錯誤；.性能等其它特性要求是否滿足；.初始化盒終止錯誤。.2測試環(huán)境與配置2.2.1服務(wù)器端硬件配置硬件環(huán)境CPUPentium3GHz內(nèi)存4G硬盤40G軟件環(huán)境簡體中文Windows桌面操作系統(tǒng)OracleDatabase10gDBRelease2或更高版本2.2.2客戶端硬件配置硬件環(huán)境CPUPentium2GHz內(nèi)存1G硬盤20G軟件環(huán)境簡體中文Windows桌面操作系統(tǒng).NETFRAMEWORK3.5或更高版本OracleDatabase10gClientRelease2或更高版本XXX系統(tǒng)V1.0.3測試方法和工具XXX系統(tǒng)測試主要用到了以下幾種測試方法：等價類、邊界值、因果圖、錯誤猜測等，用到最多的是等價類和邊界值，錯誤猜測的方法。所謂等價類劃分法是一種典型的、重要的黑盒測試方法，它將程序所有可能的輸入數(shù)據(jù)（有效的和無效的）劃分成若干個等價類。然后從每個部分中選取具有代表性的數(shù)據(jù)當做測試用例進行合理的分類，測試用例由有效等價類和無效等價類的代表組成，從而保證測試用例具有完整性和代表性。例如：本系統(tǒng)中測試用戶名不存在，系統(tǒng)應(yīng)該給出什么樣的提示時，就可以將所有用戶名分為兩類，一類是已經(jīng)注冊的用戶，另一類是沒有注冊的用戶，前者為有效等價類，后者為無效的等價類。所謂邊界值法是指相當于輸入等價類和輸出等價類而言，稍高于其邊界值及稍低于其邊界值的一些特定情況?；谶吔绲姆椒ㄊ歉鶕?jù)定義域來實現(xiàn)的，最終演變成邊界值分析、健壯性測試、最壞情況測試和健壯最壞情況測試四種技術(shù)。例如：本系統(tǒng)中，對經(jīng)緯度輸入范圍進行測試，由于經(jīng)度的范圍是（-180，+180），所以在選擇測試數(shù)據(jù)時，我們選擇（-180.000001，-180.000000，-179.999999,-90，0,90,179.999999,180.000000,180.00001），這樣就能測試出系統(tǒng)對經(jīng)緯度的約束是否準確。因果圖法是一種適合于描述對于多種輸入條件組合的測試方法，根據(jù)輸入條件的組合、約束關(guān)系和輸出條件的因果關(guān)系，分析輸入條件的各種組合情況，從而設(shè)計測試用例的方法，它適合于檢查程序輸入條件涉及的各種組合情況。因果圖法一般和判定表結(jié)合使用，通過映射同時發(fā)生相互影響的多個輸入來確定判定條件。因果圖法最終生成的就是判定表，它適合于檢查程序輸入條件的各種組合情況。3測試結(jié)果及缺陷分析測試執(zhí)行情況與記錄測試組織測試組成：

圖3測試人員結(jié)構(gòu)測試人員的工作分配：編號測試內(nèi)容責(zé)任人123456覆蓋分析本次測試中為了使需求覆蓋率達到100%,現(xiàn)在對以下功能點進行了測試。希望對需求規(guī)格說明書中的各個功能點盡量全部測試，最大限度的找出系統(tǒng)錯誤，為完善程序提供合理的建議。功能編號測試點描述是否測試重要等級[Y][P][N][N/A]1測試系統(tǒng)能否正常將規(guī)范格式文件中的數(shù)據(jù)導(dǎo)入到數(shù)據(jù)庫。是重要P2測試系統(tǒng)能否正常通過手動填寫和選擇各項目錄入數(shù)據(jù)是重要P

3測試系統(tǒng)能否正常將所選文件夾的中的規(guī)范格式文件的數(shù)據(jù)批量導(dǎo)入數(shù)據(jù)庫。是重要P4是重要P5是重要Y6是一般Y7是重要P備注：Y表示測試用例全部通過；P表示大部分部分測試用例通過，根據(jù)測試出現(xiàn)的BUG或者測試人員建議進行修正；N表示測試用例不通過，程序出現(xiàn)嚴重BUG；N/A表示不可測試或者用例不適用。測試覆蓋功能（或編號）用例個數(shù)執(zhí)行總數(shù)未執(zhí)行數(shù)未/漏測分析和原因15502550355045505330611071010085509550108801133012111101377014770

1588016141401722018101001955020110217702213130231111024330251010026330271102833029440301010031770327703366034990合計2142140測試覆蓋率=執(zhí)行總數(shù)/用例總數(shù)*100%=100%缺陷統(tǒng)計與分析缺陷匯總Bug等級定義如下表所述等級描述說明

嚴重發(fā)現(xiàn)可重復(fù)出現(xiàn)的致命問題——導(dǎo)致系統(tǒng)崩潰；——導(dǎo)致程序模塊丟失；——主業(yè)務(wù)流程出現(xiàn)斷點；——內(nèi)存泄漏；——導(dǎo)致死機一般發(fā)現(xiàn)可重復(fù)出現(xiàn)的嚴重問題——被測功能不能正確實現(xiàn)；——軟件錯誤導(dǎo)致數(shù)據(jù)丟失；——被測數(shù)據(jù)處理錯誤；——用戶需求未實現(xiàn)。微小一般性的錯誤或功能實現(xiàn)有不完美處——操作界面錯誤；——打印內(nèi)容、格式錯誤；——簡單的輸入限制未放在前臺進行控制；——刪除操作未給出提示?！缑娌灰?guī)范；——輔助說明描述不清楚；——輸入輸出不規(guī)范；——長操作未給用戶提示；——提示窗口文字未采用行業(yè)術(shù)語。增量確認測試階段Bug列表:Bug級別嚴重一般微小無效Bug數(shù)目362712各類Bug數(shù)目柱狀圖如下:

圖4各類Bug數(shù)目各類bug所占比例如下餅狀圖所示缺陷引入原因分析測試過程中發(fā)現(xiàn)的缺陷主要有以下幾個方面：.需求理解不明確開發(fā)人員根據(jù)需求進行設(shè)計時，沒有考慮相關(guān)功能的關(guān)聯(lián)性，以及需求錯誤的地方，在測試過程中，需求相關(guān)的問題表現(xiàn)出來。需求做改正，設(shè)計必須跟著做改動，浪費時間和影響開發(fā)人員的積極性，降低開發(fā)人員對需求的信任，可能會導(dǎo)致開發(fā)人員不按照需求進行設(shè)計而根據(jù)自己的經(jīng)驗來進行設(shè)計。.功能性錯誤功能實現(xiàn)錯誤，實現(xiàn)了需求未定義的功能，執(zhí)行需求定義的功能時系統(tǒng)出現(xiàn)錯誤。主要是統(tǒng)計分析出圖時數(shù)據(jù)因編碼錯誤出現(xiàn)處理異常，導(dǎo)致顯示錯誤統(tǒng)計數(shù)據(jù)。.界面設(shè)計和需求不一致界面設(shè)計沒有根據(jù)需求進行，輸入，輸出字段文字錯誤，用戶無法理解字段含義。界面設(shè)計沒有完成需求規(guī)定的輸入限制驗證，導(dǎo)致用戶可以輸入錯誤的或者無效的數(shù)據(jù)，這些數(shù)據(jù)有可能會引起功能性錯誤。.界面設(shè)計易用性缺陷界面設(shè)計不夠友好，系統(tǒng)中很多界面的輸入字段無明確的輸入提示，用戶無法快速理解何種輸入是正確的，但是用戶輸入錯誤后，系統(tǒng)提示出錯，增加用戶負擔(dān)。提示信息錯誤，不同模塊相同結(jié)果的提示信息不一致，用戶操作后，相應(yīng)的提示信息不明確，引起用戶誤解。提示信息一致性，用戶在不同界面執(zhí)行相同的操作，提示信息不同。.開發(fā)人員疏忽引起的缺陷因為開發(fā)人員的疏忽，導(dǎo)致系統(tǒng)需要驗證的地方，調(diào)用了錯誤的驗證，系統(tǒng)需要進行輸入控制的地方?jīng)]有進行相應(yīng)的控制。4測試結(jié)論測試類別缺陷總數(shù)遺留問題數(shù)目用例總數(shù)測試功能點數(shù)結(jié)論功能測試48021434通過安裝測試008/通過5綜合評價資源消耗:測試時間測試人力6人X6天+1人X10天=46人天硬件服務(wù)端PC1臺客戶端PC6臺測試質(zhì)量：下面給出用例質(zhì)量和缺陷密度兩個指標來衡量功能測試的質(zhì)量用例質(zhì)量缺陷總數(shù)/測試用例總數(shù)=48/214=22.43%缺陷密度缺陷總數(shù)/功能點數(shù)=48/34=1.41軟件能力XXX系統(tǒng)完整實現(xiàn)了需求規(guī)格說明書中的需求，主要分為。。。等功能模塊