今年九月初找工作才開始走上軟體測試的道路，下面的是我找軟體測試這份工作之前通過閱讀軟體測評師教程做的筆記。因為是為找工作中的筆試和麵試準備的，所以都是一些重點的羅列，希望能幫到正在找軟體測試工作的應屆生們。

 

 

1、軟體測試的目的是發現軟體中存在的錯誤，提高軟體質量，降低軟體專案的風險。

2、軟體測試只能證明軟體存在錯誤，而不能證明軟體沒有錯誤。測試的目的只是把軟體的錯誤控制在一個可以進行產品交付/釋出的程度上，可以交付/釋出產品並不是沒有錯誤的產品。

3、軟體測試不可能無休止的進行下去。隨著測試時間的延伸，發現錯誤的成本會越來越大，這就需要測試有度，而這個度並不能由專案計劃實際判斷，而是要根據測試發現錯誤的概率來判斷。

4、第三方測試指獨立於軟體公司自身測試的測試，所謂第三方是指在軟體公司和軟體使用者之間的一方，是一箇中介的服務機構，第三方測試除了發現軟體問題之外，還要對軟體進行科學、公正的評價的職能。

5、軟體測試是指對軟體形成過程中的文件、資料及程式進行的測試，而不僅僅是對程式進行的測試。

6、軟體測試與質量保證的區別

         質量保證（QA）：質量保證的重要工作通過預防、檢查與改進來保證軟體質量，QA採用“全面質量管理”和“過程改進”的原來來開展質量保證工作，所關注的是軟體質量的檢查與測量。QA的工作是軟體生命週期的管理及驗證軟體是否滿足規定的質量和使用者需求，因此主要著眼於軟體開發活動中的過程、步驟和產物，而不是對軟體進行剖析找出問題或評估。

         軟體測試：軟體測試雖然也與開發過程緊密相關，但關心的不是過程的活動，而是對過程的產物以及開發出來的軟體進行剖析。

7、軟體測試的作用

（1）對軟體質量進行度量和評估，以驗證軟體的質量滿足使用者的需求的程度，為使用者選擇和接受軟體提供有力的依據；

（2）通過分析錯誤產生的原因幫助發現當前開發工作所採用的軟體過程的缺陷；

（3）通過測試結果的分析整理，還可以修正軟體開發規則，並未軟體可靠性分析提供依據；

8、軟體測試的原則

（1）所有軟體測試都應追溯到使用者需求；

（2）應當把“儘早地和不斷地進行軟體測試”作為軟體測試的座右銘；

（3）完全的測試是不可能的，測試需要終止；

（4）測試無法顯示軟體潛在的缺陷；

（5）充分注意測試中的群集現象；

（6）程式設計師應避免檢查自己的程式；

（7）儘量避免測試的隨意性。

9、軟體測試的物件

軟體中的程式、資料和文件。軟體測試貫穿字整個軟體生命週期中，各階段有不同的測試物件，形成了不同階段的不同型別的測試。

（1）需求分析、概要設計、詳細設計以及程式編碼等各個階段所得的文件，包括需求規格說明書、概要設計規格說明、詳細設計規格說明以及源程式；

（2）在軟體編碼結束之後，對編寫的每個程式模組進行測試，稱為“模組測試”或“單元測試”；

（3）在模組整合後，對整合在一起的模組元件，有時也可稱為“部件”，進行測試，稱為“整合測試”；

（4）在整合測試之後，需要檢測與證實軟體滿足軟體需求規格說明書中規定的要求，這就成為“確認測試”；

（5）將整個程式模組即成為軟體系統，安裝在執行環境下，對硬體、網路、作業系統及支撐平臺構成的整體系統進行測試，稱為“系統測試”。

10、驗證與確認

驗證是保證軟體正確實現特定功能的一系列活動和過程，目的是保證軟體生命週期中的每一個階段的成果滿足上一個階段所設定的目標；確認是保證軟體滿足使用者需求的一系列的活動與過程，目的是在軟體開發完成後保證軟體與使用者需求相符合。

驗證與確認均屬於軟體測試，包括對軟體分析、設計及程式的驗證和確認。

11、軟體測試的分類

按照全生命週期的軟體測試概念，測試物件應該包括軟體設計開發的各個階段的內容，此處重點講述開發階段的測試和程式測試。

（1）按照開發階段劃分：

按照開發階段劃分軟體測試可分為：單元測試、整合測試、系統測試、確認測試和驗收測試。

1）單元測試：單元測試又稱為模組測試，是針對軟體設計的最小單位—程式模組進行正確性檢驗的測試工作。其目的在於堅持每個程式單元能否正確的實現詳細設計說明中的模組功能、效能、介面和設計約束等要求，發現各模組內部可能存在的各種錯誤。單元測試需要從程式的內部結構出發設計測試用例。多個模組可以平行地獨立進行單元測試。

