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

《軟件評(píng)測(cè)師教程筆記之第2章軟件測(cè)試基礎(chǔ)》由會(huì)員分享，可在線閱讀，更多相關(guān)《軟件評(píng)測(cè)師教程筆記之第2章軟件測(cè)試基礎(chǔ)（25頁(yè)珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。

1、第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)”。 “軟件測(cè)試”的經(jīng)典定義是在規(guī)定條件下對(duì)程序進(jìn)行操作，以發(fā)覺(jué)錯(cuò)誤，對(duì)軟件質(zhì)量進(jìn)行評(píng)估。 軟件是由文檔、數(shù)據(jù)以及程序組成的，那么軟件測(cè)試就應(yīng)當(dāng)是對(duì)軟件形成過(guò)程的文檔、數(shù)據(jù)以及程序進(jìn)行的測(cè)試，而不僅僅是對(duì)程序進(jìn)行的測(cè)試。 2、什么是軟件質(zhì)量 ISO9126中定義的“軟件質(zhì)量”是：軟件滿意規(guī)定或潛在用戶需求特性的總和。 ISO14598中“軟件質(zhì)量”定義是：軟件特性的總和，軟件滿意規(guī)定或潛在用戶需求的實(shí)力。 ISO9126定義的軟件質(zhì)量包括“內(nèi)

2、部質(zhì)量”、“外部質(zhì)量”、“運(yùn)用質(zhì)量”三部分。也就是說(shuō)，“軟件滿意規(guī)定或潛在用戶需求的實(shí)力”要從軟件在內(nèi)部、外部和運(yùn)用中的表現(xiàn)來(lái)衡量。 3、軟件測(cè)試是在規(guī)定條件下對(duì)程序進(jìn)行操作，以發(fā)覺(jué)錯(cuò)誤，對(duì)軟件質(zhì)量進(jìn)行評(píng)估。 4、軟件質(zhì)量定義是：軟件特性的總和，軟件滿意規(guī)定或潛在用戶需求的實(shí)力。 軟件質(zhì)量包括：內(nèi)部質(zhì)量、外部質(zhì)量、運(yùn)用質(zhì)量三個(gè)部分。 5、軟件測(cè)試與質(zhì)量保證的區(qū)分： 質(zhì)量保證（QA）質(zhì)量保證的重要工作通過(guò)預(yù)防、檢查與改進(jìn)來(lái)保證軟件質(zhì)量。QA采納“全面質(zhì)量管理”和“過(guò)程改進(jìn)”的原理開(kāi)展質(zhì)量保證工作。關(guān)注軟件質(zhì)量的檢查與測(cè)量。 軟件測(cè)試也與軟件開(kāi)發(fā)過(guò)程緊密相關(guān)，關(guān)切的不是過(guò)程的活動(dòng)，而是

3、對(duì)過(guò)程的產(chǎn)物以及開(kāi)發(fā)出的軟件進(jìn)行剖析。測(cè)試員要“執(zhí)行”軟件，對(duì)過(guò)程中的產(chǎn)物開(kāi)發(fā)文檔和源代碼進(jìn)行走查，運(yùn)行軟件，以找出問(wèn)題，報(bào)告質(zhì)量。對(duì)測(cè)試中發(fā)覺(jué)的問(wèn)題的分析、追蹤和回來(lái)測(cè)試。軟件測(cè)試是保證軟件質(zhì)量的一個(gè)重要環(huán)節(jié)。 6、軟件測(cè)試目的 測(cè)試目的三個(gè)觀點(diǎn)： 測(cè)試是程序的執(zhí)行過(guò)程，目的在于發(fā)覺(jué)錯(cuò)誤； 一個(gè)好的測(cè)試用例在于能發(fā)覺(jué)至今未發(fā)覺(jué)的錯(cuò)誤； 一個(gè)勝利的測(cè)試是發(fā)覺(jué)了至今未發(fā)覺(jué)的錯(cuò)誤的測(cè)試； 測(cè)試的目的，是想以最少的人力、物力和時(shí)間找出軟件潛在的各種錯(cuò)誤和缺陷，通過(guò)修正各種錯(cuò)誤和缺陷 提高軟件質(zhì)量，回避軟件發(fā)布后由于潛在的軟件缺陷和錯(cuò)誤造居的隱患所帶來(lái)的商業(yè)風(fēng)險(xiǎn)。 測(cè)試是對(duì)軟件質(zhì)量

4、的度量與評(píng)價(jià)，以驗(yàn)證軟件的質(zhì)量滿意用戶的需求的程度，為用戶選擇與接受軟件供應(yīng)有力的依據(jù)。 7、軟件測(cè)試原則 全部的軟件測(cè)試都應(yīng)追溯到用戶需求。 應(yīng)當(dāng)把“盡早地和不斷地進(jìn)行軟件測(cè)試”作為軟件測(cè)試者的座左銘。 完全測(cè)試是不行能的，測(cè)試須要終止。 ??? 在有限的時(shí)間和資源條件下，軟件趨于完備，是不行能的。主要有三個(gè)緣由： ??? 軟件入量太大； ??? 輸出結(jié)果太多； ??? 路徑組合太多。 測(cè)試無(wú)法顯示軟件潛在的缺陷 充分留意測(cè)試中的群集現(xiàn)象。 程序員應(yīng)避開(kāi)檢查自己的程序。 盡量避開(kāi)測(cè)試的隨意性。（應(yīng)當(dāng)從工程的角度去理解軟件測(cè)試，它是有組織、有支配、步驟的活動(dòng)。）

