軟件測試基本概念

章軟件測試基本概念2021/5/91目錄軟件缺陷1軟件測試的分類2靜態(tài)測試與動態(tài)測試3主動測試與被動測試4黑盒測試與白盒測試5軟件測試級別6軟件測試計(jì)劃與用例7專業(yè)測試人員的責(zé)任和要求82021/5/921軟件缺陷2021/5/93缺陷是質(zhì)量的對立面要了解什么是缺陷(Defect)，就必須清楚“質(zhì)量(Quality)”概念，因?yàn)槿毕菔窍鄬|(zhì)量而存在的，違背了質(zhì)量、違背了客戶的意愿，不能滿足客戶的要求，就會引起缺陷或產(chǎn)生缺陷2021/5/941.軟件質(zhì)量的內(nèi)涵質(zhì)量的定義

質(zhì)量管理專家朱蘭對“質(zhì)量”的定義：滿足使用要求的基礎(chǔ)是質(zhì)量的特征，產(chǎn)品的任何特征（性質(zhì)、屬性等）、材料或滿足使用要求的過程都是質(zhì)量特征。

1986年ISO8492給出了質(zhì)量的定義：質(zhì)量是產(chǎn)品或服務(wù)所滿足明示或暗示需求能力的固有特性和特征的集合。固有特性：某事物中本來就有的，尤其是那種永久性的特性明示的特性：理解為規(guī)定的要求，用于描述或者客戶明確提出的那些要求暗示的特性：是由社會習(xí)俗約定、行為慣例所要求的一種潛規(guī)則、不言而喻的。2021/5/951.軟件質(zhì)量的內(nèi)涵IEEESTD729：軟件產(chǎn)品滿足規(guī)定的和隱含的與需求能力有關(guān)的全部特征和特性。主要包括：軟件產(chǎn)品滿足使用要求的程度軟件各種屬性的組合程度用戶對軟件產(chǎn)品的綜合反映程度軟件在使用過程中滿足用戶要求的程度2021/5/961.軟件質(zhì)量的內(nèi)涵高質(zhì)量軟件標(biāo)準(zhǔn)體系（1）軟件產(chǎn)品的質(zhì)量

是人們實(shí)踐產(chǎn)物的屬性和行為，是可以認(rèn)識，可以科學(xué)地描述的。并且可以通過一些方法和人類活動，來改進(jìn)質(zhì)量（2）軟件開發(fā)過程中的質(zhì)量

是指過程滿足明確和隱含需要的能力的特性之總和（3）應(yīng)用領(lǐng)域或者業(yè)務(wù)上的質(zhì)量

在商業(yè)過程中有關(guān)的質(zhì)量內(nèi)容:培訓(xùn)、成品制作、宣傳、發(fā)布日起、客戶、風(fēng)險(xiǎn)、成本、業(yè)務(wù)等2021/5/971.軟件質(zhì)量的內(nèi)涵產(chǎn)品質(zhì)量的標(biāo)準(zhǔn)功能性Functionality可用性Usability可靠性Reliability性能Performance容量Capacity可伸縮性Scalability可維護(hù)性Servicemanageability兼容性Compatibility可擴(kuò)展性Extensibility2021/5/981.軟件質(zhì)量的內(nèi)涵軟件質(zhì)量模型Boehm質(zhì)量模型McCall質(zhì)量模型ISO質(zhì)量模型2021/5/991.軟件質(zhì)量的內(nèi)涵互用性正確性可靠性效率完整性可用性可維護(hù)性可測試性靈活性可移植性重復(fù)性闡述性數(shù)據(jù)公開性連貫性容錯性執(zhí)行效率/儲存效率存取控制/存取檢查可訓(xùn)練溝通良好簡單性易操作的工具自我操作性擴(kuò)展性一般性模塊性軟件系統(tǒng)獨(dú)立性機(jī)器獨(dú)立性通訊公開性正確性可操作性產(chǎn)品操作產(chǎn)品修改產(chǎn)品維護(hù)Boehm軟件質(zhì)量模型2021/5/9101.軟件質(zhì)量的內(nèi)涵McCall軟件質(zhì)量模型2021/5/9111.軟件質(zhì)量的內(nèi)涵功能性可靠性可用性效率可移植性可維護(hù)性匹配性精確性互用性安全性成熟性容錯能力可恢復(fù)性可理解性可學(xué)習(xí)性可操作性時(shí)間表現(xiàn)資源表現(xiàn)可分析性可變化性穩(wěn)定性適應(yīng)性可測試性易安裝性一致性可替換性用戶自定義軟件產(chǎn)品度量標(biāo)準(zhǔn)ISO9126三層模型2021/5/9121.軟件質(zhì)量的內(nèi)涵內(nèi)部質(zhì)量、外部質(zhì)量和使用質(zhì)量的關(guān)系2021/5/9131.軟件質(zhì)量的內(nèi)涵軟件質(zhì)量特征(ISO9126)功能：與一組功能及其指定性質(zhì)有關(guān)的一組屬性，這里的功能是滿足明確或隱含的需求的那些功能?？煽浚涸谝?guī)定的一段時(shí)間和條件下，與軟件維持其性能水平的能力有關(guān)的一組屬性。易用：由一組規(guī)定或潛在的用戶為使用軟件所需作的努力和所作的評價(jià)有關(guān)的一組屬性。效率：與在規(guī)定條件下軟件的性能水平與所使用資源量之間關(guān)系有關(guān)的一組屬性。可維護(hù)：與進(jìn)行指定的修改所需的努力有關(guān)的一組屬性。可移植：與軟件從一個(gè)環(huán)境轉(zhuǎn)移到另一個(gè)環(huán)境的能力有關(guān)的一組屬性。其中每一個(gè)質(zhì)量特征都分別與若干子特征相對應(yīng)。2021/5/9141.軟件質(zhì)量的內(nèi)涵ISQ/IEC9126-1:2001