2）整合測試：整合測試也叫做組裝測試。通常在單元測試的基礎上，將所有的程式模組進行有序的、遞增的測試。整合測試是檢驗程式單元或部件的介面關係，逐步即成為符合概要設計要求的程式部件或整個系統。

軟體整合的過程是一個持續的過程，會形成很多個臨時版本，在不斷地整合過程中，功能整合的穩定性是真正的挑戰。在每個版本提交時，都需要進行冒煙測試，即對程式主要功能進行驗證。冒煙測試（BVT (Build Verification Test)）也叫做版本驗證測試、提交測試。

3）確認測試：確認測試時通過檢驗和提供客觀證據，證實軟體是否滿足特定預期用途的需求。確認測試是檢測與證實軟體是否滿足軟體需求說明書中規定的要求。

4）系統測試：系統測試是為驗證和確認系統是否達到其原始目標，而對整合的硬體和軟體系統的測試。系統測試時在真實或者模擬系統執行的環境下，檢查完整的程式能否與系統（包括硬體、外設、網路和系統軟體、支援平臺等）正確配置、連線，並滿足使用者需求。

5）驗收測試：按照專案任務書或合同、供需雙方約定的驗收依據文件進行的對整個系統的測試與評審，決定是否接受或者拒收系統。

（2）按照測試實施組織劃分

按照測試實施組織劃分，軟體測試可分為開發方測試、使用者測試（β測試）、第三方測試。

1）開發方測試：通常也叫“驗證測試”或“α測試”。開發方通過檢測和提供客觀證據，證實軟體的實現是否滿足規定的需求。驗證測試是在軟體開發環境下，由開發者檢測與證實軟體的實現是否滿足軟體設計說明或軟體需求說明的要求。主要是指在軟體開發完成以後，開發方對要提交的軟體進行全面的自我檢查與驗證，可以與軟體的“系統測試”一併進行。

2）使用者測試：在使用者的應用環境下，使用者通過執行和使用軟體，檢測與核實軟體實現是否符合自己預期的要求。通常情況下，使用者測試不是指使用者的“驗收測試”，而是指使用者的使用性測試，由使用者找出軟體應用過程中發現的軟體的缺陷與問題，並對使用質量進行評價。

β測試通常被看成是一種“使用者測試”。β測試主要是把軟體產品有計劃地免費分發到目標市場，讓使用者大量使用，並評價、檢查軟體。通過使用者各種方式的大量使用，來發現軟體中存在的問題與錯誤，把資訊反饋給開發者修改。β測試中廠商獲得的資訊，可以有助於軟體產品的成功釋出。

3）第三方測試：介於軟體開發方和使用者方之間的測試組織的測試，第三方測試也成為獨立測試。獨立的驗證和確認活動。在模擬使用者真實應用環境下，進行軟體確認測試。

（3）按照測試技術分

第一種劃分：靜態測試、動態測試；

1)靜態測試：指不允許程式，通過人工對程式和文件進行分析與檢查。又稱為靜態分析技術，實際上是對軟體中的需求說明書、設計說明書、程式原始碼等進行非執行檢察，包括：走查、符號執行、需求確認。

2)動態測試：是指通過人工或者使用工具執行程式進行檢查、分析程式的執行狀態和程式的外部表現。

第二種劃分：白盒測試、黑盒測試、灰盒測試；

1)白盒測試：通過對程式內部結構的分析、檢測來尋找問題。白盒測試是在清楚瞭解程式結構和處理過程的基礎上，檢查是否所有的結構及路徑都是正確的，檢查軟體內部動作是否按照設計說明書的規定正常進行。又稱為結構測試。

2)黑盒測試：通過軟體的外部表現來發現其缺陷和錯誤，完全不考慮程式內部結構和處理過程，在程式介面處進行測試，只是檢查程式是否按照需求規格說明書的規定正常實現。

3)灰盒測試：介於白盒測試與黑盒測試之間的測試，關注輸出對於輸入的正確性；同時也關注內部表現，但是這種關注不像白盒測試那樣詳細、完整，只是通過一些表徵性的現象、時間、標誌來判斷內部的執行狀態。

12、軟體測試過程模型

（1）V模型

優點：是瀑布模型的變種，反映了測試活動與分析和設計的關係，從左到右，描述了基本的開發過程和測試行為，非常明確的標明瞭測試過程中存在的不同級別，並且清楚地描述了這些測試階段和開發過程期間各階段的對於關係。