5、 8、軟件測(cè)試對(duì)象 依據(jù)軟件定義，軟件包括程序、數(shù)據(jù)和文檔，所以軟件測(cè)試并不僅僅是程序測(cè)試。 在軟件編碼結(jié)束后，對(duì)編寫的每一個(gè)程序模塊進(jìn)行測(cè)試，稱為模塊測(cè)試或單元測(cè)試。 在模塊集成后，對(duì)集成在一起模塊組件，有時(shí)稱為部件，進(jìn)行測(cè)試，稱為集成測(cè)試。 在集成測(cè)試后，須要檢測(cè)與證明軟件是否滿意軟件需求說(shuō)明書(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）是保證軟件正的確現(xiàn)

6、特定功能的一系列活動(dòng)和過(guò)程，目的是保證軟件生命周期中的每一個(gè)階段的成果滿意上一個(gè)階段所設(shè)定的目標(biāo)。 確認(rèn)（validation）是保證軟件滿意用戶需求的一系列的活動(dòng)和過(guò)程，目的是在軟件開(kāi)發(fā)完成后保證軟件與用戶需求相符合。 驗(yàn)證與確認(rèn)都屬于軟件測(cè)試，它包括對(duì)軟件分析、設(shè)計(jì)以及程序的驗(yàn)證和確認(rèn)。 需求分析、概要設(shè)計(jì)、具體設(shè)計(jì)以及程序編碼等各階段所得到的文檔，包括需求規(guī)格說(shuō)明、概要設(shè)計(jì)規(guī)格說(shuō)明、具體設(shè)計(jì)規(guī)格說(shuō)明以及源程序，都應(yīng)成為“軟件測(cè)試”的對(duì)象。在軟件編碼結(jié)束后，對(duì)編寫的每一個(gè)程序模塊進(jìn)行測(cè)試，稱為“模塊測(cè)試”或“單元測(cè)試”；在模塊集成后，對(duì)集成在一起的模塊組件，有時(shí)也可稱為“部件”，進(jìn)行

7、測(cè)試，稱為“集成測(cè)試”；在集成測(cè)試后，須要檢測(cè)與證明軟件是否滿意軟件需求說(shuō)明書(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è)試過(guò)程按4個(gè)步驟進(jìn)行，即單元測(cè)試、集成（組裝）測(cè)試、確認(rèn)測(cè)試和系統(tǒng)測(cè)試。 9、軟件測(cè)試分類 依據(jù)開(kāi)發(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è)程序單元能否正的確現(xiàn)具體設(shè)計(jì)說(shuō)明中的模塊功能、性能、接口和設(shè)計(jì)約

8、束等要求，發(fā)覺(jué)各模塊內(nèi)部可能存在的各種錯(cuò)誤。單元測(cè)試須要從程序的內(nèi)部結(jié)構(gòu)動(dòng)身設(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è)試：就是通過(guò)檢驗(yàn)和供應(yīng)客觀證據(jù)，證明軟件是否滿意特定預(yù)期用途的要求。確認(rèn)測(cè)試是檢測(cè)與證明軟件是否滿意軟件需求說(shuō)明書(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)能否（包

9、括硬件、外設(shè)、網(wǎng)絡(luò)和系統(tǒng)軟件、支持平臺(tái)等）正確配置、連接，并滿意用戶需求。 驗(yàn)收測(cè)試：依據(jù)項(xiàng)目任務(wù)書(shū)或合同、供需雙方約定的驗(yàn)收依據(jù)文檔進(jìn)行的對(duì)整個(gè)系統(tǒng)的測(cè)試與評(píng)審，確定是否接收或拒收系統(tǒng)。 l 依據(jù)開(kāi)發(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è)試是通過(guò)檢驗(yàn)和供應(yīng)客觀證據(jù)，證明軟件是否滿意特定預(yù)

10、期用途的需求。確認(rèn)測(cè)試是檢測(cè)與證明軟件是否滿意軟件需求說(shuō)明書(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è)試 依據(jù)項(xiàng)目任務(wù)書(shū)或合同、供需雙方約定的驗(yàn)收依據(jù)文檔進(jìn)行的對(duì)整個(gè)系統(tǒng)的測(cè)試與評(píng)審，確定是否接收或拒收系統(tǒng)。 l 依據(jù)測(cè)試實(shí)施組織劃分 依據(jù)測(cè)試實(shí)施組織劃分，軟件測(cè)試可分為開(kāi)發(fā)方測(cè)試、用戶測(cè)試（Beta測(cè)試）、第三方測(cè)試。 （1）開(kāi)發(fā)方測(cè)試 通常也叫“驗(yàn)證

11、測(cè)試”或“α測(cè)試”。驗(yàn)證測(cè)試是在軟件開(kāi)發(fā)環(huán)境下，由開(kāi)發(fā)者檢測(cè)與證明軟件的實(shí)現(xiàn)是否滿意軟件設(shè)計(jì)說(shuō)明或軟件需求說(shuō)明的要求。主要是指在軟件開(kāi)發(fā)完成以后，開(kāi)發(fā)方對(duì)要提交的軟件進(jìn)行全面的自我檢查與驗(yàn)證，可以和軟件的“系統(tǒng)測(cè)試”一并進(jìn)行。 （2）用戶測(cè)試 在用戶的應(yīng)用環(huán)境下，用戶通過(guò)運(yùn)行和運(yùn)用軟件，檢測(cè)與核實(shí)軟件實(shí)現(xiàn)是否符合自己預(yù)期的要求。用戶測(cè)試不是指用戶的“驗(yàn)收測(cè)試”，而是指用戶的運(yùn)用性測(cè)試，由用戶找出軟件的應(yīng)用過(guò)程中發(fā)覺(jué)的軟件的缺陷與問(wèn)題，并對(duì)運(yùn)用質(zhì)量進(jìn)行評(píng)價(jià)。 （3）第三方測(cè)試 介于軟件開(kāi)發(fā)方和用戶方之間的測(cè)試組織的測(cè)試。一般狀況下是在模擬用戶真實(shí)應(yīng)用環(huán)境下，進(jìn)行軟件確認(rèn)測(cè)試。 l 依據(jù)

12、測(cè)試技術(shù)劃分 依據(jù)測(cè)試技術(shù)劃分：白盒測(cè)試、黑盒測(cè)試、灰盒測(cè)試。也可劃分為靜態(tài)測(cè)試和動(dòng)態(tài)測(cè)試。靜態(tài)測(cè)試是指不運(yùn)行程序，通過(guò)人工對(duì)程序和文檔進(jìn)行分析與檢查：靜態(tài)測(cè)試技術(shù)又稱靜態(tài)分析技術(shù)，靜態(tài)測(cè)試事實(shí)上是對(duì)軟件中的需求說(shuō)明書(shū)、設(shè)計(jì)說(shuō)明書(shū)、程序源代碼等進(jìn)行非運(yùn)行的檢查，靜態(tài)測(cè)試包括：走查、符號(hào)執(zhí)行、需求確認(rèn)等。動(dòng)態(tài)測(cè)試是指通過(guò)人工或運(yùn)用工具運(yùn)行程序進(jìn)行檢查、分析程序的執(zhí)行狀態(tài)和程序的外部表現(xiàn)。 （1）白盒測(cè)試 通過(guò)對(duì)程序內(nèi)部結(jié)構(gòu)的分析、檢測(cè)來(lái)找尋問(wèn)題。了解程序結(jié)構(gòu)和處理過(guò)程，檢查是否全部的結(jié)構(gòu)及路徑都是正確的，檢查軟件內(nèi)部動(dòng)作是否依據(jù)設(shè)計(jì)說(shuō)明的規(guī)定正常進(jìn)行。 （2）黑盒測(cè)試 通過(guò)軟件

13、的外部表現(xiàn)來(lái)發(fā)覺(jué)其缺陷和錯(cuò)誤。黑盒測(cè)試法把測(cè)試對(duì)象看成一個(gè)黑盒子，完全不考慮程序內(nèi)部結(jié)構(gòu)和處理過(guò)程。黑盒測(cè)試是在程序界面處進(jìn)行測(cè)試，它只是檢查程序是否依據(jù)需求規(guī)格說(shuō)明書(shū)的規(guī)定正常實(shí)現(xiàn)。 （3）灰盒測(cè)試 灰盒測(cè)試關(guān)注輸出對(duì)于輸入的正確性 ? 靜態(tài)測(cè)試 它是指不運(yùn)行程序，通過(guò)人工對(duì)程序和文檔進(jìn)行分析與檢查； 靜態(tài)測(cè)試技術(shù)又稱靜態(tài)分析技術(shù)，靜態(tài)測(cè)試事實(shí)上是對(duì)軟件中的需求說(shuō)明書(shū)、設(shè)計(jì)說(shuō)明書(shū)、程序源代碼等進(jìn)行非運(yùn)行檢查， 靜態(tài)測(cè)試包括：走查、符號(hào)執(zhí)行、需求確認(rèn)等。 ? 動(dòng)態(tài)測(cè)試 它是指通過(guò)人工或運(yùn)用工具運(yùn)行程序進(jìn)行檢查、分析程序的執(zhí)行狀態(tài)和程序的外部表現(xiàn)。 ? 白盒測(cè)試 又稱結(jié)構(gòu)測(cè)試。

14、通過(guò)對(duì)程序內(nèi)部結(jié)構(gòu)的分析、檢測(cè)來(lái)找尋問(wèn)題。 ? 黑盒測(cè)試 通過(guò)軟件的外部表現(xiàn)來(lái)發(fā)覺(jué)其缺陷和錯(cuò)誤。它是在程序界面處進(jìn)行測(cè)試，它只是檢查樣序是否依據(jù)需求規(guī)格說(shuō)明書(shū)的規(guī)定正常實(shí)現(xiàn)。 10、軟件測(cè)試過(guò)程模型 ? V模型 它反映了測(cè)試活動(dòng)與分析和設(shè)計(jì)的關(guān)系，從左到右，描述了基本的開(kāi)發(fā)過(guò)程和測(cè)試行為，特別明確地標(biāo)明白測(cè)試過(guò)程中存在的不同級(jí)別，并且清晰地描述了這些測(cè)試階段和開(kāi)發(fā)過(guò)程期間各階段的對(duì)應(yīng)關(guān)系，如圖所示，圖中的箭頭代表了時(shí)間方向，左邊下降的是開(kāi)發(fā)過(guò)程各階段，與此相對(duì)應(yīng)的是右邊上升的部分，即各測(cè)試過(guò)程的各個(gè)階段。 V模型指出，單元和集成測(cè)試是驗(yàn)證的程序設(shè)計(jì)，檢測(cè)程序的執(zhí)行是否滿

15、意軟件設(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è)試，追溯軟件需求說(shuō)明書(shū)進(jìn)行測(cè)試，以確定軟件的實(shí)現(xiàn)是否滿意用戶需求或合同的要求。 V模型存在肯定的局限性，它僅僅是測(cè)試過(guò)程作為在需求分析、概要設(shè)計(jì)、具體設(shè)計(jì)及編碼后的一個(gè)階段。需求分析階段隱藏的問(wèn)題始終到后期的驗(yàn)收測(cè)試才被發(fā)覺(jué)。 V模型的軟件測(cè)試策略既包括低層測(cè)試又包括了高層測(cè)試，低層測(cè)試是為了源代碼的正確性，高層測(cè)試為了使整個(gè)系統(tǒng)滿意用戶的需求。 ? W模型 1、W模型建立 V模型的局限性在于沒(méi)有明確地說(shuō)明早期的測(cè)試，不能體現(xiàn)“盡早地和不

16、斷地進(jìn)行軟件測(cè)試”的原則。在V模型中增加軟件各開(kāi)發(fā)階段應(yīng)同步進(jìn)行的測(cè)試，被演化為一種W模型，因?yàn)槭聦?shí)上開(kāi)發(fā)是“V”，測(cè)試也是與此相并行的“V”。基于“盡早地和不斷地進(jìn)行軟件測(cè)試”的原則， 優(yōu)點(diǎn)： 測(cè)試伴隨著整個(gè)軟件開(kāi)發(fā)周期，而且測(cè)試的對(duì)象不僅僅是程序，需求、功能和設(shè)計(jì)同樣要測(cè)試。 體現(xiàn)“盡早地和不斷地進(jìn)行軟件測(cè)試”的原則。 在V模型中增加軟件和開(kāi)發(fā)階段應(yīng)同步進(jìn)行的測(cè)試。 局限性： 軟件開(kāi)發(fā)和測(cè)試保持一種線性的前后關(guān)系，須要有嚴(yán)格的指令表示上一階段完全結(jié)束，才可正式起先下一個(gè)階段。這就無(wú)法支持迭代、自發(fā)性以及變更調(diào)整。 2、W模型應(yīng)用 它強(qiáng)調(diào)：測(cè)試伴隨著整個(gè)軟件開(kāi)發(fā)周期，而且