《信息技術(shù)-產(chǎn)品質(zhì)量》的第一部分《質(zhì)量模型》

ISO/IECTR9126-2:2003

《IT-產(chǎn)品質(zhì)量》的第二部分《外部質(zhì)量》

ISO/IECTR9126-3:2003

《IT-產(chǎn)品質(zhì)量》的第三部分《內(nèi)部質(zhì)量》

ISO/IECTR9126-3:2003

《IT-產(chǎn)品質(zhì)量》的第四部分《使用質(zhì)量》ISO/IEC14598-1:1999

《IT--軟件產(chǎn)品評估--第一部分：綜述》

ISO/IEC14598-2:2000

《IT--產(chǎn)品評估--第二部分：計(jì)劃和管理》

ISO/IEC14598-3:2000

《IT--產(chǎn)品評估--第三部分：開發(fā)者過程》

ISO/IEC14598-4:1999

《IT--產(chǎn)品評估--第四部分：購買方過程》

ISO/IEC14598-5:1998

《IT--軟件產(chǎn)品評估--第五部分：評估方過程》

ISO/IEC14598-6:2001

《IT--產(chǎn)品評估--第六部分：評估模型文檔》 ISO9126(GB/T16260)《信息技術(shù)軟件產(chǎn)品質(zhì)量》軟件質(zhì)量評價(jià)方法2021/5/9151.軟件質(zhì)量的內(nèi)涵ISO軟件質(zhì)量模型2021/5/9161.軟件質(zhì)量的內(nèi)涵ISO軟件質(zhì)量模型2021/5/9172.缺陷–Defect,Bug缺點(diǎn)（defect）謬誤（fault）失?。╢ailure）矛盾（inconsistency）毛?。╥ncident）偏差（variance）問題（problem）錯誤（error）異常（anomy）2021/5/9182.缺陷–Defect,Bug軟件錯誤(error)在軟件生存期內(nèi)的不希望或者不可接受的人為錯誤。軟件缺陷(defect)任何程序、系統(tǒng)中的問題，和產(chǎn)品設(shè)計(jì)說明書的不一致性，不能滿足用戶的需求。軟件故障(fault)軟件運(yùn)行過程中出現(xiàn)的一種不希望或不可接受的內(nèi)部狀態(tài)。此時(shí)，如果沒有適當(dāng)?shù)奶幚泶胧┑脑?，軟件故障就會?dǎo)致軟件失效。軟件失效(failure)軟件運(yùn)行時(shí)產(chǎn)生的一種不希望或不可接受的外部行為結(jié)果。比如死機(jī)就是一種嚴(yán)重的軟件失效。軟件失效是軟件用戶所能直接感受到的。當(dāng)軟件出現(xiàn)失效時(shí)，必然說明軟件中存在缺陷。2021/5/9192.缺陷–Defect,BugIEEE(1983)729軟件缺陷一個(gè)標(biāo)準(zhǔn)的定義：從產(chǎn)品內(nèi)部看，軟件缺陷是軟件產(chǎn)品開發(fā)或維護(hù)過程中所存在的錯誤、毛病等各種問題；從外部看，軟件缺陷是系統(tǒng)所需要實(shí)現(xiàn)的某種功能的失效或違背。2021/5/9202.缺陷–Defect,Bug軟件缺陷的表現(xiàn)：功能、特性沒有實(shí)現(xiàn)或部分實(shí)現(xiàn)設(shè)計(jì)不合理，存在缺陷實(shí)際結(jié)果和預(yù)期結(jié)果不一致運(yùn)行出錯，包括運(yùn)行中斷、系統(tǒng)崩潰、界面混亂數(shù)據(jù)結(jié)果不正確、精度不夠用戶不能接受的其他問題，如存取時(shí)間過長、界面不美觀2021/5/9212.缺陷–Defect,Bug軟件缺陷被引入的時(shí)間開發(fā)階段規(guī)格說明書設(shè)計(jì)環(huán)節(jié)編碼修復(fù)缺陷時(shí)也可能產(chǎn)生新的缺陷修改代碼后一定要進(jìn)行回歸測試！2021/5/9222.缺陷–Defect,Bug軟件缺陷的產(chǎn)生的主要因素技術(shù)問題開發(fā)人員開發(fā)經(jīng)驗(yàn)不足對采用的新技術(shù)不熟悉程序模塊復(fù)雜度高接口參數(shù)多其他2021/5/9232.缺陷–Defect,Bug軟件本身不合理的軟件開發(fā)流程文檔錯誤沒有考慮軟件實(shí)際使用場景，導(dǎo)致出現(xiàn)負(fù)載問題對程序的邏輯路徑或數(shù)據(jù)范圍的邊界考慮不周全與硬件、第三方系統(tǒng)軟件之間存在接口或依賴性其他2021/5/9242.缺陷–Defect,Bug團(tuán)隊(duì)工作對軟件質(zhì)量問題不重視對客戶需求未調(diào)研清楚或存在誤解不同階段開發(fā)人員理解不一致其他2021/5/9252.缺陷–Defect,Bug2021/5/9262.缺陷–Defect,Bug軟件缺陷的構(gòu)成規(guī)格說明書是缺陷最容易出現(xiàn)的地方開發(fā)人員與用戶的溝通問題軟件產(chǎn)品還沒有設(shè)計(jì)、開發(fā)，完全靠想象描述系統(tǒng)的實(shí)現(xiàn)結(jié)果，有些特性還不夠清晰需求的頻繁變動，造成不一致性對規(guī)格說明書不夠重視，在設(shè)計(jì)和寫作上投入的人力、時(shí)間不足溝通不充分，只有設(shè)計(jì)師或項(xiàng)目經(jīng)理知道的信息較多2021/5/9272.缺陷–Defect,BugRayleigh缺陷模型在真正的程序測試之前，通過審查、評審會可以發(fā)現(xiàn)更多的缺陷。規(guī)格說明書的缺陷會在需求分析審查、設(shè)計(jì)、編碼、測試等過程中會逐步發(fā)現(xiàn)，而不能在需求分析一個(gè)階段發(fā)現(xiàn)2021/5/9282.缺陷–Defect,Bug需求設(shè)計(jì)編碼測試發(fā)布