缺點：僅僅把測試過程作為在需求設計、概要設計、詳細設計及編碼之後的一個階段，不能體現“儘早地和不斷地進行軟體測試”的原則。容易使人認為測試時軟體開發的最後一個階段，主要是針對程式進行測試尋找錯誤，而是需求分析階段隱藏的問題一直到後期的驗收測試才被發現。

 

（2）W模型

         在V模型中增加軟體各開發階段應同步進行的測試，被演化為W模型，因為開發是“V”，測試也是與此並行的“V”。基於“儘早地和不斷地進行軟體測試”的原則，在軟體的需求和設計階段的測試活動應遵循IEEE std 1012-1998《軟體驗證和確認（V&V）》的原則。

         侷限性：跟V模型一樣把軟體開發是為需求、設計、編碼等一系列序列的活動。同樣的，軟體開發與測試保持一種線性的前後關係，需要有嚴格的指令表示上一階段完全結束，才可正式開始下一個階段，這樣就無法支援迭代、自發性以及變更調整。對於當前很多文件需要時候補充，或者根本就沒有文件的做法下（這已成為一種開發的文化），開發人員和測試人員都面臨同樣的困惑。

 

（3）H模型

         將測試活動完全獨立出來，形成一個獨立的流程，將測試準備活動和測試執行活動清晰地表現出來。

 

這個示意圖僅僅演示了在整個生產週期中某個層次上的一次測試“微迴圈”。圖中的其他流程可以是任意開發流程（設計流程、編碼流程等，也可以是測試流程自身），只要測試條件成熟了，測試準備活動完成了，測試執行活動就可以（或者說需要）進行了。

         H模型揭示了：

1）軟體測試不僅僅指測試的執行，還包括很多其他的活動。

2）軟體測試是一個獨立的流程，貫穿產品整個生命週期，與其他流程併發地進行。

3）軟體測試要儘早準備，儘早執行。

4）軟體測試是根據被測物的不同分層次進行的。不同層次的測試活動可以是按照某個次序先後進行的，但也可能是反覆的。

 

（4）X模型

 

         X模型的目標是彌補V模型的一些缺陷。X模型左邊描述的是針對單獨程式片段進行的相互分離的編碼和測試，此後進行頻繁的交接，通過整合最終合成可執行的程式。這一點在圖的右上方得以體現，而且這些可執行程式還需要進行測試，已通過測試的成品可以進行封板並提交給使用者，也可以作為更大規模和範圍內整合的一部分。此外，X模型還定位了探索性測試，即不進行事先計劃的特殊型別的測試，諸如“我這麼測一下，結果會怎麼樣”，這一方式往往能幫助有經驗的測試人員在測試計劃之外發現更多的軟體錯誤。

 

（5）前置測試模型

 

前置測試模型體現了以下的要點：

1）開發和測試相結合

2）對每一個交付內容進行測試，不僅僅是源程式程式碼，還包括可行性報告、業務需求說明、系統設計文件等。

3）在設計階段進行測試計劃和測試設計

4）測試和開發結合在一起，在開發階段以編碼—測試—編碼—測試的方式實現，也就是說程式片段一旦編寫完成，就會立即進行測試。

5）讓驗收測試和技術測試保持相互獨立。

 

13、軟體測試與軟體開發過程的關係

 

14、軟體測試策略

（1）測試資訊流

 

1）軟體配置：包括軟體需求規格說明書、軟體設計規格說明書、原始碼等。

2）測試配置：包括測試計劃、測試用例、測試驅動程式等。實際上，在整個軟體工程中，測試配置只是軟體配置的一個子集。

3）測試工具：減輕測試的手工勞動，如測試資料的自動生成程式、靜態分析程式、動態分析程式、測試結果分析程式以及驅動測試的測試資料庫等

（2）分析設計階段

         主要包括需求說明書評測、詳細設計說明書評測以及軟體編碼規範評測。

軟體編碼規範評測主要圍繞源程式文件化、資料說明的方法、語句結構和輸入輸出這四個方面進行。

源程式文件化：符號名的命名、程式註釋、標準的書寫格式。

資料說明：資料說明的次序應當規範化、說明語句中變數的安排有序化、使用註釋說明覆雜資料結構。

語句結構：清晰第一，效率第二，不要為了最求效率而喪失了清晰性。

輸入輸出：輸入輸出的方式和格式應儘可能方便使用者的使用。

（3）開發階段

1）單元測試

a、單元測試的內容

模組介面測試：呼叫所測模組時的輸入引數與模組的形式引數在個數、屬性、順序上是否匹配；所測模組呼叫子模組時，它輸入給子模組的引數與子模組的形式引數在個數、屬性、順序上是否匹配；是否修改了製作輸入用的形式引數；輸出給標準函式的引數在個數、屬性、順序上是否正確；全域性量的定義在各模組中是否一致；限制是否通過形式引數來傳遞。