17、測(cè)試的對(duì)象不僅僅是程序，需求、功能和設(shè)計(jì)同樣要測(cè)試。只要相應(yīng)的開(kāi)發(fā)活動(dòng)完成，我們就可以起先執(zhí)行測(cè)試，可以說(shuō)，測(cè)試與開(kāi)發(fā)是同步進(jìn)行的，有利于盡早地發(fā)覺(jué)問(wèn)題。以需求為例，需求分析一完成，我們就可以對(duì)需求進(jìn)行測(cè)試，而不是等到最終才進(jìn)行針對(duì)需求的驗(yàn)收測(cè)試。 參加前期工作的測(cè)試者可以預(yù)先估計(jì)問(wèn)題和難度，這將可以顯著地削減總體測(cè)試時(shí)間，加快項(xiàng)目進(jìn)度。 依據(jù)W模型的要求，一旦有文檔供應(yīng)，就要?jiǎng)偤么_定測(cè)試條件，以及編寫測(cè)試用例。 W模型也是有局限性。W模型和V模型都把軟件的開(kāi)發(fā)視為需求、設(shè)計(jì)、編碼等一系列串行的活動(dòng)。同樣的，軟件開(kāi)發(fā)和測(cè)試保持一種線性的前后關(guān)系，須要有嚴(yán)格的指令表示上一階段完全結(jié)束，才可

18、正式起先下一個(gè)階段。這樣就無(wú)法支持迭代、自發(fā)性以及變更調(diào)整。 ? H模型 1、H模型建立 它將測(cè)試活動(dòng)獨(dú)立出來(lái)，形成一個(gè)完全獨(dú)立的流程，將測(cè)試打算活動(dòng)和測(cè)試執(zhí)行活動(dòng)清晰地體現(xiàn)出來(lái)。 2、H模型應(yīng)用 軟件測(cè)試不僅僅指測(cè)試的執(zhí)行，還包括很多其他的活動(dòng)。 軟件測(cè)試是一個(gè)獨(dú)立的流程，貫穿產(chǎn)品整個(gè)生命周期，與其他流程并發(fā)地進(jìn)行。 軟件測(cè)試要盡早打算，盡早執(zhí)行。 軟件測(cè)試是依據(jù)被測(cè)物的不同而分層次進(jìn)行的。不同層次的測(cè)試活動(dòng)可以是依據(jù)某個(gè)次序先后進(jìn)行的，但也可能是反復(fù)的。 在H模型中，軟件測(cè)試模型是一個(gè)獨(dú)立的流程，貫穿于整個(gè)產(chǎn)品周期，與其他流程并發(fā)地進(jìn)行。 ? 其他模型 1、 X模

19、型 該模型定位了探究性測(cè)試。 Marick對(duì)V模型最主要指責(zé)是V模型無(wú)法引導(dǎo)項(xiàng)目全部過(guò)程。他認(rèn)為一個(gè)模型必需能處理開(kāi)發(fā)的全部方面，包括交接、頻繁重復(fù)的集成以及需求文檔的缺乏等。 2、前置測(cè)試模型 它是一個(gè)將測(cè)試和開(kāi)發(fā)緊密結(jié)合的模型，該模型供應(yīng)了輕松的方式，可使你的項(xiàng)目加快速度。 前置測(cè)試模型體現(xiàn)了以下的要點(diǎn)： （1）開(kāi)發(fā)和測(cè)試相結(jié)合；前置測(cè)試模型將開(kāi)發(fā)和測(cè)試的生命周期整合在一起，標(biāo)識(shí)了項(xiàng)目生命周期從起先到結(jié)束之間的關(guān)鍵行為。 （2）對(duì)每一個(gè)交付內(nèi)容進(jìn)行測(cè)試；每一個(gè)交付的開(kāi)發(fā)結(jié)果都必需通過(guò)肯定的方式進(jìn)行測(cè)試。 （3）在設(shè)計(jì)階段進(jìn)行測(cè)試支配和測(cè)試設(shè)計(jì)；設(shè)計(jì)階段是作測(cè)試支

