軟件的最低測試方法

　　前言

　　1.1. 引言

　　對于大部分軟件系統，如何測試及有效的測試，是一個很頭痛的問題。在軟件工程上，測試是軟件工程中極其重要的一部分; 但在具體的實際情況上，無論是時間、人手及資源的調配等原因，使國內大部分軟件公司沒有進行過理論上的完整的測試。

　　本文想要描述的，就是一種簡單可行，又能使軟件系統達到最低質量要求的一組測試方法。

　　1.2. 測試目的

　　對于任何一款軟件來講，它的價值在于正確的實現了用戶的需求，那么測試的最終目的，就是測試軟件是否真正的對于用戶的需求進行了實現，并使系統達到用戶可以接收的程度。

　　1.3. 測試方法

　　用戶對于軟件的最終的認可程度及驗收情況，就是對于一個軟件的最終的認同，然后才能投入正確的使用。所以對于開發者來講，最終將系統交付于用戶前，是必須具備一整套科學的完善的內部測試的方法。內部測試時，開發商會一致要求測試人員從用戶的角度來使用，并進行逐一的測試，測試通過后，才能把系統提交給用戶。

　　也就是說內部的測試最少要進行系統的確認及系統的測試等相關的部分。

　　2. 內部測試流程

　　2.1. 測試前期準備

　　測試前首先要根據系統情況，準備相應的機器及設備，還要建設相應的測試環境，配備相應的測試人員。

　　對于相應的測試人員必須從客戶的角度進行測試，也就是說在測試前要非常明確系統要達到的功能目標，測試人員所具備的專業的鑒賞能力，應當明白重點及非重點。

　　測試人員對于需求的明確性是內部測試最低的要求 。

　　2.2. 編寫測試計劃

　　測試計劃一定要包涵以下內容：

　　1 .確定測試人員并進行分工，明確各自的職責。

　　2 .明確的測試功能，進行功能的優先順序排序。

　　對于測試工作安排一般次序如下：

　　? 系統安裝

　　? 系統參數設置

　　? 遍歷所有的業務功能，并明確是否實現了所有的需求

　　? 通過測試

　　? 準確性測試(含數據測試)

　　? 失敗測試

　　? 狀態測試

　　? 業務處理功能查詢功能及報表功能

　　? 系統性能

　　3 .測試數據設計說明。

　　4 .培訓及其它支持條件

　　2.3. 測試用例設計

　　2.3.1. 測試用例的編寫

　　關鍵點

　　1. 測試用例的功能點必須由 SA 編寫明確及進行解析，大量的測試案例由測試小組進行編寫，最終的測試用例由 SA 進行簽字確認

　　2. 當然如果 SA 不進行編碼，那么測試組長由其擔任是最為合適的。

　　3. 功能點的跟蹤與變更必須即時更新，一般由 SA 或 PM 進行，測試案例也必須進行相應更新。

　　實際過程中需要根據可用的資源(人力、物力及時間等)用盡量少的測試用例，來發現更多的錯誤。給最終用戶提供具有一定可信度的質量評價。如果想編寫和測試所有的用例是不太現實的，下面是一個具體的例子，在實際測試過程中良好的程序員，也只能列出下面實際需要的測試用例的一半多一點。

　　2.3.2. 一個典例測試用例

　　程序：一個程序接受 3 個整型輸入。 3 個整型值代有表三角形的 3 條邊。根據這 3 個值，程序要確定出這個三角形是不等邊三角形、等腰三角形還是等邊三角形。

　　完整的測試用例：

　　測試用例的目的 注釋

　　有效的不等邊三角形 諸如 1 、 2 、 3 和 2 、 5 、 10 之類的測試用例不能保證“是”答案，因為不存在這樣的三角形

　　有效的等邊三角形

　　有效的等腰三角形 1 ， 1 ， 2 類測試用例不能計算在內，因為不存在這樣的三角形

　　測試用例是有效的等腰三角形，從而就包括了兩個等邊的 3 個置換 例如： 3 、 3 、 4 ; 3 、 4 、 3 和 4 、 3 、 3

　　一個邊是 0

　　一個邊是負值

　　3 個大于 0 的整數，并且 2 個數的和與第 3 個數相等 如果程序認為 1 、 2 、 3 表示不等邊三角形，則是一個 BUG