區域性資料結構測試：區域性資料結構是最常見的錯誤來源，區域性資料結構測試主要包括不正確或不一致的資料型別說明；使用尚未賦值或尚未初始化的變數；錯誤的初始值或錯誤的卻預設值；變數名拼寫錯或書寫錯；不一致的資料型別。可能的話，除區域性資料之外的全域性資料對木塊的影響也需要查清。

路徑測試：選擇適當的測試用例，對模組中重要的執行路徑進行測試。

錯誤處理測試：要求能遇見出錯的條件，並設定適當的出錯處理，以便在一旦程式出錯是，能對出錯程式重做安排，保證其邏輯上的正確性。以下情況表明模組的錯誤處理功能半酣有錯誤或缺陷：出錯描述難以理解；出錯的描述不足以對錯誤進行定位，不足以確定出錯的原因；顯示的錯誤與實際的錯誤不符；對錯誤條件的處理不正確；在對粗無進行處理之前，錯誤條件已經引起系統的干預等。

邊界測試：要特別注意資料流、控制流中剛好等於、大於或小於確定的比較值時出錯的可能性。

 

b、單元測試的步驟

在源程式程式碼編制完成，經過評審和驗證，確認沒有語法錯誤之後，就開始進行單元測試的測試用例設計。

單元測試的輔助模組：

驅動模組--相當於所測模組的主程式，它接受測試資料，把這些資料傳送給所測模組，最後再輸出實測結果。

樁模組—也叫做存根模組，用於代替所測模組呼叫的子模組。樁模組可以做少量的資料操作，不需要把子模組所有功能都帶進來，但不允許什麼事都不做。

驅動模組和樁模組的編寫會給測試帶來額外的開銷。因為他們在軟體交付時不作為產品的一部分一同交付。為了能夠正確地測試軟體，樁模組可能需要模擬實際子模組的功能，這樣，樁模組的建立就不是很輕鬆了。

 

模組的內聚程度高的話，可以簡化單元測試的過程。如果一個模組要完成多種功能，且以程式包的形式出現的也不少見，這是就可以把這個模組看成幾個小程式，分別進行單元測試，對關鍵模組還要做效能測試。對支援某些標準規程的程式，更要招收進行互聯測試。有人把這種情況特別稱為模組測試，以區別單元測試。

 

2）整合測試

整合測試也叫做組裝測試或者聯合測試。通常，在單元測試的基礎上，需要將所有模組按照概要設計說明書和詳細設計說明書的要求進行組裝。

a、組裝時要考慮的問題

在把各個模組連線起來的時候，穿越模組介面的資料是否會丟失；

一個模組的功能是否會對另一個模組的功能產生不利的影響；

各個子功能模組組合起來，能否達到預期要求的父功能；

全域性資料結構是否有問題；

各個模組的誤差累計起來，是否會放大，以致達到不能接受的程度。

b、部件測試

子系統的整合測試稱為部件測試，它所做的工作是要找出組裝後的子系統與系統需求規格說明書之間的不一致。

c、模組組裝成為系統的方式

 

一次性組裝方式：首先對每個模組分別進行模組測試，再把所有模組組裝在一起進行測試，最終得到要求的軟體系統。

 

 

其中，d1,d2,d3,d4,d5是對各個模組做單元測試時建立的驅動模組，s1,s2,s3,s4,s5是為單元測試而建立的樁木塊。這種一次性組裝方式試圖在輔助模組的協助下，在分別完成模組單元測試的基礎上，將所有模組連線起來進行測試。但是由於不可避免的存在模組間介面、全域性資料結構等方面的問題，所以一次性試執行成功的可能性並不大，其結果是，發現有錯誤，卻茫然找不到原因，查錯和改錯都會遇到困難。

 

增值式組裝方式：又稱漸增式組裝，是首先對一個個模組進行模組測試，然後將這些模組逐步組裝成較大的系統，在組裝的過程中邊連線邊測試，以發現連線過程中產生的問題，最後通過增殖逐步組裝成為要求的軟體系統。包括自頂向下的增殖方式、自底向上的增殖方式、混合增值式測試。

自頂向下的增殖方式：首先以主模組作為所測模組兼驅動模組，所有直屬於主模組的下屬模組全部用樁模組代替，對主模組進行測試。再採用深度優先或廣度優先的策略，用實際模組替換相應的樁模組，再用樁模組代替他們的直屬下屬模組，與已測試的模組或子系統組裝成新的子系統。然後進行迴歸測試（即重新執行以前做過的全部測試或部分測試），排除組裝過程中引入新的錯誤的可能。最後，判斷是否所有的模組都已組裝到系統中，是，則結束測試；否則繼續執行。

