第三方軟件測試報(bào)告

1、第三方軟件測試報(bào)告（暫定）1. 引言1.1.編寫目的本文檔作為該系統(tǒng)測試的測試標(biāo)準(zhǔn)，內(nèi)容關(guān)系到本次系統(tǒng)測試可能涉及到的測試內(nèi)容和測試技術(shù)解決方案。1.2.系統(tǒng)概述?略2. 測試描述2.1.測試范圍與內(nèi)容我方（北京圓規(guī)創(chuàng)新公司）對XX公司“XX項(xiàng)目進(jìn)行測試，保證使用方的功能正確，保證系統(tǒng)核心模塊的穩(wěn)定和安全，為項(xiàng)目的驗(yàn)收提供參考。以此，本計(jì)劃列出了在此次功能測試過程中所要進(jìn)行的內(nèi)容和實(shí)施的方案及測試資源的安排，作為測試活動(dòng)的依據(jù)和參考。本次測試的對象為xx公司“xX項(xiàng)目，測試范圍為：略。本次測試的主要內(nèi)容有功能測試（含容錯(cuò)測試）、易用性測試。2.2.測試依據(jù)本次測試所依據(jù)的文檔包含開發(fā)方提供的需

2、求規(guī)格說明書、操作手冊、用戶手冊，維護(hù)手冊，設(shè)計(jì)文檔等相關(guān)開發(fā)文檔。并依據(jù)IT行業(yè)項(xiàng)目的通用標(biāo)準(zhǔn)，包括功能測試標(biāo)準(zhǔn)、缺陷標(biāo)準(zhǔn)、易用性標(biāo)準(zhǔn)。對于項(xiàng)目的易用性標(biāo)準(zhǔn)，原則上由測試方提出易用性問題修改的建議，由開發(fā)方對測試方提交的問題進(jìn)行確認(rèn)。3. 測試解決方案我公司針對用戶方提出的測試要求，根據(jù)以往項(xiàng)目的實(shí)際經(jīng)驗(yàn)，撰寫測試技術(shù)解決方案。該解決方案包含了本次系統(tǒng)測試可能涉及到的測試類型，并分別介紹不同測試類型的內(nèi)容和相關(guān)標(biāo)準(zhǔn)。3.1.系統(tǒng)功能測試實(shí)施系統(tǒng)功能測試，完成對被測系統(tǒng)的功能確認(rèn)。采用黑盒測試方法，根據(jù)需求規(guī)格說明書和用戶手冊，將功能點(diǎn)轉(zhuǎn)換為功能測試需求，根據(jù)測試需求編寫測試用例，保證所有功能

3、點(diǎn)必須被測試用例覆蓋。測試用例的編寫采用基于場景的測試用例編寫原則，便于以使用者的角度進(jìn)行測試。用例設(shè)計(jì)上兼顧正常業(yè)務(wù)邏輯和異常業(yè)務(wù)邏輯。測試數(shù)據(jù)的選取可采用GU測試，等價(jià)類劃分、邊界值分析、錯(cuò)誤推測、比較測試等測試方法中的一種或者幾種數(shù)據(jù)的組合，一般以等價(jià)類劃分和邊界值法為主。3.1.1. 系統(tǒng)功能項(xiàng)測試對軟件需求規(guī)格說明書中的所有功能項(xiàng)進(jìn)行測試（列表）；3.1.2. 系統(tǒng)業(yè)務(wù)流程測試對軟件需求規(guī)格說明書中的典型業(yè)務(wù)流程進(jìn)行測試（列表）；3.13系統(tǒng)功能測試標(biāo)準(zhǔn)可測試的功能點(diǎn)100%作為測試需求（如未作為測試需求，必須在測試計(jì)劃中標(biāo)注原因并通知用戶方負(fù)責(zé)人）；測試需求100%被測試用例覆蓋；

4、測試用例100%被實(shí)施（如未實(shí)施，在測試報(bào)告中標(biāo)注未測試的原因并通知用戶方負(fù)責(zé)人）；含有一類缺陷的系統(tǒng)不建議上線發(fā)布（缺陷嚴(yán)重等級見附錄，需確認(rèn)）；含有二類缺陷的系統(tǒng)不建議上線發(fā)布（缺陷嚴(yán)重等級見附錄，需確認(rèn)）；含有三類缺陷10個(gè)以上不建議上線發(fā)布（缺陷嚴(yán)重等級見附錄，需確認(rèn)）；權(quán)限矩陣測試覆蓋率100%。3.2. 易用性測試本系統(tǒng)的易用性測試不是本次測試的重點(diǎn)。我方的原則是在測試過程中如果發(fā)現(xiàn)有完全不符合IT行業(yè)習(xí)慣的操作、完成一次業(yè)務(wù)過多操作步驟和彈出窗口、界面顏色嚴(yán)重影響閱讀、提示信息過于復(fù)雜或者簡單、業(yè)務(wù)邏輯完全不符合思維邏輯的情況下，我方測試人員會(huì)提出易用性類型的缺陷，此類缺陷由用戶

