系統(tǒng)測試報告參考文檔

1、精選優(yōu)質(zhì)文檔-傾情為你奉上系統(tǒng)測試報告1 系統(tǒng)測試報告寫作的目的1、軟件測試人員對整個系統(tǒng)測試工作進行總結(jié)，對被測試對象進行評估，并對以后的測試工作給出建議2、測試經(jīng)理通過測試報告了解被測試產(chǎn)品的質(zhì)量情況、測試過程的質(zhì)量3、軟件開發(fā)項目經(jīng)理通過軟件測試報告了解開發(fā)產(chǎn)品的質(zhì)量情況，并在下階段的開發(fā)工作中采取應(yīng)對措施4、在軟件測試報告中，軟件測試人員作出的軟件產(chǎn)品質(zhì)量評估，可以作為軟件產(chǎn)品是否對外發(fā)布的重要參考依據(jù)。2 系統(tǒng)測試報告寫作的要點2.1 概述簡單介紹被測對象、測試特性及其版本/修訂級別情況指明本次系統(tǒng)測試活動所依據(jù)的測試計劃、測試方案、測試用例及測試過程，對測試內(nèi)容也要進行簡要說明2.

2、2 測試時間、地點、人員描述本次測試的時間，地點和測試人員，以及人員分工。例如：版本名稱測試時間測試人員測試地點起始時間結(jié)束時間2.3 環(huán)境描述描述本次測試的環(huán)境，包括軟硬件、測試儀器、組網(wǎng)圖等。例如：硬件環(huán)境軟件環(huán)境名稱型號大小個數(shù)名稱版本號CPU操作系統(tǒng)內(nèi)存應(yīng)用軟件硬盤數(shù)據(jù)庫2.4 總結(jié)和評價2.4.1 測試過程質(zhì)量統(tǒng)計評估1、工作量數(shù)據(jù)統(tǒng)計例如：模塊/特性規(guī)模投入人時投入人時/KLOC合計分析：1）可以根據(jù)不同模塊每千行代碼投入的工作量來查看哪些模塊測試比較充分；哪些模塊測試不夠充分。2）結(jié)合模塊的實際情況，對關(guān)鍵模塊或者復(fù)雜模塊投入的測試人時比例應(yīng)相對較高；對非關(guān)鍵或者簡單的模塊投入的

3、測試人時比例可以相對較低，根據(jù)該指標(biāo)可以用來衡量測試過程中測試資源的分布是否合理。2、用例數(shù)統(tǒng)計例如：模塊規(guī)模(KLOC)用例數(shù)用例數(shù)/KLOC%合計 分析：1）可以根據(jù)用例數(shù)/KLOC來查看哪些模塊用例設(shè)計的比較充分；哪些模塊用例設(shè)計的相對比較少，結(jié)合模塊的具體特點，需要進行分析，避免關(guān)鍵模塊用例設(shè)計不充分的情況。2）可以根據(jù)不同模塊用例數(shù)來了解不同測試人員的工作量；結(jié)合時間方面的數(shù)據(jù)，對工作量少而花費時間較多的情況進行調(diào)查分析，對其中存在的問題采取相關(guān)策略進行有效的規(guī)避。3、用例對需求的覆蓋率例如：需求id用例數(shù)合計分析：從需求的覆蓋率來查看不同的需求對應(yīng)的用例數(shù)，可以考量不同需求測試的程

4、度：1）對于重要的關(guān)鍵的需求，應(yīng)該設(shè)計比較充分的用例；2）對于功能比較簡單的需求，可以設(shè)計相對少的用例；3）對于沒有用例對應(yīng)的需求，一定要調(diào)查相關(guān)負責(zé)人員的工作情況，避免工作中的不認(rèn)真導(dǎo)致的測試的不全面性。4、用例的穩(wěn)定性 例如：模塊/特性用例數(shù)變更用例數(shù)變更用例數(shù)/用例數(shù)合計分析：根據(jù)每個模塊設(shè)計的用例的穩(wěn)定性來判斷：對個別變更比例比較高的模塊要進行調(diào)查分析，看變更的原因在哪里？是開發(fā)的文檔發(fā)生了變更，還是由于測試方面理解發(fā)生了偏差導(dǎo)致的變更。1）如果是開發(fā)方面變更頻繁，需要反饋給開發(fā)方面；2）如果是后者，測試方面需要分析導(dǎo)致這個偏差產(chǎn)生的原因是客觀的還是主觀的；要采取相應(yīng)的措施進行規(guī)避。5

5、、用例的有效性例如：模塊/特性用例數(shù)發(fā)現(xiàn)的缺陷數(shù)缺陷數(shù)/用例數(shù)合計分析：根據(jù)每個模塊對應(yīng)的平均用例缺陷數(shù)來判斷用例設(shè)計的水準(zhǔn)：1）如果模塊對應(yīng)的該值比較高，可以認(rèn)為： 該模塊質(zhì)量比較差 用例設(shè)計的質(zhì)量比較高2）如果模塊對應(yīng)的該值比較低，可以認(rèn)為： 該模塊的質(zhì)量比較好 用例設(shè)計的質(zhì)量一般總之，對于上面的各種情況，必須調(diào)查驗證，對有問題的情況進行改善控制。6、測試執(zhí)行的效率： 例如：模塊特性執(zhí)行用例數(shù)發(fā)現(xiàn)缺陷數(shù)人時執(zhí)行用例數(shù)/人時發(fā)現(xiàn)缺陷數(shù)/人時合計分析：根據(jù)不同的模塊查看不同測試人員的執(zhí)行效率：1）個別模塊執(zhí)行效率很高，考慮 測試人員對工作比較負責(zé)，積極，或者使用了比較好的測試技術(shù)； 測試人員測