缺點是要建立樁模組，而且建立樁模組的複雜度高，會增加附加的測試；底層模組最容易出問題，如果到組裝後期才遇到，就會導致過多的迴歸測試。

優點是能夠較早的發現主要控制方面的問題。

自底向上的增殖方式：首先由驅動模組控制最底層模組的並行測試；也可以把最底層模組組合成實現某一特定軟體功能的簇，由驅動模組控制它進行測試。再用實際模組代替驅動模組，與它已測試的指數子模組組裝成為子系統。然後為子系統配備驅動模組，進行新的測試。最後判斷是否已組裝到達主模組，是則結束測試，否則繼續執行測試。

 

缺點是主要控制最後才接觸到，優點是不需要樁模組，而驅動模組一般叫好建立。

混合增殖式測試：自頂向下的增殖方式和自底向上的增殖方式混合。

d、整合測試計劃要考慮的因素

採用何種系統組裝方法進行整合測試;

整合測試過程中各個連線模組的順序;

模組程式碼編制和測試進度是否與整合測試的順序一致;

測試過程中是否需要專門的硬體裝置;

e、整合測試完成的標識

成功地執行了測試計劃中規定的所有整合測試;

修正了所發現的錯誤;

測試結果通過了專門小組的評審;

測試完成後要提交測試報告，測試報告中藥積累實際的測試結果、在測試中發現的問題、解決這些問題的方法以及解決之後再次測試的結果，此外還應提出目前不能解決、還需要管理人員和開發人員注意的一些問題，提供測試評審和最終覺得，以提出處理意見。

整合測試要提交的文件包括整合測試計劃、整合測試規格說明和整合測試分析報告。

 

3）確認測試

確認測試的任務是驗證軟體的功能與效能及其其他特性是否與使用者的要求一致，對軟體的功能和效能要求在軟體需求規格說明書中明確規定。確認測試一般包括有效性測試和軟體配置複查，一般由獨立的第三方機構進行。

有效性測試：在模擬的環境下，運用黑盒測試的方法，驗證所測軟體是否滿足需求規格說明書列出的需求。

軟體配置複查：保證如見配置的素有成分都齊全，各方面的質量都符合要求，具有維護階段所必須的細節，而且已經編排好分類的目錄。

在確認測試中，還應當嚴格遵守使用者手冊和操作手冊中規定的使用步驟，以便檢查文件資料的完整性和正確性。

4）系統測試

系統測試是將通過整合測試的軟體，作為整個基於計算機系統的一個元素，與計算機硬體、外設、某些支援軟體、資料和人員等其他系統元素結合在一起，在實際或者模擬執行（使用）環境下，對計算機系統進行一系列的測試。目的是通過與系統的需求定義做比較，發現軟體與系統定義不符合或者與之矛盾的地方。

5）驗收測試

驗收測試是以使用者為主的測試。軟體開發人員和質量保證人員也應參加。由使用者參加設計測試用例，使用使用者輸入介面輸入測試資料，並分析測試的輸出結果，一般使用生產中的實際資料進行測試。

（4）軟體驗證與確認（V&V）過程

         軟體的V&V）過程是確定按照規定的軟體開發過程開發的產品是否符合活動的要求，軟體會否滿足它的預期使用者和使用者需要，包括軟體產品和過程的分析、評價、評審、稽核、評估和測試。

15、軟體失效分類

         軟體錯誤、軟體缺陷、軟體故障、軟體失效。

（1）軟體錯誤：指軟體生存期內的不希望或不可接受的人為錯誤，其結果是導致軟體缺陷的產生。

（2）軟體缺陷：軟體缺陷是存在於軟體（文件、資料、程式）之中的那些不希望或不可接受的偏差，如少一逗點、多一語句等。其結果是軟體運行於某一特定條件時出現軟體故障，這時稱軟體缺陷被啟用。

（3）軟體故障：是指軟體執行過程中出現的一種不希望或不可接受的內部狀態。譬如軟體處於執行一個多餘迴圈過程時，我們說軟體出現故障。此時若無適當措施加以即時處理，便會產生軟體失效

（4）軟體失效：是指軟體執行時產生的一種不希望或不可接受的外部行為結果。

         綜上所述，軟體錯誤是一種認為錯誤，一個軟體錯誤必定產生一個或多個軟體缺陷，當一個軟體缺陷被啟用時，便會產生一個軟體故障；同一個軟體缺陷在不同條件下被啟用，可能產生不同的軟體故障。故障如果沒有及時的容錯措施加以處理，便不可避免地產生軟體失效；同一軟體故障在不同條件下可能產生不同的軟體失效。

         軟體缺陷第一大來源是產品說明書，第二大來源是設計方案，原因都是片面、多變、理解與溝通不足。

