軟件評測師教程筆記之軟件測試基礎

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

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

應當把“盡早地和不斷地進行軟件測試”作為軟件測試者的座左銘。

完全測試是不可能的，測試需要終止。

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

軟件入量太大；

輸出結(jié)果太多；

路徑組合太多。

測試無法顯示軟件潛在的缺陷

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

程序員應避免檢查自己的程序。

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