更高級別的測試

當程序沒法實現最終用戶要求的合理功能時，就會發生一個軟件錯誤。

根據這個定義，即便完成了一次很是完美的模塊測試，仍然不能保證已經找出了程序的全部錯誤。所以，要結束整個測試任務，必須進行其餘形式的更深刻的測試，將這些新型形式的測試稱爲「更高級別的測試」

軟件開發週期的文檔說明：

●要求規格說明定義了爲何要開發程序

●目標定義了程序要作什麼，以及作得怎樣

●外部規格說明了程序對用戶的準確表現

●與後續階段相關的文檔愈來愈詳細地規定了程序是如何創建起來的

肯定軟件開發週期7個階段包括了信息的溝通，理解和轉換，以及大多數的軟件錯誤都源於信息處理中的故障，如今有三個方法來預防和識別這些錯誤。

1. 能夠是軟件開發過程更加精密，以防其中有不少錯誤。
   

2. 引入獨立的驗證過程，在進入下一階段前儘量多地發現錯誤。

3. 對不一樣的階段的採用不一樣的測試方法，應該在開發和測試過程之間創建一對一的聯繫。

        ●模塊測試的目的是是發現程序與規格說明之間的不一致

        ●功能測試的目的是爲了說明程序未能符合其外部規格說明

        ●系統測試的目的是爲了證實軟件產品與其初始目標不一致

注：咱們討論功能測試，系統測試，驗收測試和安裝測試的過程。這裏忽略了集成測試。由於集成測試每每不是做爲獨立測試步驟，並且在增量模塊測試中，它是模塊測試的隱含部分。

1.功能測試

功能測試是一個試圖發現程序與其外部規格說明之間存在的不一致的過程。外部規格說明是一份最終的用戶角度對程序行爲的精確描述。

功能測試一般是一項黑盒操做，也就是說，依賴早期的模塊測試過程來實現理想的白盒邏輯規則。

在功能測試時，須要對規格說明進行說明以獲取測試用例集，如等價類劃分，邊界值分析，因果圖分析和錯誤猜想法。最後應該牢記測試的目的是爲了暴露程序的錯誤以及規格說明不一致之處，而不是爲了證實程序符合外部說明。

2.系統測試

系統測試並非測試整個系統或程序功能的過程。由於有了功能測試這樣會顯得多餘。系統測試有着特定的目的：將系統或程序與其初始目標進行比較，給定這個目標後，隱含兩方面的含義：

1. 系統測試並不侷限於系統，若是產品是一個程序，那麼系統測試就是一個試圖說明程序做爲一個總體是如何不知足其目標的過程。
   

2. 根據定義，若是產品沒有一組書面的，可度量的目標，系統測試將沒法進行。

再尋找程序與其目標不一致的過程當中，應重點注意那些設計外部規格說明所犯的錯誤。這也暗示了與功能測試不一樣，外部規格說明不能做爲系統測試用例的基礎，不然就破壞了系統測試的目標。另外一方面，也不能用文檔自己表示測試用例，由於這些文檔並不包含對接口的準確描述。

克服方法：利用程序的用戶文檔，經過分析目標文檔來設計系統測試，分析用戶文檔來闡明測試用例。

目標雖已闡明，但沒有確認生成測試用例的方法，僅含一些含糊卻有用的指南來指導如何編寫測試用例，以證實程序與中的目標文檔每一句都存在不一致性。事實上，設計好的系統測試用例比設計系統或程序須要更多的創造性。

2.1能力測試

最明顯的系統測試類型是判斷目標文檔說起的每一項能力是否確實以實現，能力測試的語句是逐條檢查目標文檔，語句定義了一個「要作什麼」，就判斷該程序是否知足，這種類型的測試經常在不一樣的計算機狀況下運行，又是人工對目標文檔和用戶文檔進行比較久足夠了。

2.2容量測試

是使程序經受大容量數據的檢驗，例如：編譯器可能要處理編譯規模很是大的源程序，編譯器可能須要處理一個包含上千模塊的程序等等。而操做系統的做業隊列可能已經達到飽和容量。若是程序須要處理跨越不一樣的卷，則應產生足夠的數據使程序從一個卷轉到另外一箇中。故：容量測試的目的是爲了證實程序不能處理目標文檔中規定的數據容量