16、缺陷與錯誤的嚴重性和優先順序

（1）嚴重級：

1）嚴重：系統崩潰、資料跌勢、資料毀壞。

2）較嚴重：操作性錯誤、錯誤結果、遺漏功能。

3）一般：小問題、錯別字、UI佈局、罕見故障。

4）建議：不影響使用的瑕疵或更好的實現。

（2）優先順序：

1）最高優先順序：立即修復，停止進一步測試。

2）次高優先順序：在產品釋出之前必須修復。

3）中等優先順序：如果時間允許應該修復。

4）最低等優先順序：可能會修復，但是也能釋出。

17、軟體錯誤跟蹤管理

（1）錯誤跟蹤管理

1）Bug記錄資訊：測試軟體名稱、測試版本號、測試人名稱、測試事件、測試軟體和硬體配置環境、發現軟體錯誤的型別、錯誤的嚴重級別、詳細步驟、必要的附圖、測試註釋；

2）Bug處理資訊：處理者姓名、處理時間、處理步驟、錯誤記錄的當前狀態；

（2）軟體錯誤的狀態

1）新資訊（New）：測試中新報告的軟體Bug。

2）開啟（Open）：被確認並分配給相關開發人員處理。

3）修正（Fixed）：開發人員已完成修正，等待測試人員驗證。

4）拒絕（Declined）：拒絕修改Bug。

5）延期（Deferred）：不在當前版本修復的錯誤，下一版本修復。

6）關閉（Closed）：Bug已被修復。

（3）錯誤管理流程

1）測試人員提交新的錯誤入庫，錯誤狀態為“New”。

2）高階測試人員驗證錯誤。

如果確認是錯誤，分配給相應的開發人員，設定狀態為“Open”。

如果不是錯誤，則拒絕，設定為“Declined”狀態

3）開發人員查詢狀態為“Open”的錯誤，做如下處理：

如果不是錯誤，則置狀態為“Declined”。

如果是錯誤，則修復並置狀態為“Fixed”。

如果不能解決的錯誤，要留下文字說明並保持錯誤為“Open”狀態。

對於不能解決和延期解決的錯誤，不能由開發人員自己決定，一般要通過某種會議（評審會）通過才能認可。

4）測試人員查詢狀態為“Fixed”的錯誤，驗證錯誤是否已解決，做如下處理：

如果問題解決了，置錯誤狀態為“Closed”。

如果問題沒解決，則置狀態為“Reopen”。

18、自動化測試

自動化測試就是通過測試工具或其他手段，按照測試工程師的預定計劃對軟體產品進行自動的測試，它是軟體測試的一個重要組成部分，它能夠完成許多手工無法完成或者難以實現的一些測試工作。

（1）優勢：

提高測試質量；

提高測試效率，縮短測試工作時間；

提高測試覆蓋率；

執行手工測試不能完成的測試任務；

更好的重現軟體缺陷的能力；

更好的利用資源；

增進測試人員與開發人員之間的合作伙伴關係。

（2）適用專案和環境：

需要反覆進行的工作；

複雜壓力測試；

公司有大量的測試人員和開發人員，他們合作完成一個產品，那麼如何在產品的生命週期中進行有效的管理和合作，藉助自動化測試管理工具，會取得事半功倍的效果。

如果需要進行測試系統後臺或者內部的效能特徵，進而進行故障定位和效能調優，自動化測試工具是一個不錯的選擇。

（3）侷限性：定製型專案、週期很短的專案、業務規則複雜的物件、人體感官與易用性測試、不穩定的軟體、涉及物理互動。

（4）對自動化測試的不正確的期望

1）自動化測試可以完成一切測試工作：在顯示中有關的測試計劃、測試案例以及一些關鍵的測試任務害死需要人工參與的，即自動化測試時對手工測試的輔助和補充，它永遠不可能取代手工測試。

2）測試工具可適用於所有的測試：每種自動化測試工具都有它的應用範圍和可用物件，針對不同的測試目的和測試物件，應該選擇合適的測試工具，在很多情況下，需要利用很多測試工具才能完成測試工作。

3）測試工具能使工作量大幅降低：事實上，引入自動化測試工具不會馬上減輕測試工作，相反，在更多情況下，首次將自動化測試工具引入企業時，測試工作實際上變得更艱鉅。只有正確合理的使用測試工具，並且有一定的技術積累，測試工作量才能逐漸減輕。

4）測試工具能實現百分百的測試覆蓋率：自動化測試可以增加測試覆蓋的深度和廣度，但是也不可能進行百分之百的徹底測試。

