測試用例的準備，都是為了執行測試準備的。

測試環境的搭建

　　（1）測試數據：有些測試需要使用大批量的數據，例如容量測試、壓力測試等。根據產品的具體測試要求，可能需要在數據庫表插入大量的數據，準備大量的文件，生成大量的Socket包等。

　　（2）有些測試需要專門的外部硬件設備，比如打印機，條碼識別器，讀卡機，指紋儀等。

　　　　?如果是手機應用測試，可能要把所有支持的型號的手機都準備好。這些設備有些可以使用模擬器來模擬，有些則不能。模擬器比如夜神安卓模擬器。經常遇到在手機模擬器上可以執行的程序，在真正的手機上運行則會出現問題，或者在pc上報表格式正確，但是真正打印出來則會移位，走樣。

　　（3）有些產品需要支持多種操作系統，那么在做兼容性測試之前就需要準備好各種操作系統的計算機，或者可以考慮虛擬機來安裝，如vm ware,virtual PC等。

　　（4）有些測試需要部署到多臺機器，并且需要設置各種參數，那么就需要在測試之前準備好各種安裝包。

　　（5）有些測試需要用到網絡，設置需要考慮網絡的路由設置、拓撲結構等，那么在測試之前就需要準備好這樣的網絡設備和網絡環境配置。

BVT測試與冒煙測試

　　BVT測試（Build Verification Test)），編譯檢查測試，主要檢查源代碼是否能正確編譯成一個新的，完整可用的版本。如果BVT不通過，測試人員不能拿到新的版本進行測試。

　　冒煙測試，該概念來源于硬件生產領域，一般通過給制造出來的電路板加電，看電板是否通電，如果設計不合理，則可能在通電的同時馬上冒出煙，電路板不可用，因此沒有必要進行下一步的檢測。

　　那么該概念應用于軟件測試，其實意義也一致。就是主要驗證主功能，如果主功能都行不通，那就沒有驗證下去的必要，直接把編譯版本退回給開發人員修改。

　　需要注意的是，冒煙測試的測試用例應該是隨著開發的深入而不斷演進的。

每日構建的基本流程

　　程序模塊的集成問題是一個導致開發進度受阻的常見原因。缺陷也往往在集成階段才集中出現的，尤其是那些接口設計不夠好的軟件。

　　那么解決集成問題的最后辦法就是盡早集成，持續地集成，小版本集成。通過每日構建可以達到持續集成，小版本集成以及版本集成驗證的目的。

　　每日構建就是每天定時把所有的文件編譯，連接，組成一個可執行的程序的過程。

　　通常把每日構建放在晚上，利用空余時間自動進行，因此也叫每晚自動構建。簡單的流程如下圖

通過每日構建來規范代碼管理

　　每日構建除了可以解決部分版本集成的問題外，還可以對程序員的源代碼簽入簽出行為做出規范性約束。

　　大家都知道，如果程序員沒有遵循一定的規范簽入，簽出源代碼，就很可能導致其他程序員的代碼模塊失效或者混亂。一個正確而謹慎的做法應該是每次簽入自己修改的代碼之前，先獲取所有新版本并把所有代碼編譯通過，確保不會影響別人的代碼時才簽入，否則必須先把問題解決掉。

　　每日構建是一個提高士氣的機制，每天項目組的所有人都能看到構建出來的新版本增加了哪些新特性，看到能工作的產品，并且每天都比前一天多一些，增強一些，就像看到自己的孩子在茁壯地成長著，給所有人一種信心和鼓舞。

測試的記錄和跟蹤

　　bug的質量：所謂質量，是指測試人員錄入bug描述的清晰度，越容易理解的bug，質量越高。開發跟測試之間也不用花費大量時間去理解該bug如何修改合適。

如何錄入一個合格的bug

發現問題的版本

　　一般來說，在不同版本發現同一個Bug,有可能是由于不同原因產生的。所以如果在版本1.1修改完該Bug后，在版本1.2又發現了該bug，不應該把版本1.1的bug激活，而應該重新錄入一個bug，版本改為1.2。因為這是一個新增的Bug,測試人員需要重新驗證，統計。如果激活上一個bug也可能造成質量統計時的漏算。

問題出現的環境

　　問題出現的環境包括操作系統環境、軟件配置環境，有時候還需要包括系統資源的情況，因為有些錯誤只有在資源不足時才出現。

　　由于開發環境與測試環境存在差異，往往導致有些問題只有在測試環境下才能出現。例如開發環境中使用的某些第三方組件在測試環境沒有注冊。這時測試人員應該把這些差異寫清楚，以便開發人員在重新問題和進入調試之前把環境設置好。

問題重現步驟

　　描述問題出現的操作步驟。要盡量把操作步驟縮減到必須執行才能重新錯誤的幾個步驟。別浪費步驟在無關問題上面，影響重現進度。

預期行為的描述

　　需要讓開發人員知道什么才是正確的。有些描述不清的，如“編輯單據時，列表中不出現日期信息”，那么你是希望他出現日期呢，還是不出現日期呢？一般描述就加上XX應該XX或者SS不應該SS。

錯誤行為的描述

　　描述問題的現象。例如“程序拋出異常信息如下。。。”，如實反映，不要夸大。

除了以上，還有嚴重程度，優先級別，出現模塊，缺陷類型，發現日期等等，一般在缺陷管理系統中都會提示填寫。

BUG描述中應該注意的幾個問題

1、不要出現錯別字

　　我們是做測試的，就是要把錯誤找出來，我們是找BUG而不是創建BUG。

2、不要把幾個BUG錄入到同一個ID

　　最好一個問題一個ID，比如創建一個客戶，沒有做非空校驗，保存也出現異常。這時候需要分為2個ID錄，雖然在同個模塊同個界面，但是分開錄有利于后面可以清晰地跟蹤所有BUG的狀態，并且有利于缺陷的統計和質量的衡量。

3、附加必要的截圖和文件

　　有截圖或者文件，并且在截圖上框出出錯的位置，標記上問題，能讓開發更快速地定位到錯誤，高效率地修改。

4、錄入完一個BUG后自己讀一遍

　　如果一個BUG錄完之后連自己都讀不通，那么別想開發人員能修改高質量的產品，所以錄完之后自己讀一遍，讀通了之后再進行其他的測試。

如何跟蹤一個BUG的生命周期

　　創建-打開-修復（拒絕/延期）-關閉-激活

如何與開發人員溝通一個BUG

　　能讓開發人員解決最多的BUG的測試人員是最優秀的測試人員，如果能正確地，高質量地錄入一個BUG，那已經跟開發人員溝通了一大半關于BUG的信息，但是有些BUG字面會說不清楚，所以我們就得自己找開發談，最好演示一遍給開發看。注意的是，跟開發講BUG的時候一定要語氣平和，千萬不要趾高氣揚，指責開發等語氣，因為每個人都是不喜歡收拾爛攤子的，所以我們需要用技巧地跟開發溝通，比如說麻煩了，辛苦了之類的，這樣的話，開發會更樂意修改這個BUG，心情好修改當然質量高了。