時(shí)間

缺陷數(shù)早期缺陷發(fā)現(xiàn)（70%-90%）測試前在真正的程序測試之前，通過審查、評審會可以發(fā)現(xiàn)更多的缺陷。軟件缺陷在不同階段的分布2021/5/9292.缺陷–Defect,Bug修復(fù)軟件缺陷的代價(jià)缺陷的代價(jià)是非常高昂的一項(xiàng)統(tǒng)計(jì)數(shù)據(jù)表明，大約62%的項(xiàng)目成本用于修復(fù)軟件缺陷。據(jù)美國NIST在2002年發(fā)布的一項(xiàng)研究估計(jì)，美國經(jīng)濟(jì)每年因軟件Bug會損失600億美金，約合0.6%的國民生產(chǎn)總值2021/5/9302.缺陷–Defect,BugBoehm在其著作《軟件工程經(jīng)濟(jì)學(xué)》中提到如果需求階段糾正一個(gè)錯誤的代價(jià)是1設(shè)計(jì)階段是它的3~6倍編程階段是它的10倍內(nèi)部測試階段是它的20~40倍外部測試階段是它的30~70倍產(chǎn)品發(fā)布時(shí)，這個(gè)數(shù)字是40~1000倍代價(jià)不是呈線性增長，而是呈指數(shù)級增長2021/5/9312.缺陷–Defect,Bug缺陷成本2021/5/9322.缺陷–Defect,Bug缺陷的生命周期

