軟件評(píng)測(cè)師教程筆記之軟件測(cè)試基礎(chǔ)

第2章軟件測(cè)試基礎(chǔ)1、什么是軟件測(cè)試測(cè)試（test）被當(dāng)作一個(gè)常規(guī)的檢驗(yàn)產(chǎn)品質(zhì)量的生產(chǎn)活動(dòng)。測(cè)試的含義為“為檢驗(yàn)產(chǎn)品是否滿足需求為目標(biāo)”?！败浖y(cè)試”的經(jīng)典定義是在規(guī)定條件下對(duì)程序進(jìn)行操作，以發(fā)現(xiàn)錯(cuò)誤，對(duì)軟件質(zhì)量進(jìn)行評(píng)估。軟件是由文檔、數(shù)據(jù)以及程序組成的，那么軟件測(cè)試就應(yīng)該是對(duì)軟件形成過程的文檔、數(shù)據(jù)以及程序進(jìn)行的測(cè)試，而不僅僅是對(duì)程序進(jìn)行的測(cè)試。2、什么是軟件質(zhì)量ISO9126中定義的“軟件質(zhì)量”是：軟件滿足規(guī)定或潛在用戶需求特性的總和。ISO14598中“軟件質(zhì)量”定義是：軟件特性的總和，軟件滿足規(guī)定或潛在用戶需求的能力。ISO9126定義的軟件質(zhì)量包括“內(nèi)部質(zhì)量”、“外部質(zhì)量”、“使用質(zhì)量”三部分。也就是說，“軟件滿足規(guī)定或潛在用戶需求的能力”要從軟件在內(nèi)部、外部和使用中的表現(xiàn)來衡量。3、軟件測(cè)試是在規(guī)定條件下對(duì)程序進(jìn)行操作，以發(fā)現(xiàn)錯(cuò)誤，對(duì)軟件質(zhì)量進(jìn)行評(píng)估。4、軟件質(zhì)量定義是：軟件特性的總和，軟件滿足規(guī)定或潛在用戶需求的能力。軟件質(zhì)量包括：內(nèi)部質(zhì)量、外部質(zhì)量、使用質(zhì)量三個(gè)部分。5、軟件測(cè)試與質(zhì)量保證的區(qū)別：質(zhì)量保證（QA）質(zhì)量保證的重要工作通過預(yù)防、檢查與改進(jìn)來保證軟件質(zhì)量。QA采用“全面質(zhì)量管理”和“過程改進(jìn)”的原理開展質(zhì)量保證工作。關(guān)注軟件質(zhì)量的檢查與測(cè)量。軟件測(cè)試也與軟件開發(fā)過程緊密相關(guān)，關(guān)心的不是過程的活動(dòng)，而是對(duì)過程的產(chǎn)物以及開發(fā)出的軟件進(jìn)行剖析。測(cè)試員要“執(zhí)行”軟件，對(duì)過程中的產(chǎn)物開發(fā)文檔和源代碼進(jìn)行走查，運(yùn)行軟件，以找出問題，報(bào)告質(zhì)量。對(duì)測(cè)試中發(fā)現(xiàn)的問題的分析、追蹤和回歸測(cè)試。軟件測(cè)試是保證軟件質(zhì)量的一個(gè)重要環(huán)節(jié)。6、軟件測(cè)試目的測(cè)試目的三個(gè)觀點(diǎn)：測(cè)試是程序的執(zhí)行過程，目的在于發(fā)現(xiàn)錯(cuò)誤；一個(gè)好的測(cè)試用例在于能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯(cuò)誤；一個(gè)成功的測(cè)試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試；測(cè)試的目的，是想以最少的人力、物力和時(shí)間找出軟件潛在的各種錯(cuò)誤和缺陷，通過修正各種錯(cuò)誤和缺陷

提高軟件質(zhì)量，回避軟件發(fā)布后由于潛在的軟件缺陷和錯(cuò)誤造居的隱患所帶來的商業(yè)風(fēng)險(xiǎn)。測(cè)試是對(duì)軟件質(zhì)量的度量與評(píng)價(jià)，以驗(yàn)證軟件的質(zhì)量滿足用戶的需求的程度，為用戶選擇與接受軟件提供有力的依據(jù)。7、軟件測(cè)試原則所有的軟件測(cè)試都應(yīng)追溯到用戶需求。

應(yīng)當(dāng)把“盡早地和不斷地進(jìn)行軟件測(cè)試”作為軟件測(cè)試者的座左銘。

完全測(cè)試是不可能的，測(cè)試需要終止。

在有限的時(shí)間和資源條件下，軟件趨于完美，是不可能的。主要有三個(gè)原因：

軟件入量太大；

輸出結(jié)果太多；

路徑組合太多。

測(cè)試無法顯示軟件潛在的缺陷

充分注意測(cè)試中的群集現(xiàn)象。

程序員應(yīng)避免檢查自己的程序。