5、方最終確認(rèn)。易用性測試的內(nèi)容包括：-軟件的用戶界面是否友好，是否出現(xiàn)中英文混雜的界面；-軟件中的提示信息是否清楚、易理解，是否存在原始的英文提示；-軟件中各個(gè)模塊的界面風(fēng)格是否一致；-軟件中的查詢結(jié)果的輸出方式是否比較直觀、合理。3.3.容錯(cuò)測試本系統(tǒng)的容錯(cuò)測試不是本次測試的重點(diǎn)。我方的原則是在測試的過程中檢查對系統(tǒng)對非常規(guī)操作或業(yè)務(wù)流程的容錯(cuò)性處理，是否影響系統(tǒng)的正常運(yùn)行，是否給與用戶明確的提示信息等，此類缺陷由用戶方最終確認(rèn)。容錯(cuò)測試的檢查內(nèi)容包括：-軟件對用戶常見的誤操作是否能進(jìn)行提示；-軟件對用戶的的操作錯(cuò)誤和軟件錯(cuò)誤，是否有準(zhǔn)確、清晰的提示；-軟件對重要數(shù)據(jù)的刪除是否有警告和確認(rèn)提示

6、；-軟件是否能判斷數(shù)據(jù)的有效性，屏蔽用戶的錯(cuò)誤輸入，識(shí)別非法值，并有相應(yīng)的錯(cuò)誤提示。3.4. 安全性測試如用戶方有明確的安全測試需求，可根據(jù)用戶實(shí)際情況，進(jìn)行安全性測試。安全性測試的檢查內(nèi)容包括：-軟件中的密鑰是否以密文方式存儲(chǔ)；-軟件是否有留痕功能，即是否保存有用戶的操作日志；-軟件中各種用戶的權(quán)限分配是否合理；3.5. 性能測試對軟件需求規(guī)格說明書中明確的軟件性能進(jìn)行測試。測試的準(zhǔn)則是要滿足規(guī)格說明書中的各項(xiàng)性能指標(biāo)（需明確說明）。36適應(yīng)性測試參照用戶的軟、硬件使用環(huán)境和需求規(guī)格說明書中的規(guī)定，列出開發(fā)的軟件需要滿足的軟、硬件環(huán)境（包括服務(wù)器環(huán)境、客戶端環(huán)境）。對部署環(huán)境進(jìn)行測試（需明確

7、說明）C3.7.文檔測試用戶文檔包括：安裝手冊、操作手冊和維護(hù)手冊（需明確說明）。對用戶文檔測試的內(nèi)容包括：-操作、維護(hù)文檔是否齊全、是否包含產(chǎn)品使用所需的信息和所有的功能模塊；-用戶文檔描述的信息是否正確，是否沒有歧義和錯(cuò)誤的表達(dá)；-用戶文檔是否容易理解，是否通過使用適當(dāng)?shù)男g(shù)語、圖形表示、詳細(xì)的解釋來表達(dá)；-用戶文檔對主要功能和關(guān)鍵操作是否提供應(yīng)用實(shí)例；4用戶文檔是否有詳細(xì)的目錄表和索引表；-文檔描述與程序當(dāng)前版本符合3.8.用戶有特別要求的測試用戶對于系統(tǒng)是否有特別的要求（需明確說明）4. 預(yù)期提交文檔本次系統(tǒng)測試可能提交的文檔包括測試需求、測試計(jì)劃、測試用例、測試報(bào)告等。其中測試計(jì)劃、報(bào)

8、告等根據(jù)測試回歸次數(shù)而產(chǎn)生多份。4.1. 測試需求文檔首先完成測試需求的整理，閱讀項(xiàng)目功能性說明的相關(guān)文檔，挑選出可以測試的功能點(diǎn)，完成測試需求的整理。4.2. 測試用例文檔測試需求作為今后測試活動(dòng)的指導(dǎo)和目標(biāo)，且為測試工作量的估算提供可計(jì)算的依據(jù)。我方制定測試需求后將測試需求提交相關(guān)人員進(jìn)行審查。通過之后，將根據(jù)測試需求完成功能性測試用例的編寫。4.3. 測試日志文檔測試用例設(shè)計(jì)完成之后，我方將測試用例提交給相關(guān)各方評審。評審?fù)ㄟ^后測試人員按照測試用例實(shí)施測試。測試人員在實(shí)施測試的時(shí)候，將每日填寫測試日志。4.4. 測試報(bào)告完成一次完整的功能測試之后，我方將匯總?cè)毕荩瓿蓽y試報(bào)告。5. 測試