20、配和測(cè)試設(shè)計(jì)的最好時(shí)機(jī)。 （4）測(cè)試和開(kāi)發(fā)結(jié)合在一起；前置測(cè)試將測(cè)試執(zhí)行和開(kāi)發(fā)結(jié)合在一起，并在開(kāi)發(fā)階段以編碼——測(cè)試——編碼——測(cè)試的方式來(lái)體現(xiàn)。 （5）讓驗(yàn)收測(cè)試和技術(shù)測(cè)試保持相互獨(dú)立。驗(yàn)收測(cè)試應(yīng)當(dāng)獨(dú)立于技術(shù)測(cè)試，這樣可以供應(yīng)雙重的保險(xiǎn)，以保證設(shè)計(jì)及程序編碼能夠符合最終用戶的需求。 10、軟件生命周期測(cè)試策略 ? 軟件開(kāi)發(fā)與軟件測(cè)試 軟件開(kāi)發(fā)的過(guò)程是一個(gè)自頂向下，逐步細(xì)化的過(guò)程。 測(cè)試過(guò)程則是依照相反的依次支配自底向上，逐步集成的過(guò)程。 ? 軟件測(cè)試策略 測(cè)試過(guò)程按4個(gè)步驟進(jìn)行，即單元測(cè)試、集成（組裝）測(cè)試、確認(rèn)測(cè)試和系統(tǒng)測(cè)試。 1、測(cè)試信息流 測(cè)試過(guò)

21、程須要以下三類輸入： 軟件配置：包括軟件需求規(guī)格說(shuō)明、軟件設(shè)計(jì)規(guī)格說(shuō)明、源代碼等。 測(cè)試配置：包括測(cè)試支配、測(cè)試用例、測(cè)試驅(qū)動(dòng)程序等。測(cè)試配置只是軟件配置的一個(gè)子集。 測(cè)試工具： 2、分析設(shè)計(jì)階段 分析設(shè)計(jì)階段的測(cè)試工作是評(píng)審與測(cè)試相結(jié)合的過(guò)程，主要包括需求說(shuō)明書(shū)評(píng)測(cè)、概要設(shè)計(jì)說(shuō)明書(shū)、具體設(shè)計(jì)說(shuō)明書(shū)評(píng)測(cè)以及軟件編碼規(guī)范評(píng)測(cè)等。 編制良好的需求說(shuō)明書(shū)8條原則： 功能與實(shí)現(xiàn)分別； 要求運(yùn)用面對(duì)處理的規(guī)格說(shuō)明語(yǔ)言； 描述該目標(biāo)軟件與系統(tǒng)的其他系統(tǒng)元素交互的方式； 規(guī)格說(shuō)明必需包括系統(tǒng)運(yùn)行的環(huán)境； 系統(tǒng)規(guī)格說(shuō)明必需是一個(gè)相識(shí)的模型； 規(guī)格說(shuō)明必需是可操作的； 規(guī)格說(shuō)明必需容許

22、不完備性并允許擴(kuò)充； 規(guī)格說(shuō)明必需局部化和松散的耦合。 （1）需求說(shuō)明書(shū)評(píng)測(cè) 需求說(shuō)明書(shū)是分析任務(wù)的最終產(chǎn)物，通過(guò)建立完整的信息描述、具體的功能和行為描述、性能需求和設(shè)計(jì)約束的說(shuō)明、性能需求和設(shè)計(jì)約束的說(shuō)明、合適的驗(yàn)收標(biāo)準(zhǔn)，給出對(duì)目標(biāo)軟件的各種需求。 需求說(shuō)明書(shū)評(píng)測(cè)內(nèi)容： 系統(tǒng)定義的目標(biāo)是否與用戶的要求一樣。 系統(tǒng)需求分析階段供應(yīng)的文檔資料是否齊全。 文檔中的全部描述是否完整、清晰、精確地反映用戶要求； 與全部其他系統(tǒng)成份的重要接口是否都已經(jīng)描述； 被開(kāi)發(fā)項(xiàng)目的數(shù)據(jù)流與數(shù)據(jù)結(jié)構(gòu)是否足夠、確定； 全部圖表是否清晰，在不補(bǔ)充說(shuō)明時(shí)能否理解； 主要功能是否已包括在規(guī)定的

23、軟件范圍之內(nèi)，是否都已充分說(shuō)明； 軟件的行為和它必需處理的信息、必需完成的功能是否一樣； 設(shè)計(jì)的約束條件或限制條件是否符合實(shí)際； 是否考慮了開(kāi)發(fā)的技術(shù)風(fēng)險(xiǎn)； 是否考慮過(guò)軟件需求的其他方案； 是否考慮過(guò)將來(lái)可能會(huì)提出的軟件需求； 是否具體制定了檢驗(yàn)標(biāo)準(zhǔn)，它們能否對(duì)系統(tǒng)定義是否勝利進(jìn)行確認(rèn)； 有沒(méi)有遺漏、重復(fù)或不一樣的地方； 用戶是否審查了初步的用戶手冊(cè)或原型； 項(xiàng)目開(kāi)發(fā)支配中的估算是否受到了影響。 （1）需求說(shuō)明書(shū)評(píng)測(cè) 編制良好的需求說(shuō)明書(shū)8條原則。 原則1：功能與實(shí)現(xiàn)分別，即

24、描述要“做什么”而不是“怎樣實(shí)現(xiàn)”。 原則2：要求運(yùn)用面對(duì)處理的規(guī)格說(shuō)明語(yǔ)言，探討來(lái)自環(huán)境的各種刺激可能導(dǎo)致系統(tǒng)做出什么樣的功能性反應(yīng)，來(lái)定義一個(gè)行為模型，從而得到“做什么”的規(guī)格說(shuō)明。 原則3：假如目標(biāo)軟件只是一個(gè)大系統(tǒng)中的一個(gè)元素，那么整個(gè)系統(tǒng)也包括在規(guī)格說(shuō)明的描述之中。 原則4：規(guī)格說(shuō)明必需包括系統(tǒng)運(yùn)行的環(huán)境。 原則5：系統(tǒng)規(guī)格說(shuō)明必需是一個(gè)相識(shí)的模型，而不是設(shè)計(jì)或?qū)崿F(xiàn)的模型。 原則6：規(guī)格說(shuō)明必需是可操作的。 原則7：規(guī)格說(shuō)明必需容許不完備性并允許擴(kuò)充。 原則8：規(guī)格說(shuō)明必需局部化和松散的耦合。 需求說(shuō)明書(shū)的框架。 需求說(shuō)明書(shū)是分析任務(wù)的最終產(chǎn)物，通過(guò)建立完整的信

25、息描述、具體的功能和行為描述、性能需求和設(shè)計(jì)約束的說(shuō)明、合適的驗(yàn)收標(biāo)準(zhǔn)，給出對(duì)目標(biāo)軟件的各種需求。 需求說(shuō)明書(shū)評(píng)測(cè)內(nèi)容。 需求說(shuō)明書(shū)評(píng)測(cè)作為需求分析階段工作的復(fù)查手段，應(yīng)當(dāng)對(duì)功能的正確性、完整性和清晰性，以及其他需求賜予評(píng)測(cè)。評(píng)測(cè)的主要內(nèi)容是： （1）系統(tǒng)定義的目標(biāo)是否與用戶的要求一樣； （2）系統(tǒng)需求分析階段供應(yīng)的文檔資料是否齊全； （3）文檔中的全部描述是否完整、清晰，精確地反映用戶要求； （4）與全部其他系統(tǒng)成份的重要接口是否都已經(jīng)描述； （5）被開(kāi)發(fā)項(xiàng)目的數(shù)據(jù)流與數(shù)據(jù)結(jié)構(gòu)是否足夠、確定； （6）全部圖表是否清晰，在不補(bǔ)充說(shuō)明時(shí)能否理解； （7）主要功能是否已包括在規(guī)定