5）自動化測試工具容易使用：許多人認為測試工具可以簡單地通過捕獲（錄製）客戶端操作生成指令碼，且指令碼不加編輯就可以用於回放使用。事實上，自動化測試不是那麼簡單，捕獲的操作是否正確以及指令碼編輯是否合理都會影響到測試結果，因此，自動化測試需要更多的技能，也需要更多的培訓。

6）自動化測試能發現大量的新缺陷：發現更多的新缺陷應該是手工測試的主要目的，不能期望自動化測試區發現更多新缺陷，事實上自動化測試主要用於發現老缺陷。

（5）自動化測試工具分類

1）負載壓力測試工具：主要目的是為了度量應用系統的可擴充套件性和效能，是一種預測系統行為和效能的自動化測試工具。通過模擬成百上千直至上萬使用者併發執行關鍵業務，而完成對應用程式的測試，在實施併發負載過程中通過實施效能檢測來確認和查詢問題，並針對所發現的問題對系統性能進行優化，確保應用的成功部署。負載壓力測試工具能夠對整個企業架構進行測試，通過這些測試，企業能最大限度地縮短測試時間，優化效能和加速應用系統的釋出週期。這類工具的主要代表有LoadRunner、QALoad、SILKOERFORMA V和E-Test Suite等。

2）功能測試工具：通過自動錄製、檢測和回放使用者的應用操作，將被測系統的輸出記錄同預先給定的標準結果進行比較，功能測試工具能夠有效地幫助測試人員對複雜的企業級應用的不同分佈版本的功能進行測試，提高測試人員的工作效率和質量。其主要目標是檢測應用程式是否能夠達到預期的功能並正常執行。功能測試工具可以大大減輕黑盒測試的工作量，在迭代開發的過程中，能夠很好的進行迴歸測試。這類工具的代表有WinRunner、QARun等。

3）白盒測試工具：白盒測試一般是針對程式碼進行測試，測試中發現的缺陷可以定位到程式碼級，根據測試工具原理的不同，又分為靜態測試工具和動態測試工具。靜態測試工具可以直接對程式碼進行分析，不需要執行程式碼，也不需要對程式碼編譯連線和生產可執行檔案。靜態測試工具一般是對程式碼進行語法掃描，找到不符合編碼規範的地方，根據某種質量模型評價程式碼的質量，生產系統的呼叫關係圖等，代表工具有Logiscope軟體和PRQA軟體。動態測試工具與靜態測試工具不同，動態測試工具一般採用“插樁”的方式，向程式碼生產的可執行檔案中插入一些檢測程式碼，用來統計程式執行時的資料。其餘靜態測試工具最大的不同就是動態檢測工具要求被測系統實際執行，代表工具有DevPartner、Rational Purify系列等。

4）網路測試工具：這類工具主要包括網路故障定位工具、網路效能監測工具、網路模擬模擬工具等。他們分析分散式應用效能，關注應用、網路和其他元素（如伺服器）內部的互動式活動，以便使網路管理員能夠了解網路不同位置和不同活動之間應用的行為。你可以用它在交易執行過程中、web查詢和檢索或在日常資料庫上載/下載中跟蹤應用行為。它可以在會話級、程式碼級，甚至在幀級和包級觀察應用的行為過程，並深入程式碼內部的結構，解析有問題的會話。

5）測試管理工具：用於對測試進行管理，一般對測試需求、測試計劃、測試用例、測試實施進行管理，還包括對缺陷的跟蹤管理。測試管理工具能讓測試人員、開發人員或其他的IT人員通過一個重要資料倉庫，在不同的地方就能互動資訊。測試管理工具將測試過程流水化，從測試需求管理到測試計劃、測試日程安排、測試執行到出錯後的錯誤跟蹤，實現了全過程的自動化管理。測試管理工具的代表有TestDirector、TestManger、TrarkRecord等。

6）測試輔助工具：這些工具本身不執行測試，例如生產測試資料，為測試提供資料準備。

19、功能自動化測試

（1）概述

功能測試自動化工具可以幫助測試工程師自動處理測試開發到測試執行的整個過程中的問題。其主要功能就是為了確保應用按照預期設計執行而將業務處理過程記錄到測試指令碼中。當應用被開發完成或應用升級時，測試工具支援測試指令碼的編輯、擴充套件、執行和報告測試結果，並且保證測試指令碼的可重複使用，貫穿於應用的整個生命週期。

對於功能測試工具的使用，比較重要的是測試規劃問題。

（2）原理

功能自動化測試工具基本上都是採用錄製回放的方式來模擬使用者的實際操作。當你在軟體操作中點選圖形使用者介面上的物件時，測試工具會用一種類C或其他指令碼語言（TSL）生產一個測試指令碼，該指令碼記錄了你的操作過程，然後測試工具就可以回放剛才的操作。通常情況下，測試工具採取兩種錄製模式。