2.3強度測試

強度測試使程序承受高負載或強度的檢驗。所謂高強度就是指在短期間隔內達到數據或操做的數量峯值。相似一名打字員，容量測試是判斷打字員可否處理大篇幅的稿子，而強度測試是判斷打字員可否達到每分鐘50個單詞的速度。

基於web的應用程序是最長接受強度測試的軟件之一，在這裏，咱們須要確信是應用程序以及硬件可以處理必定容量 的併發用戶，但有人會狡辯說，也許數百萬人在同一時刻訪問該站點，但這是不現實的，咱們須要弄清用戶羣，而後設計一個強度測試，體現出可能訪問站點的最大人羣的狀況。

2.4易用性測試

今天的軟件系統，尤爲那些廣大的商業市場而設計的軟件。一般有普遍的人爲因素的研究。列舉測試中的一些問題：

1. 每一個用戶界面是否可以根據最終用戶的智力，教育背景和環境進行了調整
   

2. 程序輸出是否有意義，不模糊且沒有計算機雜亂信息

3. 診斷錯誤（如錯誤信息）是否直接。

4. 總體的用戶界面是否在語法，慣例，語義，格式，風格和縮寫方面展示出至關程度的概念完整性。

5. 在準確性極爲重要的環境中，如網上銀行系統，輸入中是否有足夠的冗餘信息例如：該系統可能會要求輸入帳號，用戶名和PIN來驗證訪問帳號信息是合法用戶。

6. 系統是否包含過多或不大可能遇到的選項？

7. 對於全部的輸入，系統是否返回了某些類型的及時的確認消息。

8. 程序是否易用。如輸入是否區分大小寫這一點對用戶來講是否清楚。此外，若是須要瀏覽一系列的菜單操做，返回主菜單的方法是否清楚。

2.5安全型測試

安全性測試是設計測試用例來破壞程序安全性檢查的過程。舉例來講，咱們能夠設計測試用例來規避操做系統的內存保護機制，破壞數據庫管理系統的數據安全機制。設計這種測試用例的方法之一是研究相似系統中已知的安全問題，而後生成測試用例，儘可能暴露被測系統存在的類似問題。

基於web的應用程序經常比絕大多數程序所需的安全測試級別更高，對於電子商務網站尤爲如此，儘管已經有了足夠多的技術（密碼學）容許客戶在因特網上安全地完成交易，但不能單純地依賴技術的應用來確保安全。

2.6性能測試

不少軟件都有特定的性能或效率目標，這些特性描述在特定負載和配置環境下程序響應時間和吞吐量，再一次強調，因爲系統測試的目的是爲了證實程序不能實現其目標，所以，應設計測試用例來講明程序不能知足其性能目標。

2.7存儲測試

相似的，軟件可能偶爾有存儲目標，舉例來講，可能描述了程序使用內存和輔存的容量，以及臨時文件或溢出文件的大小，應用測試用例來證實這些存儲目標沒有獲得知足。

2.8配置測試

諸如操做系統，等都支持多種硬件配置，包括I/O設備，通訊線路，或不一樣的存儲容量。一般可能配置的數量很是大，沒法面面俱到，但至少有一種類型的設備，以最大最小的配置來測試程序。如軟件自己的配置可忽略掉某些程序組件，或可運行在不一樣的計算機上，軟件全部可能的配置都應測試到。

現在的軟件都設計在可運行的多種操做系統環境下，所以若是設計此類程序，應該在該程序面向的全部操做環境中進行測試。

2.9兼容性/配置/轉換測試

大多數開發軟件並非全新的，經常爲了替換掉某些不完善的軟件，每每有着特定的目標，設計現有系統的兼容以及現有系統的轉換過程。針對這些目標測試程序，測試用例的目的是爲了兼容性目標未被知足，轉換過程爲生效。將數據從一個系統轉換到另外一個系統時，應盡力發現這些錯誤。升級數據庫管理就是一個例子。不少不一樣的方法測試這個過程，但這些方法都高度依賴於所用的數據庫系統。