軟件缺陷從被測試人員發(fā)現(xiàn)一直到被修復(fù)，要經(jīng)歷一個(gè)特有的生命周期，階段包括：新建、打開、拒絕、修復(fù)、關(guān)閉、重新打開等。2021/5/9332.缺陷–Defect,Bug2021/5/9342.缺陷–Defect,Bug從上述討論可知，軟件缺陷不僅存在于可執(zhí)行程序中，而且存在于需求定義和設(shè)計(jì)的文檔中，所以軟件測試不僅僅是“為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程”，而且還包括對產(chǎn)品規(guī)格說明書、技術(shù)設(shè)計(jì)文檔等的測試。軟件測試貫穿于整個(gè)軟件開發(fā)過程，是軟件驗(yàn)證和用戶需求確認(rèn)的統(tǒng)一，和軟件評審密不可分。2021/5/9352軟件測試的分類2021/5/9361.軟件測試的分類方法目標(biāo)/特性單元測試系統(tǒng)測試驗(yàn)收測試性能測試強(qiáng)壯性測試功能測試白盒測試黑盒測試測試階段或?qū)哟芜m用性測試可靠性測試集成測試安全性測試2021/5/9371.軟件測試的分類軟件執(zhí)行的角度測試階段的角度測試方法的角度靜態(tài)測試白盒測試動態(tài)測試單元測試黑盒測試集成測試系統(tǒng)測試驗(yàn)收測試回歸測試灰盒測試2021/5/9381.軟件測試的分類測試階段的角度單元測試集成測試系統(tǒng)測試驗(yàn)收測試回歸測試功能測試性能測試隨機(jī)測試2021/5/9391.軟件測試的分類測試方法的角度白盒測試黑盒測試灰盒測試邏輯驅(qū)動基路測試等價(jià)類劃分邊界值分析因果圖錯誤推測2021/5/9401.軟件測試的分類測試過程2021/5/9413靜態(tài)測試和動態(tài)測試2021/5/942

1.靜態(tài)測試和動態(tài)測試靜態(tài)測試包括對軟件產(chǎn)品的需求和設(shè)計(jì)規(guī)格說明書的評審、對程序代碼的復(fù)審等動態(tài)測試是通過真正運(yùn)行程序發(fā)現(xiàn)錯誤，通過觀察代碼運(yùn)行過程，來獲取系統(tǒng)信息，對系統(tǒng)行為進(jìn)行驗(yàn)證。2021/5/943

1.靜態(tài)測試和動態(tài)測試靜態(tài)測試的方法：產(chǎn)品評審靜態(tài)分析2021/5/944評審的形式/方法互為評審(Peerreview)輪查(Pass-round)走查(walk-through)會議評審(Inspection)

2.產(chǎn)品評審最不正式的最正式的臨時(shí)評審輪查走查互為評審?fù)性u審評審2021/5/945評審對象管理評審技術(shù)評審文檔評審流程評審

2.產(chǎn)品評審軟件測試評審對象需求評審設(shè)計(jì)評審代碼評審文檔評審2021/5/946需求和設(shè)計(jì)審查

測試人員參與產(chǎn)品需求分析和系統(tǒng)設(shè)計(jì)，認(rèn)真閱讀有關(guān)文檔，真正理解客戶的需求和技術(shù)上的設(shè)計(jì)，檢查需求說明書對產(chǎn)品描述的準(zhǔn)確性、一致性等，檢查系統(tǒng)設(shè)計(jì)的合理性和可測試性等