26、的軟件范圍之內(nèi)，是否都已充分說(shuō)明； （8）軟件的行為和它必需處理的信息、必需完成的功能是否一樣； （9）設(shè)計(jì)的約束條件或限制條件是否符合實(shí)際； （10）是否考慮了開(kāi)發(fā)的技術(shù)風(fēng)險(xiǎn)； （11）是否考慮過(guò)軟件需求的其他方案； （12）是否考慮過(guò)將來(lái)可能會(huì)提出的軟件需求； （13）是否具體制定了檢驗(yàn)標(biāo)準(zhǔn)，它們能否對(duì)系統(tǒng)定義是否勝利進(jìn)行確認(rèn)； （14）有沒(méi)有遺漏、重復(fù)或不一樣的地方； （15）用戶是否審查了初步的用戶手冊(cè)或原型； （16）項(xiàng)目開(kāi)發(fā)支配中的估算是否受到了影響。 （2）概要設(shè)計(jì)說(shuō)明書(shū)評(píng)測(cè) 設(shè)計(jì)說(shuō)明書(shū)的框架 設(shè)計(jì)說(shuō)明書(shū)的框架內(nèi)容： （1）可追溯性

27、 （2）接口 （3）風(fēng)險(xiǎn) （4）好用性 （5）技術(shù)清晰度 （6）可維護(hù)性 （7）質(zhì)量 （8）各種選擇方案 （9）限制 （10）其他具體問(wèn)題 為評(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ù)清晰度；可維護(hù)性；質(zhì)量；各種選擇方案；限制；其他具體問(wèn)題。 （1）設(shè)計(jì)出來(lái)的結(jié)構(gòu)應(yīng)是分層結(jié)構(gòu)，從而建立軟件成分之間的限制； （2）設(shè)計(jì)出來(lái)的結(jié)構(gòu)應(yīng)是分層結(jié)構(gòu)，從而建立軟件成分之間的限制； （3）設(shè)計(jì)應(yīng)當(dāng)既包含數(shù)據(jù)抽象，也包含過(guò)程抽象； （4）設(shè)計(jì)應(yīng)當(dāng)建立具有獨(dú)立功能特征的模塊； （5）設(shè)計(jì)應(yīng)當(dāng)建立能夠降低模塊與外

28、部環(huán)境之間困難連接的接口； （6）設(shè)計(jì)應(yīng)當(dāng)依據(jù)軟件需求分析獲得的信息，建立可驅(qū)動(dòng)、可重復(fù)的方法。 （3）具體設(shè)計(jì)說(shuō)明書(shū)評(píng)測(cè) 與概要設(shè)計(jì)說(shuō)明書(shū)基本相同。 （4）軟件編碼規(guī)范評(píng)測(cè) 程序事實(shí)上也是一種供人閱讀的文章，有一個(gè)文章的風(fēng)格問(wèn)題。程序良好的風(fēng)格表現(xiàn)在源程序文檔化、數(shù)據(jù)說(shuō)明的方法、語(yǔ)句結(jié)構(gòu)的輸入/輸出方法這四個(gè)方面，軟件編碼規(guī)范評(píng)測(cè)也是圍繞這四個(gè)方面綻開(kāi)。 源程序文檔化 （1）符號(hào)名的命名。符號(hào)名即標(biāo)識(shí)符，包括模塊名、變量名、常量名、標(biāo)號(hào)名、子程序名、數(shù)據(jù)區(qū)名以及緩沖區(qū)名等。 （2）程序的注釋。注釋分為序言性注釋和功能性注釋。 （3）標(biāo)準(zhǔn)的書(shū)寫格式。 數(shù)據(jù)說(shuō)明 （1）

29、數(shù)據(jù)說(shuō)明的次序應(yīng)當(dāng)規(guī)范化。 （2）說(shuō)明語(yǔ)句中變量支配有序化。 （3）運(yùn)用注釋說(shuō)明困難數(shù)據(jù)結(jié)構(gòu)。 語(yǔ)句結(jié)構(gòu) 在設(shè)計(jì)階段確定了軟件的邏輯流結(jié)構(gòu)，但構(gòu)造單個(gè)語(yǔ)句則是編碼階段的任務(wù)。語(yǔ)句構(gòu)造力求簡(jiǎn)潔、干脆，不能為了片面追求效率而使語(yǔ)句困難化。 輸入和輸出 輸入和輸出信息是與用戶的運(yùn)用干脆相關(guān)的。輸入和輸出的方式和格式應(yīng)當(dāng)盡可能便利用戶的運(yùn)用?？隙ㄒ荛_(kāi)因設(shè)計(jì)不當(dāng)給用戶帶來(lái)的麻煩。因此，在軟件需求分析階段和設(shè)計(jì)階段，就應(yīng)基本確定輸入和輸出的風(fēng)格。系統(tǒng)能否被用戶接受，有時(shí)就取決于輸入和輸出的風(fēng)格。不論是批處理的輸入/輸出方式，還是交互式的輸入/輸出方式，在設(shè)計(jì)和程序編碼時(shí)都應(yīng)考慮下列原則。

30、 輸入和輸出 在設(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)允許運(yùn)用自由格式輸入； （5）應(yīng)允許缺省值； （6）輸入一批數(shù)據(jù)時(shí)，最好運(yùn)用輸入結(jié)束標(biāo)記，而不要由用戶指定輸入數(shù)據(jù)數(shù)目； （7）在交互式輸入時(shí)，要在屏幕上運(yùn)用提示符，明確提示交互輸入的懇求，指明可運(yùn)用選擇項(xiàng)的種類和取值范圍。同時(shí)，在數(shù)據(jù)輸入的過(guò)程中和輸入結(jié)束時(shí)，也要在屏幕上給出狀態(tài)信息； （8）當(dāng)程序設(shè)

31、計(jì)語(yǔ)言對(duì)輸入/輸出格有嚴(yán)格要求時(shí)，應(yīng)保持輸入格式與輸入語(yǔ)句要求的一樣性； （9）給全部的輸出加注解，并設(shè)計(jì)輸出報(bào)表格式。 3、開(kāi)發(fā)階段 （1）單元測(cè)試 單元測(cè)試的內(nèi)容： 在進(jìn)行單元測(cè)試時(shí)，測(cè)試者須要依據(jù)具體設(shè)計(jì)說(shuō)明書(shū)和源程序清單，了解該模塊的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è)試

32、者須要依據(jù)具體設(shè)計(jì)說(shuō)明書(shū)和源程序清單，了解該模塊的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ì)通過(guò)所測(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ù)與子模塊中

33、的形式參數(shù)在個(gè)數(shù)、屬性、依次上是否匹配； 是否修改了只作輸入用的形式參數(shù)； 輸出給標(biāo)準(zhǔn)函數(shù)的參數(shù)在個(gè)數(shù)、屬性、依次上是否正確； 全局量的定義在各模塊中是否一樣； 限制是否通過(guò)形式參數(shù)來(lái)傳送。 2）局部數(shù)據(jù)結(jié)構(gòu)測(cè)試 設(shè)計(jì)測(cè)試用例以檢查以下各種錯(cuò)誤： 不正確或不一樣的數(shù)據(jù)類型說(shuō)明； 運(yùn)用尚未賦值或尚未初始化的變量； 錯(cuò)誤的初始值或錯(cuò)誤的缺省值； 變量名拼法錯(cuò)或書(shū)寫錯(cuò)； 不一樣的數(shù)據(jù)類型。 3）路徑測(cè)試 常見(jiàn)的不正確計(jì)算有：運(yùn)算的優(yōu)先次序不正確或誤會(huì)了運(yùn)算的優(yōu)先次序； 運(yùn)算的方式錯(cuò)，即運(yùn)算的對(duì)象彼此在類型上不相容；

34、 算法錯(cuò)； 初始化不正確； 運(yùn)算精度不夠； 表達(dá)式的符號(hào)表示不正確。 4）錯(cuò)誤處理測(cè)試 比較完善的模塊設(shè)計(jì)要求能預(yù)見(jiàn)出錯(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ù)等。