2.10安裝測試

有些類型的軟件系統安裝過程很是複雜，測試安裝過程是系統測試中一個重要的部分，對於包在軟件安裝包的自動安裝系統而言，尤爲重要，安裝若是出現錯誤，可能會影響用戶對軟件的成功體驗。

2.11可靠性測試

固然，全部類型的測試是爲了提升軟件的可靠性，但軟件的目標中包含了對可靠性的特別描述，就必須專門設計可靠性測試。此種類型的軟件證實或測試聽起來很複雜，可是對於那些必須維持很是高的正常時間運行時間的系統。重要性日益增長。

2.12可恢復性測試

諸如操做系統，數據庫管理系統，和遠程處理系統等軟件，一般有可恢復性目標，說明系統是如何從錯誤、硬件失效和數據錯誤中恢復過來，系統測試的一個目標是爲了證實這些恢復機制不可以正常發揮做用。咱們能夠故意將程序錯誤步入某個系統中，判斷系統是否能夠從中恢復。諸如內存錯誤，I/O錯誤等硬件錯誤能夠模擬。而如通訊中的線路噪音或數據庫中的無效指針等數據錯誤也能夠模擬出來。以分析系統的反應。

2.13適用性測試

軟件還能夠有適用性或可維護性的目標，全部此類的目標必須測試到，這些功能可能定義了系統提供的輔助功能，包括存儲轉發程序或診斷程序，調試明顯問題的平均時間、維護過程以及內部業務文檔的質量等。

2.14文檔測試

系統測試也須要檢查用戶文檔的正確性，完成此任務主要方法是根據文檔來肯定系統測試用例的形式，也就是說，一旦設計完成某個具體的測試狀況，應該使用文檔來做爲編寫實際測試用例的指南。同時，用戶文檔做爲審覈的對象，檢查其正確性清晰性。在文檔中描述的任何範例應當編寫成測試用例，並提交給程序。

2.15過程測試

不少軟件都是較大系統的組成部分，這些系統並非徹底自動化的，包含了不少人員操做過程。在系統測試中，必須對全部已經規定的人工過程，如系統操做員、數據庫管理員或最終用戶的操做過程進行測試。

數據庫管理員必須記錄備份和恢復數據庫系統的操做過程。在可能的狀況下，應由與數據庫管理不相關的人來測試這些狀況。然而，公司必須爲充分測試這些過程提供所需資源，這些資源一般包括硬件和額外的軟件許可證。

2.16系統測試的執行

系統測試執行的最關鍵的一個考慮是決定由誰來進行測試。（1）不能由程序員來進行系統測試；（2）在全部的測試階段之中，這是惟一一個明確地不能由負責該程序開發的機構來進行測試

第一點基於的事實是，執行系統測試的人思考問題的方式必須與最終用戶相同，顯然，理想的測試小組應由幾位專業的系統測試專家（以執行系統測試爲職業）、一位或者兩位最終的用戶表明，一位人類工程學工程師以及該程序主要分析人或者設計者所組成。

第二點基於現實的是，大多數開發機構最關心的是讓系統測試進行的儘量順利而且按時完成，而不會盡力去證實程序不能知足其目標。系統測試至少應由不多受開發機構左右的獨立人羣來執行，也是最經濟的執行系統測試的形式。

3.驗收測試

驗收測試是將程序與最初的需求及最終用戶當前的須要進行比較的過程。這是一種不尋常的測試用例，由於這一般是由程序的客戶或最終用戶來進行通常不認爲軟件開發機構的職責，由訂購方（用戶）來驗收測試。將程序的實際操做與原始合同進行對照。與其餘類型的測試同樣，驗收測試最好的方法是設計測試用例，盡力證實程序沒有知足合同的要求。

4安裝測試

它與其餘測試過程不一樣，與設計過程當中的任何階段都沒有聯繫，它的目的不是爲了發現軟件的錯誤，而是爲了發現安裝過程當中出現的錯誤。

