關鍵字：測試方法
1. 前言... 1.1. 引言..
1.2. 測試目的
1.3. 測試方法
2. 內部測試流程
2.1. 測試前期準備
2.2. 編寫測試計劃
2.3. 測試用例設計
2.3.1. 測試用例的編寫
2.3.2. 一個典例測試用例
2.4. 測試流程
2.4.1. 開發小組程序員之間的聯調
2.4.2. 測試小組同程序開發小組的工作形式
2.4.3. 測試小組工作要求
2.4.4. 測試組工作流
2.5. 常規問題
2.5.1. 程序人員自測不嚴
2.5.2. 數據約束的合理性是桌前檢查第一步
3. 軟件的測試標準
4. 附錄...
4.1. 測試計劃大綱
4.2. BUG列表必要內容..
4.3. 常用名詞定義
4.4. 關于α、β測試..
1. 前言
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) 數據的記錄應詳細，所作的所有操作關鍵數據均應記錄。
2、BUG的跟蹤
A) 對自己發現的BUG已解決和未解決的問題進行跟蹤。
B) 對新版本中仍未解決的問題應另外作BUG記錄，并可注明“遺留問題”。
3、測試任務分工
明確每人的測試重點，文件的保存位置，提交BUG的方式，所有的BUG由測試組長匯總后提交給項目組。
2.4.4. 測試組工作流
1. 項目組PM提交測試程序；
要求：包含所有工程文件和執行文件（第一次要求是項目組經過預測試的可運行程序）
2. 測試人員驗收；
3. 測試人員將所有文件打進一個包；
4. 提交給項目配置庫；
5. 測試執行
說明：測試人員按《測試任務分工》、《業務依賴關系》及相關的《需求文檔》 執行測試
6. 填寫《測試記錄》與《BUG列表》
要求：《測試記錄》在測試過程中按照要求即時、詳盡的填寫；《BUG列表》每天測試完成后按要求填寫
7. 將《測試記錄》與《測試BUG列表》提交測試組長（不長于2天提交一次）；
說明：測試人員不長于2天完成一輪測試
8. 測試組長統計測試情況并及時將BUG列表提交項目組PM
9. 項目組及時更改程序并跟蹤記錄BUG的解決情況；
要求：項目組不長于2天的時間，提交一次軟件新版本（以日期定義版本）給測試小組進行測試。新版本軟件提交到配置庫并及時通知測試組
2.5. 常規問題
2.5.1. 程序人員自測不嚴
程序人員在有測試人員的情況下，對于編碼后的程序常不行全面的測試后就會拋給測試小組進行測試，使測試小組承擔過多的責任，解決方式：程序人員進行單元測試，提供單元測試記錄，加強程序嚴謹性；在一定（一天或兩天）時間程序進行代碼暫時封凍，程序員進行互測，使其了解自己編的程序到底如何或給項目領導進行演示，破壞其自我優越感。
2.5.2. 數據約束的合理性是桌前檢查第一步
數據是否是約定條件范圍內；對于越界處理是否正常；默認、空白、null值、零值的處理是否正常。
3. 軟件的測試標準
對于軟件的測試從以下幾個方面考慮：
1. 用戶需求的完整性：
是否根據用戶所要求的業務流程，進行了相應的具體系統的實現。
2. 文檔的完整性：
是否已經完成合同及約定所明確的所有的文檔。
3. 通過測試（含準確性測試）
測試的第一步，測試系統能做什么工作。
4. 條件覆蓋測試
測試的第二步，測試系統多方面考慮進行的如何。通過一定的測試數據明確是否進行了足夠的條件覆蓋，使系統達到足夠的質量。
5. 數據約束的合理性：
數據是否是約定條件范圍內；對于越界處理是否正常；默認、空白、null值、零值的處理是否正常。
6. 狀態控制
進行系統和功能在不同狀態下的處理，如數據庫關機，客戶機開機是否可以正常。
7. 軟件常規性能及其它：
軟件所需的操作環境及易使用性，可移植性、兼容性、錯誤恢復能力和可維護性等等是否為用戶認可。
對于測試的結果有兩種可能，一種可能是各種方面（主要是功能和性能指標）滿足軟件需求說明的要求，用戶接受系統；另一種可能是軟件不滿足軟件需求說明的要求，用戶無法接受。對于這個階段才發現的嚴重錯誤（一般指重要的業務邏輯）一般很難在預定的時間改正，因此必須與用戶協商，尋求一個妥善解決問題的方法。
關于作者：
王輝，具有八年的編程及系統管理經驗，所使用的語言為C和Java 編程語言。目前在深圳一家公司做項目經理，使用C和ORACLE數據庫開發應用系統�？赏ㄟ^ ddxxkk@21cn.com 聯系。
4. 附錄
4.1. 測試計劃大綱
摘自計算機軟件產品開發文件編制指南 GB 8567-88
這里所說的測試，主要是指整個程序系統的組裝測試和確認測試。本文件的編制是為了提供一個對該軟件的測試計劃，包括對每項測試活動的內容、進度安排、設計考慮、測試數據的整理方法及評價準則。具體的內容要求如下：
17．1引言
17．1．1編寫目的
17．1．2背景
17．1．3定義
17．1．4參考資料
17． 2計劃
17．2．1軟件說明
17．2．2測試內容
17．2．3測試1（標識符）
17．2．3．1進度安排
17．2．3．2條件
17．2．3．3測試資料
17．2．3．4測試培訓
17．2．4測試2（標識符）
．．．．．．
17．3測試設計說明
17．3．1測試l（標識符）
17．3．1．1控制
17．3．1．2輸入
17．3．1．3輸出
17．3．1．4過程
17．3．2測試2（標識符）
．．．．．．．
17．4評價準則
17．4．1范圍
17．4．2數據整理
17．4．3尺度
4.2. BUG列表必要內容
包括錯誤程序名稱及版本，錯誤主題，錯誤嚴重級別，測試過程描述，測試人，測試時間，修改結果，修改人，修改時間。
對于錯誤嚴重級別的分類說明如下：
? 嚴重錯誤：導致系統無法實現功能目標，使測試無法繼續進行。主要包括：程序不能起動、程序非正常終止、程序死機、關鍵需求未實現、嚴重的數值計算錯誤、安全性錯誤、文檔與軟件嚴重不符。
? 中等錯誤：導致系統無法正常實現功能目標，但知道如何通過其它途徑來避免錯誤發生。主要包括：程序非正常終止但可避免、系統邊界值錯誤、非關鍵需求理解錯誤、系統文檔錯誤。
? 輕微錯誤：導致用戶/操作員使用不方便，但不影響系統功能目標的實現。主要包括：查詢報告格式錯誤、用戶界面不很友好、顯示格式錯誤、輕微的數值計算錯誤、系統處理未優化、系統文檔存在輕微錯誤等。
? 建議：使系統更加完善的建設性意見等。
4.3. 常用名詞定義
白盒測試：如果已知產品的內部活動方式，可以測試它的內部活動是否都符合設計要求，這種方法叫白盒測試，檢查軟件的內部邏輯結構，是以仔細檢查過程的細節為基礎，通過提供一組指定條件和循環的測試用例，對穿過軟件的邏輯路徑進行測試，可以在不同點檢查程序的狀態，以確定實際狀態與預期狀態是否一致。
黑盒測試：著眼于軟件的外部特性，而不考慮軟件的內部邏輯結構。指在軟件的接口上進行測試，即看它能否滿足功能要求，輸入能否被正確地接收，并正確的輸出結果，以及能否保持外部信息（如數據文件）的完整性等等。
單元測試（模塊測試）：相當于分調，即逐個模塊考察，是以詳細設計描述為指南，對重要的控制路徑進行測試，用以發現錯誤。使用白盒子測試法。
集成測試（組裝測試或聯合測試）：相當于聯調，主要是考察模塊間的接口和各模塊間的聯系
確認測試（有效性測試）：是驗證軟件的功能和性能及其它特點是否與用戶的要求一致。功能與用戶的需求是否一致。使用黑盒測試。
系統測試（系統聯調）：是將通過確認測試的軟件，作為整個基于計算機系統的一個元素，與計算機硬件、外設、某些支持軟件、數據和人員等其他系統元素結合在一起，在實際運行（使用）環境下，對計算機系統進行一系列的組裝測試和確認測試。
驗收測試：由用戶實施，通過所謂黑盒子測試，來證實軟件功能與描述的需求是否一致
回歸測試：重復以前進行過的部分或全部測試
恢復測試：是一種系統測試，它以不同的方式強使軟件出現故障，用來嚴整軟件能否恰當地完成恢復
安全性測試：就是試圖去驗證建立在系統內的預防機制，以防止來自非正常的侵入。
強度測試：實在要求一個非常數量、頻率或容量資源方式下運行一個系統。它實際上是一種叫做敏感性測試技術
性能測試：就是測試軟件在給組裝進系統的環境下運行時的性能。性能測試應覆蓋測試過程的每一步
測試用例：一組最有可能發現某個錯誤或某類錯誤的測試數據
4.4. 關于α、β測試
事實上，軟件開發人員不可能完全預見用戶實際使用程序的情況。例如，用戶可能錯誤的理解命令，或提供一些奇怪的數據組合，亦可能對設計者自認明了的輸出信息迷惑不解，等等。因此，軟件是否真正滿足最終用戶的要求，應由用戶進行一系列“驗收測試”。驗收測試既可以是非正式的測試，也可以有計劃、有系統的測試。有時，驗收測試長達數周甚至數月，不斷暴露錯誤，導致開發延期。一個軟件產品，可能擁有眾多用戶，不可能由每個用戶驗收，此時多采用稱為α、β測試的過程，以期發現那些似乎只有最終用戶才能發現的問題。
α測試是指軟件開發公司組織內部人員模擬各類用戶行對即將面市軟件產品（稱為α版本）進行測試，試圖發現錯誤并修正。α測試的關鍵在于盡可能逼真地模擬實際運行環境和用戶對軟件產品的操作并盡最大努力涵蓋所有可能的 用戶操作方式。經過α測試調整的軟件產品稱為β版本。緊隨其后的β測試是指軟件開發公司組織各方面的典型用戶在日常工作中實際使用β版本，并要求用戶報告異常情況、提出批評意見。然后軟件開發公司再對β版本進行改錯和完善。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