35、 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)來(lái)，但不允許什么事情也不做。 （2）集成測(cè)試 集成測(cè)試也叫做組裝測(cè)試或聯(lián)合測(cè)試。在單元測(cè)試的基礎(chǔ)上，須要將全部模塊依據(jù)概要設(shè)計(jì)說(shuō)明書(shū)和具體設(shè)計(jì)說(shuō)明書(shū)的要求進(jìn)行組裝。 組成時(shí)須要考慮的問(wèn)題： 1）在把各個(gè)模塊連接起的時(shí)候，穿越模塊接口的數(shù)據(jù)是否會(huì)丟失； 2）一個(gè)模塊的功能是否會(huì)對(duì)另一個(gè)模塊的功能產(chǎn)生不利的影響；

36、 3）各個(gè)子功能組合起來(lái)，能否達(dá)到預(yù)期要求的父功能； 4）全局?jǐn)?shù)據(jù)結(jié)構(gòu)是否有問(wèn)題； 5）單個(gè)模塊的誤差累積起來(lái)，是否會(huì)放大，以至達(dá)到不能接受的程度。 子系統(tǒng)的集成測(cè)試稱為部件測(cè)試，它所做的工作是要找出組裝后的子系統(tǒng)與系統(tǒng)需求規(guī)格說(shuō)明之間的不一樣。 模塊組裝成為系統(tǒng)的方式。 模塊組裝成為系統(tǒng)的方式有兩種：一次性組裝方式和增殖式組裝方式。 1）一次性組裝方式 它是一種非增殖式組裝方式，也叫做整體拼裝。運(yùn)用這種方式，首先對(duì)每個(gè)模塊分別進(jìn)行模塊測(cè)試，再把全部模塊組裝在一起進(jìn)行測(cè)試，最終得到要求的軟件系統(tǒng)。 2）增殖式組裝方式 這種組裝方式又稱漸增式組裝，是首先對(duì)一個(gè)個(gè)模塊進(jìn)行模塊測(cè)

37、試，然后將這些模塊逐步組裝成較大的系統(tǒng)，在組裝的過(guò)程中邊連接邊測(cè)試，以發(fā)覺(jué)連接過(guò)程中產(chǎn)生的問(wèn)題。最終通過(guò)增殖逐步組裝成為要求的軟件系統(tǒng)。 自頂向下的增殖方式。步驟如下：首先以主模塊作為所測(cè)模塊兼驅(qū)動(dòng)模塊，全部直屬于主模塊的下屬模塊全部用樁模塊代替，對(duì)主模塊進(jìn)行測(cè)試。再采納深度優(yōu)先或廣度優(yōu)先的策略，用實(shí)際模塊替換相應(yīng)的樁模塊，再用樁模塊代替它們的干脆下屬模塊，與已測(cè)試的模塊或子系統(tǒng)組裝成新的子系統(tǒng)。然后，進(jìn)行回來(lái)測(cè)試（即重新執(zhí)行以前做過(guò)的全部測(cè)試或部分測(cè)試），解除組裝過(guò)程中引新的錯(cuò)誤的可能。最終，推斷是否全部的模塊都已組裝到系統(tǒng)中。 自頂向下的增殖方式在測(cè)試過(guò)程中較早地驗(yàn)證了主要的限制和

38、推斷點(diǎn)。在一個(gè)功能劃分合理的程序模塊結(jié)構(gòu)中，推斷經(jīng)常出現(xiàn)在較高的層次里，因而，能夠較早地遇到這種問(wèn)題。 假如選用按深度方向組裝的方式，可以首先實(shí)現(xiàn)和驗(yàn)證一個(gè)完整的軟件功能，可先對(duì)邏輯輸入的分支進(jìn)行組裝和測(cè)試，檢查和克服潛藏的錯(cuò)誤和缺陷，驗(yàn)證其功能的正確性，就為其后對(duì)主要加工分支的組裝和測(cè)試供應(yīng)了保證。 自底向上的增殖方式。 提高測(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ā)生錯(cuò)誤； 有明確定義的性能要求。 在

39、做回來(lái)測(cè)試時(shí)，也應(yīng)當(dāng)集中測(cè)試關(guān)鍵模塊的功能。 集成測(cè)試的組織和實(shí)施。 集成測(cè)試是一種正規(guī)測(cè)試過(guò)程，必需細(xì)心支配，并與單元測(cè)試的完成時(shí)間協(xié)調(diào)起來(lái)。在制定測(cè)試支配時(shí)，應(yīng)考慮如下因素： （1）采納何種系統(tǒng)組裝方法來(lái)進(jìn)行集成測(cè)試。 （2）集成測(cè)試過(guò)程中連接各個(gè)模塊的依次。 （3）模塊代碼編制和測(cè)試進(jìn)度是否與集成測(cè)試的依次一樣。 （4）測(cè)試過(guò)程中是否須要特地的硬件設(shè)備。 集成測(cè)試完成的標(biāo)記。 集成測(cè)試完成的標(biāo)記主要有以下幾項(xiàng)。 （1）勝利地執(zhí)行了測(cè)試支配中規(guī)定的全部集成測(cè)試。 （2）修正了所發(fā)覺(jué)的錯(cuò)誤。 （3）測(cè)試結(jié)果通過(guò)了特地小組的評(píng)審。 集成測(cè)試須要提交的文檔有集成測(cè)試支配、

40、集成測(cè)試規(guī)格說(shuō)明書(shū)和集成測(cè)試分析報(bào)告。 （3）確認(rèn)測(cè)試 確認(rèn)測(cè)試的任務(wù)是驗(yàn)證軟件的功能和性能及其他特性是否與用戶的要求一樣。對(duì)軟件的功能和性能要求在軟件需求規(guī)格說(shuō)明中明確規(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ī)格說(shuō)明書(shū)列出的要求。 在全部軟件測(cè)試的測(cè)試用例運(yùn)行完后，全部的測(cè)試結(jié)果可以分為兩類。 （1）測(cè)試結(jié)果與預(yù)期的結(jié)果相符。這說(shuō)明軟件的部分功能或性能特征與需求規(guī)格說(shuō)明書(shū)相符合，從而接受了這部分程序。 （2）測(cè)試結(jié)果與預(yù)期的結(jié)果不符。這說(shuō)明