　　在上面測試中至少有 3 個測試用例，這樣你便可以嘗試 3 種排列。其中 1 個邊的長度等于另外 2 個邊和的長度

　　3 個大于 0 的整數，并且 2 個數的和小于第 3 個數 如： 1 、 2 、 4 和 12 、 15 、 30

　　在上面測試中至少有 3 個測試用例，這樣你可以嘗試 3 種排列 如： 1 、 2 、 4 ; 1 、 4 、 2 和 4 、 1 、 2

　　所有的邊為 0

　　非整數值

　　輸入數據的個數錯誤 如輸入 2 個或多于 3 個數

　　是否規定了每一個測試用例的預期輸出

　　(摘錄自《軟件驗證與確認的最佳管理方法》)

　　2.4. 測試流程

　　測試的流程對于實際情況有兩種 :

　　2.4.1. 開發小組程序員之間的聯調

　　程序員之間的聯調多發生在多個子系統構成的大系統或一個系統由多人根據功能分工編寫的情況下。

　　測試流程一般由業務發起點的功能編寫者發起測試，到達業務的終止點為結束。

　　具體形式如下：

　　起始點的開發者發起業務后，添寫紙質的聯調測試書，明確發起的內容，送到下一個處理環節的程序員處。

　　相應的下一環節程序員，進行相應的處理。處理完畢后，添加聯調測試書中相應的部分或在聯調測試書中簽字說明已經完成相應的處理，再送下一處理環節的程序員處，通過這種類似層層審批的方式到達最終點，完成內部聯調流程。

　　內部聯調是對于每個程序員所編程序的測試，由于分工及技術水平的不同，一般容易產生每個程序員工作量及進展難于把握 的情況，所以對于聯調測試期人員分工要進行靈活調動的方式。

　　2.4.2. 測試小組同程序開發小組的工作形式

　　1. 程序人員自我測試后提交項目經理請求測試驗收，項目經理文字或其他方式通知測試負責人準備提交測試，測試負責人到程序員處當場進行初驗(程序員當場演示)，記錄當場發現的 BUG 數(推薦每個程序員的辦公桌前有一個 初驗 BUG 數表 ，每次初驗 BUG 數記錄在文件內， 周報時通報 每周最高和最低的人員及 BUG 數，，最終測試期階段初驗 BUG 數據影響程序人員考核，用來加強程序人員進行初驗前的自驗重視程度)

　　2. 初驗合格，程序員把項目文件(源程序包)及 EXE 文件(或安裝程序包)打包在一個 ZIP 文件。發送給內部文件管理員或項目規定的測試文件存放目錄，否則程序員進行修改后并重復第 1 步。

　　3. 文件管理員進行本次測試的版本文件歸檔后，文件管理員再通知測試負責人要進行測試的文件所存放的位置。

　　4. 測試負責人取相應的系統進行測試， 記錄測試過程 ，最終提交測試結果形成 BUG 列表，傳達給項目經理 , 項目經理審查后再傳送給程序員。

　　5. 程序員根據 BUG 列表進行相應的程序修改，并對 BUG 列表文件進行更新，發送給項目經理，項目經理審核后再傳送給測試負責人。

　　6. 重復第 1 步，后期的測試中測試人員將對原測試錯誤進行跟蹤審查。

　　測試負責人及文件管理員可以是專人也可由項目經理或系統分析員兼任。

　　如果使用最終用戶作為測試人員，千萬注意，過多的 BUG (特別是對于金額的誤差)的發現，會使用戶對系統有恐懼心理，認為將來給他們的程序是一個大炸彈。所以在提交前，必須進行嚴格的自驗。對于 BUG 的必需嚴肅的對待，不然將影響用戶對系統的信心。對于由于不嚴謹產生嚴重的 BUG ，必須進行必要的批評(周會或小組會議)，使程序員加強自身的檢查。

　　2.4.3. 測試小組工作要求

　　1 、 BUG 列表的提交及數據提交

　　A) 要求記錄所有的 BUG 。

　　B) 重大 BUG 可即時提交由項目組解決，但必須作好 BUG 記錄，并繼續其它的測試 ( 除不能進行測試以 外 ) 。

　　C) 對于某些測試人員認為要進行的測試，若進行不了，應作 BUG 提交。

　　D) 數據的記錄應詳細，所作的所有操作關鍵數據均應記錄。

原文轉自：http://www.anti-gravitydesign.com