2.產(chǎn)品評審2021/5/947靜態(tài)分析的查錯和分析功能是其他方法所不能替代的，可以采用人工檢測和計(jì)算機(jī)輔助靜態(tài)分析手段進(jìn)行檢測，但越來越多地采用工具進(jìn)行自動化分析人工檢測：人工檢測偏重于編碼風(fēng)格、質(zhì)量的檢驗(yàn)，對設(shè)計(jì)、代碼進(jìn)行分析，有效地發(fā)現(xiàn)邏輯設(shè)計(jì)和編碼錯誤。計(jì)算機(jī)輔助靜態(tài)分析：利用靜態(tài)分析工具對被測程序進(jìn)行特性分析，從程序中提取一些信息，以便檢查程序邏輯的各種缺陷和可疑的程序構(gòu)造。3.靜態(tài)分析2021/5/948為了把握各個(gè)環(huán)節(jié)的正確性，人們需要進(jìn)行各種驗(yàn)證和確認(rèn)工作。驗(yàn)證（verification）是保證軟件正確實(shí)現(xiàn)特定功能的一系列活動和過程，目的是保證軟件生命周期中的每一個(gè)階段的成果滿足上一個(gè)階段所設(shè)定的目標(biāo)確認(rèn)（validation）是保證軟件滿足用戶需求的一系列的話動和過程，目的是開發(fā)完成后保證軟件與用戶需求相符合。4.驗(yàn)證和確認(rèn)2021/5/9494主動測試和被動測試2021/5/950主動測試方法：測試人員主動向被測試對象發(fā)送請求、或借助數(shù)據(jù)、事件驅(qū)動被測試對象的行為，從而驗(yàn)證被測試對象的反應(yīng)或輸出結(jié)果被動測試方法：測試人員不干預(yù)產(chǎn)品的運(yùn)行，而是被動地監(jiān)控產(chǎn)品在實(shí)際環(huán)境中運(yùn)行，通過一定的被動機(jī)制來獲得系統(tǒng)運(yùn)行的數(shù)據(jù)，包括輸入、輸出數(shù)據(jù)1.主動測試和被動測試2021/5/9515黑盒測試方法和白盒測試2021/5/952白盒測試

通過對程序內(nèi)部結(jié)構(gòu)的分析、檢測來尋找問題。白盒測試可以把程序看成裝在一個(gè)透明的盒子里，也就是清楚了解程序結(jié)構(gòu)和處理過程，檢查是否所有的結(jié)構(gòu)及路徑都是正確的，檢查軟件內(nèi)部動作是否按照設(shè)計(jì)說明的規(guī)定正常進(jìn)行。白盒測試又稱結(jié)構(gòu)測試。

黑盒測試

通過軟件外部表現(xiàn)來發(fā)現(xiàn)其缺陷和錯誤。黑盒測試法把測試對象看成一個(gè)黑盒子，完全不考慮程序內(nèi)部結(jié)構(gòu)和處理過程。黑盒測試是在程序界面處進(jìn)行測試，它只是檢查樣序是否按照需求說明書的規(guī)定正常實(shí)現(xiàn)。

1.黑盒測試方法和白盒測試2021/5/9531.黑盒測試方法和白盒測試功能測試數(shù)據(jù)驅(qū)動測試結(jié)構(gòu)測試邏輯驅(qū)動測試

客戶需求事件驅(qū)動輸入輸出2021/5/9546軟件測試級別2021/5/955測試級別的劃分單元測試集成測試驗(yàn)收(確認(rèn))測試系統(tǒng)測試1.軟件測試級別2021/5/9561.軟件測試級別SRDCUTITSVTST系統(tǒng)工程單元測試編碼軟件需求分析設(shè)計(jì)集成測試驗(yàn)收測試系統(tǒng)測試2021/5/9572.不同測試級別的任務(wù)調(diào)試組件功能

健壯性

效率組件之間的接口系統(tǒng)功能

安全性

健壯性

效率

功能及用戶界面

安全性

效率