盡量避免測(cè)試的隨意性。（應(yīng)該從工程的角度去理解軟件測(cè)試，它是有組織、有計(jì)劃、步驟的活動(dòng)。）8、軟件測(cè)試對(duì)象根據(jù)軟件定義，軟件包括程序、數(shù)據(jù)和文檔，所以軟件測(cè)試并不僅僅是程序測(cè)試。在軟件編碼結(jié)束后，對(duì)編寫的每一個(gè)程序模塊進(jìn)行測(cè)試，稱為模塊測(cè)試或單元測(cè)試。在模塊集成后，對(duì)集成在一起模塊組件，有時(shí)稱為部件，進(jìn)行測(cè)試，稱為集成測(cè)試。在集成測(cè)試后，需要檢測(cè)與證實(shí)軟件是否滿足軟件需求說明書中規(guī)定的要求，稱為確認(rèn)測(cè)試。將整個(gè)程序模塊集成為軟件系統(tǒng)，安裝在運(yùn)行環(huán)境下，對(duì)硬件、網(wǎng)絡(luò)、操作系統(tǒng)及支撐平臺(tái)構(gòu)成的整體系統(tǒng)進(jìn)行測(cè)試，稱為系統(tǒng)測(cè)試。軟件錯(cuò)誤中，屬于需求分析和軟件設(shè)計(jì)的錯(cuò)誤約為64%，屬于程序編寫的錯(cuò)誤僅占36%。驗(yàn)證（verification）是保證軟件正確實(shí)現(xiàn)特定功能的一系列活動(dòng)和過程，目的是保證軟件生命周期中的每一個(gè)階段的成果滿足上一個(gè)階段所設(shè)定的目標(biāo)。確認(rèn)（validation）是保證軟件滿足用戶需求的一系列的活動(dòng)和過程，目的是在軟件開發(fā)完成后保證軟件與用戶需求相符合。驗(yàn)證與確認(rèn)都屬于軟件測(cè)試，它包括對(duì)軟件分析、設(shè)計(jì)以及程序的驗(yàn)證和確認(rèn)。需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)以及程序編碼等各階段所得到的文檔，包括需求規(guī)格說明、概要設(shè)計(jì)規(guī)格說明、詳細(xì)設(shè)計(jì)規(guī)格說明以及源程序，都應(yīng)成為“軟件測(cè)試”的對(duì)象。在軟件編碼結(jié)束后，對(duì)編寫的每一個(gè)程序模塊進(jìn)行測(cè)試，稱為“模塊測(cè)試”或“單元測(cè)試”；在模塊集成后，對(duì)集成在一起的模塊組件，有時(shí)也可稱為“部件”，進(jìn)行測(cè)試，稱為“集成測(cè)試”；在集成測(cè)試后，需要檢測(cè)與證實(shí)軟件是否滿足軟件需求說明書中規(guī)定的要求，稱為“確認(rèn)測(cè)試”。將整個(gè)程序模塊集成為軟件系統(tǒng)，安裝在運(yùn)行環(huán)境下，對(duì)硬件、網(wǎng)絡(luò)、操作系統(tǒng)及支撐平臺(tái)構(gòu)成的整體系統(tǒng)進(jìn)行測(cè)試，稱為“系統(tǒng)測(cè)試”。測(cè)試過程按4個(gè)步驟進(jìn)行，即單元測(cè)試、集成（組裝）測(cè)試、確認(rèn)測(cè)試和系統(tǒng)測(cè)試。9、軟件測(cè)試分類按照開發(fā)階段劃分軟件測(cè)試可分為：?jiǎn)卧獪y(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、確認(rèn)測(cè)試和驗(yàn)收測(cè)試。單元測(cè)試：?jiǎn)卧獪y(cè)試又稱模塊測(cè)試，是針對(duì)軟件設(shè)計(jì)的最小單位——程序模塊進(jìn)行正確性檢驗(yàn)的測(cè)試工作。其目的在于檢查每個(gè)程序單元能否正確實(shí)現(xiàn)詳細(xì)設(shè)計(jì)說明中的模塊功能、性能、接口和設(shè)計(jì)約束等要求，發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種錯(cuò)誤。單元測(cè)試需要從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計(jì)測(cè)試用例。多個(gè)模塊可以平行地獨(dú)立進(jìn)行單元測(cè)試。集成測(cè)試：也叫組裝測(cè)試。通常在單元測(cè)試的基礎(chǔ)上，將所有的程序模塊進(jìn)行有序的、遞增的測(cè)試。集成測(cè)試是檢驗(yàn)程序單元或部件的接口關(guān)系，逐步集成為符合概要設(shè)計(jì)要求的程序部件或整個(gè)系統(tǒng)。確認(rèn)測(cè)試：就是通過檢驗(yàn)和提供客觀證據(jù)，證實(shí)軟件是否滿足特定預(yù)期用途的要求。確認(rèn)測(cè)試是檢測(cè)與證實(shí)軟件是否滿足軟件需求說明書中規(guī)定的要求。系統(tǒng)測(cè)試：它是為驗(yàn)證和確認(rèn)系統(tǒng)是否達(dá)到其原始目標(biāo)，而對(duì)集成的硬件和軟件系統(tǒng)進(jìn)行的測(cè)試。系統(tǒng)測(cè)試是在真實(shí)或模擬系統(tǒng)運(yùn)行的環(huán)境下，檢查完整的程序系統(tǒng)能否（包括硬件、外設(shè)、網(wǎng)絡(luò)和系統(tǒng)軟件、支持平臺(tái)等）正確配置、連接，并滿足用戶需求。驗(yàn)收測(cè)試：按照項(xiàng)目任務(wù)書或合同、供需雙方約定的驗(yàn)收依據(jù)文檔進(jìn)行的對(duì)整個(gè)系統(tǒng)的測(cè)試與評(píng)審，決定是否接收或拒收系統(tǒng)。按照開發(fā)階段劃分單元測(cè)試。單元測(cè)試又稱模塊測(cè)試，是針對(duì)程序模塊進(jìn)行正確性檢驗(yàn)的測(cè)試工作。集成測(cè)試集成測(cè)試也叫組裝測(cè)試。通常在單元測(cè)試的基礎(chǔ)上，將所有的程序模塊進(jìn)行有序的、遞增的測(cè)試。集成測(cè)試是檢驗(yàn)程序或部件的接口關(guān)系，逐步集成為符合概要設(shè)計(jì)要求的程序部件或整個(gè)系統(tǒng)。冒煙測(cè)試也叫驗(yàn)證測(cè)試、提交測(cè)試。確認(rèn)測(cè)試確認(rèn)測(cè)試是通過檢驗(yàn)和提供客觀證據(jù)，證實(shí)軟件是否滿足特定預(yù)期用途的需求。確認(rèn)測(cè)試是檢測(cè)與證實(shí)軟件是否滿足軟件需求說明書中規(guī)定的要求。系統(tǒng)測(cè)試系統(tǒng)測(cè)試是為驗(yàn)證和確認(rèn)系統(tǒng)是否達(dá)到其原始目標(biāo)，而對(duì)集成的硬件和軟件系統(tǒng)進(jìn)行的測(cè)試。系統(tǒng)測(cè)試是在真實(shí)或模擬系統(tǒng)運(yùn)行的環(huán)境下，檢查完整的程序系統(tǒng)能否和系統(tǒng)（包括硬件、外設(shè)、網(wǎng)絡(luò)和系統(tǒng)軟件、支持平臺(tái)等）正確配置、連接、并滿足用戶需求。驗(yàn)收測(cè)試按照項(xiàng)目任務(wù)書或合同、供需雙方約定的驗(yàn)收依據(jù)文檔進(jìn)行的對(duì)整個(gè)系統(tǒng)的測(cè)試與評(píng)審，決定是否接收或拒收系統(tǒng)。按照測(cè)試實(shí)施組織劃分按照測(cè)試實(shí)施組織劃分，軟件測(cè)試可分為開發(fā)方測(cè)試、用戶測(cè)試（Beta測(cè)試）、第三方測(cè)試。（1）開發(fā)方測(cè)試通常也叫“驗(yàn)證測(cè)試”或“α測(cè)試”。驗(yàn)證測(cè)試是在軟件開發(fā)環(huán)境下，由開發(fā)者檢測(cè)與證實(shí)軟件的實(shí)現(xiàn)是否滿足軟件設(shè)計(jì)說明或軟件需求說明的要求。主要是指在軟件開發(fā)完成以后，開發(fā)方對(duì)要提交的軟件進(jìn)行全面的自我檢查與驗(yàn)證，可以和軟件的“系統(tǒng)測(cè)試”一并進(jìn)行。（2）用戶測(cè)試在用戶的應(yīng)用環(huán)境下，用戶通過運(yùn)行和使用軟件，檢測(cè)與核實(shí)軟件實(shí)現(xiàn)是否符合自己預(yù)期的要求。用戶測(cè)試不是指用戶的“驗(yàn)收測(cè)試”，而是指用戶的使用性測(cè)試，由用戶找出軟件的應(yīng)用過程中發(fā)現(xiàn)的軟件的缺陷與問題，并對(duì)使用質(zhì)量進(jìn)行評(píng)價(jià)。（3）第三方測(cè)試介于軟件開發(fā)方和用戶方之間的測(cè)試組織的測(cè)試。一般情況下是在模擬用戶真實(shí)應(yīng)用環(huán)境下，進(jìn)行軟件確認(rèn)測(cè)試。按照測(cè)試技術(shù)劃分按照測(cè)試技術(shù)劃分：白盒測(cè)試、黑盒測(cè)試、灰盒測(cè)試。也可劃分為靜態(tài)測(cè)試和動(dòng)態(tài)測(cè)試。靜態(tài)測(cè)試是指不運(yùn)行程序，通過人工對(duì)程序和文檔進(jìn)行分析與檢查：靜態(tài)測(cè)試技術(shù)又稱靜態(tài)分析技術(shù)，靜態(tài)測(cè)試實(shí)際上是對(duì)軟件中的需求說明書、設(shè)計(jì)說明書、程序源代碼等進(jìn)行非運(yùn)行的檢查，靜態(tài)測(cè)試包括：走查、符號(hào)執(zhí)行、需求確認(rèn)等。動(dòng)態(tài)測(cè)試是指通過人工或使用工具運(yùn)行程序進(jìn)行檢查、分析程序的執(zhí)行狀態(tài)和程序的外部表現(xiàn)。（1）白盒測(cè)試通過對(duì)程序內(nèi)部結(jié)構(gòu)的分析、檢測(cè)來尋找問題。了解程序結(jié)構(gòu)和處理過程，檢查是否所有的結(jié)構(gòu)及路徑都是正確的，檢查軟件內(nèi)部動(dòng)作是否按照設(shè)計(jì)說明的規(guī)定正常進(jìn)行。（2）黑盒測(cè)試通過軟件的外部表現(xiàn)來發(fā)現(xiàn)其缺陷和錯(cuò)誤。黑盒測(cè)試法把測(cè)試對(duì)象看成一個(gè)黑盒子，完全不考慮程序內(nèi)部結(jié)構(gòu)和處理過程。黑盒測(cè)試是在程序界面處進(jìn)行測(cè)試，它只是檢查程序是否按照需求規(guī)格說明書的規(guī)定正常實(shí)現(xiàn)。（3）灰盒測(cè)試灰盒測(cè)試關(guān)注輸出對(duì)于輸入的正確性靜態(tài)測(cè)試它是指不運(yùn)行程序，通過人工對(duì)程序和文檔進(jìn)行分析與檢查；靜態(tài)測(cè)試技術(shù)又稱靜態(tài)分析技術(shù)，靜態(tài)測(cè)試實(shí)際上是對(duì)軟件中的需求說明書、設(shè)計(jì)說明書、程序源代碼等進(jìn)行非運(yùn)行檢查，靜態(tài)測(cè)試包括：走查、符號(hào)執(zhí)行、需求確認(rèn)等。動(dòng)態(tài)測(cè)試它是指通過人工或使用工具運(yùn)行程序進(jìn)行檢查、分析程序的執(zhí)行狀態(tài)和程序的外部表現(xiàn)。白盒測(cè)試又稱結(jié)構(gòu)測(cè)試。通過對(duì)程序內(nèi)部結(jié)構(gòu)的分析、檢測(cè)來尋找問題。黑盒測(cè)試通過軟件的外部表現(xiàn)來發(fā)現(xiàn)其缺陷和錯(cuò)誤。它是在程序界面處進(jìn)行測(cè)試，它只是檢查樣序是否按照需求規(guī)格說明書的規(guī)定正常實(shí)現(xiàn)。10、軟件測(cè)試過程模型V模型它反映了測(cè)試活動(dòng)與分析和設(shè)計(jì)的關(guān)系，從左到右，描述了基本的開發(fā)過程和測(cè)試行為，非常明確地標(biāo)明了測(cè)試過程中存在的不同級(jí)別，并且清楚地描述了這些測(cè)試階段和開發(fā)過程期間各階段的對(duì)應(yīng)關(guān)系，如圖所示，圖中的箭頭代表了時(shí)間方向，左邊下降的是開發(fā)過程各階段，與此相對(duì)應(yīng)的是右邊上升的部分，即各測(cè)試過程的各個(gè)階段。V模型指出，單元和集成測(cè)試是驗(yàn)證的程序設(shè)計(jì)，檢測(cè)程序的執(zhí)行是否滿足軟件設(shè)計(jì)的要求；系統(tǒng)測(cè)試應(yīng)當(dāng)驗(yàn)證系統(tǒng)設(shè)計(jì)，檢測(cè)系統(tǒng)功能、性能的質(zhì)量特性是否達(dá)到系統(tǒng)設(shè)計(jì)的指標(biāo)；測(cè)試員和用戶進(jìn)行軟件的確認(rèn)測(cè)試和驗(yàn)收測(cè)試，追溯軟件需求說明書進(jìn)行測(cè)試，以確定軟件的實(shí)現(xiàn)是否滿足用戶需求或合同的要求。V模型存在一定的局限性，它僅僅是測(cè)試過程作為在需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)及編碼后的一個(gè)階段。需求分析階段隱藏的問題一直到后期的驗(yàn)收測(cè)試才被發(fā)現(xiàn)。V模型的軟件測(cè)試策略既包括低層測(cè)試又包括了高層測(cè)試，低層測(cè)試是為了源代碼的正確性，高層測(cè)試為了使整個(gè)系統(tǒng)滿足用戶的需求。W模型1、W模型建立V模型的局限性在于沒有明確地說明早期的測(cè)試，不能體現(xiàn)“盡早地和不斷地進(jìn)行軟件測(cè)試”的原則。在V模型中增加軟件各開發(fā)階段應(yīng)同步進(jìn)行的測(cè)試，被演化為一種W模型，因?yàn)閷?shí)際上開發(fā)是“V”，測(cè)試也是與此相并行的“V”?；凇氨M早地和不斷地進(jìn)行軟件測(cè)試”的原則，優(yōu)點(diǎn)：測(cè)試伴隨著整個(gè)軟件開發(fā)周期，而且測(cè)試的對(duì)象不僅僅是程序，需求、功能和設(shè)計(jì)同樣要測(cè)試。體現(xiàn)“盡早地和不斷地進(jìn)行軟件測(cè)試”的原則。在V模型中增加軟件和開發(fā)階段應(yīng)同步進(jìn)行的測(cè)試。局限性：軟件開發(fā)和測(cè)試保持一種線性的前后關(guān)系，需要有嚴(yán)格的指令表示上一階段完全結(jié)束，才可正式開始下一個(gè)階段。這就無法支持迭代、自發(fā)性以及變更調(diào)整。2、W模型應(yīng)用它強(qiáng)調(diào)：測(cè)試伴隨著整個(gè)軟件開發(fā)周期，而且測(cè)試的對(duì)象不僅僅是程序，需求、功能和設(shè)計(jì)同樣要測(cè)試。只要相應(yīng)的開發(fā)活動(dòng)完成，我們就可以開始執(zhí)行測(cè)試，可以說，測(cè)試與開發(fā)是同步進(jìn)行的，有利于盡早地發(fā)現(xiàn)問題。以需求為例，需求分析一完成，我們就可以對(duì)需求進(jìn)行測(cè)試，而不是等到最后才進(jìn)行針對(duì)需求的驗(yàn)收測(cè)試。參與前期工作的測(cè)試者可以預(yù)先估計(jì)問題和難度，這將可以顯著地減少總體測(cè)試時(shí)間，加快項(xiàng)目進(jìn)度。根據(jù)W模型的要求，一旦有文檔提供，就要及時(shí)確定測(cè)試條件，以及編寫測(cè)試用例。W模型也是有局限性。W模型和V模型都把軟件的開發(fā)視為需求、設(shè)計(jì)、編碼等一系列串行的活動(dòng)。同樣的，軟件開發(fā)和測(cè)試保持一種線性的前后關(guān)系，需要有嚴(yán)格的指令表示上一階段完全結(jié)束，才可正式開始下一個(gè)階段。這樣就無法支持迭代、自發(fā)性以及變更調(diào)整。H模型1、H模型建立它將測(cè)試活動(dòng)獨(dú)立出來，形成一個(gè)完全獨(dú)立的流程，將測(cè)試準(zhǔn)備活動(dòng)和測(cè)試執(zhí)行活動(dòng)清晰地體現(xiàn)出來。2、H模型應(yīng)用軟件測(cè)試不僅僅指測(cè)試的執(zhí)行，還包括很多其他的活動(dòng)。軟件測(cè)試是一個(gè)獨(dú)立的流程，貫穿產(chǎn)品整個(gè)生命周期，與其他流程并發(fā)地進(jìn)行。軟件測(cè)試要盡早準(zhǔn)備，盡早執(zhí)行。軟件測(cè)試是根據(jù)被測(cè)物的不同而分層次進(jìn)行的。不同層次的測(cè)試活動(dòng)可以是按照某個(gè)次序先后進(jìn)行的，但也可能是反復(fù)的。在H模型中，軟件測(cè)試模型是一個(gè)獨(dú)立的流程，貫穿于整個(gè)產(chǎn)品周期，與其他流程并發(fā)地進(jìn)行。其他模型X模型該模型定位了探索性測(cè)試。Marick對(duì)V模型最主要批評(píng)是V模型無法引導(dǎo)項(xiàng)目全部過程。他認(rèn)為一個(gè)模型必須能處理開發(fā)的所有方面，包括交接、頻繁重復(fù)的集成以及需求文檔的缺乏等。2、前置測(cè)試模型它是一個(gè)將測(cè)試和開發(fā)緊密結(jié)合的模型，該模型提供了輕松的方式，可使你的項(xiàng)目加快速度。前置測(cè)試模型體現(xiàn)了以下的要點(diǎn)：（1）開發(fā)和測(cè)試相結(jié)合；前置測(cè)試模型將開發(fā)和測(cè)試的生命周期整合在一起，標(biāo)識(shí)了項(xiàng)目生命周期從開始到結(jié)束之間的關(guān)鍵行為。（2）對(duì)每一個(gè)交付內(nèi)容進(jìn)行測(cè)試；每一個(gè)交付的開發(fā)結(jié)果都必須通過一定的方式進(jìn)行測(cè)試。（3）在設(shè)計(jì)階段進(jìn)行測(cè)試計(jì)劃和測(cè)試設(shè)計(jì)；設(shè)計(jì)階段是作測(cè)試計(jì)劃和測(cè)試設(shè)計(jì)的最好時(shí)機(jī)。（4）測(cè)試和開發(fā)結(jié)合在一起；前置測(cè)試將測(cè)試執(zhí)行和開發(fā)結(jié)合在一起，并在開發(fā)階段以編碼——測(cè)試——編碼——測(cè)試的方式來體現(xiàn)。（5）讓驗(yàn)收測(cè)試和技術(shù)測(cè)試保持相互獨(dú)立。驗(yàn)收測(cè)試應(yīng)該獨(dú)立于技術(shù)測(cè)試，這樣可以提供雙重的保險(xiǎn)，以保證設(shè)計(jì)及程序編碼能夠符合最終用戶的需求。10、軟件生命周期測(cè)試策略軟件開發(fā)與軟件測(cè)試軟件開發(fā)的過程是一個(gè)自頂向下，逐步細(xì)化的過程。測(cè)試過程則是依照相反的順序安排自底向上，逐步集成的過程。軟件測(cè)試策略測(cè)試過程按4個(gè)步驟進(jìn)行，即單元測(cè)試、集成（組裝）測(cè)試、確認(rèn)測(cè)試和系統(tǒng)測(cè)試。1、測(cè)試信息流測(cè)試過程需要以下三類輸入：軟件配置：包括軟件需求規(guī)格說明、軟件設(shè)計(jì)規(guī)格說明、源代碼等。測(cè)試配置：包括測(cè)試計(jì)劃、測(cè)試用例、測(cè)試驅(qū)動(dòng)程序等。測(cè)試配置只是軟件配置的一個(gè)子集。測(cè)試工具：2、分析設(shè)計(jì)階段分析設(shè)計(jì)階段的測(cè)試工作是評(píng)審與測(cè)試相結(jié)合的過程，主要包括需求說明書評(píng)測(cè)、概要設(shè)計(jì)說明書、詳細(xì)設(shè)計(jì)說明書評(píng)測(cè)以及軟件編碼規(guī)范評(píng)測(cè)等。編制良好的需求說明書8條原則：功能與實(shí)現(xiàn)分離；要求使用面向處理的規(guī)格說明語言；描述該目標(biāo)軟件與系統(tǒng)的其他系統(tǒng)元素交互的方式；規(guī)格說明必須包括系統(tǒng)運(yùn)行的環(huán)境；系統(tǒng)規(guī)格說明必須是一個(gè)認(rèn)識(shí)的模型；規(guī)格說明必須是可操作的；規(guī)格說明必須容許不完備性并允許擴(kuò)充；規(guī)格說明必須局部化和松散的耦合。（1）需求說明書評(píng)測(cè)需求說明書是分析任務(wù)的最終產(chǎn)物，通過建立完整的信息描述、詳細(xì)的功能和行為描述、性能需求和設(shè)計(jì)約束的說明、性能需求和設(shè)計(jì)約束的說明、合適的驗(yàn)收標(biāo)準(zhǔn)，給出對(duì)目標(biāo)軟件的各種需求。需求說明書評(píng)測(cè)內(nèi)容：系統(tǒng)定義的目標(biāo)是否與用戶的要求一致。系統(tǒng)需求分析階段提供的文檔資料是否齊全。文檔中的所有描述是否完整、清晰、準(zhǔn)確地反映用戶要求；與所有其他系統(tǒng)成份的重要接口是否都已經(jīng)描述；被開發(fā)項(xiàng)目的數(shù)據(jù)流與數(shù)據(jù)結(jié)構(gòu)是否足夠、確定；所有圖表是否清楚，在不補(bǔ)充說明時(shí)能否理解；主要功能是否已包括在規(guī)定的軟件范圍之內(nèi)，是否都已充分說明；軟件的行為和它必須處理的信息、必須完成的功能是否一致；設(shè)計(jì)的約束條件或限制條件是否符合實(shí)際；是否考慮了開發(fā)的技術(shù)風(fēng)險(xiǎn)；是否考慮過軟件需求的其他方案；是否考慮過將來可能會(huì)提出的軟件需求；是否詳細(xì)制定了檢驗(yàn)標(biāo)準(zhǔn)，它們能否對(duì)系統(tǒng)定義是否成功進(jìn)行確認(rèn)；有沒有遺漏、重復(fù)或不一致的地方；用戶是否審查了初步的用戶手冊(cè)或原型；項(xiàng)目開發(fā)計(jì)劃中的估算是否受到了影響。（1）需求說明書評(píng)測(cè)編制良好的需求說明書8條原則。原則1：功能與實(shí)現(xiàn)分離，即描述要“做什么”而不是“怎樣實(shí)現(xiàn)”。原則2：要求使用面向處理的規(guī)格說明語言，討論來自環(huán)境的各種刺激可能導(dǎo)致系統(tǒng)做出什么樣的功能性反應(yīng)，來定義一個(gè)行為模型，從而得到“做什么”的規(guī)格說明。原則3：如果目標(biāo)軟件只是一個(gè)大系統(tǒng)中的一個(gè)元素，那么整個(gè)系統(tǒng)也包括在規(guī)格說明的描述之中。原則4：規(guī)格說明必須包括系統(tǒng)運(yùn)行的環(huán)境。原則5：系統(tǒng)規(guī)格說明必須是一個(gè)認(rèn)識(shí)的模型，而不是設(shè)計(jì)或?qū)崿F(xiàn)的模型。原則6：規(guī)格說明必須是可操作的。原則7：規(guī)格說明必須容許不完備性并允許擴(kuò)充。原則8：規(guī)格說明必須局部化和松散的耦合。需求說明書的框架。需求說明書是分析任務(wù)的最終產(chǎn)物，通過建立完整的信息描述、詳細(xì)的功能和行為描述、性能需求和設(shè)計(jì)約束的說明、合適的驗(yàn)收標(biāo)準(zhǔn)，給出對(duì)目標(biāo)軟件的各種需求。需求說明書評(píng)測(cè)內(nèi)容。需求說明書評(píng)測(cè)作為需求分析階段工作的復(fù)查手段，應(yīng)該對(duì)功能的正確性、完整性和清晰性，以及其他需求給予評(píng)測(cè)。評(píng)測(cè)的主要內(nèi)容是：（1）系統(tǒng)定義的目標(biāo)是否與用戶的要求一致；（2）系統(tǒng)需求分析階段提供的文檔資料是否齊全；（3）文檔中的所有描述是否完整、清晰，準(zhǔn)確地反映用戶要求；（4）與所有其他系統(tǒng)成份的重要接口是否都已經(jīng)描述；（5）被開發(fā)項(xiàng)目的數(shù)據(jù)流與數(shù)據(jù)結(jié)構(gòu)是否足夠、確定；（6）所有圖表是否清楚，在不補(bǔ)充說明時(shí)能否理解；（7）主要功能是否已包括在規(guī)定的軟件范圍之內(nèi)，是否都已充分說明；（8）軟件的行為和它必須處理的信息、必須完成的功能是否一致；（9）設(shè)計(jì)的約束條件或限制條件是否符合實(shí)際；（10）是否考慮了開發(fā)的技術(shù)風(fēng)險(xiǎn)；（11）是否考慮過軟件需求的其他方案；（12）是否考慮過將來可能會(huì)提出的軟件需求；（13）是否詳細(xì)制定了檢驗(yàn)標(biāo)準(zhǔn)，它們能否對(duì)系統(tǒng)定義是否成功進(jìn)行確認(rèn)；（14）有沒有遺漏、重復(fù)或不一致的地方；（15）用戶是否審查了初步的用戶手冊(cè)或原型；（16）項(xiàng)目開發(fā)計(jì)劃中的估算是否受到了影響。（2）概要設(shè)計(jì)說明書評(píng)測(cè)設(shè)計(jì)說明書的框架設(shè)計(jì)說明書的框架內(nèi)容：（1）可追溯性（2）接口（3）風(fēng)險(xiǎn)（4）實(shí)用性（5）技術(shù)清晰度（6）可維護(hù)性（7）質(zhì)量（8）各種選擇方案（9）限制（10）其他具體問題為評(píng)測(cè)設(shè)計(jì)是否達(dá)到目標(biāo)，必須建立衡量設(shè)計(jì)的技術(shù)標(biāo)準(zhǔn)。如下：主要評(píng)測(cè)內(nèi)容：可追溯性；接口；風(fēng)險(xiǎn)；實(shí)用性；技術(shù)清晰度；可維護(hù)性；質(zhì)量；各種選擇方案；限制；其他具體問題。（1）設(shè)計(jì)出來的結(jié)構(gòu)應(yīng)是分層結(jié)構(gòu)，從而建立軟件成分之間的控制；（2）設(shè)計(jì)出來的結(jié)構(gòu)應(yīng)是分層結(jié)構(gòu)，從而建立軟件成分之間的控制；（3）設(shè)計(jì)應(yīng)當(dāng)既包含數(shù)據(jù)抽象，也包含過程抽象；（4）設(shè)計(jì)應(yīng)當(dāng)建立具有獨(dú)立功能特征的模塊；（5）設(shè)計(jì)應(yīng)當(dāng)建立能夠降低模塊與外部環(huán)境之間復(fù)雜連接的接口；（6）設(shè)計(jì)應(yīng)當(dāng)根據(jù)軟件需求分析獲取的信息，建立可驅(qū)動(dòng)、可重復(fù)的方法。（3）詳細(xì)設(shè)計(jì)說明書評(píng)測(cè)與概要設(shè)計(jì)說明書基本相同。（4）軟件編碼規(guī)范評(píng)測(cè)程序?qū)嶋H上也是一種供人閱讀的文章，有一個(gè)文章的風(fēng)格問題。程序良好的風(fēng)格表現(xiàn)在源程序文檔化、數(shù)據(jù)說明的方法、語句結(jié)構(gòu)的輸入/輸出方法這四個(gè)方面，軟件編碼規(guī)范評(píng)測(cè)也是圍繞這四個(gè)方面展開。源程序文檔化（1）符號(hào)名的命名。符號(hào)名即標(biāo)識(shí)符，包括模塊名、變量名、常量名、標(biāo)號(hào)名、子程序名、數(shù)據(jù)區(qū)名以及緩沖區(qū)名等。（2）程序的注釋。注釋分為序言性注釋和功能性注釋。（3）標(biāo)準(zhǔn)的書寫格式。數(shù)據(jù)說明（1）數(shù)據(jù)說明的次序應(yīng)當(dāng)規(guī)范化。（2）說明語句中變量安排有序化。（3）使用注釋說明復(fù)雜數(shù)據(jù)結(jié)構(gòu)。語句結(jié)構(gòu)在設(shè)計(jì)階段確定了軟件的邏輯流結(jié)構(gòu)，但構(gòu)造單個(gè)語句則是編碼階段的任務(wù)。語句構(gòu)造力求簡(jiǎn)單、直接，不能為了片面追求效率而使語句復(fù)雜化。輸入和輸出輸入和輸出信息是與用戶的使用直接相關(guān)的。輸入和輸出的方式和格式應(yīng)當(dāng)盡可能方便用戶的使用。一定要避免因設(shè)計(jì)不當(dāng)給用戶帶來的麻煩。因此，在軟件需求分析階段和設(shè)計(jì)階段，就應(yīng)基本確定輸入和輸出的風(fēng)格。系統(tǒng)能否被用戶接受，有時(shí)就取決于輸入和輸出的風(fēng)格。不論是批處理的輸入/輸出方式，還是交互式的輸入/輸出方式，在設(shè)計(jì)和程序編碼時(shí)都應(yīng)考慮下列原則。輸入和輸出在設(shè)計(jì)和程序編碼時(shí)都應(yīng)考慮下列原則。（1）對(duì)所有的輸入數(shù)據(jù)都要進(jìn)行檢驗(yàn)，識(shí)別錯(cuò)誤的輸入，以保證每個(gè)數(shù)據(jù)的有效性；（2）檢查輸入項(xiàng)的各種重要組合的合理性，必要時(shí)報(bào)告輸入狀態(tài)信息；（3）使輸入的步驟和操作盡可能簡(jiǎn)單，并保持簡(jiǎn)單的輸入格式；（4）輸入數(shù)據(jù)時(shí)，應(yīng)允許使用自由格式輸入；（5）應(yīng)允許缺省值；（6）輸入一批數(shù)據(jù)時(shí)，最好使用輸入結(jié)束標(biāo)志，而不要由用戶指定輸入數(shù)據(jù)數(shù)目；（7）在交互式輸入時(shí)，要在屏幕上使用提示符，明確提示交互輸入的請(qǐng)求，指明可使用選擇項(xiàng)的種類和取值范圍。同時(shí)，在數(shù)據(jù)輸入的過程中和輸入結(jié)束時(shí)，也要在屏幕上給出狀態(tài)信息；（8）當(dāng)程序設(shè)計(jì)語言對(duì)輸入/輸出格有嚴(yán)格要求時(shí)，應(yīng)保持輸入格式與輸入語句要求的一致性；（9）給所有的輸出加注解，并設(shè)計(jì)輸出報(bào)表格式。3、開發(fā)階段（1）單元測(cè)試單元測(cè)試的內(nèi)容：在進(jìn)行單元測(cè)試時(shí)，測(cè)試者需要依據(jù)詳細(xì)設(shè)計(jì)說明書和源程序清單，了解該模塊的I/O條件和模塊的邏輯結(jié)構(gòu)，主要采用白盒測(cè)試的測(cè)試用例，輔之黑盒測(cè)試的測(cè)試用例。使之對(duì)任何合理的輸入和不合理的輸入，都能鑒別和響應(yīng)。這要求對(duì)所有的局部的和全局的數(shù)據(jù)結(jié)構(gòu)、外部接口和程序代碼的關(guān)鍵部分，都要進(jìn)行桌面檢查和嚴(yán)格的代碼審查。在單元測(cè)試中進(jìn)行的測(cè)試工作如圖2-9所示，需要在五個(gè)方面對(duì)所測(cè)模塊進(jìn)行檢查。在進(jìn)行單元測(cè)試時(shí)，測(cè)試者需要依據(jù)詳細(xì)設(shè)計(jì)說明書和源程序清單，了解該模塊的I/O條件和模塊的邏輯結(jié)構(gòu)，主要采用白盒測(cè)試的測(cè)試用例，輔之以黑盒測(cè)試的測(cè)試用例，使之對(duì)任何合理的輸入和不合理的輸入，都能鑒別和響應(yīng)。這要求對(duì)所有的局部的和全局的數(shù)據(jù)結(jié)構(gòu)、外部接口和程序代碼的關(guān)鍵部分，都要進(jìn)行桌面檢查和嚴(yán)格的代碼審查。1）模塊接口測(cè)試在單元測(cè)試的開始，應(yīng)對(duì)通過所測(cè)模塊的數(shù)據(jù)流進(jìn)行測(cè)試。如果數(shù)據(jù)不能正確地輸入和輸出，就談不上進(jìn)行其他測(cè)試。為此，對(duì)模塊接口可能需要如下的測(cè)試項(xiàng)目：調(diào)用所測(cè)模塊時(shí)的輸入?yún)?shù)與模塊的形式參數(shù)在個(gè)數(shù)、屬性、順序上是否匹配；所測(cè)模塊調(diào)用子模塊時(shí)，它輸入給子模塊的參數(shù)與子模塊中的形式參數(shù)在個(gè)數(shù)、屬性、順序上是否匹配；是否修改了只作輸入用的形式參數(shù)；輸出給標(biāo)準(zhǔn)函數(shù)的參數(shù)在個(gè)數(shù)、屬性、順序上是否正確；全局量的定義在各模塊中是否一致；限制是否通過形式參數(shù)來傳送。2）局部數(shù)據(jù)結(jié)構(gòu)測(cè)試設(shè)計(jì)測(cè)試用例以檢查以下各種錯(cuò)誤：不正確或不一致的數(shù)據(jù)類型說明；使用尚未賦值或尚未初始化的變量；錯(cuò)誤的初始值或錯(cuò)誤的缺省值；變量名拼寫錯(cuò)或書寫錯(cuò)；不一致的數(shù)據(jù)類型。3）路徑測(cè)試常見的不正確計(jì)算有：運(yùn)算的優(yōu)先次序不正確或誤解了運(yùn)算的優(yōu)先次序；運(yùn)算的方式錯(cuò)，即運(yùn)算的對(duì)象彼此在類型上不相容；算法錯(cuò)；初始化不正確；運(yùn)算精度不夠；表達(dá)式的符號(hào)表示不正確。4）錯(cuò)誤處理測(cè)試比較完善的模塊設(shè)計(jì)要求能預(yù)見出錯(cuò)的條件，并設(shè)置適當(dāng)?shù)某鲥e(cuò)處理，以便在一旦程序出錯(cuò)時(shí)，能對(duì)出錯(cuò)程序重做安排，保證其邏輯上的正確性。模塊和錯(cuò)誤處理功能包含有錯(cuò)誤或缺陷：出錯(cuò)的描述難以理解；出錯(cuò)的描述不足以對(duì)錯(cuò)誤定位，不足以確定出錯(cuò)的原因；顯示的錯(cuò)誤與實(shí)際的錯(cuò)誤不符；對(duì)錯(cuò)誤條件的處理不正確；在對(duì)錯(cuò)誤進(jìn)行處理之前，錯(cuò)誤條件已經(jīng)引起系統(tǒng)的干預(yù)等。5）邊界測(cè)試單元測(cè)試步驟：驅(qū)動(dòng)模塊（driver）相當(dāng)于所測(cè)模塊的主程序。它接收測(cè)試數(shù)據(jù)，把這些數(shù)據(jù)傳送給所測(cè)模塊，最后輸出實(shí)測(cè)結(jié)果。樁模塊（stub）也叫存根模塊。用以代替所測(cè)模塊調(diào)用的子模塊。樁模塊可以做少量的數(shù)據(jù)操作，不需要把子模塊所有功能都帶進(jìn)來，但不允許什么事情也不做。（2）集成測(cè)試集成測(cè)試也叫做組裝測(cè)試或聯(lián)合測(cè)試。在單元測(cè)試的基礎(chǔ)上，需要將所有模塊按照概要設(shè)計(jì)說明書和詳細(xì)設(shè)計(jì)說明書的要求進(jìn)行組裝。組成時(shí)需要考慮的問題：1）在把各個(gè)模塊連接起的時(shí)候，穿越模塊接口的數(shù)據(jù)是否會(huì)丟失；2）一個(gè)模塊的功能是否會(huì)對(duì)另一個(gè)模塊的功能產(chǎn)生不利的影響；3）各個(gè)子功能組合起來，能否達(dá)到預(yù)期要求的父功能；4）全局?jǐn)?shù)據(jù)結(jié)構(gòu)是否有問題；5）單個(gè)模塊的誤差累積起來，是否會(huì)放大，以至達(dá)到不能接受的程度。子系統(tǒng)的集成測(cè)試稱為部件測(cè)試，它所做的工作是要找出組裝后的子系統(tǒng)與系統(tǒng)需求規(guī)格說明之間的不一致。模塊組裝成為系統(tǒng)的方式。模塊組裝成為系統(tǒng)的方式有兩種：一次性組裝方式和增殖式組裝方式。1）一次性組裝方式它是一種非增殖式組裝方式，也叫做整體拼裝。使用這種方式，首先對(duì)每個(gè)模塊分別進(jìn)行模塊測(cè)試，再把所有模塊組裝在一起進(jìn)行測(cè)試，最終得到要求的軟件系統(tǒng)。2）增殖式組裝方式這種組裝方式又稱漸增式組裝，是首先對(duì)一個(gè)個(gè)模塊進(jìn)行模塊測(cè)試，然后將這些模塊逐步組裝成較大的系統(tǒng)，在組裝的過程中邊連接邊測(cè)試，以發(fā)現(xiàn)連接過程中產(chǎn)生的問題。最后通過增殖逐步組裝成為要求的軟件系統(tǒng)。自頂向下的增殖方式。步驟如下：首先以主模塊作為所測(cè)模塊兼驅(qū)動(dòng)模塊，所有直屬于主模塊的下屬模塊全部用樁模塊代替，對(duì)主模塊進(jìn)行測(cè)試。再采用深度優(yōu)先或廣度優(yōu)先的策略，用實(shí)際模塊替換相應(yīng)的樁模塊，再用樁模塊代替它們的直接下屬模塊，與已測(cè)試的模塊或子系統(tǒng)組裝成新的子系統(tǒng)。然后，進(jìn)行回歸測(cè)試（即重新執(zhí)行以前做過的全部測(cè)試或部分測(cè)試），排除組裝過程中引新的錯(cuò)誤的可能。最后，判斷是否所有的模塊都已組裝到系統(tǒng)中。自頂向下的增殖方式在測(cè)試過程中較早地驗(yàn)證了主要的控制和判斷點(diǎn)。在一個(gè)功能劃分合理的程序模塊結(jié)構(gòu)中，判斷常常出現(xiàn)在較高的層次里，因而，能夠較早地遇到這種問題。如果選用按深度方向組裝的方式，可以首先實(shí)現(xiàn)和驗(yàn)證一個(gè)完整的軟件功能，可先對(duì)邏輯輸入的分支進(jìn)行組裝和測(cè)試，檢查和克服潛藏的錯(cuò)誤和缺陷，驗(yàn)證其功能的正確性，就為其后對(duì)主要加工分支的組裝和測(cè)試提供了保證。自底向上的增殖方式。提高測(cè)試效率。進(jìn)行集成測(cè)試時(shí)，測(cè)試者應(yīng)當(dāng)確定關(guān)鍵模塊，對(duì)這些關(guān)鍵模塊及早進(jìn)行測(cè)試。關(guān)鍵模塊至少應(yīng)具有以下幾種特征之一：滿足某些軟件需求；在程序的模塊結(jié)構(gòu)中位于較高的層次（高層控制模塊）；較復(fù)雜、較易發(fā)生錯(cuò)誤；有明確定義的性能要求。在做回歸測(cè)試時(shí)，也應(yīng)該集中測(cè)試關(guān)鍵模塊的功能。集成測(cè)試的組織和實(shí)施。集成測(cè)試是一種正規(guī)測(cè)試過程，必須精心計(jì)劃，并與單元測(cè)試的完成時(shí)間協(xié)調(diào)起來。在制定測(cè)試計(jì)劃時(shí)，應(yīng)考慮如下因素：（1）采用何種系統(tǒng)組裝方法來進(jìn)行集成測(cè)試。（2）集成測(cè)試過程中連接各個(gè)模塊的順序。（3）模塊代碼編制和測(cè)試進(jìn)度是否與集成測(cè)試的順序一致。（4）測(cè)試過程中是否需要專門的硬件設(shè)備。集成測(cè)試完成的標(biāo)志。集成測(cè)試完成的標(biāo)志主要有以下幾項(xiàng)。（1）成功地執(zhí)行了測(cè)試計(jì)劃中規(guī)定的所有集成測(cè)試。（2）修正了所發(fā)現(xiàn)的錯(cuò)誤。（3）測(cè)試結(jié)果通過了專門小組的評(píng)審。集成測(cè)試需要提交的文檔有集成測(cè)試計(jì)劃、集成測(cè)試規(guī)格說明書和集成測(cè)試分析報(bào)告。（3）確認(rèn)測(cè)試確認(rèn)測(cè)試的任務(wù)是驗(yàn)證軟件的功能和性能及其他特性是否與用戶的要求一致。對(duì)軟件的功能和性能要求在軟件需求規(guī)格說明中明確規(guī)定。確認(rèn)測(cè)試一般包括有效性測(cè)試和軟件配置復(fù)查，確認(rèn)測(cè)試一般由獨(dú)立的第三方測(cè)試機(jī)構(gòu)進(jìn)行。進(jìn)行有效性測(cè)試。有效性測(cè)試是在模擬的環(huán)境下，運(yùn)用黑盒測(cè)試的方法，驗(yàn)證所測(cè)軟件是否滿足需求規(guī)格說明書列出的要求。在全部軟件測(cè)試的測(cè)試用例運(yùn)行完后，所有的測(cè)試結(jié)果可以分為兩類。（1）測(cè)試結(jié)果與預(yù)期的結(jié)果相符。這說明軟件的部分功能或性能特征與需求規(guī)格說明書相符合，從而接受了這部分程序。（2）測(cè)試結(jié)果與預(yù)期的結(jié)果不符。這說明軟件的這部分功能或性能特征與需求規(guī)格說明不一致，因此要為它提交一份問題報(bào)告。軟件配置復(fù)查。（4）系統(tǒng)測(cè)試系統(tǒng)測(cè)試是將通過集成測(cè)試的軟件，作為整個(gè)基于計(jì)算機(jī)系統(tǒng)的一個(gè)元素，與計(jì)算機(jī)硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起，在實(shí)際或模擬運(yùn)行（使用）環(huán)境下，對(duì)計(jì)算機(jī)系統(tǒng)進(jìn)行一系統(tǒng)列測(cè)試。（5）驗(yàn)收測(cè)試4、軟件驗(yàn)證與確認(rèn)（V&V）過程軟件的V&V過程是確定按照規(guī)定的軟件過程開發(fā)的產(chǎn)品是否符合活動(dòng)的要求，軟件是否滿足它的預(yù)期用途和用戶需要。軟件的V&V過程包括軟件產(chǎn)品和過程的分析、評(píng)價(jià)、評(píng)審、審核、評(píng)估和測(cè)試。軟件測(cè)試活動(dòng)是軟件V&V過程的一個(gè)組成部分。軟件測(cè)試過程的任務(wù)與管理也要符合軟件V&V過程的有關(guān)規(guī)定。（1）V&V基本概念驗(yàn)證（Verfication）：通過檢查和提供客觀證據(jù)，證實(shí)規(guī)定的需求已滿足。確認(rèn)（Validation）：通過檢查和提供客觀證據(jù)，證實(shí)預(yù)期用途的需求是否得到滿足。獨(dú)立驗(yàn)證和確認(rèn)：由在技術(shù)、管理和財(cái)務(wù)上與開發(fā)組織有規(guī)定程度獨(dú)立性的組織執(zhí)行的V&V過程。（2）軟件V&V過程軟件生存周期的V&V過程框架。軟件開發(fā)過程的V&V概述。（3）軟件V&V過程中的測(cè)試測(cè)試過程。需求V&V活動(dòng)中的測(cè)試。2.8軟件失效分類與管理2.8.1軟件失效分類軟件錯(cuò)誤（softwareerror）軟件缺陷（softwaredefect）軟件故障（softwarefault）軟件失效（softwarefailure）軟件失效機(jī)理可描述為：軟件錯(cuò)誤軟件缺陷軟件故障軟件失效（1）軟件錯(cuò)誤是指在軟件生存期內(nèi)的不希望或不可接受的人為錯(cuò)誤，其結(jié)果是導(dǎo)致軟件缺陷的產(chǎn)生。可見，軟件錯(cuò)誤是一種人為過程，相對(duì)于軟件本身，是一種外部行為。（2）軟件缺陷存在于軟件（文檔、數(shù)據(jù)、程序）之中的那些不希望或不可接受的偏差。其結(jié)果是軟件運(yùn)行于某一特定條件時(shí)出現(xiàn)軟件故障，這時(shí)稱軟件缺陷激動(dòng)。（3）軟件故障是指軟件運(yùn)行過程中出現(xiàn)的一種不希望或不可接受的內(nèi)部狀態(tài)。（4）軟件失效是指軟件運(yùn)行時(shí)產(chǎn)生的一種不希望或不可接受的外部行為結(jié)果。錯(cuò)誤的廣義定義是：不正確的事務(wù)和行為。錯(cuò)誤是在系統(tǒng)運(yùn)行時(shí)，引起或可能潛在地引起失效的缺陷，是一種面向開發(fā)概念。軟件缺陷：（1）軟件未達(dá)到產(chǎn)品說明書中標(biāo)明的功能；（2）軟件出現(xiàn)了產(chǎn)品說明書中指明的不會(huì)出現(xiàn)的錯(cuò)誤；（3）軟件功能超出了產(chǎn)品說明書指明的范圍；（4）軟件未達(dá)到產(chǎn)品說明書雖未指出應(yīng)達(dá)到的目標(biāo)；（5）軟件測(cè)試人員認(rèn)為軟件難以理解、不易使用、運(yùn)行速度慢，或最終用戶認(rèn)為不好使用。產(chǎn)品說明書是軟件缺陷的第一來源，也就出自于軟件需求說明書本身的問題。設(shè)計(jì)方案（軟件設(shè)計(jì)說明書）是軟件缺陷第二來源。2.8.2缺陷與錯(cuò)誤分布2.8.3缺陷與錯(cuò)誤嚴(yán)重性和優(yōu)先級(jí)軟件存在的缺陷與錯(cuò)誤會(huì)帶來軟件失敗的風(fēng)險(xiǎn)，重要軟件故障與失效會(huì)導(dǎo)致重大經(jīng)濟(jì)損失與災(zāi)難。給軟件缺陷與錯(cuò)誤劃分嚴(yán)重性和優(yōu)先級(jí)的通用原則是：（1）表示軟件缺陷所造成的危害的惡劣程度；（2）優(yōu)先級(jí)表示修復(fù)缺陷的重要程度和次序；嚴(yán)重級(jí)：嚴(yán)重：系統(tǒng)崩潰、數(shù)據(jù)丟失、數(shù)據(jù)毀壞較嚴(yán)重：操作性錯(cuò)誤、錯(cuò)誤結(jié)果、遺漏功能一般：小問題、錯(cuò)別字、UI布局、罕見故障建議：不影響使用的瑕疵或更好的實(shí)現(xiàn)優(yōu)先級(jí)：最高優(yōu)先級(jí)：立即修復(fù)，停止進(jìn)一步測(cè)試次高優(yōu)先級(jí)：在產(chǎn)品發(fā)布之前必須修復(fù)中等優(yōu)先級(jí)：如果時(shí)間允許應(yīng)該修復(fù)最低等優(yōu)先級(jí)：可能會(huì)修復(fù)，但是也能發(fā)布2.8.4軟件錯(cuò)誤跟蹤管理軟件測(cè)試的主要目的在于發(fā)現(xiàn)軟件存在的錯(cuò)誤（Bug），如何處理測(cè)試中發(fā)現(xiàn)的錯(cuò)誤，將直接影響到測(cè)試的效果。只有正確、迅速、準(zhǔn)確地處理這些錯(cuò)誤，才能消除軟件錯(cuò)誤，保證要發(fā)布的軟件符合需求設(shè)計(jì)的目標(biāo)。在實(shí)際的軟件測(cè)試過程中，每個(gè)BUG都要經(jīng)過測(cè)試、確認(rèn)、修復(fù)、驗(yàn)證等的管理過程，這是軟件測(cè)試的重要環(huán)節(jié)。作為一個(gè)錯(cuò)誤跟蹤管理系統(tǒng)，需要正確記錄錯(cuò)誤信息和錯(cuò)誤處理信息的全部?jī)?nèi)容。（1）BUG記錄信息主要包括以下幾項(xiàng)內(nèi)容。測(cè)試軟件名稱測(cè)試版本號(hào)測(cè)試人名稱測(cè)試事件測(cè)試軟件和硬件配置環(huán)境發(fā)現(xiàn)軟件錯(cuò)誤的類型錯(cuò)誤的嚴(yán)重等級(jí)詳細(xì)步驟必要的附圖測(cè)試注釋（2）BUG處理信息處理者姓名處理時(shí)間處理步驟錯(cuò)誤記錄的當(dāng)前狀態(tài)2、軟件錯(cuò)誤的狀態(tài)新信息（New）：測(cè)試中新報(bào)告的軟件BUG打開（Open）：被確認(rèn)并分配給相關(guān)開發(fā)人員處理。修正（Fixed）：開發(fā)人員已完成修正，等待測(cè)試人員驗(yàn)證。拒絕（Declined）拒絕修改BUG延期（Deferred）：不在當(dāng)前版本修復(fù)的錯(cuò)誤，下一步修復(fù)。關(guān)閉（Closed）：BUG已被修復(fù)。3、錯(cuò)誤管理流程4、錯(cuò)誤流程管理原則2.9白盒測(cè)試2.10黑盒測(cè)試黑盒測(cè)試也稱為功能測(cè)試，它是通過測(cè)試來檢測(cè)每個(gè)功能是否都能正常使用。在完全不考慮內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，在程序接口進(jìn)行測(cè)試，它只檢查程序功能是否按照需求說明書的規(guī)定正常使用，程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)據(jù)而產(chǎn)生正確的輸出信息。主要針對(duì)軟件界面和軟件功能進(jìn)行測(cè)試。黑盒測(cè)試法注重于測(cè)試軟件的功能需求，主要試圖發(fā)現(xiàn)下列幾類錯(cuò)誤。功能不正確或遺漏界面錯(cuò)誤數(shù)據(jù)庫訪問錯(cuò)誤性能錯(cuò)誤初始化和終止錯(cuò)誤黑盒測(cè)試用例設(shè)計(jì)方法包括等價(jià)類劃分法、邊界值分析法、錯(cuò)誤推測(cè)法、因果圖法、判定表驅(qū)動(dòng)法、正交試驗(yàn)設(shè)計(jì)法、功能圖法等。2.11自動(dòng)化測(cè)試2.11.1自動(dòng)化測(cè)試的基本概念自動(dòng)化測(cè)試的定義：通過測(cè)試工具或其他手段，按照測(cè)試工程師的預(yù)定計(jì)劃對(duì)軟件產(chǎn)品進(jìn)行自動(dòng)的測(cè)試，它是軟件測(cè)試的一個(gè)重要的組成部分，它能夠完成許多手工無法完成或難以實(shí)現(xiàn)的一些測(cè)試。正確、合理地實(shí)施自動(dòng)化測(cè)試，能夠快速、全在財(cái)對(duì)軟件進(jìn)行測(cè)試，從而提高軟件質(zhì)量，節(jié)省經(jīng)費(fèi)，縮短產(chǎn)品發(fā)布周期。2.11.2自動(dòng)化測(cè)試的優(yōu)勢(shì)與局限1、自動(dòng)化測(cè)試的優(yōu)勢(shì)避免重復(fù)測(cè)試，同時(shí)，還能完成大量手工無法完成的測(cè)試工作，如并發(fā)用戶測(cè)試、大數(shù)據(jù)量測(cè)試、長(zhǎng)時(shí)間運(yùn)行可靠性測(cè)試等，優(yōu)點(diǎn)：提高測(cè)試質(zhì)量提高測(cè)試效率，縮短測(cè)試工作時(shí)間提高測(cè)試覆蓋率執(zhí)行手工測(cè)試不能完成的測(cè)試任務(wù)更好地重現(xiàn)軟件缺陷的能力更好地利用資源增進(jìn)測(cè)試人員與開發(fā)人員之間的合作伙伴關(guān)系以下項(xiàng)目和環(huán)境中更適合使用自動(dòng)化測(cè)試工具：需要反復(fù)進(jìn)行的工作負(fù)載壓力測(cè)試測(cè)試人員和開發(fā)人員有效合作借助測(cè)試管理工具，會(huì)取得事半功倍的效果。若需要進(jìn)行測(cè)試系統(tǒng)后臺(tái)或者內(nèi)部的性能特性，進(jìn)而進(jìn)行故障定位和性能調(diào)優(yōu)。2、自動(dòng)化測(cè)試的局限性定制型項(xiàng)目周期很短的項(xiàng)目業(yè)務(wù)規(guī)則復(fù)雜的對(duì)象