了解一些遊戲測試知識

讀 《軟體測試》[(美)Ron Patton中文電子版的筆記。

第一章

1、軟體缺陷的定義：

①、軟體未達到產品說明書標明的的功能

②、軟體出現了產品說明書指明不會出現的錯誤

③、軟體功能超出產品說明指定範圍

④、軟體未達到產品說明書雖未指出但應達到的目標

⑤、軟體測試員認為軟體難以理解、不易使用、運行速度緩慢，或者最終用戶認為不好。

2、缺陷原因

4、軟體測試是客戶的眼睛，是第一次看見軟體的人，代表客戶說話，應力求完美。

5、

第二章、軟體開發過程

1、

2、

5、軟體開發模式

第三章、軟體測試的實質

1、

2、

3、

第四章、檢查產品說明書

1、

2、

3

5、

第五章、閉著眼睛測試軟體

1、

5、

6、

7、

第六章、檢查代碼

1、

第七章、帶上X光眼鏡檢查軟體

1、

3、

4、

第八章、配置測試

1、

2、

1、

2、

第十章、外國語言測試

1、

2、

第十一章、易用性測試

1、

2、

第十二章、測試文檔

1、

第十三章、網站測試

1、

1、

第十五章、臭蟲轟炸和Beta測試

1、

第十六章、計劃測試工作

1、

2、

第十七章、編寫和跟蹤測試案例

第十八章、報告發現的問題

1、

2、

第十九章、評價成效

第二十章、軟體質量評判

測試理論體系

一、定義

1、軟體測試（英語：Software Testing），描述一種用來促進鑒定軟體的正確性、完整性、安全性和質量的過程。換句話說，軟體測試是一種實際輸出與預期輸出間的審核或者比較過程。軟體測試的經典定義是：在規定的條件下對程序進行操作，以發現程序錯誤，衡量軟體質量，並對其是否能滿足設計要求進行評估的過程。

2、1983年IEEE提出的軟體工程術語中給軟體測試下的定義是：「使用人工或自動的手段來運行或測定某個軟體系統的過程，其目的在於檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別」。

3、軟體測試 是使用人工操作或者軟體自動運行的方式來檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別的過程。

4、我自己的理解：軟體測試的目的是為了檢驗軟體系統是否滿足需求。

二、Glenford J.Myers曾對軟體測試的目的提出過以下觀點：

(1)測試是為了發現程序中的錯誤而執行程序的過程。

(2)好的測試方案是極可能發現迄今為止尚未發現的錯誤的測試方案。

(3)成功的測試是發現了至今為止尚未發現的錯誤的測試。

(4)測試並不僅僅是為了找出錯誤。通過分析錯誤產生的原因和錯誤的發生趨勢，可以幫助項目管理者發現當前軟體開發過程中的缺陷，以便及時改進。

(5)這種分析也能幫助測試人員設計出有針對性的測試方法，改善測試的效率和有效性。

(6)沒有發現錯誤的測試也是有價值的，完整的測試是評定軟體質量的一種方法。

(7)另外，根據測試目的的不同，還有回歸測試、壓力測試、性能測試等，分別為了檢驗修改或優化過程是否引發新的問題、軟體所能達到處理能力和是否達到預期的處理能力等。

三、原則

一，測試應該儘早進行，最好在需求階段就開始介入，因為最嚴重的錯誤不外乎是系統不能滿足用戶的需求。

二，程序員應該避免檢查自己的程序，軟體測試應該由第三方來負責。

三，設計測試用例時應考慮到合法的輸入和不合法的輸入以及各種邊界條件，特殊情況下還要製造極端狀態和意外狀態，如網路異常中斷、電源斷電等。

四，應該充分注意測試中的群集現象。

五，對錯誤結果要進行一個確認過程。一般由A測試出來的錯誤，一定要由B來確認。嚴重的錯誤可以召開評審會議進行討論和分析，對測試結果要進行嚴格地確認，是否真的存在這個問題以及嚴重程度等。

六，制定嚴格的測試計劃。一定要制定測試計劃，並且要有指導性。測試時間安排盡量寬鬆，不要希望在極短的時間內完成一個高水平的測試。

七，妥善保存測試計劃、測試用例、出錯統計和最終分析報告，為維護提供方便。

四、測試目標

1．發現一些可以通過測試避免的開發風險。

2．實施測試來降低所發現的風險。

3．確定測試何時可以結束。

4．在開發項目的過程中將測試看作是一個標準項目。

五、測試對象

程序。

數據。

文檔。

六、測試流程

1、制定測試計劃[4]

2、編輯測試用例

3、執行測試用例

4、發現並提交BUG

5、開發組修正BUG

6、對已修正BUG進行返測

7、修正完成的BUG將狀態置為已關閉，未正確修正的BUG重新激活

第一步：對要執行測試的產品/項目進行分析，確定測試策略，制定測試計劃。該計劃被審核批准後轉向第二步。測試工作啟動前一定要確定正確的測試策略和指導方針，這些是後期開展工作的基礎。只有將本次的測試目標和要求分析清楚，才能決定測試資源的投入。

第二步：設計測試用例。設計測試用例要根據測試需求和測試策略來進行，進度壓力不大時，應該設計的詳細，如果進度、成本壓力較大，則應該保證測試用例覆蓋到關鍵性的測試需求。該用例被批准後轉向第三步。

第三步：如果滿足「啟動準則」（EntryCriteria），那麼執行測試。執行測試主要是搭建測試環境，執行測試用例。執行測試時要進行進度控制、項目協調等工作。

第四步：提交缺陷。這裡要進行缺陷審核和驗證等工作。

第五步：消除軟體缺陷。通常情況下，開發經理需要審核缺陷，並進行缺陷分配。程序員修改自己負責的缺陷。在程序員修改完成後，進入到回歸測試階段。如果滿足「完成準則」（ExitCriteria），那麼正常結束測試。

第六步：撰寫測試報告。對測試進行分析，總結本次的經驗教訓，在下一次的工作中改。

軟體測試過程管理，主要包括軟體測試是什麼樣的過程，如何評價一個軟體測試過程，如何進行配置管理和測試風險分析以及測試成本的管理。

七、詳細分類

1、角度細分

①、從是否關心軟體內部結構和具體實現的角度劃分（按測試分類）

A.白盒測試

B.黑盒測試

C.灰盒測試

②、從是否執行程序的角度

A.靜態測試

B.動態測試。

2、階段細分

從軟體開發的過程按階段劃分有

A.單元測試

B.集成測試

C.確認測試

D.系統測試

E.驗收測試

F.回歸測試

G.Alpha測試

H.Beta測試

八、測試模型

V模型W模型H模型X模型

九、測試工具

AutoRunner是國內第一款自動化測試工具，可以用來完成功能測試、回歸測試、每日構建測試與自動回歸測試等工作。是具有腳本語言的、提供針對腳本完善的跟蹤和調試功能的、支持IE測試和Windows native測試的自動化測試工具。

TestCenter是一款功能強大測試管理工具，它可以幫助您：實現測試用例的過程管理，對測試需求過程、測試用例設計過程、業務組件設計實現過程等整個測試過程進行管理。實現測試用例的標準化即每個測試人員都能夠理解並使用標準化後的測試用例，降低了測試用例對個人的依賴；提供測試用例復用，用例和腳本能夠被複用，以保護測試人員的資產；提供可伸縮的測試執行框架，提供自動測試支持；提供測試數據管理，幫助用戶同意管理測試數據，降低測試數據和測試腳本之間的耦合度。

TAR(TerminalAutoRunner)適用於VT100、VT220等標準的應用系統，支持命令行模式和窗口模式（使用Cursors編寫的應用程序），支持自動錄製腳本、所見即所得的資源和腳本編輯，穩定的自動同步功能。是目前國內最好的銀行業務測試工具.

TestDirector是全球最大的軟體測試工具提供商Mercury Interactive公司生產的企業級測試管理工具，也是業界第一個基於Web的測試管理系統，它可以在您公司內部或外部進行全球範圍內測試的管理。通過在一個整體的應用系統中集成了測試管理的各個部分，包括需求管理，測試計劃，測試執行以及錯誤跟蹤等功能，TestDirector極大地加速了測試過程。

附錄1 名詞解釋

1、SQA=軟體質量保證：軟體質量保證的目的是使軟體過程對於管理人員來說是可見的。

2、回歸測試：指修改了舊代碼後，重新進行測試以確認修改沒有引入新的錯誤或導致其他代碼產生錯誤。.

1.回歸測試是指重複以前的全部或部分的相同測試。

2.新加入測試的模組，可能對其他模組產生副作用，故須進行某些程度的回歸測試。

3.回歸測試的重心，以關鍵性模組為核心。

3、壓力測試（Stress Test），也稱為強度測試、負載測試。壓力測試是模擬實際應用的軟硬體環境及用戶使用過程的系統負荷，長時間或超大負荷地運行測試軟體，來測試被測系統的性能、可靠性、穩定性等。

4、性能測試： 是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項性能指標進行測試。目的是驗證軟體系統是否能夠達到用戶提出的性能指標，同時發現軟體系統中存在的性能瓶頸，優化軟體，最後起到優化系統的目的。

5、測試用例（Test Case）：是為某個特殊目標而編製的一組測試輸入、執行條件以及預期結果，以便測試某個程序路徑或核實是否滿足某個特定需求。

6、單元測試（unit testing），是指對軟體中的最小可測試單元進行檢查和驗證。測試方法：(1) 模塊介面測試(2) 局部數據結構測試(3) 路徑測試(4) 錯誤處理測試(5) 邊界測試

7、集成測試，也叫組裝測試或聯合測試。在單元測試的基礎上，將所有模塊按照設計要求（如根據結構圖）組裝成為子系統或系統，進行集成測試。通常，把模塊集成成為系統的方式有兩種：1一次性集成方式。2 增殖式集成方式.增值式集成測試的實施方案有很多種，如自底向上集成測試、自頂向下集成測試、Big-Bang集成測試、三明治集成測試、核心集成測試、分層集成測試、基於使用的集成測試等。

8、確認測試的目的是向未來的用戶表明系統能夠像預定要求那樣工作。目前廣泛使用的兩種確認測試方式是α測試和β測試。α小，β大。

9、系統測試是針對整個產品系統進行的測試，目的是驗證系統是否滿足了需求規格的定義，找出與需求規格不符或與之矛盾的地方，從而提出更加完善的方案。比較常見的、典型的系統測試包括恢複測試、安全測試、壓力測試。

10、恢複測試：主要關注導致軟體運行失敗的各種條件，並驗證其恢復過程能否正確執行。

11、安全測試用來驗證系統內部的保護機制，以防止非法侵入。

12、驗收測試是向未來的用戶表明系統能夠像預定要求那樣工作。正式驗收 非正式驗收或 Alpha 測試 Beta 測試 註：確認測試是對開發人員，驗收測試是對客戶。

13、V模型：V模型的價值在於它非常明確地標明了測試過程中存在的不同級別，並且清楚地描述了這些測試階段和開發過程期間各階段的對應關係。局限性：把測試作為編碼之後的最後一個活動，需求分析等前期產生的錯誤直到後期的驗收測試才能發現。

14、W模型是V模型的發展，強調的是測試伴隨著整個軟體開發周期，而且測試的對象不僅僅是程序，需求、功能和設計同樣要測試。測試與開發是同步進行的，從而有利於儘早地發現問題。無法支持迭代、自發性以及變更調整。

15、X模型：X模型的左邊描述的是針對單獨程序片段所進行的相互分離的編碼和測試，此後將進行頻繁的交接，通過集成最終成為可執行的程序，然後再對這些可執行程序進行測試。但這樣可能對測試造成人力、物力和財力的浪費，對測試員的熟練程度要求比較高。

16：H模型：H模型中, 軟體測試過程活動完全獨立,貫穿於整個產品的周期,與其他流程並發地進行,某個測試點準備就緒時,就可以從測試準備階段進行到測試執行階段。

附錄2 黑盒測試

1、定義：黑盒測試也稱功能測試，它是通過測試來檢測每個功能是否都能正常使用。在測試中，把程序看作一個不能打開的黑盒子，在完全不考慮程序內部結構和內部特性的情況下，在程序介面進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數據而產生正確的輸出信息。黑盒測試著眼於程序外部結構，不考慮內部邏輯結構，主要針對軟體界面和軟體功能進行測試。

2、測試目標：功能不正確或遺漏；界面錯誤；輸入和輸出錯誤；資料庫訪問錯誤；性能錯誤；初始化和終止錯誤等。

3、具體的黑盒測試用例設計方法包括：等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、判定表驅動法、正交試驗設計法、功能圖法、場景法等。

1、等價類劃分法。等價類是指某個輸入域的子集合。下面六條確定等價類的原則。

①在輸入條件規定了取值範圍或值的個數的下，則一個有效等價類和兩個無效等價類。

②在輸入條件規定了輸入值的集合或者規定了「必須如何」的條件的情況下，可確立一個有效等價類和一個無效等價類.

③在輸入條件是一個布爾量的情況下，可確定一個有效等價類和一個無效等價類。

④在規定了輸入數據的一組值（假定n個），並且程序要對每一個輸入值分別處理的情況下，可確立n個有效等價類和一個無效等價類。

⑤在規定了輸入數據必須遵守的規則的情況下，可確立一個有效等價類（符合規則）和若干個無效等價類（從不同角度違反規則）。

⑥在確知已劃分的等價類中各元素在程序處理中的方式不同的情況下，則應再將該等價類進一步的劃分為更小的等價類。

然後從劃分出的等價類中按以下三個原則設計測試用例：

①為每一個等價類規定一個唯一的編號。

②設計一個新的測試用例，使其儘可能多地覆蓋尚未被覆蓋地有效等價類，重複這一步.直到所有的有效等價類都被覆蓋為止。

③設計一個新的測試用例，使其僅覆蓋一個尚未被覆蓋的無效等價類，重複這一步.直到所有的無效等價類都被覆蓋為止。

2、邊界值分析法。邊界值分析法就是對輸入或輸出的邊界值進行測試的一種黑盒測試方法。通常邊界值分析法是作為對等價類劃分法的補充，這種情況下，其測試用例來自等價類的邊界。基於邊界值分析方法選擇測試用例的原則：

1）如果輸入條件規定了值的範圍，則應取剛達到這個範圍的邊界的值，以及剛剛超越這個範圍邊界的值作為測試輸入數據。

2）如果輸入條件規定了值的個數，則用最大個數,最小個數，比最小個數少一，比最大個數多一的數作為測試數據。

3）根據規格說明的每個輸出條件，使用前面的原則1）。

4）根據規格說明的每個輸出條件，應用前面的原則2）。

5）如果程序的規格說明給出的輸入域或輸出域是有序集合，則應選取集合的第一個元素和最後一個元素作為測試用例。

6）如果程序中使用了一個內部數據結構，則應當選擇這個內部數據結構的邊界上的值作為測試用例。

7）分析規格說明，找出其它可能的邊界條件。

3、錯誤推測法。錯誤推測法是基於經驗和直覺推測程序中所有可能存在的各種錯誤，從而有針對性的設計測試用例的方法.

4、因果圖法：描述對於多種條件的組合，相應產生多個動作的形式來考慮設計測試用例. 這就需要利用因果圖（邏輯模型）。因果圖方法最終生成的就是判定表。它適合於檢查程序輸入條件的各種組合情況。把判定表的每一列拿出來作為依據，設計測試用例。

5、正交試驗設計：就是使用已經造好了的正交表格來安排試驗並進行數據分析的一種方法，目的是用最少的測試用例達到最高的測試覆蓋率。

6、功能圖法：使用功能圖形式化地表示程序的功能說明，並機械地生成功能圖的測試用例。是一種黑盒白盒混合用例的設計方法。

7、場景法：通過運用場景來對系統的功能點或業務流程的描述，從而提高測試效果的一種方法。

附錄3 白盒測試

1、定義：白盒測試是一種測試用例設計方法，盒子指的是被測試的軟體，白盒指的是盒子是可視的，你清楚盒子內部的東西以及裡面是如何運作的。"白盒"法全面了解程序內部邏輯結構、對所有邏輯路徑進行測試。通過檢查軟體內部的邏輯結構，對軟體中的邏輯路徑進行覆蓋測試;在程序不同地方設立檢查點，檢查程序的狀態，以確定實際運行狀態與預期狀態是否一致。

2、測試要求：

1.保證一個模塊中的所有獨立路徑至少被使用一次。

2.對所有邏輯值均需測試 true 和 false。

3.在上下邊界及可操作範圍內運行所有循環。

4.檢查內部數據結構以確保其有效性。

3、 白盒測試法的覆蓋標準有邏輯覆蓋、循環覆蓋和基本路徑測試。其中邏輯覆蓋包括語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋。六種覆蓋標準發現錯誤的能力呈由弱到強的變化：

1.語句覆蓋每條語句至少執行一次。

2.判定覆蓋每個判定的每個分支至少執行一次。

3.條件覆蓋每個判定的每個條件應取到各種可能的值。

4.判定/條件覆蓋同時滿足判定覆蓋條件覆蓋。

5.條件組合覆蓋每個判定中各條件的每一種組合至少出現一次。

6.路徑覆蓋使程序中每一條可能的路徑至少執行一次。

4、白盒測試的測試方法有代碼檢查法、靜態結構分析法、靜態質量度量法、邏輯覆蓋法、基本路徑測試法、域測試、符號測試、z路徑覆蓋和程序變異。

1、基本路徑測試法是在程序控制流圖的基礎上，通過分析控制構造的環路複雜性，導出基本可執行路徑集合，從而設計測試用例的方法。