用戶的可接受性組件測試集成測試系統(tǒng)測試實(shí)現(xiàn)（編碼）驗(yàn)收測試測試階段和測試重點(diǎn)：理想狀態(tài)2021/5/958單元測試的對象是程序系統(tǒng)中的最小單元---模塊或組件上，在編碼階段進(jìn)行，針對每個(gè)模塊進(jìn)行測試，主要通過白盒測試方法，從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計(jì)測試用例，檢查程序模塊或組件的已實(shí)現(xiàn)的功能與定義的功能是否一致、以及編碼中是否存在錯誤。多個(gè)模塊可以平行地、獨(dú)立地測試，通常要編寫驅(qū)動模塊和樁模塊單元測試一般由編程人員和測試人員共同完成，而以開發(fā)人員為主單元測試包括代碼評審，代碼評審可以發(fā)現(xiàn)程序50%～70%代碼的缺陷。3.單元測試2021/5/959集成測試，也稱組裝測試、聯(lián)合測試、子系統(tǒng)測試，在單元測試的基礎(chǔ)上，將模塊按照設(shè)計(jì)要求組裝起來同時(shí)進(jìn)行測試，主要目標(biāo)是發(fā)現(xiàn)與接口有關(guān)的模塊之間問題兩種集成方式：一次性集成方式和增殖式集成方式。一次性集成方式：首先對每個(gè)單元分別進(jìn)行測試，然后再把所有單元組裝在一起進(jìn)行測試，最終達(dá)到要求的軟件系統(tǒng)漸增式集成方式：首先對某兩三個(gè)單元進(jìn)行測試，然后在把剩下的單元逐步添加組裝成較大的系統(tǒng)，一邊測試，一邊集成，最后構(gòu)造一個(gè)完整的軟件系統(tǒng)。4.集成測試2021/5/960系統(tǒng)非功能性測試是將軟件放在整個(gè)計(jì)算機(jī)環(huán)境下，包括軟硬件平臺、某些支持軟件、數(shù)據(jù)和人員等，在實(shí)際運(yùn)行環(huán)境下進(jìn)行一系列的測試，包括恢復(fù)測試、安全測試、強(qiáng)度測試和性能測試等系統(tǒng)功能測試一般須在完成集成測試后進(jìn)行，而且是針對應(yīng)用系統(tǒng)進(jìn)行測試。功能測試是基于產(chǎn)品功能說明書，是在已知產(chǎn)品所應(yīng)具有的功能，從用戶角度來進(jìn)行功能驗(yàn)證，以確認(rèn)每個(gè)功能是否都能正常使用5.系統(tǒng)測試2021/5/961驗(yàn)收測試的目的是向未來的用戶表明系統(tǒng)能夠像預(yù)定要求那樣工作，驗(yàn)證軟件的功能和性能如同用戶所合理期待的那樣α測試一種先期的用戶測試，此時(shí)系統(tǒng)剛剛開發(fā)完成。β測試一種后期的用戶測試，此時(shí)系統(tǒng)已經(jīng)通過內(nèi)部測試，大部分錯誤已經(jīng)改正，即將正式發(fā)行。安裝測試是指按照軟件產(chǎn)品安裝手冊或相應(yīng)的文檔，在一個(gè)和用戶使用該產(chǎn)品完全一樣的環(huán)境中或相當(dāng)于用戶使用環(huán)境中，進(jìn)行一步一步的安裝操作性的測試6.驗(yàn)收測試&安裝測試2021/5/9627軟件測試計(jì)劃與用例2021/5/963軟件測試工作的組織與管理：制定測試策略、測試計(jì)劃，確認(rèn)所采用的測試方法與規(guī)范，控制測試進(jìn)度，管理測試資源。測試工作的實(shí)施：編制符合標(biāo)準(zhǔn)的測試文檔，搭建測試環(huán)境，開發(fā)測試腳本、與開發(fā)組織協(xié)作實(shí)現(xiàn)各階段的測試活動1.軟件測試的工作范疇2021/5/9642.測試工作流程主要有6個(gè)方面：（1）測試組織和管理（2）測試計(jì)劃（3）測試用例設(shè)計(jì)（4）測試實(shí)施（5）測試結(jié)果分析（6）測試評審與報(bào)告2021/5/965測試計(jì)劃的定義軟件測試是一個(gè)有組織有計(jì)劃的活動，應(yīng)當(dāng)對時(shí)間和資源制訂測試計(jì)劃，才能在合理的控制下正常進(jìn)行。測試計(jì)劃作為測試的起始步驟，是整個(gè)軟件測試過程的關(guān)鍵。測試計(jì)劃規(guī)定了測試各個(gè)階段所要使用的方法策略、測試環(huán)境、測試通過或失敗的準(zhǔn)則等內(nèi)容?！禔NSI/IEEE軟件測試文檔標(biāo)準(zhǔn)829-1983》將測試計(jì)劃定義為：“一個(gè)敘述了預(yù)定的測試活動的范圍、途徑、資源及進(jìn)度安排的文檔。它確認(rèn)了測試項(xiàng)、被測特征、測試任務(wù)、人員安排，以及任何偶發(fā)事件的風(fēng)險(xiǎn)?！?.軟件測試計(jì)劃2021/5/966測試計(jì)劃的目的和作用