6、試的比較馬虎，用例執(zhí)行可能存在應(yīng)付現(xiàn)象。2）個別模塊執(zhí)行效率不高，考慮 測試人員測試方法存在問題，或者能力有限，考慮是否需要幫助 對應(yīng)的模塊測試難度較大，屬客觀因素?？傊?，對于上面的各種情況，必須調(diào)查驗證，對有問題的情況進行改善控制。2.4.2 軟件產(chǎn)品質(zhì)量統(tǒng)計評估1、版本缺陷統(tǒng)計例如：模塊/特性版本1(缺陷個數(shù))版本2(缺陷個數(shù))版本3(缺陷個數(shù))合計(缺陷個數(shù))合計分析：根據(jù)不同版本缺陷的收斂狀態(tài)來觀察軟件的質(zhì)量如果缺陷收斂的比較快，可以考慮系統(tǒng)中的缺陷主要在模塊或者函數(shù)內(nèi)部生成，接口方面的缺陷相對較少，一個模塊的修改不會引發(fā)其他模塊的問題；可以認(rèn)為軟件產(chǎn)品質(zhì)量相對比較容易控制；如果缺陷收

7、斂的比較慢，可以考慮系統(tǒng)中的缺陷主要在模塊的接口處產(chǎn)生，一個bug的修改，可能對多個模塊產(chǎn)生影響，從而引入新的bug；可以認(rèn)為軟件產(chǎn)品的質(zhì)量控制相對困難。另外，通過這個指標(biāo)，也可以考核測試組對每個版本測試的充分性，但在前面測試過程控制的前提下，這個指標(biāo)主要用來衡量軟件的質(zhì)量水平。 2、缺陷等級統(tǒng)計例如：模塊/特性致命嚴(yán)重一般提示合計合計分析： 根據(jù)不同的模塊來查看缺陷的嚴(yán)重性。 對于等級相對比較嚴(yán)重的問題要進行分析，了解問題產(chǎn)生的原因，并考慮有沒有比較好的方式進行規(guī)避。對于嚴(yán)重問題比較多的模塊，要結(jié)合開發(fā)人員的能力，工作態(tài)度和模塊的難度考慮，考慮任務(wù)安排的合理性。3、測試用例的通過率例如：模塊

8、/特性PassedFailedBLOCKNo RunN/A合計用例通過率合計分析：假設(shè)測試過程質(zhì)量得到有效控制的前提下： 在最后一個回歸測試版本中，對用例的通過率的衡量可以考核軟件產(chǎn)品質(zhì)量的等級1）對于未通過的用例點需要分析，看對軟件產(chǎn)品質(zhì)量的影響達到什么級別2）對于遺留的問題，需要分析遺留的主觀和客觀原因，考慮在以后的版本中是否可以進行規(guī)避。4、缺陷原因分布：例如：缺陷/原因致命嚴(yán)重一般提示合計需求設(shè)計編碼合計分析： 根據(jù)缺陷的分布來分析研發(fā)過程的規(guī)范性 如果在需求及設(shè)計階段發(fā)現(xiàn)的缺陷較多，需要考慮相關(guān)過程的質(zhì)量控制是否嚴(yán)格 如果在需求及設(shè)計階段發(fā)現(xiàn)的缺陷很少，可以認(rèn)為過程的質(zhì)量控制比較有效

9、2.4.3 系統(tǒng)測試綜合評價1、對測試過程綜合評價：從測試的充分性，效率，質(zhì)量，協(xié)作等多個方面進行評價，重點在于暴露測試過程中的問題，并提出相應(yīng)的改進策略。2、對被測模塊/特性綜合評價：從軟件產(chǎn)品的系統(tǒng)功能、業(yè)務(wù)正確性、安全性，可用性，可維護性，性能，可靠性等多個方面作出客觀評價。測試對象的整體質(zhì)量： A：質(zhì)量穩(wěn)定，適合大規(guī)模應(yīng)用； B：存在少數(shù)嚴(yán)重問題，但有規(guī)避措施，可以使用； C：基本功能可用，但問題較多 D：基本功能不可用2.5 系統(tǒng)測試遺留問題報告遺留問題是指測試過程中發(fā)生的并且在測試報告時仍沒有得到解決的測試問題。測試報告時已經(jīng)得到解決，并已經(jīng)過回歸驗證的測試問題不記入其中?？蓪z留問題數(shù)和級別進行統(tǒng)計。要列出每個遺留問題的詳細情況，包括問題單號、問題級別、詳細描述、問題分析與處理措施等。例如：問題總數(shù)致命問題嚴(yán)重問題一般問題提示問題其他統(tǒng)計項數(shù)目百分比遺留問題詳細