41、軟件的這部分功能或性能特征與需求規(guī)格說(shuō)明不一樣，因此要為它提交一份問(wèn)題報(bào)告。 軟件配置復(fù)查。 （4）系統(tǒng)測(cè)試 系統(tǒng)測(cè)試是將通過(guò)集成測(cè)試的軟件，作為整個(gè)基于計(jì)算機(jī)系統(tǒng)的一個(gè)元素，與計(jì)算機(jī)硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起，在實(shí)際或模擬運(yùn)行（運(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）過(guò)程 軟件的V&V過(guò)程是確定依據(jù)規(guī)定的軟件過(guò)程開(kāi)發(fā)的產(chǎn)品是否符合活動(dòng)的要求，軟件是否滿意它的預(yù)期用途和用戶須要。軟件的V&V過(guò)程包括軟件產(chǎn)品和過(guò)程的分析、評(píng)價(jià)、評(píng)審、審核、評(píng)估和測(cè)試。 軟件測(cè)試活動(dòng)是軟件V&V過(guò)程的一個(gè)組成部分

42、。軟件測(cè)試過(guò)程的任務(wù)與管理也要符合軟件V&V過(guò)程的有關(guān)規(guī)定。 （1）V&V基本概念 驗(yàn)證（Verfication）：通過(guò)檢查和供應(yīng)客觀證據(jù)，證明規(guī)定的需求已滿意。 確認(rèn)（Validation）：通過(guò)檢查和供應(yīng)客觀證據(jù)，證明預(yù)期用途的需求是否得到滿意。 獨(dú)立驗(yàn)證和確認(rèn)：由在技術(shù)、管理和財(cái)務(wù)上與開(kāi)發(fā)組織有規(guī)定程度獨(dú)立性的組織執(zhí)行的V&V過(guò)程。 （2）軟件V&V過(guò)程 軟件生存周期的V&V過(guò)程框架。 軟件開(kāi)發(fā)過(guò)程的V&V概述。 （3）軟件V&V過(guò)程中的測(cè)試 測(cè)試過(guò)程。 需求V&V活動(dòng)中的測(cè)試。 2.8軟件失效分類與管理 軟件失效分類 軟件錯(cuò)誤（software error）

43、 軟件缺陷（software defect） 軟件故障（software fault） 軟件失效（software failure） 軟件失效機(jī)理可描述為：軟件錯(cuò)誤è軟件缺陷è軟件故障è軟件失效 （1）軟件錯(cuò)誤是指在軟件生存期內(nèi)的不希望或不行接受的人為錯(cuò)誤，其結(jié)果是導(dǎo)致軟件缺陷的產(chǎn)生?？梢?jiàn)，軟件錯(cuò)誤是一種人為過(guò)程，相對(duì)于軟件本身，是一種外部行為。 （2）軟件缺陷存在于軟件（文檔、數(shù)據(jù)、程序）之中的那些不希望或不行接受的偏差。其結(jié)果是軟件運(yùn)行于某一特定條件時(shí)出現(xiàn)軟件故障，這時(shí)稱軟件缺陷激烈。 （3）軟件故障是指軟件運(yùn)行過(guò)程中出現(xiàn)的一種不希望或不行接受的內(nèi)部狀態(tài)。 （4）軟件失效是指

44、軟件運(yùn)行時(shí)產(chǎn)生的一種不希望或不行接受的外部行為結(jié)果。 錯(cuò)誤的廣義定義是：不正確的事務(wù)和行為。 錯(cuò)誤是在系統(tǒng)運(yùn)行時(shí)，引起或可能潛在地引起失效的缺陷，是一種面對(duì)開(kāi)發(fā)概念。 軟件缺陷： （1）軟件未達(dá)到產(chǎn)品說(shuō)明書(shū)中標(biāo)明的功能； （2）軟件出現(xiàn)了產(chǎn)品說(shuō)明書(shū)中指明的不會(huì)出現(xiàn)的錯(cuò)誤； （3）軟件功能超出了產(chǎn)品說(shuō)明書(shū)指明的范圍； （4）軟件未達(dá)到產(chǎn)品說(shuō)明書(shū)雖未指出應(yīng)達(dá)到的目標(biāo)； （5）軟件測(cè)試人員認(rèn)為軟件難以理解、不易運(yùn)用、運(yùn)行速度慢，或最終用戶認(rèn)為不好運(yùn)用。 產(chǎn)品說(shuō)明書(shū)是軟件缺陷的第一來(lái)源，也就出自于軟件需求說(shuō)明書(shū)本身的問(wèn)題。 設(shè)計(jì)方案（軟件設(shè)計(jì)說(shuō)明書(shū)）是軟件缺陷其次來(lái)源。 缺陷與

45、錯(cuò)誤分布 缺陷與錯(cuò)誤嚴(yán)峻性和優(yōu)先級(jí) 軟件存在的缺陷與錯(cuò)誤會(huì)帶來(lái)軟件失敗的風(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é)果、遺漏功能 一般：小問(wèn)題、錯(cuò)別字、UI布局、罕見(jiàn)故障 建議：不影響運(yùn)用的瑕疵或更好的實(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)當(dāng)修復(fù) 最低等優(yōu)先級(jí)：可能會(huì)修復(fù)

46、，但是也能發(fā)布 軟件錯(cuò)誤跟蹤管理 軟件測(cè)試的主要目的在于發(fā)覺(jué)軟件存在的錯(cuò)誤（Bug），如何處理測(cè)試中發(fā)覺(jué)的錯(cuò)誤，將干脆影響到測(cè)試的效果。只有正確、快速、精確地處理這些錯(cuò)誤，才能消退軟件錯(cuò)誤，保證要發(fā)布的軟件符合需求設(shè)計(jì)的目標(biāo)。 在實(shí)際的軟件測(cè)試過(guò)程中，每個(gè)BUG都要經(jīng)過(guò)測(cè)試、確認(rèn)、修復(fù)、驗(yàn)證等的管理過(guò)程，這是軟件測(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è)試事務(wù) 測(cè)試軟件和硬件配置環(huán)境 發(fā)覺(jué)軟件錯(cuò)誤的類型 錯(cuò)誤的嚴(yán)峻等級(jí) 具體步驟

47、 必要的附圖 測(cè)試注釋 （2）BUG處理信息 處理者姓名 處理時(shí)間 處理步驟 錯(cuò)誤記錄的當(dāng)前狀態(tài) 2、軟件錯(cuò)誤的狀態(tài) 新信息（New）：測(cè)試中新報(bào)告的軟件BUG 打開(kāi)（Open）：被確認(rèn)并安排給相關(guān)開(kāi)發(fā)人員處理。 修正（Fixed）：開(kāi)發(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è)試，它是通過(guò)測(cè)試來(lái)檢測(cè)每個(gè)功能是否都能

48、正常運(yùn)用。在完全不考慮內(nèi)部結(jié)構(gòu)和內(nèi)部特性的狀況下，在程序接口進(jìn)行測(cè)試，它只檢查程序功能是否依據(jù)需求說(shuō)明書(shū)的規(guī)定正常運(yùn)用，程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)據(jù)而產(chǎn)生正確的輸出信息。主要針對(duì)軟件界面和軟件功能進(jìn)行測(cè)試。 黑盒測(cè)試法留意于測(cè)試軟件的功能需求，主要試圖發(fā)覺(jué)下列幾類錯(cuò)誤。 功能不正確或遺漏 界面錯(cuò)誤 數(shù)據(jù)庫(kù)訪問(wèn)錯(cuò)誤 性能錯(cuò)誤 初始化和終止錯(cuò)誤 黑盒測(cè)試用例設(shè)計(jì)方法包括等價(jià)類劃分法、邊界值分析法、錯(cuò)誤推想法、因果圖法、判定表驅(qū)動(dòng)法、正交試驗(yàn)設(shè)計(jì)法、功能圖法等。 2.11自動(dòng)化測(cè)試 自動(dòng)化測(cè)試的基本概念 自動(dòng)化測(cè)試的定義：通過(guò)測(cè)試工具或其他手段，依據(jù)測(cè)試工程師的預(yù)定支配對(duì)軟件

49、產(chǎn)品進(jìn)行自動(dòng)的測(cè)試，它是軟件測(cè)試的一個(gè)重要的組成部分，它能夠完成很多手工無(wú)法完成或難以實(shí)現(xiàn)的一些測(cè)試。正確、合理地實(shí)施自動(dòng)化測(cè)試，能夠快速、全在財(cái)對(duì)軟件進(jìn)行測(cè)試，從而提高軟件質(zhì)量，節(jié)約經(jīng)費(fèi)，縮短產(chǎn)品發(fā)布周期。 自動(dòng)化測(cè)試的優(yōu)勢(shì)與局限 1、自動(dòng)化測(cè)試的優(yōu)勢(shì) 避開(kāi)重復(fù)測(cè)試，同時(shí)，還能完成大量手工無(wú)法完成的測(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)軟件缺陷的實(shí)力 更好地利用資源 增進(jìn)測(cè)試人員與開(kāi)發(fā)人員之間的合作伙伴關(guān)系 以下項(xiàng)目和環(huán)境中更適合