測試計(jì)劃的目的是明確測試活動的意圖，規(guī)范軟件測試內(nèi)容、方法和過程，為有組織地完成測試任務(wù)提供保障。盡管測試的每一個(gè)步驟都是獨(dú)立的，但是必須要有一個(gè)起到框架結(jié)構(gòu)作用的測試計(jì)劃。軟件測試計(jì)劃是整個(gè)測試過程中最重要的部分，為實(shí)現(xiàn)可管理且高質(zhì)量的測試過程提供基礎(chǔ)。3.軟件測試計(jì)劃2021/5/967測試計(jì)劃書

測試計(jì)劃文檔化即是測試計(jì)劃書，分為總體計(jì)劃和分級計(jì)劃，是可以更新改進(jìn)的文檔。測試計(jì)劃書描述了軟件測試預(yù)計(jì)達(dá)到的目標(biāo)，確定測試過程所要采用的方法策略。從文檔的角度看，測試計(jì)劃書是最重要的測試文檔。3.軟件測試計(jì)劃2021/5/968測試計(jì)劃的內(nèi)容

測試計(jì)劃包括測試目的、測試范圍、測試對象、測試策略、測試任務(wù)、測試用例、資源配置、測試結(jié)果分析和度量以及測試風(fēng)險(xiǎn)評估等，測試計(jì)劃應(yīng)當(dāng)足夠完整但也不應(yīng)當(dāng)太詳盡。實(shí)際的測試計(jì)劃內(nèi)容因不同的測試對象而靈活變化。3.軟件測試計(jì)劃2021/5/969測試用例定義

所謂的測試用例就是將軟件測試的行為活動，做一個(gè)科學(xué)化的組織歸納。軟件測試是有組織性、步驟性和計(jì)劃性的，而設(shè)計(jì)軟件測試用例的目的，就是為了能將軟件測試的行為轉(zhuǎn)換為可管理的模式。

軟件測試是軟件質(zhì)量管理中最實(shí)際的行動，同時(shí)也是耗時(shí)最多的一項(xiàng)?；跁r(shí)間因素的考慮，軟件測試行為必須能夠加以量化，才能進(jìn)一步讓管理階層掌握所需要的測試過程，而測試用例就是將測試行為具體量化的方法之一。4.測試用例2021/5/970測試用例要素所屬模塊：按照不同的模塊進(jìn)行測試，為測試用例分組；編號ID：測試用例的唯一性標(biāo)志；用例描述：簡單的語言描述所測試的內(nèi)容，例如“設(shè)置廣播服務(wù)器網(wǎng)絡(luò)參數(shù)，并測試網(wǎng)絡(luò)連通性”；重要級別：高、中、低三級；、預(yù)置條件：就是執(zhí)行當(dāng)前測試用例的前提描述，如果不滿足這些條件，則無法進(jìn)行測試；測試輸入：測試用例執(zhí)行時(shí)，需要輸入的外部信息。例如：某一個(gè)文件，數(shù)據(jù)記錄等；4.測試用例2021/5/971操作步驟：執(zhí)行當(dāng)前測試用例所要經(jīng)過的操作步驟，需要給出每一步操作的詳細(xì)描述，測試人員根據(jù)測試用例操作步驟，完成測試用例的執(zhí)行預(yù)期結(jié)果：當(dāng)前測試用例的預(yù)期輸出結(jié)果，用來與實(shí)際結(jié)果比較，如果相同則該測試用例通過，否則該測試用例失敗。測試結(jié)果：Pass、Fail、Block4.測試用例2021/5/972良好測試用例的特征1.完整的2.準(zhǔn)確3.清晰、簡潔4.可維護(hù)性5.適當(dāng)性6.可復(fù)用性7.其他4.測試用例2021/