9、工作流程5.1.測試啟動(dòng)開發(fā)方提供項(xiàng)目相關(guān)文檔，包括需求規(guī)格說明書、設(shè)計(jì)文檔、用戶手冊等相關(guān)文檔；開發(fā)方搭建測試環(huán)境，提供必要的軟、硬件；開發(fā)方進(jìn)行系統(tǒng)講解，完成對測試方的培訓(xùn)；測試方閱讀相關(guān)文檔并學(xué)習(xí)使用被測系統(tǒng)；測試方對依據(jù)的文檔中的不足提出意見，由開發(fā)方補(bǔ)充完善文檔。5.2.測試準(zhǔn)備測試方制定必要的標(biāo)準(zhǔn)，提交開發(fā)方和用戶方審閱；測試方整理測試需求，提交開發(fā)方和用戶方審閱；測試方書寫測試計(jì)劃，提交開發(fā)方和用戶方審閱；測試方編寫測試用例，開發(fā)測試腳本，可提交開發(fā)方和用戶方審閱；5.3.測試實(shí)施測試方按照測試計(jì)劃，按照設(shè)計(jì)的測試用例實(shí)施測試，記錄測試過程中的問題。測試方每日完成測試日志，并將測

10、試日志提交開發(fā)方和用戶方。5.4.測試總結(jié)測試方對每次回歸測試提交缺陷列表，編寫測試報(bào)告。6. 三方職責(zé)分工測試過程中需要開發(fā)方精悍有素的人員的大力支持與配合，并且為測試方提供現(xiàn)場技術(shù)支持。開發(fā)方有義務(wù)配合測試方完成本次的系統(tǒng)測試，并提供必要的支持工作。由于測試階段的根本目標(biāo)是盡可能多發(fā)現(xiàn)并排除軟件中潛藏的錯(cuò)誤，最終把一個(gè)高質(zhì)量的軟件系統(tǒng)交給用戶使用，因此用戶方在測試階段的直接參與、指正和確認(rèn)起著十分重要的作用。開發(fā)方需要有專人負(fù)責(zé)本次系統(tǒng)測試工作，組織測試現(xiàn)場和相關(guān)硬件設(shè)備，溝通和協(xié)調(diào)各方關(guān)系。測試方嚴(yán)格按照軟件工程理論進(jìn)行測試，提供專業(yè)測試人員和必要的測試工具，并以用戶方的根本利益為工作原

11、則指導(dǎo)。7. 附錄7.1.軟件錯(cuò)誤的嚴(yán)重性等級7.1.1.Critical：1級錯(cuò)誤這一級別的錯(cuò)誤一般包括以下內(nèi)容:沒有實(shí)現(xiàn)或錯(cuò)誤地實(shí)現(xiàn)重要的功能；業(yè)務(wù)流程存在重大隱患；軟件在操作過程中由于軟件自身的原因自動(dòng)退出系統(tǒng)或出現(xiàn)死機(jī)的情況；軟件在操作過程中由于軟件自身的原因?qū)ο到y(tǒng)或數(shù)據(jù)造成破壞；在現(xiàn)有的軟、硬建設(shè)環(huán)境下不能實(shí)現(xiàn)應(yīng)有的功能；特殊軟件在操作過程中可能危及系統(tǒng)和人身安全等。7.1.2. Major：2級錯(cuò)誤這一級別的錯(cuò)誤一般包括以下內(nèi)容沒有實(shí)現(xiàn)基本功能，并且不存在替代辦法；沒有實(shí)現(xiàn)重要功能中的部分功能，并且不存在替代辦法；業(yè)務(wù)流程銜接錯(cuò)誤；用戶的權(quán)限分配不合理；不可繼續(xù)使用的異常錯(cuò)誤；系統(tǒng)不明原因資源占用增大,導(dǎo)致性能不斷下降；界面與需求不符；7.1.3. Averagte：3級錯(cuò)誤這一級別的錯(cuò)誤一般包括以下內(nèi)容:沒有實(shí)現(xiàn)基本功能，但存在替代辦法；沒有實(shí)現(xiàn)重要功能中的部分功能，但存在替代辦法；可繼續(xù)使用的異常錯(cuò)誤；提示信息存在錯(cuò)誤7.1.4. Minor：4級錯(cuò)