（1）環境判斷模式

這種模式根據你選取的圖形使用者介面物件（如窗體、清單、按鈕等），把你對軟體的操作動作錄製下來，並忽略這些物件在螢幕上的物理位置。每一次你對被測軟體進行操作，測試指令碼語言會記錄並描述你選取的物件和你的操作動作。當你進行錄製時，測試工具會對你選取的每個物件對唯一描述並寫入相應的檔案中。當軟體使用者介面發生改變時，你只需要更小特定的物件記錄檔案。這樣一來，環境判斷模式的測試指令碼將非常容易地被重複使用。執行測試只需要回放測試指令碼。回放時，測試工具從指定檔案中讀取物件描述，並在被測軟體中查詢符合這些描述的物件並模擬使用者使用滑鼠選取該物件、用鍵盤輸入資料的操作。

（2）模擬模式

這種模式記錄滑鼠點選、鍵盤輸入和滑鼠在二維平面上（x軸和y軸）的精確運動軌跡。執行測試時，測試工具讓滑鼠根據軌跡運動。這種模式對於那些需要追蹤滑鼠運動的測試非常有效，例如畫圖軟體等。

不管採用何種模式，功能自動化測試必須經歷以下幾個操作步驟：

1）建立指令碼：可以通過錄制、程式設計或者兩者同用的方式建立測試指令碼。

2）除錯指令碼：指令碼錄製或編輯結束後，你可以先在除錯模式下執行指令碼，並可以設定斷點來檢測變數，控制物件識別和隔離錯誤。

3）執行測試：指令碼除錯結束後，便可以在檢測模式下測試被測軟體。

4）結果分析:每次測試結束，測試工具都會把測試情況顯示在測試結果報告中。測試結果報告會詳細描述測試執行過程中發生的所有主要事件，如檢查點、錯誤資訊、系統資訊或使用者資訊。

20、負載壓力自動化測試

（1）什麼是負載測試和壓力測試？

1）負載測試是為了證明在與產品（預期）規模等同的資料庫中處理給定的事務請求的容量下，系統功能與效能是否與需求規格說明書中規定的，可接受的響應時間一致的測試過程。

2）而壓力測試則是使客戶機在大容量情況下執行的測試過程，目的是檢視應用將在何時何處出現中斷，即識別系統的薄弱環節。可能暴露的系統缺陷有記憶體洩露、系統資源過量消耗、磁碟空間用完等。

（2）負載壓力測試工具可以記錄下客戶端的操作，並以指令碼的方式儲存，然後建立多個虛擬使用者，在一臺或者幾臺PC機上模擬上百或上千虛擬使用者同時操作的情景，同時記錄下每一事務處理的響應時間、中介軟體伺服器資源使用、資料庫負載等，測試工程師可以根據測試結果分析系統瓶頸。

負載測試是任何Web應用的開發週期中一個重要的步驟。

（3）測試原理

負載壓力測試工具基本上都是採取錄製回放的方式來模擬使用者的實際操作的。而且測試工具一般都會有一個後臺代理程序，通過該代理程序，測試工具可以監視並獲取在各種通訊協議下應用系統的客戶與伺服器端的通訊資訊，測試工具會用一種類C或者其他指令碼語言（TSL）生成一個測試指令碼，該指令碼記錄了你對伺服器的請求過程，然後測試工具就可以回放剛才的訪問過程，接受伺服器的響應，當然，也可以手工程式設計生成這個指令碼。

當被測系統執行時，指令碼生成器會自動獲取客戶端與伺服器的通訊資訊並轉換成測試工具可以識別的指令碼，測試工具通過控制檯將測試指令碼分發到其他負載生成器上以模擬多使用者對伺服器的併發訪問，同時控制檯還可以通過伺服器上開啟的遠端RPC服務，獲取相關的資源使用資訊，最後可以收集測試資料。

指令碼錄製和分配過程中應遵循的原則：

1）指令碼越小越好。

2）選擇負載壓力最高的業務功能進行測試。

3）選擇所需要的操作進行錄製。

測試工具模擬多使用者併發訪問的兩種方式：

1）程序回放模式：模擬多程序執行方式，即客戶端與伺服器的訪問採用程序方式，每一個虛擬使用者通過一個程序建立與伺服器的通訊連線並訪問。

2）執行緒回放模式：模擬多執行緒執行方式，即客戶端與伺服器的訪問採用執行緒方式，每一個虛擬使用者通過一個執行緒建立與伺服器的通訊連線並訪問。

測試工具進行錄製回訪時必須經歷的幾個操作步驟：

1）協議選擇；

2）建立測試指令碼；

3）引數化測試資料；

4）建立虛擬使用者；

5）執行測試；

6）結果分析。