在安裝軟件系統期間會發生不少事件，簡單歸納下列事件

1. 用戶必須選擇大量的選項。
   

2. 必須分配並加載文件和庫

3. 必須進行有效的硬件配置

4. 軟件可能要求網絡連通，以便與其餘軟件鏈接。

測試用例須要檢查以確認已選的選項集合互不衝突，系統的全部部件所有存在，全部文件已常常見幷包含必須內容。

5測試計劃與控制

與大多數項目的狀況同樣，計劃是管理測試過程當中相當重要的一部分，一個良好的測試計劃包括：

1）目標。必須定義每一個測試階段的目標

2）結束準則。必須制定準則以規定每一個測試階段什麼時候該結束

3）進度。應什麼時候設計、編寫執行測試用例。

4）責任。對於每個階段，應當有誰來設計、編寫驗收測試用例，誰來修改發現軟件錯誤。

5）測試用例庫及標準

6）工具。包括由誰來開發或採購，如何使用工具以及什麼時候須要使用工具。

7）計算機時間。計劃每一個測試所須要的時間

8）硬件設備。如特別須要的硬件設備或裝備，則需一份計劃來描述該需求，應該如何知足需求以及什麼時候須要知足。

9）集成。測試計劃的一部分是定義程序如何組裝在一塊兒的方法（如自頂向下的增量測試）。一個系統若是包含大的子系統或程序，可按增量方式組裝在一塊兒，例如自頂向下或者自底向上的方法，但這些構造塊是程序或者子系統，而不是模塊。若是是這種狀況，就須要個系統集成計劃。系統集成計劃規定了系統集成的順序。

10）跟蹤步驟。必須跟蹤進行中的方方面面，包括對錯誤易發模塊的定位以及有關進度、資源和結束準則的進展估計。

11）調試步驟。必須制定上報已發生錯誤、跟蹤錯誤修改進程以及將修改部分加入系統中去的機制。調試計劃中還應包括進度、責任分工，工具以及計算機時間/資源等。

12）迴歸測試。是對程序功能改進或者修改以後進行，其目的是判斷程序的改動是否引發了程序其餘方面的退步。迴歸測試一般是執行測試用例中的某個子集。迴歸測試很重要，由於由於程序的改動和對錯誤的糾正要遠比原來程序代碼更容易出錯。迴歸測試計劃規定測試人員，測試方法和測試時間，它也是必須的。

6測試結束準則

1)用完了安排的測試時間後，測試便結束。

2)當執行完全部測試用例都爲發現錯誤，測試便結束。

以上兩條沒有任何做用。不能保證測試用例的質量。

有三類較爲有用的結束準則。

第一類：

測試用例來源於：

（1）知足多重條件覆蓋準則

（2）規模塊接口規格說明進行了邊界值分析，產生的全部測試用例最終都是不成功的

在知足下列狀況時規定測試功能結束

測試用例來源於

（1）因果圖分析

（2）邊界值分析

（3）錯誤猜想產生的全部測試用例均不成功

第二類：

（1）預測出程序中錯誤的總數量

（2）預測這些錯誤中有多大比例可能經過測試而發現

（3）預測這些錯誤中有多少是由各個設計階段產生的，以及什麼樣的測試用例可以發現這些問題。

第三類結束準則表面上看上去很容易，其中涉及不少判斷和直覺，須要在測試過程當中記錄單位時間發現錯誤的總量。假設某個程序正在進行功能測試，對於每週發現的錯誤數量都進行了記錄，若是第七週的曲線仍然相對於前幾周處於上升狀態，那麼這時候結束顯然有些草率。此時應該繼續進行功能測試。另外一方面，若是程序中的錯誤一直處於降低階段，而且第七週比前幾周都低，此時也許就是最佳的行動結束功能測試並開始新的測試類型。固然也要考慮其餘因素。

最佳結束準則多是上述三種類型的結合

7.獨立的測試機構

就公司的架構而言，而是部門用該儘量遠離開發部門。事實上，最理想的測試機構不該該是同一公司的一部分。而是僱傭獨立的公司進行軟件測試。