50、運(yùn)用自動(dòng)化測(cè)試工具： 須要反復(fù)進(jìn)行的工作 負(fù)載壓力測(cè)試 測(cè)試人員和開(kāi)發(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ī)則困難的對(duì)象 人體感觀與易用性測(cè)試 不穩(wěn)定的軟件 涉及物理交互 選擇合適的自動(dòng)化測(cè)試工具 1、自動(dòng)化測(cè)試工具分類 自動(dòng)化測(cè)試工具分以下幾類： 負(fù)載壓力測(cè)試工具 功能測(cè)試工具 白盒測(cè)試工具 網(wǎng)絡(luò)測(cè)試工具 測(cè)試管理工具 測(cè)試協(xié)助工具 2、自動(dòng)化測(cè)試應(yīng)用策略 在測(cè)試過(guò)程中應(yīng)用測(cè)試工具主要有以下幾

51、個(gè)目的： 提高測(cè)試質(zhì)量； 削減測(cè)試過(guò)程中的重復(fù)勞動(dòng)； 實(shí)現(xiàn)測(cè)試自動(dòng)化，解決手工測(cè)試不能解決的問(wèn)題。 選擇合適的自動(dòng)化測(cè)試工具 建議以下幾個(gè)方面來(lái)權(quán)衡： （1）功能 報(bào)表功能 測(cè)試工具的集成實(shí)力 操作系統(tǒng)和開(kāi)發(fā)工具的兼容性 （2）價(jià)格 （3）測(cè)試工具的長(zhǎng)期投資考慮 測(cè)試工具的引入： 確定測(cè)試工具的應(yīng)用時(shí)機(jī)； 確定測(cè)試重點(diǎn)； 確定測(cè)試目標(biāo)和指標(biāo)； 充分利用測(cè)試工具的優(yōu)勢(shì)； 加強(qiáng)對(duì)測(cè)試工程師的技能培訓(xùn)； 功能自動(dòng)化測(cè)試 1、測(cè)試原理 測(cè)試自動(dòng)化測(cè)試工具基本上都是實(shí)行錄制回放的方式來(lái)模擬用戶的實(shí)際操作。在軟件操作中點(diǎn)擊圖形用戶界面上的對(duì)象時(shí)，測(cè)試工具會(huì)用一

52、種類C或其他的腳本語(yǔ)言（TSL）生成一個(gè)測(cè)試腳本，該腳本記錄了你的操作過(guò)程，然后測(cè)試工具就可回放剛才的操作過(guò)程。測(cè)試工具實(shí)行兩種錄制模式： （1）環(huán)境推斷模式 這種模式依據(jù)你選取的圖形用戶界面對(duì)象（如窗體、清單、按鈕等），把你對(duì)軟件的操作動(dòng)作錄制下來(lái)，每一次你對(duì)被測(cè)軟件進(jìn)行操作，測(cè)試腳本語(yǔ)言會(huì)記錄并描述你選取的對(duì)象和你的操作動(dòng)作。當(dāng)你進(jìn)行錄制時(shí)，測(cè)試工具會(huì)對(duì)你選取的每個(gè)對(duì)象做惟一描述并寫入相應(yīng)的文件中?；胤艜r(shí)，測(cè)試工具從指定文件中讀取對(duì)象描述，并在被測(cè)軟件中查找符合這些描述的對(duì)象并模擬用戶運(yùn)用鼠標(biāo)選取該對(duì)象、用鍵盤輸入數(shù)據(jù)的操作。 （2）模擬模式 這種模式記錄鼠標(biāo)點(diǎn)擊、鍵盤輸入和鼠標(biāo)在

53、二維平面上的精確運(yùn)動(dòng)軌跡。執(zhí)行測(cè)試時(shí)，測(cè)試工具讓鼠標(biāo)依據(jù)軌跡運(yùn)行。 通常狀況下，其實(shí)施測(cè)試必需經(jīng)驗(yàn)的幾個(gè)操作步驟如下： 創(chuàng)建腳本。你可以通過(guò)錄制、編程或兩者同用的方式創(chuàng)建測(cè)試腳本。測(cè)試工具可以自動(dòng)記錄你的操作并生成所需的腳本代碼，你還可以干脆修改測(cè)試腳本以滿意各種困難測(cè)試的需求，錄制測(cè)試時(shí)，在須要檢查軟件反應(yīng)的地方插入檢查點(diǎn)。在這個(gè)過(guò)程中，測(cè)試工具會(huì)自動(dòng)捕獲數(shù)據(jù)，并將該數(shù)據(jù)作為期望結(jié)果儲(chǔ)存下來(lái)。 調(diào)試腳本：腳本錄制或編輯結(jié)束后，在調(diào)試模式下運(yùn)行腳本。并可以設(shè)置中斷點(diǎn)來(lái)監(jiān)測(cè)變量，限制對(duì)象識(shí)別和隔離錯(cuò)誤。 執(zhí)行測(cè)試：腳本調(diào)試結(jié)束后，便可以在檢驗(yàn)?zāi)Ｊ较聹y(cè)試被測(cè)軟件。 結(jié)果分析：每次測(cè)試結(jié)束

54、，測(cè)試工具都會(huì)把測(cè)試狀況顯示在測(cè)試結(jié)果報(bào)告中。 負(fù)載壓力自動(dòng)化測(cè)試 負(fù)載測(cè)試是為了證明在與產(chǎn)品（預(yù)期）規(guī)模等同的數(shù)據(jù)庫(kù)中處理給定的事務(wù)懇求的容量下，系統(tǒng)功能與性能是否與需求規(guī)格說(shuō)明中規(guī)定的，可接受的響應(yīng)時(shí)間一樣的測(cè)試過(guò)程。而壓力測(cè)試則是使客戶機(jī)在大容量狀況下運(yùn)行的測(cè)試過(guò)程，目的是查看應(yīng)用將在何時(shí)何處出現(xiàn)中斷，即識(shí)別系統(tǒng)的薄弱環(huán)節(jié)。 負(fù)載壓力測(cè)試工具基本上都是實(shí)行錄制回放的方式來(lái)模擬用戶的實(shí)際操作的，而且測(cè)試工具一般都會(huì)有一個(gè)后臺(tái)代理進(jìn)程，通過(guò)該代理進(jìn)程，測(cè)試工具可以監(jiān)視并獲得在各種通信協(xié)議下應(yīng)用系統(tǒng)的客戶與服務(wù)器的通信信息，測(cè)試工具會(huì)用一類C或者其他的腳本語(yǔ)言（TSL）生成一個(gè)測(cè)試腳本，該腳本記錄了你對(duì)服務(wù)器的懇求過(guò)程，然后測(cè)試工具就可以回放剛才的訪問(wèn)過(guò)程，接收服務(wù)器的響應(yīng)，當(dāng)然你也可以用手工編程生成這個(gè)腳本。 同時(shí)，限制臺(tái)還可以通過(guò)服務(wù)器上開(kāi)啟的遠(yuǎn)程RPC服務(wù)，獲得相關(guān)的資源運(yùn)用信息，最終還可以收集測(cè)試數(shù)據(jù)。 在進(jìn)行測(cè)試腳本錄制與安排的過(guò)程中，應(yīng)遵循如下幾個(gè)原則。 腳本越小越好。 選擇負(fù)載壓力最高的業(yè)務(wù)功能進(jìn)行測(cè)試。 選擇所須要的操作進(jìn)行錄制。 測(cè)試工具模擬多用戶并發(fā)訪問(wèn)可以有以下兩種方式： 進(jìn)程回放模式； 線程回放模式； 操作步驟如下： 協(xié)議選擇： 創(chuàng)建測(cè)試腳本： 參數(shù)化測(cè)試數(shù)據(jù) 創(chuàng)建虛擬用戶，設(shè)定負(fù)載方案 執(zhí)行測(cè)試 結(jié)果分析